Статус документа

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

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

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

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

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

Таблица 7 - Представления для проекта модуля программного обеспечения


Методы		УПБА
		А	В	С	D
1а	Естественный язык	++	++	++	++
1b	Неформальные представления	++	++	+	+
1с	Полуформальные представления	+	++	++	++
1d	Формальные представления	+	+	+	+

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

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

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

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

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

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

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

d) простоте;

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

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

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

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

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

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


Свойства		УПБА
		А	В	С	D
1а	Одна точка входа и одна точка выхода в подпрограммах и функциях	++	++	++	++
1b	Не использовать динамические объекты или переменные, либо выполнять тестирование в неавтономном режиме при их создании	+	++	++	++
1с	Инициализация переменных	++	++	++	++
1d	Не использовать многократно имена переменных	+	++	++	++
1е	Избегать глобальных переменных либо обосновывать их использование	+	+	++	++
1f	Ограничивать использование указателей	о	+	+	++
1g	Исключать неявные преобразования типов	+	++	++	++
1h	Исключать скрытые потоки данных или потоки управления	+	++	++	++
1i	Исключать безусловные переходы	++	++	++	++
1j	Исключать рекурсии	+	+	++	++
Методы 1а, 1b, 1d, 1е, 1f, 1g и 1i нельзя применять для представлений графического моделирования, используемых при разработке на основе модели. Методы 1g и 1i не применяются при программировании на ассемблере. Методы 1h и 1i сокращают возможность для моделирования потока данных и потока управления из-за переходов или глобальных переменных.

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

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

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

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

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