ГОСТ Р ИСО 26262-6-2021
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ДОРОЖНЫЕ ТРАНСПОРТНЫЕ СРЕДСТВА. ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ
Часть 6
Разработка программного обеспечения изделия
Road vehicles. Functional safety. Part 6. Product development at the software level
ОКС 13.110
Дата введения 2022-06-01
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Российский институт стандартизации" (ФГБУ "РСТ") совместно с Обществом с ограниченной ответственностью "ЭОС Тех" (ООО "ЭОС Тех") и Обществом с ограниченной ответственностью "Корпоративные электронные системы" (ООО "КЭЛС-центр") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 058 "Функциональная безопасность"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 25 октября 2021 г. N 1279-ст
4 Настоящий стандарт идентичен международному стандарту ИСО 26262-6:2018* "Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия" (ISO 26262-6:2018 "Road vehicles - Functional safety - Part 6: Product development at the software level", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВЗАМЕН ГОСТ Р ИСО 26262-6-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-4:2018, Road vehicles - Functional safety - Part 4: Product development at the system level (Дорожные транспортные средства. Функциональная безопасность. Часть 4. Разработка изделия на уровне системы)
ISO 26262-5:2018, Road vehicles - Functional safety - Part 5: Product development at the hardware level (Дорожные транспортные средства. Функциональная безопасность. Часть 5. Разработка изделия на уровне аппаратных средств)
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.
ИСО и МЭК для применения в стандартизации поддерживают терминологические базы данных:
- Электропедия МЭК; доступна по адресу: //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, определены в части 12.
4.6 Адаптация к грузовым транспортным средствам, автобусам, прицепам и полуприцепам
Содержание, которое предназначено для спецификации грузовых автомобилей, автобусов, прицепов и полуприцепов, обозначается как (T&B).
5 Общие вопросы по разработке изделия на уровне программного обеспечения
5.1 Цели
Цели данного раздела заключаются в следующем:
a) обеспечить надлежащий и последовательный процесс разработки программного обеспечения;
b) обеспечить надлежащую среду разработки программного обеспечения.
5.2 Общие положения
Базовая модель стадии разработки программного обеспечения представлена на рисунке 2. Подробная информация о работе с конфигурируемым программным обеспечением приведена в приложении C.
|
 |
Примечание - На рисунке конкретные разделы каждой части настоящего стандарта указаны следующим образом: "m-n", где "m" представляет собой номер части настоящего стандарта, а "n" указывает на номер ее раздела; например, 4-7 представляет раздел 7 ИСО 26262-4.
Рисунок 2 - Базовая модель стадии разработки изделия на уровне программного обеспечения (ПО)
Примечания
1 Для разработки программного обеспечения, связанного с безопасностью, могут также использоваться подходы или методы гибкой разработки программного обеспечения, но в таком случае деятельность по обеспечению безопасности корректируется в соответствии с 6.4.5 ИСО 26262-2. Однако гибкие подходы и методы не исключают использование мер безопасности и строго следуют базовой документации, процессу или значению полноты безопасности, которые необходимы для обеспечения функциональной безопасности.
Примеры
1 Для улучшения качества и тестируемости требований может быть использован метод "Разработка через тестирование".
2 Согласованность подстадий и упрощение выполнения регрессионных тестов может обеспечить непрерывная интеграция на основе автоматической системы сборки программ. Такая система обычно выполняет генерацию, компиляцию и редактирование связей кода, статический анализ кода, генерацию документации, тестирование и создание инсталляционного пакета программ. Она позволяет, в зависимости от состава и конфигурации инструментальных средств, осуществлять воспроизводимую и, при внесении изменений, пригодную для сравнений разработку программного обеспечения, документации и результатов тестирования.
2 При разработке встроенного программного обеспечения конкретного устройства также может быть учтена кибербезопасность, см. 5.4.2.3 ИСО 26262-2. Для того, чтобы иметь возможность разрабатывать программное обеспечение, в настоящем разделе рассматриваются конкретные вопросы, касающиеся используемых языков моделирования, проектирования и/или программирования, а также вопросы применения руководств и инструментальных средств.
3 Инструментальные средства, используемые для разработки программного обеспечения, могут включать в себя инструментальные средства, отличные от программных инструментальных средств.
Пример - Инструментальные средства, используемые для стадий тестирования.
5.3 Входная информация
5.3.1 Предварительные требования
Необходима следующая информация:
- (не задается).
5.3.2 Дополнительная информация
Может быть учтена следующая информация:
- доступность квалифицированных программных средств (см. раздел 11 ИСО 26262-8);
- руководства по проектированию и кодированию для языков моделирования и программирования (из внешнего источника);
- руководства по применению методов (из внешнего источника);
- руководящие указания по применению инструментальных средств (из внешнего источника).
5.4 Требования и рекомендации
5.4.1 При разработке программного обеспечения устройства необходимо использовать процессы и среды разработки программного обеспечения, которые:
a) пригодны для разработки встроенного программного обеспечения, связанного с безопасностью, включая методы, руководства, языки и инструментальные средства;
b) обеспечивают согласованность всех подстадий жизненного цикла разработки программного обеспечения и соответствующих результатов их работы;
c) совместимы со стадиями разработки системы и аппаратных средств для требуемого взаимодействия и согласованности при обмене информацией.
Примечания
1 Последовательность стадий, задач и действий, включая итерацию, для программного обеспечения устройства призваны обеспечить согласованность соответствующих результатов работы с разработкой изделия на уровне аппаратных средств (см. ИСО 26262-5) и разработкой изделия на уровне системы (см. ИСО 26262-4).
2 Основой для использования инструментального программного обеспечения может служить отчет об оценке критериев использования инструментального программного обеспечения (см. 11.5.1 ИСО 26262-8) или отчет о квалификации инструментального программного обеспечения (см. 11.5.2 ИСО 26262-8).
5.4.2 При выборе языка проектирования, моделирования или программирования должны учитываться следующие критерии:
a) однозначное и полностью исчерпывающее определение.
Пример - Однозначное определение синтаксиса и семантики или ограничения конфигурации среды разработки;
b) пригодность для определения и управления требованиями безопасности в соответствии с разделом 6 ИСО 26262-8, если для разработки и управления требованиями используется моделирование;
c) обеспечение модульности, абстракции и инкапсуляции;
d) обеспечение использования структурированных конструкций.
Примечание - Для тех частей программного обеспечения, где использование языков программирования высокого уровня нецелесообразно, таких как низкоуровневое программное обеспечение интерфейсов с техническими средствами, обработчики прерываний или критические по времени алгоритмы, могут быть использованы языки ассемблера. Однако использование языков ассемблера может потребовать надлежащего применения или корректировки всех стадий разработки программного обеспечения (например, см. требования раздела 8).
5.4.3 Критерии выбора языков моделирования, проектирования или программирования (см. 5.4.2), которые в достаточной степени не рассматриваются в самом языке, должны быть обеспечены соответствующими руководствами или средой разработки с учетом вопросов, перечисленных в таблице 1.
Примеры
1 MISRA С [3] представляет собой руководство по кодированию для языка программирования C и включает в себя руководство для автоматической генерации кода.
2 При разработке на основе модели с автоматической генерацией кода руководства могут применяться как на уровне модели, так и на уровне кода. Могут быть рассмотрены соответствующие инструкции по стилю моделирования, в том числе серии MISRA AC. Также допускается использовать руководства по стилю для коммерческих инструментальных средств.
Примечание - Существующие руководства по кодированию и руководства по моделированию могут быть скорректированы для разработки конкретного устройства.
Таблица 1 - Вопросы, которые должны быть рассмотрены в руководствах по моделированию и кодированию
|
|
|
|
|
|
Свойства | УПБТС | ||||
| A | B | C | D | |
1a | Применение низкой сложности  | ++ | ++ | ++ | ++ |
1b | Использование подмножеств языков  | ++ | ++ | ++ | ++ |
1c | Применение строгой типизации  | ++ | ++ | ++ | ++ |
1d | Использование методов безопасного программирования  | + | + | ++ | ++ |
1e | Использование проверенных принципов проектирования  | + | + | ++ | ++ |
1f | Использование однозначного графического представления | + | ++ | ++ | ++ |
1g | Использование правил оформления | + | ++ | ++ | ++ |
1h | Использование соглашений об именовании | ++ | ++ | ++ | ++ |
1i | Аспекты параллельного выполнения  | + | + | + | + |
Применение этого метода может потребовать нахождения компромисса с другими требованиями настоящего стандарта. Целями метода 1b являются: - исключение неоднозначно определенных конструкций языка, которые могут быть по-разному интерпретированы различными разработчиками моделей, программистами, генераторами кодов или компиляторами;
- исключение конструкций языка, которые, как показывает опыт, легко приводят к ошибкам, например присваивание в условиях или идентичность имен локальных и глобальных переменных;
- исключение конструкций языка, которые могут привести к необрабатываемым ошибкам во время выполнения.
Цель метода 1c состоит в наложении принципов строгой типизации там, где они не присущи языку. Примеры методов защиты реализации: - проверка делителя перед операцией деления (отличен от нуля или находится в конкретном диапазоне);
- проверка идентификатора, передаваемого параметром, для верификации того, что вызов выполнен из той функции, из которой ожидается;
- использование варианта "default" в операторах "switch case" для обнаружения ошибки.
Может потребоваться верификация обоснованности принятых допущений, границ и условий. Распараллеливание процессов или задач не ограничивается выполнением программного обеспечения в многоядерной или многопроцессорной среде исполнения. | |||||
5.5 Результаты работы
5.5.1 Документация на среду разработки программного обеспечения
В результате выполнения требований 5.4.1-5.4.3 и C.4.1-C.4.11.
6 Спецификация требований безопасности программного обеспечения
6.1 Цели
Цели настоящей подстадии:
a) определить или уточнить требования безопасности программного обеспечения, вытекающие из концепции технической безопасности и спецификации архитектуры системы;
b) определить связанные с безопасностью функции и свойства реализуемого программного обеспечения;
c) уточнить требования к аппаратно-программному интерфейсу разрабатываемому в соответствии с требованиями раздела 6 ИСО 26262-4;
d) удостовериться в том, что требования безопасности программного обеспечения и требования к аппаратно-программному интерфейсу пригодны для разработки программного обеспечения и соответствуют концепции технической безопасности и спецификации архитектуры системы.
6.2 Общие положения
Требования технической безопасности уточняются и распределяются для аппаратных средств и программного обеспечения на стадии проектирования архитектуры системы, представленной в разделе 6 ИСО 26262-4. Спецификация требований безопасности программного обеспечения учитывает, в частности, ограничения аппаратных средств и влияние этих ограничений на программное обеспечение. Настоящая подстадия включает в себя спецификацию требований безопасности программного обеспечения для обеспечения последующих стадий проектирования.
6.3 Входная информация
6.3.1 Предварительные требования
Необходима следующая информация:
- спецификация требований технической безопасности в соответствии с 6.5.1 ИСО 26262-4;
- концепция технической безопасности в соответствии с 6.5.2 ИСО 26262-4;
- спецификация архитектуры системы в соответствии с 6.5.3 ИСО 26262-4;
- спецификация аппаратно-программного интерфейса в соответствии с 6.5.4 ИСО 26262-4;
- документация на среду разработки программного обеспечения в соответствии с 5.5.1.
6.3.2 Дополнительная информация
Может быть учтена следующая информация:
- спецификация проекта аппаратных средств (см. 7.5.1 ИСО 26262-5);
- спецификация не связанных с безопасностью функций и свойств программного обеспечения (из внешнего источника).
6.4 Требования и рекомендации
6.4.1 Требования безопасности программного обеспечения должны быть определены с учетом необходимых функций и свойств программного обеспечения, связанных с безопасностью, отказы которого могут привести к нарушению требований технической безопасности, распределенных для программного обеспечения.
Примечания
1 Требования безопасности программного обеспечения либо определяются непосредственно из требований технической безопасности, распределенных для программного обеспечения, либо представляют собой требования к функциям и свойствам программного обеспечения, которые, если они не выполнены, могут привести к нарушению требований технической безопасности, распределенных для программного обеспечения.
Примеры
1 Связанными с безопасностью функциями программного обеспечения могут быть функции:
- обеспечивающие безопасное выполнение некоторой функции в установленном режиме;
- которые обеспечивают системе достижение или поддержание безопасного состояния или состояния со сниженной функциональностью;
- связанные с обнаружением, индикацией и ослаблением сбоев элементов аппаратного обеспечения, связанных с безопасностью;
- самотестирования или мониторинга, связанные с обнаружением, индикацией и ослаблением отказов в операционной системе, базовом программном обеспечении или в прикладном программном обеспечении;
- связанные с бортовыми и автономными испытаниями во время производства, эксплуатации, обслуживания и вывода из эксплуатации;
- позволяющие вносить изменения в программное обеспечение в процессе производства и обслуживания;
- связанные с рабочими характеристиками или критичными по времени операциями.
2 Свойства, связанные с безопасностью, включают в себя: робастность к ошибочным входным значениям, независимость или отсутствие влияния между различными выполняемыми функциями, или отказоустойчивость программного обеспечения.
2 Для определения дополнительных требований безопасности программного обеспечения или для подтверждения их выполнения допускается использовать анализ безопасности (см. 7.4.10 или 7.4.11).
6.4.2 Спецификация требований безопасности программного обеспечения должна быть сформирована из требований технической безопасности, концепции технической безопасности и архитектуры системы в соответствии с требованиями 6.4.1 и 6.4.5 ИСО 26262-4 и должна содержать:
a) спецификацию и управление требованиями безопасности в соответствии с требованиями раздела 6 ИСО 26262-8;
b) определенные конфигурации системы и аппаратных средств.
Пример - Параметры конфигурации могут включать в себя следующее: получение управления, полосу пропускания и делитель частоты системных часов;
c) спецификацию аппаратно-программного интерфейса;
d) соответствующую требованиям спецификацию проекта аппаратных средств;
e) временные ограничения.
Пример - Время выполнения или реакции, определяемое требуемым временем отклика на уровне системы;
f) внешние интерфейсы.
Пример - Коммуникационные и пользовательские интерфейсы;
g) описание каждого рабочего режима и каждого перехода между рабочими режимами транспортного средства, системы или аппаратных средств, оказывающих влияние на программное обеспечение.
Пример - Рабочие режимы включают в себя следующее: режим отключения или ожидания, установка в начальное состояние, штатный режим работы, режим ограниченной функциональности и расширенный режим для тестирования или записи в постоянное запоминающее устройство.
6.4.3 Если для требований безопасности программного обеспечения применяется декомпозиция УПБТС, то должны соблюдаться требования раздела 5 ИСО 26262-9.
6.4.4 Спецификация аппаратно-программного интерфейса, формируемая в соответствии с требованиями раздела 6 ИСО 26262-4, должна быть в достаточной степени уточнена до уровня, позволяющего обеспечить корректное управление и использование аппаратных средств программным обеспечением, и должна содержать описание каждой связанной с безопасностью зависимости между аппаратными средствами и программным обеспечением.
6.4.5 Если встроенное программное обеспечение выполняет другие функции в дополнение к тем функциям, для которых требования безопасности указаны в 6.4.1, то в соответствии с применяемой системой управления качеством должна быть определена спецификация этих функций и их свойств.
6.4.6 Уточненная спецификация аппаратно-программного интерфейса должна быть проверена совместно с лицами, ответственными за разработку системы, аппаратных средств и программного обеспечения.
6.4.7 Требования безопасности программного обеспечения и уточненные требования к спецификации аппаратно-программного интерфейса должны быть верифицированы в соответствии с требованиями разделов 6 и 9 ИСО 26262-8, чтобы показать:
a) их пригодность для разработки программного обеспечения;
b) их соответствие и согласованность с требованиями технической безопасности;
c) их соответствие с проектом системы;
d) их согласованность с аппаратно-программным интерфейсом.
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.4.7.
7 Архитектура программного обеспечения
7.1 Цели
Цели настоящей подстадии:
a) разработать архитектуру программного обеспечения, удовлетворяющую требованиям безопасности программного обеспечения и другим требованиям к программному обеспечению;
b) проверить соответствие архитектуры программного обеспечения требованиям безопасности программного обеспечения с требуемым значением УПБТС;
c) обеспечить реализацию и верификацию программного обеспечения.
7.2 Общие положения
Архитектура программного обеспечения описывает элементы архитектуры программного обеспечения и их взаимодействие в иерархической структуре. В нем описываются статические аспекты, такие как интерфейсы между компонентами программного обеспечения, а также динамические аспекты, такие как последовательности процессов и их временные характеристики.
Примечание - Архитектура программного обеспечения не всегда ограничивается одним микроконтроллером или ЭБУ. В настоящем подразделе также рассматривается архитектура программного обеспечения для каждого микроконтроллера.
Архитектура программного обеспечения должна удовлетворять как требованиям к программному обеспечению, связанным с безопасностью, так и другим требованиям к программному обеспечению. Следовательно, на рассматриваемой подстадии связанные с безопасностью и не связанные с безопасностью требования к программному обеспечению рассматриваются в рамках единого процесса разработки.
Архитектура программного обеспечения предусматривает средства для реализации как требований к программному обеспечению, так и требований безопасности программного обеспечения с предусмотренным значением УПБТС, а также средства для управления сложностью рабочего проектирования и реализации программного обеспечения.
7.3 Входная информация
7.3.1 Предварительные требования
Необходима следующая информация:
- документация на среду разработки программного обеспечения в соответствии с 5.5.1;
- спецификация (уточненная) аппаратно-программного интерфейса в соответствии с 6.5.2;
- спецификация требований безопасности программного обеспечения в соответствии с 6.5.1.
7.3.2 Дополнительная информация
Может быть учтена следующая информация:
- концепция технической безопасности (см. 6.5.2 ИСО 26262-4);
- спецификация архитектуры системы (см. 6.5.3 ИСО 26262-4);
- о доступных квалифицированных компонентах программного обеспечения (см. раздел 12 ИСО 26262-8);
- спецификация не связанных с безопасностью функций и свойств программного обеспечения и других требований к программному обеспечению в соответствии с 6.4.5 (из внешнего источника).
7.4 Требования и рекомендации
7.4.1 Во избежание систематических сбоев в архитектуре программного обеспечения и в последующей разработке архитектура программного обеспечения должна быть описана с учетом следующих характеристик, используя для этого представления архитектуры программного обеспечения, приведенные в таблице 2:
a) понятность;
b) согласованность;
c) простота;
d) верифицируемость;
e) модульность;
f) абстрактность представления.
Примечание - Абстрактность представления может быть реализована с использованием иерархических структур, схем группирования или представлений для выражения статических, динамических и связанных с развертыванием на аппаратных средствах аспектов архитектуры;
g) инкапсуляция;
h) удобство сопровождения.
Таблица 2 - Представления для архитектуры программного обеспечения
|
|
|
|
|
|
Представления | УПБТС | ||||
| A | B | C | D | |
1a | Неформальный язык | ++ | ++ | ++ | ++ |
2b | Неформальные представления | ++ | ++ | + | + |
3c | Полуформальные представления | + | + | ++ | ++ |
4d | Формальные представления | + | + | + | + |
Естественный язык может дополнять использование нотаций, например, в тех случаях, когда некоторые темы легче выражаются на естественном языке, или для объяснений и обоснований решений, представленных в нотации. Полуформальные представления могут включать в себя псевдокод или моделирование с помощью UML®, SysML®, Simulink® или Stateflow®. Примечание - UML®, SysML®, Simulink® и Stateflow® являются примерами подходящих продуктов, доступных на коммерческой основе. Эта информация приводится для удобства пользователей настоящего стандарта и не является рекомендацией ИСО для этих продуктов. | |||||
7.4.2 При разработке архитектуры программного обеспечения необходимо рассмотреть следующее:
a) верифицируемость архитектуры программного обеспечения.
Примечание - Это подразумевает двунаправленную прослеживаемость между архитектурой программного обеспечения и требованиями безопасности программного обеспечения;
b) возможность применения конфигурируемого программного обеспечения;
c) возможность разработки и реализации программных модулей;
d) тестируемость архитектуры программного обеспечения во время тестирования интеграции программного обеспечения;
e) возможность сопровождения архитектуры программного обеспечения.
7.4.3 Для предотвращения систематических сбоев архитектура программного обеспечения должна обладать следующими свойствами в случае применения принципов, перечисленных в таблице 3:
a) понятность;
b) согласованность;
c) простота;
d) верифицируемость;
e) модульность;
f) инкапсуляция;
g) удобство сопровождения.
Таблица 3 - Принципы проектирования архитектуры программного обеспечения
|
|
|
|
|
|
Принципы | УПБТС | ||||
| A | B | C | D | |
1a | Подходящая иерархическая структура программных компонентов | ++ | ++ | ++ | ++ |
1b | Ограниченный размер и сложность программных компонентов | ++ | ++ | ++ | ++ |
1c | Ограниченный размер интерфейсов | + | + | + | ++ |
1d | Высокая связность внутри каждого компонента программного обеспечения | + | ++ | ++ | ++ |
1e | Слабое взаимовлияние между программными компонентами  | + | ++ | ++ | ++ |
1f | Надлежащие свойства планирования | ++ | ++ | ++ | ++ |
1g | Ограниченное использование прерываний  | + | + | + | ++ |
1h | Подходящая пространственная изоляция программных компонентов | + | + | + | ++ |
1i | Подходящее управление разделяемыми ресурсами | ++ | ++ | ++ | ++ |
В принципах 1b, 1c, 1e и 1g слово "ограниченный" означает минимальный по сравнению с влиянием других аспектов проекта. Принципы 1d и 1e, например, могут быть реализованы путем разделения вопросов, касающихся способности идентифицировать, инкапсулировать и манипулировать теми частями программного обеспечения, которые имеют отношение к определенной концепции, цели, задаче или назначению. Принцип 1e связан с управлением зависимостями между программными компонентами. Принцип 1g может включать в себя минимизацию количества прерываний или использование прерываний с определенным приоритетом для достижения детерминизма. Принцип 1i применяется к разделяемым ресурсам аппаратных средств, а также к разделяемым программным ресурсам в случае их совместного применения. Такое управление ресурсами может быть реализовано в программном обеспечении или в аппаратных средствах и включает в себя механизмы безопасности и/или меры процесса, которые предотвращают конфликт доступа к разделяемым ресурсам, а также механизмы, которые обнаруживают и обрабатывают конфликт доступа к разделяемым ресурсам. | |||||
Примечания
1 Поскольку методы, приведенные в таблице 3, не являются взаимоисключающими, между ними может потребоваться компромисс.
2 Показателями высокой сложности могут быть:
- значительное ветвление потока управления или данных;
- чрезмерное число требований, распределяемых к отдельному элементу проекта;
- чрезмерное количество интерфейсов у одного элемента проекта или взаимодействий между элементами проекта;
- сложные типы или чрезмерное количество параметров;
- чрезмерное количество глобальных переменных;
- трудности с предоставлением доказательств пригодности и полноты обнаружения и обработки ошибок;
- трудности с обеспечением требуемого охвата тестами;
- наличие ясности только у нескольких экспертов или только у участников проекта.
3 Эти свойства и принципы также применимы к подпрограммам (например, к функции обработки прерываний).
7.4.4 Архитектура программного обеспечения должна быть разработана до уровня, где идентифицированы все программные модули.
7.4.5 Архитектура программного обеспечения должна описывать:
a) статические аспекты элементов архитектуры программного обеспечения.
Примечания
1 Статическими свойствами проекта являются:
- структура программного обеспечения, включая ее иерархические уровни;
- типы данных и их характеристики;
- внешние интерфейсы программных компонентов;
- внешние интерфейсы встроенного программного обеспечения;
- глобальные переменные;
- ограничения, в том числе область применения архитектуры и внешние зависимости.
2 В случае разработки, основанной на моделировании, моделирование структуры является неотъемлемой частью всего процесса моделирования. Моделируемая структура может зависеть от выбранного языка моделирования;
b) динамические свойства проекта элементов архитектуры программного обеспечения.
Примечания
1 Динамическими свойствами проекта являются:
- функциональная последовательность событий и реакций на них;
- логическая последовательность обработки данных;
- поток управления и распараллеливание процессов;
- поток данных через интерфейсы и глобальные переменные;
- временные ограничения.
2 Для определения динамических характеристик (например, задач, временных интервалов и прерываний) рассматриваются различные рабочие состояния (например, включение питания, остановка двигателя, штатный режим работы, калибровка и диагностика).
3 Для описания динамических характеристик (например, задач, временных интервалов и прерываний) определяются коммуникационные связи и их распределение в аппаратных средствах системы (например, в ЭБУ и каналах связи).
7.4.6 Требования безопасности программного обеспечения должны быть иерархически распределены для компонентов программного обеспечения вплоть до модулей программного обеспечения. В результате каждый компонент программного обеспечения должен быть разработан в соответствии с самым высоким значением УПБТС среди распределенных для него требований.
Примечание - В процессе разработки проекта и распределения требований может потребоваться разделение или дальнейшее уточнение требований безопасности программного обеспечения в соответствии с разделом 6.
7.4.7 Если элемент архитектуры предварительно существующего программного обеспечения используется без изменений для обеспечения соответствия установленным требованиям безопасности без его разработки в соответствии с серией стандартов ИСО 26262, то этот элемент должен быть квалифицирован в соответствии с разделом 12 ИСО 26262-8.
Примечания
1 Использование квалифицированных компонентов программного обеспечения не отменяет применение требований разделов 10 и 11. Однако некоторые виды действий, описанные в разделах 8 и 9, могут быть опущены.
2 Пригодность повторного использования элементов программного обеспечения, разработанных в соответствии с серией стандартов ИСО 26262, подтверждается при верификации архитектуры программного обеспечения.
7.4.8 Если встроенное программное обеспечение реализуется с использованием компонентов программного обеспечения с различными значениями УПБТС или с использованием компонентов программного обеспечения, связанных с безопасностью и не связанных с безопасностью, то все встроенное программное обеспечение должно рассматриваться в соответствии с самым высоким значением УПБТС, если компоненты программного обеспечения не удовлетворяют критериям совместимости в соответствии с требованиями раздела 6 ИСО 26262-9.
7.4.9 Если для устранения взаимного влияния между программными компонентами используется программное управление разделами (см. приложение D), то следует обеспечить, чтобы:
a) общие ресурсы использовались таким образом, чтобы отсутствовало влияние между разделами программного обеспечения.
Примечания
1 Между задачами внутри программного раздела взаимное влияние возможно.
2 Один программный раздел не может ни изменить код или данные другого программного раздела, ни управлять неразделяемыми ресурсами других программных разделов.
3 Услуги, получаемые от разделяемых ресурсов одним программным разделом, не могут зависеть от услуг, получаемых другим программным разделом. Они включают в себя производительность соответствующих ресурсов, а также частоту, задержку, фазовое дрожание и длительность запланированного доступа к ресурсу;
b) программное управление разделами поддерживается специальными функциями аппаратных средств или эквивалентными средствами (данное требование распространяется на значение УПБТС, равное D, в соответствии с 4.4).
Пример - Функция аппаратных средств, такая как блок управления памятью;
c) программный компонент, который реализует управление программными разделами, разработан в соответствии с самым высоким значением УПБТС, назначенным любому из требований к программным разделам.
Примечание - Обычно управление программными разделами предоставляет или обеспечивает операционная система;
d) подтверждение эффективности разделения программного обеспечения было сформировано при интеграции и верификации программного обеспечения (в соответствии с требованиями раздела 10).
7.4.10 На уровне архитектуры программного обеспечения в соответствии с требованиями раздела 8 ИСО 26262-9 должен быть выполнен анализ безопасности для того, чтобы:
- предоставить доказательства пригодности программного обеспечения для выполнения определенных связанных с безопасностью функций и свойств согласно требуемому значению УПБТС.
Примечание - Свойства, связанные с безопасностью, включают в себя независимость и требования к отсутствию влияния;
- определить или подтвердить связанные с безопасностью части программного обеспечения;
- сформировать спецификацию и выполнить проверку эффективности мер обеспечения безопасности.
Примечания
1 Меры обеспечения безопасности включают в себя механизмы безопасности, которые были получены на основе анализа безопасности и могут охватывать проблемы, связанные со случайными отказами аппаратных средств, а также со сбоями программного обеспечения.
2 Дополнительную информацию о применении анализа безопасности на уровне архитектуры программного обеспечения и выборе соответствующих мер безопасности см. в приложении E.
7.4.11 Если реализация требований безопасности программного обеспечения зависит от отсутствия влияния или достаточной независимости между программными компонентами, то должен быть выполнен анализ зависимых отказов и их влияния в соответствии с требованиями раздела 7 ИСО 26262-9.
Примечание - Дополнительную информацию о применении анализа зависимых отказов на уровне архитектуры программного обеспечения см. в приложении E настоящего стандарта и в приложении С ИСО 26262-9.
7.4.12 Механизмы безопасности для выявления и обработки ошибок должны применяться в зависимости от результатов анализа безопасности на уровне архитектуры программного обеспечения в соответствии с 7.4.10 или 7.4.11.
Примечания
1 Приложение E содержит указания для принятия решения о том, требуются ли механизмы безопасности для вида отказов.
2 Механизмы безопасности для выявления ошибок могут включать в себя следующее:
- контроль допустимых значений входных и выходных данных;
- проверку достоверности (например, использование эталонной модели требуемого функционирования, проверку утверждений или сравнение сигналов из различных источников);
- обнаружение ошибок данных (например, коды обнаружения ошибок и резервирование хранилищ данных);
- мониторинг выполнения программы внешними средствами, например специализированной интегральной схемой (СИС) или другим элементом программного обеспечения, выполняющим функцию сторожевого таймера. Мониторинг может быть логическим или временным либо и тем, и другим;
- временной мониторинг исполнения программы;
- использование при проектировании разнообразия;
- механизмы управления контролем доступа, реализованные программным обеспечением или аппаратными средствами, обеспечивающие предоставление или отказ в доступе к общим ресурсам, связанным с безопасностью.
3 Механизмы безопасности для обработки ошибок могут включать в себя следующее:
- отключение для достижения и обеспечения безопасного состояния;
- статический механизм восстановления (например, блоки восстановления, восстановление предыдущего состояния, восстановление без возврата и восстановление посредством повтора);
- постепенное снижение эффективности путем расположения по приоритетам реализуемых функций для минимизации негативного влияния возможных отказов на функциональную безопасность;
- проектирование однородной избыточности, которая в основном управляет последствиями нестабильных сбоев или случайными сбоями в аппаратных средствах, на которых выполняется аналогичное программное обеспечение (например, временная избыточность выполнения программного обеспечения);
- проектирование разнообразия, которое подразумевает разнородное программное обеспечение в каждом параллельном канале и в основном направлено на предотвращение или управление систематическими сбоями в программном обеспечении;
- коды исправления данных;
- управление правами доступа, реализуемое в программном обеспечении или аппаратных средствах, выполняющее предоставление или отказ в доступе к общим ресурсам, связанным с безопасностью.
4 Механизмы безопасности программного обеспечения (включая общие механизмы робастности) могут быть проанализированы на уровне системы для выявления возможного влияния на ее функционирование и проверки их соответствия требованиям технической безопасности.
7.4.13 Должна быть выполнена верхняя оценка ресурсов, необходимых для встроенного программного обеспечения, в том числе:
a) время выполнения;
b) объем памяти.
Пример - ОЗУ для стеков и динамически распределяемых областей памяти, ПЗУ для программ и неизменяемых данных;
c) коммуникационные ресурсы.
7.4.1.4 Архитектура программного обеспечения должна быть верифицирована в соответствии с требованиями раздела 9 ИСО 26262-8, используя методы верификации архитектуры программного обеспечения, перечисленные в таблице 4, чтобы продемонстрировать достижение следующих целей:
a) соответствие архитектуры программного обеспечения требованиям безопасности программного обеспечения с требуемым значением УПБТС;
b) доказательство соответствия архитектуры программного обеспечения требованиям программного обеспечения с требуемым значением УПБТС, используя результаты анализа или исследования этого проекта;
c) совместимость с целевой внешней средой.
Примечание - Целевая среда - это среда, в которой выполняется программное обеспечение. Она может включать в себя операционную систему и базовое программное обеспечение в дополнение к целевым аппаратным средствам и их ресурсам, как указано в 7.4.13;
d) соблюдение руководств по проектированию.
Таблица 4 - Методы верификации архитектуры программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Сквозной контроль проекта | ++ | + | о | о |
1b | Ревизия проекта | + | ++ | ++ | ++ |
1c | Моделирование проекта в динамике | + | + | + | ++ |
1d | Генерация прототипа | о | о | + | ++ |
1e | Формальная верификация | о | о | + | + |
1f | Анализ потока управления | + | + | ++ | ++ |
1g | Анализ потока данных | + | + | ++ | ++ |
1h | Анализ диспетчеризации | + | + | ++ | ++ |
В случае разработки, основанной на моделировании, эти методы могут быть применены к модели. Анализ потока управления и/или данных может быть ограничен связанными с безопасностью компонентами и их интерфейсами. | |||||
7.5 Результаты работы
7.5.1 Спецификация архитектуры программного обеспечения
В результате выполнения требований 7.4.1-7.4.13.
7.5.2 Отчет по анализу безопасности
В результате выполнения требований 7.4.10.
7.5.3 Отчет по анализу зависимых отказов
В результате выполнения требований 7.4.11.
7.5.4 Отчет по верификации программного обеспечения
В результате выполнения требований 7.4.14.
8 Проектирование и реализация модуля программного обеспечения
8.1 Цели
Цели настоящей подстадии:
a) разработать проект модуля программного обеспечения в соответствии с архитектурой программного обеспечения, критериями проектирования и распределенными требованиями программного обеспечения, которые обеспечивают реализацию и верификацию модуля программного обеспечения;
b) реализовать модули программного обеспечения в соответствии с требованиями.
8.2 Общие положения
На основе архитектуры программного обеспечения разрабатывается детальный проект модулей программного обеспечения. Такой детальный проект может быть представлен в виде модели.
Реализация на уровне исходного кода может быть создана вручную или сгенерирована автоматически по результатам проектирования, используя среду разработки программного обеспечения.
При разработке проекта отдельного модуля программного обеспечения реализуются как требования безопасности программного обеспечения, так и все не связанные с безопасностью требования. Следовательно, на данной подстадии связанные с безопасностью и не связанные с безопасностью требования рассматриваются в рамках единого процесса разработки.
8.3 Входная информация
8.3.1 Предварительные требования
Необходима следующая информация:
- документация на среду разработки программного обеспечения в соответствии с 5.5.1;
- спецификация аппаратно-программного интерфейса (уточненная) в соответствии с 6.5.2;
- спецификация архитектуры программного обеспечения в соответствии с 7.5.1;
- спецификация требований безопасности программного обеспечения в соответствии с 6.5.1;
- данные конфигурации в соответствии с С.5.3, если применимы;
- калибровочные данные в соответствии с С.5.4, если применимы.
8.3.2 Дополнительная информация
Может быть учтена следующая информация:
- концепция технической безопасности (см. 6.5.2 ИСО 26262-4);
- спецификация архитектуры системы (см. 6.5.3 ИСО 26262-4);
- спецификация функций и свойств программного обеспечения, не связанных с безопасностью (из внешнего источника);
- отчет по анализу безопасности (см. 7.5.2);
- отчет по анализу зависимых отказов (см. 7.5.3).
8.4 Требования и рекомендации
8.4.1 Требования настоящего подраздела должны соблюдаться, если модуль программного обеспечения является элементом, связанным с безопасностью.
Примечание - Слова "связанный с безопасностью" означают, что модуль реализует требования безопасности или что критерии совместимости (см. раздел 6 ИСО 26262-9) этого модуля с другими модулями не выполнены.
8.4.2 Проектирование и реализация модуля программного обеспечения должны:
a) соответствовать требованиям программного обеспечения, распределенным для модуля программного обеспечения с требуемым значением УПБТС;
b) соответствовать спецификации архитектуры программного обеспечения;
c) соответствовать спецификации аппаратно-программного интерфейса, если применимо.
Пример - Полнота и согласованность интерфейсов с другими модулями программного обеспечения; корректность, точность и своевременность ввода или вывода данных.
8.4.3 Во избежание систематических сбоев и для обеспечения того, чтобы проект модуля программного обеспечения достиг следующих свойств, проект модуля программного обеспечения должен быть описан с использованием представлений, перечисленных в таблице 5.
a) последовательность;
b) понятность;
c) удобство сопровождения;
d) верифицируемость.
Таблица 5 - Представления для проекта модуля программного обеспечения
|
|
|
|
|
|
Представления | УПБТС | ||||
| A | B | C | D | |
1a | Неформальный язык | ++ | ++ | ++ | ++ |
2b | Неформальные нотации | ++ | ++ | + | + |
3c | Полуформальные нотации | + | + | ++ | ++ |
4d | Формальные нотации | + | + | + | + |
Естественный язык может дополнять использование нотаций, например, в тех случаях, когда некоторые темы более легко выражаются на естественном языке, или давать объяснение и обоснование решений, представленных в нотации. Пример - Чтобы избежать возможной неоднозначности естественного языка при проектировании сложных элементов, может использоваться комбинация диаграммы функционирования с естественным языком.
Полуформальные нотации могут включать в себя псевдокод или моделирование с помощью UML®, SysML®, Simulink® или Stateflow®. Примечание - UML®, SysML®, Simulink® и Stateflow® являются примерами подходящих продуктов, доступных на коммерческой основе. Эта информация приводится для удобства пользователей настоящего стандарта и не является рекомендацией ИСО для этих продуктов. | |||||
Примечание - Если используется разработка, основанная на моделировании, с автоматической генерацией кода, то эти способы представления проекта модуля программного обеспечения применяются для модели, которая служит основой для генерации кода.
8.4.4 Спецификация модулей программного обеспечения должна описывать выполняемые ими функции и внутренний проект этих модулей до уровня детализации, необходимого для их реализации.
Пример - Внутренний проект может включать в себя ограничения на использование регистров и запоминающего устройства.
8.4.5 Принципы проектирования для разработки и реализации модуля программного обеспечения на уровне исходного кода, которые перечислены в таблице 6, должны применяться для достижения следующих свойств:
a) корректного порядка выполнения подпрограмм и функций внутри программных модулей, основанного на архитектуре программного обеспечения;
b) согласованности интерфейсов между модулями программного обеспечения;
c) корректности потока данных и управления между и внутри модулей программного обеспечения;
d) простоты;
e) читаемости и полноты;
f) робастности.
Пример - Методы предотвращения недостоверных значений, ошибок исполнения, деления на ноль, и ошибок потока данных и потока управления;
g) пригодности программного обеспечения для модификации;
h) верифицируемости.
Таблица 6 - Принципы проектирования для разработки и реализации модуля программного обеспечения
|
|
|
|
|
|
Принципы | УПБТС | ||||
| A | B | C | D | |
1a | Одна точка входа и одна точка выхода в подпрограммах и функциях | ++ | ++ | ++ | ++ |
1b | Не использовать динамические объекты или переменные либо выполнять оперативное тестирование при их создании | + | ++ | ++ | ++ |
1c | Инициализация переменных | ++ | ++ | ++ | ++ |
1d | Не использовать многократно имена переменных | ++ | ++ | ++ | ++ |
1e | Избегать глобальных переменных либо обосновывать их использование | + | + | ++ | ++ |
1f | Ограничивать использование указателей | + | ++ | ++ | ++ |
1g | Исключать неявные преобразования типов | + | ++ | ++ | ++ |
1h | Исключать скрытые потоки данных или потоки управления | + | ++ | ++ | ++ |
1i | Исключать безусловные переходы | ++ | ++ | ++ | ++ |
1j | Исключать рекурсии | + | + | ++ | ++ |
Принципы 1a, 1b, 1d, 1e, 1f, 1g и 1i могут быть неприменимы для нотаций графических моделей, используемых при разработке, основанной на моделировании. | |||||
Примечание - MISRA С (для языка С) [3] включает в себя многие из принципов, перечисленных в таблице 8.
8.5 Результаты работы
8.5.1 Спецификация проекта модуля программного обеспечения
В результате выполнения требований 8.4.2-8.4.5.
Примечание - В случае разработки, основанной на моделировании, модель реализации и вспомогательная документация к ней с использованием методов, перечисленных в таблицах 5 и 6, определяет модули программного обеспечения.
8.5.2 Реализация модуля программного обеспечения
В результате выполнения требований 8.4.5.
9 Верификация модуля программного обеспечения
9.1 Цели
Цели настоящей подстадии:
a) предоставить доказательства того, что проект модуля программного обеспечения удовлетворяет распределенным требованиям программного обеспечения и подходит для реализации;
b) подтвердить, что определенные меры безопасности, полученные в результате анализа безопасности в соответствии с 7.4.10 и 7.4.11, выполнены надлежащим образом;
c) предоставить доказательства того, что реализованный модуль программного обеспечения соответствует проекту модуля и распределенным требованиям программного обеспечения с требуемым значением УПБТС;
d) предоставить достаточные доказательства того, что модуль программного обеспечения не реализует ни нежелательных функций, ни нежелательных свойств, влияющих на функциональную безопасность.
9.2 Общие положения
Проект модуля программного обеспечения и реализованные модули программного обеспечения верифицируются с помощью соответствующей комбинации мер верификации, таких как отчеты, исследования и тестирование.
Для верификации проекта каждого модуля программного обеспечения учитываются как требования безопасности программного обеспечения, так и все требования, не связанные с безопасностью. Таким образом, на данном подэтапе требования, связанные и не связанные с безопасностью, выполняются в рамках единого процесса разработки.
9.3 Входная информация
9.3.1 Предварительные требования
Необходима следующая информация:
- спецификация аппаратно-программного интерфейса (уточненная) в соответствии с 6.5.2;
- спецификация архитектуры программного обеспечения в соответствии с 7.5.1;
- спецификация проекта модуля программного обеспечения в соответствии с 8.5.1;
- реализация модуля программного обеспечения в соответствии с 8.5.2;
- данные конфигурации в соответствии с С.5.3, если применимы;
- калибровочные данные в соответствии с С.5.4, если применимы;
- отчет по анализу безопасности в соответствии с 7.5.2;
- документация на среду разработки программного обеспечения в соответствии с 5.5.1.
9.3.2 Дополнительная информация
Может быть учтена следующая информация:
- не задается.
9.4 Требования и рекомендации
9.4.1 Требования настоящего подраздела должны соблюдаться, если модуль программного обеспечения является элементом, связанным с безопасностью.
Примечания
1 Согласно ИСО 26262-1 слова "элемент, связанный с безопасностью" означают, что модуль реализует требования безопасности или что критерии совместимости (см. раздел 6 ИСО 26262-9) этого модуля с другими модулями не выполнены.
2 Требования настоящего раздела касаются модулей программного обеспечения, связанных с безопасностью. Для проверки других модулей программного обеспечения допускается применять другие стандарты на программное обеспечение (см. 5.4.5.1 ИСО 26262-2).
3 При разработке программного обеспечения на основе модели соответствующие части модели реализации также являются объектами планирования верификации. В зависимости от выбранного процесса разработки программного обеспечения объектами верификации могут быть код, полученный из этой модели, сама модель или и то, и другое.
9.4.2 Проект модуля программного обеспечения и реализованный модуль программного обеспечения должны быть верифицированы в соответствии с требованиями раздела 9 ИСО 26262-8 путем применения соответствующей комбинации методов, представленных в таблице 7, для подтверждения:
a) соответствия требованиям раздела 8 к проектированию и реализации модуля.
Примечания
1 Требования безопасности программного обеспечения относятся как к функциям, так и к свойствам программного обеспечения.
2 Выполнение верификации на уровне модели может заменить верификацию на уровне исходного кода при условии, что генерация кода сохраняет свойства модуля (например, достаточную уверенность в используемых генераторах кода).
Пример - Доказательство эффективной реализации механизмов выявления и обработки ошибок, определенных для достижения робастности модуля программного обеспечения в случае ошибочных входных данных;
b) соответствия исходного кода со спецификацией его проекта.
Примечание - В случае разработки, основанной на моделировании, также применяется требование перечисления b);
c) соответствия со спецификацией аппаратно-программного интерфейса (в соответствии с требованиями 6.4.4), если применимо;
d) уверенности в отсутствии непреднамеренных функций и свойств;
e) достаточного уровня обеспечения ресурсами для поддержки его функций и свойств;
f) соответствия реализации мер безопасности результатам анализа безопасности, выполненного согласно требованиям 7.4.10 и 7.4.11.
Таблица 7 - Методы верификации модуля программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Сквозной контроль проекта | ++ | + | о | о |
1b | Дублированное программирование | + | + | + | + |
1c | Ревизия | + | ++ | ++ | ++ |
1d | Полуформальная верификация | + | + | ++ | ++ |
1e | Формальная верификация | о | о | + | + |
1f | Анализ потока управления | + | + | ++ | ++ |
1g | Анализ потока данных | + | + | ++ | ++ |
1h | Статический анализ кода | ++ | ++ | ++ | ++ |
1i | Статический анализ, основанный на абстрактной интерпретации | + | + | + | + |
1j | Тестирование на основе требований | ++ | ++ | ++ | ++ |
1k | Тестирование интерфейса  | ++ | ++ | ++ | ++ |
1l | Тестирование методом внесения дефектов  | + | + | + | ++ |
1m | Оценка используемых ресурсов  | + | + | + | ++ |
1n | Сравнительный тест между моделью и кодом, если он применим  | + | + | ++ | ++ |
При разработке, основанной на моделировании, эти методы применяются на уровне модели, если имеются доказательства, которые обосновывают доверие к используемому генератору кода. Методы 1f и 1g могут применяться на уровне исходного кода. Эти методы применяются как при разработке кода вручную, так и при разработке, основанной на моделировании. Методы 1f и 1g могут быть частью методов 1e, 1h или 1i. Статический анализ представляет собой собирательный термин, который включает в себя различные виды анализа, например поиск текста исходного кода или модели шаблонов, соответствующих известным сбоям, или анализ соблюдения руководства по моделированию или кодированию. Статический анализ, основанный на абстрактной интерпретации, является собирательным термином для расширенного статического анализа, который включает в себя такие виды анализа, как расширение дерева синтаксического разбора компилятора путем добавления семантической информации, которая может проверяться на предмет нарушения определенных правил (например, при возникновении проблем с типами данных, при появлении неинициализированных переменных), формирование графа потока управления и анализ потока данных (например, для обнаружения сбоев, связанных с гонками потоков и взаимоблокировками, ошибками в указателях) или даже метакомпиляция и абстрактная интерпретация кода или модели. Требования к программному обеспечению на уровне модуля являются основой для тестирования на основе требований. К ним относятся спецификация проекта модуля программного обеспечения и требования к безопасности модуля программного обеспечения, распределенные для этого модуля программного обеспечения. Данный метод может быть использован для обеспечения доказательства целостности используемых данных и данных обмена. В контексте испытания модуля программного обеспечения тестирование методом внесения дефектов означает изменение тестируемого модуля программного обеспечения (например, внесение сбоев в программное обеспечение) для целей, описанных в 9.4.2. Такие модификации включают в себя внесение произвольных дефектов (например, путем повреждения значений переменных, путем введения изменения данных или путем повреждения значений регистров центрального процессора). Некоторые задачи метода оценки используемых ресурсов могут быть выполнены надлежащим образом только в том случае, если тестирование модуля программного обеспечения выполняется в целевой среде или если эмулятор целевого процессора корректно обеспечивает тесты использования ресурсов. Для данного метода требуется модель, которая может имитировать функционирование программных модулей. В этом случае модель и код выполняются одинаковым образом, а результаты сравниваются друг с другом. Пример - В случае проектирования на основе модели допускается сравнивать результаты операций, имеющие типы данных кроме плавающей точки. | |||||
9.4.3 В соответствии с требованиями 9.4.2 для получения подходящих тестовых сценариев для испытания модуля программного обеспечения должны быть использованы методы, перечисленные в таблице 8.
Таблица 8 - Методы получения тестовых сценариев для тестирования модуля программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Анализ требований | ++ | ++ | ++ | ++ |
1b | Генерация и анализ классов эквивалентности | + | ++ | ++ | ++ |
1c | Анализ граничных значений | + | ++ | ++ | ++ |
1d | Предугадывание ошибок на основе знаний или опыта | + | + | + | + |
Классы эквивалентности могут быть определены на основе разделения входных и выходных данных так, чтобы репрезентативные тестовые значения могли быть выбраны из каждого класса. Данный метод применяется к интерфейсам, у которых значения приближаются и пересекают границы, а также выходят за границы диапазона значений. Испытания с предугадыванием ошибок могут быть основаны на данных, полученных из "обобщения опыта" и экспертной оценки. | |||||
9.4.4 Для того, чтобы оценить полноту верификации и предоставить доказательства того, что цели, поставленные перед испытанием модуля, надлежащим образом достигнуты, должен быть определен охват требований на уровне модуля программного обеспечения и должно быть измерено структурное покрытие с помощью метрик, перечисленных в таблице 9. Если достигаемое структурное покрытие считается недостаточным, то либо должны быть определены дополнительные тестовые сценарии, либо должно быть предоставлено обоснование, основанное на других методах.
Примечание - Отсутствие целевого значения структурного покрытия или его низкое целевое значение должно быть обосновано.
Примеры
1 Анализ структурного покрытия может выявить недостатки в тестовых сценариях при тестировании на основе требований, несоответствия в требованиях, неисполняемый код, выводящий из строя код или непреднамеренную функциональность.
2 Для уровня покрытия, достигаемого на основе принятого неисполняемого кода (например, кода для отладки) или сегментов кода в зависимости от различных конфигураций программного обеспечения, может быть предоставлено обоснование; либо не охваченный покрытием код может быть верифицирован с помощью дополнительных методов (например, с помощью проверок).
3 Обоснование может быть основано на современном уровне развития техники.
Таблица 9 - Метрики структурного покрытия на уровне модуля программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Покрытие операторов | ++ | ++ | + | + |
1b | Покрытие ветвей | + | ++ | ++ | ++ |
1c | Модифицированное покрытие условий и ветвей (MC/DC) | + | + | + | ++ |
Примечания
1 Структурное покрытие может быть определено путем использования соответствующих программных инструментальных средств.
2 При разработке, основанной на моделировании, анализ структурного покрытия может быть выполнен на уровне модели с использованием аналогичных метрик структурного покрытия для моделей.
Пример - Анализ структурного покрытия, выполняемый на уровне модели, может заменить метрики покрытия исходного кода, если показано, что они эквивалентны, с обоснованиями, основанными на свидетельствах того, что это покрытие представляет уровень кода.
3 Если для определения степени покрытия используется инструментированный код, то может потребоваться показать, что инструментирование не влияет на результаты тестирования. Это может быть сделано путем повторения репрезентативных тестовых сценариев с использованием неинструментированного кода.
9.4.5 Для достижения целей тестирования модуля испытательная среда тестирования модуля программного обеспечения должна быть как можно более близка к целевой среде. Если тестирование модуля программного обеспечения выполняется не в целевой среде, то должны быть проанализированы различия исходного и объектного кодов, а также различия между средой тестирования и целевой средой для того, чтобы определить дополнительные тесты в целевой среде для последующих стадий тестирования.
Примечания
1 Различия между средой тестирования и целевой средой могут возникнуть в исходном коде или в объектном коде, например из-за различной разрядности слов данных и адресных слов процессоров.
2 В зависимости от области применения тестов для выполнения модуля программного обеспечения используется соответствующая среда тестирования (например, целевой процессор, процессор-эмулятор или разрабатываемая система).
3 Тестирование модуля программного обеспечения может быть выполнено в различных средах, например:
- тестирование с моделью в контуре обратной связи;
- тестирование с программой в контуре обратной связи;
- тестирование с процессором в контуре обратной связи;
- тестирование с аппаратными средствами в контуре обратной связи.
4 При разработке, основанной на моделировании, тестирование модуля программного обеспечения может быть выполнено на уровне модели с помощью сравнительных тестов между моделью и объектным кодом. Сравнительные тесты используются, чтобы обеспечить эквивалентность функционирования модели, учитывающей цели тестирования, и автоматически сгенерированного кода.
9.5 Результаты работы
9.5.1 Спецификация верификации программного обеспечения
В результате выполнения требований 9.4.2-9.4.5.
9.5.2 Отчет о верификации программного обеспечения (уточненный)
В результате выполнения требований 9.4.2.
10 Интеграция и верификация программного обеспечения
10.1 Цели
Цели настоящей подстадии:
a) определить этапы интеграции и интегрировать элементы программного обеспечения до полной интеграции встроенного программного обеспечения;
b) проверить, что определенные меры безопасности, полученные из анализа безопасности на уровне архитектуры программного обеспечения, реализованы надлежащим образом;
c) предоставить доказательства того, что интегрированные программные модули и компоненты удовлетворяют требованиям, которые определены для них в архитектуре программного обеспечения;
d) предоставить достаточные доказательства того, что интегрированное программное обеспечение не реализует ни нежелательных функций, ни нежелательных свойств, влияющих на функциональную безопасность.
10.2 Общие положения
На данной подстадии верифицируются определенные уровни интеграции и интерфейсы между элементами программного обеспечения на соответствие архитектуре программного обеспечения. Этапы интеграции и верификации элементов программного обеспечения связаны с иерархической архитектурой программного обеспечения.
Встроенное программное обеспечение может состоять из связанных и не связанных с безопасностью элементов программного обеспечения.
10.3 Входная информация
10.3.1 Предварительные требования
Необходима следующая информация:
- спецификация аппаратно-программного интерфейса (уточненная) в соответствии с 6.5.2;
- спецификация архитектуры программного обеспечения в соответствии с 7.5.1;
- отчет по анализу безопасности в соответствии с 7.5.2;
- отчет по анализу зависимых отказов в соответствии с 7.5.3;
- реализация модуля программного обеспечения в соответствии с 8.5.2;
- данные конфигурации в соответствии с С.5.3, если применимы;
- калибровочные данные в соответствии с С.5.4, если применимы;
- документация на среду разработки программного обеспечения в соответствии с 5.5.1;
- спецификация верификации программного обеспечения в соответствии с 9.5.1.
10.3.2 Дополнительная информация
Может быть учтена следующая информация:
- о доступных квалифицированных компонентах программного обеспечения (см. раздел 12 ИСО 26262-8).
10.4 Требования и рекомендации
10.4.1 Должен быть определен подход к интеграции программного обеспечения и описаны этапы иерархической интеграции отдельных программных модулей в программные компоненты до полной интеграции встроенного программного обеспечения, а также должны быть рассмотрены:
a) требования, связанные с достижением целей верификации, предусмотренные в 10.4.2;
b) функциональные зависимости, которые важны для интеграции программного обеспечения;
c) зависимости между интеграцией программного обеспечения и интеграцией аппаратно-программного обеспечения.
Примечание - При разработке, основанной на моделировании, интеграция программного обеспечения может быть заменена на интеграцию на уровне модели с последующей автоматической генерацией кода из интегрированной модели (см. приложение B).
10.4.2 Интеграция программного обеспечения должна быть верифицирована в соответствии с требованиями раздела 9 ИСО 26262-8, соответствующей комбинацией методов, представленных в таблице 10, для подтверждения того, что иерархически интегрированные программные модули, программные компоненты и интегрированное встроенное программное обеспечение достигают:
a) соответствия с архитектурой программного обеспечения согласно требованиям раздела 7;
b) соответствия со спецификацией аппаратно-программного интерфейса согласно требованиям 6.5.2;
c) заданных функциональных возможностей;
d) заданных свойств.
Пример - Безотказность из-за отсутствия недоступного программного обеспечения, устойчивость к ошибкам на входах, робастность вследствие эффективного обнаружения и обработки ошибок;
e) обеспечения достаточных ресурсов для поддержки функциональности;
f) эффективности мер безопасности, полученных из анализа безопасности в соответствии с 7.4.10 и 7.4.11, если это применимо.
Примечание - Меры безопасности могут включать в себя программное управление разделами.
Таблица 10 - Методы верификации интеграции программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование на основе требований | ++ | ++ | ++ | ++ |
1b | Тестирование интерфейса | ++ | ++ | ++ | ++ |
1c | Тестирование с внесением дефектов | + | + | ++ | ++ |
1d | Оценка используемых ресурсов  | ++ | ++ | ++ | ++ |
1e | Сравнительный тест модели и кода, если он применим | + | + | ++ | ++ |
1f | Верификация потока управления и потока данных | + | + | ++ | ++ |
1g | Статический анализ кода | ++ | ++ | ++ | ++ |
1h | Статический анализ, основанный на абстрактной интерпретации | + | + | + | + |
Требования к программному обеспечению, распределенные по элементам архитектуры, являются основой для тестирования на основе требований. В контексте испытания модуля программного обеспечения тестирование методом внесения дефектов означает внесение сбоев в программное обеспечение для целей, описанных в 10.4.3, и тем самым проверку корректности аппаратно-программного интерфейса, связанного с механизмами безопасности. Данный метод включает в себя внесение произвольных сбоев для тестирования механизмов безопасности (например, путем повреждения программных интерфейсов). Внесение дефектов также может использоваться для проверки отсутствия влияния. Для обеспечения выполнения требований, вытекающих из проекта архитектуры аппаратных средств с достаточной устойчивостью, необходимо определить такие свойства, как средняя и максимальная производительность процессора, минимальное или максимальное время выполнения, использование памяти (например, ОЗУ для стека и динамической памяти, ПЗУ для программы и данных), а также полосу пропускания линий связи (например, шин данных). Некоторые задачи оценки используемых ресурсов могут быть выполнены надлежащим образом только в том случае, если тестирование интеграции программного обеспечения выполняется в целевой среде или если эмулятор целевого процессора корректно поддерживает тесты используемых ресурсов. Для данного метода требуется модель, которая может имитировать функциональные возможности программных компонентов. На вход модели и кода подаются одинаковые данные, а результаты сравниваются друг с другом. Статический анализ кода представляет собой собирательный термин, который включает в себя такие виды анализа, как анализ архитектуры, анализ потребления ресурсов, поиск текста исходного кода или признаков шаблонов, соответствующих известным сбоям, или анализ соблюдения стандартов по моделированию или кодированию, если это еще не было верифицировано на уровне модуля. Статический анализ, основанный на абстрактной интерпретации, является собирательным термином для расширенного статического анализа, который включает в себя такие виды анализа, как расширение дерева синтаксического разбора компилятора путем добавления семантической информации, которая может проверяться на предмет нарушения определенных правил (например, при возникновении проблем с типами данных, при появлении неинициализированных переменных), формирование графа потока управления и анализ потока данных (например, для обнаружения сбоев, связанных с гонками потоков и взаимоблокировками, ошибками в указателях) или даже метакомпиляция и абстрактная интерпретация кода или модели, если это еще не было верифицировано на уровне модуля. | |||||
Примечание - При разработке, основанной на моделировании, объектами верификации могут быть модели, связанные с компонентами программного обеспечения.
10.4.3 Для формирования соответствующих тестовых сценариев для методов тестирования интеграции программного обеспечения, выбранных в соответствии с 10.4.2, тестовые сценарии должны быть получены, используя методы, перечисленные в таблице 11.
Таблица 11 - Методы получения тестовых сценариев для тестирования интеграции программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Анализ требований | ++ | ++ | ++ | ++ |
1b | Генерация и анализ классов эквивалентности | + | ++ | ++ | ++ |
1c | Анализ граничных значений | + | ++ | ++ | ++ |
1d | Предугадывание ошибок на основе знаний или опыта | + | + | + | + |
Классы эквивалентности могут быть определены на основе разделения входных и выходных данных так, чтобы репрезентативные тестовые значения выбирались из каждого класса. Данный метод применяется к параметрам или переменным, значения которых приближаются и пересекают границы, а также выходят за границы диапазона значений. Испытания с предугадыванием ошибок могут быть основаны на данных, полученных из "обобщения опыта" и экспертной оценки. | |||||
10.4.4 Для оценки полноты верификации и подтверждения того, что цели испытаний по тестированию интеграции надлежащим образом достигнуты, должен быть определен охват требований тестовыми сценариями на уровне архитектуры программного обеспечения. При необходимости указываются дополнительные тестовые сценарии или приводится обоснование, основанное на других методах.
10.4.5 Данное требование распространяется на значения УПБТС (A), (B), C и D в соответствии с 4.4. Для оценки полноты тестовых сценариев и получения уверенности в том, что цели испытаний при тестировании интеграции надлежащим образом достигнуты, должно быть оценено структурное покрытие в соответствии с методами, перечисленными в таблице 12. Если достигнутое структурное покрытие считается недостаточным, то либо должны быть определены дополнительные тестовые сценарии, либо должно быть предусмотрено обоснование, основанное на других методах.
Пример - Анализ структурного покрытия может выявить недостатки в тестовых сценариях при тестировании на основе требований, несоответствия в требованиях, неисполняемый код, выводящий из строя код или непреднамеренную функциональность.
Таблица 12 - Структурное покрытие на уровне архитектуры программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Покрытие функций | + | + | ++ | ++ |
1b | Охват вызовов | + | + | ++ | ++ |
Метод 1a оценивает процент выполняемых подпрограмм или функций в программном обеспечении (определение см. в С.5.8 МЭК 61508-7). Метод 1b оценивает процент выполняемых подпрограмм или функций программного обеспечения относительно каждого реализованного вызова этих подпрограмм или функций в программном обеспечении. Примечание - Подтверждение может быть предоставлено путем реализации соответствующей стратегии интеграции и тестирования программного обеспечения. | |||||
Примечания
1 Структурное покрытие может быть определено путем использования соответствующих программных инструментальных средств.
2 При разработке, основанной на моделировании, тестирование архитектуры программного обеспечения может быть выполнено на уровне модели с использованием аналогичных метрик структурного покрытия для моделей.
10.4.6 Должно быть верифицировано, что встроенное программное обеспечение, которое в соответствии стребованиями раздела 11 ИСО 26262-4 должно быть частью выпускаемого изделия, содержит все специфицированные функции и свойства, а также содержит только такие неспецифицированные функции, которые не влияют на соответствие требованиям безопасности программного обеспечения.
Пример - В этом контексте неспецифицированные функции включают в себя код, используемый для отладки или инструментирования.
Примечание - Если может быть обеспечено отключение таких неспецифицированных функций, то оно является приемлемым способом соответствия данному требованию. В противном случае удаление такого кода является изменением (см. раздел 8 ИСО 26262-8).
10.4.7 Среда тестирования при тестировании интеграции программного обеспечения для достижения целей тестирования интеграции должна быть как можно более близка к целевой среде. Если тестирование интеграции программного обеспечения не выполняется в целевой среде, то должны быть проанализированы различия исходного и объектного кодов, а также различия между средой тестирования и целевой средой для того, чтобы специфицировать дополнительные тесты в целевой среде в течение последующих стадий тестирования.
Примечания
1 Различия между средой тестирования и целевой средой могут возникнуть в исходном коде или в объектном коде, например за счет разной разрядности слов данных и адресных слов процессоров.
2 Используемые среды тестирования зависят от области применения тестов и иерархического уровня интеграции выполняемых элементов программного обеспечения. Такой средой тестирования может быть целевой процессор для окончательной интеграции, или эмулятор процессора, или система разработки для предыдущих этапов интеграции.
3 Тестирование интеграции программного обеспечения может быть выполнено в различных средах, например:
- тестирование с моделью в контуре обратной связи;
- тестирование с программой в контуре обратной связи;
- тестирование с процессором в контуре;
- тестирование с аппаратными средствами в контуре обратной связи.
10.5 Результаты работы
10.5.1 Спецификация верификации программного обеспечения (уточненная)
В результате выполнения требований 10.4.2-10.4.7.
10.5.2 Встроенное программное обеспечение
В результате выполнения требований 10.4.1.
10.5.3 Отчет о верификации программного обеспечения (уточненный)
В результате выполнения требований 10.4.2.
11 Тестирование встроенного программного обеспечения
11.1 Цель
Цель данной подстадии - предоставить свидетельства, что встроенное программное обеспечение:
a) выполняет требования безопасности при реализации в целевой среде;
b) не реализует ни нежелательных функций, ни нежелательных свойств, влияющих на функциональную безопасность.
11.2 Общие положения
Целью этих действий является подтверждение того, что встроенное программное обеспечение выполняет требования безопасности в целевой среде. Такие подтверждения могут быть представлены с использованием подходящих результатов других действий по верификации.
Примечание - Рекомендуется выполнять тестирование встроенного программного обеспечения лицом, отличным от того, которое реализовало это программное обеспечение.
11.3 Входная информация
11.3.1 Предварительные требования
Необходима следующая информация:
- спецификация архитектуры программного обеспечения в соответствии с 7.5.1;
- спецификация требований безопасности программного обеспечения (уточненная) в соответствии с 6.5.1;
- встроенное программное обеспечение в соответствии с 10.5.2;
- калибровочные данные в соответствии с С.5.4, если применимы;
- документация на среду разработки программного обеспечения в соответствии с 5.5.1;
- спецификация верификации программного обеспечения (уточненная) в соответствии с 10.5.1.
11.3.2 Дополнительная информация
Может быть учтена следующая информация:
- концепция технической безопасности (см. 6.5.2 ИСО 26262-4);
- спецификация архитектуры системы (см. 6.5.3 ИСО 26262-4);
- стратегия интеграции и тестирования (см. 7.5.1 ИСО 26262-4);
- отчет по интеграции и тестированию (см. 7.5.2 ИСО 26262-4).
11.4 Требования и рекомендации
11.4.1 Чтобы убедиться, что встроенное программное обеспечение отвечает требованиям безопасности программного обеспечения в целевой среде, необходимо провести испытания в подходящих средах тестирования, перечисленных в таблице 13, и в соответствии с требованиями раздела 9 ИСО 26262-9.
Примечание - Тестовые сценарии, которые уже существуют, могут быть использованы повторно, например для тестирования интеграции программного обеспечения.
Таблица 13 - Среды тестирования для выполнения тестирования программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Аппаратные средства в контуре обратной связи | ++ | ++ | ++ | ++ |
1b | Сетевые среды электронного блока управления | ++ | ++ | ++ | ++ |
1c | Транспортные средства | + | + | ++ | ++ |
Например, тестовые стенды, частично или полностью включающие электрические системы транспортного средства, автомобили-лаборатории или базовые модели автомобилей для испытаний новых узлов, а также имитации остальных частей шины. | |||||
11.4.2 Для подтверждения того, что встроенное программное обеспечение удовлетворяет требованиям программного обеспечения, которые определяются соответствующим значением УПБТС, тестирование встроенного программного обеспечения должно выполняться с использованием методов, перечисленных в таблице 14.
Таблица 14 - Методы тестирования встроенного программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Тестирование на основе требований | ++ | ++ | ++ | ++ |
1b | Тестирование с внесением дефектов | + | + | + | ++ |
В контексте тестирования программного обеспечения испытание с внесением дефектов означает внесение сбоев в программное обеспечение посредством, например, повреждения параметров калибровки. | |||||
11.4.3 Соответствующие тестовые сценарии для испытания программного обеспечения в соответствии с 11.4.2 должны быть получены с использованием методов, перечисленных в таблице 15.
Таблица 15 - Методы получения тестовых сценариев для испытания встроенного программного обеспечения
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Анализ требований | ++ | ++ | ++ | ++ |
1b | Генерация и анализ классов эквивалентности | + | ++ | ++ | ++ |
1c | Анализ граничных значений | + | + | ++ | ++ |
1d | Предугадывание ошибок на основе знаний или опыта | + | + | ++ | ++ |
1e | Анализ функциональных зависимостей | + | + | ++ | ++ |
1f | Анализ эксплуатационных сценариев использования | + | ++ | ++ | ++ |
Примеры эксплуатационных сценариев использования программного обеспечения могут включать в себя следующее: обновление программного обеспечения на местах; запуск штатного приложения только в том случае, если целостность программного обеспечения обеспечивается загрузчиком; функционирование, связанное с безопасностью встроенного программного обеспечения в различных рабочих режимах, таких как запуск, диагностика, ухудшение качества, отключение питания (переход в спящий режим), включение питания (пробуждение), калибровка; функции синхронизации режимов между различными ЭБУ или режим тестового стенда специального выходного контроля для защиты производственного персонала. | |||||
11.4.4 Результаты тестирования встроенного программного обеспечения должны быть оценены:
a) на соответствие ожидаемым результатам;
b) охват требований безопасности программного обеспечения.
Примечание - Результаты включают в себя охват диапазонов конфигурации и калибровки. См. приложение C.
11.5 Результаты работы
11.5.1 Спецификация верификации программного обеспечения (уточненная)
В результате выполнения требований 11.4.1-11.4.3.
11.5.2 Отчет о верификации программного обеспечения (уточненный)
В результате выполнения требований 11.4.1-11.4.4.
Приложение A
(справочное)
Обзор и последовательность выполняемых работ в процессе управления разработкой изделия на уровне программного обеспечения
Таблица A.1 содержит обзор целей, предварительных требований и результатов работы конкретных стадий разработки изделия на уровне программного обеспечения.
Таблица A.1 - Обзор разработки изделия на уровне программного обеспечения
|
|
|
|
Раздел | Цели | Предварительные требования | Результаты работы |
5 Общие вопросы по разработке изделия на уровне программного обеспечения | Цели данного раздела заключаются в следующем:
a) обеспечить надлежащий и последовательный процесс разработки программного обеспечения;
b) обеспечить надлежащую среду разработки программного обеспечения | (Не задается) | 5.5.1 Документация на среду разработки программного обеспечения |
6 Спецификация требований безопасности программного обеспечения | Цели настоящей подстадии следующие:
a) определить или уточнить требования безопасности программного обеспечения, вытекающие из концепции технической безопасности и спецификации архитектуры системы;
b) определить связанные с безопасностью функции и свойства реализуемого программного обеспечения;
c) уточнить требования к аппаратно-программному интерфейсу, разрабатываемому в соответствии с требованиями раздела 6 ИСО 26262-4;
d) удостовериться в том, что требования безопасности программного обеспечения и требования к аппаратно-программному интерфейсу пригодны для разработки программного обеспечения и соответствуют концепции технической безопасности и спецификации архитектуры системы | Спецификация требований технической безопасности (см. 6.5.1 ИСО 26262-4).
Концепция технической безопасности (см. 6.5.2 ИСО 26262-4).
Спецификация архитектуры системы (см. 6.5.3 ИСО 26262-4).
Спецификация аппаратно-программного интерфейса (см. 6.5.4 ИСО 26262-4).
Документация на среду разработки программного обеспечения (см. 5.5.1) | 6.5.1 Спецификация требований безопасности программного обеспечения.
6.5.2 Спецификация программно-аппаратного интерфейса (уточненная).
6.5.3 Отчет о верификации программного обеспечения |
7 Архитектура программного обеспечения | Цели настоящей подстадии следующие:
a) разработать архитектуру программного обеспечения, удовлетворяющую требованиям безопасности программного обеспечения и другим требованиям к программному обеспечению;
b) проверить соответствие архитектуры программного обеспечения требованиям безопасности программного обеспечения с требуемым значением УПБТС;
c) обеспечить реализацию и верификацию программного обеспечения | Документация на среду разработки программного обеспечения (см. 5.5.1).
Спецификация (уточненная) аппаратно-программного интерфейса (см. 6.5.2).
Спецификация требований безопасности программного обеспечения (см. 6.5.1) | 7.5.1 Спецификация архитектуры программного обеспечения.
7.5.2 Отчет по анализу безопасности.
7.5.3 Отчет по анализу зависимых отказов.
7.5.4 Отчет по верификации программного обеспечения (уточненный) |
8 Проектирование и реализация модуля программного обеспечения | Цели настоящей подстадии следующие:
a) разработать проект модуля программного обеспечения в соответствии с архитектурой программного обеспечения, критериями проектирования и распределенными требованиями программного обеспечения, которые обеспечивают реализацию и верификацию модуля программного обеспечения;
b) реализовать модули программного обеспечения в соответствии с требованиями | Документация на среду разработки программного обеспечения (см. 5.5.1).
Спецификация аппаратно-программного интерфейса (уточненная) (см. 6.5.2).
Спецификация архитектуры программного обеспечения (см. 7.5.1). Спецификация требований безопасности программного обеспечения (см. 6.5.1).
Данные конфигурации (см. С.5.3), если применимы.
Калибровочные данные (см. С.5.4), если применимы | 8.5.1 Спецификация проекта модуля программного обеспечения.
8.5.2 Реализация модуля программного обеспечения |
9 Верификация модуля программного обеспечения | Цели настоящей подстадии следующие:
a) предоставить доказательства того, что проект модуля программного обеспечения удовлетворяет распределенным требованиям программного обеспечения и подходит для реализации;
b) подтвердить, что определенные меры безопасности, полученные в результате анализа безопасности в соответствии с 7.4.10 и 7.4.11, выполнены надлежащим образом;
c) предоставить доказательства того, что реализованный модуль программного обеспечения соответствует проекту модуля и распределенным требованиям программного обеспечения с требуемым значением УПБТС;
d) предоставить достаточные доказательства того, что модуль программного обеспечения не реализует ни нежелательных функций, ни нежелательных свойств, влияющих на функциональную безопасность | Спецификация аппаратно-программного интерфейса (уточненная) (см. 6.5.2).
Спецификация архитектуры программного обеспечения (см. 7.5.1).
Спецификация проекта модуля программного обеспечения (см. 8.5.1).
Реализация модуля программного обеспечения (см. 8.5.2).
Данные конфигурации (см. 6.5.3), если применимы.
Калибровочные данные (см. С.5.4), если применимы.
Отчет по анализу безопасности (см. 7.5.2). Документация на среду разработки программного обеспечения (см. 5.5.1) | 9.5.1 Спецификация верификации программного обеспечения.
9.5.2 Отчет о верификации программного обеспечения (уточненный) |
10 Интеграция и верификация программного обеспечения | Цели настоящей подстадии следующие:
a) определить этапы интеграции и интегрировать элементы программного обеспечения до полной интеграции встроенного программного обеспечения;
b) проверить, что определенные меры безопасности, полученные из анализа безопасности на уровне архитектуры программного обеспечения, реализованы надлежащим образом;
c) предоставить доказательства того, что интегрированные модули программного обеспечения и компоненты программного обеспечения удовлетворяют требованиям, которые определены для них в архитектуре программного обеспечения;
d) предоставить достаточные доказательства того, что интегрированное программное обеспечение не реализует ни нежелательных функций, ни нежелательных свойств, влияющих на функциональную безопасность | Спецификация аппаратно-программного интерфейса (уточненная) (см. 6.5.2). Спецификация архитектуры программного обеспечения (см. 7.5.1). Отчет по анализу безопасности (см. 7.5.2). Отчет по анализу зависимых отказов (см. 7.5.3).
Реализация модуля программного обеспечения (см. 8.5.2).
Данные конфигурации (см. С.5.3), если применимы.
Калибровочные данные (см. С.5.4), если применимы.
Документация на среду разработки программного обеспечения (см. 5.5.1).
Спецификация верификации программного обеспечения (см. 9.5.1) | 10.5.1 Спецификация верификации программного обеспечения (уточненная).
10.5.2 Встроенное программное обеспечение.
10.5.3 Отчет о верификации программного обеспечения (уточненный) |
11 Тестирование встроенного программного обеспечения | Цель данной подстадии - представить свидетельства, что встроенное программное обеспечение:
a) выполняет требования безопасности при реализации в целевой среде;
b) не реализует ни нежелательных функций, ни нежелательных свойств, влияющих на функциональную безопасность | Спецификация архитектуры программного обеспечения (см. 7.5.1).
Спецификация требований безопасности программного обеспечения (уточненная) (см. 6.5.1).
Встроенное программное обеспечение (см. 10.5.2).
Калибровочные данные (см. С.5.4), если применимы.
Документация на среду разработки программного обеспечения (см. 5.5.1).
Спецификация верификации программного обеспечения (уточненная) (см. 10.5.1) | 11.5.1 Спецификация верификации программного обеспечения (уточненная).
11.5.2 Отчет о верификации программного обеспечения (уточненный) |
Приложение C. Конфигурация программного обеспечения | Цели конфигурации программного обеспечения заключаются в следующем:
а) обеспечить управление изменениями при функционировании программного обеспечения для различных приложений;
б) представить доказательства того, что данные о конфигурации и калибровочные данные соответствуют требованиям, предъявляемым к УПБТС;
в) предоставить доказательства того, что встроенное программное обеспечение для конкретного приложения и его калибровочные данные подходят для запуска в производство | См. применяемые предварительные требования соответствующих стадий жизненного цикла системы безопасности, в которых применяется конфигурирование программного обеспечения | С.5.1 Спецификация данных о конфигурации.
С.5.2 Спецификация данных о калибровке.
С.5.3 Данные о конфигурации.
С.5.4 Данные о калибровке.
С.5.5 Спецификация верификации (уточненная).
С.5.6 Отчет о верификации (уточненный).
С.5.7 Спецификация архитектуры программного обеспечения (уточненная).
С.5.8 Документация о среде разработки программного обеспечения (уточненная) |
Приложение B
(справочное)
Подходы к разработке, основанной на моделировании
B.1 Цели
В настоящем приложении разъясняются возможные преимущества использования и потенциальные проблемы подходов к разработке, основанной на моделировании (РОМ), используемых в процессе разработки на уровне программного обеспечения.
Примечание - Настоящее приложение не подразумевает, что подходы к разработке, основанной на моделировании, ограничиваются только разработкой программного обеспечения.
B.2 Общие положения
В настоящем подразделе представлена информация, которая является общей для различных случаев использования РОМ (например, при спецификации требований, проектировании, верификации/тестировании). Подраздел B.3 содержит анализ конкретных случаев, основанный на приведенных в качестве примеров сценариях использования.
В.2.1 Введение
Модели могут использоваться для отображения информации или представлений информации, требуемой на стадии разработки, а также для абстрактного проектирования и реализации одного или нескольких элементов программного обеспечения или среды программного обеспечения. Сами модели могут состоять из описаний моделируемого объекта на различных иерархических уровнях детализации или из ссылок на уточненные модели на более низком иерархическом уровне (например, иерархическая структура с представлениями в виде "черного ящика" и "белого ящика" для каждого элемента модели). Модель разрабатывается с использованием языка моделирования.
Языки моделирования могут быть графическими и/или текстовыми. Они могут быть формальными (например, язык на основе формальных математических определений) или полуформальными (например, структурированный язык с не полностью определенной семантикой). Языки моделирования могут быть описаны в международных стандартах (например, UML®) или быть принятыми в компании. Обычно их описание основано на таких понятиях, как классы, блок-схемы, схемы управления или диаграммы состояний (описывающие состояния и переход между состояниями). В настоящем приложении рассматриваются только те модели и языки моделирования, в которых определенны синтаксис и семантика, соответствующие их предполагаемому использованию (т.е. рисунки, используемые в качестве примера, без таких определений не рассматриваются в качестве моделей). Помимо конкретных причин использования РОМ (например, для имитационного моделирования или генерации кода), правильно определенные синтаксис и семантика являются основой для достижения таких критериев, как полнота, однозначность, корректность, согласованность и верифицируемость информации или результатов работы, описанных моделями, особенно когда взаимодействуют несколько различных сторон.
Кроме самого языка моделирования руководства по моделированию и/или подходящие инструментальные средства являются средствами достижения правильно определенного синтаксиса, семантики и соблюдения руководств по моделированию.
Пример - Приведенные в руководствах соглашения по именованию или по стилю обеспечивают достижение таких критериев, как "понятность", в то время как выбор подмножеств языков, исключая неоднозначные конструкции, обеспечивает как "понятность", так и корректное преобразование и выполнение модели. При моделировании или преобразовании моделей подходящие моделирующие машины или генераторы кода могут дополнять требуемые семантики, такие как детерминированный порядок выполнения или преобразования, при наличии достаточных знаний о детальном функционировании моделирующих машин или генераторов кода.
В настоящем приложении рассматриваются следующие примеры использования подходов к разработке, основанной на моделировании:
- спецификация требований безопасности программного обеспечения (раздел 6 настоящего стандарта и раздел 6 ИСО 26262-8);
- разработка архитектуры программного обеспечения (раздел 7);
- проектирование и реализация модулей программного обеспечения с автоматической генерацией кода или без него (раздел 8);
- проектирование, реализация и интеграция компонентов программного обеспечения, включая автоматическую генерацию кода из моделей компонентов программного обеспечения (разделы 8, 9 и 10);
- верификация (статическая и/или динамическая) (разделы 9, 10 и 11).
B.2.2 Общие вопросы пригодности
Пригодность выбранного подхода к разработке, основанной на моделировании, для предполагаемого применения, включая методы моделирования, обозначения, языки или инструментальные средства, может оцениваться по таким вопросам, как:
- достижение критериев, предусмотренных серией стандартов ИСО 26262, для соответствующего этапа разработки (например, понятность, полнота, верифицируемость, однозначность, точность) при выбранном(ых) подходе(ах);
- знания и опыт работы с выбранным(и) подходом(ами);
- адекватность определения синтаксиса и семантики;
- адекватность предметной области приложения (например, функционирование в реальном времени, соответствие структур данных, генерация программного обеспечения для микроконтроллера с фиксированной точкой и с плавающей точкой);
- роль модели в жизненном цикле программного обеспечения (например, разработка требований безопасности, выражающих статические или динамические характеристики проектов архитектуры);
- обеспечение управления сложностью путем соблюдения принципов абстракции, инкапсуляции, иерархии и модульности;
- моделирование сотрудничества между внутренними/внешними партнерами по разработке (например, согласованность данных в процессе обмена данными);
- требуемое и реально имеющееся доверие к программным инструментальным средствам (см. раздел 11 ИСО 26262-8);
- квалификация компонентов программного обеспечения (например, программных библиотек), используемых в рамках выбранного подхода РОМ или включенных в среду РОМ (см. раздел 12 ИСО 26262-8).
B.2.3 Возможное влияние РОМ на жизненный цикл программного обеспечения
Модель может быть использована для представления ряда результатов работы, описанных в настоящем стандарте (например, разработки требований, проекта архитектуры, детального проекта и интеграции программного обеспечения на основе модели с генерацией кода). По сравнению с традиционным процессом разработки программного обеспечения с четким разделением стадий при разработке на основе модели можно отметить более тесное объединение стадий "Требования безопасности программного обеспечения", "Архитектура программного обеспечения", "Проектирование и реализация программного обеспечения" и т.д. Возможные преимущества рассматриваемого подхода (например, непрерывность, обмен информацией на протяжении всего жизненного цикла разработки программного обеспечения, согласованность) достаточно привлекательны, но этот подход может также вызвать проблемы, связанные с появлением систематических сбоев (см. B.3).
B.3 Обсуждение примеров использования РОМ при разработке программного обеспечения
В настоящем подразделе приводится обсуждение преимуществ и возможных проблем, основанное на примерах использования.
B.3.1 Спецификация требований безопасности программного обеспечения (раздел 6 настоящего стандарта и раздел 6 ИСО 26262-8)
Модели могут использоваться для представления функциональных возможностей, функционирования, проекта или свойств программного обеспечения, которые должны быть реализованы с учетом требований безопасности (например, разомкнутый или замкнутый контур управления, управляемые системы, состояния и переходы, функции мониторинга или свойства независимости), а также для верификации и валидации требований с помощью имитационных или формальных методов.
Модели могут быть удобными средствами для достижения характеристик требований безопасности и являются средствами, которые удовлетворяют требованиям использования полуформальных или формальных нотаций, как указано в разделе 6 ИСО 26262-8.
Пример - При определении конечного автомата, используя подход, основанный на модели, соответствующая модель фиксирует требуемые состояния и переходы интуитивно понятным и однозначным образом. Удобно то, что такая модель представляет более одного элементарного требования по сравнению с текстовой спецификацией того же конечного автомата. Надлежащим обоснованием является то, что для рассматриваемой цели полноту, верифицируемость и внутреннюю согласованность спецификации можно лучше всего достигнуть и обеспечить в модели без дублирования информации.
Однако следует иметь в виду, что при использовании моделей требований можно упустить требования безопасности, которые не могут быть выражены с помощью выбранного подхода к разработке, основанного на моделировании. По этой причине в разделе 6 ИСО 26262-8 обращается особое внимание на соответствующее сочетание текстовых требований и других нотаций.
Пример - Требования, связанные с робастностью программного обеспечения при отсутствии или ошибочности входов.
B.3.2 Разработка архитектуры программного обеспечения (раздел 7)
Модели могут использоваться для представления архитектуры программного обеспечения, в частности для описания ее:
a) статических свойств (например, компонентов, их интерфейсов и потоков данных, атрибутов компонентов);
b) динамических свойств (например, функциональной последовательности событий, планирования, передачи сообщений).
Модели вместе с руководствами по моделированию могут быть удобными средствами для достижения свойств и реализации принципов для проектов архитектуры, связанных с безопасностью, и являются средствами, которые удовлетворяют требованиям использования полуформальных или формальных нотаций, как указано в разделе 7.
Однако следует иметь в виду, что один подход к моделированию может не отражать все требуемые свойства, например модели, нацеленные на реализацию функций программного обеспечения, часто не описывают весь проект архитектуры, включающий элементы базового программного обеспечения или операционной системы), а также модель может быть не вполне понятной без дополнительных текстовых объяснений (например, для различных сотрудничающих сторон).
B.3.3 Проектирование и реализация модулей программного обеспечения (разделы 8 и 9)
Модели вместе с руководствами по моделированию и кодированию могут использоваться для разработки детального проекта и самого модуля программного обеспечения на более высоком уровне абстракции. При использовании РОМ исполняемый код может быть получен непосредственно из модели путем генерации кода.
РОМ обеспечивает автоматическую проверку согласованности (например, типизации данных, корректности данных перед использованием) и верификацию формальными методами, имитационное моделирование, статический анализ или тестирование модулей программного обеспечения с моделью в контуре обратной связи либо с программой в контуре обратной связи. В зависимости от доверия к генерации кода (см. раздел 11 ИСО 26262-8) автоматическое формирование кода из модели может снизить риск ошибок кодирования по сравнению с ручным кодированием.
Однако следует иметь в виду, что:
- свойства проекта, которые не могут быть выражены нотациями моделирования, могут быть не охвачены, если они не были документально оформлены в какой-либо другой подходящей форме. Даже тестирование модуля (например, с использованием сравнительного теста) может их не обнаружить, если все тесты получены только на основе такой "неполной" модели;
- свойства кода, связанные с безопасностью, такие как робастность, могут быть не реализованы, если моделируется только предполагаемая функция. Свойства кода часто достигаются соответствующей комбинацией свойств модели и свойств генерации кода (например, если деление генерируется генератором кода "как есть", то предотвращение деления на ноль будет проверяться на уровне модели. Если генератор кода обрабатывает деление на ноль с помощью надежного шаблона проектирования, то проблема деления на ноль в модели может быть нивелирована);
- сбои могут появиться в результате некорректной адресации или особенностей обработки численной точности (например, если модель непосредственно унаследована из теории управления). Например, проблемы, связанные с различными свойствами точности компьютерной среды инженера по управлению и целевой среды;
- сбои могут появиться при создании дискретных моделей функционирования программного обеспечения из непрерывных моделей (например, влияние дискретизации значений и/или времени, время выполнения вычислений, обработка параллельных задач);
- результаты моделирования или верификации (например, результаты проверок согласованности) могут зависеть от инструментальных средств, поскольку различные механизмы моделирования или средства проверки модели могут быть реализованы семантически по-разному (например, семантики языка моделирования не предназначены для решения алгоритмических проблем);
- использование ресурсов в случае автоматического кодирования (время выполнения и используемая память) может отличаться от их использования при ручном кодировании. Кроме того, возможности средств оптимизации ресурсов могут быть более ограниченными;
- в случае автоматического кодирования довольно трудно обеспечить верификацию эквивалентности сгенерированного исходного кода и ручного кода.
B.3.4 Проектирование, реализация и интеграция компонентов программного обеспечения, включая автоматическое формирование кода из моделей компонентов программного обеспечения (разделы 8, 9 и 10)
Модели вместе с руководствами по моделированию и кодированию могут использоваться для проектирования, реализации и интеграции программного обеспечения на более высоком уровне абстракции. Таким образом, программные компоненты или даже встроенное программное обеспечение могут быть реализованы посредством генерации кода из интегрированной модели.
Данный подход предполагает тесное взаимодействие различных стадий разработки программного обеспечения, и поэтому преимущества такого подхода по сравнению с возможными проблемами должны быть тщательно оценены (см. указания, приведенные выше), включая реализацию соответствующих мер безопасности (например, использование отдельных моделей испытаний для получения дополнительных тестовых сценариев).
В.3.5 Верификация (статическая и/или динамическая) (разделы 9, 10 и 11)
Модели могут служить средством верификации результатов работ (например, модель проекта, код). Такая модель называется моделью верификации. Модели верификации могут использоваться, например, в качестве основы для сравнительного тестирования, создания тестовых сценариев или для представления свойств, связанных с безопасностью, в качестве основы для формальной верификации (так как для этого требуется, чтобы модель для верификации также была формальной).
Модели также могут служить средством для обеспечения возможностей или обеспечения действий по верификации (например, модель объекта, необходимая для тестирования с аппаратными средствами в контуре систем управления с обратной связью путем имитации среды тестируемого устройства).
Использование моделей для целей верификации может позволить раннее и эффективное обнаружение сбоев/отказов в результатах работы (включая программное обеспечение), более эффективное формирование тестовых сценариев, высокоавтоматизированное тестирование или даже применение формальных методов верификации.
Однако следует иметь в виду, что:
- без доказательств пригодности модели, используемой для целей верификации, достоверность соответствующих результатов может быть сомнительной (например, неадекватные модели объекта могут привести к некорректным результатам испытаний);
- для обеспечения достоверных результатов зрелость модели верификации должна соответствовать целевой зрелости объекта верификации;
- тестовые сценарии, созданные на основе модели, которая также используется для генерации кода, не могут служить единственным источником для верификации как самой модели, так и кода, созданного на ее основе.
Приложение C
(обязательное)
Конфигурация программного обеспечения
C.1 Цели
Цели конфигурации программного обеспечения заключаются в следующем:
a) обеспечить управление изменениями при функционировании программного обеспечения для различных приложений;
b) представить доказательства того, что данные о конфигурации и калибровочные данные соответствуют требованиям, предъявляемым к УПБТС;
c) предоставить доказательства того, что встроенное программное обеспечение для конкретного приложения и его калибровочные данные подходят для запуска в производство.
C.2 Общие положения
Конфигурация программного обеспечения позволяет разработку конкретного прикладного программного обеспечения с использованием данных о конфигурации и данных о калибровке (см. рисунок C.1).
|
 |
Рисунок C.1 - Создание конкретного прикладного программного обеспечения (ПО)
C.3 Входная информация
C.3.1 Предварительные требования
Предварительные требования определяются согласно соответствующим стадиям, в которых применяется конфигурирование программного обеспечения.
C.3.2 Дополнительная информация
Используется применимая дополнительная информация соответствующих стадий, в которых применяется конфигурирование программного обеспечения.
C.4 Требования и рекомендации
C.4.1 Чтобы в процессе жизненного цикла систем безопасности обеспечить корректное использование конфигурируемого программного обеспечения, должны быть определены данные о конфигурации. Они должны включать в себя следующее:
a) допустимые значения данных о конфигурации;
b) цель и использование данных о конфигурации;
c) диапазон, масштаб, единицы измерения;
d) взаимозависимость между различными элементами данных о конфигурации.
C.4.2 Должна быть выполнена верификация данных о конфигурации и их спецификации в соответствии с требованиями раздела 9 ИСО 26262-8 для подтверждения того, что:
a) данные о конфигурации соответствуют спецификации архитектуры программного обеспечения согласно 7.5.1 и спецификации проекта модуля программного обеспечения согласно 8.5.1;
b) значения используются в заданном для них диапазоне;
c) существует совместимость с другими конфигурационными данными.
Примечание - Тестирование конфигурируемого программного обеспечения осуществляется на стадиях тестирования жизненного цикла программного обеспечения (см. разделы 9, 10, 11 настоящего стандарта и раздел 7 ИСО 26262-4).
C.4.3 Значение УПБТС данных о конфигурации должно быть равно наибольшему значению УПБТС конфигурируемого программного обеспечения, в котором эти данные используются.
C.4.4 Согласно требованиям раздела 9 ИСО 26262-8 конфигурируемое программное обеспечение должно быть верифицировано с конфигурационными данными, которые предназначены для применения в разрабатываемом устройстве.
Примечание - На соответствие набору данных о конфигурации верифицируется только та часть встроенного программного обеспечения, функционирование которой зависит от данных о конфигурации.
C.4.5 Для конфигурируемого программного обеспечения может быть применен упрощенный жизненный цикл программного обеспечения системы безопасности в соответствии с рисунками C.2 или C.3.
Примечание - Полную верификацию сконфигурированного программного обеспечения можно достигнуть с помощью комбинации следующих действий по верификации:
a) верификация конфигурируемого программного обеспечения;
b) верификация данных о конфигурации;
c) верификация сконфигурированного программного обеспечения.
Это достигается:
- верификацией диапазона допустимых данных о конфигурации при выполнении верификации, указанной в перечислении a), и демонстрацией соответствия этому диапазону выполнением верификации, указанной в перечислении b); либо
- демонстрацией соответствия диапазона допустимых данных о конфигурации, выполнением верификации, указанной в перечислении b), и выполнением верификации, указанной в перечислении c).
|
 |
Рисунок C.2 - Варианты базовой модели стадии разработки программного обеспечения с конфигурируемым программным обеспечением (ПО) и различными данными о конфигурации и различными данными о калибровке
|
 |
Рисунок C.3 - Варианты базовой модели стадии разработки программного обеспечения с конфигурируемым программным обеспечением (ПО) с одинаковыми данными о конфигурации и различными данными о калибровке
С.4.6 Чтобы обеспечить корректное функционирование и ожидаемые характеристики конфигурируемого программного обеспечения, должны быть определены данные о калибровке, связанные с компонентами программного обеспечения. Они должны включать в себя следующее:
a) допустимые значения данных о калибровке;
b) цель и использование данных о калибровке;
c) диапазон, масштаб и единицы измерения, если применимы, с их зависимостью от рабочего состояния;
d) известные взаимозависимости между различными данными о калибровке.
Примечание - Между данными о калибровке в рамках одного набора калибровочных данных или между данными о калибровке в разных наборах калибровочных данных могут существовать взаимозависимости такие же, как и для связанных с ними функций, реализованных в программном обеспечении отдельных ЭБУ;
e) известные взаимозависимости между данными о конфигурации и данными о калибровке.
Примечание - Данные о конфигурации могут оказать влияние на сконфигурированное программное обеспечение, которое использует данные о калибровке.
C.4.7 Значение УПБТС данных о калибровке должно быть равно наибольшему значению УПБТС требований безопасности к программному обеспечению, которое может быть нарушено этими данными.
C.4.8 В соответствии с требованиями раздела 9 ИСО 26262-8 определение калибровочных данных должно быть проверено для подтверждения того, что:
a) указанные калибровочные данные являются подходящими и соответствуют требованиям безопасности программного обеспечения в соответствии с 6.5.1;
b) указанные калибровочные данные соответствуют спецификации архитектуры программного обеспечения в соответствии с 7.5.1 и спецификации проекта модуля программного обеспечения в соответствии с 8.5.1;
c) указанные калибровочные данные согласуются и совместимы со спецификацией других калибровочных данных для предотвращения непреднамеренного воздействия.
C.4.9 Калибровочные данные, выпущенные для производства, должны быть верифицированы в соответствии с требованиями раздела 9 ИСО 26262-8 для подтверждения того, что:
a) выпущенные калибровочные данные соответствуют их спецификации (см. C.4.6);
b) калиброванный, специальный для приложения вариант встроенного программного обеспечения реализует определенные функциональные возможности и свойства, связанные с безопасностью.
Примечание - Верификация калибровочных данных также может быть выполнена на уровне системы.
C.4.10 Для обнаружения непреднамеренных изменений связанных с безопасностью данных о калибровке должны применяться механизмы для обнаружения непреднамеренных изменений данных, указанные в таблице C.1.
Таблица С.1 - Механизмы для обнаружения непреднамеренного изменения данных
|
|
|
|
|
|
Методы | УПБТС | ||||
| A | B | C | D | |
1a | Проверка достоверности калибровочных данных | ++ | ++ | ++ | ++ |
1b | Резервное хранение и сравнение калибровочных данных | + | + | + | ++ |
1c | Проверка калибровочных данных с использованием кодов обнаружения ошибок | + | + | + | ++ |
Коды обнаружения ошибок также могут быть реализованы аппаратно в соответствии с ИСО 26262-5. | |||||
C.4.11 При формировании и применении данных о калибровке должны быть определены:
a) процедуры, которые должны соблюдаться;
b) инструментальные средства для создания калибровочных данных;
c) процедуры верификации данных о калибровке.
Примечание - Верификация данных о калибровке может включать в себя проверку диапазонов значений данных о калибровке или проверку взаимозависимости между различными данными о калибровке.
С.5 Результаты работы
С.5.1 Спецификация данных о конфигурации
В результате выполнения требований С.4.1-С.4.4.
С.5.2 Спецификация данных о калибровке
В результате выполнения требований С.4.6-С.4.8.
С.5.3 Данные о конфигурации
В результате выполнения требований С.4.2-С.4.4.
С.5.4 Данные о калибровке
В результате выполнения требований С.4.7-С.4.10.
С.5.5 Спецификация верификации (уточненная)
В результате выполнения требований С.4.2, С.4.4, С.4.5, С.4.7, С.4.8, С.4.10 и С.4.11.
С.5.6 Отчет о верификации (уточненный)
В результате выполнения требований С.4.2, С.4.4, С.4.5, С.4.7, С.4.8, С.4.10 и С.4.11.
С.5.7 Спецификация архитектуры программного обеспечения (уточненная)
В результате выполнения требований С.4.10.
С.5.8 Документация о среде разработки программного обеспечения (уточненная)
В результате выполнения требований С.4.1-С.4.11.
Приложение D
(справочное)
Устранение влияния между элементами программного обеспечения
D.1 Цели
Цель настоящего приложения состоит в том, чтобы привести примеры сбоев, которые могут вызвать взаимное влияние между элементами программного обеспечения (например, между элементами программного обеспечения различных разделов программного обеспечения). Кроме того, данное приложение рассматривает примеры возможных механизмов для предотвращения или обнаружения и смягчения последствий вышеупомянутых ошибок.
Примечание - Возможности и эффективность механизмов, используемых для предотвращения или обнаружения и смягчения соответствующих сбоев, оцениваются в процессе разработки.
D.2 Общие положения
D.2.1 Достижение отсутствия взаимного влияния
Для обеспечения или оценки устранения взаимного влияния между элементами программного обеспечения могут быть рассмотрены последствия типовых сбоев и распространение отказов, которые могут при этом возникать.
D.2.2 Временная согласованность и выполнение
При временных ограничениях для элементов программного обеспечения, выполняемых в каждом разделе программного обеспечения, могут быть рассмотрены последствия следующих сбоев:
- блокирование выполнения;
- взаимоблокировки;
- динамические взаимоблокировки;
- некорректное распределение времени выполнения;
- некорректная синхронизация между элементами программного обеспечения.
Пример - Могут быть рассмотрены такие механизмы, как: диспетчеризация циклического выполнения; диспетчеризация на основе фиксированного приоритета; диспетчеризация, управляемая по времени; мониторинг времени работы процессора; мониторинг последовательности выполнения программы и мониторинг интенсивности входного потока.
D.2.3 Память
При доступе к памяти для элементов программного обеспечения, выполняемых в каждом разделе программного обеспечения, могут быть рассмотрены последствия следующих сбоев:
- повреждение содержания памяти;
- противоречие данных (например, из-за обновления во время выборки данных);
- переполнение или исчерпание стека;
- доступ к памяти по чтению или записи, выделенной для другого элемента программного обеспечения.
Примеры
1 Могут быть использованы такие механизмы, как: защита памяти, биты четности, код с исправлением ошибок (ЕСС), контроль циклическим избыточным кодом (CRC), резервное хранение, ограниченный доступ к памяти, статический анализ доступа к памяти программного обеспечения и статическое распределение.
2 В качестве подробного анализа безопасности для определения критически важных блоков памяти, для которых используются механизмы защиты, могут рассматриваться соответствующие методы верификации. Результаты анализа статического и семантического кода, анализа потока управления и потока данных могут служить доказательством для демонстрации отсутствия влияния.
D.2.4 Обмен информацией
При обмене информацией для каждого отправителя или каждого получателя допускается рассматривать перечисленные ниже причины сбоев или их последствия:
- повторение информации;
- потеря информации;
- задержка информации;
- ввод информации;
- нелегальное проникновение или некорректная адресация информации;
- некорректная последовательность информации;
- повреждение информации;
- асимметричная информация, посланная от отправителя к нескольким получателям;
- информация от отправителя, полученная только подмножеством получателей;
- блокирование доступа к каналу связи.
Примечание - Обмен информацией между элементами, выполняемый в разных разделах программного обеспечения или в различных электронных блоках управления, включает сигналы, данные, сообщения и т.д.
Примеры
1 Для обмена информацией можно использовать устройства В/В, шины данных и т.д.
2 Могут быть использованы такие механизмы, как: протоколы связи, повторная передача информации, обратная передача данных, подтверждение приема информации, соответствующая конфигурация штырьков В/В, раздельные однонаправленные объекты коммуникации между двумя узлами, непротиворечивые двусторонние объекты коммуникации, асинхронная передача данных, синхронная передача данных, управляемые событиями шины данных, управляемые событиями шины данных с доступом, управляемым по времени, управляемые по времени шины данных, минисегментирование и управление доступом к шине по приоритету.
3 Коммуникационные протоколы могут содержать такую информацию, как идентификаторы для объектов коммуникации, подтверждающие активность сообщения, активные счетчики, порядковые номера, коды для обнаружения ошибок и коды с исправлением ошибок.
4 В качестве подробного анализа безопасности для определения критически важного обмена данными, для которого используются механизмы защиты, могут рассматриваться соответствующие методы верификации. Результаты статического и семантического анализа кода, анализа потока управления и потока данных могут служить доказательством для демонстрации устранения влияния.
Приложение E
(справочное)
Применение анализа безопасности и анализа зависимых отказов на уровне архитектуры программного обеспечения
E.1 Цели
В настоящем приложении разъясняется возможное применение анализа безопасности и анализа зависимых отказов на уровне архитектуры программного обеспечения. Примеры, приведенные в настоящем приложении, призваны содействовать пониманию этих видов анализа и служить руководством для их применения.
E.2 Общие положения
E.2.1 Область применения и цель анализа
С помощью анализа безопасности или анализа зависимых отказов на уровне архитектуры программного обеспечения проверяется или подтверждается способность встроенного программного обеспечения выполнять определенные функции, демонстрируя при этом заданное функционирование и свойства с требуемой полнотой безопасности, соответствующей назначенному значению УПБТС.
Пригодность встроенного программного обеспечения для выполнения заданных функций и свойств с требуемой полнотой безопасности, соответствующей назначенному значению УПБТС, проверяется:
- выявлением возможных недостатков проектирования, условий, сбоев или отказов проекта, которые могут вызвать последовательность событий, приводящих к нарушению требований безопасности (например, с использованием индуктивного или дедуктивного метода); и
- анализом последствий возможных сбоев, отказов или последовательностей вызовов для функций и свойств, требуемых для элементов архитектуры программного обеспечения.
Достигнутый уровень независимости или отсутствия влияния между соответствующими элементами архитектуры программного обеспечения проверяется путем анализа архитектуры программного обеспечения с учетом зависимых отказов, т.е. проверяются:
- возможные единичные события, сбои или отказы, которые могут вызвать некорректное функционирование двух и более элементов программного обеспечения, которые должны функционировать независимо друг от друга (например, каскадные и/или отказы по общей причине, включая отказы общего вида); и
- возможные единичные события, сбои или отказы, которые могут распространяться от одного элемента программного обеспечения к другому, вызывая причинно-следственные цепочки событий, приводящих к нарушению требований безопасности (например, каскадные отказы).
Обеспечение независимости или устранение влияния между элементами архитектуры и программного обеспечения может потребоваться для:
- применения декомпозиции УПБТС на уровне программного обеспечения (см. 6.4.3);
- выполнения требований безопасности программного обеспечения (см. 7.4.11), например для подтверждения эффективности программных механизмов безопасности, таких как независимость между контролируемым элементом и средством контроля; или
- требуемой совместимости элементов архитектуры программного обеспечения (см. 7.4.6, 7.4.8 и 7.4.9 настоящего стандарта и раздел 6 ИСО 26262-9).
Роль анализа безопасности и анализа зависимых отказов на уровне архитектуры программного обеспечения обеспечивают как спецификация проекта, так и действия по верификации проекта.
Такой анализ может также выявить неполноту или несоответствия в заданных требованиях безопасности.
Результаты анализа безопасности и анализа зависимых отказов на уровне архитектуры программного обеспечения также являются основой для:
- спецификации и внедрения эффективных механизмов безопасности в изделии; или
- определения надлежащих мер безопасности на этапе разработки, которые подходят либо для предотвращения, либо для обнаружения и управления соответствующими сбоями или отказами, выявленными в ходе этих анализов.
На рисунке E.1 показана роль анализа безопасности на уровне архитектуры программного обеспечения в процессе разработки программного обеспечения, а также основные взаимосвязи или взаимодействия между требованиями безопасности программного обеспечения, архитектурой программного обеспечения и планом безопасности.
|
 |
Рисунок E.1 - Иллюстрация роли анализа, ориентированного на безопасность программного обеспечения в процессе его разработки
Пример - Рисунок E.2 иллюстрирует влияние, вызванное конфликтующим использованием разделяемого ресурса (например, общего элемента обработки). Как показано на рисунке E.2, программный компонент уровня QM оказывает влияние и предотвращает своевременное выполнение элемента программного обеспечения с заданным значением УПБТС. Аналогичное влияние может также возникать между компонентами программного обеспечения с различными значениями УПБТС. Настоящий рисунок иллюстрирует влияние на выполнение программ имеющих и не имеющих механизмов устранения влияния. Вводя в программу "контрольные точки" и реализуя контроль времени прохождения контрольных точек, можно обнаружить влияние на время выполнения и инициировать подходящую реакцию.
|
 |
Рисунок E.2 - Пример влияния на временные характеристики, приводящего к каскадному отказу
Анализ безопасности и анализ зависимых отказов предназначены для применения на уровне архитектуры программного обеспечения. Анализ безопасности на уровне кода (например, ошибок во время выполнения, таких как деление на ноль, доступ за пределы границ индекса массива) не требуется и не считается необходимым по следующим причинам:
- остаточный риск для этих типов сбоев можно считать достаточно низким при условии тщательного применения подхода к разработке программного обеспечения, описанного в настоящем стандарте, включающего выбор и применение подходящих методов; подходов и принципов разработки, таких как руководства по моделированию и программированию, правил проектирования и реализации, анализа моделей и/или кодов, семантического или статического анализа, модульного и интеграционного тестирования;
- эти типы сбоев при реализации соответствующих элементов архитектуры, как правило, вызывают такое же некорректное функционирование элемента на его интерфейсах, как это было выявлено в процессе анализа на уровне архитектуры. Поэтому анализ на более высоком уровне уже свидетельствует о том, что выбранные механизмы технической безопасности являются эффективными или что меры по обеспечению безопасности на этапе разработки являются достаточными для обеспечения адекватного обоснования.
E.2.2 Взаимосвязь между анализом безопасности и анализом зависимых отказов на уровне системы, аппаратных средств и программного обеспечения
Анализ безопасности и анализ зависимых отказов применяются на нескольких стадиях жизненного цикла разработки. Эти виды анализа могут быть связаны друг с другом.
При подходе, основанном на разделении, использованном на уровне системы, как правило, в результате разработки аппаратных средств обеспечивается то, что устройство обработки имеет достаточно низкий остаточный риск, связанный со сбоями аппаратных средств. Поэтому анализ безопасности программного обеспечения и анализ зависимых отказов программного обеспечения на уровне архитектуры программного обеспечения могут быть выполнены без учета аппаратных отказов.
Однако при некоторых условиях для аппаратных средств (например, недостаточная величина диагностического охвата случайных сбоев аппаратных средств элемента обработки, включая нестабильные сбои) может оказаться целесообразным учитывать негативное влияние аппаратных сбоев. В таких случаях выполняется конкретный анализ взаимодействия аппаратных средств и программного обеспечения, учитывающий, например:
- соответствие конкретного программного обеспечения с различными устройствами обработки многоядерных систем;
- детальное проектирование обрабатывающего элемента, на котором выполняется программное обеспечение, согласно статическим или динамическим аспектам архитектуры программного обеспечения; или
- достижимый диагностический охват выбранных механизмов безопасности программного обеспечения для программных отказов аппаратных средств.
Примечание - Анализ конкретного взаимодействия аппаратных средств и программного обеспечения может быть выполнен методами внесения дефектов (см. также 4.8 ИСО 26262-11).
E.2.3 Анализ безопасности в распределенной разработке программного обеспечения (включая разработку элементов программного обеспечения вне контекста - SEooC)
Встраиваемое программное обеспечение и его элементы часто реализуются несколькими организациями как распределенная разработка [включая изготовителя подлинного оборудования (OEM), его подрядчика (Tier 1), его субподрядчика (Tier 2), поставщика кремниевых ИС или поставщика программного обеспечения] и даже используя элементы безопасности вне контекста (например, базовое программное обеспечение, программное обеспечение, связанное с аппаратными средствами, коммерчески доступное программное обеспечение или операционные системы, разработанные как элементы безопасности вне контекста).
Важными задачами эффективного анализа безопасности при распределенной разработке программного обеспечения являются:
- определение и согласование области применения анализа и процедур или методов, используемых для проведения анализа, отдельно или совместно (включая обмен информацией/документацией или подтверждение допущений);
- определение и согласование общей ответственности за процесс анализа безопасности программного обеспечения и общих правил для участвующих организаций (например, для компонентов высокого уровня, правил доступа к ним);
- определение и согласование интерфейсов для анализа при использовании модульного подхода (например, согласованные модели отказов программного обеспечения на интерфейсах между различными областями применения, применяемый подход или обмениваемая информация/документы); и
- определение и согласование проверки результатов анализа.
E.3 Содержание анализа
Архитектура программного обеспечения содержит правила и решения высокого уровня (например, классификацию компонентов функциональной безопасности, правила доступа между компонентами), которые обеспечивают реализацию и обоснование достижения функциональной безопасности.
Общими составными частями эффективного анализа являются определения:
- цели анализа - см. E.3.1;
- области применения и границы - см. E.3.2;
- метода, применяемого для проведения анализа, - см. E.3.3; и
- средств или критериев обеспечения информативности, объективности и строгости анализа - см. E.3.4.
E.3.1 Определение целей анализа
Цели предусмотрены разделом 7 настоящего стандарта и разделами 7 и 8 ИСО 26262-9.
Пример - Нарушение связанных с безопасностью функций или свойств, назначенных программному обеспечению, находится в области применения анализа, такого как анализ робастности или анализ детерминированного времени выполнения.
E.3.2 Определение области применения и границ анализа для конкретного проекта архитектуры
В зависимости от целей анализа определяется область его применения, в котором основное внимание уделяется соответствующим частям проекта архитектуры.
На область применения анализа могут влиять:
- соответствующая область применения поставки и распределенные обязанности, определенные в соглашении о разработке (DIA);
- конкретные цели анализа;
- стратегии архитектуры, основанные на зарекомендовавших себя на практике принципах проектирования (см. 7.4.3); или
- свойства, которые требуются от проекта архитектуры и которые задаются в концепции безопасности более высокого уровня, связанные с достижением достаточной независимости или с устранением влияния.
Примеры
1 В качестве аргумента того, что базовое программное обеспечение может рассматриваться как "черный ящик" при рассмотрении обмена связанными с безопасностью данными с внешними отправителями или получателями во время анализа безопасности, могут использоваться подходящие механизмы сквозной защиты данных.
2 Зависимости функций программного обеспечения от рабочих режимов, такие как связанная с безопасностью функция, которая является активной только в режиме, в котором другая критическая функция безопасно отключается функцией перехода в безопасный режим.
|
 |
Рисунок E.3 - Область применения анализа для обоснования безопасности
E.3.3 Определение метода, применяемого для проведения анализа
Из-за специфических особенностей программного обеспечения (например, отсутствие случайных отказов из-за износа или старения и отсутствие разработанного вероятностного метода) методы, разработанные для такого анализа на уровне системы или аппаратных средств, часто не могут быть без изменений использованы для программного обеспечения либо дать значимые результаты.
Общая структура методов анализа безопасности, как правило, состоит из средств обеспечения реализации структурированного подхода, хранения полученных знаний и формирования заключения.
Пример - Синтаксис и семантика для описания сбоев и их зависимостей в дереве отказов или сети функций, или списке элементов, или значения приоритетности риска, используемые в FMEA.
Основой для анализа безопасности и анализа зависимых отказов является архитектура программного обеспечения, описывающая статические характеристики (например, представленные блок-схемой, показывающей функциональные элементы и их интерфейсы/взаимосвязи), а также динамические характеристики (например, описанные упорядоченными, временными или представляющими состояния диаграммами) соответствующего программного обеспечения.
Анализ безопасности и анализ зависимых отказов в соответствии с архитектурой программного обеспечения могут быть реализованы как функциональные последовательности и/или как последовательности процессов, которые учитывают как статические, так и динамические характеристики. В ходе такого анализа для выявления связанных с безопасностью слабых сторон проекта могут использоваться модели сбоев программного обеспечения или такие вопросы, как: "Какой конкретный сбой или отказ, вызванный данным компонентом программного обеспечения или влияющий на него, может привести к нарушению установленных требований безопасности?"
Уточнения архитектуры программного обеспечения могут обеспечить возможность анализа безопасности и анализа зависимых отказов на требуемом уровне детализации, чтобы определить сбои или отказы на более низком уровне.
Уровень детализации, необходимый в ходе такого анализа, связан:
- с корректным выбором области применения при доработке проекта архитектуры;
- свойствами, обеспечивающими достижение конкретных целей анализов;
- обоснованием, основанным на стратегии архитектуры, подкрепленной "зарекомендовавшими себя на практике" принципами проектирования (см. 7.4.3); или
- обоснованием, основанным на достаточной независимости, включая достигнутое устранение влияния.
E.3.4 Аспекты, обеспечивающие информативность, объективность и строгость анализа
E.3.4.1 Классы факторов взаимовлияния для анализа зависимых отказов в соответствии с ИСО 26262-9
В приложении C ИСО 26262-9 определены классы факторов взаимовлияния с соответствующими примерами на уровне программного обеспечения, которые могут использоваться для улучшения результатов анализа зависимых отказов, выполняемого методами функциональных последовательностей или последовательностей процессов для программного обеспечения, к которому предъявляются требования независимости.
E.3.4.2 Содержание приложения D
Приложение D содержит модели сбоев программного обеспечения для анализа взаимного влияния между программными элементами, например:
- для временной согласованности и выполнения;
- памяти; или
- обмена информацией.
E.3.4.3 Анализ с использованием ключевых слов
Для систематического анализа возможных отклонений от определенного проектного замысла и их возможных последствий могут использоваться ключевые слова. Ключевые слова используются для формирования вопросов при проверке определенной функциональности или свойства элемента архитектуры при анализе безопасности. При использовании ключевых слов анализ безопасности отдельных функций или свойств каждого элемента проекта повторяется с каждым ключевым словом до тех пор, пока не будут проверены все заданные ключевые слова. Таким образом, ключевые слова являются средством систематического выполнения анализа и поддержки аргумента с точки зрения полноты.
Для описания функциональных аспектов архитектуры программного обеспечения часто используются диаграммы потока данных или аналогичные схемы (например, функциональные последовательности или последовательности процессов). На рисунке Е.4 показано взаимодействие программных компонентов Y, U и V и соответствующей функциональной последовательности или последовательности процессов (например, на основе потока данных).
Ключевые слова допускается использовать для выявления слабых мест, сбоев и отказов. Выбор подходящих ключевых слов зависит от характеристик исследуемых функций, их выполнения, свойств, интерфейсов или обмениваемых данных.
|
 |
Рисунок E.4 - Блок-схема архитектуры программного обеспечения
Исходя из цели проекта, ключевые слова формируются путем объединения атрибутов проекта, соответствующих ключевых слов и их интерпретации, чтобы достичь общего понимания для анализа. В таблице E.1 приведены примеры выбора ключевых слов, применяемых к проекту на рисунке E.4.
Таблица E.1 - Пример выбора ключевых слов, связанных с выполнением программного обеспечения, планированием или взаимодействием
|
|
|
|
Проверяемые функциональные возможности или свойства | Примеры для ключевых слов | Интерпретация | Дополнительные ссылки |
Поток сигналов  | После/ поздно | Слишком поздний сигнал или его нет в последовательности | В приложении D описываются соответствующие ситуации:
D.2.4 Задержка информации
D.2.4 Некорректная последовательность информации
D.2.4 Блокирование доступа к каналу связи
D.2.2 Блокирование выполнения
D.2.2 Взаимоблокировки
D.2.2 Динамические взаимоблокировки
D.2.2 Некорректное распределение времени выполнения
D.2.2 Некорректная синхронизация между элементами программного обеспечения |
Поток сигналов | Прежде/ рано | Слишком ранний сигнал или его нет в последовательности | В приложении D описываются соответствующие ситуации:
D.2.4 Некорректная последовательность информации
D.2.2 Некорректная синхронизация между элементами программного обеспечения |
| Нет | Нет сигнала | В приложении D описываются соответствующие ситуации:
D.2.2 Блокирование выполнения
D.2.2 Взаимоблокировки
D.2.2 Динамические взаимоблокировки
D.2.2 Некорректная синхронизация между элементами программного обеспечения |
Значения сигналов | Больше | Значение сигнала выше допустимого диапазона |
|
| Меньше | Значение сигнала не достигает допустимого диапазона |
|
Во время анализа ключевые слова допускается применять, используя дедуктивный или индуктивный подход. В ходе анализа при необходимости возможно дальнейшее уточнение ключевых слов (например, для лучшего соответствия конкретным аспектам проекта).
Таблица E.2 - Пример анализа, сопровождаемого ключевыми словами
|
|
|
|
|
Пример ключевого слова | Интерпретация | Последствие | Меры по обеспечению безопасности | Необходимые действия |
Больше | Значение сигнала выше допустимого диапазона | Ошибка на выходе функции О | Сторожевой модуль M ограничивает сигналы  до разрешенного максимального диапазона | Применение сторожевого модуля M |
Меньше | Значение сигнала не достигает допустимого диапазона | Ошибка на выходе функции О | Сторожевой модуль M ограничивает сигналы до разрешенного минимального диапазона | Применение сторожевого модуля M |
Отличающийся от | Значения сигналов не согласованы | Ошибка на выходе функции О | Сторожевой модуль M проверяет сигналы на согласованность, используя физические зависимости | Применение сторожевого модуля M |
E.4 Стратегия смягчения недостатков, выявленных в ходе анализа безопасности и анализа зависимых отказов
Результаты анализа безопасности и анализа зависимых отказов на уровне архитектуры программного обеспечения позволяют выбрать адекватные меры безопасности для предотвращения или обнаружения и управления последствиями сбоев и отказов, которые могут привести к нарушению требований безопасности или к недостижению целей безопасности.
Стратегия определения мер безопасности может учитывать следующее:
- критичность каждого выявленного сбоя исходя из того, может ли он привести к недостижению цели безопасности или нарушить требования безопасности, распределенные по элементам архитектуры, и назначенное для них значение УПБТС;
- может ли проект архитектуры быть доработан для устранения выявленных недостатков или снижения критичности выявленного сбоя;
- эффективность определенных мер безопасности, применяемых при разработке, и их способность в достаточной степени смягчить выявленный сбой, учитывая его критичность, с предоставлением соответствующего обоснования (например, обоснования эффективности определенных мероприятий по верификации с учетом используемой при анализе модели этого сбоя программного обеспечения);
- эффективность определенных механизмов безопасности для смягчения выявленных критических сбоев, для которых меры, принятые в процессе разработки, считаются недостаточными;
- сложность архитектуры программного обеспечения (например, количество интерфейсов и компонентов программного обеспечения) или компонентов программного обеспечения (например, количество назначенных требований или размер компонента).
Пример - Для более сложного программного обеспечения обоснование, основанное исключительно на мерах, принимаемых в процессе разработки, подходит меньше.
В соответствии с вышеуказанной стратегией не всегда необходимо внедрять механизмы безопасности, которые способны предотвращать или обнаруживать и управлять последствиями таких сбоев или отказов в процессе эксплуатации.
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.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-4:2018 | IDT | ГОСТ Р ИСО 26262-4-2021 "Дорожные транспортные средства. Функциональная безопасность. Часть 4. Разработка изделия на уровне системы" |
ISO 26262-5:2018 | IDT | ГОСТ Р ИСО 26262-5-2021 "Дорожные транспортные средства. Функциональная безопасность. Часть 5. Разработка изделия на уровне аппаратных средств" |
ISO 26262-7:2018 | - | * |
ISO 26262-8:2018 | - | * |
ISO 26262-9:2018 | - | * |
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта.
Примечание - В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов:
- IDT - идентичные стандарты. | ||
Библиография
|
|
[1] | ISO/IEC 12207:2008, Systems and software engineering - Software life cycle processes |
[2] | IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems |
[3] | MISRA-C:2012, Guidelines for the use of the С language in critical systems, ISBN 978-1-906400-10-1, MIRA, March 2013 |
[4] | MISRA AC AGC, Guidelines for the application of MISRA-C:2004 in the context of automatic code generation, ISBN 978-906400-06-4, MIRA, May 2009 |
[5] | ISO/IEC/IEEE 29119:2013 (all parts), Software and systems engineering - Software testing |
[6] | Bieman J.M., Dreilinger D., Lin L. "Using fault injection to increase software test coverage", in Software Reliability Engineering, 1996. Proceedings., Seventh International Symposium on, vol., no., pp.166-174, 30 Oct-2 Nov 1996 doi: 10.1109/ISSRE.1996.558776 |
[7] | Jia Y., Merayo M., Harman M. 2015 Introduction to the special issue on Mutation Testing. Softw. Test. Verif. Reliab., 25: 461-463 |
[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 |
| |
Ключевые слова: функциональная безопасность, жизненный цикл систем, транспортные средства, программируемые электронные компоненты и системы, программное обеспечение, разработка и верификация, архитектура программного обеспечения, модуль программного обеспечения | |
