Введение
Встроенное программное обеспечение с юридически обязательными требованиями к безопасности и надежности.
Программное обеспечение авиационной техники – это встроенное программное обеспечение с юридически обязательными требованиями к безопасности и надежности, используемое в авиационной технике. Основное отличие программного обеспечения для авиации от обычного встроенного программного обеспечения заключается в том, что процесс его разработки регламентирован законом и оптимизирован для обеспечения безопасности. Утверждается, что описанный ниже процесс лишь незначительно медленнее и дороже (возможно, на 15 процентов), чем обычные, неформальные процессы, используемые для коммерческого программного обеспечения. Поскольку большинство программных сбоев происходит из-за ошибок, их устранение на самом раннем этапе является относительно недорогим и надежным способом создания программного обеспечения. Однако в некоторых проектах ошибки в спецификациях могут быть обнаружены только после развертывания. В этом случае их исправление может оказаться очень дорогостоящим. Основная идея любой модели разработки программного обеспечения заключается в том, что каждый этап процесса проектирования имеет результаты, называемые "поставляемыми продуктами" (deliverables). Если эти продукты тестируются на корректность и исправляются, то обычные человеческие ошибки не смогут легко перерасти в опасные или дорогостоящие проблемы. Большинство производителей используют каскадную модель (waterfall model) для координации разработки, но почти все допускают пересмотр ранее выполненной работы. В результате чаще всего получается модель, близкая к спиральной. Обзор встроенного программного обеспечения можно найти в статьях "Встроенные системы" и "Модели разработки программного обеспечения". В остальной части статьи предполагается знакомство с этой информацией и рассматриваются различия между коммерческими встроенными системами и коммерческими моделями разработки.
Общий обзор
Поскольку большинство производителей авионики рассматривают программное обеспечение как способ добавления ценности без увеличения веса, важность встроенного программного обеспечения в авионических системах постоянно растет. Большинство современных коммерческих самолетов с автопилотами используют бортовые компьютеры и так называемые системы управления полетом (FMS), способные выполнять полет без активного вмешательства пилота на определенных этапах. Также разрабатываются или производятся беспилотные летательные аппараты: ракеты и дроны, которые могут взлетать, совершать крейсерский полет и приземляться без участия пилота на борту. В многих из этих систем отказ недопустим. Надежность программного обеспечения, работающего в летательных аппаратах (гражданских или военных), подтверждается тем, что большинство авиационных происшествий происходит из-за человеческого фактора. К сожалению, надежное программное обеспечение не всегда просто в использовании или интуитивно понятно, а недостатки в дизайне пользовательского интерфейса стали причиной многих авиационных катастроф и гибели людей.
Регулирующие вопросы
Из-за требований безопасности большинство стран регулируют авионику или, по крайней мере, принимают стандарты, используемые группой союзников или таможенным союзом. Три регулирующих организации, которые больше всего влияют на развитие международной авиации, – это США, Европейский Союз и Россия. В США авионика и другие компоненты самолетов имеют стандарты безопасности и надежности, установленные Федеральными авиационными правилами, Частью 25 для транспортных самолетов, Частью 23 для небольших самолетов и Частями 27 и 29 для роторных самолетов. Эти стандарты обеспечиваются «уполномоченными инженерами» FAA, которые обычно оплачиваются производителем и сертифицированы FAA. В Европейском союзе IEC описывает «рекомендуемые» требования к системам, критичным для безопасности, которые обычно принимаются правительствами без изменений. Безопасная и надежная авионика имеет маркировку «CE». Регулирование в значительной степени напоминает систему пожарной безопасности в США и Канаде. Правительство сертифицирует испытательные лаборатории, а лаборатории сертифицируют как готовую продукцию, так и организации. По сути, контроль за разработкой передается от правительства и производителя в испытательную лабораторию. Для обеспечения безопасности и надежности национальные регулирующие органы (например, FAA, CAA или DOD) требуют стандартов разработки программного обеспечения. Некоторые типичные стандарты включают MIL STD 2167 для военных систем или RTCA DO 178B и его преемника DO 178C для гражданской авиации. Нормативные требования к этому программному обеспечению могут быть дорогостоящими по сравнению с другими программными продуктами, но они обычно являются минимальными, необходимыми для обеспечения требуемого уровня безопасности.
Процесс разработки
Основное различие между программным обеспечением для авионики и другими встраиваемыми системами заключается в том, что действующие стандарты зачастую гораздо более детализированы и строги, чем коммерческие, и обычно описываются документами, насчитывающими сотни страниц. Как правило, оно работает на операционной системе реального времени. Поскольку этот процесс предписан законом, большинство этапов разработки сопровождаются документацией или программным обеспечением, обеспечивающим прослеживаемость требований – от пронумерованных пунктов в спецификациях и проектах до конкретных фрагментов кода, для каждого из которых предусмотрены точные тесты, и отметка в итоговом списке сертификации. Это делается специально для подтверждения соответствия юридически обязательным стандартам. Отклонения от описанных здесь процессов в конкретном проекте могут возникать из-за использования альтернативных методик или невысоких требований к уровню безопасности. Почти все стандарты разработки программного обеспечения описывают, как выполнять и совершенствовать спецификации, проектирование, кодирование и тестирование (см. модель разработки программного обеспечения). Однако стандарты разработки программного обеспечения для авионики добавляют к процессу разработки дополнительные этапы, необходимые для обеспечения безопасности и сертификации.
Человеческие интерфейсы
Проекты со значительным взаимодействием с пользователем обычно проходят прототипирование или моделирование. Видеозапись обычно сохраняется, но прототип утилизируется сразу после тестирования, так как в противном случае высшее руководство и заказчики могут решить, что система готова. Главная задача – выявить проблемы взаимодействия с пользователем, которые могут повлиять на безопасность и удобство работы.
Анализ рисков
Авионика, критически важная для безопасности, обычно подвергается анализу опасностей. Уже на ранних стадиях проекта формируется хотя бы общее представление об основных его компонентах. Инженер затем рассматривает каждый блок структурной схемы и анализирует возможные сбои в этом блоке, а также их влияние на систему в целом. После этого оценивается серьезность и вероятность возникновения каждой опасности. Выявленные проблемы формулируются как требования, которые включаются в техническое задание на проектирование. Проекты, связанные с военной криптографической защитой, обычно включают анализ безопасности, использующий методы, аналогичные анализу опасностей.
Руководство по техническому обслуживанию
Как только техническое задание будет завершено, можно приступать к написанию руководства по техническому обслуживанию. Руководство по техническому обслуживанию необходимо для проведения ремонта, и, конечно, если систему не удастся отремонтировать, она будет небезопасна. Большинство стандартов имеет несколько уровней. Устройство с низкой степенью влияния на безопасность, такое как система развлечений в полете (бортовой телевизор), может обойтись схемой и процедурами установки и настройки. Система навигации, автопилот или двигатель могут содержать тысячи страниц процедур, проверок и инструкций по регулировке. Документация сейчас (2003 год) обычно поставляется на CD-ROM в стандартных форматах, включающих текст и изображения. Одно из необычных требований к документации заключается в том, что большинство коммерческих контрактов требуют гарантии, что документация по системе будет доступна неограниченно долго. Стандартный коммерческий способ предоставления такой гарантии – создание и финансирование небольшого фонда или траста. Этот траст затем поддерживает почтовый ящик и хранит копии (обычно на ультрафише) в безопасном месте, например, в арендованном помещении в университетской библиотеке (управляемом как специальная коллекция), или (реже в настоящее время) захороненных в пещере или в пустынной местности.
Документы по проектированию и спецификации
Они обычно во многом схожи с теми, что используются в других моделях разработки программного обеспечения. Существенное отличие состоит в том, что требования обычно прослеживаются, как описано выше. В крупных проектах прослеживаемость требований – это настолько масштабная и дорогостоящая задача, что для её управления требуются крупные и дорогостоящие компьютерные программы.
Составление и пересмотр кода
Код написан, а затем обычно проверяется программистом (или группой программистов, как правило, независимо), не являвшимся его автором (это еще одно нормативное требование). Специализированные организации также обычно проводят анализ кода, используя контрольный список возможных ошибок. При обнаружении нового типа ошибки он добавляется в этот список и устраняется во всем коде. Код часто также анализируется специальными программами, проверяющими корректность (статический анализ кода), например, SPARK examiner для SPARK (подмножества языка программирования Ada) или lint для семейства языков C (преимущественно C). Компиляторы или специальные инструменты проверки, такие как "lint", проверяют совместимость типов данных с выполняемыми над ними операциями, а также регулярно используются для обеспечения строгого соблюдения допустимых подмножеств языка программирования и стилей кодирования. Другой набор программ измеряет метрики программного обеспечения для выявления участков кода, в которых наиболее вероятно наличие ошибок. Все обнаруженные проблемы устраняются или, по крайней мере, понимаются и подвергаются повторной проверке. Для некоторых типов кода, таких как цифровые фильтры, графические пользовательские интерфейсы и инерциальные навигационные системы, разработаны специальные инструменты, позволяющие автоматически генерировать программное обеспечение, поскольку они хорошо изучены. В этих случаях разрабатываются спецификации и на их основе автоматически создается надежное программное обеспечение.
Опыты на единицу
Код модульных тестов пишется для выполнения каждой инструкции кода как минимум один раз, чтобы достичь 100% покрытия кода. Инструмент измерения покрытия часто используется для проверки выполнения каждой инструкции, а затем покрытие тестами документируется, в том числе по юридическим причинам. Этот вид тестирования – один из самых эффективных. Он требует тщательного анализа логики программы и позволяет выявить большинство ошибок кодирования, компиляции и некоторые ошибки проектирования. Некоторые организации пишут модульные тесты до написания кода, используя проект программного обеспечения в качестве спецификации модуля. Код модульных тестов выполняется, и все обнаруженные проблемы исправляются.
Интеграционное тестирование
По мере поступления фрагментов кода они добавляются к базовому каркасу программы и тестируются непосредственно в системе для проверки работоспособности каждого интерфейса. Как правило, сначала завершают встроенные тесты электроники, чтобы затем приступить к испытаниям на надежность и радиоизлучение. После этого интегрируются наиболее важные функции программного обеспечения. Интеграторам очень удобно иметь возможность запускать небольшие, выбранные фрагменты кода, например, через простую систему меню. Некоторые руководители проектов стремятся организовать процесс интеграции таким образом, чтобы после достижения минимально необходимого функционала система могла быть поставлена в любой последующий момент времени, с постепенным добавлением новых функций.
Черная коробка и испытания на прием
Тем временем, инженеры по тестированию обычно приступают к сборке испытательного стенда и выпуску предварительных тестов для использования разработчиками программного обеспечения. В какой-то момент тесты охватывают все функции, указанные в техническом задании. На этом этапе начинается тестирование всего авионического блока. Целью приемочных испытаний является подтверждение безопасности и надежности работы блока. Первым и одним из самых сложных испытаний программного обеспечения в условиях сжатых сроков является реалистичное тестирование радиоизлучений блока. Обычно его необходимо начинать на ранних стадиях проекта, чтобы обеспечить достаточно времени для внесения необходимых изменений в конструкцию электроники. Программное обеспечение также подвергается анализу структурного покрытия, в ходе которого проводятся тесты, собираются данные об охвате кода и проводится их анализ.
Сертификация
Каждый этап работы приводит к созданию результата, будь то документ, код или отчет об испытаниях. Когда программное обеспечение успешно проходит все тесты (или достаточное количество для безопасной продажи), все эти результаты объединяются в сертификационный отчет, который может содержать буквально тысячи страниц. Назначенный инженер, ответственный за завершение работы, затем решает, является ли результат приемлемым. Если да, он подписывает отчет, и авиационное программное обеспечение сертифицировано.