RTCA DO-254, «Design Assurance Guidance For Airborne Electronic Hardware», — основное руководство по производству авиационной электроники; его последняя версия опубликована в 2000 году. RTCA DO-254 задаёт требования к жизненному циклу проектирования систем авионики и содержит указания по лётной годности бортовой электроники. DO-254, как и DO-178, выпущен в сотрудничестве RTCA и EUROCAE. FAA официально приняла DO-254 в 2005 году в ответ на расширяющееся применение разнообразной электроники в авиации.
Соответствие DO-254 помогает повысить безопасность пассажиров, экипажа и эксплуатантов и укрепляет вашу организацию. К тому же, поскольку некоторые проекты требуют соответствия DO-254, оно даёт вашей компании конкурентное преимущество перед производителями и разработчиками, которые его не обеспечивают.
Основные процессы сертификации DO-254 можно кратко представить так:
- Процесс планирования
- Процесс разработки
- Процесс верификации
Процесс разработки должен начинаться после завершения процесса планирования, а процесс верификации — вестись от начала и до конца проекта.
Требования DO-254 должны подтверждаться, среди прочего, следующими документами:
- PHAC (Plan for Hardware Aspects of Certification)
- HVP (Hardware Verification Plan)
- HVP (Hardware Validation Plan)
- HPAP (Hardware Process Assurance Plan)
- HAS (Hardware Accomplishment Summary)
Некоторые документы DO-178 похожи на документы DO-254. Ознакомиться с нашими документами DO-178 и приобрести их можно здесь.
Документы DO254
PHAC
PHAC (Plan for Hardware Aspects of Certification) должен быть подготовлен в ходе процесса планирования и одобрен сертифицирующим органом. PHAC отражает соглашение между заявителем и сертифицирующим органом о процедурах и действиях, которые предстоит выполнить, а также о создаваемых в результате свидетельствах для выполнения аппаратных аспектов сертификации. В этом плане разработчик описывает свою стратегию и то, как применяется DO-254. Нажмите здесь, чтобы ознакомиться с нашим документом PHAC.
Hardware Verification & Validation Plan
Hardware Verification Plan проверяет, отвечает ли аппаратура проектным требованиям. Hardware Validation Plan, в свою очередь, служит для проверки того, отвечает ли аппаратура эксплуатационным и функциональным требованиям пользователя. Как следует из определений, принципиальное различие между верификацией и валидацией — среда, в которой проводятся испытания. В процессе верификации корректность конструкции проверяется относительно проектных требований; в процессе валидации — относительно требований целевого пользователя. Эти документы также готовятся в рамках процесса планирования.
HPAP
HPAP (Hardware Process Assurance Plan) проверяет, определены ли процессы и данные жизненного цикла проектирования аппаратуры и соответствуют ли они утверждённым планам. Сертифицирующему органу предлагаются методы достижения целей гарантии проектирования аппаратуры, включая выбранные стратегии. Нажмите здесь, чтобы ознакомиться с нашим документом HPAP.
HAS
HAS (Hardware Accomplishment Summary) информирует сертифицирующий орган о том, что сделано по аппаратной части. Различие между PHAC и HAS в том, что PHAC сообщает органу, что вы планируете сделать, а HAS — что вы сделали фактически. HAS также должен указывать отклонения от утверждённого PHAC. HAS должен включать идентификацию аппаратуры, её статус, историю версий и заявление о соответствии. Он аналогичен документу Software Accomplishment Summary, используемому для соответствия DO-178. HAS должен содержать разделы об обзоре системы и аппаратуры, описании жизненного цикла проектирования и данных жизненного цикла аппаратуры. Нажмите здесь, чтобы ознакомиться с нашим документом HAS.
Этапы проектирования
Этап предварительного проектирования
Этап предварительного проектирования начинается с функциональной базовой линии, созданной при концептуальном проектировании, и продолжается преобразованием функциональных потребностей уровня системы в проектные требования к подсистемам, из которых будет собрана система. Это преобразование требует продолжения анализа требований, начатого на этапе концепции. Должны быть определены потребности системы в аппаратуре, программном обеспечении и персонале. Проводятся анализы выгод и рисков, и итогом предварительного проектирования становится распределённая базовая линия, в которой потребности закреплены за отдельными подсистемами.
Этап критического проектирования
Этап критического проектирования — междисциплинарный технический процесс, гарантирующий, что система может перейти к производству, демонстрации и испытаниям, отвечая заданным критериям качества в рамках ограничений по стоимости, срокам и рискам. На этом этапе закладывается базовая линия продукта. Цель критического проектирования — оценить окончательную конструкцию системы, как она определена в спецификациях продукта для каждой конфигурационной единицы базовой линии, и удостовериться, что каждая конфигурационная единица отражена в документах детального проектирования.
Этап завершается проведением критического рассмотрения проекта. CDR подтверждает, что система может переходить к испытаниям и производству, а требования выполнимы в рамках бюджета и графика. Полученные исчерпывающие чертежи и спецификации образуют финальную базовую линию вместе с первоначальной базовой линией продукта. CDR должно быть тщательным и всеобъемлющим.
Этап окончательного проектирования
Этап окончательного проектирования включает точные архитектурные и технические чертежи каждого компонента проекта. Для некоторых проектов важно подготовить отчёт об окончательном проекте. До завершения этапа должны быть решены все выявленные проектные проблемы. Чертежи и отчёты должны быть достаточно детальны, чтобы задавать сроки. В отчёт следует включить уточнённый график, оценки затрат и требования. Необходимо также подтвердить финансовую состоятельность проекта. Любые изменения на этапе окончательного проектирования обходятся дороже, чем на предыдущих этапах, поэтому вносить их нужно с большой осторожностью.
Автор: Can Önal ([email protected])
