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

Свойства		УПБТС
		A	B	C	D
1a	Применение низкой сложности <a>	++	++	++	++
1b	Использование подмножеств языков <b>	++	++	++	++
1c	Применение строгой типизации <c>	++	++	++	++
1d	Использование методов безопасного программирования <d>	+	+	++	++
1e	Использование проверенных принципов проектирования <e>	+	+	++	++
1f	Использование однозначного графического представления	+	++	++	++
1g	Использование правил оформления	+	++	++	++
1h	Использование соглашений об именовании	++	++	++	++
1i	Аспекты параллельного выполнения <f>	+	+	+	+
<a> Применение этого метода может потребовать нахождения компромисса с другими требованиями настоящего стандарта. <b> Целями метода 1b являются: - исключение неоднозначно определенных конструкций языка, которые могут быть по-разному интерпретированы различными разработчиками моделей, программистами, генераторами кодов или компиляторами; - исключение конструкций языка, которые, как показывает опыт, легко приводят к ошибкам, например присваивание в условиях или идентичность имен локальных и глобальных переменных; - исключение конструкций языка, которые могут привести к необрабатываемым ошибкам во время выполнения. <c> Цель метода 1c состоит в наложении принципов строгой типизации там, где они не присущи языку. <d> Примеры методов защиты реализации: - проверка делителя перед операцией деления (отличен от нуля или находится в конкретном диапазоне): - проверка идентификатора, передаваемого параметром, для верификации того, что вызов выполнен из той функции, из которой ожидается; - использование варианта "default" в операторах "switch case" для обнаружения ошибки. <e> Может потребоваться верификация обоснованности принятых допущений, границ и условий. <f> Распараллеливание процессов или задач не ограничивается выполнением программного обеспечения в многоядерной или многопроцессорной среде исполнения.

Представления		УПБТС
		A	B	C	D
1a	Неформальный язык <a>	++	++	++	++
2b	Неформальные представления	++	++	+	+
3c	Полуформальные представления <b>	+	+	++	++
4d	Формальные представления	+	+	+	+
<a> Естественный язык может дополнять использование нотаций, например, в тех случаях, когда некоторые темы легче выражаются на естественном языке, или для объяснений и обоснований решений, представленных в нотации. <b> Полуформальные представления могут включать в себя псевдокод или моделирование с помощью , , или . Примечание - , , и являются примерами подходящих продуктов, доступных на коммерческой основе. Эта информация приводится для удобства пользователей настоящего стандарта и не является рекомендацией ИСО для этих продуктов.

Принципы		УПБТС
		A	B	C	D
1a	Подходящая иерархическая структура программных компонентов	++	++	++	++
1b	Ограниченный размер и сложность программных компонентов <a>	++	++	++	++
1c	Ограниченный размер интерфейсов <a>	+	+	+	++
1d	Высокая связность внутри каждого компонента программного обеспечения <b>	+	++	++	++
1e	Слабое взаимовлияние между программными компонентами <b>, <c>	+	++	++	++
1f	Надлежащие свойства планирования	++	++	++	++
1g	Ограниченное использование прерываний <a>, <d>	+	+	+	++
1h	Подходящая пространственная изоляция программных компонентов	+	+	+	++
1i	Подходящее управление разделяемыми ресурсами <e>	++	++	++	++
<a> В принципах 1b, 1c, 1e и 1g слово "ограниченный" означает минимальный по сравнению с влиянием других аспектов проекта. <b> Принципы 1d и 1e, например, могут быть реализованы путем разделения вопросов, касающихся способности идентифицировать, инкапсулировать и манипулировать теми частями программного обеспечения, которые имеют отношение к определенной концепции, цели, задаче или назначению. <c> Принцип 1e связан с управлением зависимостями между программными компонентами. <d> Принцип 1g может включать в себя минимизацию количества прерываний или использование прерываний с определенным приоритетом для достижения детерминизма. <e> Принцип 1i применяется к разделяемым ресурсам аппаратных средств, а также к разделяемым программным ресурсам в случае их совместного применения. Такое управление ресурсами может быть реализовано в программном обеспечении или в аппаратных средствах и включает в себя механизмы безопасности и/или меры процесса, которые предотвращают конфликт доступа к разделяемым ресурсам, а также механизмы, которые обнаруживают и обрабатывают конфликт доступа к разделяемым ресурсам.

Методы		УПБТС
		A	B	C	D
1a	Сквозной контроль проекта <a>	++	+	о	о
1b	Ревизия проекта <a>	+	++	++	++
1c	Моделирование проекта в динамике	+	+	+	++
1d	Генерация прототипа	о	о	+	++
1e	Формальная верификация	о	о	+	+
1f	Анализ потока управления <b>	+	+	++	++
1g	Анализ потока данных <b>	+	+	++	++
1h	Анализ диспетчеризации	+	+	++	++
<a> В случае разработки, основанной на моделировании, эти методы могут быть применены к модели. <b> Анализ потока управления и/или данных может быть ограничен связанными с безопасностью компонентами и их интерфейсами.

Представления		УПБТС
		A	B	C	D
1a	Неформальный язык <a>	++	++	++	++
2b	Неформальные нотации	++	++	+	+
3c	Полуформальные нотации <b>	+	+	++	++
4d	Формальные нотации	+	+	+	+
<a> Естественный язык может дополнять использование нотаций, например, в тех случаях, когда некоторые темы более легко выражаются на естественном языке, или давать объяснение и обоснование решений, представленных в нотации. Пример - Чтобы избежать возможной неоднозначности естественного языка при проектировании сложных элементов, может использоваться комбинация диаграммы функционирования с естественным языком. <b> Полуформальные нотации могут включать в себя псевдокод или моделирование с помощью , , или . Примечание - , , и являются примерами подходящих продуктов, доступных на коммерческой основе. Эта информация приводится для удобства пользователей настоящего стандарта и не является рекомендацией ИСО для этих продуктов.

Принципы		УПБТС
		A	B	C	D
1a	Одна точка входа и одна точка выхода в подпрограммах и функциях <a>	++	++	++	++
1b	Не использовать динамические объекты или переменные либо выполнять оперативное тестирование при их создании <a>	+	++	++	++
1c	Инициализация переменных	++	++	++	++
1d	Не использовать многократно имена переменных <a>	++	++	++	++
1e	Избегать глобальных переменных либо обосновывать их использование <a>	+	+	++	++
1f	Ограничивать использование указателей <a>	+	++	++	++
1g	Исключать неявные преобразования типов <a>	+	++	++	++
1h	Исключать скрытые потоки данных или потоки управления	+	++	++	++
1i	Исключать безусловные переходы <a>	++	++	++	++
1j	Исключать рекурсии	+	+	++	++
<a> Принципы 1a, 1b, 1d, 1e, 1f, 1g и 1i могут быть неприменимы для нотаций графических моделей, используемых при разработке, основанной на моделировании.

Методы		УПБТС
		A	B	C	D
1a	Сквозной контроль проекта <a>	++	+	о	о
1b	Дублированное программирование <a>	+	+	+	+
1c	Ревизия <a>	+	++	++	++
1d	Полуформальная верификация	+	+	++	++
1e	Формальная верификация	о	о	+	+
1f	Анализ потока управления <b>, <c>	+	+	++	++
1g	Анализ потока данных <b>, <c>	+	+	++	++
1h	Статический анализ кода <d>	++	++	++	++
1i	Статический анализ, основанный на абстрактной интерпретации <e>	+	+	+	+
1j	Тестирование на основе требований <f>	++	++	++	++
1k	Тестирование интерфейса <g>	++	++	++	++
1l	Тестирование методом внесения дефектов <h>	+	+	+	++
1m	Оценка используемых ресурсов <i>	+	+	+	++
1n	Сравнительный тест между моделью и кодом, если он применим <j>	+	+	++	++
<a> При разработке, основанной на моделировании, эти методы применяются на уровне модели, если имеются доказательства, которые обосновывают доверие к используемому генератору кода. <b> Методы 1f и 1g могут применяться на уровне исходного кода. Эти методы применяются как при разработке кода вручную, так и при разработке, основанной на моделировании. <c> Методы 1f и 1g могут быть частью методов 1e, 1h или 1i. <d> Статический анализ представляет собой собирательный термин, который включает в себя различные виды анализа, например поиск текста исходного кода или модели шаблонов, соответствующих известным сбоям, или анализ соблюдения руководства по моделированию или кодированию. <e> Статический анализ, основанный на абстрактной интерпретации, является собирательным термином для расширенного статического анализа, который включает в себя такие виды анализа, как расширение дерева синтаксического разбора компилятора путем добавления семантической информации, которая может проверяться на предмет нарушения определенных правил (например, при возникновении проблем с типами данных, при появлении неинициализированных переменных), формирование графа потока управления и анализ потока данных (например, для обнаружения сбоев, связанных с гонками потоков и взаимоблокировками, ошибками в указателях) или даже метакомпиляция и абстрактная интерпретация кода или модели. <f> Требования к программному обеспечению на уровне модуля являются основой для тестирования на основе требований. К ним относятся спецификация проекта модуля программного обеспечения и требования к безопасности модуля программного обеспечения, распределенные для этого модуля программного обеспечения. <g> Данный метод может быть использован для обеспечения доказательства целостности используемых данных и данных обмена. <h> В контексте испытания модуля программного обеспечения тестирование методом внесения дефектов означает изменение тестируемого модуля программного обеспечения (например, внесение сбоев в программное обеспечение) для целей, описанных в 9.4.2. Такие модификации включают в себя внесение произвольных дефектов (например, путем повреждения значений переменных, путем введения изменения данных или путем повреждения значений регистров центрального процессора). <i> Некоторые задачи метода оценки используемых ресурсов могут быть выполнены надлежащим образом только в том случае, если тестирование модуля программного обеспечения выполняется в целевой среде или если эмулятор целевого процессора корректно обеспечивает тесты использования ресурсов. <j> Для данного метода требуется модель, которая может имитировать функционирование программных модулей. В этом случае модель и код выполняются одинаковым образом, а результаты сравниваются друг с другом. Пример - В случае проектирования на основе модели допускается сравнивать результаты операций, имеющие типы данных кроме плавающей точки.

Методы		УПБТС
		A	B	C	D
1a	Анализ требований	++	++	++	++
1b	Генерация и анализ классов эквивалентности <a>	+	++	++	++
1c	Анализ граничных значений <b>	+	++	++	++
1d	Предугадывание ошибок на основе знаний или опыта <c>	+	+	+	+
<a> Классы эквивалентности могут быть определены на основе разделения входных и выходных данных так, чтобы репрезентативные тестовые значения могли быть выбраны из каждого класса. <b> Данный метод применяется к интерфейсам, у которых значения приближаются и пересекают границы, а также выходят за границы диапазона значений. <c> Испытания с предугадыванием ошибок могут быть основаны на данных, полученных из "обобщения опыта" и экспертной оценки.

Методы		УПБТС
		A	B	C	D
1a	Покрытие операторов	++	++	+	+
1b	Покрытие ветвей	+	++	++	++
1c	Модифицированное покрытие условий и ветвей (MC/DC)	+	+	+	++

Методы		УПБТС
		A	B	C	D
1a	Тестирование на основе требований <a>	++	++	++	++
1b	Тестирование интерфейса	++	++	++	++
1c	Тестирование с внесением дефектов <b>	+	+	++	++
1d	Оценка используемых ресурсов <c>, <d>	++	++	++	++
1e	Сравнительный тест модели и кода, если он применим <e>	+	+	++	++
1f	Верификация потока управления и потока данных	+	+	++	++
1g	Статический анализ кода <f>	++	++	++	++
1h	Статический анализ, основанный на абстрактной интерпретации <g>	+	+	+	+
<a> Требования к программному обеспечению, распределенные по элементам архитектуры, являются основой для тестирования на основе требований. <b> В контексте испытания модуля программного обеспечения тестирование методом внесения дефектов означает внесение сбоев в программное обеспечение для целей, описанных в 10.4.3, и тем самым проверку корректности аппаратно-программного интерфейса, связанного с механизмами безопасности. Данный метод включает в себя внесение произвольных сбоев для тестирования механизмов безопасности (например, путем повреждения программных интерфейсов). Внесение дефектов также может использоваться для проверки отсутствия влияния. <c> Для обеспечения выполнения требований, вытекающих из проекта архитектуры аппаратных средств с достаточной устойчивостью, необходимо определить такие свойства, как средняя и максимальная производительность процессора, минимальное или максимальное время выполнения, использование памяти (например, ОЗУ для стека и динамической памяти, ПЗУ для программы и данных), а также полосу пропускания линий связи (например, шин данных). <d> Некоторые задачи оценки используемых ресурсов могут быть выполнены надлежащим образом только в том случае, если тестирование интеграции программного обеспечения выполняется в целевой среде или если эмулятор целевого процессора корректно поддерживает тесты используемых ресурсов. <e> Для данного метода требуется модель, которая может имитировать функциональные возможности программных компонентов. На вход модели и кода подаются одинаковые данные, а результаты сравниваются друг с другом. <f> Статический анализ кода представляет собой собирательный термин, который включает в себя такие виды анализа, как анализ архитектуры, анализ потребления ресурсов, поиск текста исходного кода или признаков шаблонов, соответствующих известным сбоям, или анализ соблюдения стандартов по моделированию или кодированию, если это еще не было верифицировано на уровне модуля. <g> Статический анализ, основанный на абстрактной интерпретации, является собирательным термином для расширенного статического анализа, который включает в себя такие виды анализа, как расширение дерева синтаксического разбора компилятора путем добавления семантической информации, которая может проверяться на предмет нарушения определенных правил (например, при возникновении проблем с типами данных, при появлении неинициализированных переменных), формирование графа потока управления и анализ потока данных (например, для обнаружения сбоев, связанных с гонками потоков и взаимоблокировками, ошибками в указателях) или даже метакомпиляция и абстрактная интерпретация кода или модели, если это еще не было верифицировано на уровне модуля.

Методы		УПБТС
		A	B	C	D
1a	Анализ требований	++	++	++	++
1b	Генерация и анализ классов эквивалентности <a>	+	++	++	++
1c	Анализ граничных значений <b>	+	++	++	++
1d	Предугадывание ошибок на основе знаний или опыта <c>	+	+	+	+
<a> Классы эквивалентности могут быть определены на основе разделения входных и выходных данных так, чтобы репрезентативные тестовые значения выбирались из каждого класса. <b> Данный метод применяется к параметрам или переменным, значения которых приближаются и пересекают границы, а также выходят за границы диапазона значений. <c> Испытания с предугадыванием ошибок могут быть основаны на данных, полученных из "обобщения опыта" и экспертной оценки.

Методы		УПБТС
		A	B	C	D
1a	Покрытие функций <a>	+	+	++	++
1b	Охват вызовов <b>	+	+	++	++
<a> Метод 1a оценивает процент выполняемых подпрограмм или функций в программном обеспечении (определение см. в C.5.8 МЭК 61508-7). <b> Метод 1b оценивает процент выполняемых подпрограмм или функций программного обеспечения относительно каждого реализованного вызова этих подпрограмм или функций в программном обеспечении. Примечание - Подтверждение может быть предоставлено путем реализации соответствующей стратегии интеграции и тестирования программного обеспечения.

Методы		УПБТС
		A	B	C	D
1a	Аппаратные средства в контуре обратной связи	++	++	++	++
1b	Сетевые среды электронного блока управления <a>	++	++	++	++
1c	Транспортные средства	+	+	++	++
<a> Например, тестовые стенды, частично или полностью включающие электрические системы транспортного средства, автомобили-лаборатории или базовые модели автомобилей для испытаний новых узлов, а также имитации остальных частей шины.

Методы		УПБТС
		A	B	C	D
1a	Тестирование на основе требований	++	++	++	++
1b	Тестирование с внесением дефектов <a>	+	+	+	++
<a> В контексте тестирования программного обеспечения испытание с внесением дефектов означает внесение сбоев в программное обеспечение посредством, например, повреждения параметров калибровки.

Методы		УПБТС
		A	B	C	D
1a	Анализ требований	++	++	++	++
1b	Генерация и анализ классов эквивалентности	+	++	++	++
1c	Анализ граничных значений	+	+	++	++
1d	Предугадывание ошибок на основе знаний или опыта	+	+	++	++
1e	Анализ функциональных зависимостей	+	+	++	++
1f	Анализ эксплуатационных сценариев использования <a>	+	++	++	++
<a> Примеры эксплуатационных сценариев использования программного обеспечения могут включать в себя следующее: обновление программного обеспечения на местах; запуск штатного приложения только в том случае, если целостность программного обеспечения обеспечивается загрузчиком; функционирование, связанное с безопасностью встроенного программного обеспечения в различных рабочих режимах, таких как запуск, диагностика, ухудшение качества, отключение питания (переход в спящий режим), включение питания (пробуждение), калибровка; функции синхронизации режимов между различными ЭБУ или режим тестового стенда специального выходного контроля для защиты производственного персонала.

Раздел	Цели	Предварительные требования	Результаты работы
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). Данные конфигурации (см. C.5.3), если применимы. Калибровочные данные (см. C.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), если применимы. Калибровочные данные (см. C.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). Данные конфигурации (см. C.5.3), если применимы. Калибровочные данные (см. C.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). Калибровочные данные (см. C.5.4), если применимы. Документация на среду разработки программного обеспечения (см. 5.5.1). Спецификация верификации программного обеспечения (уточненная) (см. 10.5.1)	11.5.1 Спецификация верификации программного обеспечения (уточненная). 11.5.2 Отчет о верификации программного обеспечения (уточненный)
Приложение C. Конфигурация программного обеспечения	Цели конфигурации программного обеспечения заключаются в следующем: а) обеспечить управление изменениями при функционировании программного обеспечения для различных приложений; б) представить доказательства того, что данные о конфигурации и калибровочные данные соответствуют требованиям, предъявляемым к УПБТС; в) предоставить доказательства того, что встроенное программное обеспечение для конкретного приложения и его калибровочные данные подходят для запуска в производство	См. применяемые предварительные требования соответствующих стадий жизненного цикла системы безопасности, в которых применяется конфигурирование программного обеспечения	C.5.1 Спецификация данных о конфигурации. C.5.2 Спецификация данных о калибровке. C.5.3 Данные о конфигурации. C.5.4 Данные о калибровке. C.5.5 Спецификация верификации (уточненная). C.5.6 Отчет о верификации (уточненный). C.5.7 Спецификация архитектуры программного обеспечения (уточненная). C.5.8 Документация о среде разработки программного обеспечения (уточненная)

Методы		УПБТС
		A	B	C	D
1a	Проверка достоверности калибровочных данных <a>	++	++	++	++
1b	Резервное хранение и сравнение калибровочных данных	+	+	+	++
1c	Проверка калибровочных данных с использованием кодов обнаружения ошибок <a>	+	+	+	++
<a> Коды обнаружения ошибок также могут быть реализованы аппаратно в соответствии с ИСО 26262-5.

	-	выполняемый программный компонент;
	-	заблокированный программный компонент;
	-	влияние;
	-	управляющая контрольная точка прохождения программного потока;
	-	управляющая контрольная точка непрохождения программного потока

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

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

Проверяемые функциональные возможности или свойства	Примеры для ключевых слов	Интерпретация	Дополнительные ссылки
Поток сигналов Ai - An	После/поздно	Слишком поздний сигнал или его нет в последовательности	В приложении 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 Некорректная синхронизация между элементами программного обеспечения
Значения сигналов Ai - An	Больше	Значение сигнала выше допустимого диапазона
	Меньше	Значение сигнала не достигает допустимого диапазона

Пример ключевого слова	Интерпретация	Последствие	Меры по обеспечению безопасности	Необходимые действия
Больше	Значение сигнала выше допустимого диапазона	Ошибка на выходе функции O	Сторожевой модуль M ограничивает сигналы A1 - An до разрешенного максимального диапазона	Применение сторожевого модуля M
Меньше	Значение сигнала не достигает допустимого диапазона	Ошибка на выходе функции O	Сторожевой модуль M ограничивает сигналы A1 - An до разрешенного минимального диапазона	Применение сторожевого модуля M
Отличающийся от	Значения сигналов A1 - An не согласованы	Ошибка на выходе функции O	Сторожевой модуль M проверяет сигналы A1 - An на согласованность, используя физические зависимости	Применение сторожевого модуля M

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
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. Разработка изделия на уровне системы"
ИС NORMPROD: примечание. В официальном тексте документа, видимо, допущена опечатка: ГОСТ Р ИСО 26262-5-2021 имеет название "Дорожные транспортные средства. Функциональная безопасность. Часть 5. Разработка аппаратных средств изделия".
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 C 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
Ключевые слова: функциональная безопасность, жизненный цикл систем, транспортные средства, программируемые электронные компоненты и системы, программное обеспечение, разработка и верификация, архитектура программного обеспечения, модуль программного обеспечения