ru
Contact US
ru
DO Standards

Сертификация RTCA DO-254 и Процессы и Этапы Проектирования

RTCA DO-254, «Design Assurance Guidance For Airborne Electronic Hardware» (Руководство по обеспечению качества конструкции для бортового электронного оборудования), является основным руководством для производства бортового электронного оборудования, последняя версия которого была опубликована в 2000 году. RTCA DO-254 определяет требования к жизненному циклу проектирования для авионных систем и предоставляет рекомендации по летной годности электронного оборудования самолетов. DO-254, как и DO-178, также был выпущен в сотрудничестве с RTCA и EUROCAE. DO-254, в 2005 году, был официально принят FAA в ответ на возрастающее использование различного электронного оборудования в бортовых системах.

Соответствие DO-254 помогает улучшить безопасность пассажиров, экипажа и оператора, укрепляет ваш бизнес. Более того, это обеспечивает вашей компании конкурентное преимущество, поскольку некоторые проекты требуют соответствия DO-254, и у вас будет преимущество перед другими производителями и разработчиками, которые его не предоставляют.

Основные процессы для сертификации DO-254 можно резюмировать как

  1. Процесс планирования — Planning Process
  2. Процесс разработки — Development Process
  3. Процесс проверки правильности — Correctness Process

Важно заметить, что процесс разработки должен начаться после завершения процесса планирования, тогда как процесс проверки правильности должен проводиться на протяжении всего проекта.

Стандартам 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-254 могут напоминать документы DO-178. Наши чек-листы DO-178 доступны для просмотра и покупки здесь.

Документы DO254

PHAC

PHAC (Plan for Hardware Aspects of Certification) должен быть создан в процессе планирования и получить одобрение от органа сертификации. PHAC отражает соглашение между заявителем на сертификацию и сертификационным органом о процедурах и действиях, которые должны быть выполнены, а также о результатах, которые должны быть сгенерированы для выполнения аппаратных аспектов сертификации. В контексте этого плана разработчик описывает свою стратегию и как реализуется DO-254. Чтобы проверить наш документ PHAC, пожалуйста, нажмите здесь.

План Верификации и Валидации Аппаратного Обеспечения — Hardware Verification & 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, пожалуйста, нажмите здесь.

Этапы Проектирования

Предварительная Фаза Проектирования — Preliminary Design Phase

Предварительное проектирование начинается с установления функциональной базы во время концептуального проектирования и продвигается к работе по переводу системных функциональных потребностей в требования к проектированию для подсистем, которые будут объединены для формирования системы. Этот перевод требует продолжения анализа требований, начатого на концептуальном этапе. Должны быть определены конкретные потребности аппаратного обеспечения, программного обеспечения и персонала системы. Выполняются анализы компромиссов, и результаты предварительного проектирования приводят к созданию распределенной базы, в которой потребности назначаются отдельным подсистемам, составляющим систему.

Критическая Фаза Проектирования — Critical Design Phase

Критическая фаза проектирования — это многодисциплинарный технический процесс, который гарантирует, что система может перейти к производству, демонстрации и тестированию, соответствуя заявленным критериям производительности в рамках ограничений по стоимости, времени и риску. Базовая линия продукта инициализируется на критической фазе проектирования. Цель критического проектирования заключается в оценке окончательного дизайна системы, как определено в спецификациях продукта для каждого элемента конфигурации в базовой линии продукта системы, и в подтверждении, что каждый элемент конфигурации был включен в детальную документацию проектирования.

Критическая фаза проектирования завершается проведением Критического Обзора Проекта (CDR). CDR гарантирует, что система может перейти к тестированию и производству. Также подтверждается, что упомянутые требования могут быть выполнены в рамках бюджета и графика. Появившиеся комплексные чертежи и спецификации обеспечивают первоначальную базовую линию продукта с окончательной базовой линией. CDR должен быть тщательным и исчерпывающим.

Финальная Фаза Проектирования — Final Design Phase

Финальная Фаза Проектирования включает точные архитектурные и технические чертежи каждого компонента проекта. Для некоторых проектов может быть важно создать итоговый отчет по дизайну. Перед завершением финального процесса проектирования необходимо решить все обнаруженные проблемы дизайна. Чертежи и отчет должны быть достаточно детализированы, чтобы обеспечить относительно точные оценки стоимости строительства и эксплуатации, а также сроки строительства. В итоговом отчете по дизайну должны быть включены пересмотренный график, оценки стоимости и требования. Также должно быть утверждено, что проект экономически целесообразен. Любые изменения, внесенные на этапе Финального Проектирования, обходятся дороже, чем на предыдущих этапах. Следовательно, это должно быть выполнено с большим вниманием.

Can Önal ([email protected])

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from - Youtube
Vimeo
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Spotify
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound

For a Second Chance

Cart Overview