Откройте актуальную версию документа прямо сейчас
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Приложение Е
(справочное)
Прикладные аспекты применения FMEA
Е.1 Общие положения
В данном приложении рассмотрено общее применение FMEA и конкретные вопросы, которые необходимо рассмотреть при проведении FMEA в соответствии с общей методологией, приведенной в настоящем стандарте, и руководством по адаптации, приведенным в приложении А. Рассмотренные варианты применения не являются исчерпывающими.
Обсуждаемые варианты применения FMEA могут включать определенные требования в отношении анализа критичности (например, безопасности) или могут обеспечивать совместимость с конкретными стандартами (например, FMECA в рамках технического обслуживания, ориентированного на безотказность). Также рассмотрено использование FMEA для сложных систем (например, безотказность и готовность по модулям и компонентам).
Е.2 FMEA программного обеспечения
FMEA программного обеспечения аналогично FMEA аппаратного обеспечения, процедур и функций. Для программного обеспечения обычно устанавливают, что:
- ошибка программного обеспечения - это ошибка в программном коде,
- программная ошибка - это проблема с выполнением процедуры/функции,
- отказ программного обеспечения - это полная или частичная деградация конкретной функции программного обеспечения.
Дефекты в программном обеспечении (обычно называемые "ошибками") могут привести к отказу программного обеспечения. Последствия такого отказа для функций программного обеспечения и выхода программного обеспечения могут быть проанализированы, как и для любого другого объекта. Вероятность отказа можно оценить как количество случаев активации функции, содержащей "ошибку", деленное на общее количество выполнения функции, но поскольку эта информация обычно недоступна, количественный анализ редко возможен. Состояния отказа в программном обеспечении часто являются неустойчивыми и в некоторых случаях могут быть устранены путем переустановки программного обеспечения. Все отказы программного обеспечения связаны с проектом, независимо от того, были ли они вызваны неверной интерпретацией требований, ошибками в кодах, нехваткой памяти, наличием разомкнутых циклов, синтаксическими ошибками и т.п.
Программное обеспечение может быть проанализировано сверху вниз или снизу вверх. Как и оборудование, программное обеспечение разбивают на несколько уровней, например пакет программ, программные модули и функции кода (таблица 1). Для каждого элемента анализ должен рассматривать вход, выполнение и выход. Выполнение зависит от начальных условий до ввода данных, например положения в структуре меню, содержимого регистров и памяти (ОЗУ, а также ПЗУ). На более низких уровнях отказы могут возникать во входных данных (например, неверные или поврежденные данные), в начальных условиях (например, неправильная позиция в меню, неверное или поврежденное содержимое памяти) или из-за неправильной работы (например, ошибок в алгоритмах). Отказы на уровне системы часто связаны с выходными данными (например, поврежденные выходные данные или неверные данные). Наконец, выход программного обеспечения может вызвать проблемы взаимодействия с аппаратным обеспечением, например проблемы синхронизации. Анализ обычно фокусируется на видах отказов, связанных с программным обеспечением, однако причины, показатели и последствия отказов могут быть связаны с соответствующим аппаратным обеспечением. Поэтому в анализе должны участвовать как аналитики, знающие программное обеспечение, так и аналитики, знающие аппаратное обеспечение.
Глубина и область применения FMEA программного обеспечения могут быть различны. FMEA может быть ограничен только программными компонентами или модулями. При запуске на раннем этапе разработки программного обеспечения FMEA может быть направлен на функции программного обеспечения, необходимые для работы системы, и на возможные ошибки или отказы, которые могут стать причиной отказа функции в одном или нескольких видах отказа. Такой анализ выполняют в начале разработки программного обеспечения и используют в качестве источника информации для создания контрольных примеров программного обеспечения. По мере разработки системы влияние программных ошибок, сбоев или отказов может быть определено лучше, а также определены обстоятельства или их комбинации, которые могут вызвать отказ.
Ключевые причины отказов могут представлять собой ошибки программиста ("ошибки"), а также причины, связанные с состоянием аппаратных средств. Для выполнения FMEA необходимо определить, может ли единичный отказ программного обеспечения стать причиной неприемлемых локальных последствий (помимо конечных/глобальных последствий), например:
- переменная принимает непредусмотренное значение;
- сообщение содержит непредусмотренные данные или затрачивает на выполнение неожидаемое время;
- модуль дает неожидаемые выходы.
Затем анализируют каждый вид отказа для (конечных) последствий системы. Это правило, основанное на анализе сложных единичных последствий, которые зависят от времени и состояния системы. Перед выполнением FMEA для программного обеспечения необходимо провести отдельный анализ спецификации требований. Поскольку программная ошибка или сбой часто приводят к нежелательным последствиям для аппаратного обеспечения, сначала необходимо выполнить FMEA для аппаратного обеспечения, чтобы установить влияние системы. В этом случае последствия для системы программного обеспечения могут основываться на последствиях для системы аппаратного обеспечения.
Следующий перечень основан на примерах, приведенных в [11]. FMEA программного обеспечения также должно учитывать условия эксплуатации, например:
- аппаратные отказы, вызывающие отказ памяти;
- периферические отказы карты памяти (например, отказы аналоговых/цифровых преобразователей или устройств ввода-вывода);
- отказ источника питания, например сброс из-за падения напряжения питания;
- электромагнитные помехи (EMI), электромагнитные импульсы (ЕМР);
- неправильно обработанные неверные входные данные, включая ошибки загрузки.
Примеры причин отказа на уровне системы:
- неправильное использование вызовов операционной системы;
- неверная синхронизация, например коллизия данных из-за изменения времени передачи данных;
- прерывание обработки и неадекватный анализ;
- неадекватная или отсутствующая обработка исключений.
Примеры ошибок программирования (причины отказов):
- ошибки проектирования и выполнения (например, при кодировании, масштабировании, разработке алгоритмов);
- неадекватное обнаружение ошибок (например, нарушение границ, указатели вне диапазона);
- неадекватное определение допустимого диапазона;
- непреднамеренная перезапись в памяти;
- неадекватная обработка ошибок программного обеспечения (например, неожиданная ситуация).
Примеры видов отказов:
- неправильная точка выхода, превышение времени, неожиданное взаимодействие ввода-вывода;
- недостающие данные, неверные данные, неверная синхронизация данных, особые данные;
- ненормальное завершение, пропущенные события, неверные логика, синхронизация/порядок;
- остановка, аварийный отказ, зависание, медленная реакция, отказ запуска, ошибочные сообщения.
Если анализ выполняют с использованием электронной таблицы, обычно можно использовать следующие столбцы:
a) иерархия системы и компонентов;
b) обозначения компонентов;
c) виды отказов;
d) причины отказов;
e) последствия неготовности отказавшей функции (при восстановлении программного обеспечения);
f) смягчающее обеспечение проекта (меры по восстановлению проекта, альтернативные пути, защита от отказов);
g) компенсационное обеспечение;
h) закрытие вопроса;
i) окончательное снижение неготовности функции в результате идентификации вида отказа.
На рисунке Е.1 показан пример модели отказа программного обеспечения.
По мере разработки конструкции аппаратного обеспечения анализ рассматривает систему в целом, включая программное и аппаратное обеспечение, и направлен на функции системы и их цепочки.
FMEA аппаратного обеспечения изменяется вслед за программной частью, анализ может разрастись до нежелательных размеров при поиске цепочки последствий, приводящих к отказу системы, и оценке влияния их деградации или значимости их потери на работу системы. При анализе смешанной аппаратно-программной системы предпочтительной практикой является отслеживание функции системы по ветвям сверху вниз для идентификации компонентов программного обеспечения, их возможных ошибок или неисправностей и возможных видов отказов, а также их причин.
Следует помнить, что FMEA одновременно исследует только один вид отказов, он не предназначен для рассмотрения функциональных зависимостей, последовательностей событий (отказов) или комбинаций событий. Отказ аппаратного обеспечения может быть причиной отказа программного обеспечения, а с точки зрения FMEA отказ программного обеспечения является следствием отказа аппаратного обеспечения.
FMEA программного обеспечения - один из методов (помимо тестирования), который помогает повысить безотказность программного обеспечения. Тестирование также может быть использовано в качестве обработки видов отказов, которые считаются критическими.
Рисунок Е.1 - Общая модель отказа программного обеспечения для компонента программного обеспечения
Е.3 FMEA процесса
Для процессов и процедур общая методология FMEA такая же, как и для аппаратного и программного обеспечения. Начальной точкой анализа является схема работы процесса, структура деления работ или анализ задач. Процесс подразделяют на элементы, которые являются этапами процесса. Уровень декомпозиции выбирают в соответствии с областью применения анализа. Функцию каждого этапа или его предполагаемого выхода определяют с помощью описания функции, достаточно специфичного, чтобы был ясен уровень работы, представляющий собой отказ. Как и в случае FMEA аппаратного и программного обеспечения, варианты отказа функций процесса должны быть перечислены в качестве видов отказов в FMEA процесса. Последствия отказа, механизмы и возможные причины отказа также должны быть определены. Механизмы и причины отказов часто охватывают как ошибки человека, так и отказы оборудования. Анализ критичности может быть применен также, как описано в общем руководстве FMEA.
FMEA процесса впервые был применен к производственным процессам, но теперь его применяют более широко. Например, его широко используют при анализе медицинских процедур в здравоохранении.
Е.4 FMEA при проектировании и разработке
FMEA - неотъемлемая часть процесса проектирования, от концепции до разработки системы. FMEA - итеративный процесс, он начинается, как только появляется предварительная информация о проекте на высшем уровне системы, и распространяется на более низкие уровни иерархии системы по мере поступления большого количества информации. Адаптация FMEA (приложение А) должна гарантировать, что он вносит существенный вклад в решения организации в отношении осуществимости и адекватности подхода к разработке проекта.
Целью FMEA в процессе проектирования является идентификация видов отказов внутри системы и возможных критических отказов, которые могут быть устранены или сокращены с помощью проектных решений как можно раньше.
В дополнение к ориентации на надежность FMEA поддерживает усилия по сопровождению, техническому обслуживанию и анализу риска.
Е.5 FMEA в рамках технического обслуживания, ориентированного на безотказность
Для разработки успешной программы технического обслуживания, ориентированного на безотказность, необходимо четкое понимание функций объекта, отказов и последствий с точки зрения целей организации при эксплуатации объекта.
FMEA и метод анализа критичности подходят для применения к техническому обслуживанию, ориентированному на безотказность, если анализ структурирован таким образом, что соответствует требованиям стандарта технического обслуживания, ориентированного на безотказность (ГОСТ Р 27.606).
Для структурирования анализа необходимо, чтобы все виды отказов были четко связаны с потерей функции на соответствующем уровне иерархии объекта и чтобы такие аспекты, как "средства обнаружения" отказов, были согласованы с потенциальными задачами технического обслуживания.
Е.6 FMEA для систем управления, связанных с безопасностью
Е.6.1 Общие положения
Применительно к безопасности FMEA используют в различных ситуациях. Метод FMEA является одной из альтернатив при планировании функций, связанных с безопасностью, или анализе риска.
Пример 1 - Некоторые стандарты (например, ГОСТ Р МЭК 62061 и ГОСТ Р МЭК 61508 (все части)) требуют применения определенных форм анализа при установлении подходящих методов обработки риска, при создании функций, связанных с безопасностью, или при разработке устройств для использования таких функций. FMEA - один из методов, который можно использовать при планировании функций, связанных с безопасностью.
Применительно к безопасности FMEA классифицирует виды отказов функции, связанной с безопасностью, на безопасные и опасные. Классификация может быть различной в зависимости от условий использования, структуры системы, окружающей среды.
Пример 2 - Для многих систем безопасным состоянием (неизменным безопасным состоянием системы) является обесточенное состояние (выключенное состояние). Отказ тормозной системы воздушного судна можно считать безопасным отказом, когда самолет находится на земле, но этот отказ становится опасным отказом при взлете или посадке (переменное безопасное состояние системы (см. [12]).
Некоторые стандарты безопасности требуют, чтобы единичные отказы были обнаружены так, чтобы это приводило к безопасному состоянию или сохранению безопасного состояния за счет функциональной избыточности (резервирования), напрямую не приводило к небезопасному состоянию.
При ранжировании действий применительно к безопасности действия по проектированию должны в первую очередь рассматривать последствия отказов и не должны использовать экономические компромиссы. Следовательно, при проектировании действия должны быть направлены:
- на снижение вероятности опасных отказов;
- распознавание или обнаружение появления опасных отказов и соответствующее реагирование на них;
- оповещение пользователя о безопасном состоянии устройства;
- устранение или снижение вероятности отказов, вызванных ошибками или непониманием человека.
Е.6.2 FMEA при планировании применительно к безопасности
FMEA может быть применен на уровне системы на этапе планирования разработки применительно к безопасности. Виды и последствия отказов всех компонентов системы и их взаимодействие систематически оценивают для определения их влияния на безопасность системы.
FMEA также может быть применен в других точках проекта, где при определении методов обработки для повышения безопасности могут быть использованы идентификация риска и анализ влияния риска на функции, связанные с безопасностью. Целью FMEA в области безопасности является поиск всех элементов, связанных с функцией безопасности, и всесторонняя идентификация источников вреда. Методы, способствующие комплексной идентификации, включают в себя контрольные перечни, исследования и использование экспертных оценок в широком диапазоне.
Меру риска, основанную на тяжести вреда и качественной оценке вероятности опасного события, используют для определения требуемой целостности безопасности систем управления электрических, электронных и программируемых электронных, связанных с безопасностью в соответствии с ГОСТ Р МЭК 62061.
Вероятность нанесения вреда учитывает:
- частоту и продолжительность воздействия опасности на людей;
- вероятность возникновения опасного события;
- возможность избежать или ограничить возможный вред.
Эти три фактора наряду со значимостью последствий используют для создания класса необходимого снижения риска при применении. Такие классификации используют в нескольких стандартах, связанных с безопасностью.
Примечание - В ГОСТ Р МЭК 61508 (все части) и ГОСТ Р МЭК 62061 использован термин SIL (уровень целостности безопасности) для такой классификации.
Пример - В ГОСТ Р МЭК 62061 для наивысшей категории снижения риска требуется уровень SIL3, который эквивалентен интенсивности отказов функции управления безопасностью от 10 -8 до 10 -7 в час.
Е.6.3 Анализ критичности, включающий диагностику
Дополнительный уровень детализации включен в так называемый анализ видов, последствий и диагностики отказов (FMEDA).
Примечание 1 - Метод FMEDA также используют для систем, не связанных с безопасностью.
Способность системы или подсистемы обнаруживать внутренние отказы, предпочтительно с помощью автоматической онлайн-диагностики, имеет решающее значение для достижения и сохранения правильного функционирования сложных систем и систем, которые не могут в полной мере использовать все функциональные возможности в нормальных условиях, таких как редкие запросы системы аварийного отключения (система ESD). При оценке целостности системы, связанной с безопасностью, всем анализируемым компонентам добавляют количественные данные об интенсивности отказов (интенсивность отказов и распределение видов отказа). Кроме того, количественно определяют способность системы обнаруживать внутренние отказы.
Если анализируемые компоненты являются электронными устройствами, интенсивность отказов должна иметь соответствующую сопроводительную документацию для обоснования ее оценки, в идеале из опыта эксплуатации на местах. Интенсивность отказов для каждого компонента определяют на основе сведений из баз данных, для которых доказана их пригодность для данной цели. Кроме того, распределения видов отказов могут быть выведены из аналогичных источников или из стандартов (например, [7]), их, как правило, приводят в процентах от общего количества.
Примечание 2 - Интенсивность отказов часто указывают в виде количества отказов в единицу времени (FIT). FIT означает 10 -9 отказов в час.
Примечание 3 - Распределение видов отказов соответствует доле общей интенсивности отказов компонента, которая может быть приписана каждому из видов отказов.
Во многих случаях также указывают интенсивность отказов для отказов, которые не влияют на функцию безопасности, или отказов составных частей, которые не являются частью функции безопасности, но эти интенсивности не влияют на дальнейшие вычисления.
При оценке электронного устройства анализ учитывает каждый электрический компонент и его влияние на функцию безопасности, что позволяет сделать вывод о том, какое влияние оказывает отказ на функцию безопасности.
Отказы обычно делят на безопасные отказы, опасные обнаруженные отказы, опасные необнаруженные отказы и отказы, которые не влияют на функцию безопасности. Для проверки полноты оценки иногда целесообразно перечислить компоненты, которые не влияют на функцию безопасности.
Решение о том, является ли опасный отказ обнаруженным или необнаруженным, определяется значением диагностического охвата, которое может быть выведено на основе соответствующей диагностической схемы и оценки ее результативности. Значение прибавляют к оценке, сумма характеризует качество устройства для использования в рамках функции безопасности. Полученные значения также могут быть использованы для расчета интенсивности отказов или других показателей безотказности функции безопасности или показателей качества функции безопасности, таких как доля безопасных отказов (SFF) или общий диагностический охват (DC). Определение значений этих характеристик зависит от условий, для которых они определены.
Результатом является ранг значений вероятности отказа, который позволяет оценить общий риск, соответствующий отказу функции безопасности в случае возникновения ее запроса.
При недостатке информации о возможных видах отказов и их распределении по электрическим компонентам FMEA снова является подходящим методом сбора информации о возможных видах отказов. Исходя из этого могут быть начаты практические эксперименты или теоретические обсуждения для определения этих значений.
Примечание 4 - Данный метод и возможности исключения ошибок описаны в ГОСТ ISO 13849-1.
Е.7 FMEA для сложных систем с распределением безотказности
Е.7.1 Общие положения
FMEA может быть использован для сложных и ответственных систем, от оборонного и аэрокосмического сектора до водоснабжения, канализации, транспорта, связи, производства и распределения электроэнергии. В этих системах требования к показателям готовности, ремонтопригодности и безотказности могут быть распределены по элементам системы. Адаптированный FMEA может быть проведен с рассмотрением характеристик отказа каждого элемента для понимания влияния на систему таких конструктивных особенностей, как использование общих компонентов и резервирования.
Е.7.2 Оценка критичности для невосстанавливаемых систем с распределенной вероятностью отказа
В процессе FMEA для сложной, не восстанавливаемой системы частоты возникновения, вероятности, интенсивности отказов или другие соответствующие показатели могут быть распределены для каждого последствия на уровне системы. Это распределение можно сравнить с приемлемым риском системы, распределенными вероятностями и значимостью в матрице риска.
Локальные последствия каждого отказа на самом низком уровне иерархии системы можно привести к последствиям на более высоком уровне и, наконец, на уровне системы. Эти фактические оценки риска затем можно сопоставить с согласованным уровнем приемлемого риска. Если критичность превышает допустимое значение, необходимо проследить ее появление до той составной части системы, откуда она возникает.
Оценки вероятностей отказов можно сравнить с допустимыми пределами для каждого уровня значимости, чтобы определить составные части или компоненты на более низком уровне с чрезмерной критичностью. Затем выполняют инженерные действия для снижения критичности компонентов путем снижения вероятности отказа или другие меры смягчения последствий отказа. Этот процесс показан на рисунке Е.2.
Часто предполагается, что если критичность компонента более низкого уровня не превышает приемлемый уровень, то никаких действий предпринимать не нужно. Это особенно неверно, когда имеется много аналогичных компонентов, которые могут оказывать одинаковое воздействие на подсистемы или систему. Общее суммарное воздействие отказов всех компонентов, имеющих одинаковую вероятность и значимость последствий, не должно превышать допустимую вероятность отказов сборочной единицы, в которой они находятся. Эта мера гарантирует, что определенная критичность на уровне системы не будет превышена.
Рисунок Е.2 - Распределение вероятностей отказа в системе
Е.7.3 Оценка критичности для восстанавливаемых систем с распределением показателя неготовности
Требования к готовности для восстанавливаемых систем распределяют по показателям надежности, таким как среднее время между отказами (MTBF) для безотказности и среднее время восстановления (MTTR) для ремонтопригодности системы. Показатель неготовности системы обычно используют для оценки критичности системы. Оценка коэффициента неготовности аналогична оценке вероятности отказа (ненадежности). Коэффициент неготовности распределяют по подсистемам и сборочным единицам, он имеет два измерения, поскольку зависит от двух показателей, MTBF и MTTR.
Процесс распределения на уровне системы, подсистемы, сборочных единиц аналогичен распределению в Е.7.2, за исключением того, что вместо вероятности появления вида отказа, для вида отказа выводят коэффициент неготовности системы, подсистемы и сборочных единиц. Виды отказов, вызывающие неприемлемый уровень неготовности, должны быть обработаны.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.