Дерево причин при аварийной остановке агрегата: как построить и не ошибиться

Аварийная остановка агрегата — это всегда цепочка событий, а не одно «сломалось». Дерево причин нужно, чтобы развернуть эту цепочку в наглядную схему: от самого факта остановки вниз к исходным условиям, решениям и отказам, которые её вызвали. Главный принцип такой работы: сначала фиксируются только подтверждённые факты, и лишь потом выдвигаются гипотезы о связях между ними. Если начать с версии «виноват оператор» или «заводской брак», анализ превратится в поиск доказательств под готовый вывод, а настоящая причина останется невыясненной.

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

Зачем нужно дерево причин и когда его строить

Дерево причин (в инженерной практике близко к методу анализа дерева отказов, Fault Tree Analysis) — это графическая модель, в которой нежелательное событие раскладывается на комбинации более простых событий через логические операторы «И» и «ИЛИ». Для разбора аварийной остановки это даёт три вещи:

• Объективность. Схема заставляет отделять наблюдаемые факты от предположений: каждое звено либо подтверждено данными, либо помечено как гипотеза.
• Полноту. Ветвление через «ИЛИ» показывает альтернативные сценарии, которые иначе легко упустить: одна и та же остановка могла быть вызвана разными путями.
• Работоспособные выводы. Корректирующие меры привязываются к конкретным узлам схемы, а не к общим фразам вроде «усилить контроль».

Строить дерево имеет смысл не для каждой остановки. Если агрегат остановился по известному срабатыванию защиты с очевидной причиной (например, сработало реле давления из-за трещины трубопровода), достаточно короткого акта расследования. Полноценное дерево оправдано, когда:

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

Шаг 1. Зафиксировать состояние до начала анализа

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

1. Запретить демонтаж, разборку и ремонт узлов, причастных к событию, до фиксации их положения и состояния фотографиями и схемами.
2. Выгрузить архивы АСУ ТП, регистраторов, защит и систем видеонаблюдения; отметить границы записей по времени.
3. Снять и сохранить показания приборов, положение арматуры, состояние предохранительных устройств, следы на деталях (нагар, задиры, разрушения, утечки).
4. Опросить персонал по отдельности, пока воспоминания свежие, и записать ответы дословно, без редактирования «в удобную формулировку».
5. Зафиксировать режим работы агрегата перед остановкой: нагрузку, параметры среды, изменения настроек, незадолго до этого выполненные работы.

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

Шаг 2. Правильно сформулировать вершинное событие

Вершина дерева — это само нежелательное событие, которое будет объясняться. Ошибка на этом шаге искажает всё дерево. Типичные проблемы формулировок:

• Слишком широко. «Авария на установке» — такое событие невозможно разложить на конкретные ветви, оно объединяет разные сценарии.
• Слишком узко. «Разрушился подшипник насоса» — если подшипник сам является промежуточным звеном, вершина заранее отсекает причины выше по цепочке.
• Смешение события и причины. «Остановка из-за ошибки оператора» — вывод уже встроен в формулировку, анализировать нечего.

Рабочая формулировка описывает наблюдаемое событие с привязкой ко времени и месту: «Аварийная остановка компрессора №3 по срабатыванию защиты от превышения температуры подшипников 12 мая в 14:37». Такое событие можно проверить по записям, у него есть точный момент начала, и оно допускает ветвление: почему выросла температура, почему защита сработала именно так, почему ситуация не была замечена раньше.

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

Шаг 3. Разложить событие на ветви через логику «И» и «ИЛИ»

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

• «ИЛИ» — любое из перечисленных событий по отдельности вызывает верхнее. Пример: температура подшипника выросла ИЗ-ЗА недостатка смазки, ИЛИ из-за повышенной нагрузки, ИЛИ из-за неисправности датчика (ложное срабатывание).
• «И» — верхнее событие наступает только при одновременном сочетании нижних. Пример: разрушение узла произошло, ЕСЛИ возникла недопустимая нагрузка И отсутствовала защита, способная её ограничить.

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

Глубина разложения определяется практической целью. Спускаться имеет смысл до уровня событий, которые можно подтвердить или опровергнуть фактами: конкретный отказ детали, конкретное действие или бездействие, конкретное условие эксплуатации. Дальше начинается бесконечное дробление («износ произошёл из-за трения, трение — из-за движения…»), которое ничего не добавляет к выводам.

Пример фрагмента дерева

Условный пример для остановки насосного агрегата по защите от сухого хода:

Уровень	Событие	Логика перехода
Вершина	Аварийная остановка насоса по сигналу «сухой ход»	—
Уровень 1	Уровень жидкости в приёмной ёмкости упал ниже допустимого ИЛИ датчик уровня дал ложный сигнал	«ИЛИ»
Уровень 2 (ветвь А)	Расход превысил приток ИЛИ не сработала защита ёмкости от минимального уровня	«ИЛИ»
Уровень 3 (ветвь А)	Защита отключена для ремонта И не была включена обратно после окончания работ	«И»

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

Шаг 4. Подтверждать или помечать каждую ветвь

Дерево строится в двух состояниях: рабочая версия и проверенная схема. Каждому узлу присваивается статус:

• Подтверждено — есть объективные данные: запись АСУ ТП, результат осмотра, лабораторный анализ, документ.
• Опровергнуто — данные исключают эту версию; такие ветви оставляют в схеме с пометкой, чтобы показать полноту рассмотренных вариантов.
• Гипотеза — правдоподобно, но данных нет; требуется дополнительная проверка.

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

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

• Подгонка под версию. Команда начинает с мнения «кто виноват» и включает в дерево только подтверждающие ветви. Признак проблемы: в схеме нет ни одной опровергнутой ветви — значит, альтернативы всерьёз не рассматривались.
• Остановка на человеке. Финальной причиной назначают «ошибку оператора». Вопрос «почему это действие было возможно и почему система не предотвратила его?» остаётся без ответа, и мера «провести инструктаж» не защищает от повтора.
• Перепутанные уровни. В одну ветвь сваливают события разных масштабов: «износ втулки» рядом с «плохой организацией ТО». Каждый уровень должен отвечать на вопрос «что непосредственно привело к событию выше», а не «что вообще связано с темой».
• Игнорирование оператора «И». Все связи оформляются как «ИЛИ», из-за чего теряется главное: аварии почти всегда требуют совпадения отказа и неработающего барьера.
• Анализ без данных. Дерево рисуют по памяти через неделю после события, когда оборудование уже отремонтировано. Восстановить картину становится невозможно.
• Меры не привязаны к узлам. По итогам пишут общий список пожеланий. Каждое корректирующее действие должно закрывать конкретный узел или связь в дереве — тогда понятно, что именно оно предотвращает.

Как проверить качество готового дерева

Перед утверждением схемы полезно пройтись по контрольным вопросам:

1. Вершина сформулирована как наблюдаемое событие с местом и временем, без встроенного вывода?
2. Каждая связь обоснована: можно объяснить механизм, по которому нижнее событие приводит к верхнему?
3. Рассмотрены ли альтернативные сценарии, даже если они опровергнуты? Есть ли в дереве ветви со статусом «опровергнуто»?
4. Хотя бы одна цепочка доведена до первопричины и подтверждена данными на каждом шаге?
5. Для каждого узла с сочетанием «И» понятно, какой барьер отсутствовал или отказал?
6. Каждая корректирующая мера ссылается на конкретный узел, и устранение этого узла действительно разрывает путь к вершине?
7. Схема выдерживает проверку обратным ходом: двигаясь снизу вверх по подтверждённой цепочке, вы получаете ровно то событие, которое наблюдалось, без дополнительных допущений?

Полезна и независимая проверка: человек, не участвовавший в расследовании, читает дерево и пытается объяснить по нему, что произошло. Если ему требуются пояснения «на словах», схема неполна.

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

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

1. Выделите все подтверждённые узлы вдоль реализовавшейся цепочки.
2. Для каждого определите тип меры: устранить источник (заменить узел, изменить режим), восстановить или добавить барьер (защита, блокировка, сигнализация), исправить процедуру (порядок вывода защиты в ремонт, контроль возврата), изменить условия (обучение, штат, надзор).
3. Приоритизируйте меры, стоящие ближе к началу цепочки: они устраняют причину, а не симптом. Но не отбрасывайте барьерные меры — они защищают от похожих сценариев по другим ветвям.
4. Назначьте ответственных и сроки, а через согласованный период проверьте выполнение и отсутствие повторов события.

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

Что делать дальше

Если перед вами стоит задача разобраться в конкретной аварийной остановке, начните не с построения схемы, а с сохранения данных: зафиксируйте состояние оборудования, выгрузите архивы и опросите персонал. Затем сформулируйте вершинное событие точно и нейтрально, разложите его на ветви через «И» и «ИЛИ», честно разделяя факты и гипотезы, и не останавливайтесь на уровне «человеческой ошибки» — идите до условий, которые сделали ошибку возможной. Готовое дерево проверьте по контрольному списку выше и превратите в перечень мер, привязанных к конкретным узлам.

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

Материал носит информационный характер и описывает общий порядок анализа инцидентов. Конкретные требования к расследованию аварий, составу комиссий и документам определяются отраслевыми нормами и внутренними регламентами организации; при существенных последствиях инцидента принимайте решения с участием профильных специалистов.