Я уже обсуждал, как управлять устройствами в OneM2M на в этой теме , но заметил, что у меня все еще есть некоторое недопонимание.
Отношение между MgmtObj и MgmtCmd . Какова точная корреляция между ними? Похоже, что MgmtObj сохраняет состояние, такое как текущее программное обеспечение или встроенное ПО в нем, батарея, информация об устройстве и т. Д. ObjectIds и ObjectPaths используются для отображения этой информации в стандарт управления устройствами, такой как LWM2M, TR-0069. Это правильно?
Я не понимаю, почему Узел имеет несколько объектов перезагрузки
в этом?
Предположим, у нас есть несколько разных прошивок на узле. Каждая прошивка контролирует разные части оборудования.
Тогда я думаю, что я должен создать MgmtCmd для каждой прошивки, но как MgmtCmd знает
с какой прошивкой (MgmtObj) связано? Между ними нет никакой связи, когда мы смотрим на определение ресурса в OneM2M. На самом деле это указывает на мой первый вопрос о том, каковы отношения между MgmtObj и MgmtCmd, потому что каким-то образом, когда MgmtCmd запускается и завершает свою работу, соответствующая прошивка должна обновляться в соответствующем узле.
Предположим, что я не собираюсь внедрять какие-либо стандарты управления устройствами, такие как TR-0069, LWM2M и т. Д. Мы используем устройства неOneM2M, у которых есть собственный запатентованный способ управления устройствами. Тогда какой самый простой способ сделать это?
Что мы думали, так это то, что мы должны поместить некоторую логику управления устройствами в IPE (межпрокси-объект), который может подписываться на все события, которые происходят в любом связанном MgmtCmds для устройств, таких как обновление его состояния ExecEnabled и создание ExecInstance. Затем мы должны уведомить IPE с этим ExecInstance, тогда IPE управляет всей процедурой. Целесообразно ли использовать механизм подписки / уведомления для управления устройством?
Ресурс mgmtCmd представляет метод для выполнения управления
процедуры или для моделирования команд и удаленных вызовов процедур (RPC)
требуется существующими протоколами управления (например, BBF TR-069 [i.4]),
и позволяет AE запрашивать выполнение процедур управления на
удаленная сущность. Это также позволяет отменить отмену и
инициированные, но незавершенные процедуры или команды управления.
Ресурс mgmtObj содержит данные управления, которые позволяют
отдельные функции управления M2M. Это обеспечивает общую структуру
сопоставить с технологией внешнего управления, например, OMA DM [i.5], BBF TR-069
[i.4] и LWM2M [i.6] модели данных. Каждый экземпляр mgmtObj
ресурс должен быть привязан к единой технологии внешнего управления.
-------------------------------- РАЗЪЯСНЕНИЕ ----------- ---------------------
Когда мы смотрим на xsd узла, он содержит дочерние ресурсы, такие как
- Список прошивок
- Список программ
- Список перезагрузок
- и т.д ...
На самом деле я только что привел пример, это не сценарий реального мира. Также я пытаюсь понять, почему узел имеет несколько таких ресурсов, как перезагрузка, программное обеспечение, даже если deviceinfo кажется странной. На что они ссылаются?
<xs:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.onem2m.org/xml/protocols"
xmlns:m2m="http://www.onem2m.org/xml/protocols" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
elementFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="CDT-commonTypes-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-memory-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-battery-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-areaNwkInfo-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-areaNwkDeviceInfo-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-firmware-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-software-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-deviceInfo-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-deviceCapability-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-reboot-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-eventLog-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-cmdhPolicy-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-activeCmdhPolicy-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-subscription-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-semanticDescriptor-v3_9_0.xsd" />
<xs:include schemaLocation="CDT-transaction-v3_9_0.xsd"/>
<xs:include schemaLocation="CDT-schedule-v3_9_0.xsd"/>
<xs:element name="node" substitutionGroup="m2m:sg_announceableResource">
<xs:complexType>
<xs:complexContent>
<!-- Inherit common attributes for announceable Resources -->
<xs:extension base="m2m:announceableResource">
<!-- Resource Specific Attributes -->
<xs:sequence>
<xs:element name="nodeID" type="m2m:nodeID" />
<xs:element name="hostedCSELink" type="m2m:ID" minOccurs="0" />
<xs:element name="hostedAELinks" type="m2m:listOfM2MID" minOccurs="0" />
<xs:element name="hostedServiceLinks" type="m2m:listOfM2MID" minOccurs="0" />
<xs:element name="mgmtClientAddress" type="xs:string" minOccurs="0" />
<xs:element name="roamingStatus" type="xs:boolean" minOccurs="0" />
<xs:element name="networkID" type="xs:string" minOccurs="0" />
<!-- Child Resources -->
<xs:choice minOccurs="0" maxOccurs="1">
<xs:element name="childResource" type="m2m:childResourceRef" minOccurs="1" maxOccurs="unbounded" />
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element ref="m2m:memory" />
<xs:element ref="m2m:battery" />
<xs:element ref="m2m:areaNwkInfo" />
<xs:element ref="m2m:areaNwkDeviceInfo" />
<xs:element ref="m2m:firmware" />
<xs:element ref="m2m:software" />
<xs:element ref="m2m:deviceInfo" />
<xs:element ref="m2m:deviceCapability" />
<xs:element ref="m2m:reboot" />
<xs:element ref="m2m:eventLog" />
<xs:element ref="m2m:cmdhPolicy" />
<xs:element ref="m2m:activeCmdhPolicy" />
<xs:element ref="m2m:subscription" />
<xs:element ref="m2m:semanticDescriptor" />
<xs:element ref="m2m:transaction" />
<xs:element ref="m2m:schedule" />
</xs:choice>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
----------------------- БОЛЬШЕ УТОЧНЕНИЯ ------------------- ----------
Кстати, уже есть обсуждение deviceinfo. Тогда я думаю, что они выбрали способ множественного deviceInfo на узел, потому что текущая версия OneM2M поддерживает несколько deviceInfo на узел. Мне также интересно узнать, что означает множественная перезагрузка или прошивка для узла?
