Программное обеспечение для авионики

Программное обеспечение для авионики — это встроенное программное обеспечение , в котором предусмотрены юридически предусмотренные требования безопасности и надежности , используемые в авионике . Основное различие между авиационным программным обеспечением и обычным встроенным программным обеспечением заключается в том, что процесс разработки требуется по закону и оптимизирован с точки зрения безопасности. Утверждается, что описанный ниже процесс лишь немного медленнее и дороже (возможно, на 15 процентов), чем обычные специальные процессы, используемые для коммерческого программного обеспечения . Поскольку большая часть программного обеспечения выходит из строя из-за ошибок, устранение ошибок на самом раннем этапе также является относительно недорогим и надежным способом создания программного обеспечения. Однако в некоторых проектах ошибки в спецификациях могут быть не обнаружены до момента развертывания. В этот момент их исправление может оказаться очень дорогим.

Основная идея любой модели разработки программного обеспечения заключается в том, что каждый этап процесса проектирования имеет результаты, называемые «результатами». ^[1] Если результаты проверяются на правильность и исправляются, то обычные человеческие ошибки не могут легко перерасти в опасные или дорогостоящие проблемы. Большинство производителей ^[2] следуйте водопадной модели для координации дизайнерского продукта, ^[3] но почти все они прямо разрешают пересматривать более ранние работы. Результат чаще всего ближе к спиральной модели .

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

Общий обзор [ править ]

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

Большинство современных коммерческих самолетов с автопилотами используют бортовые компьютеры и так называемые системы управления полетом (FMS), которые могут управлять самолетом без активного вмешательства пилота на определенных этапах полета. Также разрабатываются или производятся беспилотные летательные аппараты: ракеты и дроны, которые могут взлетать, летать и приземляться без вмешательства пилотов с воздуха.

Во многих из этих систем сбой недопустим. Надежность программного обеспечения, работающего на летательных аппаратах (гражданских или военных), подтверждается тем фактом, что большинство авиационных происшествий происходит из-за ошибок, допущенных вручную. К сожалению, надежное программное обеспечение не обязательно простое в использовании или интуитивно понятное, плохой дизайн пользовательского интерфейса стал одной из причин многих авиационных происшествий и смертей. ^{[ нужна ссылка ]}

Нормативные вопросы [ править ]

Из-за требований безопасности большинство стран регулируют авионику или, по крайней мере, принимают стандарты, используемые группой союзников или таможенным союзом. Тремя регулирующими организациями, которые больше всего влияют на развитие международной авиации, являются США, ЕС и Россия.

В США авионика и другие компоненты самолетов имеют стандарты безопасности и надежности, предусмотренные Федеральными авиационными правилами, частью 25 для транспортных самолетов, частью 23 для малых самолетов и частями 27 и 29 для винтокрылых самолетов. Эти стандарты обеспечиваются «назначенными техническими представителями» ФАУ , которым обычно платит производитель и которые сертифицируются ФАУ.

В Европейском Союзе МЭК описывает « рекомендуемые» требования к критически важным для безопасности системам, которые обычно принимаются правительствами без изменений. Безопасная и надежная часть авионики имеет знак CE. Нормативно-правовая база очень похожа на систему пожарной безопасности в США и Канаде. Правительство сертифицирует испытательные лаборатории, а лаборатории сертифицируют как производимую продукцию, так и организации. По сути, надзор за разработкой передается от правительства и производителя испытательной лаборатории.

Для обеспечения безопасности и надежности национальные регулирующие органы (например, FAA , CAA или DOD ) требуют стандартов разработки программного обеспечения. Некоторые репрезентативные стандарты включают MIL-STD-2167 для военных систем или RTCA DO-178B и его преемник DO-178C для гражданских самолетов.

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

Процесс разработки [ править ]

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

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

Отклонения от конкретного проекта от описанных здесь процессов могут возникнуть из-за использования альтернативных методов или требований низкого уровня безопасности.

Почти все стандарты разработки программного обеспечения описывают, как выполнять и улучшать спецификации, проекты, кодирование и тестирование (см. Модель разработки программного обеспечения ). Однако стандарты разработки программного обеспечения для авионики добавляют некоторые шаги к разработке для обеспечения безопасности и сертификации:

Человеческие интерфейсы [ править ]

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

Анализ опасностей

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

Проекты, связанные с военной криптографической безопасностью, обычно включают анализ безопасности с использованием методов, очень похожих на анализ опасностей.

Руководство по техническому обслуживанию [ править ]

Как только техническая спецификация будет завершена, можно приступать к написанию руководства по техническому обслуживанию. Руководство по техническому обслуживанию необходимо для ремонта, и, конечно, если систему невозможно починить, она не будет безопасной.

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

Одним из наиболее странных требований к документации является то, что большинство коммерческих контрактов требуют гарантии того, что системная документация будет доступна в течение неопределенного времени. Обычным коммерческим методом предоставления такой гарантии является создание и финансирование небольшого фонда или траста. Затем траст сохраняет почтовый ящик и хранит копии (обычно на ультрафишах ) в безопасном месте, например, в арендованном месте в университетской библиотеке (управляемом как специальная коллекция) или (сейчас реже) закопанном в пещере или пустыне. ^[4]

Проектная и техническая документация [ править ]

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

Создание и проверка кода [ править ]

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

Код также часто проверяется специальными программами, анализирующими корректность ( Статический анализ кода ), такими как SPARK-эксперт для SPARK (подмножество языка программирования Ada) или lint для C-семейства языков программирования (правда, в первую очередь C). .Компиляторы или специальные программы проверки , такие как «lint», проверяют, совместимы ли типы данных с операциями над ними, а также такие инструменты регулярно используются для обеспечения строгого использования допустимых подмножеств языков программирования и стилей программирования.Другой набор программ измеряет метрики программного обеспечения , чтобы найти части кода, в которых могут быть ошибки.Все проблемы устранены или по крайней мере поняты и перепроверены.

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

Модульное тестирование [ править ]

Код «модульного теста» пишется так, чтобы каждая инструкция кода выполнялась хотя бы один раз, чтобы получить 100% покрытие кода . Инструмент «покрытия» часто используется для проверки выполнения каждой инструкции, а затем также документируется тестовое покрытие по юридическим причинам.

Этот тест является одним из самых мощных. Он требует детального анализа логики программы и обнаруживает большинство ошибок кодирования, компиляции и некоторые ошибки проектирования. Некоторые организации пишут модульные тесты перед написанием кода, используя дизайн программного обеспечения в качестве спецификации модуля. Код модульного теста выполнен, и все проблемы устранены.

Интеграционное тестирование [ править ]

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

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

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

ящик и приемочное тестирование Черный

Тем временем инженеры по тестированию обычно начинают собирать испытательную установку и выпускать предварительные тесты для использования инженерами-программистами. В какой-то момент тесты охватывают все функции технической спецификации. С этого момента начинаются испытания всей авионики. Цель приемочных испытаний – доказать безопасность и надежность установки в эксплуатации.

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

Сертификация [ править ]

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

См. также [ править ]

Ссылки [ править ]

^ «Программные модели» . www.cs.uct.ac.za. Проверено 28 января 2024 г.
^ «Что такое модель водопада? – Определение и руководство» . Качество программного обеспечения . Проверено 1 декабря 2023 г.
^ «Программные модели» . www.cs.uct.ac.za. Проверено 28 января 2024 г.
^ Личная информация, Роберт Яблонски, технический руководитель, BE Aerospace, Ирвин, Калифорния, 1993 г.

Внешние ссылки [ править ]

Общая спецификация программного обеспечения авионики от Института программной инженерии (SEI)

[1] «Программные модели» . www.cs.uct.ac.za. Проверено 28 января 2024 г.

[2] «Что такое модель водопада? – Определение и руководство» . Качество программного обеспечения . Проверено 1 декабря 2023 г.

[3] «Программные модели» . www.cs.uct.ac.za. Проверено 28 января 2024 г.

[4] Личная информация, Роберт Яблонски, технический руководитель, BE Aerospace, Ирвин, Калифорния, 1993 г.

[1]

[2]

[3]

[4]