Разработка программного обеспечения для систем, критичных к безопасности, на основе требований / Хабр

2.1. V‑Модель
2.2. Функциональная концепция безопасности
2.3. Техническая концепция безопасности
2.4. Требования к безопасности ПО
2.5. Проектирование архитектуры ПО
2.6. Трассируемость

3. ПРИМЕРЫ

4. РЕЗЮМЕ

5. СПИСОК ЛИТЕРАТУРЫ

Аннотация

В разработке программного обеспечения для систем, критичных к безопасности, таких как используемые в авиации и автомобилестроении, среди прочих, основа успеха заключается в строгом сборе и управлении требованиями. Эти системы должны соответствовать строгим стандартам безопасности, таким как ISO 26262, поскольку даже незначительные сбои могут привести к опасностям и катастрофическим последствиям. В данной статье рассматривается процесс разработки программного обеспечения на основе требований для электрических и электронных систем дорожных транспортных средств, подчеркивая ключевую роль всеобъемлющих и четких требований как движущей силы на протяжении всего жизненного цикла проекта. Описаны основные этапы разработки от концепции до фазы проектирования вместе с некоторыми примерами требований.

1. Введение

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

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

1.1. Функциональная безопасность

Функциональная безопасность относится к процессу обеспечения корректной работы систем в ответ на их входные данные, эффективно удовлетворяя заданным функциональным требованиям. Это особенно важно в таких отраслях, как промышленная автоматизация и автомобилестроение, где сбои систем могут иметь серьезные последствия для безопасности. Наиболее релевантными стандартами в этих двух отраслях являются IEC 61 508 и ISO 26 262 соответственно.

1.2. Стандарт IEC 61 508

IEC 61 508 — это базовый стандарт функциональной безопасности, применимый ко всем отраслям. Он состоит из методов о том, как применять, проектировать, развертывать и обслуживать электрические/электронные/программируемые электронные системы, связанные с безопасностью (E/E/PE или E/E/PES). Основная цель заключается в том, чтобы любая система, связанная с безопасностью, работала корректно или отказывала предсказуемым (безопасным) образом [1].

1.3. Стандарт ISO 26 262

ISO 26 262 — это адаптация IEC 61508 для удовлетворения специфических потребностей автомобильного сектора в отношении электрических и/или электронных (E/E) систем в дорожных транспортных средствах, и он широко принимается крупными производителями автомобилей.

Стандарт предоставляет структурированный подход для оценки функциональной безопасности путем категоризации функций транспортного средства на основе их влияния на безопасность. Каждой функции назначается Уровень Полноты Безопасности Автомобиля (ASIL), который определяет степень важности мер безопасности. Более высокие уровни ASIL соответствуют более строгим требованиям безопасности, включая такие механизмы, как резервирование, обнаружение неисправностей и отказ безопасные реакции. Этот систематический метод обеспечивает надежную работу систем транспортного средства и предотвращает аварии за счет устранения рисков с помощью специально подобранных механизмов безопасности [1].

2. Процесс разработки

В автомобильной промышленности жизненный цикл разработки продукта включает такие первые шаги, как разработка концепции на уровне транспортного средства, проектирование системы, аппаратного и программного обеспечения, далее проходя через реализацию до верификации и валидации каждой фазы разработки. Этот процесс разработки известен как V-модель. Данный подход представляет собой систематический метод, который фиксирует все необходимые требования до начала разработки, обеспечивая полное определение и валидацию каждого аспекта системы. Данная статья фокусируется на концептуальной и проектной фазах процесса разработки ПО по V‑модели.

2.1. V‑Модель

Цикл разработки по V‑модели представляет собой процесс, который можно рассматривать как расширение каскадной модели. Шаги процесса после фазы кодирования изгибаются вверх, вместо того чтобы двигаться линейно вниз, как в каскадном подходе, образуя характерную V‑форму. Связи между каждой фазой разработки и соответствующей ей фазой тестирования четко представлены в V-модели.

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

Рисунок 1: Процесс разработки ПО по V-модели согласно ISO 26262 [1]

На Рисунке 1 показан процесс разработки ПО по V-модели согласно стандарту ISO 26262 с акцентом на фазы концепции, проектирования, тестирования и верификации. Горизонтальные оси представляют время или завершенность проекта, а вертикальные оси — уровень абстракции.

Рисунок 2: Основные этапы концептуальной и проектной фаз [1]

Основные этапы концептуальной и проектной фаз, от Анализа Опасностей и Оценки Рисков (HARA) через функциональную концепцию безопасности (FSC), техническую концепцию безопасности (TSC) до спецификации требований к безопасности программного обеспечения (SSR), описаны на Рисунке 2.

2.2. Функциональная концепция безопасности

Функциональная концепция безопасности (FSC) — это последний шаг и результат концептуальной фазы согласно ISO 26262, который включает определение того, что система должна делать, выявление критических функций, оценку рисков, связанных с каждой функцией, и затем установление целей или требований безопасности для снижения этих рисков. Все эти мероприятия являются предыдущими шагами процесса, которые используют структурированные методы, называемые определением элемента и анализом HARA согласно стандарту. Концептуальная фаза закладывает основу для системного подхода стандарта, определяя границы, в рамках которых будут происходить последующие проектные и валидационные мероприятия [2].

Ключевые аспекты концептуальной фазы включают:

Определение функций системы: Выявление того, что система должна выполнять, и ее критических функций.
Оценка рисков: Оценка потенциальных опасностей, связанных с каждой функцией, с учетом их серьезности и вероятности возникновения. Определение уровней ASIL.
Установление требований безопасности: Определение целей или мер безопасности на основе оцененных рисков, обеспечивающее безопасную работу системы без опасных отказов.

2.3. Техническая концепция безопасности

Техническая концепция безопасности (TSC) — это процесс выведения конкретных технических требований безопасности (TSR) из функциональных требований безопасности (FSR) системы и проектирования архитектуры системы на их основе для удовлетворения функциональной концепции безопасности.

Этот процесс включает добавление и интеграцию в архитектуру системы дополнительных механизмов безопасности, необходимых для удовлетворения функциональных требований безопасности, и обновление исходной архитектуры фазы FSC. Это включает такие механизмы, как обнаружение, предотвращение и смягчение последствий неисправностей. Технические требования безопасности должны быть распределены по архитектуре системы в конкретной аллокации или по отдельным элементам (аппаратное обеспечение, программное обеспечение) [2].

2.4. Требования к безопасности ПО

Требования к безопасности программного обеспечения (SSR) — это низкоуровневые, реализуемые в ПО требования, которые выводятся из менее детального уровня TSR, назначенных программному обеспечению [2].

Основные цели этапа SSR:

Вывести SSR из TSR и архитектуры системы
Определить связанные с безопасностью функциональности и свойства ПО
Уточнить требования к интерфейсу аппаратного и программного обеспечения

Другие существенные характеристики и свойства SSR:

Четкие, точные, однозначные, понятные
Выполнимые, проверяемые, сопровождаемые и под управлением конфигурации
Трассируемые к TSC
Обеспечение низкой сложности

2.5. Проектирование архитектуры ПО

Проектирование архитектуры программного обеспечения — это последний шаг проектной фазы перед началом реализации, и оно необходимо для обеспечения того, что все SSR могут быть реализованы с требуемым ASIL. Хорошо спроектированная архитектура ПО должна быть понятной и согласованной, без внутренних проектных ошибок, простой и понятной, с предсказуемым поведением, а также проверяемой и тестируемой. Все эти атрибуты могут быть реализованы, если архитектура построена модульным способом. Рисунок 3 представляет хорошо спроектированную модульную архитектуру [2].

Ключевые статические аспекты проектирования архитектуры:

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

Ключевые динамические аспекты проектирования архитектуры:

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

2.6. Трассируемость

Согласно стандарту ISO 26262, трассируемость требований необходима для достижения ожидаемых требований безопасности системы в процессе разработки, чтобы обеспечить и продемонстрировать это. На Рисунке 4 показана ожидаемая трассируемость требований от концептуальной фазы через проектную фазу до начала реализации.

Рисунок 4: Представление трассируемости требований

Трассируемость относится к:

каждому источнику требования на следующем верхнем иерархическом уровне
каждому производному требованию на следующем нижнем иерархическом уровне
верификационной спецификации

Трассируемость также поддерживает:

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

3. Примеры

Цель Безопасности	Безопасное состояние Электронного Блока Управления ADAS (ADCU)
Предотвратить возникновение непреднамеренного крутящего момента в Продвинутой Системе Помощи Водителю (ADAS) (в пределах функциональных возможностей ADAS)	Отключить функцию ADAS, которая может контролировать вождение

FSR	TSRs	SSRs
Система «ADCU» должна «перейти в безопасное состояние, ЕСЛИ значение запроса на расчет ускорения больше ограничения по ускорению».	ADCU должен ограничить сигнал ADCU_ACC_Ax_Req, рассчитанный функцией Адаптивного Круиз Контроля (ACC), минимальным значением.	Запрос на ускорение от ACC будет перезаписан до минимально допустимого порогового значения, если запрос меньше порогового значения. When rqAcclACC_L2iaVUC < thldMinAcclRq_L2caIUC Then rqAcclACC_L2caVUC = thldMinAcclRq_L2caIUC Otherwise rqAcclACC_L2caVUC = rqAcclACC_L2iaVUC
	ADCU должен ограничить сигнал ADCU_ACC_Ax_Req, рассчитанный функцией ACC, максимальным значением	Запрос на ускорение от ACC будет перезаписан до максимально допустимого порога, если запрос превышает порог. When rqAcclACC_L2iaVUC > thldMaxAcclRq_L2caIUC Then rqAcclACC_L2caVUC = thldMaxAcclRq_L2caIUC Otherwise rqAcclACC_L2caVUC = rqAcclACC_L2iaVUC
	ADCU должен генерировать флаг ошибки при неправильном расчете запроса на ускорение/замедление	Флаг запроса ошибки ACC должен быть установлен на значение «Истина», если запрос ускорения от ACC выходит за пределы минимального или максимального порогового значения. When rqAcclACC_L2iaVUC < thldMinAcclRq_L2caIUC or rqAcclACC_L2iaVUC > thldMaxAcclRq_L2caIUC Then flgRqACCFlt_L2caVUC = 1 ("True") Otherwise flgRqACCFlt_L2caVUC = 0 ("False")
	…	…

4. Резюме

В итоге концептуальная фаза ISO 26 262 заключается в определении требований безопасности на уровне транспортного средства и установлении системного подхода для обеспечения того, что автомобильные системы с самого начала проектируются безопасно. Это также основа для обеспечения того, что все последующие проектные и валидационные мероприятия будут отдавать приоритет безопасности. Концептуальная фаза включает выявление критических функций, оценку рисков и установление целей безопасности.

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

5. Список литературы

[1] TÜV SÜD Akademie GmbH. https://www.tuvsud.com/

[2] Standard ISO 26262: 2018.

Автор: Андрес Сильва, ведущий инженер по функциональной безопасности ADAS в Атоме

Разработка программного обеспечения для систем, критичных к безопасности, на основе требований

Оглавление