Physical modeling is quickly becoming an essential dimension in automotive engineering. As discussed in Part 1 of this series, industry leaders such as Toyota and IAV have begun sounding alarms on the impending wall that our industry may hit. The Physical Modeling Consortium (PMC) was founded by Toyota and the modeling software company Maplesoft to raise awareness and increase standards of practice among engineers.
What is physical modeling?
The term "physical modeling" is somewhat ambiguous. A physical model can be interpreted as a real plastic and metal replica of an actual object. In the context of automotive engineering, it refers to modeling techniques that better represent the physics and the mathematics of a system. The terms "physics-based modeling" and "physical system modeling" are sometimes used and are generally considered synonymous with physical modeling.
Continuing with ambiguous terminology, another synonym for physical modeling, depending on who you are talking to, is "plant modeling." Plant, in this case, refers to the control system sense of the word; that is, the plant is the physical system that the controller tries to control. Control engineers were among the first to raise awareness of the need for better physical modeling tools and consequently, you will find heavy influences from the control community.
Lumped parameter vs. continuum models
There is yet another group of engineers who might also stake claim to some part of the physical modeling turf: Those working on continuum models. Continuum representations are used to deal with very detailed analyses of a system's performance. As such, they model their objects as continuous fields: For example, solid materials, fluids, heat, electromagnetism, and so on. This is the domain of solid modeling, finite element analysis (FEA), and computational fluid dynamics (CFD) among others.
The physical modeling context with which the PMC is concerned deals with "lumped parameter" systems—typically machines or systems with multiple components, with each one carrying only the high-level essential physical information. For example, an entire vehicle suspension system may be represented in a free body diagram with the car portion as a single point mass with no consideration for the various geometric elements of the real car. This is acceptable for many types of analysis. But, clearly, if your goal is to design the precise shape of a suspension arm or optimize body shape for aerodynamic qualities, you would not make such a gross assumption.
Signal-flow vs. object-oriented modeling systems
In many ways, the physical modeling movement is a reaction to the deficiency of the so-called "signal-flow" modeling system. Signal-flow systems are based on time-based signal flows between one measurable entity and another: For example, velocity to displacement using an integration block. Simulink® from The MathWorks is a famous example. Such systems have been found to be very effective in designing and deploying control systems.
However, the signal-flow view of models has one fundamental deficiency: it maps poorly to the physical topology of real systems. For example, in a typical spring-mass-damper system, a signal-flow model will not typically have a clear articulation of the various components, but will generally be composed of the mathematical relationships among the essential measurable quantities.
Procedurally, this involves the formulation of the differential equations representing the system and then mapping the various parts of the equation to visual blocks and connections. The origin of this representation, ironically, is the analog computer that competed for simulation supremacy with the then-still-nascent digital computer during the '60s and early '70s. Analog computers, through hard-wired circuitry for integration and other mathematical operations, allow instantaneous and accurate solution of differential equation-based models.
Over time, of course, the flexibility and ease-of-use of digital simulation techniques replaced these fascinating machines. In many ways, the modern signal-flow software systems are virtual analog computers. In fact, the schematic sketches that engineers used to draw to organize their models for the analog computer are very similar in structure to models for modern signal-flow systems. Starting with the differential equations of the model, you would reorganize to a system of first order equations and associate an integration operation for each state variable.
Although this process is well-defined, it can get fairly abstract quickly for complex systems. As such, the plant modeling process can often become laborious and time-consuming. Some estimate that, for typical design scenarios, more than 80% of project time is spent on plant modeling (the derivation of the differential equations) and the remainder on control design. In other words, up to 80% of project time is still fairly manual and poorly supported by software.
Object-oriented simulation tools approach the simulation model from the perspective of physical system components. One defines the major components and then defines the connectivity among the components. So, for an RLC circuit in series, for example, you would first define a resistor block, inductor block, and so on, and then a series connection. Most modern tools will have appropriate graphical user interfaces that will allow a user to simply "draw" this circuit.
Once the model is defined, the software would then use some mathematical framework to automatically formulate system equations. An example of such a framework is linear graph theory as introduced in a previous Automotive DesignLine article titled Generate efficient vehicle dynamic models - right down to the tires: Part 1 - procedures and system topology. The results are differential equations that be solved or, in some cases, moved into a signal-flow framework to design a controller. These equations highlight an additional benefit: An object-oriented system can either be a complete replacement of a signal-flow approach or an effective complement specializing in the plant modeling portion of the project.
