Architecture Based Vehicle Modeling

Reviewing Architecture-Based Approaches for Vehicle Modeling

All Modelon libraries are developed to adhere to the open-standard, Modelica language. We, at Modelon, thrive in this language standard for many reasons and fully leverage it in the use of templates and model architectures to rapidly create models and model variants. Modelon’s Vehicle Dynamics Library utilizes this template-based approach in full vehicle modeling. There is even the VehicleInterfaces library that attempts to provide common interfaces for use in vehicle simulation

One architecture to rule them all?

In an ideal world, full-vehicle modeling based on a standard set of interfaces would work seamlessly; however, vehicle model simulations can vary widely in scope to different customers. Some customers simulate detailed multibody vehicle dynamics simulations, while some analyze various powertrain concepts, and others need to integrate vehicle thermal management systems.  The breakdown of the vehicle into different components/subsystems may differ based on the modeling needs and engineering activities at different parts of the product development process.  For some customers, they adhere to the standard templates from VehicleInterfaces.  We also have other customers who lump subsystems differently, often pulling key subsystems to the top level of the model to focus on those subsystems and their variants.  In some cases, it makes sense to lump by the physical domain (i.e. electrical system, hydraulic system, pneumatic system, thermal system, etc.) rather than by traditional vehicle subsystem.

In addition to the subsystem decomposition, there is also the choice of which connectors should be included on the interfaces.  While the connector requirements are straightforward in the mechanical domain, the situation is less clear for multi-domain applications.  In our view, VehicleInterfaces essentially provides only the minimal required connectors and perhaps rightly so.  Unfortunately, we have seen that strict adherence to these interfaces often leads to modeling errors.  Our work with customers has repeatedly shown that we need more than what is provided by VehicleInterfaces, and thus we need to implement new/extended interfaces anyway thereby significantly reducing the value of a common interfaces library.

From our experience, there isn’t a single architecture that will satisfy everyone without becoming unwieldy (and believe me, we have tried).  But how do we promote reuse even as we allow flexibility in the model architectures?

A multi-perspective view

We at Modelon have embraced the idea of multi-perspective along with multi-fidelity. With a multi-perspective approach, we can provide different model architectures with different engineering focus but still populated by the same underlying models.  From the start, we build flexibility to handle different engineering applications via configurable interfaces and templates.  With this approach, it is very easy to create new model architectures as needed.  And to be clear, these model architectures can be populated by models from the Modelica Standard Library, Modelon libraries, and other commercial libraries like PowerTrain Library, etc.

The images below show a multi-perspective view based on Vehicle Dynamics Library for a full vehicle thermal management application.  These models are all identical but with just a different model architecture.

Model A shows a sub-system focused perspective. This perspective might be preferable for system integrators who want to rapidly configure models without explicitly aggregating into a vehicle model.

Model B shows another perspective with the traditional driver-vehicle approach from Modelon’s Vehicle Dynamics Library and additional top-level subsystems for the electrical and thermal systems.  This perspective may be preferable for engineering applications focused on electrical/thermal systems integrated with traditional vehicle mechanical systems.

With Model C, everything is combined into the traditional driver-vehicle approach from Modelon’s Vehicle Dynamics Library. This perspective provides a single, self-contained vehicle model that can be validated and then integrated to support other engineering applications like control system design, etc.

In Model D, a fuel cell vehicle model is created by combining Modelon’s Vehicle Dynamics Library and Fuel Cell Library.  The additional top-level subsystems provide the fuel cell system and the electrical system including the motor and battery.

Summary

It’s important to recognize that we aren’t constrained by a template.  Creating templates is easy; the more difficult part is the creation of the correct and appropriately detailed component models used to populate these templates.  These applications are just a few examples of how our libraries are integrated to simulate and study vehicle thermal management and advanced vehicle concepts like fuel cell-powered hybrid vehicle designs.