ГОСТ Р ИСО 26262-6—2014
7.4.16 Если в результате проектирования архитектуры программное обеспечение появились
новые опасности, еще не охваченные существующей целью безопасности, то они должны быть учте ны
и оценены при анализе опасностей и оценке рисков в соответствии с требованиями процесса
управления изменениями, представленными в разделе 8 ИСО 26262-8.
П р и м е ч а н и е - Вновь выявленные опасности и неучтенные в цели безопасности, как правило, яв
ляются нефункциональными опасностями. Нефункциональные опасности выходят за рамки области применения
настоящего стандарта, но они могут быть при анализе опасностей и оценке рисков снабжены следующим пояс
нением «Данной опасности значение УПБА не назначается, поскольку она выходит за рамки области применения
настоящего стандарта». Тем не менее, значение УПБА может быть назначено в качестве рекомендации.
7.4.17 Должна быть выполнена верхняя оценка ресурсов, необходимых для встроенного про
граммного обеспечения, в том числе:
a) времени выполнения:
b
) объема памяти.
Пример - Оперативная память для стеков и динамически распределяемых областей
памяти, ПЗУ для программ и энергонезависимых данных;
c)
коммуникационных ресурсов.
7.4.18 Проект архитектуры программного обеспечения должен быть верифицирован в соответ
ствии с требованиями раздела 9 ИСО 26262-8 и с помощью методов верификации проекта архитек
туры программного обеспечения, перечисленных в таблице 6. для демонстрации следующих свойств:
a) соответствия требованиям безопасности к программному обеспечению;
b
) совместимости с целевыми аппаратными средствами.
П р и м е ч а н и е - Они включает в себя ресурсы, указанные в 7.4.17;
c) соблюдения руководств по проектированию.
Т а б л и ц а 6 - Методы верификации проекта архитектуры программного обеспечения
Методы
Ав
УПБА
сD
1аСквозной контроль проекта
1ЬПроверка (контроль) проекта “
1сМоделирование динамических частей проекта
1dГенерация прототипа
1еФормальная верификация
1fАнализ потока управления
4
♦++
ОО
♦ ♦+ ++ ++
+++ +♦
о0
+ ++
ОО
+♦
++++++
Анализ потока данных
^
+
+
++++
- В случае разработки на основе модели эти методы могут быть применены к модели.
Ь) Метод 1с требует использования исполняемых моделей для динамических частей архитектуры программно
го обеспечения.
с:Анализ потока управления и’или данных может быть ограничен связанными с безопасностью компонентами
и их интерфейсами.
7.5 Результаты работы
7.5.1 Спецификация проекта архитектуры программного обеспечения
В результате выполнения требований 7.4.1 - 7.4.6, 7.4.9, 7.4.10. 7.4.14, 7.4.15 и 7.4.17.
7.5.2 План обеспечения безопасности (уточненный)
В результате выполнения требований 7.4.7.
7.5.3 Спецификация требований безопасности к программному обеспечению (уточнвн-
В результате выполнения требований 7.4.9.
7.5.4 Отчет по анализу безопасности
В результате выполнения требований 7.4.13.
7.5.5 Отчет по анализу зависимых отказов
В результате выполнения требований 7.4.12.
7.5.6 Отчет по верификации программного обеспечения (уточненный)
В результате выполнения требований 7.4.18.
13