ГОСТ Р 42.3.05-2023 Гражданская оборона. Технические средства оповещения населения. Протоколы информационного обмена. Общие требования

        ГОСТ Р 42.3.05-2023

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

Гражданская оборона

ТЕХНИЧЕСКИЕ СРЕДСТВА ОПОВЕЩЕНИЯ НАСЕЛЕНИЯ

Протоколы информационного обмена. Общие требования

Civil defense. Technical means of public notification. Information exchange protocols. General requirements

ОКС 13.200

Дата введения 2023-06-01

Предисловие

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

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

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

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящем стандарте использованы термины по ГОСТ Р 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 автоматизированная система оповещения должностных лиц; АСО: Система (средство) оповещения должностных лиц (дежурных служб органов управления) в автоматизированном (автоматическом) режиме по сетям местной (междугородной, подвижной) телефонной связи (ведомственным сетям телефонной связи) на пользовательское оборудование (оконечное оборудование) путем отбора абонентской линии (автоматического дозвона на абонентский номер) и передачи аудиосообщения (аудиовизуального, короткого текстового сообщения).

4 Сокращения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Общие требования

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 Требования к сигналам оповещения

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

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

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

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

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

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

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

- групповой;

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

5.9.3 Формат СО

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.

Таблица 1 - Формат передачи видеосообщения (видеоконтент) для технических средства видеоотображения информации оповещения

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

5.10 Требования к сигналам и командам, поддерживаемым в ТСО для управления оконечными устройствами оповещения звукового, речевого и видеооповещения

5.10.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 Требования к квитирующему сигналу

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

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

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

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

5.10.3 Требования к сервисному (служебному) сигналу

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

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

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

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

- "Сбой";

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

5.10.4 Требования к незапрашиваемому сигналу

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

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

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

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

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

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

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

5.11 Требования к сигналам и командам, поддерживаемым в СЦНЭТВ

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

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

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

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

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

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

Таблица 2 - Формат посылки КУ

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

5.12 Режимы функционирования ТСО

5.12.1 Дежурный режим

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

5.12.2 Рабочий режим

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

5.13 Требования к алгоритму задействования и адресации

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 Информационное взаимодействие системы оповещения населения со сторонними взаимодействующими автоматизированными и информационными системами

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

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

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

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

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

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

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

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

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

6 Особенности организации информационного обмена по сети цифрового наземного эфирного телерадиовещания

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 - Перечень КУ и КС АРМ оповещения

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

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

А.2 Форматы КУ, КС в режиме "Входящее оповещение" для АРМ оповещения

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

Таблица А.2 - Формат КУ входящего оповещения для АРМ оповещения

А.2.1 Формат звукового сообщения

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

Таблица А.3 - Формат КУ "Старт звукового сообщения"

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

Таблица А.4 - Формат КУ "Остановка звукового сообщения"

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

А.2.2 Порядок байт для кодировки текстового сообщения UTF-16LE

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

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

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

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

Таблица А.6 - Формат КУ "Конец сеанса"

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

Таблица А.7 - Формат КУ "Сброс"

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

Таблица А.8 - Формат КС "Автоматическое подтверждение"

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

Таблица А.9 - Формат КС "Ручное подтверждение"

A.3 Входящее оповещение с ретрансляцией

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица А.10 - Формат КУ "Подготовка оповещения с ретрансляцией"

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

Таблица А.11 - Формат КУ "Список абонентов" для индивидуальной (избирательной) адресации

Таблица А.12 - Формат КУ "Список абонентов" для групповой адресации

Таблица А.13 - Формат КУ "Список абонентов" для циркулярной адресации

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

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

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

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

Таблица А.15 - Формат КС "Список принят"

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

Таблица А.16 - Формат КУ "Окончание сеанса с ретрансляцией"

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

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

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

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

Таблица А.17 - Формат КС для СО с ретрансляцией

А.4 КС о запуске ТСО

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

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

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

Рисунок А.3 - Графы состояний для режима КУ о запуске ТСО

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

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

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

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

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

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

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

А.5 Исходящее оповещение

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

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

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

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

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

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

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

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

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

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

Рисунок А.4 - Графы состояний для режима "Исходящее оповещение"

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

Таблица А.20 - Формат КУ исходящего оповещения для АРМ оповещения

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

Таблица А.21 - Формат КС от ОУ

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

Таблица А.22 - Формат КУ "Окончание сеанса"

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

Таблица А.23 - Формат КУ "Сброс"

А.6 Сервисные (служебные) сигналы

А.6.1 СС "Передача управления"

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

Таблица А.24 - Формат СС "Передача управления"

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

Таблица А.25 - Формат СС "Передаю управление"

Таблица А.26 - Формат СС "Управление принял"

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

Таблица А.27 - Формат СС "Беру управление"

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

Таблица А.28 - Формат КС "Передаю управление"

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

А.6.2 СС установки времени

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

Таблица А.29 - Формат СС установки времени

Таблица А.30 - Формат СС установки дату

Таблица А.31 - Формат квитанции СС "Установка времени"

Таблица А.32 - Формат квитанции СС "Установка даты"

А.6.3 Зондирующие пакеты

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

Приложение Б

(обязательное)

Протокол информационного обмена между АРМ оповещения и устройством управления

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

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

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

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

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

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

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

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

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

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

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

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

Таблица Б.1 - Формат КУ "Входящее оповещение"

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

Таблица Б.2 - Список КУ для оконечных средств оповещения

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

Таблица Б.3 - Формат КС автоматического подтверждения для АРМ оповещения

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

Таблица Б.4 - Формат КС "Подтверждение оконечным устройством"

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

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

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

Таблица Б.5 - Формат КУ "Сброс"

Б.3 Передача СО от АРМ оповещения к устройству управления

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

Таблица Б.6 - Формат КУ "Старт звукового сообщения"

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

Таблица Б.7 - Формат КУ "Остановка звукового сообщения"

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

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

Таблица Б.8 - Формат КС "Команда не поддерживается"

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

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

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

Таблица Б.10 - Формат КС "Команда не поддерживается"

Б.4 Передача СС от АРМ оповещения к устройству управления

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

Таблица Б.11 - СС "Проверка без включения оконечных устройств"

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

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

Таблица Б.12 - Формат СС "Проверка с включением оконечных устройств"

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

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

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

Таблица Б.13 - Формат СС "Запрос состояния"

Таблица Б.14 - Формат СС Квитанция "Запрос состояния"

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

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

Таблица Б.15 - Формат СС "Запрос типа и ID-устройства"

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

Таблица Б.16 - Формат СС "Квитанция типа и ID-устройства"

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

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

Таблица Б.17 - Формат СС "Установить время"

Таблица Б.18 - Формат СС "Установить дату"

Таблица Б.19 - Формат СС "Установка времени"

Таблица Б.20 - Формат СС "Установка даты"

Таблица Б.21 - Формат квитанции СС "Установка времени"

Таблица Б.22 - Формат квитанции СС "Установка даты"

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

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

Таблица Б.23 - Формат НС

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

Таблица Б.24 - Список датчиков (событий) и рекомендуемые номера для датчиков

Приложение В

(обязательное)

Протокол информационного обмена АРМ оповещения и сети цифрового наземного эфирного телерадиовещания

В.1 Информационный обмен АРМ оповещения и СЦНЭТВ для передачи видеосообщения

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

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

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

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

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

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

В.2.2 Описание структуры КУ, КС, СС

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

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

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

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

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

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

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

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

Таблица В.1 - Список поддерживаемых КУ

В.2.3 Описание команд

В.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)/отключает (of) режим врезки.

В.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"V > <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)/отключает (of) режим оповещения.

В.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)/деактивирует (of) сирену.

В.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)/деактивирует (of) передачу сообщения, в режиме "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() - расшифровка ошибки в текстовом виде.

Приложение Г

(справочное)

Пример формирования XML-пакетов

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo> <CanonicalizationMethod Algorithm="http://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>MIIDx

wYJKoZIhvcNAQcCoIIDuDCCA7QCAQExDjAMBggqhQMHAQECAgUAMBcGCSqGSIb3DQEHAaAKBAgxMjM0NTY3OK

CApQwggKQMIICPaADAgECAgkAk3jvnAfBKVowCgYIKoUDBwEBAwIweTELMAkGA1UEBhMCUlUxDzANBgNVBAgM

lJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQWt0aXYtU29mdDEQMA4GA1UECw

wHUn0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QwHhcNMjEwNjE3MDk0NzI0WhcNMjIwNjE3MD0N

I0WjA9MRcwFQYDVQQDDA5renRhLXAxNjYtdGVzdDELMAkGA1UEBhMCUlUxFTATBgNVBAgMDNCa0LDQu9G

D0LPQsDBmMB8GCCqFAwcBAQEBMBMGByqFAwICIwEGCCqFAwcBAQICA0MABECrAVPmqxnb6zmVixnZ7DWhpv1/

lWtqOP9dOs0qwcSaJW/x2dhmrEK7KGcIWVeSzSFik/s+4zqAX4b4vv4kXt1oo4HcMIHZMAsGA1UdDwQEAwIHgDATB

gNVHSAEDDAKMAgGBiqFA2RxATAvBgUqhQNkbwQmDCTQodCa0JfQmCAi0KDRg9GC0L7QutC10L0g0K3QptC

fIDIuMCIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3JhLnJ1dG9rZW4ucnUvcm9vdF9jZXJ0cy9nb3N0LmNybD

BJBggrBgEFBQcBAQQ9MDswOQYIKwYBBQUHMAKGLWh0dHA6Ly9yYS5ydXRva2VuLnJ1L3Jvb3RfY2VydHMvY

2FHb3N0MjU2LmNydDAKBggqhQMHAQEDAgNBALPti+JziS68VpuC/pWp2ioEvcaJ2ltPUe3z5t6y/aGLLbZhYfN/xUw

pk90ssKA6Por5BqNndVOMc9UZllh2eWMxge0wgeoCAQEwgYYweTELMAkGA1UEBhMCUlUxDzANBgNVBAgM

BlJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQWt0aXYtU29mdDEQMA4GA1UECw

wHUnV0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QCCQCTeO+cB8EpWjAMBggqhQMHAQECAgUA

MAwGCCqFAwcBAQEBBQAEQKKC8C7B/kBiOOl7VL6SkjTywidB7cmn1MSVHFS+pGDSyPfnp3Qz5rY13psX4mF7RS

n0qjtZ7+uBTCELvDjaRhc=</DigestValue> </Reference> </SignedInfo>

<SignatureValue>MIIDxwYJKoZIhvcNAQcCoIIDuDCCA7QCAQExDjAMBggqhQMHAQECAgUAMBcGCSqGSIb

3DQEHAaAKBAgxMjM0NTY3OKCCApQwggKQMIICPaADAgECAgkAk3jvnAfBKVowCgYIKoUDBwEBAwIweTELMAk

GA1UEBhMCUlUxDzANBgNVBAgMBlJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQ

Wt0aXYtU29mdDEQMA4GA1UECwwHUnV0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QwHhcNM

jEwNjE3MDk0NzI0WhcNMjIwNjE3MDk0NzI0WjA9MRcwFQYDVQQDDA5renRhLXAxNjYtdGVzdDELMAkGA1UE

BhMCUlUxFTATBgNVBAgMDNCa0LDQu9GD0LPQsDBmMB8GCCqFAwcBAQEBMBMGByqFAwICIwEGCCqFAwcB

AQICA0MABECrAVPmqxnb6zmVixnZ7DWhpv1/lWtqOP9dOs0qwcSaJW/x2dhmrEK7KGcIWVeSzSFik/s+4zqAX4b4v

v4kXt1oo4HcMIHZMAsGA1UdDwQEAwIHgDATBgNVHSAEDDAKMAgGBiqFA2RxATAvBgUqhQNkbwQmDCTQodCa

0JfQmCAi0KDRg9GC0L7QutC10L0g0K3QptCfIDIuMCIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3JhLnJ1dG9r

ZW4ucnUvcm9vdF9jZXJ0cy9nb3N0LmNybDBJBggrBgEFBQcBAQQ9MDswOQYIKwYBBQUHMAKGLWh0dHA6Ly9yY

S5ydXRva2VuLnJ1L3Jvb3RfY2VydHMvY2FHb3N0MjU2LmNydDAKBggqhQMHAQEDAgNBALPti+JziS68VpuC/pW

p2ioEvcaJ2ltPUe3z5t6y/aGLLbZhYfN/xUwpk90ssKA6Por5BqNndVOMc9UZllh2eWMxge0wgeoCAQEwgYYweTEL

MAkA1UEBhMCUlUxDzANBgNVBAgMBlJ1c3NpYTEPMA0GA1UEBwwGTW9zY293MRcwFQYDVQQKDA5aQU8gQ

Wt0aXYtU29mdDEQMA4GA1UECwwHUnV0b2tlbjEdMBsGA1UEAwwUUnV0b2tlbiBURVNUIENBIEdPU1QCCQC

TeO+cB8EpWjAMBggqhQMHAQECAgUAMAwGCCqFAwcBAQEBBQAEQKKC8C7B/kBiOOl7VL6SkjTywidB7cmn

1MSVHFS+pGDSyPfnp3Qz5rY13psX4mF7RSn0qjtZ7+uBTCELvDjaRhc=</SignatureValue>

<Object Id="ac796d69-9cb1-4db7-ba21-0b01809c9d68" MimeType="application/xml" Encoding="UTF-8"> <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>

Библиография