На совещании по пуску заказчик говорит: «Сделайте по 61511, у нас SIL 2 на отключение». Интегратор кивает и открывает CODESYS. Через месяц приходит инженер по функциональной безопасности и спрашивает SRS, proof test и разделение BPCS/SIS. В проекте есть логика «если давление высокое - закрыть клапан», но нет трассировки от опасного события до клапана, нет расчёта PFD, нет регламента испытаний. Инженер АСУ ТП честно настроил ПЛК, но граница его ответственности закончилась не там, где все думали.
ISO/IEC 61511 описывает жизненный цикл систем безопасности процесса (SIS). На объекте пересекаются роли эксплуатанта, проектировщика SIS, интегратора АСУ ТП и подрядчика по машинной безопасности (ISO 13849). Статья разбирает, какие задачи реально ложатся на инженера АСУ ТП в контуре 61511, а какие нельзя «закрыть» одной программой в обычном ПЛК. Без пересказа всего стандарта и без подмены оценки рисков настройкой таймеров.
Инженер АСУ ТП в проекте по ISO/IEC 61511 обычно отвечает за BPCS (базовую систему управления): измерения, регулирование, HMI, межблокировки технологические, интерфейс с SIS, документирование сигналов и версий ПО - в рамках договора. Он не подменяет инженера по функциональной безопасности: не пишет SRS в одиночку, не назначает SIL «по опыту», не подтверждает соответствие SIS без расчёта и верификации. SIS - отдельный контур с требованиями к архитектуре, диагностике, proof test и независимости от BPCS. Логику «на всякий случай» в том же ПЛК, что и PID, нельзя считать выполнением 61511. Proof test, обучение операторов, управление изменениями после пуска - зона эксплуатанта и ответственного за SIS. От ISO 13849 (машины, приводы, двери станка) 61511 отличается объектом и жизненным циклом; путать стандарты в одном ТЗ - типовая ошибка.
Эксплуатант владеет процессом, опасностями, решением «что защищать» и принимает остаточный риск. Заказывает оценку, утверждает SRS, обеспечивает ресурсы на proof test и аудит, хранит документацию на весь срок эксплуатации.
Инженер / организация по функциональной безопасности (FS) ведёт HAZOP/LOPA (или принимает их результаты), определяет SIL для SIF, пишет или проверяет SRS, выбирает архитектуру SIS, считает PFD, планирует proof test, участвует в FAT/SAT безопасности.
Интегратор АСУ ТП проектирует BPCS: ПЛК, модули I/O, сети, SCADA, регулирование, технологические блокировки по ТЗ, интерфейсы с SIS (дискретные разрешения, квитирование, отображение). Реализует SIS только если это отдельный контракт, отдельное железо/ПО и полномочия по FS, с трассировкой до SRS.
Поставщик оборудования (клапаны, датчики, реле безопасности) даёт сертификаты, данные для расчёта, ограничения по применению.
На малом объекте роли сжимаются в одних людей, но артефакты не сжимаются: без SRS и proof test «SIL 2 в переписке» не существует.
Safety Requirements Specification (SRS) для каждой safety instrumented function (SIF) фиксирует: опасное событие, входы, логику (в терминах причин/эффектов), выходы, требуемый SIL, время реакции, режимы (PFD/PFH), требования к тестированию и ручному вмешательству. SRS - не комментарий в FBD «давление > 10 - закрыть XV».
Инженер АСУ ТП может участвовать: дать список доступных тегов, типов клапанов, времени срабатывания приводов, предложить разделение BPCS/SIS на уровне сигналов. Но утверждение SRS и привязка к LOPA - не его соло-задача, если он не назначен ответственным за FS по договору.
Типовая ошибка: в ТЗ на АСУ ТП пункт «реализовать SIL 2 по давлению» без SRS. Интегратор добавляет сравнение и RST в том же ПЛК, что котёл и насосы. Это не SIS по 61511.
61511 требует независимости, диагностики, ограничений на общие отказы. BPCS может терять питание, перезагружаться после загрузки проекта, иметь online-правки без формального MOC. SIS проектируют с другими критериями: отказоопасные состояния, safe state, периодические тесты, сертифицированные или оценённые элементы.
Инженер АСУ ТП настраивает границу: какие сигналы идут из SIS в BPCS (разрешение пуска, аварийный стоп), какие команды BPCS не должны дублировать SIS, как на HMI показывать состояние SIF без обхода. Перепутать технологическую блокировку («нельзя пускать насос при сухом баке») и safety («нельзя допустить разрыв сосуда») - разные уровни и разные документы.
Что нельзя закрыть только логикой обычного ПЛК без FS-контура:
Подробнее о документах и оценке - в материале про функциональную безопасность и SIL на практике.
Proof test подтверждает, что SIF работает от датчика до финального элемента с заданной покрытией. Период, процедура, ответственный, запись результата - в плане испытаний из жизненного цикла 61511. Эксплуатант выполняет или контролирует; FS-инженер задаёт интервал из расчёта PFD.
Инженер АСУ ТП помогает: обеспечить режим для теста (имитация, bypass по процедуре, отображение на HMI), не блокировать тест неожиданной перезагрузкой, задокументировать версию BPCS на момент теста. Он не подменяет подпись ответственного за SIS на протоколе proof test.
Пропуск proof test со временем «съедает» заявленный SIL даже при исправном железе.
61511 - процессная (химия, НГК, энергетика): давление, уровень, утечки, пожарогаз. ISO 13849 - безопасность машин и приводов: кожух, световая завеса, STO привода, Category/PL.
На одном заводе могут быть оба: реактор по 61511, линия розлива с 13849 на приводе. Разные методы оценки, разные отчёты, разные исполнители. «SIL 2 = Category 3» - неверно. Карта стандартов для ориентира - IEC 61508, 61511, ISO 13849.
Инженер АСУ ТП настраивает сигналы от шкафа машинной безопасности в BPCS (разрешения, индикация), но не подменяет валидацию 13849 расчётом в ПЛК.
На FAT проверяют BPCS: циклы, HMI, связи, регулирование, технологические interlock по сценариям из ТЗ на АСУ. SAT - на объекте с процессом или имитацией.
Приёмка SIS - отдельные сценарии из SRS: время срабатывания, safe state, отказ датчика, потеря питания, имитация опасного события в согласованных пределах. Инженер АСУ ТП участвует в совместных тестах, но не подписывает SAT по SIL без FS.
Материал FAT и SAT без сюрпризов на пуске про общую приёмку АСУ; для SIS к нему добавляют протоколы по SRS, не заменяют ими.
Типовая зона АСУ на FAT: доказать, что BPCS не мешает SIS, что bypass на HMI соответствует матрице, что версия проекта зафиксирована.
В рамках BPCS и интерфейсов он обычно:
Он обычно не делает без полномочий FS:
Любая правка, затрагивающая SIF или границу BPCS/SIS, проходит management of change. Инженер АСУ ТП инициирует запрос при правке логики, затрагивающей разрешения или общие теги; FS оценивает влияние на SIL. «Быстрый фикс в online» в контуре, который заказчик считает safety, - риск для лицензии и для людей.
Для BPCS MOC тоже нужен, но критерии другие. Путаница возникает, когда safety-логика живёт в «общем» ПЛК без отдельного учёта.
Операторский bypass interlock на экране - частая точка спора. SRS и политика эксплуатанта определяют: допустим ли bypass, на сколько, с каким ключом, с какой сигнализацией. Инженер АСУ ТП реализует матрицу: кто видит bypass, что пишется в журнал, какой таймер возврата. Он не решает сам, можно ли «на смену отключить отключение по давлению».
Если в проекте BPCS есть скрытая кнопка «отключить все блокировки» без роли и без записи - это не помощь технологу, а будущий пункт аудита. Согласуйте с FS до FAT. Сценарий «дверь шкафа, разрешение пуска» из отдельной статьи ближе к машинной/технологической логике, но принцип журнала и ролей тот же.
Газоанализатор и разрешение на пуск - пример, где АСУ стыкует сигналы, а классификация SIF или технологии - вне вечернего правления константы в ST. См. газоанализатор в норме, пауза не снимается: там разбор логики разрешений, не замена LOPA.
В договоре на АСУ ТП полезны явные формулировки: поставка и наладка BPCS по приложению X; SIS/SRS - приложение Y и отдельный исполнитель; интегратор не выполняет расчёт SIL без письменного поручения и исходных данных LOPA. На совещаниях фиксируйте протокол: «вопрос о proof test передан эксплуатанту».
Инженер АСУ с сертификатом по CODESYS - не автомат замены инженера TÜV FS. Обратное тоже верно: FS-консультант без опыта пуска не должен один править scan cycle в BPCS. Нормальная схема - совместные сессии на границе сигналов.
При приёмке пакета документов на ввод проверьте, что раздел SIS не пустой ссылкой «будет позже». Пустой раздел на пуске превращается в вашу ночную смену через полгода.
| Задача на объекте | Чей контур ответственности | Артефакт |
|---|---|---|
| Определить опасные события и целевой риск | Эксплуатант, HAZOP/LOPA с FS | Протокол HAZOP/LOPA, реестр опасностей |
| Назначить SIL для SIF | FS-инженер по результатам LOPA | Запись в LOPA, согласование эксплуатанта |
| Описать логику SIF, время, safe state | FS-инженер, утверждает эксплуатант | SRS на каждую SIF |
| Спроектировать SIS (ПЛК/реле, I/O, клапаны) | FS / поставщик SIS по SRS | Схемы SIS, расчёт PFD, спецификация |
| Реализовать BPCS, HMI, технологические блокировки | Интегратор АСУ ТП по ТЗ на АСУ | Функциональная схема, ПО, FAT BPCS |
| Интерфейс BPCS-SIS (разрешения, индикация) | АСУ ТП + FS, согласованная матрица | Матрица сигналов, описание bypass |
| Proof test в эксплуатации | Эксплуатант, процедура от FS | Регламент, журнал испытаний, период |
| FAT/SAT SIS | FS, эксплуатант, подрядчики | Протоколы по сценариям SRS |
| Машинная безопасность привода, двери | Проектировщик 13849, OEM | Расчёт PL/Category, схема STO |
| Обучение операторов (bypass, аварии) | Эксплуатант | Журнал обучения, инструкции |
| MOC при изменении логики SIF | Эксплуатант + FS; АСУ при затрагивании BPCS | Заявка MOC, переоценка при необходимости |
В ТЗ написано «SIL 2» без SRS - что делать интегратору АСУ?
Зафиксировать в протоколе: реализуется BPCS по приложению; SIS требует отдельного ТЗ и SRS. Не имитировать SIL в общем ПЛК без письменного согласования рисков.
Можно ли одним ПЛК и процесс, и safety?
Теоретически при сертифицированном решении и полном FS-контуре. На практике SIS часто отдельное железо. Решение не за инженером АСУ «по умолчанию».
Инженер АСУ настраивает газоанализатор и блокировку пуска - это 61511?
Зависит от классификации в LOPA/SRS. Может быть SIF, может быть технологическая блокировка. Классификацию делает FS/эксплуатант, не наладчик по факту подключения.
Чем помочь на пуске без лишней ответственности?
Документировать версии, сигналы, сценарии FAT BPCS, не соглашаться на формулировки «вы отвечаете за SIL» без границ в договоре.
61511 и пожарогазовая сигнализация?
Смежные контуры; интеграция в BPCS есть, но требования к SIS/ПГС задаются отдельными нормами и SRS, не одной кнопкой в SCADA.