Функциональная безопасность: практика и аудит

🎤 30 сентября выступили на форуме PROавтоматизацию 2026 с докладом «Где заканчивается открытость АСУ ТП: ограничения для систем противоаварийной защиты».
В открытых АСУ ТП сегодня много внимания уделяется многовендорности, стандартизованным интерфейсам, переносимости и взаимозаменяемости компонентов. В докладе мы постарались показать, где эти принципы начинают сталкиваться с требованиями функциональной безопасности.

💬 В частности, обсудили:
➜ почему архитектурное отделение ПАЗ не исключает вопросов взаимодействия с другими системами;
➜ почему для передачи данных, связанных с безопасностью, обычного коммуникационного протокола недостаточно и нужен safety-протокол;
➜ почему совместимость компонентов ещё не означает их взаимозаменяемость с точки зрения ФБ;
➜ почему любое изменение ПАЗ — замена компонента, изменение ПО, конфигурации или коммуникации — требует оценки влияния на функциональную безопасность, а при наличии такого влияния — подтверждения сохранения ФБ.

Отдельно затронули вопрос доступности в РФ экосистемы, необходимой для реализации промышленных коммуникационных протоколов, включая safety-протоколы: открытый стандарт на протокол сам по себе ещё не означает технологическую независимость.

🤝 Спасибо организаторам PROавтоматизацию за возможность обсудить эту тему и участникам форума — за вопросы и интерес к докладу.

📌 Главный вывод нашего доклада:
Мы считаем, что по аналогии с международным отраслевым стандартом O-PAS ПАЗ следует прямо исключить из области применения российских стандартов по открытой АСУ ТП.

Спикеры Форума PROавтоматизацию продолжают рассказывать, о чем готовят доклады 📌

Где заканчивается открытость АСУ ТП и начинается зона ответственности ПАЗ? Этот и другие вопросы поднимет в своем выступлении Елена Рогова, ведущий специалист по функциональной безопасности, к.т.н., ФанкСэйфети. Подробности в видео.

• 30 сентября
• Офлайн в Москве, в Цифровом деловом пространстве (ЦДП) + Онлайн-трансляция
• Участие бесплатно, количество очных мест ограничено

➡️Регистрируйтесь на Форум, чтобы послушать доклад Елены и выступления других спикеров.

🛡 Безопасное состояние — не всегда «всё отключить»

В промышленной функциональной безопасности часто применяется принцип de-energize-to-trip: при отказе снимается питание, прекращается опасное движение, закрывается клапан или система иным способом переводится в заранее определённое безопасное состояние.
Из-за этого обесточивание можно ошибочно принять за универсальную безопасную реакцию. Однако МЭК 61508 не устанавливает такого требования. Для каждой функции безопасности определяется состояние, которое система должна достигать или поддерживать с учётом характеристик технологического процесса и условий эксплуатации.

🚗 В автомобиле ограниченность принципа «отключить при отказе» особенно заметна.
Например, в распределённой электромеханической системе brake-by-wire при отказе тормоза одного колеса система может продолжить торможение с помощью тормозов остальных колёс. При этом тормозные усилия перераспределяются так, чтобы сохранить необходимое замедление и устойчивость автомобиля до контролируемой остановки.
Отключение всей тормозной функции во время движения, напротив, привело бы к утрате тормозной способности.

📌 В ISO 26262 ограниченная функциональность приведена как один из возможных вариантов безопасного состояния в течение определённого времени — наряду с состояниями «выключено», «заблокировано» и «транспортное средство неподвижно и обслуживается».

➡️ Если безопасное состояние нельзя достигнуть за приемлемый интервал времени, ISO 26262 требует определить аварийный режим. В этом режиме система временно продолжает работу в объёме, необходимом для обеспечения безопасности, пока не будет достигнуто безопасное состояние; при этом её функциональность или характеристики могут быть ограничены.

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

💬 STO, категории останова и контактор: разбираем вопросы подписчиков
Наши подписчики задают такие интересные вопросы, что они заслуживают отдельных постов. Один из подписчиков в MAX оставил содержательный комментарий к нашей публикации по теме STO — в нём сразу несколько вопросов, которые мы решили разобрать отдельно. Пишите в комментариях — наиболее интересные вопросы мы будем разбирать в следующих публикациях.
Цитаты из комментария приведены с сокращениями без изменения смысла.

➡️ «Есть 3 реализации STO: Stop Cat0, Stop Cat1 и Stop Cat2. Stop Cat0 — это и есть самовыбег, т.е. неконтролируемый останов, Stop Cat1 — это останов по рампе (контролируемый останов, после останова питание снимается), Stop Cat2 — аналогично Stop Cat1, но питание после останова не снимается».
Наш комментарий: STO не имеет трёх реализаций Cat. 0 / Cat. 1 / Cat. 2, хотя здесь действительно легко запутаться. Категории останова 0, 1 и 2 определены для останова машины в МЭК 60204-1, а STO, SS1, SS2 и другие — это отдельные функции безопасности привода по МЭК 61800-5-2.
STO соответствует останову категории 0; SS1 — останову категории 1, при котором выполняется управляемый останов с последующим переходом в STO; SS2 — останову категории 2, при котором после управляемого останова активируется SOS.

➡️ «Как правило, привода реализованы по SIL2. Если же требуется SIL3, то необходимо ставить дополнительный контактор ПЕРЕД частотником, а не после него. [...] Почему необходимо ставить контактор ПЕРЕД частотником, а не между частотником и электродвигателем?..»
Наш комментарий: Из требования SIL 3 не следует обязательная установка дополнительного силового контактора перед преобразователем. У ряда современных приводов встроенная STO уже имеет SIL 3 / PL e — например, у ABB ACS880, Siemens SINAMICS G220 и Rockwell Automation PowerFlex 755.
Если встроенной STO недостаточно, дополнительный путь отключения может быть предусмотрен архитектурой функции безопасности. Но простое добавление контактора само по себе ещё не превращает SIL 2 в SIL 3.
Что касается места его установки, универсального правила «только перед ПЧ» нет. Контактор между преобразователем и двигателем также может применяться, но его коммутация должна соответствовать требованиям изготовителя. Например, ABB указывает, что выходной контактор нельзя размыкать, пока преобразователь активно управляет двигателем; при останове по заданной рампе сначала останавливают двигатель и только затем размыкают контактор.

📊 Что показала наша пятничная викторина?

Все участники выбрали правильный ответ: PL / SIL следует оценивать для всей функции безопасности — по полной цепочке от датчика через логику до функции STO привода.

📌 При этом важный нюанс стоит повторить: функция STO привода и функция безопасности машины — не одно и то же, хотя на практике их иногда ошибочно отождествляют. Даже если для STO заявлены PL e / SIL 3, этот уровень нельзя автоматически распространить на функцию безопасности машины в целом. STO — лишь одна из частей цепочки, а достигнутый PL / SIL определяется для всей реализованной функции.

🔧 Есть здесь и ещё один практический момент. Как и при работе с МЭК 61508, специалисту по функциональной безопасности важно понимать электрические схемы и принципы работы элементов, участвующих в реализации функции безопасности: датчиков, контакторов, ПЛК, приводов и т. д.
В безопасности машин это особенно наглядно: при виде подобных схем может возникнуть ощущение, что это уже «курс электротехники», а не функциональная безопасность. Однако без понимания того, как именно реализована функция безопасности, корректно оценить её PL или SIL бывает весьма затруднительно.

🧭 Мы планируем и дальше разбирать безопасность машин в канале. МЭК 61508 остаётся фундаментальной основой функциональной безопасности, но у машинного оборудования есть своя специфика, свои стандарты и немало интересных инженерных нюансов. Поэтому к ISO 13849-1, МЭК 62061, МЭК 61800-5-2 и практическим схемам реализации функций безопасности мы ещё не раз вернёмся.

📊 Продолжаем тему безопасности машин и предлагаем вам пятничную викторину по ФБ.
🔧Открытие защитного ограждения станка инициирует функцию безопасности, в которой используется функция STO привода с заявленными PL e / SIL 3. Как следует оценивать достигнутый уровень PL / SIL всей функции безопасности?👇

⚙️ STO: привод не создаёт крутящий момент, но остаётся под напряжением
При проектировании безопасности приводных систем часто рассматривают функции: STO (Safe Torque Off) — безопасное отключение крутящего момента; SBC (Safe Brake Control) — безопасное управление тормозом.
Сегодня рассмотрим один из принципиально важных аспектов STO.

🔧 В большинстве современных частотных преобразователей и сервоприводов STO реализуется аппаратным блокированием управления силовыми полупроводниками выходного каскада — например, снятием питания с драйверов затворов IGBT. При срабатывании STO преобразователь перестаёт формировать управляемое выходное напряжение, необходимое для создания двигателем крутящего момента.

⚠️ При этом привод не отключается от источника питания. Силовые цепи, включая выпрямитель и звено постоянного тока, вспомогательные цепи, а также другие части приводной системы могут оставаться под опасным напряжением.

➡️ Следовательно, STO предотвращает создание приводом крутящего момента, но не обеспечивает электрическое отделение привода от источников энергии, а также не заменяет отключение питания и проверку отсутствия напряжения перед электрическими работами.

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

Для функции безопасности машины определяется требуемый уровень — PLr или SIL. Встроенная функция STO привода проектируется и оценивается с учётом требований соответствующих стандартов — ISO 13849-1, МЭК 61508, МЭК 62061 и МЭК 61800-5-2. Для STO отдельных приводов могут заявляться уровни до PL e и SIL 3.

📌 STO отвечает на вопрос: «Предотвращено ли создание двигателем крутящего момента?», однако не отвечает на вопросы: «Обесточено ли оборудование?» и «Остановлен и надёжно удерживается ли механизм?»

🎯 Вывод: предотвращение опасного крутящего момента, управляемая остановка и удержание механизма, а также защита от поражения электрическим током — это разные задачи, для которых требуются разные технические меры.

🧠 Что показал наш опрос об использовании ИИ в функциональной безопасности?
📌 Большинство участников используют ИИ как вспомогательный инструмент либо не готовы доверять ему критичные инженерные решения. И нас такой результат не удивил.
В функциональной безопасности недостаточно получить убедительно сформулированный ответ. Нужно понимать, на каких данных и допущениях он основан, насколько он полон и как его проверить.
ИИ может помочь:
➜ структурировать информацию;
➜ сопоставить документы;
➜ подготовить перечень вопросов и замечаний;
➜ найти возможные противоречия и пропуски;
➜ сформировать шаблон требования, процедуры или отчёта.

Однако далеко не все результаты можно принимать только на основании ответа ИИ.
🚫 Без независимой инженерной проверки нельзя доверять ИИ:
➜ вывод о полноте выявленных опасностей;
➜ определение функций безопасности;
➜ назначение SIL, ASIL, PL;
➜ оценку архитектурных решений и независимости защитных мер;
➜ расчёты PFH, PFDavg, PMHF без проверки модели, данных и допущений;
➜ вывод о соответствии требованиям стандарта;
➜ решение о приёмке результатов верификации, валидации, аудита или оценки ФБ.

🧷 Отдельная тема, которую мы здесь не рассматриваем, — применение ИИ непосредственно в функциях и механизмах безопасности, например при распознавании опасной ситуации или формировании защитного воздействия. В этом случае ИИ становится частью системы, связанной с безопасностью, и требует отдельного обоснования и верификации.

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

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

🎯 На текущем этапе развития технологий мы видим ситуацию именно так.
❓ Какие задачи в области ФБ вам уже приходилось решать с помощью ИИ?

🧩 Резервировать ли интерфейс между процессорным модулем и модулями ввода/вывода в ПЛК ПАЗ?
В проектах часто возникает вопрос: нужно ли резервировать интерфейс между процессорным модулем и модулями ввода/вывода в ПЛК уровня SIL 2 / SIL 3?

📌 Сам по себе SIL не означает автоматическое требование «дублировать всё». Решение о резервировании обычно принимается с учётом архитектуры конкретной системы ПЛК, наличия резервированных процессорных модулей, требований к безопасной передаче данных и требований к доступности.

Обычно резервирование в коммуникационных протоколах безопасности применяют для решения двух задач: уменьшить интенсивность остаточных коммуникационных ошибок; повысить доступность при отказе одного коммуникационного канала / обрыве кабеля.

🔍 При этом резервирование может быть реализовано по-разному. Меры безопасности коммуникационного уровня безопасности / КУБ (CRC, номер последовательности, адресация, метка времени и др.) могут обеспечивать достаточно низкую интенсивность остаточных коммуникационных ошибок даже без резервирования физических интерфейсов. В некоторых случаях это позволяет применять такой обмен и в функциях безопасности уровня SIL 3. Однако такой вывод должен подтверждаться качественным и количественным анализом КУБ конкретного протокола.

📚 В 4-м издании МЭК 61784-3, Приложение A, рассмотрены разные коммуникационные модели в протоколах безопасности: A, B, C и D. Модель B — это модель полного резервирования: резервируются КУБ/SCL и весь путь передачи данных, включая физические интерфейсы / физические каналы.

❓Можно ли реализовать резервирование в коммуникационных протоколах безопасности без резервирования физических интерфейсов?
Да, например, за счёт резервирования сообщений. Однако важно понимать: далеко не любое дублирование сообщений снижает интенсивность остаточных коммуникационных ошибок. Это нужно отдельно анализировать.

⚠️ И ещё нюанс: резервирование сообщений по одному физическому интерфейсу не спасёт от обрыва кабеля или отказа единственного физического канала. То есть в плане доступности оно не поможет.

⏱️ А если в протоколе используются метки времени, резервирование также требует дополнительного анализа синхронизации, задержек и устаревания сообщений.

🎯 Итог: резервирование интерфейса между процессорным модулем и модулями ввода/вывода не является обязательным само по себе — ни для SIL 2, ни автоматически для SIL 3. Решение должно основываться на качественном анализе КУБ, количественной оценке интенсивности остаточных коммуникационных ошибок, архитектуре всей системы ПЛК и требованиях к доступности.

🧾 SRS вручную?

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

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

📌 Сам по себе ручной режим не запрещён. ГОСТ Р МЭК 61508 не требует, чтобы SRS/СТБ обязательно создавалась в специализированной системе управления требованиями. Однако стандарт требует, чтобы требования безопасности были определены, проверяемы, согласованы, актуальны и прослеживаемы на протяжении жизненного цикла безопасности.

⚠️ И вот здесь начинаются сложности, которые мы видим достаточно часто при ручном ведении SRS:
➜ документ SRS устарел и не отражает текущую конфигурацию системы;
➜ отсутствуют связи между требованиями, тестами и другими доказательными материалами;
➜ нет понятной иерархии требований;
➜ отсутствует прослеживаемость требований на разных стадиях проекта;
➜ изменения требований не отслеживаются;
➜ разработчик не может ответить на вопрос: "все ли требования взяты в работу?".

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

🎯 Инструмент управления требованиями сам по себе не обеспечивает функциональную безопасность. Однако отсутствие такого инструмента требует ещё более строгой дисциплины и наличия зрелого процесса менеджмента ФБ (FSM).

❓ А как у вас ведутся требования ФБ — в специализированной системе или вручную? Используете ли отечественные или open-source системы?

🗂 Зачем нужны шаблоны в ФБ?
Иногда шаблоны документов функциональной безопасности (плана безопасности, SRS, отчётов, протоколов, руководств и др.) воспринимают как «формальность для аудитора». Но на практике шаблон — это не просто оформление документа. Это часть системы менеджмента ФБ (FSM).

📌 ГОСТ Р МЭК 61508 и ГОСТ Р ИСО 26262 не требуют конкретных «шаблонов» как файлов Word или Excel. Но они требуют управляемой, согласованной и проверяемой доказательной базы по ФБ. Поэтому для зрелого FSM шаблоны — это не просто удобство.

🔍 Шаблоны ФБ помогают:
➜ не забыть обязательные разделы, ограничения и допущения;
➜ обеспечить единый подход к основным документам FSM;
➜ заранее определить основные входы и выходы между связанными документами;
➜ обеспечить готовность к проверке;
➜ ускорить работу над новым документом ФБ.
Шаблоны также являются частью того или иного процесса ФБ (например, управления изменениями).

⚠️ Важно: при сертификации менеджмента ФБ обычно смотрят не только на наличие процедур, но и на то, как они реально применяются. Поэтому наличие и качество шаблонов тоже становятся предметом внимания.

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

🎯 Вывод: Хорошие шаблоны не заменяют экспертизу. Но они помогают сделать функциональную безопасность регламентированной, проверяемой и менее зависимой от памяти конкретного специалиста.

✅ Разбор викторины по PFH
Правильный ответ — 3.
Давайте коротко разберём все варианты.
1️⃣ PFH ≠ PFDavg / T.
PFDavg применяется для режима с низкой частотой запросов и отражает среднюю вероятность опасного отказа по запросу. Простое деление PFDavg на интервал контрольной проверки не превращает один показатель в другой.

2️⃣ PFH не становится эквивалентным PMHF при переобозначении λ.
Да, оба показателя имеют размерность 1/ч, но логика расчёта, а также смысл различных интенсивностей отказов в МЭК 61508 и ИСО 26262 различаются. Нельзя просто взять скрытые, остаточные и одиночные отказы из ИСО 26262 и обозначить их как λDU в терминах МЭК 61508.

3️⃣ PFH в МЭК 61508 — это средняя частота опасного отказа в час для режима с высокой частотой запросов или непрерывного режима работы.
Это корректный вариант ответа. При этом сама аббревиатура PFH иногда сбивает с толку: буква P подталкивает к слову probability / вероятность , хотя в контексте МЭК 61508 речь идёт именно о частоте.
🔍 Нюанс: строго говоря, PFH(t) можно трактовать как мгновенную частоту / ROCOF опасных отказов в момент времени t. А отношение среднего числа опасных отказов за интервал (0; t) к длительности этого интервала t — это среднее значение PFH на интервале (0; t). Если частота возникновения опасных отказов постоянна во времени, мгновенное и среднее значения совпадают.

4️⃣ PFH не всегда равно λDU.
Для простой 1oo1-архитектуры в упрощённой модели PFH действительно может быть близко к λDU. Но в общем случае PFH зависит от архитектуры, диагностики, CCF и других параметров. Например, упрощённая формула PFH для 1oo2 при соблюдении ряда условий, среди которых, в том числе, и отcутствие ССF, ≈λDU²·T.

🎯 Вывод:
PFH — это не «вероятность в час», не PFDavg/T, не PMHF под другим названием и далеко не всегда просто λDU. Это средняя частота опасного отказа в час.

📊 Пятничная викторина по ФБ: обсудим PFH

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

1️⃣ PFH — средняя вероятность опасного отказа в час.
Это то же самое, что PFDavg, делённое на T, где T — интервал контрольной проверки.
2️⃣ PFH в МЭК 61508 эквивалентно PMHF в ИСО 26262, если правильно переобозначить интенсивности отказов.
Для этого все интенсивности скрытых, остаточных и одиночных отказов в терминах ИСО 26262 нужно обозначить как λDU в терминах МЭК 61508.
3️⃣ PFH — средняя частота опасного отказа в час.
А PFH(t) — это отношение среднего числа опасных отказов за интервал (0; t) к самому t.
4️⃣ Значение PFH в упрощённом варианте всегда равно интенсивности опасных необнаруженных отказов λDU независимо от архитектуры системы.

❓ Какой вариант выбираете?
Полные формулировки не помещаются в варианты Telegram-опроса, а сокращать их до потери смысла не хотелось. Поэтому ниже — анонимный опрос только с номерами ответов: 1, 2, 3 или 4. 👇

❓ «Отказ по общей причине» или «отказы по общей причине»?

Прошлый пост о зависимых отказах вызвал обсуждение за рамками мессенджера. В том числе подняли интересный вопрос: как всё-таки корректнее говорить — отказ по общей причине или отказы по общей причине?

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

🔍 Однако в функциональной безопасности мы часто смотрим не только на уровень компонентов, но и на уровень системы, выполняющей функцию безопасности.
Например: приборная функция безопасности не была выполнена системой безопасности с многоканальной архитектурой из-за общей причины.
В таком контексте можно говорить об отказе SIF /функции безопасности вследствие общей причины. Здесь в фокусе уже итоговое событие — отказ функции или системы.

📚 Во многих стандартах ФБ (МЭК 61508, МЭК 62061, МЭК 61131-6, ISO 13849-1) ООП определяется в единственном числе. На наш взгляд, это связано с тем, что ООП рассматривается в контексте отказа системы безопасности / выполнения функции безопасности вследствие общей причины. В этой связи интересно 4-е издание ISO 13849-1:2023, где также появляется формулировка в единственном числе. Причём, в ISO 13849-1:2023 в определении CCF сделали замену "system failure" на "failure of a safety function" - как раз с акцентом на отказе функции безопасности, чтобы не было неоднозначности (в отечественном стандарте ГОСТ ISO 13849-1-2014, который является переводом более раннего издания ISO 13849-1:2006, формулировка другая).

🎯 В инженерной практике важно не просто выбрать «правильный» термин, а явно указать уровень анализа и применяемый стандарт. В одних стандартах ФБ определение ООП привязано к многоканальной архитектуре, в других - сформулировано более широко. Однако во многих стандартах ФБ отказ по общей причине рассматривается как результат воздействия одной или нескольких причин/событий, вследствие чего функция безопасности не выполняется.

А какой вариант вы считаете наиболее корректным?
1️⃣ «Отказ по общей причине» — потому что речь об отказе системы / SIF.
2️⃣ «Отказы по общей причине» — потому что отказывают несколько компонентов или каналов.
3️⃣ Оба варианта допустимы, но для разных уровней анализа