Главная | Обратная связь | Поможем написать вашу работу!

Анализ дерева отказов

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

В рамках индуктивных и дедуктивных методов существуют различные подходы к анализу опасностей и рисков. Они включают экспертизы таблиц контрольных проверок и такие более формальные методы, как анализ сетей Петри [277], методы формальной логики [188] и анализ дерева отказов [183].

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

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

Дерево отказов на рис. 17.3 не завершено. Здесь показаны только потенциальные сбои и ошибки программного обеспечения. Сбои оборудования, например понижение напряжения батареи, вызывающие отказ датчика, не показаны. На этом уровне детализации дальнейший анализ опасностей невозможен. Чтобы использовать дерево отказов для анализа опасностей, возникающих в процессе проектирования и разработки систем, необходима более детальная и подробная информация. В работах [183, 214] показано, как деревья отказов можно использовать для анализа программного обеспечения вплоть до уровня отдельных операторов программного кода.

Рис. 17.3. Дерево отказов системы инъекций инсулина

Оценка рисков

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

1. Недопустимые. В этом случае система разрабатывается таким образом, чтобы опасность либо не возникала, либо, если возникла, не приводила к тяжелым последствиям.

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

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

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

Рис. 17.4. Уровни риска

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

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

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

Таблица 17.4. Анализ рисков

Опасность	Вероятность опасности	Серьезность опасности	Риск	Допустимость опасности
Передозировка инсулина	Средняя	Высокая	Высокий	Недопустима
Недостаточная доза инсулина	Средняя	Низкая	Низкий	Допустима
Отказ элетропитания	Высокая	Низкая	Низкий	Допустима
Неправильно собран механизм введения инсулина	Высокая	Высокая	Высокий	Недопустима
Повреждение механизма введения инсулина	Низкая	Высокая	Средний	Минимально допустима
Инфекция через механизм введения	Средняя	Средняя	Средний	Минимально допустима
Электрические помехи	Низкая	Высокая	Средний	Минимально допустима
Аллергическая реакция	Низкая	Низкая	Низкий	Допустима

Уменьшение рисков

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

1. Предотвращение опасности. Система проектируется так, чтобы опасность не могла возникнуть.

2. Обнаружение и устранение опасности. Система разрабатывается таким образом, чтобы опасности обнаруживались и нейтрализовались раньше, чем они приведут к серьезным последствиям.

3. Ограничение последствий. Система разрабатывается так, чтобы свести последствия опасностей к минимуму.

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

Рассмотрим ошибки программного обеспечения (см. рис. 17.3), приводящие к опасностям в системе инъекций инсулина.

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

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

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

Некоторые требования безопасности для системы инъекций инсулина приведены во врезке 17.1. Они являются пользовательскими требованиями и, конечно, должны быть детализированы в заключительной системной спецификации. Табл. 3 и 4, на которые есть ссылки в требованиях, должны быть включены в документ спецификации.

Врезка 17.1. Примеры требований безопасности для системы инъекций инсулина

Требование 1 Разовая доза инсулина не должна превышать максимальной дозы, определенной для пользователя

Требование 2 Суммарная доза инсулина не должна превышать суммарной дозы, определенной для пользователя

Требование 3 Система должна включать диагностическое оборудование не менее 4 раз в час

Требование 4 Система должна иметь обработчик исключений, определенный в табл. 3

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

⇐ Предыдущая 118 119 120 121 122123124 125 126 127 Следующая ⇒