Анализ видов и последствий отказов
 Скачать 1.94 Mb.
|
|
Глубина и область применения FMEA программного обеспечения могут быть различны. FMEA может быть ограничен только программными компонентами или модулями. При запуске на раннем этале разработки программ- ного обеспечения FMEA может быть направлен на функции программного обеспечения, необходимые для работы системы, и на возможные ошибки или отказы, которые могут стать причиной отказа функции в одном или несколь- ких видах отказа. Такой анализ выполняют в начале разработки программного обеспечения и используют в каче- стве источника информации для создания контрольных примеров программного обеспечения. По мере разработки системы влияние программных ошибок, сбоев или отказов может быть определено лучше, а также определены обстоятельства или их комбинации, которые могут вызвать отказ. Ключевые причины отказов могут представлять собой ошибки программиста («ошибки»), а также причины, связанные с состоянием аппаратных средств. Для выполнения FMEA необходимо определить, может ли единич- ный отказ программного обеспечения стать причиной неприемлемых локальных последствий (помимо конечных/ глобальных последствий), например: переменная принимает непредусмотренное значение: сообщение содержит непредусмотренные данные или затрачивает на выполнение неожидаемов время: модуль дает нвожидаемые выходы. Затем анализируют каждый вид отказа для (конечных) последствий системы. Это правило, основанное на анализе сложных единичных последствий, которые зависят от времени и состояния систем. Перед выполне- нием FMEA для программного обеспечения необходимо провести отдельный анализ спецификации требований. Поскольку программная ошибка или сбой часто приводят к нежелательным последствиям для аппаратного обес- печения. сначала необходимо выполнить FMEA для аппаратного обеспечения, чтобы установить влияние системы. В этом случае последствия для системы программного обеспечения могут основываться на последствиях для системы аппаратного обеспечения. Следующий перечень основан на примерах, приведенных в [If]- FMEA программного обеспечения также должно учитывать условия эксплуатации, например: аппаратные отказы, вызывающие отказ памяти; периферические отказы карты памяти (например, отказы аналоговых/цифровых преобразователей или устройств ввода-вывода); отказ источника питания, например сброс из-за падения напряжения литания; электромагнитные помехи (EMI). электромагнитные импульсы (ЕМР); неправильно обработанные неверные входные данные, включая ошибки загрузки. Примеры причин отказа на уровне системы: неправильное использование вызовов операционной системы; неверная синхронизация, например коллизия данных из-за изменения времени передачи данных; прерывание обработки и неадекватный анализ: неадекватная или отсутствующая обработка исключений. Примеры ошибок программирования (причины отказов): ошибки проектирования и выполнения (например, при кодировании, масштабировании, разработке алго- ритмов); неадекватное обнаружение ошибок (например, нарушение границ, указатели вне диапазона): неадекватное определение допустимого диапазона; непреднамеренная перезапись в памяти; неадекватная обработка ошибок программного обеспечения (например, неожиданная ситуация). Примеры видов отказов: неправильная точка выхода, превышение времени, неожиданное взаимодействие ввода-вывода; недостающие данные, неверные данные, неверная синхронизация данных, особые данные; ненормальное завершение, пропущенные события, неверные логика, синхронизация/порядок: остановка, аварийный отказ, зависание, медленная реакция, отказ запуска, ошибочные сообщения. Если анализ выполняют с использованием электронной таблицы, обычно можно использовать следующие столбцы: иерархия системы и компонентов; обозначения компонентов; виды отказов причины отказов: последствия неготовности отказавшей функции (при восстановлении программного обеспечения); смягчающее обеспечение проекта (меры по восстановлению проекта, альтернативные пути, защита от отказов); д) компенсационное обеспечение; закрытие вопроса: окончательное снижение неготовности функции в результате идентификации вида отказа. На рисунке Е.1 показан пример модели отказа программного обеспечения. По мере разработки конструкции аппаратного обеспечения анализ рассматривает систему в целом, включая программное и аппаратное обеспечение, и направлен на функции системы и их цепочки. FMEA аппаратного обеспечения изменяется вслед за программной частью, анализ может разрастись до не- желательных размеров при поиске цепочки последствий, приводящих к отказу системы, и оценке влияния их де- градации или значимости их потери на работу системы. При анализе смешанной аппаратно-программной системы предпочтительной практикой является отслеживание функции системы по ветвям сверху вниз для идентификации компонентов программного обеспечения, их возможных ошибок или неисправностей и возможных видов отказов. а также их причин. Следует помнить, что FMEA одновременно исследует только один вид отказов, он не предназначен для рассмотрения функциональных зависимостей, последовательностей событий (отказов) или комбинаций событий. Отказ аппаратного обеспечения может быть причиной отказа программного обеспечения, а с точки зрения FMEA отказ программного обеспечения является следствием отказа аппаратного обеспечения. FMEA программного обеспечения — один из методов (помимо тестирования), который помогает повысить безотказность программного обеспечения. Тестирование также может быть использовано в качестве обработки видов отказов, которые считаются критическими. УПРАВЛЕНИЕ (режимы управления.  Рисунок Е.1 — Общая модель отказа программного обеспечения для компонента программного обеспечения FMEA процесса Для процессов и процедур общая методология FMEA такая же. как и для аппаратного и программного обе- спечения. Начальной точкой анализа является схема работы процесса, структура деления работ или анализ задач. Процесс подразделяют на элементы, которые являются этапами процесса. Уровень декомпозиции выбирают в со- ответствии с областью применения анализа. Функцию каждого этапа или его предполагаемого выхода определяют с помощью описания функции, достаточно специфичного, чтобы был ясен уровень работы, представляющий собой отказ. Ках и в случае FMEA аппаратного и программного обеспечения, варианты отказа функций процесса должны быть перечислены в качестве видов отказов в FMEA процесса. Последствия отказа, механизмы и возможные при- чины отказа также должны быть определены. Механизмы и причины отказов часто охватывают как ошибки челове- ка. так и отказы оборудования. Анализ критичности может быть применен так же. как описано в общем руководстве FMEA. FMEA процесса впервые был применен к производственным процессам, но теперь его применяет более широко. Например, его широко используют при анализе медицинских процедур в здравоохранении. FMEA при проектировании и разработке FMEA — неотъемлемая часть процесса проектирования, от концепции до разработки системы. FMEA — итеративный процесс, он начинается, как только появляется предварительная информация о проекте на высшем уровне системы, и распространяется на более низкие уровни иерархии системы по мере поступления большого количества информации. Адаптация FMEA (приложение А) должна гарантировать, что он вносит существенный вклад в решения организации в отношении осуществимости и адекватности подхода к разработке проекта. Целью FMEAb процессе проектирования является идентификация видов отказов внутри системы и возмож- ных критических отказов, которые могут быть устранены или сокращены с помощью проектных решений как можно раньше. В дополнение к ориентации на надежность FMEA поддерживает усилия по сопровождению, техническому обслуживанию и анашзу риска. E.S FMEA в рамках технического обслуживания, ориентированного на безотказность Для разработки успешной программы технического обслуживания, ориентированного на безотказность, не- обходимо четкое понимание функций объекта, отказов и последствий с точен зрения целей организации при экс- плуатации объекта. FMEA и метод анализа критичности подходят для применения к техническому обслуживанию, ориентиро- ванному на безотказность, если анализ структурирован таким образом, что соответствует требованиям стандарта технического обслуживания, ориентированного на безотказность (ГОСТ Р 27.606). Для структурирования анализа необходимо, чтобы все виды отказов были четко связаны с потерей функции на соответствующем уровне иерархии объекта и чтобы такие аспекты, как «средства обнаружения» отказов, были согласованы с потенциальными задачами технического обслуживания. |