Бортовое программное обеспечение самолета

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

Среди международных нормативных документов, содержащих требования к ПО АТ, наиболее значимым есть документ DO-178, в первый раз сформулированный в 1978 г. На данный момент употребляются его усовершенствованные варианты: DO-I78A, действующий с 1985 г., и DO-I78B, действующий с 1993 г., в котором большое внимание отводится вопросу квалификации инструментального ПО.

В России и Украине действуют аналоги этих документов: соответственно КТ-178А с 1998 г. и КТ-178В с 2004 г. Дополнениями к этим квалификационным требованиям помогают документы РМ-178А и РМ-178В.

Среди стандартов серии ISO, действующих в Украине и относящихся к ПО, основное место занимают два: ДСТУ ISO 9000-3-98 и ДСТУ 3918-1999 (ISO/IEC 12207:1995). Первый посвящен организации и мероприятиям совокупности качества применительно к ПО, второй процессам ЖЦ ПО. Требования стандартов ISO связаны конкретно с процедурами сертификации ВС и его компонентов, включая процедуры сертификации ПО.

Также, при сертификации фирм авиационной индустрии, в этом случае производственных применения и процессов создания ПО, употребляется документ АРМАК «Управление 21.2С», в частности раздел «Элемент 3. Гарантия качества ПО», что подразделяется на две части: «Часть А. Бортовое ПО» и «Часть Б. ПО для приемки изделий».

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

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

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

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

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

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

Классификация уровней ПО по категориям критичности следующая:

ПО уровня А — ПО таковой функциональной совокупности, отказное состояние которой, появившееся из-за неточности в ПО, может привести к катастрофической обстановке для ВС, в то время, когда фактически нереально не допустить смерть ВС и людей. Возможность происхождения таковой ситуации на один час полета должна быть фактически немыслимой, т. е. меньше чем 10~9;
ПО уровня В ПО таковой функциональной совокупности, отказное состояние которой, появившееся из- за неточности в ПО, может привести к аварийной обстановке для ВС. Аварийная обстановка характеризуется большим ухудшением черт ВС либо превышением его предельных ограничений, и таким физическим напряжением летного экипажа, при котором он не имеет возможности совершенно верно и всецело выполнить собственные функции. Аварийная обстановка может привести к большим повреждениям ВС, травмам людей либо отдельным жертвам. Возможность происхождения таковой ситуации на один час полета должна быть очень маловероятной, т. е. быть в диапазоне 10 М0~9;
ПО уровня С — ПО таковой функциональной совокупности, отказное состояние которой, появившееся из- за неточности в ПО, может привести к непростой обстановке для ВС. Непростая обстановка характеризуется заметным ухудшением черт ВС, выходом одного либо больше параметров за эксплуатационные ограничения, но без успехи предельных ограничений, и уменьшением свойства экипажа справится с данной обстановкой из-за повышения рабочей нагрузки и по обстоятельству появления негативных условий, каковые снижают эффективность действий экипажа. Непростая обстановка может привести к дискомфорту пассажиров, включая, быть может, травмы. Возможность происхождения непростой обстановке на один час полета должна быть маловероятной, т. е. быть в диапазоне 10 5-10-7;
ПО уровня D — ПО таковой функциональной совокупности, отказное состояние которой, появившееся из-за неточности в ПО, может привести к усложнению условий полета для ВС. Такая обстановка характеризуется малым ухудшением черт ВС либо маленьким повышением рабочей нагрузки на экипаж. Такую обстановку возможно не допустить, к примеру, методом трансформации замысла полета, а для пассажиров она обязана приводить не более, чем к некоторым неудобствам;
ПО уровня Е — ПО таковой функциональной совокупности, отказное состояние которой, появившееся из-за неточности в ПО, не воздействует на эксплуатационные возможности ВС и не увеличивает нагрузки на экипаж. Получение от сертификационного органа подтверждения того, что данное ПО принадлежит к уровню Е, свидетельствует, что к нему не используются положения документа КТ-178В.

Документ КТ-178А определяет три категории критичности функций бортовых авиационных совокупностей:

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

Соответственно существуют три уровня ПО:

уровень 1 для категории «критическая» с самые высокими требованиями к ПО и большим количеством работ, исполнение которых нужно для доказательства соответствия сертификационным требованиям, и большим числом сопроводительной документации;
уровень 2 — для категории «значительная» с более низкими требованиями;
уровень 3 — для категории «несущественная» с минимальными требованиями.

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

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

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

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

Процессы разработки, аттестации и верификации ПО

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

Приведены процессы создания программного продукта, занимательные с позиций получения определенных обеспечений безопасности. Тут каждое мероприятие, которое связано с разработкой (Р) имеет соответствующее верификационное мероприятие (В). И те, и другие порождают соответствующие документы (Д).

Исходным материалом для инициации процессов создания ПО являются заявленные требования к совокупности, каковые должны быть оформлены в виде соответствующего документа (ДФ ), и каковые нужно преобразовать в требования к ПО (Д1), как раз в связи с тем, что реализация функций цифровых электронных совокупностей, как уже отмечалось, осуществляется программно. Процесс разработки требований к ПО (Р1) — это и имеется процесс изменения требований к совокупности в требования к ПО.

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

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

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

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

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

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

В следствии должны быть оформлены пять документов (допускается обоснованное совмещение): замысел сертификации ПО (ДЗ), замысел разработки ПО, замысел верификации, и замыслы управления конфигурацией ПО (Д6) и гарантии его качества. Верификационные мероприятия (В2, ВЗ) относятся, по большей части, к процедурам согласования замыслов на этапе утверждения, и к их коррекции по замечаниям, появившимся на более поздних этапах создания а также эксплуатации ПО. Содержание документов рассматривается дальше.

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

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

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

В верификационном документе Д13 должна быть представлена таблица соответствия проекта ПО требованиям к ПО в виде перекрестного анализа. Отступления от требований и стандартов должны быть отмечены и обоснованы.

Все рассмотренные до сих пор этапы, лаже этап проектирования ПО, возможно охарактеризовать как подготовительные. Лишь в следствии процессов программирования (Р5), комплексирования программных компонентов (Р6) и интеграции ПО с аппаратными средствами (Р7) появляется фактически программный продукт в окончательном виде.

Первым результатом процесса, реализующим требования низкого уровня, постоянно является исходный код (Д9), что обязан трансформироваться в проект ПО. Учет архитектуры ПО в ходе проектирования реализуется в процедурах комплексирования компонентов ПО, а интеграция ПО в целевой вычислитель даст в итоге, исполняемый объектный код (ДЮ) и соответствующий каталог комплектации ПО (Д11).

Неправильные либо недостаточные входные эти, распознанные в этих процессах, направляться возвратить в прошлые процессы для внесения исправлений либо ясности. Также, среда создания ПО (она же, значительно чаще, и среда его сопровождения) должна быть четко и подробно выяснена и зафиксирована (Д12).

Само собой очевидно, на данном этапе разработки осуществляются самые объёмные, самые сложные по содержанию и самые важные верификационные мероприятия (В5, В6, В7) под неспециализированным заглавием — тестирование (опробования) ПО с целью обнаружения содержащихся в ПО неточностей. Неприятность тут в том, что распознанные неточности, в большинстве случаев, устраняются, а не распознанные не смогут быть кроме того спрогнозированы.

Содержание всех трех верификационных мероприятий.

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

Рассмотрение процессов создания ПО будет неполным, если не упомянуть о замыслах УКПО и ГКПО. каковые должны быть реализованы методом внешних и внутренних аудиторских испытаний состояния конфигурации, и соответствующих организационных и технологических процедур, и отражены в протоколах Д14 и Д15.

Реализация замысла сертификации ПО фиксируется документом Д16.

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

Документация для сертификации ПО. В Соединенных Штатах с 1987 г. официально существует методика университета SEI (Software Engineering Institute), разрешающая выяснить уровень технологической зрелости фирм, разрабатывающих ПО и совершенствовать процессы разработки. Первоначально это Capability Maturity

Model (СММ), а позднее — Capability Maturity Model Integration (CMMI). В соответствии с моделью верховный («оптимизирующий») уровень технологической зрелости — пятый — отвечает полностью автоматизированному процессу производства ПО на базе математической модели с применением способов параметрической и структурной оптимизации, и организация сосредотачивается на совершенствовании процессов. Одним из показателей низшего первого («начального») уровня есть зависимость организации от отдельных программистов, а одним из условий перехода со второго («повторяемого») уровня на третий («определенный») — документирование процессов под управлением соответствующей работы во главе с важным лицом из состава высшего управления организации.

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

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

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

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

Д1 «Требования к ПО» — содержит описание изменения требований к совокупности в требования к ПО с выделением требований большого и низкого уровней и с особенным вниманием к вопросам безопасности и вероятным отказным состояниям. Должны быть выяснены критерии исполнения функций и вероятные ограничения, к примеру: по памяти, по времени, по частоте, по сотрудничеству. Особенное внимание отводится обособлению компонентов ПО.
Д2 — «Стандарты создания ПО» — множественный список. Как минимум — это список официально действующих стандартов разработки требований, проектирования, кодирования, опробований ПО. Совместно со стандартами — это пара документов.
Их содержание — способы создания, правила структурирования, ограничения на проект (к примеру, исключение рекурсии, динамических объектов, других обозначений данных), ограничения по сложности (к примеру, вложенность вызовов, применение переходов), по компиляторам и языку, инструментам и среде.
ДЗ — «Замысел сертификации ПО» подается на утверждение в национальный сертификационный орган, определяет порядок действий, способы доказательства соответствия продукта требованиям к нему, к совокупности, к ВС и нужную для этого документацию.
Д4 «Замысел разработки ПО» — определяет ЖЦ создания ПО, сотрудничество исполнителей и среду разработки.
Д5 — «Замысел верификации ПО» — определяет этапы (позиции процесса разработки и критерии перехода к процедурам верификации), способы, процедуры, инструменты и среду верификации, включая инструментальные программные средства, инструкции относительно достижения нужных показателей качества (безопасности) и указания довольно испытаний и повторных проверок по окончании внесения трансформаций в ПО, каковые гарантируют устранение распознанных неточностей.
Д6 — «Замысел управления конфигурацией ПО» — устанавливает правила идентификации единиц ПО и комплектации, базисные предположения и их трассируемость на производные версии, правила управления трансформациями, учёта состояния и правила порядка конфигурации, архивирования, контроля и зашиты данных, обращения единиц ПО.
Д7 — «Замысел гарантии качества ПО» устанавливает сферу действия, распределение ответственности и аудита и полномочий инспекций, вторых мероприятий, которые связаны с процессами получения обеспечений, включая сообщения о проблемах, их отслеживание и корректирующие действия.
Д8 — «Описание проекта ПО» — содержит подробное описание того, как ПО удовлетворяет предъявляемым к нему требованиям большого уровня, включая методы, структуры данных, и как требования к ПО распределяются по процессам и задачам. Также, приводится описание архитектуры ПО, библиотек, входов/ выходов, потоков данных и управления, распределения ресурсов и связанных с этим ограничений, процедур диспетчеризации, схем между-процессного и межзадачного обмена, прерывания, компонентов ПО, способов их обособления.
Д9 «Исходный код» — содержит исходный код, инструкции компилятора для генерации объектного кода, эти для загрузки и редактирования связей.
Д10 — «Объектный исполняемый код» — содержит код, пригодный для яркого исполнения процессором целевого вычислителя, т. е. таковой, что загружается в аппаратуру совокупности авионики.
Д11 — «Каталог комплектации ПО» — определяет конфигурацию продукта как поставляемой единицы. Он обязан идентифицировать программный продукт в целом, любой компонент, соответствующие их носители и документы.
Д12 — «Каталог среды ПО» — содержит описание среды ЖЦ ПО, начиная с этапа специфицирования требований и заканчивая этапом списания продукта из эксплуатации. В каталоге идентифицируются инструменты разработки, верификации, сопровождения программных средств, приводятся эти относительно квалификации инструментария.
Д13 — «Процедуры и результаты верификации» допускается дробить на два-три документа, в которых должны быть обрисованы процедуры рассмотрения, анализа, опробований на всех этапах разработки, примененные результаты и тестовые примеры совершённых процедур с идентифицированными компонентами ПО. Все неприятности и выполненные корректирующие действия должны быть детально обрисованы.
Д14 — «Протоколы УКПО».
Д15 — «Протоколы ГКПО».
Д16 — «Итоговое заключение о ПО» — это главный документ, фиксирующий исполнение «Замысла сертификации ПО» и степень соответствия «Требованиям к ПО». Он обязан содержать краткие описания совокупности и ПО, сертификационные условия (договоренности), характеристики, состояние и идентификацию ПО, список документации на ПО и прошение о степени исполнения требований к ПО.

Бортовое программное обеспечение самолета

Русский мозг: отладка авионики для МС-21

Увлекательные записи:

Похожие статьи, которые вам, наверника будут интересны: