Aircraft embedded control systems

design testing and software

Flight simulators are used by aircraft engineering teams to develop, integrate, and test aircraft subsystems such as flight controls, avionics, and cockpit displays.

Real-time simulation is used to test those components of aircraft flight that are difficult or costly to bring into a lab such as aerodynamics, six degrees-of-freedom motion, changing global position, and 70,000 lbs-thrust engines. The discovery of design and implementation flaws during simulated flight test is much more cost effective and imposes far less risk on the development program than flaws found during final flight test.

 In house real-time simulation systems have proved costly for the bigger aerospace and military applications and as new standard aerospace interfaces, such as ARINC-664, come along software needs to evolve.  The complexity and sophistication of today's platforms always increases and involves highly complex embedded systems.

The mark of highly effective embedded control systems software is collaborative design and integration during each design simulation and real-time simulation stage. The prime contractor and all the subsystem suppliers contribute simulation models for each simulation stage. Each member also contributes to simulation result analysis and adds particular expertise to the review.

Integrated and networked embedded systems aren't a challenge only for the aerospace and defence industries. Embedded processors are now used on motor cars.

Simulation-based design and development. 

The simulation process's preliminary design stage is similar to that of most other development processes. During preliminary design, the team defines high-level requirements for the system. These requirements may include system weight, range, speed, efficiency, and so on. Next the team breaks down the system into subsystems and specifies high-level requirements for each of those. Finally, they define the interfaces between subsystems. The preliminary design stage generates a high-level specification used to guide design efforts in the next stage of the process.

The second stage is simulation-based design. The goal of simulation-based design is to enable quick iterations between the mechanical design, the behavioural simulation, the control-systems design, and closed-loop simulation. First, solid models of mechanical component are developed using CAD tools. These solid models are then converted to behavioural models using behavioral-modelling tools.

New features of these modelling tools allow much of this conversion to be automated. Behavioural simulations assess the mechanical design. Finally, behaviour-simulation models are used for closed-loop simulation to assist control systems design and evaluation.

Simulation-based design requires a massive collaborative team effort involving mechanical designers, behavioural-simulation engineers, and control-system designers.

Team members share solid models, real-time models, and problem reports. Outputs from this stage of the process include solid models delivered to fabricators, real-time

models used in cosimulation and integration, and embedded control code used for early integration and delivered to embedded system suppliers. The tools used to help improve simulation-based design efficiency are evolving quickly.

The third stage, cosimulation, is a new animal for many aerospace companies. Program managers use a burden-rate calculation as a measure of the cost of using tools, machines, and facilities. A high burden rate suggests that the tool is expensive to operate. The real-time simulation computers used during early and late integration are very costly and therefore have a high burden-rate. The main purpose of cosimulation is to fully exercise all the subsystems and to validate embedded system code on a low burden rate platform (a Windows PC or Unix workstation) before prototype development or outsourcing begins.

The secondary purpose of cosimulation is to create a low-cost platform (typically a Windows or Unix workstation) for system-integration. This includes preparing models for real-time simulation and developing tests for reuse during the early and late stages of integration. The tools used for cosimulation should ideally be the same tools used in the two integration stages. Using the same tools for cosimulation and integration means the effort to configure cosimulation models, document interfaces, and create test scripts comes earlier in the development process and isn't duplicated in integration testing. The cosimulation tools must support the synchronous execution of models from numerous modelling languages.

Output from the cosimulation stage includes validated embedded system code delivered to the embedded system supplier, projects used for real-time simulation, and test scripts that will be reused during integration.

The fourth stage of the simulation process is early integration. Early integration is the first step into real-time simulation and is the first time embedded system code is executed in real time.

The fifth and final stage is late-integration testing. Once early integration is complete, the early integration facility is transformed, subsystem by subsystem, into the late integration facility. As subsystems arrive from suppliers and development teams they're scheduled as late-integration activities. Subsystems are added one at a time to isolate the source of any problems. Suppliers might schedule the delivery of several generations of prototypes over a period of perhaps a year. Early generations are modular and have easy access to circuits for probing.

Swappable daughterboards allow different microprocessors and sensor circuits to be accurately evaluated. Later-generation prototypes begin to look like the final production system. Circuits become more dense and harder to access. Cooling, structural rigidity, and vibration damping are all accounted for in the last generations.

The sources of many embedded software problems are modern cockpit displays and their interaction with avionics and other control computers. Test pilots will spend thousands of hours evaluating and testing complex controls and displays in the late-integration facility. Late-integration facilities are often very expensive because they include millions of dollars of prototype equipment.

The down side to all this is that many aerospace and defence companies are beginning to feel they've lost control of their embedded systems. For example, the vast majority of new features added to an aircraft are implemented in an embedded system rather than through advancements in mechanical design or construction materials. Avionics computers are an aircraft's brain and so, all new embedded systems in an aircraft will touch the avionics computer. Many aircraft manufacturers outsource the complete avionics computer system. As a result, they are at the mercy of its avionics supplier to provide new features in a timely and reliable manner. As more and more of the cost of an aircraft is in the embedded systems, the aircraft integrator has control over less and less of its own product.

Many aerospace OEMs are realizing they are in the business of software development and are using the simulation to regain control of their embedded systems. By embracing model-based control-systems development, OEMs are able to keep application knowledge in-house. Communication is improved and the blame game is eliminated by getting the responsible technical experts in one test facility at the same time and completing a single test matrix. As problems are found, they're characterized and isolated. Once bugs are isolated the owner is identified. Iterations are made, embedded software bugs are eliminated, and development programs are a success.