DO-178B

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «DO-178B»  -  новости  · газеты  · книги  · ученый  · JSTOR ( июнь 2010 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

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

FAA применяется DO-178B в качестве документа , который он использует для руководства , чтобы определить , если программное обеспечение будет работать надежно в воздухе окружающей среды, ^[1] , если это указано в Техническом стандартном заказе (ТСО) , для которых сертификация испрашивается. В Соединенных Штатах, введение ОТП в процесс сертификации летной годности, а также расширение DO-178B, явно установлено в Разделе 14: аэронавтике и исследованию космического пространства в Свода федеральных правил (CFR), также известный как Положения Федерального авиационного , Часть 21, подраздел O.

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

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

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

Сам по себе 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. Фраза «с независимостью» относится к разделению ответственности, когда объективность процессов верификации и валидации обеспечивается за счет их «независимости» от команды разработчиков программного обеспечения. Для целей, которые должны быть удовлетворены с помощью независимости, лицо, проверяющее элемент (например, требование или исходный код), может не быть лицом, создавшим элемент, и это разделение должно быть четко задокументировано. ^[3] В некоторых случаях автоматизированный инструмент может быть эквивалентен независимости. ^[4] Однако сам инструмент должен быть квалифицирован, если он заменяет проверку, проводимую людьми.

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

Процессы предназначены для поддержки целей в соответствии с уровнем программного обеспечения (от 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 модель

Подтверждение [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Обеспечение качества [ править ]

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

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

Этот процесс выполняет обзоры и аудит, чтобы показать соответствие DO-178B. Интерфейс с центром сертификации также обрабатывается процессом обеспечения качества.

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

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

Инструменты [ править ]

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

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

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

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

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

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

Критика [ править ]

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

Ресурсы [ править ]

• FAR Часть 23/25 §1301 / §1309
• FAR Часть 27/29
• AC 23 / 25.1309
• AC 20-115B
• RTCA / DO-178B
• Приказ FAA 8110.49 Руководство по утверждению программного обеспечения

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

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

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

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

• AC 25.1309-1A
• AC 20-115B
• Приказ FAA 8110.49, изменение 1