In 2024, the IndyCar series will become the latest championship to employ hybrid technology. To prepare for this here at Claytex, we have added support for hybrid systems to the IndyCar vehicle models as part of our VeSyMA – Motorsport library. It promises to be an exciting addition to the IndyCar Series, which already features close and compelling racing.
It does however present some problems to be solved by the teams, and some questions to answer. Adding motors and battery packs to the vehicle will impact its mass distribution, which will impact the handling; optimising hybrid harvesting, and regeneration, will also have a profound effect on the overall lap time. As such, addition of this feature in the VeSyMA – Motorsport library was required. Happily, it so happens to provide an interesting case study into the mindset and ethos of customer lead development here at Claytex.
A Template for Success
As with implementing any feature, thought needs to be given to how the user will utilise it. Ignoring the end user at the early stages of development will result in a feature which does not satisfy the customer’s needs or presents further problems. Such thoughts were at the forefront of our minds when work began to implement hybrid support in our IndyCar model.
Good library development practice dictates that models should be structured in such a way that model maintenance – the work undertaken to update the models to new versions of base libraries or implement enhancements and bug fixes – is kept to a minimum. This is done by intelligent use of templates, interfaces and extending from models wherever possible.
Figure 1: By extending from the base IndyCar model, all model maintenance undertaken on the IndyCar model is automatically enacted in the hybrid model, vastly reducing library management overheads. As the hybrid system is a “bolt on” addition to the IR-18, these components have not been redeclared as “replaceable”, as it is envisaged that this model will be the end of the chain with any other developments occurring in the base IndyCar model.
Adding the hybrid functionality to the IndyCar vehicle model presented a challenge, as hybrid support requires additional components, not just the redeclarations of existing ones. One method would have been to simply extend from the original IndyCar model, declaring the additional components in the new vehicle model. This, however, would have been messy, with the potential for users to lose important parameter modifiers (such as setting the EMTransmission to use a multibody driveline and engine), if they redeclared hybrid components. Naturally, this could cause much confusion and directly impact the functionality of the model. Therefore, the decision was taken to switch the original IndyCar model to use a hybrid template, adding a Boolean to that template to deactivate the hybrid component declarations when not needed.
Figure 2: At the template level, the hybrid components are conditionally declared. This enables them to be deactivated when not required, but also to always carry important setting relating to their deployment in the model, no matter the redeclaration by the user at a higher level.
Supporting, rather than controlling, the customer
Beyond the physical hybrid components, there needed to be a hybrid controller model. Now, this presents an interesting example of why considering customer use case is important.
By the traditional standards of the motorsport library, the controller model would reside inside the vehicle model itself. Nominally this is intuitive, as the controller model is built within the context of the vehicle model with regards to inputs and outputs. Complex external controllers for items such as the engine and transmission can be used in motorsport simulations, although for much of the vehicle model’s usage, a simplified controller is sufficient. Keeping the simplified controller within the vehicle model makes sense, reducing model management overheads. In this use case, the hybrid controller is expected to have a sizable impact upon the driveability of the vehicle; therefore, to obtain the accuracy required, the customer will want to be able to employ their detailed and complex external controller. Specifically, this is important for Driver-In-the-Loop (DiL) studies. As explained in a previous blog post, correct signal routing for parameter matching enables external apps to interface with the vehicle model inside DiL simulations. This mean correctly routing the required control variables for the hybrid system to the top level of the vehicle model experiment will save the customer time and better support their particular use case.
Figure 3: By placing the controller at the top level of the experiment, it is easier for the user to combine their controller model with the vehicle model in DiL applications.
Final Thoughts
Keeping the end user in mind when developing software solutions – like the VeSyMA suite – is important at every step of the process. Without it, it is easy for the resultant software to fail to meet the demands and expectations of the user. At Claytex, every step of the way the customer’s needs are at the forefront of the mind, whether it be in development of products for sale or in consultancy work.
Written by: Theodor Ensbury – Project Engineer
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion.
