Как построить дерево причин при аварийной остановке агрегата: алгоритм, логика и типичные ошибки

Аварийная остановка агрегата — это не просто срабатывание защиты, а отказ системы управления рисками. Дерево причин (Fault Tree Analysis, FTA) позволяет восстановить логическую цепочку от вершины события (Top Event) до базовых причин, разделяя совокупность факторов на необходимые и достаточные условия. В отличие от линейного «5 почему», дерево фиксирует параллельные ветви и комбинации отказов, что критично для сложных технологических объектов.

Главный принцип: дерево строится дедуктивно — от последствия к причинам. Каждый узел разбивается на непосредственные предшественники через логические вентили И (AND) и ИЛИ (OR). Качество анализа определяется не объёмом схемы, а точностью определения вершины события, полнотой исходных данных и дисциплиной применения логики. Ниже — пошаговый алгоритм, применимый на любом производстве.

Подготовка: команда, данные и определение вершины события

Начинать построение схемы до сбора фактов — гарантированный путь к вымышленным причинам. Минимальный состав команды: инженер процесса/технолог (знает режимы), инженер КИПиА/автоматики (читает логи контроллеров), оператор панели (видел картину в момент остановки), представитель службы безопасности/ТБ (оценивает организационные факторы). Привлечение узких специалистов (вибродиагност, трубопроводчик, электрик) происходит по мере углубления ветвей.

Необходимый пакет данных к началу работы:

• Протокол аварийной остановки с временными метками (журнал событий SCADA/DCS, реле защиты, черный ящик ПЛК).
• Схемы принципиальные (P&ID), функциональные (FDS), логические (Cause & Effect Matrix), электрические однолинейные.
• Уставки срабатываний защиты и блокировок с указанием задержек и логики голосования (1oo2, 2oo3).
• Записи оператора/сменного инженера (устные и письменные) — фиксируются в первый час после события.
• История неисправностей агрегата за последние 6–12 месяцев (повторяющиеся алармы, дрифт параметров, временные ремонты).

Определение вершины события (Top Event) — самый ответственный момент. Формулировка должна быть конкретной, измеримой и привязанной ко времени. Неправильно: «Аварийная остановка компрессора». Правильно: «Срабатывание аварийной остановки компрессора К-101 по сигналу высокой вибрации на подшипнике втулкового 2-го ступени (датчик VIB-102, уставка 7.5 мм/с) 15.03.2024 14:23:12». Чёткая вершина исключает размывание анализа на смежные режимы и не связанные срабатывания.

Пошаговый алгоритм построения дерева

1. Фиксация вершины. Разместите определенное Top Event в вершине схемы. Назначьте ему уникальный идентификатор (например, TE-01).
2. Первый уровень разложения (непосредственные причины). Ответьте на вопрос: «Какие условия должны были выполниться СИМУЛЬТАННО или АЛЬТЕРНАТИВНО, чтобы это событие произошло?». Используйте только данные из журналов и схем, а не догадки. Каждому условию присвойте ID (IE-01, IE-02…).
3. Назначение логических вентилей. Соедините вершину с первым уровнем через вентиль И (все условия обязательны) или ИЛИ (достаточно любого). Если логика голосования защиты 2oo3 — это вентиль И для пары каналов, вложенный в ИЛИ для комбинаций пар. Ошибка в выборе вентиля на первом уровне перевернёт всё дерево.
4. Рекурсивное углубление. Для каждого промежуточного события (Intermediate Event) повторяйте шаги 2–3. Двигайтесь вниз, пока не достигнете базовых событий (Basic Events) — отказов элементарных компонентов (датчик, клапан, кабель, действие человека, внешнее воздействие), которые не требуют дальнейшего разложения в рамках данного анализа.
5. Классификация базовых событий. Пометьте каждый базовый событие категорией: Оборудование (HW), Программное обеспечение/Логика (SW), Человеческий фактор (HF), Процедура/Документация (PR), Внешняя среда (EN). Это нужно для статистики и выбора мер.
6. Документирование обоснований. К каждому узлу прикрепите ссылку на источник: тег журнала (timestamp, tagname), пункт схемы (P&ID rev.X), пункт инструкции, показания прибора, фотофиксация. Узел без доказательной базы — гипотеза, подлежащая проверке, а не факт.
7. Остановка разложения. Прекращайте спуск вниз, когда: а) достигнут корневой компонент; б) дальнейшее деление не меняет набор корректирующих мер; в) отсутствуют данные для подтверждения/опровержения. Не разводите дерево до уровня «кварк внутри транзистора микроконтроллера».

Логические вентили И и ИЛИ: как не запутаться

Понимание разницы между необходимым и достаточным условием — основа корректного дерева. Вентиль ИЛИ (OR) означает: событие сверху произойдёт, если произойдёт ХОТЯ БЫ ОДНО из событий снизу. Причины альтернативны, они конкурируют. Пример: срабатывание защиты по высокому давлению ИЛИ по высокой температуре — достаточно одного признака.

Вентиль И (AND) означает: событие сверху произойдёт ТОЛЬКО ЕСЛИ произойдут ВСЕ события снизу одновременно (или в заданном временном окне). Причины дополняют друг друга. Классический пример — отказ системы голосования 2oo3: нужно одновременное срабатывание (или отказ) любого пары из трёх каналов. Здесь вентиль И соединяет пары каналов, а верхний уровень — ИЛИ соединяет три возможные пары (1&2, 1&3, 2&3).

Типичная ошибка — использование ИЛИ там, где физика процесса требует И. Например: «Разрыв трубопровода» — это ИЛИ (коррозия ИЛИ удар Арие ИЛИ дефект сварки). Но «Несрабатывание ПАЗ на разрыв» — это И (датчик не сработал И логика не выдала команду И клапан не закрылся). Путаница приводит к завышению или занижению вклада отдельных факторов.

Сложные конструкции: Исключающее ИЛИ (XOR) — взаимно исключающие причины (редко в FTA, чаще в.Event Tree). Вентиль PRIORITY AND — строгая временная последовательность (событие А должно произойти РАНЬШЕ события Б). Используйте их только если временная логика критична для воспроизведения аварии и подтверждена логами с миллисекундной точностью.

Работа с базовыми событиями: оборудование, человек, процедуры

Базовые события — листья дерева. Их формулировка должна быть в форме отказа: «Датчик давления PT-101 не выдаёт сигнал при превышении уставки», а не «Плохой датчик». Чёткость формулировки определяет целесообразность меры. Разбирайте каждую категорию по своим правилам.

• Оборудование (HW). Указывайте конкретный тег, режим отказа (нет сигнала, ложный сигнал, дрифт, заклинивание, пробой изоляции). Проверяйте: соответствует ли режим отказа данным журнала? Есть ли история дефектов на этом теге? Совпадает ли серийный номер с паспортным?
• Программное обеспечение/Логика (SW). Фиксируйте версию ПО контроллера, хеш конфигурации, конкретный блок функции (FB) или рунг ледер-диаграммы. Частая причина — недокументированное изменение логики при вводе в эксплуатацию или несовпадение уставок в ПЛК и в проекте SCADA.
• Человеческий фактор (HF). Не пишите «ошибка оператора». Разделяйте: пропуск действия (не нажал кнопку), ошибочное действие (открыл не тот клапан), нарушение процедуры (работал без разрешения), некомпетентность (не знал уставку). Каждый подтип требует разной меры: переобучение, изменение интерфейса, изменение процедуры, администрирование доступа.
• Процедуры/Документация (PR). Отсутствие инструкции, противоречие между ПТЭ и схемой, устаревшая ревизия схемы на пульте, отсутствие пункта проверки в чек-листе ППР. Это системные причины, устранение которых закрывает сразу группу базовых событий.
• Внешняя среда (EN). Питание (просадка напряжения, глюки сети), климат (конденсат в кабельном канале, перегрев щита), вибрация от соседнего агрегата, химическая агрессия среды. Часто упускаются, так как не видно в журналах агрегата.

Валидация дерева: нисходящий и восходящий проходы

Построенное дерево — гипотеза. Её нужно провалидировать двумя независимыми проходами.

1. Нисходящий проход (Top-Down): От вершины к листьям. Вопрос: «Если реализуются ВСЕ базовые события данной ветви (с учётом вентилей), гарантированно ли произойдёт Top Event?». Если нет — дерево неполно (пропущена причина) или вентиль выбран неверно. Проверяйте каждую ветвь до листьев.
2. Восходящий проход (Bottom-Up): От листьев к вершине. Вопрос: «Если реализуется ЭТО базовое событие, к какому промежутоному событию оно ведёт и далее — к вершине?». Это выявляет «висячие» листья, не влияющие на Top Event, и дублирующие ветви. Также проверяет полноту покрытия всех известных режимов отказа компонентов.

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

Типичные ошибки построения и их последствия

• Подмена вершины события симптомом. Анализируют «сработал реле защиты» вместо «сработал реле защиты ПО ПРИЧИНЕ реального превышения давления». Результат: меры по замене реле, а реальная утечка не устранена.
• Смешивание временных последовательностей в одной ветви. В одной ветви И стоят «утечка упаковки» и «срабатывание датчика газа». Датчик сработает ПОСЛЕ утечки, но для Top Event (пожар) нужны И утечка, И источник зажигания, И неработающая вентиляция. Временная логика нарушена — меры не попадают в цель.
• Игнорирование латентных отказов. Дерево строится только по активным отказам момент аварии. Упускают: «резервный клапан был закорожен за месяц до аварии» (латентный отказ). Без учёта латентных отказов дерево не объясняет, почему защита не сработала.
• Обобщение «человеческий фактор» без детализации. Лист «Ошибка оператора» не даёт меры. Нужно: «Оператор не опознал аварийный режим за 30 сек из-за отсутствия визуализации на mimic-диаграме» — мера: доработка SCADA.
• Отсутствие ссылок на доказательную базу. Узел «Коррозия трубопровода» без ссылки на УЗК/рентген/фото — слух. Такие узлы помечайте «Требует подтверждения» и выносите в план проверок, не выдавайте за факт.
• Построение дерева в одиночку. Один инженер не держит в голове всю логику процесса, автоматики и эксплуатации. Коллективная валидация — единственный способ убрать слепые зоны.

От дерева причин к корректирующим действиям: иерархия эффективности

Дерево причин само по себе не устраняет риск. Каждый подтверждённый базовый.event требует меры. Приоритизируйте меры по иерархии (от наиболее к наименее эффективной):

1. Исключение опасности (Elimination). Конструктивное изменение, устраняющее возможность отказа. Пример: замена датчика с контактной группой на бесконтактный, исключающий заклинивание.
2. Замена/Снижение риска (Substitution/Reduction). Переход на более надёжный принцип действия, снижение критичности. Пример: установка дублирующего датчика с голосованием 2oo2 вместо 1oo1.
3. Инженерные барьеры (Engineering Controls). Автоматические защиты, блокировки, аварийные сливы, ПАЗ. Не зависят от человека в момент аварии.
4. Административные барьеры (Administrative Controls). Процедуры, чек-листы, обучение, разрешения, ППР, инструкции по аварийным действиям. Работают только при дисциплине.
5. Средства индивидуальной защиты (PPE) / Знаки / Обучение. Последняя линия, не предотвращающая аварию, а митигирующая последствия для человека.

Для каждого базового события формулируйте меру максимально высокого доступного уровня. Если можно устранить конструктивно — не ограничивайтесь инструкцией. Фиксируйте в плане мер: ответственное лицо, срок, критерий закрытия (проверка результата), статус. Мера без срока и ответственного — намерение, не действие.

Условный пример: аварийная остановка центрифужного компрессора по вибрации

Top Event (TE-01): Аварийная остановка К-101 по высокой вибрации VIB-102 (2-я ступень, уставка 7.5 мм/с) 15.03 14:23.

Уровень 1 (OR): IE-01: Реальная вибрация > 7.5 мм/с. IE-02: Ложный сигнал датчика VIB-102. IE-03: Ошибка логики ПЛК (ложное срабатывание блока сравнения).

Ветвь IE-01 (AND): IE-01.1: Нарушение динамической балансировки ротора (сборка грязи/коррозия) И IE-01.2: Работа в зоне резонанса (частота вращения совпала с критической). Данные: спектр вибрации показывает 1х и 2х гармоники, рост амплитуды 3 недели.

Ветвь IE-02 (OR): IE-02.1: Отказ питания датчика (пробой кабеля). IE-02.2: Механическое поврешение пьезокерамики (удар при ППР). IE-02.3: ЭМИ от пускового устройства соседнего двигателя (нет экранирования). Журнал: нет обрыва сигнала, есть скачки амплитуды синхронно с пуском соседа.

Ветвь IE-03 (AND): IE-03.1: Несовпадение уставки в ПЛК (7.5) и в проекте SCADA (8.0) И IE-03.2: Отсутствие проверки согласованности при вводе ревизии ПО v.4.2.

Валидация: Нисходящий проход: ветвь IE-02.3 подтверждена логами (пуск соседа в 14:22:50). Ветвь IE-01 подтверждена трендом. Ветвь IE-03 подтверждена аудитом конфигурации. Восходящий проход: все листья ведут к TE-01. Висячих листьев нет.

Меры (пример): 1) Очистка ротора/балансировка (Elimination для IE-01.1). 2) Проверка/ремонт экранирования кабелей VIB-102 (Engineering для IE-02.3). 3) Внедрение процедуры верификации уставок ПЛК/SCADA при любом изменении ПО (Administrative для IE-03.1/IE-03.2).

Инструменты и оформление документации

Для разовых анализов достаточно Excel/Visio или draw.io с библиотекой символов FTA (IEC 60617 / ISA 5.1). Для системного управления рисками на объекте применяют специализированное ПО: Isograph FaultTree+, Item ToolKit, PHA-Pro, RiskSpectrum, или модули АПРС/ЕАМ (IBM Maximo, SAP PM, Meridium) с встроенным FTA. Главное — единый репозиторий схем, версионирование (ревизия дерева привязана к ревизии P&ID и ПО ПЛК) и связка с системой управления инцидентами (Incident Management).

Обязательные артефакты итогового пакета:

• Схема дерева причин в векторном формате (PDF/SVG) с ID узлов и вентилями.
• Таблица узлов (Node Register): ID, описание, тип (TOP/Intermediate/Basic), вентиль выше, категория (HW/SW/HF/PR/EN), статус (Подтверждён/Гипотеза/Исключён), источник доказательства.
• План корректирующих и предупреждающих действий (CAPA) с привязкой к базовым событиям.
• Протокол валидации (подписи участников, дата нисходящего/восходящего проходов, замечания и их закрытие).

Материал носит информационный характер и описывает общую методологию построения дерева причин (FTA) для аварийных остановок промышленных агрегатов. Конкретные требования к расследованию инцидентов, составу комиссии, срокам, форме отчётности и правовым последствиям определяются действующим законодательством (ФЗ-116, ПТЭ, отраслевые нормативы), внутренними регламентами организации и классом опасности производственного объекта. При анализе реальных аварий на объектах I–II класса опасности обязательно привлекайте уполномоченных экспертов промышленной безопасности и следуйте утверждённым процедурам расследования.

Следующий шаг: от анализа к системному улучшению

Построение дерева причин завершено не тогда, когда нарисована схема, а когда закрыты все меры по базовым событиям и проведена проверка эффективности (follow-up) через 3–6 месяцев. Используйте накопленную базу деревьев для поиска системных слабых мест: повторяющиеся категории базовых событий (например, частые отказы кабелей на вибрации или системные ошибки версионирования ПО) указывают на дефекты процессов управления надежностью, закупок, ППР или управления изменениями (MOC). Регулярный разбор портфеля деревьев причин на совещаниях по надежности (RAMS review) переводит реактивное расследование в проактивное управление целостностью актива.