Стандарты кодирования и регуляторные требования

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

Эта статья - обзорная карта местности, а не руководство по сертификации. Её задача - чтобы вы понимали, о чём идёт речь, когда в вакансии написано «опыт работы по MISRA» или «проекты по ISO 26262», и знали, где искать подробности.

Стандартов и требований очень много, и ниже собраны лишь самые заметные. Единого «обязательного набора» не существует: каждый проект использует своё подмножество в зависимости от отрасли, страны, заказчика и класса критичности. Разбираться в конкретных стандартах имеет смысл тогда, когда они реально встретились на вашем проекте, а не про запас.

Требования и сроки меняются. Перед принятием решений сверяйтесь с актуальными редакциями стандартов и с юристами вашей компании - эта статья для ориентирования, а не для юридических выводов.

Стандарты кодирования

Ограничивают язык до подмножества, в котором меньше способов выстрелить себе в ногу: запрет на динамическое выделение памяти после инициализации, на исключения, на неявные приведения типов и так далее. Соблюдение проверяется статическими анализаторами - вручную такие своды правил не контролируют.

MISRA C++:2023 - misra.org.uk

Наиболее известный свод правил для C++ в безопасно-критичных системах. Пришёл на смену MISRA C++:2008 и охватывает C++17. Важное изменение: в него влились рекомендации AUTOSAR C++14, поэтому вместо двух конкурирующих сводов правил, как было раньше, теперь развивается один. Если встретите проект на AUTOSAR C++14 - это предыдущее поколение того же подхода (autosar.org).
SEI CERT C++ - wiki.sei.cmu.edu

Свод правил с акцентом на безопасность: как не допустить конструкций, приводящих к уязвимостям. В отличие от MISRA, доступен бесплатно и открыто - хороший способ познакомиться с самим жанром, даже если ваш проект не сертифицируется.
C++ Core Guidelines - isocpp.github.io

Рекомендации от Бьярне Страуструпа и Херба Саттера. В отличие от MISRA, не ограничивают язык, а наоборот - подталкивают к современному стилю. Формально не регуляторный документ, но полезны любому C++ разработчику; частично проверяются через clang-tidy и Microsoft GSL.

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

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

Базовый стандарт в этой области - IEC 61508, вводящий уровни полноты безопасности SIL 1-4. Отраслевые стандарты ниже - это его адаптации:

ISO 26262 - автомобилестроение - iso.org

Функциональная безопасность дорожных транспортных средств. Вводит уровни ASIL от A до D, где D - самый строгий (например, управление тормозами или рулевым управлением). Именно здесь чаще всего встречается связка «ISO 26262 + MISRA C++».
IEC 62304 - медицинское ПО - iso.org

Жизненный цикл программного обеспечения медицинских изделий. Определяет классы безопасности A, B и C в зависимости от того, может ли отказ привести к вреду здоровью и насколько тяжёлому. Соблюдение этого стандарта - основной способ показать соответствие европейскому регламенту о медицинских изделиях MDR (Regulation (EU) 2017/745), а также требованиям FDA в США.
DO-178C - авионика - rtca.org

Требования к бортовому ПО. Уровни критичности DAL от A до E; для уровня A требуется, в частности, покрытие тестами на уровне отдельных условий в логических выражениях (MC/DC). Считается одним из самых требовательных и дорогих в соблюдении стандартов отрасли.

Кибербезопасность и цепочка поставок

Относительно новая для C++ мира тема: регуляторы переносят ответственность за уязвимости на производителя ПО.

EU Cyber Resilience Act (CRA) - digital-strategy.ec.europa.eu

Регламент ЕС, распространяющийся на продукты с цифровыми элементами, поставляемые на европейский рынок - от промышленных контроллеров до потребительской электроники. Требует безопасной разработки, выпуска обновлений безопасности в течение срока поддержки и уведомления об активно эксплуатируемых уязвимостях. Вступил в силу в декабре 2024 года, основные обязанности применяются с конца 2027 года, обязанности по уведомлению - раньше. Важно, что затрагивает не только «безопасно-критичные» отрасли, а практически любое ПО в составе продаваемого продукта.
SBOM (Software Bill of Materials) - spdx.dev, cyclonedx.org

Машиночитаемая опись всех компонентов и зависимостей, входящих в поставляемое ПО, - «состав продукта» по аналогии с составом на упаковке. Нужна, чтобы при обнаружении уязвимости в популярной библиотеке можно было быстро ответить на вопрос «а есть ли она у нас». Два основных формата - SPDX и CycloneDX; оба стандартизованы. Для C++ тема ощутимая: зависимости часто подключаются исходниками или собираются вручную, и что именно попало в сборку, без SBOM бывает неочевидно.

Что это значит на практике

Если вы попадёте на такой проект, изменится не столько язык, сколько окружение вокруг кода:

Подмножество языка. Часть привычных возможностей будет запрещена - обычно динамическая память после инициализации, исключения, RTTI, иногда шаблоны и стандартная библиотека целиком.
Обязательный статический анализ. Сборка падает не только от ошибок компилятора, но и от нарушений правил. Отклонения от правил оформляются письменно и согласуются, а не просто подавляются в коде.
Трассируемость. Для каждой строки кода можно проследить, из какого требования она возникла и каким тестом покрыта. Отсюда высокие требования к оформлению задач и коммитов.
Квалификация инструментов. Компилятор, анализатор и фреймворк тестирования тоже нужно обосновать - поэтому версии обновляются редко, а «взять последний GCC» не всегда возможно.
Тяжёлое ревью и документация. Объём сопроводительных документов может превышать объём кода, а сроки - заметно превосходить привычные по обычной разработке.

Кому это действительно нужно

Не всем. Если вы пишете игры, десктопные приложения, backend или трейдинг - на практике вы, скорее всего, не столкнётесь с этими стандартами, и специально изучать их незачем.

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

Исключение - CRA и SBOM. Они касаются гораздо более широкого круга продуктов, чем классическая функциональная безопасность, так что познакомиться с ними стоит и «обычным» разработчикам, чьи продукты продаются в Европе.

На главную страницу