Экспертный канал по функциональной безопасности. Реальный опыт TÜV, IEC 61508, ISO 26262, IEC 61784-3, ISO 13849-1, IEC 62061. Разборы кейсов, типовые ошибки, практика сертификации и аудита. Канал ведёт компания «FUNCSAFETY» https://func-safety.ru.
Иногда функциональную безопасность пытаются объяснить просто: «Чем выше SIL/ASIL, тем надёжнее система». Звучит убедительно — но некорректно.
Надёжность — это свойство объекта сохранять способность выполнять требуемые функции в заданных условиях эксплуатации. Соответственно, вероятность безотказной работы — это вероятность того, что отказ в пределах заданной наработки не возникнет.
А что такое SIL и ASIL?
SIL — это дискретный уровень (1–4) по МЭК 61508, МЭК 61511 и др., соответствующий диапазону значений полноты безопасности. Для аппаратной части он напрямую связан с вероятностью опасного отказа функции безопасности при необходимости её выполнения (PFDavg и/или PFH), а также с архитектурными ограничениями, зависящими от SFF и HFT. ASIL — это дискретный уровень (A–D) по ИСО 26262, определяющий требуемую строгость мер безопасности и инженерных требований к устройству или элементу для предотвращения неоправданного риска. В части случайных аппаратных отказов достижение ASIL подтверждается архитектурными метриками (SPFM, LFM) и либо вероятностной оценкой (PMHF), либо EEC-методом.
И SIL, и ASIL задают требования к обеспечению функциональной безопасности, а не являются показателями надёжности оборудования. Можно спроектировать систему с высоким MTBF — и при этом получить недопустимо высокий риск из-за недиагностируемых опасных отказов. Можно, наоборот, использовать элементы с умеренной общей надёжностью — но за счёт архитектуры, обнаружения и обработки отказов достичь требуемого SIL/ASIL.
Если свести функциональную безопасность к «повышению надёжности», теряется сама идея ФБ: мы управляем опасными отказами (МЭК 61508, МЭК 61511, МЭК 62061 и др.) или отказами, приводящими к нарушению цели безопасности (ИСО 26262), и риском, а не просто уменьшаем количество отказов.
❓ Считаете ли вы, что путаница между надёжностью и функциональной безопасностью — это вопрос терминологии или отражение более глубокой проблемы в понимании роли SIL/ASIL?
Грядёт 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»?
Функциональная безопасность редко «ломается» на уровне формул, таблиц или расчётов. Она ломается тогда, когда остаётся на бумаге.
ГОСТ Р ИСО 26262, ГОСТ Р МЭК 61508 и другие стандарты ФБ часто воспринимают как набор документов: план безопасности, FMEA, FMEDA, HARA, FSC, TSC, Safety Case, РФБ и т.д.
Но в реальности функциональная безопасность — это не «документики и расчётики», как любят говорить некоторые специалисты при первом знакомстве с ФБ. Это: ✓ встраивание процессов ФБ в систему качества ✓ изменение процессов разработки ✓ пересмотр архитектуры HW и SW, а не косметические правки ✓ решения по ответственности, независимости, управлению изменениями и многое другое.
Если процессы остались прежними, а безопасность просто «описали» — она не заработает. Именно поэтому функциональная безопасность важна во всех отраслях: от старейших областей промышленной автоматизации, где ошибки могут копиться годами и проявляться внезапно, до новейших и стремительно развивающихся направлений — ИИ и беспилотных технологий, где сложность и неопределённость только растут.
ФБ — это не только про соответствие стандарту. Это про снижение рисков в реальных инженерных системах и, как результат, уменьшение количества аварий, катастроф и человеческих жертв. В этом канале мы будем говорить именно об этом: о практике и теории функциональной безопасности, о том, где и почему она не работает — и что с этим делать.
Функциональная безопасность: практика и аудит pinned «Мы запускаем этот канал, потому что видим одну и ту же проблему снова и снова. Проекты не соответствуют требованиям ФБ или соответствуют формально, т.е. документы есть, но функциональной безопасности по сути нет. За годы работы в аудитах и консалтинге мы…»
Мы запускаем этот канал, потому что видим одну и ту же проблему снова и снова.
Проекты не соответствуют требованиям ФБ или соответствуют формально, т.е. документы есть, но функциональной безопасности по сути нет.
За годы работы в аудитах и консалтинге мы видели десятки таких случаев. И почти всегда причина не в стандарте, а в том, как его понимают и применяют.
В этом канале мы будем разбирать практику функциональной безопасности: реальные ошибки, логику аудиторов, инженерные решения с опорой на нормативную базу.
Если вы работаете с ГОСТ Р МЭК 61508, ГОСТ Р ИСО 26262, ГОСТ Р МЭК 61511, безопасностью коммуникационных протоколов, безопасностью машин (safety of machinery), или просто отвечаете за safety — этот канал для вас.
