Open, Scalable Real-Time Solutions Background Introducing TestDrive TestDrive Hardware TestDrive Software

Open, Scalable Real-Time Solutions Background Introducing TestDrive TestDrive Hardware TestDrive Software Martin Belanger Director of sales September, 2010

ECU Testing Challenges Growing number of ECUs in new vehicles Growing number of ECU variants Growing amount of control software to test At the same time: Static simulators are becoming inadequate Dynamic simulators are powerful, but require more time (model development), training (operation) and money. Note on dynamic simulators - RT-LAB Engineering Simulator (HILbox based systems) is primarily used for ECU validation, which is towards the end of the development cycle. No one disagrees the use of hardware in-the-loop, and the fact that HIL has been successfully used for ECU validation for many years. The reality is unfortunately somewhat different. At this phase of development, the customers often have running vehicles, which provides for a reasonable alternative to HIL. This factor, coupled with the investment needed to set up an HIL system and to correlate a plant model, slows the adoption of HIL. TestDrive, on the other hand, is designed to serve ECU software development teams.

Progression of ECU use in Vehicles Electronics share of a vehicles’ value: 2001-2010 (Source: ABI Research)

Difficulties with Static Simulators The current static simulators lack: Configurability Expansion for new I/O types and higher pin counts Support for dynamically linked I/O channels such as VVT Data bus simulation Support for test automation Support for plant models Support for remote access . . .

Press Ctrl-Alt-Del to restart Power Steering Error PS_CONTROLLER.exe has caused a fatal error. If the problem continues, please contact your vendor. Press Ctrl-Alt-Del to restart

Next Generation – Design Objectives Support users accustomed to static simulators and their simplicity Provide a repeatable test environment at low unit cost Provide a model-based simulator to those who may not be familiar with real-time dynamic simulation As mentioned earlier, TestDrive is designed primarily to serve the ECU software development teams. Many such teams use static simulators today. Static simulators are simple to use, but they nevertheless have many limitations. Our challenge is to design a simulator that is not only powerful but also simple enough to use. Our goal is to provide software engineers and test engineers the same look-and-feel of a static simulator and its ease of use, yet the design will include the use of a Simulink model and support test automation. The three keys are ease-of-use, low unit cost, and model-based.

Open, Scalable Real-Time Solutions Background Introducing TestDrive TestDrive Hardware TestDrive Software Mathieu Dubé-Dallaire Application Engineer August 30th, 2005

Introducing TestDrive Compact, robust chassis Intel Core 2 Quad processor I/O modules with integrated signal conditioning and protection TestDrive graphical user interface TestDrive automation scripts Cost-effective replacement of static simulators Scalable from static (open-loop) to dynamic (closed-loop) Powered by a mature RT-LAB and QNX real-time platform Modeling done using Simulink

TestDrive is more than an HIL Simulator Unlike a traditional HIL simulator, TestDrive is: Mainly for open-loop testing, can be used for closed loop Primarily for functional test during ECU development Inexpensive to buy and to operate Does not requires model development Requires minimal set up time Does not require Matlab/Simulink/RTW to run Can be used by software engineers with no modeling background (users of current static simulators) Affordable - can be deployed in large numbers

Open, Scalable Real-Time Solutions Background Introducing TestDrive TestDrive Hardware TestDrive Software Mathieu Dubé-Dallaire Application Engineer August 30th, 2005

RT-LAB TestDrive – Hardware Highlights Software configurable I/O hardware Software selectable rail voltages for ECU inputs No jumpers, no DIP switches Initialization script for one ECU – allowing one simulator to be shared among multiple projects Software configurable power moding Software selectable engine crank/cam patterns Each pattern is specified as a MAT file Robust design I/O channels have built in over current protection in case of an incorrect connection or faults

RT-LAB TestDrive – Hardware Highlights Modular, compact and high channel count Over 200 IO channels using 7 slots, with 4 spare slots Designed to meet testing challenges for the next generation ECUs. Multiple systems can be linked for additional capacity Harness and connector ID 5 dedicated pins on each connector for connector Ids 16 dedicated pins on each harness for harness Ids Models and test script can check to make sure the proper ECU is connected using these IDs.

RT-LAB TestDrive – Chassis 25A power moding lines and connections including battery voltage, ignition, accessories, radio. Slots for I/O modules with signal conditioning and monitoring Real-time target computer with Core 2 Quad CPU TCP/IP connection to host PC Rear high-density 56-way ELCO connectors for direct ECU connection PCI slots for optional modules, such as CAN bus, GPIB, and IEEE 1394 10U desktop simulator, external dimension: 17” (w) x 16” (h) x 12” (d)

RT-LAB TestDrive – Modules Common to all modules: FPGA-based daughter board: Maximizes commonality between modules Contains I/O logic for each module Protected from the I/O stages to minimize replacement cost in case of failures Prototyping area for custom circuitry

RT-LAB TestDrive – BM & PDL Base Module (BM) Power moding (8) Communication activity and general purpose measurement (10) Pulse Driven Load Module (PDL) Measures analog & discrete states as well as pulse width (PWM) for each channel (39) Resistive loads on all channels

RT-LAB TestDrive – RPG & SM Reference Pulse Generation (RPG) Variable cam (4) Crank and other reference pulses (11) Cam and cranks have a selectable output stage: open drain, +/- 12v, 0-Vbatt, 0-5v Spark and injector capture (24) Knock simulation (2) Switch Module (SM) Digital output board with configurable rails (43)

RT-LAB TestDrive – ASM, POM & RSM Analog Sensor Module (ASM) Ratiometric analog outputs (16) Pulsetrain Output Module (POM) Digital PWM outputs with analog mode True 0% and 100% capability Resistive Sensor Module (RSM) Programmable resistors (12) Current monitoring and feedback 0.5 ohm to 200 kilo-ohm range

Open, Scalable Real-Time Solutions Background Introducing TestDrive TestDrive Hardware TestDrive Software Mathieu Dubé-Dallaire Application Engineer August 30th, 2005

RT-LAB TestDrive – Software Highlights Designed for ECU software testing, TestDrive combines: Static simulators’ ease-of-use TestDrive GUI Tactile Interface Module provides a unique combination between real-time simulation and touch-and-feel operation Optimized for software or test engineers No Matlab/Simulink and no modeling Hardware configured in software Automated testing: scripts can be reused and easily shared Low cost for deployment in large numbers

RT-LAB TestDrive – Software Packages Included (base) with each simulator: TestDrive GUI (for interactive use) RT-LAB Run-time Python scripting language (for test automation) Open-loop model (precompiled) For model development (closed-loop), add: Matlab/Simulink/RTW to create or modify your simulated model (engine, vehicle, …) RT-LAB development license to compile and run your model in real-time For custom GUI development, add: LabVIEW base license to develop your own virtual instrument (VI) panels

RT-LAB TestDrive and Simulink I/O channels are defined in Simulink By running a model, TestDrive takes full advantage of Simulink, for both open-loop and closed-loop testing Yet, the TestDrive GUI hides the model from the end users so they don’t need to learn Simulink Simulink is needed only for development system, which helps lower the overall deployment cost The simulator is characterized in Simulink, as you define I/O channels, scaling, and (if any) dynamics there. The GUI does a good job separating the users of the simulator (and the model) from the developer of the model. The advantages of this approach include Reduced learning curve – you don’t need to learn Simulink or to study the model in order to use the simulator for interactive or automated testing Reduced tooling cost – you don’t need to buy Simulink, RTW, or even Matlab and LabVIEW for every simulator Enhances sharing of test environment without having to share the model. You can ship a TestDrive to your customer or supplier and they can benefit from the test environment including the model, but they won’t have access to the model unless you provide it to them.

RT-LAB TestDrive User Interface The TestDrive interface runs on a laptop or desktop host or directly on a tactile interface module The TestDrive interface animates and monitors a graphical panel (included or user-designed) with signals to/from the real-time system Signals can be assigned to graphical elements in real-time and the configuration is saved for each project New panels are created and edited from LabVIEW, but no wiring is needed, just the graphical layout How LabVIEW has been used with RT-LAB? You build GUI panels, you wire up the logic on the diagram, and you have to match up signals in the model and the GUI object by using an index for each signal. Now you can use LabVIEW with the simulator without doing wiring in LabVIEW

RT-LAB TestDrive Configuration Scripts and Macros Python Editor Graphical User Interface Software for test set up and simulation control running from Windows host PC.   System Configuration Panel RT-LAB TestDrive Interface Module Configuration Panels Real-Time Simulation RT-LAB Panel Design Interface LabVIEW and compiled LabVIEW Model Design Matlab/Simulink Signal Mapping Interface

RT-LAB TestDrive Software Packages Simulator Engineers Configuring simulator Customizing models Very few of these engineers Tools: RT-LAB Matlab/Simulink/RTW ECU Systems Engineers Customizing panels Setting-up automated tests Tools: TestDrive GUI LabVIEW Python Software and Test Engineers Performing interactive tests Customizing test cases Executing test cases Tools: TestDrive GUI Python Based on our discussion with OEMs and suppliers, we defined three user profiles, each with its set of tools. Within a larger team, different engineers may take on each of the three roles (profiles), but in smaller environment one person may wear more than one hat. Example: each system includes a copy of RT-LAB run-time, TestDrive GUI, and Python. Now, when you have a lab of 10 simulators, how many copies of Matlab/Simulink/RTW do you need? Probably just one. How many copies of LabVIEW do you need? Well, between 1 and 10, it is based on the number of engineers who will be customizing GUI panels. What level of LabVIEW license do you need? Base. Number of Users

Where Does RT-LAB TestDrive Fit … in the design process (TestDrive vs. Full Scale Dynamic HIL Simulators) Design Specification & Requirements Definition System Validation Signal Mapping and Power Moding Module Power Supply Plant Simulation Integration Testing Controller Algorithm Development Functional Checkout We have been serving users for ECU validation (towards to the end of the V) for many years with the RT-LAB Engineering Simulator. This is the area that the computing power to run high-fidelity closed-loop plant models and the flexibility to interface with many ECUs are important. Simulators tend to be used in smaller numbers and shared by teams. In the area of software development, we see needs for a larger number of simulators, each of which is typically used by one or two engineers. They need to run the simulator in open-loop mode and closed-loop, and switch back and forth. Again, these systems have to be simple to set up and simple to use. Note: running the simulator in open-loop means that the system is quick to set up. But more importantly for software development teams, running the system in open-loop is sometimes the only viable solution. At this stage ECU software is often incomplete (for example, the ECU may contain low level I/O driver software only and no control algorithm, or it may have control algorithms implemented in software but they are not properly calibrated). As a result, the ECU may not have fully functional software to interact with a closed-loop model, or it may contain enough working software to partially close the loop. Instead, running open-loop allows the users to verify individual I/O functions in the ECU by directly controlling outputs from the simulator and monitoring the outputs of the ECU. Coding and Unit Testing

TestDrive Design Highlights - System Fast time to productivity with your simulator Connect ECU to your simulator Install GUI software on your host PC Point GUI to the simulator, you are ready to configure I/O channels in GUI

Fully Programmable Powertrain and Vehicle Simulation for ECU-in-the-Loop Testing Compact and robust platform Comprehensive modular I/O set Fully software configurable Built-in signal conditioning and protection Open-loop ready with zero set up time Upgradeable from open-loop to closed-loop Automated testing Easy to use Affordable Tactile interface No auxiliary software cost for open-loop © 2005 Opal-RT Technologies Inc