Стандарты сертификации программного обеспечения DO-178B и DO-178C служат руководством для создания летных бортовых систем. DO-178B (Рассмотрение программного обеспечения в бортовых системах и оборудовании для сертификации), впервые опубликованный в 1992 году, был основным документом, учитываемым при получении сертификации от органов вроде EASA (Европейское агентство авиационной безопасности) и FAA (Федеральное управление гражданской авиации) для коммерческих программно-зависимых бортовых систем. Однако Федеральные авиационные правила признали DO-178C методом демонстрации соответствия летной годности в 2013 году. Для получения более общей информации о стандартах DO-178B и DO-178C вы можете прочитать эту статью.
Стандартам DO-178B или DO-178C должны соответствовать такие документы, как:
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
Это не единственные документы, необходимые для соответствия стандартам DO-178B и DO-178C. Существует большое количество других документов для улучшения летной годности. Вы можете проверить и купить эти документы здесь.
Документы DO178
Документ PSAC
Документ PSAC (Plan for Software Aspects of Certification) описывает необходимые стандарты, процессы, протоколы и методологии, которым следует следовать, а также представляет данные жизненного цикла. Таким образом, могут быть достигнуты цели документов DO-178. PSAC также указывает график разработки программного обеспечения и обзор системы. Этот документ используется как сертифицирующим органом, так и заявителем. PSAC должен быть создан на начальном этапе планирования программного обеспечения и получить одобрение органа. Чтобы проверить наш документ PSAC, пожалуйста, нажмите здесь.
Документ SDP
Документ SDP (Software Development Plan) направлен на проверку, указана ли необходимая информация, такая как процедуры разработки программного обеспечения, протоколы, стандарты, жизненные циклы и среда разработки. Документ SDP является важной частью периода планирования программного обеспечения. Чтобы проверить наш документ SDP, пожалуйста, нажмите здесь.
Документ SVP
Документ SVP (Software Verification Plan) определяет необходимые тестовые случаи и покрытия, процедуры, протоколы, верификацию требований, верификацию исходного кода с надлежащим контролем версий. SVP также является ключевым элементом процесса планирования. Чтобы проверить наш документ SVP, пожалуйста, нажмите здесь.
Документ SCMP
Документ SCMP (Software Configuration Management Plan) является еще одним ключевым аспектом периода планирования. В процессе разработки программного обеспечения часто случается, что первоначальный план меняется. SCMP помогает нам обнаруживать, контролировать, поддерживать и отслеживать эти изменения. Он применяется на протяжении всего процесса разработки программного обеспечения. Цель SCMP — минимизировать ошибки и максимизировать производительность. Члены команды должны приложить усилия для отчета и уведомления об изменениях. Чтобы проверить наш документ SCMP, пожалуйста, нажмите здесь.
Документ SQAP
Документ SQAP (Software Quality Assurance Plan) включает инструменты, методы и техники, используемые для обеспечения того, чтобы продукт или услуга соответствовали спецификациям, указанным в SRS (Software Requirement Specification). SQAP объясняет, как будут проводиться действия по обеспечению качества программного обеспечения в проекте. Команда SQA устанавливает вехи и оценивает качество проекта на каждой вехе. SQA проводится на протяжении всего жизненного цикла программного обеспечения. Чтобы проверить наш документ SQAP, пожалуйста, нажмите здесь.
Документ SAS
Документ SAS (Software Accomplishment Summary) подводит итоги каждого шага компонентов программного обеспечения в процессе разработки и верификации. SAS должен включать резюме результатов квалификации инструментов верификации. FAA должно быть уведомлено о SAS. Это позволяет органу сертификации проверить результаты данных верификации и служит доказательством статуса квалификации инструмента. Чтобы проверить наш документ SAS, пожалуйста, нажмите здесь.
Стандарты ARP4754 и стандарты DO178
ARP4754 означает «Рекомендуемая авиационная практика ARP4754A Руководство по разработке гражданских самолетов и систем». Стандарты ARP4754 предоставляют руководство для полных систем самолета, тогда как стандарты DO178 используются для программного обеспечения полета. Оба стандарта приняты такими органами, как FAA и EASA.
ARP4754 был разработан и опубликован SAE (Общество автомобильных инженеров) в 1996 году. В 2010 году SAE опубликовало ARP4754A, что означает Руководство по разработке гражданских самолетов и систем. ARP4754A расширяет идею обеспечения проектирования для использования на уровне самолетов и систем, а также стандартизирует использование термина обеспечение разработки. ARP4754 был признан FAA в ноябре 2011 года.
От требований до интеграции и верификации ARP4754 охватывает весь цикл разработки самолета. ARP4754 обеспечивает абстракцию для самолета, системы и элемента. Для проектирования элемента ARP4754 делает явную ссылку на DO-178 и DO-254. ARP4754 сосредотачивается на оценке безопасности на различных этапах, таких как разработка, проектирование и верификация. Тем не менее, следует отметить, что ARP4754 не включает конкретную сферу разработки программного обеспечения или электронного оборудования, деятельности по безопасности в процессе эксплуатации и разработке конструкции самолета.
Этапы проектирования
Предварительный обзор проекта — Preliminary Design Review (PDR)
Предварительное проектирование является важной фазой процесса разработки программного обеспечения. Во время предварительного проектирования определяются высокоуровневые требования и варианты использования для создания архитектуры системы. В проектировании могут быть использованы документы для интерфейса, базы данных и архитектуры, а также диаграммы для отношений между компонентами. Предварительное проектирование предложит визуальное представление системы на начальном этапе проекта на основе этих входных данных. Предварительное проектирование также создает основу для следующих более детализированных этапов проектирования. Это можно рассматривать как чертеж.
Предварительный обзор проекта (PDR) завершает этап предварительного проектирования проекта. Для перехода к детальному проектированию PRD должен предоставить достаточные гарантии. Цель PDR — убедиться, что предварительное проектирование и основная архитектура системы завершены, что есть техническая уверенность в том, что требования могут быть выполнены в рамках бюджета и графика.
Критический Обзор Проекта — Critical Design Review (CDR)
Критический Обзор Проекта (CDR) завершает критическую фазу проектирования проекта. Итоговые проекты представляются на CDR посредством комплексного анализа, симуляций, схем, программного кода и данных испытаний. CDR гарантирует, что система может перейти к тестированию и производству. Также подтверждается, что упомянутые требования могут быть выполнены в рамках бюджета и графика. Появившиеся комплексные чертежи и спецификации обеспечивают первоначальную базовую линию продукта с окончательной базовой линией. CDR должен быть тщательным и исчерпывающим.
Финальная Фаза Проектирования — Final Design Phase
Финальная Фаза Проектирования предоставляет детальные архитектурные и инженерные чертежи каждого компонента проекта. Для некоторых проектов может потребоваться создание итогового отчета по дизайну. Обнаруженные проблемы дизайна должны быть решены до завершения финальной фазы проектирования. Чертежи и отчет должны предоставить достаточно деталей для разумно точных оценок стоимости строительства и эксплуатации, а также времени строительства. Итоговый отчет по дизайну должен включать обновленный график, оценки стоимости и спецификации. Также должно быть подтверждено, что проект экономически целесообразен. Любые изменения на стадии Финального Проектирования обходятся дороже, чем на других этапах. Таким образом, она должна проводиться с большим вниманием.
Этапы Участия — SOI (Stages of Involvement)
Оценки Этапов Участия (SOI) проводятся авиационными властями соответствующих стран на различных этапах проекта, таких как планирование, разработка и верификация, чтобы оценить соответствие проектов DO-178B. В идеальных случаях планируется проведение четырех обзоров SOI.
Первоначальная оценка, которая является первым SOI, включает фазу планирования исследований соответствия сертификации проекта. Второй обзор SOI сосредоточен на фазах разработки проекта. Начиная с разработки высокоуровневых требований к программному обеспечению, он проверяет, производятся ли дизайн, требования к программному обеспечению низкого уровня и исходный код в соответствии с DO178B. Третий обзор SOI сосредоточен на фазах валидации. Исследуются не только действия по тестированию, но и все действия, проводимые в целях верификации. Четвертый SOI, с другой стороны, является заключительной оценкой, проводимой ближе к концу проекта, в которой проверяется, остались ли какие-либо действия незавершенными и возникли ли новые проблемы с момента предыдущих оценок.
Ожидание DO-178B от произведенных во время фазы планирования программных продуктов заключается в том, чтобы договориться о общем наборе правил между властью и компанией, его создающей, и соблюдать этот набор правил на протяжении всего проекта. Иными словами, при написании планов и стандартов компания не только определяет свои собственные процессы, но и пишет правила того, как власть будет оценивать себя на протяжении всего процесса сертификации.
Can Önal ([email protected])
Mor Teknoloji
