Enabling PC-Based HIL Simulation for Automotive Applications Paul Baracos, Ph.D., P.Eng , Guillaume Murere, Ph.D., C.A. Rabbath, Ph.D., eng., and Wensi Jin, B.S.(E.E.) Opal-RT, 1751 Richardson, suite 2525, Montreal, QC, Canada H3K 1G6 phone:514-935-2323 email:
[email protected] http://www.opal-rt.com
Abstract This paper describes new technologies that enable the use of the affordable PC hardware as the computing platform for high-performance electromechanical simulation. Challenging applications such as real-time hardware-in-the-loop and mega-simulation are made possible using a combination of PC-based simulation environment, distributed architecture, and software solutions to numerical problems that arise from fixedtime step integration. The technologies are flexible enough to allow expansion and reconfiguration, and cover the entire design process from modeling to real-time simulation or control without the engineer ever having to write code. Keywords Fixed-time-step integration, real-time simulation, hardwarein-the-loop simulation, distributed simulation megasimulation, simulation accelerator, computing cluster, COTS Acronyms and Abbreviations The following acronyms and abbreviation are used in this paper: ABS COTS ECU HIL PC TCP/IP UDP
Antilock brake system Commercial-off-the-shelf Engine Control Unit Hardware-In-the-Loop simulation Personal Computer (IBM compatible) Transmission Control Protocol/Internet Protocol User Datagram Protocol
Introduction Real-time simulation and support for HIL are increasingly recognized as essential tools for engineering design. Pollini and Innocenti[1] review the state of the art and point out the necessity of distributed simulation for dealing with complex dynamic models and real-time constraints. They discuss topics such as simulator decomposition, computational needs, inter-processor bandwidth, TCP/IP vs. UDP, deadlock avoidance, real-time clock synchronization and optimization, and console integration. Stasko et al.[2] acknowledge that HIL is no longer a luxury in modern system design. This paper presents a suite of technologies that enable automotive engineers to use modern simulation and rapid control prototyping methods at minimal expense while avoiding many of the arcane details of real-time numerical analysis. Overview The automotive industry is seeing increasing use of modeling tools for various applications from design engineering through rapid control prototyping to hardware-in-the-loop and
human-in-the loop simulation. Many techniques that were pioneered in the higher-cost world of aerospace engineering are now seeing wider use now that they are no longer bound to expensive proprietary hardware. As COTS solutions have replaced custom development, PC systems have now supplanted proprietary designs, workstations and even mainframes for many simulation and control applications. With the advent of PC clusters, embedded PCs, high-end graphics cards and other technologies, the range of applications that can benefit from the low cost of COTS hardware has grown. Today, true COTS hardware such as PC, Ethernet and IEEE1394 (Firewire) allow large savings in cost and engineering effort. Similarly, commercial simulation software such as MATLAB/Simulink™1 and MATRIXX/SystemBuild™2 are now widely used in engineering simulation. They have become the modeling tools of choice because their graphic interfaces mimic the function-block methodologies taught in universities and technical schools. This reduces the learning time and increases engineering productivity. Another useful feature of these packages is automatic code generation that frees engineers from the tedious and error-prone task of writing code. They make it possible to go from concept to simulation without ever having to write code. However, the code generated by these packages is not always well suited to real-time execution , one reason being that the tool developers have concentrated their efforts on variabletime-step integration methods and iterative solvers which give the best simulation precision, but this precision is at the expense of real-time determinism. Real-time determinism can only be achieved using fixed-timestep integration and without using iterative solvers. Special attention is required to maintain numerical precision.
™1 Trademark of The MathWorks ™2 Trademark of Wind River Systems 1/8
Guiding Principles The research and development described in this paper have been guided by the following principles: •
Advanced modeling and simulation algorithms (not proprietary hardware) are the key to success.
•
Real-time simulation and control should be affordable.
•
The tools should look after low-level details by providing a simulation environment, taking the engineer from graphical models to platform hardware without hand coding.
•
Benefit from the market-driven advances in commercial technologies. Use the latest technologies as soon as they appear.
•
Simulation architecture should be scalable.
•
Models should be deployable in real-life as the actual control system.
•
In real-time, every microsecond counts, but not at the expense of precision. Special numerical methods must be used to maintain precision without using variabletime-step integration or iterative solvers.
HIL – Design By Simulation Automotive systems typically contain numerous feedback loops, each consisting of a physical system or plant to be controlled, sensors, actuators, a controller and a setpoint (or more generally, a desired state trajectory) , as shown in Figure 1. The controller is in fact a computer that uses input data from the sensors to calculate an output control signal that moves the actuators in such a way as to coerce the plant to the follow the desired state trajectory.
desired setpoint trajectory
virtual controller virtual engine
IBM Compatible
Figure 2. Virtual automotive system (simulated)
Hardware-in-the-loop In order to validate that a controller can indeed meet real realtime performance constraints, the HIL technique is employed. In HIL, either a simulated plant is wired to a real controller, Figure 3, or a real plant to a simulated controller, Figure 4. In either case, the distinguishing feature is the presence of I/O and wires.
simulated trajectory
real I/O controller
virtual engine
input signals from simulator
I/O control signals to simulator
IBM Compatible
Figure 3. HIL: simulated plant, real controller
× +
+ +
-
in p u t s ig n a ls
c o n tro lle r I/O c o n tr o l s ig na ls
+
d dt
s e n s o rs a c tu a to rs
simulated controller
input signals from plant
d e s ire d tr a je c to r y a u to m o b ile
I/O IBM Compatible
control signals to plant
real trajectory real engine
Figure 1. Automotive control loop (real, not simulated)
Due to the complexity of the dynamic equations, it is rarely possible to find closed-form solutions. The alternative is to carry out simulation studies, entirely within the virtual world of a desktop computer, as shown in Figure 2. However, such off-line simulation does not validate the implementation of the controller. Off-line simulation provides no guarantee that the real-time performance constraints can be met in a sampled-time embedded computer with real-life I/O.
Figure 4. HIL: real plant, simulated controller
Usually, simulation and control begins with models of hardware because the actual hardware is not yet available. Later, when it is available, the models of that hardware can be removed and the actual hardware connected. Thus the hardware can be tested on-line as early as possible in the design process so that the real-time performance can be evaluated.
2/8
Enabling Technology 1: PC-Based Simulation Environment
Enabling Technology 2: Distributed Real-Time Simulation Platform
As the computer industry overall is growing at a phenomenon pace, PCs have now gained acceptance in application areas from Internet access, scientific computing to web server and data centers. It is clear that consumer demands such as multimedia and commercial solutions such as database will continue fuel increases in PC performance, performance which can be harnessed for low-cost HIL simulation. However, raw processor power is only part of the answer, having a simulation environment in which the engineer will build, compile and execute his/her own model is also of vital importance. Having a readily available environment saves the engineer much time that would have otherwise been spent in developing the “glue” software between the simulation and the underlying operating system. The software described includes tools for simulation development, automatic code generation, execution control, data acquisition, and performance analysis. The tools developed by Opal-RT are part of a package called RT-Lab. RT-Lab uses either of the popular MATLAB/Simulink or MATRIXX/Systembuild tools packages as a front-end for editing and viewing graphic models in block-diagram format. The block-diagram models become the source from which code can be automatically generated, manipulated and downloaded onto target processors for real-time or distributed simulation.
Sufficiently complex system dynamics, i.e. mega-simulation, and/or sufficiently small step size will ultimately overwhelm even the fastest processor. Millisecond or faster cycles are not rare. The solution is parallel processing. RT-Lab implements distributed simulation in the form of a PC cluster, as shown in Figure 6. In keeping with the guiding principles, HIL is accomplished using commercial components, which are in fact PCs equipped with I/O boards. Starting with Simulink or Systembuild models, complex simulations can be subdivided for execution on separate processors. Simply subdivide the models and add the inter-processor connection blocks supplied with RT-Lab.
I/O Interfaces Interfacing with real world hardware devices, controller or physical plant alike, is a requirement for HIL. I/O interfaces are configured through custom blocks, supplied with RT-Lab. The engineer merely needs to add the blocks to the graphic model and connect the inputs and outputs to these blocks. The automatic code generator will direct the model’s data flow onto the physical I/O cards.
,QWHUIDFHVIRU,2FDUG
virtual automobile simulated trajectory
distributed simulator
controller
input signals from sensors
node 1
control signals to actuators
node 2
node n
Figure 6. Distributed HIL simulation
Opal-RT’s real-time simulation executes on a distributed system of standard PCs. No custom or proprietary boards are utilized. Typically, there is no performance penalty with this approach but there is a noticeable decrease in cost[5]. Inter-PC communication options range from low-cost UDP/IP on Ethernet at 100Mb/s, through FireWire at 400Mb/s to high-performance Giganet cLAN™3 at 1.2GB/s. For ultrahigh-performance, RT-Lab can make use of symmetric multiprocessing computers where the processors talk to each other directly through shared memory. Cluster size can be scaled to meet increased performance needs. Simply add processors and redistribute the simulation model at the graphic level.
Figure 5. Graphic tools for defining a simulation.
™3 Trademark of Giganet Inc. 3/8
Automatic Code Generation RT-Lab code “understands” distributed, real-time simulation, and works with the standard MATLAB or MATRIXX code generators to enable parallel, real-time execution and physical I/O interface. RT-Lab automatically takes care of setting up all the communication, including real-time data exchanges between processors and interfacing with the real-time operating system, QNX™4 or RT-Linux. This leaves the engineer free to work on the already difficult task of creating a proper mathematical model. Execution Control RT-Lab supports two execution modes: as-fast-as-possible (which means what it says) and hard real time (which means the execution time of each simulation step is always less than an upper bound usually expressed in microseconds or milliseconds). In either mode, RT-Lab provides the interface to start, stop and pause simulation execution, as well as stepping through the execution. With large step sizes, say 100 milliseconds or greater, soft real-time can be achieved using a standard operating system such as Windows NT™ or Linux. With fine-grained step sizes, hard real-time execution requires the use of a real-time operating system such as QNX or RT-Linux. It is not unusual for HIL simulations to require sub-millisecond hard real-time step sizes, and RT-Lab as been used in hard real-time applications with step sizes as small as 22 microseconds5.
Enabling Technology 3: Algorithmic Optimization Although parallel processing on low-cost processors is an attractive solution, it is the second choice after algorithmic enhancements that allow the simulation to run faster (independently of the number of processor). RT-Lab incorporates two algorithms that can increase simulation one or more orders of magnitude. The RT-Events Algorithm In 1999, Opal-RT was approached by the Ford Research Laboratory to solve two problems encountered with engine simulation. Briefly, engine dynamics are governed by the crankshaft angle. The Ford V6 engine model is no exception to this rule. However, in a rapid prototyping environment, internal combustion engine control systems are difficult to model and to simulate, especially within both fast and realtime simulation settings. This is so since the engine dynamics may change abruptly at times other than the simulation time instants, in the case of fixed-step simulations. This phenomenon usually results in a loss of accuracy. If one uses variablestep simulations to obtain a relatively high level of accuracy then the problem of long simulation times may arise.
Jonathan Friedman, then at the Ford Research Laboratory, noted that the conventional fixed-step techniques of engine simulations resulted in a problem called reset-walk. This phenomenon has been known to network simulation specialists for some time, but until now no practical solution to the problems it causes has been available to users of commercial software such as Simulink. To better envisage the problem of reset-walk, suppose that several reset events take place over a given time period, assuming that a maximum of one event arises between successive iteration steps. Moreover, assume that the integrator is approximated with any of the conventional fixed-step simulation techniques (e.g. Forward Euler, Tustin’s approximation, etc.). Figure 5 shows a typical configuration of reset integrator using RT-Events blocks.
Reset-walk Demo Model Speed
U Y R
RT-EVENTS Integrator RTE >=
Scope
Threshold Position
RT-EVENTS Level Detector Figure 5. Simple system exhibiting reset-walk.
This configuration is the same with the conventional techniques although the native Simulink blocks are used instead of the RT-Events blocks. Figure 6 shows the outputs of the actual (or theoretical) and the simulated integrators in the case of the integration of a constant signal with reset occurring every time the integrator output reaches the comparator value. There is a relative movement between the time instants at which the resets of the fixed-step simulated integrators take place and the instants at which the reset events of the actual integrator occur. The difference in reset event occurrences, between the actual and the simulated models, and its increase with time, occurs because the reset is based on feedback of the integrator’s internal state. For the conventional techniques, as the simulation moves forward in time, the difference in reset times grows since the error in integrator outputs increases. The reset walk effect can be eliminated through the use of an event-interpolation algorithm that we call RT-Events. In typical HIL applications, this is almost completely eliminated by RT-EVENTS.
™4 Trademark of QSSL 5 %HQFKPDUN VRQD 350 MHz Pentium-based PC 4/8
Also apparent on Figure 7 is a numerical instability that appears as a sawtooth in the uncompensated signal (without RTEvents.
integrator output
Accumulating Error
e
e
e
3
2
1
integration steps variable-step-size And RT-Events integration fixed-step-size integration without RT-Events
Figure 6. Accumulating error in reset demo RT-Events works by compensating for errors induced when a comparator’s output changes between fixed time steps. Under event compensation, a 2-element vector (rather that a scalar value) is passed from the Level Detector to the Integrator. The first vector element is a Boolean-type value whereas the second element is an interpolation factor used to compensate the Integrator for the offset between the event time and the fixed time step. RT-Events is implemented as a Simulink Blockset. It works with Simulink to improve the accuracy of fixed-time-step simulations commonly used in real-time and hardware-in-the loop applications in industries such as the aeronautic, automotive and electric industries. The accuracy of RT-EVENTS simulation approaches that of variable-time-step simulation, as shown on Figure 7, yet runs tens (and sometimes hundreds) of times faster without significant loss of accuracy.
The Artemis Algorithm Modern automobiles can contain hundreds of electric actuators, from window raisers to fuel injectors. The use of electomechanical devices can only increase with the expected adoption of hybrid vehicle, drive-by-wire, active suspension and other innovations. The Simulink Power System Blockset provides an excellent tool for modeling these systems, but it must be modified for use in real-time systems. In the Power System Blockset, electric machines are modeled as nonlinear current sources. This implies a time-step delay between the network's solution and that of the machines. This delay can render the simulation numerically unstable. Opal-RT has developed a Plug-In technology called Artemis (for Advanced Real-Time ElectroMechanical Simulation) as a Plug-in module to improve the fixed-time-step behavior of the Power System Blockset. The Artemis algorithm, invented by C. Dufour [6] allows fixed-time-step simulation to obtain results almost identical to those of variable-time-step simulation, but in constant time suitable for HIL applications. Testing has shown that the Artemis Plug-in is more precise and more stable than the than the Tustin fixed-time-step integration used by unmodified Simulink/PSB simulation, especially for networks containing nonlinear elements in general, and electric machines in particular. This is illustrated by system shown in Figure 8. This system includes an induction motor and a synchronous generator driven by a diesel engine. Asynchronous motor and diesel generator (psbmachines.mdl) A
Fault ABC - G
B
+ -
C
N
Engine speed calculated by standard fixed step algorithm showing numeric instability
A
A
A
A
a
B
B
b
C
Switch. B ABC
B
C
C
c
25kV 1000MVA A
B
C
B1 25 kV
C
3- Phase Break er
A
m C
25 kV - 2.4 kV 6 MVA
3000
2950
Pm
Pm
Vtref (pu)
Engine speed calculated by RT-Event fixed-step algorithm
2900
m
C
tstTime Clock
To Workspace
Vf
Vt
m
SM 3.125 MVA
w
$Diesel Engine Speed & Voltage Control
B
C
Vtref
1.0
Speed (rpm)
rad\ s>rpm
7964
1 MW 500 kvar
B
Vf
-K-
ASM Measurement Demux
Torque (N.m)
A A wref
wm
m_SI
Tm
B2 2400 V
1.0
ASM
is_abc B
ASM 2250HP
wref (pu)
Va (V) tstout To Workspace3
5 MW
3050
Engine RPM
v
Va
3- Phase Fault
Pmec (pu) Vf (pu) Vt (pu) Speed (pu)
powergui SM
2850
2800
Reference engine speed calculated by variable-step algorithm
2750
2700 5.5
6
6.5
7
7.5
8
8.5
9
9.5
seconds
Figure 7. Removing engine speed errors via RT-Events time-step interpolation.
Figure 8.
System including induction motor and synchronous generator driven by diesel engine.
Figures 9 and 10, superimpose the bus B2, phase A voltage waveform simulated with and without the Artemis Plug-in onto the reference waveform. Both fixed-time-step solvers give waveforms that are under-damped immediately following a three-phase fault. Apart from the under-damping immediately after the fault, the Artemis Plug-in waveform is very close to the reference. 5/8
Without the Artemis Plug-in, simulation has the same underdamping problem as well as a large phase-shift error.
With Artemis Plug-in: speed is very close to reference, no instability Synchronous machine speed (per unit)
1.04
With Artemis Plug-in: no error in low-frequency component 2000
Reference and Artemis, TS=100 V
Bus B2 phase a voltage (v)
1500 1000 500 0
0.96 0.94 0.92 0.9 0.88 0.5
1
1.5
2
2.5
3
3.5
4
4.5
Time (s)
-1000
-2000
Reference and Artemis Plug-in, TS=100 V
Low frequency component Instability with unmodifed PSB, TS=100 V
0
0.05
0.1
0.15
0.2 0.25 Time (s)
0.3
0.35
0.4
0.45
Figure 11. Synchronous machine speed: 100µs fixed-time-step waveforms superimposed on reference.
Under-damped high frequency component
Bus B2, Phase A voltage: Artemis Plug-in 100µs fixedtime-step waveform superimposed on reference waveform.
Figure 10 shows the synchronous machine speeds simulated by three integration methods: the reference, Artemis Plug-in, and Tustin. The speed calculated by Artemis Plug-in is almost the same as that calculated by the variable step solver, while the speed by the Tustin method is considerably more erroneous, and unstable in the long term. Without Artemis Plug-in: large phase-shift error
2000 Bus B2 Phase a voltage (v)
1 0.98
0
-500
-1500
Figure 9.
1.02
To demonstrate how RT-Lab can be used, an engine simulator example is presented. Mathematical Model The starting point for any simulation is a mathematical model of the components that are to be simulated. With RT-Lab, the main concern of the engineer has moved from code writing to producing good real-time models. Figure 14 shows a sample Simulink model of an engine. The model is composed of 3 main sections: the controller block (left), the engine model (center) and the instrumentation (right). The presence of these loosely coupled sections suggests immediately that the model is amenable to decomposition for parallel execution on 3 nodes of a PC cluster.
Reference and unmodifed PSB fixed-timestep simulation, TS=100 V
1500
Engine Simulator Application
1000 500 0 -500 -1000
Phase error
-1500 -2000
Under-damped high frequency component 0
0.05
0.1
0.15
0.2 0.25 Time (s)
0.3
0.35
0.4
0.45
Figure 10. Bus B2, Phase A voltage: unmodified PSB 100µs fixedtime-step waveform superimposed on reference waveform.
Results in Figure 11 illustrate how important it is to solve the linear part of the power system by a precise integration method, as is done with Artemis Plug-in.
Decomposition and Parallelization The model is decomposed for use in RT-Lab from within the Simulink window. Decomposition is based on some simple rules: •
all display elements are placed into a console block (SC_),
•
high-rate elements are placed in the master block (SM_),
•
all other elements are distributed into the master or slave blocks (SM_ and SS_) as desired restricted only by the number of processors.
6/8
crank speed (rad/sec)
valve tim ing edge180
mass(k)
Torque mass(k+1)
Throttle An g.
Throttle Ang. N
1
Engine Speed, N
Controller
s Throttle & Manifold Intake
Figure 12. Engine-speed Simulation Model. To separate the model, simply “rubber band” the sections shown in Figure 12 and select the “create subsystem” command from the Simulink Edit menu. This yields the separated model shown in Figure 13. C losed-L oop E ngine S peed C ontrol M od el Separated for Parallel P rocessin g
O ut1 In1
O ut2 O ut1
In2 SM _subs ystem
In1
In1 O ut3 O ut4
In2 S C_ sub system
SS_subsystem
Figure 13. Distributed Engine-Speed Model.
Once the engineer has sub-divided the model into blocks, RTLab asks which blocks should be downloaded onto which target nodes in the PC cluster. RT-Lab then does the following: •
generates code,
•
distributes to the various targets,
N
•
provides an interface for model execution and parameter manipulation. The result is an automotive simulation running in parallel and in real-time. Visuals and other interfaces RT-Lab provides for distributed real-time dynamic simulation, and its open architecture allows third-party COTS geometry engines and visual rendering to be connected for outthe-window visuals. Because of the complexity of geometry, rendering and visual effects calculations, it is good practice to dedicate a separate PC for this purpose. Graphics cards developed for the video game market provide a low-cost, highperformance solution for visuals. Display can be through window-mounted monitors or commercial projectors.
Combustion Compression
Teng
N
trigger
Mass Airflow Rate
rad/s to rpm
Air Charge
Desired rpm
speed set point
1
N
Load
Engine Speed (rpm )
30/pi
Tload
Vehicle Dynam ics
throttle deg load torque
drag torque
Virtual automotive instrument displays can also be provided using COTS solutions such as Labview™6, ALTIA™7or VAPS™8. Touch screen hardware can be installed over virtual switches to mimic toggles, flap levers or gear levers. This provides an inexpensive alternative to expensive hardware and gives the flexibility to easily reconfigure the simulator. Display computers linked with RT-Lab via TCP/IP on Ethernet give typical refresh rates greater than 30Hz. Figure 10 below shows the complete configuration including host processor, real-time PC simulation cluster, out-thewindow and virtual-instrument graphics and HIL. Hardware-in-the-loop Interface to the real world via analog and digital input/output cards is a prerequisite for HIL simulation. RT-Lab’s open architecture allows a wide choice of PC-based cards to be used to talk to various COTS hardware such as driver controls, ECU and ABS units. RT-Lab can also communicate directly with other systems using standard protocols such as those standardized by CAN. Complex configurations can be implemented. Drive-by-wire control system can first be modeled on a simulation cluster. As components arrive they replace simulated components on a block-by-block basis.
Benchmark Results Table 1 shows the speed improvements obtained when combining the use of the RT-Events Blockset with an engine model distribution on multi-processors via the RT-LAB software. The V6 Engine model is distributed on two Pentium III 550 MHz processors as shown on Figure 14 and the simulations use a 500 µsec fixed step. The engine systems comprise a relatively complex controller with sensor noise modeling. Sensor noise is random with uniform distribution over +/- 2% of 5000 RPM. With the same data collected in all cases, Table 1 shows that simulations can be run up to 40 times faster with RT-Events under RT-LAB solution than with the vari™6 Trademark of National Instruments ™7 Trademark of Altia Inc. ™8 Trademark of Virtual Prototypes 7/8
able-step Simulink approach, and up to 14 times faster than the conventional fixed step techniques.
This is true for a highly oscillating signal such as the instantaneous torque and for other signals of interest such as the mean torque and the engine speed. MORE ACCURATE SIMULATIONS WITH RT-EVENTS 300
250
TCP/IP SM_Master
Simulated ECU SS_Slave
Data Acquisition
SC_Console
Instantaneous Torque(in ft.lb)
Shared Memory
Engine Dynamics
200
150
100
50
Variable-Step
0
-50
Fixed-Step without RT-EVENTS
-100
Figure 14. Ford V6 Distributed Model
-150 6.05
Figure 15 shows the higher level of accuracy provided by the use of the RT-Events Blockset as compared with the poor simulation accuracy offered by the native Simulink model, for the same simulation condition.
Fixed-Step with RT-EVENTS
6.055
6.06
6.065
6.07
6.075
6.08
6.085
6.09
Time (in sec)
Figure 15. Instantaneous torque - Ford V6
Table 1 Ford Engine Simulation Results
Model type
Simulation environment
Simulation parameters
Native Simulink Reference Model
Simulink
atol = 1e-4, rtol = 1e-3
Average execution time per simulation step
Total execution time 100 second scenario
N.A.
2000 sec
3500 µsec
700 sec
445 µsec
90 sec
255 µsec
50 sec
Variable step Ode45 Max Step Auto. Native Simulink Reference Model Model with RT-Events
Simulink 1 CPU, RT-LAB
Fixed step 500 µsec Ode4 Fixed step 500 µsec Ode4
Model with
2 CPUs, RT-LAB
Fixed step 500 µsec
RT-Events
Shared Memory
Ode4
Conclusions RT-Lab implements distributed simulation in the form of a PC cluster. The package includes tools for iteration-free fixed-time-step integration for simulation and control, automatic code generation, downloading and execution monitoring. It also includes special algorithms that compensated for numerical errors that are usually associated with fixed-timestep integration. In keeping with the guiding principles, HIL is accomplished using commercial PC-based components. RT-Lab uses either of the popular MATLAB/Simulink or MATRIXX/Systembuild tools packages as a front-end for model definition and viewing. The defined models become the source from which code can be automatically generated, manipulated and downloaded onto target processors for realtime or distributed simulation. Once the simulation has been completed, the same automatically generated code that was used for the HIL simulation can be deployed in real-life as the actual control system, simply
by downloading into the flash memory of an embedded controller. This provides the ultimate in rapid control prototyping, from simulation to functioning controller with a few mouse clicks. Use of RT-Lab has been demonstrated for an engine simulator, starting with a Simulink model of an automotive engine. With RT-Lab, it is also possible to have innovative solutions to demanding problems. The system aims to maximize the speed at which new designs can be tested and implemented, while minimizing the effort of the engineers. From imagination to real-time, without ever having to write code.
8/8
References
About the Authors
[1] L. Pollini and M. Innocenti, A Synthetic Environment for Dynamic Systems Control and Distributed Simulation, IEEE Control Systems Magazine, April2000, pp. 49-61. [2] J.C.Stasko, R.L Crandell, M.T. Dunn, N. Sureshbabu and W.Weber, The Versatile Hardware-in-the-loop Laboratory: Beyond the Ad-hoc Fixture, Proceedings 1998 American Control Conference, Philadelpia, PA, June 1998. [3] C.A.Rabbath, M.Abdoune, J.Belanger, Effective RealTime Simulations of Event-Based Systems, Opal-RT Technologies Inc. White Paper, 1999. [4] J.Ozard and H.Désira, Simulink Model Implementation on Multi-Processors under Windows-NT, Defense Research Establishment White Paper, 1999. [5] C.A.Rabbath, Real-Time Simulation: Pentium vs. DSP, Opal-RT Technologies Inc. White Paper, 1999. [6] Christian Dufour, Method for Simulating a Non-linear System, International Patent Application PCT/CA99/ 00501, June 7, 1999.
Paul Baracos, Ph.D., P.Eng., has been involved in simulation and control systems since 1976. He has degrees in Physics, Systems Design and Mechanical Engineering and is a member of the Manitoba Association of Professional Engineers. He joined Opal-RT as Director of Product in 2000. In his spare time he serves as chairman of the ISA Automation and Control Systems Committee. Guillaume Murere, Ph.D., studied Electrical Engineering at École Polytechnique de Montréal. In 1994-1995, he worked at the Research Institute of Hydro-Québec on a parallel version of ST600, the transient stability program of HydroQuébec. In February 2000, he joined Opal-RT where he is now managing the Power System Blockset acceleration project. He is a member of the Quebec order of Engineers. C. A. Rabbath, Ph.D., eng., is a Control Systems Specialist and Consultant for Opal-RT Technologies as well as an Adjunct Professor in the Department of Mechanical Engineering at McGill University. He is a member of IEEE, ASME and AIAA. Wensi Jin, B.S.(E.E.), is the Automotive Product Manager with Opal-RT Technologies. Since graduation from the University of Texas at Austin, he has been working in the field of automotive powertrain control system design and development. His current focus is to apply the cutting edge simulation technologies to the automotive industry.
9/8
