На совещаниях про SIL говорят уверенно, а в цехе часто оказывается, что «уровень безопасности» записан в одном документе, расчёт сидит в Excel у подрядчика, а список proof test живёт в голове у главного инженера. Через два года после ввода в эксплуатацию это превращается в риск: никто не помнит, откуда взялась цифра, и менять логику страшно.
Эта статья про то, как пройти путь от слов «нам нужен SIL 2» до нормальной эксплуатации без лишней бюрократии и без самообмана в цифрах.
Короткий ответ
SIL - это не «надпись на шильдике ПЛК», а соглашение о том, насколько редко отказ системы безопасности должен оставлять опасное состояние незамеченным. Оценка делается через анализ сценария (часто LOPA), расчёт PFDavg или PFH для цепочки от датчика до финального элемента, оформление жизненного цикла по IEC 61511 и регулярные проверки в эксплуатации. Если одного из звеньев нет, «SIL на бумаге» не переживёт ни аудит, ни реальный инцидент.
Зачем вообще SIL и чем он отличается от «надежного ПЛК»
Обычный контроллер оптимизируют под доступность и стоимость цикла. Система безопасности (SIS) оптимизируется под другое: вероятность того, что она не сработает, когда должна. Отсюда идея уровней SIL (Safety Integrity Level): чем выше SIL, тем жёстче требования к архитектуре, к процессу разработки и к тому, как вы обслуживаете систему после запуска.
В процессной отрасли чаще всего говорят о низкой интенсивности запросов к безопасности: аварийная остановка или отключение нагрева случаются редко, но последствия тяжёлые. Тогда ключевая метрика - PFDavg (средняя вероятность отказа по требованию) для всей цепочки. Если запросы к защите идут часто или система работает почти непрерывно, в расчёт уходит PFH (частота опасных отказов в час) - это другая логика и другие таблицы, и смешивать её с «редкими срабатываниями» нельзя.
LOPA и откуда берётся цифра
LOPA (Layer Of Protection Analysis) - практичный способ не утонуть в Fault Tree на первом же узле. Вы фиксируете исходное событие, оцениваете последствия, перечисляете независимые слои защиты и для каждого слоя задаёте порядок снижения риска. Для слоя, который вы хотите отнести к SIS, получается требуемый RRF (risk reduction factor), из которого выводится целевой SIL.
Важный момент для инженера АСУ ТП: LOPA - это не «математика ради математики». Если слои зависимы друг от друга (один и тот же датчик, одна шина, один человек), их нельзя суммировать как независимые. Именно здесь чаще всего завышают уверенность и занижают реальный риск.
Жизненный цикл по IEC 61511: что должно жить в проекте, а не в голове
Стандарт описывает фазы от концепции до вывода из эксплуатации. На практике полезно держать в голове пять опорных блоков:
1.Определение опасностей - что может пойти не так и какова тяжесть.
2.Проектирование SIS - архитектура, отказобезопасные состояния, диагностика, ограничения на изменения.
3.Верификация - расчёт PFDavg/PFH, проверка, что цепочка реально закрывает сценарий.
4.Валидация и ввод - FAT/SAT, сценарные тесты, фиксация версий и параметров.
5.Эксплуатация - proof test, учёт изменений, разбор срабатываний, обучение персонала.
Если фазы 3-4 оформлены слабо, фаза 5 превращается в угадайку: «мы поменяли датчик, SIL ещё есть или уже нет?».
Таблица: SIL, требуемый PFDavg и типичные примеры
Ниже - ориентиры для низкой интенсивности запросов (процессная логика, редкие остановки). Диапазоны соответствуют общепринятой шкале IEC 61508 / IEC 61511; точные границы в проекте должны быть согласованы с методикой расчёта и выбранной моделью отказов.
Если вам говорят «SIL 3» без расчёта и без явной цели по PFDavg, это повод остановиться и попросить цепочку: сценарий, слои, допущения, вклад каждого элемента.
Документирование: минимальный набор, который реально читают
Хороший пакет для сопровождения обычно включает:
•SRS (спецификация требований к безопасности): что должна делать функция, в каких режимах, какие режимы обслуживания, что считается безопасным состоянием.
•SIF-карточки: один лист на функцию безопасности, с входами, выходами, логикой, тестируемыми интервалами и ответственными.
•Расчёт PFDavg/PFH с версией, датой и допущениями (λ, proof test interval, common cause, coverage диагностики).
•Процедуры proof test пошагово, чтобы два разных техника дали одинаковый результат.
•Журнал изменений, связанный с MOC: что поменяли, пересчитали ли, кто подписал.
Это не «лишние бумаги», а страховка от ситуации, когда на объекте три поколения правок и ни одного источника правды.
Типичные ошибки, которые потом дорого стоят
Смешение BPCS и SIS в одной голове без границ. Управление процессом и безопасность - разные роли. Если «и так работает» на одном контроллере, вопрос не технический, а организационный: кто имеет право менять уставки и кто отвечает за сохранность SIL.
Заниженный proof test interval в расчёте и завышенный в жизни. В расчёте пишут «тест каждые 12 месяцев», а на практике оборудование не останавливают три года. PFDavg уезжает, и вы об этом не знаете, пока не случится событие.
Игнорирование common cause: один кабельный лоток, один ИБП, один инженерный ноутбук на всю сеть. Независимость слоёв и каналов нужно проверять физически, а не только на схеме.
Изменения без пересчёта: заменили тип клапана, прошивку safety-модуля, добавили диагностический сигнал в логику. Любое из этого может изменить λ и диагностическое покрытие.
Поддержка в эксплуатации: proof test и культура
Proof test - не «формальность для аудита», а измерение того, что цепочка реально переводит процесс в безопасное состояние. Хорошая практика - заранее договориться о окнах остановок, о дублировании критичных измерений и о том, как фиксируются отклонения (что считается failed test и что делать до следующего цикла).
Отдельно стоит выделить анализ срабатываний: каждый trip safety-системы - это данные. Если их не разбирать, вы не узнаете, где процесс «бьёт в защиту» слишком часто и где BPCS на самом деле не справляется.
Где уместен СТАБУР
В проектах на базе решений СТАБУР функциональная безопасность - часть общей дисциплины изменений: версии логики, понятные границы между управлением и защитой, журналы и процедуры тестирования. Это не заменяет расчёт SIL, но сильно упрощает жизнь тем, кто будет сопровождать объект через пять лет.
Заключение
SIL на практике - это связка оценка риска, расчёт, документы и дисциплина эксплуатации. Если убрать любое звено, остальное превращается в декорацию. Инженеру АСУ ТП выгодно не «знать стандарт наизусть», а уметь задавать правильные вопросы подрядчику и заказчику: какая цепочка, какие допущения, какой PFDavg, какой интервал proof test и что происходит при изменении.
FAQ
Обязательно ли LOPA, или достаточно HAZOP?
HAZOP выявляет отклонения, LOPA помогает количественно распределить снижение риска по слоям. Для выбора SIL часто используют связку HAZOP + LOPA, но методика должна быть согласована с политикой предприятия.
Можно ли считать SIL только по каталогу вендора?
Каталог даёт данные по элементам. SIL относится к функции и цепочке в целом, включая датчики, логику и исполнительные механизмы.
Что делать, если в эксплуатации нельзя выполнить полный proof test?
Это проектный и организационный долг: предусмотреть частичные тесты, обходные схемы, дублирование или изменить архитектуру. Игнорировать нельзя - нужно явно документировать ограничение и пересчитать риск.
Нужен ли отдельный safety-ПЛК всегда?
Не всегда. Зависит от архитектуры, требуемого SIL и вендорской концепции. Но граница между управлением и безопасностью должна быть прозрачной и зафиксированной в документах.
Кто «владелец» SIL на предприятии?
Обычно это связка процессной безопасности, главного инженера и АСУ ТП с участием эксплуатации. Без владельца документы и тесты разъезжаются.