Почему SIL 2 ≠ «можно расслабиться»

Грядёт 25-я международная выставка Нефтегаз-2026. В прошлом году мы посетили выставку и пообщались с большим количеством производителей оборудования на тему функциональной безопасности. Особо запомнился один разговор про следование требованиям ФБ, а именно — SIL 2. Разработчики оборудования для автоматизации прямо сказали: «если нужен SIL 2, то особо делать ничего и не требуется: достаточно ограничиться документальным обоснованием и, возможно, расчётами, чтобы safety manual (РФБ) выглядел убедительно».

Так ли это? Давайте разберёмся на примере ПЛК уровня SIL 2.

1. Обычный ПЛК сам по себе не является безопасным устройством.
Как правило, у него нет ни определённых безопасных состояний, ни встроенных функций безопасности. Он просто управляет процессом — и не более того.
2. Перевод системы в безопасное состояние требует конкретной аппаратной реализации.
Например, de-energize to trip — это не абстракция из документации, а вполне конкретные схемные решения: транзисторные ключи, силовые элементы с контролем отказов, продуманная логика выхода в safe state. Без этого «безопасность» остаётся только на бумаге.
3. Обмен данными между модулями ПЛК должен учитывать коммуникационные ошибки — и качественно, и количественно.
Потери, искажения, перепутанные сообщения, ошибки адресации и т.д. — всё это должно детектироваться и корректно обрабатываться. В стандартных ПЛК коммуникации проектируются из соображений надёжности и доступности (availability), но не из требований ФБ.
4. Операционная система общего назначения (GPOS) не подходит для safety-ПЛК.
Причина банальна, но критична: отсутствие гарантированного реального времени и детерминированного поведения. А без этого невозможно доказать корректное выполнение safety-функций в заданные временные интервалы.
5. Да, для SIL 2 допускается HFT = 0 даже для устройств типа B.
Но при этом значение SFF (ДБО) должно быть достаточно высоким.
А в стандартных ПЛК:
· диагностическое покрытие целенаправленно не оценивалось,
· многие опасные отказы просто не детектируются,
· FMEDA анализ не проводился.
Это означает, что практически наверняка потребуется добавлять и аппаратное, и программное детектирование отказов, то есть вносить изменения в HW и SW.

Есть и другие важные моменты — инженерная среда, требования к ПО, МКУ и ЦПУ, FIT тесты, документы и процессы ФБ, расчёты и т.д. Но уже на этом уровне очевидно: SIL 2 — это не про «расслабиться».

Считаете ли вы, что SIL 2 на практике — это про реальные инженерные решения или чаще про «убедительный safety manual»?