ГОСТ Р ИСО 26262-6-2014. Национальный стандарт Российской Федерации. Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия

(утв. и введен в действие Приказом Росстандарта России от 10.06.2014 № 524-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р ИСО 26262-6-2014"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-iso-26262-6-2014" "ГОСТ Р ИСО 26262-6-2014. Национальный стандарт Российской Федерации. Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного... (утв. и введен"
  n1["ГОСТ Р ИСО 26262-6-2021"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-r-iso-26262-6-2021" "ГОСТ Р ИСО 26262-6-2021. Национальный стандарт Российской Федерации. Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения издел"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ДОРОЖНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА. ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ

ЧАСТЬ 6

РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЗДЕЛИЯ

Road vehicles — Functional safety — Part 6: Product development at the software level

ISO 26262-6:2011 Road vehicles — Functional safety — Part 6: Product development at the software level (IDT)

ГОСТ Р ИСО 26262-6-2014

Предисловие

1. Подготовлен Обществом с ограниченной ответственностью «Корпоративные электронные системы» и Федеральным государственным учреждением «Консультационно-внедренческая фирма в области международной стандартизации и сертификации — „Фирма „ИНТЕРСТАНДАРТ“ на основе собственного аутентичного перевода на русский язык международного документа, указанного в пункте 4.»

2. Внесен Техническим комитетом по стандартизации ТК 58 «Функциональная безопасность».

3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии России от 10 июня 2014 г. № 524-ст.

4. Настоящий стандарт идентичен международному стандарту ИСО 26262-6:2011 «Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия» (ISO 26262-6:2011 «Road vehicles — Functional safety — Part 6: Product development at the software level»).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5).

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

5. Введен впервые.

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru).

Введение

Комплекс стандартов ИСО 26262 является адаптацией комплекса стандартов МЭК 61508 и предназначен для применения электрических и/или электронных (Э/Э) систем в дорожно-транспортных средствах.

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

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

С ростом сложности технологий, программного обеспечения и мехатронных устройств увеличиваются риски, связанные с систематическими отказами и случайными отказами оборудования. Чтобы предотвратить эти риски, комплекс стандартов ИСО 26262 включает соответствующие требования и процессы.

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

a) обеспечивает жизненный цикл систем безопасности автомобиля (менеджмент, разработку, производство, эксплуатацию, обслуживание, вывод из эксплуатации) и поддерживает адаптацию необходимых действий для выполнения этих стадий жизненного цикла;

b) обеспечивает разработанный специально для автотранспорта основанный на риске подход для определения уровней полноты безопасности [уровни полноты безопасности автомобиля (УПБА)];

c) использует значения УПБА при спецификации соответствующих требований, чтобы предотвратить неоправданный остаточный риск;

d) устанавливает требования к мерам проверки соответствия и подтверждения, которые обеспечивают достижение достаточного и приемлемого уровня безопасности;

e) устанавливает требования к взаимодействию с поставщиками.

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

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

На рисунке 1 показана общая структура комплекса ИСО 26262. В нем для различных стадий разработки изделия используется эталонная V-модель процесса. На рисунке 1:

• залитая область в виде символа «V» представляет взаимосвязь между ИСО 26262-3, ИСО 26262-4, ИСО 26262-5, ИСО 26262-6 и ИСО 26262-7;
• ссылки на конкретную информацию даны в виде: «m-n», где «m» представляет собой номер части настоящего стандарта, а «n» указывает на номер раздела этой части.

Пример - 2-6 ссылается на пункт 6 ИСО 26262-2.

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

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

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

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

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

Настоящий стандарт устанавливает требования к разработке программного обеспечения изделия для автомобильной промышленности, в том числе:

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

2. Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ИСО 26262-1:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 1. Термины и определения (ISO 26262-2:2011, Road vehicles — Functional safety — Part 1: Vocabulary)

ИСО 26262-2:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 2. Менеджмент функциональной безопасности (ISO 26262-2:2011, Road vehicles — Functional safety — Part 2: Management of functional safety)

ИСО 26262-3:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 3. Стадия формирования концепции (ISO 26262-3:2011, Road vehicles — Functional safety — Part 3: Concept phase)

ИСО 26262-4:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 4. Разработка изделия на уровне системы (ISO 26262-4:2011, Road vehicles — Functional safety — Part 4: Product development at the system level)

ИСО 26262-5:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 5. Разработка аппаратных средств изделия (ISO 26262-5:2011, Road vehicles — Functional safety — Part 5: Product development at the hardware level)

ИСО 26262-7:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 7. Производство и эксплуатация (ISO 26262-7:2011, Road vehicles — Functional safety — Part 7: Production and operation)

ИСО 26262-8:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 8. Вспомогательные процессы (ISO 26262-8:2011, Road vehicles — Functional safety — Part 8: Supporting processes)

ИСО 26262-9:2011 Дорожно-транспортные средства. Функциональная безопасность. Часть 9. Анализ уровня полноты безопасности автомобиля и анализ безопасности автомобиля (ISO 26262-9:2011, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses).

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

3. Термины, определения и сокращения

В настоящем стандарте применимы термины, определения и сокращения по ИСО 26262-1:2011.

4. Требования соответствия настоящему стандарту

4.1. Общие требования

Для соответствия настоящему стандарту должно быть выполнено каждое его требование, если для этого требования не выполняется одно из следующих условий:

a) в соответствии с настоящим стандартом предусмотрена настройка действий по обеспечению безопасности, поэтому данное требование не применяется или

b) существует обоснование того, что несоблюдение данного требования допустимо, а также показано соответствие этого обоснования настоящему стандарту.

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

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

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

4.2. Интерпретация таблиц

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

а) последовательный список методов (он обозначен порядковым номером в левой колонке, например, 1, 2, 3) или

б) альтернативный список методов (он обозначен номером с последующей буквой в левом столбце, например, 2а, 2б, 2в).

В случае последовательного списка должны применяться все методы согласно рекомендациям для соответствующего значения УПБА. Если будут применяться другие методы, отличные от перечисленных, то должно быть дано обоснование, что они удовлетворяют соответствующим требованиям.

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

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

Для каждого метода степень рекомендуемости его применения зависит от значения УПБА и классифицируется следующим образом:

• «++» означает, что метод очень рекомендуется для определенного значения УПБА;
• «+» означает, что метод рекомендуется для определенного значения УПБА;
• «О» означает, что метод не имеет рекомендации за или против его применения для определенного значения УПБА.

4.3. Требования и рекомендации, зависимые от значения УПБА

Требования или рекомендации каждого подраздела должны соблюдаться для значений УПБА A, B, C и D, если не указано иное. Эти требования и рекомендации связаны со значениями УПБА цели безопасности. Если в соответствии с требованиями раздела 5 ИСО 26262-9 декомпозиция УПБА была выполнена на более ранней стадии разработки, то значения УПБА, полученные в результате декомпозиции, должны соблюдаться.

Если в настоящем стандарте значение УПБА дается в круглых скобках, то соответствующий подпункт должен рассматриваться как рекомендация, а не требование для этого значения УПБА. Это не относится к круглым скобкам в нотации, связанной с декомпозицией УПБА.

5. Начальная подстадия разработки программного обеспечения изделия

5.1. Цель

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

5.2. Общие положения

Инициирование разработки программного обеспечения заключается в планировании деятельности по определению и формированию планов для подстадии разработки программного обеспечения и их вспомогательных процессов (см. ИСО 26262-8 и ИСО 26262-9) в зависимости от объема и сложности разработки устройства. Подстадии разработки программного обеспечения и вспомогательные процессы инициируются определением соответствующих методов, обеспечивающих выполнение требований и соответствующих значений УПБА. Методы поддерживаются руководящими указаниями и инструментальными средствами, которые определяются и планируются для каждой подстадии и вспомогательного процесса.

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

Пример - Инструментальные средства, используемые для стадий тестирования.

Планирование разработки программного обеспечения должно координироваться с разработкой изделия на уровне системы (см. ИСО 26262-4) и разработкой аппаратных средств изделия (см. ИСО 26262-5).

5.3. Входная информация

5.3.1 Предварительные требования

Необходима следующая информация:

• план проекта (уточненный) в соответствии с 5.5.1 ИСО 26262-4;
• план по обеспечению безопасности (уточненный) в соответствии с 5.5.2 ИСО 26262-4;
• техническая концепция системы безопасности в соответствии с 7.5.1 ИСО 26262-4;
• спецификация проекта системы в соответствии с 7.5.2 ИСО 26262-4;
• план интеграции и тестирования устройства (уточненный) в соответствии с 8.5.1 ИСО 26262-4.

5.3.2 Дополнительная информация

Следующая информация может быть учтена:

• доступность квалифицированных программных средств (см. раздел 11 ИСО 26262-8);
• доступность квалифицированных компонентов программного обеспечения (см. раздел 12 ИСО 26262-8);
• руководства по проектированию и кодированию для языков моделирования и программирования (из внешнего источника);
• руководства по применению методов (из внешнего источника); и
• руководящие указания по применению инструментальных средств (из внешнего источника).

5.4. Требования и рекомендации

5.4.1. Должны быть спланированы действия и определены соответствующие методы разработки программного обеспечения изделия.

5.4.2. Должна быть выполнена настройка жизненного цикла разработки программного обеспечения изделия в соответствии с требованиями 6.4.5 ИСО 26262-2, на основе базовой модели стадии, приведенной на рисунке 2.

Примечание. На рисунке конкретные разделы каждой части настоящего стандарта указаны следующим образом: «m-n», где «m» представляет собой номер части настоящего стандарта, а «n» указывает на номер ее раздела, например, 4-7 представляет раздел 7 ИСО 26262-4.

5.4.3. В случае создания конфигурируемого программного обеспечения применяется Приложение C.

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

Примечание. Последовательность стадий, задач и действий, включая итерации, для программного обеспечения устройства является гарантией обеспечения согласованности соответствующих результатов разработки аппаратных средств изделия (см. ИСО 26262-5) и результатов разработки на уровне системы (см. ИСО 26262-4).

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

a) методы и

b) соответствующие инструментальные средства.

5.4.6 Критериями выбора подходящего языка моделирования или программирования являются:

a) однозначность определения;

Пример - Синтаксиса и семантик языка.

b) поддержка встроенного программного обеспечения систем реального времени и обработка ошибок во время выполнения;

c) поддержка модульности, абстракции и структурированных конструкций.

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

Примечания

1. Выбранный язык программирования (например, ADA, C, C++, Java, Ассемблер или графический язык моделирования) поддерживает свойства, приведенные в 5.4.7. Для выполнения этих свойств могут использоваться соответствующие рекомендации по программированию или моделированию.

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

5.4.7. Для поддержки корректности разработки и реализации руководства по разработке и кодированию для моделирования или языков программирования должны рассматривать вопросы, перечисленные в таблице 1.

Примечания

1. Руководства по кодированию, как правило, различны для различных языков программирования.

2. Руководства по кодированию могут отличаться для разработки на основе модели.

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

Пример — MISRA C [3] и MISRA AC AGC [4] являются руководствами по кодированию для языка программирования C.

5.5. Результаты работы

5.5.1 План по обеспечению безопасности (уточненный)

В результате выполнения требований 5.4.1 - 5.4.7.

5.5.2 План верификации программного обеспечения

В результате выполнения требований 5.4.1 - 5.4.5 и 5.4.7.

5.5.3 Руководства по разработке и кодированию для языков моделирования и программирования

В результате выполнения требований 5.4.6 и 5.4.7.

5.5.4 Руководства по применению инструментальных средств

В результате выполнения требований 5.4.5 и 5.4.6.

6. Спецификация требований безопасности к программному обеспечению

6.1. Цели

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

Второй целью настоящего раздела является формирование подробных требований к программно-аппаратному интерфейсу, спроектированного в соответствии с требованиями раздела 7 ИСО 26262-4.

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

6.2. Общие положения

Технические требования к системе безопасности распределяются для аппаратных средств и программного обеспечения на стадии проектирования системы, представленной в разделе 7 ИСО 26262-4. Спецификация требований безопасности к программному обеспечению рассматривает ограничения аппаратных средств и влияние этих ограничений на программное обеспечение. Данная подстадия включает в себя спецификацию требований безопасности к программному обеспечению для поддержки последующих стадий проектирования.

6.3. Входная информация

6.3.1 Предварительные требования

Необходима следующая информация:

• техническая концепция системы безопасности в соответствии с 7.5.1 ИСО 26262-4;
• спецификация проекта системы в соответствии с 7.5.2 ИСО 26262-4;
• спецификация программно-аппаратного интерфейса в соответствии 7.5.3 ИСО 26262-4;
• план по обеспечению безопасности (уточненный) в соответствии с 5.5.1;
• план верификации программного обеспечения в соответствии с 5.5.2.

6.3.2 Дополнительная информация

Следующая информация может быть учтена:

• спецификация проекта аппаратных средств (см. 7.5.1 ИСО 26262-5);
• руководства по применению методов (из внешнего источника).

6.4. Требования и рекомендации

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

Пример - Функции, отказ которых может привести к нарушению требования безопасности, могут быть:

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

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

• функциями, связанными с внутренними и внешними испытаниями автомобиля;

Примечания

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

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

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

6.4.2. Спецификация требований безопасности к программному обеспечению должна быть сформирована из технической концепции системы безопасности и проекта системы в соответствии с требованиями 7.4.1 и 7.4.5 ИСО 26262-4 и должна содержать:

a) спецификацию и менеджмент требований безопасности в соответствии с разделом 6 ИСО 26262-8;

b) специфицированные конфигурации системы и аппаратных средств.

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

c) спецификацию программно-аппаратного интерфейса;

d) соответствующую требованиям спецификацию проекта аппаратных средств;

e) временные ограничения.

Пример - Время выполнения или реакции, определяемое требуемым временем отклика на уровне системы;

f) внешние интерфейсы.

Пример - Коммуникационные и пользовательские интерфейсы;

g) описание каждого режима работы транспортного средства, системы или аппаратных средств, оказывающих воздействие на программное обеспечение.

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

6.4.3. Если для требований безопасности к программному обеспечению применяется распределение УПБА, то должны соблюдаться требования раздела 5 ИСО 26262-9.

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

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

6.4.6. В соответствии с требованиями раздела 9 ИСО 26262-8 должна планироваться верификация требований безопасности к программному обеспечению и уточненной спецификации программно-аппаратного интерфейса.

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

6.4.8. Требования безопасности к программному обеспечению и требования к уточненной спецификации программно-аппаратного интерфейса должны быть верифицированы в соответствии с требованиями разделов 6 и 9 ИСО 26262-8, чтобы показать свое:

a) соответствие и согласованность с техническими требованиями системы безопасности;

b) соответствие с проектом системы;

c) согласованность с аппаратно-программным интерфейсом.

6.5. Результаты работы

6.5.1 Спецификация требований безопасности к программному обеспечению

В результате выполнения требований 6.4.1 - 6.4.3 и 6.4.5.

6.5.2 Спецификация программно-аппаратного интерфейса (уточненная)

В результате выполнения требований 6.4.4.

Примечание. Данный результат работы совпадает с результатом работы 6.5.2 ИСО 26262-5.

6.5.3 План верификации программного обеспечения (уточненный)

В результате выполнения требований 6.4.6.

6.5.4 Отчет о верификации программного обеспечения системы безопасности

В результате выполнения требований 6.4.7 и 6.4.8.

7. Проектирование архитектуры программного обеспечения

7.1. Цели

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

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

7.2. Общие положения

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

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

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

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

7.3. Входная информация

7.3.1 Предварительные требования

Необходима следующая информация:

• план обеспечения безопасности (уточненный) в соответствии с 5.5.1;
• руководства по проектированию и кодированию для языков моделирования и программирования в соответствии с 5.5.3;
• спецификация программно-аппаратного интерфейса в соответствии с требованиями 7.5.3 ИСО 26262-4;
• спецификация требований безопасности к программному обеспечению в соответствии с 6.5.1;
• план верификации программного обеспечения (уточненный) в соответствии с 6.5.3;
• отчет о верификации программного обеспечения в соответствии с 6.5.4.

7.3.2 Дополнительная информация

Следующая информация может быть учтена:

• техническая концепция системы безопасности (см. 7.5.1 ИСО 26262-4);
• спецификация проекта системы (см. 7.5.2 ИСО 26262-4);
• о доступных квалифицированных компонентах программного обеспечения (см. раздел 12 ИСО 26262-8);
• руководства по применению инструментальных средств в соответствии с 5.5.4;
• руководства по применению методов (из внешнего источника).

7.4. Требования и рекомендации

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

7.4.2 При разработке проекта архитектуры программного обеспечения необходимо рассмотреть следующее:

a) верифицируемость проекта архитектуры программного обеспечения;

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

b) пригодность программного обеспечения к конфигурируемости;

c) возможность разработки и реализации программных модулей;

d) тестируемость архитектуры программного обеспечения во время тестирования интеграции программного обеспечения;

e) удобство сопровождения проекта архитектуры программного обеспечения.

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

a) модульностью;

b) инкапсуляцией;

c) простотой.

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

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

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

a) статические аспекты проекта компонентов программного обеспечения;

Примечания

1. Статическими аспектами проекта являются:

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

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

b) динамические аспекты проекта компонентов программного обеспечения.

Примечания

1. Динамическими аспектами проекта являются:

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

2. Для определения динамических характеристик (например, задач, временных интервалов и прерываний) рассматриваются различные режимы работы (например, включение питания, останов, нормальная работа, калибровка и диагностика).

3. Для описания динамического поведения (например, задач, временных интервалов и прерываний) специфицируются коммуникационные отношения и их распределение в аппаратных средствах системы (например, процессора и каналов связи).

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

a) вновь разрабатываемый;

b) используемый повторно с модификациями или

c) используемый повторно без изменений.

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

Примечание. В этих случаях требования раздела 12 ИСО 26262-8 не применяются.

7.4.8. Связанные с безопасностью компоненты программного обеспечения, которые используются повторно без изменений, должны быть квалифицированы в соответствии с требованиями раздела 12 ИСО 26262-8.

Примечание. Использование квалифицированных компонентов программного обеспечения не влияет на применимость требований разделов 10 и 11. Тем не менее, некоторые действия, описанные в разделах 8 и 9, могут быть опущены.

7.4.9. Требования безопасности к программному обеспечению должны быть распределены для программных компонентов. В результате каждый компонент программного обеспечения должен быть разработан в соответствии с самым высоким значением УПБА среди распределенных для него требований.

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

7.4.10. Если встроенное программное обеспечение реализуется с использованием компонентов программного обеспечения с различными значениями УПБА или с использованием компонентов программного обеспечения, связанных с безопасностью и не связанных с безопасностью, то все встроенное программное обеспечение должно рассматриваться в соответствии с самым высоким значением УПБА, если программные компоненты не отвечают критериям совместимости в соответствии с требованиями раздела 6 ИСО 26262-9.

7.4.11. Если используется разделение программного обеспечения (см. Приложение D) для устранения влияния между компонентами программного обеспечения, то следует обеспечить, чтобы:

a) общие ресурсы использовались таким образом, чтобы отсутствовало влияние между разделами программного обеспечения;

Примечания

1. Задачи внутри раздела программного обеспечения не свободны от влияния со стороны друг друга.

2. Один раздел программного обеспечения не может изменить ни код или данные другого раздела программного обеспечения, ни команду неразделяемых ресурсов других разделов программного обеспечения.

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

b) разделение программного обеспечения поддерживается специальными функциями аппаратных средств или эквивалентными средствами (данное требование распространяется на значение УПБА, равное D, в соответствии с 4.3);

c) часть программного обеспечения, которая реализует разделение программного обеспечения, разрабатывается в соответствии с тем же или с более высоким значением УПБА, чем наивысшее значение УПБА, назначенное требованиями для разделов программного обеспечения;

Примечание. В общем случае операционная система предоставляет или поддерживает программы для создания разделов.

d) верификация разделения программного обеспечения в процессе интеграции и тестирования программного обеспечения (в соответствии с требованиями раздела 10) не выполняется.

7.4.12. Если при реализации требований безопасности к программному обеспечению предполагается отсутствие влияния или достаточная независимость между компонентами программного обеспечения, то анализ зависимых отказов осуществляется в соответствии с требованиями раздела 7 ИСО 26262-9.

7.4.13. На уровне архитектуры программного обеспечения в соответствии с требованиями раздела 8 ИСО 26262-9 осуществляется анализ системы безопасности для того, чтобы:

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

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

7.4.14. Для определения необходимых механизмов обеспечения безопасности программного обеспечения на уровне архитектуры программного обеспечения на основе результатов анализа безопасности в соответствии с требованиями 7.4.13 должны быть применены механизмы для обнаружения ошибок, перечисленные в таблице 4.

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

7.4.15. Данное требование распространяется на значения УПБА (A), (B), C и D в соответствии с 4.3. Для спецификации необходимых механизмов безопасности программного обеспечения на уровне архитектуры программного обеспечения на основе результатов анализа безопасности, выполненного в соответствии с требованиями 7.4.13, должны применяется механизмы для обработки ошибок, представленные в таблице 5.

Примечания

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

2. Анализ возможных опасностей архитектуры программного обеспечения из-за аппаратных средств описан в ИСО 26262-5.

7.4.16. Если в результате проектирования архитектуры программного обеспечения появились новые опасности, еще не охваченные существующей целью безопасности, то они должны быть учтены и оценены при анализе опасностей и оценке рисков в соответствии с требованиями процесса управления изменениями, представленными в разделе 8 ИСО 26262-8.

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

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

a) времени выполнения;

b) объема памяти;

Пример - Оперативная память для стеков и динамически распределяемых областей памяти, ПЗУ для программ и энергонезависимых данных.

c) коммуникационных ресурсов.

7.4.18. Проект архитектуры программного обеспечения должен быть верифицирован в соответствии с требованиями раздела 9 ИСО 26262-8 и с помощью методов верификации проекта архитектуры программного обеспечения, перечисленных в таблице 6, для демонстрации следующих свойств:

a) соответствия требованиям безопасности к программному обеспечению;

b) совместимости с целевыми аппаратными средствами;

Примечание. Они включают в себя ресурсы, указанные в 7.4.17.

c) соблюдения руководств по проектированию.

7.5. Результаты работы

7.5.1 Спецификация проекта архитектуры программного обеспечения

В результате выполнения требований 7.4.1 - 7.4.6, 7.4.9, 7.4.10, 7.4.14, 7.4.15 и 7.4.17.

7.5.2 План обеспечения безопасности (уточненный)

В результате выполнения требований 7.4.7.

7.5.3 Спецификация требований безопасности к программному обеспечению (уточненная)

В результате выполнения требований 7.4.9.

7.5.4 Отчет по анализу безопасности

В результате выполнения требований 7.4.13.

7.5.5 Отчет по анализу зависимых отказов

В результате выполнения требований 7.4.12.

7.5.6 Отчет по верификации программного обеспечения (уточненный)

В результате выполнения требований 7.4.18.

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

8.1. Цели

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

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

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

8.2. Общие положения

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

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

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

8.3. Входная информация

8.3.1 Предварительные требования

Следующая информация должна быть доступна:

• руководства по разработке и кодированию для языков моделирования и программирования в соответствии с 5.5.3;
• план верификации программного обеспечения (уточненный) в соответствии с 6.5.3;
• спецификация проекта архитектуры программного обеспечения в соответствии с 7.5.1;
• план обеспечения безопасности (уточненный) в соответствии с 7.5.2;
• спецификация требований безопасности к программному обеспечению (уточненная) в соответствии с 7.5.3;
• отчет по верификации программного обеспечения (уточненный) в соответствии с 7.5.6.

8.3.2 Дополнительная информация

Следующая информация может быть учтена:

• техническая концепция системы безопасности (см. 7.5.1 ИСО 26262-4);
• спецификация проекта системы (см. 7.5.2 ИСО 26262-4);
• руководства по применению инструментальных средств в соответствии с 5.5.4;
• спецификация программно-аппаратного интерфейса (уточненная) (см. 6.5.2);
• отчет по анализу безопасности в соответствии с 7.5.4;
• руководства по применению методов (из внешнего источника).

8.4. Требования и рекомендации

8.4.1. Требования настоящего подраздела должны соблюдаться, если модуль программного обеспечения связан с безопасностью.

Примечание. «Связанный с безопасностью» означает, что модуль реализует требования безопасности или что критерии совместимости (см. раздел 6 ИСО 26262-9) этого модуля с другими модулями не выполнены.

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

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

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

Пример - Внутреннее проектирование может включать в себя ограничения на использование регистров и запоминающего устройства.

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

a) корректного порядка выполнения подпрограмм и функций внутри программных модулей, основанных на проекте архитектуры программного обеспечения;

b) согласованности интерфейсов между модулями программного обеспечения;

c) корректности потока данных и управления между и внутри программных модулей;

d) простоте;

e) читаемости и понимаемости;

f) надежности.

Пример - Методы предотвращения недостоверных значений, ошибок исполнения, деления на ноль и ошибок потока данных и потока управления;

g) пригодности программного обеспечения для модификации;

h) тестируемости.

Примечание. MISRA C (для языка C) [3] включает многие из методов, перечисленных в таблице 8.

8.4.5. Разработка и реализация модуля программного обеспечения должны быть верифицированы в соответствии с требованиями раздела 9 ИСО 26262-8, применяя методы верификации, приведенные в таблице 9, чтобы продемонстрировать:

a) соответствие со спецификацией программно-аппаратного интерфейса (в соответствии с требованиями 6.4.10 ИСО 26262-5);

b) выполнение требований безопасности к программному обеспечению при их распределении модулям программного обеспечения (в соответствии с требованиями 7.4.9), используя прослеживание;

c) соответствие исходного кода его проектной спецификации;

Примечание. В случае разработки на основе модели требование перечисления c) все еще применяется.

d) соответствие исходного кода принципам кодирования (см. 5.5.3);

e) совместимость реализации модуля программного обеспечения с целевыми аппаратными средствами.

Примечание. В таблице 9 перечислены только статические методы верификации. Динамические методы верификации (например, методы тестирования) рассмотрены в таблицах 10 - 12.

8.5. Результаты работы

8.5.1 Спецификация проекта модулей программного обеспечения

В результате выполнения требований 8.4.2 - 8.4.4.

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

8.5.2 Реализация модулей программного обеспечения

В результате выполнения требований 8.4.4.

8.5.3 Отчет о верификации программного обеспечения (уточненный)

В результате выполнения требований 8.4.5.

9. Тестирование модуля программного обеспечения

9.1. Цель

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

9.2. Общие положения

Спецификация проекта модуля программного обеспечения устанавливает для него процедуру тестирования, и испытания модуля программного обеспечения проводятся в соответствии с этой процедурой.

9.3. Входная информация

9.3.1 Предварительные требования

Следующая информация должна быть доступна:

• спецификация программно-аппаратного интерфейса (уточненная) в соответствии с 6.5.2;
• план верификации программного обеспечения (уточненный) в соответствии с 7.5.2;
• спецификация проекта модуля программного обеспечения в соответствии с 8.5.1;
• реализация модуля программного обеспечения в соответствии с 8.5.2;
• отчет о верификации программного обеспечения (уточненный) в соответствии с 8.5.3.

9.3.2 Дополнительная информация

Следующая информация может быть учтена:

• руководства по применению инструментальных средств в соответствии с 5.5.4;
• руководства по применению методов (из внешнего источника).

9.4. Требования и рекомендации

9.4.1. Требования настоящего подраздела должны соблюдаться, если модуль программного обеспечения связан с безопасностью.

Примечание. «Связанный с безопасностью» означает, что модуль реализует требования безопасности или что критерии совместимости этого модуля с другими модулями не выполнены.

9.4.2. Тестирование модуля программного обеспечения должно быть спланировано, специфицировано и выполнено в соответствии с требованиями раздела 9 ИСО 26262-8.

Примечания

1. В соответствии с определениями раздела 9 ИСО 26262-8 объектами испытаний при тестировании модуля программного обеспечения являются программные модули.

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

9.4.3. Должны применяться методы тестирования модулей программного обеспечения, перечисленные в таблице 10, чтобы продемонстрировать, что модуль программного обеспечения достигает:

a) соответствия со спецификацией проекта модуля программного обеспечения (в соответствии с требованиями раздела 8);

b) соответствия спецификации программно-аппаратного интерфейса (в соответствии с требованиями 6.4.10 ИСО 26262-5);

c) заданную функциональность;

d) уверенность в отсутствии непреднамеренной функциональности;

e) надежность.

Пример - Отсутствие недостижимого программного обеспечения, эффективность механизмов обнаружения и обработки ошибок;

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

9.4.4. Для получения подходящих тестов для тестирования модуля программного обеспечения в соответствии с требованиями 9.4.3 должны быть использованы методы, перечисленные в таблице 11.

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

Примеры

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

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

Примечания

1. Структурное покрытие может быть определено путем использования соответствующих программных инструментальных средств.

2. В случае разработки на основе модели анализ структурного покрытия может быть выполнен на уровне модели с использованием аналогичных метрик структурного покрытия для моделей.

3. Если для определения степени покрытия используется код измерительного средства, то, может быть, необходимо показать, что измерительные средства никак не влияют на результаты испытаний. Это может быть сделано путем повторения испытаний без кода измерительного средства.

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

Примечания

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

2. В зависимости от объема тестов для выполнения модуля программного обеспечения используется соответствующая тестовая среда (например, целевой процессор, процессор эмулятор или разрабатываемая система).

3. Тестирование модуля программного обеспечения может быть выполнено в различных средах, например:

• тестирование с моделью в контуре обратной связи;
• тестирование с программой в контуре обратной связи;
• тестирование с процессором в контуре обратной связи;
• программно-аппаратное тестирование.

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

9.5. Результаты работы

9.5.1 План верификации программного обеспечения (уточненный)

В результате выполнения требований 9.4.2 - 9.4.6.

9.5.2 Спецификация верификации программного обеспечения

В результате выполнения требований 9.4.2 и 9.4.4 - 9.4.6.

9.5.3 Отчет о верификации программного обеспечения (уточненный)

В результате выполнения требований 9.4.2.

10. Интеграция и тестирование программного обеспечения

10.1. Цели

Первая цель данной подстадии состоит в обеспечении интеграции элементов программного обеспечения.

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

10.2. Общие положения

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

Встроенное программное обеспечение может состоять из связанных и не связанных с безопасностью элементов программного обеспечения.

10.3. Входная информация

10.3.1 Предварительные требования

Следующая информация должна быть доступна:

• спецификация программно-аппаратного интерфейса (уточненная) в соответствии с 6.5.2;
• спецификация проекта архитектуры программного обеспечения в соответствии с 7.5.1;
• план по обеспечению безопасности (уточненный) в соответствии с 7.5.2;
• реализация модуля программного обеспечения в соответствии с 8.5.2;
• план верификации программного обеспечения (уточненный) в соответствии с 9.5.1;
• спецификация верификации программного обеспечения в соответствии с 9.5.2;
• отчет о верификации программного обеспечения (уточненный) в соответствии с 9.5.3.

10.3.2 Дополнительная информация

Следующая информация может быть учтена:

• о доступных квалифицированных компонентах программного обеспечения (см. раздел 12 ИСО 26262-8);
• отчет о квалификации инструментального программного обеспечения в соответствии с 11.5.2 ИСО 26262-8;
• руководства по применению инструментальных средств в соответствии с 5.5.4;
• руководства по применению методов (из внешнего источника).

10.4. Требования и рекомендации

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

a) функциональные зависимости, которые важны для интеграции программного обеспечения, а также

b) зависимости между интеграцией программного обеспечения и программно-аппаратной интеграцией.

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

10.4.2. Тестирование интеграции программного обеспечения должно быть спланировано, специфицировано и выполнено в соответствии с требованиями раздела 9 ИСО 26262-8.

Примечания

1. На основании определений раздела 9 ИСО 26262-8 объектами испытаний интеграции программного обеспечения являются компоненты программного обеспечения.

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

10.4.3. Должны применяться методы тестирования интеграции программного обеспечения, приведенные в таблице 13, чтобы продемонстрировать, что как компоненты программного обеспечения, так и встроенное программное обеспечение достигают:

a) соответствия с проектом архитектуры программного обеспечения в соответствии с требованиями раздела 7;

b) соответствия со спецификацией программно-аппаратного интерфейса в соответствии с требованиями раздела 7 ИСО 26262;

c) заданной функциональности;

d) надежности.

Пример - Отсутствие недостижимого программного обеспечения; эффективность обнаружения и обработки ошибок;

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

10.4.4. Для получения подходящих тестов для методов тестирования интеграции программного обеспечения в соответствии с требованиями 10.4.3 должны быть использованы методы, перечисленные в таблице 14.

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

10.4.6. Данное требование распространяется на значения УПБА (A), (B), C и D в соответствии с 4.3. Для оценки полноты тестов и получения уверенности в том, что непреднамеренная функциональность отсутствует, должно быть измерено структурное покрытие в соответствии с метриками, перечисленными в таблице 15. Если достигнутое структурное покрытие считается недостаточным, то либо должны быть специфицированы дополнительные тесты, либо должно быть предусмотрено обоснование.

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

10.4.7. Необходимо убедиться, что встроенное программное обеспечение, которое должно быть включено как часть выпускаемых изделий в соответствии с требованиями раздела 11 ИСО 26262-4, содержит все специфицированные функции и содержит только такие неспецифицированные функции, которые не влияют на соответствие требованиям безопасности к программному обеспечению.

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

Примечание. Если может быть обеспечена дезактивация таких неспецифицированных функций, то это является приемлемым способом соответствия данному требованию. В противном случае удаление такого кода является изменением (см. раздел 8 ИСО 26262-8).

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

Примечания

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

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

3. Тестирование интеграции программного обеспечения может быть выполнено в различных средах, например:

• тестирование с моделью в контуре обратной связи;
• тестирование с программой в контуре обратной связи;
• тестирование с процессором в контуре обратной связи;
• программно-аппаратное тестирование.

10.5. Результаты работы

10.5.1 План верификации программного обеспечения (уточненный)

В результате выполнения требований 10.4.1 - 10.4.6 и 10.4.8.

10.5.2 Спецификация верификации программного обеспечения (уточненная)

В результате выполнения требований 10.4.1, 10.4.2, 10.4.4, 10.4.5, 10.4.7 и 10.4.8.

10.5.3 Встроенное программное обеспечение

В результате выполнения требований 10.4.1.

10.5.4 Отчет о верификации программного обеспечения (уточненный)

В результате выполнения требований 10.4.2.

11. Верификация требований безопасности к программному обеспечению

11.1. Цель

Цель данной подстадии — продемонстрировать, что встроенное программное обеспечение отвечает требованиям безопасности к программному обеспечению.

11.2. Общие положения

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

11.3. Входная информация

11.3.1 Предварительные требования

Следующая информация должна быть доступна:

• спецификация проекта архитектуры программного обеспечения в соответствии с 7.5.1;
• план по обеспечению безопасности (уточненный) в соответствии с 7.5.2;
• спецификация требований к программному обеспечению системы безопасности (уточненная) в соответствии с 7.5.3;
• план верификации программного обеспечения (уточненный) в соответствии с 10.5.1;

11.3.2 Дополнительная информация

Следующая информация может быть учтена:

• план подтверждения соответствия (уточненный) (см. 6.5.3 ИСО 26262-4);
• техническая концепция системы безопасности (см. 7.5.1 ИСО 26262-4);
• спецификация проекта системы (см. 7.5.2 ИСО 26262-4);
• руководства по применению инструментальных средств в соответствии с 5.5.4;
• руководства по применению методов (из внешнего источника).

11.4. Требования и рекомендации

11.4.1. Верификация требований безопасности к программному обеспечению должна быть спланирована, специфицирована и выполнена в соответствии с требованиями раздела 9 ИСО 26262-8.

11.4.2. Чтобы убедиться, что встроенное программное обеспечение отвечает требованиям безопасности к программному обеспечению, должны быть проведены испытания в тестовых средах, перечисленных в таблице 16.

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

Таблица 16

Тестовые среды для выполнения верификации требований безопасности к программному обеспечению

11.4.4 Результаты верификации требований безопасности к программному обеспечению системы должны быть оценены на:

11.5. Результаты работы

11.5.1 План верификации программного обеспечения (уточненный)

11.5.2 Спецификация верификации программного обеспечения (уточненная)

11.5.3 Отчет о верификации программного обеспечения (уточненный)

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

Таблица A.1

Обзор разработки программного обеспечения изделия

Приложение B (справочное)

РАЗРАБОТКА НА ОСНОВЕ МОДЕЛИ

B.1. Цели

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

B.2. Общие положения

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

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

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

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

Конфигурируемое программное обеспечение позволяет разработку конкретного прикладного программного обеспечения с использованием данных о конфигурации и калибровки (см. рисунок C.1).

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

C.3.2. Дополнительная информация

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

C.4. Требования и рекомендации

C.4.1. Должны быть специфицированы данные о конфигурации, чтобы обеспечить правильное использование конфигурируемого программного обеспечения в процессе жизненного цикла систем безопасности. Оно должно включать:

a) допустимые значения данных о конфигурации;

b) цель и использование данных о конфигурации;

c) диапазон, масштаб, единицы измерения;

d) взаимозависимость между различными элементами данных о конфигурации.

C.4.2. Должна быть выполнена верификация данных о конфигурации, чтобы обеспечить:

a) использование значений в заданном для них диапазоне;

b) совместимость с другими данными о конфигурации.

Примечание. Тестирование конфигурируемого программного обеспечения осуществляется на стадиях тестирования жизненного цикла программного обеспечения (см. разделы 9 «Тестирование модулей программного обеспечения», 10 «Интеграция и тестирование программного обеспечения», 11 «Верификация требований безопасности к программному обеспечению» и раздел 8 ИСО 26262-4 «Интеграция и тестирование устройства»).

C.4.3. Значение УПБА данных о конфигурации должно быть равно наибольшему значению УПБА конфигурируемого программного обеспечения, в котором эти данные используются.

C.4.4. Верификация конфигурируемого программного обеспечения должна планироваться, задаваться и выполняться в соответствии с требованиями раздела 9 ИСО 26262-8. Конфигурируемое программное обеспечение должно быть верифицировано на соответствие набору данных о конфигурации, которые должны быть применены для разрабатываемого устройства.

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

C.4.5. Для конфигурируемого программного обеспечения может быть применен упрощенный жизненный цикл программного обеспечения системы безопасности в соответствии с рисунками C.2 или C.3.

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

a) «верификация конфигурируемого программного обеспечения»,

b) «верификация данных о конфигурации»,

c) «верификация сконфигурированного программного обеспечения».

C.4.8. Значение УПБА данных о калибровке должно быть равно наибольшему значению УПБА требований безопасности к программному обеспечению, которое может быть нарушено этими данными.

C.4.9. Для обнаружения непреднамеренных изменений связанных с безопасностью данных о калибровке должны применяться механизмы для обнаружения непреднамеренных изменений данных, указанные в таблице C.1.

C.4.10. При планировании получения и применения данных о калибровке должны быть специфицированы:

a) процедуры, которые должны соблюдаться;

b) инструментальные средства для создания калибровочных данных;

c) процедуры верификации данных о калибровке.

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

C.5. Результаты работы

C.5.1. Спецификация данных о конфигурации

В результате выполнения требований C.4.1 и C.4.3.

C.5.2. Спецификация данных о калибровке

В результате выполнения требований C.4.2, C.4.4, C.4.7 и C.4.10.

C.5.7. Спецификация верификации

В результате выполнения требований C.4.4 и C.4.7.

C.5.8. Отчет о верификации

В результате выполнения требований C.4.1, C.4.4, C.4.7 и C.4.8.

Приложение D (справочное)

ОТСУТСТВИЕ ВЗАИМНОГО ВЛИЯНИЯ МЕЖДУ ЭЛЕМЕНТАМИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

D.1. Цели

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

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

D.2. Общие положения

D.2.1. Достижение отсутствия взаимного влияния

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

D.2.2. Временная согласованность и выполнение

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

• блокирование выполнения;
• тупики;
• динамические взаимоблокировки;
• неправильное распределение времени выполнения;
• неправильная синхронизация между элементами программного обеспечения.

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

D.2.3. Память

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

• повреждение содержания памяти;
• доступ к памяти по чтению или записи, выделенной для другого элемента программного обеспечения.

Пример - Могут быть использованы такие механизмы, как: защита памяти, биты четности, код с исправлением ошибок (ECC), контроль циклическим избыточным кодом (CRC), резервное хранение, ограниченный доступ к памяти, статический анализ доступа к памяти программного обеспечения и статическое распределение.

D.2.4. Обмен информацией

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

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

БИБЛИОГРАФИЯ