Функциональная безопасность, часть 4 из 4. Процессы управления и оценивания
Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.
Данная статья продолжает серию публикаций на тему функциональной безопасности.
Часть 1 является вводной.
В части 2 рассмотрена общая структура стандарта МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems) и используемая в нем терминология.
В части 3 требования МЭК 61508 разложены «по полочкам» на основе их общей классификации.
В данной статье достаточно абстрактные требования к управлению функциональной безопасностью интерпретированы для внедрения в рабочие процессы. Эта информация проверена и отшлифована на практике нескольких проектов по сертификации.
Процессная инженерия — скучно это или нет? Именно процессы позволяют масштабировать 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 и, разумеется, из блогов авторов хабра, например, «Записки отставного сиэмщика» от @Aguary.
При определении элементов конфигурации (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.
