С тех пор как появились инжекторные двигатели так сразу и в автомобили проникло программное обеспечение. В связи с этим появился стандарт 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/1i11ZFEse_zPntcOXRBFQRXnt-fOBlLomDzyqb-PsuKc/edit#gid=0

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

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--Допустим компания разрабатывает автомобильный блок телематики для удаленного зажигания в холодном климате и для отслеживания перемещения авто по GNSS. Какой минимальный уровень ASIL (A, B, C, или D) выбрать для разработки модуля телематики? Ведь телематика из-за ошибки в программе может послать команду заглушить двигатель прямо на автостраде на скорости 140км./ч.

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

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

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

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

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

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

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

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

То что я перечислил выше это в основном для ASIL-A. Допусти мы захотели делать устройство по самому строгому уровню ASIL-D. Какие придется предпринять экстра усилия?

Вот неполный список того, что настоятельно рекомендуется для ASIL-D. Проверять делитель на ноль перед делением, проверять аргументы функций, всегда определять default ветку в операторе switch, для каждого конечного автомата в прошивке рисовать граф переходов (StateFlow), стараться не использовать прерывания и указатели, делать инспекцию программ, прототипы функций должны генерироваться автоматически, код сопровождать псевдокодом, не использовать динамического выделения памяти, избегать глобальных переменных, не использовать скрытного преобразования типов, не использовать скрытную передачу данных или управления, не использовать рекурсию, анализировать ресурсы, которые поглощает программа. При тестировании писать тесты для граничных значений, снимать покрытие ветвей и вызова функций после прогона тестов, проверять код на реальном автомобиле, делать мажорирование калибровочных данных, оснащать калибровочные данные контрольной суммой.

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

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

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

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

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

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

Словарь

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

https://ru.wikipedia.org/wiki/V-Model

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

Вопросы

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

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