«ВЕРХНИЙ УРОВЕНЬ» МФСБ

Зачем он нужен, если на него нет требований. О важности интеграций и интегратора

ПЕРЕЙТИ НА САЙТ >>

Что входит в понятие «верхнего уровня» МФСБ?

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

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

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

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

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

В структуре МФСБ целесообразно выделить две части:

  • 1. Информационная система многофункциональной системы безопасности (ИС МФСБ): совокупность информационных технологий и технических средств, обеспечивающих обработку информации, получаемой от КТС МФСБ.
  • 2. Комплекс технических средств многофункциональной системы безопасности (КТС МФСБ): комплексы технических, технологических, инженерных, информационных и иных систем, объединяемые в МФСБ, а также, дополнительные технические средства, не входящие в состав систем, но необходимые для локального сбора данных о состоянии контролируемых источников опасности.

К «верхнему уровню» МФСБ относится не все серверное оборудование с программным обеспечением, а только то, что входит в ИС МФСБ. Именно на верхнем уровне МФСБ реализуется функциональность информационно-аналитической системы.

Основными задачами верхнего уровня МФСБ угольного разреза в минимальном виде можно считать:

  • 1. обеспечение процесса дистанционного мониторинга параметров безопасности в соответствии с ФНП;
  • 2. представление информации по мониторингу параметров безопасности территориальному органу Ростехнадзора в рамках проведения контрольных (надзорных) мероприятий.

Попробуем разобраться, что входит в понятие «параметр безопасности», как они формируются, и как с этой задачей справляется программное обеспечение «верхнего уровня» МФСБ.

Теоретическая основа для построения «верхнего уровня» МФСБ. К чему привязывать данные?

Как было отмечено выше, одной из основных задач «верхнего уровня» МФСБ является обеспечение процесса дистанционного мониторинга параметров безопасности. Безопасность – это состояние защищенности, характеризуемое отсутствием недопустимого риска. Риск при этом рассчитывается, как произведение вероятности наступления аварийного события на величину возможного ущерба.

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

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

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

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

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

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

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

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

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

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

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

Показатели безопасности могут формироваться в результате обработки параметров самого контролируемого объекта, например, показатель «превышение ПДК метана», где объектов контроля является рудничная среда, параметром: «концентрация метана», а обработка основана на превышении предупредительных и предаварийных уставок.

Для формирования комплексных показателей обрабатываться могут параметры разных объектов контроля, например, показатель «опасность опрокидывания техники» срабатывает, если горнотранспортная техника на горных работах (координаты техники из системы позиционирования находятся в заданной геозоне) плюс средняя скорость ветра выше 20 м/с (данные в систему передаются от метеостанции).

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

Перспективы передачи данных в рамках государственного мониторинга.

С 2019 года обсуждается внедрение механизма государственного мониторинга промышленной безопасности посредством АИС Ростехнадзора, включающего цифровой профиль субъекта и объекта надзора с управлением рисками, предусматривающими дистанционный мониторинг (СДК ПБ)

В настоящий момент проводится апробация СДК ПБ в рамках эксперимента, проводимого на основании Постановления Правительства РФ от 31.12.2020 № 2415 со сроком завершения до конца 2025 года.

Также можно отметить, что в 2023 году был разработан ГОСТ Р 71002-2023 (Многофункциональные системы безопасности угольных разрезов. Системы дистанционного контроля опасных производственных объектов, и есть основания полагать, что МФСБ, как система, объединяющая другие автоматизированные системы на предприятии, станет источником данных для аналитики в составе СДК.

В этом случае, данные о состоянии промышленной безопасности (показатели безопасности) могут использоваться как на самом предприятии, так и передаваться регулятору, поэтому у системы должно быть двойное назначение: государственный мониторинг с одной стороны, и производственный контроль за состоянием ПБ с другой.

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

О важности интеграций и интегратора при создании МФСБ.

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

  • • получение справочников, реестров (объектов и их типов, событий и их типов, параметров, показателей, и т.д.);
  • • получение актуальной информации об объектах контроля от источников данных;
  • • передача обработанных данных о состоянии промышленной безопасности (показатели безопасности) во внешние системы.

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

Где содержится информация об объектах контроля, которые мы хотим завести в МФСБ? С одной стороны, все физические активы предприятия должны быть на балансе в системе бухгалтерского учета, например, в качестве основных средств в 1С. Также на предприятии может быть внедрена система класса EAM, предназначенная для управления жизненным циклом активов. Причем в EAM системе, скорее всего, представление данных будет в виде реестров и справочников по активам в иерархическом представлении. При этом часть из этих активов есть не что иное, как источники опасности или объекты рисков.

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

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

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

Получение актуальной информации об объектах контроля от источников данных является задачей подсистемы мониторинга, реализуемой в «верхнем уровне» МФСБ.

Вариантов сбора данных не так много, но каждый имеет свои особенности:

  • 1. От датчиков, средств измерений, диагностических выводов оборудования и т.д. с аналоговым выходом, дискретным выходом, «сухим контактом» и прочими. Выходной аналоговый сигнал, например, 4-20м, 0-10В, выход «сопротивление», «открытый коллектор», «сухой контакт» и т.д. снимается контроллером с соответствующим типом ввода. Уже оцифрованные данные передаются, как правило, по Ethernet на сервер обработки.
  • 2. От датчиков, средств измерений, диагностических выводов оборудования и т.д. с цифровым выходом, контроллеров, преобразователей интерфейсов и протоколов, пультов.
    Данных от источников с цифровым выходом преобразуются в части интерфейса передачи данных, например, RS-232, RS-485, CAN и т.д. как правило, в Ethernet для передачи по локальной вычислительной сети объекта, или, в случае невозможности, данные передаются по радиоканалу с последующим преобразованием в Ethernet. Сюда же можно отнести решения промышленного интернета вещей (IIoT) с применением оборудования LoRaWAN, Nb-IoT.
  • 3. От серверов информационных систем (подсистем из состава КТС МФСБ):

• через прямые интеграции;
• через API.
• через брокеры сообщений;
• через шину данных;

  • Программное обеспечение, предназначенное для прямых интеграций, должно поддерживать широкий набор протоколов верхнего и нижнего уровня стека TCP/IP, в том числе:

•  промышленные: HTTP(S), TCP, UDP, ICMP, Modbus TCP, OPC UA Client, OPC UA Server и др;
•  взаимодействие через последовательные порты: Modbus RTU;
•  разбор и формирование структур данных в формате JSON, XML, CSV;
 • взаимодействие с базами данных: PostgreSQL;

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

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

Интеграция посредством API – через интерфейс приложения, который предоставляет доступ к нему, разрешения, позволяя интеграционному программному обеспечению взаимодействовать с ним, получать необходимые данные. Для интеграции с веб-сервисами часто используется REST API, протокол HTTP и формат данных (разметка) JSON, либо SOAP.

Брокеры сообщений (также их называют «очереди сообщений») позволяют осуществлять обмен информацией между системами в асинхронном режиме, снимая нагрузку как с источника, так и с получателя сообщения, при этом контролируя факт успешного получения, так, чтобы информация не терялась. Из наиболее распространенных: Apache Kafka, RabbitMQ. Брокеры осуществляют транспортную функцию, при этом сами сообщения формируются взаимодействующими системами по указанным выше правилам.

Шины данных (ESB - Enterprise Service Bus) являются специализированным программным обеспечением, выполняющим функции центрального «хаба», определяющего правила и формат передачи данных внутри корпоративной сети между системами, контролирует целостность данных, обеспечивает маршрутизацию. Шины содержат в себе брокеров сообщений, их функциональность гораздо шире. Но интеграция с такими системами в рамках МФСБ, скорее редкость, поскольку ESB применяется в основном на крупных предприятиях, реализующих или реализовавших проект цифровой трансформации.

Что касается передачи обработанных данных о состоянии промышленной безопасности (показатели безопасности) во внешние системы, то стоит рассмотреть, как эта задача решается в настоящий момент и какие есть перспективы.

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

Способы обмена данными, состав и формат данных для обмена с территориальным органом Ростехнадзора не регламентирован, и определяется на этапе проектирования МФСБ.

Аналогичные требования действовали в отношении угольных разрезов до 1 сентября 2024 года на основании «Правил безопасности при разработке угольных месторождений открытым способом», утвержденных Приказом Ростехнадзора от 10.11.2020 N 436.

 Актуальные вопросы по МФСБ

Отвечает Максим Кретинин, директор направления «Цифровизация добычи» ПАО «Ростелеком»

1. Угледобывающая организация разработала проектную документацию на техническое перевооружение в части внедрения МФСБ на угольном разрезе до 01.09.2024г. В настоящий момент с учетом изменений в ФНП передавать обработанную информацию о выявленных изменениях контролируемых параметров безопасности угольного разреза и срабатывании систем противоаварийной защиты в территориальный орган Ростехнадзора не требуется. Что делать?
Поскольку ФПН изменились, для приведения проекта МФСБ в соответствие обновленным правилам безопасности, следует выполнить корректировку проектной документации. При этом в соответствии со ст. 8 Федерального закона № 116-ФЗ от 21.07.1997 «О промышленной безопасности опасных производственных объектов» изменения, вносимые в документацию на техническое перевооружение ОПО, подлежат экспертизе промышленной безопасности.
Предвосхищая следующий вопрос, аналогичный порядок подходит и в отношении уже реализованных проектов МФСБ, даже тех, где обеспечивалась передача данных в территориальный орган.
2. В какой форме и какими способами допустимо представление информации по мониторингу параметров безопасности, регистрируемых МФСБ угольного разреза, которую угледобывающая организация должна предоставлять территориальному органу Ростехнадзора в рамках проведения контрольных (надзорных) мероприятий?
Формат предоставления обработанной информации по мониторингу параметров безопасности, регистрируемых МФСБ угольного разреза, определяется в проектной документации МФСБ. Примерами предоставления таких параметров могут быть таблицы, графики, диаграммы, гистограммы, индивидуально разработанные программные системы (приложения) для визуализации данных и другие.
Предоставление обработанной информации контрольному (надзорному) органу возможно любым доступным способом, но при этом должна быть обеспечена не только полнота, точность и достоверность регистрируемых данных МФСБ угольного разреза, но и защита представленных данных от искажения, уничтожения, блокирования и модификации получаемой МФСБ информации.

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

Подключение объектового СДК ПБ к информационному ресурсу Ростехнадзора требует наличия и поддержки средств криптографической защиты данных, совместимых с программно-аппаратными средствами криптографической защиты данных Ростехнадзора;

Непосредственно обработанные данные формируются и передаются в виде XML-документа, требования к которому описаны в типовом соглашении с участником эксперимента СДК ПБ.

Подводя итог, интеграции в МФСБ играют огромное значение и позволяют:

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

К «верхнему уровню» МФСБ также относят и программное обеспечение, которое помогает специалистам службы эксплуатации опасного производственного объекта решать задачи оперативно-диспетчерского управления и производственного контроля за соблюдением требований промышленной безопасности, используя инструменты для управления состоянием объектов контроля, включая возможности наблюдения и реагирования на поток событий, планирования, постановки и контроля заданий, удобного доступа к историческим данным и аналитике для принятия управленческих решений для обеспечения безопасности предприятия.

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

  • •  авторизации;
  •  • добавления и настройки объектов контроля и связей между ними;
  • •  основной бизнес-логики обработки потока входных данных;
  •  • формирования отчётов;
  • •  работы с файлами и документами;
  • •  сопряжения с ПО интеграции МФСБ, реализуя приём данных;
  •  • инструментов для перспективной настройки информационного взаимодействия с АИС Ростехнадзор и МЧС.

Для работы программного комплекса при внедрении МФСБ предприятия предусматривается:

  • • создание информационной модели источников опасности (объекты контроля);
  • • определение контролируемых параметров;
  • • задание показателей опасности (выбор из предустановленных или разработка);
  • • настройка потоков данных;
  • • настройка прав и ролей пользователей;
  • • разработка дашбордов;
  • • интеграция с информационными системами заказчика.

Программный комплекс разворачивается локально (on premise), а также в качестве облачного решения, поддерживает контейнеризацию и масштабирование.

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

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

Интегратор, получая прошедший экспертизу промышленной безопасности проект МФСБ в производство работ, должен реализовать его в соответствии с проектными требованиями, сталкиваясь с разными сложностями, среди которых можно выделить следующие основные:

  • • методы и способы интеграции с объектовыми системами и оборудованием проработаны крайне слабо или не проработаны вовсе;
  • • показатели МФСБ построены на данных, которые невозможно получить (данные либо отсутствуют в сопрягаемых системах, либо нет возможности обеспечить такое сопряжение);
  • • качество проработки инженерно-технических решений, актуальность и полнота проекта не позволяют выполнить строительно-монтажные и наладочные работы без дополнительных обследований.

Поэтому интегратор должен не только иметь возможности реализации проекта, но также обладать отраслевой экспертизой, в том числе иметь возможности доработать рабочую документацию МФСБ.

В настоящий момент можно отметить следующие сложности с интеграцией МФСБ:

  • 1. в состав информации МФСБ попадает минимум данных, предназначенных в первую очередь, для инспектора, а не для специалистов эксплуатирующей организации;
  • 2. большая часть технических руководителей эксплуатирующих организаций не хочет менять привычные производственные процессы, и встраивать туда МФСБ;
  • 3. в отсутствии конкретных требований со стороны Ростехнадзора большинство предприятий идет по пути минимизации затрат на МФСБ.

Что больше всего влияет на стоимость внедрения МФСБ: 

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

Актуальными подходами к реализации МФСБ в текущей ситуации с учетом трендов развития являются следующие:

  1. не переделывать существующие системы, только планово модернизировать;
  2. использовать существующую инфраструктуру передачи данных;
  3. не автоматизировать сразу сбор данных от всех источников опасностей;
  4. рассматривать производственный контроль и системы связи в качестве источника данных.

В 2024 году мы обогатили наш опыт внедрения МФСБ, основные тезисы по итогам внедрений следующие:

  • • большое количество различных систем, с которыми необходимо реализовать сопряжение;
  • • большая часть систем предоставляют API, но далеко не все подстраиваются под информационные платформы заказчика;
  • • сопрягаемые системы могут передавать наборы данных не в том виде, в котором их предусматривает ПД МФСБ (значения параметров, показатели, события);
  • • необходимость добавления работы через брокеров сообщений (очереди);
  • • необходимость согласования справочников (MDM) или упрощения реализации (например, обобщение до комплексного показателя);
  • • некоторые функции дублируются в других системах (планировщик задач также в наряд-допускной системе, журналы событий в системе позиционирования и контроля горно-транспортного оборудования), при этом проектами не определены целевые системы, в которых оператор должен вести работу.

Чтобы МФСБ действительно могла принести пользу, нужен менее формальный подход к проектированию и реализации МФСБ с обязательным привлечением технических специалистов. Интегратор, управляя процессом реализации системы, своевременно обеспечивает вовлечение функциональных заказчиков, помогает с подготовкой организационной и правовой основы для применения МФСБ на предприятии.

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

Сергей Ковалев, эксперт по стандартизации