Производство по чертежам Подбор аналогов Цены производителя Оригинальная продукция в короткие сроки
INNERпроизводство и поставка промышленных комплектующих и оборудования
Отзыв ★★★★★ Будем благодарны за отзыв в Яндексе — это помогает нам развиваться Оставить отзыв →
Правовая информация Условия использования технических материалов и калькуляторов Правовая информация →
INNER
Контакты

Журнал отказов и система FRACAS

  • 18.06.2026
  • Познавательное

FRACAS (Failure Reporting, Analysis, and Corrective Action System) — замкнутая система регистрации отказов, анализа их причин, выработки корректирующих действий и проверки эффективности этих действий. Назначение FRACAS — превратить разрозненную информацию о сбоях в управляемый поток данных, по которому надёжность оборудования планомерно растёт от поколения к поколению.

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

Содержание статьи
Определение

Что такое FRACAS

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

Исторически FRACAS был сформулирован в США в 1970-х годах в рамках программ повышения надёжности военной техники. В 1985 году подход был закреплён в военном стандарте MIL-STD-2155. В декабре 1995 года стандарт был переведён в статус справочника как MIL-HDBK-2155 «Failure Reporting, Analysis and Corrective Action Taken»; с тех пор обязательного характера для коммерческих программ он не имеет, но остаётся базовым методическим документом для построения FRACAS-процесса. В области надёжности гражданского оборудования сбор и обработка данных эксплуатации формализованы в IEC 60300-3-2 «Dependability management — Application guide — Collection of dependability data from the field». Терминологическая база — IEC 60050-192:2015, ГОСТ Р 27.102-2021, ГОСТ 18322-2016.

FRACAS не сводится ни к журналу отказов, ни к процедуре корректирующих и предупреждающих действий (CAPA) системы менеджмента качества. Это самостоятельный замкнутый процесс надёжности, в котором каждый отказ — это вход, а проверенное снижение вероятности повторения — выход.

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

Замкнутый цикл и его этапы

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

  1. Регистрация отказа. Факт отказа фиксируется в журнале с предусмотренным набором полей. Регистрацию выполняет тот, кто обнаружил отказ или впервые получил информацию о нём — оператор, дежурный персонал, технолог, диагност. На этом этапе важна полнота фактических данных, а не предположений о причинах.
  2. Первичная классификация и приоритизация. Отказу присваиваются категория критичности и приоритет анализа. На этом же этапе оценивается необходимость немедленных действий по локализации последствий — остановка участка, переключение на резерв, ограничения по режиму.
  3. Анализ коренной причины. Выявляется первопричина отказа — техническая, организационная или их сочетание. Используются 5 Why, диаграмма Ишикавы, FMEA/FMECA, анализ дерева неисправностей, разборка-дефектация, лабораторные исследования материалов и масел. Результат — задокументированный вывод о коренной причине с обоснованием.
  4. Разработка и реализация корректирующего действия. Формулируется решение, направленное на устранение коренной причины, а не симптома. Назначаются ответственный, срок и контролируемые показатели. Действие может включать конструктивную доработку, изменение режима эксплуатации, ужесточение приёмки, изменение регламента ТО, обновление обучения персонала.
  5. Проверка эффективности и замыкание цикла. После реализации действия объект отслеживается на заранее согласованном интервале времени или числа циклов. Если отказ не повторяется и подтверждено отсутствие новых отказов с той же коренной причиной, инцидент закрывается. Если повторение зафиксировано, цикл возвращается к этапу анализа.

Закрытие инцидента без подтверждённой эффективности — главный признак сломанного FRACAS. В таком процессе номер регистрации меняется, но реальные проблемы остаются.

Зафиксирован отказ маслостанции — срабатывание защиты по давлению через 200 часов работы. Первичный осмотр показал засорение фильтра. Симптоматический ответ — замена фильтра и возврат в работу. FRACAS-ответ: разобраться, почему фильтр загрязнился раньше нормативного срока. После анализа коренная причина — внутренний износ насоса, в маслосистему попадают продукты износа. Корректирующее действие — замена насоса с повышенным ресурсом по износу плюс уплотнённый интервал замены масла на остальных установках того же типа. Проверка — три месяца работы без повторного срабатывания защиты на этом и однотипных объектах.
Наверх Журнал отказов

Поля журнала отказов

Полнота анализа определяется полнотой регистрации. Стандартизация полей журнала — обязательное условие. Ниже — минимально достаточный набор по группам, согласованный с практикой IEC 60300-3-2 и MIL-HDBK-2155.

Группа полейСодержание
Идентификация событияНомер записи; дата и время обнаружения отказа; дата и время фактического возникновения (если отличается); кто зарегистрировал; режим работы (нормальный, испытания, пусконаладка, режим обслуживания).
Идентификация объектаЗаводской и инвентарный номера; позиционное обозначение (TAG); тип, модель; место установки; общая наработка на момент отказа; наработка с момента последнего планового вмешательства.
Описание отказаВнешние проявления; вид отказа (по классификации, например, по ГОСТ Р 27.102-2021); последствия для объекта и системы; условия работы непосредственно перед отказом — нагрузка, температура, давление, режим.
КлассификацияКритичность (катастрофический, критический, существенный, малосущественный); приоритет анализа; флаги: безопасность, экология, потеря функции, скрытый отказ, повторный отказ.
АнализГипотезы о причинах; результаты диагностики и дефектации; коренная причина; способствующие факторы; вид отказа по схеме FMEA (если применима); привязка к ранее зарегистрированным сходным отказам.
ДействияНемедленные действия по локализации; корректирующее действие; ответственный, срок исполнения; перечень затронутых объектов и документации (регламент ТО, инструкции, чертежи); ссылка на акт реализации.
Проверка и закрытиеМетод подтверждения эффективности; контролируемый показатель; интервал наблюдения; результат проверки; дата закрытия; ответственный за закрытие.

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

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

Наверх Анализ причин

Методы анализа коренной причины

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

«5 почему»

Метод последовательного раскрытия причинно-следственной цепочки: к найденной причине задаётся вопрос «почему?», ответ становится новой причиной, и так до тех пор, пока ответ не даёт первопричину, устранение которой решает проблему. Число «5» условно — иногда достаточно трёх шагов, иногда требуется семь и более. Метод удобен для отказов с линейной причинно-следственной цепочкой, применяется быстро и без специальных инструментов.

Диаграмма Ишикавы (диаграмма «рыбьего скелета»)

Графический инструмент группировки гипотез о причинах. «Хребет» направлен на отказ, ветви соответствуют категориям возможных причин. Классическая разбивка для производственного оборудования — категории «6M»: человек (man), машина (machine), материал (material), метод (method), измерение (measurement), окружающая среда (milieu/environment). Диаграмма Ишикавы хороша для отказов с несколькими переплетёнными факторами; часто применяется как первый шаг, после которого «5 почему» используется для углубления по выбранной ветви.

FMEA и FMECA

Анализ видов и последствий отказов — систематизированная процедура идентификации видов отказов объекта и оценки их последствий. Если в анализ включают ранжирование критичности, методика называется FMECA. В российской нормативной системе процедура описана в ГОСТ Р 27.303-2021 «Надёжность в технике. Анализ видов и последствий отказов», который модифицирован относительно международного МЭК 60812:2018. В контексте FRACAS FMEA используется двумя способами: на этапе анализа — как источник перечня возможных видов отказов и проверка, был ли данный отказ предусмотрен; после серии отказов — для пересмотра FMEA конструкции или процесса.

Анализ дерева неисправностей

Дедуктивный графический метод: вершина — нежелательное событие (отказ функции), листья — элементарные события (отказы компонентов, ошибки персонала, внешние воздействия), связи — логические операторы И/ИЛИ. Подход формализован в IEC 61025:2006 и в гармонизированном с ним ГОСТ Р 27.302-2009 «Надёжность в технике. Анализ дерева неисправностей»; применяется к сложным системам, особенно к таким, где отказ функции связан с одновременным наступлением нескольких независимых событий.

Лабораторные и инструментальные исследования

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

Наверх Метрики

Связь FRACAS с MTBF и показателями надёжности

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

MTBF и сопряжённые величины

MTBF (mean time between failures) — средняя наработка на отказ восстанавливаемого объекта. По данным FRACAS оценивается как отношение суммарной наработки за период наблюдения к числу зарегистрированных отказов:

MTBF ≈ Tтот / N

где Tтот — суммарная наработка всех объектов наблюдаемого парка за период, N — число отказов за этот же период. Оценка справедлива в предположении приблизительно постоянной интенсивности отказов (период нормальной эксплуатации). Точные определения по ГОСТ Р 27.102-2021; математические выражения для показателей надёжности — IEC 61703:2016.

Для невосстанавливаемых объектов вместо MTBF используется MTTF (mean time to failure) — средняя наработка до отказа. Эти величины не взаимозаменяемы: MTBF определена только для объектов, которые после отказа восстанавливают и возвращают в работу. На практике, когда среднее время восстановления существенно меньше средней наработки, MTBF и MTTF близки численно.

Среднее время восстановления — MTTR (mean time to repair / mean time to restoration) — оценивается по тем же записям FRACAS: складывается из времени обнаружения отказа, диагностики, замены или ремонта и ввода в работу. Точные определения и обозначения показателей надёжности — по ГОСТ Р 27.102-2021; математические выражения — по IEC 61703:2016.

Коэффициент готовности

Для оценки доступности оборудования используется коэффициент готовности:

Kг = MTBF / (MTBF + MTTR)

Параметр выражает долю времени, в течение которого объект находится в работоспособном состоянии (при условии, что необходимые внешние ресурсы обеспечены). Определение и связь с другими показателями — ГОСТ Р 27.102-2021.

Тренды и контроль изменений

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

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

Наверх Внедрение

Внедрение FRACAS

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

Условия запуска

  • Поддержка руководства. Решения по корректирующим действиям часто требуют ресурсов, которые превышают полномочия линейного персонала. Без формальной поддержки руководства цикл закрытия не работает.
  • Зафиксированная область применения. Определено, какое оборудование охватывается FRACAS, какие классы отказов регистрируются и какие — нет. Размытая область приводит к перегрузке журнала несущественными событиями и недогрузке существенными.
  • Единый справочник отказов. Перечень видов отказов, кодировка узлов, классификация критичности и причин — стандартизированы и неизменны на длительном горизонте. Иначе выборки за разные периоды несопоставимы.
  • Распределение ролей. Регистратор, аналитик, владелец корректирующего действия, контролёр закрытия — разные роли с разной ответственностью. Совмещение всех ролей в одном лице ослабляет контроль.
  • Интеграция с действующими процессами. FRACAS соединяется с CMMS/ERP, программой планового ТО, процедурой управления изменениями и системой управления документами. Изолированный FRACAS теряет связь с реальной эксплуатацией.

Регламент работы

  1. Сроки этапов. Для каждого приоритета определены целевые сроки регистрации, анализа, реализации и проверки. Просроченные инциденты эскалируются.
  2. Периодический разбор. Регулярные совещания по разбору отказов с участием эксплуатации, ремонта, инженерии и поставщика. Разбор не заменяет анализ, но позволяет согласовать приоритеты.
  3. Обратная связь к проектированию. Результаты анализа коренных причин по серии отказов используются при проектировании следующей версии изделия и при пересмотре FMEA.
  4. Внутренний аудит. Выборочно проверяется качество регистрации и обоснованность закрытия. Без аудита система деградирует к формальному закрытию инцидентов.
Наверх Типовые проблемы

Типичные ошибки и риски

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

ОшибкаПроявлениеПоследствие
Закрытие без проверки эффективностиИнцидент закрывается сразу после ремонта; этап проверки фиктивен.Повторяющиеся отказы накапливаются; реальная картина надёжности скрыта.
Анализ на уровне симптомаВ графе коренной причины написано «отказ детали X», без объяснения, почему деталь X отказала.Корректирующее действие сводится к замене и не предотвращает повторения.
Подмена причины ответственнымКоренной причиной указывается «ошибка персонала», обстоятельства не уточняются.Системные дефекты процессов, документации и обучения остаются не выявленными.
Нестабильная классификацияВиды отказов и узлы кодируются непоследовательно от случая к случаю.Выборки и тренды теряют смысл; сопоставление периодов невозможно.
Изолированный журналFRACAS не интегрирован с CMMS и инженерными процессами; данные не доходят до проектирования.Уроки эксплуатации не используются при модернизации и закупках.
Перегруз малозначимыми событиямиВ журнал попадают все инциденты подряд без приоритизации.Аналитический ресурс распыляется, существенные отказы тонут в фоне.
Боязнь регистрацииОтказ скрывается, чтобы не портить статистику подразделения.База данных не отражает реальность; выводы по ней опасны.
Наверх FAQ

Частые вопросы

Чем FRACAS отличается от обычного журнала отказов?

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

Чем FRACAS отличается от FMEA?

FMEA (анализ видов и последствий отказов, ГОСТ Р 27.303-2021) — это упреждающий, проектный анализ: список потенциальных видов отказов и их последствий формируется до отказа в эксплуатации. FRACAS — это реактивный, эксплуатационный процесс: работает с уже произошедшими отказами. Методы дополняют друг друга: FMEA даёт справочник видов отказов и их предполагаемых причин, а FRACAS уточняет этот справочник по фактическим данным эксплуатации и в ряде случаев приводит к пересмотру исходного FMEA.

Чем FRACAS отличается от CAPA?

CAPA (corrective and preventive actions) — это процесс системы менеджмента качества: корректирующие и предупреждающие действия применяются к несоответствиям, выявленным в продукции, процессах и системе менеджмента. FRACAS специализирован на отказах оборудования и систем в эксплуатации, оперирует характерными для надёжности показателями и встроен в инженерные процессы. На практике CAPA и FRACAS пересекаются и могут быть согласованы как смежные процессы.

Достаточно ли «5 почему» для большинства отказов?

Метод «5 почему» хорошо работает для отказов с линейной причинно-следственной цепочкой и доступной фактической базой. Для отказов с несколькими переплетёнными факторами он часто упрощает картину и приводит к преждевременному выводу. В таких случаях полезнее начать с диаграммы Ишикавы или FMEA, а «5 почему» использовать для углубления по выбранной ветви.

Когда инцидент можно закрыть?

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

Может ли FRACAS работать без специализированного программного обеспечения?

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

Как FRACAS связан с показателями надёжности по контракту?

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

Кто должен владеть процессом FRACAS?

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

Статья носит ознакомительный характер и не заменяет действующие тексты ГОСТ Р 27.102-2021, ГОСТ 18322-2016, ГОСТ Р 27.303-2021, IEC 60050-192:2015, IEC 60300-3-2:2004, IEC 61703:2016, MIL-HDBK-2155 и эксплуатационной документации производителей. Конкретные форматы журнала отказов, методики расчёта показателей надёжности и регламент работы FRACAS определяются по официальным документам с учётом особенностей конкретной отрасли, объекта и условий эксплуатации. Автор и издатель не несут ответственности за последствия применения сведений из статьи без сверки с первоисточниками и квалифицированной инженерной проработки.

Источники

  1. ГОСТ Р 27.102-2021 — Надёжность в технике. Надёжность объекта. Термины и определения.
  2. ГОСТ Р 27.101-2021 — Надёжность в технике. Надёжность выполнения задания и управление непрерывностью деятельности. Термины и определения.
  3. ГОСТ 18322-2016 — Система технического обслуживания и ремонта техники. Термины и определения.
  4. ГОСТ 27.003-2016 — Надёжность в технике. Состав и общие правила задания требований по надёжности.
  5. ГОСТ Р 27.303-2021 (МЭК 60812:2018) — Надёжность в технике. Анализ видов и последствий отказов.
  6. ГОСТ Р 27.302-2009 — Надёжность в технике. Анализ дерева неисправностей.
  7. ГОСТ Р 27.013-2019 — Надёжность в технике. Методы оценки показателей безотказности.
  8. IEC 60050-192:2015 — International Electrotechnical Vocabulary — Part 192: Dependability.
  9. IEC 60300-3-2:2004 — Dependability management — Part 3-2: Application guide — Collection of dependability data from the field.
  10. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA).
  11. IEC 61025:2006 — Fault tree analysis.
  12. IEC 61703:2016 — Mathematical expressions for reliability, availability, maintainability and maintenance support terms.
  13. IEC 60300-3-11:2009 — Dependability management — Part 3-11: Application guide — Reliability centred maintenance.
  14. MIL-HDBK-2155 — Failure Reporting, Analysis and Corrective Action Taken. Department of Defense, 11 December 1995 (Notice 2 — Validation, 2019).
  15. Smith D. J. Reliability, Maintainability and Risk. Elsevier / Butterworth-Heinemann.
  16. Половко А. М., Гуров С. В. Основы теории надёжности. — 2-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2006.

© Компания Иннер Инжиниринг. Все права защищены.

Появились вопросы?

Вы можете задать любой вопрос на тему нашей продукции или работы нашего сайта.