Model-driven development forestalls “11th hour” design problems

The development of a large-scale system or mil/aero platform, be it consumer minivan or combat helicopter, is a long-term project fraught with complexity. The penalties for a miscalculation often manifest as cost overruns, schedule delays, reliability problems, and even dangerous product failures. Every engineer and manager worries about risks like these and takes measures to avoid them.

But even in a disciplined and rigorous program, critical issues may not become apparent until the “11^th hour” of a project’s life cycle. Moreover, certain realities in today’s mil/aero development ecosystem are making it even more challenging to achieve consistent quality and cost-effectiveness throughout the development life cycle, particularly at the time of system integration.

As systems become more complex, contractors who once specialized in narrow technical areas are being forced to act as systems integrators and in turn, are contracting subsystems to a global network of subcontractors. It adds up to significant potential for misunderstandings, errors, and omissions due to communication challenges across language and cultural boundaries.

New technology options add further complications and require diversified skills from system developers. Designers must deal with embedded software, electronic control units (ECUs), electro-mechanical subsystems (mechatronics), and the networks through which they communicate. And of course, the complexity of the wiring systems (harnesses) that connect all these elements has multiplied accordingly.

Yet another factor is compliance with DO-254 and other aviation standards and regulatory mandates as well as modeling-related recommended practices in ARP4761. The purpose of DO-254 is to ensure that airborne electronics perform their intended function under all foreseeable conditions. DO-254 oversees design assurance for in-flight hardware, and its full implementation will affect every level of electronic hardware: system, LRU, board, and device. ARP4761 covers a different but relevant discipline: modeling and its use in assessing the safety of an aircraft or other system. While neither document explicitly increases the complexity of the end product, they may complicate the design process.

An ideal solution would have teams of experts working independently throughout the technical, system, and process levels, with designers concentrating on their specific tasks using the best available tools. Ideas would be tested using software modeling techniques and, once proven, would pass from step to step in the process. Monitoring of compliance with regulatory standards would be integral to every step. Ultimately all the pieces would be efficiently integrated into a system that works. It is this vision that gave rise to innovative model-driven development (MDD) tools and processes that are fast gaining favor among system developers. MDD lays the groundwork for an integrated design flow that addresses the complexity challenge once and for all.

System integration challenges increase in proportion to complexity

A typical aerospace platform is a complex hierarchy of subsystems and components that includes multiple development programs. To summarize these programs in general terms:

1.      Dedicated IC devices are developed and assembled with other components to create printed circuit board-based functions.

2.      Software is integrated with these functions to create stand-alone electrical subsystems.

3.      The subsystems are assembled into complete electrical systems supporting unique platform capabilities, such as power distribution, flight control, and braking.

4.      Compatibility, communication, and integrated operation are established between these complete systems.

5.      Finally, the systems are brought together into a functioning, producible, maintainable, and highly reliable platform.

Most programs begin with a concept development and refinement phase, after which the system requirements and constraints are defined and reviewed. The system is then functionally and physically partitioned into subsystems and components and the requirements for the interfaces between these elements are allocated and specified. With these definitions completed, engineers create a preliminary design of each subsystem or component to validate the approach. Then they proceed with a detailed design phase in which the engineers refine the subsystem and component designs to the point where it appears they will meet performance requirements and are specified sufficiently to be built.

At this point, the system integration process begins. Subsystems and components must be built and assembled into a system prototype; this is tested and debugged prior to being demonstrated to the customer. Once the customer accepts the prototype, a production readiness program is initiated and the system is released to production, after which it can be operationally deployed.

Perhaps system integration sounds like an elaborate and costly process. In fact, it is, and it can be a bottleneck. Bringing subsystems and components together into a single system is trouble-prone and unpredictable. Problems encountered at this point in the program may require a subsystem or component redesign, or possibly even refinement of the system requirements. As the yellow arrows in Figure 1 imply, a flaw detected late in process can send the project back to “Square One.” Repeated iterations through the earlier stages of the design cycle significantly delay a project.

Historically, rigorous testing and verification have not taken place until the second half of the product life cycle. Components and subsystems are first tested individually and then integrated into a system which then undergoes architectural, functional, and requirements verification. However, when system integration and verification is postponed until subsystems are physically produced and ready for assembly, the risk for costly rework and delays goes up dramatically.

Figure 1: A traditional system development life cycle

Problems found during systems integration are very expensive to fix because time, effort, and money have already been committed to detailed design and production tooling. Equally important, a project that is behind schedule and over budget can damage credibility with the customer and impact long-term business relationships.