In my last blog, Part 1, I covered how we experienced the challenges of a development process through simple exercise of designing a catapult. In this blog I will cover how these challenges relate to some of those the automotive industry faces today.
One of the obvious differences between our simple catapult and a modern vehicle is the system complexity. We were able to conceptualize our catapult on a piece of paper and wrap our heads around it and for the lack of other means were forced to resort to physical testing.
The complexity of modern vehicles makes this more difficult. Multidisciplinary teams are required to work on developing the new product in parallel, each using different tools and practices that are best suited for what their unit is aiming to achieve. Extra time and costs associated with physical testing also drive the demand for majority of the development process to happen in the virtual world of modelling and simulations (virtual system development – “frontloading”).
This has led to the development of standards in modelling and simulation such as FMI, SSP and DCP. These standards enable model exchange between different modelling and simulation environments and co-simulations. As the term suggests, these are simulations from multiple disciplines coupled together that provide more holistic and complete performance. Let’s now have a look at these standards in a more detail.
Functional Mockup Interface (FMI) is a standard defining a container and an interface that allows exchange of dynamic models between different simulation environments. This enables integration of simulation models, tools and solvers from different technical disciplines that might be developed by different internal engineering teams within the company or external partners. A component that implements such interface is called Functional Mockup Unit (FMU).
System Structure and Parametrization (SSP) is a standard that defines connection structure for systems consisting of one or more FMUs with the necessary parametrization so that it can be transferred between simulation tools. This vendor independent system description shared by data management and integration tools enables the reuse of models, tests, layouts, and their parameters allowing tools such as AVL’s Model.CONNECT to setup the simulation architecture, manage different models, integrate them, and execute. This development standard should be usable throughout all stages of development process from architecture definition to MiL, SiL or HiL testing.
Distributed Co-Simulation Protocol (DCP) takes connecting and communication between models one step further. It is a standard for integration of non-real time (virtual models) and real-time (i.e. engine testbench) systems into simulations environments connected via communication systems and transport protocols such as UDP/IPv4, Bluetooth, USB or CAN. This takes away the limitations of having to have all the necessary models available locally and allows connection of various models owned by different teams and even companies (OEMs, suppliers) over the internet to perform collaborative development.
All these standards and the option of running distributed co-simulations is a long way from the simple development process we used for our catapult. They aim to reduce development time, costs, and shorten time-to-market whilst still protecting intellectual property. I am impressed by the amount of effort and collaboration between all the companies that contributed towards the development of these standards and cannot wait to see what the future holds.
For readers that would like to explore little bit more:
fmi-standard [Online] Available at: Functional Mock-up Interface (fmi-standard.org)
ssp-standard [Online] Available at: System Structure and Parametrization (ssp-standard.org)
dcp-standard [Online] Available at: Distributed Co-Simulation Protocol (DCP) (dcp-standard.org)
