As automotive manufacturers strive to improve the fuel efficiency of their vehicles, much of the focus is on the engine as the primary source of power loss. However, there is as much loss through the transmission. Engineers are putting tremendous effort into determining exactly how much power is lost and what can be done to reduce losses and improve overall efficiency. As a result, the transmission industry is now actively involved in optimizing existing designs and exploring new system architectures.
Transmission modeling and simulation provide a means of reducing the number of physical prototypes that must be built during the design of a transmission. At a requirements level this translates into choosing the number and ratio of the gears that will be in a particular design, given a vehicle’s target dynamic performance, production cost, and fuel economy. At a much more granular level, requirements come down to minimizing losses and maximizing efficiencies through plant and controller design (“plant” being the transmission, and “controller” being the embedded controller unit, or ECU).
Traditionally, signal-flow modeling software has been used to model transmissions. Signal-flow models are constructed of integrators, gains, feedback loops, and other basic operations related to the mathematics of the system. This method of modeling necessitates that engineers specify ahead of time what is an input, what is an output, what direction energy will flow, and set up their mathematical formulation based on this. Should any of these details change, a new formulation must be created and implemented in the modeling tool. This is a particularly thorny issue for transmission modeling because the direction of energy flow can change quite often during normal operation: when clutches activate or deactivate, when the engine becomes a power sink instead of a power source, etc.
To sidestep these issues, over the last decade there has been a remarkable push toward acausal modeling environments, such as MapleSim from Maplesoft, which takes a different approach to modeling. Rather than representing mathematics directly, models use components that contain governing equations, and it is incumbent on the solver to perform the mathematical manipulation. Modelica is an object-oriented language that describes these components and their connections—it enables acausal modeling at a programming language level. For example, a mass-spring-damper in a signal-flow environment looks like a bunch of integrators, adders, and feedback components, and its topology doesn’t resemble the physical system. In MapleSim, it looks like a mass, spring, and damper. The spring would contain Hooke’s Law, F = -k•x, which would be rearranged depending on if the force or position was known. This is truly impressive when one considers the following: For the mass-spring-damper, applying a force to the mass vs. specifying its acceleration are two completely separate models in a signal-flow representation, but one in an acausal environment. Removing this burden from engineers via acausal modeling has been imperative to advancing the field of transmission modeling.
With the architecture in place and an accurate model in hand, a controller can be designed to operate the transmission to achieve performance requirements. Ultimately, the better the plant model, the better the controller since it is designed against the plant model. Then, hardware-in-the-loop (HIL) testing comes into play to validate that controllers will achieve the necessary performance. An ECU hosting the control code is connected to a software model of the transmission. That is, the ECU thinks it is controlling the real transmission, but instead it is just plant model code running on a HIL test bench consisting of dSpace or National Instruments boxes full of CPUs and I/Os.
To run on a HIL bench, the transmission model must be able to run in real time since the ECU thinks it is a real transmission. So, the ∆t within the simulation must take less than ∆t in reality to compute on the HIL test bench—much less because of the overhead of I/O and various other functions that must be provided. This has traditionally necessitated a trade-off between model fidelity and simulation speed. Again, acausal modeling is part of the solution, specifically Modelica-based tools: In a signal-flow model, there is no room for simplification beyond what any compiler can do. However, since model equations are available in Modelica modeling environments, symbolic pre-processing is possible, which eliminates the number of states that must be calculated every time step. The reduction is on the order of 10x, so a model with 1500 states to solve in a signal-flow formulation would have about 150 in an acausal modeling environment. Less states equals faster code without sacrificing fidelity.
Derek Wright, Product Director, Maplesoft, wrote this article for AEI.