Протокол ГОСТ АРМ-УУ

#Введение

Документ описывает протокол информационного обмена между АРМ и УУ версии v24 на основе ГОСТ Р 42.3.05-2023, приложение Б. Редакция от 06.10.2026.

#Список сокращений

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

Дежурный режим УУ - основной по времени режим, при котором УУ ожидает КУ от АРМ и отправляет НС.

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

#1.1 Общие положения

1. Команды, квитанции и незапрашиваемые сигналы передаются по TCP на порт 42305. Размер сообщения - ровно 8 байт, нумерация байтов - от 0 до 7. Сигнатуры: команда АРМ A5 CE, квитанция A7 CE, НС A3 CE. Это последовательности байтов; их не следует переставлять при записи 16-битного числа. Дополнительной контрольной суммы в сообщении нет.
2. При команде АРМ открывает соединение к УУ, отправляет одно сообщение и получает один ответ. После ответа УУ закрывает соединение. Следующая команда передается в новом соединении после завершения предыдущего обмена. Несколько команд в одном соединении и параллельные команды одному УУ не используются. АРМ передает все 8 байт одной операцией записи. Приемники с обеих сторон накапливают полный восьмибайтовый кадр: TCP может доставить его частями.
3. При самостоятельной передаче НС или результата E2 соединение открывает УУ к порту 42305 АРМ. АРМ отвечает A7 CE E0 FF 00 00 00 00 в этом соединении. УУ завершает обмен после подтверждения. На ответ в соединении, открытом АРМ, дополнительное АП не передается. Подробности: подтверждение E2.
4. IP-адрес каждого УУ и АРМ уникален в пределах системы. В УУ задается список разрешенных АРМ. Проверка адреса источника предшествует выполнению команды. Сеанс связан с IP-адресом АРМ, принятая команда которого запустила этот сеанс.
5. УУ отправляет НС каждому настроенному АРМ. Самостоятельный результат E2 адресуется инициатору сеанса. Периодический НС передает текущий режим из Б.24.1 каждые 120 с от последней отправки сообщения о режиме. Он не содержит полного состояния датчиков; для него используется запрос 0x50.
6. Звук передается по UDP на порт 42306: 4 байта счетчика little-endian и 80 байт G.711 A-law. Полный формат и правила счетчика приведены в 5.2 и 5.4.
7. АП подтверждает прием и анализ команды. Положительное АП запуска не подтверждает фактическое звучание или исправность ОУ. Итог сеанса передается в E2; датчики и текущий режим передаются отдельными сообщениями.
8. В сообщениях нет идентификатора транзакции. Повтор после потери ответа может попасть в уже начавшийся сеанс. Правила повторов и ограничения времени приведены в 5.3.

#1.2 Включение и перезагрузка устройства управления

УУ информирует АРМ о своем включении или перезагрузке. Алгоритм (см. диаграмму 4.1):

1. УУ передает АРМ НС с кодом 0x10 - "Включение или перезагрузка УУ" (табл. Б.24.1). АРМ отвечает КС "АП" (табл. Б.3).
2. АРМ передает УУ СС "Запрос состояния" (табл. Б.13).
3. АРМ ожидает от УУ ответную КС "Запрос состояния" (табл. Б.14).
4. УУ отвечает КС 0x50 в соединении запроса: байты 3-4 содержат входные сигналы (датчики), байты 5-6 - выходные сигналы (табл. Б.14, Б.14.1). УУ закрывает соединение; дополнительное АП не требуется.

#1.3 Передача информации об изменении состояния

УУ постоянно контролирует состояние себя, ОУ и датчиков. При любом изменении - информирует АРМ. Алгоритм (см. диаграмму 4.2):

1. УУ передает АРМ НС с соответствующим кодом (табл. Б.23, Б.24, Б.24.1).
2. АРМ отвечает КС "АП" (табл. Б.3). Информационный обмен завершен.

#1.4 Запрос состояния устройства управления

Запрос возвращает текущее состояние входных и выходных сигналов УУ. Алгоритм (см. диаграмму 4.3):

1. АРМ передает УУ СС "Запрос состояния" (табл. Б.13).
2. АРМ ожидает ответную КС (табл. Б.14).
3. УУ отвечает КС 0x50 (табл. Б.14): входные сигналы находятся в байтах 3-4, выходные - в байтах 5-6. Назначения датчиков приведены в Б.14.1. Затем УУ закрывает соединение; АРМ не передает дополнительное АП.

#1.5 Запрос типа устройства и версии ПО

Результат - передача УУ информации о типе и версии ПО. Алгоритм (см. диаграмму 4.4):

1. АРМ передает УУ СС "Запрос типа устройства и версии ПО" (табл. Б.15).
2. АРМ ожидает ответную КС (табл. Б.16).
3. УУ анализирует СС и отвечает КС "Запрос типа устройства и версии ПО" (табл. Б.16) с типом, версией и датой сборки ПО (число дней с 01.01.1970, без времени суток). Запрос завершен.

#1.6 Сеанс проверки без включения ОУ

Проверка без включения ОУ запускается только из дежурного режима. См. диаграмму 4.5.

1. АРМ передает A5 CE 48 FF 00 00 00 00. УУ отвечает АП A7 CE E0 FF 00 00 00 00.
2. УУ запускает проверку и отправляет настроенным АРМ НС A3 CE 14 00 00 00 00 00. Каждое АРМ подтверждает НС.
3. По завершении УУ передает инициатору результат E2 в отдельном TCP-соединении. АРМ подтверждает его АП. Положительный результат - FF 00, отрицательный - 00 03 в байтах 3-4.
4. УУ переходит в дежурный режим и отправляет НС 0x15 всем настроенным АРМ. АРМ подтверждает его. После освобождения командного соединения АРМ может запросить состояние 0x50; этот запрос не заменяет результат проверки.

При отрицательном АП сеанс не запускается. При потере АП результат доставки неизвестен; правила повторов приведены в 5.3. Повторный запуск при занятом УУ получает E0 00 03, в том числе от инициатора действующего сеанса.

#1.7 Сеанс проверки с включением ОУ

Проверка с включением ОУ запускается только из дежурного режима. См. диаграмму 4.6.

1. АРМ передает A5 CE 46 FF 00 00 00 00. УУ отвечает АП A7 CE E0 FF 00 00 00 00.
2. УУ запускает проверку и отправляет настроенным АРМ НС A3 CE 14 00 00 00 00 00. Каждое АРМ подтверждает НС.
3. По завершении УУ передает инициатору результат E2 в отдельном TCP-соединении. АРМ подтверждает его АП. Положительный результат - FF 00, отрицательный - 00 03 в байтах 3-4.
4. УУ переходит в дежурный режим и отправляет НС 0x15 всем настроенным АРМ. АРМ подтверждает его. После освобождения командного соединения АРМ может запросить состояние 0x50; этот запрос не заменяет результат проверки.

При отрицательном АП сеанс не запускается. При потере АП результат доставки неизвестен; правила повторов приведены в 5.3. Повторный запуск при занятом УУ получает E0 00 03, в том числе от инициатора действующего сеанса.

#1.8 Сеанс сиренного оповещения

Сеанс включает сирену непрерывно (0x07) или прерывисто (0x08). См. 4.7, 4.7.1, 4.7.2.

1. АРМ передает A5 CE 44 FF 07 00 00 00 или A5 CE 44 FF 08 00 00 00 и ожидает положительное АП.
2. УУ запускает сирену и отправляет всем настроенным АРМ НС 0x11. Каждое АРМ отвечает АП.
3. При завершении по команде инициатора 0x01 УУ возвращает E2 в соединении команды. Дополнительное АП не требуется. Байты 3-4: FF 00 при положительном результате, 00 00 при отсутствии положительного подтверждения работы ОУ.
4. При самостоятельном завершении УУ передает инициатору E2 в отдельном соединении: FF 01 при положительном результате и окончании по таймауту, 00 03 при отрицательном результате. АРМ отвечает АП. Самостоятельное завершение работы сирены до предельного времени также передается с причиной 0x01 при положительном результате.
5. После завершения УУ отправляет НС 0x15. "Сброс" 0x03 прерывает сеанс с положительным АП и НС 0x15, без отдельного E2.

При отрицательном АП сеанс не запускается. При потере АП результат доставки неизвестен; правила повторов приведены в 5.3. Повторный запуск при занятом УУ получает E0 00 03, в том числе от инициатора действующего сеанса.

НС неисправности описывает состояние оборудования и сам по себе не завершает сеанс. Для результата используются квитанции Б.4.

#1.9 Сеанс звукового оповещения

Передача речи доступна профилю 0x0B. См. 4.8, 4.8.1, 4.8.2 и 4.8.3.

1. АРМ передает A5 CE 44 FF 0C 00 00 00 и ожидает положительное АП. УУ открывает сеанс и отправляет НС 0x12 настроенным АРМ.
2. Инициатор передает A5 CE 05 00 00 00 00 00 и ожидает положительное АП. Затем отправляет UDP-аудио по правилам 5.4.
3. Для остановки речи инициатор прекращает UDP-поток, передает A5 CE 06 00 00 00 00 00 и получает АП. Команда останавливает прием и воспроизведение речи, но оставляет сеанс открытым.
4. В одном сеансе можно повторить цикл 0x05, UDP, 0x06. Каждый новый 0x05 переинициализирует приемный аудиобуфер; счетчик нового потока начинается с нуля. Повторять 0x05 во время передачи уже идущего потока нельзя: это нарушает непрерывность приема.
5. Для завершения инициатор передает 0x01. УУ отвечает E2 в этом соединении и отправляет НС 0x15 всем настроенным АРМ. Ответный E2 не требует АП; НС требует.

При отрицательном АП сеанс не запускается. При потере АП результат доставки неизвестен; правила повторов приведены в 5.3. Повторный запуск при занятом УУ получает E0 00 03, в том числе от инициатора действующего сеанса.

При самостоятельном завершении по таймауту УУ передает инициатору E2 FF 01 при положительном результате или E2 00 03 при отрицательном, затем НС 0x15. Самостоятельный E2 подтверждается АП. "Сброс" 0x03 прекращает сеанс с АП и НС 0x15, без отдельного E2.

#1.10 Сеанс трансляции заранее записанного звукового сообщения

Профиль 0x0B поддерживает запуск сообщений, хранящихся в ОУ. Номер N от 1 до 16 кодируется в байте 4 как 0x10 + (N - 1): сообщение 1 - 0x10, сообщение 16 - 0x1F. См. 4.9, 4.9.1 и 4.9.2.

1. АРМ передает 0x44 с кодом сообщения и ожидает положительное АП. Например, первое сообщение: A5 CE 44 FF 10 00 00 00.
2. УУ передает ОУ команду воспроизведения и отправляет всем настроенным АРМ НС 0x13. UDP-аудио от АРМ в этом сценарии не передается.
3. При включенном контроле обратной связи УУ отслеживает переход ОУ в рабочее состояние и последующее окончание воспроизведения. Результат E2 FF 00 или E2 00 03 передается инициатору в отдельном соединении и подтверждается АП.
4. При отсутствии подтвержденного окончания сеанс завершается командой 0x01 либо по предельному времени. При положительном результате самостоятельное завершение по времени передается как E2 FF 01. Положительное АП запуска не подтверждает наличие выбранной записи или ее воспроизведение.
5. После завершения УУ передает НС 0x15. "Сброс" 0x03 прерывает сеанс с АП и НС 0x15, без отдельного E2.

При отрицательном АП сеанс не запускается. При потере АП результат доставки неизвестен; правила повторов приведены в 5.3. Повторный запуск при занятом УУ получает E0 00 03, в том числе от инициатора действующего сеанса.

#1.11 Профили и поддерживаемые функции

В v24 определены два профиля. Профиль определяется байтом 3 ответа 0x51. Наличие бита функции не сообщает текущее состояние ОУ.

Назначения других битов типа и кодов датчиков сохранены в таблицах для совместимости. Нулевой бит состояния неподдерживаемого датчика не доказывает его наличие и исправность. Отдельной команды согласования редакции v24 или запроса списка возможностей нет. Текстовые сеансы и передача текста в v24 не определены.

#1.12 Команды и состояние сеанса

Обозначения ответа ниже: код квитанции и ее байты 3-4. Сначала проверяется разрешенный IP-адрес: для неразрешенного источника любая команда получает E0 00 02 без изменения сеанса.

Для 0x44 занятость проверяется раньше подкоманды: неподдерживаемая подкоманда при активном сеансе получает E0 00 03. Для 0x01 и поддерживаемых 0x05/0x06 проверяется инициатор; "Сброс" доступен любому разрешенному АРМ. Запросы состояния и версии сеанс не перехватывают. В профиле 0x0B команды 0x05/0x06 обрабатываются также при режиме записанных сообщений; в сценарии 1.10 они не используются, чтобы не переключить речевой тракт.

#1.13 Общие правила полей и совместимости

• Многобайтовые счетчики, маски и дата передаются младшим байтом вперед. Номера версии ПО в байтах 4 и 5 ответа 0x51 - отдельные десятичные компоненты. Сигнатура задается двумя фиксированными байтами.
• Резервные байты отправитель заполняет нулями. Их ненулевое значение не вводит дополнительного действия. Неизвестные поля нельзя трактовать как подтвержденные возможности устройства.
• Байт абонента в командах 0x44/0x46/0x48 сохраняет положение из исходного формата, но выбор отдельного ОУ через этот байт в v24 не выполняется. АРМ передает 0xFF; действие относится к ОУ данного УУ. Значения 0x01-0xFE не обеспечивают индивидуальной адресации.
• Для неизвестной команды с корректным форматом предусмотрено отрицательное АП E0 00 01. Поврежденный, неполный пакет или неизвестная сигнатура не имеют отдельного кода ошибки формата; отсутствие ответа не следует интерпретировать как такой код.
• Неизвестный код НС, версия или вид дополнительной телеметрии подтверждается обычным положительным АП, но его данные не изменяют известные состояния. Неизвестная причина E2 отображается в исходном виде вместе с результатом; ее нельзя заменять успешным завершением.
• Коды 0x54 и 0x55 сохранены как совместимые служебные обращения: ответ A7 CE 54 00 00 00 00 00 или A7 CE 55 00 00 00 00 00. Время и дата этими обращениями не изменяются; применять их для синхронизации часов нельзя.
• НС и самостоятельные результаты могут повторяться при потере АП. АРМ подтверждает каждый повтор; повтор результата не создает новый сеанс. Без идентификатора транзакции нельзя надежно связать запоздалый результат с новым сеансом только по коду E2.

#2. Перечень команд

Таблица Б.0 - Перечень команд управления, квитирующих и сервисных сигналов Вводится вновь

#Матрица направлений команд

#Карта состояний устройства управления

Таблица Б.2 - Список команд управления ОУ

Таблица Б.3.1 - Коды ошибок в КС "АП" Вводится вновь

Таблица Б.4.1 - Коды ошибок и состояний в КС "Подтверждение ОУ" Вводится вновь

В профилях v24 байты 5-6 равны 00 00; раздельные выходные сигналы этим ответом не передаются. Биты входов, не перечисленные для профиля в 1.11, равны нулю. Код датчика N из Б.24 соответствует биту N-1 в 16-битной маске входов.

Таблица Б.14.1 - Коды датчиков УУ Вводится вновь

Комбинации битов типа

Это арифметические комбинации назначенных битов. Профили v24 имеют значения 0x01 и 0x0B; отдельные профили 0x03, 0x09 и 0x0A настоящим документом не задаются. Версия ПО записывается как старший байт.младший байт, без BCD-кодирования. Дата - беззнаковое 16-битное число дней с 01.01.1970; время суток отсутствует.

#Таблица Б.23.1 - Дополнительная детализация фидеров

Дополнительный НС 0x30 профиля 0x0B передает состояния восьми протокольных позиций фидеров одной страницы. Он дополняет общее событие неисправности 0x08 и не заменяет его. НС подтверждается обычным АП.

Для позиции k от 0 до 7 состояние равно (states >> (2*k)) & 3, номер позиции равен 8*page + k + 1. Значения: 0 - выключено без неисправности; 1 - обрыв; 2 - перегрузка; 3 - включено без неисправности.

Максимум - 34 позиции, поэтому на странице 4 значимы только позиции 33 и 34 (младшие 4 бита). Число физических линий определяется конфигурацией ОУ и в этом кадре не передается. Неиспользуемые позиции не следует отображать как реальные исправные линии. Страницы передаются при изменениях; отсутствие страницы не означает отсутствие неисправности. Неизвестные версия, вид объекта и номер страницы подтверждаются АП без интерпретации данных.

После запуска сеанса профиль 0x0B передает НС режима, затем снимок активных неисправностей датчиков 0x01, 0x03, 0x04, 0x06, 0x08, 0x09. При неисправных фидерах дополнительно передаются страницы 0x30 с обрывом или перегрузкой. Нормальные состояния в этот снимок не включаются.

Таблица Б.24 - Список датчиков (событий) для НС (табл. Б.23)

Таблица Б.24.1 - Коды состояния УУ для НС (табл. Б.23) Вводится вновь

#4.1 Включение и перезагрузка устройства управления

#4.2 Изменение состояния УУ / ОУ / датчиков

#4.3 Запрос состояния устройства управления

#4.4 Запрос типа устройства и версии ПО

#4.5 Сеанс проверки без включения ОУ

#4.5.1 Проверка без включения ОУ - аварийное завершение

#4.6 Сеанс проверки с включением ОУ

#4.6.1 Проверка с включением ОУ - аварийное завершение

#4.7 Сеанс сиренного оповещения

#4.7.1 Сиренное оповещение - завершение по сбою или таймауту

#4.7.2 Сиренное оповещение - аварийное завершение

#4.8 Сеанс звукового оповещения

#4.8.1 Звуковое оповещение - завершение по сбою или таймауту

#4.8.2 Звуковое оповещение - аварийное завершение

#4.8.3 Передача звукового сообщения (детализация)

#4.9 Сеанс трансляции заранее записанного звукового сообщения

#4.9.1 Трансляция записанного - завершение по сбою или таймауту

#4.9.2 Трансляция записанного - аварийное завершение

Таблица 5.1 - Назначение сетевых подключений

Таблица 5.2 - Параметры передачи звукового сообщения по UDP

#5.3 Время обмена и повторы

Время проверки и сеанса относится к выполнению на УУ. Ожидание результата на АРМ должно дополнительно учитывать доставку и повторы. АП запуска, периодический НС и итоговый E2 - разные события и не заменяют друг друга.

При повторной отправке самостоятельного сообщения УУ заново открывает TCP-соединение. Интервал между попытками включает сетевое соединение, ожидание квитанции и освобождение канала; он не равен строго 400 мс. Параметры повторов УУ не задают политику повторов команд АРМ.

При потере ответа на запуск АРМ сохраняет состояние "результат доставки неизвестен". Слепой повтор 0x44/0x46/0x48 не гарантирует повторного выполнения: занятое УУ ответит E0 00 03. По 0x50 можно уточнить датчики, но не владельца и не результат сеанса. Для режима используются НС. Повторять команду 0x05 на идущем потоке нельзя из-за переинициализации буфера.

После НС включения 0x10 АРМ прекращает отправку текущего UDP-потока и снимает предположение о продолжающемся сеансе. Новый сеанс требует отдельного запуска. Пропуск периодического НС означает отсутствие подтвержденной связи, но не определяет физическое состояние ОУ.

#5.4 Правила передачи звука

1. Передаются raw-данные G.711 A-law, 8000 отсчетов/с, моно. WAV-заголовок, RTP-заголовок и дополнительные поля не передаются. Одна датаграмма содержит 80 отсчетов, то есть 10 мс звука.
2. Полезная нагрузка UDP имеет ровно 84 байта. Счетчик занимает байты 0-3 (беззнаковое число little-endian), звук - байты 4-83. UDP-датаграммы другой длины не обрабатываются как аудиопакеты.
3. Первый пакет нового потока имеет счетчик 0; каждый следующий увеличивает его на 1. Допустимый диапазон - 0..131071 (0x00000000..0x0001FFFF). Четырехбайтовое поле не означает поддержку всего диапазона uint32. Переход через верхнюю границу внутри потока не определен; передавать значения за пределами диапазона нельзя. При установленном предельном времени речевого сеанса 600 с этот предел не достигается при 100 пакетах/с.
4. После принятого 0x05 приемный буфер и привязка счетчика переинициализируются. Следующий поток после 0x06 и нового 0x05 также начинается с нуля. Повторное воспроизведение файла внутри непрерывного UDP-потока продолжает счетчик, а не сбрасывает его.
5. Аудио принимается от выбранного источника сеанса, входящего в список разрешенных АРМ. Другой IP-адрес не заменяет инициатора текущего потока.
6. УУ размещает данные по счетчику с привязкой к первому принятому пакету. Дубликат уже принятой позиции и пакет для уже воспроизведенной области не дают повторного воспроизведения. Пакеты могут поступать с перестановкой до момента воспроизведения соответствующей области.
7. Для аудиодатаграмм нет АП, запроса повторной передачи и гарантии восстановления потерянного звука. Пропуск счетчика означает пропуск данных; отправитель продолжает нумерацию и темп. Приемный буфер не является основанием для отправки всего файла без выдерживания интервала 10 мс.

Примеры заголовков: пакет 0 - 00 00 00 00, пакет 1 - 01 00 00 00, пакет 256 - 00 01 00 00. После каждого заголовка следуют ровно 80 байт A-law.

#5.5 Байтовые примеры обмена

Каждая строка ниже - отдельное восьмибайтовое сообщение. Это примеры формата, а не дополнительные команды. В примерах старта предполагаются разрешенный IP-адрес и дежурное состояние УУ.

Полные последовательности, включая НС и открытие обратного TCP-соединения, приведены в разделе 4. Для разбора одного сообщения используйте декодер.

#Приложение А. Защищенный обмен и интеграция

Приложение устанавливает требования к дополнительному защищенному обмену АРМ-УУ. Оно применяется при выборе защищенного режима и не изменяет смысл команд, квитанций и событий v24. Криптографическая оболочка является отдельным расширением, а не частью исходного ГОСТ Р 42.3.05-2023.

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

#А.1 Требования к защите сообщений

Описание алгоритмов: RFC 7801: "Кузнечик" и RFC 9058: MGM. Совпадения алгоритма недостаточно для совместимости: порядок установления сеанса, формат оболочки, счетчики, выработка ключей и обработка ошибок должны соответствовать единой спецификации криптографического профиля.

#А.2 Ключи и обслуживание

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

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

#А.3 Режим и сохранность данных

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

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

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

#А.4 Речевой канал

Команды запуска, остановки и завершения речевого сеанса передаются с криптографической защитой. Прием аудио разрешается только в рамках принятого речевого сеанса от его согласованного источника и прекращается при завершении сеанса. Формат звука приведен в разделе 5.4.

#А.5 Подключение оборудования производителей

Производитель может реализовать защищенный обмен в собственном УУ либо использовать МЗУМ как модуль сопряжения своего оборудования с АРМ.

В состав согласования входят команды и подтверждения ОУ, аварийные сигналы, поведение после перезапуска, речевой тракт при его наличии, установка и замена ключей, настройка и обновление ПО. При использовании МЗУМ отдельно определяется защита локального интерфейса между модулем и ОУ: защита связи АРМ-МЗУМ сама по себе не защищает этот участок.

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

Это приложение задает общие требования и порядок интеграции. Байтовый формат криптографической оболочки и тестовые векторы фиксируются в согласованной спецификации профиля. Декодер и конструктор на этой странице работают с сообщениями v24 без криптографической оболочки; они не устанавливают защищенное соединение и не работают с ключами.