Управление приводом в oneM2M - PullRequest
Новая
       42

Управление приводом в oneM2M

2 голосов
/ 25 марта 2019

Я прочитал документацию по двусторонней связи в OneM2M.Я понимаю, что одним из способов сделать это является использование системы подписки и уведомлений.Предположим, у нас есть пример, подобный приведенному ниже.IN-AE (смартфон) хочет открыть свет ADN-AE2.Предположим, что регистрация и создание ресурса уже выполнены, а также ADN-AE-2 уже подписан на контейнер источника света в ADN-AE-2.

В результате oneM2M покрывает часть того, как IN-AE отправляет запрос управления освещением и то, как ADN-AE-2 или ADN-AE-1 приняли запрос, поступивший из IN-AE, и выполнили его.Но что делать, если ADN-AE-2 не может управлять светом и перестать работать при его управлении?Какой должен быть сценарий?Contentinstance уже создан с запросом, посланным IN-AE.

1- Если ADN-AE-2 создаст другой экземпляр содержимого, который является предыдущим состоянием контейнера

2- Если ADN-AE-2 удалит экземпляр содержимого, который не был выполнен (тогда как насчет другихподписчики, которые получают уведомление и успешно его исполняют)

Каким должен быть рекомендуемый способ, если привод не может выполнить действие?

enter image description here

http://www.onem2m.org/tr-0034/procedures/actuator-switch-control

1 Ответ

2 голосов
/ 26 марта 2019

Это общая проблема в асинхронной связи.Что происходит, когда получатель никогда не получает команду или просто не может ее выполнить (по каким-либо причинам, например, он занят выполнением других действий или запрос находится за пределами определенных параметров)?

Оба ваших варианта действительны, но не будут работать, когда ADN находится в автономном режиме, поэтому ADN-AE2 не может выполнить процедуры.Кроме того, даже когда ADN всегда подключен к сети, у обеих процедур возникают проблемы, когда существует несколько других AE, которые хотят управлять ADN-AE2, или когда IN-AE нетерпеливо устанавливает желаемое состояние снова и снова.Это часто может привести к условиям гонки.

Я бы предложил переосмыслить схему связи между двумя АЕ и разделить оригинальный Контейнер на два: один Контейнер для состояния target идругой контейнер для состояния status .Контейнер target используется AE, кроме ADN-AE2, для установки желаемого состояния.ADN-AE2 уведомляется о создании нового ContentInstance и действует соответственно.Затем он создает новый ContentInstance в контейнере state , который отражает новое внутреннее состояние, и это уведомляет IN-AE об отражении изменения.

Следующий рисунок отражает примерную структуру ресурсадля этого шаблона: 

AE ─┬─ Container_target ─── ContentInstances*   ◀═══ Container for desired state, set by other AEs
    │                                      
    └─ Container_state ─── ContentInstances*    ◀═══ Container for actual state, set only by this AE

Это общий шаблон в асинхронной связи, когда связь между узлами не всегда надежна или когда результат запроса изменения состояния не всегда гарантируется.Ответственность за выполнение запросов лежит на ADN-AE2, а политика в отношении того, как часто повторяться или реагировать на ошибки, лежит на IN-AE.

...