Model Based Design and HIL Simulations

Veiw figure View Figure

2. Model-Based Design Workflow

In a traditional workflow, requirements analysis and high-level design tradeoffs are often done on paper or with a basic tool such as Excel or using expensive prototype hardware. Algorithm implementation in C or Hardware Description Language (HDL) is done manually, as is the testing and verification. This process often requires several iterations between the algorithm design team and the C and HDL teams due to unclear requirements and design documentation or inherent design difficulties.

With Model-Based Design, system engineers use models to derive low-level requirements and then use the models to interface with customers and suppliers. They model the behaviour of digital, analogue, and RF components of the system and perform design tradeoffs in simulation, which can be difficult or impossible using paper-based design reviews. Algorithm developers can then reuse and elaborate the same models to build and test more detailed designs. Further in the development process, these models can become the design artefacts from which hardware engineers automatically generate HDL code. Then the system level models and tests can be reused as a test bench to validate the performance of the HDL implementation and the final hardware against the model level results. With Model-Based Design, models are re-used and elaborated at every development phase, reducing the amount of translation inefficiencies and errors in the process. With the model at the centre of the design process, design iterations are faster, design artefacts are automatically generated, and engineering teams have a common platform to share design ^[9].

Figure 2. Model-Based Design provides a multi-domain tool environment and integrates all phases of development [9]

Download as

Veiw figure View Figure

In generally, there are six steps to modeling any system:

• Defining the System

• Identifying System Components

• Modeling the System with Equations

• Building the model

• Running the Simulation

• Validating the Simulation Results

We perform the first three steps of this process outside of the software environment before we begin building our model. Mainly, these first three steps are important and many people make mistakes in these steps. Finally, when system is modeled through the equations, next building of the model is more or less routine operation. It is important to say that every model is not perfect and every time we have to neglect any points and simplify system description. Overall process requires the experiences. When we will try to make absolutely prefect model, very complicated model and slowly simulation will be as the result of them ^[5].

Defining of the system - the first step in modeling a dynamic system is to fully define the system. If we are modeling a large system that can be broken into parts, we should model each subcomponent on its own. Then, after building each component, we can integrate them into a complete model of the system.

Identifying System Components - the second step in the modeling process is to identify the system components. Three types of components define a system: parameters (system values that remain constant unless you change them), states (variables in the system that change over time), and signals (input and output values that change dynamically during a simulation).

Modeling the System with Equations - the third step in modeling a system is to formulate the mathematical equations that describe the system. For each subsystem, use the list of system components that we identified to describe the system mathematically. Model may include: algebraic equations, logical equations, differential equations, for continuous systems and difference equations, for discrete systems etc.

Building the Simulink Block Diagram - after we have defined the mathematical equations that describe each subsystem, we can begin building a block diagram of our model for example in MATLAB/Simulink. Build the block diagram for each of our subcomponents separately. After we have modeled each subcomponent, we can then integrate them into a complete model of the system.

Running the Simulation - after we build the Simulink block diagram, we can simulate the model and analyze the results. Simulink allows us to interactively define system inputs, simulate the model, and observe changes in behavior. This allows us to quickly evaluate your model.

Validating the Simulation Results - finally, we must validate that our model accurately represents the physical characteristics of the dynamic system. We can use the linearization and trimming tools available from the MATLAB command line, plus the many tools in MATLAB and its application toolboxes to analyze and validate our model ^{[5, 6, 7]}.

Figure 3. Early verification as part of Model-Based Design streamlines embedded control design with modeling, simulation, and automatic code generation [7]

Download as

Veiw figure View Figure

Model-Based Design with MATLAB and Simulink is an efficient and cost-effective way to develop complex embedded systems in aerospace, automotive, communications, and other industries. It enables system- and component-level design and simulation, automatic code generation, and continuous test and verification. ^{[5, 6]}.

Plant models provide another perspective on the system. Modeling the non-software parts of the system gives engineers another view into system behavior. Engineers can often learn more about system dynamics through simulation than from the real system because simulation provides details on force, torque, current, and other values that are difficult or impossible to measure on the actual hardware ^[7].

Creating plant models requires engineering effort, but this effort is often overestimated, while the value provided by plant modeling is underestimated. When developing plant models, it is a best practice to start at a high level of abstraction and add details as needed. Choosing a level of abstraction that is just detailed enough to produce the needed results saves modeling effort as well as simulation time (see Figure 2) ^{[5, 7]}.

System behavior is defined not only by the embedded control software, but also by the electronic and mechanical components, including the connected sensors and actuators. Early simulations in which the architecture is executed provide more insight when they are performed in a closed loop with plant or environment models. System-level optimization requires multi-domain simulations. It is impossible to optimize today’s sophisticated systems by tuning one parameter at a time. To deliver maximum energy efficiency and highest performance at minimal material cost, engineers must optimize the system as a whole, and not just the embedded software ^{[5, 6, 7]}.

3. Model Based Simulation Modes

There are different simulation modes Figure 5 for the model (model-in-the-loop (MIL) simulation), the host implementation (software-in-the-loop (SIL) simulation) and the target implementation (processor-in-the-loop (PIL) simulation) ^[2].

Figure 4. Simulation modes [2]

Download as

Veiw figure View Figure

These methods Figure 5 avoid work-intensive iterations in later development phases, and save time and money by:

• Verifying at an early stage, by means of model simulation, that the model and requirement are correct

• Verifying that the code and the mode are consistent, and that the code correctly represents the model’s functionality, by simulating the generated code on the host PC

• Verifying seamless traceability for documenting the software development

• Allowing resource requirements to be estimated at an early stage by simulating the code on the appropriate evaluation hardware ^[2].

4. Hardware-in-the-loop Simulation (HIL)

Not only is the number of electronic control units (ECUs) in modern vehicles constantly increasing, the software of the ECUs is also becoming more complex. Both make testing a central task within the development of automotive electronics. Testing ECUs in real vehicles is time-consuming and costly, and comes very late in the automotive development process. It is therefore increasingly being replaced by laboratory tests using hardware-in-the-loop (HIL) simulation Figure 5 ^{[10, 11]}.

Figure 5. (a) The Components Required for High-Speed Simulation of the Electric Machine (b) Typical architecture for Hardware-in-the-loop HIL simulations [10,11]

Download as

Veiw figure View Figure

Time to market is speeding up, especially in automotive electronics. 90% of automotive innovations are currently connected with new electronics. Test drives can scarcely cope with the volume of systematic testing needed, especially just before start of production. The growing number of recall campaigns is a clear indication of this. It is little wonder that testing and error finding have become key tasks in the development process.

ECU testing typically is done using hardware-in-the-loop simulation. The ECU (prototype) is connected to a real-time simulation system simulating the plant (engine, vehicle dynamics, transmission, etc.) or even the whole vehicle.

As HIL has become a standard method for testing ECUs and control strategies during the whole development cycle (i.e., not only after availability of the final ECUs), different needs of different users have to be addressed by the various test systems ^{[10, 11]}.

The dSPACE software components are standardized and can be integrated in any dSPACE simulator. The tight integration of dSPACE software and the modelling tool MATLAB®/Simulink® from The MathWorks provides a powerful development environment.

dSPACE Simulator’s graphical user interface provides a convenient and flexible environment. Simulated driving cycles, data acquisition, instrumentation, monitoring, test automation and all other tasks are executed graphically within dSPACE Simulator. The hardware requirements, however, vary immensely depending on the HIL application Figure 6. For example, function tests typically are executed with simulators that have a fixed (super)set of I/O, and adaptations to the ECU are most often made in the cable harness. In contrast, acceptance tests call for flexible and combinable simulator setups ^{[10, 11]}.

Figure 6. dSpace system for HIL simulation [5]

Download as

Veiw figure View Figure