DO-178B - Википедия - DO-178B

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

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

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

Он был разработан совместно рабочей группой по безопасности RTCA SC-167 из RTCA и РГ-12 EUROCAE. RTCA опубликовало документ как RTCA / DO-178B, а EUROCAE опубликовало документ как ЭД-12Б.

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

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

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

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

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

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

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

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

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

Критика

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

Ресурсы

• ДАЛЕКО Часть 23/25 §1301 / §1309
• ДАЛЕКО Часть 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 (стандарт разработки процессов жизненного цикла программного обеспечения)
• ЭД-153 (Руководство по обеспечению безопасности программного обеспечения ANS)
• Измененное условие / покрытие решения
• DO-178B Аэрокосмическая промышленность

Рекомендации

внешняя ссылка

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