Our client – a project manager at an automotive group – is responsible for the system architecture and the system engineering of a part of the power train (unfortunately, for reasons of secrecy, we are not allowed to give details here).
He always has to answer the same questions: If the system is to be integrated into vehicle A, B or C, how should it look best? How large do the individual components have to be? How well can the system meet which vehicle-specific requirements? How well can which driving cycle be fulfilled and what influence do these system decisions have on fuel consumption and costs?
The client wanted a modular system in Simulink. This was to consist of partial models for all individual components. The models had to reflect the physics as well as possible – but at the same time be simple and pragmatic enough to exchange individual characteristic curves, efficiencies or material data without any problems.
Project Manager Research and Development, Automobile Manufacturer
Our client is always confronted with the same questions by his boss or the vehicle project managers:
– How good is your system? What exactly does it look like for vehicle platform A, B or C?
– How can we save costs without losing function and safety?
– How big and how heavy will the system be? What options can we offer?
– How can we work as modularly as possible?
The client has to answer these questions by simulation. He must be able to set up numerous variants quickly and “run over” the relevant test scenarios – driving cycles, cold starts, etc. – without effort.
As a result, he needs graphics and result values that are as standardized as possible and with which he can satisfy his internal clients. These also serve as documentation for further development.
Simulink is the optimal tool for these questions. We were able to program the client a physical model for each component that was correct in itself. Where no general assumptions were possible, we worked with assumptions, characteristic curves and efficiencies. In some cases, the models are structured in such a way that everything is possible, and the client selects the appropriate case-specific model.
The client can now combine the component models himself to form a system model and thus reproduce the desired reality. A standardized input interface and a standardized evaluation – e.g. as fuel consumption over the driving cycle – round off the package.