Model-Based Design of Multi-Physics Automotive Systems
Today’s vehicles epitomize the concept of multi-physics systems. Design teams are bringing together software and electronics, along with airflow and environmental sensors, mechatronic, hydraulic and pneumatic subsystems, to create increasingly sophisticated automotive systems.
Traditionally, the automotive industry has made extensive use of “downstream” engineering. Design teams have followed the traditional “V-cycle”, which splits the engineering process into two phases — design and implementation followed by validation.
While design teams can benefit significantly from earlier validation of their concepts, the industry has historically favored physical prototyping as a means of validating the design, which requires a commitment to build a hardware prototype early in the project lifecycle.
This is often followed by a sequence of reworking, patching and more prototyping. Design teams pursue this cycle until the design appears to be bug-free. Unfortunately, such a downstream approach to engineering can lead to periods of prolonged patch fixing while engineers chase their tails and lose production cycles. If we cannot fix the design by patching, it may require a complete re-design. In the worst case, we may not discover the problem until the vehicle is in production, which can lead to disastrous product recalls.
Upfront Engineering
While simulation doesn’t remove the need for physical prototyping, it does considerably reduce the number of prototyping cycles that we need to go through during a project. By spending more time upfront with the design, we avoid many of the downstream problems.
Simulation enables us to learn more about the system and understand how it works. Because simulation models give us better visibility into the way our designs work conceptually, we can get rid of bugs — hopefully before we build them into the prototype. An additional benefit is the ability for new team members to get up to speed with the design by experimenting with the simulation, which doesn’t risk causing damage to (expensive) physical prototypes.
Cyber-Physical Systems
A model-based cyber-physical systems (CPSs) (Figure 1) development approach enables design teams to integrate physical processes with computational systems during simulation. These virtual CPSs support abstractions appropriate for modeling and design, and analysis techniques suitable for integrated systems.
Figure 1: Simplified block diagram of cyber-physical system (CPS) showing close integration between physical systems (plant) and computational systems (ECU — electronic control unit)
The mechatronic control systems that are implemented in automotive applications include those used for engine control, transmission control, throttle control and braking. These typically involve multiple complex physical systems with dedicated embedded controllers that communicate with each other via a vehicle network, such as Controller Area Network (CAN) or FlexRay.
We have adopted model-based design for CPSs to improve the efficiency of the design process for these complex systems. During the system design stage we integrate models of physical system behavior (also called “plant models”) with controller models to produce an abstracted system implementation.
Accelerating Project Schedules
Simulation enables us to fix bugs before they manifest themselves as problems. That can sometimes make it difficult to put a value on our use of simulation in terms of the engineering time saved or improved design quality.
However, a typical prototyping cycle might take us approximately six months. By introducing a model-based CPS, we can reduce that to around two months by breaking the “prototype/bug-fix” cycle. For derivative projects, we will typically go through two or more prototyping spins to accommodate new requirements, while updating the simulation models will often only take a couple of days.
We are also interested in the use of model-based design for more experimental work. For example, we are considering the use of multicore devices for our next-generation advanced architectures, which we don’t use in our products today. Simulation will enable us to investigate and optimize these new architectures before we spend time implementing them.
Using the Right Tool for the Job
We use a portfolio of simulation tools to suit the task in hand. For mathematical modeling of signal flow or behavior we use MATLAB/Simulink. For modeling hydraulics systems we use AMEsim. As soon as we get away from modeling control algorithms and into the electronics domain, then Saber is our tool of choice. Saber supports the concept of conserved system modeling, which allows us to analyze the effects of how one block loads another — something that’s not possible using a signal-flow analysis. Saber also allows us to model events and event transfers, whereas SPICE simulation, for example, uses the continuous (Laplace) domain.
Case Study: Modeling a Gasoline Pump
The physical system of a gasoline fuel pump (Figure 2) consists of three parts: a driver circuit simulated using an electromechanical simulator, and separate pump and inlet valve models, which are simulated using the hydraulics simulator.
To create the multi-domain simulation shown in Figure 2 we used Simulink to model the control part of the ECU algorithm and deployed a combination of Saber and AMEsim (simulating the hydraulics of the fuel pump) to model the plant.
Figure 2: The block diagram of the gasoline fuel pump system and its simulation modelrepresents a multi-domain implementation with a co-simulation bus
It’s a common misconception that Saber is only useful for modeling a system’s power electronics; it actually does a very good job of modeling the electromechanical parts of the system. For example, by getting accurate readings of the force from the electromagnetic circuitry for a solenoid, we can use it to send out a force and receive back a position.
We used proportional-integral (PI) control to generate the controller output based on the difference between the target pressure and the pressure feedback at a constant battery voltage input level. Triggering the solenoid in response to the controller output uses energy, so we added pulse width modulation (PWM) duty-cycle control to the original control. While the solenoid had to be fully triggered to open the inlet valve, less force was required for holding it open and therefore we could reduce the current through the solenoid. The percentage reduction in the solenoid current was determined by the PWM duty factor.
Following several tests and using our experience, we gathered data on the relationship between the duty factor for various start angles and the revolutions per minute (RPM) and battery voltage. We then produced a look-up table that could be used to obtain the duty-cycle value. The PWM-based control also enabled the use of the virtual CPU based approach for implementing this CPS.
We also use Saber to analyze the first-order hysteresis effects of magnetic circuits (Figure 3). This is much simpler and less time consuming than performing a finite element analysis, which has its place if you need to look at fringe effects, but otherwise Saber gives us the right level of detail for system modeling without too much complexity.
Figure 3: Example of a BH curve taken from the Magnetic Component tool in Saber
The Future of Modeling
Given our globally distributed teams, we’re very interested in the emergence of cloud computing to harness global CPU resources and enable us to share higher fidelity models across distributed teams. Today, we are using the cloud to deploy product lifetime management (PLM) applications, but with an increased use of simulation and co-simulation over the next 10 years we can see our use of the cloud transitioning from a manager’s tool to an engineer’s tool.
Increasingly, we are encouraging the use of virtual CPU modeling, which involves developing a software model of the microcontroller hardware itself. We can then integrate the microcontroller model with the behavioral models of the plant (the physical system) so that we can perform realistic system performance measurement and validation. This approach allows concurrent development of the plant models and control software applications, and also their validation, including the real-time operating system (RTOS) and device drivers. We will explain more about our methodology for virtual CPU modeling and co-simulation with the physical systems in a forthcoming article for Synopsys’ Automotive Technical Bulletin.
Project Profile
Synopsys Saber:
Electro-mechanical (power and magnetics) conserved-system modeling and simulation
MathWorks MATLAB/Simulink Software: Algorithm modeling and simulation
LMS Imagine.Lab AMEsim:
Hydraulics modeling and simulation
ChiasTek CosiMate:
Heterogeneous co-simulation
About the Authors
Sujit S. Phatak received his Bachelor of Engineering (BE) in Instrumentation & Control Engineering from University of Pune, India in 2003 and his Master of Science in Electrical Engineering (MSEE) with specialization in Embedded Systems from University of Texas at Arlington in 2007. He has been working with Hitachi America R&D since 2007 as a researcher in the Embedded Systems group and has been involved in several research projects related to Model Based Development (MBD) for Automotive Embedded Control Systems. Some of his past projects involved simulation and modeling of powertrain systems including engine management and hybrid tecnologies as well as GPS antenna performance modeling. Currently, he has been responsible for development of virtual prototyping systems including the microcontroller simulation for developing automotive Electronic Control Unit (ECU) simulation models. He has published papers related to virtual prototyping systems for SAE and IFAC. He has two US patents pending.
DJ McCune received his Bachelor of Science (BSEE) in 1988 Electrical Engineering from Lawrence Technological University and his Master of Science (MSSE) in Systems Engineering from Oakland University in 2000. He has been working at Hitachi America R&D since 2003 and his current position is Group Leader/Senior Researcher for the Embedded Systems Group. The Embedded System Group is involved with Model Based Design and model development of Electronic Control Units, Simulation of Mechatronic Systems, and development of simulation models. He is a member of SAE. He has twelve US patents.
In a forthcoming article the authors will describe how they extend their model-based design environment with “processor in the loop simulation” to run production software on a real hardware ECU to control the physical model.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
