ДО-178Б

Аспекты программного обеспечения при сертификации бортовых систем и оборудования

Аббревиатура	ДО-178Б ЭД-12Б
Последняя версия	1 декабря 1992 г ( 1992-12-01 )
Организация	РТКА СК-167 ЕВРОКАЕ РГ-12
Домен	Авиация

DO-178B, «Аспекты программного обеспечения при сертификации бортовых систем и оборудования» — это руководство, касающееся безопасности критически важного для безопасности программного обеспечения, используемого в определенных бортовых системах. Он был совместно разработан рабочей группой по вопросам безопасности RTCA SC-167 Радиотехнической комиссии по аэронавтике (RTCA) и WG-12 Европейской организации по оборудованию гражданской авиации (EUROCAE). RTCA опубликовало документ как RTCA/DO-178B , а EUROCAE опубликовало документ как ED-12B . Хотя технически это руководство , оно было фактическим стандартом для разработки систем программного обеспечения авионики , пока в 2012 году его не заменил DO-178C .

Федеральное управление гражданской авиации (FAA) применяет DO-178B в качестве документа, который оно использует в качестве руководства для определения того, будет ли программное обеспечение надежно работать в воздушной среде. если это указано в Приказе о технических стандартах (TSO), для которого запрашивается сертификация. В Соединенных Штатах включение TSO в процесс сертификации летной годности и, как следствие, DO-178B, прямо установлено в разделе 14 «Аэронавтика и космос» Кодекса федеральных правил (CFR), также известного как Федеральные авиационные правила . Часть 21, подраздел О.

Уровень программного обеспечения

Уровень программного обеспечения , также называемый уровнем гарантии проектирования (DAL) или уровнем гарантии разработки изделия (IDAL), как определено в ARP4754 ( DO-178C упоминает IDAL только как синоним уровня программного обеспечения). ), определяется на основе процесса оценки безопасности и анализа опасностей путем изучения последствий отказа в системе. Условия отказа классифицируются по их влиянию на воздушное судно, экипаж и пассажиров.

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

DO-178B сам по себе не предназначен для обеспечения безопасности программного обеспечения. Атрибуты безопасности, заложенные в проект и реализованные как функциональные возможности, должны получать дополнительные обязательные задачи безопасности системы для управления и демонстрации объективных доказательств соответствия явным требованиям безопасности. Обычно планы безопасности программного обеспечения IEEE STD-1228-1994 распределяются, и задачи анализа безопасности программного обеспечения выполняются в последовательные этапы (анализ требований, анализ проекта верхнего уровня, подробный анализ проекта, анализ уровня кода, анализ тестирования и анализ изменений). Эти задачи и артефакты безопасности программного обеспечения являются неотъемлемыми вспомогательными частями процесса определения серьезности опасностей и DAL, которые документируются в оценках безопасности системы (SSA). Органы по сертификации требуют, а DO-178B определяет правильный DAL, который должен быть установлен с использованием этих методов комплексного анализа для установления уровня программного обеспечения AE. Любое программное обеспечение, которое управляет, контролирует и контролирует критически важные для безопасности функции, должно получить самый высокий DAL - уровень A. Именно анализ безопасности программного обеспечения определяет оценки безопасности системы, определяющие DAL, который определяет соответствующий уровень строгости в DO-178B. Оценка безопасности системы в сочетании с такими методами, как SAE ARP 4754A определяет DAL после устранения опасностей и может позволить снизить цели уровня программного обеспечения DO-178B, которые должны быть удовлетворены, если избыточность, функции проектной безопасности и другие архитектурные формы снижения опасностей входят в требования, определяемые анализом безопасности. Таким образом, центральной темой DO-178B является обеспечение и проверка конструкции после того, как были установлены необходимые требования безопасности.

Количество целей, которые необходимо удовлетворить (в конечном итоге с независимостью), определяется уровнем программного обеспечения AE. Фраза «с независимостью» относится к разделению обязанностей, при котором объективность процессов проверки и валидации обеспечивается за счет их «независимости» от команды разработчиков программного обеспечения. Для целей, которым должна быть обеспечена независимость, лицо, проверяющее элемент (например, требование или исходный код), может не быть автором элемента, и это разделение должно быть четко задокументировано. В некоторых случаях автоматизированный инструмент может быть эквивалентом независимости. Однако в этом случае сам инструмент должен быть квалифицирован, если он заменяет проверку человеком.

Уровень	Состояние отказа	Цели	С независимостью	Частота отказов
А	Катастрофический	66	25	10 −9 /час
Б	Опасный	65	14	10 −7 /час
С	Главный	57	2	10 −5 /час
Д	Незначительный	28	2	10 −3 /час
И	Нет эффекта	0	0	н/д

Процессы и документы

Процессы предназначены для поддержки целей в соответствии с уровнем программного обеспечения (от A до D — уровни E выходят за рамки DO-178B). В DO-178B процессы описаны как абстрактные области работы, и планировщикам реального проекта предстоит определить и задокументировать особенности того, как процесс будет выполняться. В реальном проекте необходимо показать фактические действия, которые будут выполняться в контексте процесса, для достижения целей. Эти действия определяются планировщиками проекта как часть процесса планирования.

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

Гибкий характер процессов DO-178B и критериев входа/выхода затрудняет реализацию с первого раза, поскольку эти аспекты абстрактны и не существует «базового набора» действий, на основе которого можно было бы работать. Цель DO-178B не заключалась в том, чтобы носить предписывающий характер. Существует множество возможных и приемлемых способов определения этих аспектов в реальном проекте. Это может быть сложно, когда компания впервые пытается разработать систему гражданской авионики в соответствии с этим стандартом и создала нишу рынка для обучения и консультирования по DO-178B.

Для общего процесса, основанного на DO-178B, предоставляется визуальное резюме , включая этапы участия (SOI), определенные FAA в «Руководстве и методических указаниях для программного обеспечения и сложного электронного оборудования».

Планирование

Системные требования обычно вводятся во весь проект.

Последние 3 документа (стандарта) не требуются для уровня ПО D..

Разработка

DO-178B не предназначен в качестве стандарта разработки программного обеспечения; это гарантия программного обеспечения, использующая набор задач для достижения целей и уровней строгости.

Выходные документы процесса разработки:

• Данные о требованиях к программному обеспечению (SRD)
• Описание проекта программного обеспечения (SDD)
• Исходный код
• Исполняемый объектный код

Обычно требуется прослеживаемость от системных требований до всего исходного кода или исполняемого объектного кода (в зависимости от уровня программного обеспечения).

Обычно используемый процесс разработки программного обеспечения :

• Модель водопада
• Спиральная модель
• V model

Проверка

Документируйте результаты, полученные в результате этого процесса:

• Случаи и процедуры проверки программного обеспечения (SVCP)
• Результаты проверки ПО (SVR):
  • Обзор всех требований, дизайна и кода
  • Тестирование исполняемого объектного кода
  • покрытия кода Анализ

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

Этот процесс обычно также включает в себя:

• Инструменты тестирования на основе требований
• покрытия кода Инструменты анализа

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

• Модульное тестирование
• Интеграционное тестирование
• Черный ящик и приемочное тестирование

Управление конфигурацией

Документы, поддерживаемые процессом управления конфигурацией :

• Индекс конфигурации программного обеспечения (SCI)
• Индекс конфигурации среды жизненного цикла программного обеспечения (SECI)

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

• Среда разработки исходного кода
• Другие среды разработки (например, инструменты тестирования/анализа)
• Инструмент интеграции программного обеспечения
• Все остальные документы, программное и аппаратное обеспечение

Гарантия качества

Выходные документы процесса обеспечения качества:

• программного обеспечения Записи обеспечения качества (SQAR)
• Проверка соответствия программного обеспечения (SCR)
• Сводка достижений программного обеспечения (SAS)

В рамках этого процесса проводятся проверки и аудиты для подтверждения соответствия требованиям DO-178B. Взаимодействие с центром сертификации также регулируется процессом обеспечения качества.

Представитель по сертификации

Обычно назначенный технический представитель (DER) проверяет технические данные при их передаче в ФАУ на утверждение.

Инструменты

Программное обеспечение может автоматизировать, помогать или иным образом управлять или помогать в процессах DO-178B. Все инструменты, используемые для разработки DO-178B, должны быть частью процесса сертификации. Инструменты, генерирующие встроенный код, квалифицируются как инструменты разработки с теми же ограничениями, что и встроенный код. Инструменты, используемые для проверки кода (симуляторы, инструмент выполнения тестов, инструменты покрытия, инструменты отчетности и т. д.), должны квалифицироваться как инструменты проверки . Это гораздо более легкий процесс, заключающийся во всестороннем «черного ящика» тестировании инструмента методом .

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

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

• Инструмент управления проблемами может обеспечить отслеживание изменений.
• SCI и SECI можно создать из журналов в инструменте контроля версий .

Управление требованиями

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

Критика

VDC Research отмечает, что DO-178B стал «несколько устаревшим», поскольку он плохо адаптируется к потребностям и предпочтениям сегодняшних инженеров. В том же отчете они также отмечают, что DO-178C, похоже, хорошо подходит для решения этой проблемы.

Ресурсы

• FAR Часть 23/25 §1301/§1309
• ФАР Часть 27/29
• АС 23/25.1309
• АС 20-115Б
• РТКА/ДО-178Б
• Приказ ФАУ 8110.49 «Руководство по одобрению программного обеспечения»

См. также

• ДО-178С
• Программное обеспечение для авионики
• ARP4761 (Процесс оценки безопасности)
• ARP4754 (Процесс разработки системы)
• DO-248B (Окончательный отчет по разъяснению DO-178B)
• ДО-254 (аналог ДО-178Б, но по аппаратной части)
• Управление требованиями (слишком общее, чтобы его можно было «непосредственно применять» к DO-178B)
• МЭК 61508
• ISO/IEC 12207 (стандарт разработки процессов жизненного цикла программного обеспечения)
• ED-153 (Руководство по обеспечению безопасности программного обеспечения ANS)
• Измененное покрытие условий/решений

Дальнейшее чтение

• Лесли А. (Шад) Джонсон. DO-178B, Вопросы программного обеспечения при сертификации бортовых систем и оборудования (в контексте разработки программного обеспечения для военных самолетов, обсуждение практиками эволюции текущей практики и применения RTCA/DO-178B) . Группа коммерческих самолетов Boeing . Проверено 3 марта 2022 г.

• Леанна Риерсон (19 декабря 2017 г.) [7 января 2013 г.]. Разработка программного обеспечения, критически важного для безопасности: Практическое руководство по авиационному программному обеспечению и обеспечению соответствия DO-178C . ЦРК Пресс . ISBN  9781351834056 . Проверено 3 марта 2022 г.

Внешние ссылки

• АС 25.1309-1А
• АС 20-115Б
• Приказ ФАУ 8110.49 Изменение 1