Co-simulation is a simulation methodology that allows complex systems comprised of subsystems to be easily simulated. How is this is accomplished? Each of the subsystems is simulated in a different simulation tool, but they are executed simultaneously. Relevant signals between them are exchanged during execution at regular intervals and the combined simulation is synchronized so that an orderly exchange of signals is made possible.
A co-simulation approach allows organizations to choose the most appropriate simulation tools for each discipline. The co-simulation coupling provides engineers with the ability to create and simulate system level models.
Co-simulation is a potential solution whenever multiple-physics are to be coupled. The following examples, taken from the automotive domain, provide a glimpse of the generality of co-simulation and variety of system-level simulations that can be performed with co-simulation. Similar examples can be found in other industries also.
In this scenario, the objective is to understand how well control systems can regulate/control the behavior of a mechanical system. The mechanical system could be a car and the control system could be a steering control system. The vehicle model is defined in MotionSolve and the steering control is defined in a controls package like Simulink. The vehicle sends information like vehicle heading and tire slip angles to the controller. The controller computes a steering wheel angle or torque based on these inputs and returns it to the vehicle model.
Figure-1: Co-simulation between a vehicle model and a controller regulating the vehicle
In this scenario, the objective is to understand how well the hydraulics in a system can regulate/control the behavior of a mechanical system. The mechanical system could be a car and the hydraulic system could be a brake system. The vehicle model is defined in MotionSolve and the steering control is defined in a hydraulics package like DSHPlus (www.fluidon.com). The vehicle sends information like wheel speed and steering wheel angle to the controller. The controller/hydraulics system computes a brake demand and torque based on these inputs and returns it to the vehicle model.
Figure-2: Co-simulation between a vehicle and a hydraulic system such as a brake regulating the vehicle
In this scenario, the objective is to “drive” a full vehicle model with a driver model and understand how the vehicle responds to the driver input. The driver module is provided the vehicle heading, its speed as input. The driver is required to make the vehicle follow a specified path at a specified velocity and ensure that the vehicle lateral acceleration is below a target limit. The driver specifies as output the throttle value, the brake pressure, the steering angle and the gearshift value. The vehicle is modeled in MotionSolve. The driver, modeled as a hierarchical control system, is contained in a separate driver module.
Figure-3: Co-simulation between a vehicle and a driver model controlling the vehicle
Tires play a critical role in vehicle simulations; they are the only portion of the vehicle that is in contact with the road. Tires are very complex entities consisting of rubber, metal, and plastic. Their behavior is influenced by a variety of internal factors such as air pressure and tread, environmental factors such as temperature and road conditions, and driving conditions such as acceleration, braking, and turning.
Tire and tire-terrain interaction is quite complex and specialized; off-the-shelf tire models are available. Co-simulation is used to couple the tire model to the vehicle model. The vehicle tells the tire where it is in space and how fast it is moving. The tire then calculates the tire-terrain interaction force and tells the vehicle the forces and moments acting at the spindle.
Such a coupling can be quite sophisticated as evidenced by the figure below. The truck-trailer system shown below may have as many as 100 tires. Each of these tires is connected to the vehicle model via co-simulation.
Figure-4: Co-simulation between a vehicle and a driver model controlling the vehicle
Complex systems such as cars and planes have many embedded control systems. These systems monitor and control the behavior of the car or plane to avoid catastrophic failures and ensure high performance. The term, Mechatronics, was coined to define such embedded systems. Figure 5 provides a few examples of mechatronic systems relevant to automobiles. In order to assess the behavior of the controlled vehicle, co-simulation between the vehicle model and the various mechatronic subsystems is necessary.
Figure-5: Mechatronic systems in automobiles. Mechatronics is the synergistic use of precision engineering, control theory, computer science, mathematics, and sensor technology to design smart products, processes, and systems.
The co-simulation process typically consists of the following steps:
• | Decomposing a complex system into sub-systems, based on the physics describing the subsystems. |
• | Creating functional models for each subsystem in the individual simulators and making sure that each subsystem performs as intended. |
• | Creating the “connections” (signals) between the different subsystems. Typically, there is power transfer from one system to another. So, one subsystem typically receives flow information such as velocity, angular velocity, current, volumetric flow rate or entropy flow rate. In return it sends back to the subsystem from which it received the flow information, effort information such as force, moment, voltage, pressure or temperature. |
• | Choosing the mechanism for inter-process communication (for example, shared memory on a single machine or TCP/IP for network communication). |
• | Performing the combined simulation. |
Implicit to this process is a sampling strategy to sample the connected signal by each solver, which can be accomplished with different approaches.
Figure 6 below describes schematically and generally how this may be done between two simulators A and B.
At the sampling times, which may be pre-decided or computed during the co-simulation, each simulator deposits the information it is required to provide to the other simulator into a Co-Simulation Buffer. When Simulator A requires information from B at a certain time, the Co-Simulation Buffer provides this information to A, either by interpolating or extrapolating through data provided by B. Likewise, when Simulator B requires information from A at a certain time, the Co-Simulation Buffer provides this information to B, either by interpolating or extrapolating through data provided to it by A.
Figure-6: A schematic illustration of co-simulation between two simulators A and B
Through the use of a co-simulation buffer, many simulators A…N may be coupled. As long each simulator deposits its exchange values at the appropriate frequency, the Simulation Buffer has the ability to provide each simulator with the data it needs from the other simulators.
The MotionSolve implementation of co-simulation using Control_PlantInput and Control_PlantOutput statements resembles this process, with a few qualifications to the sampling strategy.
The intent of co-simulation with MotionSolve is to exchange data with another system and use it in a manner resemble a continuous system. During co-simulation, MotionSolve and the other process (Simulink) with which it is simulating share data with the Co-Simulation Buffer, as described previously.
The other process that co-simulates with MotionSolve, always leads the co-simulation, taking the first step, and MotionSolve catches up to keep the processes coordinated. Each solver can take whatever time step they choose, but there are some conditions that cause the solver to wait if the data from the other solver is not yet available.
The data must be coordinated so that the extrapolating solver (the leading solver) is not allowed to take a larger time step than the interpolating solver, in order to prevent large error from extrapolating too far ahead in time. And, the interpolating solver (the lagging solver), cannot take a step if the data is not yet available for the last time step, since by the nature of the interpolation, the data at a future time must be available.
MotionSolve is the lagging solver in co-simulation using Control_PlantInput and Control_PlantOutput statements (for example, with Simulink), which means that it always interpolates data coming to it (via Control_PlantInput). The other process with which MotionSolve co-simulates always leads, which means that it always extrapolates data coming to it (via Control_PlantOutput).