2010-01-0936

Automated Model Based Design Process to Evaluate Advanced Component Technologies

R. Vijayagopal, N. Shidore, S. Halbach, L. Michaels, A. Rousseau Argonne National Laboratory

Copyright © 2010 SAE International

ABSTRACT

To reduce development time and introduce technologies faster to the market, many companies have been turning more and more to Model Based Design. In Model Based Design, the development process centers around a system model, from requirements capture and design to implementation and test. Engineers can skip over a generation of system design processes on the basis of hand coding and use graphical models to design, analyze, and implement the software that determines machine performance and behavior. This paper describes the process implemented in Autonomie, a Plug-and-Play Software Environment, to design and evaluate component hardware in an emulated environment. We will discuss best practices and provide an example through evaluation of advanced high-energy battery pack within an emulated Plug-in Hybrid Electric Vehicle.

INTRODUCTION

Building hardware is expensive, time consuming, and severely limiting with respect to comprehending, and accounting for, variation in a system design. Traditional design paradigms in the automotive industry often delay control system design until late in the process, in some cases requiring several costly hardware iterations. To reduce costs and improve time to market, it is imperative that greater emphasis be placed on modeling and simulation early in the development process. This becomes more necessary as time goes on as a result of increasing vehicle complexity, more vehicle configurations, and larger groups of engineers working on projects, which complicates design choices. To fully realize the benefits of math-based design, the models created must be as flexible and reusable as possible.

Greater reliance on modeling and simulation does come at some cost. Even if institutional inertia can be overcome, new processes must be put in place to facilitate communication between the model creators and consumers and to handle an increase in the number of files, which can be quite significant and overwhelming.

Model management introduces a set of requirements that are quite similar to software management requirements. There is a need to maintain version control for the models, as well as to implement a system-level model assembly capability, comparable to the need to interface, compile, and link the code modules that comprise a complete software build. Project management requirements also exist, to ensure that all the files and data needed to create a complete simulation are organized, maintained, and provided as a complete package.

The Autonomie software [1,2] provides an integrated environment and set of processes for managing, interconnecting, and integrating dynamic models of vehicle components and subsystems, to build and execute complete system simulations. These simulations are then used for many different types of analyses, from trade-off studies of alternative propulsion system architectures to detailed control system design.

Autonomie’s Plug-and-Play architecture facilitates the use of component and subsystem models of selectable fidelity, permitting users to focus in detail on the area of interest they want to investigate.

MODEL-BASED DESIGN OVERVIEW

Model-Based Design (MBD) [3] is a math-based visual method for designing complex control systems and is being used successfully in many motion control, industrial, aerospace, and automotive applications. It provides an efficient methodology that includes four key elements in the development process: modeling a plant (from first principles or system identification), synthesizing and analyzing a controller for the plant, simulating the plant and controller together, and programming/deploying the controller. MBD integrates all these multiple phases and provides a common framework for communication throughout the entire design process.

The MBD paradigm is significantly different from traditional design methodology. Rather than using complex structures and extensive software code, designers can formulate advanced functional characteristics by using continuous-time and discrete-time computational building blocks. These models and associated simulation support tools can provide rapid prototyping, virtual functional verification, and software testing and hardware/software validation. MBD is a process that enables faster, more cost-effective development of dynamic systems, including control systems, signal processing, and communications systems. In MBD, a system model is at the center of the development process, from requirements development, through design, implementation, and testing. The control algorithm model is an executable specification that is continually refined and elaborated throughout the development process.

MBD allows one to improve efficiency by:

- Using a common design environment across project teams - Linking designs directly to requirements - Integrating testing with design to continuously identify and correct errors - Investigating the effects of variation on system performance and robustness - Refining algorithms through multi-domain simulation - Automatically generating embedded software code - Developing and reusing test suites - Automatically generating documentation - Reusing designs to deploy systems across multiple processors and hardware targets

The different phases of MBD are described in Figure 1.

Figure 1: V Diagram for Software Development [4]

Different steps are supported by a variety of approaches from Model-in-the-Loop (MIL), to Software-in-the-Loop (SIL), Hardware-in-the-Loop (HIL), Rapid-Control-Prototyping (RCP), or Component-in-the-Loop (CIL). Each process is used to address different stages of the development.

The automotive companies have widely implemented these processes from code generation [5], to RCP [6] and HIL [7].

The first step is the simulation, where neither the controller nor the plant operates in real time. This step, usually used toward the beginning of the process, allows engineers to study the performance of the system and design the control algorithm(s) in a virtual environment, running computer simulations of the complete system, or subsystem.

Rapid Control Prototyping (RCP) provides the engineer with the ability to quickly test and iterate their control strategies on a real-time computer with actual hardware. The control strategy is simulated in real-time on a processor that augments or replaces the real embedded controller, allowing the user to investigate and refine the control algorithms while operating with the real system under control. RCP is now a commonly used method to develop and test control strategies.

In SIL phase, the actual Production Software Code is incorporated into the mathematical simulation that contains models of the Physical System. This is done to permit inclusion of software functionality for which no model(s) exists or to enable faster simulation runs.

Controller HIL is a technique for running a mathematical simulation model of a system on a real-time computer, integrated with actual controller hardware and software, such that the controller acts as though it were integrated into the real system. This is used for testing and validation of embedded electronic controllers, prior to testing in a vehicle or on a dynamometer.

CIL is used to assess the impact of an entire system (e.g., engine plant and control) on other portions of the system (e.g., vehicle). The system to be analyzed is real hardware while the rest of the components are emulated from models.

The main approaches are described in Figure 2.

Figure 2: Main Steps of MBD

PLUG-AND-PLAY ARCHITECTURE TO SUPPORT MBD

Autonomie [2] is a software package designed to support the ideal use of modeling and simulation for math-based automotive control system design. Autonomie supports the assembly and use of models from design to simulation to analysis with complete plug-and-play capabilities. Models in the standard format create building blocks, which are assembled at runtime into a simulation model of a vehicle, system, subsystem, or component to simulate. All parts of the graphical user interface (GUI) are designed to be flexible to support architectures, systems, components, and processes not yet envisioned. This allows the software to be molded to individual uses, so it can grow as requirements and technical knowledge expand [1]. This flexibility also allows for implementation of legacy code, including models, controller code, processes, and post-processing equations.

CONFIGURATION DEFINITION — The relative position of systems and their interconnections are defined by a set of configuration files. For example, a conventional vehicle can be represented by different configurations. One configuration may have a torque converter and a gearbox. Another may have those two systems grouped together under a single transmission system. Both configurations are valid for a conventional vehicle, and the selection between the two of them depends on the application. Figure 3 shows and example of a completed configuration in Simulink for generic component systems.

Figure 3: Configuration Example

SYSTEM DEFINITION — System definition is typically done by a system expert. Several things are needed to fully define a system: the configuration of the system; the model of the system, which is a description of the physical equations characterizing the generic component (e.g., engine plant); and the parameters, or initialization data, which make the generic component specific (e.g., 2-L GM DOHC gasoline engine, 100-kW, model year 2010).

Figure 4 shows the different files that can be contained in an expert system. While some are compulsory (i.e., model and initialization files), others should be added by the expert to maximize reusability and traceability.

Figure 4: Files Contained in an Expert System

SELECTION THROUGH THE GUI — The GUI manages the system definition complexity and makes it possible for novice users, as well as experts, to quickly find the files they need, to stitch them together into a cohesive simulation, to execute standard work processes, and to perform database management functions without becoming overwhelmed.

The first step in defining a model is to select its configuration. As the user selects various systems in the GUI, several configuration options may be available in the GUI and are selected through Drag-and-Drop (Figure 5). Once the configurations are selected, experts select their model and initialization files to define a system.

Figure 5: Configuration Selection

The saved systems by each expert can then be selected for further development or used within a study dedicated to a group of systems. For example, a vehicle-level control expert could reuse the systems developed for each of the powertrain components by the different component experts. The saved systems can be selected through the GUI, as shown in Figure 6.

Figure 6: System Selection

Once each system is defined, the vehicle model can be developed. A vehicle model has a logical hierarchical structure: the vehicle contains the Vehicle Propulsion Architecture (VPA) system, which contains component systems (such as an engine), which contain plants, on down to the lowest level of systems, which themselves contain models. Autonomie has two ways of displaying this information: in a tree format in the Project Explorer window and as a series of icons representing systems that can be “drilled down” into to navigate deeper into the structure (Figure 7).

Figure 7: All Systems Selected in Autonomie

BUILDING THE ENTIRE MODEL AUTOMATICALLY — Autonomie uses a novel approach that allows users to build the entire model on the basis of configurations and systems selected from the GUI. This gives users the flexibility of saving and versioning models independently without the headache of manually connecting everything. Users select the correct files in a user interface, and the automatic building uses metadata associated with the models to create the correct connections. This GUI also uses the metadata to facilitate the other necessary functions, such as compatibility checks and file selection. Figure 8 shows how each selected system from the GUI is built and connected to represent the final model.

It also allows component experts (e.g., engine experts) to focus on the areas they are familiar with, while still being able to evaluate their component both as a standalone system as well as within a vehicle context. Systems can be exported and transferred that way, or the systems can be shared through the database. Autonomie includes as many pre-built systems as possible to give users a “jump start” into creating vehicles from scratch.

Figure 8: A Powertrain Is Assembled by System Experts on the basis of Selected Configuration

Once the completed model is assembled and the different files initialized, the model is ready for simulation. An example of completed Simulink model is shown in Figure 9.

Figure 9: Completed Simulink Model

SYSTEM ARCHITECTURE DEFINITION FOR MBD

Similarly to experts systems, which can be reused from one study to another, generic configurations can be defined for each step of the MBD process. The following paragraph describes the generic systems used in Autonomie as part of MBD. Figures 10–16 illustrate how the generic system organization can be changed for different applications. Each of the subsystems (boxes) represents a separate model that can be selected from the Graphical User Interface.

SOFTWARE-IN-THE-LOOP — For SIL, the generic system configuration is similar to the one for a simulation. As shown in Figure 10, the system consists of a controller, an actuator, a plant, and sensor blocks. Depending of the component and the degree of modeling, any of these blocks or their combinations can be used. For example, a system might only contain a plant (e.g., accessories, final drive…) or a controller (e.g., driver.)

Figure 10: Generic Component System Configuration

ADDITIONAL SYSTEMS REQUIRED FOR HARDWARE CONNECTIONS — To control hardware or receive feedback, specific logic needs to be introduced. This provides a convenient point for the user to implement a testing plan or to enforce checks to ensure safe operation of the hardware. Figure 11 describes the generic configuration setup used for hardware/software interactions. Note that two additional blocks are added to the generic component system, which is described in Figure 11.

Figure 11: Hardware/Software Interaction Configuration

The experiment block deals with the system constraints and experiment commands, as show in Figure 12. In the constraints block, the commands are saturated and sensor signals from the hardware are available here as feedback information. If an emergency action is required on the basis of the experiment survey, the commands from the system will be overwritten to ensure safe operation. Similarly, the commands can also be changed manually in the Overwrite Command block, mostly for debugging purposes.

Figure 12: Experiment Control Block

The objective of the experiment survey block, shown in Figure 13, is to verify that each signal is within its expected operating range. This could even be extended to implement diagnostic features. If any abnormal condition is observed, a warning will be sent to the experiment control block so that action can be taken, such as limiting the operating range or even triggering an emergency shutdown.

Figure 13: Experiment Survey Block

For the following paragraphs, only the changes in the generic component system block will be discussed because both the experiment control and survey blocks have to be used for each process.

Whenever a hardware is introduced to a simulation environment, it has to be represented by a set of input output signals. The sensors and actuators that enable the interaction between the hardware and simulations are necessary for this experimental setup.

HARDWARE-IN-THE-LOOP — For HIL, the controller block from Figure 10 is replaced by the connections with the hardware Input/Output (I/O). Signals can be through CAN, analog, or digital. In addition, the measured signals are converted back to SI units so the rest of the models can use them with complete information about the signals. Figure 14 shows the generic configuration for HIL.

Figure 14: HIL Generic System Configuration

RAPID-CONTROL-PROTOTYPING — For RCP, we have the opposite setup as for the HIL, in that the controller model is kept while the plant block is replaced with the hardware I/O. As a reminder, the hardware is, in general, more than the plant itself. For example, when using an engine plant, it has to be connected to the dynamometer and other emissions equipments, which all have to be controlled. Figure 15 shows the generic configuration for RCP.

Figure 15: RCP Generic System Configuration

COMPONENT-IN-THE-LOOP — For CIL, because both the controller and the plants are hardware, the entire component system is simply replaced by the hardware I/O.

Figure 16: CIL Generic System Configuration

APPLICATION EXAMPLE – BATTERY-IN-THE-LOOP

HARDWARE SETUP DESCRIPTION

Figure 17 shows a block diagram representation of BIL.

Figure 17: Battery in the Loop Block Diagram

Battery hardware is subjected to power demands from a virtual vehicle (in Autonomie). A high-voltage DC power supply (the ABC-170 CE) sinks and sources power from the battery to emulate battery utilization on standard dynamometer cycles or real-world driving. Real-time feedback from the battery (SOC, voltage, temperature, current limits) is used by the virtual vehicle energy management controller as a part of its strategy. Figure 18 shows the actual hardware setup. As shown in Table 1, in addition to the battery, several components are also part of the experiment.

Table 1: Components in the Battery-in-the-Loop Experiment

Hardware Component Use Communication with Virtual

Vehicle/Experiment

Battery The component-in-the-loop CAN, RS 485, analog voltage and current measurement

ABC-170CE Battery cycler CAN

Brusa charger Charge the battery overnight CAN

Power meter Measure AC and DC Ah, power RS-232

Chiller Coolant flow through battery RS-232, thermocouple feedback, pressure gauage

Environmental Chamber Cold and hot temperature tests RS-232

NI- Crio DAQ CAN

Figure 18: Battery-in-the-Loop Hardware

DESCRIPTION OF THE DIFFERENT SYSTEMS — As previously mentioned, the system architecture is split up into three main blocks: the experiment control block, the generic component system, and the experiment survey block (Figure 11). The purpose and content of each block is described below from the “battery-in-the-loop” perspective:

Experiment Control Block:

The experiment control block (Figure 12) consists of three blocks – constraints, overwrite commands, and experiment commands:

1. Survey the current command to the battery cycler, to be within the battery limits.

The constraints block:

2. Saturate the current command. 3. In case of an E-Stop being triggered, force the current command signal to a pre-determined value

(e.g., 0 A). The E-stop can be triggered by multiple situations: a. The command (current) being out of bounds — to protect the hardware from damage. b. The feedback being out of bounds (e.g., faulty sensor/damaged hardware). c. A “fault” signal from the battery or the battery cycler or any other hardware apparatus.

For situations like calibration of the current measurement device, standard USABC tests on the batteries, debugging the experiment commands, and others, the hardware components need to be controlled independently (and not be a part of the virtual vehicle, with the vehicle controller issuing commands). In such a case, the overwrite commands block provides the user the option to overwrite the vehicle commands and send signals to the components based on the test at hand. For example, if the response time of the battery cycler and the current clamp need to be quantified, the user can send pre-programmed square pulses as current commands to the battery cycler, independent of the vehicle commands.

The overwrite commands block:

This block converts vehicle-level signals (e.g., battery current command, key on) to signals for each hardware component. For example, when the vehicle sends a “key on’ signal at the start of the drive cycle, commands are sent out to each component, ensuring proper sequence, to avoid potentially

The experiment commands block:

Environmental Chamber

Virtual vehicle in a dSPACE system.

DAQ ( Ni- CRIO)

Battery cycler (ABC-170CE)

Battery Charger

Power meter

Chiller

dangerous situations (e.g., the battery cycler is a current source and therefore should always have the battery as a load).

1. Close battery contactors. 2. Close battery cycler contactors and put the cycler in current mode (it tracks a current command). 3. Set the integrator in the power meter to start integration of current and power. 4. Set the chiller temperature and start coolant flow. 5. Set environmental chamber temperature. 6. Send a current command to the cycler only when status feedback from all the components has

been received. 7. Send command to the data logger (C-Rio) to log battery and virtual vehicle data.

Similar commands have to be sent during the experiment (e.g., periodic check of status, battery faults) and when there is a “key-off” command.

The experiment commands block could therefore be a StateFlow chart, which coordinates all actions listed above to ensure smooth, safe operation of the hardware and passes on the effort or flow commands to the hardware components. The inputs to the experiment commands block are vehicle signals from the input block, but the outputs are component commands to each component. Again, these scaled commands are saturated to be within limits.

Generic component system:

For BIL, the generic component system has no controller — the BMS for the battery and the battery cycler controller are inside the battery and the battery cycler, respectively, and the user does not have control access to them. Similarly, there is no actuator, and there are no sensor models as well. Therefore, the generic component system is a block with hardware I/O. Table 1 above lists the I/O to different components.

Several actions are taken for the output signals this block:

1. The CAN bus generally follows a Hexadecimal system; therefore, proper conversion from decimal to HEX is needed for commands to the CAN block.

2. The signals to the RS-232 have to be converted into Ascii for serial transmission. 3. Rate transition blocks are needed if the CAN bus rate is different from the rate of the real-time

simulation.

The signals are then connected to the CAN, Serial, Analog, or Digital Output blocks, which are generally specific to the real time target (e.g., dSPACE).

Similarly, the input (feedback) signals have to be processed: 1. CAN and RS-232 signals have to be converted into the decimal system. 2. The analog input signals have to be converted from raw voltages to actual vehicle signals (e.g.,

voltage, temperature, current). 3. Sometimes, the feedback signal is very noisy and needs to be filtered to prevent instability in the

vehicle system. Therefore, digital filters can be implemented, in addition to the physical filtering of the feedback signals (e.g., 5 B modules).

The E-Stop is generally a digital out signal, which triggers a Normally Closed relay in the E-stop loop.

The inputs to the generic component system block are signals to each hardware component in the experiment, and output signals are of three types:

1. Signals needed by other components in the vehicle model (effort, flow).

2. Feedback signals to the vehicle controller. 3. Signals that need to be monitored for safety.

Experiment Survey Block:

The survey block monitors all the feedback signals from the hardware components that are needed for vehicle operation or for safety. For BIL, the following signals will be surveyed:

1. For use by the vehicle controller: a. Battery state of charge (sent by BMS on CAN) b. Battery temperature c. Battery current limits (sent by the BMS on CAN) d. Battery cell voltages

2. For use by other components: a. Battery voltage (effort to other blocks)

3. For safety: a. Fault signals from all the hardware components (sent over the CAN bus) b. Battery temperature c. Battery cell voltages d. Coolant temperature e. Battery state of charge f. Battery voltage

If any of the signals are out of bounds, a fault signal is sent to the experiment control block, and, on the basis of the nature of fault, an E-STOP can be trigged.

RESULTS — The Autonomie simulation of a midsize pre-transmission parallel vehicle with a 41-A·h, 10-kWh JCS battery in electric operation was compared to the same vehicle with an actual physical battery (same specification) by using BIL. The aim of the experiment was to validate the battery simulation model. Proper validation is only possible if the battery model can be seamlessly replaced by an actual battery, with the rest of the vehicle model remaining untouched. Autonomie provides the flexibility for such kinds of experiments. After the simulation, Autonomie was configured for CIL, as described in the section above.

Figure 19 compares the Autonomie simulation model voltage (red) with the actual battery voltage (blue).

Figure 19: Battery Voltage Comparison in Simulation and Component-in-the-Loop ― both Using Autonomie

Table 2: Simulation Results Comparison with the Battery Hardware

Units Component-in-the-Loop Simulation

AER from 0.9 to 0.3 SOC mi 24.79 26

Battery A·h Depleted A·h 25 24.7

Battery Electrical Energy kWh 6.29 6.57

Energy Consumption Wh/mi 253.7 241

Table 2 shows the comparison of the simulation and component results. Because the same vehicle was used for both the simulation and the component HIL, it was easy to identify that the differences between simulation and CIL were due to differences in the battery model. The battery model was then refined, and the new generation simulation results were again compared to CIL results for validation of battery model accuracy.

While the actual results of the comparison between battery model and physical battery are not important for this paper, the flexibility of Autonomie, to enable such a comparison by providing the same platform for simulation and CIL, can be easily appreciated.

SUMMARY AND CONCLUSIONS

To reduce costs, the automotive industry must embrace math-based control system design for modeling, simulation, testing, and analysis. This paper proposes an ideal modeling process, wherein experts produce libraries of high-quality models in varying levels of fidelity for use throughout an organization and across the automotive industry. These models connect seamlessly for maximum reusability and flexibility, making collaboration quick and easy. The models developed by these experts can be used from the beginning to the end of the design process, from high-level configuration sorting studies, to code testing with production software (such as SIL, HIL, or RCP), and, finally, to solving production problems.

Each system (e.g., plant or control) can be either represented by a set of equations or by its hardware. To quickly evaluate new technologies in different environments, a generic process was presented to replace any part of the system through the graphical interface. This generic process allows companies to increase their productivity and bring technologies to the market faster.

ACKNOWLEDGMENTS

This work was supported by DOE’s Vehicle Technology Office under the direction of Lee Slezak. The submitted manuscript has been created by UChicago Argonne, LLC, Operator of Argonne National Laboratory (“Argonne”). Argonne, a U.S. Department of Energy Office of Science laboratory, is operated under Contract No. DE-AC02-06CH11357. The U.S. Government retains for itself, and others acting on its behalf, a paid-up nonexclusive, irrevocable worldwide license in said article to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government.

REFERENCES

1. Argonne National Laboratory, Autonomie Documentation2. Argonne National Laboratory, Autonomie, Computer Software,

, 2009. www.transportation.anl.

gov/modeling_simulation/index.html, 2009.

3. Paul Smith, The MathWorks, “Best Practices for Establishing a Model-Based Design Culture,” SAE 2007-01-0777, SAE World Congress.

4. Jim Tung, The MathWorks, “From Specification and Design to Implementation and Test,” MathWorks Conference, June 2004.

5. General Motors, “Automatic Code Generation Process,” MathWorks Automotive Conference, June 2005.

6. Oguz Dagci, General Motors, “Real Time Interface Blockset Development in Matlab/Simulink for On-Target Rapid Prototyping,” SAE 2006-01-0169.

7. Sergey Semenov, Ford Motor Company, “Automation of Hardware-in-the-Loop and In-the-Vehicle Testing and Validation for Hybrid Electric Vehicles at Ford,” SAE 2006-01-1448.

CONTACT

Aymeric Rousseau (630) 252-7261 E-mail: arousseau@anl.gov