ПНСТ 976-2024 Информационные технологии. Интернет вещей. Протокол передачи данных для информационного обмена между компонентами системы комплексного учета энергоресурсов МИРТ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

пнет

976-2024

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол передачи данных для информационного обмена между компонентами системы комплексного учета энергоресурсов МИРТ

Издание официальное

Москва Российский институт стандартизации 2024

ПНСТ 976—2024

Предисловие

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

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

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16—2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 115324 Москва, Овчинниковская наб., д. 20, стр. 2, e-mail: info@tc194.ru и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «Институт стандартизации», 2024

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

II

ПНСТ 976—2024

Содержание

1 Область применения..................................................................1

2 Нормативные ссылки..................................................................2

3 Термины и определения...............................................................2

4 Сокращения.........................................................................3

5 Формат пакетов......................................................................3

6 Байт-стаффинг.......................................................................5

7 Контрольная сумма...................................................................5

8 Защита паролем......................................................................6

9 Адресация устройств..................................................................7

10 Ретрансляция пакетов в сети..........................................................8

11 Пакеты ответов......................................................................9

12 Флаги тревожных событий...........................................................12

13 Коды ошибок......................................................................12

14 Структуры данных..................................................................13

15 Инициативные пакеты...............................................................13

16 Устройства внутри устройств.........................................................16

Приложение А (справочное) Структуры данных команд для счетчиков воды и газа..............17

Приложение Б (справочное) Структуры данных команд для счетчиков тепла...................44

Приложение В (справочное) Структуры данных команд для электрических счетчиков............89

III

ПНСТ 976—2024

Введение

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

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

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

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

IV

ПНСТ 976—2024

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Протокол передачи данных для информационного обмена между компонентами системы комплексного учета энергоресурсов МИРТ

Information technology. Internet of things. Data transfer protocol for exchange between the components of the integrated energy accounting system MIRT

Срок действия — с 2024—12—01 до 2027—12—01

1 Область применения

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

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

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

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

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

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

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

Издание официальное

1

ПНСТ 976—2024

2 Нормативные ссылки

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

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

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

3 Термины и определения

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

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 пакет: Протокольный блок данных, передаваемый по каналу связи.

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

2

ПНСТ 976—2024

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

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

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

4 Сокращения

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

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

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

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

тия дополнительной защиты;

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

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

МЭК 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).

5 Формат пакетов

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

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

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

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

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

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

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

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

3

ПНСТ 976—2024

ПУТЬ

Запрос

Старт-1

Старт-2

Параметры

Ретрансляция

8.

Ф q

£ 5

8 I

Ответ

Старт-1

Старт-2

Параметры

Значение

Количество байт

0x73

0x55

CVDL4L3L2 L1

Ретрансляция

R3 R2 R1 R0 СЗ С2 С1

Команда

Пароль

Данные

CRC8

Стоп

£5

Команда

Данные

CRC8

Стоп

0x55

0-30

Заголовок пакета

0-31

1

Участвует в расчете CRC__ Подлежит байт-стаффингу____________________

| | | | Прикладные данные* |

Выбор конкретных алгоритмов шифрования прикладных данных для блока «Прикладные данные» определяет разработчик оконечного устройства в зависимости от целевого назначения оконечного устройства и действующих нормативных документов.

Рисунок 1 — Формат пакета с длиной поля данных до 31 байта

| ПУТЬ

Запрос

Старт-1

Старт-2

Параметры

Старшие биты длины данных

Ответ

Старт-1

Старт-2

Параметры

Ретрансляция

О

ГЛ

S s

s

§ 5

О 3 U х пт п =

Команда

Команда

Пароль

Статус ответа

Данные

Данные

CRC16

CRC16

Стоп

Стоп

Значение Количество байт

0x73

0x55

CVDL4L3L2L1 L0

L12-L5

R3 R2 R1 R0 СЗ С2 С1 СО

Заголовок пакета

0x55

0-

30

2

2

0-8191

Участвует в расчете CRC____________________________ Подлежит байт-стаффингу___________________

I II | Прикладные данные* |

Выбор конкретных алгоритмов шифрования прикладных данных для блока «Прикладные данные» определяет разработчик оконечного устройства в зависимости от целевого назначения оконечного устройства и действующих нормативных документов.

Рисунок 2 — Формат пакета с длиной поля данных до 8191 байт

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

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

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

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

4

ПНСТ 976—2024

Бит «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. Данные длиной более одного байта укладываются в пакет младшим байтом вперед.

6 Байт-стаффинг

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

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

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

7 Контрольная сумма

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

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

uint8_t crc8 (uint8_t *pData, uintl6_t Len) {

uint8_t crcByte, i;

uint8_t resCrc = 0;

while (len--)

{

crcByte = <uin18_t)*pData;

5

ПНСТ 976—2024

pData++;

1 = 8; while (i--) {

if (((crcByte ^л resCrc) & 0x80) == 0) resCrc = (uint8_t)(resCrc << 1); else

resCrc = (uint8_t)((resCrc << 1) ^л 0xA9); crcByte=(uint8_t)(crcByte << 1);

}

} return resCrc;

}

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

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

uintl6_t Crcl6(uint8_t *bAddr, uintl6_t wLen) {

uint8_t i;

uintl6_t wCRC; while(wLen--) {

wCRC = wCRC^Л(((uint16_t)(*bAddr++))<<8); for (i = 8;i;i--)

if (wCRC&0x8000) wCRC = (wCRC«l) ^л0х1021 ; else wCRC <<= 1;

}

} return wCRC;

8 Защита паролем

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

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

6

ПНСТ 976—2024

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

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

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

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

9 Адресация устройств

Адрес устройств состоит из двух байтов, т.е. используется диапазон адресов от 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 — для ЗС-модуля;

- 65295 — для 4С/ЬТЕ-модуля;

- 65296 — для SG-модуля;

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

- 65298 — для LTE Cat М1 (еМТЗ)-модуля;

- 65299 — для LTE Cat NB (NB-loT);

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

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

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

7

ПНСТ 976—2024

10 Ретрансляция пакетов в сети

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

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

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

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

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

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

Текущий адрес

Адрес назначения

База

Рисунок 3 — Схема ретрансляции

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

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

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

Запрос: Координатор => № 1 => № 2 => № 3 => № 4 => № 8

Ответ: № 8 => № 4 => № 3 => № 2 => № 1 => Координатор

Таблица 1 — Формирование пути для проверки связи с устройством

8

Окончание таблицы 1

ПНСТ 976—2024

11 Пакеты ответов

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

Текущий

Адрес

адрес

назначения

База

Зеркальный разворот относительно середины

I

Рисунок 4 — Схема формирования пакета ответа

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

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

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

9

ПНСТ 976—2024

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

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

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

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

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

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

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

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

Таблица 2 — Формат поля «Статус ответа»

Таблица 3 — Распределение ролей устройств

10

ПНСТ 976—2024

Продолжение таблицы 3

11

ПНСТ 976—2024

Окончание таблицы 3

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

12 Флаги тревожных событий

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

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

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

Р1 — вскрытие пломбы крышки клеммной колодки;

Р2 — вскрытие пломбы крышки корпуса;

РЗ — вскрытие дополнительной пломбы;

М1 — воздействие постоянного магнитного поля;

М2 — воздействие переменного магнитного поля;

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

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

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

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

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

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

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

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

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

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

13 Коды ошибок

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

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

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

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

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

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

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

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

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

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

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

ОхОА — действие уже выполнено;

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

12

ПНСТ 976—2024

14 Структуры данных

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

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

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

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

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

15 Инициативные пакеты

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

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

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

Таблица 4 — Формат статусного поля для инициативного пакета с данными счетчиков с батарейным питанием

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

1 — текущие данные;

2 — данные на начало суток;

1 байт — ASCII символ «D»;

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

1 байт — ASCII символ «С»;

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

1 байт — ASCII символ «V»;

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

1 байт — ASCII символ «S»;

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

13

ПНСТ 976—2024

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

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

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

Режимы:

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

В этом режиме настраивается время передачи данных (чч¹\мм¹) — 2 байта) и список данных для передачи (list¹) — 20 байт).

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

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

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

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

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

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

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

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

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

Таблица 5 — Таблица конфигурации инициативных данных

¹) чч — часы (0..23);

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

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

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

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

14

ПНСТ 976—2024

Продолжение таблицы 5

15

ПНСТ 976—2024

Окончание таблицы 5

16 Устройства внутри устройств

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

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

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

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

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

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

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

Пример — Устройство с сетевым адресом № 1122 имеет два GSM-модуля и модуль Ethernet, подлежащих различному конфигурированию. Запросы командой OxFC к устройству с адресом № 65001 через ретранслятор №1122 отдадут информацию, что внутри имеется три встроенных модуля: №1 — GSM-модуль, №2 — GSM-модуль и №3 — Ethernet-модуль. Обращаться к GSM-модулю №2 теперь можно используя путь: Координатор (65535)-> 1122 -> 65001 -> 2.

16

ПНСТ 976—2024

Приложение А (справочное)

Структуры данных команд для счетчиков воды и газа

17

ПНСТ 976—2024

18

ПНСТ 976—2024

19

ПНСТ 976—2024

20

ПНСТ 976—2024

21

ПНСТ 976—2024

22

ПНСТ 976—2024

23

ПНСТ 976—2024

24

ПНСТ 976—2024

25

ПНСТ 976—2024

26

ПНСТ 976—2024

27

ПНСТ 976—2024

28

ПНСТ 976—2024

29

ПНСТ 976—2024

30

ПНСТ 976—2024

31

ПНСТ 976—2024

32

ПНСТ 976—2024

33

ПНСТ 976—2024

34

ПНСТ 976—2024

35

ПНСТ 976—2024

36

ПНСТ 976—2024

37

ПНСТ 976—2024

38

ПНСТ 976—2024