Протокол управления датчиками и выключателями

Протокол взаимодействия датчиков и выключателей

Обобщённые характеристики

Уровень соответствующий эталонной Сетевой модели OSI: “Канальный уровень (Data Link layer)”.
Модель взаимодествия: Клиент-серверная (Несколько клиентов ? один сервер).
Изолированность среды: Способность работы в неизолированной среде (когда все устройства на одной шине).
Тип носителя передачи: Кадры (Frames).
Размер кадра: фиксированный.
Возможность фрагментации: нет. (хотя некая возможность фрагментации не исключена – на ДРУГИХ уровнях).
Контроль ошибок: Да (только проверка контрольнай суммы).

Вводное описание

Простой протокол (канального уровня) для управления “Выключателей” и “Датчиков” Управляющим контроллером.
Протокол предполагает нахождение в одной среде: нескольких Клиентских устройств и одного Серверного устройства. Среда сети – не изолированна на Физическом уровне (предполагается что на Физическом уровне: все передачи – широковещательны ).

Клиентские устройства предполагают два типа:
1. Датчики.
2. Выключатели.

[Комментарий/Примечение! Разделение Клиентских устройств на тип-Датчики и тип-Выключатели – считается довольно АБСТРАКТНЫМ (и возможно – избыточным) . Так как на ДАННОМ (Канальном) уровне – поведение Датчиков совпадает с поведением Выключателей. Однако на БОЛЕЕ ВЫСОКОМ уровне – разница в поведении Датчиков и Выключателей заключается в том что Датчик (в отличие от Выключателя) НЕ будет получать от Серверного устройства каких-либо Установочных Сигналов, а будет только сообщать с своём состоянии (разумеется, только при получении от Серверного устройства соответствующего запроса о состоянии). Но в тоже время каждый Выключатель – по своему поведению ВКЛЮЧАЕТ в себя поведенческую модель Датчика (то есть каждый Выключатель является Датчиком, но НЕ каждый Датчик является Выключателем).]

Серверное устройство – в техническом смысле Управляющий контроллер.

Управление – в контексте данного уровня протокола – принятие и передача Сигналов двух типов:
1. Передача Запроса – от Серверного устройства к Клиентскому устройству.
2. Передача Ответа – от Клиентского устройства к Серверному.

Передача сигналов от одного Клиентского устройства к другому Клиентскому устройству – НЕ предусмотрена. То есть всё управление осуществляется в рузультате работы Серверного устройства (или в результате ОТСУТСТВИЯ его работы, если имеет место Аварийная ситуация).

Структура кадра

Каждый отдельный сигнал передаётся в одном Кадре.
Кадр имеет размер 16 бит .



поля Кадра – целые числа. Порядок битов – младшие биты находятся ВНАЧАЛЕ.

Каждому Клиентскому устройству присвоен уникальный 7-битный аддресс (уникальный – внутри сети). Серверное устройство адреса не имеет.

Кадр Запроса и Кадр Ответа – имеют одинаковую структуру.

В Кадре Запроса:
1. Поле “Тип сигнала” – здесь: 0x0.
2. Поле “Адрес” – используется для указания адреса конкретного Клиентского устройства, которому предназначается запрос (остальные Клиентские устройства, должны проигнорировать содержание кадра).
3. Поле “Состояние...” – используется для указания Клиентскому устройству – в какое новое состояние необходимо ему изменить своё состояние. (:-))

Существует также и ПСЕВДОсостояние (так называемое “-1” состояние): 0xF . Указывает на то что менять состояние Клиентского устройства не нужно (нужно только получить).

Существует и ПСЕВДОадрес (так называемый “-1” аддресс): 0x7F . Он указывает на заведомо несуществующий адрес (Ответ с которого и не ожидается) . Это СПЕЦИАЛЬНАЯ зарезервированная-на-будущее опция. Серверное устройство может использовать это для указания своей активности (в этом случае мы имеем дело с ПСЕВДОактивностью).

В Кадре Ответа:
1. Поле “Тип сигнала” – здесь: 0x1.
2. Поле “Адрес” – используется для указания аддреса ОТ какого Клиентского устройства поступает Ответ (это необходимо для исключения случаев когда по какойто причине Ответ от устройства приходит не вовремя: чтобы в этом случае не возникали ситуации с подменами состояний одних устройств другими).
3. Поле “Состояние...” – используется для указания на то – в каком состоянии находится Клиентское устройство (на момент Ответа, а не на момент Запроса).

Поле “Контрольная сумма” (в Запросе и в Ответе) – предполагает несложную функцию проверки целостности Кадра. В качестве кандидата – табличня реализация CRC4.
В случаях несовпадения “Контрольной суммы” (повреждённие Кадра) – Кадр игнорируется без проведения каких-либо дополнительных действий.

Поведение Клиентского устройства.
после каждого отправленного Запроса (Серверным устройством) – предполагается Ответ (Клиентским устройством).

Хотя могут и существовать СПЕЦИАЛЬНЫЕ ситуации , когда Ответ от Клиентского устройства – НЕ ПРЕДПОЛАГАЕТСЯ. Это расчитанно на задействование опеделённых СПЕЦИАЛЬНЫХ зарезервированных-на-будущее возможностей (напрмиер групповое вещание) . Но в обычных слуачях после каждого Запроса предполагается Ответ.

Клиентские устройства должны отвечать (посылать сигналы Ответов) ТОЛЬКО при получении соответствующего запроса. А не просто при изменении своего состояния. И на каждый Запрос – предполагается только один Ответ (точнее будет сказать – не более одного).

Ответы – всегда содержат текущее состояние (текущее – на момент Ответа). Важно не путать Ответ с простым подтверждением Запроса, хотя вероятно, что во многих слуаях они будут совпадать (в случаях когда нет технической возможности проверить Реальное состояние приводимого в действие механизма Клиентским устройством).

Распознавание Аварийной ситуации (и Аварийное поведение Клиентского устройства) – рассмотренно в соответствующей главе.

Поведение Серверного устройства.

Поведение Серверного устройства заключается в поочерёдном отправлении Запросов каждому из Клиентских устройства (а также получении от них Ответов), в соответствии с произведённым анализом состояний всех устройств сети.

Технически – Серверное устройство предполагает Контроллер, с возможностью глубокой настройки параметров и поведения . Напрмер, установка различных предельно-допустимых периодов времени ожидания Ответов от Клиентских устройств , или например такие параметры как изменение порядка и приоритетов опросов Клиентских устройств .

Подробные требования и детали поведения Серверного устройства в этом документе не определены.

Распознавание Аварийной ситуации (и Аварийное поведение Серверного устройства) – рассмотренно в соответствующей главе.

О предполагаемом Физическом уровене (Physical layer)

На физическом уровне Кадр перадётся по принципам Универсальной Асинхронной передачи, с фиксированным временем такта и с синохронизацией по START-биту.
Передача 16-битного Кадра осуществляется в ПРЯМОМ порядке.
Время внешнего такта – настраиваемый параметр
Время внутреннего такта = в 4 раза короче времени внешнего такта (врнутренние такты необходимы для обнаружения середины START-бита ).

Для подробностей информации смотреть: uart – universal asynchronous receiver/transmitter .

Аварийная ситуация (Прикладной или др-высокий уровень)

на более высоком уровне работы системы – предусмотренн Аварийный режим. Это режим, когда Исполнительные устройства (Выключатели) распознают, что они потеряли связь с Серверным устройством (либо серверное устройство “сломалось”) .

В этом случае Выключатель должен переключится в Аварийное состояние. Это состояние задаётся предварительной настройкой, и должно быть наиболее безопасным. Например если Выключатель отвечает за включание нагревания некоего котла, то его Аварийным состоянием – должно быть состояние “выкл”.

Серверное устройство – предполагается, что тоже способно определить отсутствие связи с Выключателем. В этом случае оно должно например отправлять уведомление (sms или другой способ оповещения) Хозяина системы . Либо плюс к тому – будут задействованы другие Выключатели (которые не были распознаны как вовлеченные в Аварийную ситуацию).

Впрочем, высокая сложность Серверного устрйоства (в отличие от примитивной сложности Выключателя) позволит настроить Аварийное состояние Серверного устрйоства необходимым конкретным для системы образом.

С позиции Выключателя – Аварийное состояние может быть распознанно по двум критериям:
1. Отсутствие активности Серверного усройства, в течении промежутка времени 1 секунда. Здесь имеется ввиду любая активность Серверного усройства (и даже псевдоактивность), а не только передача адресовваных Запросов данному Выключателю .
2. Отсутствует передача адресованых Запросов для данного Выключателя в течении промежутка времени 30 секунд или 60 секунд . данные симптомы с наибольшей вероятностью будут свидетельствовать о неправильной настройке системы, чем об аварии, однако не исключён и аварийный характер ситуации.

С позиции Серверного устройства – Аварийное состояние некоторого Выключателя распознаётся при отсутствии Ответа, либо Ответа с состоянием не соответствующего нужному, в течении некоторого времени ... . Параметры распознавания и соответствующие поведение – задаются конкретной конфигарацией Серверного устройства.

Так, как Серверное устройство является более сложным – с его позиции Аварийное состояние может и не означать обязательно именно отсутствие связи между ним и неким Выключателем. Это может быть и просто некоторый анализ различных Датчиков (например Ответ с датчиков сигнализации). Чёткий критерий, когда ситуацию можно рассматривать как Аварийную (с присвоением аварии определённого уровня тревоги) – зависит от конкретной системы, где работает сеть.
Примитивные же Выключатели – распознают ситуацию, как Аварийную – строго при распознавании отсутсвия связи с Серверным устрйоством (в соответствии с описанными для него двумя критериями) .