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

🧩 Зависимые отказы в функциональной безопасности

Зависимым отказам в функциональной безопасности отводится особая роль, т.к. часто причиной отказа функции безопасности является именно зависимый отказ.

📌 К таким отказам относятся отказы, которые нельзя рассматривать как статистически независимые: это могут быть отказы по общей причине (CCF) или каскадные отказы. Причём зависимые отказы возможны не только в аппаратных средствах, но и в программном обеспечении.

🔍 В ГОСТ Р МЭК 61508 при расчёте PFDavg/PFH для многоканальных архитектур учитывается вклад отказов по общей причине. Для этого используется β-фактор: часть опасных отказов рассматривается как отказ по общей причине, из-за которой могут отказать несколько каналов одновременно. Оценку β-фактора можно выполнять, например, с использованием методик и таблиц, приведённых в МЭК 61508 или МЭК 62061. Иногда количественный вклад CCF настолько велик, что это побуждает разработчиков системы сменить архитектуру, использовать диверсификацию и т.п.

🧠 Однако не все зависимые отказы можно учесть количественно. Для аппаратных средств часть таких отказов можно оценить через β-фактор и аналогичные модели, а, например, для ПО анализ носит качественный характер. Именно поэтому анализ зависимых отказов нельзя сводить только к расчёту. Например, в ISO 26262 есть отдельный результат работы — отчёт по анализу зависимых отказов.

🧬Отдельно стоит выделить каскадные отказы, при которых отказ одного элемента становится причиной отказа второго, третьего и так далее. Такие зависимости особенно важны при анализе ПО на архитектурном уровне. Иногда результат такого анализа — изменение архитектуры ПО.

⚠️ В реальных проектах зависимые отказы часто записывают в предположения/ограничения системы даже при правильно проведённом анализе: т.е. предполагается, что такой отказ произойти не может, потому что "мы не допустим такой режим эксплуатации», «это будет исключено организационными мерами» и т.д. Однако по мере развития проекта бывает так, что эти предположения теряются или забываются. И тогда то, что когда-то было важным ограничением, превращается в незакрытый риск.

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

🔧 PFDavg/PFH "слишком низкие": ошибка или нормальный результат?

🧠 Недавно обсуждали оценку PFDavg с одним производителем КИП, который только начинает работать с ФБ. Коллеги никак не могли понять, как у отечественных конкурентов и зарубежных производителей получаются такие низкие значения PFDavg: «Не может у них быть таких низких значений — они это всё придумали!» Выяснилось, что коллеги рассматривали полную интенсивность отказов и не учитывали специфику ФБ, где важно помимо базовой интенсивности отказов, знать типы отказов и их диагностируемость.

🧷 Например, если полная интенсивность отказов компонента λ = 3 FIT, то для расчётов ФБ сначала нужно определить долю опасных отказов. Условно примем, что λd = 1,5 FIT. Если диагностический охват DC = 90%, то λdd = 1,35 FIT и λdu = 0,15 FIT. Именно λdu — интенсивность опасных необнаруженных отказов — в значительной степени определяет результат расчёта PFDavg для режима с низкой частотой запросов. После корректного разделения отказов и учёта диагностируемости в FMEDA анализе у коллег расчёты «вдруг» стали сопоставимы с тем, что показывают другие производители.

🔍 Похожая ситуация часто возникает и в контексте ГОСТ ISO 13849-1. Многие удивляются, почему MTTFd может быть примерно в два раза больше MTTF. Но здесь тоже нет никакой магии: в ГОСТ ISO 13849-1 часто используется допущение, что примерно 50% отказов являются опасными, а 50% — безопасными. Тогда интенсивность опасных отказов оказывается примерно в два раза ниже полной интенсивности отказов, а MTTFd, соответственно, примерно в два раза выше MTTF.

⚠️ Функциональная безопасность действительно опирается на теорию надёжности, но не сводится к ней. Для расчётов ФБ принципиально важно разделять отказы по типам и учитывать их диагностируемость.

🚫 Типичная ошибка — считать PFDavg напрямую от общей интенсивности отказов без анализа видов, последствий отказов и их диагностируемости. Но есть и обратная крайность: когда производитель необоснованно завышает DC или слишком оптимистично классифицирует отказы как безопасные / обнаруженные. И вот это уже действительно может привести к искусственно заниженным значениям PFDavg и PFH.

🎯 Низкое значение PFDavg само по себе далеко не всегда является подозрительным. Подозрительным оно становится тогда, когда за ним нет корректного анализа отказов, обоснованной классификации отказов с оценкой диагностического охвата и прозрачного расчёта.

С Днём Победы!

🧪 Зачем нужен FMEDA-анализ и кто его должен проводить?

FMEDA — это анализ видов, последствий и диагностируемости отказов.

📌 Главная цель FMEDA — показать, как отказы аппаратных компонентов влияют на выполнение функции безопасности: какие отказы являются безопасными; какие — опасными; какие отказы обнаруживаются диагностикой и за счёт каких диагностических механизмов; а какие отказы и вовсе не имеют влияния на безопасность. На основе такого анализа определяются, в частности, интенсивности опасных обнаруженных и опасных необнаруженных отказов, а также исходные данные для оценки PFDavg, PFH (по МЭК 61508) и, например, для оценки PMHF (по ИСО 26262).

‼️ После продолжительной работы за рубежом в области ФБ для нас было несколько удивительно столкнуться с мнением некоторых отечественных органов по сертификации, что FMEDA-анализ якобы должен выполнять орган по сертификации. На наш взгляд это методически неверное понимание распределения ролей в функциональной безопасности.

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

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

🚫 Отсюда, возможно, и появился миф, что FMEDA — это нечто искусственное, что нужно сделать «для сертификата». На практике это формирует у производителей неправильную привычку: не разбираться в собственных отказах и диагностике, а ждать, что кто-то «сделает FMEDA под сертификацию».

▶️ На самом деле FMEDA нужен прежде всего самому изготовителю — чтобы понимать, насколько его оборудование действительно пригодно для применения в системах безопасности, насколько эффективно обнаруживаются отказы, и есть ли опасные отказы, для которых не предусмотрено никакой диагностики.

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

🌿 1 мая — День труда. А у нас небольшой вопрос к профессиональному сообществу.

👷Функциональная безопасность — это всегда командная работа инженеров по ФБ, проектировщиков, разработчиков, тестировщиков, эксплуатации, аудиторов, руководителей проектов и других специалистов.

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

🚗 Заблокированные двери в электромобилях: где заканчивается комфорт и начинается безопасность?

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

➡️ Электронный замок e-latch, зависящий от 12V питания. Если питание пропало из-за повреждения цепей при аварии, дверь может просто не открыться 🚫

📌 Функция «обеспечить возможность покинуть автомобиль» — это не комфорт и не UX. Это функция безопасности, и она должна рассматриваться в HARA согласно ISO 26262. Если в HARA рассматривается отказ системы электронного отпирания/открытия двери после ДТП, одним из возможных опасных событий может быть невозможность эвакуации пассажира. В зависимости от оценок S/E/C такой сценарий может привести к формированию цели безопасности, например: "Дверь должна обеспечивать возможность выхода из автомобиля после ДТП при отказе электронного отпирания или потере 12V питания."

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

⚠️ На практике многие EV формально имеют аварийный механический рычаг, но он спрятан, неочевиден и требует «знания конструкции». В момент ДТП это почти эквивалентно его отсутствию.

📚 Существующие нормативы, например FMVSS 206 и требования UNECE, в первую очередь регламентируют удержание двери при ударе — чтобы пассажира не выбросило из автомобиля. То есть дверь должна быть «хорошо закрыта». Но сценарий эвакуации после аварии регулируется значительно слабее. Даже в рамках ISO 26262 такой сценарий может не попасть в HARA: его могут отнести, например, к post-crash.

📈 Однако ситуация меняется. Китай с 1 января 2027 года вводит запрет на скрытые дверные ручки и требует механическую функцию открывания дверей, кроме багажника; для ранее одобренных моделей предусмотрен переходный период до 1 января 2029 года.

🎯 Итог: e-latch превратил простую механическую функцию в E/E систему с отказами, зависимостями и необходимостью проведения HARA. Но эвакуация пассажира до сих пор часто остаётся «между стандартами».

❓ Как вы считаете: требование к доступному механическому открытию двери должно быть жёстко зафиксировано в ISO 26262 или это зона стандартов пассивной безопасности?

🌍🚫 Санкции и компонентная база с точки зрения ФБ

🧭Нам часто задают вопрос: «можно ли заменить санкционный сертифицированный согласно МЭК 61508/ИСО 26262 микроконтроллер/микропроцессор (MCU/MPU) на доступный по функционалу не сертифицированный аналог?»

В системах безопасности важен не сам MCU/MPU, а обоснование его применения в составе системы безопасности. Также важно задать вопрос: "разрабатывался ли данный не сертифицированный HW элемент в соответствии с требованиями ФБ, и какова вообще его роль в системе безопасности?"

➡️ МЭК 61508-2 достаточно лоялен к требованиям к серийно выпускаемым чипам с точки зрения систематических отказов: «Настоящий стандарт не содержит конкретных требований, касающихся предотвращения систематических ошибок во время проектирования серийно выпускаемых электронных интегральных схем, таких как стандартные микропроцессоры, так как вероятность ошибок в таких устройствах минимизирована строгими процедурами разработки, строгим тестированием и обширным опытом использования со значительной информацией от пользователей».

Однако что касается случайных отказов, разработчику системы безопасности, как минимум, нужно будет запросить у производителя FMEDA-анализ чипа, проанализировать его архитектуру, изучить safety manual.

⚠️ А если чип не разрабатывался с учётом требований ФБ, фактически FMEDA-анализ, расчёт SFF, PFH, PFD нужно будет проводить разработчику системы безопасности своими силами: это едва ли возможно без предоставленной детальной документации от производителя, которая, скорее всего, отсутствует, если чип не разрабатывался согласно требованиям ФБ. Безусловно, для грубой оценки интенсивности отказов можно воспользоваться SN 29500 или другими справочниками надёжности, но анализ безопасности это не заменит.

➡️Что касается ИСО 26262, квалификация компонентов класса III, к которым относятся MCU/MPU, не является предпочтительным подходом, такие HW элементы должны быть разработаны в соответствии с ИСО 26262. Если дело всё-таки доходит до квалификации MCU/MPU, то, например, для TUV SUD многое зависит от того, реализует ли элемент механизм безопасности (SM), а также каков уровень ASIL: для ASIL C/D с SM такая квалификация сразу попадает в «красную зону» с обязательным аудитом производства вендора чипа, технической оценкой FMEA, FMEDA, DFA, применимостью аргумента серийно выпускаемого устройства и др. Фактически это означает «вторичную сертификацию» чипа в составе сертифицируемого устройства безопасности.

❓Что же тогда делать? Универсального ответа здесь нет. Есть разные решения, и все они рассматриваются индивидуально.

✅ На практике выход обычно ищут следующим образом: «обкладывают» MCU/MPU дополнительной диагностикой, вводят независимый мониторинг, применяют резервирование и перекрёстный контроль, перераспределяют safety-функции между элементами системы и т.д.

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

“As good as new” ("как новый") после проведения контрольной проверки: реальность или допущение?

🧠 В расчётах PFDavg для систем ПАЗ часто используется допущение: после проведения периодической контрольной проверки (proof test) устройство возвращается в состояние “as good as new” — как будто оно только что введено в эксплуатацию.

📌 Это не факт, а допущение, и оно далеко не всегда выполняется. Это допущение корректно только если proof test обнаруживает все опасные скрытые отказы (DU), т.е. 100%.
Возьмём устройство с интенсивностью опасных отказов λd=100 FIT, из которых λdd=10 FIT, а λdu=90 FIT. Предположим, что контрольная проверка выявляет 80% опасных скрытых отказов: это значит, что 18 FIT DU-отказов останутся невыявленными!

⚠️ На практике:
• охват контрольными проверками PTC < 100%
• часть отказов остаётся невыявленной
• возможны ошибки при ремонте / восстановлении

➡️ В этом случае устройство становится не “as good as new”, а скорее “as good as tested”.

📚Формулы PFDavg/PFH для архитектур голосования MooN в МЭК 61508 приведены с допущением полного восстановления после проведения контрольной проверки (PTC=100%), хотя в 6-м томе стандарта влияние неидеальных контрольных проверок рассматривается.

✅ Если предположение об «идеальности» контрольной проверки не верно (особенно «ощутимо» это для исполнительных механизмов), вводится параметр PTC – proof test coverage, который влияет на оценку PFDavg. У многих известных производителей КИП для СПАЗ параметр PTC указан в руководстве по функциональной безопасности (safety manual). А для клапанов часто вводится ещё и PVST (периодическая контрольная проверка клапана методом частичного хода).

💡 Чем “оптимистичнее” допущение для PTC, тем выше риск переоценки SIL.

❓ А вы в своих расчётах явно фиксируете это допущение, или PTC = 100% у вас обычно “подразумевается по умолчанию”?

📡 Количественная оценка ошибок искажения данных

❓ Знаете ли Вы, что коммуникационный протокол функциональной безопасности должен быть разработан с учётом коммуникационных мер безопасности? Причём, эти меры носят не только качественный, но и количественный характер?

▶️ Это значит, что недостаточно детектировать искажение, непреднамеренный повтор, неправильную последовательность, подмену, потерю, недопустимую задержку, вставку, неправильную адресацию на качественном уровне: есть и количественные требования к эффективности детектирования коммуникационных ошибок.

🧮 Во втором издании IEC 61784-3:2010 / ГОСТ Р МЭК 61784-3 -2015, на который ссылается ГОСТ Р МЭК 61508-2, приведена общая формула расчета вероятности остаточной ошибки целостности данных (Rcrc). Rcrc – вероятность того, что на пути передачи данных в коммуникационном канале произошла (хотя бы одна) битовая ошибка и она не была обнаружена получателем средствами используемого полинома CRC. Вся сложность расчёта данной ошибки заключается, прежде всего, в оценке коэффициента распределения кода Ai.

📚 Во втором издании издании МЭК 61784-3 показано, что для определенного класса так называемых «правильных» ("proper”) CRC полиномов применима аппроксимация коэффициента распределения кода Ai с весовым коэффициентом 2^-r (где r – количество бит CRC), так что величина Rcrc может быть вычислена приближенно. Однако проверка полиномов на правильность является отдельной аналитической задачей, требующей от инженеров соответствующей математической подготовки. А рекомендации по проверке полиномов на правильность второе издание стандарта не приводит.

🚫Что происходит на практике: инженер видит аппроксимационную формулу и просто использует её для расчёта, не проверяя на правильность полином, что приводит к излишне оптимистичным результатам (иногда на несколько порядков!) в случае использования аппроксимации для неправильных полиномов.

Доказательство «правильности» CRC полинома включает в себя вычисление коэффициентов распределения кода Ai. Именно поэтому в четвёртом издании IEC 61784-3:2021 аппроксимационная формула удалена, и оставлена только точная формула вычисления Rcrc с помощью расчёта коэффициентов распределения кода Ai. Задача оценки Ai не тривиальная, но вполне реальная.

🔗Если Вы интересуетесь темой коммуникационных протоколов функциональной безопасности, а также расчётом интенсивности остаточных коммуникационных ошибок, приглашаем ознакомиться с нашей статьёй в журнале "Автоматизация в промышленности".

👇 А здесь Вы можете посчитать Rcrc для некоторых популярных 16-битных CRC полиномов.

🚗 ISO 26262: safety case (обоснование безопасности), functional safety assessment (оценка функциональной безопасности) и safety manual (руководство по безопасности)

Бывает, что в практике ISO 26262 эти три понятия смешивают, хотя у них разное назначение.

Safety case ➡️ отвечает на вопрос: почему мы считаем, что функциональная безопасность достигнута?
Это структурированная аргументация, опирающаяся на требования, архитектуру, анализы, V&V и другие подтверждающие материалы.

Functional safety assessment (FSA) ➡️ отвечает на вопрос: согласна ли независимая сторона с тем, что эта аргументация и результаты действительно достаточны? То есть это уже не «наш комплект доказательств», а независимая оценка, причём требуемая степень независимости определяется стандартом и зависит от ASIL.

Safety manual ➡️ отвечает на вопрос: при каких условиях и каким образом компонент или SEooC могут быть корректно интегрированы в систему с точки зрения assumptions of use, внешних мер безопасности, диагностики, ограничений применения и связанных с ними требований безопасности. В нём обычно публикуются и основные показатели функциональной безопасности либо даются ссылки на соответствующе документы.

⚠️ Важно: в ISO 26262 safety case и functional safety assessment прямо укладываются в нормативную логику стандарта. А вот safety manual, который широко применяется в МЭК 61508, хотя и встречается в automotive очень часто (особенно для SEooC), как отдельный документ в ISO 26262 прямо не обозначен. Именно поэтому в аудиторской практике роль safety manual могут выполнять и другие документы, например safety application note или комплект документов с аналогичным назначением.

🚫 Типичная ошибка: считать, что safety manual «заменяет» safety case, или что functional safety assessment по сути и есть safety case.

🎯 Вывод:
Safety case — это аргументация достижения функциональной безопасности.
FSA — независимая оценка этой аргументации.
Safety manual — руководство по корректному safety-применению и интеграции.
Путать их — значит путать доказательство, оценку доказательства и условия безопасного применения.

❓ Часто ли вы встречаете в практике по ISO 26262 отдельный safety manual? Или эта информация у вас включается в состав других документов?

Функциональная безопасность: практика и аудит pinned «Мы ведём канал-дублёр в МАХ. Чтобы не потеряться: https://max.ru/join/6UQdRr-6zpm4sczOcJY4GvGKvEPZxifFvfEa-7ixdXE»

⚙️ Safety of machinery: fault exclusion — удобное допущение или дыра в аргументации?

В проектах по безопасности машин fault exclusion (исключение неисправности) иногда используют слишком легко: «этот отказ можно исключить, потому что он маловероятен». Именно здесь часто начинаются проблемы.

📌 Fault exclusion — это не “инженерное ощущение”, а обоснованное и ограниченное допущение.

Нельзя просто объявить отказ исключённым, если на это нет конструктивных, эксплуатационных и технических оснований. Особенно опасно так “упрощать” расчёт, когда без этого не сходятся PL или SIL-требования.

🚫 Типичная ошибка: исключать обрыв, изменение характеристик, короткое замыкание и т.д. без обоснованного объяснения со ссылкой на ГОСТ ISO 13849-1 и ГОСТ ISO 13849-2, почему такой сценарий действительно можно не учитывать.

🔍 Нюанс: чем больше fault exclusion в проекте, тем внимательнее аудиторы обычно смотрят на качество аргументации и границы применимости этих допущений.

✅ Из нашей зарубежной практики оценки ФБ: очень известная компания-производитель оборудования вынуждена была исключить из сертификата соответствие стандарту ISO 13849-1 только потому, что в анализе безопасности использовались в большом количестве fault exclusions для определённого типа резисторов, хотя для такого типа компонентов и такого вида отказа это допущение было некорректным. На практике мы рекомендуем каждый случай fault exclusion оформлять отдельно:
- какой именно отказ исключается и на каком основании;
- при каких условиях допущение остаётся корректным.

🎯 Вывод: fault exclusion допустим, но только там, где он действительно доказуем, а не просто удобен для расчёта.

Мы ведём канал-дублёр в МАХ. Чтобы не потеряться: https://max.ru/join/6UQdRr-6zpm4sczOcJY4GvGKvEPZxifFvfEa-7ixdXE

🧠 Машинное обучение в системах, связанных с безопасностью

В автомобильной отрасли машинное обучение (или ML), прежде всего, применяется для решения так называемых задач восприятия (perception problems) — например, обнаружения пешеходов и объектов на дороге.

Сегодня уже есть документы, дающие рекомендации по безопасному применению ML: среди них ISO/IEC TR 5469 (ПНСТ 836-2023) и ISO/PAS 8800. Однако по-прежнему остаётся открытым вопрос: как оценивать ошибки ML и учитывать их при проектировании, разработке и валидации safety-critical систем?

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

✅ Что помогает на практике:
1. Спецификация семантических данных
Это формализация того, какие именно объекты, события, условия и сценарии должны быть представлены в обучающих и тестовых данных, чтобы поведение модели соответствовало функциональным требованиям и ограничениям области применения.
2. Практический статистический анализ ML
Согласно ISO/PAS 8800, для ИИ в safety-critical задачах нельзя точно вычислить вероятность ошибки: обычно оценивают лишь наблюдаемую частоту ошибок на выборке данных, а связанную с ней неопределённость дополнительно учитывают через требования к безопасности. Такой анализ помогает оценить частоту ошибок, вероятные режимы отказа и границы применимости модели.
3. Онлайн-мониторинг производительности и дополнительные меры защиты
Если по результатам HARA видно, что ML используется в ситуации с высоким уровнем риска, одной модели недостаточно: нужны дополнительные независимые меры защиты. Также проводится верификация ML и непрерывный мониторинг ML.

🎯 Вывод: для ML в safety-critical применениях недостаточно показать хорошую среднюю производительность модели. Нужно обосновать, что ошибки модели в значимых сценариях выявлены, статистически оценены и компенсированы мерами безопасности.

❓ Как, по вашему мнению, корректнее учитывать ошибки ML в автомобильной и промышленной safety-практике: пытаться связывать их с классическими метриками PMHF / PFH / PFDavg, или для ML нужны отдельные подходы и отдельные критерии достаточности данных и статистической достоверности оценок?

🧪 Итоги викторины: 1oo2 vs 2oo3
Спасибо всем, кто проголосовал и оставил аргументы в комментариях.
Результаты голосования: 62% - за вариант 1, 38% - за вариант 2.
✅ Правильный ответ (при допущениях: одинаковые каналы + независимые отказы без учёта CCF) — вариант 1 (вероятность опасных отказов ниже у 1оо2, а вероятность ложных срабатываний ниже у 2оо3).

🧭 Что считаем “опасным отказом” и “ложным срабатыванием” системы (голосующей группы):
1. Опасный отказ возникает, когда есть запрос на выполнение функции безопасности, но система не может надлежащим образом выполнить функцию безопасности, хотя должна.
2. Ложное срабатывание возникает, когда функция безопасности активирована без реального запроса на её выполнение. Это стандартная трактовка для практики ПАЗ/МЭК 61511 (см. также, например, справочник Фёдорова Ю.Н.)
Для голосующей группы (1oo2 и 2oo3) опасный отказ и ложное срабатывание определяем через количество каналов, отдавших (или не отдавших) требуемый голос.

▶️ Пример c нормально-открытыми задвижками в архитектуре 1оо2: чтобы такая система не смогла выполнить переход в безопасное состояние (закрытое) необходимо, чтобы ОБЕ задвижки не смогли закрыться (логика И). Однако при ложном срабатывании этой же системы достаточно, чтобы ХОТЯ БЫ ОДНА задвижка закрылась (логика ИЛИ).

🧮 Обозначим:
· Pd — вероятность опасного отказа одного канала
· Pst — вероятность ложного “голоса за trip” одного канала
· C(n,k) — число сочетаний из n по k (сколько способов выбрать k каналов из n)

1) Опасные отказы (не сработать по требованию)
1oo2 (нужно, чтобы отказали оба канала):
Pd(1oo2)=Pd^2
2oo3 (нужно, чтобы отказали 2 из 3 или 3 из 3):
Pd(2oo3) = C(3,2)*Pd^2*(1-Pd) + C(3,3)*Pd^3=3*Pd^2-2*Pd^3
⇒ При 0<Pd<1: Pd(1oo2)<Pd(2oo3).

2) Ложные срабатывания (spurious trip)
1oo2 (достаточно, если ложный trip выдаст хотя бы один из двух каналов):
Pst(1oo2)=1-(1-Pst)^2=2*Pst-Pst^2
2oo3 (нужно, чтобы ложный trip выдали 2 из 3 или 3 из 3):
Pst(2oo3) = C(3,2)*Pst^2*(1-Pst) + C(3,3)*Pst^3=3*Pst^2-2*Pst^3
⇒ При 0<Pst<1: Pst(1oo2)>Pst(2oo3).

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

Сегодня завершается работа выставки «Нефтегаз». Было много интересных встреч и обсуждений по функциональной безопасности — в том числе и по резервированию оборудования. Казалось бы, тема давно известная, но споры не утихают.

📊 Предлагаем поучаствовать в опросе про вероятность опасных отказов и ложные срабатывания двух самых распространённых аппаратных архитектур: 1oo2 и 2oo3.

🧷P.S. Сравнение архитектур выполняется для одинаковых каналов и независимых отказов. При учёте отказов по общей причине (CCF) преимущества резервирования могут заметно снижаться — поэтому в реальном проекте всегда отдельно проверяем CCF-факторы.

🔧 Почему приборная система безопасности (ПСБ) в эксплуатации “живет своей жизнью”?

Проведены HAZOP, LOPA, установлен требуемый SIL и выполнены расчёты. Интервал контрольной проверки определён. РФБ (safety manual) датчиков, ПЛК и исполнительных механизмов изучены, сертификаты — в наличии.
А через год эксплуатации:
· появляются частые ложные срабатывания,
· защиты выводятся в bypass,
· выявляются случаи несрабатывания функций безопасности по запросу,
· интервалы контрольных проверок сдвигаются,
· параметры процесса меняются.

📌 Вопрос: сохраняется ли соответствие SIL, подтверждённое перед вводом в эксплуатацию?
Соответствие SIL контура ПСБ определяется при конкретных допущениях (интервал контрольной проверки, охват диагностикой, условия среды, конфигурация HW/SW, архитектура и др.). Если эти допущения нарушаются — расчёт уже не отражает реальность.

1️⃣ Bypass — это не просто временная мера. Каждый обход функции безопасности увеличивает риск при отсутствии адекватных компенсационных мер.
2️⃣ Интервал контрольной проверки (proof test) — не «рекомендация». Увеличение интервала напрямую влияет на значение PFDavg.
3️⃣ Несрабатывание функции безопасности по запросу. Частая причина — необнаруженные опасные отказы (DU), которые остаются скрытыми до момента запроса на выполнение функции безопасности (в т.ч. из-за недостаточной эффективности контрольных проверок, т.к. 100%-я эффективность таких проверок зачастую - идеализация).
4️⃣ Частые ложные срабатывания. Часто это индикатор проблем в настройке, диагностике, прикладной программе или архитектуре. Некоторые аппаратные архитектуры резервирования повышают отказоустойчивость, но увеличивают вероятность ложных срабатываний.
5️⃣ Конфигурация системы. На практике часто встречается требование «возможности on-line изменений» в программе без останова системы. Но для safety-логики это существенно повышает риск несрабатывания функции безопасности и/или ложных срабатываний. Любые изменения конфигурации (HW/SW) должны проходить через процедуру управления изменениями, анализ влияния на ФБ и, в соответствии с результатами анализа влияния, необходимую верификацию и/или валидацию. Исключения — только заранее регламентированные случаи (например, режим деградации, описанный в РФБ, при соблюдении определённых условий и ограниченного времени).

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

❓Какие факторы, на ваш взгляд, чаще всего приводят к расхождению между расчётным SIL и фактической эксплуатацией ПСБ?