ТЕХНОЛОГИИ: Все, что вы хотели спросить о сертификации бортового программного обеспечения, но боялись узнать

Автор: Титов,Анатолий

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

ОБ АВТОРЕ

Анатолий Титов - профессиональный разработчик ПО, семнадцать лет работающий в аэрокосмической индустрии. Участвовал во многих проектах, в том числе был ведущим разработчиком технологии TCL/MC3 - кроссплатформного стандарта векторных электронных карт, сертифицированного для использования в бортовых летно-информационных системах. Также принимал участие в работе над REDSHIFT 3 и 4.

Авиаиженеры постоянно занимаются проблемами обеспечения безопасности, поэтому свой опыт они успешно переносят и на ПО. Компании, производящие авиационное ПО, имеют богатую историю проектирования больших критических систем, и репутация их программных продуктов очень высока. Примером использования ПО в авиации можно назвать устанавливаемые практически на все современные самолеты электронные летно-информационные системы (Electronic Flight Information System, EFIS). На дисплеях этих систем ПО отображает информацию (крен, курс, тангаж, скорость, высоту, скольжение и пр.), которую раньше предоставляли механические приборы, а также многое другое, включая полетные и погодные карты. О требованиях, предъявляемых к ПО в авиации, и рассказывает эта статья.

Какой же подход у авиационной индустрии к надежности ПО? Надежность любой программы должна быть доказана, иначе она не может считаться ни надежной, ни безопасной. Поскольку доказать правильность выполнения программы на практике в общем случае невозможно, авиаторы ограничиваются сертификацией согласно установленному стандарту. Без этого ни один прибор, ни одна система не могут быть смонтированы на летательном аппарате. В США сертификаты выдает FAA (Federal Aviation Administration), в Канаде - Transport Canada, в Европе - JAA (Joint Aviation Authorities). Все эти организации главным стандартом для сертификации бортового авиационного ПО полагают RTCA DO-178B (или его европейский аналог EUROCAE ED-12B). Этот стандарт начал разрабатываться в начале 80-х годов, первая редакция появилась в 1982 году, актуальная версия была выпущена десять лет спустя. Специальный стандарт для сертификации бортового ПО понадобился потому, что подход к сертификации ПО существенно отличается от подхода к сертификации любого агрегата самолета, поскольку методы проверки надежности оборудования неприменимы для ПО. Например, мы можем, взяв на тестирование крыло самолета, приложить к нему нагрузку. На тысячный раз под воздействием нагрузки крыло сломается, и мы сумеем определить параметры безопасности нагрузки и интенсивности ее применения, при которых крыло остается недеформированным. С программами такое не проходит. Поэтому для сертификации ПО предлагается другой подход: необходимо определить жизненный цикл ПО, входящие в него процессы, установить их цели, виды деятельности, условия переходов между ними, доказать сертификационной власти, что все они соответствуют стандарту и что авиаторы следуют им на всем протяжении жизненного цикла ПО. Стандарт DO-178B и содержит всю эту информацию.

С чего начинается сертификация? Сертификация начинается с классификации рассматриваемого ПО с точки зрения безопасности. Классификация напрямую связана с тяжестью состояния отказа, которое ПО может вызывать. Состояние отказа определяется как воздействие на летательный аппарат (ЛА) или на лиц, находящихся на его борту, привносящее существенный вред в операционные условия и окружение ЛА. Установлены следующие категории состояний отказа:

• A. Катастрофическое - состояние, не совместимое с безопасным полетом и посадкой.

• B. Опасное - состояние, при котором функциональные способности ЛА или способности экипажа справляться с неблагоприятными условиями управления достигают нижних пределов безопасности. Экипаж не может выполнять свои задачи аккуратно и полностью.

• C. Существенное - состояние, при котором функциональные способности ЛА или способности экипажа справляться с неблагоприятными условиями управления снижены до существенных пределов. Имеет место существенное увеличение нагрузки на экипаж или ухудшение эффективности работы экипажа.

• D. Несущественное - состояние, не приводящее к значительным потерям безопасности управления ЛА.

• E. Не влияющее - состояние, никак не влияющие на способности управления ЛА.

Исходя из этой классификации и сертифицируются программные продукты (очевидно, что для программ, сбой которых приводит только к состоянию Е, сертификация не требуется, а программы, способные привести к катастрофе, проверяются гораздо тщательнее остальных). Чем выше уровень ПО (от D до A), тем более жесткие требования предъявляются к нему, к детальности и объему необходимой документации, и, как следствие, требуется больше ресурсов для процесса сертификации. Определение уровня сертификации выясняется во время консультаций с сертификационной властью, которая руководствуется двумя базовыми принципами:

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

• Если аномальное поведение ПО может приводить к различным категориям состояния отказа, то уровень ПО выбирается в соответствии с самым серьезным состоянием отказа.

Что понимается под жизненным циклом? Ключевым понятием DO-178B является понятие жизненного цикла программы. Стандарт определяет жизненный цикл ПО как период времени, который начинается с решения о производстве или модификации программного продукта и заканчивается тогда, когда продукт перестает поддерживаться (причем под продуктом здесь понимается не только сама программа, но и связанные с нею документация и данные). Жизненный цикл состоит из набора процессов, являющихся необходимыми и достаточными для производства и поддержки программного продукта. DO-178B жестко не устанавливает каких либо моделей жизненного цикла, поэтому любые модели, будь то каскадные, итерационные или какие-либо другие, могут быть использованы, но он требует, чтобы они были описаны или чтобы были указаны источники их описаний, а также показано, что жизненный цикл следует этим моделям. Все, что производится в течение жизненного цикла для планирования, управления, объяснения, определения, контроля, доказательства проведения определенных действий, - относится к артефактам ЖЦ ПО, и без этих артефактов сертификация невозможна.

Для всех процессов жизненного цикла стандарт определяет их цели в соответствии с уровнями ПО. Процесс содержит в себе один или несколько видов деятельности, каждое из которых представляет собой набор действий для решения конкретной задачи или группы тесно связанных задач. Конкретный проект может определять один или несколько жизненных циклов и выбирать виды деятельности для каждого процесса, их последовательность и решаемые задачи. DO-178B не задает жесткой структуры жизненного цикла, но рекомендует включать в него процесс планирования, процесс разработки, а также четыре процесса, которые относятся к интегральным: процесс обеспечения качества, процесс управления конфигурацией, процесс верификации, процесс сертификационного взаимодействия (интегральные процессы остаются актуальными в течение всего жизненного цикла, причем особый интерес представляет не относящийся напрямую к программированию процесс сертификационного взаимодействия: в нем поддерживается связь между компанией-разработчиком и организацией, ведающей выдачей сертификатов).

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

Для перехода от одного процесса к другому или повторения процесса должны быть определены критерии перехода, которые являются минимально достаточными условиями перехода к процессу. Только когда все эти условия будут удовлетворены, возможна инициализация нового процесса. Некоторые критерии перехода между процессами зависят от уровня, на которое претендует ПО.

В чем особенности процесса разработки ПО стандарта DO-178B? Разработка ПО состоит, в свою очередь, из четырех процессов: процесса создания требований, процесса дизайна, процесса кодирования и процесса интеграции. Целью процесса создания требований является разработка высокоуровневых требований, которые непосредственно исходят из требований системы и включают функциональные и операционные требования к ПО, критерии производительности, точности, правильности, безопасности, а также интерфейсы, протоколы и другое. Базируясь на высокоуровневых требованиях, процесс дизайна вырабатывает низкоуровневые требования и архитектуру ПО. Низкоуровневые требования - это требования, из которых исходный код может быть создан напрямую, без дополнительной информации. Результатом работы процесса дизайна являются описания: алгоритмов, структур данных, компонентов ПО, низкоуровневых интерфейсов, механизмов управления ресурсами и др. На основе этой информации в процессе кодирования разрабатывается исходный код, из которого в процессе интеграции создается выполняемый объектный код. Последовательность процессов, входящих в процесс разработки, не является строгой, поскольку не все процессы могут быть задействованы. Например, при сертификации уже разработанного ПО могут быть использованы только процессы создания требований и интеграции. Если необходимо добавить к уже разработанному ПО дополнительную функцию, которая не нарушает общей структуры и может быть закодирована непосредственно из требований, тогда последовательность процессов будет выглядеть как создание требований, кодирование, интеграция. Если используются методы разработки прототипов, тогда процессы создания требований, кодирования и интеграции могут повторяться многократно, до тех пор, пока не определится наилучший прототип, после чего будут иметь место процесс дизайна и финальные процессы кодирования и интеграции.

Есть ли ограничения по выбору языка программирования? Стандарт не дает каких бы то ни было рекомендаций по выбору языка программирования, но выбор высокоуровневого языка предпочтителен. Высокоуровневые языки считаются более надежными, поскольку код у них прозрачнее, в нем легче прослеживается связь с требованиями дизайна, он детерминирован, устойчив, и на нем можно реализовывать синтаксически сложные конструкции. До недавнего времени для бортового ПО использовался только язык Ada, сейчас более популярны С и С++. Существует бортовое ПО, написанное на языке Java.

Достаточно ли одного тести-рования для выявления всех ошибок, которые могут быть допущены в течение всего жизненного цикла? DO-178B утверждает, что этого недостаточно. Согласно стандарту, за нахождение ошибок и информирование о них отвечает процесс верификации ПО. Этот процесс кроме тестирования должен использовать такие методы верификации, как ревизия и анализ. Под ревизией понимается инспекция выходной информации исследуемого процесса в соответствии с контрольным перечнем. Анализ детально экзаменует функциональность, производительность, источники требований, полноту тестирования, безопасность компонента ПО, а также его взаимоотношения с другими компонентами бортового ПО. Анализ может выявить противоречия и несоответствия в спецификации, требованиях, дизайне и коде. Одним из инструментов анализа могут быть так называемые формальные методы, под которыми понимаются описательные нотации или аналитические методы, используемые для конструирования, разработки и оценки математических моделей поведения системы. Всего стандарт выделяет шесть типов ревизий и анализов: высокоуровневых требований, низкоуровневых требований, архитектуры, исходного кода, результатов интегральных процессов и тестирующих примеров. За тестирование в процессе верификации ПО отвечает процесс тестирования ПО, состоящий из тестов на соответствие установленным требованиям и анализа тестового покрытия, который, в свою очередь, состоит из анализа покрытия тестов и анализа структурного покрытия. Первый проверяет, что у каждого требования есть свой тестирующий пример; целью второго анализа является выявление структур кода, не охваченного тестирующими примерами. Если при анализе структурного покрытия будет выявлен не протестированный код, то решений может быть два: создание тестов, покрывающих этот код, или удаление кода как "мертвого". Конечно, в некоторых языках программирования есть конструкции, которые довольно трудно проверить. Эти особенности языка должны быть описаны в документации. Кроме нормальных тестов, использующих правильные входные данные, стандарт требует проводить тесты на устойчивость. Эти тесты включают установку неправильных начальных значений для переменных, инициализацию данных в ненормальных условиях, сбойную модель входной информации, нарушение временной синхронизации и др.

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

Сертификация - это дорого? Да. Сертификация ПО согласно стандарту DO-178B - довольно дорогая процедура. Она приводит к увеличению стоимости разработки ПО на 50–200% и напрямую зависит от уровня ПО, на который нацелена сертификация. Стоимость сертифицированного ПО при покупке, для установки на своем оборудовании или использование его как части своего ПО может отличаться в разы от стоимости несертифицированного ПО. Любое, даже самое незначительное изменение ПО, приводит к потере сертификационного доверия к нему сертификационной властью, и это ПО должно быть повторно сертифицировано. Поэтому любое изменение такого ПО обходится очень дорого.

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

• Высокая надежность и безопасность.

• Высокое качество, поддающееся проверке.

• Непротиворечивость.

• Возможность повторного использования.

• Низкая стоимость технического обслуживания.

• Быстрая интеграция с аппаратными средствами.

• Переносимость на другие платформы.

Предполагаются ли изменения в стандарте? Несмотря на всю эволюцию ПО, DO-178В остается основным стандартом сертификации ПО для бортовых систем. Происходит это потому, что DO-178В не содержит требований, касающихся структуры организации ПО, его операционных способностей и возможностей; в нем также отсутствуют ссылки на какие-либо конкретные национальные или международные стандарты. Этот стандарт используется не только в авиации. Например, он успешно применяется в медицине. Существуют планы его использования в атомной промышленности и робототехнике. Начиная с 2005 года ведется разработка нового стандарта сертификации бортового оборудования под названием DO-178С, который предполагается опубликовать в 2008 году. Главное отличие нового стандарта от текущего в том, что в нем будет сделан акцент на объектно-ориентированные технологии, на более широкое использование формальных методов верификации ПО, на моделирование бортовых систем с помощью ПО, будет большая согласованность между процессами жизненного цикла ПО, а также улучшится кооперация DO-178 с другими документами RTCA. Есть большая вероятность, что новая версия стандарта станет основным документом для любых критических систем, где используются программные продукты и где безопасность людей является доминирующим критерием.

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

Перед вами, пожалуй, самый многострадальный текст этого года, переживший жесточайшую авторскую и редакторскую правку. Началось все со статьи Анатолия Титова с поэтичным названием "Сертификация программного обеспечения в авиации. Вопросы по сертификации бортового программного обеспечения согласно стандарту RTCA DO-178B". Из текста было понятно, что автор прекрасно разбирается в предмете, но, по грубым прикидкам, в оригинальном виде эта статья заняла бы полос двадцать, не меньше. Причем большая часть полос состояла бы из пассажей вида "эти требования, в зависимости от их строгости, классифицируются на две категории: контрольную категорию 1 (КК1) и контрольную категорию 2 (КК2), причем КК2 представляет собой подмножество КК1". У нас не было никаких сомнений, что дочитавший статью до конца поймет, наконец, как и зачем сертифицируется программное обеспечение для самолетов, однако в том, что таких счастливчиков окажется относительно немного, сомнений тоже не возникало - тема довольно сложная, и особых скидок на читателей еженедельных журналов автор не делал. По нашей просьбе текст был значительно сокращен (более чем в четыре раза!) и упрощен; кроме того, автор изменил внутреннюю структуру текста - по большому счету, это был даже не правленный, а заново написанный материал на ту же тему. Но даже в таком виде он казался слишком сложным для периодического издания. Мы попытались смягчить самые формально описанные фрагменты, пока наконец не поняли, что чрезмерное упрощение статьи только умаляет сложность задачи, которая стоит перед программистами, работающими на авиаиндустрию. Другими словами, НОСР (не очень сообразительный редактор) вовремя перестал выкидывать из АТ (авторского текста) НК (непонятные куски) и МА (многочисленные аббревиатуры). К слову, во время жизненного цикла статьи автор проявлял поистине ангельское терпение, потому что НОСР отвечал на АП (авторские письма) нерегулярно, чем заметно усложнил процесс сертификации текста. ВГ