使用 timeSeries 相对于容器资源的优势

Question

timeSeries 资源表示数据实例的容器，timeSeriesInstance 资源表示资源中的数据实例。

与容器和 contentInstance 的主要区别在于将时间信息与数据保持在一起并能够检测丢失的数据。

使用 timeSeries 和 timeSeriesInstance 资源代替 container 和 contentInstance 资源还有其他优势吗？

它是否也有助于节省数据冗余，例如如果我的一个应用程序实例每 30 秒发送一次数据，那么一天将创建 24*120 个 contentInstance。

如果正在使用 timeSeries 和 timeSeriesInstance 资源，那么对于上述情况，一天内会创建相同数量的 timeSeriesInstance（即 24*120）吗？

此外，将 contentInfo 属性保留在 timeSeries 而不是 timeSeriesInstance 中是否有任何特定目的（就像我们在 contentInstance 资源中有 contentInfo）

Answer 1

和 资源类型之间存在一些差异。

资源可以包含任意数量的 资源以及作为子资源的 和（子） 资源。这样做的好处是 可以进一步结构化以表示更复杂的数据类型。

这也是为什么contentInfo属性不能成为资源的一部分的原因，因为内容的类型可以混合，或者资源我根本没有直接的 资源。

资源只能有 资源作为子资源（、、 等除外）。假定所有子 资源都是同一类型，因此 contentInfo 位于 资源中。

资源也可能有一个 sequenceNr 属性，允许 CSE 检查缺失或 out-of-sequence 数据。例如，参见 资源中的 missingDataDetect 属性。

对于您的应用程序（每 30 秒发送和存储数据）：这取决于要求。始终传输测量值重要吗？或者知道何时丢失数据很重要？然后使用 和 。如果您的应用程序只是在测量值发生变化时发送数据并且检索最新值很重要，那么请使用 和 。

Answer 2

我觉得 的两个用例比使用 更好。

第一个用例涉及 dataGenerationTime 属性。这允许传感器专门记录传感器值被捕获的时间，而使用 您有创建时间（您可以将捕获时间放入 content 属性，但是然后需要额外的处理才能从 content 中提取）。如果您使用 的 creationtime 属性，时间将根据 CSE 接收原语的时间而有所不同。使用 时，变化消失了，因为 CREATE 请求包含 dataGenerationTime 属性。这使数据更加准确。

第二个用例涉及 missingDataDetect 属性。简而言之，使用它以及预期的 periodicInterval，您可以为您的传感器实现 "heartbeat" 类型的功能。如果传感器没有每 30 秒发送一次指示门 closed/open 的测量值，则可以发送一条通知，指示传感器发生故障或被篡改。