Overcoming DAL-D Development Pitfalls with Modular Avionics COTS

Modern aircraft developments place huge demands on avionics designers as multiple subsystems are developed in parallel without full knowledge of how they will eventually interact. As manufacturers of flight data recorders, Curtiss-Wright was subcontracted to provide a crash-protected recorder that would interface to the DMU (data management unit) of a new mid-range commercial airliner. The original DMU development plan was aborted twelve months into the development phase, and Curtiss-Wright was asked to take over the DMU development, with the caveat that the original delivery schedule still be achieved. 

In addition to needing compressed development time, the OEM needed early prototypes of the DMU, to allow for design validation and verification with other sub-system interfaces. Due to the parallel development of multiple subsystems, there was an awareness from the outset that specifications of interfacing sub-systems would not be 100% complete before design of the DMU commenced. This was an indeterminate risk that needed to be managed and adapted to by Curtiss-Wright. 

Curtiss-Wright took ownership of the DAL-D DMU development and achieved the schedule recovery required to keep the avionics program on track. The rapid prototyping of the DMU significantly reduced program risk, moving very quickly beyond a "design-on-paper" to a testable solution.

Specification changes anticipated at the program outset manifested themselves as three major alterations to the DMU during the design phase. By purposely avoiding a monolithic design, these changes were easily accommodated by the modular avionics COTS architecture.

• Specification for the DMU output format changed 6 months prior to agreed delivery from an ARINC-664 part 7 packet format to an ARINC-717 format. Accommodating this change allowed the removal of switching circuitry and reduced avionics chipset recurring costs by ~$40K per chipset.
• The ACMS routine was removed from the DMU requirement when it was recognized that similar functionality already existed in EMU (engine monitoring unit). The easy removal of this interface allowed for recurring cost reduction of 6%.
• Several interface specifications (e.g. OMS routines) were incomplete at the beginning of design phase. Natural hardware partitioning and streamlining of the verification process allowed fully defined modules to be tested without delay, with other modules being scheduled later in the verification cycle. 

Download the case study to learn more.