Индуктивный анализ

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

На рисунке закрашенными точками меньшего размера показаны сбои компонентов, а точками большего размера – отказное состояние системы. Пунктирными линиями показано распространение отказа. За один шаг анализа (другими словами – строчкой в таблице, документирующий анализ) принимают «переход» от одного отказа к другому. Для каждого такого «перехода» можно определить параметры. Список параметров зависит от конкретного вида анализа. Эти параметры связаны с вероятностью «перехода» и/или вероятностью обнаружения отказа до того, как отказ начнет распространяться. По параметрам определяют критичность отказа. Затем разрабатывают меры, направленные против возникновения и/или распространения отказов. Чем критичнее отказ -- тем больший приоритет у мер по борьбе с ним.

К индуктивным видам анализа относится анализ видов и последствий отказов (АВПО). По-английски он называется Failure Mode and Effect Analysis (FMEA). Туда же -- подвиды FMEA: DFMEA (Design FMEA), SFMEA (System FMEA), FMEDA (Failure Modes, Effects and Diagnostics Analysis), FMECA (Failure modes, Effects and Cost Analysis), SW FMEA (Software FMEA) и т.п. Кроме того, анализ дерева событий (АДС, ETA), применяемый для поиска опасных путей исполнения программ -- тоже индуктивный.

Дедуктивный анализ

Дедуктивный анализ начинается с отказов системы и идёт «назад» – к сбоям отдельных элементов. В ходе анализа выясняется, какие сбои компонентов привели к интересующему отказу. Если сбоев больше одного – важно, в каких они отношениях. Если отказ происходит после двух сбоев, такие сбои объединяются логическим элементом «И», а если каждый сбой отдельно вызвает отказ – нужна логическая операция «ИЛИ».

Анализ дерева отказов (АДО; по-английски – Fault Tree Analysis, FTA) -- дедуктивный, как и все его подвиды: SW FTA, System FTA, HW FTA.

Резюме

Чтобы завершить разговор о различных видах анализа безопасности, приведем несколько таблиц.

Виды анализа безопасности

Входная информация

Результаты

Требования ИСО 26262

Давайте еще раз посмотрим на картинку с информационными потоками. Чтобы анализировать, нужно как минимум знание:
* Методики проведения анализа
* Функций системы и отказных состояний
* Структуры системы
* Компонентов и видов их отказов

Маловероятно, что в компании найдется человек, хорошо знакомый со всем списком. Значит, для анализа нужна команда. Дальше расскажем, как организовать эту команду.

Анализ и люди

Модератор
Модератор или фасилитатор– капитан команды и процентов на семьдесят определяет успех мероприятия. Для него важны и технические знания, и личные качества. Еще он знает инструмент, используемый для документации, иначе часть времени уйдет на «борьбу» с таблицами, а не на работу.

Технические знания, необходимые модератору – во-первых, методика анализа. Если оператор методически не подготовлен, то анализ не достигнет цели. Если в ходе анализа «незаметно» поменяются границы или целевой уровень рассмотрения, или даже шаблоны фраз в документации, в выводах будет что-то пропущено. Избежать таких «внезапных изменений» помогает знание методов и опыт. У опытного модератора появляется «чувство анализа» — какое значение параметра соответствует ситуации, документировать описанные неполадки как отказ подсистемы или как отказное состояние и т.п.

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

Другие участники
Сотрудники приглашаются к участию в анализе не просто так, а за знания, которых нет у других. Чаще всего необходимы:

* Системный архитектор или инженер – специалист по функциям и структуре системы. Если в штатном расписании нет такой должности, его «выбирает» коллектив: системный инженер — человек, к которому коллеги наиболее часто обращаются с вопросом «как это работает?»
* Специалист по качеству / взаимодействию с поставщиками – эти люди чаще всего разбираются с отказами компонентов. Ответы на вопрос «Как это может сломаться?» очень пригодятся, особенно если под рукой нет справочника или базы данных, суммирующей опыт компании
* Специалист сервисного обслуживания или сотрудник отдела продаж расскажет, какие функции и свойства продукта важны для покупателей, а какие – менее важны, это нужно для приоритизации мер, разработанных во время анализа.

Отдельно — о тех, кого не надо приглашать
* Присутствие высокого руководства не делает легче свободный обмен мнениями: одни будут молчать, боясь показать себя не с той стороны, др – соглашаться с руководителем, третьи – наоборот, постоянно говорить, чтобы руководство заметило. И без того сложная задача модератора станет еще труднее.
* Сотрудники «экономического блока» вряд ли помогут анализу конструкции, зато внесут разлад, пытаясь приоритизировать разрабатываемые меры по стоимости. Это правильно при проведении FMECA, но неуместно в других видах анализа.

Советы начинающим модераторам
* В командах меньше 5 человек трудно инициировать обсуждение, люди будут только отвечать на вопросы.
* С командами больше 10 человек трудно работать – люди будут отвлекаться, варианты будут сыпаться слишком быстро, это скоро надоест…
* Если сомневаетесь, приглашать коллегу на аналитическую сессию или нет – лучше пригласить хотя бы на одну. * Если коллега там не нужен, на следующую он сам не захочет.
* К аналитической сессии нужно готовиться: получить необходимый минимум знаний о системе и заполнить обязательные поля в листе анализа, чтобы не терять времени на встрече. Если 12 человек ждали 5 минут, пока вы воевали с документацией – потерян один человеко-час.
* Главное в анализе – не заполненная таблица, а предложенные меры по улучшению функционала и снижению риска.

Роль SafetyConsult
Все сотрудники SafetyConsult имеют опыт участия в аналитических сессиях. Среди нас есть опытные модераторы. Можем проводить сессии оффлайн и онлайн.

Когнитивные искажения — враг инженера, и всех остальных тоже враг.