INTERVIEW
through the accelerator, and realistic throttle control behaviours from the driver. You can then connect hardware into the loop via a HIL rig and use that to load the battery, the motor and the inverter in real time. That’s going to be far more representative of the thermal state of the battery than attempting to model it in software.
Ansible Motion’s simulators are all designed around the company’s Distributed Data Bus (DDB) concept. This centralises the communication between the various hardware and software modules that make up the simulator. One of the key benefits of this approach is that it simplifies the task of adding external hardware or software into the loop. In the initial phase, the entire vehicle might
“
As lead times and development budgets get squeezed, third party suppliers don’t always get as much access to physical prototypes as they might like. DIL simulation can be used to plug this gap, and Ansible Motion’s DDB architecture means that technology from different developers can interact with the same model without comprising intellectual property in either direction.
be modelled in software to verify the concept’s feasibility and begin laying down specifications for the production hardware. As the design matures, however, it’s possible to substitute virtually any aspect of the simulated vehicle with real-world hardware. Common examples include vehicle control units, ADAS sensors and even full powertrains.
One of the benefits of the DDB approach is that everything is available in one place. It’s all there in one file, so you don’t have to try and synch up four or five different log files to understand what’s happening in different parts of the system. The simulator also captures all the other things that you might not realise are relevant when you design the test. We have full control over the environment and the scenario, so we can really understand what led to a particular event.
The absolute repeatability offered by DIL testing brings its own merits. The same tests can be performed over and over again without changes to the environmental conditions, for instance, to isolate the variables that you want to investigate. Similarly, the test conditions and the scenarios can be changed at will, such as going from an urban environment on a cold day to a highway running through the desert. Carrying out this testing in the digital domain can be far more cost-effective than transporting physical prototypes around the world, and it removes the risks of weather disruption.
DIL simulation helps to reduce the need for real world testing. Development vehicles can cost upwards of a million pounds each and test mile accumulation is costly as well, so if you can reduce the number of physical prototypes and road miles that are required, a DIL simulator can pay for itself in a single project.
Another point to bear in mind is that physical prototypes are not necessarily that representative of the finished product. Mule vehicles adapted from the previous generation model or another vehicle in the manufacturer’s portfolio can be a pretty vague approximation to the intended design – especially if that’s radically different to the current technology. This has always been an issue in the automotive industry, but it’s one that has become particularly acute as the rate of evolution speeds up. Many OEMs are currently
contemplating challenges such as their first dedicated EV platform or the adoption of semi-autonomous driving capabilities. These can involve a step change in technology, which makes it harder than ever to infer meaningful results from existing designs. In some cases, OEMs are confronting challenges that they simply haven’t encountered before. There’s always a risk of playing it too safe when you’re weighing up the time and money that’s going to be invested into physical prototypes, whereas DIL simulation allows you to evaluate more leftfield concepts at far less risk.
As lead times and development budgets get squeezed, third party suppliers don’t always get as much access to physical prototypes as they might like. DIL simulation can be used to plug this gap, and Ansible Motion’s DDB architecture means that technology from different developers can interact with the same model without comprising intellectual property in either direction.
Offline testing can handle the bulk of the work when it comes to things like durability cycles. When it comes to functional testing, however, the results that come out are only ever as accurate as the inputs that go in. And to truly capture that complexity there’s sometimes no substitute for having a driver in the loop.
Ansible Motion
www.ansiblemotion.com MARCH 2022 | ELECTRONICS TODAY 37
”
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46
