Developing Models for Real-Time Simulators Using MATLAB and Simulink

Developing Models for Real-Time Simulators Using MATLAB and Simulink


by Christian D. Bodemann
Vega IT GmbH

Note: This article is adapted from “Funktions-orientierte Modellentwicklung für Echtzeit-Simulatoren mit Hilfe von MATLAB/Simulink,” which appeared in the January 2004 issue of MATLAB Select, the MathWorks German-language print publication.
Simulation is increasingly being used in aerospace development to define systems; validate hardware and flight software designs and operating procedures; and to train operators for mission deployment. At the heart of the simulator is a model of the system. Models can be used to simulate hardware and software functions and environmental influences. This article describes how the Automated Transfer Vehicle (ATV) developers used MATLAB and Simulink with Model-Based Design to develop platform- and simulator-independent numerical models that could be applied and reused in every stage of the project's development. The resulting modeling and simulation framework proved to be reusable for many other projects.
ATV Program

The ATV program was launched by the European Space Agency (ESA) in October 1995 to develop a service and logistics spacecraft for regular resupply missions to the International Space Station (ISS). The ATV will be used to refuel the ISS; supply the ISS with compressed air, water, and pressurized cargo; reboost the ISS to offset height loss due to friction; and eliminate ISS waste materials.
A team comprising EADS Launch Vehicles, DATASPAZIO SPA, and VEGA IT GmbH, based at EADS Launch Vehicles in Les Mureaux, developed the numerical models for the ATV test bench simulators. The team selected MATLAB and Simulink to develop models for the specification, design, and programming of the simulators. They used Simulink diagrams in technical specifications and in the architectural design document. Real-Time Workshop was used to generate the code, which was successfully integrated with EuroSim, a hard real-time simulation framework for multiprocessor environments.
Space Project Development

The development lifecycle of most space applications differs from that of other technical applications in that it does not include maintenance and repair. However, the technical requirements and service life of most spacecraft, such as telecommunications satellites and space probes, must meet more stringent expectations. The intense environmental influences to which spacecraft are exposed increase the demand for technical reliability. To meet these reliability requirements, engineers use simulators at all stages of development.
Figure 1. Stages in the development of a spacecraft component. Click on image to see enlarged view.
Figure 1 shows the five phases in the development life cycle of a space application, including:

• Specification—Components are analyzed in terms of quality and service life, primary physical properties, and load limits. This analysis data is fed into the requirement profile to develop the component specification.
• Design—The requirement profile is transformed into a component at a technical level. The requirements are joined by functional properties such as operating states, measured data input, and component control.
• Validation—The hardware functions and the onboard software are tested.
• Service—Simulators are used to train operators to handle the spacecraft, which is then deployed.
• Secondary service—The mission profile and onboard software are modified.

Engineers simulate and test all developments and modifications using the simulators from the preceding phases.
Simulators for Validation

Validation involves integrating the onboard software with the entire system environment (hardware-in-the-loop).
Throughout the development process, the ATV developers used a wide range of non-real-time and real-time simulators based on numerical models to validate the specification, verify the flight software functionality, and validate completed ATV functionality. The engineers used models to simulate factors such as the effects of internal and external influences on the vehicle's dynamic behavior and then fed the results into simulated real-time equipment. Other models simulated the behavior of external systems with an interface to the vehicle, such as GPS, constellation, and the ISS. Some models served as part of a hardware-in-the-loop simulation, replacing technical modules missing from the real test model, or modules that provided stimuli to the real equipment for testing the flight software.
Numerical models can be avionics models or physical models. For example, the ATV project includes external interface models, such as the Ariane 5 interface model, and equipment models such as the propulsion, power supply, and communications models.
Model Development

The classic V-diagram in Figure 2 shows the tasks in the development cycle and which tools were used at each stage.
The ATV team selected the following tools:

• Simulink—Numerical model specification and design; in the programming phase, and during model validation on the host
• Real-Time Workshop—ANSI C code generation
• Mosaic—Model integration in EuroSim
• EuroSim—Simulator design, real-time integration of the numerical models, and complete simulation software validation

Figure 2. Tools used in the development cycle of the simulation software. Click on image to see enlarged view.
Development Strategy

The ATV team conducted a five-phase development process, which is described in the following sections:

• Technical requirements specification
• Architecture specification
• Implementation
• Model validation
• Simulator integration and validation

Requirements Specification

During the initial definition phase, engineers create schemes of the functional structure of the hardware and onboard software. The graphics-based programming in Simulink enables these schemes to be used as a guide for a function-oriented approach to model development. As a result, the functional structure of the model is directly reflected in the eventual structure of the hardware.
The ATV developers used Simulink to generate block diagrams that subdivided functionality into functional libraries, some based on diagrams of the actual equipment. This approach facilitates reading and understanding the specification of the model requirements while maintaining a low level of abstraction between the model and the actual hardware and software. The Simulink diagrams were used in the requirements document to represent the requirements.
Figure 3 shows the level of detail available to the diagrams in the specification phase.
Figure 3. Technical specification of the propulsion subsystem in a Simulink model, broken down into its principal components, including a representation of the necessary signal flows. The requirements describe the functionality expected of the subsystem. Click on image to see enlarged view.
Architecture Specification

To develop the model architecture specification, the team subdivided the technical specification representation into functional subsystems and blocks based on the Simulink diagrams from the software requirements phase. Simulink blocks used in the technical specification were further developed in terms of their functional requirements. To document the architecture specification, the Simulink blocks' inputs, outputs, and functionality were described.
Using Simulink, the graphical schemes describing the model and generated for the technical specification were reused in the architectural design document (ADD). The ADD described the ATV's internal interfaces and the interfaces with external models. Because the Simulink diagram was used as a guide for programming, all interfaces were already identified and defined in the diagram. Different developers could then easily integrate their models into the project.
Implementation

Simulink blocks were used to create custom blocks to implement functionality. Custom models were used to create a model library, from which they were integrated into the diagrams and models. Figure 4 shows an example of a custom model.
Figure 4. Breakdown of the propulsion subsystem into custom blocks. Click on image to see enlarged view.
The custom model library for propulsion contained models for the propellant valve, check valve, sensor, propelling nozzle valve, and pressure regulator. All these models could be controlled by the simulator, by the actual propulsion electronics (hardware-in-the-loop), or by user-entered commands. The models were kept as generic as possible so that they could be reused. For example, the model of the propellant valve could be modified to serve as a model for an electric switch or a thermal knife. The specification phase produced a large number of Fortran or C models for non-real-time simulators, such as the Fortran model for propellant consumption, which were encapsulated into Simulink blocks for reuse in the real-time simulator.
This library-based, function-oriented approach using Simulink offers several advantages:

• If the hardware functionality changes, it is easy to update the model in the library. The updated model is then executed automatically.
• It is easy to identify a specific block for maintenance purposes.
• New engineers who are familiar with the actual hardware architecture can understand the function and architecture of the model.
• Model libraries can be reused.

Validation

The team used a bottom-up approach, validating the numerical ATV models once the functionality had been implemented in the diagrams.
Within the Simulink environment, validation involves three phases:

• Module tests—A test environment is created and executed in Simulink. The Simulink Report Generator can be used to quickly generate and store the test automatically so that only validated modules are then integrated.
• Integration tests—Once the individual modules have been tested, they are integrated into the larger subsystems. Installing the subsystems in the test environment tests integration. Because the functionality of the module has already been verified, these tests validate only the correct integration with the subsystem. The final integration test constitutes the test of the overall model.
• Subsystem tests—If the model comprises a number of different models, the subsystem is checked in a system test.

Simulator Integration and Validation

Following the final integration test in Simulink, the team used Real-Time Workshop to generate the C code, and Mosaic to prepare the generated code for integration with EuroSim. After integration, the final test was repeated in EuroSim and the test results were compared.
Summary

Using Model-Based Design with MATLAB and Simulink, the ATV team developed a function-oriented design methodology that provides virtually all the capabilities of a classical, object-oriented approach and the following additional benefits:

• The graphical representation provided a link between the model and the actual hardware, easing communication between the model developers and end users.
• Using Simulink at all stages of the project kept the involvement of other programming languages and techniques to a minimum. As a result, new team members could be integrated more easily, efficiently, and economically.
• The diagrams of the technical specification and the ADD represented program code, helping to preserve an overview of the development process.
• Interfaces clearly defined in the ADD helped to avoid integration problems.
• The Report Generator in MATLAB and Simulink shortened the time needed to document the test results.
• The underlying development methodology ensured that the test framework could be reused with a common test scheduler, reducing the resources needed for testing. Visualization of the test results guaranteed high quality.
• Library-based development of the Simulink models enabled program code to be reused in other projects.

Because all models were completed on schedule and with few errors, the ATV project was considered a success.


更多...