Implementing Hardware-in-the-Loop (HIL) Test Systems Christian Hahn National Instruments Abstract: As the complexity of embedded devices increases, so do the testing challenges for these devices. Hardware-in-the-Loop (HIL) simulation is a test technique that can help solve these challenges. In this session, we will examine what HIL simulation is and why it is useful. We will also review a general architecture for building a HIL test system and discuss a variety of methods for using 3rd party models/simulations inside LabVIEW. Level: Beginner National Instruments CONFIDENTIAL

National Instruments Leadership Seminar April, 2002 Closed-Loop Control Disturbance Measured Speed Desired Motor Controller Motor Command DC Motor - In this presentation we will discuss what HIL simulation is, why it’s useful, and how to create HIL test systems in LabVIEW - HIL Simulation is used in the testing of systems or products that have embedded control - An example of such a system is a DC motor that needs to maintain a specified speed in spite of any disturbances it may endure such as an increased load on the motor [animate] - To accomplish this, we would use a closed-loop controller that would compare a desired speed set-point to the actual, measured speed of the motor and adjust the output/motor command to compensate National Instruments CONFIDENTIAL

National Instruments Leadership Seminar April, 2002 Closed-Loop Control Engine Control Navigation Control Flight Control Steam Turbine Control - For the purposes of today’s session, we are using this very fundamental control system, however similar, but more sophisticated control systems can be found in a variety of applications/systems as the application complexity, consumer expectations, and regulatory demands necessitate the use of embedded control to meet design requirements. examples: green engineering to improve efficiency of power generation – steam turbine meet fuel economy and emissions regulations – engine control energy efficiency – dryer cycle control application complexity – print head control, flight control, medical device control Dryer Cycle Control Print Head Control Medical Device Control National Instruments CONFIDENTIAL

Example…the automobile National Instruments Leadership Seminar April, 2002 Example…the automobile 3 ECUs  15 to 70 ECUs in 10 years The number of ECUs in most automobiles has climbed from 3 to 15 and to as many as 70 in high end automobiles such as the Mercedes S-class and 7-Series BMWs. Typical ECU Modules (from SAE Paper 2005-01-1658 – HIL Testing of Networked Electronics at Ford) Anti-Lock Braking Controller Audio Control Unit CD Changer Controller Door Control Unit Display Control Unit Automatic Temperature Control Unit Power Assist Steering Controller Headlamp Control Module Navigation Module Parking Aid Module Powertrain Control Unit Restraints Control Module Transmission Control Module Electronic Stability Control Module As the number of ECUs climb the requirements on the in-car network start changing, they need to be faster and deterministic. This is how new networks like FlexRay have come, other networks like MOST (Media Oriented Systems Transport) and IDB (Intelligent Transport System Data Bus) are entering to connect the infotainment portion of the car. It is expected that by 2010 the % of electronics in your vehicle will be close to 40% as this study by ABI Research revealed. By consequence it is predicted for the next 10 years an increase of 10-15% of software in the share of costs of a vehicle every year. McKensey study, 2002 Industry experts see several advantages to the use of electronics, electric systems inherently are more reliable, more efficient, add less weight to a vehicle and can offer more functionality than can mechanical systems. Moving to more reliable ECUs means a safer car, fewer hits on a warranty and fewer recalls. Electronics promises to play a bigger role as automaker move to more innovation in hybridization and alternative fuels sources. National Instruments CONFIDENTIAL

Embedded Control System Challenges Test Challenges Increasing application complexity Increasing reliability requirements Decreasing time-to-market Reduce development cost Test Resources - Applications/systems today are increasing in their complexity which is as a result, increasing the demands on the design and test engineer - You are expected to solve harder problems, with greater results in less time and at a lower cost. [animate] - It would seem that these demands cannot be simultaneously met - however, HIL simulation is a tool that helps the address these challenges making testing of these systems more efficient allowing you to maintain reliability and budgets even as your testing challenges grow Are these mutually exclusive?

Testing Embedded Control Systems System Level Testing Test System Test Profile Logging/ Analysis UUT Disturbance Desired Speed Motor Controller Motor Command Measured Speed DC Motor - To understand how HIL simulation accomplishes this, let’s take a look at how we test the embedded control systems on our products/systems - Returning to our DC motor control system example, to test this system we would create a stimulus-response test shown here [animate] - A test profile would apply a stimulus to our system in the form of a desired set-point/operating condition and a series of disturbances (motor load/faults) that it should be able to handle - Our test system would monitor the response of our system to determine if it is performing as specified

Testing Embedded Control Systems System Level Testing What if the “DC Motor” is not available yet? What if test failures could damage the ”DC Motor”? What if the ”DC Motor” is very expensive (capital, maintenance, operation, facilities)? What if ”DC Motor” conditions are not repeatable? What if there are numerous variations of the ”DC Motor”? DC Motor Motor Command Measured Speed Disturbance - But there can be many challenges with creating this kind of system-level test for a closed-loop control system - In our simple system used for demonstration today, these issues may not seem realistic, but consider the applications presented a couple slides earlier and it is easy to see the potential impact of these challenges [animate and read through the bullets] - not available: many times, the controls for a system are developed in parallel to the system itself. The complete system is not always available when the controller is ready to be tested which can cause delays in time-to-market - damage: if this costly or one-of-a-kind system is available, what if a test failure damages the system (cost, time) - expensive: to keep reliability high, numerous tests are required – many of these systems are costly to build, and have high operation/maintenance costs associated with them. So increasing/maintaining test coverage could be cost prohibitive - repeatable: the dynamics of many of these systems can make it difficult to perform repeatable tests – so if a problem is identified, it can take a considerable amount of time to determine the cause of failure and validate that it has been resolved - variations: if the product you are testing can have many variations, it could require the creation and maintenance of numerous, similar test systems (ex 6-, 8-, 12- cyl engine test stands) - So you can see that system level testing of closed-loop control products presents many challenges. - HIL simulation addresses these challenges by providing a virtual or simulated system to allow you to test your embedded control unit without the “DC Motor” – the rest of the system that interfaces to you embedded control unit - We’ll see in this presentation, that although HIL simulation does not eliminate the need for this kind of testing, it does allow us to test more efficiently - performing only the necessary numbers of system level tests and no more. - This allows us to maintain reliability and time-to-market requirements in a cost-effective manner even as our products become more complex.

Testing Embedded Control Systems Component Level Testing Test System Test Profile Logging/ Analysis UUT Disturbance Desired Speed Motor Command Motor Controller - Before we look at how HIL simulation works, let’s look at another alternative, component level testing - In component level testing, we eliminate the part of the system that is presenting the challenges mentioned in the previous slide and test only the embedded controller [animate] - For this type of testing, we provide the same set-point stimulus in our test profile and log/analyze the results, however our UUT, the embedded controller, is missing the feedback input(s) that would typically be provided by the rest of the system. - Therefore, we must add these signals to our Test Profile - However, this makes it very difficult to test the controller’s response to the disturbances that our system may experience. We could attempt to represent these in the changes to our test profile, however the dynamics of most of these kinds of systems make it very difficult to do this accurately and achieve the necessary test coverage Measured Speed

National Instruments Leadership Seminar April, 2002 What is HIL Simulation? Types of Test Functional Parametric Validation (V&V) Durability (HALT/HAST) End-of-line … Test Methods Temperature/power variation Salt/sand spray EM radiation Mechanical loading/resistance HIL Simulation … - To begin to understand what HIL Simulation/Testing is, let’s first consider the types of tests we perform. These are all types of test created for different purposes in the development of our products. [animate] - Independent of these types of tests are numerous “test methods” that may be applied in the creation of a type of test depending on the goal/purpose of the test. - HIL simulation is a test method that provides a virtual reality for your UUT – it simulates the world around the UUT, the embedded control unit, so that you can perform a system level test on your embedded controller without the rest of the system minimizing the impact of the challenges mentioned earlier (availability, cost, safety, etc) National Instruments CONFIDENTIAL

Virtual Reality for your UUT What does your UUT know about the world around it? UUT Voltage Desired Speed Motor Command Current Motor Controller - To understand how HIL simulation works, consider what your UUT “knows about the world around it” – how does it interact with the real world. [animate] - Everything that the UUT “knows” about the world around it is through sensors and actuators - therefore, if we can preserve the voltage, current, load, and timing characteristics of the rest of the system, the UUT will not “know” the difference in being connected to the real system or a simulated version of it. - It’s worth noting that real-time (RTOS-based) test systems are necessary to implement HIL test systems because the timing must be preserved on a point-by-point basis, you cannot used buffered outputs (Load/impedance simulation is necessary to test the hardware aspects – as opposed to algorithm aspects – of the UUT. It must experience the same current draw, attenuation characterists) TCP PWM Impedance Measured Speed Timing ENCODER

Testing Embedded Control Systems Virtual System Level Testing Test System Test Profile Logging/ Analysis MODEL UUT Desired Speed Motor Command Motor Controller - If we can do this, then we can create a virtual reality for our UUT and perform “virtual system level testing” on our UUT, the embedded controller, without the complete system - This kind of test system, a HIL test system would look like this - We would have the same stimulus/response configuration as our real system level test [animate] - however we will use a model to provide the feedback inputs to the UUT that it expects from the system it is intended to interface to. - The model takes into account the response of our UUT as well as the test profile to produce the next stimulus point for our UUT. This allows certain stimulus to be calculated dynamically on a point-by-point basis to provide an accurate simulation of the rest of the system interfacing to the UUT - The stimulus is a function of the response of the UUT to the previous stimulus Measured Speed Stimulus = MODEL(test profile, UUT response)

Testing Embedded Control Systems Virtual System Level Testing Test System Test Profile Logging/ Analysis MODEL UUT Desired Speed Motor Command Motor Controller The key element of this type of test system is the model – so what is a model? Measured Speed Stimulus = MODEL(test profile, UUT response)

National Instruments Leadership Seminar April, 2002 What is a Model? - A model is simply an equation, a math function that represents how the output(s) of a system are affected by the input(s) to the system - Take this system shock absorber system as an example - A physicist would look at this system as a mass-spring-damper system shown in the free-body diagram to the left of the shock absorber - From this diagram, you could derive a math expression seen on the bottom left with the variables being: - characteristics of the system (spring constant, damping coefficient) - inputs to the system (road input). - The result of the equation is the response or outputs of the system – in this case the position of the mass it is attached to. - Here you can see two forms of this model, a textual form and a graphical form created using LabVIEW - Models are simply mathematic equations, so they can be created using many tools. c m k National Instruments CONFIDENTIAL

National Instruments Leadership Seminar April, 2002 Dynamic System Models NI LabVIEW ANSI C MapleSoft MapleSim …here are a few examples. The MathWorks, Inc. Simulink® Software Esterel SCADE NI MATRIXx SystemBuild Simulink® is a registered trademark of The MathWorks, Inc. All other trademarks are the property of their respective owners. National Instruments CONFIDENTIAL

National Instruments Leadership Seminar April, 2002 You Need a Model… Test System Test Profile Logging/ Analysis MODEL UUT Desired Speed Motor Command Motor Controller So to build a HIL test system you need a model – so where do you get a model and how do you use it with LabVIEW to create a HIL test system? Measured Speed Stimulus = MODEL(test profile, UUT response) National Instruments CONFIDENTIAL

Control Design Process System Testing Modeling and Design Targeting Rapid Prototyping Hardware-in-the-Loop Testing

Modeling and Design Kc Controller Control Output Kp Plant Setpoint Error Feedback Modeling and Design Produce Controller and Plant Models A key component of shrinking the “V” through model-based design is to begin developing the embedded control as early in the design cycle as possible. Modeling and simulation, provides the ability to begin simulating control behavior while hardware prototypes are still unavailable. In addition, models from previous designs may be reused to further reduce the effort necessary to produce a model. If prototype or existing hardware is available, the modeling effort may be complemented by using real-world input/output data to produce models with system identification techniques. Software tools such as LabVIEW Simulation, Simulink® or MATRIXx offer a variety of advanced control design tools in an interactive environment that helps the designer quickly evaluate a control system without the need for prototype hardware. This capability provides the design engineer with the ability to determine specification, requirements, and modeling errors immediately instead of waiting for testing later in the design flow.

Modeling and Design Software Tools NI LabVIEW Simulation Module NI MATRIXx The MathWorks Inc., Simulink® Application Software MSC CarSim Hand-coded models (C, Fortran, etc.) Engineers use various tools to model and design control systems. The National Instruments LabVIEW Simulation Module integrates dynamic system simulation into the LabVIEW environment. You can model linear, nonlinear, discrete, and continuous plant or control systems in block diagram form within the simulation node, then execute the simulation on Windows or real-time hardware. The NI MATRIXx product family is an entire control design suite of software that includes SystemBuild, an easy-to-use graphical environment for rapid model development and simulation. SystemBuild is an excellent environment for the development and management of large, complex models. In addition to the National Instruments modeling and design software tools, the NI platform is open to integrate models and code that have been created with other software, including models developed in the MathWorks Inc. Simulink Application Software, MSC CarSim as well as hand-coded models developed in C, Fortran, etc. Because of the open architecture of NI software and hardware, you can instrument models from almost any software. Simulink® is a registered trademark of The MathWorks, Inc.

Rapid Control Prototyping Kc Controller Control Output Kp Plant Setpoint Error Feedback Creating a Functional Prototype of the Controller Since software simulations cannot account for all of the unique behaviors of an actual dynamic environment, a hardware prototype is developed to aid in the testing of the control algorithm in real-time. This is rapid control prototyping and is the second stage of the control design V diagram. As shown in the Figure, the controller design is tested in a real-time environment and connected to the real or simulated plant. This provides excellent verification and validation feedback on the fidelity of the modeling effort and the resulting control design early in the design flow. Further refinements to the controller and hardware designs and requirements can be made prior to finishing the design of the production systems. [Animate] You can use any of the NI real-time hardware platforms to implement a prototype. CompactRIO is a good example to be the prototype because of it’s form factor, ruggedness, and flexibility.

Hardware-in-the-Loop Simulation Control Output Kc Controller Kp Plant Setpoint Error Feedback Testing Production Controller with Simulated Plant

HIL System Architecture Host PC Loads / Power Real-Time Simulator Fault Insertion Unit (FIU) ECU

National Instruments Leadership Seminar April, 2002 Loads, Power, and Faults Simulated & Real Loads Physical loads that would be seen by the ECU Break-out & Power Supplies Panel for manual fault insertion and custom loads Fault Insertion Unit Programmatic fault insertion of open, short to Vbatt, short to GND, ch-to-ch Break-out Panel Power Supplies Simulated and Real Loads Fault Insertion Unit (FIU) Simulated & Real Loads Physical loads that would be seen by the ECU Typically in a separate housing with active cooling Custom Loads & Power Supplies Manually configured, but can be programmatically switched during simulation Can implement ch-to-ch shorts with or without resistance Fault Insertion Unit Facilitates switching of custom loads and power supplies Programmatic fault insertion of open, short to Vbatt, short to GND National Instruments CONFIDENTIAL

HIL Functional Architecture National Instruments Leadership Seminar April, 2002 HIL Functional Architecture User Interface Data Manager Model Manager Test Sequence Analysis & Reporting Host Simulator Interface IO Interfaces Datalogging Sequencer/Profiler RT Simulator Plant Model Simulated Fault Insertion RT IO Interfaces Power Supply Bus IO DMM/ Scope FPGA IO AIO/DIO Vision RF / GPIB Cal / Diag Interfaces IO SigCon Fault Insertion Unit (Switching) Break-out ECU Loads National Instruments CONFIDENTIAL

Manufacturing test of hydraulic actuators Customer: Parker Hannifin Application Integrate measurements with control Control actuator movement deterministically Easily change motion profile for each unit Solution LabVIEW Real-Time Modular PXI hardware platform NI DAQ I/O modules Saved 44 weeks of development time and reduced cost by 6x Saved 44 weeks of development time and reduced cost by 6X

Lockheed Martin Simulator (PXI, LabVIEW Real-Time, SIT, VISA) Application Prototype integrated avionics unit in XSS-11 Create hardware-in-the-loop/HIL simulator to test LIDAR (light detection and ranging system) controller Key points LabVIEW and NI hardware provide future flexibility NI helped create an interface to a third-party synchronous serial interface using NI-VISA LIDAR= light detection and ranging control software functionality. The Lead: Customer was interested in MATRIXx and called DSM to discuss purchase price. During discussion the DSM uncovered the need to perform HIL/RCP test. The Competition: Customer was planning on purchasing Opal-RT hardware for the HIL/RCP tester until DSM probed and uncovered opportunity for SIT Why We Won Support – NI had a large install base of LabVIEW users at Lockheed that could provide assistance on the project. NI also provided local onsite support (DSM) LabVIEW – Customer felt that LabVIEW would enable them to quickly program a solution Openness – Because SIT is built on top of LabVIEW the customer felt that they would be able to implement new requirements as they were uncovered