Article
Articles, Issue 48 - Spring 2013

In the Loop

Over the years, electronic control units (ECUs) have proliferated in the automotive world and modern day vehicles may have up to 90 or more individual ECUs, controlling everything from engines to interior lights.  Due to this, new ways of developing and validating hardware and software have been developed and are known as ‘in-the-loop’ testing.

Model in the loop (MiL)

MiL is where a mathematical model of a physical system or systems can be tested in the virtual world. Here, the control strategies can be written, developed and validated but the main aspect to MiL is that the algorithms can be quickly modified or updated to validate the outputs.

Software in the loop (SiL)

The next stage is to test how different system models interact with each other, using control algorithms. This stage is called software in the loop. SiL can be used to develop real-time software models of control algorithms by taking the ‘rough’ coding from the MiL and developing, validating and implementing the ‘real’ or production-intent coding that will be used in the vehicle controllers. At this point, any changes to the control algorithms cannot be implemented as quickly as in MiL due to how the production intent coding works.

Hardware in the loop (HiL)

HiL is a technique used for the testing and development of real-time sophisticated electronic control systems. It is based on taking the SiL coding and using plant models of systems in a simulation environment. HiL allows test and development of hardware such as an electronic controller connected to equipment that mimics the rest of the vehicle, fooling the ECU into thinking it is actually controlling the vehicle or systems that would be on the vehicle.

Conventional engine control development

A set of control algorithms is either developed from scratch or carry over algorithms are used. These are coded in C or Simulink and can then be loaded into a production or development controller. Engine dynamometer testing can be done using the controller and base-level calibrations can be performed. The next stage is to install the engine into a vehicle and perform open loop testing on a rolling road. Calibration refinements can be made to the control algorithms culminating in open and closed loop testing on a test track. In a similar way to suspension tuning, lots of iterations can be tried until it feels right.

Strengths of conventional development 

It is a well established process with minimal, if any, investment in facilities required. The testing can start quickly particularly if the vehicle is already running. A ‘quick and dirty’ approach can be taken if this is appropriate. This won’t create a refined solution but will get results fairly quickly.

Weaknesses of conventional development 

Only open loop testing is normally conducted on rigs, this has limitations as real life (closed loop) testing can only be done with a vehicle that is representative and reliable.

Testing is limited by time, cost and track availability, therefore only a limited range of combinations or iterations can be tried. Tests for specific responses are not reliably repeatable as there are human factors, road and ambient conditions included. Safety or failure related issues are difficult or even may be too risky to test. Additionally, it is difficult to test any interactions with other systems in the vehicle.

What is required to address the shortcomings?

The shortcomings of conventional design, development and testing can be addressed by the use of hardware and software that simulates real life driving, analysing how the vehicle systems interact with each other and how the systems are electronically controlled. Development of objective criteria against which to evaluate the simulations is important so that the boundaries of pass and fail criteria are understood. The simulation system can facilitate real life closed loop testing when it is linked to a test rig or dynamometer, proving that the process can be demonstrated and create real results.

Simulation of real life driving

Using proprietary software, a dynamic simulation model of the vehicle can be created. To get the most out of the simulation (virtual testing) there needs to be refined models of the systems that are part of the vehicle model but once this is done, the model can be connected to a virtual test driver for closed loop tests and virtual roads for a variety of topology and configurable test manoeuvres. This means that we have virtual driving testing where any parameters are available as ‘measurements’.

Real life driving with controllers

Virtual test driving can be undertaken with a virtual vehicle, with virtual electronic controllers on virtual roads. The vehicle can be developed to a good level on the test bench or laptop. Algorithms can be validated against aims and targets in a perfect environment i.e. always repeatable with no human errors. At this point it is possible to quickly change algorithms, strategy and calibration.

One aspect of this that cannot be overlooked is the ability to support failure modes effects analysis (FMEA) and safety analysis. This is where the limits in safety can be explored without endangering a real test driver or an expensive prototype vehicle. This is particularly important for the latest developments in electric drive systems where individual wheels can be driven with individual motors. Many ‘what if’ scenarios can be played out in virtual testing and faults can be artificially inserted. Aside from the benefits in testing safely, virtual testing allowed over 3,000 scenarios to be computed and run through in 24 hours, showing that significant development time can be taken out of a programme if real vehicle testing can be supplemented or replaced with virtual testing.

Real life testing on the rig

Moving on from SiL, now we have a model simulating the vehicle in real time so instead of emulating the electronic controller and its software we can exercise the real hardware as if it was in a real vehicle. Inputs to the controller come from signals generated within the plant model and drive signals from the controller interpreted as inputs to the model. This is virtual test driving the controller hardware and can be used to validate that the control algorithms, implementation and hardware meet the design criteria.

HiL is not just for the controller

The HiL boundary can be drawn anywhere and other pieces of hardware could replace its modelled (SiL) counterpart. For example, as well as a physical controller, a physical electric drive motor could replace the virtual one, a real engine, a real battery pack etc. Another aspect would be that the controller may still exist in software but it is controlling a piece of hardware like a steering gear or brake system mounted to the rig. An engine could be on a dynamometer and run as if it is in a real vehicle. Ultimately, a whole vehicle could be in the emissions lab and do virtual test drives under open or closed loop control as if it was driving different emissions routes. An electric vehicle, or just its motor and battery could drive different routes, with or without traffic, to test its range with different energy management strategies.

Additionally, HiL provides a platform to bench test multiple network communication systems alongside multiple ECUs and this is the industry standard of proving whole vehicle systems. At a practical level, there is the potential to decrease the number of expensive prototypes that form part of a vehicle test and validation programme.

Summary of benefits of using HiL

Integration of electrical systems is at the core of HiL and it can provide a quicker means to development and validation compared with the traditional design-build-test methodology. Fault and safety analysis can be conducted in a manner that doesn’t put personnel or expensive prototypes at risk. Controllers that are not yet available can be emulated and when controllers are available, they can be tested and networks proven before they are assembled into the vehicle. Complex system interactions can be developed and tested with automated execution, analysis and documentation. Tests are repeatable and can be done before a vehicle is built. More rigorous and varied testing can be conducted on a 24/7 basis and this simulation and testing can be used to homologate type variants rather than building and testing actual vehicles.

Writer: Phil Barker, Chief Engineer H&EV, Lotus Engineering

About lotusproactive

Lotus proActive is an e-magazine published quarterly by Lotus Engineering, covering engineering articles, industry news and articles from within Group Lotus (Cars, Engineering, Originals and Racing).

Discussion

Comments are closed.

%d bloggers like this: