DO-178C, Software Considerations in Airborne Systems and Equipment Certification — основной документ, по которому сертификационные органы, такие как FAA , EASA и Transport Canada, одобряют все коммерческие программные аэрокосмические системы. Документ опубликован RTCA, Incorporated , совместно с EUROC и заменяет DO-178B . Новый документ называется DO-178C/ED-12C, он был завершен в ноябре 2011 года и одобрен RTCA в декабре 2011 года. Он стал доступен для продажи и использования в январе 2012 года. [1] [2] [3]
За исключением FAR 33 / JAR E, Федеральные авиационные правила напрямую не ссылаются на летную годность программного обеспечения. [4] 19 июля 2013 года FAA одобрило AC 20-115C , обозначив DO-178C как признанное «приемлемое средство, но не единственное средство для демонстрации соответствия применимым правилам летной годности FAR для аспектов программного обеспечения бортовых систем и сертификации оборудования». [5]
После выпуска DO-178B были настойчивые призывы со стороны уполномоченных инженерных представителей FAA (DER) прояснить/уточнить определения и границы между ключевыми концепциями DO-178B требований высокого уровня, требований низкого уровня и производных требований, а также более четко определить критерии выхода/входа между системными требованиями и проектированием системы (см. ARP4754 ) и требованиями к программному обеспечению и проектированием программного обеспечения (что является областью DO-178B). Другие опасения включали значение верификации в парадигме разработки на основе моделей и соображения о замене некоторых или всех видов деятельности по тестированию программного обеспечения на имитационное моделирование или формальные методы. Выпуск DO-178C и сопутствующих документов DO-278A (Наземные системы), DO-248C (Дополнительная информация с обоснованием для каждой цели DO-178C), DO-330 (Квалификация инструмента), DO-331 (Моделирование), DO-332 (Объектно-ориентированный) и DO-333 (Формальные методы) были созданы для решения отмеченных проблем. Члены SC-205 работали с комитетом SAE S-18, чтобы гарантировать, что ARP4754A и вышеупомянутые документы DO-xxx предоставляют единый и связанный процесс с дополнительными критериями.
В целом, DO-178C сохраняет большую часть текста DO-178B, что вызывает опасения, что проблемы с DO-178B, такие как неоднозначность концепции требований низкого уровня, могут быть не полностью решены. [6]
Работа совместного комитета RTCA/EUROCAE была разделена на семь подгрупп:
Подгруппа Model Based Development and Verification (SG4) была крупнейшей из рабочих групп. Вся работа собирается и координируется через веб-сайт, который является механизмом управления совместной работой. [7] Рабочие артефакты и черновики документов хранились в закрытой зоне, доступной только членам группы.
Работа была сосредоточена на обновлении DO-178B/ED-12B с учетом современных методов, инструментов и технологий разработки программного обеспечения. [8] [9]
Уровень программного обеспечения , также известный как уровень обеспечения разработки (DAL) или уровень обеспечения разработки элемента (IDAL), как определено в ARP4754 (DO-178C упоминает IDAL только как синоним уровня программного обеспечения [10] ), определяется из процесса оценки безопасности и анализа опасностей путем изучения последствий состояния отказа в системе. Состояния отказа классифицируются по их влиянию на самолет, экипаж и пассажиров.
DO-178C сам по себе не предназначен для гарантии аспектов безопасности программного обеспечения. Атрибуты безопасности в проекте и реализованные в виде функциональности должны получить дополнительные обязательные задачи безопасности системы для управления и демонстрации объективных доказательств соответствия явным требованиям безопасности. Сертификационные органы требуют, а DO-178C указывает, что правильный DAL должен быть установлен с использованием этих методов комплексного анализа для установления уровня программного обеспечения AE. «Уровень программного обеспечения устанавливает строгость, необходимую для демонстрации соответствия» с DO-178C. [10] Любое программное обеспечение, которое управляет, контролирует и отслеживает критически важные для безопасности функции, должно получить самый высокий DAL - уровень A.
Количество целей, которые должны быть удовлетворены (некоторые с независимостью), определяется уровнем программного обеспечения AE. Фраза «с независимостью» относится к разделению обязанностей, при котором объективность процессов верификации и валидации обеспечивается в силу их «независимости» от команды разработчиков программного обеспечения. Для целей, которые должны быть удовлетворены с независимостью, лицо, проверяющее элемент (например, требование или исходный код), может не быть лицом, которое создало элемент, и это разделение должно быть четко задокументировано. [11]
Процессы предназначены для поддержки целей в соответствии с уровнем программного обеспечения (A–D — уровень E находился вне сферы действия DO-178C). Процессы описываются как абстрактные области работы в DO-178C, и планировщики реального проекта должны определить и задокументировать особенности того, как будет выполняться процесс. В реальном проекте фактические действия, которые будут выполняться в контексте процесса, должны быть показаны для поддержки целей. Эти действия определяются планировщиками проекта как часть процесса планирования.
Эта объективная природа DO-178C допускает большую гибкость в отношении следования различным стилям жизненного цикла программного обеспечения . После того, как действие в рамках процесса определено, обычно ожидается, что проект будет уважать это документированное действие в рамках своего процесса. Кроме того, процессы (и их конкретные действия) должны иметь четко определенные критерии входа и выхода, согласно DO-178C, и проект должен показать, что он уважает эти критерии, выполняя действия в рамках процесса.
Гибкий характер процессов DO-178C и критериев входа/выхода затрудняет внедрение в первый раз, поскольку эти аспекты абстрактны и нет «базового набора» видов деятельности, с которыми можно было бы работать. Целью DO-178C не было предписание. Существует множество возможных и приемлемых способов для определения этих аспектов в реальном проекте. Это может быть сложно, когда компания впервые пытается разработать гражданскую систему авионики в соответствии с этим стандартом, и создало нишевый рынок для обучения и консультирования по DO-178C.
Для общего процесса на основе DO-178C этапы участия (SOI) представляют собой минимальные этапы, в которых орган по сертификации участвует при проверке системы или подсистемы, как определено EASA в Меморандуме о сертификации SWCEH – 002: Руководство по утверждению ПО и FAA в Приказе 8110.49: Руководство по утверждению ПО.
DO-178 требует документированных двунаправленных связей (называемых трассировками) между артефактами сертификации. Например, требование низкого уровня (LLR) прослеживается до требования высокого уровня (HLR), которому оно должно удовлетворять, а также до строк исходного кода, которые должны его реализовать, тестовых случаев, которые должны проверить правильность исходного кода относительно требования, результатов этих тестов и т. д. Затем используется анализ прослеживаемости, чтобы гарантировать, что каждое требование выполняется исходным кодом, что каждое функциональное требование проверено тестом, что каждая строка исходного кода имеет цель (связана с требованием) и т. д. Анализ прослеживаемости оценивает полноту системы. Строгость и детализация артефактов сертификации связаны с уровнем программного обеспечения.
SC-205/WG-12 отвечал за пересмотр DO-178B/ED-12B с целью приведения его в соответствие с современными технологиями разработки и проверки программного обеспечения. Структура документа в основном остается неизменной от B до C. Примеры изменений включают: [13]
DO-178B не был полностью последовательным в использовании терминов «руководящие принципы» и «руководящие указания» в тексте. «Руководящие принципы» передают немного более сильное чувство обязательства, чем «руководящие принципы». Таким образом, с DO-178C SCWG остановилась на использовании «руководящих принципов» для всех утверждений, которые считаются «рекомендациями», заменив оставшиеся случаи «руководящих принципов» на «вспомогательную информацию» и используя эту фразу везде, где текст больше ориентирован на «информацию», чем на «рекомендации».
Весь документ DO-248C /ED-94C, Вспомогательная информация для DO-178C и DO-278A , относится к категории «вспомогательной информации», а не руководства. [18]
Глава 6.1 определяет цель процесса проверки программного обеспечения. DO-178C добавляет следующее утверждение об исполняемом объектном коде:
Для сравнения, в DO-178B в отношении исполняемого объектного кода указано следующее:
Дополнительное разъяснение редакции C заполнило пробел, с которым разработчик программного обеспечения мог столкнуться при интерпретации документа редакции B. [19]
{{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )Отрасль ожидает, что окончательный пакет —DO-178C— будет выпущен в первом квартале 2011 г. и станет обязательным через шесть-девять месяцев после ратификации.
Выпуск этих долгожданных стандартов состоится в середине 2011 г. и будет признан органами сертификации в 2012 г.
{{cite web}}: CS1 maint: архивная копия как заголовок ( ссылка )DO-178C будет содержать больше подробностей о моделировании программного обеспечения и потенциальной возможности использования моделирования для замены некоторых методов проверки, обычно требуемых в DO-178B. DO-178C также будет более полно рассматривать OO (объектно-ориентированное) программное обеспечение и условия, при которых оно может использоваться, а также последствия сертификации OO в DO-178C.