Пять методов обеспечения надёжности для анализа отказоустойчивости промышленных систем

Почему для отказоустойчивости требуется нечто большее, чем резервное оборудование

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

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

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

Для этой работы особенно полезны пять методов. Анализ дерева отказов изучает, как сочетания отказов могут привести к заданному верхнему событию. Анализ видов и последствий отказов исследует, каким образом могут выходить из строя отдельные компоненты и как эти отказы влияют на систему в целом. Имитационное моделирование методом Монте-Карло исследует неопределённость во множестве возможных сценариев эксплуатации и отказов, а анализ первопричин выясняет, почему произошло фактическое событие. Марковские модели описывают, как ремонтопригодные системы со временем переходят между исправным, деградировавшим, отказавшим и восстановленным состояниями.

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

Надёжность, доступность, безопасность и ремонтопригодность — не одно и то же

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

Ремонтопригодность показывает, насколько эффективно можно диагностировать отказавшую систему и восстановить её работоспособность. Безопасность показывает, остаются ли отказы в пределах приемлемых уровней риска для персонала, окружающей среды и оборудования. Эти свойства влияют друг на друга, но улучшение одного из них автоматически не улучшает все остальные. Защитное отключение может снизить доступность производства, одновременно значительно повысив безопасность установки.

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

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

Выбор метода по инженерному вопросу

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

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

Правильный выбор зависит от поставленного вопроса. Команда, исследующая возможные причины полной потери охлаждения, обычно начинает с FTA. Проектная команда, проверяющая все возможные отказы датчиков, контроллеров и клапанов, получит больше пользы от FMEA. Управляющий активами, сравнивающий неопределённые интервалы технического обслуживания, может использовать моделирование методом Монте-Карло, а инженер по надёжности, рассчитывающий долгосрочную готовность пары резервированных контроллеров, может предпочесть марковскую модель.

Эти методы дополняют друг друга, а не являются взаимозаменяемыми. FMEA может выявить виды отказов, которые впоследствии станут базовыми событиями в дереве отказов. Результаты RCA могут скорректировать нереалистичные предположения об отказах в марковской модели. Моделирование методом Монте-Карло может проверить, как неопределённость вероятностей влияет на выводы, полученные с помощью FTA или при планировании технического обслуживания.

Анализ дерева отказов начинается с последствия

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

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

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

Завершённое дерево даёт наглядное представление логики отказов. Оно позволяет специалистам по электротехнике, механике, контрольно-измерительным системам, технологическим процессам, техническому обслуживанию и безопасности рассматривать одну и ту же систему с общей точки зрения. Эта общая модель — одно из главных практических преимуществ FTA. Она упрощает выявление и оспаривание скрытых допущений до того, как они закрепятся в проекте.

Рисунок 2. Дерево отказов строится от заданного верхнего события в обратном направлении и выявляет сочетания отказов нижнего уровня, которые могут привести к нему.

Пошаговая разработка дерева отказов

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

Затем команда выявляет непосредственные причины. Полная потеря охлаждения может произойти из-за недоступности всех насосов, блокировки общего подающего коллектора или неправильного закрытия запорных клапанов. Каждая непосредственная причина подвергается дальнейшему разложению. Недоступность насоса может быть вызвана отказом двигателя, заклиниванием подшипника, потерей всасывания, отказом контроллера или потерей электропитания.

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

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

Минимальные сечения показывают наиболее опасные сочетания

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

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

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

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

Пример: избыточность насосов питательной воды котла, которая не является действительно независимой

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

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

Анализ может привести к нескольким практическим улучшениям. Раздельные источники электропитания могут снизить вероятность общей потери питания. Разнотипные измерения уровня могут уменьшить зависимость от одной технологии преобразователей. Независимые контуры управления, улучшенное ручное управление и более эффективный контроль всасывания могут повысить надёжность архитектуры без обязательного добавления ещё одного полного насосного агрегата.

Этот пример показывает, почему FTA полезнее простого подсчёта резервных устройств. Он позволяет оценить, сохраняют ли устройства независимость в реальных условиях эксплуатации. Он также показывает, где дополнительная сложность действительно повышает защищённость, а где лишь создаёт видимость защиты.

Где анализ дерева отказов работает хорошо — и где нет

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

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

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

Поэтому FTA наиболее эффективен как часть более широкой программы обеспечения надёжности. FMEA может предоставить подробные сведения о видах отказов компонентов, тогда как методы Маркова или Монте-Карло позволяют учитывать ремонт, последовательность событий и неопределённость. Ни одно дерево не следует рассматривать как полное представление всех возможных режимов поведения системы.

Анализ видов и последствий отказов начинается с компонента

Анализ видов и последствий отказов использует индуктивный подход. Вместо того чтобы начинать с конечного события, команда рассматривает элемент, функцию или этап процесса. Затем она выясняет, каким образом этот элемент может отказать и к каким последствиям каждый отказ приведёт на локальном уровне и для всей системы. Благодаря такой направленности FMEA особенно полезен на этапах проектирования и анализа оборудования.

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

FMEA заставляет команду описывать эти различия, а не просто фиксировать «отказ передатчика». Анализ также рассматривает существующие средства предотвращения и обнаружения. В ходе анализа могут быть выявлены диагностические средства, логика сравнения, функциональные испытания, аварийная сигнализация, обходные схемы или проверки оператором, снижающие последствия. Слабое обнаружение отказов часто оказывается не менее важным, чем исходный вид отказа.

Рисунок 3. FMEA оценивает отдельные виды отказов, их эффекты, тяжесть последствий и доступные средства контроля для их предотвращения или обнаружения.

Что должен содержать эффективный рабочий лист FMEA

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

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

Многие организации присваивают оценки тяжести последствий, вероятности возникновения и обнаруживаемости. Иногда эти значения перемножают, чтобы получить число приоритета риска. Это число может помочь расставить приоритеты, но не должно заменять техническое суждение. Разные сочетания оценок могут давать одинаковый результат, хотя их последствия принципиально различаются.

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

Пример: резервированные входы ПЛК с общей уязвимостью

Рассмотрим два канала дискретных входов, контролирующих один аварийный полевой выключатель. Архитектура кажется резервированной, поскольку сигнал поступает на два входа ПЛК. FMEA-анализ проверяет, действительно ли весь тракт сигнала независим. Он учитывает полевой контакт, проводку, питание входов, клеммные сборки, модули, логику и диагностическое поведение.

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

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

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

FMEA конструкции и FMEA процесса рассматривают разные риски

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

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

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

Для критически важных систем автоматизации оба вида анализа следует обновлять после существенных изменений. Замена контроллера, переход на другую сетевую инфраструктуру, обновление программного обеспечения или изменение процедуры контрольного испытания могут привести к появлению новых видов отказов. Исторические рабочие документы не должны оставаться неизменными, пока предприятие продолжает развиваться.

FMECA предусматривает более формальную оценку критичности

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

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

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

FMECA наиболее полезен, когда его результаты приводят к действиям по изменению конструкции или техническому обслуживанию. Сложная таблица ранжирования малоценна, если она не влияет на архитектуру, состав запасных частей, диагностику, испытания или эксплуатационные процедуры. Цель по-прежнему заключается в практическом снижении риска, а не в расчетах ради самих расчетов.

Где FMEA эффективен — и где он может ввести в заблуждение

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

При применении к очень крупным системам метод может стать рутинным. Команды могут тратить чрезмерно много времени на документирование мало значимых видов отказов, упуская взаимодействия в системе. Традиционный FMEA также обычно рассматривает по одному отказу за раз. Несколько одновременных отказов и события, зависящие от последовательности, могут быть недостаточно четко выявлены.

Системы оценивания создают еще один риск. Команды могут корректировать оценки, чтобы получить желаемый приоритет, или считать итоговое число более объективным, чем лежащее в его основе суждение. Низкая оценка не доказывает, что отказ приемлем. События с высокой тяжестью последствий, отказы по общей причине и нормативные требования следует рассматривать отдельно.

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

Моделирование методом Монте-Карло превращает неопределенность в распределение

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

Инженер сначала создает модель системы и задает распределения вероятностей для неопределенных переменных. Затем моделирование генерирует множество возможных сочетаний. В одном прогоне может предполагаться, что насос выйдет из строя через 8 000 часов и будет отремонтирован в течение четырех часов. В другом прогоне отказ может произойти позже, но ремонт продлится гораздо дольше, поскольку необходимая запасная часть недоступна.

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

Рисунок 4. Моделирование методом Монте-Карло оценивает множество случайно сгенерированных сценариев отказов и ремонтов, чтобы определить диапазон возможных результатов.

Создание достоверной модели надежности методом Монте-Карло

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

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

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

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

Выбор распределений вероятностей, соответствующих механизму отказа

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

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

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

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

Пример: доступность станции с тремя компрессорами

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

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

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

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

Где моделирование методом Монте-Карло работает хорошо — и где оно даёт сбои

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

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

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

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

Анализ первопричин начинается после события

Анализ первопричин исследует, почему произошли фактический отказ, проблема с качеством или событие, связанное с безопасностью. Он выходит за рамки выявления повреждённого компонента. Двигатель может остановиться из-за заклинивания подшипника, но замена подшипника лишь восстанавливает работу. Расследование должно определить, почему подшипник пришёл в такое состояние.

К более глубоким причинам могут относиться загрязнение, неправильная смазка, ненадлежащее хранение, повреждение при монтаже, чрезмерная нагрузка на процесс или пропущенная проверка. Также могут способствовать организационные условия. Задачи технического обслуживания могли быть исключены, запасные части — оказаться неподходящими, а производственное давление — задержать выполнение корректирующих работ.

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

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

Доказательства необходимо сохранить до возвращения установки к нормальной работе

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

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

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

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

Составление временной шкалы событий до выяснения причин

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

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

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

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

Пример: повторяющиеся отказы приводов с регулируемой скоростью

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

Команда анализа первопричин сопоставляет даты отказов с данными об окружающей среде и техническом обслуживании. Большинство отказов произошло в жаркие летние периоды. Тренды температуры в шкафу показывают длительную работу за пределами предпочтительного диапазона. Осмотр выявляет засорённые фильтры, ограниченный поток воздуха и значительное скопление пыли вокруг системы охлаждения.

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

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

Корректирующие действия должны быть связаны с подтверждёнными причинами

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

Каждая мера должна быть направлена на подтвержденную причину или способствующее условие. Для нее должны быть назначены ответственный, срок выполнения и определенный метод проверки. Организация должна различать временное сдерживание последствий, корректирующую меру и долгосрочную профилактическую меру. Восстановление производства — не то же самое, что предотвращение повторения.

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

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

Человеческая ошибка редко бывает исчерпывающей первопричиной

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

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

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

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

Где анализ первопричин эффективен, а где — нет

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

Метод является реактивным, поскольку начинается после события. Отрасли с высокими последствиями отказов не могут полагаться только на извлечение уроков из отказов. Проактивные методы, такие как FMEA и FTA, по-прежнему необходимы. RCA должен дополнять их, обновляя предположения на основе фактических данных эксплуатации.

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

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

Марковские модели отслеживают изменения состояний системы

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

Интенсивность отказов может перевести систему из полностью рабочего состояния в состояние деградации. Еще один отказ может перевести ее из состояния деградации в состояние недоступности. Интенсивность восстановления может вернуть систему к полной работоспособности. Модель рассчитывает вероятность нахождения системы в каждом состоянии во времени.

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

Рисунок 6. Марковские модели описывают переходы систем между исправным, деградировавшим, отказавшим и восстановленным состояниями.

Двухсостояная модель: основной принцип

Простейшая марковская модель содержит одно рабочее состояние и одно состояние отказа. Интенсивность отказов определяет переход из рабочего состояния в состояние отказа. Интенсивность восстановления определяет обратный переход в рабочее состояние. На основе этих переходов модель может оценивать доступность в течение заданного периода или в установившемся режиме.

Эта модель полезна для простого ремонтопригодного оборудования, но не полностью описывает большинство резервированных систем автоматизации. Двухканальный контроллер может продолжать работать после отказа одного канала. Система остается функциональной, но теряет резервирование. Теперь она находится в состоянии деградации и подвергается большему риску второго отказа.

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

Модель также может различать обнаруженные и необнаруженные отказы. Обнаруженная неисправность канала может немедленно запустить ремонт. Необнаруженный отказ может оставаться скрытым до возникновения запроса или другого отказа. Диагностический охват изменяет структуру переходов и, следовательно, расчётные показатели доступности и риска.

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

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

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

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

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

Для резервного оборудования недостаточно состояния отказа работающего блока

Резервирование в режиме ожидания приводит к дополнительным сценариям поведения. Резервный насос может оставаться остановленным до отказа работающего насоса. В резервном блоке может присутствовать скрытая неисправность, он может не запуститься или столкнуться с проблемой в логике переключения. Запорные клапаны также могут не перейти в требуемое положение.

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

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

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

Марковское допущение одновременно упрощает модель и ограничивает её возможности

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

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

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

Модель должна содержать достаточно деталей для принятия решения, но не описывать каждое физическое изменение. Чрезмерная сложность создаёт проблемы с сопровождением и валидацией. Слишком простая модель скрывает важное поведение, а чрезмерно подробную модель невозможно объяснить.

Где марковское моделирование работает хорошо — а где нет

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

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

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

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

Использование пяти методов как единой системы надёжности

Эти пять методов обеспечивают наибольшую ценность, когда используются совместно. FMEA позволяет выявить подробные виды отказов компонентов на этапе проектирования. Затем FTA помогает определить, какие сочетания отказов приводят к критическому событию в системе. Марковское моделирование позволяет описать поведение системы после первого отказа и во время ремонта.

Моделирование методом Монте-Карло позволяет проверять неопределенные входные данные, такие как продолжительность ремонта, сроки поставки запасных частей, погодные условия и объем работ по техническому обслуживанию. RCA предоставляет данные после реальных отказов и может выявить предположения, которые первоначальные модели не учитывали. Затем модели следует обновлять, а не хранить в качестве исторических документов.

Предположим, что в дереве отказов два отказа контроллеров рассматриваются как независимые. Позднее анализ коренных причин отказов (RCA) показывает, что оба контроллера отказали после того, как один технический специалист загрузил одну и ту же неправильную конфигурацию. В дерево отказов необходимо добавить общее событие, связанное с техническим обслуживанием. Модели Маркова и модели Монте-Карло также должны учитывать новую зависимость.

Этот процесс обратной связи формирует постоянно развивающуюся программу обеспечения надежности. Прогнозный анализ направляет проектирование, эксплуатационные данные проверяют предположения, а результаты расследований улучшают следующее поколение моделей. Работа по обеспечению надежности становится частью жизненного цикла системы, а не разовым требованием проекта.

Отказы по общей причине могут вывести из строя всю резервированную архитектуру

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

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

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

Предположения об отказах по общей причине должны быть явно отражены в каждой количественной модели. Рассмотрение резервированных каналов как полностью независимых почти всегда приводит к оптимистичному результату. Опыт эксплуатации объекта и результаты анализа коренных причин отказов (RCA) дают ценные данные для оценки этих зависимостей.

Диагностическое покрытие определяет, как долго система остается уязвимой

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

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

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

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

Время ремонта часто не менее важно, чем частота отказов

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

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

Улучшенная диагностика может сократить время поиска неисправности. Стандартизированные модули и предварительно сконфигурированные запасные части могут сократить время замены. Локальные запасы, четкие процедуры эскалации и удаленная инженерная поддержка могут уменьшить логистические задержки. Марковские и Монте-Карло модели позволяют количественно оценить эффект этих улучшений.

Наилучшие инвестиции в надежность не всегда связаны с использованием более надежного оборудования. В некоторых системах сокращение времени ремонта снижает риск сильнее, чем небольшое уменьшение частоты отказов компонентов. В ходе анализа следует сравнить оба варианта.

Применение анализа надежности к архитектурам DCS и PLC

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

Резервированные контроллеры могут использовать одну стойку ввода-вывода. Резервированные серверы могут зависеть от одного сетевого коммутатора или одной системы хранения данных. Сети удаленного ввода-вывода могут использовать отдельные каналы связи, проходящие по одному и тому же физическому маршруту. Полный анализ должен прослеживать функцию от полевого устройства до конечного управляющего воздействия.

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

Организации, планирующие модернизацию систем управления, также могут ознакомиться с типовыми компонентами DCS-систем управления, используемыми в архитектурах автоматизации технологических процессов. Выбор компонентов всегда должен основываться на требованиях к надежности всего приложения, а не на характеристиках отдельных продуктов.

Надежные модели зависят от надежных данных о техническом обслуживании

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

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

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

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

Практический рабочий процесс повышения надежности

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

Затем FMEA может выявить виды отказов на уровне компонентов и слабые места в средствах обнаружения. FTA позволяет исследовать критические верхнеуровневые события и общие зависимости. Марковское моделирование может оценить деградировавшие состояния и реакцию на ремонт, а моделирование методом Монте-Карло — учесть неопределенность отказов, технического обслуживания и логистики.

Исторические инциденты следует анализировать с помощью RCA. Результаты необходимо использовать для обновления проектных анализов и количественных допущений. Приоритет действий следует определять с учетом последствий, вероятности, обнаруживаемости, продолжительности воздействия, времени ремонта и стоимости.

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

Вопросы, выявляющие необоснованные заявления об отказоустойчивости

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

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

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

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

Итоговый взгляд

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

Анализ дерева отказов показывает, как сочетания отказов могут привести к критическому событию. FMEA обеспечивает систематический анализ отдельных видов отказов и их последствий. Имитационное моделирование методом Монте-Карло оценивает неопределенные сценарии, а RCA превращает реальные отказы в знания для их предотвращения. Марковское моделирование объясняет, как ремонтопригодные системы переходят между исправным, деградировавшим, отказавшим и восстановленным состояниями.

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

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