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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

Таблица 13 - Методы тестирования интеграции программного обеспечения


Методы		УПБА
		А	В	С	D
1а	Тестирование на основе требований	++	++	++	++
1b	Тестирование интерфейса	++	++	++	++
1с	Испытания с введением неисправностей	+	+	+	++
1d	Тестирование используемых ресурсов	+	+	+	++
1е	Сравнительное испытание между моделью и кодом, если оно применимо	+	+	++	++
Данный метод реализуется на основе требований к программному обеспечению на уровне архитектуры. Они включают в себя введение произвольных неисправностей для тестирования механизмов безопасности (например, путем повреждения программного обеспечения либо компонентов аппаратных средств). Для обеспечения выполнения требований проектом архитектуры аппаратных средств с достаточной устойчивостью должны быть определены свойства, такие как средняя и максимальная производительность процессора, минимальное или максимальное время выполнения, использование памяти (например, ОЗУ для стека и динамически распределяемых областей памяти, ПЗУ для программ и данных) и пропускная способность коммуникационных линий (например, шин данных). Некоторые аспекты теста использования ресурсов могут быть оценены правильно, только когда тестирование интеграции программного обеспечения выполняется на целевых аппаратных средствах или если эмулятор целевого процессора поддерживает тесты использования ресурсов. Данный метод требует модель, которая может имитировать функциональные возможности компонентов программного обеспечения. На вход модели и кода подаются одинаковые данные, а результаты сравниваются друг с другом.

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

Таблица 14 - Методы получения тестов для тестирования интеграции программного обеспечения


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

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

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

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

Таблица 15 - Метрики структурного покрытия на уровне архитектуры программного обеспечения