Крис Хоббс (Chris Hobbs) в своей фундаментальной работе «Embedded Software Development for Safety-Critical Systems» [1] приводит распространенное среди программистов мнение о том, что накладывать ограничения на языки программирования, это как заказывать Пикассо создание картины, при этом запрещать ему использовать желтый цвет. Тем не менее, сложно представить себе предприятие, которое серьезно занимается разработкой программного обеспечения для систем ответственного назначения, у которого в писанных или неписанных стандартах не было бы указаний о том, какой язык программирования применять и, мало того, как его применять.

Данная статья посвящена подходу, который определен в стандарте IEC 61508 и который состоит в применении для разработки ответственного программного обеспечения безопасных подмножеств языков программирования С и С++.

IEC 61508 имеет семь частей и официальный перевод на русский язык, имеющий статус национального стандарта Российской Федерации. Для обсуждаемой темы нас, в первую очередь, интересуют часть 3 «Требования к программному обеспечению» [2], которая содержит необходимые базовые принципы, и часть 7 «Методы и средства» [3], которая предлагает конкретные рекомендации. Далее мы рассмотрим стандарты “MISRA C:2012” [4] и “MISRA C++:2008” [5], которые имеют для программистов самое непосредственное практическое значение.

Программирование как инструмент управления рисками

IEC 61508 содержит структурированные и систематизированные рекомендации о применении различных средств и методов снижения риска на различных стадиях жизненного цикла разработки. Написание программного кода, т.е. кодирование, является одной из стадий. Прочем, смею заметить, её физически невозможно исключить даже при самом недетерминированном процессе разработки программного обеспечения.

Разумеется, меры по снижению риска имеют свою цену, выражаемую в затратах рабочего времени на их реализацию. А рабочее время каждого сотрудника имеет вполне конкретное денежное выражение.

На одной из конференций по программному обеспечению для авионики я услышал историю про некоторую систему управления, разработанную крупной международной компанией. Продукт должен был соответствовать требованиям регуляторов 66 стран, поэтому только в 2015 году аудиты предприятия-разработчика и продукта проводили свыше ста организаций. За год на обеспечение проведения этих аудитов разработчик затратил 3500 человеко-дней.

Чем выше требования к снижению риска, тем выше затраты на выполнение соответствующих мероприятий. Поэтому IEC 61508 делит системы, обеспечивающие функциональную безопасность, на четыре иерархические категории, именуемые по-русски уровнями полноты безопасности (УПБ). Самый высокий уровень – УПБ4, самый низкий – УПБ1. В английском оригинале используется термин safety integrity level (SIL).

Критерии выбора языка программирования

Приложение А седьмого раздела IEC 61508 [3] содержит весьма информативное руководство по выбору методов и средств, а приложение С, в свою очередь, содержит обзор методов и средств с их кратким описанием и ссылками на источники информации о них.

Указания по выбору формулируются весьма просто: для каждого уровня и каждого средства задается обозначение. Эти обозначения называют “рекомендациями”. Самыми жесткими рекомендациями являются HR (настоятельно рекомендуется) и NR (категорически не рекомендуется).

Разумеется, для разработки программного обеспечения систем ответственного назначения существует ряд специализированных языков программирования, таких как, например, Ada, D, FORTRAN 77 или RUST, в которых обеспечивается строгая типизация данных и решены другие важные вопросы, связанные с кодированием. Все они имеют свои ниши и являются весьма интересными с инженерной точки зрения. Но, поскольку мы с Вами, уважаемый читатель, реалисты, то для данной статьи выбор пал на тот язык, на котором на самом деле чаще всего пишут программы для систем ответственного назначения – на С. А коль скоро такие объектно-ориентированные технологии, как Qt и Mesa 3D, завоёвывают всё большую популярность среди разработчиков систем реального времени, то нельзя обойти вниманием и вопросы применения С++.

Что же об этих языках говорит МЭК 61508?

Для высоких уровней полноты безопасности – УПБ3 и УПБ4 – для языков С, С++ и, на всякий случай замечу, Java задана рекомендация NR. Однако для С и С++, как сказано в стандарте, «с подмножеством и стандартом кодирования, а так же использование инструментов статического анализа», задана рекомендация HR. В тоже время, например, для Java, даже для подмножества с выключенной или детерминированной сборкой мусора, для уровней УПБ3 и УПБ4 указана рекомендация NR.

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

Давайте с вами разберемся, какие мы можем применять подмножества и стандарты кодирования для языков С и С++.

Язык С

Наиболее авторитетным документом, определяющим подмножество языка С является стандарт, известный как ”MISRA C” [4]. На основе него или, по крайней мере, под его влиянием, разрабатываются стандарты безопасного кодирования различных организаций, например, стандарт кодирования компании JPL [6].

Во вводной части “MISRA C” приводит причины популярности языка С. Назовем некоторые из них:

• Программы, написанные на С, могут быть скомпилированы в эффективный машинный код;
• Существует готовые компиляторы С для самых разных аппаратных архитектур;
• С поддерживается значительным количеством инструментов статического анализа и тестирования;
• Существует международный стандарт на язык С [7], [8];
• Накоплен большой опыт применения С при разработке систем ответственного назначения.

В тоже время разработчики “MISRA C” констатируют недостатки языка С. В их числе неточные определения, позволяющие разработчикам компиляторов по-разному реализовывать некоторый функционал, а так же возможность внесения ошибок, которые не являются таковыми с точки зрения компилятора – классическая проблема замены знака присвоения на знак равенства или наоборот. Так же в качестве недостатка, являющегося обратной стороной эффективной компиляции кода, указывается отсутствие контроля ошибок времени исполнения, что требует от программиста явного контроля ошибок в программе.

“MISRA C” допускает использование как С99, так и С90. Рекомендации касательно стандарта C11/С18 отсутствуют только по причине того, что на момент завершения работы над текстом “MISRA C” рабочая группа ISO/IEC еще не успела одобрить новую версию языка С, а ссылаться на неутвержденный стандарт было бы моветоном. Поэтому, разумеется, С11/С18 вполне может применяться.

Большое внимание стандарт придает выбору непосредственно инструментальных средств: компиляторов и статических анализаторов. При этом – весьма не случайно – упоминаются стандарты IEC 61508, ISO 26262 [9] и DO-178C [10]. Если в этот список добавить ещё упоминаемые в “MISRA C” стандарты EN 50128 [11] и IEC 62304 [12], которые касаются жизненного цикла разработки программного обеспечения, то, в общем-то, круг замкнётся. Все остальные стандарты, относящиеся к функциональной безопасности программного обеспечения, содержат уточнения или специализированные варианты тех принципов и подходов, которые описаны в перечисленных документах. При этом я вовсе не хочу сказать, что не нужно изучать другие документы – безусловно, такие стандарты, как, например, IEC 60880 [13] очень важны с точки зрения применения тех или иных средств и методов к решению определенного класса задач.

Указания “MISRA C” бывают двух типов: правила и директивы.

Правилами называют такие указания, соответствие которым можно проверить путем анализа исходного текста без каких-либо иных источников информации. Статические анализаторы должы уметь строго проверять выполнение правил. К директивам же относятся такие указания, которые не могут быть сформулированы так строго, как правила. Для анализа соответствия кода директиве одного только кода не достаточно: может потребоваться изучение проектной документации.

Статические анализаторы могут помогать в ходе проверок, но результаты их работы нужно корректно интерпретировать.

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

Если код, написанный на языке С, заявлен как соответствующий стандарту “MISRA C”, то он должен без каких-либо оговорок или исключений удовлетворять всем обязательным указаниям стандарта.

Аналогичным образом С-код, заявленный как соответствующий “MISRA C”, должен удовлетворять всем «требуемым» указаниям стандарта. Разница состоит в том, что для указаний этой степени допускаются отклонения, каждое из которых должно быть четко задокументировано. Пример документального оформления отклонения приведен в одном из приложений стандарта. Для некоторых проектов «требуемые» указания по решению заказчика или разработчика могут приравниваться к «обязательным».

И, наконец, «рекомендованные» указания могут нарушаться без документально оформленных объяснений. Однако следует помнить, что эти указания были выработаны на основе колоссального опыта, поэтому игнорировать их не стоит ни в коем случае. Стандарт советует оформлять документ, объясняющий причину невыполнения рекомендаций. Мало того, для некоторых проектов «рекомендуемые» указания по решению заказчика или разработчика могут приравниваться к «требуемым» или даже «обязательным».

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

Ну и наконец, что бы окончательно Вас запутать, последняя классификация: по масштабу анализа правила делятся на модульные и системные. Модульными называют такие правили, для соответствия которым достаточно проверять единицу компиляции, т.е. отдельный файл. Как не сложно догадаться, для проверки соответствия правилу масштаба системы необходимо анализировать две и более единицы компиляции, а чаще всего – весь исходный текст проекта.
Правила по области их применения разбиты на двадцать две группы, а директивы на четыре группы. Есть указания, которые относятся к типам данных, к работе с указателями, к операторам управления, к директивам препроцессора и т.д.

Пример «требуемого» правила, входящего в группу «Стандартные библиотеки», разрешимого, масштаба единицы компиляции: функции выделения и освобождения памяти, определенные в заголовочном файле <stdlib.h> стандартной библиотеки С, использоваться не должны. Назначение это правила достаточно очевидное: сократить такие распространенные ошибки программирования, как утечка памяти, освобождение невыделенной памяти, доступ к выделенной памяти до инициализации и т.п. Допустим, Вам все-таки необходимо использовать «кучу». Поскольку правило «требуемое», а не «обязательное», то его можно «нарушить», задокументировав обоснование, почему это сделано. Но в таком случае вступают в силу обязательные правила из группы «Ресурсы», нерешаемые, масштаба системы:

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

Как видите, второе из указанных правил в какой-то мере сужает применение функции free() по сравнению, например, с функцией malloc().

В заключение этого краткого обзора стандарта “MISRA C” хотелось бы подчеркнуть, что изучение этого документа, на мой взгляд, обязательно для любого программиста, который использует язык С при разработке приложений ответственного назначения. Причем независимо от того, внедрен этот стандарт в Вашей организации или нет. Как минимум он позволит углубить знания С и разобраться во многих нюансах этого языка. Поскольку для чтения этого документа нужна персональная или корпоративная лицензия, можно обратить внимание на разработанные под его влиянием правила кодирования компании JPL [6], упомянутые выше, и краткий, но эффективный и достаточно знаменитый набор десяти правил Жерара Хольцмана (Gerard J. Holzmann) [14].

Язык С++

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

Стандарт ГОСТ Р МЭК 61508-7-2012 [3] в приложении G коротко определяет (рекомендация HR для УПБ3 и УПБ4) базовые принципы написания объектно-ориентированного кода независимо от языка программирования, например,:

• Наследование допускается только с целью уточнения базового класса;
• Глубина наследования должна быть ограничена;
• Множественное наследование допускается только для интерфейсных классов;
• Должен осуществляться контроль переопределения методов и операций.

Стандарт настоятельно рекомендует (HR) использовать апробированные паттерны (шаблоны) проектирования и программные каркасы (фреймворки). И действительно, каркасы и автоматически сгенерированный код, вероятно, являются основными путями применения языка С++ в системах ответственного назначения. С конца 1990-х годов росла популярность фреймворков с генерацией кода из UML-моделей, которые удобно использовать для реализации алгоритмов, основанных на конечных автоматах. Затем, когда мощность встраиваемых систем позволила использовать богатые UX, передовые коммуникационные и другие технологии, широкое распространение получил также фреймворк Qt. Паттернам для разных этапов проектирования посвящена, например, работа Брюса Дугласа (Bruce Paul Douglass) “Real-Time Design Patterns” [15]. В качестве примеров фреймворков можно привести OXF от IBM Rational и RXF от Willert Software Tools.

Как бы то ни было, The Motor Industry Software Reliability Association не осталась в стороне от процесса и внесла свой вклад в разработку подходов к безопасному кодированию на языке С++, выпустив стандарт MISRA C++:2008 [5]. Несмотря на то, что уже несколько лет назад был принят стандарт С++11 [16], MISRA C++ всё ещё основан на С++03 [17], поскольку на момент утверждения это была действующая редакция. MISRA C++ прямо заявляет, что разработчики документа не имеют намерения продвигать язык С++. Их целью является рекомендованное IEC 61508 определение подмножества С++, требуемого для различных УПБ при разработке программного обеспечения ответственного назначения.

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

Заключение

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

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

Среди некоммерческих продуктов я бы выделил популярную утилиту cppcheck, по применению которой можно найти много полезной информации в открытом доступе, например статья на ресурсе Хабрахабр. Что касается анализа кода на соответстие MISRA C и MISRA С++, то список возможных инструментов можно найти в соответствующих статьях Википедии.

Использованная литература:

1. Chris Hobbs. Embedded Software Development for Safety-Critical Systems. CRC Press, 2016.
2. ГОСТ Р МЭК 61508-3-2012 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению (пер. IEC 61508-3:2010). М.: Стандартинформ, 2014.
3. ГОСТ Р МЭК 61508-7-2012. Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства (пер. IEC 61508-7:2010). М.: Стандартинформ, 2014.
4. MISRA C:2012 Guidelines for the use of the C language in critical systems. MIRA Limited, 2012.
5. MISRA C++:2008 Guidelines for the use of the C++ language in critical systems. MIRA Limited, 2008.
6. JPL Institutional Coding Standard for the C Programming Language, 2009. URL: itech.fgcu.edu/faculty/zalewski/CEN4935/JPL_Coding_Standard_C.pdf (дата обращения 25.06.2020).
7. ISO/IEC 9899:2011 Information technology — Programming languages — C. ISO/IEC, 2011.
8. ISO/IEC 9899:1999 Information technology — Programming languages — C. ISO/IEC, 1999.
9. ISO 26262-6:2011 Road vehicles — Functional safety — Part 6: Product development at the software level, ISO, 2011.
10. DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, 2012.
11. EN 50128 ed. 2 Railway applications — Communication, signalling and processing systems — Software for railway control and protection systems. CEN, 2011.
12. IEC 62304:2006 Medical device software – Software life cycle processes. IEC, 2006.
13. IEC 60880:2006 Nuclear power plants — Instrumentation and control systems important to safety — Software aspects for computer-based systems performing category A functions. IEC, 2006.
14. Gerard J. Holzmann. The Power of 10: Rules for Developing Safety-Critical Code. IEEE Computer Society, 39 (6): p.p. 95–99, 2006. URL: ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1642624 (дата обращения 25.06.2020).
15. Bruce Powel Douglass. Real-Time Design Patterns: robust scalable architecture for Real-time systems. Addison-Wesley, 2003.
16. ISO/IEC 14882:2011 Information technology — Programming languages — C++. ISO/IEC, 2011.
17. ISO/IEC 14882:2003 Information technology — Programming languages — C++. ISO/IEC, 2003.