Стандарты безопасности: DO-178C, ISO 26262

370 млн долларов сгорело за 37 секунд. Ariane 5, 1996 год: 64-битное переполнение в модуле, скопированном из Ariane 4 без анализа применимости. Именно такие катастрофы породили стандарты, где каждая строка кода требует доказательства своей безопасности.

• **Авиация:** Boeing 737 MAX MCAS - отсутствие ASIL/DAL анализа для датчика угла атаки привело к двум катастрофам (346 жертв). После расследований FAA ужесточило применение DO-178C для Flight Control Software.
• **Автомобили:** Tesla Autopilot работает под ISO 26262 ASIL-B для систем помощи водителю. Полная автономность (Level 4) требует ASIL-D - отсюда сложность сертификации беспилотных автомобилей.
• **Медицина:** IEC 62304 - аналог ISO 26262 для медицинских устройств. Программируемые инсулиновые помпы и дефибрилляторы разрабатываются по этому стандарту с SIL 3 требованиями.

DO-178C: авиационный стандарт

В 1996 году самолёт Ariane 5 взорвался через 37 секунд после старта. Причина - переполнение 64-битного числа в модуле, унаследованном из Ariane 4, где такой сценарий был невозможен. Потери: 370 млн долларов. Именно после подобных катастроф появились стандарты, превращающие разработку ПО для критических систем в доказуемый процесс. DO-178C - это стандарт RTCA для авиационного программного обеспечения, принятый FAA, EASA и большинством авиационных регуляторов мира. Он не описывает, как писать код - он описывает, что надо доказать перед выпуском.

DO-178C делит ПО на пять уровней DAL (Design Assurance Level) - от A (катастрофический отказ) до E (без последствий). Для DAL-A требуется MC/DC coverage - Modified Condition/Decision Coverage, самый строгий вид покрытия кода. Каждое требование трассируется от спецификации до тест-кейса и обратно. Никаких мёртвых ветвей, никакого неиспользуемого кода.

ISO 26262: функциональная безопасность автомобилей

В 2009 году Toyota отозвала 8 миллионов автомобилей из-за подозрений в неконтролируемом ускорении. Независимое расследование NASA обнаружило в прошивке системы управления двигателем задачу без watchdog-таймера и стек без защиты от переполнения. После этого скандала автопроизводители перешли от самодеятельности к ISO 26262 - международному стандарту функциональной безопасности для дорожных транспортных средств. ISO 26262 принят в 2011 году, расширен в 2018 для полуавтономных систем. Он охватывает весь V-cycle: от концепции безопасности до вывода из эксплуатации.

ISO 26262 использует концепцию HARA (Hazard Analysis and Risk Assessment) для определения уровня риска. Каждая опасность оценивается по трём осям: Severity (S0-S3), Exposure (E0-E4), Controllability (C0-C3). Произведение этих факторов даёт ASIL (Automotive Safety Integrity Level) от QM до ASIL-D. Системы с ASIL-D - это электроусилитель руля, система ABS, управление тормозами.

ASIL: уровни целостности и декомпозиция

ASIL - это не просто метка на коробке с чипом. Это набор требований к процессу разработки, архитектуре, верификации и инструментам. ASIL-D диктует, что код должен писаться на MISRA C, компилятор должен быть сертифицирован (IEC 61508), а тест-покрытие должно достигать 100% MC/DC. Но есть изящный инструмент: ASIL-декомпозиция. Если систему ASIL-D разделить на два независимых канала ASIL-B, совокупный ASIL остаётся D при условии действительной независимости каналов.

Правило ASIL-декомпозиции: D = B + B, C = A + A, B = A + QM. QM (Quality Management) - минимальный уровень без специальных требований к функциональной безопасности. Декомпозиция требует архитектурной независимости: раздельные MCU, раздельные источники питания, раздельные цепи коммуникации. Иначе общий режим отказа (Common Cause Failure) аннулирует всю декомпозицию.

DAL vs ASIL: сравнение стандартов

DO-178C и ISO 26262 решают одну задачу в разных доменах, но идут разными путями. DO-178C - процессный стандарт: соответствие достигается через следование задокументированному процессу разработки и верификации. ISO 26262 - целевой стандарт: он определяет цели безопасности (Safety Goals) и требует доказать их достижение. Для разработчиков embedded-систем принципиальное различие в том, что DO-178C практически запрещает динамическое управление памятью и рекурсию для DAL-A/B, тогда как ISO 26262 эти ограничения задаёт через MISRA, но более гибко.

Существует третий важный стандарт - IEC 61508 для промышленных систем. Он вводит понятие SIL (Safety Integrity Level) 1-4 и является родоначальником ISO 26262. DO-178C и IEC 61508 частично гармонизированы через DO-254 (для аппаратуры) и ARP 4754A (для системного уровня). Знание этих отношений критично при разработке систем, сертифицируемых по нескольким стандартам одновременно (например, авиационная автоматика с электронными компонентами от автопрома).

Ключевые идеи

• **DO-178C** делит ПО на уровни DAL-A..E. DAL-A требует 100% MC/DC, запрет динамической памяти и рекурсии, полную трассируемость требований.
• **ISO 26262** использует HARA для определения ASIL через Severity, Exposure, Controllability. ASIL-D допускает декомпозицию: D = B + B при архитектурной независимости каналов.
• **Оба стандарта** требуют MC/DC для наивысших уровней, Tool Qualification для CI-инструментов и полную документацию Safety Case - сертификация занимает годы, не дни.

Связанные темы

Стандарты безопасности опираются на концепции из других областей RTS:

• Формальные методы для RTS — DO-178C DAL-A и ASIL-D на практике сочетаются с формальной верификацией через model checking
• Планировщики задач в RTS — WCET analysis и priority assignment - обязательная часть safety case для ASIL-D и DAL-A систем

Вопросы для размышления

• ASIL-декомпозиция позволяет заменить один канал ASIL-D двумя каналами ASIL-B. Какие архитектурные условия делают эту замену недействительной, и как это проверяется при аудите?
• DO-178C требует квалификации инструментов (TQL). Если команда использует open-source компилятор GCC для DAL-A кода - что конкретно нужно сделать для compliance?
• Почему запрет динамической памяти (malloc) в DO-178C DAL-A считается разумным с точки зрения safety, хотя modern C++ активно использует RAII и heap?

Связанные уроки

• emb-01