Model-based design links multiple domains

The increasing complexity and fast pace of innovation involved in today’s design processes places a premium on understanding the interplay between various design domains at an early phase in the design process. Many manufacturers of complex products are using model-based design for a graphical, hierarchical development approach that initially defines an entire design at a conceptual level...

By Paul Barnard November 1, 2006

The increasing complexity and fast pace of innovation involved in today’s design processes places a premium on understanding the interplay between various design domains at an early phase in the design process. Many manufacturers of complex products are using model-based design for a graphical, hierarchical development approach that initially defines an entire design at a conceptual level, then adds functional detail as needed.

Preconfigured component models can be used to represent design elements and simulate performance. As the design process continues, the model can be expanded to address more detailed decisions.

A model for an aerospace vehicle that uses an automated flight control system during the approach and landing phase illustrates these concepts. The system includes models of the following dynamics and behavior:

Aerodynamic effects;

Environment models;

Control surface actuators;

Landing gear ground forces;

Guidance, navigation, and control (GNC); and

Fault detection, isolation, and recovery.

The traditional approach to developing complex control systems involves first writing text-based specifications that define requirements for the control systems in as much detail as possible. These specifications are passed to control engineers who design a control strategy that is then usually implemented in C code. To run simulations of the aircraft, they include equations of motion and other plant dynamics implemented in Fortran or C code.

A major problem with this approach is that it’s very difficult to detect mistakes in hand-written code, especially during the early phases of the development effort. Additionally, many teams, such as those involved in designing GNC, aerodynamics, and flight controls, will each create their own code, which must later be integrated into the complete model and may only be meaningful to the person who wrote it.

Model-based design can improve the control/design process by providing an environment for developing an executable specification that incorporates the key elements of the control logic, and mechanical and electronic designs. This can be accomplished by embedding test cases designed to verify each of the requirements in the model. These test cases can easily be exercised each time the model is verified to quickly identify its performance in compared to specifications.

Navigation links are constructed between test cases and requirements documents that point to each other, making it easy to compare requirements to the design and vice versa.

Graphics reduce ambiguity

Embedding the specification in a graphical design model eliminates the risk of ambiguity and miscommunications when handing over from specification definition to control design. Rather than being coded line-by-line, the model can be defined and elaborated by selecting blocks that specify control-system component models, 6 degrees-of-freedom (6DoF) dynamic models, environmental models, and whatever other design elements are needed. Engineers can then simulate the design and graphically evaluate its performance at any stage of the process.

After viewing the simulation results, the designer can quickly make changes by adding, subtracting, or moving blocks, or tuning parameters within blocks, and then immediately assess these changes’ impacts.

The model generates C code that can run on the target control module or a prototype controller. The plant model can be ported to a real-time simulation device with I/O ports to emulate the physical-plant I/O connections.

The control module can then be connected to the simulated plant and the same test routines can be run in a hardware-in-the-loop simulation to verify that the addition of real-time constraints has not uncovered any design flaws. As real hardware becomes available, it can be connected to the control module to replace parts of the plant model.

Dynamic links

A complete flight control system was developed and simulated using a model design based on the HL-20 lifting body. The airframe subsystem for the HL-20, which serves as the plant model that guides control system development, consists of five components:

The 6DoF (Euler angles) subsystem is so-named because it is constructed from blocks that each provide the three translation and three rotational axes needed to fully describe airframe motion. During the simulation, forces and torques are applied to the 6DoF blocks based on the aerodynamic, drag, and gravity forces determined by the alpha, beta, and mach subsystems. The 6DoF blocks themselves calculate acceleration, which in turn can be integrated to determine airframe velocity and position.

A complete mechanical model with linkages can also be created using mechanical simulation blocks, account for changes in mass, inertia, and geometry of the airframe. The 6DoF blocks contain the governing equations needed to simulate the flight dynamics. The 6DoF subsystem computes the Mach number, incidence angles, total velocity, and dynamic pressure. The aerodynamic data contained in this subsystem was gathered from wind tunnel testing of scaled models of the HL-20. The data was curve fitted and most of the aerodynamic coefficients are described as polynomial functions of angle of attack and sideslip angle.

The datum coefficients subsystem calculates coefficients for the basic configuration without control-surface deflection. Lookup tables determine incremental changes to the coefficients that reflect control-surface deflections in the actuator increment subsystem. Available control surfaces include symmetric wing flaps (elevator), differential wing flaps (ailerons), positive body flaps, negative body flaps, differential body flaps, and an all-movable rudder. Summing the datum coefficients, body rate damping, and actuator increments subsystem outputs generates the six aerodynamic coefficients used to calculate airframe forces and moments.

The forces and moments subsystem calculates the body forces and body moments around the center of gravity based on aerodynamic coefficients, thrust, dynamic pressure, and reference airframe parameters. The environmental model subsystem contains the World Geodetic System model of 1984 for gravity, the Committee of Extension to the Standard Atmosphere model for atmosphere and wind shear, Dryden turbulence, and discrete gust wind models.

Fault detection, gain scheduling

The flight control subsystem maintains the aircraft on the glide slope while bringing it in for a landing. The control logic includes fault detection, isolation, and recovery (FDIR) logic modeled with several finite state machines with states, transitions, and truth-tables forming the system building blocks. The control logic was created by dragging states, junctions, and functions into a graphical design tool and creating transitions and flow by connecting states and junctions together.

The flight controller accepts information from the navigation system and instruments and trims control surfaces to keep the aircraft on its glide path. It uses linear algorithms that provide a good approximation of the nonlinear flight control problem within specific operating ranges. The flight control systems provide a nonlinear control strategy by interpolating between different linear controllers (in a process called gain scheduling) based on the aircraft’s operating conditions.

To provide redundancy, the flight control system runs on three independent and identical processors whose outputs are intercompared prior to every decision. If one processor’s output does not match those of the others, then its results are thrown away. The FDIR block reacts to simulated failures of the position sensors used to determine position of control surface actuators and the hydraulic systems. Failures are counteracted by switching to backup systems. It is important to note that the ability to simulate the whole model enables failure-mode analysis of the safety-critical components, such as redundant sensors and actuators.

Flight simulator connection

The benefits of model-based design become readily apparent when the model is connected to a software flight simulator. The model provides the vehicle dynamics, control guidance, and environmental models, while the flight simulator serves up the graphics. In contrast, when using conventional development methods, the ability to simulate control-system operation would not arise until much later in the design process—typically after prototype hardware delivery.

The flight control system brings the HL-20 in for a smooth landing on the flight simulator, interpolating smoothly between control algorithms in response to changes in the environment. The user can easily evaluate the control system’s performance as it reacts to various simulated component failures.

For example, the control system reacts smoothly to the failure of one hydraulic system, recovering without any noticeable change in the glide path. Failing both the primary and backup hydraulic systems, on the other hand, causes a catastrophic failure as the control surfaces are no longer powered. Engineers can also use the model to automatically generate code for the target processor and run hardware-in-the-loop simulation while connected to a full flight simulator. This makes it possible to evaluate the impact of the chosen hardware solution on control system performance.

By using model-based design, engineers can evaluate alternatives and correct problems earlier in the design process, reducing the time and cost required for development, and enabling performance to be optimized to a degree that would otherwise not be possible.

Author Information

Paul Barnard, marketing director for control design, The MathWorks,