ГОСТ Р ИСО 26262-10-2014 Дорожно-транспортные средства. Функциональная безопасность. Часть 10. Руководство по ИСО 26262.
ГОСТ Р ИСО 26262-10-2014
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ДОРОЖНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА. ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ
Часть 10
Руководящие указания по ИСО 26262
Road vehicles. Functional safety. Part 10. Guideline on ISO 26262
ОКС 43.040.10
Дата введения 2015-10-01
Предисловие
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Корпоративные электронные системы" и Федеральным государственным учреждением "Консультационно-внедренческая фирма в области международной стандартизации и сертификации - "Фирма "Интерстандарт" на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 58 "Функциональная безопасность"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии России от 17 ноября 2014 г. N 1624-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 26262-10:2012* "Дорожные транспортные средства. Функциональная безопасность. Часть 10. Руководящие указания по ИСО 26262" (ISO 26262-10:2012 "Road vehicles - Functional safety - Part 10: Guideline on ISO 26262").
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
Комплекс стандартов ИСО 26262 является адаптацией комплекса стандартов МЭК 61508 и предназначен для применения электрических и/или электронных (Э/Э) систем в дорожно-транспортных средствах.
Эта адаптация распространяется на все виды деятельности в процессе жизненного цикла систем, связанных с безопасностью, включающих электрические, электронные и программные компоненты.
Безопасность является одним из важнейших вопросов в автомобилестроении. Создание новых функциональных возможностей не только в таких системах, как содействие водителю, силовые установки, управление динамикой автомобиля, но и в активных и пассивных системах безопасности тесно связано с деятельностью по проектированию систем безопасности. Разработка и интеграция этих функциональных возможностей повышает необходимость использования процессов разработки систем безопасности и обеспечения доказательств того, что все обоснованные цели системы безопасности выполнены.
С ростом сложности технологий, программного обеспечения и мехатронных устройств увеличиваются риски, связанные с систематическими отказами и случайными отказами оборудования. Чтобы предотвратить эти риски, комплекс стандартов ИСО 26262 включает соответствующие требования и процессы.
Безопасность системы достигается за счет ряда мер безопасности, которые реализуются с применением различных технологий (например, механических, гидравлических, пневматических, электрических, электронных, программируемых электронных) и применяются на различных уровнях процесса разработки. Несмотря на то, что настоящий стандарт касается функциональной безопасности Э/Э систем, подход, рассматриваемый в настоящем стандарте, может быть использован для разработки связанных с безопасностью систем, основанных на других технологиях.
Настоящий стандарт:
a) обеспечивает жизненный цикл систем безопасности автомобиля (менеджмент, разработку, производство, эксплуатацию, обслуживание, вывод из эксплуатации) и поддерживает адаптацию необходимых действий для выполнения этих стадий жизненного цикла;
b) обеспечивает разработанный специально для автотранспорта, основанный на риске подход для определения уровней полноты безопасности [уровни полноты безопасности автомобиля (УПБА)];
c) использует значения УПБА при спецификации соответствующих требований, чтобы предотвратить неоправданный остаточный риск;
d) устанавливает требования к мерам проверки соответствия и подтверждения, которые обеспечивают достижение достаточного и приемлемого уровня безопасности;
e) устанавливает требования к взаимодействию с поставщиками.
На функциональную безопасность влияют процессы разработки (в том числе спецификация требований, реализация, внедрение, интеграция, верификация, подтверждение соответствия и управление конфигурацией), процессы производства и обслуживания, а также процессы управления.
Вопросы безопасности тесно связаны с любыми опытно-конструкторскими работами, реализующими функционал и обеспечивающими качество создаваемых изделий, а также с результатами таких работ. Настоящий стандарт рассматривает связанные с безопасностью проблемы, касающиеся опытно-конструкторских работ и их результатов.
На рисунке 1 показана общая структура комплекса ИСО 26262. В нем для различных стадий разработки изделия используется эталонная V-модель процесса. На рисунке 1:
- залитая область в виде символа "V" представляет взаимосвязь между ИСО 26262-3, ИСО 26262-4, ИСО 26262-5, ИСО 26262-6 и ИСО 26262-7;
- ссылки на конкретную информацию даны в виде: "m-n", где "m" представляет собой номер части настоящего стандарта, а "n" указывает на номер раздела этой части.
Пример - 2-6 ссылается на пункт 6 ИСО 26262-2.
|
 |
Рисунок 1 - Общая структура ИСО 26262
1 Область применения
Настоящий стандарт применяется к связанным с безопасностью системам, включающим в себя одну или несколько электрических и/или электронных (Э/Э) систем, которые установлены в серийно производимых легковых автомобилях с максимальной массой (брутто) транспортного средства до 3500 кг. Настоящий стандарт не применяется для уникальных Э/Э систем в транспортных средствах специального назначения, таких как транспортные средства, предназначенные для водителей с ограниченными возможностями.
Системы и их компоненты, находящиеся в производстве или на стадии разработки до даты публикации настоящего стандарта, не входят в область его применения. Если разрабатываемые автомобили или их модификации используют системы и их компоненты, выпущенные до публикации настоящего стандарта, то только модификации этих систем должны быть разработаны в соответствии с настоящим стандартом.
Настоящий стандарт рассматривает возможные опасности, вызванные некорректным поведением Э/Э связанных с безопасностью систем, а также некорректным взаимодействием этих систем. Настоящий стандарт не рассматривает опасности, связанные с поражением электрическим током, возгоранием, задымлением, перегревом, излучением, токсичностью, воспламеняемостью, химической активностью, коррозией и подобные опасности, если они непосредственно не вызваны некорректным поведением Э/Э связанных с безопасностью систем.
Настоящий стандарт не рассматривает номинальные рабочие характеристики Э/Э систем, даже если для таких систем существуют стандарты, посвященные их функциональным рабочим характеристикам (например, активные и пассивные системы безопасности, тормозные системы, адаптивный круиз-контроль).
В настоящем стандарте сделан краткий обзор комплекса ИСО 26262, а также даны дополнительные объяснения к нему. Настоящий стандарт предназначен для улучшения понимания других частей комплекса ИСО 26262, носит только справочный характер и описывает общие понятия ИСО 26262. Объяснения даются как для общих понятий, так и для их конкретного содержания.
В случае расхождения между требованиями, рекомендациями или данными, используемыми в настоящем стандарте и в другой части комплекса ИСО 26262, применяются требования, рекомендации или данные, определенные в другой части комплекса ИСО 26262.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты*:
ИСО 26262-1:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 1. Термины и определения (ISO 26262-2:2011, Road vehicles - Functional safety - Part 1: Vocabulary)
ИСО 26262-2:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 2. Управление функциональной безопасностью (ISO 26262-2:2011, Road vehicles - Functional safety - Part 2: Management of functional safety)
ИСО 26262-3:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 3. Стадия формирования концепции (ISO 26262-3:2011, Road vehicles - Functional safety - Part 3: Concept phase)
ИСО 26262-4:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 4. Разработка изделия на уровне системы (ISO 26262-4:2011, Road vehicles - Functional safety - Part 4: Product development at the system level)
ИСО 26262-5:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 5. Разработка аппаратных средств изделия (ISO 26262-5:2011, Road vehicles - Functional safety - Part 5: Product development at the hardware level)
ИСО 26262-6:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия (ISO 26262-6:2011, Road vehicles - Functional safety - Part 6: Product development at the software level)
ИСО 26262-7:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 7. Производство и эксплуатация (ISO 26262-7:2011, Road vehicles - Functional safety - Part 7: Production and operation)
ИСО 26262-8:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 8. Вспомогательные процессы (ISO 26262-8:2011, Road vehicles - Functional safety - Part 8: Supporting processes)
ИСО 26262-9:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 9. Анализ уровня полноты безопасности автомобиля и анализ безопасности автомобиля (ISO 26262-9:2011, Road vehicles - Functional safety - Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses)
3 Термины, определения и сокращения
В настоящем стандарте применимы термины, определения и сокращения по ИСО 26262-1:2011.
4 Основные понятия ИСО 26262
4.1 Функциональная безопасность систем транспортного средства (связь с МЭК 61508)
Серия МЭК 61508 "Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью", является базовым стандартом МЭК в области функциональной безопасности. Это означает, что стандарты по функциональной безопасности, разрабатываемые для других секторов промышленности, будут основываться на требованиях МЭК 61508.
В автомобильной промышленности существует ряд областей, где МЭК 61508 применяется непосредственно. Некоторые из этих областей и их отличия в ИСО 26262 описаны ниже.
МЭК 61508 основывается на модели "управляемого оборудования" (например, промышленное предприятие, имеющее свою систему управления) следующим образом:
a) анализ опасностей идентифицирует опасности в управляемом оборудовании (в том числе в системе управления оборудованием), к которым будут применяться меры по снижению риска. Это может быть достигнуто с помощью Э/Э/ПЭ систем или систем, связанных с безопасностью, основанных на других технологиях (например, предохранительный клапан), или внешних мер по снижению риска (например, физические меры предосторожности предприятия). Настоящий стандарт содержит нормативную схему классификации опасностей транспортного средства в зависимости от их важности, вероятности влияния на них внешнего воздействия и управляемости;
b) снижение рисков, задаваемое Э/Э/ПЭ системам обеспечивается так называемыми функциями безопасности. Эти функции безопасности вместе с другими реализуются либо как отдельная система безопасности, либо могут быть включены в систему управления предприятием. Реализовывать отдельные системы безопасности в транспортном средстве не всегда разумно, так как безопасность транспортного средства зависит от поведения самих систем управления.
ИСО 26262 реализует концепцию целей безопасности и концепцию обеспечения безопасности, следующим образом:
- анализ опасностей и оценка рисков определяет опасности и опасные события, которые должны быть предотвращены, смягчены или должны контролироваться;
- цель безопасности формулируется для каждого опасного события;
- уровень полноты безопасности автомобиля (УПБА) связан с каждой целью безопасности;
- концепцией обеспечения функциональной безопасности является описание функциональности системы, связанной с безопасностью, которая необходима для достижения цели(ей) безопасности;
- технической концепцией обеспечения безопасности является положение о том, как эта функциональность реализуется на уровне системы аппаратными средствами и программным обеспечением;
- требования к программному обеспечению системы безопасности и требования к ее аппаратным средствам устанавливают конкретные требования к системе безопасности, которые будут реализованы в процессе проектирования программного обеспечения и аппаратных средств.
Пример - Система подушек безопасности:
- одной из опасностей является непреднамеренное их раскрытие;
- соответствующая цель безопасности заключается в том, что подушка безопасности не раскрывается, если не происходит аварии, требующей ее раскрытия;
- концепция обеспечения функциональной безопасности может определить дополнительную функцию для обнаружения столкновения автомобиля;
- техническая концепция обеспечения безопасности может определить реализацию двух независимых датчиков ускорения по различным осям и двух независимых схем запуска раскрытия. Петарда запускается, если обе схемы срабатывают.
МЭК 61508 предназначен для отдельных систем или систем невысокой сложности. Система создается и тестируется, затем устанавливается на предприятии и после этого для нее выполняется подтверждение соответствия системе безопасности. Для рынка массовых изделий, таких как транспортные средства, подтверждение соответствия системе безопасности выполняется перед началом их массового (серийного) производства. Поэтому порядок действий, выполняемых на стадиях жизненного цикла, описанный в ИСО 26262, иной. Так, например, в ИСО 26262-7 представлены требования к производству, которые в МЭК 61508 отсутствуют.
В МЭК 61508 не рассматриваются конкретные требования к управлению разработкой несколькими организациями и цепочками поставок, в то время как в ИСО 26262 этот вопрос рассматривается подробно, включая и соглашение об интерфейсе разработки (см. раздел 5 26262-8 "Взаимодействие в совместных разработках"), так как автотранспортные системы создаются одним или несколькими поставщиками заказчика, например производителем автотранспортных средств, поставщиком заказчика или заказчиком.
МЭК 61508 не содержит нормативных требований к классификации опасности. ИСО 26262 схему классификации опасностей автомобиля содержит. Данная схема признает, что опасность в системе автомобиля не обязательно приводит к аварии. Это зависит от результатов анализа, выполненного для лиц, подвергающихся риску: действительно ли они подвергаются опасности, если она возникает, и в состоянии ли они принять меры по управлению результатами опасных событий. На рисунке 2 приведен пример такого подхода для отказа, который влияет на управляемость движущегося транспортного средства.
Примечание - Данный подход призван лишь продемонстрировать, что не всегда существует прямая связь между произошедшим отказом и аварией. Это не выявляется в процессе анализа опасностей и оценки рисков, хотя оцениваемые параметры в этом процессе связаны с вероятностями переходов между состояниями, показанными на рисунке 2.
|
 |
Рисунок 2 - Модель конечного автомата для оценки риска автомобиля
Требования для разработки аппаратных средств (ИСО 26262-5) и программного обеспечения (МСО 26262-6) адаптированы для современного автомобилестроения. В частности, ИСО 26262-6 содержит требования, связанные с разработкой на основе модели; МЭК 61508 предусматривает применения конкретных методов. Применение любого альтернативного метода должно быть подробно обосновано. Для методов, перечисленных в ИСО 26262, предоставляются конкретные цели. Для достижения этих целей могут быть применены предусмотренные методы или предусмотрено обоснование достижения цели альтернативными методами.
Требования к системе безопасности в настоящем стандарте определяется уровнем полноты безопасности автомобиля (УПБА), а не уровнем полноты безопасности (УПБ). Основное различие состоит в том, что УПБ в МЭК 61508 задается в вероятностных терминах (см. таблицу 3 МЭК 61508-1). В МЭК 61508 указано: "Принято считать, что только по отношению к полноте безопасности аппаратных средств возможно дать количественную оценку и использовать надежные методы предсказания при оценке того, будут ли достигнуты планируемые величины отказов. При определении того, будут ли достаточны меры предосторожности для достижения планируемых величин отказов по отношению к полноте безопасности, связанной с систематическими отказами, должны быть использованы качественные методы и обоснования". УПБА основан не на таком вероятностном требовании, касающемся возникновения опасности. Однако существуют вероятностные цели, связанные с соблюдением требований УПБА.
4.2 Устройство, система, элемент, компонент, часть аппаратного средства и модуль программного обеспечения
Термины устройство, система, элемент, компонент, часть аппаратного средства и модуль программного обеспечения определены в ИСО 26262-1. На рисунке 3 представлена взаимосвязь устройства, системы, элемента, компонента, части аппаратного средства и модуля программного обеспечения. На рисунке 4 показано, что может входить в устройство. В устройстве можно выделить систему, подсистему или компонент. Полученный в результате выделения элемент, соответствующий критериям системы, может быть системой или подсистемой. Термин подсистема используется, когда важно подчеркнуть, что элемент является частью более крупной системы. Компонент является логически и технически отдельным элементом не уровня системы. Часто термин компонент применяют к элементу, который состоит только из частей и блоков, но также может быть применен к элементу, состоящему из элементов нижнего уровня конкретной области технологии, например электрической/электронной технологии (см. рисунок 4).
Пример - Для микроконтроллера или СИС может быть использована следующая декомпозиция: весь микроконтроллер является компонентом, блок обработки (например, процессор) является его частью, регистры внутри блока обработки (например, блок регистров процессора) являются подчастью. В случае анализа микроконтроллера может быть необходима декомпозиция с более высоким уровнем детализации. Чтобы помочь в этом, можно декомпозировать часть на подчасти, которые могут быть далее декомпозированы на базовые / элементарные подчасти.
|
 |
Примечания
1 В этой диаграмме, в зависимости от контекста, термин "элемент" может применяться к объектам "система", "компонент", "аппаратная часть" и "модуль программного обеспечения" согласно п.1.32 ИСО 26262-1.
2 Как определено в ИСО 26262-1, система, по крайней мере, состоит из датчика, контроллера и исполнительного механизма, например, как минимум, из 3 связанных элементов.
3 * означает, что возможны N элементов.
Рисунок 3 - Взаимосвязь устройства, системы, элемента, компонента, части аппаратного средства и модуля программного обеспечения
|
 |
Рисунок 4 - Пример выделения компонентов в устройстве
4.3 Отношения между сбоями, ошибками и отказами
Термины сбой, ошибка и отказ определяются в ИСО 26262-1. На рисунке 5 представлен процесс последовательного развития сбоя в ошибку и ошибки в отказ для трех различных типов причин их появления, связанных с систематическими проблемами программного обеспечения, случайными проблемами аппаратных средств и систематическими проблемами аппаратных средств. Систематические сбои (см. ИСО 26262-1) обусловлены проблемами на стадиях спецификации и проектирования. К систематическим сбоям относят сбои программного обеспечения и некоторую часть сбоев аппаратных средств. Случайные сбои аппаратных средств (см. ИСО 26262-1) обусловлены физическими процессами, такими как износ, физическая деградация или аномальные внешние условия. На уровне компонентов каждый из различных типов сбоев может привести к различным отказам. Однако отказы на уровне компонента являются сбоями на уровне устройства. Отметим, что в этом примере на уровне автомобиля сбои, связанные с различными причинами, могут привести к одинаковому отказу. Подмножество отказов на уровне устройства будут представлять собой опасности (см. ИСО 26262-1), если дополнительные факторы внешней среды позволяют отказу внести свой вклад в аварийный сценарий.
Пример - Если транспортное средство начинает вести себя неожиданно при пересечении перекрестка, то может произойти авария, например оценивается тяжесть, воздействие и управляемость риска опасного события "транспортное средство "скачет" при пересечении перекрестка" ("скакать" - делать резкие отрывистые движения).
|
 |
Рисунок 5 - Пример сбоев, приводящих к отказам
5 Отдельные вопросы, связанные с управлением безопасностью
5.1 Результат работы
Данный подраздел описывает термин "результат работы".
Результат работы является результатом выполнения соответствующих требований настоящего стандарта (см. ИСО 26262-1). Таким образом, документально оформленный результат работы может обеспечить доказательство соответствия с этими требованиями безопасности.
Пример - Спецификация требований является результатом работы, который может быть документально оформлен с помощью базы данных требований или в виде текстового файла. Исполняемая модель является результатом работы, которая может быть представлена файлами на языке моделирования, которые могут быть выполнены, например, программными инструментальными средствами для решения задач моделирования.
Документация на результат работы [см. раздел 10 ("Документирование") ИСО 26262-8] является записью выполненных действий по обеспечению безопасности, требований к системе безопасности или связанной информации. Такая документация не ограничивается какой-либо формой или средой.
Пример - Документация на результат работы может быть представлена в виде электронных или бумажных файлов, отдельным документом или набором документов. Она может быть объединена с документацией на другие результаты работы или с документацией, непосредственно не связанной с функциональной безопасностью.
Для того чтобы избежать дублирования информации, могут быть использованы перекрестные ссылки между или внутри документации.
5.2 Меры подтверждения
5.2.1 Общие положения
В настоящем стандарте определенные результаты работы оцениваются во время последующих действий либо частично мерами подтверждения, либо частично действиями по верификации. Данный подраздел описывает различия между мерами верификации и подтверждения.
С одной стороны, действия по верификации выполняются с целью определения полноты и правильности спецификации или реализации требований к системе безопасности. Верификация результатов работы может включать в себя:
- отчеты по верификации спецификации или реализации требований безопасности, полученных из требований безопасности более высокого уровня, в отношении их полноты и правильности, или
- выполнение тестов или проверку результатов тестирования для обеспечения доказательств выполнения установленных требований безопасности устройством или его элементом(ами).
Действия по верификации установлены в ИСО 26262-3, ИСО 26262-4, ИСО 26262-5 и ИСО 26262-6.
Кроме того, общие требования к действиям по верификации в настоящем стандарте установлены в разделе 9 ИСО 26262-8 (Верификация), а в дальнейшем детали, специфичные для верификации требований безопасности, установлены в разделе 6 ИСО 26262-8 (Спецификация и менеджмент требованиями к системе безопасности).
С другой стороны, выполняются меры подтверждения для оценки достижения устройством функциональной безопасности, включая подтверждения:
- надлежащих определения, адаптации и выполнения действий по обеспечению безопасности, выполняемых во время разработки устройства, и реализованных процессов безопасности в соответствии с требованиями настоящего стандарта, а также
- надлежащего содержания результатов работы относительно соответствующих требований настоящего стандарта.
Меры подтверждения установлены в разделе 6 (Управление созданием системы безопасности на стадиях формирования концепции и разработки изделия) ИСО 26262-2.
Пример - Если декомпозиция УПБА применяется на стадии проектирования системы, то:
- верификация полученного проекта системы выполняется в соответствии с технической концепцией системы безопасности (см. 7.4.8 ИСО 26262-4) и
- подтверждение правильности применения декомпозиции УПБА может быть выполнено как часть оценки функциональной безопасности, в соответствии с разделом 5 ИСО 26262-9 (Декомпозиция требований с распределением УПБА), включая подтверждение того, что был выполнен анализ зависимых отказов и он обосновывает выполнение требования достаточной независимости между элементами, которые реализуют соответствующие требования избыточности системы безопасности.
5.2.2 Оценка функциональной безопасности
Если самое большое значение УПБА целей безопасности устройства равно значению C или D, то выполнение оценки функциональной безопасности заключается в оценке достижения устройством функциональной безопасности. В ИСО 26262-2 некоторые аспекты оценки функциональной безопасности рассматриваются отдельно, например аудит функциональной безопасности и отчеты о подтверждении.
Оценка функциональной безопасности включает в себя:
a) рассмотрение вопроса о целесообразности и эффективности реализуемых мер обеспечения безопасности, которые могут быть оценены в процессе разработки устройства;
b) оценку результатов работы, требуемых планом обеспечения безопасности. Рассмотрению отдельных результатов работы придается особое значение. Ими являются отчеты о подтверждении и планы подтверждения соблюдения такими результатами работы соответствующих требований настоящего стандарта; а также
c) один или более аудитов функциональной безопасности для оценки осуществления процессов, необходимых для функциональной безопасности.
Оценка функциональной безопасности может быть выполнена повторно или обновлена.
Примеры
1 Оценка функциональной безопасности обновляется из-за изменения устройства или элемента (элементов) этого устройства, которое определяется технологией управления изменениями, так как оно оказывает влияние на функциональную безопасность устройства [см. раздел 8 ИСО 26262-8 (Управление изменениями)].
2 Повторная оценка функциональной безопасности может быть вызвана информацией об оценке функциональной безопасности, которая включает рекомендации по условному принятию или отклонению функциональной безопасности устройства. В этом случае повторная оценка включает в себя рекомендации, полученные из предыдущей(их) оценки(ок) функциональной безопасности, включая оценку проведенных корректирующих действий, если они применимы.
Если самое большое значение УПБА целей безопасности устройства равно значению B, то оценка функциональной безопасности может не выполняться или может быть выполнена менее строго. Однако, даже если оценка функциональной безопасности не выполняется, то должны быть выполнены другие меры подтверждения, например отчеты о подтверждении оценки опасности и анализа рисков, о плане обеспечения безопасности, о плане интеграции и тестирования устройства, о плане подтверждения соответствия, о подходящем анализе безопасности, о подтверждении проверкой в эксплуатации (если применимо) и о полноте обоснования безопасности (см. таблицу 1 ИСО 26262-2).
Если самое большое значение УПБА целей безопасности устройства равно значению A, то в настоящем стандарте нет никакого требования или рекомендации о проведении или непроведении оценки функциональной безопасности. Однако отчеты о подтверждении анализа опасностей и оценки рисков и о подходящем анализе безопасности по-прежнему выполняются.
В случае распределенной разработки, область применения оценки функциональной безопасности включает в себя полученные результаты работы, а также выполненные процессы и меры обеспечения безопасности заводом-изготовителем транспортного средства и поставщиками в цепочке поставок устройства [см. ИСО 26262-2 и раздел 5 (Взаимодействие в совместных разработках) ИСО 26262-8].
Цель оценки функциональной безопасности заключается в оценке достижения устройством функциональной безопасности, которая возможна только на уровне устройства. Таким образом, оценка функциональной безопасности на территории поставщика (который разрабатывает элементы устройства) выполняется только в ограниченном объеме, результаты которой, по существу, являются исходной информацией для последующих действий по оценке функциональной безопасности (на стороне заказчика). Как конечный потребитель разработанного устройства, изготовитель транспортного средства назначает лицо (несколько лиц) для выполнения оценки функциональной безопасности в полном объеме, чтобы судить о достижении устройством функциональной безопасности. Это обоснование включает в себя рекомендации по принятию, условному принятию или отклонению результатов оценки функциональной безопасности устройства.
Примечание - В случае если поставщик первого Уровня несет ответственность за разработку устройства, включая интеграцию транспортного средства, то такой поставщик берет на себя вышеупомянутую роль изготовителя транспортного средства.
На практике оценка функциональной безопасности при распределенной разработке может быть разделена на выполнение:
- оценки функциональной безопасности в ограниченном объеме на территории поставщика, затрагивая поставщиков в цепочке поставок. Применяется значение УПБА, являющееся самым высоким унаследованным значением УПБА (от целей безопасности устройства), для всех элементов устройства, которые разрабатываются поставщиком (см. также 5.4.5 ИСО 26262-8); и
- окончательной оценки функциональной безопасности, включающей в себя обоснование достижения функциональной безопасности интегрированным устройством, например выполняемой изготовителем транспортного средства. Применяемое значение УПБА является наибольшим значением УПБА целей безопасности устройства (см. также ИСО 26262-2).
Пример - Производитель автомобиля разрабатывает устройство, у которого цель безопасности 1 (ЦБ 1) имеет значение УПБА, равное D, а цель безопасности 2 (ЦБ 2) имеет значение УПБА, равное A, и планирует выполнить оценку функциональной безопасности этого устройства. Вполне возможно, что, например, поставщик второго или третьего Уровня разрабатывает элементы для этого устройства только со значениями УПБА, равными A, то есть только элементы, которые наследуют значение УПБА ЦБ 2, равное A [если, однако, это применимо, см. раздел 6 ИСО 26262-9 (Критерии совместимости элементов)]. В настоящем стандарте не существует требования или рекомендации (ни за, ни против), о выполнении оценки функциональной безопасности на территории такого поставщика для такого разрабатываемого устройства.
Область применения, процедура (например, результаты работы должны быть предоставлены поставщиком, результаты работы должны быть рассмотрены заказчиком) и выполнение оценки функциональной безопасности, касающиеся взаимодействия между заказчиком и поставщиком указываются в соответствующем соглашении об интерфейсе разработки [см. раздел 5 ИСО 26262-8 (Взаимодействие в совместных разработках)].
Пример - Соглашение об интерфейсе разработки между изготовителем транспортного средства (заказчик) и поставщиком первого Уровня. Соглашение об интерфейсе разработки между поставщиком первого Уровня (заказчик) и поставщиком второго Уровня.
Один из возможных способов выполнения оценки функциональной безопасности в случае распределенной разработки заключается в том, что изготовитель транспортного средства и каждый из поставщиков в цепочке поставок решает те вопросы по оценке [см. перечисления a), b) и c) выше], за которые соответствующая сторона несет ответственность, а именно:
- поставщик рассматривает меры обеспечения безопасности, реализованные при разработке элементов, включая их целесообразность и эффективность, чтобы обеспечить соответствие с целями безопасности или требованиями безопасности (предусмотренными заказчиком или разработанными поставщиком), и оценивает свои реализуемые процессы и полученные результаты работы. Поставщик также оценивает возможное влияние разработанных элементов на функциональную безопасность устройства, например выявляет, могут ли реализованные меры по обеспечению безопасности привести к новым опасностям;
- изготовитель транспортного средства оценивает функциональную безопасность интегрированного устройства. Часть оценки может быть основана на результатах работы или информации, предоставленной одним или более поставщиками, включая сообщения об оценках функциональной безопасности, выполненных на территории поставщика.
Примечание - Заказчик может оценить меры обеспечения безопасности, осуществляемые поставщиком, и результаты работы, предоставляемые поставщиком. Заказчик может также оценить процессы, осуществляемые поставщиком на территории поставщика (см. 5.4.4.8 ИСО 26262-8).
5.3 Обоснования безопасности
5.3.1 Объяснение обоснований безопасности
Целью обоснования безопасности является обеспечение четкого, всеобъемлющего и аргументированного объяснения, поддержанного доказательством, что при работе в целевом контексте в устройстве отсутствуют необоснованные риски.
Приведенные ниже руководящие указания даны для области применения настоящего стандарта.
Существуют три основных элемента обоснования безопасности, а именно:
- требования;
- доказательство и
- материалы, подтверждающие безопасность, например результаты работы в соответствии с требованиями настоящего стандарта.
Соотношение между этими тремя элементами в контексте настоящего стандарта представлено на рисунке 6.
|
 |
Рисунок 6 - Ключевые элементы обоснования безопасности [2]
Доказательство безопасности реализует отношение между материалами, подтверждающими безопасность, и целями. Ролью доказательства безопасности часто пренебрегают. Можно представить многостраничный документ с доказательствами без четкого объяснения, как эти доказательства связаны с целями безопасности. Доказательство и материалы, подтверждающие безопасность, являются важными элементами обоснования безопасности и рассматриваются всегда вместе. Доказательство без материалов, подтверждающих безопасность, является необоснованным и потому неубедительным. Материалы, подтверждающие безопасность, без доказательства являются необъяснимыми, в результате отсутствует ясность в том, как были достигнуты цели безопасности. Обоснования безопасности передаются в виде разработанных и представленных отчетов с обоснованием безопасности. Роль отчета с обоснованием безопасности заключается в объединении доказательства безопасности с соответствующими отчетами о получении материалов, подтверждающих безопасность (например, протоколы испытаний).
Доказательства безопасности, используемые в настоящее время в других отраслях, часто включаются в отчеты с обоснованием безопасности в виде обычного текста. Обычным текстом можно описать, как цель безопасности была интерпретирована, распределена и декомпозирована, в конечном счете, доходя до ссылок на доказательства, которые демонстрируют выполнение заявленных характеристик безопасности для нижнего уровня. Кроме того, становится все более популярным использование графических представлений доказательства безопасности (например, требования - доказательства безопасности - материалы, подтверждающие безопасность, в средстве представления структурирования цели [2]), чтобы явно и наглядно представить отдельные элементы доказательства безопасности (требования, заявленные характеристики, материалы, подтверждающие безопасность, и контекст) и отношения, которые существуют между этими элементами (например, как отдельные требования поддерживаются конкретными заявленными характеристиками безопасности, каким образом заявленные характеристики безопасности поддерживаются материалами, подтверждающими безопасность, и предполагаемым контекстом, который определен для доказательства безопасности).
Доказательство безопасности, которое рассматривает безопасность, непосредственно используя характеристики реализуемого устройства (например, поведение синхронизации сторожевого таймера), часто называют доказательством безопасности изделия. Доказательство безопасности, которое рассматривает безопасность, используя характеристики процесса разработки и оценки (например, представления, принятые при проектировании), часто называют доказательством безопасности процесса.
Оба типа доказательства безопасности могут быть использованы для достижения обоснованного доказательства безопасности устройства, где доказательство безопасности процесса может рассматриваться как обеспечение уверенности в материалах, подтверждающих безопасность, используемых при доказательстве безопасности изделия.
5.3.2 Жизненный цикл разработки обоснования безопасности
Разработку обоснования безопасности можно рассматривать как дополнительную деятельность, которая интегрируется с остальными стадиями разработки жизненного цикла системы безопасности.
Примечание - План обеспечения безопасности может включать в себя планирование дополнительных шагов и предварительных версий обоснования безопасности.
Такой подход формирует промежуточные версии обоснования безопасности основных стадий разработки изделия. Например, предварительная версия обоснования безопасности может быть создана после верификации технических требований системы безопасности; промежуточная версия обоснования безопасности может быть создана после верификации проекта системы и окончательная версия может быть создана непосредственно перед оценкой функциональной безопасности.
Обоснование безопасности оформляется в виде отчета о подтверждении, как указано в 6.4.7 ИСО 26262-2 (Меры подтверждения: виды, независимость и полномочия).
Если устройство модифицируется, то оценивается влияние на обоснование безопасности и, при необходимости, обоснование безопасности обновляется с учетом модификаций.
6 Стадия формирования концепции и разработка системы
6.1 Общие положения
В настоящем разделе представлен обзор принципов, лежащих в основе анализа опасностей и классификации рисков, и рассмотрены упрощенные примеры понятий.
6.2 Пример анализа опасностей и оценки рисков
6.2.1 Общие положения
Рассмотрим пример устройства управления блоком накопления энергии, встроенного в транспортное средство. В данном примере предположим, что накапливаемая энергия должна расходоваться только тогда, когда транспортное средство движется со скоростью, равной или превышающей 15 км/ч. Расход накапливаемой энергии при скорости менее 15 км/ч может привести к перегреву и последующему разрушению блока.
6.2.2 Анализ 1
a) Определение опасности:
- отказ, приводящий к нежелательному расходу энергии блоком, может привести к разрушению блока.
b) Опасное событие:
В данном примере предположим, что дорожная ситуация для анализа опасностей и оценки рисков является следующей:
- движение автомобиля в "пробках" со скоростью менее 15 км/ч.
Происходит нежелательное расходование энергии из-за отказа в устройстве. Блок накопления энергии разрушается, нанося серьезный вред водителю и пассажирам транспортного средства.
c) Классификация выявленного опасного события
Разрушение приводит к опасным для жизни травмам с сомнительным выживанием для людей, находящихся в транспортном средстве, поэтому тяжесть оценивается как S3.
Автомобиль движется в "пробках" со скоростью менее 15 км/ч. На основе статистики трафика для целевого рынка данного транспортного средства воздействие такой ситуации может быть оценено как E3 (происходящее в течение 1%-10% среднего времени работы автомобиля).
Способность водителя или пассажиров транспортного средства управлять отказом устройства и разрушением блока рассматривается как неправдоподобное событие: в данном случае управляемость может быть оценена как C3 (трудноконтролируемое или неконтролируемое событие).
Применяя таблицу 4 ИСО 26262-3, получим значение УПБА, равное C.
6.2.3 Анализ 2
a) Определение опасности:
- отказ не приводит к расходу энергии блоком.
b) Опасное событие:
- любая ситуация в процессе управления автомобилем.
Отказ устройства происходит, но он не приводит к расходу какой-либо энергии из блока накопления энергии и поэтому никакой вред не наносится.
c) Классификация выявленного опасного события
Поскольку отказ устройства не наносит вреда, тяжесть классифицируется как S0 и управляемость не определяется. Поэтому цель безопасности не определяется.
6.3 Замечания о классификации управляемости
Как поясняется в разделе 7 ИСО 26262-3 (Анализ опасностей и оценка рисков), управляемость оценивается вероятностью того, что водитель или другой участник движения могут избежать конкретного вреда.
В простейшем случае рассматривается только один результат для данного опасного события, а управляемость представляет собой оценку вероятности того, что этого результата можно избежать. Тем не менее, могут быть и другие случаи. Например, возможные тяжелые последствия (например, класс тяжести последствий S2) можно относительно легко предотвратить (например, в случае управляемости C1), однако менее тяжелых последствий (например, класс тяжести последствий S1) бывает гораздо труднее избежать (например, в случае управляемости C3). Если предположить, что класс воздействия E4, то следующий набор полученных значений УПБА, показывает, что необязательно самый высокий класс тяжести последствий приводит к самому высокому значению УПБА:
- E4, S2, C1 => значение УПБА, равное A;
- E4, S1, C3 => значение УПБА, равное B.
В данном примере значение УПБА, равное B, представляет собой соответствующую классификацию опасного события.
6.4 Внешние меры
6.4.1 Общие положения
Внешняя мера является отдельной и независимой от устройства мерой, которая снижает или смягчает риски, связанные с отказом данного устройства.
6.4.2 Пример 1 зависимых от транспортного средства внешних мер
Автомобиль A оснащен ручным механизмом привода коробки передач, который можно оставить на любой передаче, в том числе нейтральной, при выключенном зажигании. Транспортное средство B оснащено автоматической коробкой передач, у которой, при выключенном зажигании, включена одна передача и нормально замкнуто сцепление. Оба автомобиля имеют дополнительное устройство, электрический стояночный тормоз (EPB).
Для рассматриваемых транспортных средств анализируется следующий сценарий:
- автомобиль на парковке (зажигание выключено, водитель отсутствует);
- местом парковки является тротуар с наклонным участком, расположенным на территории города с большим населением;
- отказом является внезапная потеря работоспособности EPB.
В этом случае автомобиль А, оставаясь на нейтральной передаче при выключенном зажигании (ситуация, которая соответствует разумно предсказуемому, неправильному использованию), возможно, будет двигаться, если его оставить без присмотра. Оценивая данную ситуацию, можно определить следующие классы: для управляемости - равный C3, тяжести последствий - равный S2 или выше, в зависимости от наличия поблизости лиц, которые могут быть уязвимы, и воздействия - более E0. В зависимости от диапазона реально назначаемого класса воздействия, диапазон значений УПБА классифицируется между QM и C.
Однако автомобиль B, у которого передача всегда включена, двигаться не будет, поэтому опасность не возникает. Зависимые от транспортного средства внешние меры, включенные в проект этого автомобиля, способствовали ликвидации риска для рассматриваемого сценария, но только если можно показать, что автоматическая коробка передач и EPB достаточно независимы.
6.4.3 Пример 2 зависимых от транспортного средства внешних мер
Автомобиль A оснащен системой динамической стабилизации в дополнение к системе повторного запуска двигателя. Автомобиль B оборудован только системой повторного запуска двигателя.
Для рассматриваемых транспортных средств анализируется следующий сценарий:
- дорога мощеная, сухая и проходит в пригородной зоне;
- транспортное средство приближается к среднему значению кривизны в изгибе дороги;
- скорость транспортного средства и кривизна дороги таковы, что боковая составляющая ускорения выше среднего значения;
- отказ системы повторного запуска двигателя, заключающийся в нежелательном выключении двигателя, приводит к внезапной потере тягового усилия во время выполнения сценария.
В результате внезапной потери тягового усилия у транспортного средства появляется момент рыскания, требующий от водителя восстановить управление автомобилем рулевым колесом. Можно показать, что автомобиль B при выполнении этого маневра будет иметь низкую управляемость, что может дать значения для УПБА, равные C или D. С другой стороны, система динамической стабилизации транспортного средства A ограничивает последствия боковой неустойчивости. В результате управляемость для транспортного средства A будет ниже. Таким образом, зависимые от транспортного средства внешние меры, представленные системой динамической стабилизации, способствуют снижению риска для этого сценария. Однако это справедливо лишь в том случае, если можно показать, что рассматриваемый отказ системы повторного запуска двигателя не может повлиять на систему динамической стабилизации и для этих систем данный отказ не является зависимым.
6.5 Пример объединения целей безопасности
6.5.1 Введение
Цели безопасности - это требования к безопасности верхнего уровня для данного устройства. Из них формируются требования к функциональной безопасности, чтобы избежать необоснованного риска опасного события. Цели безопасности определяются на стадии формирования концепции в соответствии с требованиями 7.4.8 ИСО 26262-3. Если цели безопасности похожи или ссылаются на одну и ту же опасность в различных ситуациях, то они могут быть объединены в одну цель безопасности с самыми высокими значением УПБА из объединяемых целей безопасности. Дальнейшая разработка может упроститься с уменьшением количества целей безопасности, которые в то же время должны охватывать все выявленные опасности.
6.5.2 Общие положения
В следующем примере устройство, цели безопасности и классификации значений УПБА используются только для иллюстрации процесса объединения целей безопасности. Данный пример не отражает применения настоящего стандарта для аналогичных реальных проектов. В частности, он не касается идентификации видов отказов, анализа ситуации и оценки воздействия на уровне автомобиля.
Для простоты, данный пример ограничивается композицией двух целей безопасности, но тот же самый подход может быть распространен и на большее количество исходных целей безопасности.
6.5.3 Определение функции
Рассмотрим транспортное средство, оснащенное системой электрического стояночного тормоза (EPB). Система EPB, включенная по конкретному запросу водителя, формирует тормозной момент на задних колесах автомобиля, чтобы предотвратить непреднамеренные движения автомобиля во время его стоянки (функция парковки).
6.5.4 Цели безопасности, применяемые для одной и той же опасности в различных ситуациях
6.5.4.1 Анализ опасностей и оценка рисков
Для упрощения примера рассмотрим следующий вид отказа функции парковки:
- непреднамеренное приведение в действие стояночного тормоза.
Примечание - В данном контексте термин "непреднамеренное приведение в действие" означает срабатывание функции без запроса водителя.
Данный вид отказа может по-разному воздействовать на транспортное средство в зависимости от конкретной сложившейся ситуации в момент возникновения отказа, что отражено в таблице 1.
6.5.4.2 Разработка целей безопасности
Как показано выше, одинаковые цели безопасности и безопасные состояния применимы к обеим ситуациям. Итак, цель безопасности может быть определена следующим образом:
- цель безопасности: предотвратить включение функции парковки без запроса водителя, когда транспортное средство двигается;
- безопасное состояние: EPB не работает;
- значение УПБА: наибольшее значение УПБА, определенное в таблице 1, задается данной цели безопасности.
Таблица 1 - Цели безопасности, полученные для одной и той же опасности в различных ситуациях
|
|
|
|
|
|
|
|
Вид отказа | Опасность | Конкретная ситуация | Опасное событие | Возможные последствия | УПБА | Цель безопасности | Безо- пасное состоя- ние |
Непреднамеренное приведение в действие стояночного тормоза | Неожиданное замедление | Высокая скорость, ИЛИ поворот, ИЛИ низкое поверхностное трение | Неожиданное замедление на высокой скорости, ИЛИ поворот, ИЛИ низкое поверхностное трение | Потеря устойчивости автомобиля | Более высокое значение УПБА | Предотвратить включение функции парковки без запроса водителя, когда транспортное средство двигается | EPB не работает |
Непреднамеренное приведение в действие стояночного тормоза | Неожиданное замедление | Скорость ниже средней И высокое поверхностное трение | Неожиданное замедление на скорости ниже средней И высокое поверхностное трение | Заднее столкновение со следующим автомобилем | Более низкое значение УПБА | Предотвратить включение функции парковки без запроса водителя, когда транспортное средство двигается | EPB не работает |
7 Структура требований к процессу обеспечения безопасности. Последовательность выполнения требований к безопасности
Последовательность разработки и выполнения требований к безопасности в соответствии с настоящим стандартом показаны на рисунках 7 и 8 и описаны ниже. На этих рисунках конкретные разделы настоящего стандарта указаны следующим образом: "m-n", где "m" означает номер части настоящего стандарта, а "n" указывает номер раздела или подраздела в этой части.
Анализ опасностей и оценка риска выполняется для определения рисков и определения целей безопасности для снижения этих рисков. (См. раздел 7 ИСО 26262-3 Анализ опасностей и оценка рисков.)
Затем формируется концепция функциональной безопасности, которая определяет требования функциональной безопасности, обеспечивающие выполнение целей безопасности. Данные требования определяют механизмы обеспечения безопасности и другие меры обеспечения безопасности, которые будут использоваться в данном устройстве. Кроме того, определяются элементы архитектуры системы, которые обеспечивают выполнение этих требований. (См. раздел 8 ИСО 26262-3, Концепция функциональной безопасности.)
Далее формируется техническая концепция обеспечения безопасности, которая определяет технические требования к системе безопасности и их распределение по элементам системы, реализуемым в проекте системы. Эти технические требования к системе безопасности укажут разбиение этих элементов между аппаратными средствами и программным обеспечением. (См. раздел 6 ИСО 26262-4, Спецификация технических требований к системе безопасности.)
Проект системы будет разработан в соответствии с техническими требованиями системы безопасности. Их реализация может быть определена в спецификации проекта системы. (См. раздел 7 ИСО 26262-4, Проект системы.)
Наконец, чтобы выполнить технические требования к системе безопасности и проекту системы, будут указаны требования к аппаратным средствам и программному обеспечению системы безопасности. (См. раздел 6 ИСО 26262-5, Спецификация требований к безопасности аппаратных средств, и раздел 6 ИСО 26262-6, Спецификация требований к безопасности программного обеспечения).
Рисунок 7 иллюстрирует взаимосвязь между стадиями формирования требований и разработки аппаратных средств, которые определены в настоящем стандарте.
|
 |
Рисунок 7 - Начинающаяся от формирования концепции последовательность разработки требований безопасности, проектирования и тестирования для аппаратных средств
Рисунок 8 иллюстрирует взаимосвязь между подстадиями формирования требований, разработки и тестирования для программного обеспечения, определяемую настоящим стандартом.
|
 |
ПО - программное обеспечение
Рисунок 8 - Начинающаяся от формирования концепции последовательность разработки требований безопасности, проектирования и тестирования для программного обеспечения
Проектирование системы
Проектирование системы - это непрерывный процесс уточнения от определения устройства (3-6) до формирования предположений предварительной архитектуры и проекта системы (4-7).
Зависимость между уровнями тестирования
Спецификации тестов и тестовых примеров на каждом уровне в основном зависят от соответствующих требований и проекта. Они не зависят от спецификаций тестов, тестовых примеров и результатов тестов на других уровнях тестирования. Спецификации тестов обычно зависят от среды тестирования.
Зависимость уровней тестирования от уровней требований и проектирования
Спецификации тестов и тестовые примеры формируются из требований и используют информацию о проекте одного и того же уровня проектирования.
Пример - Для выполнения тестирования необходима информация о проекте.
Верификация требований к программному обеспечению системы безопасности
Стадия верификации требований к программному обеспечению системы безопасности (6-11) требует интеграции программного обеспечения и аппаратных средств.
Внешние меры и другие технологии
Подтверждение соответствия внешних меры и других технологий выполняется на уровне транспортного средства.
8 Разработка аппаратных средств
8.1 Классификация случайных сбоев аппаратных средств
8.1.1 Общие положения
В общем случае при рассмотрении комбинаций сбоев ограничиваются комбинациями из двух независимых сбоев аппаратных средств, если анализ, выполненный на основе функциональной или технической концепции обеспечения безопасности не показал, что n-кратный сбой с n>2 является существенным. Следовательно, для заданной цели безопасности и заданного элемента аппаратных средств, сбой может быть классифицирован в большинстве случаев как:
a) одиночный сбой;
b) остаточный сбой;
c) обнаруживаемый двойной сбой;
d) воспринимаемый двойной сбой;
e) скрытый двойной сбой;
f) безопасный сбой.
Пояснения и примеры различных классов сбоев приведены ниже.
8.1.2 Одиночный сбой
Данный сбой:
- может непосредственно привести к нарушению цели безопасности; и
- является сбоем элемента аппаратного средства, для которого ни один механизм безопасности не предотвращает некоторые из таких сбоев элемента аппаратного средства от нарушения цели безопасности.
Пример - Неконтролируемый резистор, для которого хотя бы один вид отказа (например, обрыв цепи) имеет возможность нарушить цель безопасности.
Примечание - Если часть аппаратного средства имеет, по крайней мере, один механизм безопасности (например, сторожевое устройство микроконтроллера), то ни один сбой этой части не классифицируется как одиночный сбой. Сбои, для которых механизмы безопасности не предотвращают нарушения цели безопасности, классифицируются как остаточные сбои.
8.1.3 Остаточный сбой
Данный сбой:
- может непосредственно привести к нарушению цели безопасности; и
- является сбоем элемента аппаратного средства, для которого, по крайней мере, один механизм безопасности предотвращает некоторые из таких сбоев элемента аппаратного средства от нарушения цели безопасности.
Пример - Если оперативная память (RAM) модуля проверяется только с помощью механизма безопасности, использующего тест шахматного кода, то некоторые виды сбоев типа замыкания не обнаруживаются. Нарушение целей безопасности из-за этих сбоев не предотвращается механизмом безопасности. Такие сбои являются примерами остаточных сбоев.
Примечание - В таком случае значение охвата диагностикой механизма безопасности менее 100%.
8.1.4 Обнаруживаемый двойной сбой
Данный сбой:
- вносит вклад в нарушение цели безопасности;
- может привести к нарушению цели безопасности только в сочетании с другим, отличающимся от него, независимым сбоем аппаратного средства, связанным с этим двойным сбоем; и
- обнаруживается механизмом безопасности, который не позволяет ему быть скрытым.
Примеры
1 Флэш-память защищена контролем по четности. Сбой одного бита, который выявляется и в соответствии с технической концепцией обеспечения безопасности инициируется такая реакция, как отключение устройства и информирование водителя с помощью контрольной лампы.
2 Флэш-память защищена механизмом обнаружения ошибки и исправления кода (EDC). Сбои в логике EDC обнаруживаются тестированием и в соответствии с технической концепцией обеспечения безопасности инициируется реакция такая, как информирование водителя с помощью контрольной лампы.
Если происходит кратковременный сбой и механизм безопасности восстанавливает устройство в состояние без сбоя, то такой сбой можно рассматривать как обнаруживаемый двойной сбой, даже если водитель никогда не будет информирован о его существовании.
Пример - Кратковременное переключение бита, которое корректируется механизмом обнаружения ошибки и исправления кода (EDC) перед передачей данных в центральный процессор и корректируется в дальнейшем, записывая правильное значение. Можно вести журнал, чтобы различать прерывистые сбои от истинных кратковременных сбоев.
8.1.5 Воспринимаемый двойной сбой
Данный сбой:
- вносит вклад в нарушение цели безопасности, но будет приводить к нарушению цели безопасности только в сочетании с другим, отличающимся от него, независимым сбоем аппаратного средства, связанным с этим двойным сбоем и
- воспринимается водителем в течение установленного времени независимо от того был или не был обнаружен данный сбой механизмом безопасности.
Пример - Двойной сбой может быть воспринят водителем, если функциональность значительно и однозначно пострадала от последствия данного сбоя.
Примечание - Если двойной сбой воспринимается водителем, а также выявляется механизмом безопасности, то он может классифицироваться как обнаруживаемый либо воспринимаемый двойной сбой, но не оба одновременно. Это связано с тем, что метрика скрытого сбоя будет рассчитываться неправильно, так как один сбой будет вносить вклад в обнаруживаемые двойные сбои, а также в воспринимаемые двойные сбои, учитывая этот сбой дважды.
8.1.6 Скрытый двойной сбой
Данный сбой:
- вносит вклад в нарушение цели безопасности, но будет приводить к нарушению цели безопасности только в сочетании с другим, отличающимся от него, независимым сбоем и
- не обнаруживается механизмом безопасности и не воспринимается водителем. До появления второго независимого сбоя система все еще действует и водителю об этом сбое не сообщается.
Примеры
1 Флэш-память защищена механизмом EDC. Значение постоянного сбоя в одном разряде корректируется EDC при чтении, но данный сбой не исправляется во флэш-памяти и сигнал о нем водителю не подается. В этом случае данный сбой не может привести к нарушению цели безопасности (так как неисправный бит корректируется), но он не является ни обнаруживаемым (о единичном сбое бита не сообщается), ни воспринимаемым (так как не влияет на функциональность применения). Если в логике EDC происходит дополнительный сбой, то он может привести к потере управления над данным одиночным сбоем бита и возможному нарушению цели безопасности.
2 Флэш-память защищена механизмом EDC. Сбой в логике EDC приводит к неготовности EDC, которая тестом не выявляется.
8.1.7 Безопасный сбой
Безопасными могут быть сбои одной из двух категорий:
a) все n-кратные сбои с n>2, если концепция обеспечения безопасности не показывает, что они вносят соответствующий вклад в нарушение цели безопасности, или
b) сбои, которые не вносят вклад в нарушение цели безопасности.
Примеры
1 Флэш-память защищена механизмами EDC и циклического контроля избыточности (CRC). Сбой в одном разряде корректируется EDC, но о нем водителю не сообщается. Сбою не дают возможность нарушить цель безопасности, но EDC об этом не сообщает. Если логика EDC выходит из строя, то сбой обнаруживается механизмом CRC и система отключается. И только если во флэш-памяти присутствует сбой в одном разряде, и логика EDC вышла из строя, и в механизме CRC произошли нарушения при вычислении контрольной суммы CRC, то может произойти нарушение цели безопасности (n=3).
2 Три соединенные последовательно резистора решают проблему одиночного сбоя типа короткого замыкания, так как короткое замыкание каждого резистора можно считать безопасным сбоем, и для нарушения цели безопасности необходимо, чтобы произошли три независимых коротких замыкания (n=3).
8.1.8 Блок-схема классификации сбоев и вычисление вклада каждого класса сбоев
Виды отказов элемента аппаратного средства могут быть классифицированы, как показано на рисунке B.1 ИСО 26262-5, и используя блок-схему, описанную на рисунке B.2 ИСО 26262-5. На рисунке 9 представлен расчет интенсивностей различных отказов на основе базовой интенсивности отказов и охвата различных видов отказов (остаточных по сравнению со скрытыми).
|
 |
Примечание - Существует два источника множественных сбоев:
- сбои, которые могут привести к нарушению цели безопасности, но для их предотвращения существуют механизмы безопасности;
- сбои, которые сами по себе не могут привести к нарушению цели безопасности, но которые вносят вклад в сценарий множественного отказа.
В зависимости от источника множественного сбоя, охват вида отказа по отношению к множественным сбоям может варьироваться.
Рисунок 9 - Классификация категорий отказов и расчет соответствующих интенсивностей отказов
8.1.9 Расчет интенсивности отказов от множественных сбоев, связанных с механизмами безопасности на основе программного обеспечения от случайных отказов аппаратных средств
Хотя систематические сбои программного обеспечения и аппаратных средств в настоящем стандарте количественно не определяются, интенсивность отказов может быть рассчитана для случайных отказов аппаратных средств аппаратных ресурсов, поддерживающих выполнение механизмов безопасности на основе программного обеспечения от случайных отказов аппаратных средств.
Если на этих аппаратных ресурсах совместно реализуются функции, которые могут непосредственно нарушить цель безопасности, то выбираются модели сбоев так, чтобы отразить данную ситуацию и рассмотреть возможные зависимые отказы.
8.2 Пример оценки интенсивности остаточных отказов и метрики локального одиночного сбоя
8.2.1 Общие положения
Такой контроль выполняется в соответствии с требованиями приложения D ИСО 26262-5, либо как "проверка обоснованности датчика", либо как "сравнение / голосование на входе".
В данном примере классифицируются и оцениваются только сбои датчика A_Master. Отказы датчика A_Checker не рассматриваются.
8.2.2 Технические требования обеспечения безопасности для датчика A_Master
Граница безопасной эксплуатации датчика A_Master показана на рисунке 10 и считается заданной в данном примере (ее вывод из цели безопасности здесь не обсуждается). Она может быть выражена с помощью следующих терминов:
v - измеряемая физическая величина;
a - постоянная величина.
Связанный с безопасностью отказ датчика происходит, когда
|
 |
Рисунок 10 - Граница безопасной эксплуатации датчика A_Master
8.2.3 Описание механизма безопасности
Если значение состояния отказа ИСТИНА, то выполняется переход в безопасное состояние.
В этом алгоритме:
Предполагается, что датчики имеют следующие известные допуски:
v - измеряемая физическая величина.
При таком подходе, наихудшим случаем необнаружения отказа является:
v - измеряемая физическая величина.
В зависимости от значений допуска, возможны различные сценарии выявления отказов. Два примера представлены на рисунках 11 и 12.
|
 |
Рисунок 11 - Пример 1 наихудшего случая порога обнаружения (слишком высокий)
На рисунке 11 указателями показаны три области.
|
 |
8.2.4 Оценка примера 1, описанного на рисунке 11
8.2.4.1 Общие положения
Таблица 2 - Пример видов отказов датчика
|
|
|
|
|
Элемент | См. таблицы | Анализируемые виды отказов для 60/90/99% ОД | ||
|
| Низкий (60%) | Средний (90%) | Высокий (99%) |
Общие элементы | ||||
Датчики, включая переключатели сигналов | D.11 | Нет общей модели сбоя. Необходим детальный анализ.
Типичные виды охватываемых отказов:
- недопустимые значения;
- константные в рабочем диапазоне | Нет общей модели сбоя. Необходим детальный анализ.
Типичные виды охватываемых отказов:
- недопустимые значения;
- смещения;
- константные в рабочем диапазоне | Нет общей модели сбоя. Необходим детальный анализ.
Типичные виды охватываемых отказов:
- недопустимые значения;
- смещения;
- константные в рабочем диапазоне; - колебания |
Для анализа выделяем три различных сценария константных сбоев для датчика (см. рисунок 13):
|
 |
Рисунок 13 - Сценарии константных сбоев
|
 |
|
 |
|
 |
Для каждого из этих условий, вероятность остаточного сбоя вычисляется отдельно. Результирующая вероятность остаточного сбоя рассчитывается с использованием значения этих трех вероятностей.
|
 |
В зависимости от текущего значения v, сбои могут быть обнаруживаемыми двойными сбоями (область 4), остаточными сбоями (область 6) или не имеющими возможность нарушить цель безопасности (область 5).
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.