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