ГОСТ Р ИСО 26262-6-2021 Дорожные транспортные средства. Функциональная безопасность. Часть 6. Разработка программного обеспечения изделия.
ГОСТ Р ИСО 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.
ИСО и МЭК для применения в стандартизации поддерживают терминологические базы данных:
- Электропедия МЭК; доступна по адресу: http://www.electropedia.org/
- платформа онлайн-просмотра ИСО; доступна по адресу: https://www.iso.org/obp.
4 Требования соответствия настоящему стандарту
4.1 Цель
Настоящий раздел описывает:
a) каким образом обеспечить соответствие требованиям серии стандартов ИСО 26262;
b) каким образом интерпретировать таблицы, используемые в серии стандартов ИСО 26262;
c) каким образом интерпретировать применимость каждого раздела в зависимости от соответствующего значения УПБА.
4.2 Общие требования
Для соответствия серии стандартов ИСО 26262 должно быть выполнено каждое ее требование, если только для этого требования не выполняется одно из следующих условий:
a) в соответствии с ИСО 26262-2 предусмотрена корректировка действий по обеспечению безопасности, которая показывает, что данное требование не применяется;
b) существует обоснование того, что несоблюдение данного требования допустимо, а также показано соответствие этого обоснования ИСО 26262-2.
Справочная информация, включая примечания и примеры, должна использоваться только для понимания или для уточнения соответствующего требования и не должна толковаться как самостоятельное требование или считаться для него полной или исчерпывающей.
Результаты действий по обеспечению безопасности представлены как результаты работы. В пунктах "Предварительные требования" перечисляется информация, которая должна быть доступна в результате выполнения предыдущей стадии. Так как некоторые требования разделов настоящего стандарта зависят от УПБТС или могут быть скорректированы, то некоторые результаты работы в качестве предварительных условий могут не потребоваться.
В пунктах "Дополнительная информация" содержится информация, которую можно учитывать, но в некоторых случаях настоящий стандарт не требует, чтобы она была результатом работы предыдущей стадии. Такая информация может быть доступна из внешних источников, от лиц или организаций, которые не несут ответственности за деятельность по обеспечению функциональной безопасности.
4.3 Интерпретация таблиц
В настоящем стандарте используются нормативные или справочные таблицы в зависимости от их контекста. Перечисленные в таблицах различные методы вносят вклад в уровень уверенности в достижении соответствия рассматриваемым требованиям. Каждый метод в таблицах включен:
a) в последовательный список методов (он обозначен порядковым номером в левой графе, например 1, 2, 3);
b) либо в альтернативный список методов (он обозначен номером с последующей буквой в левой графе, например 2a, 2b, 2c).
В случае последовательного списка для соответствующего значения УПБТС следует применять все наиболее рекомендуемые и рекомендуемые методы. Допускается замена наиболее рекомендуемого или рекомендуемого метода другим, не перечисленным в таблице методом, но в этом случае должно быть приведено обоснование, почему он удовлетворяет соответствующему требованию. Если может быть обосновано, что для удовлетворения соответствующему требованию не выбираются никакие методы, то в дальнейшем обоснование пропущенных методов не выполняют.
В случае альтернативного списка следует применять подходящую комбинацию методов в соответствии с указанным значением УПБТС независимо от того, перечислены ли в таблице эти комбинации или нет. Если перечисленные методы имеют разные степени рекомендуемости их применения для некоторого значения УПБТС, то следует отдать предпочтение методам с более высокой степенью рекомендуемости. Должно быть приведено обоснование, что выбранная комбинация методов или даже отдельно выбранный метод выполняют соответствующее требование.
Примечание - Обоснование, основанное на методах, перечисленных в таблице, является достаточным. Но это не означает, что существует какое-то предубеждение за или против применения методов, не перечисленных в таблице.
Для каждого метода степень рекомендуемости его применения зависит от значения УПБТС и классифицируется следующим образом:
- "++" - метод является наиболее рекомендуемым для определенного значения УПБТС;
- "+" - метод рекомендуется для определенного значения УПБТС;
- "о" - метод не имеет рекомендации за или против его применения для определенного значения УПБТС.
4.4 Требования и рекомендации, зависимые от значения УПБТС
Требования или рекомендации каждого подраздела необходимо соблюдать для значений УПБТС A, B, C и D, если не указано иное. Эти требования и рекомендации связаны со значениями УПБТС цели безопасности. Если в соответствии с требованиями раздела 5 ИСО 26262-9 декомпозиция УПБТС была выполнена на более ранней стадии разработки, то должны соблюдаться значения УПБТС, полученные в результате декомпозиции.
Если в настоящем стандарте значение УПБТС приведено в круглых скобках, то соответствующий пункт должен рассматриваться как рекомендация, а не требование для этого значения УПБТС. Это не касается приведенных в скобках записей, относящихся к декомпозиции УПБТС.
4.5 Адаптация к мотоциклам
Для устройств или элементов мотоциклов, для которых применимы требования ИСО 26262-12, эти требования могут быть использованы вместо соответствующих требований настоящего стандарта. Требования настоящего стандарта, которые заменяются требованиями ИСО 26262-12, определены в части 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® являются примерами подходящих продуктов, доступных на коммерческой основе. Эта информация приводится для удобства пользователей настоящего стандарта и не является рекомендацией ИСО для этих продуктов. | |||||
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.