Стандарты сертификации программного обеспечения DO-178B и DO-178C служат руководством по созданию лётно-годных воздушных систем. Впервые опубликованный в 1992 году DO-178B (Software Considerations in Airborne Systems and Equipment Certification) был важным документом для получения необходимой сертификации у таких органов, как EASA (Агентство авиационной безопасности Европейского союза) и FAA (Федеральное управление гражданской авиации США), для программно-зависимых воздушных систем. Однако в 2013 году федеральные авиационные правила приняли DO-178C как метод демонстрации соответствия лётной годности. Более общую информацию о стандартах DO-178B и DO-178C можно получить, прочитав эту статью.
Соответствие стандартам DO-178B или DO178C должно подтверждаться, среди прочего, следующими примерными документами.
- 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 должен включать сводку результатов квалификации инструментов верификации. О SAS должна быть проинформирована FAA. Это даёт сертифицирующему органу подтверждение результатов верификационных данных и служит свидетельством статуса квалификации инструмента. Нажмите здесь, чтобы ознакомиться с нашим документом SAS
Стандарты ARP4754 и стандарты DO178
ARP4754 расшифровывается как «Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems». Стандарты ARP4754 дают рекомендации для систем воздушного судна в целом, тогда как стандарты DO178 применяются только к полётному программному обеспечению. Оба стандарта признаны такими органами, как FAA и EASA.
ARP4754 был разработан и опубликован SAE (Society of Automotive Engineers) в 1996 году. В 2010 году SAE выпустило ARP4754A — Guidelines for Development of Civil Aircraft and Systems. ARP4754A обогащает концепцию гарантии проектирования на уровнях воздушного судна и системы, а также стандартизирует употребление термина «гарантия разработки». В ноябре 2011 года ARP4754 был одобрен FAA.
ARP4754 охватывает весь цикл разработки воздушного судна — от определения требований до завершения процессов интеграции и верификации. ARP4754 предлагает абстракцию для воздушных судов, систем и компонентов. В части проектирования компонентов он прямо ссылается на DO-178 и DO-254. ARP4754 сосредоточен на оценке безопасности через различные процессы: разработку, проектирование, верификацию. Следует, однако, учитывать, что ARP4754 не охватывает специфику разработки ПО и электронной аппаратуры, мероприятия по безопасности в эксплуатации и процесс разработки конструкции планера.
Этапы проектирования
Предварительное рассмотрение проекта (PDR)
Предварительное проектирование — важная фаза процесса разработки ПО. На ней определяются высокоуровневые требования и сценарии использования, формирующие архитектуру системы. В проектировании могут использоваться документы по интерфейсам, базам данных и архитектуре, а также диаграммы связей компонентов. Предварительный проект даёт наглядное представление о системе в начале работы на основе этих входных данных, закладывает основу для последующих, более детальных фаз и может рассматриваться как черновик.
Предварительное рассмотрение проекта (PDR) завершает фазу предварительного проектирования. PDR должно давать достаточную уверенность для перехода к детальному проектированию. Его цель — убедиться, что предварительный проект и базовая архитектура системы завершены и что есть техническая уверенность в выполнимости требований в рамках бюджета и графика.
Критическое рассмотрение проекта (CDR)
Критическое рассмотрение проекта (CDR) завершает фазу критического проектирования. На CDR окончательные решения представляются через развёрнутый анализ, моделирование, схемы, программный код и данные испытаний. CDR подтверждает, что система может переходить к испытаниям и производству, а требования выполнимы в рамках бюджета и сроков. Полученные исчерпывающие чертежи и спецификации образуют финальную базовую линию вместе с первоначальной базовой линией продукта. CDR должно быть широким по охвату и детальным.
Этап окончательного проектирования
Этап окончательного проектирования даёт детальные архитектурные и инженерные чертежи каждого компонента проекта. Для некоторых проектов может потребоваться отчёт об окончательном проекте. Выявленные проектные проблемы должны быть решены до завершения этапа. Чертежи и отчёты должны содержать достаточно деталей для плановых оценок. Отчёт должен включать обновлённый график, оценки затрат и спецификации. Необходимо также подтвердить экономическую целесообразность проекта. Изменения на этапе окончательного проектирования обходятся дороже, чем на других этапах, поэтому выполнять их следует крайне осмотрительно.
SOI (Stages of Involvement)
Для оценки соответствия проектов DO-178B авиационные власти соответствующих стран проводят оценки SOI на различных стадиях проекта: планировании, разработке, верификации. В идеале планируются четыре обзора SOI.
Первая оценка SOI охватывает планирование работ по сертификационному соответствию проекта. Второй обзор SOI сосредоточен на стадиях разработки: начиная с высокоуровневых требований к ПО, проверяется, созданы ли проект, низкоуровневые требования и исходный код в соответствии с DO178B. Третий обзор SOI посвящён верификации: рассматриваются не только испытания, но и все работы, выполняемые в целях верификации. Четвёртая SOI — завершающая оценка ближе к концу проекта: проверяется, не осталось ли незакрытых работ и не возникло ли новых проблем со времени предыдущих оценок.
Ожидание DO-178B от программных продуктов, создаваемых на стадии планирования, — согласовать общий свод правил между органом и исполняющей компанией и придерживаться его на протяжении всего проекта. Иначе говоря, при составлении планов и стандартов компания определяет не только собственные процессы, но и правила, по которым орган будет оценивать её в ходе сертификации.
Автор: Can Önal ([email protected])
