Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Соображения по поводу программного обеспечения при сертификации бортовых систем и оборудования
Последняя версия5 января 2012 г. (2012-01-05)
Организация
ДоменАвиация
Сокращение
  • DO-178C
  • ED-12C

DO-178C «Соображения по программному обеспечению при сертификации бортовых систем и оборудования» - это основной документ, с помощью которого сертификационные органы, такие как FAA , EASA и Transport Canada, утверждают все коммерческие программные аэрокосмические системы. Документ опубликован RTCA, Incorporated , совместно с EUROCAE , и заменяет DO-178B . Новый документ называется DO-178C / ED-12C и был завершен в ноябре 2011 года и одобрен RTCA в декабре 2011 года. Он стал доступен для продажи и использования в январе 2012 года. [1] [2] [3]

FAA одобрило AC 20-115C [4] 19 июля 2013 года, что сделало DO-178C признанным «приемлемым средством, но не единственным средством демонстрации соответствия применимым правилам летной годности для программных аспектов сертификации бортовых систем и оборудования. "

Фон [ править ]

С момента выпуска DO-178B , DER ( уполномоченные технические представители FAA) настоятельно призывали прояснить / уточнить определения и границы между ключевыми концепциями 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, такие как двусмысленность концепции требований низкого уровня, могут быть не решены полностью. [5]

Организация комитета [ править ]

Работа совместного комитета RTCA / EUROCAE была разделена на семь подгрупп:

  • ИК1: интеграция документов SCWG
  • ИК2: Проблемы и обоснование
  • ИК3: Квалификация инструмента
  • ИК4: Разработка и проверка на основе моделей
  • ИК5: Объектно-ориентированные технологии
  • ИК6: Формальные методы
  • ИК7: Соображения, связанные с безопасностью

Подгруппа разработки и проверки на основе моделей (SG4) была самой большой из рабочих групп. Вся работа собирается и координируется через веб-сайт, который представляет собой механизм управления совместной работой. [6] Рабочие артефакты и черновики документов хранились в закрытой зоне, доступной только членам группы.

Работа была сосредоточена на обновлении DO-178B / ED-12B с учетом текущих практик, инструментов и технологий разработки программного обеспечения. [7] [8]

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

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

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

Сам по себе DO-178C не предназначен для гарантии аспектов безопасности программного обеспечения. Атрибуты безопасности в проекте и в том виде, в каком они реализованы как функциональные возможности, должны получать дополнительные обязательные системные задачи безопасности для управления и демонстрации объективных свидетельств соответствия явным требованиям безопасности. Органы сертификации требуют, а DO-178C указывает, что правильный DAL должен быть установлен с использованием этих комплексных методов анализа для установления уровня программного обеспечения AE. «Уровень программного обеспечения устанавливает строгость, необходимую для демонстрации соответствия» DO-178C. [9] Любое программное обеспечение, которое управляет, контролирует и отслеживает критически важные для безопасности функции, должно получить наивысший DAL - уровень A.

Количество целей, которые должны быть удовлетворены (некоторые с независимостью), определяется программным уровнем AE. Фраза «с независимостью» относится к разделению ответственности, когда объективность процессов верификации и валидации обеспечивается за счет их «независимости» от команды разработчиков программного обеспечения. Для целей, которые должны быть удовлетворены с помощью независимости, лицо, проверяющее элемент (например, требование или исходный код), может не быть лицом, создавшим элемент, и это разделение должно быть четко задокументировано. [10]

УровеньСостояние отказаЦели [11]С независимостью
АКатастрофический7130
BОпасно6918
CГлавный625
DНезначительный26 год2
EНет эффекта безопасности00

Прослеживаемость [ править ]

Диаграмма, показывающая необходимую трассировку между артефактами сертификации в соответствии со стандартом RTCA DO-178C. Кривые красного цвета требуются только для уровня A. Кривые красного цвета требуются для уровней A, B и C. Кривые зеленого цвета предназначены для уровней A, B, C и D. Уровень E не требует какой-либо трассировки. Ссылки на каждой стрелке трассировки представляют собой ссылки на стандарт для цели, действия и обзора / проверки, соответственно.

DO-178 требует документированного соединения (называемого трассировкой) между артефактами сертификации. Например, требование низкого уровня (LLR) прослеживается до требования высокого уровня (HLR). Затем используется анализ прослеживаемости, чтобы гарантировать, что каждое требование выполняется исходным кодом, что каждое требование проверено, что каждая строка исходного кода имеет цель (связана с требованием) и т. Д. Прослеживаемость гарантирует завершенность системы. Строгость и детализация артефактов сертификации связаны с уровнем программного обеспечения.

Отличия от DO-178B [ править ]

SC-205 / WG-12 отвечала за пересмотр DO-178B / ED-12B, чтобы привести его в соответствие с текущими технологиями разработки и проверки программного обеспечения. Структура документа остается в основном той же от B до C. Примеры изменений включают: [12]

  • Обеспечьте более понятный язык и терминологию, обеспечьте больше единообразия
  • Больше целей (для уровней A, B и C)
  • Уточнена «скрытая цель», применимая к уровню A, которая подразумевается DO-178B в разделе 6.4.4.2b, но не указана в таблицах приложения A. Эта цель теперь явно указана в DO-178C, приложение A, таблица A-7, цель 9: «Достигнута проверка дополнительного кода, который не может быть прослежен до исходного кода». [13]
  • Файлы элементов данных параметров - предоставляют отдельную информацию, которая влияет на поведение исполняемого объектного кода (без его изменения). Примером может служить файл конфигурации, который устанавливает расписание и основные временные рамки многораздельной операционной системы. Файл элемента данных параметра должен быть проверен вместе с исполняемым объектным кодом, в противном случае он должен быть протестирован для всех возможных диапазонов элементов данных параметра.
  • DO-330 «Соображения по квалификации программных средств», новый «независимый от предметной области внешний документ», был разработан для обеспечения руководства по приемлемому процессу квалификации инструментальных средств. Хотя DO-178C использовался в качестве основы для разработки этого нового документа, текст был адаптирован для прямого и раздельного применения при разработке инструментов и для рассмотрения всех аспектов инструментов. Как независимый от предметной области, автономный документ DO-330 предназначен для использования не только для поддержки DO-178C / ED-12C, но и DO-278 / ED-109, DO-254 / ED-80 , DO- 278 , а также DO-200 , даже для неавиационных приложений, например, ISO 26262 или ECSS . [14] Следовательно, руководство по квалификации инструмента было удалено из DO-178C, заменено в нем руководством для принятия решения о том, когда применять руководство по квалификации инструмента DO-330 к инструментам, используемым в контексте DO-178C. [15]
  • Добавлены технологические дополнения, чтобы расширить руководство документа DO-178C до конкретных методов. Вместо того, чтобы расширять предыдущий текст для учета всех текущих и будущих методов разработки программного обеспечения, доступны дополнения для явного добавления, удаления или иного изменения руководства основного стандарта для применения к конкретным методам или технологиям. Все руководства в этих дополнениях написаны в контексте затронутых элементов руководства в DO-178C, и поэтому их следует рассматривать как на том же уровне полномочий, что и этот базовый документ. [16]
    • DO-331 «Дополнение к DO-178C и DO-278A для модельно-ориентированной разработки и проверки» - касается модельно-ориентированной разработки (MBD) и проверки, а также возможности использования методов моделирования для улучшения разработки и проверки, избегая при этом ошибок, присущих некоторым моделям методы
    • DO-332 «Приложение к объектно-ориентированным технологиям и смежным методам к DO-178C и DO-278A» - адресное объектно-ориентированное программное обеспечение и условия, при которых оно может использоваться.
    • DO-333 «Дополнение к формальным методам к DO-178C и DO-278A» - обращение к формальным методам, дополняющим (но не заменяющим) тестирование.

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

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

Весь документ DO-248C / ED-94C, Вспомогательная информация для DO-178C и DO-278A , относится к категории «вспомогательной информации», а не к руководству. [17]

Примерная разница между DO-178B и DO-178C [ править ]

В главе 6.1 определяется цель процесса проверки программного обеспечения. DO-178C добавляет следующее утверждение об исполняемом коде объекта:

  • «Исполняемый объектный код удовлетворяет программным требованиям (то есть предполагаемой функции) и обеспечивает уверенность в отсутствии непредвиденных функций».
  • «Исполняемый объектный код устойчив к требованиям программного обеспечения, так что он может правильно реагировать на аномальные входные данные и условия».

Для сравнения, DO-178B утверждает следующее относительно исполняемого объектного кода:

  • «Исполняемый объектный код удовлетворяет программным требованиям».

Дополнительное пояснение заполняет пробел, с которым может столкнуться разработчик программного обеспечения при интерпретации документа. [18]

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

  • DO-178B
  • DO-248C , дополнительная информация для DO-178C и DO-278A
  • Измененное условие / покрытие решения

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

  1. ^ Программное обеспечение членства Timberlake, 703-591-4232. "РТКА, Инк ." Rtca.org . Проверено 7 августа +2016 .
  2. ↑ Шарлотта Адамс (1 сентября 2010 г.). «DO-178C приближается к финишу, заслуга современных инструментов и технологий» . Avionics Intelligence . Проверено 23 октября 2010 года . Промышленность ожидает, что окончательный пакет - DO-178C - будет выпущен в первом квартале 2011 года и будет утвержден через шесть-девять месяцев после ратификации.
  3. ^ «Краткое изложение различий между DO-178B и DO-178C» . FAA Consultants.com . Qualtech Consulting, Inc . Проверено 23 октября 2010 года . Выпуск этих долгожданных стандартов состоится в середине 2011 года и будет признан сертификационными органами в 2012 году.
  4. ^ «Архивная копия» (PDF) . Архивировано из оригинала (PDF) на 3 сентября 2014 года . Проверено 8 августа 2013 . CS1 maint: archived copy as title (link)
  5. ^ Дейл, Крис; Андерсон, Том, ред. (2010). Достижения в области безопасности систем: Труды Девятнадцатой безопасности критически важные системы Симпозиума, Саутгемптон, Великобритания, 8-10 февраля 2011 . Лондон: Спрингер. С. 298–299. ISBN 9780857291325.
  6. ^ "Архивная копия" . Архивировано из оригинального 19 июля 2011 года . Проверено 18 сентября 2010 .CS1 maint: archived copy as title (link)
  7. ^ Билл StClair и Тим Кинг (7 марта 2012). «DO-178C привносит современные технологии в разработку критически важного для безопасности программного обеспечения» . Военные встраиваемые системы . Проверено 17 апреля 2012 года .
  8. ^ "DO-178C расширяет возможности разработки программного обеспечения авионики, критически важного для безопасности" . Электронный дизайн . Электронный дизайн . Проверено 17 апреля 2012 года .
  9. ^ a b RTCA / DO-178C «Рекомендации по программному обеспечению при сертификации бортовых систем и оборудования», стр. 116. «Одним из примеров является термин« уровень обеспечения разработки элементов »(IDAL), который для программного обеспечения является синонимом термина« уровень программного обеспечения ».
  10. ^ RTCA / DO-178C "Соображения по поводу программного обеспечения при сертификации бортовых систем и оборудования", стр. 41 год
  11. ^ RTCA / DO-178C "Соображения по поводу программного обеспечения при сертификации бортовых систем и оборудования", Приложение A
  12. ^ «HighRely Synopsis National FAA Software and Hardware Meeting включает статус DO-178C» . 2006 . Проверено 30 сентября 2009 года . DO-178C будет содержать более подробную информацию о программном моделировании и потенциальной возможности использования моделирования для замены некоторых методов проверки, обычно требуемых в DO-178B. DO-178C также будет более полно адресовать объектно-ориентированное программное обеспечение (объектно-ориентированное) и условия, при которых оно может использоваться, а также сертификационные разветвления объектно-ориентированного программного обеспечения в DO-178C.
  13. ^ RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc. 2011.
  14. ^ Pothon, Frédéric. "Principles and benefits of using DO-330/ED-215" (PDF). validas. Retrieved 3 October 2019.
  15. ^ Pothon, Frédéric; et al. (2012). DO-178C/ED-12C versus DO-178B/ED-12B Changes and Improvements (PDF). p. 49. Retrieved 5 January 2015.
  16. ^ Pothon, pp. 43-46
  17. ^ Pothon, p. 14
  18. ^ "Archived copy". Archived from the original on 11 September 2014. Retrieved 2013-03-07.CS1 maint: archived copy as title (link)

External links[edit]

  • Charlotte Adams (21 October 2010). "Safety-critical software for mission-critical applications to get boost with release of DO-178C". Military & Aerospace Electronics. Retrieved 4 February 2014.
  • Charlotte Adams (1 September 2010). "DO-178C Core changes". Avionics Intelligence. Retrieved 23 October 2010.
  • Bill StClair and Nat Hillary (2010). "DO-178C: Improved certification for cost-effective avionics systems". VME and Critical Systems. Retrieved 23 October 2010.
  • John McHale (8 October 2009). "Upgrade to DO-178B certification, DO-178C, to address modern avionics software trends". Avionics Intelligence. Retrieved 23 October 2010.
  • Frederic Pothon (2012). "DO-178C/ED-12C vs DO-178B/ED-12B: Changes and Improvements". Open DO. Retrieved 23 October 2010.