Преимущества использования timeSeries над контейнерным ресурсом

Question

Ресурс timeSeries представляет контейнер для экземпляров данных, а ресурс timeSeriesInstance представляет экземпляр данных в ресурсе.

Основное отличие от контейнера и contentInstance состоит в том, чтобы хранить информацию о времени с данными и иметь возможность обнаруживать отсутствующие данные.

Есть ли какое-либо другое преимущество, которое может быть достигнуто с использованием ресурса timeSeries и timeSeriesInstance вместо ресурсов контейнера и contentInstance?

Помогает ли это также в сохранении избыточности данных, например если мой единственный экземпляр приложения отправляет данные каждые 30 секунд, то через сутки будет создано 24 * 120 contentInstance.

Если используются ресурсы timeSeries и timeSeriesInstance, будет ли создаваться одинаковое количество timeSeriesInstance в день (т. Е. 24 * 120) для указанного выше случая?

Кроме того, существует ли какая-либо конкретная цель для хранения атрибута contentInfo в timeSeries вместо timeSeriesInstance (как у нас есть contentInfo в ресурсе contentInstance)

Answer 1

Два варианта использования для , которые кажутся мне лучше, чем использование .

В первом случае использования используется атрибут dataGenerationTime . Это позволяет датчику специально записывать время, когда было получено значение датчика, тогда как с у вас есть время создания (вы можете поместить время захвата в атрибут content , но тогда это требует дополнительных обработка для извлечения из содержимого ). Если вы используете атрибут creationtime для , то будут изменения во времени в зависимости от того, когда CSE получает примитив. При использовании изменения исчезают, поскольку запрос CREATE включает атрибут dataGenerationTime . Это делает данные более точными.

Во втором случае используется атрибут missingDataDetect . Короче говоря, используя это, наряду с ожидаемым periodInterval , вы можете реализовать функциональность типа «пульс» для вашего датчика. Если датчик не отправляет измерение, указывающее, что дверь закрывается / открывается каждые 30 секунд, может быть отправлено уведомление о том, что датчик неисправен или подделан.

Answer 2

Существует несколько различий между типами ресурсов и .

Ресурс может содержать произвольное количество ресурсов , а также ресурсов и (sub) в качестве дочерних ресурсов. Преимущество этого в том, что может быть дополнительно структурирован для представления более сложных типов данных.

Это также причина, по которой атрибут contentInfo не может быть частью ресурса , поскольку тип содержимого может быть просто смешанным, или ресурс может не иметь прямой ресурсов на всех.

Ресурс может иметь в качестве дочернего ресурса только ресурсы (кроме , , и т. Д.). Предполагается, что все дочерние ресурсы относятся к одному типу, поэтому contentInfo находится в ресурсе .

Ресурсы

могут также иметь атрибут sequenceNr , который позволяет CSE проверять данные на отсутствие или несоответствие последовательности. См., Например, атрибут missingDataDetect в ресурсе .

Для вашего приложения (отправка и хранение данных каждые 30 секунд): зависит от требований. Важно ли, чтобы измерения передавались постоянно или когда важно знать, когда данные отсутствуют? Затем используйте и . Если ваше приложение просто отправляет данные при изменении измерения, и важно только получить последнее значение, используйте и .