1 РАЗРАБОТАН Обществом с ограниченной ответственностью "МИРТЕК" (ООО "МИРТЕК")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 "Кибер-физические системы"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 ноября 2024 г. N 95-пнст

При современном уровне развития электроники существует множество различных бытовых и промышленных устройств, при этом Интернет стал распространенным способом связи между оборудованием, коммуникаторами и информационными системами. Для эффективной работы разнообразные типы оборудования объединяются в сети для организации комплексных систем доступа, удаленного контроля, мониторинга и управления. Однако, для подключения всего спектра устройств к сети Интернет необходимо ресурсоемкое и производительное оборудование.

Настоящий стандарт устанавливает требования к протоколу передачи данных для информационного обмена между компонентами системы комплексного учета энергоресурсов МИРТ для организации связи с малопроизводительными устройствами (далее - протокол МИРТ). Протокол МИРТ может быть применен в интеллектуальных счетчиках воды, газа, тепла и электроэнергии как для прямого, так и для сетевого доступа к счетчикам. Гибкость протокола МИРТ позволяет применять его в системе обмена данными для любых устройств. Протокол МИРТ не предъявляет требований к физическому каналу связи и может работать в любых средах передачи данных.

Простота реализации протокола МИРТ позволяет использовать его в счетчиках газа, воды, тепла, в любых датчиках и в управляющих устройствах. При этом обеспечивается возможность передачи данных между устройствами разного типа. Использование протокола МИРТ по радиоканалу открывает широкие возможности для применения в частном секторе, где будет обеспечиваться связь с устройствами на дальности, в пятнадцать раз превышающей дальность прямой радиосвязи.

Протокол МИРТ может быть использован для транспорта до целевого устройства в сети других протоколов, не имеющих собственных маршрутов.

Настоящий стандарт устанавливает требования к структуре, формату и правилам использования протоколу передачи данных для информационного обмена между компонентами системы комплексного учета энергоресурсов МИРТ (далее - протокол МИРТ). Протокол МИРТ подходит для использования как в устройствах с батарейным питанием и малым объемом передаваемой информации, так и для высокофункциональных устройств со скоростными каналами и большими объемами передаваемых данных. При подключении к серверу сбора множества сетей с топологией типа "дерево" сбор данных может осуществляться с миллионов устройств.

Протокол МИРТ не предназначен для использования в системах хранения и/или передачи информации, содержащих сведения, составляющие государственную тайну.

Протокол МИРТ предоставляет возможности по конфигурированию, управлению и получению данных с устройств как в режиме точка-точка, так и для доступа к данным устройств в организованной сети. Устройство может выступать в качестве оконечного устройства, ретранслятора или координатора сети. Сеть из множества различных устройств имеет топологию дерева, где пакеты данных передаются от координатора сети к оконечным устройствам через ретрансляторы. Это позволяет использовать протокол для систем комплексного учета энергоресурсов, где счетчики воды, газа, тепла, электроэнергии и различные датчики образуют единую сеть.

Протокол МИРТ не накладывает ограничений на скорость передачи данных или время связи.

Протокол МИРТ предоставляет возможность работать не только по принципу запрос-ответ, но также обеспечивает инициативную передачу данных, что является актуальным для устройств с батарейным питанием.

Настоящий стандарт не устанавливает требований к шифрованию прикладных данных и к средствам криптографической защиты информации. Для шифрования прикладных данных требуется использование внешних программно-аппаратных средств криптографической защиты информации.

Выбор конкретных алгоритмов шифрования прикладных данных определяет разработчик оконечного устройства в зависимости от целевого назначения оконечного устройства и действующих нормативных документов. Например, для систем класса критической информационной инфраструктуры (КИИ) могут использоваться криптографические преобразования. Используемые в оконечном устройстве алгоритмы шифрования данных должны быть указаны в эксплуатационной документации на соответствующее оконечное устройство. Рекомендуется использовать алгоритм блочного шифрования. Описание и выбор конкретных алгоритмов шифрования данных выходит за рамки настоящего стандарта.

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

ГОСТ Р МЭК 60870-5-104 Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 104. Доступ к сети для ГОСТ Р МЭК 870-5-101 с использованием стандартных транспортных профилей

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 протокол передачи данных: Формализованный набор требований к структуре пакетов данных и алгоритму обмена пакетами данных между оконечными устройствами и компонентами системы учета.

3.2 устройство (связи): Устройство, выполняющее ввод и вывод сигналов в виде пакетов данных, несущих сообщения.

Примечание - Устройство связи может быть частью оконечного устройства или обособленным модулем.

3.3 оконечное устройство: Оборудование с устройством связи, получающее запросы и направляющее ответы, предназначенное для присоединения к системе учета.

Примечания

1 Оконечное устройство может иметь несколько устройств связи различных типов, при этом каждое устройство связи может иметь сетевой адрес.

2 Примеры оконечных устройств - прибор учета ресурса, датчик величины, обособленный ретранслятор.

3.4 ретранслятор: Узел сети, который транслирует пакеты других узлов сети.

3.5 ретрансляция: Действия устройства связи по приему битового потока от предыдущего устройства связи и помещению его в физическую среду для передачи следующему устройству связи.

Примечания

1 Устройство связи с функцией ретрансляции (ретранслятор) копирует битовый поток в свой буфер и модифицирует биты, указывающие путь к следующим устройствам связи.

2 Функцию ретрансляции может выполнять определенная группа оконечных устройств и/или обособленные ретрансляторы.

3.6 координатор: Узел сети, через который направляются запросы, имеющий одинаковый физический канал связи с оконечным устройством или ретранслятором.

3.7 запрос: Пакет с данными, передаваемый от координатора к устройству.

3.8 ответ: Пакет с данными, передаваемый от устройства к координатору.

3.9 байт-стаффинг: Механизм замены одного байта данных в пакете на последовательность из двух байт, предотвращающий появление внутри пакета стартовой и стоповой последовательности.

3.10 путь: Совокупность адресов, состоящая из полей "Путь", "Адрес назначения" и "Адрес источника" и описывающая полный маршрут движения пакета.

3.11 текущий адрес: Адрес устройства, которому адресован пакет.

3.12 пакет: Протокольный блок данных, передаваемый по каналу связи.

Примечание - Каждый пакет содержит в дополнение к фактическому сообщению информацию об отправителе, получателе, для контроля ошибок и другие данные.

3.13 сообщение: Данные, имеющие смысловое содержание и пригодные для обработки и/или использования в системе учета.

3.14 команда: Сообщение, вызывающее определенное действие оконечного устройства.

Примечание - Каждую команду представляют кодом команды, выбираемым из заданного набора.

В настоящем стандарте применены следующие сокращения:

ВПУ - высоковольтный прибор учета;

ГВС - горячее водоснабжение;

ДСТП - дистанционное снятие показаний, кнопка счетчика, может использоваться для снятия дополнительной защиты;

ЖКИ - жидкокристаллический индикатор (дисплей);

ИСУЭ - интеллектуальная система учета электроэнергии;

МЭК 104 - протокол передачи данных в сетях телеметрии и телемеханики, соответствующий требованиям ГОСТ Р МЭК 60870-5-104, применяется в системах контроля и управления территориально распределенных систем;

ОУ - отсчетное устройство;

ПО - программное обеспечение;

РИП - резервный источник питания;

ТПП - разработчик радиомодулей ООО "ТПП Инжиниринг";

УСПД - устройство сбора и передачи данных;

ASCII - таблица, в которой некоторым распространенным печатным и непечатным символам сопоставлены числовые коды (american standard code for information interchange);

DLMS - стек-ориентированный протокол, базирующийся на концепциях модели OSI, регламентирующий обмен данными между приборами учета и системами сбора (device language message specification);

HDLC - высокоуровневый протокол управления каналом передачи данных (high-level data link control);

LoRaWan - проприетарная технология модуляции маломощной сети передачи данных со скоростью 0,3 - 50 кб/с и дальностью от 1 до 15 км в нелицензируемом диапазоне частот (Long Range);

PLC - группа технологий передачи данных по силовым линиям (Power line communication);

RF-433 - радиоинтерфейс 433 МГц;

UART - универсальный асинхронный приемопередатчик (universal asynchronous receiver/transmitter).

Все пакеты, передаваемые по протоколу МИРТ, должны иметь определенный формат (см. рисунки 1, 2). Два стартовых байта позволяют определить начало пакета, стоповый байт позволяет определить конец пакета с использованием байт-стаффинга.

Пакеты имеют короткий (см. рисунок 1) и длинный формат (см. рисунок 2). Короткий формат использует для проверки целостности CRC8, длинный формат - CRC16.

Стартовая последовательность, равная 0x73 0x55, а также стоповый байт, равный 0x55, не могут находиться внутри пакета.

Используемый тип и метод шифрования определяется на этапе согласования требований к системе учета, описывается в требованиях к системе учета и выходит за рамки настоящего стандарта.

Содержимое поля "Параметры" определяет:

- запрос это или ответ;

- в прямом или в зашифрованном виде передаются данные;

- длину данных.

Бит "D" поля "Параметры", равный 1, указывает на запрос к устройству, а равный 0 - на ответ устройства.

Бит "C" поля "Параметры", равный 1, указывает, что прикладные данные зашифрованы.

Биты "L0-L4" поля "Параметры" содержат длину поля данных для короткого формата пакета, "L0-L12" - для длинного формата.

Бит "V" поля "Параметры", равный 0, указывает на короткий формат данных. Короткий формат подходит для устройств со слабыми вычислительными мощностями, в коротком формате поле данных не может быть более 31 байта. Применяемая контрольная сумма - CRC8.

Бит "V" поля "Параметры", равный 1, указывает на длинный формат данных. Длинный формат подходит для устройств с высокими вычислительными мощностями. Поле данных может иметь длину до 8191 байт. Применяемая контрольная сумма - CRC16.

Поле "Ретрансляция" состоит из двух полей по 4 бита, в которых указывается общее количество ретрансляций пакета (R3...R0) до конечного устройства и оставшееся количество ретрансляций (C3...C0). Количество возможных ретрансляций ограничено пятнадцатью.

Поле "Путь" содержит адреса всех ретрансляторов, расположенных между координатором и оконечным устройством. Данное поле имеет нулевую длину, т.е. отсутствует, в случае, когда обмен с устройством ведется напрямую без ретрансляторов. В таком случае поле "Ретрансляция" будет иметь значение 0 и адрес будет совпадать с полем "Адрес назначения".

Поля "Адрес назначения" (2 байта) и "Адрес источника" (2 байта) содержат адреса оконечного устройства и координатора соответственно. Порядок использования адресации определен в разделе 9. Каждая подсеть, образованная одним координатором, имеет ограничение адресации до 65 000 узлов. Ограничение на количество узлов в системе учета в целом отсутствует.

Поле "Команда" (1 байт) в запросе служит для идентификации выполняемых устройством действий и определяет формат структуры в поле "Данные". Команда может принимать 256 вариантов для запроса и 256 вариантов для ответа. Количество команд в будущем может быть расширено за счет использования номера параметра в качестве команды.

Поле "Пароль" (4 байта) используется только для запроса и является числом в диапазоне от 0 до 4 294 967 295. Порядок использования пароля в устройствах определен в разделе 8.

Поле "Статус ответа" (4 байта) используется в ответе вместо поля "Пароль" и включает поля "Роль устройства", "Флаги тревожных событий", "Код ошибки".

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

Стартовая последовательность имеет значение 0x73 0x55, стоповый байт - 0x55. Данные между стартовой последовательностью и стоповым байтом подлежат байт-стаффингу для исключения появления указанных последовательностей внутри данных и, как следствие, исключения ложных срабатываний.

При отправке пакета в канал связи все байты после стартовой последовательности до стопового байта должны подвергаться механизму байт-стаффинга. Если байт имеет значение 0x55, то он должен быть заменен на последовательность 0x73 0x11. Если байт имеет значение 0x73, то он должен быть заменен на 0x73 0x22.

В случае приема пакета производится обратный байт-стаффинг. После обнаружения стартовой последовательности и до обнаружения стопового байта последовательности 0x73 0x11 и 0x73 0x22 должны быть заменены на 0x55 и 0x73 соответственно.

Контрольная сумма CRC8 занимает один байт. Вычисления производятся на основе полинома 0xA9, стартовое значение = 0x00.

Пример расчета CRC8 на языке Си приведен далее. pData - указатель на байтовый массив, для которого надо рассчитать CRC8. Len - длина массива в байтах.

Контрольная сумма CRC16 занимает два байта. Вычисления производятся на основе полинома 0x1021, стартовое значение = 0xFFFF.

Пример расчета CRC16 на языке Си приведен далее. bAddr - указатель на байтовый массив, для которого надо рассчитать CRC16. wLen - длина массива в байтах.

Поле "Пароль" имеет длину 4 байта в запросе. В ответе данное поле не используется. Использование паролей предназначено для разделения целевых ролей и уровней доступа пользователями системы даже в случае отсутствия шифрования. В случае необходимости защиты передаваемых данных, должно использоваться шифрование прикладных данных, включая поле "Пароль" с помощью дополнительных программно-аппаратных средств. В устройстве допускается использовать любое количество паролей для разных уровней доступа.

Защиту от атак, связанных с подбором пароля, рекомендуется реализовывать в устройстве путем ограничения количества попыток подключения к устройству с неверным паролем. При определенном количестве обращений к устройству с неверным паролем, устройство может быть блокировано на заданный период времени. Рекомендуется блокировать интерфейс от попыток записи до конца текущих суток. Для более гибкого использования защиты рекомендуется делать в устройстве время блокирования настраиваемым. При каждой попытке доступа к устройству с неверным паролем устройство отвечает кодом ошибки 0x01 - "Попытка доступа с неверным паролем", а после превышения разрешенного количества попыток устройство должно отвечать ошибкой 0x05 - "Интерфейс заблокирован (до выполнения условий разблокировки)" в соответствии с разделом 13 настоящего стандарта. При этом полной блокировки интерфейса связи не происходит, устройством выполняются команды чтения, для которых защита паролем не предусмотрена.

Способ реализации защиты от атак, связанных с подбором пароля, должен быть описан в эксплуатационной документации производителя.

Для устройств можно реализовывать доступ по паролю на чтение и запись или доступ по паролю только для команд записи. В описании структуры данных команд (см. приложения А, Б, В) команды, которые выполняются только с паролем, имеют отметку "Защита паролем".

Для использования в пароле цифр, букв и символов возможно использовать хэш такого пароля длиной в 4 байта.

Для устройств рекомендуется использовать не менее двух паролей. При производстве рекомендуется устанавливать первый пароль равным нулю, а второй пароль - равным 1 934 979 925. Сброс паролей устройства должен быть защищен физическим способом. К примеру, для устройств с использованием электронных пломб, для сброса пароля необходимо выполнить обязательное распломбирование устройства. Для устройств, к которым доступ ограничивается физически (в закрытых и пломбируемых помещениях) возможна реализация сброса пломб по команде через интерфейс при нажатии на кнопку на устройстве.

Адрес устройств состоит из двух байтов, т.е. используется диапазон адресов от 0 до 65 535 для одной подсети. Количество подсетей при этом не ограничено. Адрес 0 рекомендуется использовать в процессе производства устройств. Адрес 65 535 необходимо использовать как широковещательный.

Широковещательный запрос должны выполнять все устройства, но ответ на широковещательный запрос не должен формироваться. Допускается исключение, когда ответ может быть сформирован и выдается в канал связи в случайное время в течение некоего периода после приема запроса. Рекомендуется отправлять такой ответ не ранее чем через 4 с и не позднее 255 с после получения широковещательного запроса.

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

Распределение адресного пространства:

- адреса в диапазоне от 1 до 65000 рекомендуется использовать для серийных устройств;

- адреса от 65001 до 65535 рекомендуется использовать под системные нужды.

Зарезервированные адреса:

- 65535 - конфигуратор;

- 65534 - ПО сбора данных;

- 65520 - УСПД;

- 65281 - координаторы сети RF433;

- (65282 - 65287) - зарезервированы для других координаторов сети;

- 65001 - зарезервирован за внутренним маршрутизатором. По этому адресу можно обращаться к устройствам внутри устройств. Обращаясь по этому адресу внутри устройства, можно запрашивать наличие внутренних логических устройств или отдельно конфигурируемых модулей;

- 65301 - зарезервирован для всех типов встроенных GSM-модулей как Единый адрес.

Для каждого из типов GSM-модулей можно использовать собственный адрес в соответствии с типом модуля (Типовой адрес):

- 65293 - для GPRS-модуля;

- 65294 - для 3G-модуля;

- 65295 - для 4G/LTE-модуля;

- 65296 - для 5G-модуля;

- 65297 - для GPRS/NB-IoT-модуля;

- 65298 - для LTE Cat M1 (eMTS)-модуля;

- 65299 - для LTE Cat NB (NB-IoT);

- 65290 - для Wi-Fi модулей;

- 65291 - для Ethernet модулей.

Все оставшиеся свободные адреса зарезервированы для перспективных требований.

С помощью механизма ретрансляции выполняется передача пакета в тот или иной канал связи в случае, когда устройство не является оконечным устройством. При этом устройство следит за текущим адресом и полем "Ретрансляция". Если текущий адрес принадлежит устройству, а младшие 4 бита поля "Ретрансляция" не равны нулю, то пакет необходимо ретранслировать. Алгоритм ретрансляции не зависит от направления движения пакета (в сторону оконечного устройства или от него). Операция перестановки адресов одинакова, см. рисунок 3.

Для ретрансляции устройство должно выполнить следующие действия:

- сдвинуть влево циклически на 1 адрес (2 байта) весь путь (см. рисунок 3);

- уменьшить на 1 количество оставшихся ретрансляторов в поле "Ретрансляция";

- рассчитать новую контрольную сумму пакета;

- передать пакет в канал связи.

Движение пакета от одного устройства к другому происходит из-за того, что каждое устройство реагирует на него только тогда, когда его адрес совпадает с текущим адресом в пакете. При неверном построении пути пакет будет утерян. Потеря пакета обязательно произойдет при указании последовательно двух одинаковых адресов. При наличии двух устройств с одинаковыми адресами на одном канале связи одновременный ответ двух устройств исказит данные, контрольная сумма подтвердит разрушение пакета, и пакет будет далее проигнорирован всеми последующими устройствами. При правильном построении пакета он будет двигаться к цели и обратно, даже если ретрансляция не нужна, например когда устройства находятся на одном проводном канале.

Маршрут ретрансляции может задаваться статически при конфигурировании системы или формироваться динамически. Алгоритм динамического формирования маршрута определяется конкретной реализацией протокола, зависит от используемой среды передачи данных и выходит за рамки настоящего стандарта.

В таблице 1 показан набор пакетов при подаче команды PING на устройство с номером 8 последовательно через ретрансляторы 1 - 2 - 3 - 4.

Когда текущий адрес принадлежит устройству, и младшие 4 бита поля "Ретрансляция" равны нулю, то для устройства это является признаком того, что пакет нужно отдать на обработку и сформировать ответ.

Для формирования ответа устройство должно выполнить следующие действия:

- пул адресов необходимо развернуть, записав его в обратном порядке, как показано на рисунке 4;

- поле "Пароль" заменить полем "Статус ответа";

- в поле "Ретрансляция" оставшееся количество ретрансляций нужно сделать равным общему количеству ретрансляций;

- установить бит "D"=0, что означает "ответ";

- поле данных заполнить данными, предназначенными для ответа на запрос;

- указать в заголовке длину поля данных;

- рассчитать новую контрольную сумму пакета;

- передать пакет в канал связи.

Структура поля "Статус ответа" приведена в таблице 2.

Для формирования поля "Статус ответа" необходимо заполнить поля: "Роль устройства" согласно таблице 3, "Флаги тревожных событий" согласно разделу 12 и поле "Код ошибки" согласно разделу 13.

Все не описанные в таблице роли устройств зарезервированы для дальнейшего развития.

Флаги тревожных событий находятся в поле "Статус ответа". Это позволяет донести информацию от устройства к координатору через любой пакет ответа независимо от команды запроса.

Установка статусного бита в единицу означает:

JL - есть изменения в журнале событий;

P1 - вскрытие пломбы крышки клеммной колодки;

P2 - вскрытие пломбы крышки корпуса;

P3 - вскрытие дополнительной пломбы;

M1 - воздействие постоянного магнитного поля;

M2 - воздействие переменного магнитного поля;

SY - в текущих сутках синхронизация времени была произведена;

W - достигнут критический уровень (по какому параметру - выбирает разработчик);

J - вскрыта защита заводских настроек;

R0 - реле ограничения потребителя присутствует;

R1 - ограничение потребителя можно отменить удаленно;

R2 - включено ограничение потребителя (потребитель не получает ресурс);

IN - импульсный вход учета отсутствует;

ND - возникновение аварийной ситуации;

AR - включена авторегистрация устройства в системе учета;

N - присутствует небаланс токов.

Когда устройство готовит ответ, оно должно анализировать правильность оформления запроса, чтобы определить, знает ли устройство такую команду, понимает ли структуру присылаемых данных и имеет ли право на ответ. В связи с производимым анализом, в ответном пакете всегда должен присутствовать код ошибки. Если код ошибки равен нулю, это означает, что ошибок нет, пакет запроса успешно распознан, ответ составлен и передан в канал связи. В случае возникновения ошибки, код ошибки содержит описание проблемы, а длина данных ответа должна быть равной нулю.

0x00 - команда выполнена успешно (нет ошибок);

0x01 - попытка доступа с неверным паролем;

0x02 - передан недопустимый параметр;

0x03 - попытка изменения заводского параметра;

0x04 - неверная длина данных (поле данных имеет неизвестную структуру);

0x05 - интерфейс заблокирован (до выполнения условий разблокировки);

0x06 - запрашиваемых данных нет (к примеру, на определенную дату);

0x07 - попытка чтения с неверным паролем;

0x08 - невозможно выполнить команду;

0x09 - невозможно выполнить команду в данный момент;

0x0A - действие уже выполнено;

0x85 - интерфейс только что заблокирован из-за окончания попыток доступа.

Так как любой запрос содержит код команды, то ответ содержит тот же код команды. Таким образом, на один код команды существуют две структуры с данными: структура данных запроса и структура данных ответа, которые понимает устройство. Если устройство не понимает структуру данных (по длине или внутренним параметрам), то оно отвечает кодом ошибки. Система опроса, в таком случае, имеет возможность послать запрос повторно, в другом формате (с другой структурой данных).

Коды команд с описанием структур запросов и ответов для устройств "счетчики воды/газа" приведены в приложении А.

Коды команд с описанием структур запросов и ответов для устройств "счетчики тепла" приведены в приложении Б.

Коды команд с описанием структур запросов и ответов для устройств "счетчики электрической энергии" приведены в приложении В.

Пространство имен/значений, не задействованных в протоколе, является резервным и предназначено для реализации перспективных требований и разработок.

В случае необходимости инициативной передачи данных устройство формирует пакет по тем же правилам, по которым формируется ответ на запрос, и передает пакет в канал связи. Устройства могут самостоятельно формировать не только пакеты с данными, но и пакеты с аварийными событиями. В таком случае устройство должно сформировать пакет ответа, который должен содержать аварийное событие в виде ответа на команду чтения журнальной записи.

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

Формат пакета с данными должен выглядеть как ответ на запрос команды 0x07. В статусном поле должна содержаться информация в соответствии с таблицей 4.

Формат поля данных ответа при этом должен состоять из 31 байта и иметь следующую структуру:

1 байт - тип данных:

1 байт - ASCII символ "D";

11 байт - заводской номер устройства в формате ASCII;

1 байт - ASCII символ "C";

9 байт - показания в формате ASCII, в качестве десятичного разделителя необходимо использовать ASCII код "." (точка);

1 байт - ASCII символ "V";

4 байта - напряжение батарейки в формате ASCII, в качестве десятичного разделителя необходимо использовать ASCII код "." (точка);

1 байт - ASCII символ "S";

3 байта - номер последовательности в формате ASCII (сквозной номер нумерации пакетов, который должен увеличиваться после каждой посылки пакета в канал связи).

Для устройств с батарейным питанием (такие как счетчики воды, газа, различные датчики) возможна организация режима передачи данных в соответствии с графиком. График настраивается командами 0x70 WriteInitiativeParameters и 0x71 ReadInitiativeParameters.

При этом для сбора данных возможно использовать устройства с питанием от электрической сети. Такие устройства должны находиться в постоянном режиме ожидания данных и служат накопителями поступающих данных.

Для инициативной передачи данных необходимо реализовать четыре режима работы, которые могут функционировать как отдельно, так и совместно со всеми остальными режимами и выбираться в соответствии с конфигурацией устройства.

Режимы:

1) единовременный

В этом режиме настраивается время передачи данных (чч <1>:мм <1> - 2 байта) и список данных для передачи (list <1> - 20 байт).

Передача данных, производится 1 раз в сутки, в указанное время. Пакеты с данными направляются последовательно, согласно настроенному списку;

2) периодический

В этом режиме настраивается время начала передачи данных (чч:мм - 2 байта), время окончания передачи данных (чч:мм - 2 байта), период передачи данных (min <1> - 2 байта), список данных для передачи (list - 20 байт).

Передача данных, производится в течение указанного диапазона времени. После каждой отправки данных, следующая передача производится через заданное количество минут. По истечении времени ожидания необходимо снова выйти на связь и передать все данные по списку. Пакеты с данными направляются последовательно, согласно настроенному списку;

3) по готовности данных

В этом режиме настраивается только список данных для передачи (list - 20 байт). Передача данных производится сразу по наступлению события, согласно настроенному списку;

4) график активности

В этом режиме настраивается график активности канала связи. Достаточным является график с дискретностью 10 минут (time <1> 18 байт).

--------------------------------

<1> чч - часы (0..23);

мм - минуты (0..99);

list - побитовый список из 20 байт для настроек 160 параметров согласно таблице 5;

min - количество минут (1..1440);

time - побитовый график из 18 байт с 10 дискретностью (0-й бит - время от 00:00 до 00:10).

Устройство должно включать/отключать модуль связи согласно суточному графику с 10-минутной дискретностью. Имеет приоритет перед другими режимами. Данные должны передаваться согласно настройкам первых трех режимов.

В устройстве могут находиться другие устройства, требующие отдельной настройки (GSM-модемы, модули PLC или радиосвязи и пр.). К устройствам внутри устройств можно обращаться через зарезервированный адрес 65001. При таком подключении запросы и ответы должны ретранслироваться внутри устройства в канал связи с модулем.

Работа с такими устройствами разделена на три этапа:

- запрос у устройства с адресом 65001 через адрес устройства (как через ретранслятор) количества устройств внутри устройства;

- получение информации об этих устройствах;

- работа с устройствами по их набору команд.

Устройств внутри устройства может быть не более 255. Каждое устройство в зависимости от специфики его применения может иметь собственный набор команд и свои устройства внутри.

Вычитывание данных производится зарезервированной командой 0xFC, которая позволяет узнать полное количество устройств внутри устройства и получить развернутую информацию об устройствах. Доступ к этим устройствам необходимо производить по их сетевым адресам через адрес устройства (как ретранслятор).