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

Question

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

container 和 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 检查丢失或失序的数据。例如，参见 资源中的 missingDataDetect 属性。

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

Answer 2

的两个用例在我看来比使用 更好。

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

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