Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSE 522 Simulink Some of the slides were based on lectures by Lee & Seshia (UC Berkeley) and Fainekos (ASU) Computer Science & Engineering Department Arizona.

Similar presentations

Presentation on theme: "CSE 522 Simulink Some of the slides were based on lectures by Lee & Seshia (UC Berkeley) and Fainekos (ASU) Computer Science & Engineering Department Arizona."— Presentation transcript:

1 CSE 522 Simulink Some of the slides were based on lectures by Lee & Seshia (UC Berkeley) and Fainekos (ASU) Computer Science & Engineering Department Arizona State University Tempe, AZ Dr. Yann-Hang Lee (480)

2 Actor-Oriented Design  Object orientation:  Actor orientation: class name data methods call return What flows through an object is sequential control actor name data (state) ports Input data parameters Output data What flows through an object is data streams (

3 Actor Orientation vs. Object Orientation  Identified limitations of object orientation:  Says little or nothing about concurrency and time  Concurrency typically expressed with threads, monitors, semaphores  Components tend to implement low-level communication protocols  Re-use potential is disappointing OO interface definition gives procedures that have to be invoked in an order not specified as part of the interface definition. TextToSpeech initialize(): void notify(): void isReady(): boolean getSpeech(): double[] actor-oriented interface definition says “Give me text and I’ll give you speech” Actor oriented Object oriented ( 3

4 Example of an Actor-Oriented Framework q Signal flow graph with linear, time-invariant components q Synchronous concurrent composition of components q basic abstraction mechanism is hierarchy. ( entations/04/Parc_Lee.ppt) 4

5 Matlab/Simulink  Developed by Mathworks (  Matlab  An high-level programming language and interactive environment for scientific computing  good quality numerical algorithms  easy-to-use graphics and visualization capabilities  real and complex vectors and matrices (including sparse matrices)  The syntax of the language closely resembles the way we write mathematical equations  Easy extensibility, by the user or via packages of M-files (which contains a computer code) and GUIs known as toolboxes  It has a large number of toolboxes as add-ons  The academic and scientific communities also create toolboxes 5

6 Example Mathlab Code  Trapezoidal Rule function y = corrtrap(fname, fpname, a, b) % Corrected trapezoidal rule y. % fname - the m-file used to evaluate the integrand, % fpname - the m-file used to evaluate the first derivative % a,b - endpoinds of the interval of integration. h = b - a; y = (h/2)*(feval(fname,a) + feval(fname,b))+ (h^2)/12*(feval(fpname,a) - feval(fpname,b)); 6

7 Simulink  A graphical environment for multi-domain simulation and Model-Based Design for dynamic and embedded systems.  Based on block diagrams and data flow modeling  Not a programming language  Hierarchical, component-based modeling  Extensive library of predefined blocks  MATLAB integration  Application-specific libraries available  Open Application Program Interface (API)  It has a large number of toolboxes as add-ons  Code generation  Verification, Validation, and Test 7

8  Model in the loop  Define mathematical models of the plant and the controller.  Can the controller and algorithm fulfill the specification?  The set of tests will be used as “an oracle” in the next steps. Verification Methodology (1) 8 controller (model) plant (model) actuator sensor Test process outputs test vectors Simulation platform

9  Software (code) in the loop  Hardware in the loop  Processor in the loop Verification Methodology (2) 9 controller (software) plant (model) Test process Simulation platform processor (software) plant (model) Test process Simulation platform

10 Simulink Blocks (1)  Block: an actor  Consists of some functionality and an arbitrary number of ports  can be pre-defined blocks from Simulink library, S-function blocks (writing your own function in C, Fortran, etc.), or subsystem blocks  S-functions are dynamically linked subroutines that the MATLAB interpreter can automatically load and execute  Signals connect block‘s ports to pass data between blocks  To calculate the values of the output ports based on the values of the input ports and the internal states.  Sample time: how often and when the functionality of a block is evaluated. 10

11 Simulink Blocks (2)  Continuous blocks  have an infinitesimal sample time, e.g., integrator and derivative blocks  Discrete block  configured by a sample time parameter  can be inherited either from the block connected to its input (inheritance) of its output (back inheritance).  Block update (for all blocks within a system): to compute  the block‘s outputs, the block‘s states, and the time for the next time step  Direct feed-through ports  The calculation of the output values depends on the input values of the current sample time, e.g., sum block  An algebraic loop occurs when a signal loop exists with only direct feed-through blocks within the loop 11

12 Simulink Signal and Subsystem  Each Signal Object is associated to:  Data Type, dimension, sample rate, complexity (real, complex or auto), minimum/maximum values, initial value, unit of measure (only for doc), description  Subsystems -- decompose the model in components and reuse 12 subsystems virtual atomicconditional non-virtual documentation library enabled triggered control flow

13 Conditionally Executed Subsystems  A subsystem whose execution depends on the value of an input signal.  Enabled Subsystem  Executed if the control signal has a positive value  Control Flow Subsystem  Executed if the control flow condition (e.g., if, while) evaluated to true  Triggered Subsystem: execute each time a trigger event occurs  positive or negative edges  function call signals (from function-call generator blocks or S-function blocks) 13

14 Mathlab/Simulink Code Generation  Embedded MATLAB:  a subset of the MATLAB language that supports efficient code generation for deployment in embedded systems  can use Real-Time Workshop to convert MATLAB programs to C programs  Generated code can run in real time (physical clock) or simulated time (steps) 14 (formerly Real-Time Workshop) ( 08/welcome-to-the-coders/)

15 Simulink Model Execution (1)  Model compilation  Identification of the signal types, sizes  Propagation of the types  Optimization of the structure  Flattening of the virtual subsystems  Link phase  Allocation of memory structures  Connection between elements  Loop phase 15

16 Simulink Model Execution (2)  Block defines the time invariant relation between its input and its output.  Virtual time –  computation takes no time and when it is done, advance to next time step.  Major step to produce output  Minor step to improve the accuracy of continuous solvers 16 input: x 0, d 0, t 0, h 0 ; n = 0; loop until t n  t end evaluate g(t n, x n, d n ) ; update d = f d (t n, x n, d n ) ; solve ẋ (t) = f x (t, x(t), d n ) over interval [t n, t n + h n ] to get x(t n + h n ) ; find zero crossing ; compute h n+1 ; compute t n+1 ; d n+1 = d; x n+1 = x(t n + h n ) ; n = n + 1 ; end loop ( simulink_semantics.pdf ) simulink_semantics.pdf

17 Simulink Model Execution (3)  Order of block updates  Updated before any of the blocks if it drives via direct-feed-through ports  Blocks that do not have direct-feed-through inputs can be updated in any order.  Atomic (compute at once) to Virtual Subsystem (flattened to the level of the parent system)  Block priority 17

18 Execution Models of Generated Code (1) 18 single-rate single- tasking model_main() spawns a base rate task, tBaseRate, which is task is activated by a clock semaphore and calls model_step multi-rate single- tasking model_main() spawns only a base rate task, tBaseRate. All rates run under this task. The base rate task is activated by a clock semaphore provided by VxWorks. On each activation, tBaseRate calls model_step. model_step in turn calls the rate_monotonic_scheduler utility, which maintains the scheduling counters that determine which rates should execute. multi-rate multi- tasking model_main() spawns a base rate task and sub-rate tasks which call model_step with their associated tids. The base rate task and model_step are responsible for maintaining event flags and scheduling counter. Task priorities are assigned by rate.

19 Execution Scheduling  In simulation: computation results occur instantaneously  In real execution  non-zero non-deterministic block execution time  task overrun detection  communication through data variables in memory  Single-tasking multiple-rate execution  rates are harmonic  a timer ISR to drive at base rate  assume 3 tasks of sampling times of 1, 2 and 4 19 (from Simulink Coder User Guide) T1 T2 T4 T1 T1 T2 T1 T1 T2 T4

20 RTW Main program (no RTOS)  Periodically interrupted by a timer.  rt_OneStep is either installed as a timer interrupt service routine (ISR), or called from a timer ISR at each clock step 20 main() { Initialization (including installation of rt_OneStep as an interrupt service routine for a real-time clock) Initialize and start timer hardware Enable interrupts While(not Error) and (time < final time) Background task EndWhile Disable interrupts (Disable rt_OneStep from executing) Complete any background tasks Shutdown } (from RTW Embedded Coder User Guide)

21 RTW Main program (no RTOS)  sequences calls to the model_step functions for multi-rate model  reinterruption of rt_OneStep by the timer is an error condition and rt_OneStep signals an error and returns immediately. 21 rt_OneStep() { Check for base-rate interrupt overrun Enable "rt_OneStep" interrupt Determine which rates need to run this time step Model_Step0() -- run base-rate time step code For N=1:NumTasks-1 -- iterate over sub-rate tasks If (sub-rate task N is scheduled) Check for sub-rate interrupt overrun Model_StepN() -- run sub-rate time step code EndIf EndFor } (from RTW Embedded Coder User Guide)

22  Multi-rate and multi-tasking model  multiple threads (tasks) with preemption  one thread for each rate and, for periodic tasks, the faster rate task has higher priority  Faster to slower transition  The input of slower block may be changed during its execution  Slower to faster transition Rate Transition (1) 22 (from Simulink Coder User Guide)

23  Rate transition block to copy data  runs in high priority, but low rate  output value is held constant while the slower block executes  rate transition update and output Rate Transition (2) 23 (from Simulink Coder User Guide)

24 Semantics-preserving (1)  Synchronous:  atomic reactions indexed by a global logical clock,  each reaction computes new events for its outputs based on its internal state and on the input values  the communication of all events between components occur synchronously during each reaction.  Cycles of reading inputs, computing reaction and producing outputs  Synchronous = 0-delay = within the same cycle  No interference between I/O and computation  Why?  deterministic semantics in the presence of concurrency. 24

25 Semantics-preserving (2) A_1 A_2 a high priority task B arrives and receives inputs from A (from A_1 or A_2?) A_1 A_2 C B B A_1 A_2 C B C if Pri(A) > Pri(C)>Pri(B), depending upon the execution time of C, B may receive inputs from A_1 or A_2 25

26 Semantics-preserving (3)  If execution time = 0, then the computation is determined by the order of arrivals, not the arrival instances, nor execution time  Can we memorize the arrival order and then fetch data from buffer  Unit delay is necessary when a higher priority task reads from a lower priority task A_1 A_2 C B B A_1 A_2 C B C y_1 y_2y_1 26

27 Asynchronous Support in RTW/vxWorks  Asyns interrupt -- generate interrupt-level code  Task sync -- spawn a vxWorks task that calls a function call subsystem  Protected RT -- enable data integrity when transferring data between blocks running as different tasks  Unprotected RT -- use an unprotected/nondeterministic mode 27

Download ppt "CSE 522 Simulink Some of the slides were based on lectures by Lee & Seshia (UC Berkeley) and Fainekos (ASU) Computer Science & Engineering Department Arizona."

Similar presentations

Ads by Google