Russian English French German Italian Spanish
Бортовое программное обеспечение
Прочие
Бортовое программное обеспечение

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

 

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

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

Комментарии

CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
.

Лучшее в мире авиации

АОПА-Россия
Сообщение в блоге
Авторские статьи
наверх