Modeling Control Logic and Event-Driven Behavior for Early Detection of Communication Latencies

Complex systems such as airplanes, automobiles, and industrial machinery require multiple electronic control units (ECUs) to control the behavior of electrical subsystems. When these ECUs interact with each other as well as with sensors and actuators on the plant, communication latencies can result. Often the latencies remain undetected until the system has been implemented in hardware, causing costly redesigns and delays to the project schedule.

The solution is to use a system model that combines finite state machines, to model the control logic, and discrete-event systems, to model the communication network. You can simulate the model to determine how robust the system is to spurious signals or real-time delays between the ECU and the communication bus well before software is implemented and integrated with hardware.

Using an automotive CD player system as an example, this article demonstrates a workflow for verifying system behavior in the presence of communication latencies. The workflow uses a single system model that incorporates the ECU, the CD player mechanism, and the I2C communication bus.

Modeling the ECU Control Logic

The CD player’s ECU contains a significant amount of control logic. From the top level, the player can be either off or on. If the system is on, it can be in a variety of states—for example, running diagnostics, playing a CD, or tuned to an AM/FM radio. The decisions that must be made to switch from state to state are numerous, complex, and hierarchical in nature. Representing all this logic with code would be challenging, in part because it is difficult to visualize exactly how the states are connected to one another simply by examining code.

Instead, we represent this logic with a finite state machine using Stateflow^® (Figure 1).

A state machine clearly shows the different states of the logic system and how they are connected to one another. For example, the state machine in Figure 1 shows us immediately that the substates of the ON superstate are “Diagnostics,” “CD,” “FM,” and “AM” and that the variable RadioReq determines which substate is active.

Modeling the Mechanism Mode Logic

When a CD has been loaded, the player mechanism, too, can be in a variety of different modes, such as Normal, Rewind, or Fast-forward. We use a Stateflow chart to model the behavior of this mechanism in our system model (Figure 2).

Capturing Communication Latencies

When a voltage is applied between the top electrode and the ground plane, electrostatic charges are induced on the surface of the conductors, which give rise to electrostatic forces acting normal to the surface of the conductors. Since the ground plane is fixed, the electrostatic forces deform only the top electrode. When the beam deforms, the charge redistributes on the surface of the conductors. The resultant electrostatic forces and the deformation of the beam also change. This process continues until a state of equilibrium is reached.

Applying FEM to Coupled Electro-Mechanical Analysis

Ideally, and with minimal communication latency, the ECU and the CD player mechanism will always be in sync. In our example, however, latency naturally occurs over the I2C bus. To capture the true system behavior, our model must represent the communication on the I2C bus.

We build the bus model using SimEvents™ library blocks, including Entity Generator, FIFO Queue, and Single Server (Figure 3).

The Single Server block delays incoming packets for a specified amount of time. This amount can be fixed for every incoming packet, or it can vary according to the configuration. The FIFO Queue buffers the communication packets, and as a result, adds queuing latencies. Simulation will enable us to monitor the number of packets in the queue, average wait time in the queue, and other statistics, such as the bus utilization.

Figure 4 shows the top-level view of the model with the I2C Communication Bus subsystems connecting logic components in the ECU and the CD player mechanism. The I2C Communication Bus subsystem captures the queuing latency, which varies according to the amount of traffic on the bus.

Verifying System Behavior

The CD player shares the I2C bus with other devices installed on the vehicle. As a result, the incoming traffic on the bus includes both the CD player packets and the background traffic packets. The traffic packet from the CD player is light. The background traffic is heavier, and it is unpredictable. Heavy background traffic could delay the CD player packets, causing the CD player to get stuck in one state. By simulating the model we will be able to assess the effects of background traffic on the behavior of the CD player logic.

Simulation results reveal that the state of the CD player mechanism is not in synch with the ECU state. Because this is not a valid state of the system, we must reduce the communication latency on the I2C bus—for example, by replacing the I2C bus to a CAN bus and testing the system model under the new scenario.

Advantages of this Approach

By modeling control logic and even-driven behavior with Stateflow and SimEvents, we were able to understand the effects of variable communication latencies on system behavior well before implementing the code on hardware. Once we are satisfied with the system design we can generate embeddable code from the Stateflow charts. The model will make it easy for systems engineers to communicate design issues to engineers working on the CD player control logic or the communication network.