Building Models

This chapter describes the basics of RT-LAB, provides an overview of the simulation process, from designing and validating the model, to using block diagrams and I/O devices, to running the simulation and using the Console as a graphic interface.

Building a Simple Model for RT-LAB

Naming Convention

In RT-LAB, all top-level subsystems must be named with a prefix identifying their function.

The prefixes are:

Native Simulink Model

RT-LAB supports any Simulink model without modifying the model.

However, this model has to be compatible with Real-Time Workshop (RTW) before opening it with RT-LAB:

• uses fixed-step solver
• uses block sets compatible with RTW

During the compilation process, the model will be automatically separated (no modification are done to the original model) into one computation subsystem and one console with one acquisition group. The signals to display could be added later dynamically when the model is running. Interaction to the model is done by setting the model’s parameter on-the-fly.

Single Subsystem Model

You may want to modify your model to make it compatible with RT-LAB. It could be useful when you want to set some signals to be always sent from the SM to the SC subsystem and also to define some control signals. In this case, the rules for creating the model is the same than a distributed model except that there will be no SS subsystems. Refer to the next paragraph to learn how to create an RT-LAB model.

Building a Distributed Model for RT-LAB

Any Simulink model can be implemented in RT-LAB, but some modifications must be made to distribute the model and transfer it into the simulation environment. The success of distributed computing with a complex model will depend on the separation of that model into small subsystems synchronized to run in parallel. This should be kept in mind early in and throughout the design process.

To build a distributed model, users must modify the block diagram (.mdl or .sbd file) by regrouping the model into calculation subsystems, inserting OpComm communication blocks, taking into account step size calculations and exchanging state variables or using Delay blocks; each of these topics is covered within this chapter. After these steps have been completed, RT-LAB begins the compilation process with the regrouped file, separating the model and generating and compiling the code. You then set execution settings, which are covered in the following chapters, after which point the model’s simulation is ready to be executed. This chapter describes the steps necessary to build an RT-LAB model by modifying your Simulink block diagram to ensure it is properly separated for distributed execution and to maximize its performance. RTdemo2 example

This model consists of:

This logical separation is used to create the top-level subsystems

rtdemo2 model

OpComm Communication Blocks

Once the model is grouped into Console and computation subsystems, special blocks called OpComm blocks must be inserted into the subsystems. These are simple feed-through blocks that intercept all incoming signals before sending them to computation blocks within a given subsystem.

OpComm blocks serve several purposes:

• When a simulation model runs in the RT-LAB environment, all connections between the main subsystems (SC_, SM_, or SS_) are replaced by hardware communication links.
• For communication between real-time target nodes (SM_ and SS_), RT-LAB uses a designated real-time link. For communication between the Console (SC_) and the real-time nodes (SM_ or SS_), RT-LAB uses TCP/IP.
• Because of these communication links between nodes, the simulation may not run the same way in Simulink as in RT-LAB. In RT-LAB, a computation subsystem waits for reception of all signals before it is able to start calculating. In Simulink, on the other hand, computations performed on a signal start as soon as the signal is available. As pass-through icons that wait for all inputs before making their outputs available, OpComm blocks emulate the behavior of the system as it is run in RT-LAB. Keep this effect in mind when designing models.
• If you receive a message indicating that the inserted OpComm blocks create an algebraic loop, this means your model cannot be run in real-time, as a deadlock has been created. To correct this problem, include a state variable. See the full discussion in section Maximizing Parallel Communication.
• OpComm blocks inserted into the Console subsystem enable you to select the data acquisition group you want to use to acquire data from the model and to specify acquisition parameters. (Acquisition parameters are described in the following sections).
• RT-LAB uses OpComm blocks to enable and to save communication setup information. This includes both communication between the command station and computation nodes and communication between computation nodes in a distributed simulation scenario.
• All inputs to top-level subsystems must first go through an OpComm block before they can be used.

OpComm Placement Rules

In the computation subsystems (SM or SS):

• One OpComm receives real-time-synchronized signals from other computation subsystems
• One OpComm receives signals asynchronously from the console subsystem In the console subsystem (SC subsystem):
• One or more OpComm blocks may be inserted to receive signals from the computation nodes.

Multiple OpComm blocks define unique acquisition groups with their own data acquisition parameters

OpComm Blocks in the SM Subsystem

One OpComm block is inserted to receive signals from the SC subsystem (asynchronous network).
One OpComm block is inserted to receive signals from other real-time subsystems (in this case, plant_response, from SS)

SM subsystem and associated OpComm mask

OpComm Blocks in the SS Subsystem

Since data are only from the SM subsystem, only one OpComm block is inserted into the slave subsystem.

SS subsystem and associated OpComm mask

OpComm Blocks in the SC Subsystem

For the console, 1 or many OpComm blocks can be added depending on how many acquisition groups you want to set. Acquisition groups allow you to define different priorities and acquisition parameters to different groups of signals.

SC subsystem and associated OpComm block

Since the SC (console) subsystem run asynchronously from the main computation (SM and SS), the following limitations apply:

• The console subsystem cannot contain computation on which the real-time model relies
• Only signals from the same acquisition group (OpComm) can be compared with each other. Signals from different OpComm blocks are not synchronized together.

Maximizing Parallel Communication

To maximize parallel communication, output data must be exchanged between your network’s nodes in the most efficient way possible. The order in which data is sent can be prioritized so that nodes run their main calculations without having to wait for outputs from other nodes in the network. This is accomplished by identifying calculations that can be run independently of inputs as state variables and passing input-dependant variables through Delay blocks.

State Variable

A state can be defined as an output (signal) which is computed only from preceding inputs or outputs. Example of blocks which introduce a state are the “integrator” and “memory” blocks. A “gain” block does not produce a state because its output at step z depends on its input at the same
step.

Distributed Examples