DO-178B, Software Considerations in Airborne Systems and Equipment Certification — это руководство, касающееся безопасности критически важного для безопасности программного обеспечения, используемого в определенных бортовых системах. Оно было совместно разработано рабочей группой по критически важным для безопасности RTCA SC-167 Радиотехнической комиссии по аэронавтике (RTCA) и WG-12 Европейской организации по оборудованию для гражданской авиации (EUROCAE). RTCA опубликовала документ как RTCA/DO-178B , в то время как EUROCAE опубликовала документ как ED-12B . Хотя технически это руководство , оно было фактическим стандартом для разработки систем программного обеспечения авионики , пока в 2012 году его не заменил DO-178C .
Федеральное управление гражданской авиации (FAA) применяет DO-178B в качестве документа, который оно использует в качестве руководства для определения того, будет ли программное обеспечение надежно работать в воздушной среде, [1] когда это указано в Техническом стандартном приказе (TSO), для которого запрашивается сертификация. В Соединенных Штатах введение TSO в процесс сертификации летной годности и, соответственно, 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 не предназначен для использования в качестве стандарта разработки программного обеспечения; это обеспечение качества программного обеспечения, использующее набор задач для достижения целей и уровней строгости.
Выходные документы процесса разработки:
Обычно требуется прослеживаемость от системных требований до всего исходного кода или исполняемого объектного кода (в зависимости от уровня программного обеспечения).
Обычно используемый процесс разработки программного обеспечения :
Результаты документирования, полученные в результате этого процесса:
Обычно требуется анализ всего кода и прослеживаемость от тестов и результатов до всех требований (в зависимости от уровня программного обеспечения).
Этот процесс обычно также включает:
Другие названия тестов, выполняемых в этом процессе, могут быть:
Документы, поддерживаемые процессом управления конфигурацией :
Этот процесс обрабатывает отчеты о проблемах, изменения и связанные с ними действия. Процесс управления конфигурацией обычно обеспечивает архив и идентификацию ревизий:
Выходные документы процесса обеспечения качества:
Этот процесс выполняет обзоры и аудиты для демонстрации соответствия DO-178B. Интерфейс с органом сертификации также обрабатывается процессом обеспечения качества.
Обычно уполномоченный технический представитель (DER) рассматривает технические данные в рамках представления в FAA для утверждения.
Программное обеспечение может автоматизировать, помогать или иным образом управлять или помогать в процессах DO-178B. Все инструменты, используемые для разработки DO-178B, должны быть частью процесса сертификации. Инструменты, генерирующие встроенный код, квалифицируются как инструменты разработки с теми же ограничениями, что и встроенный код. Инструменты, используемые для проверки кода (симуляторы, инструмент выполнения теста, инструменты покрытия, инструменты отчетности и т. д.), должны квалифицироваться как инструменты верификации , гораздо более легкий процесс, состоящий из всестороннего тестирования инструмента методом черного ящика .
Инструмент третьей стороны может быть квалифицирован как инструмент проверки, но инструменты разработки должны быть разработаны в соответствии с процессом DO-178. Компании, предоставляющие такие инструменты как COTS , подлежат аудиту со стороны органов сертификации, которым они предоставляют полный доступ к исходному коду, спецификациям и всем артефактам сертификации.
За пределами этой области результаты работы любого используемого инструмента должны быть проверены вручную людьми.
Прослеживаемость требований связана с документированием жизненного цикла требования. Должна быть возможность проследить происхождение каждого требования, и поэтому каждое изменение, внесенное в требование, должно быть документировано для достижения прослеживаемости. Даже использование требования после того, как реализованные функции были развернуты и использованы, должно быть прослеживаемым.
VDC Research отмечает, что DO-178B стал «несколько устаревшим», поскольку он не очень хорошо адаптируется к потребностям и предпочтениям современных инженеров. В том же отчете они также отмечают, что DO-178C , похоже, хорошо подходит для решения этой проблемы. [ необходима цитата ]