Функциональная безопасность, часть 7. Оценивание показателей функциональной безопасности и надежности

Источник

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

Мы рассмотрим следующие вопросы:

— связь атрибутов надежности, информационной и функциональной безопасности;
— переход от анализа рисков к измерению показателей функциональной безопасности;
— примеры расчета показателей надежности и функциональной безопасности.

Атрибуты надежности, информационной и функциональной безопасности

Для того, чтобы лучше понять, какие именно свойства мы будем оценивать, рассмотрим структуру и взаимосвязь атрибутов надежности, ИБ и ФБ.

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

Рисунок 1. Графическая интерпретация определения надежности

Про соотношение свойств dependability и reliability следует сказать отдельно, поскольку в области стандартизации этого свойства западная и советская наука в свое время пошли несколько различными путями. Корректный перевод термина надежность – это dependability, поскольку и надежность, и dependability рассматриваются, как комплексные свойства. Reliability – это правильный перевод для термина безотказность, которая является важной, но все же только одной из составляющих надежности. Безотказностью называется свойство объекта непрерывно сохранять работоспособное состояние в течение некоторого времени или наработки, т.е. безотказность можно обобщать с надежностью только для необслуживаемых систем.

Кроме безотказности, составными свойствами надежности являются ремонтопригодность (Maintainability), долговечность (Durability) и сохраняемость (Storability). Готовность (availability) является комбинацией безотказности и ремонтопригодности.

Все эти положения были изложены в одном из самых лучших по стройности изложения стандартов, которые я когда-либо держал в руках, ГОСТ 27.002-89. «Надежность в технике. Основные понятия. Термины и определения». К сожалению, «неселективная» адаптация западных стандартов в качестве ГОСТ Р привела к тому, что наработки советской школы надежности ныне позабыты (по крайней мере, в области формальной стандартизации). В 2009 году был выпущен стандарт ГОСТ Р 27.002-2009 (первоначальный номер у него почему-то был ГОСТ Р 53480-2009, затем историческая справедливость восторжествовала), представляющий собой копи-паст также достаточно древнего словаря Международной электротехнической комиссии, IEC 60050-191:1990. Прогресс не всегда происходит поступательно, и о качестве изложения вы можете судить сами, сравнив изложение основных терминов (Рисунок 2). В Украине ныне действует ДСТУ 2860-94, соответствующий ГОСТ 27.002-89.

Рисунок 2. Сравнительный анализ атрибутов надежности согласно версий ГОСТ 27.002 от 1989 г. и 2009 г.

Подчеркнем, что мы рассматриваем именно случайные отказы аппаратных средств, к которым может быть применен математический аппарат теории вероятностей. Теория надежности дает практичную картину мира, в которой можно строить надежные системы из не вполне надежных компонентов (как правило, методами резервирования и диагностирования). По-другому обстоит дело с систематическими отказами, которые, очевидно, не могут быть описаны в рамках теории надежности. Именно такие отказы составляют наибольшую проблему, поскольку они непредсказуемы. В 1980-90-е годы были попытки применить вероятностные модели для оценивания надежности программного обеспечения, ошибок оператора, а затем и показателей ИБ. До настоящего момента этот путь не дал практически применимых результатов.

Еще одним подходом к анализу атрибутов надежности являемся так называемый RAMS подход, который расшифровывается, как Reliability (безотказность), Availability (готовность), Maintainability (ремонтопригодность), and Safety (безопасность). Иногда к этой четверке атрибутов добавляется еще и Integrity, интегрированность или полнота, ибо именно так это слово переводится в русскоязычной версии МЭК 61508. Наиболее простыми определениями для этих свойств являются:

— Готовность – это пригодность к правильной эксплуатации;
— Безотказность – это непрерывность правильного обслуживания;
— Ремонтопригодность – это способность подвергаться модификациям и ремонту.
— Безопасность – это отсутствие катастрофических последствий для пользователя и окружающей среды;
— Интегрированность – это отсутствие ненадлежащих системных изменений.

Security (ИБ) представляет собой совокупность атрибутов конфиденциальности, интегрированности и готовности (так называемая триада CIA). Готовность или доступность рассматривается для авторизованных действий по доступу к информации, а интегрированность рассматривается для корректной работы с данными, исключающей их неавторизованное изменение. Конфиденциальность является дополнительным, по сравнению с надежностью, атрибутом, который означает отсутствие несанкционированного раскрытия информации. Таким образом, простейшая модель, описывающая dependability (т.е. надежность) и security (т.е. информационную безопасность) представлена всего шестью атрибутами (Рисунок 3).



Рисунок 3. Атрибуты RAMS & CIA

Теперь сделаем еще одну итерацию и попробуем представить все известные нам атрибуты в виде одной диаграммы (Рисунок 4).



Рисунок 4. Обобщенная таксономия атрибутов надежности, информационной и функциональной безопасности

Обычными линиями отмечены атрибуты и связи, соответствующие только что рассмотренной модели из шести атрибутов. Пунктиром добавлены дополнительные атрибуты. Одна из групп атрибутов относится к составляющим надежности (dependability). ФБ (Safety), согласно МЭК 61508, включает safety functions & integrity, причем, через функции безопасности ФБ связана с безотказностью, готовностью и надежностью, а интегрированность выполнения функций обеспечивает целый ряд свойств, в том числе, ИБ. Таким образом, между атрибутами надежности, ИБ и ФБ существуют взаимное влияние и определенные связи, которые мы будем учитывать при количественном оценивании.

Анализ рисков и показатели функциональной безопасности

Теперь обратимся к показателям безопасности. Базовым понятием и показателем ФБ является риск, представляющий собой комбинацию вероятности нежелательного события и его последствий.

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

Если нежелательное событие и ущерб от него зафиксированы, то риск становится численно равен вероятности P(t) возникновения фиксированного ущерба. Например, риск аварии атомной электростанции с выбросом радиоактивных веществ в атмосферу на сегодняшний день устанавливается не более, чем 10^-7 1/год.

Широкое распространение для оценивания и управления рисками получил так называемый принцип ALARA (ALARP) (as low as reasonably applicable/practicable) – подход к управлению риском, который подразумевает его максимально возможное снижение, достигаемое за счет реально имеющихся (ограниченных) ресурсов (Рисунок 5).



Рисунок 5. Снижения риска на основе метода ALARP (as low as reasonably practicable), IEC 61508-5

Удобной моделью является граф рисков (Рисунок 6). Пример взят из стандарта по безопасности промышленного оборудования (EN ISO 13849-1 Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design). Кроме вероятности и последствий событий учтена еще возможность избегания опасностей и ущерба. Эти три категории имеют высокое и низкое значение, в итоге получаем шесть комбинаций, каждая из которых соответствует тому или иному Performance Level (PL), от а до е, который является аналогом Safety Integrity Level (SIL).



Рисунок 6. Граф рисков, EN ISO 13849-1

Таков качественный подход к оцениванию рисков, теперь рассмотрим, как в МЭК 61508 нормируются количественные значения показателей безопасности. Если рассматривать системы управления, то событиями, связанными с риском, являются отказы функций безопасности, поэтому логично, что в качестве показателей безопасности выбраны вероятности отказов для функций безопасности.

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

Одним из важнейших показателей является вероятность безотказной работы, под которой понимается вероятность того, что отказ не произойдет за установленное время MTTF, называемое наработкой до отказа:
P(t) = P{MTTF > t}. Как и любая вероятность, вероятность безотказной работы принимает значения от 1 до 0, причем единице она равна в начальный момент времени, а нулю равна при времени стремящемся к бесконечности.

Вероятностью отказа называется вероятность того, что отказ произойдет за установленное время T, т.е. вероятность отказа дополняет вероятность безотказной работы до единицы (отказ либо произойдет, либо нет, т.е. имеем полную группу событий): F(t) = 1 – P(t).

Интенсивность отказов – условная плотность распределения (т.е. производная по времени) наработки до отказа при условии, что отказ не произошел, имеет размерность 1/час: λ(t) = f(t)/P(t) = – [1/P(t)] • [dP(t)/dt] = – [1/(1 – F(t)] • [dF(t /dt]. При статистической оценке интенсивность отказов определяется как отношение количества отказавших однотипных изделий к продолжительности интервала времени, на котором эти отказы наблюдались (например, если за 1000 часов отказало 10 изделий, то λ = 10/1000 = 0,01 1/час).

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

Наработка до отказа MTTF вычисляется как определенный интеграл в пределах от нуля до бесконечности для вероятности безотказной работы по времени:



Иногда MTTF трактуется как среднее или гарантированное время работы системы, но это не так, поскольку вероятность безотказной работы в момент времени MTTF равняется 1/е, что приблизительно равно 0,37. Это значит, что для единичного устройства вероятность того, что устройство останется в работоспособным по истечению MTTF составляет всего лишь 0,37. Для группы однотипных устройств это означает, что только 37% из них останется работоспособным по истечению MTTF.

Коэффициент готовности (availability) – это вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается. Рассчитывается коэффициент готовности, как отношения наработки до отказа к сумме наработки до отказа (MTTF) и среднего времени восстановления после отказа (MTTR):

A = MTTF / (MTTF + MTTR).

Для понимания соотношения между надежностью и безопасностью обратимся к классификации отказов, рассмотренной в МЭК 61508 (Рисунок 7). Отказы могут быть опасные и безопасные, а также диагностируемые и недиагностируемые. В рамках надежности рассматриваются все виды отказов. С точки зрения безопасности нас интересуют только опасные отказы, причем важно, чтобы такие отказы были диагностируемые, и при их обнаружении система могла перейти в безопасное состояние.



Рисунок 7. Классификация отказов и показатели безопасности согласно IEC 61508

МЭК 61508 говорит о следующих показателях безопасности.

Во-первых, это так называемая устойчивость к аппаратным отказам (Hardware Fault Tolerance, HFT). Это очень простой показатель, который говорит о том, сколько может произойти аппаратных отказов в системе до выхода ее из строя. По сути, это эквивалентно количеству дополнительных резервных каналов. Т.е., если система нерезервированная, то любой отказ выводит ее из строя, HFT = 0. Если в система два резервных канала, то один из них является дополнительным, избыточным. После единичного отказа система останется работоспособное, т.е. HFT = 1, и т.д.

Во-вторых, должна быть определена доля безопасных отказов (Safe Failure Fraction, SFF). В терминах МЭК 61508 это отношение интенсивности безопасных и опасных диагностируемых отказов к суммарной интенсивности отказов (см. Рисунок 7). Получается, что в терминах МЭК 61508 учитываются, в первую очередь опасные недиагностируемые отказы, а опасные диагностируемые отказы в доле безопасных отказов относятся к безопасным.

Соответственно, может быть определена доля опасных отказов (Dangerous Failure Fraction, DFF), дополняющая долю безопасных отказов до единицы и рассчитываемая, как отношение интенсивности опасных недиагностируемых отказов к суммарной интенсивности отказов (см. Рисунок 7).

Диагностическое покрытие (Diagnostic Coverage, DC_D) в МЭК 61508 определяется только исходя из интенсивности опасных отказов, это отношение интенсивности опасных диагностируемых отказов к интенсивности опасных отказов (см. Рисунок 7).

В технической диагностике более привычным является подход, когда диагностическое покрытие (DC) определяется, как отношение интенсивности диагностируемых отказов к суммарной интенсивности отказов (см. Рисунок 7). Однако, МЭК 61508 декларирует диагностическое покрытие, исходя из доли уменьшения вероятности опасных отказов за счет встроенного диагностирования.

Исходя из полученного значения доли безопасных отказов (Safe Failure Fraction) может быть определен максимально достижимый уровень полноты безопасности SIL, в зависимости от резервированной либо нерезервированной конфигурации (Рисунок 8).



Рисунок 8. Максимально достижимый уровень SIL, исходя из показателей Safe Failure Fraction (SFF) и Hardware Fault Tolerance (HFT), IEC 61508-2

Например, для доли безопасных отказов 90%-99% для нерезервированной конфигурации (HFT=0) может быть достигнут максимальный уровень полноты безопасности SIL2. В дублированной системе (HFT=1) может быть достигнут SIL3, а в троированной – SIL4 (HFT=2). Обычно такой подход применяют разработчики ПЛК и другого оборудования для управляющих систем безопасности. Стойкость к случайным отказам аппаратных средств соответствует уровню SIL2 для нерезервированной конфигурации и уровню SIL3 для дублированной конфигурации. Однако, следует помнить, что при этом стойкость к систематическим отказам, обусловленная реализацией процессов жизненного цикла также должна соответствовать уровню SIL3.

Еще одной градацией, установленной в МЭК 61508, является разделение оборудования на типы А и В (Type A & Type B). К типу А относятся наиболее простые, преимущественно механические и электрические компоненты. Все программируемые электронные компоненты относятся к типу В.

Кроме рассмотренных требований, существуют еще требования к численным значениям показателей безопасности.

Из базовых определений МЭК 61508 вспомним, что существует три режима работы оборудования: с низкой частотой запросов (low demand mode), в котором частота запросов на выполнение функции безопасности не превышает одного в год, с высокой частотой запросов (high demand mode), в котором частота запросов на выполнение функции безопасности превышает один в год, и непрерывный режим (continuous mode). Оказывается, что МЭК 61508 рекомендует различные показатели надежности для этих режимов.

Для систем, работающих с низкой частотой запросов, в качестве целевого показателя должна быть определена средняя вероятность опасного отказа выполнения функции безопасности по запросу (Рисунок 9). Для уровня полноты безопасности SIL1 этот показатель не должен превышать 0,1. С повышением SIL каждый раз вероятность опасного отказа должна уменьшаться в 10 раз. Таким образом, для уровня полноты безопасности SIL4 вероятность опасного отказа должна составлять от 10^-5 до 10^-4.

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



Рисунок 9. Зависимость уровня SIL от значения средней вероятности опасного отказа выполнения функции безопасности по запросу (режим с низкой частотой запросов), IEC 61508-1

Для систем, работающих с высокой частотой запросов или в непрерывном режиме, определяется средняя частота (или интенсивность) опасных отказов функции безопасности (Рисунок 10). Для уровня полноты безопасности SIL1 этот показатель не должен превышать 10^-5 1/час, что эквивалентно одному отказу в 11,4 лет. С повышением SIL каждый раз интенсивность опасного отказа должна уменьшаться в 10 раз. Для уровня полноты безопасности SIL4 интенсивность опасного отказа должна составлять от 10^-9 до 10^-8 1/час, т.е., не чаще, чем один отказ в 11 400 лет. Конечно, для единичной системы это звучит несколько абсурдно, но, если учесть, что в мире эксплуатируются тысячи однотипных систем, то даже с такой низкой интенсивностью отказов опасные отказы являются вполне вероятными, что мы наблюдаем в действительности.

Данный показатель эквивалентен интенсивности опасных недиагностируемых отказов.



Рисунок 10. Зависимость уровня SIL от значения средней интенсивности опасных отказов функции безопасности (режим с высокой частотой запросов и непрерывный режим), IEC 61508-1

Все задачи расчета показателей безопасности связываются воедино в рамках методологии анализа видов, последствий и критичности отказов (Failure Mode, Effect and Criticality Analysis, FMECA). Основные положения данной методики изложены в стандарте IEC 60812:2006 Analysis techniques for system reliability – Procedure for failure mode and effects analysis (FMEA). В Российской Федерации принят ГОСТ Р 51901.12-2007 «Менеджмент риска. Метод анализа видов и последствий отказов», являющийся адаптацией МЭК 60812.

Исходные данные для FMECA могут быть получены в результате применения таких методов, как структурные схемы надежности, анализ дерева отказов и марковский анализ.

Примеры расчета показателей функциональной безопасности и надежности

Теперь рассмотрим несколько примеров по определению показателей безопасности, я их несколько адаптировал на основе примеров, приведенных в «Справочнике инженера по АСУ ТП» Ю.Н. Федорова.

Пусть необходимо рассчитать безопасность простой системы управления технологическим процессом. У нас есть некий резервуар (например, бойлер) с датчиком давления, в который подается по трубе некоторая жидкость (Рисунок 11). При превышении заданного уровня давления должен сработать отсечной клапан и перекрыть подачу жидкости в резервуар. Для обработки сигнала от датчика и выдачи сигнала срабатывания на клапан применяется программируемый логический контроллер (ПЛК). Для конкретики зададим вероятности отказов, пусть для датчика и клапана мы имеем вероятность отказа 10^-3. Чтобы было удобней исследовать подходы к резервированию полевого оборудования, вынесем ПЛК за «скобки», т.е. мы будем считать, что ПЛК абсолютно надежный и его влияние мы учитывать не будем.

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

Теперь скажем пару слов об одном из пробелов в МЭК 61508. Оказывается, что МЭК 61508 не выдвигает никаких требований к надежности и готовности систем управления, он содержит требования только к безопасности. Казалось бы, что это одно и то же, чем надежней система, тем она безопасней. Однако это не совсем так, абсолютно безопасной является та система, которая постоянно находится в безопасном состоянии, то есть не функционирует. Инженерные задачи по разработке систем безопасности включают в себя оптимизацию показателей безопасности (вероятности опасного отказа) и готовности (вероятности ложного срабатывания). На нашем примере мы рассмотрим простейшие архитектуры систем управления с точки зрения вероятностей опасных отказов и ложных срабатываний.

Рисунок 11. Пример 1: Нерезервированная система
Определите вероятность опасного отказа и вероятность ложного срабатывания

Ответ для Рисунка 11

Опасный отказ происходит в случае, когда отказывает или датчик или клапан. В этом случае вероятности складываются, то есть для системы вероятность опасного отказа составляет 2•10^-3. Вероятность ложного срабатывания определяется точно такой же схемой событий и также равна 2•10^-3.

Теперь определим вероятности для различных видов резервирования. Сначала введем резервирование для датчика (Рисунок 12). Будем считать, что резервированные компоненты идентичны, то есть, вероятности их отказа равны. Попробуйте определить, каковы вероятности опасного отказа и ложного срабатывания для этого случая?

Рисунок 12. Пример 2: Резервирование датчиков
Определите вероятность опасного отказа и вероятность ложного срабатывания

Ответ для Рисунка 12

Опасный отказ происходит в случае, когда отказывает или оба датчика или клапан. Вероятности отказов датчиков перемножаются, поскольку для отказа должны произойти оба отказа. Затем результат умножения складывается с вероятностью отказа клапана, получаем в результате 10^-6 + 10^-3 = 1,001•10^-3, то есть величина близкая к 10^-3. Таким образом, резервирования только одного компонента системы позволила снизить вдвое вероятность опасных отказов. Теперь, что получается с ложными срабатываниями? Вероятность ложных срабатываний у нас увеличилась в полтора раза по сравнению с исходной схемой, поскольку ложное срабатывание может произойти для любого из трех компонентов, следовательно, вероятности складываются и получаем 3•10^-3.

Теперь давайте рассмотрим, что получится, если резервируется не датчик, а клапан (Рисунок 13)? Чему равны вероятности?

Рисунок 13. Пример 3: Резервирование клапанов
Определите вероятность опасного отказа и вероятность ложного срабатывания

Ответ для Рисунка 13

Как и следовало ожидать, результат идентичен предыдущей схеме резервирования, вероятность опасных отказов равна 1,001•10^-3, вероятность ложных срабатываний 3•10^-3.

Теперь рассмотрим схему, где резервируются и датчики, и клапаны. Будем считать, что по данным каждого из датчиков формируется сигнал управления на каждый из клапанов (Рисунок 14). Что получаем?

Рисунок 14. Пример 4: Резервирование датчиков и клапанов (1-й способ)
Определите вероятность опасного отказа и вероятность ложного срабатывания

Ответ для Рисунка 14

Опасный отказ наступит, если отказали оба датчика или оба клапана. Таким образом, вероятности отказов для датчиков и для клапанов перемножаются, и эти результаты складываются, получаем
2•10^-6, т.е. мы снизили вероятность опасных отказов в 1000 раз по сравнению с исходной нерезервированной системой. А вот ложное срабатывание произойдет при срабатывании любого из компонентов системы, т.е. все вероятности отказов складываются, и мы получаем 4•10^-3. Т.е. как ни парадоксально звучит, но в системе безопасности резервирование снизило готовность системы в два раза по сравнению с исходной системой.

Для отсечного клапана возможен еще один вид резервирования, когда они устанавливаются параллельно, и тогда подача продукта в резервуар прекращается в том случае, когда сработали оба клапана (Рисунок 15). Как в этом случае определить вероятности опасного отказа и ложного срабатывания?

Рисунок 15. Пример 5: Резервирование датчиков и клапанов (2-й способ)
Определите вероятность опасного отказа и вероятность ложного срабатывания

Ответ для Рисунка 15

Опасный отказ происходит при отказе обоих датчиков либо любого из клапанов. Вероятности отказа датчиков перемножаются, вероятности отказа клапанов складываются. В итоге получаем вероятность опасного отказа 2,001•10^-3. Для вероятности ложного срабатывания вероятности отказа датчиков складываются, вероятности отказа клапанов перемножаются, и мы получаем вероятность ложного срабатывания также равную 2,001•10^-3. Если сравнить с исходной схемой, то опять-таки получается парадокс, ввели резервирование, увеличили в два раза объем оборудования, но никакого выигрыша при этом не получили.

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

Выводы

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

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

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

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

Риск является универсальным показателем функциональной безопасности. В зависимости от типа системы, риск может быть трансформирован в целевые значение коэффициента готовности и интенсивности отказов, которая варьируются в зависимости от уровня полноты безопасности SIL.

Анализ видов, последствий и критичности отказов (FMECA) является наиболее эффективным подходом для количественной и качественной оценки безопасности.

Здесь можно посмотреть видеолекции по теме публикации

Функциональная безопасность, часть 6. Жизненный цикл информационной и функциональной безопасности

Источник

По данным IoT Analytics в 2016 году больше всего проектов (22% от общего количества), связанных с применением интернета вещей, было реализовано для промышленных объектов. Это подтверждает развитие и распространение технологий заявленных в доктрине Industry 4.0.

Таким образом, на наших глазах возник новый класс кибер-физических систем, получивший название Industrial Internet Control Systems (IICS) или Industrial Internet of Things (IIoT).

Из названия понятно, что такие системы являются гибридом технологий, применяемых в АСУ ТП и в системах на базе интернета вещей. Соответственно в таких системах необходимо учитывать все риски, связанные с нарушением свойств информационной (security) и функциональной безопасности (safety).

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

При рассмотрении требований к информационной безопасности АСУ ТП у нас получилось гармонизировать требования к информационной безопасности (ИБ) и функциональной безопасности (ФБ) (см. Рисунок 1). Как видно на рисунке, процессы обеспечения ИБ и ФБ должны реализовываться в рамках единого жизненного цикла.



Рисунок 1. Структура требований к ИБ и ФБ

«Большой» жизненный цикл

Поскольку речь идет, в первую очередь, об АСУ ТП, их жизненный цикл обычно рассматривается в привязке к промышленному объекту управления. Поэтому и рассматривается так называемый «большой» жизненный цикл, связанный с проектированием, строительством, эксплуатацией и утилизацией промышленного объекта, где АСУ ТП является одной из составляющих. Конечно, может осуществляться и модернизация существующего оборудования АСУ ТП, но в «большой» жизненный цикл это также вписывается.

Взглянем, что по этому поводу говорит МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems). В первой части этого стандарта содержится «эпический» рисунок, относящийся к жизненному циклу промышленного объекта. Названия этапов говорят сами за себя. Непосредственно к АСУ ТП относятся следующие этапы (отмечены на Рисунке 2 зелеными звездочками):

— 1 Concept;
— 9 Electrical/electronic/programmable electronic (E/E/PE) system safety requirement specification;
— 10 E/E/PE system realization;
— 12 Overall installation and commissioning;
— 14 Overall operation, maintenance and repair;
— 15 Overall modification and retrofit;
— 16 Decommissioning or disposal.



Рисунок 2. IEC 61508-1, Figure 2 – Overall safety lifecycle
(«*» отмечает этапы, применимые к АСУ ТП)

V-образный («малый») жизненный цикл

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

Далее, МЭК 61508 раскрывает структуру этапа «10 E/E/PE system realization» (см. Рисунок 3). Структура процесса реализации предлагается, как для программного, так и для аппаратного обеспечения, причем для последнего различается программируемая составляющая (например, ПЛИС, программируемые интегральные схемы) и непрограммируемая составляющая.



Рисунок 3. IEC 61508-2, Figure 4 – Relationship between and scope of IEC 61508-2 and IEC 61508-3

МЭК 61508 содержит несколько неточностей и пробелов, связанных со структурой жизненного цикла системы. Это связано с тем, что сделана попытка в «малом» жизненном цикле разделить требования к программному и аппаратному обеспечению, а системный уровень представить в «большом» жизненном цикле.

Таким образом, одна из проблем МЭК 61508 заключается в том, что в нем отсутствует в явном виде жизненный цикл, который мог бы непосредственно быть применен к компьютерным системам управления, будь то АСУ ТП, встроенные системы или уровень устройств «интернета вещей».

Обычно в практике программной и системной инженерии речь идет о разработке системы до момента передачи ее поставщику. Мы будем детально рассматривать именно такой V-образный жизненный цикл. Структура жизненного цикла определена стандартами по функциональной безопасности, в том числе и МЭК 61508 (см. Рисунок 4). По нисходящей ветке жизненного цикла выполняется разработка «сверху – вниз». По восходящей ветке жизненного цикла выполняется интеграция «снизу – вверх», сопровождаемая тестированием на соответствие тем или иным проектным документам.



Рисунок 4. IEC 61508-3, Figure 6 – Software systematic capability and the development lifecycle (the V-model) 

Для детального изучения жизненного цикла предлагается авторская интерпретация, проверенная на собственном опыте в нескольких успешных проектах по сертификации. Предлагаемая структура жизненного цикла, с одной стороны, не противоречит требованиям МЭК 61508, а с другой стороны закрывает некоторые пробелы в требованиях, показывая, как можно в рамках единой модели интегрировать разработку, верификацию и валидацию системы, программного обеспечения и аппаратных средств.



Рисунок 5. Жизненный цикл информационной и функциональной безопасности

Модель жизненного цикла включает в себя следующие последовательно выполняемые этапы (на Рисунке 5 этапы обозначены именами итоговых документов):

— разработка концепции (Concept);
— разработка спецификации требований по безопасности (Safety Requirements Specification, SRS), описывающей систему в виде «черного ящика», то есть, «что выполняется», а не «как выполняется»;
— обзор спецификации требований по безопасности (SRS Review), является этапом процесса верификации и валидации;
— разработка проекта архитектуры системы (System Architecture Design, SAD), описывающей систему в виде «белого ящика», то есть, «как выполняется», а не «что выполняется»;
— обзор проекта архитектуры системы (SAD Review), является этапом процесса верификации и валидации;
— разработка проекта аппаратных средств (Hardware Design), в русскоязычной терминологии эта составляющая называется конструкторской документацией (КД), в нее входят, как проекты электронных плат, так и чертежи механических конструкций и электрической части (так называемой «обвязки»), включающей кабели, компоненты электроснабжения и сопряжения с полевым оборудованием (датчиками и исполнительными механизмами;
— обзор проекта аппаратных средств (Hardware Design Review), является этапом процесса верификации и валидации;
— анализ видов, последствий и критичности отказов (Failure Mode, Effect and Criticality Analysis, FMECA), является этапом процесса верификации и валидации; при выполнении FMECA в первую очередь учитывается структура аппаратных средств, однако, принимается во внимание также механизмы диагностирования и отказоустойчивости, реализуемые в программном обеспечении;
— проектирование программного обеспечения (Software Design);
— обзор проекта программного обеспечения (Software Design Review), является этапом процесса верификации и валидации;
— разработка кода программного обеспечения (Software Coding);
— статический анализ программного кода (Static Code Analysis);
— тестирование программного обеспечения на соответствие требованиям проекта (Software Testing) включает в себя как юнит-, так и интеграционное тестирование, как функциональное, так и структурное тестирование; перед началом тестирования разрабатывается план и спецификация тестирования программного обеспечения (Software Test Plan and Specification, TP&S), результаты тестирования документируются в отчете о тестировании программного обеспечения (Software Test Report, TR);
— тестирование методом засева дефектов в аппаратные средства и программное обеспечение (Fault Insertion Testing), входом для которого являются результаты FMEDA в части анализа реализации самодиагностики; перед началом тестирования разрабатывается план и спецификация тестирования методом засева дефектов (Fault Insertion TP&S), результаты тестирования документируются в отчете о тестировании методом засева дефектов (Fault Insertion TR);
— интеграционное тестирование интегрированных программно-аппаратных компонентов на соответствие требованиям к архитектуре (Integration Testing); перед началом тестирования разрабатывается план и спецификация интеграционного тестирования (Integration TP&S), результаты тестирования документируются в отчете об интеграционном тестировании (Integration TR);
— валидационное тестирование интегрированной системы на соответствие спецификации требований по безопасности (Validation Testing); перед началом тестирования разрабатывается план и спецификация валидационного тестирования (Validation TP&S), результаты тестирования документируются в отчете об валидационном тестировании (Validation TR); учитывая важность данного заключительного этапа жизненного цикла, МЭК 61508 требует, чтобы план валидационного тестирования был составлен сразу после окончания разработки спецификации требований по безопасности (SRS); валидация может включать в себя кроме функционального тестирования также тестирование на устойчивость к экстремальным воздействиям окружающей среды (температурно-влажностным, механическим, электромагнитным, радиационным и т.д.).

Фазы жизненного цикла

Детальное описание фаз жизненного цикла представлено в виде набора таблиц. В таблицах синхронизирована деятельность по обеспечению как функциональной, так и информационной безопасности. Некоторые действия могут быть отнесены одновременно и к ФБ, и ИБ. Для компьютерных систем управления основные риски относятся к нарушениям свойства ФБ. Поэтому в таблице приоритет отдан ФБ. Те действия, которые обеспечивают и ФБ, и ИБ внесены в графу, относящуюся к ФБ. Соответственно, в графе, относящейся к ИБ учтены действия, которые не перекрываются деятельностью по обеспечению ФБ. Понимаю, что выглядит все это несколько скучновато, однако, предлагаемый материал может быть использован в качестве справочного.

Таблица 1. Фаза Concept



Таблица 2. Фаза Safety Requirements Specification



Таблица 3. Фаза Safety Requirements Specification Review



Таблица 4. Фазы System Architecture Design, System Architecture Design Review



Таблица 5. Фазы Hardware Design, Hardware Design Review



Таблица 6. Фаза Failure Mode, Effect and Criticality Analysis



Таблица 7. Фазы Software Design, Software Design Review, Software Coding, Static Code Analysis



Таблица 8. Фаза Software Testing



Таблица 9. Фаза Fault Insertion Testing



Таблица 10. Фаза Integration Testing



Таблица 11. Фаза Validation Testing

Трассировка требований

Трассировка требований является одним из процессов более обширной области знаний, называемой инженерия требований (Requirements Engineering).

Под требованием понимается документальное представление условия или свойства, которому должна соответствовать система или системный компонент, для того, чтобы удовлетворять контракту, стандартам, спецификации или другим формальным документам.

Трассировка требований является методом управления изменяющимися требованиями и относящимися к ним артефактам. Трассировка требований решает три основные задачи:

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

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



Рисунок 6. Пример трассировки требований

Слева представлен фрагмент Safety Requirements Specification. Документ разработан в табличном виде. Для каждого из требований введен идентификатор, в данном случае это EIR.01, требования к интерфейсу электропитания. Сканирование документа для трассировки выполняется инструментальным средством DEUS компании exida. DEUS представляет собой макрос MS Office. Начало требования определяется идентификатором, а окончание требование символом [/]. В поле Allocation указывается документ нижнего уровня, куда трассируются требования спецификации. В данном случае это System Architecture Design. В System Architecture Design также должна быть выполнена разметка требований тегами. Кроме того, для каждого из требований должен быть указан его источник в документе верхнего уровня, так называемое родительское требование. Для нашего требования получилось отношение один-ко-многим, то есть требование к электропитанию отобразилось в требования и к базовой концепции продукта, и к шасси, и ко всем модулям. Далее каждое из требований SAD трассируется в Hardware Design & Software Design. Окончательные результаты трассировки могут быть представлены в виде набора матриц, отражающих соотношения между требованиями документов. Обратная трассировка требований выполняется от документов нижнего уровня к документам верхнего уровня чтобы убедиться в том, что в продукте не появился лишний недокументированный функционал.

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

Выводы

Четвертая индустриальная революция (Industry 4.0) формирует вызовы, связанные с обеспечением информационной и функциональной безопасности для нового типа систем, Industrial Internet Control Systems (IICS) или Industrial Internet of Things (IIoT). В связи с этим представляется важным учитывать в комплексе требования к ИБ и ФБ. Как часть стратегии по реализации требований к ИБ и ФБ, в настоящей статье описана структура и содержание этапов для Safety & Security Life Cycle.

Еще одним вызовом является подготовка специалистов, способных разрабатывать, оценивать и эксплуатировать новый класс систем (IICS, IIoT). Очевидно, что такие специалисты должны владеть технологиями в двух доменах: АСУ ТП и интернет вещей. Наши вузы таких специалистов пока массово не готовят, а на рынке АСУ ТП и интернет вещей, как единый стек технологий, пока еще не «дружат», хотя этот вопрос времени.

Здесь можно посмотреть видеолекции по теме публикации

Функциональная безопасность, Часть 5. Процессы управления и оценивания функциональной безопасности

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

В предыдущей статье была рассмотрена структура требований к функциональной безопасности (см. рисунок 1). Сейчас мы остановимся на двух аспектах: управление функциональной безопасностью (Functional Safety Management) и оценивание функциональной безопасности (Functional Safety Assessment).

Рисунок 1. Структура требований МЭК 61508

План управления функциональной безопасностью (Functional Safety Management Plan)

Процессы управления функциональной безопасностью во многом созвучны с процессами Project Management (PM) и Capability Maturity Model Integration (CMMI).

Рассмотрим, каким образом может быть организовано управление функциональной безопасностью (Functional Safety Management), чтобы соответствовать требованиям МЭК 61508 и других сопряженных стандартов (IEC 61511, IEC 62061, ISO 26262, EN 50129, IEC 62304, etc.).

Такие требования содержатся в разделе 6, который входит в МЭК 61508-1,2,3. Основной объем требований представлен в МЭК 61508-1; в МЭК 61508-2 есть лишь ссылка на часть 1, в МЭК 61508-3 содержится дополнение в части управления конфигурацией программного обеспечения.

Теперь попробуем разобраться в этих требованиях и в действиях, необходимых, чтобы этим требованиям соответствовать. На практике лучше всего для этого разработать специальный документ – «План управления функциональной безопасностью» (Functional Safety Management Plan, FSMP). Такой план будет включать в себя несколько направлений:
— управление персоналом (Human Resource Management);
— управление конфигурацией (Configuration Management);
— выбор и оценивание инструментальных средств разработки (Tools Selection and Evaluation);
— верификация и валидация (Verification and Validation);
— управление документацией (Documentation Management);
— оценивание функциональной безопасности (Functional Safety Assessment).

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

Кроме того, FSMP должен содержать следующие разделы (они либо достаточно просты, либо входят за рамки данной публикации и будут рассмотрены в запланированной публикации по описанию жизненного цикла):
— политика и стратегия проекта (Project Policy and Strategy) – это достаточно декларативное описание того, как и зачем будут достигаться цели проекта; собственно говоря, можно в этой части резюмировать основные положения FSMP;
— управление поставщиками (Suppliers Management) включает взаимодействие с поставщиками продукции и услуг, влияющих на обеспечение функциональной безопасности; это требование пришло из системы менеджмента качества (ИСО 9001); в терминах Project Management аналогом является управление закупками; МЭК 61508 требует, чтобы у поставщиков действовала система менеджмента качества; если у поставщиков есть сертификат ИСО 9001, то проблем не возникает (и наоборот);
— информационная безопасность (Security); МЭК 61508 лишь вскользь говорит об этом важном свойстве, что, конечно, не означает, что данному аспекту не уделяется внимание; эти свойства описаны в других стандартах, и сертификация по их требования представляет собой отдельный процесс; что касается рассматриваемой здесь процессной составляющей, то она, по крайней мере, не противоречит требованиям к системе менеджмента информационной безопасности (например, сертифицируемой согласно ИСО 27000);
— жизненный цикл функциональной безопасности (Functional Safety Life Cycle) должен быть поэтапно описан в FSMP; мы рассмотрим эту составляющую в отдельной публикации, так же, как и примыкающий к ней процесс трассировки требований (Requirement Tracing).

Таким образом, рассмотренная структура FSMP представлена ниже в виде Mind Maps.



Рисунок 2. Структура Плана управления функциональной безопасностью (Functional Safety Management Plan, FSMP)

Как уже было сказано, многие положения в управлении функциональной безопасностью пересекаются или же напрямую заимствованы из управления проектами. Кроме того, применение управления проектами рекомендуется в МЭК 61508, как один из методов защиты от систематических отказов. Поэтому, такие инструменты, как устав проекта, план проекта на основе WBS, Action and Bug Trackers и т.п. горячо приветствуются и рекомендуются к использованию. Я же остановлюсь на том, что должно быть выполнено согласно требованиям стандарта.

Управление персоналом (Human Resource Management)

В принципе, если в компании уже применяется методология Project Management (PMBOOK) или что-то похожее (например, CMMI), то, как правило, ничего особенного по этому направлению делать не придется. IEC 61508 требует выполнить прагматичные действия:
— назначить ответственных лиц для выполнения всех необходимых действий; поскольку здесь же говорится о необходимости координации действий, связанных с обеспечением и оцениванием функциональной безопасности, то целесообразно назначить так называемого Functional Safety Coordinator (или можно также возложить такие функции на менеджера проекта);
— определить процедуры коммуникации между должностными лицами проекта, включая сторонних участников;
— разработать все необходимые процедуры, которые перекрывали бы все направления, перечисленные в FSMP;
— организовать необходимое обучение персонала, гарантирующее поддержание компетенций на требуемом уровне.

Исходя из вышесказанного (а также, из личного опыта), основными инструментами управления персоналом в подобных проектах являются оргдиаграмма (Organizational Chart) и матрица компетенций (Competency Matrix).
Для детального планирования управления персоналом разрабатываем соответствующий план (Human Resource Management Plan). Отметим, что этот план относится не к организации в целом, а лишь к участникам сертифицируемого проекта по разработке продукта (ПО или система), важного для безопасности. В нем должны содержаться (см. рисунок 3):
— организационная диаграмма проекта с описанием проектных ролей;
— список участников проекта с указанием проектных ролей и ответственности за планирование и выполнение работ на тех или иных этапах жизненного цикла;
— матрица компетенций и выводы о достаточности либо недостатке компетенций назначаемых исполнителей (т.е. какие знания и умения требуются для конкретной проектной роли и насколько им соответствует конкретный сотрудник); здесь может возникнуть вопрос: «а как же могут быть назначены люди с недостаточными компетенциями?»; в реальном мире, однако, дефицит ресурсов, в первую очередь, людских наблюдается всегда; позитивная новость при этом состоит в том, что в случае некритического недостатка компетенций многих исполнителей можно обучить недостающим навыкам и знаниям;
— мероприятия по обучению персонала, направленные на достижение и поддержание указанных выше компетенций, критичных для выполнения проекта; планы и отчеты по тренингам должны документироваться;
— план коммуникаций участников проекта;
— лист с подписями персонала, свидетельствующими об ознакомлении с данным планом.



Рисунок 3. Структура Плана управления человеческими ресурсами (Human Resource Management Plan)

Управление конфигурацией (Configuration Management)

Данное направление также достаточно известное и методически отработанное, поскольку перекликается с PMBOOK и CMMI. В терминах функциональной безопасности в управление конфигурацией также включено управление изменениями (Change Control) и реализация модификаций программного обеспечения и оборудования, включая снятие с эксплуатации. В эту же область попадает и анализ опасных событий, поскольку различные происшествия являются входом для внесения изменений. Также многие полезные положения можно почерпнуть из стандарта IEEE 828 Standard for Software Configuration Management Plan.

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



Рисунок 4. Типовые элементы конфигурации (Configuration Items)

Такая структура может служить основой для проектного репозитория. О документах и инструментальных средствах будет подробней рассказано ниже.

Управление конфигурацией напрямую зависит от применяемых инструментов, однако можно выделить некоторые общие моменты, которые необходимо включать в «План управления конфигурацией» (Configuration Management), такие как (см. рисунок 5):
— роли и ответственность участников проекта в процессе управления конфигурацией; из ключевых участников проекта следует организовать группу по управлению конфигурацией и изменениями с вовлечением всех тех лиц, мнение которых важно учитывать при внесении изменений;
— подход к планированию и сопровождению процесса управления конфигурацией;
— ресурсы процесса управления конфигурацией, в первую очередь, применяемый инструментарий (SVN, Git, etc.);
— процедура идентификации всех компонентов конфигурации (Configuration Items) и формирования базовых версий (baselines);
— процедура применения инструментария для контроля версий программных и аппаратных компонентов продукта и для учета их статуса;
— процедура доступа к компонентам конфигурации и резервного хранения;
— процедура и периодичность проведения аудитов конфигурации;
— процедура анализа и устранения выявленных дефектов, в том числе, обнаруженных в процессе эксплуатации (это один из возможных входов для следующего пункта – Change Control);
— процедура контроля внесения изменений (Change Control), включая анализ влияния изменений (Impact Analysis) и проверку корректности внесения изменений.



Рисунок 5. Структура Плана управления конфигурацией (Configuration Management Plan)

Процедура контроля внесения изменений критически важна при внедрении и сертификации процессов. Для формализации обычно применяется поэтапная обработка запросов на внесение изменений (Change Request). Этапы внесения изменений представлены ниже на диаграмме (см. рисунок 6) и включают в себя:
— Submit – поступление запроса на внесение изменений, причиной может быть любая коррекция или доработка;
— Approve – рассмотрение и формальное утверждение запроса; разумеется, запрос может быть отклонен, тогда последующие этапы не выполняются;
— Impact Analysis – анализ влияние запроса на функционал, безопасность, объем и стоимость работ и т.д.; здесь же определяется не только объем разработки, но изменения документации, тестирования и других проверок, связанных с верификацией и валидацией;
— Implement – непосредственная реализация изменений;
— Verify – выполнение (возможно, поэтапное) различного рода верификационных проверок в части внесенных изменений;
— Close – формальное закрытие запроса на внесение изменений.

 

Рисунок 6. Процесс управления имениями (Change Control), основанный на обработке запросов на внесение изменений (Change Request)

Выбор и оценивание инструментальных средств разработки (Tools Selection and Evaluation)

Действия по выбору и оцениванию инструментальных средств (ИС) тесно примыкают к управлению функциональной безопасности, хотя требования изложены в МЭК 61508-3 (7.4.4 Requirements for Support Tools, including Programming Languages).

В зависимости от степени влияния на конечный продукт (систему и программное обеспечение), инструментальные средства классифицируются следующим образом:
— инструментальные средства класса T1 не генерируют выходы, которые непосредственно влияют на исполнимый код; сюда можно отнести тестовые и графические редакторы, средства управления конфигурацией (те, которые непосредственно не генерируют код), Action & Bug Tracker;
— инструментальные средства класса T2 поддерживают тестирование и другие виды верификации (например, статический анализ кода или анализ полноты тестового покрытия); при этом непосредственное влияние на исполняемый код не оказывается, однако, проблема в средствах тестирования может привести к тому, что ошибки в программном обеспечении, возможно, не будут обнаружены; к данному классу должны быть отнесены не только программные средства, но и программно-аппаратные симуляторы входных/выходных сигналов; следует отметить, что к классу T2 также могут быть отнесены средства проектирования механических, электрических и электронных компонентов (например, печатных плат);
— инструментальные средства класса T3 генерируют выходы, которые непосредственно влияют на исполнимый код, к ним относятся трансляторы и компиляторы, скрипты для поддержки сборок и SCADA в части конфигурации контроллеров.



Рисунок 7. Классификация типовых инструментальные средств для проектов, связанных с функциональной безопасностью

Обоснование возможности применения компиляторов для целей функциональной безопасности представляет собой наибольшую проблему, поскольку требования к ним таковы, что должно быть проведено полное тестирование всех функций, влияющих на генерацию исполнимого кода. От разработчика получить такую информацию в частном порядке вряд ли удастся, а самостоятельно проводить 100% тестирование чужого компилятора – это тоже мало подъемная задача. К счастью, в последние лет 5 многие ведущие производители программируемых чипов (CPU, FPGA/CPLD) вышли на рынок с уже сертифицированными по требованиям МЭК 61508 версиями компиляторов. Такой инструментарий может быть использован для разработки продуктов, соответствующих требованиям МЭК 61508. Проблемы здесь две: высокая стоимость многих таких инструментов (как правило, тысячи долларов) и то, что они совместимы далеко не со всеми микросхемами, поддерживаемыми типовыми версиями компиляторов.

Близкой к инструментальным средствам областью является выбор и применение правил кодирования, которые требуют использования ограниченного безопасного множества конструкция языка программирования.

На что следует обратить внимание при использовании инструментальных средств? Есть несколько положений, заданных в требованиях МЭК 61508:
— для инструментальных средств классов T2 и T3 должны быть доступны спецификации требований или пользовательская документация, которые однозначно описывают то, как происходит функционирование;
— для инструментальных средств классов T2 и T3 должно быть документально подтверждено их соответствие спецификации требований или пользовательской документации, например, в виде сертификата;
— должны контролироваться версии используемых инструментальных средств, поскольку не для всех версий могут выполняться указанные условия; все участники проекта должны использовать одну и ту же версию; для переходов между версиями должна применяться соответствующая процедура;
— если инструментальные средства используются как единый технологический комплекс (например, на основании спецификации генерируются код и тесты), то должна быть протестирована их совместимость между собой.

Для обеспечения соответствия указанным требованиям целесообразно разработать специальный Отчет по выбору и оцениванию инструментальных средств (Tools Selection and Evaluation Report, TSER). В него надо включать:
— описание используемого стека инструментальных средств (как программных, так и аппаратных, как коммерчески доступных, так и собственной разработки) используемых для разработки продукта, его испытаний, а также поддерживающих процессов (управление конфигурацией, набор текстовых документов, управление проектом и т.д.); для каждого из инструментов следует указать: тип (для поддержки какого процесса используется), наименование, номер версии, наименование поставщика, класс (T1, T2 или T3), генерируемые выходы в терминах компонентов конфигурации (Configuration Items);
— результаты оценивания (анализа) инструментальных средств согласно набору заданных критериев, таких как, например: выполняемые функции и их применимость в данном проекте, опыт использования, доступная документация, информация о поставщике (репутация на рынке, система менеджмента качества, подход к управлению конфигурацией и т.п.), влияние на безопасность продукта, обнаруженные и устраненные ошибки, возможные риски использования с точки зрения проявления отказов и стратегия управления данными рисками.

Если проект выполняется с использование отработанного стека технологий, то может быть использован или доработан типовой TSER.

Верификация и валидация (Verification and Validation)

Реализация данного процесса зависит от структуры выбранного жизненного цикла, поэтому детали есть смысл рассмотреть в планируемой публикации на тему жизненного цикла функциональной безопасности (Functional Safety Life Cycle).

Следует отметить, что верификация и валидация включают в себя не только тестирование, но и обзоры проектных документов, анализ видов и последствий отказов (Failure Mode and Effect Analysis), статический анализ кода и т.п.

В целях управления функциональной безопасностью есть смысл разработать верхнеуровневый план верификации и валидации (Verification and Validation (V&V) Plan), включающий следующие положения (см. рисунок 8):
— описание организации процесса V&V и распределение ресурсов на выполнение;
— этапы V&V в связи с этапами разработки;
— методы и инструментарий для выполнения V&V;
— требования к документированию результатов V&V;
— требования к обработке обнаруженных аномалий.



Рисунок 8. Структура Плана верификация и валидации управления конфигурацией (Verification and Validation Plan)

Планы, спецификации и отчеты по отдельным обзорам, анализам и тестам, как правило, представляют собой автономные документы.

Управление документацией (Documentation Management)

Требования к документации содержатся в разделе 5 МЭК 61508-1. Основные требования следующие:
— документы должны содержать достаточную информацию, как для последующих стадий разработки, так и для верификации результатов текущей стадии;
— документы должны содержать достаточную информацию, как для обеспечения, так и для оценивания функциональной безопасности;
— документы должны быть доступны для должностных лиц проекта по разработке и сертификации продуктов (ПО и систем), связанных с обеспечением безопасности;
— документы должны иметь номер версии и дату последнего изменения; изменения в документы должны вноситься согласно упомянутой выше процедуре управления изменениями (Change Control).

Для детального планирования управления документацией разрабатываем соответствующий план (Documentation Plan). Отметим, что этот план относится не к организации в целом, а лишь к участникам сертифицируемого проекта по разработке продукта, важного для безопасности (ПО или системы). В нем должны содержаться (см. рисунок 9):
— требования к идентификации, разработке, оформлению, согласованию и утверждению документов;
— процедура обзора и критерии оценивания документов (например, в виде чек-листов); в частности, критериями оценивания документов согласно МЭК 61508 являются: точность, краткость, понятность, пригодность или соответствие назначению, доступность для использования и сопровождаемость;
— перечень документов по проекту и распределение ответственности за разработку;
— процедура организации доступа и права доступа участников проекта к документам;
— процедура внесения изменений в документы, политика учета и изменения версий;
— требования к применению электронной системы документооборота (EDCS – Electronic Document Control System) и структура проектного репозитория.



Рисунок 9. Структура Плана документирования (Documentation Plan)

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

Документы разрабатываемые в проекте, связанном с обеспечением функциональной безопасности. включают следующие типы (см. рисунок 10):
— документы по планированию функциональной безопасности, рассмотренные в данной статье;
— спецификация требований (Safety Requirements Specification, SRS) и системная архитектура (System Architecture Design, SAD);
— проект аппаратных средств, называемый также конструкторской документацией (Hardware Design);
— проект программного обеспечения (Software Design);
— документы по верификации и валидации;
— документы, относящиеся к так называемому квалификационному тестированию оборудования (Equipment Qualification Testing) на устойчивость к экстремальным воздействиям; обычно задаются уровни таких воздействий, как климатические (температурно-влажностные), механические (удары, поиск резонанса, транспортная тряска, сейсмика), электро-магнитные;
— рассмотренные выше документы, относящиеся к инструментальным средствам (руководства пользователя, спецификации требований, сертификаты, подтверждающие соответствие требованиям, информация о поставщиках);
— рассмотренные выше документы по управлению изменениями (Change Control);
— пользовательская документация на поставляемый продукт, в том числе руководство пользователя по безопасности (Product Safety Manual);
— руководства, процедуры и инструкции, используемые в проекте для организации работы; такие документы могут быть использовать принятые в компании практики либо могут быть разработаны специально для проекта, связанного с функциональной безопасностью.



Рисунок 10. Классификация документации для проектов, связанных с функциональной безопасностью

Оценивание функциональной безопасности (Functional Safety Assessment)

Теперь посмотрим, как оценивается функциональная безопасность.
Для этого в ходе операционной деятельности проводятся периодические аудиты функциональной безопасности (Functional Safety Audit).
Кроме того, при проведении сертификации выполняется оценивание процессов и продукта сертифицирующей организацией, по итогам которого выдается сертификат соответствия. Наиболее известными сертификаторами функциональной безопасности является группа компаний TÜV.
Аудиты должны проводиться согласно заранее разработанным планам (Functional Safety Audit Plan). В планах должны быть определены:
— периодичность проведения аудитов (например, по завершению каждого из этапов разработки);
— область оценивания с точки зрения продуктов и процессов;
— вовлеченные организации и другие требуемые ресурсы;
— уровень независимости адиторов; аудиты могут быть внутренними, тогда аудиторами являются участники проекта, незадействованные в процессах, которые подвергаются аудиту; кроме того, сертифицирующая организация также может участвовать в периодических аудитах; вообще, вопрос независимости при оценивании безопасности имеет свои традиции в разных отраслях промышленности;
— компетентность лиц, выполняющих аудит;
— ожидаемые результаты;
— организация действий по устранению недостатков.
Исходными данными для составления чек-листа аудита являются требования FSMP и других подчиненных планов, рассмотренных в данной статье.
По результатам проведения аудитов должны быть выпущены соответствующие Отчеты об аудитах функциональной безопасности (Functional Safety Audit Reports).

Выводы

В статье проанализированы положения МЭК 61508, относящиеся к управлению функциональной безопасностью (Functional Safety Management) и оцениванию функциональной безопасности (Functional Safety Assessment).
Реализуемые процессы соответствуют основным положениям управления проектами, а также программной и системной инженерии.
Интерпретация требований может несколько отличаться для различных областей индустрии, поскольку для них разработаны собственные стандарты, которые, тем не менее, во многом гармонизированы с МЭК 61508.
Предлагаемый читателю материал подтвержден опытом (6 лет в успешных проектах по сертификации) при работе с сертифицирующими компаниями exida и TÜV.

Здесь можно посмотреть видеолекции по теме публикации.