Идея родилась на фоне запросов больших холдингов контролировать все ЛСО своих предприятий «из головы» и региональных центров. Но данный концепт может быть применен, и даже интересен, для построения систем оповещения государства или региона.

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

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

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

Вырисовывается довольно интересная картина. Система верхнего уровня (уровень 1) «видит» только сервера подчиненного уровня (2 уровень) и сервер оповещения своего уровня (3-уровень). «Видит» их доступность и критические ошибки системы оповещения 3-го уровня. Может «провалиться» на соответствующий уровень и посмотреть как состояние серверов подчиненных систем, так и «уйти глубже» в 3-й уровень уже с отображением и контролем всех оконечных устройств.

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

Есть один нюанс: так как в системах оповещения принята и действует ролевая модель и у разных пользователей разные права доступа и управления, то необходим сервер безопасности с возможностью сквозного назначения прав доступа, как на узлы, так и на действия на них. Через этот сервер будут осуществляться и назначаться права доступа, описываться перечень критических ошибок и уровень их «подъема наверх». Более того, с использованием предлагаемой концепции можно выработать метод, по которому каждой ошибке присваивается рейтинг. На соответствующем уровне ведется учет накопления «суммарного веса» рейтингов всех действующих неисправностей и, при превышении установленного порогового значения, формируется сигнал о критической ошибке, который не только извещает оператора своего уровня о большом количестве неисправностей, но и отправляет на вышестоящий уровень информацию о таком событии.

Казалось бы, предложенная теория так и рискует остаться лишь в головах её родивших, да в лучшем случае в презентациях далекоидущих перспективных планов, которые «ложатся под сукно» сразу после их публикации, но…

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

Во-первых, операторы нижестоящего уровня, зная о том, что накопление незначительных ошибок рано или поздно отправится автоматическим рапортом «наверх», стали больше рвения проявлять в своевременном их устранении, не допуская накопления «большого количества малых дел»;
Во-вторых: у контролирующих лиц и операторов вышестоящего уровня появился объективный инструмент контроля, как за состоянием систем нижестоящего уровня, так и за своевременностью устранения возникших неисправностей. Теперь личный контакт (телефонный звонок, почта, мессенджеры) не стал единственным средством получения информации, не отвлекал и не расходовал время сразу двух специалистов на выяснение причин. Достаточно было оператору вышестоящего уровня вновь «провалиться на сервер» уровня нижестоящего, чтобы, никого не отвлекая получить объективную информацию.

Какие преимущества такой архитектуры для предприятий понятно — это сквозной контроль и управляемость. А что, если этот принцип спроецировать на муниципальный, региональный или федеральный уровень систем оповещения? Ведь на вышестоящих уровнях происходит еще более тесное переплетение интересов и зон оповещения. Технические средства оповещения КСЭОН, муниципальных и региональных уровней, локальных систем оповещения часто располагаются на одной и той же территории, и часто одни и те же ТСО участвуют в формировании, и зон оповещения ЛСО, и зон оповещения МСО, и РСО и КСЭОН. При таком тесном переплетении проведение оценки готовности к использованию по предназначению без использования средств автоматизации просто невозможно и попытки проведения оценки состояния скатываются с экспертного уровня до «пальцем в небо».

Кончено, возникает вопрос об экономической целесообразности таких инноваций. Какая может выгода в количественном выражении для объекта, а для группы объектов, для региона, например или для государства? Да в принципе, колоссальная! Повторное использование средств оповещения в системах оповещения различной балансовой принадлежности, различных уровней с установкой приоритета, например РСО и МСО позволит сэкономить значительную часть и бюджета субъекта Российской Федерации и бюджета муниципальных образований в него входящих. На уровне взаимодействия муниципальных систем и систем объектового уровня тоже самое, но еще и позволит обеспечить справедливое распределение основных финансовых затрат между организациями и муниципальными образованиями. И тут стоит задуматься, в том числе, о пересмотре концепции построения систем оповещения и реализации Приложения, А ГОСТ Р 42.3.05−2023. Почему? Потому что, на мой взгляд, за время обсуждения данного ГОСТа в повседневной деятельности, получившего имя «универсальный протокол» пока существенно продвинуться в его повсеместном внедрении, не удалось. Следовательно, дополнение его такой полезной функцией совершенно точно, назад процесс внедрения не отбросит. Как писал выше, опытные зоны уже функционируют. Да, пока вне правового поля и, так сказать, «поверх» официального протокола, прошедшего испытание с комплексом технических средств оповещения, но уже дают свои результаты. А результаты сугубо положительные! Так что делаю вывод, о том, что у данной идеи есть все шансы не лечь под сукно, а торчать из-под него постоянно напоминая о пользе, которую может принести.