Definitions

Introduction

This document is intended to help RT-LAB users interface an RT-LAB model with MIL-1553 boards. To do so, RT-LAB software offers a set of Matlab/Simulink blocks that manage accesses to the 1553 boards. The RT-LAB 1553 blocks support a subset of SBS Technologies MIL-1553 boards. The underlying software (or driver) of the blocks is based on SBS Technologies API for supporting their 1553 boards.

In a typical MIL-1553 bus, three types of bus-compatible devices are recognized:

• Remote Terminals (RT), passive devices used as interfaces between the bus and the pieces of hardware that should interact and connect to it,
• Bus Controller (BC), a unique device that manages transfers on the bus to ensure the deterministic aspect of 1553 transactions,
• Bus Monitor, a passive device which simply listens to the 1553 transactions.

A 1553 board can simulate one (or more) of these bus items. So, depending on the board model, it may be possible to simulate an entire 1553 system with no more than a single 1553 device. The Opal-RT MIL-1553 driver supports the BC, RT and BM capabilities.

This driver MIL-1553 is supported with QPCX, RPCIE-1553-G2-1MW and RPCIE-1553-G2-4DAW cards. The cards QPCX and  RPCIE-1553-G2-1MW are multi function capable, so they can have each channel configured with three functions such as BC,RT and BM. But the card RPCIE-1553-G2-4DAW is a dual function board, so each channel can be configured with only two functions at a time such as BC/BM or RT/BM.

MIL-1553 Driver Organization Overview

The MIL-1553 driver is based on the RT-LAB asynchronous process architecture. It has the particularity that the model itself does not perform the MIL-1553 communication but rather leaves it to an external program, designated as an asynchronous process (AP). This AP is running on its own, outside of the sample time-based environment of the model, and reacts either to commands from the model or events from the MIL-1553 hardware. The organization of the 1553 environment and its various components is summarized in the figure below:

MATLAB/Simulink

In the RT-LAB set of blocks for 1553, each block represents a specific action (send or receive) along with the necessary parameters (RT/SA numbers, BC command type, …). Those blocks represent the various actions that a model can perform on a 1553 bus.

The most important block is the OpAsync_1553_Ctrl block. This controller block is the convergence point between all the 1553 blocks that are used to interact with a given 1553 device. The controller block is always associated to a specific 1553 hardware, selectable in the block mask from a list of supported devices, and other 1553 blocks are associated to a specific controller by sharing the same Controller ID parameter. The controller also offers global 1553 configuration parameters and hardware specific settings.

Asynchronous Process

The asynchronous process is a standalone application that executes in parallel with the model. Its source code is provided with RT-LAB and the user can, therefore, customize it if required. It communicates with the model through Asynchronous process API and controls the 1553 hardware with the RT-LAB 1553 driver.

The user-defined asynchronous application is usually compiled during the model compilation phase and loaded by the controller block (which receives the name of the AP executable as a parameter).

Even if the content of this application can be customized for user-specific applications, a few typical steps are necessary to initiate the communication link between the model and the 1553 bus:

• Initialize the communication with the Matlab/Simulink model and retrieve the parameters from the various 1553 blocks associated with our controller block,
• Initialize the Opal-RT 1553 driver from those parameters,
• Configure the application runtime behavior,
• Cycle into a send/receive loop to handle the communications between the model and the bus and, if the source code is customized, perform computations on the received/transmitted data,
• When model termination is detected, stop the transactions and reset the board.

MIL-1553 Driver

The MIL-1553 driver is an API, based on SBS Technologies API, called by the asynchronous process to interact with the 1553 hardware.

MIL-1553 Simulink Blocks

At the model/Simulink level, the 1553 hardware is described by a combination of blocks. From the Simulink browser, these blocks are located in the RT-LAB I/O/SBS/MIL-1553 section.

The following blocks are available (for easier reading, block names are shortened from their actual Op_Async_1553_* form):

It is important to note that the presence of either the BC Recv or BC Send blocks makes the 1553 board simulate the BC and therefore stipulates that no external BC is used. The Execute Bus List block may only be used when the BC is simulated.

Following the same idea, the presence of either RT blocks) makes the 1553 board simulate the RT/SA couple it is associated with.

Some boards (like the ASF) cannot simulate simultaneously the RT and BC features. RT and BC blocks cannot be mixed within the same model for these devices.

Controller block (Opal1553_AsyncCtrl)

This block represents a hardware device supporting the MIL-1553 protocol. It is essential to include this block to use the MIL-1553 interface.

This block has several purposes:

• Select the 1553 device to be used
• Provide the user with configuration parameters that are global to the 1553 system
• Specify the name of the asynchronous process executable that must be launched by RT-LAB while the model is loading
• It associates a specific device and a unique Controller Id parameter. This parameter is then used in other 1553 blocks that interface with that specific hardware. This makes it possible to control several devices in the same model, and associate different 1553 blocks to each device..

It is important to understand that the Opal1553_AsyncCtrl does not perform any 1553 initialization or operations. It is used to collect the settings from other associated 1553 blocks, including itself. Afterward, these setttings are passed to the asynchronous process which takes care of the actual hardware management.

For further details on this block, see its documentation.

BC Recv and BC Send Blocks (OpAsync_1553_BC_Recv and OpAsync_1553_BC_Send)

These blocks are used to:

• Exchange data between the model and the asynchronous process
• Declare that the hardware must simulate the Bus Controller, which excludes the possibility of an external Bus Controller. The presence of only one of these block is enough to instantiate the BC.
• Control the operations performed by the BC, including mode codes, and consequently the entire 1553 bus.

The asynchronous application is responsible for updating the output values of these blocks and collecting their input values. The BC Send block sends data to an RT/SA couple when its Data Ready line is active. The BC Recv block as a dual purpose, it sends transmission commands to remote terminals and receives incoming data from its selected RT/SA couple.

For further details on these blocks, see their documentation: BC Recv, BC Send.

RT Recv and RT Send Blocks (OpAsync_1553_RT_Recv and OpAsync_1553_RT_Send)

Each of these blocks is attached to a specific RT/SA couple and they are used to:

• Exchange data between the model and the asynchronous process
• Declare that the hardware must simulate the specified RT/SA, which excludes the possibility of an external Remote Terminal with the same number. The presence of only one of these blocks with a given RT/SA couple is enough to instantiate it.
• Configure the transactions that internally simulated RT/SA couples may perform.

It is important to note that the RT Send block does not trigger the RT/SA transmission. When its Data Ready line is active, the RT Send block signals the asynchronous process to take its input data and provide them to the 1553 hardware. The BC must issue a transaction command before the actual transmission on the 1553 bus occurs.

For further details on these blocks, see their documentation: RT Recv, RT Send.

RT Recv Mode Command and RT Send Mode Command Blocks (OpAsync_1553_Recv_ModeCommand and OpAsync_1553_Send_ModeCommand)

These blocks are used to:

• Exchange data between the model and the asynchronous process
• Perform mode code reception by an RT
• Prepare data to be transmitted by the RT when data transmission mode codes arrive.

Each block allows selecting the type of transaction to be performed along with the associated Mode Command. To have a BC transmitting a mode command, the user must add a BC Send block in the model with the 'bus control operation' set to 'MODE' and specify the command number in the 'mode command' field. To perform a mode command with data reply from an RT, the user must insert a BC Recv block in the model.

For further details on these blocks, see their documentation: RT Recv Mode Command, RT Send Mode Command.

RT Fail Bus Block (OpAsync_1553_Send_Fail_Bus)

This block is used to:

• Exchange data between the model and the asynchronous process
• Simulate bus failure on a Remote Terminal

The bus failure can be simulated either on bus A or B. The bus remains in error as long as either the Fail Bus A or Fail Bus B inputs are active. Bus failure implies that the designated remote terminal will not respond to bus transactions.

For further details on this block, see its documentation.

Execute Bus List Block (OpAsync_1553_BC_Execute_Bus_List)

This block is used to:

• Exchange data between the model and the asynchronous process
• Trigger the automatic execution by the hardware of BC command chains which are predefined in a data file. The name of this data file is specified in the controller block The format of the file will be described in the following section.

This an alternate tool for managing BC transactions. When the block's ready line is active, the BC command designated by the Chain ID input is executed by the hardware. This is an efficient method for quickly executing queued BC->RT and RT->BC transactions. This will be discussed in later sections.

For further details on this block, see its documentation.

RT Enable Block (OpAsync_1553_RT_Enable)

This block is used to:

• Exchange data between the model and the asynchronous process
• Activate or deactivate simulation of a simulated remote terminal at run-time.

For further details on this block, see its documentation.

Monitor Block (OpAsync_1553_Monitor)

This block is used to:

• Exchange data between the model and the asynchronous process
• Listen to received or transmitted messages, including mode commands, for a given RT/SA couple.

Inserting this block in a model does not instentiate simulation of a given RT/SA couple. It may be used whether an RT is external or not.

For further details on this block, see its documentation.

Model Design

Two operating modes are available:

• Direct block control: The Bus Controller blocks, namely BC Send and BC Recv, trigger transactions as they execute. So, executing a BC Send block actually triggers the Bus Controller to perform a send operation and executing the BC Recv block (with Send Tx Command turned on ) triggers a Remote Terminal to transmit.
• Chains lists: BC transaction sets are predefined and Execute Bus list blocks are used to trigger which transaction sets are executed. The main advantage of this method is that using predefined sets allows performing serialized operations that require fewer CPU resources, allowing to achieve minimal inter-message gaps. Its main drawback is that all transaction sets must be defined prior to model execution.

It is advised to read both sections since many concepts are shared between both.

Direct Block Control

This operating mode consists in having the BC Send/Recv blocks triggering the execution of the associated bus transaction. To activate this mode, make sure that the Use bus list parameter from the Controller block is unchecked and remove Execute Bus List blocks from the model. Consider the following model:

We have 1 pair of RT Send/Recv blocks belonging to RT 10/SA 4. The presence of these blocks orders the asynchronous process to have the hardware simulating the behavior of RT 10/SA 4. Triggering the Data ready input on the RT Send block will cause the action of picking up the data on the Data input and placing them on the board's memory buffer so it will be ready for transmission once the BC requests for it. This does not trigger transmission since the MIL-1553 standard does not allow remote terminals to initiate transactions. The RT Recv will raise its status line when data has been received by RT 10/SA 4 and produce the values on its Data output.

On the other hand, we have a pair of BC Recv/Send blocks associated with communication with RT 10/ SA 4. The presence of these blocks orders the AP to have the hardware accomplishBC behavior. Triggering the Data ready input on the BC Send block will have the AP pick up the presented data and place it in the board's memory. Then, the board will perform the operation of transmitting the specified data to RT 10/SA 4. Shortly afterward, the AP will receive a signal (an IRQ) that data was received by RT 10/SA 4 and will return this data to the RT Recv block.

Following the same idea, triggering the Send Tx Command input on the BC Recv block will cause the AP to issue a transmission command to RT 10/ SA 4 which in turn will transmit its prepared data. Shortly afterward, the AP will be notified that the BC received data from RT 10/SA 4 and will return the data on the output of the BC Recv block.

BC Chained Commands

The main philosophy here is that all transactions are defined and grouped in sequences prior to model execution. The same 1553 blocks as in the above example are placed in the model, but they are strictly used as portals between the bus lines and the Simulink model. They do not trigger transactions anymore. The following figure displays the equivalent model to the previous example, adapted for the use of chained commands. In the Controller block mask, the Use bus list parameter is checked and a bus list file has been specified.

Notice the addition of the Execute Bus List block. This block, when its Ready input is active, will trigger the execution of a chain of 2 BC transactions. These 2 transactions were previously defined in a bus list file. Such a file is displayed here:

In this example, the two commands are: first, an RT-BC transaction (identified by 3 in the Command column) and second, a BC-RT transaction (identified by 2 in the Command column). Both transactions are indicated as interacting with RT 10/SA 4 and having specified data lengths of 32 words.

Notice both commands share the same Chain ID. So, when the Exec Bus List block is triggered, with chain ID 1, both commands will be executed sequentially. It would also have been possible to give both commands different Chain ID identifiers, let's say 1 and 2. This would have created two chains containing one command. Each chain execution would then have been triggered by setting the Exec Bus List block input to the specific chain ID value. It is also possible to place more than one Exec Bus List block in a model in order to trigger more than one chain per step.

Bus List File Format

The format of the Bus List file is specific to RT-LAB 1553 driver, and will now be described.. The file is used to describe BC command chains and also contains several parameters that may supersede parameters already specified in the Controller block. Please refer to be above section for an example of Bus List file.

The file is divided into 3 section

1. Short section containing the number of commands listed in the file. In the above example, it was 2. Must start with a numerical character on a new line.
2. A set of configuration parameters. Must start with a numerical character on a new line.
3. Command entries listed one after the other. Must start with a numerical character on a new line and must be delimited from section 2 with a line starting with four underscores '____'. Up to 64 chains ids may be defined in these lines.

Configuration Parameters (or Bus List Link Parameters)

The parameters are included as a list of 15 integers.

Each value is described below:

Command Entries

Each command is described as a list of 16 integers. Each value is described below:

External devices

If it is required to interact with external Remote Terminals a Bus Controller, it is essential that the model does not contain blocks that would instantiate the simulation of those devices. For instance, to communicate with RT 4/ SA 10, it is important that the model does not contain any RT blocks assigned to number 4. On the other hand, it may contain BC Send/Recv assigned to RT 4/SA 10 in order to have a BC interacting with it.

To use an external BC, remove the BC Send/Recv and Execute Bus List from the model.

Model Loading and Execution

The MIL-1553 example model found in the "Examples\IO\SBS\MIL-1553\ABI\simulink" folder of RT-LAB provides a basic framework that introduces and handles many aspects of the 1553 driver usage.

The model uses a 1553 device to simulate both a BC and an RT and it contains:

• one pair of BC Send / Recv blocks to simulate a Bus Controller on the bus and initiate transactions,
• one set contains RT Send / Recv blocks to simulate addressable elements on the bus to receive and send data,

Several files are included with the model

• AsyncProc_1553_ABI.mk: Asynchronous process makefile, required at compilation
• AsyncProc_1553_ABI.c: The asynchronous process source file, required at compilation
• f040m1.dat: Firmware file for the 1553 device, required at model execution

The following steps will guide you through the steps necessary to execute the model. The configuration steps have already been made for the example but they are nonetheless detailed since it will be necessary to perform these for any new model.

• Step 1: Open the model with RT-LAB.
  Open the model in the current version of RT-LAB. The model has been made to be used at least with a version R13 of Matlab.
• Step 2: RT-LAB configuration.
  The asynchronous process is usually compiled along with the model compilation. To indicate to RT-LAB that it has to take care of this extra compilation step, make sure that all the necessary sources files, makefiles and potential firmware files are transferred to the target during compilation in the Advanced Settings > Files & Commands panel

Notice we also added the compiled executable in the file list. This is done because if one needs to execute the model on a system is different from the one used for compilation, the executable must be retrieved from the compilation node (See File to retrieve from the target in the above window), and next transferred to the execution node along with the f040m1.dat file.

If the execution and compilation occur on the same system, retransferring the compiled asynchronous process is not necessary.

Make sure that "compilation command" is specified to start the compilation of the asynchronous processing the panel below. The complete command line is :
/usr/bin/make -f /usr/opalrt/common/bin/opalmodelmk

• Step 3: Compile the model.
  The asynchronous process is compiled at the start of the target compilation.
• Step 4: Load the model.
  As soon as the model enters in the load phase, the asynchronous process is started on the target node. The board is then initialized and the communication with the model is started. When pressing the "Execute" button, the asynchronous application enters a send/receive loop and takes care of the 1553 bus transactions.

Asynchronous Process Timing Considerations

It is important to realize that an asynchronous process does not execute simultaneously with the model. It rather executes when the model is not executing, typically when waiting for the beginning of the next calculation step. The following figure depicts this situation:

A consequence of this is that the AP will not execute model commands (blocks BC Send, BC Recv, RT Send, RT Send Mode Command, RT Fail Bus, Execute Bus List) until after the model finished computing. All the commands triggering by the model are compiled and later executed in order of increasing send IDs (smallest Send ID runs first). It is also of importance to allow enough free time between the end of model computation and the beginning of the next step for the AP to complete its task.

For the RT Recv reception size, the AP is woken up by the hardware when a message comes in, it is passed to the model as soon as time allows. The data is most usually accessible from the model during the following step. For the execution of BC Recv, the AP first sends the transmission command and waits for the data to come in.

It is possible to synchronize the execution of the commands with the model. Set the Sending mode parameter of the BC Send, RT Send or RT Send Mode Command to "NEED REPLY NOW". For the BC Recv block, the equivalent parameter is called Waiting option and must be set to "Block execution until....". The effect of these parameters is that when those blocks are activated (Data ready input, Send Tx Command input...), the model will immediately stop execution and wait for the AP to execute the requested task. Remember that such a synchronization algorithm brings in a lot of CPU task switchings and may increase the time required to perform the execution cycle.