ISO 26262-6 разбор документа (или как писать безопасный софт)

С тех пор как появились инжекторные двигатели так сразу и в автомобили проникло программное обеспечение. В связи с этим появился стандарт ISO-26262-6

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

Что это за понятие такое safety?

К сожалению в русском языке нет отличия между понятиями safety и security. Поэтому далее придется использовать только слово safety.

Если переводить дословно, то safety в бытовом смысле - это безопасность в смысле не пораниться и не ушибиться. Однако в стандарте на это есть четкое определение.

--Функциональная безопасность (functional safety) это отсутствие необоснованного риска из-за опасности вызванной неправильным поведения системы

На самом деле с safety мы сталкивается каждый день. Safety проявляется на разных уровнях проработки продукта.

--на уровне проработки механики

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

--на уровне электротехники и аналоговой электроники

Габаритные огни транспортных средств, подушки безопасности, тикающие светофоры

--на уровне проработки программного обеспечения

Звук при не пристегнутом ремне, не заводится мотор при отстегнутом ремне, запертые двери во время езды. Даже электро-самоката электромотор только включает при наборе пороговой скорости 3 км./ч. Всё это - примеры safety в софте.

Классификацию примеров safety можно посмотреть тут

https://docs.google.com/spreadsheets/d/1Ka_avuSJdILEPpdXmbicfCfzR0LWQla7sqDJBs2ILsw/edit#gid=0

В этом тексте я попробовал разобраться с тем как понять автомобильный стандарт функциональной безопасности ISO26262 в той части, которая относится к требованиям к программному обеспечению (часть 6). Там всего 66 страничек английского текста.

Чтобы понять этот док надо сначала прочитать часть 1 и освоить нужную терминологию.

Терминология ISO-26262

В стандарте ISO-26262 не просто набор определений. Тут как в астрономии система определений, где чтобы определить одно понятие надо дать определение целой куче другим понятиям.

Однако с понятиями всё плохо. Тут прослеживаются циклические определения.

В идеале определения должны выстраиваться в дерево определений. А в ISO-26262-1 какой-то граф определений похожий на клубок с нитками. Вот вам яркий пример. Чтобы дать определение понятию software component надо дать определение понятию software unit. Чтобы дать определение понятию software unit надо дать определение software component. Бред какой-то, ну ни правда ли? Какая-то проблема из серии, что появилось раньше курица или яйцо.

Тем не менее вы только поглядите настолько своеобразные определения IT(шным) понятиям даны в доке ISO-26262-1

--обрабатывающий элемент (processing element) -- аппаратная часть, которая предоставляет набор инструкций для обработки данных. Обычно состоит из набора регистров, исполнительного элемента и управляющего элемента. Например двух ядерный микроконтроллер это два обрабатывающих элемента.

--Архитектура (architecture) - представление структуры элементов или нечто что позволяет опознать строительные блоки их границы и интерфейсы и включает назначения требований для этих строительных блоков.

--данные калибровки (calibration data)- данные которые будут применены как значения параметров программного обеспечения после построения артефактов в процессе разработки. Например код страны, расположение руля. Калибровочные данные не содержать исполняемый или интерпретируемый код.

--данные конфигурации (configuration data) - данные которые назначаются во время построения, которые управляют процессом сборки программных элементов. Это, например, макроопределения препроцессора, которые выбирают код для сборки. Это те же пресловутые XML файлы настройки IDE для выбора ToolChain(a) или инструментов сборки. Эти данные управляют построением ПО. Эти данные используются для выбора нужного кода из общей кодовой базы.

--Встраиваемое ПО (embedded software) - полностью объединенное ПО, которое исполняется на обрабатывающем элементе.

--Покрытие ветвей (branch coverage) - процентное содержание количества ветвей в потоке исполнения компьютерной программы во время прогона тестов.

--компонент (component) - элемент не системного уровня, который логически или технический отделяемый и состоит из более чем одной программной единицы (software unit)

--Программная единица (software unit) - неделимая часть программного компонента в программной архитектуре которую можно подвергнуть автономному тестированию

--программный компонент (software component) - один или несколько программных единиц

--Элемент (element) - система, компонент, аппаратная часть или программная единица.

--программный инструмент (software tool) - компьютерная программа, которая используется для разработки программной единицы или программного элемента.

--тестирование (testing) - процесс планирования, подготовки и эксплуатации или тренировки программной единицы или программного элемента для проверки того, что он удовлетворяет установленным требованиям, для обнаружения аномалий безопасности, для подтверждения того, что требования подходят в данном контексте и для создания уверенности в его поведении.

Цель дока ISO26262 - это уменьшить риск от ущерба, который может возникнуть из-за ошибки или сбоя в сложной технической системе.

Стандарт говорит, что надо придерживаться V модели разработки. Почему V? Если начертить декартову систему координат XY и если X-время, а Y-уровень абстракции, то получится, что процесс проработки софтвера будет прорисовывать букву V. Сначала дизайн , затем тестирование и интеграция.

То есть разрабатывая надо двигаясь от общего к частному, а проверять от частного к общему. Так и получается буква V. V-model.

Этот стандарт утверждает, что есть четыре уровня ответственности в разработке автомобильных систем: A, B, C и D. Уровень D - самый строгий. ASIL-D обычно применяют для очень важных деталей машин (например электронная рулевая рейка).

Для разработки каждого уровня надо выполнять строго перечисленные требования к действиям при разработке реализации и проверке. Эти требования ранжируются токенами "+" "++" "о"

Требования к различным уровням перечислены в этот импровизированном реестре

https://docs.google.com/spreadsheets/d/1uO6X80EzW9fGv52g26durAk19ulbCR1fv3DBiyPAyPs/edit#gid=0

Уровни абстракции при проработке программного обеспечения в ISO 26262

Вот поподробнее рис.3. По сути разработка начинается с формирования требований к программному обеспечению. На основе требований составляются тесты. Далее проектируется архитектура ПО, затем пишется код программных компонентов чтобы проходили тесты. По сути ISO26262 это Test Driven Development (TDD).

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

Сбои в исполнении программ

--блокирование исполнения

--тупики

--взаимная блокировка

--неправильное распределение времени выполнения

--неправильная синхронизация между элементами программного обеспечения

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

Сбои в памяти

--искажение данных в памяти

--противоречивые данные

--переполнение стековой RAM памяти

--чтение или запись памяти чужого программного элемента

Предлагается использовать подсчет и проверку контрольных сумм CRC, биты четности, избыточные коды ECC, избыточное хранение данных, ограниченный доступ к памяти (MPU).

Сбои в обмене информацией

--повторение информации

--потеря информации

--запаздывание информации

--неверная адресация

--ложная последовательность пакетов

--поврежденная информация

--информация от отправителя, полученная только частью получателей

--блокировка доступа к каналу связи

Предлагается использовать ретрансляцию, пакеты подтверждения, ID узлов в протоколах, "Hello" пакеты, слежение за непрерывностью передачи данных на основе порядковых номеров в заголовке пакета.

---------------------

При чтении ISO26262 лично у меня возникает ряд вопросов.

1--Допустим команда разрабатывает автомобильный блок телематики. Какой минимальный уровень ASIL (A, B, C, или D) им выбрать для разработки?

2--Допустим компания разрабатываю автомобильную аудиосистему. Какой минимальный уровень ASIL (A, B, C, или D) им выбрать для разработки?

Можно конечно выбрать ASIL-D и не ошибешься, однако трудоёмкость реализации этого ASIL-D повысится на порядок.

Для всех уровней ASIL cтандарт ISO 26262 требует с софтвере придерживаться низкой сложности, программные компоненты выстраивать в иерархию, использовать типизированные языки программирования, не называть одинаково имена локальных и глобальных переменных, в каждой функции только один return, использовать naming conventions, инициализировать все переменные при создании, не заниматься пере использованием переменных, не использовать оператор goto, покрывать код модульными тестами, прогонять код через статические анализаторы. Если в прошивке есть калибровочные данные то надо проверять на достоверность калибровочные данные.

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

В ISO26262 подразумевается что софт должен быть простым, конфигурируемым, тесто пригодным, иерархичным. Что должна быть общая кодовая база из которой как из ствола дерева произрастают разнообразные сборки. ISO 26262 намекает, что надо использовать TDD, MISRA C

При написании модульных тестов использовать в каждой функции только один return. Тесты надо создавать исходя из требований. При тестировании надо придерживаться схемы Hardware In the Loop (HIL). То есть надо строить HIL стенды. Также надо воспроизводить CAN-сеть автомобиля на макете (lab-cars).

Для всех уровней стандарт призывает анализировать затраты ресурсов которые поглощает ПО: RAM память, размер стека, Flash память, время исполнения кода, пропускную способность интерфейсов.

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

И вообще возникает впечатление, что ISO-26262 это про

за всё хорошее и против всего плохого в процессах разработки ПО

Однако что-то мне подсказывает, что едва ли кто-то реально следует всем требованиям из ISO-26262. Это слишком долго, дорого и трудно. И доступный российским программистам микроконтроллеров инструментарий едва ли дотянет до того чтобы делать снятие покрытия исполнения embedded кода на target устройстве после прогона модульных тестов.

Вывод.
Надеюсь этот текст внес некоторую ясность в первое понимание стандарта ISO-26262 и сподвигнет больше инженеров проявить интерес разбираться в том, что там всё таки на самом деле написано как интерпретировать текст ISO-26262. А самое главное как использовать его рекомендации в реальных разработках.

В целом в стандарте ISO-26262 не всё понятно но полезный рекомендации обнаружить можно.

Этот док мало прочитать один раз. С стандартом ISO26262 надо методично работать ежедневно. Это как справочное пособие.

Словарь

https://docs.google.com/spreadsheets/d/1uO6X80EzW9fGv52g26durAk19ulbCR1fv3DBiyPAyPs/edit#gid=0

https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level

https://habr.com/ru/companies/3rdman/articles/729862/
https://habr.com/ru/companies/swd_es/articles/508240/
https://habr.com/ru/articles/735584/
https://habr.com/ru/articles/525396/
https://habr.com/ru/companies/itelma/articles/519572/
https://habr.com/ru/companies/swd_es/articles/508678/

https://www.youtube.com/watch?v=bGarXE_EaLk&list=PLO2k6yikLVTlrkQJN8pbznro3G-EhkViG&index=2

Вопросы

--Какие ресурсы поглощает ПО?

--Какие сбои могут быть в ПО?