| Real-Time Workshop® | |
Before looking at the two styles of generated code, you need to have a high-level understanding of how the generated model code is executed. The Real-Time Workshop® software generates algorithmic code as defined by your model. You can include your own code in your model by using S-functions. S-functions can range from high-level signal manipulation algorithms to low-level device drivers.
The Real-Time Workshop product also provides a run-time interface that executes the generated model code. The run-time interface and model code are compiled together to create the model executable. The next figure shows a high-level object-oriented view of the executable.
The Object-Oriented View of a Real-Time Program
In general, the conceptual design of the model execution driver does not change between the rapid prototyping and embedded style of generated code. The following sections describe model execution for single-tasking and multitasking environments both for simulation (non-real-time) and for real time. For most models, the multitasking environment will provide the most efficient model execution (that is, fastest sample rate).
The following concepts are useful in describing how models execute. Function names used in ERT and GRT targets are shown, followed by the comparable GRT-compatible calls in parentheses.
Initialization: model_initialize (MdlInitializeSizes, MdlInitializeSampleTimes, MdlStart) initializes the run-time interface code and the model code.
ModelOutputs: Calling all blocks in your model that have a sample hit at the current time and having them produce their output. model_output (MdlOutputs) can be done in major or minor time steps. In major time steps, the output is a given simulation time step. In minor time steps, the run-time interface integrates the derivatives to update the continuous states.
ModelUpdate: model_update (MdlUpdate) calls all blocks in your model that have a sample hit at the current point in time and has them update their discrete states or similar type objects.
ModelDerivatives: Calling all blocks in your model that have continuous states and having them update their derivatives. model_derivatives is only called in minor time steps.
ModelTerminate: model_terminate (MdlTerminate) terminates the program if it is designed to run for a finite time. It destroys the real-time model data structure, deallocates memory, and can write data to a file.
The identifying names in the preceding list (ModelOutputs, and so on) identify functions in pseudocode examples shown in the following sections.
For a complete set of correspondences between GRT and ERT function identifiers, see the table Identifiers for Real-Time Model Data Structure Variants.
The pseudocode below shows the execution of a model for a non-real-time single-tasking system.
main()
{
Initialization
While (time < final time)
ModelOutputs -- Major time step.
LogTXY -- Log time, states and root outports.
ModelUpdate -- Major time step.
Integrate -- Integration in minor time step for
-- models with continuous states.
ModelDerivatives
Do 0 or more
ModelOutputs
ModelDerivatives
EndDo -- Number of iterations depends upon the solver
Integrate derivatives to update continuous states.
EndIntegrate
EndWhile
Termination
}
The initialization phase begins first. This consists of initializing
model states and setting up the execution engine. The model then executes,
one step at a time. First ModelOutputs executes
at time t, then the workspace I/O data is logged,
and then ModelUpdate updates the discrete states.
Next, if your model has any continuous states, ModelDerivatives integrates
the continuous states' derivatives to generate the states for time
, where h is
the step size. Time then moves forward to
and the process repeats.
During the ModelOutputs and ModelUpdate phases of model execution, only blocks that reach the current point in time execute.
The pseudocode below shows the execution of a model for a non-real-time multitasking system.
main()
{
Initialization
While (time < final time)
ModelOutputs(tid=0) -- Major time step.
LogTXY -- Log time, states, and root
-- outports.
ModelUpdate(tid=0) -- Major time step.
Integrate -- Integration in minor time step for
-- models with continuous states.
ModelDerivatives
Do 0 or more
ModelOutputs(tid=0)
ModelDerivatives
EndDo (Number of iterations depends upon the solver.)
Integrate derivatives to update continuous states.
EndIntegrate
For i=1:NumTids
ModelOutputs(tid=i) -- Major time step.
ModelUpdate(tid=i) -- Major time step.
EndFor
EndWhile
Termination
}
Multitasking operation is more complex than single-tasking execution because the output and update functions are subdivided by the task identifier (tid) that is passed into these functions. This allows for multiple invocations of these functions with different task identifiers using overlapped interrupts, or for multiple tasks when using a real-time operating system. In simulation, multiple tasks are emulated by executing the code in the order that would occur if there were no preemption in a real-time system.
Multitasking execution assumes that all tasks are multiples of the base rate. The Simulink® product enforces this when you create a fixed-step multitasking model. The multitasking execution loop is very similar to that of single-tasking, except for the use of the task identifier (tid) argument to ModelOutputs and ModelUpdate.
The pseudocode below shows the execution of a model in a real-time single-tasking system where the model is run at interrupt level.
rtOneStep()
{
Check for interrupt overflow
Enable "rtOneStep" interrupt
ModelOutputs -- Major time step.
LogTXY -- Log time, states and root outports.
ModelUpdate -- Major time step.
Integrate -- Integration in minor time step for models
-- with continuous states.
ModelDerivatives
Do 0 or more
ModelOutputs
ModelDerivatives
EndDo (Number of iterations depends upon the solver.)
Integrate derivatives to update continuous states.
EndIntegrate
}
main()
{
Initialization (including installation of rtOneStep as an
interrupt service routine, ISR, for a real-time clock).
While(time < final time)
Background task.
EndWhile
Mask interrupts (Disable rtOneStep from executing.)
Complete any background tasks.
Shutdown
}
Real-time single-tasking execution is very similar to non-real-time single-tasking execution, except that instead of free-running the code, the rt_OneStep function is driven by a periodic timer interrupt.
At the interval specified by the program's base sample rate, the interrupt service routine (ISR) preempts the background task to execute the model code. The base sample rate is the fastest in the model. If the model has continuous blocks, then the integration step size determines the base sample rate.
For example, if the model code is a controller operating at 100 Hz, then every 0.01 seconds the background task is interrupted. During this interrupt, the controller reads its inputs from the analog-to-digital converter (ADC), calculates its outputs, writes these outputs to the digital-to-analog converter (DAC), and updates its states. Program control then returns to the background task. All these steps must occur before the next interrupt.
The following pseudocode shows how a model executes in a real-time multitasking system where the model is run at interrupt level.
rtOneStep()
{
Check for interrupt overflow
Enable "rtOneStep" interrupt
ModelOutputs(tid=0) -- Major time step.
LogTXY -- Log time, states and root outports.
ModelUpdate(tid=0) -- Major time step.
Integrate -- Integration in minor time step for
-- models with continuous states.
ModelDerivatives
Do 0 or more
ModelOutputs(tid=0)
ModelDerivatives
EndDo (Number of iterations depends upon the solver.)
Integrate derivatives and update continuous states.
EndIntegrate
For i=1:NumTasks
If (hit in task i)
ModelOutputs(tid=i)
ModelUpdate(tid=i)
EndIf
EndFor
}
main()
{
Initialization (including installation of rtOneStep as an
interrupt service routine, ISR, for a real-time clock).
While(time < final time)
Background task.
EndWhile
Mask interrupts (Disable rtOneStep from executing.)
Complete any background tasks.
Shutdown
}
Running models at interrupt level in a real-time multitasking environment is very similar to the previous single-tasking environment, except that overlapped interrupts are employed for concurrent execution of the tasks.
The execution of a model in a single-tasking or multitasking environment when using real-time operating system tasking primitives is very similar to the interrupt-level examples discussed above. The pseudocode below is for a single-tasking model using real-time tasking primitives.
tSingleRate()
{
MainLoop:
If clockSem already "given", then error out due to overflow.
Wait on clockSem
ModelOutputs -- Major time step.
LogTXY -- Log time, states and root
-- outports
ModelUpdate -- Major time step
Integrate -- Integration in minor time step
-- for models with continuous
-- states.
ModelDeriviatives
Do 0 or more
ModelOutputs
ModelDerivatives
EndDo (Number of iterations depends upon the solver.)
Integrate derivatives to update continuous states.
EndIntegrate
EndMainLoop
}
main()
{
Initialization
Start/spawn task "tSingleRate".
Start clock that does a "semGive" on a clockSem semaphore.
Wait on "model-running" semaphore.
Shutdown
}
In this single-tasking environment, the model executes as real-time operating system tasking primitives. In this environment, create a single task (tSingleRate) to run the model code. This task is invoked when a clock tick occurs. The clock tick gives a clockSem (clock semaphore) to the model task (tSingleRate). The model task waits for the semaphore before executing. The clock ticks occur at the fundamental step size (base rate) for your model.
The pseudocode below is for a multitasking model using real-time tasking primitives.
tSubRate(subTaskSem,i)
{
Loop:
Wait on semaphore subTaskSem.
ModelOutputs(tid=i)
ModelUpdate(tid=i)
EndLoop
}
tBaseRate()
{
MainLoop:
If clockSem already "given", then error out due to overflow.
Wait on clockSem
For i=1:NumTasks
If (hit in task i)
If task i is currently executing, then error out due to
overflow.
Do a "semGive" on subTaskSem for task i.
EndIf
EndFor
ModelOutputs(tid=0) -- major time step.
LogTXY -- Log time, states and root outports.
ModelUpdate(tid=0) -- major time step.
Loop: -- Integration in minor time step for
-- models with continuous states.
ModelDeriviatives
Do 0 or more
ModelOutputs(tid=0)
ModelDerivatives
EndDo (number of iterations depends upon the solver).
Integrate derivatives to update continuous states.
EndLoop
EndMainLoop
}
main()
{
Initialization
Start/spawn task "tSubRate".
Start/spawn task "tBaseRate".
Start clock that does a "semGive" on a clockSem semaphore.
Wait on "model-running" semaphore.
Shutdown
}
In this multitasking environment, the model is executed using real-time operating system tasking primitives. Such environments require several model tasks (tBaseRate and several tSubRate tasks) to run the model code. The base rate task (tBaseRate) has a higher priority than the subrate tasks. The subrate task for tid=1 has a higher priority than the subrate task for tid=2, and so on. The base rate task is invoked when a clock tick occurs. The clock tick gives a clockSem to tBaseRate. The first thing tBaseRate does is give semaphores to the subtasks that have a hit at the current point in time. Because the base rate task has a higher priority, it continues to execute. Next it executes the fastest task (tid=0), consisting of blocks in your model that have the fastest sample time. After this execution, it resumes waiting for the clock semaphore. The clock ticks are configured to occur at the fundamental step size for your model.
Real-time programs require careful timing of the task invocations (either by using an interrupt or a real-time operating system tasking primitive) to ensure that the model code executes to completion before another task invocation occurs. This includes time to read and write data to and from external hardware.
The next figure illustrates interrupt timing.
Task Timing
The sample interval must be long enough to allow model code execution between task invocations.
In the figure above, the time between two adjacent vertical arrows is the sample interval. The empty boxes in the upper diagram show an example of a program that can complete one step within the interval and still allow time for the background task. The gray box in the lower diagram indicates what happens if the sample interval is too short. Another task invocation occurs before the task is complete. Such timing results in an execution error.
Note also that, if the real-time program is designed to run forever (that is, the final time is 0 or infinite so the while loop never exits), then the shutdown code never executes.
For more information on how the timing engine works, see Timing Services.
As the previous section indicates, a real-time program cannot require 100% of the CPU's time. This provides an opportunity to run background tasks during the free time.
Background tasks include operations such as writing data to a buffer or file, allowing access to program data by third-party data monitoring tools, or using Simulink external mode to update program parameters.
It is important, however, that the program be able to preempt the background task at the appropriate time to ensure real-time execution of the model code.
The way the program manages tasks depends on capabilities of the environment in which it operates.
External mode allows communication between the Simulink block diagram and the standalone program that is built from the generated code. In this mode, the real-time program functions as an interprocess communication server, responding to requests from the Simulink engine.
The Real-Time Workshop data-logging features, described in Configuring a Model for Data Logging, enable you to save system states, outputs, and time to a MAT-file at the completion of the model execution. The LogTXY function, which performs data logging, operates differently in single-tasking and multitasking environments.
If you examine how LogTXY is called in the single-tasking and multitasking environments, you will notice that for single-tasking LogTXY is called after ModelOutputs. During this ModelOutputs call, all blocks that have a hit at time t execute, whereas in multitasking, LogTXY is called after ModelOutputs(tid=0), which executes only the blocks that have a hit at time t and that have a task identifier of 0. This results in differences in the logged values between single-tasking and multitasking logging. Specifically, consider a model with two sample times, the faster sample time having a period of 1.0 second and the slower sample time having a period of 10.0 seconds. At time t = k*10, k=0,1,2... both the fast (tid=0) and slow (tid=1) blocks execute. When executing in multitasking mode, when LogTXY is called, the slow blocks execute, but the previous value is logged, whereas in single-tasking the current value is logged.
Another difference occurs when logging data in an enabled subsystem. Consider an enabled subsystem that has a slow signal driving the enable port and fast blocks within the enabled subsystem. In this case, the evaluation of the enable signal occurs in a slow task, and the fast blocks see a delay of one sample period; thus the logged values will show these differences.
To summarize differences in logged data between single-tasking and multitasking, differences will be seen when
Any root outport block has a sample time that is slower than the fastest sample time
Any block with states has a sample time that is slower than the fastest sample time
Any block in an enabled subsystem where the signal driving the enable port is slower than the rate of the blocks in the enabled subsystem
For the first two cases, even though the logged values are different between single-tasking and multitasking, the model results are not different. The only real difference is where (at what point in time) the logging is done. The third (enabled subsystem) case results in a delay that can be seen in a real-time environment.
The rapid prototyping program framework provides a common application programming interface (API) that does not change between model definitions.
The Real-Time Workshop® Embedded Coder™ product provides a different framework called the embedded program framework. The embedded program framework provides an optimized API that is tailored to your model. When you use the embedded style of generated code, you are modeling how you would like your code to execute in your embedded system. Therefore, the definitions defined in your model should be specific to your embedded targets. Items such as the model name, parameter, and signal storage class are included as part of the API for the embedded style of code.
One major difference between the rapid prototyping and embedded style of generated code is that the latter contains fewer entry-point functions. The embedded style of code can be configured to have only one run-time function, model_step.
Thus, when you look again at the model execution pseudocode presented earlier in this chapter, you can eliminate the Loop...EndLoop statements, and group ModelOutputs, LogTXY, and ModelUpdate into a single statement, model_step.
For a detailed discussion of how generated embedded code executes, see the Real-Time Workshop Embedded Coder documentation.
The rapid prototyping code defines the following functions that interface with the run-time interface:
Model(): The model registration function. This function initializes the work areas (for example, allocating and setting pointers to various data structures) needed by the model. The model registration function calls the MdlInitializeSizes and MdlInitializeSampleTimes functions. These two functions are very similar to the S-function mdlInitializeSizes and mdlInitializeSampleTimes methods.
MdlStart(void): After the model registration functions MdlInitializeSizes and MdlInitializeSampleTimes execute, the run-time interface starts execution by calling MdlStart. This routine is called once at startup.
The function MdlStart has four basic sections:
Code to initialize the states for each block in the root model that has states. A subroutine call is made to the "initialize states" routines of conditionally executed subsystems.
Code generated by the one-time initialization (start) function for each block in the model.
Code to enable the blocks in the root model that have enable methods, and the blocks inside triggered or function-call subsystems residing in the root model. Simulink blocks can have enable and disable methods. An enable method is called just before a block starts executing, and the disable method is called just after the block stops executing.
Code for each block in the model that has a constant sample time.
MdlOutputs(int_T tid): MdlOutputs updates the output of blocks at appropriate times. The tid (task identifier) parameter identifies the task that in turn maps when to execute blocks based upon their sample time. This routine is invoked by the run-time interface during major and minor time steps. The major time steps are when the run-time interface is taking an actual time step (that is, it is time to execute a specific task). If your model contains continuous states, the minor time steps will be taken. The minor time steps are when the solver is generating integration stages, which are points between major outputs. These integration stages are used to compute the derivatives used in advancing the continuous states. The solver is called to updates
MdlUpdate(int_T tid): MdlUpdate updates the states and work vector state information (that is, states that are neither continuous nor discrete) saved in work vectors. The tid (task identifier) parameter identifies the task that in turn indicates which sample times are active, allowing you to conditionally update only states of active blocks. This routine is invoked by the run-time interface after the major MdlOutputs has been executed. The solver is also called, and model_Derivatives is called in minor steps by the solver during its integration stages. All blocks that have continuous states have an identical number of derivatives. These blocks are required to compute the derivatives so that the solvers can integrate the states.
MdlTerminate(void): MdlTerminate contains any block shutdown code. MdlTerminate is called by the run-time interface, as part of the termination of the real-time program.
The contents of the above functions are directly related to the blocks in your model. A Simulink block can be generalized to the following set of equations.
Output y is a function of continuous state xc, discrete state xd, and input u. Each block writes its specific equation in the appropriate section of MdlOutput.
The discrete states xd are a function of the current state and input. Each block that has a discrete state updates its state in MdlUpdate.
The derivatives x are a function of the current input. Each block that has continuous states provides its derivatives to the solver (for example, ode5) in model_Derivatives. The derivatives are used by the solver to integrate the continuous state to produce the next value.
The output, y, is generally written to the block I/O structure. Root-level Outport blocks write to the external outputs structure. The continuous and discrete states are stored in the states structure. The input, u, can originate from another block's output, which is located in the block I/O structure, an external input (located in the external inputs structure), or a state. These structures are defined in the model.h file that the Real-Time Workshop software generates.
The next example shows the general contents of the rapid prototyping style of C code written to the model.c file.
The next figure shows a flow chart describing the execution of the rapid prototyping generated code.
Rapid Prototyping Execution Flow Chart
Each block places code in specific Mdl routines according to the algorithm that it is implementing. Blocks have input, output, parameters, and states, as well as other general items. For example, in general, block inputs and outputs are written to a block I/O structure (model_B). Block inputs can also come from the external input structure (model_U) or the state structure when connected to a state port of an integrator (model_X), or ground (rtGround) if unconnected or grounded. Block outputs can also go to the external output structure (model_Y). The next figure shows the general mapping between these items.
Data View of the Generated Code
The following list defines the structures shown in the preceding figure:
Block I/O structure (model_B): This structure consists of persistent block output signals. The number of block output signals is the sum of the widths of the data output ports of all nonvirtual blocks in your model. If you activate block I/O optimizations, the Simulink and Real-Time Workshop products reduce the size of the model_B structure by
Reusing the entries in the model_B structure
Making other entries local variables
See Signal Storage, Optimization, and Interfacing for more information on these optimizations.
Structure field names are determined either by the block's output signal name (when present) or by the block name and port number when the output signal is left unlabeled.
Block states structures: The continuous states structure (model_X) contains the continuous state information for any blocks in your model that have continuous states. Discrete states are stored in a data structure called the DWork vector (model_DWork).
Block parameters structure (model_P): The parameters structure contains all block parameters that can be changed during execution (for example, the parameter of a Gain block).
External inputs structure (model_U): The external inputs structure consists of all root-level Inport block signals. Field names are determined by either the block's output signal name, when present, or by the Inport block's name when the output signal is left unlabeled.
External outputs structure (model_Y): The external outputs structure consists of all root-level Outport blocks. Field names are determined by the root-level Outport block names in your model.
Real work, integer work, and pointer work structures (model_RWork, model_IWork, model_PWork): Blocks might have a need for real, integer, or pointer work areas. For example, the Memory block uses a real work element for each signal. These areas are used to save internal states or similar information.
The Real-Time Workshop Embedded Coder target generates the following functions:
model_initialize: Performs all model initialization and should be called once before you start executing your model.
If the Single output/update function code generation option is selected, then you see
model_step: Contains the output and update code for all blocks in your model.
Otherwise, you see
model_output: Contains the output code for all blocks in your model.
model_update: Contains the update code for all blocks in your model.
If the Terminate function required code generation option is selected, then you see
model_terminate: This contains all model shutdown code and should be called as part of system shutdown.
See Model Entry Points in the Real-Time Workshop Embedded Coder documentation for complete descriptions of these functions.
| Introduction | Rapid Prototyping Program Framework | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |