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

source

Как наиболее полно оценить безопасность, и ничего при этом не упустить? Возможно ли собрать в одном документе (или диаграмме) все разнообразие артефактов, относящихся к безопасности, и организовать их таким образом, чтобы можно было наглядно представить любой аспект с понятным уровнем детализации?

Технические специалисты были бы рады изобретению такого философского камня, который, если даже не обеспечил бы безопасность, то, по крайней мере, оценил бы ее с требуемым уровнем полноты. Подобные наработки существуют уже более 20 лет, однако, практически не известны русскоязычному читателю. Речь пойдет о методологии Assurance Case (или Safety Case), под которой подразумевается структурированный набор аргументов и документальных подтверждений, обосновывающих соответствие системы или сервиса заданным требованиям.

Введение

Перед прочтением статьи хотел бы обратить ваше внимание на пару важных моментов. Изложенный материал применим, в первую очередь, для объектов критической информационной инфраструктуры (КИИ). Для таких объектов, в частности, для информационных и управляющих систем, должен быть выполнен анализ безопасности. Результаты анализа безопасности представляются в виде соответствующих отчетов. Все это выполняется уже десятки лет, однако, отчеты, как правило, имеют произвольную текстовую форму, в логике которой не всегда просто разобраться.

Основная идея излагаемого подхода состоит в том, что результаты анализа безопасности могут быть представлены в графическом виде с использованием полуформальных нотаций, со всеми вытекающими отсюда преимуществами. Таким образом, Assurance Case является способом интегрального представления всех мер по обеспечению и оцениванию безопасности, не заменяя и не отменяя такие частные методы, как, например, тестирование, статический анализ кода, расчет надежности, FMEA, анализ рисков и т.п. Данная статья продолжает ранее опубликованную серию статей по безопасности.

Карты аргументов и их философские истоки

Как мы можем понять или утверждать, что некоторый объект является безопасным? Очевидно, для этого надо ввести ряд критериев. Однако, для этих критериев нам необходимо определить, насколько наше знание об объекте является достоверным? Почему мы можем этому знанию доверять? Что делает наши доводы и рассуждения действительно заслуживающими доверия? Углубившись в подобные проблемы, нельзя обойтись без философских дисциплин, таких как, онтология, гносеология, эпистемология, логика, а также, без великих мыслителей, которых волновали эти вопросы. В античном мире таковыми являлись Аристотель и Платон, а в эпоху нового времени основоположником современного научного метода считается Френсис Бэкон.

Что же можно сделать для обоснования или оценки безопасности разумным и логичным путем? В основе такого подхода лежит теория аргументации. Новый импульс современному развитию аргументации был дан в работе британского философа Стивена Тулмина под названием The Uses of Argument, изданной в 1958 году. Тулмин расширил логический импликативный вывод дополнительными параметрами и предложил представлять эту операцию в графической форме. Нотация Тулмина оперирует следующими сущностями: data (D) исходные данные для анализа, claim (С) цель логического импликационного вывода (If D So C), warrant (W) дополнительный аргумент, qualifier (Q) степень уверенности в результатах логического вывода, rebuttable (R ) дополнительный контраргумент (Рисунок 1).


Рисунок 1. Нотация Стивена Тулмина

Карты аргументов или аргументации (Argument Map) использовались в целях визуализации рассуждений и до Тулмина, но именно он наиболее удачно обобщил структурную модель для анализа и верификации аргументов. Отметим, что в современных картах аргументов, как правило, не используется нотация Тулмина, все упрощено, например, как на рисунке ниже. Это нотация, используемая платным онлайн сервисом Rational (бесплатная версия существует, но она крайне ограничена по функционалу) (Рисунок 2). Платная версия умеет преобразовывать полученные диаграммы в логически структурированный текст. На сайте также доступны бесплатные guides & tutorials по критическому мышлению и составлению карт аргументов.


Рисунок 2. Карта аргументов, разработанная при помощи сервиса Rational

Как видим, все довольно прозрачно, существуют всего четыре сущности и три типа связи между ними. Результат логического ввода называется Contention, подтверждающий аргумент Reason (связь because), контраргумент Objection (связь but), а вот контраргумент для контраргумента имеет специальное название Rebuttal (связь however).

На данный момент не существует общепринятой нотации для составления карт аргументов. Нет единства и в обозначениях, применяемых для структуры аргументов. Например, результат логического вывода может называться claim, contention, conclusion, goal. Аргументы могут называться premise, justification и т.д. В области моделирования аргументов существует ряд международных инициатив и сообществ (например, Argument Interchange Format, AIF), но вопросы унификации они не решили. Существуют исследования, проводящие параллели между картами аргументов и ментальными картами (Mind Map, наверно, все о них слышали). Действительно, возможности Mind Map редакторов позволяют построить аналог карты аргументов.

История и концепция Assurance Case

Какое отношение имеет все это к безопасности? Чтобы ответить на этот вопрос, обратимся ко второй половине ХХ века, именно там берет свое начало современная теория и практика обеспечения безопасности. Тогда, в результате развития сложных техногенных отраслей, таких, как атомная энергетика, космическая техника, нефтегазовая и химическая промышленность, транспорт, человечество столкнулось с техногенными катастрофами невиданных ранее масштабов.

Тогда и появилась первые отчеты по анализу безопасности, в которых сводились воедино вся релевантные требования, а, также, информация, подтверждающая их соблюдение. Позже появился термин Safety Case (по сути, аналитический отчет по безопасности), который являлся предшественником Assurance Case. Отметим, что термины Safety Case или Assurance Case напрямую перевести термин на русский язык невозможно, в данном контексте, наиболее логичным переводом является обоснование безопасности. Хотя, например, в российских переводах серии стандартов ИСО/МЭК 15026 (Systems and software engineering Systems and software assurance) Assurance Case переведен, как гарантийный случай.

Следует отметить, что в некоторых отраслях термин Safety Case применяется и в настоящий момент, наравне с Assurance Case. Assurance Case, будучи более современным термином, противопоставляется Safety Case в том смысле, что на сегодняшний день система должна соответствовать не только требованиям safety (функциональная безопасность), но, также, и security (информационная безопасность). Поэтому, предлагается использовать понятие Assurance Case, а Safety Case считать его частным случаем.

Под Assurance Case, в современном понимании этого термина, подразумевается отчет о выполненном анализе безопасности, включающий визуальное представление в виде графа или таблицы, полученных с применением полуформальных нотаций (о нотациях речь пойдет ниже). При этом, получается некоторое разночтение одного и того же термина, поскольку возможно трактовать Assurance Case, с одной стороны, как некоторый документ (отчет об анализе безопасности или отчет об обосновании безопасности), а, с другой стороны, как систему аргументации с использованием полуформальной нотации. В идеале, Assurance Case, может включать оба компонента, то есть документ, оценивающий безопасность, строится на основании модели аргументов.

Вернемся, однако, в ХХ век. Первым нормативным документом, требующим разрабатывать и анализировать Safety Case для потенциально опасных индустриальных объектов, стал CIMAH (Control of Industrial Major Accidents Hazards) Regulations, первоначально выпущенный в Великобритании в 1984 году, а затем адаптированный и в ряде других стран. Более широкое внедрение Safety Case в практику стало происходить после небывалой аварии на нефтяной платформе Piper Alpha в Северном море, унесшей в 1988 году жизни 167 человек.

В 1990-х годах исследователи продолжают искать новые подходы к оцениванию безопасности. Идея, вроде бы, лежит на поверхности: давайте разработаем специальную нотацию для обоснования соответствия техногенных объектов и систем требованиям по безопасности. За дело взялись две британские университетские команды, лондонский университет Сити (City, University of London), где была создана спин-офф компания Adelard, и университет Йорка (University of York). Надо сказать, что и в наши дни Adelard и университет Йорка занимают лидирующие позиции в области продвижения Assurance Case.

Для разработки нотаций упор был сделан на логическую аргументацию того, что свойство или компонент системы соответствует заявленным требованиям. В качестве теоретической основы были выбраны уже рассмотренные нами труды Стивена Тулмина. Будучи гуманитарием, Тулмин вряд ли он думал о техногенных системах, однако, в историю, он вошел, в том числе, и как основоположник аргументации для Assurance Case.

Взяв за основу, нотацию Тулмина, британцы вскоре разработали методологию Assurance Case (называемую в то время Safety Case) и довели результаты до практических индустриальных внедрений. В университете Йорка, была разработана Goal Structuring Notation (GSN), эту тему продвигал PhD студент Tim Kelly под руководством профессора John McDermid. В результате произошел тот редкий случай, когда диссертация Arguing Safety: A Systematic Approach to Managing Safety Cases. PhD thesis. University of York, 1998 уже больше 20 лет считается классическим трудом, и ее продолжают активно цитировать. Однако, подход к решению проблемы безопасности был, на мой взгляд, в большей степени академический, и, как результат, не был почему-то сделан вроде бы понятный и логичный шаг, связанный с разработкой программного средства для поддержки Assurance Case.

Adelard же, под руководством Robin Bloomfield и Peter Bishop, напротив, в первую очередь стремился к коммерциализации результатов. Параллельно с Йорком, в Лондоне была разработала нотация Claim, Argument and Evidence (CAE), а также программный инструмент Adelard ASCE (Assurance and Safety Case Environment), который поддерживает и CAE, и GSN. В Великобритании разработка Assurance Case (Safety Case) требуется законами и стандартами во многих областях, связанных с безопасностью, поэтому ASCE имеет здесь довольно устойчивый рынок. ASCE был и остается наиболее используемым инструментом разработки Assurance Case. Основной частью инструмента является графический редактор, в котором к графическим блокам может быть прикреплена дополнительная текстовая или гиперссылочная информация (Рисунок 3). Самостоятельно загрузить программное обеспечение ASCE с веб-сайта Adelard не получится. Вы должны заполнить запрос на 30-дневную пробную версию или академическую лицензию, после чего запрос будет рассмотрен компанией.


Рисунок 3. Интерфейс программы Adelard ASCE

Теперь рассмотрим две базовые нотации, применяемые для разработки Assurance Case (CAE и GSN).

Нотация CAE (Claim, Argument and Evidence)

Нотация CAE (Claim, Argument and Evidence цель, аргумент, подтверждение) оперирует тремя указанными сущностями: цели указывают на достижение требуемых свойств системы, подтверждения предоставляют документированный базис для аргументации, демонстрирующей достижение либо не достижение целей, аргументы строятся при помощи правил вывода и связывают подтверждения с целями. Обычно применяются такие аргументы, как детерминистские (или логические), вероятностные и качественные. Для обозначения целей, аргументов и доказательств вводятся графические примитивы, имеющие различную форму (Рисунок 4).

Рисунок4. Нотация Claim, Argument and Evidence (CAE): основные компоненты

Построение иерархии целей и подцелей является первым этапом разработки Assurance Case. Как показано на схеме, структура целей, аргументов и подтверждений не обязательно является трехуровневой, например, для поддержки аргументации могут использоваться дополнительные подцели. CAE нотация также легко трансформируется в табличный вид. Столбцами такой таблицы будут являться все те же цели, аргументы и подтверждения, между которыми теперь будут установлены связи в пределах табличных записей. Подобный подход к разработке Assurance Case используется, например, компанией exida.

Нотация GSN (Goal Structuring Notation)

GSN оперирует такими компонентами, как цель (goal, обозначается прямоугольником и является аналогом claim в CAE), стратегия аргументации (strategy, обозначается параллелограммом и является аналогом argument) и решение (solution, обозначается кругом и является аналогом evidence) (Рисунок5). Контекст (context) применяется для информационной поддержки целей. Для поддержки аргументации могут применяться предположение (assumptions) и обоснование (justifications). Структура целей имеет иерархический характер.


Рисунок5. Нотация Goal Structuring Notation (GSN): основные компоненты

Если сравнивать между собой CAE и GSN, то следует отметить, что CAE уделяет больше внимания обоснованию отдельных аргументов. Для этого выполняется детальное конструирование шагов аргументации. GSN больше фокусируется на типовых структурах (паттернах) аргументов. За счет большего числа сущностей, GSN является менее строгой, и, в то же время, при более лаконичном описании она может быть сведена к CAE. Применение каждой из нотаций может быть в достаточной мере субъективным, поскольку подход к конструированию аргументов зависит от лица, которое выполняет эту задачу. Некоторые практики Assurance Case отмечают, что в нотациях существует ряд пробелов, связанных с полнотой определения элементов семантики.

Сложилось так, что на сегодняшний день более распространенной является GSN. Формат GSN закреплен в стандарте Goal Structuring Notation (GSN) Community Standard, а также в метамодели данных Structured Assurance Case Metamodel (SACM) от Object Management Group (OMG).

База знаний: отрасли, стандарты, исследования, инструменты, альтернативные нотации

Assurance Case используется, в первую очередь, в тех отраслях, в которых его применение регламентировано нормативными документами. Лидером здесь является Великобритания и некоторые другие страны Британского содружества. В отчете британской Health Foundation Using safety cases in industry and healthcare (2012) говорится об опыте нормативного применения Assurance Case (Safety Case) в здравоохранении, авиации, атомной энергетике, автомобильной, оборонной, нефтехимической и железнодорожной отраслях.

Если рассматривать требования к применению Assurance Case за пределами Великобритании, то следует отметить:

• автомобильный стандарт ISO 26262:2011, Road vehicles Functional safety, входящий в семейство стандартов по функциональной безопасности, детализирующих требования МЭК 61508;
• документы European Organisation for the Safety of Air Navigation (EUROCONTROL): Safety Case Development Manual, 2006, EAD (European Aeronautical Information System Database) Safety Case, 2009, EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010;
• документированную общую позицию регулирующих организаций по ядерной безопасности в области лицензирования ПО для ядерных реакторов Licensing of safety critical software for nuclear reactors Common position of international nuclear regulators and authorised technical support organisations, 2018, согласована девятью странами (Бельгия, Германия, Канада, Испания, Корея, Китай, Великобритания, Швеция, Финляндия);
• стандарты серии ISO/IEC 15026, Systems and software engineering Systems and software assurance, которая включает четыре части: Part 1: Concepts and vocabulary (2019); Part 2: Assurance case (2011); Part 3: System integrity levels (2015); Part 4: Assurance in the life cycle (2012).
  

Также следует отметить ряд организаций (помимо уже упомянутых Adelard и High Integrity Systems Engineering Group из университета Йорка), которые активно работают в области Assurance Cases. К ним относятся:

• US-CERT (United States Computer Emergency Readiness Team), свою методологию они называют Security Assurance Cases;
• SEI/CMU (Sofrware Engineering Institute Carnegie Mellon University), в первую очередь, CERT Division, входящий в состав SEI, осуществляет исследовательскую и академическую поддержку для развития методологии Assurance Case и активно сотрудничает с US-CERT;
• NASA (National Aeronautics and Space Administration) в рамках программы Scientific and Technical Information (STI) применяет Assurance Case для оценивания безопасности беспилотников и некоторых космических аппаратов;
• среди всех академических публикаций, на мой взгляд, своей практической направленностью выделяются исследования John Rushby, выполненные по программам исследовательского института SRI International (бывший Stanford Research Institute), и особенно, отчет The Interpretation and Evaluation of Assurance Cases, к которому мы еще обратимся.

Из программных средств поддержки Assurance Case наиболее известным остается Adelard ASCE (Case Case and Safety Case Environment). Большинство проектов, упоминаемых в разные годы, так и не вышли на какой-либо серьезный уровень. NASA заявило о создании ПО AdvoCATE, но они применяют его в собственных целях, и не планируют выпускать на рынок. Учитывая простоту нотации, для составления диаграмм Assurance Case и их дополнения гиперссылками можно использовать, например, MS Visio.

Из альтернативных подходов к разработке Assurance Case можно также упомянуть программный инструмент NOR-STA. Он бы разработан польской компанией Argevide (spinoff Гданьского технологического университета). NOR-STA поддерживает собственную нотацию TRUST-IT. Разница состоит в том, что вместо графического представления NOR-STA использует структурированный иерархический список (Рисунок 6).



Рисунок6. Нотация Trust-IT: основные компоненты и пример использования

Сущности в иерархическом списке целей Assurance Case обозначаются разными значками. Для подтверждения соответствия заявлению используется стратегия аргументации, а факты или наблюдения, обоснования, предположения и дополнительные утверждения используются в качестве аналога подтверждений. В отличие от десктопного Adelard ASCE, NOR-STA используется онлайн и поддерживает распределенную командную работу.

Кроме того, Assurance Case применяется для решения следующих прикладных задач:

• оценивание атрибутов комплексных свойств, таких, как Quality, Dependability, Security;
• поддержка сертификации и стандартизации путем преобразование требований стандартов в структуру аргументов;
• Assurance Based Development (ABD) или разработка продукта, основанная на гарантиях, является разновидностью Model-Based Development (MBD);
• управление знаниями, например, моделирования структуры документации либо определение структурных связей в какой-либо области деятельности (бизнес процессы, документооборот, управления изменениями и т.д.).

Применение Assurance Case в области информационной безопасности

Security (Trustworthiness) Case известен, как одна из разновидностей Assurance Case. При необходимости, Security Case может быть дополнен компонентами Safety Case. Собственно говоря, идея Assurance Case и состоит в объединении атрибутов safety & security. В области сертификации существуют наработки для стандарта ISO/IEC 15408 (Общие критерии), для которого было выполнено преобразование требований в структуру, совместимую со структурой Assurance Case. Такое преобразование может быть выполнено и для других релевантных стандартов, например, для ISO 27000, или IEC 62443, или любых других фреймворков.

В качестве примера приведен фрагмент Security Assurance Cases, размещенный на сайте US-CERT. В этом фрагменте рассмотрено подтверждение реализации безопасного цикла разработки ПО (Software Development Life Cycle, SDLC). Фокус сделан на устранение дефектов кодирования (в частности Buffer Overflow), для чего применяются такие методы, как обучение программистов, ревью кода, статический анализ и тестирование. Можно, конечно, поспорить с полнотой этого фрагмента, но он приведен лишь в качестве иллюстрации (Рисунок 7).


Рисунок 7. Фрагмент Security Assurance Cases

Таким образом, хотя информационная безопасность это то приложение, где Assurance Case мог бы быть наиболее востребованным, следует констатировать, что несмотря на свой потенциал и ряд пилотных исследований, Assurance Case не стал общеизвестной практикой в этой области.

Пример практического применения Assurance Case

И, наконец, давайте рассмотрим на примере, как это все может работать. В основу положен подход, основанный на разработке структурированных аргументов.

Структурированные аргументы

Представим процесс разработки аргументов в виде двух последовательных шагов (Рисунок 8). Первый шаг, называемый шагом рассуждения (Reasoning Step, RS), это анализ подцелей (SC), которые направлены на достижение основной цели (С). На этом шаге развивается структура аргументации. На втором шаге, называемом шагом подтверждения (Evidential Step, ES), формулируются подтверждения (Evidece, E) в поддержку подцелей (SC), выработанных на предыдущем шаге. Для дальнейшей формализации шагов RS и ES используются типовые шаблоны структурированного текста (Structured Text, ST).


Рисунок 8. Шаги и компоненты структурированных аргументов

Иерархия требований

Представим иерархию или пирамиду требований, которые образуют структуру, соответствующую графу Assurance Case. В большинстве нормативных требований к компьютерным системам или к ПО структура требований включает 3 или 4 уровня (Рисунок 9).


Рисунок 9. Иерархия требований и ее связь с шагами аргументации

Нулевой уровень это мета-цель, согласно которой оцениваемая система должна соответствовать всем требованиям безопасности. На первом уровне достигаются глобальные цели безопасности, например, из требований МЭК 61508 к функциональной безопасности вытекают следующие цели:

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

На втором уровне группы требований поддерживают ту или иную глобальную цель. Например, требования к управлению безопасностью (согласно МЭК 61508) включают группы требований к управлению персоналом, управлению конфигурацией, управлению документацией и другие. Структура связей между нулевым, первым и вторым уровнями представляет собой достаточно простое дерево. Такая структура не требует детальной проработки аргументов, поскольку аргументы эти являются типовыми и многократно проверенными в различных проектах. Однако при переходе со второго уровня на более низкие требуются структурированные аргументы. При этом требования нижних уровней могут быть составными (то есть, включать ряд отдельных требований) или простыми (атомарными). Если все требования атомарные (составные требования отсутствуют), то данный уровень становится третьим, и тогда он напрямую связан с подгруппами требований. Если имеются составные требования, то получаем более сложную четырехуровневую структуру.

Для самого нижнего уровня, помимо RS, также следует применять ES. Поскольку неудобно добавлять подробную информацию о содержании аргументов в структуру графа, каждый из узлов графа Assurance Case, начиная со второго уровня, размечается описанием аргументов с использованием структурированного текста (ST). Граф Assurance Case на нижнем уровне уже не является деревом, потому что одно и то же подтверждение (E) может поддерживать разные подцели (SC).

Assurance Case для группы требований к управлению персоналом (МЭК 61508)

В качестве иллюстрации рассмотрим фрагмент Assurance Case применительно к требованиям МЭК 61508 к управлению персоналом (МЭК 61508-1, раздел 6).


Всего из МЭК 61508 было извлечено семь требований, связанных с управлением персоналом. С точки зрения структурированной аргументации, эти требования являются подцелями (SС1,,SС7). Лишь одна из подцелей (SС5) является составной, все остальные атомарные. Для того, чтобы перейти от составной подцели (SС5) к атомарным (SС5.1,,SC5.11), выполняется еще один шаг рассуждения (RS). При этом подразумевается, что согласно требованиям МЭК 61508, для проекта, связанного с созданием какого-либо абстрактного продукта, был разработан Human Resource Management Plan. Этот план интерпретирует требования стандарта в контексте проекта.


Для выполнения всех шагов подтверждения (ES) предлагается использовать общий структурированный текст с указанием связей между подцелями (SG) подтверждениями (E). Будем использовать отношение SG -> E, чтобы обозначить взаимосвязь между соответствующей подцелью (SG) и поддерживающими ее подтверждениями (E).


Все полученные отношения SG -> E могут быть трансформированы в граф Assurance Case, согласно нотации GSN, модифицированной для структурированной аргументации (Рисунок 10). Этот граф отражает всю группу требований, связанных с управлением персоналом согласно МЭК 61508. Также данный граф можно использовать в качестве шаблона для выполнения оценивания на соответствие требованиям МЭК 61508.


Рисунок 10. Граф Assurance Case, полученный на основе структурированных аргументов для группы требований по управлению персоналом (МЭК 61508)

На первый взгляд все это долго и сложно, но, тем не менее, Assurance Case имеет свое практическое применение. Именно такой подход мы использовали при сертификации ПЛК RdICS на соответствие МЭК 61508.

Заключение

Метод Assurance Case (Safety Case) применяется на протяжении более 20 лет для анализа безопасности объектов КИИ. Наибольшее распространение данный метод получил в Великобритании и ряде стран Британского содружества для таких отраслей, как здравоохранение, авиация, атомная энергетика, автомобилестроение, оборонная, нефтехимическая и железнодорожная промышленность.

К достоинствам Assurance Case следует отнести все плюсы, достигаемые визуализацией отношений в сложной предметной области, за счет улучшения нашего восприятия и понимания. Недостатки обусловлены субъективностью метода в части его зависимости от экспертности лиц, выполняющих оценивание. Наиболее известный epic fail в применении Assurance Case описан здесь. Вкратце: 2 сентября 2006 г. в Афганистане произошел пожар на борту самолета Nimrod Британских ВВС. Проблема возникла из-за утечки топлива. Погибли все 14 человек, находившиеся на борту. Выпущенный ранее отчет Safety Case подтверждал безопасность воздушного судна. Расследование показало, что на серийных самолетах была не вполне корректно выполнена модификация топливной системы, и подобные проблемы возникали раньше, но почему-то никто не обратил на них внимания, как на системную ошибку. В выпущенном 600-страничном отчете это происшествие было названо не иначе, как a failure of leadership, culture and priorities.

К слову, графические нотации в отчете для Nimrod не использовались. Одним из последствий этой катастрофы стало углубление исследований именно в области построения аргументации. Впрочем, удовлетворяющий всех общий подход так и не был выработан.

На сегодняшний день основным драйвером внедрения Assurance Case являются нормативные и законодательные требования, а вовсе не удобство, целесообразность или экономическая эффективность. Очевидно, что в области Assurance Case открываются большие возможности для искусственного интеллекта, но что-то мне не встречались публикации на данную тему.
Тем не менее, проблема, связанная с оцениванием безопасности сложных систем, остается открытой. Возможно, что определенный прогресс в этой области может быть достигнут при активном внедрении Assurance Case, ведь этот метод опирается на все те важные моменты, которые занимали человечество с самого начала философских исследований.

Крис Хоббс (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. 9599, 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.