Skip to content

Chapter 7: Dynamical Systems and Physics-Based Modeling for Component Twinning

Chapter Mission

To build high-fidelity, equation-based models that capture the physical behavior of engineered components.

Learning Objectives

By the end of this chapter, you will be able to:

  • Represent mechanical and electrical systems using ordinary differential equations (ODEs).
  • Develop state-space and transfer function models.
  • Utilize acausal, component-based modeling tools (e.g., Modelica).
  • Create a physics-based DT of a component to predict wear, thermal performance, or energy consumption.

7.1 From Abstract Flows to Physical Laws

So far, we have modeled processes, agents, and strategic structures. We now zoom into the lowest level of abstraction: the physics of an engineered component. If a Digital Twin is to predict the physical health of an asset—its temperature, stress, vibration, or energy consumption—it needs a model that speaks the language of physics: the language of dynamical systems and differential equations.

A dynamical system is a system whose state evolves over time according to a fixed rule. For continuous physical systems, this rule is typically a set of Ordinary Differential Equations (ODEs) derived from first principles like Newton's Laws, Ohm's Law, or the laws of thermodynamics. This approach is often called physics-based modeling or first-principles modeling.

Unlike a data-driven model that learns correlations, a physics-based model understands the underlying causality of the system. This is what allows it to make accurate predictions even under conditions it has never seen in its historical data.

7.2 The Core Idea: Conservation and Lumped Parameters

The foundation of physics-based modeling is the principle of conservation (of energy, mass, momentum, etc.). For any given system, we can write a balance equation:

[Rate of accumulation] = [Rate of inflow] - [Rate of outflow] + [Rate of generation]

Notice the similarity to the stock-and-flow concept from System Dynamics! Here, the "stock" is a physical quantity like thermal energy or momentum, and the "flows" are governed by physical laws.

To make the problem solvable, we often use lumped parameter modeling. Instead of modeling the temperature at every single point inside a motor (a complex partial differential equation problem), we "lump" it into a single variable, T_motor, representing the average temperature of the entire component. This assumes the temperature is uniform throughout the component, which is a powerful and often valid simplification.

7.3 The Language of Change: Ordinary Differential Equations (ODEs)

Let's model a simple mechanical system: a mass (m) attached to a spring (k) and a damper (b), subjected to an external force F(t).

From Newton's Second Law (ΣF = ma), we can write the equation of motion. The sum of forces (external force, spring force, damping force) equals mass times acceleration:

F(t) - kx - bẋ = mẍ

Where: * x is the position of the mass. * ẋ is the velocity (the first derivative of position, dx/dt). * ẍ is the acceleration (the second derivative of position, d²x/dt²).

This is a second-order linear ordinary differential equation. It is the "rule" that governs the evolution of the system's state. To solve it and predict the position x at any time t, we need a computer to perform numerical integration. The computer starts with the initial state (initial position and velocity) and takes small time steps (Δt), calculating the new state at each step using algorithms like Euler's method or the more sophisticated Runge-Kutta methods.

7.4 Formalisms for Modeling: State-Space and Transfer Functions

Writing down large systems of ODEs can be cumbersome. Engineers use more structured mathematical formalisms to represent them.

State-Space Representation

The state-space approach is a powerful and universal way to model dynamical systems. The idea is to describe the system with a set of first-order ODEs. We define a state vector, x, containing the minimum number of variables needed to fully describe the system's state.

For our mass-spring-damper system, the state variables are position and velocity. We can define our state vector and input as: x = [position; velocity] and u = [Force F(t)]

The system can then be written in the standard matrix form:

ẋ = Ax + Bu y = Cx + Du

  • ẋ is the time derivative of the state vector.
  • y is the output we care about (e.g., just the position).
  • A, B, C, D are matrices that define the system's dynamics.

This format is the foundation of modern control theory and is extremely convenient for computer simulation. Tools like MATLAB/Simulink use it extensively.

Transfer Functions

For linear time-invariant (LTI) systems, we can use the Laplace transform to convert the differential equations in the time domain into algebraic equations in the complex frequency domain (s-domain). This gives us the transfer function, G(s), which is the ratio of the output's Laplace transform to the input's Laplace transform.

G(s) = Y(s) / U(s)

For the mass-spring-damper, the transfer function from input force F(s) to output position X(s) is:

G(s) = 1 / (ms² + bs + k)

Transfer functions are excellent for analyzing system properties like stability, frequency response, and designing controllers, but are less intuitive for time-domain simulation.

7.5 Beyond Causality: Component-Based Modeling with Modelica

Both the direct ODE and state-space approaches are causal. You must manually derive the equations to compute the output from the input. This becomes incredibly difficult for complex, multi-domain systems (e.g., an electric vehicle drive train involving electrical, mechanical, and thermal components).

Acausal modeling tools, with the Modelica language being the prime example, offer a revolutionary alternative. In an acausal approach: 1. You do not write the full system of equations. 2. Instead, you build a library of reusable components (a resistor, a motor, a gear, a pipe). For each component, you just write down its fundamental physical equations without assigning causality (e.g., for a resistor, V = IR, not V = I*R or I = V/R). 3. You then build your system model by dragging, dropping, and connecting these components, just like drawing a real-world schematic. 4. The Modelica compiler then analyzes the entire system of connections and automatically derives and solves the final set of differential-algebraic equations (DAEs).

This component-based, acausal approach is vastly more scalable, reusable, and intuitive for modeling complex physical systems, making it a perfect technology for building the physics-based "Virtual Space" of a Digital Twin.

7.6 Creating a Physics-Based Digital Twin

The purpose of a physics-based model in a DT is often to infer something you cannot directly measure. You might have a sensor for voltage and rotational speed, but not for the internal winding temperature or mechanical fatigue.

The Twinning Process:

  1. Develop the Model: Create a high-fidelity, physics-based model of the component (e.g., in Simulink or OpenModelica) that takes measurable inputs and predicts both measurable and unmeasurable outputs.

    • Inputs: Voltage, Ambient Temperature (from sensors).
    • Outputs: Rotational Speed, Current Draw (measurable); Winding Temperature, Bearing Stress, Cumulative Fatigue (unmeasurable).

  2. Continuous Validation and Parameter Estimation: The model has parameters (like friction b or thermal resistance R_th) that may not be perfectly known or may change as the component ages. The twinning process uses the incoming stream of real-world sensor data to continuously validate and correct the model.

    • The DT takes the real measured voltage as an input and runs the model.
    • It compares the model's predicted rotational speed to the real measured rotational speed from the sensor.
    • If there is a persistent error, a parameter estimation algorithm (like a Kalman filter) automatically adjusts model parameters like b to make the model's output match reality again.

  3. Predictive Health Monitoring: Once the model is continuously "locked on" to reality, it can be used for prediction. The unmeasurable state variables it calculates (Winding Temperature, Fatigue) become a "virtual sensor"—a reliable estimate of the component's true internal health. This is the basis for predictive maintenance. "The model indicates that the cumulative fatigue damage will exceed the critical threshold in approximately 400 operating hours."

Lab Preview: Twinning a DC Motor

In the next lab, you will put these concepts into practice by building a simplified physics-based Digital Twin of a DC motor using MATLAB/Simulink or OpenModelica.

  1. Derive the Equations: You will first derive the coupled ODEs for the motor's electrical circuit (Ohm's Law, Faraday's Law) and its mechanical rotation (Newton's Second Law for rotation).
  2. Build the Model: You will implement these equations in your chosen simulation environment. The model will take Voltage as an input and produce Rotational Speed and Current as outputs.
  3. Simulate and Validate: You will be given a "real" dataset of voltage inputs and the corresponding speed outputs. You will run your model and tune its parameters (like motor resistance and friction) until its output matches the provided data.
  4. Create a Virtual Sensor: You will then add a thermal sub-model that uses the calculated current to estimate the motor's internal temperature—a variable that was not measured in the real world. This demonstrates the power of a physics-based twin to infer the unmeasurable.