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

DO-178B - Wikipedia
Вопросы программного обеспечения при сертификации бортовых систем и оборудования
Последняя версия1 декабря 1992 г. (1992-12-01)
Организация
ДоменАвиация
Сокращение
  • DO-178B
  • ЭД-12Б

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] Однако сам инструмент затем должен быть квалифицирован, если он заменяет проверку, проводимую людьми.

УровеньСостояние отказаЦели[5]С независимостьюИнтенсивность отказов
АКатастрофический662510−9/час
BОпасно651410−7/час
CОсновной57210−5/час
DНезначительный28210−3/час
EНет эффекта00н / д

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

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

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

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

Проверка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

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

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

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

Критика

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 Руководство по утверждению программного обеспечения

Смотрите также

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

  1. ^ Консультативный циркуляр FAA 20-115B
  2. ^ RTCA / DO-178C «Рекомендации по программному обеспечению при сертификации бортовых систем и оборудования», стр. 116. «Одним из примеров является термин« уровень обеспечения разработки элементов »(IDAL), который для программного обеспечения является синонимом термина« уровень программного обеспечения ».
  3. ^ RTCA / DO-178B «Вопросы программного обеспечения при сертификации бортовых систем и оборудования», стр. 82
  4. ^ RTCA / DO-178B "Соображения по поводу программного обеспечения при сертификации бортовых систем и оборудования", стр.82
  5. ^ RTCA / DO-178B «Соображения по поводу программного обеспечения при сертификации бортовых систем и оборудования», Приложение A

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