1 / 37

RML : Reactive Module Language

RML : Reactive Module Language. Amineh Sarvarian Hadjar Niamehr Neda noroozi. Essential characteristics of a modeling language. It must: support non-determinism. support interactions between systems and system components.

Télécharger la présentation

RML : Reactive Module Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RML : Reactive Module Language Amineh Sarvarian Hadjar Niamehr Neda noroozi

  2. Essential characteristics of a modeling language • It must: • support non-determinism. • support interactions between systems and system components. • facilitate simulation of system descriptions by supporting an execution model. • facilitate the formal analysis of system behaviors by supporting a precise mathematical semantics. Reactive Module Language

  3. Variables → atoms → modules → the composition of modules Reactive Module Language

  4. We consider systems that are discrete,deadlockfree and nondeterministic. • A discrete system is a collection of variables that over time change their values in a sequence of rounds. • The first round: initialization round • All subsequent rounds: update rounds Reactive Module Language

  5. Deadlock freedom means: • in the initialization round there is at least one option for initializing each variable • in every update round there is at least one option for updating each variable • every update round can be followed by another update round. Reactive Module Language

  6. Non-determinism means: • in the initialization round there may be several options for initializing a variable • in an update round there may be several options for updating a variable. • Consequently two exact copies of a system can over time exhibit very deferent behaviors. Reactive Module Language

  7. We define the behavior of a variable using two guarded commands • Initial command • Update command • current value of x (unprimed symbols): • value of x at the beginning of an update round • next value of x (primed symbols): • value of x at the end of an update round Reactive Module Language

  8. initial value of x: A value of x at the end of the initialization round. • The possible initial values for a variable are defined by an initial command. Reactive Module Language

  9. The possible next values for a variable are defined by an update command. Reactive Module Language

  10. Example: Scheduler • task1, task2 • amount of needed processor time to complete the related task. • Ternary variable proc: • 0 if in the most recent round the processor has been idle • 1 if the processor has been assigned to the first task • 2 if the processor has been assigned to the second task The scheduler always gives priority to the first task. Reactive Module Language

  11. Within a round • some variables are initialized or updated simultaneously • some variables are initialized or updated sequentially. If two variables x and y are initialized or updated simultaneously in some round then x and y are initialized and updated simultaneously in every round. Atom:A set of variables that are initialized simultaneously in the initialization round and updated simultaneously in every update round. Reactive Module Language

  12. The behaviors of all variables that are controlled by one atom are defined using a single initial command and a single update command Reactive Module Language

  13. Example: Scheduler • The scheduler alternates priorities between both tasks. • binary variable prior: which of the two tasks will be given priority in the upcoming round. • The variables proc and prior form an atom. In the first, third and fifth assignments the value of prior stays unchanged that is prior’=prior. Reactive Module Language

  14. Sequential updates • If x is initialized before z in the initialization round and x is updated before z in every update round then the variable x is said to be awaited by the variable z. Reactive Module Language

  15. If z awaits x then the possible initial values for z may depend on the initial value of x and in every update round the possible next values for z may depend on the next value of x. Reactive Module Language

  16. Example: Scheduler • new1and new2: The amount of new work that has arrived in the most recent round. Reactive Module Language

  17. Read variables • The initialization round and every update round consist of several subrounds one for each atom. • If the possible next values for some controlled variable of U depend on the current value of a variable x then x is said to be readby the atom U. • Read variables occur in the update command of U as unprimed symbols. Reactive Module Language

  18. variable can be both read and awaited by an atom or read and controlled. • variable cannot be awaited and controlled U. Reactive Module Language

  19. An X-atom U • Atom declaration • ctrlXU • readXU • awaitXU • Atom body • initU: From awaitXU to ctrlXU • updateU:From readXU U awaitXU to ctrlXU Reactive Module Language

  20. Deterministic atom • Atom consistency • Combinational atom • Sequential atom Reactive Module Language

  21. Lazy atom • Eager atom Reactive Module Language

  22. Passive atom • Active atom Reactive Module Language

  23. Partial order • U is a set of consistent atoms => the precedence relation is a strict partial order on U. • Execution order • U is a consistent set of X-atoms. An execution order for U is a sequence U1,…,Un of the atoms in U which doesn’t violate the : for all 1≤i, j≤n, if Ui Uj, then i<j. • Initialized trajectory:The output of the execution of U. Reactive Module Language

  24. Example: Scheduler Reactive Module Language

  25. The initialized trajectory of Scheduler The timing diagram of the above trajectory Reactive Module Language

  26. (Reactive) Module P • Variable declaration • privXP • intfXP • extlXP • ctrlXP = privXP U intfXP • obsXP = extlXP U intfXP • Set of atomsP Reactive Module Language

  27. Finite Module • All module variables can assume only finitely many values. • Closed Module • The behavior of the controlled variables is not influenced by any environment variables. • Deterministic Module • the behavior of the environment variables uniquely determines the behavior of the controlled variables. Reactive Module Language

  28. Execution of modules • Phase 1: The external variables of module P are initialized or updated non-deterministically. • Phase 2: The controlled variables are initialized or updated by carrying out the initial or update commands of module P in some execution order. Reactive Module Language

  29. Example: Scheduler The three scheduler modules Reactive Module Language

  30. Example: Scheduler Block diagram of Scheduler Module Reactive Module Language

  31. Asynchronous module vs. synchronous module • All interface variables are controlled by lazy atoms • Passive module vs. active module • All atoms in atomsP are passive • Private determinism • All private variables are controlled by deterministic atoms Reactive Module Language

  32. Operations on reactive module • parallel composition • Variable renaming • Variable hiding Reactive Module Language

  33. Parallel Composition • Module compatibility • Module composition • If P and Q are two compatible modules then the parallel composition P||Q is the module such that • privXP||Q = privXP U privXQ • intfXP||Q = intfXP U intfXQ • extlXP||Q = (extlXP U extlXQ)/ intfXP||Q • atomsXP||Q = atomsXP U atomsXQ Reactive Module Language

  34. Type of the compound module Reactive Module Language

  35. Variable renaming • Before composing two modules it may be necessary to rename private variables in order to make the two modules compatible. Reactive Module Language

  36. Variable hiding • The hiding of interface variables allows us to construct module abstractions of varying degrees of detail. Reactive Module Language

  37. Thank you. Reactive Module Language

More Related