ГОСТ Р ИСО 26262-4-2021 Дорожные транспортные средства. Функциональная безопасность. Часть 4. Разработка изделия на уровне системы.
ГОСТ Р ИСО 26262-4-2021
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ДОРОЖНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА. ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ
Часть 4
Разработка изделия на уровне системы
Road vehicles. Functional safety. Part 4. Product development at the system level
ОКС 13.110
Дата введения 2022-06-01
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Российский институт стандартизации" (ФГБУ "РСТ") совместно с Обществом с ограниченной ответственностью "ЭОС Тех" (ООО "ЭОС Тех") и Обществом с ограниченной ответственностью "Корпоративные электронные системы" (ООО "КЭЛС-центр") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 58 "Функциональная безопасность"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 октября 2021 г. N 1277-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 26262-4:2018* "Дорожные транспортные средства. Функциональная безопасность. Часть 4. Разработка изделия на уровне системы" (ISO 26262-4:2018 "Road vehicles - Functional safety - Part 4: Product development at the system level", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВЗАМЕН ГОСТ Р ИСО 26262-4-2014
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Комплекс стандартов ИСО 26262 является адаптацией комплекса стандартов МЭК 61508 и предназначена для применения электрических и/или электронных (далее - Э/Э) систем в дорожных транспортных средствах.
Данная адаптация распространяется на все виды деятельности в процессе жизненного цикла систем, связанных с безопасностью, включающих электрические, электронные и программные компоненты.
Безопасность является одним из приоритетов современного автомобилестроения. Расширение числа функциональных возможностей транспортных средств вызывает необходимость использования методологии функциональной безопасности и подтверждения достижения целей функциональной безопасности.
С ростом сложности технологий, программного обеспечения и мехатронных устройств увеличиваются риски, связанные с систематическими и случайными отказами аппаратных средств, рассматриваемыми в рамках функциональной безопасности. Комплекс стандартов ИСО 26262 является руководством по снижению этих рисков, в которое включены соответствующие требования и процессы.
Для достижения функциональной безопасности комплекс стандартов ИСО 26262 устанавливает:
a) жизненный цикл системы безопасности транспортного средства и включает перечень действий для стадий этого жизненного цикла (разработка, производство, эксплуатация, обслуживание, вывод из эксплуатации);
b) подход, основанный на оценке риска, разработанный специально для автомобильного транспорта для определения уровней полноты безопасности [уровни полноты безопасности транспортного средства (УПБТС)];
c) использование значения УПБТС для спецификации требований комплекса стандартов ИСО 26262 с целью предотвращения неоправданного остаточного риска;
d) требования к мерам по выполнению менеджмента функциональной безопасности, проектирования, реализации, верификации, валидации, а также к мерам их подтверждения;
e) требования к взаимодействию между заказчиками и поставщиками.
Комплекс стандартов ИСО 26262 рассматривает функциональную безопасность Э/Э систем, которая достигается с помощью мер по обеспечению безопасности, включая механизмы обеспечения безопасности. Однако он также обеспечивает подход, в рамках которого допускается использовать связанные с безопасностью системы, реализуемые на других технологиях (например, механических, гидравлических и пневматических).
На достижение функциональной безопасности влияют процессы разработки (в том числе спецификация требований, проектирование, реализация, интеграция, верификация, валидация и управление конфигурацией), процессы производства и обслуживания, а также процессы управления.
Вопросы безопасности тесно связаны с опытно-конструкторскими работами, реализующими функционал и обеспечивающими качество создаваемых изделий, а также с результатами таких работ. Настоящий стандарт рассматривает связанные с безопасностью проблемы, касающиеся опытно-конструкторских работ и их результатов.
На рисунке 1 показана общая структура комплекса стандартов ИСО 26262. В нем для различных стадий разработки изделия используют эталонную V-модель процесса. На рисунке 1:
- заштрихованная область в виде символа "V" представляет взаимосвязь между ИСО 26262-3, ИСО 26262-4, ИСО 26262-5, ИСО 26262-6 и ИСО 26262-7;
- для мотоциклов:
ИСО 26262-12:2018, раздел 8 соответствует требованиям ИСО 26262-3,
ИСО 26262-12:2018, разделы 8 и 10 соответствуют требованиям ИСО 26262-4;
- ссылки на конкретную информацию даны в виде: "m-n", где "m" представляет собой номер части настоящего стандарта, а "n" указывает на номер раздела этой части.
Пример - 2-6 ссылается на раздел 6 ИСО 26262-2.
|
 |
Рисунок 1 - Общая структура ИСО 26262
1 Область применения
Настоящий стандарт применяется к системам, связанным с безопасностью, включающим в себя одну или несколько Э/Э систем, которые установлены в серийно производимые дорожные транспортные средства, исключая мопеды. Настоящий стандарт не применяется для уникальных Э/Э систем транспортных средств специального назначения, таких как Э/Э системы, предназначенные для водителей с ограниченными возможностями.
Примечание - Существуют другие стандарты по безопасности для специального применения, которые могут дополнить комплекс стандартов ИСО 26262 либо включать в себя требования комплекса стандартов ИСО 26262.
Системы и их компоненты, находящиеся в производстве или на стадии разработки до даты публикации настоящего стандарта, не входят в его область применения. Настоящий стандарт распространяется на изменения к существующим системам и их компонентам, запущенным в производство до публикации настоящего стандарта, корректируя жизненный цикл системы безопасности в зависимости от конкретного изменения. Настоящий стандарт распространяется на интеграцию существующих систем, разработанных как не в соответствии с настоящим стандартом, так и в соответствии с настоящим стандартом при корректировке жизненного цикла системы безопасности.
Настоящий стандарт рассматривает возможные опасности, вызванные некорректным функционированием Э/Э систем, связанных с безопасностью, а также некорректным взаимодействием этих систем. Настоящий стандарт не рассматривает опасности, связанные с поражением электрическим током, возгоранием, задымлением, перегревом, излучением, токсичностью, воспламеняемостью, химической активностью, коррозией и подобными опасностями, если они непосредственно не вызваны некорректным функционированием Э/Э систем, связанных с безопасностью.
Настоящий стандарт описывает методологию функциональной безопасности, обеспечивающую разработку Э/Э систем, связанных с безопасностью. Эта методология предназначена для интеграции действий по функциональной безопасности в определенную для компании дисциплину разработки. Некоторые требования имеют четкую техническую направленность на обеспечение функциональной безопасности изделия; другие связаны с процессом разработки и поэтому могут рассматриваться как требования к процессу для того, чтобы продемонстрировать способность организации реализовать методологию функциональной безопасности.
Настоящий стандарт не рассматривает номинальные характеристики Э/Э систем.
Настоящий стандарт устанавливает требования к разработке изделия на уровне системы для применения на автомобильных транспортных средствах, в том числе:
- общие вопросы по запуску разработки изделия на уровне системы;
- спецификацию требований к технической безопасности;
- концепцию технической безопасности;
- архитектуру системы;
- интеграцию и тестирование устройства;
- валидацию системы.
В приложении А представлен обзор целей, предпосылок и результатов работы, рассмотренных в настоящем стандарте.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты [для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения к нему)]:
ISO 26262-1:2018, Road vehicles - Functional safety - Part 1: Vocabulary (Дорожные транспортные средства. Функциональная безопасность. Часть 1. Термины и определения)
ISO 26262-2:2018, Road vehicles - Functional safety - Part 2: Management of functional safety (Дорожные транспортные средства. Функциональная безопасность. Часть 2. Менеджмент функциональной безопасности)
ISO 26262-3:2018, Road vehicles - Functional safety - Part 3: Concept phase (Дорожные транспортные средства. Функциональная безопасность. Часть 3. Стадия формирования концепции)
ISO 26262-5:2018, Road vehicles - Functional safety - Part 5: Product development at the hardware level (Дорожные транспортные средства. Функциональная безопасность. Часть 5. Разработка аппаратных средств изделия)
ISO 26262-6:2018, Road vehicles - Functional safety - Part 6: Product development at the software level (Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия)
ISO 26262-7:2018, Road vehicles - Functional safety - Part 7: Production and operation (Дорожные транспортные средства. Функциональная безопасность. Часть 7. Производство и эксплуатация)
ISO 26262-8:2018, Road vehicles - Functional safety - Part 8: Supporting processes (Дорожные транспортные средства. Функциональная безопасность. Часть 8. Вспомогательные процессы)
ISO 26262-9:2018, Road vehicles - Functional safety - Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses (Дорожные транспортные средства. Функциональная безопасность. Часть 9. Анализ уровня полноты безопасности автомобиля и анализ безопасности автомобиля)
3 Термины и определения
В настоящем стандарте применены термины, определения и сокращения по ИСО 26262-1.
ИСО и МЭК для применения в стандартизации поддерживают терминологические базы данных:
- Электропедия МЭК; доступна по адресу: http://www.electropedia.org/
- Платформа онлайн-просмотра ИСО; доступна по адресу: https://www.iso.org/obp.
4 Требования соответствия настоящему стандарту
4.1 Цель
В настоящем разделе описывается, каким образом:
a) обеспечить соответствие требованиям комплекса стандартов ИСО 26262;
b) интерпретировать таблицы, используемые в комплексе стандартов ИСО 26262;
c) интерпретировать применимость каждого раздела в зависимости от соответствующего УПБТС.
4.2 Общие требования
Для соответствия комплекса стандартов ИСО 26262 должно быть выполнено каждое его требование, если для этого требования не выполняется одно из следующих условий:
a) в соответствии с ИСО 26262-2 предусмотрена адаптация действий по обеспечению безопасности, которая показывает, что данное требование не применяется;
b) существует обоснование того, что несоблюдение данного требования допустимо, а также показано соответствие этого обоснования ИСО 26262-2.
Справочная информация, включая примечания и примеры, должна быть использована только для понимания или уточнения соответствующего требования и не должна быть истолкована как самостоятельное требование или быть полной или исчерпывающей.
Результаты действий по обеспечению безопасности представлены как результаты работы. В пунктах "Предварительные требования" перечислена информация, которая должна быть доступна как результат работы предыдущей стадии. Так как определенные требования разделов настоящего стандарта зависят от УПБТС или могут быть адаптированы, то некоторые результаты работы в качестве предварительных условий могут не потребоваться.
В пунктах "Дополнительная информация" приведена информация, которую можно учитывать, но в некоторых случаях настоящий стандарт не требует, чтобы она была результатом работы предыдущей стадии. Такая информация может быть получена из внешних источников, а также от лиц или организаций, которые не несут ответственности за деятельность по обеспечению функциональной безопасности.
4.3 Интерпретация таблиц
В настоящем стандарте используются нормативные или справочные таблицы в зависимости от их контекста. Перечисленные в таблицах различные методы вносят вклад в уровень уверенности в достижении соответствия с рассматриваемым требованием. Каждый метод в таблицах включен:
a) в последовательный список методов (он обозначен порядковым номером в левой графе, например 1, 2, 3);
b) либо в альтернативный список методов (он обозначен номером с последующей буквой в левой графе, например 2a, 2b, 2c).
В случае последовательного списка для соответствующего значения УПБТС следует применять все "наиболее рекомендуемые" и "рекомендуемые" методы. Допускается замена "наиболее рекомендуемого" или "рекомендуемого" метода другим, не перечисленным в таблице методом, но в этом случае должно быть дано обоснование тому, почему он удовлетворяет соответствующему требованию. Если может быть обосновано, что для удовлетворения соответствующему требованию не выбираются никакие методы, то в дальнейшем обоснование пропущенных методов не выполняется.
В случае альтернативного списка следует применять наиболее подходящую комбинацию методов согласно указанному значению УПБТС независимо от того, перечислена в таблице эта комбинация или не перечислена. Если перечисленные методы имеют разные степени рекомендуемости их применения для некоторого значения УПБТС, то следует отдать предпочтение методам с более высокой степенью рекомендуемости. Должно быть дано обоснование, что выбранная комбинация методов или даже отдельно выбранный метод выполняют соответствующее требование.
Примечание - Обоснование, основанное на методах, перечисленных в таблице, является достаточным. Но это не означает, что существует какое-то предубеждение за или против применения методов, не перечисленных в таблице.
Для каждого метода степень рекомендуемости его применения зависит от значения УПБТС и классифицируется следующим образом:
"++" - метод является наиболее рекомендуемым для определенного значения УПБТС;
"+" - метод рекомендуется для определенного значения УПБТС;
"о" - метод не имеет рекомендации за или против его применения для определенного значения УПБТС.
4.4 Требования и рекомендации, зависимые от значения УПБТС
Требования или рекомендации каждого подраздела необходимо соблюдать для значений УПБТС A, B, C и D, если не указано иное. Эти требования и рекомендации связаны со значениями УПБТС цели безопасности. Если в соответствии с требованиями раздела 5 ИСО 26262-9 декомпозиция УПБТС была выполнена на более ранней стадии разработки, то должны соблюдаться значения УПБТС, полученные в результате декомпозиции.
Если в настоящем стандарте значение УПБТС дается в круглых скобках, то соответствующий подпункт должен быть рассмотрен как рекомендация, а не требование для данного значения УПБТС. Это не касается скобочных записей, относящихся к декомпозиции УПБТС.
4.5 Адаптация к мотоциклам
Для устройств или элементов мотоциклов, для которых применимы требования ИСО 26262-12, эти требования могут быть использованы вместо соответствующих требований настоящего стандарта. Требования настоящего стандарта, которые заменены требованиями ИСО 26262-12, определены в ИСО 26262-12.
4.6 Адаптация к грузовым транспортным средствам, автобусам, прицепам и полуприцепам
Содержание, которое предназначено для спецификации грузовых автомобилей, автобусов, прицепов и полуприцепов, обозначено как (Т&В).
5 Общие вопросы по разработке изделия на уровне системы
5.1 Цели
Целью настоящего раздела является предоставление общего описания разработки изделия на уровне системы.
5.2 Общие положения
Необходимые действия при разработке системы приведены на рисунке 2. Концепция технической безопасности, включая требования технической безопасности, и архитектура системы разрабатываются итерационно. Вначале устанавливается архитектура системы, затем формируются требования технической безопасности для элементов системы, а также для элементов систем, основанных на других технологиях, если они применяются. Далее эти требования технической безопасности уточняются и добавляются требования, возникающие в результате формирования архитектуры системы, включающей аппаратно-программный интерфейс (HSI). В зависимости от сложности архитектуры требования к подсистемам могут быть получены итерационно.
После разработки элементов аппаратных средств и программного обеспечения они интегрируются и тестируются, затем сформированное устройство устанавливается на транспортное средство. После интеграции устройства на уровне транспортного средства выполняется валидация безопасности для представления доказательств того, что функциональная безопасность обеспечивает достижение целей безопасности.
|
 |
Рисунок 2 - Базовая модель стадии разработки устройства, связанного с безопасностью
Настоящий стандарт применяется при разработке систем. В ИСО 26262-5 и ИСО 26262-6 представлены требования к разработке аппаратных средств и программного обеспечения соответственно. На рисунке 3 представлен пример системы с несколькими уровнями интеграции, иллюстрирующий применение настоящего стандарта, ИСО 26262-5 и ИСО 26262-6.
Примечания
1 Таблица А.1 содержит обзор целей, предварительных требований и результатов работы рассматриваемых подстадий разработки изделия на уровне системы.
2 На рисунках 2 и 3 конкретные разделы каждой части комплекса стандартов ИСО 26262 указаны следующим образом: "m-n", где "m" представляет собой номер части ИСО 26262, а "n" указывает на номер раздела этой части, например 4-5 - это раздел 5 ИСО 26262-4.
3 Дополнительную информацию о разработке изделия на уровне системы можно найти в [1] и [2].
|
 |
Рисунок 3 - Пример разработки изделия на уровне системы
6 Концепция технической безопасности
6.1 Цели
Целями настоящего раздела являются следующие:
a) определение требования технической безопасности для функций, зависимостей, ограничений и свойств элементов системы и интерфейсов, необходимых для ее реализации;
b) формирование требований технической безопасности для механизмов безопасности, которые должны быть реализованы в элементах системы и интерфейсах;
c) установление требований функциональной безопасности системы и ее элементов в процессах производства, эксплуатации, обслуживания и вывода из эксплуатации;
d) контроль требований технической безопасности на предмет достижения функциональной безопасности на уровне системы, а также их соответствия требованиям функциональной безопасности;
e) разработка архитектуры системы и концепции технической безопасности, удовлетворяющих требованиям безопасности и не противоречащих требованиям, не связанным с безопасностью;
f) анализ архитектуры системы в целях предотвращения сбоев и определения необходимых для производства и обслуживания специальных характеристик, связанных с безопасностью;
g) проверка архитектуры системы и концепции технической безопасности на предмет их соответствия требованиям безопасности с определенными значениями УПБТС.
6.2 Общие положения
Концепция технической безопасности представляет собой обобщение требований технической безопасности и соответствующей архитектуры системы, которая дает обоснование того, почему архитектура системы удовлетворяет требованиям безопасности, полученным в результате выполнения требований, описанных в ИСО 26262-3 (с учетом требований, не связанных с безопасностью), а также конструктивным ограничениям.
Требования технической безопасности определяют техническую реализацию требований функциональной безопасности на их соответствующем иерархическом уровне с учетом определения как устройства, так и архитектуры системы, а также выявления скрытых отказов, предотвращения сбоев, полноты безопасности и вопросов эксплуатации и обслуживания.
Архитектура системы - это выбранное решение на уровне системы, реализуемое технической системой. Архитектура системы предполагает выполнение как распределенных требований технической безопасности, так и требований, не связанных с безопасностью.
Разработка системы может быть выполнена итерационно.
6.3 Входная информация
6.3.1 Предварительные требования
Необходима следующая информация:
- концепция функциональной безопасности в соответствии с требованиями 7.5.1 ИСО 26262-3;
- архитектура системы (из внешних источников, см. 7.3.1 ИСО 26262-3);
- требования к устройству от других устройств, реализующих функции безопасности, если применимы.
Пример - Требования системы поддержки парковки к тормозной системе.
Примечание - При распределенной разработке концепция технической безопасности может быть основана на другой концепции технической безопасности, реализованной подсистемами.
6.3.2 Дополнительная информация
Может быть учтена следующая информация:
- отчет об анализе опасностей и оценке рисков (см. 6.5.1 ИСО 26262-3);
- определение устройства (см. 5.5.1 ИСО 26262-3).
6.4 Требования и рекомендации
6.4.1 Спецификация требований технической безопасности
6.4.1.1 Требования технической безопасности должны быть определены в соответствии с концепцией функциональной безопасности, архитектурой системы устройства и учитывать следующее:
a) связанные с безопасностью зависимости и ограничения устройств, систем и их элементов;
b) внешние интерфейсы системы, если применяются;
c) способность к изменению конфигурации системы.
Примечания
1 Конструктивные ограничения могут быть обусловлены рабочими условиями, пространством для установки, самой реализацией (например, заданная производительность, теплоемкость, теплоотдача) и другими функциональными или нефункциональными требованиями (например, защита информации, физические ограничения используемых технологий).
2 Способность к изменению конфигурации конструкции систем определяется вариантами элементов системы, данными конфигурации или калибровочными данными и часто применяется как часть стратегии повторного использования существующих систем для различных приложений.
6.4.1.2 В требованиях технической безопасности должна быть указана реакция системы на заданное воздействие, влияющая на достижение требований безопасности. Такая реакция включает комбинации соответствующих входных сигналов и отказов для каждого соответствующего режима работы и определенного состояния системы.
Пример - Электронный блок управления адаптивным круиз-контролем (АСС) блокирует функционирование АСС, если из электронного блока управления тормозной системой получена информация о том, что система курсовой устойчивости не функционирует.
6.4.1.3 Если системой или ее элементами реализуются другие функции или требования помимо тех функций, которые указаны в требованиях технической безопасности, то эти функции или требования должны быть определены или должны быть указаны ссылки на соответствующие документы.
Пример - Источниками других требований являются правила Европейской экономической комиссии (ЕЭК), Федеральный стандарт безопасности автомобилей (FMVSS), стратегические платформы компаний, функциональные концепции или другие концепции, такие как концепция киберзащищенности.
6.4.1.4 Требования технической безопасности и технические требования, не связанные с безопасностью, не должны быть противоречивы.
6.4.2 Механизмы безопасности
6.4.2.1 Технические требования безопасности должны определять необходимые механизмы безопасности, которые обнаруживают сбои и предотвращают или смягчают отказы на выходе системы, нарушающие требования функциональной безопасности (см. раздел 7 ИСО 26262-3), включая в том числе:
a) механизмы безопасности, связанные с обнаружением, индикацией и управлением сбоями в самой системе.
Примечания
1 Они включают в себя самоконтроль системы для обнаружения случайных сбоев аппаратных средств и, при необходимости, для выявления систематических сбоев.
2 Они включают в себя механизмы безопасности по выявлению и управлению отказами каналов связи (например, интерфейсы данных, коммуникационные шины, беспроводная радиосвязь).
3 Механизмы безопасности могут быть определены с учетом соответствующего уровня архитектуры системы;
b) механизмы безопасности, связанные с обнаружением, индикацией и управлением сбоями во внешних элементах, которые взаимодействуют с системой.
Пример - Внешние устройства включают в себя другие электронные блоки управления, блоки питания или средства связи;
c) механизмы безопасности, содействующие системе в обеспечении достижения или поддержания безопасного состояния устройства.
Примечание - Они включают в себя логику установления приоритетов в случае управления несколькими запросами от механизмов безопасности;
d) механизмы безопасности, определяющие и реализующие концепцию предупреждения и постепенного снижения работоспособности системы;
e) механизмы безопасности для предотвращения возникновения скрытых сбоев.
Примечание - Эти механизмы безопасности, как правило, связаны с бортовыми тестами, которые выполняются при включении питания [предварительные проверки транспортного средства (ТС)], как в случаях по перечислениям a)-d), в процессе эксплуатации, во время отключения питания (постпроверки ТС), а также при техническом обслуживании.
6.4.2.2 Для каждого механизма безопасности, который позволяет устройству достигать или поддерживать безопасное состояние, должны быть определены:
a) переходы между состояниями.
Примечание - Такая спецификация включает в себя требования к управлению исполнительными устройствами;
b) временной интервал обработки сбоя в рамках временных требований, распределяемых на соответствующем уровне архитектуры.
Примечание - Это дополнительное требование направлено на достижение согласованных временных характеристик в пределах временного интервала сбоеустойчивости (FTTI), который определен для каждой цели безопасности;
c) допустимый временной интервал аварийного режима (см. 3.45 ИСО 26262-1), если безопасное состояние изделия устройства не может быть достигнуто в пределах FTTI.
Примечание - Для определения допустимого временного интервала аварийного режима ТС могут быть использованы результаты испытаний и экспериментов, выполненные для этого ТС.
Примеры
1 Длительность состояния в режиме постепенного снижения работоспособности системы до перехода в безопасное состояние.
2 Спецификация механизма безопасности для электрической системы управления тормозной системой, зависящей от источника питания, может включать второй источник питания или устройство хранения данных (емкость, время запуска и работы и т.д.).
6.4.2.3 Должны быть определены механизмы безопасности для предотвращения возникновения скрытых сбоев, если эти механизмы применимы. Данное требование распространяется на значения УПБТС (A), (B), C и D.
Примечания
1 Только случайные сбои аппаратных средств, которые являются множественными, могут быть скрытыми.
Пример - Бортовые тесты являются механизмами безопасности, которые проверяют состояние компонентов при различных режимах работы (например, включение и выключение двигателя, режим эксплуатации или режим дополнительного бортового тестирования) для выявления множественных сбоев. Тесты клапанов, реле или функционирования ламп, которые выполняются стандартной программой при запуске двигателя, являются примерами таких бортовых тестов.
2 Критерии оценки, которые позволяют определить необходимость применения механизмов безопасности для предотвращения возникновения скрытых сбоев, получают в соответствии с надлежащей инженерной практикой. Мерой критериев оценки является значение метрики скрытых сбоев, представленное в разделе 8 ИСО 26262-5.
6.4.2.4 Данное требование распространяется на значения УПБТС (A), (B), C и D. Для того чтобы предотвратить множественные отказы, для каждого механизма безопасности, реализуемого для выявления множественных сбоев, должна быть определена стратегия диагностических испытаний, учитывающая:
a) требования к безотказности компонентов аппаратных средств с учетом их роли в архитектуре и их вклада в множественный отказ;
b) заданные количественные целевые значения для максимальной вероятности недостижения каждой цели безопасности из-за случайных отказов аппаратных средств (см. раздел 9 ИСО 26262-5);
c) назначенное значение УПБТС, полученное на основе указанной цели безопасности, соответствующего требования функциональной безопасности или требования технической безопасности на более высоком иерархическом уровне;
d) временной интервал обнаружения множественного сбоя.
Примечания
1 Стратегия диагностических испытаний может быть реализована на основе временного механизма (например, с использованием временного интервала диагностических проверок) либо событийного (например, тестирование при запуске двигателя).
2 Множественный отказ второго порядка включает два сбоя, отделенных временным интервалом обнаружения множественного сбоя.
3 Применение следующих мер зависит от временных ограничений:
- периодического тестирования системы или элементов в процессе эксплуатации;
- бортовых тестов элементов при включении или выключении двигателя;
- тестирования системы или элементов во время технического обслуживания.
6.4.2.5 Представленное ниже требование распространяется на значения УПБТС (A), (B), C и D. Разработка механизмов безопасности, которые реализованы только для предотвращения возникновения скрытых двойных сбоев, должна, по крайней мере, соответствовать:
a) значению УПБТС, равному B, если в требованиях технической безопасности назначено значение УПБТС, равное D;
b) значению УПБТС, равному A, если в требованиях технической безопасности назначены значения УПБТС, равные B и C;
c) требованиям QM, если в требованиях технической безопасности назначено значение УПБТС, равное A.
Примечание - Если к требованию применяется декомпозиция УПБТС, то требования настоящего пункта применяются к декомпозированному требованию.
Пример - Контроль по четности в памяти является ее механизмом безопасности с требованием по УПБТС, которому назначено значение В. Требованию для бортового теста, который проверяет способность механизма контроля по четности обнаруживать и подавать сигнал неисправности памяти, может быть назначено значение УПБТС, равное А.
6.4.3 Спецификация архитектуры системы и концепция технической безопасности
6.4.3.1 Архитектура системы для данной подстадии и концепция технической безопасности должны быть основаны на определении устройства, концепции функциональной безопасности и предшествующей архитектуре системы.
6.4.3.2 Должна быть проверена согласованность архитектуры системы, созданной в соответствии с требованиями 7.3.1 ИСО 26262-3, и архитектуры системы, созданной на данной подстадии. В случае выявления расхождений может потребоваться повторное выполнение действий, описанных в ИСО 26262-3.
6.4.3.3 Архитектура системы должна соответствовать требованиям технической безопасности.
6.4.3.4 При реализации требований технической безопасности в архитектуре системы должны быть учтены:
a) возможность верификации архитектуры системы;
b) технические возможности предполагаемых аппаратных средств и элементов программного обеспечения для обеспечения функциональной безопасности;
c) возможность выполнения испытаний во время интеграции системы.
6.4.3.5 Внутренние и внешние интерфейсы элементов, связанных с безопасностью, должны быть определены таким образом, чтобы другие элементы не оказывали неблагоприятного воздействия на элементы, связанные с безопасностью.
6.4.3.6 Если при проектировании архитектуры системы для требований безопасности применена декомпозиция УПБТС, то она должна быть выполнена в соответствии с разделом 5 ИСО 26262-9.
6.4.4 Анализ безопасности и предотвращение систематических отказов
6.4.4.1 В соответствии с требованиями, представленными в таблице 1 и разделе 8 ИСО 26262-9, должен быть выполнен анализ безопасности архитектуры системы для того, чтобы:
- предоставить доказательства того, что проект системы обеспечивает реализацию определенных связанных с безопасностью функций и свойств с соответствующими значениями УПБТС;
- выявить причины отказов и последствия сбоев;
- определить или подтвердить элементы и интерфейсы системы, связанные с безопасностью;
- обеспечить сопровождение спецификации проекта и выполнить проверку эффективности механизмов безопасности на основании выявленных причин сбоев и последствий отказов.
Таблица 1 - Анализ архитектуры системы
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1 | Дедуктивный анализ | о | + | ++ | ++ |
2 | Индуктивный анализ | ++ | ++ | ++ | ++ |
Примечания
1 Свойства, связанные с безопасностью, включают в себя требования к независимости и защищенности от электромагнитных помех.
2 Цель анализа архитектуры - поддержка при разработке. Поэтому на данной стадии, вероятно, можно ограничиться качественным анализом. Количественный анализ можно провести в случае необходимости.
3 Анализ проводится на том уровне детализации, который необходим для выявления причин и последствий случайных отказов аппаратных средств и систематических отказов.
4 Использование комбинации дедуктивных и индуктивных методов предназначено для реализации дополнительных методик при выполнении анализа (см. также 8.2 ИСО 26262-9).
6.4.4.2 Выявленные внутренние причины отказа должны быть устранены или, в случае необходимости, смягчены для того, чтобы было обеспечено достижение целей или соответствие требованиям безопасности.
6.4.4.3 Выявленные внешние причины отказа должны быть устранены или, в случае необходимости, смягчены для того, чтобы было обеспечено достижение целей или соответствие требованиям безопасности.
6.4.4.4 Для уменьшения вероятности систематических отказов должны быть применены принципы проектирования систем, обладающих высоким уровнем доверия в случае их использования. Данные принципы могут включать повторное использование обладающих высоким уровнем доверия:
a) концепций технической безопасности;
b) проектов элементов, включая аппаратные и программные компоненты;
c) механизмов выявления и управления отказами;
d) интерфейсов или стандартизованных интерфейсов.
6.4.4.5 Для обеспечения согласованности и соответствия требованиям применения изделия должен быть проведен и документально оформлен анализ пригодности обладающих высоким уровнем доверия принципов проектирования.
6.4.4.6 Для предотвращения систематических сбоев архитектура системы должна обладать следующими свойствами:
a) модульностью;
b) адекватным уровнем детализации;
c) простотой.
Примечание - Перечисленные выше свойства могут быть достигнуты за счет использования принципов проектирования, таких как иерархическое проектирование, точно определенные интерфейсы, устранение излишней сложности компонентов и интерфейсов, техническое обслуживание и доступность для проверки.
6.4.4.7 В соответствии с ИСО 26262-3 при повторном анализе опасностей и оценке рисков (HARA) должны быть включены опасности, выявленные в ходе анализа безопасности или при проектировании архитектуры системы, которые еще не были охвачены целью безопасности.
Примечание - Опасности, еще не охваченные целью безопасности, могут быть нефункциональными опасностями. Нефункциональные опасности не входят в область применения ИСО 26262, однако в результате выполнения анализа опасностей и оценки рисков они могут быть снабжены аннотацией, например: комментарий к опасности может быть следующий: "Этой опасности значение УПБТС не назначено, так как она не входит в область применения ИСО 26262".
6.4.5 Меры управления случайными отказами аппаратных средств в процессе эксплуатации
6.4.5.1 В соответствии с требованиями 6.4.3 для архитектуры системы должны быть определены меры по обнаружению, управлению или ослаблению последствий случайных отказов аппаратных средств.
Примеры
1 Такими мерами могут быть диагностические функции аппаратных средств и их использование программным обеспечением для обнаружения случайных отказов аппаратных средств.
2 Конструкция аппаратных средств, при наличии в них случайных отказов, всегда обеспечивает переход в безопасное состояние без выявления самого отказа (т.е. отказоустойчивая конструкция аппаратных средств).
Примечание - Для принятия решения о необходимости применения дополнительных мер безопасности следует использовать количественную аппроксимацию индуктивного и дедуктивного анализов в соответствии с требованиями 6.4.4.1. Окончательное решение может потребоваться после анализа аппаратных средств согласно ИСО 26262-5.
6.4.5.2 Данное требование распространяется на значения УПБТС (B), C и D цели безопасности. Для окончательной оценки на уровне устройства должна быть выбрана одна из альтернативных процедур оценки недостижения цели безопасности из-за случайных отказов аппаратных средств (см. раздел 8 ИСО 26262-5) и должны быть определены целевые значения.
6.4.5.3 Данное требование распространяется на значения УПБТС (B), C и D цели безопасности. На уровне элемента должны быть определены отвечающие требованиям целевые значения интенсивности отказов и диагностического охвата для того, чтобы выполнить:
a) целевые значения метрик, описанные в разделе 8 ИСО 26262-5;
b) процедуры, представленные в разделе 9 ИСО 26262-5.
6.4.5.4 Данное требование распространяется на значения УПБТС (B), C и D. При распределенной разработке (см. раздел 5 ИСО 26262-8) полученные целевые значения должны быть доведены до каждого соответствующего участника.
Примечание - Ограничения архитектуры, описанные в разделах 8 и 9 ИСО 26262-5, непосредственно не применимы к коммерчески доступным компонентам и частям, так как поставщики, как правило, не могут предвидеть использование своей продукции в конечном устройстве и возможные последствия ее применения в системах безопасности. В таком случае, чтобы позволить оценить ограничения архитектуры на уровне архитектуры аппаратных средств всей системы, поставщик должен предоставить основные данные, такие как интенсивность отказов, виды отказов, распределение интенсивностей отказов по видам отказов, встроенная диагностика и т.д.
6.4.6 Распределение требований для аппаратных средств и программного обеспечения
6.4.6.1 Требования технической безопасности должны быть распределены для элементов архитектуры системы: системы, аппаратных средств или программного обеспечения как реализующей технологии.
Примечание - Если требования распределены для системы как технического средства реализации, то для дальнейшей конкретизации этих требований вновь используется настоящий стандарт до тех пор, пока они не будут распределены для аппаратных средств и программного обеспечения.
6.4.6.2 Решения о распределении и разбиении должны соответствовать архитектуре системы.
Примечание - Чтобы добиться независимости и предотвратить распространение отказов, при проектировании архитектуры системы можно реализовать разбиение функций и компонентов.
6.4.6.3 Каждый элемент архитектуры системы должен наследовать наивысшее значение УПБТС среди требований технической безопасности, которые он реализует.
6.4.6.4 Если элемент архитектуры системы состоит из подэлементов с различными назначенными им значениями УПБТС, или подэлементов, связанных и не связанных с безопасностью, то каждый из них необходимо рассматривать в соответствии с самым высоким значением УПБТС, если они не удовлетворяют критериям совместимости (в соответствии с требованиями раздела 6 ИСО 26262-9).
6.4.6.5 Если требования технической безопасности распределяются заказным элементам аппаратных средств, которые включают программируемые функции (такие, как ASIC, FPGA или другие типы цифровых аппаратных средств), то должен быть определен и реализован подходящий процесс разработки, соответствующий сочетанию требований ИСО 26262-5 и ИСО 26262-6.
Примечания
1 Доказательства соответствия распределенному требованию безопасности для некоторых из этих элементов аппаратных средств могут быть представлены с помощью методов оценки в соответствии с требованиями раздела 13 ИСО 26262-8, если будут выполнены критерии для его применения.
2 Руководящие указания можно найти в ИСО 26262-11.
6.4.7 Технические требования к аппаратно-программному интерфейсу
6.4.7.1 Технические требования к аппаратно-программному интерфейсу (АПИ) должны определять взаимодействие аппаратных средств и программного обеспечения и должны соответствовать концепции технической безопасности. Технические требования к АПИ должны включать описания частей аппаратных средств компонента, которые находятся под управлением программного обеспечения, и аппаратные ресурсы, которые обеспечивают выполнение программ.
Примечание - Элементы и характеристики, подробно описанные в АПИ, приведены в приложении В.
6.4.7.2 Технические требования к АПИ должны включать следующие характеристики:
а) соответствующие рабочие режимы аппаратных устройств и соответствующие параметры конфигурации.
Примеры
1 Рабочие режимы аппаратных устройств: основной, пусковой, тестирования или расширенный.
2 Параметры конфигурации: регулировка усиления, полоса пропускания или частота предварительного делителя частоты тактового генератора;
b) аппаратные средства, гарантирующие независимость между элементами или обеспечивающие разбиение программного обеспечения на части;
c) общее и исключительное использование аппаратных ресурсов.
Пример - Распределение памяти, распределение регистров, таймеры, прерывания, порты ввода/вывода;
d) механизм доступа к аппаратным устройствам.
Пример - Последовательный, параллельный, ведомый, ведущий-ведомый;
e) временные ограничения, вытекающие из концепции технической безопасности.
6.4.7.3 В технических требованиях к АПИ должно быть указано о соответствующих диагностических возможностях аппаратных средств и об их реализации с помощью программного обеспечения:
a) должны быть определены диагностические возможности аппаратных средств.
Пример - Выявление перегрузки по току, короткого замыкания или перегрева;
b) должны быть определены диагностические возможности аппаратных средств, реализуемые в программном обеспечении.
6.4.7.4 АПИ должен быть определен во время проектирования архитектуры системы.
Примечание - АПИ уточняется при разработке аппаратного обеспечения (см. раздел 6 ИСО 26262-5) и программного обеспечения (см. раздел 6 ИСО 26262-6).
6.4.8 Производство, эксплуатация, обслуживание и вывод из эксплуатации
6.4.8.1 Должны быть определены рассматриваемые в ИСО 26262-7 требования к производству, эксплуатации, обслуживанию и выводу из эксплуатации, полученные в ходе проектирования архитектуры системы. Они включают:
a) меры, необходимые для выполнения технической поддержки или восстановления связанных с безопасностью функций и свойств устройства и его элементов во время производства, обслуживания или вывода из эксплуатации;
b) специальные характеристики, связанные с безопасностью;
c) требования, обеспечивающие надлежащую идентификацию систем или элементов;
d) меры по верификации производства;
e) требования к обслуживанию, включая диагностические данные и указания по обслуживанию;
f) меры по выводу из эксплуатации.
Пример - Руководства по монтажу и демонтажу, указания по обслуживанию, инструкции по допуску к ремонту элементов системы, инструкции по выводу из эксплуатации, маркировка элементов.
Примечание - Существует два аспекта, которые обеспечивают безопасность при производстве, эксплуатации, обслуживании, ремонте и выводе из эксплуатации. Первый аспект связан с действиями на стадии разработки, которые обеспечивают надлежащую архитектуру системы и определение соответствующих специальных характеристик, связанных с безопасностью, и изложены в требованиях 6.4.8; второй аспект - с действиями, которые способствуют достижению или технической поддержке функциональной безопасности на этапе производства и эксплуатации (например, на основе конкретных заданных характеристик безопасности), которые рассматриваются в ИСО 26262-7.
6.4.8.2 Диагностические возможности должны быть определены в соответствии с разделом 7 ИСО 26262-2 и с учетом результатов анализа безопасности и реализованных механизмов безопасности для предоставления необходимых данных, позволяющих в процессе эксплуатации осуществлять контроль устройства или его элементов.
6.4.8.3 Для восстановления или технической поддержки функциональной безопасности должны быть определены диагностические возможности, позволяющие во время обслуживания проверять способность выявления сбоев и эффективность технической поддержи или ремонта.
6.4.9 Верификация
6.4.9.1 Требования технической безопасности должны быть верифицированы в соответствии с требованиями разделов 6 и 9 ИСО 26262-8 для того, чтобы предоставить доказательства их корректности, полноты и согласованности относительно заданных граничных условий системы.
6.4.9.2 Архитектура системы, технические требования к АПИ и технические требования к производству, эксплуатации, обслуживанию и выводу из эксплуатации, а также концепция технической безопасности должны быть верифицированы, используя методы верификации, перечисленные в таблице 2, для подтверждения достижения следующих целей:
a) данные характеристики системы применимы и адекватны для достижения требуемого уровня функциональной безопасности с соответствующим УПБТС;
b) существует согласованность архитектуры системы с концепцией технической безопасности;
c) они валидируемы и соответствуют архитектурам системы, разработанным на предыдущих стадиях.
Примечание - О выявленных отклонениях и неполноте безопасности должно быть сообщено в соответствии с 5.4.3 ИСО 26262-2.
Таблица 2 - Верификация
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Ревизия  | + | ++ | ++ | ++ |
1b | Сквозной контроль | ++ | + | o | o |
2a | Имитационное моделирование  | + | + | ++ | ++ |
2b | Системное прототипирование и испытание транспортного средства | + | + | ++ | ++ |
3 | Анализ архитектуры системы  | См. таблицу 1 | |||
Методы 1a и 1 b служат для проверки полноты и корректности выполнения требований. Методы 2a и 2b в основном могут быть использованы в качестве испытаний с внесением дефектов для получения обоснования полноты и корректности архитектуры системы в отношении сбоев. О проведении анализа безопасности см. раздел 8 ИСО 26262-9. | |||||
6.5 Результаты работы
6.5.1 Спецификация требований технической безопасности
В результате выполнения требований 6.4.1 и 6.4.2.
6.5.2 Концепция технической безопасности
В результате выполнения требований 6.4.3-6.4.6.
6.5.3 Спецификация архитектуры системы
В результате выполнения требований 6.4.3-6.4.6.
6.5.4 Технические требования к АПИ
В результате выполнения требований 6.4.7.
6.5.5 Технические требования для производства, эксплуатации, обслуживания и вывода из эксплуатации
В результате выполнения требований 6.4.8.
6.5.6 Отчет о верификации архитектуры системы, технических требований к АПИ, технических требований для производства, эксплуатации, обслуживания и вывода из эксплуатации и концепции технической безопасности
В результате выполнения требований 6.4.9.
6.5.7 Отчет по результатам анализа безопасности
В результате выполнения требований 6.4.4.
7 Интеграция и тестирование системы и устройства
7.1 Цели
Стадия интеграции и тестирования включает в себя три этапа и три цели, описанные ниже. На первом этапе выполняется интеграция аппаратных средств и программного обеспечения каждого элемента. Второй этап заключается в интеграции элементов, составляющих систему, для формирования всего устройства. На третьем этапе выполняется интеграция устройства с другими системами в транспортном средстве. Цели настоящего раздела следующие:
a) определить последовательность действий по интеграции и интегрировать элементы системы до полной интеграции системы;
b) удостовериться в том, что определенные меры безопасности, полученные в результате анализа безопасности на уровне архитектуры системы, выполнены надлежащим образом;
c) предоставить доказательства того, что элементы интегрированной системы удовлетворяют их требованиям безопасности, которые соответствуют архитектуре системы.
7.2 Общие положения
Интеграция элементов устройства осуществляется на систематической основе начиная с программно-аппаратной интеграции и верификации, затем выполняются интеграция и верификация системы, и все заканчивается интеграцией и верификацией в транспортном средстве. Указанные интеграционные испытания проводят на каждом этапе интеграции для подтверждения правильности взаимодействия интегрированных элементов.
После обоснованного завершения разработки аппаратных средств и программного обеспечения в соответствии с требованиями ИСО 26262-5 и ИСО 26262-6 в соответствии с требованиями настоящего раздела можно начинать работы по интеграции системы.
7.3 Входная информация
7.3.1 Предварительные требования
Необходима следующая информация:
- цели безопасности из отчета по анализу безопасности и оценке риска в соответствии с 6.5.1 ИСО 26262-3;
- концепция функциональной безопасности в соответствии с 7.5.1 ИСО 26262-3;
- концепция технической безопасности в соответствии с 6.5.2;
- спецификация архитектуры системы в соответствии с 6.5.3;
- технические требования к аппаратно-программному интерфейсу в соответствии с 6.5.4, 6.5.2 ИСО 26262-5 и 6.5.2 ИСО 26262-6.
7.3.2 Дополнительная информация
Может быть учтена следующая информация:
- архитектура транспортного средства (из внешнего источника);
- концепции технической безопасности других систем транспортного средства (из внешнего источника);
- отчет об анализе безопасности (см. 6.5.7).
7.4 Требования и рекомендации
7.4.1 Спецификация стратегии интеграции и тестирования
7.4.1.1 Для предоставления доказательств того, что архитектура системы соответствует требованиям функциональной и технической безопасности, необходимо выполнить работы по тестированию интеграции в соответствии с требованиями раздела 9 ИСО 26262-8, чтобы проверить:
a) корректность реализации требований функциональной и технической безопасности;
b) корректность функционирования, точность и временные параметры механизмов безопасности;
c) согласованность и корректность реализации интерфейсов;
d) уровень робастности.
7.4.1.2 Должна быть определена стратегия интеграции и тестирования, которая основана на спецификации архитектуры системы, концепции функциональной безопасности и концепции технической безопасности. Она должна быть направлена:
a) на формирование целей тестирования, обеспечивающих возможность доказательств функциональной безопасности;
b) выполнение интеграции и тестирования устройства и его элементов, вносящих вклад в концепции безопасности.
Примечание - Стратегия интеграции и тестирования охватывает элементы, которые основаны на других технологиях и вносят вклад в концепцию безопасности.
7.4.1.3 Для запуска подстадии интеграции устройства на основе стратегии интеграции и тестирования должны быть выполнены следующие действия:
a) должна быть определена стратегия интеграции и тестирования устройства для интеграции и тестирования аппаратных средств и программного обеспечения;
b) должна быть определена стратегия интеграции и тестирования устройства для включения спецификации интеграционных тестов на уровнях системы и транспортного средства. Она обеспечивает решение открытых проблем, связанных с выполнением верификаций аппаратного-программного обеспечения;
c) стратегия интеграции и тестирования устройства должна учитывать интерфейсы между системами транспортного средства (как внутренними, так и внешними по отношению к устройству) и внешней средой;
d) в рамках стратегии интеграции и тестирования устройства должен быть рассмотрен вопрос о том, интегрируются ли системы или элементы, разработанные как элементы безопасности вне контекста (SEooC), и нуждаются ли в проверке допущения, сделанные в ходе этой разработки.
Примечание - В спецификации интеграции и верификации, выполняемых на уровне интеграции аппаратных средств и программного обеспечения, а также на уровне устройства, рассматриваются интерфейс и взаимодействие между аппаратными средствами и программным обеспечением.
7.4.1.4 Если система является конфигурируемой (например, при вариативности элементов или калибровочных данных), то верификация на уровне системы или транспортного средства должна обеспечивать подтверждение соответствия требованиям безопасности для каждой конфигурации на уровне реализации или для каждой конфигурации, предназначенной для серийного производства.
Примечание - Тестирование обоснованного подмножества конфигураций может быть достаточным.
7.4.1.5 Выполнение каждого требования функциональной безопасности и технической безопасности должно быть верифицировано (если это возможно - тестированием) по крайней мере один раз при завершении подстадии интеграции.
Примечания
1 Обычной практикой является верификация требования безопасности на более высоком уровне интеграции, на котором оно определено.
2 При интеграции SEooC в систему, связанную с безопасностью, также проверяют достоверность допущений, используемых при их разработке.
3 Об аномалиях системы безопасности, выявленных в ходе тестирования интеграции, сообщается в соответствии с требованиями 5.4.3 ИСО 26262-2.
7.4.1.6 Для того чтобы сформировать соответствующую спецификацию тестовых сценариев для интеграционных тестов, тестовые сценарии должны быть получены на основе соответствующей комбинации методов, перечисленных в таблице 3, а также с учетом уровня интеграции.
Таблица 3 - Методы получения тестовых примеров для тестирования интеграции
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Анализ требований | ++ | ++ | ++ | ++ |
1b | Анализ внешних и внутренних интерфейсов | + | ++ | ++ | ++ |
1c | Генерация и анализ классов эквивалентности для интеграции аппаратных средств и программного обеспечения | + | + | ++ | ++ |
1d | Анализ граничных значений | + | + | ++ | ++ |
1e | Предугадывание ошибок на основе знаний и опыта | + | + | ++ | ++ |
1f | Анализ функциональных зависимостей | + | + | ++ | ++ |
1g | Анализ общих предельных условий, последовательностей и источников зависимых отказов, см. 7 ИСО 26262-9 | + | + | ++ | ++ |
1h | Анализ состояния внешней среды и прецедентов эксплуатации | + | ++ | ++ | ++ |
1i | Анализ опыта эксплуатации | + | ++ | ++ | ++ |
7.4.2 Интеграция и тестирование аппаратных средств и программного обеспечения
7.4.2.1 Интеграция аппаратных средств и программного обеспечения
7.4.2.1.1 При интеграции аппаратных средств, разработанных в соответствии с требованиями ИСО 26262-5, и программного обеспечения по ИСО 26262-6 должны быть использованы методы тестирования интеграции, перечисленные в таблицах 4-8.
7.4.2.1.2 Интегрированные аппаратные средства и программное обеспечение должны быть протестированы на соответствие техническим требованиям АПИ.
Примечание - Предпочтительно использовать специально созданные аппаратные средства и программное обеспечение. В случае необходимости для конкретных методов тестирования могут быть применены модифицированные аппаратные средства или программное обеспечение.
7.4.2.2 Цели и методы тестирования во время тестирования программно-аппаратных средств
7.4.2.2.1 Цели тестирования, вытекающие из требований 7.4.2.2.2-7.4.2.2.6, должны быть достигнуты путем применения адекватных методов тестирования, как указано в соответствующих таблицах.
Примечания
1 Они поддерживают выявление систематических ошибок в архитектуре системы.
2 В зависимости от реализованной функциональности, ее сложности или распределенного характера системы может быть целесообразным перенести выполнение тестирования на другие подстадии интеграции при условии надлежащего обоснования.
7.4.2.2.2 Подтверждение корректности реализации функций, связанных с безопасностью, а также подтверждение функционирования в соответствии с требованиями технической безопасности на программно-аппаратном уровне должно быть продемонстрировано с помощью методов тестирования, приведенных в таблице 4.
Таблица 4 - Корректность реализации требований технической безопасности на программно-аппаратном уровне
|
|
|
|
|
|
Методы | УПБТС | ||||
| А | В | С | D | |
1a | Тестирование на основе требований | ++ | ++ | ++ | ++ |
1b | Тестирование с внесением дефектов | + | ++ | ++ | ++ |
1c | Сравнительное тестирование | + | + | ++ | ++ |
Тестирование на основе требований как проверяет функциональные требования, так и оценивает нефункциональные характеристики. Тестирование с внесением дефектов использует специальные средства для внесения неисправностей в тестируемое средство во время его работы. Для программного обеспечения это может быть выполнено через специальный тестовый интерфейс или специально подготовленные аппаратные средства. Данный метод часто применяют для того, чтобы улучшить тестовый охват требований безопасности, так как в процессе обычной эксплуатации механизмы безопасности не вызываются. Сравнительное тестирование сопоставляет ответы тестируемого средства с реакцией имитационной модели на те же входные воздействия для выявления различий между результатами моделирования и тестируемого средства. | |||||
Примечание - Различие в трудоемкости метода 1 b из таблицы 4 и таблицы 9 объясняется величиной усилий, затрачиваемых на выполнение тестирования с внесением дефектов на уровне системы.
7.4.2.2.3 Данное требование распространяется на значения УПБТС (A), B, C и D. Корректность функционирования, точность и временные характеристики механизмов безопасности на программно-аппаратном уровне должны быть продемонстрированы с помощью методов тестирования, приведенных в таблице 5.
Таблица 5 - Корректность функционирования, точность и временные характеристики механизмов безопасности на программно-аппаратном уровне
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Сравнительное тестирование | + | + | ++ | ++ |
1b | Эксплуатационные испытания | + | ++ | ++ | ++ |
Сравнительное тестирование сопоставляет ответы тестируемого средства с реакцией имитационной модели на те же входные воздействия для выявления различий между результатами моделирования и тестируемого средства. В ходе эксплуатационных испытаний могут быть проверены рабочие характеристики (например, планирование задачи, временные характеристики, выходная мощность) для всего испытуемого объекта, а также возможности выполнения целевого управляющего программного обеспечения на аппаратных средствах. | |||||
7.4.2.2.4 Данное требование распространяется на значения УПБТС (A), B, C и D. Подтверждение согласованности и корректности реализации внешних и внутренних интерфейсов на программно-аппаратном уровне должно быть выполнено с помощью методов тестирования, приведенных в таблице 6.
Таблица 6 - Согласованность и корректность реализации внешних и внутренних интерфейсов на программно-аппаратном уровне
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование внешних интерфейсов | + | ++ | ++ | ++ |
1b | Тестирование внутренних интерфейсов | + | ++ | ++ | ++ |
1c | Проверка согласованности интерфейсов | + | ++ | ++ | ++ |
Тесты интерфейса проверяемого объекта включают в себя тесты для аналоговых и цифровых входов и выходов, тестирование граничных значений и тестирование на основе классов эквивалентности, чтобы проверить совместимость, согласованность во времени и другие заданные значения характеристик проверяемого объекта. Внутренние интерфейсы электронного блока управления (ЭБУ) могут быть проверены как с помощью статических испытаний на совместимость программного обеспечения и аппаратных средств, так и посредством динамических испытаний последовательного периферийного интерфейса, коммуникаций интегральных схем или любых других интерфейсов между элементами ЭБУ. | |||||
7.4.2.2.5 Данное требование распространяется на значения УПБТС (A), (B), C и D. Эффективность механизмов обнаружения сбоев в аппаратных средствах на аппаратно-программном уровне для определенных видов сбоев должна быть продемонстрирована с использованием методов тестирования, перечисленных в таблице 7.
Примечание - Информация о видах сбоев приведена в приложении D ИСО 26262-5.
Таблица 7 - Эффективность механизмов безопасности на аппаратно-программном уровне
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование с внесением дефектов | + | + | ++ | ++ |
1b | Тестирование с предугадыванием ошибок | + | + | ++ | ++ |
Тестирование с внесением дефектов использует специальные средства для внесения неисправностей в тестируемое средство во время его работы. Для программного обеспечения это может быть выполнено через специальный тестовый интерфейс или специально подготовленные аппаратные средства. Этот метод часто используют для того, чтобы улучшить тестовый охват требований безопасности, так как в процессе обычной эксплуатации механизмы безопасности не вызываются. Тестирование с предугадыванием ошибок основано на использовании экспертных знаний и данных, собранных в результате полученного из опыта умения предвидеть ошибки в тестируемом объекте. Затем для проверки этих ошибок проектируют набор тестов наряду с надлежащими средствами тестирования. Тестирование предполагаемых ошибок является эффективным методом, который использует испытатель, имеющий опыт работы с подобными тестируемыми объектами. | |||||
7.4.2.2.6 Данное требование распространяется на значения УПБТС (A), (B), (C) и D. Уровень робастности элементов на аппаратно-программном уровне должен быть продемонстрирован с помощью методов тестирования, приведенных в таблице 8.
Таблица 8 - Уровень робастности на аппаратно-программном уровне
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование используемых ресурсов | + | + | + | ++ |
1b | Стресс-тест | + | + | + | ++ |
Тестирование используемых ресурсов может быть выполнено статически (например, с помощью проверки размеров кода или анализа кода при прерывании для того, чтобы убедиться в том, что наихудший сценарий не приведет к использованию всех ресурсов) или динамически во время выполнения мониторинга. Стресс-тест верифицирует исправность работы тестируемого объекта в условиях высоких эксплуатационных нагрузок или повышенных требований со стороны внешней среды. Таким образом, возможны тесты при высоких нагрузках на тестируемый объект или с особыми нагрузками на интерфейс, или значениями параметров (загрузка шины, поражение электрическим током и т.д.), а также тесты с экстремальными значениями температур, влажности и механических воздействий. | |||||
7.4.3 Интеграция и тестирование системы
7.4.3.1 Интеграция системы
7.4.3.1.1 Отдельные элементы, включаемые в систему, должны быть интегрированы в соответствии с архитектурой системы и испытаны в соответствии с определенными тестами интеграции системы.
Примечание - Тесты предназначены для предоставления доказательств того, что каждый элемент корректно функционирует в системе, соответствует требованиям технической и функциональной безопасности, и для данного элемента обеспечиваются такие оптимальные условия, при которых отсутствует его непредусмотренное функционирование, что, в свою очередь, может привести к недостижению цели безопасности.
7.4.3.2 Цели тестирования и методы испытаний при тестировании системы
7.4.3.2.1 Цели тестирования, вытекающие из требований 7.4.3.2.2-7.4.3.2.5, должны быть достигнуты путем применения адекватных методов тестирования, как указано в соответствующих таблицах.
Примечания
1 Это обеспечивает выявление систематических ошибок в процессе интеграции и тестирования системы.
2 В зависимости от реализуемой функциональности, ее сложности или распределенного характера системы может быть целесообразным перенести выполнение тестирования на другие подстадии интеграции при наличии надлежащего обоснования.
7.4.3.2.2 Подтверждение корректности реализации требований технической и функциональной безопасности на уровне системы должно быть продемонстрировано с помощью методов тестирования, приведенных в таблице 9.
Таблица 9 - Корректность реализации требований технической и функциональной безопасности на уровне системы
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование на основе требований | ++ | ++ | ++ | ++ |
1b | Тестирование с внесением дефектов | + | + | ++ | ++ |
1c | Сравнительное тестирование | о | + | + | ++ |
Тестирование на основе требований означает испытание на соответствие функциональным и нефункциональным требованиям. Тестирование с внесением дефектов использует специальные средства для внесения неисправностей в тестируемое средство во время его работы. Для программного обеспечения это может быть выполнено через специальный тестовый интерфейс или специально подготовленные аппаратные средства. Данный метод часто применяют для того, чтобы улучшить тестовый охват требований безопасности, так как в процессе обычной эксплуатации механизмы безопасности не вызываются. Сравнительное тестирование сопоставляет ответы тестируемого средства с реакцией имитационной модели на те же входные воздействия для выявления различий между результатами моделирования и тестируемого средства. | |||||
7.4.3.2.3 Данное требование распространяется на значения УПБТС (A), (B), (C) и D. Корректность функционирования, точность, охват видов отказов на уровне системы и временные характеристики механизмов безопасности на уровне системы должны быть продемонстрированы с помощью методов тестирования, приведенных в таблице 10.
Таблица 10 - Корректность функционирования, точность и временные характеристики механизмов безопасности на уровне системы
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Сравнительное тестирование | о | + | + | ++ |
1b | Тестирование с внесением дефектов | + | + | ++ | ++ |
1c | Эксплуатационные испытания | о | + | + | ++ |
1d | Тестирование с предугадыванием ошибок  | + | + | ++ | ++ |
1e | Тест, полученный на основе практического опыта  | o | + | ++ | ++ |
Сравнительное тестирование сопоставляет ответы тестируемого средства с реакцией имитационной модели на те же входные воздействия для выявления различий между результатами моделирования и тестируемого средства. При демонстрации эффективности охвата вида отказов механизмами безопасности на уровне системы под тестированием на основе метода внесения дефектов понимается внесение неисправностей в тестируемый объект во время его работы. Для программного обеспечения это может быть выполнено через специальный тестовый интерфейс или специально подготовленные аппаратные средства. Данный подход применим для ограниченного набора видов сбоев, т.е. для простых сбоев, которые могут быть реально внесены на уровне системы (например, воспроизведение постоянного сбоя на контактном штырьке компонента). Для видов сбоев на уровне полупроводника (например, исправимые ошибки или постоянный сбой транзистора) метод внесения неисправностей применяют на более детальном уровне, как описано в 4.8 ИСО 26262-11. Эксплуатационные испытания могут обеспечить проверку рабочих характеристик (например, скорости движения или прочности рабочего органа, время реакции всей системы) механизмов безопасности на уровне системы. Тестирование с предугадыванием ошибок основано на использовании экспертных знаний и данных, собранных в результате полученного из опыта умения предвидеть ошибки в тестируемом объекте. Затем для проверки этих ошибок проектируют набор тестов наряду с надлежащими средствами тестирования. Тестирование предполагаемых ошибок является эффективным методом, который использует испытатель, имеющий опыт работы с подобными тестируемыми объектами. Тест, полученный на основе опыта работы и данных, собранных в процессе эксплуатации. | |||||
7.4.3.2.4 Подтверждение согласованности и корректности реализации внешних и внутренних интерфейсов на уровне системы должно быть продемонстрировано с помощью методов тестирования, приведенных в таблице 11.
Таблица 11 - Согласованность и корректность реализации внешних и внутренних интерфейсов на уровне системы
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование внешних интерфейсов | + | ++ | ++ | ++ |
1b | Тестирование внутренних интерфейсов | + | ++ | ++ | ++ |
1c | Проверка согласованности интерфейсов | + | + | ++ | ++ |
1d | Тестирование взаимодействия/коммуникации | ++ | ++ | ++ | ++ |
Тесты интерфейса системы включают в себя тесты аналоговых и цифровых входов и выходов, тесты граничных значений и тесты на основе классов эквивалентности, что позволяет полностью проверить созданные интерфейсы, совместимость, синхронизацию и другие заданные значения характеристик системы. Внутренние интерфейсы системы могут быть проверены с помощью статических испытаний (например, соответствие штепсельных разъемов), а также посредством динамических испытаний коммуникационных шин или любых других интерфейсов между элементами системы. Тестирование коммуникации и взаимодействия включает в себя тестирование связей между элементами системы, а также между тестируемой системой и другими системами транспортного средства во время его эксплуатации на соответствие функциональным и нефункциональным требованиям. | |||||
7.4.3.2.5 Уровень робастности системы должен быть продемонстрирован с помощью методов тестирования, приведенных в таблице 12.
Таблица 12 - Уровень робастности на уровне системы
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование используемых ресурсов | о | + | ++ | ++ |
1b | Стресс-тест | о | + | ++ | ++ |
1c | Тестирование на помехоустойчивость и робастность при определенных условиях внешней среды | ++ | ++ | ++ | ++ |
На уровне системы тестирование используемых ресурсов обычно проводят в условиях динамических внешних воздействий (например, используя автомобили-лаборатории или прототипы). Тестируют также потребление энергии и загрузку коммуникационной шины. Стресс-тест верифицирует исправность работы системы в условиях высоких эксплуатационных нагрузок или повышенных требований в условиях определенной окружающей среды. Таким образом, возможно проведение испытаний при высоких нагрузках на систему или с экстремальным объемом данных, вводимых пользователем, или при запросах от других систем, а также тесты с экстремальными значениями температур, влажности и механических воздействий. Тесты на помехоустойчивость и робастность при определенных условиях внешней среды являются частным случаем стресс-тестов. Они включает в себя тестирование влияния электромагнитных помех и устойчивости к электростатическим разрядам (например, см. [4]-[7]). | |||||
7.4.4 Интеграция и тестирование транспортного средства
7.4.4.1 Интеграция транспортного средства
7.4.4.1.1 Устройство должно быть интегрировано в транспортное средство и должны быть выполнены комплексные тесты транспортного средства.
Примечание - При планировании интеграции и верификации на уровне транспортного средства может быть рассмотрено предписанное функционирование транспортного средства в обычных и экстремальных режимах, а также в обычных и экстремальных условиях эксплуатации транспортного средства, но при достаточном подмножестве используемых методов тестирования интеграции (см. таблицу 3).
7.4.4.1.2 Должна быть выполнена верификация технических требований интерфейса устройства с бортовой коммуникационной сетью и бортовой сетью электропитания транспортного средства.
7.4.4.2 Цели и методы тестирования во время испытаний транспортного средства
7.4.4.2.1 Цели тестирования, полученные на основе требований 7.4.4.2.2-7.4.4.2.5, должны быть достигнуты путем применения адекватных методов тестирования, представленных в соответствующих таблицах.
Примечания
1 Это обеспечивает выявление систематических ошибок в процессе интеграции транспортного средства.
2 В зависимости от реализованной функциональности, ее сложности или распределенного характера системы может быть более целесообразным перенести выполнение тестирования на другие подстадии интеграции при условии надлежащего обоснования.
7.4.4.2.2 Корректность реализации требований функциональной безопасности на уровне транспортного средства должна быть продемонстрирована с помощью методов тестирования, приведенных в таблице 13.
Таблица 13 - Корректность реализации требований функциональной безопасности на уровне транспортного средства
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование на основе требований | ++ | ++ | ++ | ++ |
1b | Тестирование с внесением дефектов | ++ | ++ | ++ | ++ |
1c | Длительное испытание | ++ | ++ | ++ | ++ |
1d | Тестирование у заказчика в реальных условиях | ++ | ++ | ++ | ++ |
Тестирование на основе требований означает испытание на соответствие функциональным и нефункциональным требованиям. Тестирование с внесением дефектов использует специальные средства для внесения неисправностей в устройство. В устройстве это может быть выполнено через специальный тестовый интерфейс, или специально подготовленные элементы, или коммуникационные устройства. Данный метод часто применяют для того, чтобы улучшить тестовый охват требований безопасности, так как в процессе обычной эксплуатации механизмы безопасности не вызываются. Длительное испытание и тестирование у заказчика в реальных условиях похожи на тесты, полученные исходя из опыта эксплуатации, с большим объемом выборки при участии обычных пользователей в качестве испытателей, и не связаны с предшествующими заданными сценариями тестирования, но выполняются в реальных условиях во время повседневной работы. Данные тесты могут иметь ограничения, если это необходимо для обеспечения безопасности испытателей, например дополнительные меры безопасности либо отключение приводов при выполнении тестов. | |||||
7.4.4.2.3 Данное требование распространяется на значения УПБТС (A), (B), C и D. Корректность функционирования, точность и временные характеристики механизмов безопасности на уровне транспортного средства должны быть продемонстрированы с помощью методов тестирования, приведенных в таблице 14.
Таблица 14 - Корректность функционирования, точность и временные характеристики механизмов безопасности на уровне транспортного средства
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Эксплуатационные испытания | + | + | ++ | ++ |
1b | Длительное испытание | + | + | ++ | ++ |
1c | Тестирование у заказчика в реальных условиях | + | + | ++ | ++ |
1d | Тестирование с внесением дефектов | о | + | ++ | ++ |
1e | Тестирование с предугадыванием ошибок | о | + | ++ | ++ |
1f | Тест, полученный на основе практического опыта | o | + | ++ | ++ |
Эксплуатационные испытания могут проверять рабочие характеристики (например, временной интервал сбоеустойчивости на уровне транспортного средства и управляемость транспортного средства при наличии сбоев) механизмов безопасности устройства. Длительное испытание и тестирование у заказчика в реальных условиях похожи на тесты, полученные исходя из опыта эксплуатации, с большим объемом выборки при участии обычных пользователей в качестве испытателей, и не связаны с предшествующими заданными сценариями тестирования, но выполняются в реальных условиях во время повседневной работы. Данные тесты могут иметь ограничения, если это необходимо для обеспечения безопасности испытателей, например дополнительные меры безопасности либо отключение приводов при выполнении тестов. При тестировании с внесением дефектов используют специальные средства для внесения неисправностей в устройство. В устройстве это может быть выполнено через специальный тестовый интерфейс или специально подготовленные элементы, или коммуникационные устройства. Данный метод часто применяют для того, чтобы улучшить тестовый охват требований безопасности, так как в процессе обычной эксплуатации механизмы безопасности не вызываются. Тестирование с предугадыванием ошибок основано на использовании экспертных знаний и данных, собранных в результате полученного исходя из опыта умения предвидеть ошибки в тестируемом объекте. Затем для проверки этих ошибок проектируют набор тестов наряду с надлежащими средствами тестирования. Тестирование предполагаемых ошибок является эффективным методом, который применяет испытатель, имеющий опыт работы с подобными тестируемыми объектами. Тест, полученный на основе опыта работы и данных, собранных в процессе эксплуатации. | |||||
7.4.4.2.4 Данное требование распространяется на значения УПБТС (A), (B), C и D. Согласованность и корректность реализации внутренних и внешних интерфейсов в транспортном средстве должны быть продемонстрированы с помощью методов тестирования, приведенных в таблице 15.
Примечание - Внутренние интерфейсы находятся между устройствами или между системами. Внешние интерфейсы находятся между устройством и внешней средой транспортного средства.
Таблица 15 - Согласованность и корректность реализации внешних и внутренних интерфейсов на уровне транспортного средства
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование внутренних интерфейсов | + | + | ++ | ++ |
1b | Тестирование внешних интерфейсов | + | + | ++ | ++ |
1c | Тестирование взаимодействия/коммуникации | + | + | ++ | ++ |
Тесты интерфейса на уровне транспортного средства проверяют интерфейсы систем транспортного средства на совместимость. Они могут быть статическими, выполняющими подтверждение соответствия диапазону допустимых значений, паспортным данным или габаритам, а также динамическими, реализуемыми при эксплуатации транспортного средства. Тестирование коммуникации и взаимодействия включает в себя тестирование коммуникаций между системами транспортного средства во время его эксплуатации на соответствие функциональным и нефункциональным требованиям. | |||||
7.4.4.2.5 Данное требование распространяется на значения УПБТС (A), (B), C и D. Уровень робастности на уровне транспортного средства должен быть продемонстрирован с помощью методов тестирования, приведенных в таблице 16.
Таблица 16 - Уровень робастности на уровне транспортного средства
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование используемых ресурсов | + | + | ++ | ++ |
1b | Стресс-тест | + | + | ++ | ++ |
1c | Тестирование на помехоустойчивость и робастность при определенных условиях окружающей среды | + | + | ++ | ++ |
1d | Длительное испытание | + | + | ++ | ++ |
На уровне транспортного средства тестирование используемых ресурсов устройства обычно проводят в динамических условиях (например, в сетевых средах электронных блоков управления, на прототипах или комплектных транспортных средствах). Тестируют также внутренние ресурсы устройства, потребление энергии или ограничение ресурсов других систем транспортного средства. Стресс-тест верифицирует исправность работы транспортного средства в условиях высоких эксплуатационных нагрузок или повышенных требований со стороны окружающей среды. Таким образом, возможны испытания при высоких нагрузках на транспортное средство или с экстремальным объемом данных, вводимых пользователем, или запросов от других систем, а также тесты с экстремальными значениями температур, влажности и механических воздействий. Тесты на помехоустойчивость и робастность при определенных условиях внешней среды являются частным случаем стресс-тестов. Они включают в себя тестирование влияния электромагнитных помех и устойчивости к электростатическим разрядам (например, см. [4]-[7]). Длительное тестирование и тестирование у заказчика в реальных условиях похожи на тесты, полученные исходя из опыта эксплуатации, с большим объемом выборки при участии обычных пользователей в качестве испытателей, и не связаны с предшествующими заданными сценариями тестирования, но выполняются в реальных условиях во время повседневной работы. | |||||
7.5 Результаты работы
7.5.1 Стратегия интеграции и тестирования
В результате выполнения требований 7.4.1.
7.5.2 Отчет по интеграции и тестированию
В результате выполнения требований 7.4.2-7.4.4.
8 Валидация безопасности
8.1 Цели
Цели настоящего раздела заключаются в предоставлении доказательства того, что:
a) цели безопасности достигаются с помощью устройства при его интеграции в соответствующее (ие) транспортное(ые) средство(а);
b) концепция функциональной безопасности и концепция технической безопасности обеспечивают достижение функциональной безопасности устройства.
8.2 Общие положения
Целью предыдущих действий по верификации (например, при верификации проекта, анализе безопасности, тестировании и интеграции аппаратных средств, программного обеспечения и устройства) является предоставление доказательств того, что результаты каждого конкретного вида работ соответствуют заданным требованиям.
Валидация безопасности интегрированного устройства в типовом(ых) транспортном(ых) средстве(ах) призвана обеспечить доказательство пригодности его целевого использования и направлена на подтверждение адекватности мер безопасности для класса или множества транспортных средств. Валидация безопасности, выполняемая на основе экспертизы и испытаний, гарантирует, что цели безопасности будут достигнуты.
8.3 Входная информация
8.3.1 Предварительные требования
Необходима следующая информация:
- отчет о результатах анализа опасностей и оценки рисков в соответствии с 6.5.1 ИСО 26262-3;
- концепция функциональной безопасности в соответствии с 7.5.1 ИСО 26262-3.
8.3.2 Дополнительная информация
Может быть учтена следующая информация:
- концепция технической безопасности (см. 6.5.2);
- определение устройства (см. 5.5.1 ИСО 26262-3);
- отчет по результатам анализа безопасности (см. 6.5.7).
8.4 Требования и рекомендации
8.4.1 Внешняя среда валидации безопасности
8.4.1.1 Для достижения целей безопасности валидация устройства должна быть выполнена в типовых условиях на уровне транспортного средства.
Примечания
1 Такое интегрированное устройство включает при необходимости систему, программное обеспечение, аппаратные средства, элементы, основанные на других технологиях, а также внешние меры.
2 Это особенно важно для T & B, где предметом валидации безопасности могут быть различные типы базовых транспортных средств.
8.4.1.2 При определении типовых условий следует рассматривать типовые транспортные средства для конкретных марок транспортных средств и их конфигураций.
Примечание - Подходящую исходную информацию для выбора типовых транспортных средств можно найти в отчете о результатах анализа опасностей и оценки рисков (см. 6.5.1 ИСО 26262-3).
8.4.1.3 Валидация целей безопасности должна быть выполнена с учетом отклонений условий эксплуатации, влияющих на технические характеристики, которые рассмотрены при анализе опасностей и оценке риска.
8.4.2 Спецификация валидации безопасности
8.4.2.1 Должна быть определена спецификация валидации безопасности, включающая:
a) конфигурацию устройства, для которого выполняется валидация безопасности, включая его данные о калибровке в соответствии с приложением С ИСО 26262-6.
Примечание - Если полная валидация безопасности каждой конфигурации устройства не представляется возможной, то может быть выбрано их необходимое подмножество;
b) спецификацию процедур валидации безопасности, тестовые сценарии, выполняемые водителем маневры и критерии приемки;
c) оборудование и требуемые условия внешней среды.
8.4.3 Выполнение валидации безопасности
8.4.3.1 Если для валидации безопасности используют тестирование, то могут быть применены такие же требования, как это предусмотрено для верификации (см. 9.4.2 и 9.4.3 ИСО 26262-8).
8.4.3.2 Для достижения функциональной безопасности устройства, интегрированного в транспортное средство, должна быть выполнена его валидация с помощью оценки следующих аспектов:
a) управляемость.
Примечания
1 Валидация управляемости может быть выполнена, используя сценарии эксплуатации, в том числе при целевом и возможном предсказуемом неправильном использовании.
2 Одним из критериев оценки при валидации безопасности может быть достаточная управляемость в безопасном состоянии, определенная в 7.4.2.5 ИСО 26262-3;
b) эффективность внешних мер;
c) эффективность элементов, основанных на других технологиях;
d) допущения, которые, как установлено при анализе опасностей и оценке риска (см. 6.4.4.4 ИСО 26262-3), влияют на значение УПБТС и которые могут быть проверены только на окончательном варианте транспортного средства.
Пример - Если допускается, что механический компонент предотвращает или снижает конкретную опасность, возможно вызванную неисправностью Э/Э системы, то для обеспечения эффективности этого компонента по предотвращению или снижению такой опасности выполняют его валидацию на уровне транспортного средства.
8.4.3.3 Валидация безопасности на уровне транспортного средства на соответствие целям безопасности, требованиям функциональной безопасности и предполагаемому использованию должна быть выполнена согласно плану с использованием:
a) процедур валидации безопасности и тестов для каждой цели безопасности, в том числе четко определенных критериев их прохождения/непрохождения;
b) информации об области применения, которая может включать сведения о конфигурации, условиях внешней среды, ситуациях вождения, сценариях эксплуатации и т.д.
Примечание - Сценарии эксплуатации могут быть сформированы специально для того, чтобы помочь обеспечить выполнение валидации безопасности на уровне транспортного средства.
8.4.3.4 Следует применять соответствующий набор нижеперечисленных методов:
a) повторяемые тесты с заданными процедурами испытаний, тестовые сценарии и критерии прохождения/непрохождения.
Пример - Позитивные тесты функций и требований безопасности, тестирование методом "черного ящика", моделирование, испытания с предельными значениями, тестирование с внесением дефектов, испытания на выносливость, стресс-тесты, ускоренные испытания на долговечность, моделирование внешних воздействий;
b) виды анализа.
Пример - FMEA, FTA, ETA, моделирование;
c) длительные испытания, такие как вождение транспортного средства по графикам и включенные в тестирование парки автомобилей;
d) тестирование у заказчика в реальных условиях, тестирование на стенде или контрольное тестирование, экспертные комиссии;
e) экспертизы.
8.4.4 Оценка
8.4.4.1 Результаты валидации безопасности должны быть оценены для подтверждения того, что реализованные цели безопасности обеспечивают функциональную безопасность устройства.
8.5 Результаты работы
8.5.1 Спецификация валидации безопасности, включая описание внешней среды валидации безопасности
В результате выполнения требований 8.4.1 и 8.4.2.
8.5.2 Отчет о валидации безопасности
В результате выполнения требований 8.4.3 и 8.4.4.
Приложение A
(справочное)
Обзор и последовательность выполняемых работ в процессе разработки изделия на уровне системы
Таблица A.1 содержит обзор целей, предварительных требований и результатов работы стадии разработки изделия на уровне системы.
Таблица A.1 - Обзор и поток документов стадии разработки изделия на уровне системы
|
|
|
|
Раздел | Цели | Предварительные требования | Результаты работы |
5 Общие вопросы по разработке изделия на уровне системы | Целью настоящего раздела является предоставление общего описания разработки изделия на уровне системы | - | - |
6 Концепция технической безопасности | Цели настоящего раздела заключаются в следующем:
a) определить требования технической безопасности для функций, зависимостей, ограничений и свойств элементов системы и интерфейсов, необходимых для ее реализации;
b) определить требования технической безопасности для механизмов безопасности, которые должны быть реализованы в элементах системы и интерфейсах;
c) определить требования функциональной безопасности системы и ее элементов в процессах производства, эксплуатации, обслуживания и вывода из эксплуатации;
d) проверить, что требования технической безопасности обеспечивают достижение функциональной безопасности на уровне системы и соответствуют требованиям функциональной безопасности;
e) разработать архитектуру системы и концепцию технической безопасности, которые удовлетворяют требованиям безопасности и не противоречат требованиям, не связанным с безопасностью;
f) выполнить анализ архитектуры системы в целях предотвращения сбоев и определения необходимых для производства и обслуживания специальных характеристик, связанных с безопасностью;
g) проверить, что архитектура системы и концепция технической безопасности удовлетворяют требованиям безопасности с соответствующими их значениями УПБТС | Концепция функциональной безопасности (см. 7.5.1 ИСО 26262-3). Архитектура системы (исходя из внешних источников, см. 7.3.1 ИСО 26262-3).
Требования к устройству от других устройств, реализующих функции безопасности, если применимы | 6.5.1 Спецификация требований технической безопасности в результате выполнения требований 6.4.1, 6.4.2.
6.5.2 Концепция технической безопасности в результате выполнения требований 6.4.3-6.4.6.
6.5.3 Спецификация архитектуры системы в результате выполнения требований 6.4.3-6.4.6.
6.5.4 Технические требования к АПИ в результате выполнения требований 6.4.7.
6.5.5 Технические требования для производства, эксплуатации, обслуживания и вывода из эксплуатации в результате выполнения требований 6.4.8.
6.5.6 Отчет о верификации архитектуры системы, технических требований к АПИ, технических требований для производства, эксплуатации, обслуживания и вывода из эксплуатации и концепции технической безопасности в результате выполнения требований 6.4.9.
6.5.7 Отчет по результатам анализа безопасности в результате выполнения требований 6.4.4 |
7 Интеграция и тестирование системы и устройства | Цели настоящего раздела следующие:
a) определить последовательность действий по интеграции и интегрировать элементы системы до полной интеграции системы;
b) удостовериться в том, что определенные меры безопасности, полученные в результате анализа безопасности на уровне архитектуры системы, выполнены надлежащим образом;
c) предоставить доказательства того, что элементы интегрированной системы удовлетворяют их требованиям безопасности, которые соответствуют архитектуре системы | Цели безопасности из отчета по анализу безопасности и оценке риска (см.6.5.1 ИСО 26262-3).
Концепция функциональной безопасности (см. 7.5.1 ИСО 26262-3).
Концепция технической безопасности (см. 6.5.2).
Спецификация архитектуры системы (см. 6.5.3).
Технические требования к аппаратно-программному интерфейсу (см. 6.5.4) | 7.5.1 Стратегия интеграции и тестирования в результате выполнения требований 7.4.1.
7.5.2 Отчет по интеграции и тестированию в результате выполнения требований 7.4.2-7.4.4 |
8 Валидация безопасности | Цели настоящего раздела заключаются в представлении доказательства того, что:
a) цели безопасности достигаются с помощью устройства при его интеграции в соответствующее(ие) транспортное(ые) средство(а);
b) концепция функциональной безопасности и концепция технической безопасности обеспечивают достижение функциональной безопасности устройства | Отчет о результатах анализа опасностей и оценки рисков (см. 6.5.1 ИСО 26262-3). Концепция функциональной безопасности (см. 7.5.1 ИСО 26262-3) | 8.5.1 Спецификация валидации безопасности, включая описание внешней среды валидации безопасности в результате выполнения требований 8.4.1 и 8.4.2.
8.5.2 Отчет о валидации безопасности в результате выполнения требований 8.4.3 и 8.4.4 |
Приложение B
(справочное)
Пример содержания аппаратно-программного интерфейса
B.1 Общие положения
В настоящем приложении представлены дополнительные разъяснения по аппаратно-программному интерфейсу (АПИ).
Технические требования к АПИ формируются на подстадии "Концепция технической безопасности". Технические требования к АПИ постоянно уточняются в процессе разработки аппаратных средств и программного обеспечения.
На рисунке B.1 представлен обзор задач АПИ и их взаимосвязь с разработкой изделия на уровне системы, на уровне технических средств и на уровне программного обеспечения. АПИ используют для согласования технических вопросов взаимодействия при разработке аппаратных средств и программного обеспечения.
Примечание - На рисунке B.1 конкретные разделы каждой части ИСО 26262 указаны следующим образом: "m-n", где "m" представляет собой номер части ИСО 26262, а "n" указывает на номер раздела этой части, например 3-6 - это раздел 6 ИСО 26262-3.
|
 |
Рисунок B.1 - Обзор взаимодействий аппаратно-программного интерфейса
B.2 Элементы АПИ
При подготовке технических требований к АПИ могут быть рассмотрены следующие его элементы:
a) память:
1) энергозависимая память (например, ОЗУ),
2) энергонезависимая память (например, ПЗУ);
b) интерфейсы шины [например, локальная сеть контроллеров (CAN), коммутируемая локальная сеть (LIN), внутренний высокоскоростной последовательный канал (HSSL)];
c) преобразователь:
1) аналого-цифровой,
2) цифро-аналоговый,
3) широтно-импульсной модуляции;
d) мультиплексор;
e) электрический ввод/вывод;
f) защитное устройство:
1) внутреннее,
2) внешнее.
B.3 Характеристики АПИ
При подготовке технических требований к АПИ могут быть рассмотрены следующие его характеристики:
a) прерывание;
b) согласованность синхронизации;
c) целостность данных;
d) инициализация:
1) памяти и регистров,
2) управления начальной загрузкой;
e) передача сообщений:
1) отправление сообщения,
2) получение сообщения;
f) режимы сети:
1) ждущий,
2) активный;
g) управление памятью:
1) при считывании,
2) при записи,
3) при диагностике,
4) адресного пространства,
5) типов данных;
h) счетчик реального времени:
1) запуск счетчика,
2) остановка счетчика,
3) фиксация значения счетчика,
4) загрузка счетчика.
В таблице B.1 приведен пример, демонстрирующий распределение характеристик АПИ по его элементам.
Таблица B.1 - Пример входных значений внутренних сигналов
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Опи- сание | Иден- тифи- катор аппа- рат- ных сре- дств | Иден- тифи- катор прог- рам- много обес- пече- ния | Канал 1 | Канал 2 | N муль- типле- ксора - канал 1 | N муль- типле- ксора - канал 2 | Тип дан- ных аппа- ратно- прог- рам- много интер- фейса | Адре- са канала 1 | Адре- са канала 2 | Мо- дуль | Тип интер- фейса | Ком- мента- рии | Диа- пазон значе- ний | Точно- сть (% от диа- пазо- на зна- чений) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Входы |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Вход 1 | IN_1 | IN_1 | х |
| 4 |
| U16 | 0x8000 |
| V | Анало- говый внут- рен- ний | Анало- говый вход 1 | 0-5 | 0,50% |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
|
|
|
Обозначение ссылочного международного стандарта, документа | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ISO 26262-1:2018 | IDT | ГОСТ Р ИСО 26262-1-2020 "Дорожные транспортные средства. Функциональная безопасность. Часть 1. Термины и определения" |
ISO 26262-2:2018 | IDT | ГОСТ Р ИСО 26262-2-2020 "Дорожные транспортные средства. Функциональная безопасность. Часть 2. Менеджмент функциональной безопасности" |
ISO 26262-3:2018 | IDT | ГОСТ Р ИСО 26262-3-2020 "Дорожные транспортные средства. Функциональная безопасность. Часть 3. Стадия формирования концепции" |
ISO 26262-5:2018 | IDT | ГОСТ Р ИСО 26262-5-2021 "Дорожные транспортные средства. Функциональная безопасность. Часть 5. Разработка аппаратных средств изделия" |
ISO 26262-6:2018 | IDT | ГОСТ Р ИСО 26262-6-2021 "Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия" |
ISO 26262-7:2018 | - | * |
ISO 26262-8:2018 | - | * |
ISO 26262-9:2018 | - | * |
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта.
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:
- IDT - идентичные стандарты. | ||
Библиография
|
|
[1] | ISO/IEC/IEEE 15288, Systems and software engineering - System life cycle processes |
[2] | ISO/IEC/IEEE 16326, Systems and software engineering - Life cycle processes - Project management |
[3] | ISO 26262-11:2018, Road Vehicles - Functional safety - Part 11: Guideline on application of ISO 26262 on semiconductors |
[4] | ISO 11451 (all parts), Road vehicles - Vehicle test methods for electrical disturbances from narrowband radiated electromagnetic energy |
[5] | ISO 11452 (all parts), Road vehicles - Component test methods for electrical disturbances from narrowband radiated electromagnetic energy |
[6] | ISO 7637 (all parts), Road vehicles - Electrical disturbances from conduction and coupling |
[7] | ISO 10605, Road vehicles - Test methods for electrical disturbances from electrostatic discharge |
[8] | ISO 26262-12:2018, Road Vehicles - Functional safety - Part 12: Adaptation of ISO 26262 for Motorcycles |
|
|
УДК 62-783:614.8:331.454:006.354 | ОКС 13.110 |
| |
Ключевые слова: функциональная безопасность, жизненный цикл систем, транспортные средства, электрические компоненты, программируемые электронные компоненты и системы, разработка на уровне системы, анализ опасностей и оценка рисков | |