PTWinSim provides a framework and supporting functionality enabling several applications to execute together in a coherent timeframe in a variety of hosts. Applications can consist of just about any functionality from full vehicle models, to hardware interfaces through to complex control algorithms or ECU code. The host system controls the execution; therefore, the models can operate in real-time or at a time to suit the host. A host may be one of the supplied windows applications, a block in Simulink, mex function in MATLAB, run as a plugin to a graphical environment or a data analysis package processing a real time telemetry stream, where the applications will execute in bursts as and when new data packets are available.
Examples of PTWinSim’s implementation are (see the slides here):
One of the key advantages of PTWinSim is the ability to reuse your applications in different environments. In the above examples, the Vehicle ECU models are being used by the software developers in a virtual HIL, the vehicle dynamics engineers in the simulator, and systems/control engineers in Simulink to find optimal controller settings.
The partitioning of the applications enables a plug and play approach to selecting which applications to execute together. For the DIL example above, while keeping all other applications the same, the interface to the motion system could be removed to make it suitable for a static/workstation solution, or replaced with a different one, to interface to a different platform.
PTWinSim provides the following key services for all applications:
PTWinSim is delivered with host programs to execute the applications as well as monitoring and programming tools when the host is provided by another vendor.
PTWinSim applications are Windows DLLs with defined entry points and description structures, they can be generated in several ways:
PTWinSim is implemented in such a way to allow all the functionality to be integrated in different host systems with the minimum effort. Some descriptions of actual implementations have been given below, please contact us if you wish to discuss how a bespoke host may be of use to your project.
Marelli develop the unified software that run on all MotoGP bikes using Podium Technology’s @Source in Simulink. Much of the development is done using PTWinSim as a virtual HIL system. The control code is built for PTWinSim along with a plant model to exercise the strategies and loaded into the PTWinSim GUI program and executed in real time. As PTWinSim supports the same MTP protocol used by the real ECU, the engineers are using the same Sysma tool chain to test, tune and verify the software in this virtual environment as they do when they finally test with a real ECU on a HIL system or track. The result is well proven and verified software without the need for multiple expensive HIL systems.
The source Simulink models for MotoGP are proprietary to Magneti and are not available to the teams, however, Marelli do release PTWinSim versions of the models to the teams, for use in their simulations. Teams will typically use the PTWinSim Simulink block that allows for the ECU strategies to be executed. The team then wrap their own bike/systems models around the block and execute it multiple time to optimise whatever system they are focussed on. Prior to each run, they would be updating the file the block uses to parameterise the model each time.
PTWinSim applications can execute in the rFpro driver-in-the-loop system using the plugin developed by Podium Technology. The plugin controls PTWinSim’s execution for starting, running the model and stopping as well as giving PTWinSim applications access to the complete API provided by rFpro through a series of data structures and function call-backs. The tight integration ensures the graphics, terrain and vehicle model are always perfectly synchronised.
Ansible Motion design and build driver in the loop (DIL) simulators for leading automotive manufacturers and motorsport teams. PTWinSim is used in multiple instances throughout the system, the applications are providing cueing algorithms, vehicle models, hardware interfaces (CAN bus, medical, audio etc.) and interfaces to the graphics system. The use of PTWinSim has produced several benefits, among them is the ability to handle different configurations of system easily by mixing and matching applications to suit the installation. Further benefits have come from the ability to swap in and out different vehicle models from different providers for comparison and evaluation purposes.
Ansible Motion’s approach allows for customers to take ownership of certain parts of the system (e.g. their own vehicle model or interfaces to the dashboard), while leaving the core functionality to be delivered and maintained by Ansible Motion.