Virtual design methodologies are increasingly being adopted in the development of e-mobility platforms – combining digital models of components with simulation to create a digital twin of an entire vehicle that can be driven before it has even been built.
The drive and handling experience of a vehicle is fed back into the design process, allowing the battery pack and powertrain to be optimised with different topologies and chemistries, all of which can be modelled in the digital twin. Similarly, the noise, vibration and harshness (NVH) resulting from all the components through the tyres and suspension can be analysed and reduced.
As the development of the platform advances, real devices such as the electronic control unit can replace virtual models, adding hardware-in-the-loop (HIL). This allows ECUs to be tuned for optimum balance of performance, range and reliability long before a vehicle hits the test track, potentially saving millions of dollars and months of time in the validation testing process.
HIL can also provide predictive analysis. Running a simulation faster than real time can give data on how the components behave over time, identifying parts that are more likely to fail earlier than expected under particular driving styles. This isn’t a pipe dream. Developers are aiming for an end-to-end entirely digital design process where HIL is a key element. Phil Langley, strategic and business development manager at tier one supplier ZF, clarifies this industry-wide intent:
We are working towards a digital by default design process by 2028, and HIL is a great route to getting there.
Ansible Motion's scalable Delta S3 DIL simulator integrated with Hardware-in-the Loop
Salman Safdar, business development manager at Ansible Motion, adds:
We are seeing a major shift. If you have your model and you want a human to experience that, you need us to bring that human into the virtual environment to bring in the realism of the virtual hardware.
A few years ago, people came to us for a subjective assessment through a driving simulator, but the simulator is just one aspect with MIL and mechanical HIL. We get involved right at the beginning of any development, from the components to modifying existing base models of vehicles. We can quickly load the models on the system, and put a driver in the simulator to tell developers how a driver will feel with handling, safety and performance. We are finding engineers are becoming much more bold in trying different concepts. Now they can push the boundaries with less risk.
To do this, Ansible has developed a unique databus technology that allows all the different HIL technologies, testbed models and simulators to be combined. The distributed data bus (DDB) is driven by a network of Windows PCs with software developed by Ansible Motion.
A traditional simulator connected to a powertrain testbed can cover 80% of calibration and then take it on track for safety validation. This federated HIL system offers the ability to do 95% of calibration. The next step is adding a fully dynamic simulator with six degrees of freedom (6DoF) for 100% validation. Safdar adds:
Dampers are difficult to model in the virtual environment. We have done an integration with four active damper systems with individual attributes when driving on the road, monitoring the dampers, so we’ve taken it to that extreme. Another area that’s difficult to create a good model for is the steering. That’s a nightmare for integration, and we worked with MdynamiX for the physical hardware and integrated their technology into our simulators, so what we offer now is way beyond just the driving simulators.
In our distributed data bus we align the time stamps and synchronise the signals, and present them in real-time to the driver, so we have data-logging coming from different areas, the vehicle physics, and then we take control of their software, which goes into the DDB and then into the motion-control PC. Then we have a growing network of HIL applications, from an IR sensor model to a full powertrain testbed, and even connecting four or five testbeds to have multiple vehicles for sensor interactions.
DDB bus is based on user datagram protocol (UDP) Ethernet packets that offer more deterministic links than other Ethernet protocols. For example, OEMs can run real-time models of different tyres at the DDB level to test vehicle performance under varying conditions. The same applies to testing battery technologies in different virtual vehicles and driving them in a simulator to see how their performance changes.
This allows the detailed models and code used for the development to be reused throughout the manufacturing process in ECUs, and for end-of-line testing, again saving development costs and time, and avoiding the need to redevelop the code for production testing.
Read the full article on the E-Mobility Engineering website.
