Анализ видов и последствий отказов
 Скачать 1.94 Mb.
|
|
Окончание таблицы С.5
Значимость последствий  Рисунок С.З — Матрица критичности для отчета FMECA в соответствии с таблицей С.5, разработанная в виде двумерного изображения, без учета обнаруживаемое™Приложение D (справочное) Связь FMEA с другими методами анализа надежности Сочетание FMEA с другими методами анализа надежности может повысить его результативность. Например: Для определения области применения и е качестве помощи при разработке FMEA может быть испогъзован метод структурной схемы надежности (RBD). Результаты FMEAмогут быть впоследствии использованы для пере- смотра или обновления RBD. Примечание 1 — В отличие от FMEA RBD рассматривает успешную работу системы. Для выбора важных объектов сложной системы для FMEA может быть использован анализ дерева неис- правностей (FTA) с соответствующей вершиной событий. Примечание 2 — Как и в случае FMEA, FTA рассматривает отказ системы. Результаты (нижнего уровня) FMEA могут определять основные события для FTA. и эти события должны быть включены в качестве основных событий FTA. Информация, полученная в результате анагыза первопричин, может помочь в идентификации причин от- казов процесса ([4]). 8 дополнение к FMEA. который обычно учитывает только независимые отказы, можно испогъзовать более подробные методы анализа, такие как FTA. RBD. анализ дерева событий (ЕТА). марковский анализ, сети Петри для учета взаимозависимости событий отказов (порядок появления отказов, условная вероятность возникновения отказов, резервирование, исключение возникновения. отказы по общей причине). FMEA может быть использован поэтапно в сочетании с другими методами анализа надежности в процессе разработки объекта или процесса. На стадии концепции FMEA может быть объединен с RBD и FTA для рассмотре- ния отказов на функциональном уровне. В процессе детального проектирования FMEA может быть разработан на более детальном уровне. Для выбранных критических компонентов или процессов FMEA может быть выполнен на наиболее детальном уровне. Прогнозирование безотказности и анализ результатов испытаний или отказов в эксплуатации могут быть использованы для определения количественной оценки вероятности в FMEA. Примечание 3 — Ссылки на другие стандарты анализа надежности, которые могут быть применимы: RBD (ГОСТ Р 51901.14); ГГА(ГОСТ Р 27.302); ЕТА (ГОСТ Р МОК 62502); Марковский анализ (ГОСТ Р МЭК 61165); Сети Петри ((10]): прогнозирование безотказности см. в [7] и ГОСТ Р 27.013. Результаты FMEA обеспечивают информацию о критических аспектах проекта сложного объекта или процес- са. эта информация в процессе разработки может быть использована в качестве входных данных или может быть объединена с данными: анализа технического обслуживания; устранения неисправностей при техническом обслуживании: анализа тестируемости: определения и спецификации контрольных примеров и анализа результатов испытаний (тестирования); анализа логистической поддержки: анализа безотказности выполнения целевой задачи: анализа готовности; оценки последствий изменения конструкции (проекта); документации об обязательных целях (например, одобрение безопасности для конкретной системы или для определенного типа систем).Приложение Е (справочное) Прикладные аспекты применения FMEA Общие положения В данном приложении рассмотрено общее применение FMEA и конкретные вопросы, которые необходимо рассмотреть при проведении FMEA в соответствии с общем методологией, приведенной в настоящем стандарте, и руководством по адаптации, приведенным в приложении А. Рассмотренные варианты применения не являются исчерпывающими. Обсуждаемые варианты применения FMEA могут включать определенные требования в отношении анализа критичности (например, безопасности) или могут обеспечивать совместимость с конкретными стандартами (на- пример. FMECAb рамках технического обслуживания, ориентированного на безотказность). Также рассмотрено использование FMEA для сложных систем (например, безотказность и готовность по модулям и компонентам). FMEA программного обеспечения FMEA программного обеспечения аналогично FMEA аппаратного обеспечения, процедур и функций. Для программного обеспечения обычно устанавливают, что: ошибка программного обеспечения — это ошибка в программном коде. программная ошибка — это проблема с выполнением процедуры/функции. отказ программного обеспечения — это полная или частичная деградация конкретной функции программ- ного обеспечения. Дефекты в программном обеспечении (обычно называемые «ошибками») могут привести к отказу программ- ного обеспечения. Последствия такого отказа для функций программного обеспечения и выхода программного обеспечения могут быть проанализированы, как и для любого другого объекта. Вероятность отказа можно оценить как количество случаев активации функции, содержащей «ошибку», деленное на общее количество выполнения функции, но поскольку эта информация обычно недоступна, когмчественный анализ редко возможен. Состояния отказа в программном обеспечении часто являются неустойчивыми и в некоторых случаях могут быть устранены путем переустановки программного обеспечения. Все отказы программного обеспечения связаны с проектом, не- зависимо от тога, были ли они вызваны неверной интерпретацией требований, ошибками в ходах, нехваткой памя- ти. наличием разомкнутых циклов, синтаксическими ошибками и т. п. Программное обеспечение может быть проанализировано сверху вниз или снизу вверх. Как и оборудование, программное обеспечение разбивают на несколько уровней, например пакет программ, програмъмые модули и функции кода (таблица 1). Для каждого элемента анализ должен рассматривать вход, выполнение и выход. Вы- полнение зависит от начальных условий до ввода данных, например положения в структуре меню, содержимого регистров и памяти (ОЗУ. а также ПЗУ). На более низких уровнях отказы могут возникать во входных данных (на- пример. неверные или поврежденные данные), в начальных условиях (например, неправильная позиция е меню, неверное или поврежденное содержимое памяти) или из-за неправильной работы (например, ошибок в алгорит- мах). Отказы на уровне системы часто связаны с выходными данными (например, поврежденные выходные дан- ные или неверные данные). Наконец, выход програмьыого обеспечения может вызвать проблемы взаимодействия с аппаратным обеспечением, например проблемы синхронизации. Анализ обычно фокусируется на видах отказов, связанных с программным обеспечением, однако причины, показатеш и последствия отказов могут быть связаны с соответствующим аппаратным обеспечением. Поэтому в анализе должны участвовать как аналитики, знающие программное обеспечение, так и аналитики, знающие аппаратное обеспечение. | |||||||||||||||