"ГОСТ Р 42.3.05-2023. Национальный стандарт Российской Федерации. Гражданская оборона. Технические средства оповещения населения. Протоколы информационного обмена. Общие требования"
(утв. и введен в действие Приказом Росстандарта от 14.03.2023 N 129-ст)

1 РАЗРАБОТАН Федеральным государственным бюджетным учреждением "Всероссийский научно-исследовательский институт по проблемам гражданской обороны и чрезвычайных ситуаций МЧС России" (Федеральный центр науки и высоких технологий) [ФГБУ ВНИИ ГОЧС (ФЦ)]

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 071 "Гражданская оборона, предупреждение и ликвидация чрезвычайных ситуаций"

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

4 ВВЕДЕН ВПЕРВЫЕ

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

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

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

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

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

ГОСТ 34.10 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ 34.13 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

ГОСТ Р 42.3.01 Гражданская оборона. Технические средства оповещения населения. Классификация. Общие технические требования

ГОСТ Р 51583 Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения

ГОСТ Р 54458 Телевидение вещательное цифровое. Транспортирование аудио- и видеослужб с алгоритмом компрессии MPEG-4 (H.264/AVC) по цифровым системам передачи. Общие технические требования

ГОСТ Р 58668.11 (ИСО/МЭК 19794-13) Информационные технологии. Биометрия. Форматы обмена биометрическими данными. Данные голоса

ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

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

В настоящем стандарте использованы термины по ГОСТ Р 42.3.01, а также следующие термины с соответствующими определениями:

3.1 абонент системы оповещения: Включенное в автоматизированную систему оповещения подчиненное (нижестоящее по уровню управления) техническое средство оповещения, выполняющее функцию автоматизированного рабочего места и (или) оконечного средства оповещения.

3.2 авторизация доступа: Процедура контроля доступа к программе автоматизированной системы оповещения (технического средства оповещения) в соответствии с установленными правилами управления доступом.

3.3 алгоритм работы системы оповещения населения (алгоритм действий): Последовательность действий технических средств оповещения при выполнении системой оповещения своих функций в рабочем и дежурном режимах.

3.4

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

3.6 отчет об оповещении: Автоматически (либо в ручном режиме) зафиксированный на электронном и (или) бумажном носителе результат выполнения алгоритма работы системы оповещения населения или произведенных эксплуатирующим персоналом операций на техническом средстве оповещения (в программах, с оборудованием).

3.7 дежурный режим технического средства оповещения: Исходный режим, в котором техническое средство оповещения находится в постоянной готовности к переводу в рабочий режим или осуществляет передачу/прием/трансляцию незапрашиваемых сигналов.

3.8 рабочий режим технического средства оповещения: Режим, при котором техническим средством оповещения осуществляется передача/прием/трансляция команд управления, квитирующих сигналов, сигналов оповещения и экстренной информации.

3.9 автоматический режим системы оповещения: Режим, в котором техническое средство оповещения включается в рабочий режим по заранее установленному алгоритму при получении установленных команд управления от датчиков (автоматизированных комплексов) сбора, обработки и представления информации систем контроля и мониторинга чрезвычайных ситуаций природного и техногенного характера.

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

3.11 автоматическая квитанция: Автоматически формируемый сигнал при условии нахождения в исправном состоянии технического средства оповещения.

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

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

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

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

3.16 служебный [сервисный] сигнал: Сигнал запроса или проверки состояния технического средства оповещения.

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

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

АП - автоматическое подтверждение;

АРМ - автоматизированное рабочее место;

ИП - протокол информационного обмена;

КС - квитирующий сигнал;

КУ - команда управления;

НС - незапрашиваемый сигнал;

ОУ - оконечное устройство оповещения;

РП - ручное подтверждение;

РТУ - радиотрансляционный узел;

СО - сигнал оповещения;

СС - сервисный (служебный) сигнал;

СЦВ - стойка циркулярного вызова;

СЦНЭТВ - сеть цифрового наземного эфирного телерадиовещания;

СЭ - стойка электросиренная;

СЭВ - система электронного взаимодействия;

УКЭП - усиленная квалифицированная электронная подпись;

ЧС - чрезвычайная ситуация;

GPIO - интерфейс ввода/вывода общего назначения (general-purpose input/output);

ID - уникальный признак объекта, позволяющий отличать его от других объектов (identifier);

IP - межсетевой протокол, маршрутизируемый протокол сетевого уровня стека TCP/IP (Internet Protocol);

OSI - сетевая модель взаимодействия открытых систем (open systems interconnection model);

TLS - протокол защиты транспортного уровня (transport layer security);

TCP - протокол управления передачей данных по сети (transmission control protocol);

UDP - протокол транспортного уровня (user datagram protocol);

XML - расширяемый язык разметки (extensible markup language).

5.1 Единый протокол информационного обмена между техническими средствами оповещения различных производителей (далее - протокол информационного обмена, ИП) разработан с целью создания единого информационного пространства для обеспечения совместимости систем оповещения населения всех уровней, построенных на ТСО различных производителей.

ИП не рассматривает транспортные механизмы передачи сообщений.

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

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

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

Задачи маршрутизации, резервирования, защиты информации могут решаться с помощью технических средств передачи данных и (или) протоколов, не входящих в область применения настоящего стандарта.

5.4 ИП должен быть протоколом прикладного уровня семиуровневой модели OSI по ГОСТ Р ИСО/МЭК 7498-1.

5.5 В качестве транспортной среды для информационного обмена в системах оповещения населения применяются сети связи и передачи данных на основе протоколов TCP/IP.

5.6 ИП должен представлять собой независимые, но согласованные между собой части взаимодействия:

- АРМ оповещения различных уровней систем оповещения населения (приложение А);

- АРМ оповещения и устройства запуска, управления и мониторинга (далее - устройство управления) одного уровня управления (приложение Б);

- АРМ оповещения и СЦНЭТВ (приложение В);

- АРМ оповещения со сторонними взаимодействующими автоматизированными и информационными системами.

5.7 Классификация ТСО и функциональные требования к ним должны соответствовать требованиям ГОСТ Р 42.3.01.

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

- СО;

- КУ;

- КС;

- СС;

- НС (сигналы от датчиков мониторинга технического состояния ТСО, сигналы от датчиков систем мониторинга и прогнозирования).

5.9.1 СО могут подаваться в виде:

- звукового оповещения;

- речевого сообщения;

- текстового (буквенно-цифрового) сообщения;

- видеосообщения.

5.9.2 Режимы передачи СО:

- циркулярный;

- групповой;

- избирательный.

5.9.3.1 Звуковое оповещение (звучание сирены) - в соответствии с ГОСТ Р 42.3.01.

5.9.3.2 Формат передачи речевого сообщения: A-Law (8 кГц, 8 бит, моно) в режиме реального времени по протоколу UDP [1]. Частота следования пакетов (датаграмм) равна 100 Гц. Нагрузка датаграммы составляет 84 байта: 4 байта - заголовок, 80 байт - звуковые данные. Заголовок представляет собой 32-битный инкрементальный счетчик пакетов (датаграмм), служащий для восстановления порядка и обработки потерь пакетов по ГОСТ Р 58668.11.

5.9.4 Текстовое (буквенно-цифровое) сообщение должно:

- передаваться в кириллице и (или) арабскими цифрами;

- быть внятным для понимания;

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

- иметь переменную длину, включая цифры, пробелы и знаки препинания;

- иметь не более 300 символов текстового файла для передачи на табло "бегущая строка";

- иметь не более 134 символов по каналам операторов связи сетей подвижной радиотелефонной.

5.9.5 Видеосообщение (видеоконтент) должно передаваться для автоматизированных систем оповещения населения (электронных табло и др.) в соответствии с таблицей 1.

Формат видеосообщения (видеоконтента) для передачи по СЦНЭТВ должен определяться техническими условиями, выдаваемыми Федеральным государственным унитарным предприятием "Российская телевизионная и радиовещательная сеть".

5.10.1.1 Команды управления:

- команда N 1 - включение АСО, аппаратуры оповещения старого парка (СЦВ) и передача речевого сообщения "объявлен сбор";

- команда N 2 - включение устройств управления, аппаратуры оповещения старого парка (СЭ, РТУ) и оконечных средств звукового оповещения в непрерывном режиме (однотональное звучание) продолжительностью 3 мин;

- команда N 3 - включение устройства управления аппаратуры оповещения старого парка, сетей радио- и телевизионного вещания, уличной звукофикации, РТУ и передача сигнала звукового оповещения в прерывистом режиме (звук изменяющейся тональности) и заранее записанного речевого (видео) сообщения;

- команда N 4 - включение АСО, аппаратуры оповещения старого парка (СЦВ) и передачи речевого сообщения;

- команда N 5 - включение/переключение сетей радио- и телевизионного вещания, уличной звукофикации, РТУ и передача заранее записанного речевого (видео) сообщения или речевого сообщения с микрофона АРМ;

- команда N 6 - проверочная и выключающая команда, приведение технических средств оповещения в исходное состояние;

- КУ с 7 по 128 - резервные.

5.10.1.2 КУ должны передаваться по нисходящим уровням подчиненности системы оповещения.

КС должен формироваться АРМ (устройством запуска) на каждую принимаемую КУ путем АП или РП дежурным диспетчером АРМ, за исключением команды "сброс". Подтверждение срабатывания ОУ формируется при помощи КС ОУ.

КС должен информировать о приеме КУ, успешном выполнении КУ.

При сбое выполнения КУ выдается СС "Сбой".

5.10.2.1 КС должен передаваться на АРМ, инициирующий сеанс оповещения.

СС предназначен для проверки и запроса состояния ТСО и подразделяется на сигналы:

- проверка состояния (зондирующие пакеты) - для определения доступности (исправности) ТСО и своевременного обнаружения отказов оборудования и сетей связи;

- взаимное уведомление АРМ одного уровня при задействовании системы оповещения с одного из них;

- передача управления - для передачи управления с одного АРМ на другой в процессе эксплуатации системы оповещения населения;

- "Сбой";

- установка времени - для поддержания точного хода часов реального времени в системе оповещения.

НС предназначен:

- для информирования о нештатных или аварийных ситуациях:

- неисправность (неготовность) ТСО;

- несанкционированное вскрытие ТСО;

- выход за границы эксплуатационных параметров ТСО (пониженная или повышенная температура и т.д.);

- неисправность или отсутствие канала (линии, сети) связи;

- срабатывание системы мониторинга ЧС.

5.11.1 СО (аудио/видео) СЦНЭТВ должны передаваться со следующими параметрами:

- некомпрессированный видеосигнал стандартной четкости SD SDI (SMPTE 259M) с разрешающей способностью изображения - 720 x 576 50i с вложенными сигналами звукового сопровождения (SMPTE 272M), одна стереопара (1-я группа), физический интерфейс электрический BNC 75 Ом;

- компрессированный видеосигнал MPEG-4 AVC (по ГОСТ Р 54458) Main Profile уровень 3 (MP@L3) с разрешающей способностью изображения 720 x 576 50i, звуковым сопровождением в формате MPEG1 L2 и постоянной скоростью программного потока, не превышающей 3 Мбит/с, из которых элементарный поток видео - не более 2720 кбит/с, элементарный поток аудио (стерео) - не более 192 кбит/с, в виде транспортного потока MPEG2-TS over Ethernet (по ГОСТ Р 54458) по определенному техническими условиями адресу многоадресной рассылки (multicast address) и порту (port), физический интерфейс Ethernet 100 Base-TX, витая пара категории 5 и выше;

- компрессированный видеосигнал MPEG-4 AVC (по ГОСТ Р 54458) Main Profile уровень 3 (MP@L3) с разрешающей способностью изображения 720 x 576 50i, звуковым сопровождением в формате MPEG1 L2 и постоянной скоростью программного потока, не превышающей 3 Мбит/с, из которых элементарный поток видео - не более 2720 кбит/с, элементарный поток аудио (стерео) - не более 192 кбит/с, в виде транспортного потока MPEG2-TS over ASI [2], физический интерфейс электрический BNC 75 Ом.

5.11.2 КУ замещения СЦНЭТВ и управления ОУ звукового и речевого оповещения через СЦНЭТВ должны передаваться с параметрами:

- GPIO интерфейсы ввода/вывода общего назначения, отдельная витая пара для начала передачи сигналов оповещения и (или) экстренной информации, отдельная пара для окончания передачи сигналов оповещения и (или) экстренной информации. Команда по каждой отдельной паре должна подаваться однократным (период замыкания в пределах 0,5 - 1,0 с) замыканием и размыканием контактов "GPIO интерфейсы ввода/вывода общего назначения", не допускается замыкание контактов по отдельной паре на период передачи/отсутствия передачи сигналов оповещения и (или) экстренной информации;

- посылки в формате XML (по форме в соответствии с таблицей 2), передаваемые по протоколу TCP/IP (Ethernet), порт 7777;

- порядок следования байт заголовка допустим от младших к старшим или от старших к младшим.

Формат посылки КУ приведен в таблице 2.

Пример сформированных XML-пакетов приведен в приложении Г.

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

В рабочем режиме ТСО осуществляется передача СО, КУ, КС. Общая длительность рабочего режима не должна превышать восемнадцати минут при трехкратной передаче речевого сообщения. Если после окончания сеанса оповещения в течение одной минуты не поступит КУ "Завершение сеанса" или КУ "Сброс", ТСО должно самостоятельно завершить сеанс оповещения и перейти в дежурный режим.

5.13.1 Алгоритм задействования должен описывать последовательность выполнения процедур (команд) при переходе ТСО из дежурного режима в рабочий режим (режим оповещения) от момента запуска сценария оповещения до момента получения КУ "Окончание сеанса" или КУ "Сброс", в том числе формирование и передачу квитирующих сигналов.

5.13.2 Алгоритм задействования каждого ТСО и его адресация должны задаваться АРМ оповещения по заранее подготовленным сценариям оповещения и передаваться абонентам системы оповещения.

5.13.3 При автоматическом способе функционирования запуск ТСО должен осуществляться при получении КУ или НС о срабатывании датчиков ЧС (аварии) и (или) от систем мониторинга опасных природных явлений и техногенных процессов.

5.13.4 При автоматизированном способе функционирования системы оповещения запуск ТСО должен осуществляться АРМ оповещения путем непосредственного набора и запуска на АРМ алгоритма перевода системы оповещения в рабочий режим с последующим выполнением действий ТСО по передаче сигналов и (или) информации с передачей соответствующей КУ.

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

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

После перевода управления с АРМ оповещения первого приоритета на следующее АРМ оповещения, АРМ оповещения первого приоритета переводится в дежурный режим.

5.13.6 В процессе функционирования АРМ оповещения должно выполнять информационное взаимодействие по следующим направлениям:

- входящее оповещение. Поступающий на АРМ оповещения СО требует ответного КС АП или РП;

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

- входящие КС с ретрансляцией. При ретрансляции АРМ оповещения, инициирующее СО, должно получать КС;

- АРМ оповещения, ретранслирующее КУ, должно перенаправлять КС на АРМ оповещения, инициирующее СО;

- исходящее оповещение. АРМ оповещения готовит и посылает СО, КУ управляемым АРМ оповещения, от которых получает КС о состоянии ОУ и результатах оповещения.

5.13.7 В процессе функционирования устройство управления должно:

- получать СО от АРМ оповещения, на которое устройство запуска должно выдавать КС АП и (или) подтверждения ОУ;

- транслировать СО для воспроизведения или отображения ОУ;

- передавать СС (команды установки часов реального времени, зондирующие пакеты и т.д.);

- передавать НС (сигналы от датчиков, контролирующих техническое состояние ТСО, наличие электропитания, несанкционированного доступа).

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

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

5.14 В ТСО должен быть синхронизирован ход часов.

5.15.1 Организация информационного обмена между ТСО с программно-аппаратными средствами сторонних взаимодействующих автоматизированных и информационных систем должна осуществляться на основе клиент-серверной архитектуры с использованием исходящего информационного шлюза, функционирующего в открытой или закрытой сети путем предоставления данных:

- работоспособности ТСО системы оповещения населения соответствующего уровня управления Единой государственной системы предупреждения и ликвидации чрезвычайных ситуаций;

- проведенного сеанса оповещения населения.

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

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

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

5.15.5 При информационном обмене между ТСО с программно-аппаратными средствами сторонних взаимодействующих автоматизированных и информационных систем должен использоваться единый стек открытых протоколов по (см. [3] и [4]).

5.15.6 Содержание протоколов информационного обмена ТСО с сервером взаимодействия должно разрабатываться при конкретном проектировании.

5.16 Правильность реализации ИП и выполнения функции сопряжения между техническими средствами оповещения различных производителей должна быть подтверждена соответствующими испытаниями с участием федерального органа исполнительной власти, уполномоченного на решение задач в области гражданской обороны, защиты населения и территорий от ЧС и (или) его научных организаций и испытательных лабораторий.

6.1 Организация информационного обмена ТСО с СЦНЭТВ должна осуществляться на основе клиент-серверной архитектуры с использованием СЭВ, обрабатывающего клиентские подключения ТСО с использованием средств криптографической защиты информации в соответствии с ГОСТ Р 51583, ГОСТ 34.12, ГОСТ 34.13.

6.2 При взаимодействии ТСО и СЭВ должна использоваться УКЭП в следующей последовательности:

- АРМ оповещения формирует XML-пакет в виде файла, подписанного УКЭП и зашифрованного средствами криптографической защиты информации (XML-пакет);

- входящий контроль XML-пакета на СВ должен включать в себя расшифрование и проверку УКЭП XML-пакета, проводится при его приеме на СВ;

- после входящего контроля XML-пакета на СЭВ от АРМ оповещения по результатам его обработки СЭВ направляет на АРМ оповещения XML-пакет в виде файла с результатами обработки XML входящего пакета:

- в случае отрицательного результата АРМ должен выяснить причину ошибки и при необходимости переформировать XML-пакет и заново направить на СЭВ оповещения;

- в случае положительного результата АРМ оповещения должен направить XML-пакет о приеме или исключении из обработки XML-пакета.

Если ответный XML-пакет СЭВ не был получен, АРМ оповещения должно направить запрос для выяснения причин и организации дальнейшего взаимодействия.

6.3 Сообщения должны подписываться в соответствии с [5] с учетом требований по ГОСТ 34.10 и [6].

6.4 Для технической защиты информации должны быть обеспечены:

- межсетевое экранирование и криптографическая защита сетевого трафика с использованием средств криптографической защиты информации;

- антивирусная защита программного обеспечения ТСО.

6.5 АРМ оповещения должно обеспечивать механизм разграничения доступа.

А.1 Взаимодействие между АРМ оповещения должно быть реализовано по технологии клиент-сервер: принимающее АРМ оповещения находится в режиме сервера, а передающее - в режиме клиента. СО, КУ, КС, СС, НС передаются по протоколу TCP. Передача начинается с младшего байта. КУ "Сброс" может поступить в любой момент времени. При получении КУ "Сброс" АРМ оповещения переходит в дежурный режим. Перечень команд АРМ оповещения в режиме "Входящее оповещение" приведен в таблице А.1.

Графы состояний АРМ оповещения в режиме "Входящее оповещение" приведены на рисунке А.1.

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

Воспроизведение звукового оповещения должно начинаться после получения КУ "Старт звукового сообщения" (таблица А.3).

Остановка воспроизведения звукового сообщения происходит по КУ "Остановка звукового сообщения" (таблица А.4).

Запуск и остановка звукового оповещения в течение сеанса оповещения может происходить не более трех раз. Прием КУ "Старт звукового сообщения" АРМ оповещения подтверждается КС АП, команда "Остановка звукового сообщения" не подтверждается КС.

Формат текстового сообщения приведен в таблице А.5.

Прием текстового сообщения подтверждается КС АП.

А.2.3 Формат КУ "Конец сеанса" приведен в таблице А.6. После получения данной команды АРМ оповещения сохраняет свое состояние до получения КУ "Сброс". Между командой "Окончание сеанса" и командой "Сброс" для АРМ доступна только посылка КС "Ручное подтверждение".

А.2.4 Формат КУ "Сброс" приведен в таблице А.7. После получения данной команды АРМ оповещения переходит в дежурный режим и готово воспринимать СО, КУ, КС, СС нового сеанса оповещения.

А.2.5 Формат КС "Автоматическое подтверждение" (АП) приведен в таблице А.8. Квитанция АП формируется АРМ оповещения автоматически в ответ на каждую принятую КУ. Отсутствие КС сигнализирует о неисправности или недоступности АРМ оповещения. Время формирования и отправки КС АП не должно превышать 2 с.

А.2.6 Формат КС "Ручное подтверждение" (РП) приведен в таблице А.9. КС РП формируется вручную дежурным диспетчером АРМ оповещения. КС сигнализирует о приеме СО дежурным диспетчером АРМ оповещения. КС РП отправляется между КУ "Окончание сеанса" и СС "Сброс".

А.3.1 Обработка СО с ретрансляцией имеет следующие фазы:

- прием КУ "Подготовка оповещения с ретрансляцией" и отображение ее на экране;

- прием списка оповещаемых абонентов;

- подтверждение приема КС "Список принят";

- прием КУ "Начало сеанса";

- запуск СО для выбранных абонентов;

- прием и ретрансляция текстового и звукового оповещения (при наличии);

- прием и ретрансляция КУ "Конец сеанса";

- ретрансляция КС;

- прием и ретрансляция СС "Сброс" и переход в дежурный режим.

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

А.3.2 Формат КУ "Подготовка оповещения с ретрансляцией" приведен в таблице А.10. КУ сопровождается списком вызываемых абонентов. Режим передачи СО абонентам может быть избирательным, групповым и циркулярным. При индивидуальной адресации каждому абоненту соответствует свой пакет данных, содержащий его IP-адрес и номер в устройстве управления. При групповой адресации каждой группе соответствует пакет данных, содержащих номер вызываемой группы. Необходимым условием для использования групповой адресации является согласованность баз данных АРМ оповещения. При циркулярной адресации выбираются все абоненты, подчиненные данному АРМ оповещения. Передача списка абонентов завершается КУ "Запуск оповещения с ретрансляцией".

А.3.3 Форматы КУ "Список абонентов" для индивидуальной (избирательной) адресации, групповой адресации и циркулярной адресации приведены в таблицах А.11, А.12 и А.13 соответственно.

А.3.4 Формат КУ "Запуск сеанса оповещения с ретрансляцией" представлен в таблице А.14.

Формат КУ (таблица А.14) может сопровождаться звуковым и текстовым оповещением аналогично А.2 приложения А.

А.3.5 Формат КС "Список принят" приведен в таблице А.15. Если принятый список не соответствует переданному списку с АРМ оповещения, то АРМ оповещения верхнего уровня должен послать КУ "Сброс" и повторить передачу списка, начиная с КУ "Подготовка оповещения с ретрансляцией". Подсчет элементов списка начинается с единицы.

А.3.6 Сеанс оповещения с ретрансляцией заканчивается по КУ "Окончание сеанса с ретрансляцией", формат команды приведен в таблице А.16.

После КУ "Окончание сеанса с ретрансляцией" АРМ оповещения переходит в режим ожидания КУ "Сброс". Ожидая КУ "Сброс", АРМ оповещения принимает КС от подчиненных ТСО, преобразует их в формат, представленный в таблице А.17, передает их на АРМ оповещения, инициировавшее сеанс.

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

Получив КУ "Сброс", АРМ оповещения переходит в дежурный режим.

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

А.4.1 В случае, когда АРМ оповещения инициирует запуск сеанса оповещения нижестоящего АРМ оповещения, оно информирует нижестоящий АРМ о задействовании подчиненных ему ТСО.

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

Графы состояний АРМ оповещения в режиме "Информирование о запуске ТСО" приведены на рисунке А.3.

А.4.2 Формат КУ о подготовке запуска подчиненных ТСО приведен в таблице А.18.

После КУ о подготовке запуска подчиненных ТСО следует список ТСО в формате, представленном в таблицах А.11, А.12 и А.13 в зависимости от выбранного режима адресации. Передача списка завершается КУ "Запуск подчиненных ТСО", формат которой представлен в таблице А.19.

В ответ на КУ "Запуск подчиненных устройств" АРМ оповещения дает КС "Список принят", представленную в таблице А.15. Если запуск подчиненных ТСО сопровождается звуковым или текстовым сообщением, они передаются на подчиненное АРМ оповещения после того, как от него будет получена квитанция "Список принят". Форматы звуковых и текстовых сообщений не отличаются от описанных выше для режимов входящего оповещения и оповещения с ретрансляцией.

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

А.4.4 АРМ оповещения, получившее КУ о запуске подчиненных ему ТСО, переходит в режим накопления квитанций и находится в данном режиме до получения КУ "Сброс".

А.5.1 Работа АРМ в режиме исходящего оповещения разбита на следующие фазы:

- подготовка сеанса оповещения;

- передача КУ "Начало сеанса";

- ожидание КС "Автоматическое подтверждение";

- передача СО;

- выдержка временного интервала (длительность сеанса не превышает 4 мин);

- отправка КУ "Конец сеанса";

- ожидание КС "Подтверждение оконечным устройством";

- отправка КУ "Сброс" и переход в дежурный режим.

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

А.5.2 Формат КУ исходящего оповещения для АРМ оповещения представлен в таблице А.20. В зависимости от типа оконечного устройства данная команда может сопровождаться звуковым и текстовым сообщением, аналогично описанной выше команде "Входящее оповещение без ретрансляции". Передача текстовой и (или) звуковой информации начинается после получения квитанции АП от оконечных устройств. Те устройства, которые не подтвердили прием КУ "Начало сеанса", исключаются из списка абонентов, которым должна быть передана текстовая и (или) звуковая информация. Время ожидания КС АП после передачи КУ "Начало сеанса" не должно превышать 30 с.

А.5.3 Формат КС от ОУ представлен в таблице А.21. КС формируются устройством управления в зависимости от состояния ОУ и успешности сеанса оповещения. Устройство управления может передавать КС с момента подтверждения команды "начало сеанса" и до момента получения команды "Сброс".

А.5.4 Формат КУ "Окончание сеанса" приведен в таблице А.22. После передачи данной команды АРМ оповещения переходит в фазу накопления КС подтверждения.

А.5.5 Формат КУ "Сброс" приведен в таблице А.23, после передачи которой АРМ оповещения переходит в дежурный режим.

В процессе функционирования АРМ оповещения может возникнуть ситуация, когда необходимо передать управление с АРМ оповещения первого приоритета резервному или запасному. На одном уровне может находиться более трех АРМ оповещения, в каждый момент времени один АРМ оповещения - первого приоритета. Каждое АРМ оповещения имеет свой номер, который задается в настройках АРМ. В настройках задаются адреса и номера всех АРМ оповещения одного уровня управления. Формат СС "Передача управления" приведен в таблице А.24.

АРМ оповещения, получивший СС "Передаю управление", отвечает СС "Управление принял" (таблица А.25) и передает остальным АРМ оповещения своего уровня СС "Управление принял" (таблица А.26).

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

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

Взяв на себя управление, ведущий АРМ оповещения посылает соседним в кластере (уровне управления) АРМ оповещения КС "Управление принял" (таблица А.26), на которую они отвечают автоматическим подтверждением (таблица А.8).

Одной из функций ведущего АРМ оповещения является поддержание точного хода часов реального времени в своем сегменте оповещения. Для этих целей служат команды установки времени (даты), представленные в таблицах А.29 и А.30, на которые все АРМ оповещения и устройства управления отвечают квитанцией подтверждения установки времени (даты). Если в АРМ оповещения и (или) устройствах управления отсутствуют часы реального времени, то квитанции принимают вид, представленный в таблицах А.31 и А.32.

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

Б.1 В процессе функционирования устройство управления должно вести информационный обмен по направлениям:

- входящее оповещение. Поступающая от АРМ оповещения КУ адресована данному устройству, сопровождается речевым и (или) текстовым сообщением. Требует ответных АП КС и подтверждения ОУ;

- КС на входящее оповещение. КС АП формируется ТСО автоматически в ответ на КУ и сигнализирует об исправности ТСО и корректной работе программного обеспечения устройства управления. Сигнал КС формируется по результатам запуска ОУ и сигнализирует о том, что ОУ, управляемое устройством управления, штатно функционирует;

- СО звуковой или текстовый для воспроизведения или отображения ОУ;

- СС - запросы состояния оборудования, проверочные команды, команды установки часов реального времени, зондирующие пакеты;

- НС (аварийные сигналы).

Взаимодействие устройства управления с АРМ оповещения должно реализовываться по технологии клиент-сервер.

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

В режиме передачи НС инициатором обмена является устройство управления, АРМ оповещения находится в режиме сервера, а устройство управления - в режиме клиента. Для передачи НС используется отдельное TCP соединение (сокет).

Графы состояний устройства управления приведены на рисунке Б.1.

Б.2 Входящее оповещение. Переход устройства управления из дежурного режима в рабочий режим происходит по КУ "Входящее оповещение", формат которой приведен в таблице Б.1.

Каждое ОУ получает свою КУ "Запуск", если номер абонента - 0xFF, команда предназначена всем абонентам. Номера команд для различных ОУ в одном сеансе оповещения могут отличаться. Номера команд с 1 по 6 зарезервированы для совместимости с аппаратурой старого парка и не рекомендованы для использования, остальные КУ могут быть использованы без ограничений. Список команд приведен в таблице Б.2.

Получив КУ "Входящее оповещение", устройство управления подтверждает ее квитанцией АП, представленной в таблице Б.3, и приводит в действие ОУ, которому направлена команда оповещения.

После передачи квитанции АП и приведения в действие ОУ устройство управления контролирует результат работы ОУ и в зависимости от результата формирует либо КС "Запуск успешен", либо КС "Сбой запуска", формат которой представлен в таблице Б.4.

В зависимости от типа ОУ время формирования и передачи КС может отличаться, однако, независимо от результатов сеанса, устройство управления по КУ "Окончание сеанса" обязано передать КС подтверждения ОУ. Отсутствие КС в течение таймаута, который устанавливается в АРМ оповещения, расценивается как отказ устройства управления.

Завершается сеанс получением КУ "Сброс", представленной в таблице Б.5.

КУ "Сброс" не требует подтверждения и может поступить в любой момент, как в течение сеанса, так и в дежурном режиме. По КУ "Сброс" устройство управления переходит в дежурный режим.

Б.3.1 Формат звукового сообщения. КУ входящего оповещения может сопровождаться звуковым сообщением длительностью не более трех минут. Воспроизведение звукового сообщения начинается после получения КУ "Старт звукового сообщения", таблица Б.6.

Остановка воспроизведения звукового сообщения происходит по КУ "Остановка звукового сообщения" (таблица Б.7).

Запуск и остановка звукового сообщения в течение сеанса оповещения может происходить произвольное количество раз. Прием КУ "Старт звукового сообщения" устройство управления подтверждает квитанцией АП, КУ "Остановка звукового сообщения" КС не подтверждается.

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

Б.3.2 Формат текстового сообщения приведен в таблице Б.9.

Прием текстового сообщения подтверждается КС АП. Если устройство управления не обрабатывает текстовую информацию, КС принимает вид, представленный в таблице Б.10, а текстовая информация игнорируется.

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

Получив СС "Проверка без включения оконечных устройств", устройство управления производит тестирование ТСО настолько полно, насколько это возможно без включения ОУ. Произведя проверку, устройство управления отвечает СС. Если при выборе всех абонентов хотя бы один из них не пройдет тестирование, СС "Квитанция проверка без включения оконечных устройств" должна быть отрицательной.

Формат проверки ТСО с кратковременным включением ОУ в рабочий режим представлен в таблице Б.12 и применяется там, где допустимо кратковременное включение ОУ в рабочий режим. При получении данного СС устройство управления активизирует алгоритм автономной проверки ОУ. Длительность и методика проверки зависят от типа ОУ.

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

Использование того или другого метода проверки определяется настройками АРМ оповещения.

СС "Запрос состояния" представлен в таблице Б.13. Получив команду, устройство управления отправляет квитанцию, представленную в таблице Б.14. Целью данной команды является получение информации о состоянии входных и выходных цепей и сигналов устройства управления. Команда относится к устройству управления целиком и не имеет адресации абонентов и (или) оконечных устройств.

При получении СС "Запрос состояния", в ответной квитанции необходимо сообщить о состоянии входных дискретных сигналов (датчиков) и выходных дискретных сигналов в позиционном коде. Всего может быть опрошено до 16 входных и до 16 выходных сигналов. Активное состояние входа/выхода устройства кодируется "1", неактивное "0". Отсутствующие входы/выходы кодируются "0".

СС "Запрос типа и ID-устройства". С целью диагностики и автоматизации конфигурирования подчиненных устройств АРМ может запросить у устройства его тип и идентификационный номер. Данные параметры присваиваются производителем и не могут быть изменены в процессе эксплуатации. Формат СС представлен в таблице Б.15.

Получив СС "Запрос типа и ID-устройства", устройство управления отвечает СС "Квитанция типа и ID-устройства", формат которой представлен в таблице Б.16.

Данной квитанцией устройство управления сообщает тип поддерживаемого ОУ. Если ОУ поддерживает несколько типов ТСО, коды типов ТСО складываются по схеме "или" и помещаются в третий байт квитанции. Идентификационный номер ТСО помещается в байты с 4 по 7. Если номер ТСО занимает менее четырех байт, номер дополняется до четырех байт незначащими нулями.

Б.4.2 За синхронизацию часов реального времени отвечает АРМ оповещения, имеющий приоритет в системе оповещения. Он посылает СС установки времени (даты), представленные в таблице Б.17 и Б.18. На СС установки устройства управления отвечают квитанцией подтверждения установки времени (даты), таблицы Б.19 и Б.20. Если в устройствах отсутствуют часы реального времени, то квитанция принимает вид, представленный в таблицах Б.21 и Б.22.

Б.4.3 Зондирующие пакеты. Для определения доступности (исправности) ТСО используются зонд-пакеты, которыми устройства управления периодически обмениваются с АРМ оповещения. Зонд-пакеты представляют собой восьмибайтовые пакеты и содержат только сигнатуру ЕП. Для пакета запроса используется сигнатура команд, а для ответного пакета используется сигнатура квитанций. Остальные байты зонд-пакета равны нулю. Ответный пакет не является обязательным. Определение доступности ТСО может определяться по факту доставки зонд-пакета на уровне TCP-протокола.

Б.4.4 НС должны передаваться от устройства управления на АРМ оповещения своего уровня подчиненности. Формат НС представлен в таблице Б.23.

НС посылается на каждое изменение состояния датчиков отдельно для каждого датчика. Список датчиков (событий) и рекомендуемые номера для них приведены в таблице Б.24.

АРМ оповещения формирует и отправляет КУ на СЭВ, сервер которой осуществляет верификацию входящих КУ АРМ оповещения и трансляцию в КУ СЦНЭТВ.

Схема взаимодействия АРМ оповещения и СЭВ приведена на рисунке В.1.

В.2.1 АРМ оповещения формирует СО, КУ, КС, СС и передает на СЭВ, сервер которой осуществляет верификацию входящих КУ АРМ оповещения и трансляцию в КУ СЦНЭТВ. На рисунке В.2 приведена схема взаимодействия АРМ оповещения с СЭВ для управления оконечными средствами звукового, речевого и персонального оповещения по СЦНЭТВ.

В.2.2.1 Формат команд и сообщений, MESSAGE ()

КУ должны передаваться в формате XML, быть подписаны в соответствии с [5] и [6].

Результат подписи передается в теге /Signature/SignedInfo/Reference/DigestValue в формате base64. Подписанные данные (КУ либо КС в формате XML) - в теге /Signature/Object.

Отклики СЭВ (КС, СС) на КУ должны подписываться цифровой подписью и передаться в незашифрованном виде.

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

В.2.2.2 Формат XML-команд

Команды в формате XML размещаются внутри тега /Signature/Object.

Список поддерживаемых команд приведен в таблице В.1.

В.2.3.1 server_alive - служебное сообщение, которое используется для проверки соединения с сервером. В ответ на команду формируется стандартный отклик response.

<command type="server_alive" id="11A775EB-9EE8-4575-A76A-DA283586FA69" />

* Command@type - string, тип команды.

* Command@id - UUID, уникальный идентификатор команды. Используется для определения уникальности команды и идентификации отклика response.

В.2.3.2 regional_emergency_slot - команда, которая включает или отключает режим врезки в эфир заранее записанного ролика из коллекции сервера врезки. Ролик циклически проигрывается до тех пор, пока не придет команда на отключение режима врезки.

<command type="regional_emergency_slot" id="C6A89F7B-FEFB-4C3A-BCD9-4492BE5CAEF4" slot_no="123" state="on"/>

* Command@type - string, тип команды.

* Command@id - UUID, уникальный идентификатор команды. Используется для определения уникальности команды и идентификации отклика response.

* Command@slot_no - integer, номер позиции в расписании вещательного сервера врезки с заранее записанным роликом, который хранится в файловой системе сервера врезки.

* Command/@state - string, значение из списка {"on", "off"}, включает (on)/отключает (off) режим врезки.

В.2.3.3 regional_emergency_live - команда, которая включает режим замещения эфирного сигнала live-трансляцией (SDI/ASI/MPEG2-TS) от серверов оповещения МЧС России. Параметры приема live-трансляции должны быть предварительно сконфигурированы на вещательном сервере.

<command type="regional_emergency_live" id="E0CDCF3E-0377-4245-80C7-C96D0F85B9ED" state="on" flash="off"/>

* Command/@type - string, тип команды.

* Command@id - UUID, уникальный идентификатор команды. Используется для определения уникальности команды и идентификации отклика response.

* Command/@type - string, тип команды.

* Command/@id - UUID, уникальный идентификатор команды. Используется для идентификации отклика response.

* Command/@state - string, значение из списка {"on", "off"}, включает (on)/отключает (off) режим врезки.

* Command/@flash - string, значение из списка {"on", "off"}, включает (on)/отключает (off) режим трансляции сигнала сирены на оконечном средстве оповещения.

В.2.3.4 local_emergency_slot - команда, которая включает режим вещания заранее записанного ролика с помощью устройства оповещения.

Команда позволяет передавать как индивидуальные, так и групповые сообщения.

<command type="local_emergency_slot" id="62D19F7B-68DB-48DF-B90C-C0182F6E6E7B " group_id="1"> <devices> <device id="1" slot_no="1" state="on"/> <device id="10" slot_no="11" state="on" /> <device id="111" slot_no="27" state="on" /> </devices> </command>

* Command/@type - string, тип команды.

* Command@id - UUID, уникальный идентификатор команды. Используется для определения уникальности команды и идентификации отклика response.

* Command/@group_id - задает номер группы. Адрес 0 зарезервирован под широковещательную рассылку на все группы.

* Command/devices/device/@id - integer, индивидуальный адрес устройства. Адрес 0 зарезервирован под групповую рассылку на все устройства группы.

* Command/devices/device/@slot_no - integer [0..31], номер ролика, который должен воспроизводится на устройстве оповещения. Ролики хранятся на устройстве оповещения.

* Command/devices/device/@state - string, значение из списка {"on", "off"}, включает (on)/отключает (off) режим оповещения.

В.2.3.5 local_emergency_alarm - команда, которая включает сирену на устройстве оповещения. Команда позволяет активировать сирену как индивидуально, так и на группе устройств.

<command type="local_emergency_alarm" id="32B9D69D-AC6A-46ED-9645-3AEB68B2871F" group_id="2"> <devices> <device id="1" state="on" /> <device id="10" state="on"/> <device id="111" state="on" /> </devices> </command>

* Command/@type - string, тип команды.

* Command/@id - UUID, уникальный идентификатор команды. Используется для идентификации отклика response.

* Command/@group_id - задает номер группы. Адрес 0 зарезервирован под широковещательную рассылку на все группы.

* Command/devices/device/@id - integer, индивидуальный адрес устройства. Адрес 0 зарезервирован под групповую рассылку на все устройства группы.

* Command/devices/device/@state - string, значение из списка {"on", "off"}, активирует (on)/деактивирует (off) сирену.

В.2.3.6 emergency_message - команда, которая активирует передачу сообщения для приемников персонального вызова.

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

<command type=" emergency_message" id="C940BC87-BBCC-4A49-A58F-97F86DE7C83B" group_id="1" message="COCHA"> <devices> <device id="1" state="on"/ > <device id="10" state="on" /> <device id="111" state="off" /> <device id="12" state="auto" timeout="600"/> </devices>

* Command/@type - string, тип команды. Устанавливается в значение "emergency_message".

* Command/@id - UUID, уникальный идентификатор команды. Используется для идентификации отклика response.

* Command/@group_id - integer, задает номер группы. Адрес 0 зарезервирован под широковещательную рассылку на все группы.

* Command/@message - string, текстовое сообщение, которое необходимо передать.

* Command/devices/device/@id - integer, индивидуальный адрес устройства. Адрес 0 зарезервирован под групповую рассылку на все устройства группы.

* Command/devices/device/@state - string, значение из списка {"on", "off", "auto"}, активирует (on)/деактивирует (off) передачу сообщения, в режиме "auto" активируется передача активируется, и затем автоматически деактивируется через заданный в поле @timeout интервал времени.

* Command/devices/device/@timeout - integer, интервал времени в секундах, определяющий длительность трансляции сообщения. Используется только в случае, если поле @state установлено в значение "auto".

В.2.4 response - формат отклика вещательного сервера на управляющую команду АРМ оповещения.

<response id=" 5E9F02EF-33D7-4D47-A36E-F7D81C219F9B" command_id="C940BC87-BBCC-4A49-A58F-97F86DE7C83B" result="error" error_code="401" timestamp="2021">Ошибка проверки цифровой подписи.</response>

* Response/@id - UUID, уникальный идентификатор отклика.

* Response/@command_id - UUID, идентификатор команды, на которую отправляется отклик.

* Response/@result - string, значение из перечисления {"error", "success"}. Признак успешности исполнения команды.

* Response/@error_code - integer, код ошибки.

* Response/text() - расшифровка ошибки в текстовом виде.

<Signature xmlns="/template/go.php?url=https://www.w3.org/2000/09/xmldsig#">

<SignedInfo> <CanonicalizationMethod Algorithm="/template/go.php?url=https://www.w3.org/TR/2001/REC-xml-c14n-20010315" />

<SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256" />

<Reference>

<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/><DigestValue>MIIDxwYJKoZlhvcNAQcCollDuDCCA7QCAQExDjAMBggqhQMHAQECAgUAMBcGCSqGSIb3DQEHAaAKBAgxMjM0NTY3OKCApQwggKQMIICPaADAgECAgkAk3jvnAfBKVowCgYIKoUDBwEBAwlweTELMAkGA1UEBhMCUIUxDzANBgNVBAgMIJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQWt0aXYtU29mdDEQMA4GA1UECwwHUn0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QwHhcNMjEwNjE3MDk0Nzl0WhcNMjlwNjE3MD0NI0WjA9MRcwFQYDVQQDDA5renRhLXAxNjYtdGVzdDELMAkGA1UEBhMCUIUxFTATBgNVBAgMDNCa0LDQu9GD0LPQsDBmMB8GCCqFAwcBAQEBMBMGByqFAwlClwEGCCqFAwcBAQICA0MABECrAVPmqxnb6zmVixnZ7DWhpv1/IWtqOP9dOs0qwcSaJW/x2dhmrEK7KGclWVeSzSFik/s+4zqAX4b4w4kXt1oo4HcMIHZMAsGA1UdDwQEAwIHgDATBgNVHSAEDDAKMAgGBiqFA2RxATAvBgUqhQNkbwQmDCTQodCa0JfQmCAi0KDRg9GC0L7QutC10L0g0K3QptCflDluMCIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3JhLnJ1dG9rZW4ucnUvcm9vdF9jZXJ0cy9nb3N0LmNybDBJBggrBgEFBQcBAQQ9MDswOQYIKwYBBQUHMAKGLWh0dHA6Ly9yYS5ydXRva2VuLnJ1L3Jvb3RfY2VydHMvY2FHb3N0MjU2LmNydDAKBggqhQMHAQEDAgNBALPti+JziS68VpuC/pWp2ioEvcaJ2ltPUe3z5t6y/aGLLbZhYfN/xUwpk90ssKA6Por5BqNndVOMc9UZIIh2eWMxge0wgeoCAQEwgYYweTELMAkGA1UEBhMCUlUxDzANBgNVBAgMBIJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQWt0aXYtU29mdDEQMA4GA1UECwwHUnV0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QCCQCTeO+cB8EpWjAMBggqhQMHAQECAgUAMAwGCCqFAwcBAQEBBQAEQKKC8C7B/kBiOOI7VL6SkjTywidB7cmn1MSVHFS+pGDSyPfnp3Qz5rY13psX4mF7RSn0qjtZ7+uBTCELvDjaRhc=</DigestValue> </Reference> </SignedInfo>

<SignatureValue>MIIDxwYJKoZlhvcNAQcCollDuDCCA7QCAQExDjAMBggqhQMHAQECAgUAMBcGCSqGSIb3DQEHAaAKBAgxMjM0NTY3OKCCApQwggKQMIICPaADAgECAgkAk3jvnAfBKVowCgYIKoUDBwEBAwlweTELMAkGA1UEBhMCUIUxDzANBgNVBAgMBIJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQWt0aXYtU29mdDEQMA4GA1UECwwHUnV0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QwHhcNMjEwNjE3MDk0Nzl0WhcNMjlwNjE3MDk0Nzl0WjA9MRcwFQYDVQQDDA5renRhLXAxNjYtdGVzdDELMAkGA1UEBhMCUIUxFTATBgNVBAgMDNCa0LDQu9GD0LPQsDBmMB8GCCqFAwcBAQEBMBMGByqFAwlClwEGCCqFAwcBAQICA0MABECrAVPmqxnb6zmVixnZ7DWhpv1/IWtqOP9dOs0qwcSaJW/x2dhmrEK7KGclWVeSzSFik/s+4zqAX4b4vv4kXt1oo4HcMIHZMAsGA1UdDwQEAwlHgDATBgNVHSAEDDAKMAgGBiqFA2RxATAvBgUqhQNkbwQmDCTQodCa0JfQmCAi0KDRg9GC0L7QutC10L0g0K3QptCflDluMCIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3JhLnJ1dG9rZW4ucnUvcm9vdF9jZXJ0cy9nb3N0LmNybDBJBggrBgEFBQcBAQQ9MDswOQYIKwYBBQUHMAKGLWh0dHA6Ly9yYS5ydXRva2VuLnJ1L3Jvb3RfY2VydHMvY2FHb3N0MjU2LmNydDAKBggqhQMHAQEDAgNBALPti+JziS68VpuC/pWp2ioEvcaJ2ltPUe3z5t6y/aGLLbZhYfN/xUwpk90ssKA6Por5BqNndVOMc9UZIIh2eWMxge0wgeoCAQEwgYYweTELMAkA1UEBhMCUlUxDzANBgNVBAgMBIJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQWt0aXYtU29mdDEQMA4GA1UECwwHUnV0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QCCQCTeO+cB8EpWjAMBggqhQMHAQECAgUAMAwGCCqFAwcBAQEBBQAEQKKC8C7B/kBiOOI7VL6SkjTywidB7cmn1MSVHFS+pGDSyPfnp3Qz5rY13psX4mF7RSn0qjtZ7+uBTCELvDjaRhc=</SignatureValue>

<Object Id="ac796d69-9cb1-4db7-ba21-0b01809c9d68" MimeType="application/xml" Encoding="windows-1251"> <command xmlns="" type="emergency_message" id="{9f651a0e-7d53-4916-b9a2-5ecf1be3c669}" message="Техническая Проверка Доставки Сообщения Населению" group_id="2"> <devices> <device id="165" state="auto" timeout="60"/> </devices> </command> </Object> </Signature>