ISO 26262

ISO 26262 — международный стандарт по функциональной безопасности дорожных транспортных средств. Стандарт был подготовлен к выпуску Техническим комитетом ISO/TC 22/SC 32 «Электрические, электронные компоненты и виды систем общего назначения» Международной организации по стандартизации и выдержал на данный момент 2 издания: первое — в ноябре 2011 года^[1] и второе — в декабре 2018 года^[2].

Полное наименование стандарта: «Дорожные транспортные средства — Функциональная безопасность».

Область применения стандарта

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

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

Структура стандарта

Последнее издание стандарта состоит из 12 частей:

• Часть 1 — Словарь. Содержит термины, определения, сокращения и описания основных идей и концепций, используемых во всех частях стандарта.
• Часть 2 — Менеджмент функциональной безопасности. Содержит описание принципов менеджмента функциональной безопасности в рамках компании и в рамках проекта, а также основные шаги по подтверждению соответствия разрабатываемых систем требованиям по функциональной безопасности.
• Часть 3 — Стадия концепции. Описывает шаги, необходимые для описания исследуемой/разрабатываемой системы, определения создаваемых ею опасностей, проведения оценки рисков по данным опасностям, выявления целей безопасности и функциональных требований по безопасности.
• Часть 4 — Разработка на уровне системы. В данной части описываются требования, предъявляемые к архитектуре исследуемой или разрабатываемой системы с учетом технических требований по безопасности, её верификации и валидации.
• Часть 5 — Разработка на уровне аппаратного обеспечения. Определяет процессы идентификации аппаратных требований по безопасности исследуемой/разрабатываемой системы, правила разработки архитектуры аппаратной части системы с учетом этих требований, методы её верификации и валидации.
• Часть 6 — Разработка на уровне программного обеспечения. Определяет процессы идентификации программных требований по безопасности исследуемой/разрабатываемой системы, правила разработки архитектуры программного обеспечения системы с учетом этих требований, методы его верификации и валидации.
• Часть 7 — Производство, эксплуатация, обслуживание и списание. Охватывает методы обеспечения функциональной безопасности на этапах жизненного цикла исследуемой/разрабатываемой системы в период после окончания её разработки.
• Часть 8 — Вспомогательные процессы. Освещает процессы работы с поставщиками и кооперациями, документирования, учета изменений, конфигурирования, определения требований, верификации, квалификации и использования готового программного и/или аппаратного обеспечения в проектах, применения в проекте систем не соответствующих требованиям стандарта и интеграции требований стандарта с требованиями других стандартов по функциональной безопасности.
• Часть 9 — Анализ безопасности и автомобильных уровней полноты безопасности (ASIL — Automotive Safety Integrity Level). Данная часть содержит описание подходов к декомпозиции ASIL, определению критериев совместного использования различных видов компонентов в составе систем, анализу зависимых отказов и безопасности.
• Часть 10 — Руководящие указания по ISO 26262. Содержит важные примеры применения требований, освещенных в частях 2-9 стандарта.
• Часть 11 — Руководящие указания по применению ISO 26262 при разработке полупроводников. Определяет основные идеи и концепции применения стандарта в отношении полупроводниковых компонентов, например микроконтроллеров или интегральных схем, включая анализ их безопасности, тестирование с введением неисправностей, определение моделей отказов и т. д.
• Часть 12 — Адаптация ISO 26262 для применения в отношении мотоциклов. В последней части обозначены особенности применения стандарта в отношении мотоциклов.

Краткий обзор некоторых частей стандарта

Часть 1 — Словарь

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

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

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

Часть 2 — Менеджмент функциональной безопасности

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

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

На диаграмме изображена структура 2 части стандарта. Условно ее можно разделить на 3 части: проектно-независимая и проектно-зависимая части менеджмента функциональной безопасности, а также менеджмент функциональной безопасности при производстве, эксплуатации, обслуживании и списании.

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

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

Для достижения функциональной безопасности разрабатываемых устройств необходимо обязательное наличие в организации системы менеджмента качества (СМК), при этом СМК может быть построена на основе любого стандарта. Так в качестве стандарта для СМК может использоваться ISO 9001, IATF 16949 или ASPICE. Наличие СМК в организации гарантирует, что процессы, описанные в ISO 26262 будут выстраиваться поверх уже имеющихся процессов разработки качественных устройств, добиваясь таким образом их функциональной безопасности при должном уровне надежности и качества. При отсутствии СМК внедрение ISO 26262 в организации представляется маловероятной и трудоемкой задачей.

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

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

Пример структуры аргумента безопасности

В соответствии с планом безопасности должно быть разработано обоснование безопасности. Задача этого документа заключается в демонстрации того, что функциональная безопасность достигнута в рамках данного проекта. Выполнение задачи осуществляется за счет правильно выстроенных аргументов безопасности, то есть пояснений «почему данное устройство можно считать функционально безопасным». Каждый аргумент, как правило, состоит из 4 уровней: ядро и 3 уровня.

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

Для подтверждения безопасности устройства используются 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 части стандарта. По результатам оценки формируется заключение о достижении, не достижении, или условном достижении функциональной безопасности устройством. В случае условного достижения однозначно указываются условия, при которых устройство считается функционально безопасным. В случае заключения о не достижении указываются причины и требуемые корректировки, после чего оценка повторяется.

Часть 3 — Стадия концепции

На стадии концепции начинается непосредственно разработка устройства (item), являющегося объектом исследования/разработки в ISO 26262. Устройствами являются электрические и/или электронные системы, имеющие отношение к выполнению функций, связанных с безопасностью. Устройство — это система, или совокупность систем, в отношении которых применяется стандарт ISO 26262, и которые полностью или частично реализуют функции транспортного средства. К таким функциям, например, может относиться функция движения транспортного средства, где расчет значения крутящего момента в зависимости от различных параметров является ее частью и реализуется контроллером управления тягой, который в свою очередь и является устройством.

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

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

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

На основе определение устройства, а если быть точным, указаных в нем функций устройства, используется для определения опасных событий, к которым может привести некорректная работа устройства. Для этого проводится анализ опасностей и оценка рисков (hazards analysis & risk assessment), в ходе которых определяются опасности некорректного поведения устройства, следующие за ними опасные события (для которых выставляется уровень критичности) и определяются цели безопасности.

Связь некорректного функционального поведения, опасностей и опасных событий

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

Если величина риска является приемлемой (уровень QM) в рамках проекта, то считается, что функциональная безопасность системы обеспечена в отношении данного опасного события. Если нет (ASIL A — ASIL D), то требуется дальнейшая проработка данного опасного события с целью определения защитных механизмов безопасности для снижения величины его риска до приемлемого уровня и обеспечения функциональной безопасности.

Первым этапом после анализа опасностей и оценки рисков является формирование целей безопасности (safety goals). Несмотря на название, цели безопасности представляют собой высокоуровневые требования безопасности, выполнение которых гарантирует безопасность рассматриваемого устройства. Цели безопасности определяются на основе анализа всех опасных ситуаций, которые может создать некорректное функциональное поведение устройства, и, довольно часто (но не всегда), представляют собой утверждения, противоположные опасностям, которые порождают опасные события. В рассмотренном выше примере опасностью было «непреднамеренное ускорение», а значит цель безопасности может звучать как «транспортное средство не должно непреднамеренно ускоряться».

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

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

Примером функциональных требований по безопасности может служить следующее требование: «Любое непреднамеренное ускорение транспортного средства с ускорением более 0.3 g в течение более чем 100 мс вызываемое контроллером тяги должно быть обнаружено и предотвращено». При меньших значениях ускорения или длительности его возникновения мы можем считать, что цель безопасности не нарушается, так как риск при этом не очень большой (вероятно будет невысокая тяжесть ущерба, что приведет к низкому уровню ASIL).

Функциональные требования по безопасности наследуют ASIL уровень целей безопасности, которые получают его по результатам оценки рисков. Важно понимать, что именно требования определяют что нужно сделать для обеспечения безопасности, а уровень ASIL лишь определяет набор применяемых в дальнейшем при разработке устройства методов. Чем выше уровень ASIL, тем более требовательной является разработка с точки зрения проведения различной аналитической, верификационной и валидационной работы. В качестве примера можно рассмотреть таблицу 1, представленную в части 4 стандарта, с возможными методами анализа надежности и безопасности высокоуровневой архитектуры системы.

Анализ архитектуры систем

Методы		ASIL
		A	B	C	D
1	Дедуктивный анализ	о	+	++	++
2	Индуктивный анализ	++	++	++	++

о — для данного метода нет требования об обязательности или необязательности его применения;

+ — рекомендуется использование данного метода

++ — настоятельно рекомендуется использование данного метода

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

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

Часть 4 — Разработка на уровне системы

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

Результат стадии концепции в виде набора функциональных требований по безопасности является основной вводной для начала разработки устройства на уровне системы. Системой в данном случае является само устройство, рассматриваемое как «черный ящик». На каждое функциональное требование по безопасности формируется одно, или несколько технических требований по безопасности (technical safety requirements). Эти требования в соответствии с используемым выше примером функционального требования по безопасности отвечают на вопрос «как нужно реализовать требования стадии концепции так, чтобы транспортное средство не ускорялось непреднамеренно?».

Ответ может быть следующим:

1. На стороне контроллера управления тягой должен быть установлен механизм проверки правдоподобия сигнала запроса тяги водителем (сигнал от педали газа), реализованный путем сравнения двух контрольных сигналов, идущих по двум линиям от педали к контроллеру.
2. В случае несоответствия сигналов друг другу контроллер управляемо обнуляет запрос тяги от водителя в течение 50 мс.
3. На стороне контроллера управления тягой должна осуществляться проверка правдоподобия рассчитываемого микроконтроллером значения требуемого крутящего момента и при нулевом запросе контроллер не должен самопроизвольно создавать внешний запрос на крутящий момент.
4. Выходной сигнал с запросом крутящего момента на высоковольтный инвертор должен быть отправлен на него по двум резервным линиям передачи данных.

Это лишь некоторые технические требования по безопасности, которые можно сформулировать на основе вышеописанного функционального требования по безопасности. В дополнение к ним могут прийти и требования из различных стандартов или законодательных документов, поясняющие особые требования к защитным мерам на стороне разрабатываемого устройства (например требование о наличии мер по поглощению избыточной мощности на устройствах высокого напряжения вытекает из документа UN ECE Regulation 100, но может не следовать напрямую из какого либо функционального требования по безопасности). Требования должны быть распределены между программной и аппаратной частями системы.

Защитные механизмы безопасности для контроллера управления тягой (предотвращение непреднамеренного крутящего момента)

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

Защитные механизмы безопасности подразделяются на 3 категории — предохранительные механизмы, механизмы обнаружения и механизмы смягчения. Первые используются для того, чтобы полностью предотвратить возникновение отказов, способных привести к опасностям и опасным событиям и, тогда как остальные, работая в связке, позволяют обнаружить возникновение таких отказов и уменьшить их последствия так, что уровень риска останется приемлемым. Примером предохранительных механизмов может служить резервирование, механизмов обнаружения — периодическое автоматическое тестирование, а механизмов смягчения — алгоритмы подавления самопроизвольно возникающего крутящего момента. Фактически, механизмы безопасности позволяют бороться со случайными и систематическими отказами аппаратной части и с систематическими отказами программной части, а также с их последствиями.

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

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

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

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

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

Интеграционное и квалификационное тестирование устройства на всех уровнях проводить можно в различных средах:

• Hardware-in-the-loop — тестирование контроллера в контуре обратной связи с имитатором объекта управления в режиме реального времени;
• Test rig testing — тестирование контроллера в контуре обратной связи с реальным объектом управления на стенде в режиме реального времени;
• Vehicle testing — тестирование контроллера в контуре обратной связи с реальным объектом управления в составе прототипа транспортного средства в целевом окружении и в режиме реального времени.

Часть 5 — Разработка на уровне аппаратного обеспечения

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

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

Аппаратные сбои и их взаимосвязь

Такие уязвимости называются сбоями (faults) и некоторые из них могут приводить к нарушениям целей безопасности. Одиночным сбоем называется сбой, не охваченный защитным механизмом безопасности, который непосредственно приводит к нарушению цели безопасности. Двойной сбой — это сбой, который в сочетании с другим независимым сбоем приводит к нарушению цели безопасности. Обобщенной версией двойного сбоя является множественный сбой, однако множественные сбои 3 и больших уровней считаются, согласно ISO 26262, маловероятными, а значит — безопасными. Скрытый сбой — это множественный сбой, наличие которого не выявляется защитным механизмом безопасности и не воспринимается водителем. Допускается, что при применении различных защитных механизмов безопасности, останутся так называемые остаточные сбои, то есть сбои, не охваченные защитными механизмами безопасности и приводящие к нарушению целей безопасности. Однако, для разных ASIL процент остаточных сбоев не должен превышать заданной в стандарте величины.

С этими аспектами связан тот факт, что для аппаратной части требуется расчет метрики, показывающих приемлемый уровень систематических и случайных отказов. Таблицы 4, 5 и 6 указывают целевые значения метрик случайных отказов.

Таблица с целевыми значениям метрик случайных отказов

	ASIL A	ASIL B	ASIL C	ASIL D
Метрика одиночных и остаточных сбоев	-	≥ 90 %	≥ 97 %	≥ 99 %
Метрика скрытых двойных сбоев	-	≥ 60 %	≥ 80 %	≥ 90 %
Вероятность нарушения цели безопасности из-за случайных отказов	-	< ${\displaystyle 10^{-7}}$1/ч	< ${\displaystyle 10^{-7}}$1/ч	< ${\displaystyle 10^{-8}}$1/ч

Выражение для метрики одиночных и остаточных сбоев (SPF):

${\displaystyle SPF=1-{\frac {\sum (\lambda _{SPF}+\lambda _{RF})}{\sum \lambda _{SR}}}={\frac {\sum (\lambda _{MPF}+\lambda _{S})}{\sum \lambda _{SR}}}}$

где ${\displaystyle \lambda _{SPF}}$ — интенсивность отказов для одиночных сбоев;

${\displaystyle \lambda _{RF}}$ — интенсивность отказов для остаточных сбоев;

${\displaystyle \lambda _{SR}}$ — интенсивность отказов для всех сбоев;

${\displaystyle \lambda _{S}}$ — интенсивность отказов для безопасных сбоев;

${\displaystyle \lambda _{SR}}$ — интенсивность отказов для двойных сбоев.

Выражение для метрики двойных скрытых сбоев (LF):

${\displaystyle LF=1-{\frac {\sum \lambda _{MPF,lat}}{\sum (\lambda _{SR}-\lambda _{SPF}-\lambda _{RF})}}={\frac {\sum (\lambda _{MPF,det}+\lambda _{MPF,per}+\lambda _{S})}{\sum (\lambda _{SR}-\lambda _{SPF}-\lambda _{RF})}}}$

где ${\displaystyle \lambda _{MPF,lat}}$ — интенсивность отказов для двойных скрытых сбоев;

${\displaystyle \lambda _{MPF,det}}$ — интенсивность отказов для двойных обнаруживаемых сбоев;

${\displaystyle \lambda _{MPF,per}}$ — интенсивность отказов для двойных сбоев, воспринимаемых водителем;

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

${\displaystyle PMHF\approx \lambda _{SPF}+\lambda _{RF}+\lambda _{MPF,det}\times \lambda _{MPF,lat}\times T_{Lifetime}}$,

где ${\displaystyle T_{Lifetime}}$ — время жизни транспортного средства, на практике принимается равным от 15 до 20 лет.

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

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

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

Часть 6 — Разработка на уровне программного обеспечения

Защитные механизмы и структура программной части контроллера

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

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

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

Ключевое внимание при разработке программного обеспечения уделяется использованию языка программирования и правил написания кода. Во-первых, стандартом рекомендуется использование только таких языков, которые удовлетворяют ряду критериев, например поддерживают строгую и статическую типизацию. При этом только из данного требования следует практическая невозможность применения некоторых языков программирования вроде Python. С точки зрения правил программирования на различных языках, имеется множество различных руководящих указаний и нормативных документов, которые регламентируют правила написания кода на том или ином языке программирования при разработке устройств, связанных с безопасностью. Одним из примеров таких руководящих указаний является серия документов MISRA rules для языков Си и C++.

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

• Software-in-the-loop — тестирование прошивки контроллера в контуре обратной связи с эмуляцией объекта управления на одном и том же вычислителе не в режиме реального времени;
• Processor-in-the-loop — тестирование прошивки контроллера (размещенной на тестовой плате с целевым микроконтроллером) в контуре обратной связи с имитатором объекта управления не в режиме реального времени;
• Hardware-in-the-loop — тестирование прошивки контроллера в контуре обратной связи с имитатором объекта управления в режиме реального времени.

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

Связь с другими стандартами

Стандарт ISO 26262 является одним из самых молодых и структурированных стандартов по функциональной безопасности на данный момент, так как при внушительном объеме предлагает много примеров и имеет структуру, схожую со структурой классической V-модели. Тем не менее, данный стандарт покрывает только некорректное поведение функций разрабатываемых устройств и предлагает подход для их парирования.

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

Для работы с подобными случаями ISO выпустила в 2019 году стандарт ISO/PAS 21448^[3], которые относительно легко интегрируется с ISO 26262 и покрывает ранее проблемные участки, связанные с безопасностью целевых функций.

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

Примечания

1. ISO 26262-1:2011 (англ.). ISO (1 ноября 2011). Дата обращения: 20 апреля 2020.
2. ISO 26262-1:2018 (англ.). ISO (1 декабря 2018). Дата обращения: 20 апреля 2020.
3. ISO/PAS 21448:2019 (англ.). ISO. Дата обращения: 28 июня 2020.

Литература

• ISO 21448:2022