Логотип компании СКБ АВТОАМТИКА
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.

Промышленная автоматика

Стандарт IEC 61508 — фундамент, на котором построена вся современная промышленная безопасность. Именно на его формулах рассчитывают вероятность отказа систем противоаварийной защиты (ПАЗ), по его таблицам определяют уровни SIL, на его сертификаты ссылаются производители. Стандарт воспринимается как истина в последней инстанции — нечто, не подлежащее сомнению.

Но что, если этот фундамент имеет трещины?

Автор «Справочника инженера по АСУТП» Юрий Фёдоров провёл детальный анализ математического аппарата IEC 61508 и пришёл к выводам, которые ставят под сомнение корректность стандартных формул. Речь идёт не о мелких погрешностях, а о системных ошибках, которые приводят к завышению или занижению расчётных значений вероятности отказа — в некоторых случаях в разы.

Проблема усугубляется тем, что подавляющее большинство инженеров и проектировщиков используют формулы стандарта «как есть», не задумываясь об их выводе и границах применимости. Как отметил Jouko Järvi: «без объяснения пользователи используют формулы без полного понимания их смысла и ограничений». А Julia Bukowski прямо предупредила: «легко неправильно применить упрощённое уравнение к ситуации, которая не соответствует предположениям, необходимым для его справедливости».

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

Главный тезис

Стандарт IEC 61508 корректен только для нулевого уровня диагностического охвата (DC=0). Для реальных систем с DC > 0 (а современные системы имеют DC 90–99%) стандартные формулы дают систематическую ошибку — вплоть до 100%.

Часть 1. Как стандарт предлагает считать вероятность отказа

Два режима работы системы безопасности

Стандарт IEC 61508 различает два режима работы ПАЗ:

Режим низких требований

Частота запросов на срабатывание защиты — не более одного раза в год. Основной показатель — PFD: средняя вероятность отказа выполнения требуемой функции.

Режим высоких требований / непрерывный

Частота запросов — больше одного раза в год. Основной показатель — PFH: средняя интенсивность опасных отказов в час.

Оба показателя связаны с интенсивностью опасных отказов λ и архитектурой системы. Казалось бы, всё логично.

Стандартные формулы для базовых архитектур

Для архитектуры 1oo2 (два канала, достаточно сигнала одного) стандарт предлагает:

PFD ≈ (λDU · Ti)² / 3

где λDU — интенсивность опасных необнаруженных отказов, Ti — межповерочный интервал.

Для архитектуры 2oo3 (три канала, голосование «два из трёх»):

PFD ≈ 3 · (λDU · Ti)² / 3

Для архитектуры 1oo2D (два канала с перекрёстной диагностикой):

PFD ≈ 2 · [(1-β)·λDU]² · tCE · tGE + β·λDU · (Ti/2 + MTTR)

где β — фактор отказов общего порядка, tCE и tGE — характеристические времена.

Формулы громоздкие, но их вывод в стандарте не приводится. Аналитик вынужден принимать их на веру.

В чём подвох

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

PFDсистемы ≈ PFDдатчиков + PFDлогики + PFDклапанов

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

Часть 2. Ошибка первая: PFD — это не вероятность

Среднее значение произведения не равно произведению средних

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

Но PFDavg — это среднее значение функции во времени, а не фиксированная вероятность. И среднее значение произведения двух функций не равно произведению их средних значений.

Признание самого стандарта (Приложение B)

«PFDavg не обладает теми же свойствами, что и настоящая вероятность, и его отождествление с настоящей вероятностью, вероятно, приведёт к неконсервативным результатам».

«Обычные вероятностные вычисления (сложения и умножения) больше не действительны для расчётов PFDavg (интегралов) параллельных частей».

Это прямое признание: формулы стандарта некорректны для параллельных структур. А ведь именно параллельные структуры — основа резервирования, то есть основа безопасности.

Пример расхождения

Рассмотрим простейший случай: два независимых защитных слоя, каждый с вероятностью отказа PFD₁ и PFD₂.

Если следовать логике стандарта «наивного» перемножения:

PFDсистемы = PFD₁ · PFD₂

Но точное значение:

PFDсистемы = (1/T) · ∫₀ᵀ PFD₁(t) · PFD₂(t) dt

И это не одно и то же. Как показано в диссертации Fares Innal, для двух защитных слоёв с одинаковым межповерочным интервалом T₁:

RRFexact / RRFstd = 7/6 ≈ 1,17

То есть стандартный подход даёт заниженный (оптимистичный) результат примерно на 17%. А если интервалы тестирования разные, отклонение может достигать 4/3 ≈ 1,33, то есть 33%.

Вывод автора диссертации

«Этот метод ошибочен, потому что среднее значение произведения математических функций (PFD(t) в данном случае) не равно произведению средних значений этих функций».

Часть 3. Ошибка вторая: игнорирование недоступности при тестировании

Система «слепнет» во время проверки

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

Когда вы проводите тестирование датчика, клапана или логического устройства, система не может выполнить свою функцию защиты. Если в этот момент произойдёт реальное отклонение процесса, защита не сработает.

Fares Innal в своей диссертации приводит конкретный пример: система с тремя датчиками, которые тестируются одновременно. На время тестирования (1 час) модуль обнаружения превышения давления становится недоступным — «слепым». Это увеличивает общую недоступность системы и, соответственно, PFDavg.

Из диссертации Fares Innal

«Недоступность компонентов во время их периодических тестов не учитывается в аналитической модели, потому что продолжительность тестов для данного компонента интегрирована в его MDT».

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

Насколько велика ошибка

Сравнение аналитических формул стандарта с точными моделями (деревья отказов, сети Петри) показывает:

Численное значение PFDavg, полученное из деревьев отказов и сетей Петри, в 3 раза больше, чем полученное по аналитической формуле стандарта.

Это не погрешность округления — это системная ошибка, которая может привести к выбору архитектуры с недостаточным уровнем безопасности.

Часть 4. Ошибка третья: двойной стандарт для обнаруженных и необнаруженных отказов

Проблема с tCE

В формулах стандарта для архитектуры 1oo2D присутствует параметр tCE — характеристическое время, связанное с обнаруженными отказами. Стандарт определяет его через интенсивности λDU, λDD и λSD:

tCE = [λDU/(λDU+λDD+λSD)] · (Ti/2 + MTTR) + [λDD/(λDU+λDD+λSD)] · MTTR

Но анализ показывает, что для архитектуры 1oo2D это некорректно. В этой архитектуре ни один отдельный канал не может привести систему в опасное состояние при обнаруженном опасном или безопасном отказе. Обнаруженный отказ в одном канале приводит к отключению этого канала, но система продолжает работать через второй канал.

Следовательно, параметры λDD и λSD не должны появляться в выражении для tCE. Правильное выражение:

tCE = Ti/2 + MTTR

Проблема с βD·λDD·MTTR

Ещё более серьёзная ошибка — присутствие в формуле 1oo2D члена βD · λDD · MTTR — вклада обнаруженных отказов общего порядка.

Стандарт сам утверждает, что при обнаружении отказов в обоих каналах система переводится в безопасное состояние. Тогда член βD·λDD·MTTR не должен существовать — он описывает ситуацию, которая в архитектуре 1oo2D физически невозможна.

Итог по 1oo2D: три исправления в формулу стандарта

Анализ, проведённый Fares Innal, показывает: формула PFD для архитектуры 1oo2D в IEC 61508-6 требует следующих исправлений:

  1. Удалить член βD · λDD · MTTR.
  2. Удалить λDD и λSD из выражения для tCE.
  3. Заменить множители (1-βD) и (1-β) на единицу в члене, описывающем переходы из критических состояний.

Эти ошибки приводят к искажению расчётной вероятности отказа — в одних случаях завышению, в других занижению — в зависимости от соотношения интенсивностей отказов.

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

Модель β-фактора слишком проста

Стандарт IEC 61508 для учёта отказов общего порядка (Common Cause Failure, CCF) предлагает простейшую модель β-фактора: доля β от общей интенсивности отказов приходится на события, которые выводят из строя все каналы одновременно.

Но эта модель не различает архитектуры.

Из отчёта SINTEF

«Модель не позволяет "двойному" CCF произойти в троированной системе… Таким образом, она не будет различать конфигурации 1oo2, 1oo3 и 2oo3: все три конфигурации будут иметь одинаковую интенсивность CCF».

Это абсурд. Система с двумя каналами и система с тремя каналами должны иметь разную уязвимость к отказам общего порядка. Но модель β-фактора этого не видит.

Проблема оценки β

Ещё хуже обстоит дело с определением самого коэффициента β. Стандарт не даёт чётких указаний, как его оценивать. Для систем без явного анализа отказов общего порядка предлагается значение β = 10%.

Но на практике для клапанов и исполнительных механизмов:

Реальность против стандарта

«β для конечных элементов (таких как отсечные клапаны) более 10%».

Это означает, что стандартные расчёты занижают вклад CCF для исполнительных механизмов — наиболее критичных элементов с точки зрения безопасности.

Модель CCF в IEC 61508 — это компромисс, упрощение, которое в ряде случаев приводит к неконсервативным результатам. Аналитик, использующий стандартные формулы «как есть», рискует получить оптимистичную оценку вероятности отказа — что для систем безопасности недопустимо.

Часть 6. Ошибка пятая: формула PFH для комбинированных систем

Проблема с суммированием

Для режима высоких требований стандарт предлагает определять PFH системы как сумму интенсивностей отказов подсистем:

PFHсистемы = PFHдатчиков + PFHлогики + PFHклапанов

Но это допущение неверно для резервированных структур. Как показано в отчёте SINTEF, формула IEC для PFH отклоняется от точной формулы для архитектур 1oo2, 2oo3 и других, начиная с N=2.

Проблема с MTTR

Ещё одна фундаментальная ошибка: стандартные формулы PFH включают MTTR — среднее время восстановления — через параметр tCE.

Но MTTR характеризует время, в течение которого система недоступна после отказа. Он влияет на готовность, но не на частоту опасных отказов.

Позиция SINTEF

«С нашей точки зрения, MTTR не должен включаться в PFH, поскольку нет деградированной работы системы безопасности во время ремонта одного критического компонента. Таким образом, MTTR вносит вклад в недоступность системы, но не в частоту опасных отказов системы».

Включение MTTR в PFH завышает расчётное значение, делая результат пессимистичным — но при этом некорректным.

Часть 7. Ошибка шестая: неопределённость определения PFH

«Вероятность отказа в час» — что это значит?

Стандарт IEC 61508 определяет PFH как «вероятность опасного отказа в час». Но это определение двусмысленно. Fares Innal объясняет:

Из диссертации Fares Innal

«Это определение двусмысленно, потому что оно даёт неверное представление о том, что частота отказов и интенсивность отказов — эквивалентные понятия».

Стандарт предлагает два разных способа расчёта PFH, которые не эквивалентны:

Способ 1: суммирование

Суммирование интенсивностей отказов подсистем — не учитывает реальную архитектуру системы и приводит к завышению эквивалентной интенсивности отказов.

Способ 2: деление

Деление вероятности отказа за время миссии на время миссии — не имеет строгого обоснования и приводит к парадоксальным результатам: при увеличении времени миссии PFH стремится к нулю, что физически бессмысленно.

PFH, рассчитанный по формулам стандарта, может быть завышен (при использовании первого способа) или некорректно занижен (при использовании второго). И то, и другое — недопустимо для систем безопасности.

Часть 8. Ошибка седьмая: предположение о постоянной интенсивности отказов

Экспоненциальное распределение — не универсальный закон

Все аналитические формулы IEC 61508 предполагают, что интенсивность отказов λ постоянна во времени. Это означает экспоненциальное распределение наработки до отказа — классическая модель для электронных компонентов.

Но это допущение не выполняется для компонентов, подверженных износу. Как отмечается в материалах семинара CERN:

Из материалов семинара CERN

«Большинство аналитических формул для расчёта PFD и PFH предполагают постоянную интенсивность отказов. Это предположение не обязательно справедливо для компонентов системы, подверженных износу… Эти аналитические формулы предполагают постоянные интенсивности отказов, и их несуществование [в реальности]…».

Для механических компонентов — клапанов, приводов, уплотнений — характерна возрастающая интенсивность отказов (износ) или убывающая (приработка). Использование экспоненциальной модели для них приводит к некорректным результатам.

Часть 9. Авторские формулы: точный расчёт для произвольных архитектур

Что предлагает Фёдоров

Юрий Фёдоров в своей книге предлагает альтернативный подход к расчёту вероятности отказа, свободный от ошибок стандарта. Он выводит общие соотношения для архитектур MooN, которые отсутствуют в IEC 61508.

Для случая обнаружения опасного отказа только при автономном тестировании (DC = 0):

PFDMooN[DC=0] = C(n, n−m+1) · (λDU · Ti)n−m+1 / (n−m+2)

где C(n, n−m+1) — число сочетаний (n−m+1) отказавших каналов из n.

Для случая полного диагностического охвата (DC = 1):

PFDMooN[DC=1] = C(n, n−m+1) · (λDD · MTTR)n−m+1

Интенсивность опасных отказов:

PFHMooN[DC=1] = (n−m+1) · C(n, n−m+1) · (λDD)n−m+1 · MTTRn−m

Эти формулы корректны для любых архитектур и любого уровня диагностического охвата — в отличие от стандартных формул, которые работают только для DC=0.

Проверка на базовых архитектурах

Сравним результаты для архитектуры 1oo2 (n=2, m=1):

МетодФормулаРезультат
СтандартPFD ≈ (λDU · Ti)² / 3Занижение в 1,5 раза
ФёдоровPFD = C(2,2) · (λDU · Ti)² / 2= (λDU · Ti)² / 2

Стандарт даёт заниженный результат в 1,5 раза (делит на 3 вместо 2). Это — оптимистичная ошибка: система кажется безопаснее, чем есть на самом деле.

Для архитектуры 2oo3 (n=3, m=2):

МетодФормулаРезультат
СтандартPFD ≈ 3 · (λDU · Ti)² / 3= (λDU · Ti)²
ФёдоровPFD = C(3,2) · (λDU · Ti)² / 3= (λDU · Ti)²

Здесь результаты совпадают — для этой архитектуры стандарт корректен.

Главный вывод

Стандарт IEC 61508 корректен только для нулевого уровня диагностического охвата (DC=0). Для реальных систем с DC > 0 (а современные системы имеют DC 90–99%) стандартные формулы дают систематическую ошибку.

Часть 10. Таблицы сравнения: стандарт vs точные решения

PFD для случая DC=0 (обнаружение только при тестировании)

АрхитектураСтандарт IECТочное решениеОтклонение
1oo1λDU·Ti/2λDU·Ti/20%
1oo2(λ·Ti)²/3(λ·Ti)²/2−33% (занижение)
2oo2λ·Tiλ·Ti0%
2oo3(λ·Ti)²(λ·Ti)²0%
1oo3(λ·Ti)³/4(λ·Ti)³/3−25% (занижение)

PFD для случая DC=1 (немедленное обнаружение)

АрхитектураСтандарт IECТочное решениеОтклонение
1oo1λ·MTTRλ·MTTR0%
1oo22λ²·MTTR²λ²·MTTR²+100% (завышение)
2oo22λ·MTTR2λ·MTTR0%
1oo2D0λ²·MTTR²−100% (занижение)
2oo36λ²·MTTR3λ²·MTTR+100% (завышение)

Шокирующая статистика

Шесть из десяти соотношений стандарта для DC=1 дают неправильный результат. А ведь именно DC=1 — целевой уровень для современных систем безопасности.

Часть 11. Что это значит для практики

Последствия для выбора архитектуры

Если стандартные формулы дают ошибку в 1,5–3 раза, то выбор архитектуры по этим формулам может быть неверным.

Пример из практики

Система 1oo2 с PFD по стандарту = 10⁻⁴ (SIL3). По точным формулам PFD = 1,5·10⁻⁴ (граница SIL2/SIL3). Вы выбираете архитектуру, думая, что обеспечиваете SIL3, но фактически находитесь на границе.

Последствия для сертификации

Производители сертифицируют оборудование по стандартным формулам. Если формулы завышают или занижают PFD, сертификат может не соответствовать реальности.

Что делать инженеру

  1. Не доверять стандартным формулам слепо. Использовать их как первое приближение, но проверять точными методами (Монте-Карло, Марков, деревья отказов).
  2. Учитывать недоступность при тестировании. Если датчики тестируются одновременно, это снижает доступность системы.
  3. Использовать консервативные оценки. Если точный расчёт сложен, выбирать параметры с запасом — но помнить, что запас — не решение проблемы.
  4. Требовать от производителей обоснование расчётов. Если производитель предоставляет PFD без вывода формул — это красный флаг.
  5. Учитывать полевой уровень. Ошибки в расчёте PFD для контроллера могут быть малы по сравнению с неопределённостью надёжности датчиков и клапанов.

Часть 12. Критика оппонентов и ответ на неё

Аргумент: «Стандарт проверен временем»

Да, стандарт существует с 1998 года. Но это не значит, что его формулы корректны. Fares Innal, автор диссертации по функциональной безопасности, отмечает: «Рекомендация [о необходимости проверки формул] подтверждается заявлениями других авторов в том же направлении».

Аргумент: «Ошибки малы и не влияют на результат»

Это неверно. Отклонения в 1,5–3 раза — это не «малая погрешность». Они могут привести к выбору архитектуры с недостаточным SIL.

Аргумент: «Марковские модели невозможны для сложных систем»

Это правда — полные марковские модели для реальных систем громоздки. Но сети Петри и имитационное моделирование позволяют получить точные оценки без громоздких аналитических выкладок. Современные вычислительные средства делают это доступным.

Часть 13. Практические рекомендации

Чек-лист: что делать с расчётами по IEC 61508

Выполнено 0 из 9
  • Используйте стандартные формулы только как оценку «сверху» — помните, что для DC > 0 они могут давать заниженный результат.
  • Для критических функций безопасности проводите точный расчёт с помощью имитационного моделирования (сети Петри, Монте-Карло).
  • Документируйте все допущения и обосновывайте выбор формул — со ссылками на источник и границы применимости.
  • Требуйте от подрядчика не только итоговые значения PFD, но и методику расчёта с выводом формул.
  • Проверяйте консервативность расчётов: если PFD системы близок к границе SIL — это повод для пересмотра.
  • Учитывайте полевой уровень — ошибки в расчёте контроллера могут быть перекрыты неопределённостью надёжности датчиков.
  • Не ограничивайтесь стандартными формулами — проводите верификацию точными методами для SIL2/SIL3.
  • Запрашивайте полные данные о надёжности: λDU, λDD, DC, β — без них расчёт неполон.
  • Требуйте прозрачности методик от производителей: PFD без вывода формул — красный флаг.

Заключение: стандарт — не истина, а инструмент

IEC 61508 — это огромный шаг вперёд для промышленной безопасности. Он создал единый язык, единые критерии, единый подход. Но, как любой инструмент, он не идеален.

Систематические ошибки в формулах для PFD и PFH — это не мелкие опечатки, а фундаментальные методологические проблемы. Они приводят к:

Занижение PFD

Для архитектуры 1oo2 — до 33%.

Завышение PFD

Для 1oo2D — до 100%.

Некорректный учёт CCF

Отказы общего порядка моделируются без различия архитектур.

Игнорирование недоступности

Система «слепнет» во время тестирования — стандарт это не учитывает.

Двусмысленность PFH

Два разных способа расчёта дают разные результаты.

Эти ошибки не делают стандарт бесполезным. Они делают его требующим критического осмысления. Использовать стандарт — значит понимать его ограничения и знать, где искать точные решения.

Как писал Юрий Фёдоров

«Стандарты МЭК — призыв к осмотрительности».

Осмотрительность — это не отказ от стандарта. Это использование его с открытыми глазами.