Компьютерра - Журнал Компьютерра №713

ОБ АВТОРЕ

Анатолий Титов - профессиональный разработчик ПО, семнадцать лет работающий в аэрокосмической индустрии. Участвовал во многих проектах, в том числе был ведущим разработчиком технологии 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 не задает жесткой структуры жизненного цикла, но рекомендует включать в него процесс планирования, процесс разработки, а также четыре процесса, которые относятся к интегральным: процесс обеспечения качества, процесс управления конфигурацией, процесс верификации, процесс сертификационного взаимодействия (интегральные процессы остаются актуальными в течение всего жизненного цикла, причем особый интерес представляет не относящийся напрямую к программированию процесс сертификационного взаимодействия: в нем поддерживается связь между компанией-разработчиком и организацией, ведающей выдачей сертификатов).