RT Blockset

The Real-Time Blockset is born in the context of my former study at university of Rome, when I was trying to run the Simulink models at the same speed of the real time processes. At that time, no Real-Time solution was available (like xPC or RTWT) and moreover, the solutions based on an external real-time card was too expensive.

The OS where this solution was first developed is Windows NT 4.0, then this blockset is based on the Win32 library timing functions and process control functions. The actual released blockset has been realized only for the Windows platform and has been tested on a Win2000 and WinME OS with different speed processors.

Updates

The blockset is actually composed by only one block, that has been realized using an S-function written in C++ language. Respect to the other products, the RT blockset doesn't use a separate OS or runs a RT kernel to provide an RT simulation. This blockset is based on the simple concept that, to make the Simulink run with a real-time temporization, the cycle time (the time that Simulink needs to calculate a simulation step, that is function of the hardware and the OS in which Simulink is running) should be lower then the desired simulation step. If this assumption is not valid, no real-time simulation is possible, whichever is the applied scheduling method. 

Obviously, this statement is not completely valid, for example if we suppose to work with a real-time OS, in which the scheduling can be fully controlled. Anyway, the Windows OS is not in this case, because it's a multitasking environment with a partial controllable scheduling approach. The only controllable feature of Windows is the possibility of assigning a greater priority to the running process. In this blockset, a block allows the selection of the preferred priority to assign to Simulink. 

This blockset simply hold the execution of the Simulink simulation attached to the time flow, in the sense that, if the cycle time is lower then the simulation step, this block wait for the time needed to fill the simulation step, leaving the remaining CPU time to all the WIndows Process that need it. This concept is very simple but effective.

Another feature that may let you prefer this blockset respect to xPC and RTWT, is the lack of limitation that this block impose to the use of Win32 instruction in your C/C++ S-functions. xPC, for example, being running in a separated OS, doesn't allow the use of many features normally available on Windows, like the full file access, the control of particular control board, or even the installation of a number of serial port greater then four. RTWT, instead, running in a separated virtual machine, limits the use of the instructions in Simulink (i.e.: sockets, particular file access, and others, often needed, instructions).

This blockset may virtually cooperate with any Win32 or DirectX instruction. Personally, I tested the RTW version of this block even on WinNT Embedded, with interesting results. 

The RT blocks description

The limitations of the RT blocks in a Simulink (non RTW) environment

The rule of the RT block is to keep the simulation attached to the real time. The major obstacle to this behaviour is the actions of the user during the simulation. Any window process, in fact, is constrained to manage windows messages, like the mouse messages. Matlab and Simulink are typical Windows application (contained in an unique process) and normally, they are blocked or delayed if an user send multiple messages (like the simple holding down of the mouse message).

Due to the fact that the RT block attempts to enhance the priority of the Simulink environment, the simulation is protected from the other processes but not from the Simulink itself. In few words, during the simulation , do not use or move the mouse over any  Simulink Window, that runs in the same thread as the simlation managed by the RT block.

For the purpose of understanding what can be cause of delay for your simulation, I want to remember that Matlab and Simulink runs the same process, while Simulink runs in a separated thread. Then, increasing the priority of the process, it will increase the priority of both Matlab and Simulink respect to the other processes; increasing the priority of the simulation thread, it will increase the priority of Simulink respect to Matlab and all the other applications.  

This problem will not affect the simulation compiled with the RT Workshop, when the RTW blockset will be available, because the simulation, in this case, runs in a separated process.

The enhancements resulting of a greater priority of a process and/or a thread is more evident under NT-like OS (WinNT and Win2000) respect to the 9x-like OS (Win98, WinME), due to the greater control of the processor offered by the NT' OSs.

RT blockset Application Example

An application example is the one contained in the installation pack of the blockset (RTex.mdl). In this simple example, the timer constraint the execution of the filter function over a pulse function. The simulation is performed with a fixed step, integration ode3, timestep 0.05 seconds, duration 10 seconds.

The simulation has been executed during the execution of another CPU-time requiring process, a Visual Studio build of a project that requires 7-8 seconds of a normal priority task. The compilation is launched soon after the start of the simulation. Before starting the building, the mouse pointer has been moved over a toolbar icon of Simulink, just the time to wait that the tooltip is shown. This last simple operation is instead very heavy for an application, as is shown in the figure that follows. Due to the fact that the toolbar belongs to Simulink, that is in the same thread where the simulation runs, a sharp peak of CPU request results in the simulation.

The results are reported in the graphs that follows, using different priority for the RTBlock. The blu line represents the delay in the execution of the timestep (that should be near to zero, in this case 50 ms), while the green line represents the remaining time for which Simulink waits for the next step (and leave the CPU to the remaining Windows applications). The first delaying operation occurs at 2 secs, while the build starts at 4 secs and ends after the end of the simulation 8.7 secs. 

Note the effect of the other windows application on the task. The effect is visible on the first simulation but invisible in the second and third simulation. Another effect that is due only to Simulink is the little delay present at the start of the simulation, due to the initialization of the graph window (that is erased and redrawed, operation that needs much processing time). This effect is not visible in the last simulation. The sharp peak at 2 seconds is always present in all the simulations because the change of priority is effective respect to others tasks but not respect to Simulink itself.

The RTW release of the RT blockset

The preceding experience has been repeated launching the RTW version of the simulation, applying tha same disturbs. As you can see, the tooltip showed by Simulink has no effect in the simulation, while the simulation runs without any delay when the process and thread priority is greater respect to other windows tasks. 

How to use the RT block 

The RT block delays the simulation until the next time run occurs. Then, is better to put the Simulink block as the first block in your model (i.e., the first block added in the model), or using the output of the block to conditioning the execution of a subsystem in which your simulation block resides, as shown in the figure that follows. 

The input In1 of the subsystem that contains your simulation, is only added to let the subsystem depends on the RTBlock function.

How to build your model with Real Time Workshop

To make your stand-alone simulation with RTW, you have to add to the RTW make the following files:

These file must be copied in your current directory (the directory where are your model).

To compile and link successfully with RTW a project that contains a RT Block, you should set the following options:

To see an example of settings, open the rtex.mdl model.

Information and Warranty for the End User

I must remember to all the users of this blockset that this is a product not covered by any warranty about its working performances and characteristics, because it's completely free.  All the material and the manual has been realized by myself independently from any contractual constraint with any University or company, then the intellectual property is exclusive of the author (me). 

The present library is actually under development and more blocks will be added. The notice from the users of any problem will be appreciated and recorded and any collaboration will be mentioned in the final version of the blockset.

At the start of this page, a link to the file RT.zip allows the download of the RT blockset library. The zip file has been memorized without any reference to an installation directory, then the directory will be selected from the end user at the installation time.

After the start of the Winzip (or equivalent) program, press the button "Extract" to extract all files in the desired directory. Preferably, select a folder (or create a new folder) insied the <MatlabDir>\work directory.

Installation Directory selection window

After the completion of the setup, add the path of the selected directory utilizing the menu item File-->Set Path...

Now the installation is complete. To open the RT Blockset library is sufficient to type in the Matlab command window the command "RT". A window containing all the available blocks will be displayed.