Во второй части стандарта приводится описание принципов менеджмента функциональной безопасности в рамках компании и в рамках проекта как на стадии разработки, так и на стадиях производства, эксплуатации, обслуживания и списания. Приведено более детальное описание процедур подготовки и проведения аудита функциональной безопасности, оценки функциональной безопасности и подтверждающих обзоров (confirmation review).
Проектно-независимая часть менеджмента функциональной безопасности
Эта часть менеджмента функциональной безопасности направлена на создание и поддержание культуры безопасности, системы менеджмента качества, правил, процессов, подходов для обеспечения функциональной безопасности, управление несоответствиями функциональной безопасности и компетентностью специалистов, участвующих в разработке устройств.
Ключевой частью проектно-зависимой части является культура безопасности, которая включает в себя:
- персональную вовлеченность каждого сотрудника, участвующего в разработке устройства и выполняющего работы, связанные с функциональной безопасностью, и
- открытые взаимоотношения между сотрудниками внутри организации, поощряющие “безопасное мышление”, трезвое и непредвзятое отношение к разработке, стремление к лучшим результатам, инициативность, а также самостоятельность и автономность в отношении поддержания культуры безопасности.
Культура безопасности подразумевает наличие в компании правил и процессов, позволяющих в каждом отдельном проекте создавать и поддерживать функциональную безопасность. Эти правила и процессы должны непрерывно улучшаться и иметь связи с аналогичными правилами и процессами по обеспечению информационной безопасности (cybersecurity) и качества внутри компании, а также демонстрировать взаимосвязи с другими аспектами безопасности, например, с электробезопасностью.
Неотъемлемой частью культуры безопасности также считается управление документооборотом. Для создания и поддержания функциональной безопасности организация должна выделять соответствующие человеческие ресурсы, создавать и использовать необходимые инструменты разработки, базы данных, руководства и инструкции. Культура безопасности также предполагает наличие полного карт-бланш у ответственных за функциональную безопасность.
Отличным примером руководства по выстраиванию культуры безопасности в компании могут служить отчеты МАГАТЭ от 1991 и 2015 годов.
Культура безопасности 75-INSAG-4 доклад МАГАТЭ 1991
Ключевые вопросы практики повышения культуры безопасности INSAG-15 доклад МАГАТЭ 2015
На различных этапах жизненного цикла устройств, разрабатываемых в рамках ISO 26262 могут возникать несоответствия функциональной безопасности (safety anomalies). Причины этих несоответствий могут быть самыми различными, начиная от ошибок проектирования и заканчивая ошибками пользователей при использовании устройств. На уровне организации-разработчика устройств должен быть разработан процесс анализа, качественной оценки и устранения таких несоответствий, с фокусом на быстроту и эффективность. Данный процесс должен гарантировать что в устранение несоответствий вовлечены все необходимые специалисты. По результатам устранения несоответствий предполагается проведение процесса внесения изменений в проект (например в виде внесения изменений в конструкторскую документацию).
Несоответствие функциональной безопасности считается устраненным только если реализована рациональная доработка, корректно документированная и верифицированная (подтвержденная) с точки зрения эффективности, а также не обладающая сама по себе неприемлемым уровнем риска.
Компетентность сотрудников, вовлеченных в разработку устройств по ISO 26262 также является неотъемлемой частью менеджмента функциональной безопасности. Такие сотрудники должны иметь не только достаточную техническую квалификацию для понимания всех нюансов разрабатываемого устройства, но и понимать основы функциональной безопасности и структуру стандарта ISO 26262. Данные аспекты покрываются тренингами и квалификационными испытаниями для всех участников проекта еще до его начала.
Для достижения функциональной безопасности разрабатываемых устройств необходимо обязательное наличие в организации системы менеджмента качества (СМК), при этом СМК может быть построена на основе любого стандарта. Так в качестве стандарта для СМК может использоваться ISO 9001, IATF 16949 или ASPICE. Наличие СМК в организации гарантирует, что процессы, описанные в ISO 26262 будут выстраиваться поверх уже имеющихся процессов разработки качественных устройств, добиваясь таким образом их функциональной безопасности при должном уровне надежности и качества. При отсутствии СМК внедрение ISO 26262 в организации представляется маловероятной и трудоемкой задачей.
Зачастую при наличии в организации уже установившихся процессов внедрение ISO 26262 в исходном виде является довольно сложной задачей. Это может быть связано с различием в подходах к разработке, терминологии, последовательности шагов разработки и т.д. Чтобы избежать сложностей, применяется проектно-независимая корректировка жизненного цикла устройств, разрабатываемых в рамках ISO 26262 в масштабе всей организации.
К фазам жизненного цикла функциональной безопасности любого устройства относят следующие этапы:
- Фаза концепции;
- Фаза разработки устройства на уровне системы;
- Фаза разработки устройства на уровне аппаратной части;
- Фаза разработки устройства на уровне программной части;
- Фаза производства, эксплуатации, обслуживания и списания устройства.
Каждая из вышеперечисленных фаз имеет несколько подфаз, которые можно увидеть в содержании соответствующей части стандарта ISO 26262.
Проектно-независимая корректировка представляет собой комплекс работ по адаптации ISO 26262 под текущие процессы компании и включает в себя одно или несколько действий:
- объединение или разбиение подфаз, этапов, задач, описанных в ISO 26262;
- перемещение этапов или задач в другие подфазы или фазы;
- перемещение этапов или задач в добавленные подфазы или фазы;
- повторение подфаз или фаз;
- синхронизация этапов и задач из разных подфаз или фаз;
- пропуск фаз или подфаз, не актуальных для данной организации (допускается только при наличии веской причины).
Проектно-зависимая часть менеджмента функциональной безопасности
Направлена на оперирование многими аспектами проекта разработки устройства в организации и охватывает планирование разработки, правила анализа и внесения изменений, управление распределенной разработкой, создание обоснования безопасности, проведение аудитов функциональной безопасности, оценок функциональной безопасности и подтверждающих обзоров.
Одним из важнейших элементов проектно-зависимой части является распределение ролей и ответственностей внутри проекта. Для распределения ролей и ответственностей могут использоваться различные инструменты, например, RASIC-матрица или матрица распределения ролей и ответственности. RASIC-матрица содержит описание ответственностей:
- R – Responsible (исполняет);
- A – Accountable (несет ответственность);
- S – supported (оказывает поддержку);
- I – Inform after doing (оповещается после исполнения);
- C – Consult before doing (консультирует до исполнения);
и ролей, которые являются обязательными для данного конкретного проекта. В качестве примера ниже изображена RASIC матрица для проекта разработки контроллера управления тягой.
Как указано в RASIC-матрице, основные роли в любом проекте разработки устройства – это менеджер по функциональной безопасности, руководитель проекта, главный технический специалист и руководители разработки программной и аппаратной части.
На диаграмме представлен пример того, какие требования по квалификации могут предъявляться ко всем участникам проекта. Стоит отметить, что каждый из них должен обладать минимальным набором знаний в области функциональной безопасности.
Роль менеджера по функциональной безопасности является ролью, а это значит, что на данную роль не обязательно должен быть выделен отдельный специалист. Допускается, что данная роль может, например, быть совмещена с ролью руководителя проекта, или даже распределена между несколькими ответственными. Также менеджеров по функциональной безопасности зачастую может быть двое, так как один участвует в проекте разработки непосредственно, а второй – осуществляет верификацию проделанной работы. При таком подходе верифицирующий специалист по функциональной безопасности должен быть экспертом, но при этом допускается ограниченность его знаний в предметной области.
В самом начале разработки любого устройства необходимо провести анализ влияния изменений на уровне устройства. Он нужен для того, чтобы понять, является ли разрабатываемое в рамках проекта устройство новым, модификацией уже существующего, или уже существующим, но планируемым к применению в иной рабочей среде. В случае, если устройство или его рабочая среда подлежат изменениям (разрабатываемое устройство не новое), такие изменения должны быть зафиксированы и описаны. Они могут быть условно разделены на 3 категории: изменения конструкции, изменение применения, изменения рабочей среды. По результатам анализа влияния изменений на уровне устройства на функциональную безопасность могут быть приняты решения о внесении изменений или ограничений в конструкцию или функционал уже существующего дорабатываемого устройства.
При повторном использовании элементов необходимо обязательно убедиться в соответствии данного элемента предъявляемым к нему требованиям по функциональной безопасности, определенным в рамках проекта, а также проверить справедливость допущений, сделанных в отношении того, как будет использоваться уже существующий элемент. Также важно понять, какие доработки для заимствуемого элемента могут потребоваться, включая изменения его рабочего контекста. Комплект документации на такой элемент должен всеобъемлюще описывать подходы к правильной интеграции элемента в более высокоуровневую систему. Как правило, случаи повторного использования элементов включают в себя использование квалифицированных аппаратных и программных компонентов, использование элементов, прошедших подтверждение проверкой эксплуатацией (см. часть 8 стандарта), и использование элементов, разработанных вне контекста (см. часть 10 стандарта).
При наличии особенностей в разработке того или иного устройства, может понадобиться проектно-зависимая корректировка жизненного цикла устройств в части аспектов, касающихся обеспечения функциональной безопасности. Всегда должно иметь место рациональное пояснение необходимости такого изменения, а требования к такой корректировке варьируются в зависимости от того, ведется ли разработка устройства вне контекста, проводится ли подтверждение проверкой эксплуатацией и т.д. Все эти аспекты должны быть отражены в плане безопасности и в соответствующем подтверждающем обзоре.
Планирование и координация действий по обеспечению безопасности являются ключевыми аспектами для любого проекта разработки устройств и находятся в зоне ответственности менеджера по функциональной безопасности. Он вправе делегировать некоторые задачи другим специалистам с соответствующими компетенциями, однако остается ответственным за составление плана безопасности, поддержание его актуальности и обновления текущего статуса разработки. Критически важно, чтобы все действия, указанные в плане, были доведены до соответствующих ответственных лиц (ответственность, как уже отмечалось выше, может быть оформлена в виде RASIC-матрицы).
План безопасности может быть как отдельным документом, так и частью общего плана разработки. Вне зависимости от этого план безопасности должен освещать следующие элементы:
- определение зависимых от проекта действий в области безопасности ;
- определение независимых от проекта действий в области безопасности;
- определение адаптации действий по обеспечению безопасности;
- планирование действий по разработке в рамках частей 3, 4, 5 и 6 стандарта
- планирование вспомогательных процессов (например, разработки соглашение о взаимодействии при разработке (DIA));
- планирование действий по верификации и валидации;
- планирование подтверждающих обзоров, аудита(ов) функциональной безопасности и оценки функциональной безопасности;
- планирование анализа зависимых отказов и анализов системы безопасности;
- обеспечение подтверждений проверкой в эксплуатации; и
- обеспечение уверенности в качестве используемых инструментальных средств разработки программного обеспечения.
Типовой план безопасности имеет следующее содержание:
- цель;
- зависимости по срокам от других задач или данных;
- сведения об ответственном по каждой задаче;
- объем ресурсов необходимый для выполнение задач;
- даты начала или окончания задач, а также их длительность;
- перечень ожидаемых результатов по каждой задаче (work products).
В соответствии с планом безопасности должно быть разработано обоснование безопасности. Задача этого документа заключается в демонстрации того, что функциональная безопасность достигнута в рамках данного проекта. Выполнение задачи осуществляется за счет правильно выстроенных аргументов безопасности, то есть пояснений “почему данное устройство можно считать функционально безопасным”. Каждый аргумент, как правило, состоит из 4 уровней: ядро и 3 уровня.
Одним из вариантов построения аргументов является аргументация по требованиям (приводятся по всем целям безопасности уровня ASIL B и выше) с помощью структурированной индексации по целям. При таком подходе указываются цели безопасности, функциональные, технические, аппаратные и программные требования по безопасности, на каждое из которых приводится четырехуровневый аргумент.
Для подтверждения безопасности устройства используются 3 подхода: подтверждающие обзоры, аудит функциональной безопасности и оценка функциональной безопасности.
Подтверждающие обзоры (confirmation review) используются в отношении отдельных результатов выполнения работ/задач и предназначены для подтверждения достаточности и адекватности данных результатов с точки зрения их использования в дальнейшем при формировании обоснования безопасности. Подтверждающие обзоры являются промежуточными контрольными точками в ходе жизненного цикла функциональной безопасности разрабатываемого устройства и обязательно должны быть завершены до запуска производства (а также до начала оценки безопасности). Каждый подтверждающий обзор могут проводить один или несколько специалистов по функциональной безопасности, при этом в ходе подтверждающего обзора проверяется корректность, завершенность, целостность и достаточность представленного на обзор результата работ/документа. В приложении C части 2 стандарта довольно подробно приведены основные детали процесса проведения подтверждающего обзора.
При аудите функциональной безопасности (functional safety audit) проводится экспертиза того, насколько процессы разработки электрических и/или электронных систем, имеющих отношение к выполнению функций, связанных с безопасностью, соответствует стандарту ISO 26262 в части описанных в нем процессов разработки. Рекомендуется для проведения в отношении устройств, среди целей безопасностей которых зафиксирован уровень ASIL B, а для устройств с уровнями ASIL C и ASIL D является обязательным.
Аудитор, как правило, осуществляет следующие виды оценок в ходе аудита:
- оценка соответствия процессов и задач проекта указанным в плане безопасности;
- оценка соответствия результатов выполнения плана работ правилам и руководящим документам организации в области обеспечения функциональной безопасности;
- оценка аргументов в пользу соответствия процесса разработки описанному в стандарте (с учетом проектно-зависимых и проектно-независимых изменений, внесенных в него ранее);
- оценка наличия всех необходимых результатов работ, указанным в плане безопасности;
- оценка соответствия всех необходимых результатов работ, указанных в плане безопасности, требованиям стандарта и проверка их взаимной связности и непротиворечивости.
По итогам аудита приводятся рекомендации для разработчика устройства, в том числе и рекомендации по устранению несоответствий в случае наличия таковых.
При оценке функциональной безопасности (functional safety assessment) проверяется полнота и качество обоснования безопасности, созданного для разрабатываемого устройства. Также как и аудит, оценка рекомендуется для проведения в отношении устройств, среди целей безопасностей которых зафиксирован уровень ASIL B, а для устройств с уровнями ASIL C и ASIL D является обязательной. Структура оцениваемых параметров для оценки функциональной безопасности довольно детально раскрыта в приложении D 2 части стандарта.
Объем работ в рамках оценки функциональной безопасности включает в себя:
- проверку плана безопасности и всех результатов для работ, указанных в нем;
- проверка описания процесса для обеспечения функциональной безопасности (за основу могут быть взяты результаты аудита функциональной безопасности);
- проверка корректности и эффективности защитных механизмов безопасности;
- проверка аргументов в пользу соответствия процесса разработки описанному в стандарте;
- проверка обоснования безопасности и аргументов внутри него;
- проверка отметок об остутствии нарушений безопасности.
По результатам оценки формируется заключение о достижении, не достижении, или условном достижении функциональной безопасности устройством. В случае условного достижения однозначно указываются условия, при которых устройство считается функционально безопасным. В случае заключения о не достижении указываются причины и требуемые корректировки, после чего оценка повторяется.
