| Real-Time Workshop | |
www.kxcad.net Home > CAE Software Index > MATLAB Index >
| On this page… |
|---|
Multitasking and Pseudomultitasking Modes Building a Program for Multitasking Execution Building a Program for Single-Tasking Execution Model Execution and Rate Transitions |
There are two execution modes for a fixed-step Simulink model: single-tasking and multitasking. These modes are available only for fixed-step solvers. To select an execution mode, use the Tasking mode for periodic sample times menu on the Solver pane of the Configuration Parameters dialog box. Auto mode (the default) applies multitasking execution for a multirate model, and otherwise selects single-tasking execution. You can also select Single-tasking or MultiTasking execution explicitly.
Execution of models in a real-time system can be done with the aid of a real-time operating system, or it can be done on a bare-board target, where the model runs in the context of an interrupt service routine (ISR).
The fact that a system (such as UNIX or Microsoft Windows) is multitasking does not guarantee that your program can execute in real time. This is because it is not guaranteed that the program can preempt other processes when required.
In operating systems (such as PC-DOS) where only one process can exist at any given time, an interrupt service routine (ISR) must perform the steps of saving the processor context, executing the model code, collecting data, and restoring the processor context.
Other operating systems, such as POSIX-compliant ones, provide automatic context switching and task scheduling. This simplifies the operations performed by the ISR. In this case, the ISR simply enables the model execution task, which is normally blocked. The next figure illustrates this difference.
This chapter focuses on when and how the run-time interface executes the generated code for your model. See Program Execution for a description of what happens during model execution.
In cases where the continuous part of a model executes at a rate that is different from the discrete part, or a model has blocks with different sample rates, Simulink assigns each block a task identifier (tid) to associate the block with the task that executes at the block's sample rate.
You set sample rates and their constraints on the Solver pane of the Configuration Parameters dialog box. To generate code with Real-Time Workshop, you must select Fixed-step for the solver type. Certain restrictions apply to the sample rates that you can use:
The sample rate of any block must be an integer multiple of the base (that is, the fastest) sample period.
When Periodic sample time constraint is unconstrained, the base sample period is determined by the Fixed step size specified on the Solvers pane of the Configuration parameters dialog box.
When Periodic sample time constraint is Specified, the base rate fixed-step size is the first element of the sample time matrix that you specify in the companion option Sample time properties. The Solver pane from the demo model rtwdemo_mrmtbb shows an example.
Continuous blocks always execute by using an integration algorithm that runs at the base sample rate. The base sample period is the greatest common denominator of all rates in the model only when Periodic sample time constraint is set to Unconstrained and Fixed step size is Auto.
The continuous and discrete parts of the model can execute at different rates only if the discrete part is executed at the same or a slower rate than the continuous part and is an integer multiple of the base sample rate.
When periodic tasks execute in a multitasking mode, by default the blocks with the fastest sample rates are executed by the task with the highest priority, the next fastest blocks are executed by a task with the next higher priority, and so on. Time available in between the processing of high-priority tasks is used for processing lower priority tasks. This results in efficient program execution.
Where tasks are asynchronous rather than periodic, there may not necessarily be a relationship between sample rates and task priorities; the task with the highest priority need not have the fastest sample rate. You specify asynchronous task priorities using Async Interrupt and Task Synchronization blocks. You can switch the sense of what priority numbers mean by selecting or deselecting the Solver option Higher priority value indicates higher task priority.
In multitasking environments (that is, under a real-time operating system), you can define separate tasks and assign them priorities. In a bare-board target (that is, no real-time operating system present), you cannot create separate tasks. However, Real-Time Workshop application modules implement what is effectively a multitasking execution scheme using overlapped interrupts, accompanied by programmatic context switching.
This means an interrupt can occur while another interrupt is currently in progress. When this happens, the current interrupt is preempted, the floating-point unit (FPU) context is saved, and the higher priority interrupt executes its higher priority (that is, faster sample rate) code. Once complete, control is returned to the preempted ISR.
The next figures illustrate how timing of tasks in multirate systems are handled by Real-Time Workshop in multitasking, pseudomultitasking, and single-tasking environments.
The next figure shows how overlapped interrupts are used to implement pseudomultitasking. In this case, Interrupt 0 does not return until after Interrupts 1, 2, and 3.
To use multitasking execution, select Auto (the default) or MultiTasking from the Tasking mode for periodic sample times menu on the Solver pane of the Configuration Parameters dialog box. This menu is active only if you select Fixed-step as the solver type. Auto mode results in a multitasking environment if your model has two or more different sample times. A model with a continuous and a discrete sample time runs in single-tasking mode if the fixed-step size is equal to the discrete sample time.
You can execute model code in a strictly single-tasking manner. While this mode is less efficient with regard to execution speed, in certain situations, it can simplify your model.
In single-tasking mode, the base sample rate must define a time interval that is long enough to allow the execution of all blocks within that interval.
The next figure illustrates the inefficiency inherent in single-tasking execution.
Single-tasking system execution requires a base sample rate that is long enough to execute one step through the entire model.
To use single-tasking execution, select Single-tasking from the Tasking mode for periodic sample times menu on the Solver pane of the Configuration Parameters dialog box. If you select Auto, single-tasking is used in the following cases:
If your model contains one sample time
If your model contains a continuous and a discrete sample time and the fixed step size is equal to the discrete sample time
To generate code that executes correctly in real time, you (or Simulink) might need to identify and properly handle sample rate transitions within the model. In multitasking mode, by default Simulink flags errors during simulation if the model contains invalid rate transitions, although you can use the Multitask rate transition diagnostic to alter this behavior. A similar diagnostic, called Single task rate transition, exists for single-tasking mode.
To avoid raising rate transition errors, insert Rate Transition blocks between tasks. You can request Simulink to handle rate transitions automatically by inserting hidden Rate Transition blocks. See Automatic Rate Transition for an explanation of this option.
To understand such problems, first consider how Simulink simulations differ from real-time programs.
Before Simulink simulates a model, it orders all the blocks based upon their topological dependencies. This includes expanding virtual subsystems into the individual blocks they contain and flattening the entire model into a single list. Once this step is complete, each block is executed in order.
The key to this process is the proper ordering of blocks. Any block whose output is directly dependent on its input (that is, any block with direct feedthrough) cannot execute until the block driving its input executes.
Some blocks set their outputs based on values acquired in a previous time step or from initial conditions specified as a block parameter. The output of such a block is determined by a value stored in memory, which can be updated independently of its input. During simulation, all necessary computations are performed prior to advancing the variable corresponding to time. In essence, this results in all computations occurring instantaneously (that is, no computational delay).
A real-time program differs from a Simulink simulation in that the program must execute the model code synchronously with real time. Every calculation results in some computational delay. This means the sample intervals cannot be shortened or lengthened (as they can be in Simulink), which leads to less efficient execution.
Consider the following timing figure.
Note the processing inefficiency in the sample interval t1. That interval cannot be compressed to increase execution speed because, by definition, sample times are clocked in real time.
You can circumvent this potential inefficiency by using the multitasking mode. The multitasking mode defines tasks with different priorities to execute parts of the model code that have different sample rates.
See Multitasking and Pseudomultitasking Modes for a description of how this works. It is important to understand that section before proceeding here.
Single-tasking programs require longer sample intervals, because all computations must be executed within each clock period. This can result in inefficient use of available CPU time, as shown in the previous figure.
Multitasking mode can improve the efficiency of your program if the model is large and has many blocks executing at each rate.
However, if your model is dominated by a single rate, and only a few blocks execute at a slower rate, multitasking can actually degrade performance. In such a model, the overhead incurred in task switching can be greater than the time required to execute the slower blocks. In this case, it is more efficient to execute all blocks at the dominant rate.
If you have a model that can benefit from multitasking execution, you might need to modify your Simulink model by adding Rate Transition blocks (or instruct Simulink to do so) to generate correct results. The next section, Sample Rate Transitions, discusses issues related to rate transition blocks.
| | Introduction | Sample Rate Transitions | |
© 1984-2007 The MathWorks, Inc. • Terms of Use • Patents • Trademarks • Acknowledgments