Terms ISO International Organization for Standardization OSI Open Systems Interconnection FDT Formal Description Technique LOTOS Language of Temporal Ordering Specification ISO Health Care … OSI… Road Vehicles FDT Estelle LOTOS SDL
Purpose: Create standards to make life simpler. Increase reliability and effectiveness of goods and services. Standards Environment Health Care Natural Sciences Ship BuildingTelecommunications Food Technology ISO
OSI Standard for interconnection between any two points in network. Purpose: For equipment to consistently work with other equipment. Structure: 7 layer system
FDT Formal method for developing telecommunications services & protocols. Purpose: Produce unambiguous descriptions of OSI in a precise & comprehensive way. Three officially recognized FDT’s : Estelle, LOTOS, SDL.
LOTOS Developed during the years 1981 – 1986. Specification language. Built specifically for OSI. Can be used for concurrent & distributed systems also. Key Idea To ensure compatibility of communication and cooperation between machines.
Components of LOTOS 1.Processes & their interaction with each other and their environment. 2.Data structures and value expressions.
Process Definition Process definition is a description of the behaviour of a subsystem 3 main purposes: –Representation of recursivity (loops + infinite behaviours) –Create behaviour abstractions and hierarchies (top-down) –Gate re-labeling
Process Definition (cont.) Process process [ formal-gates] ( params): functions := behaviours where local-definitions endproc
Behaviour Expressions They are created by applying an operator to other behaviour expressions They may also include instantiations of other processes, whose definitions are provided in the where clause
Behaviour Example process MAX3 [ in1, in2, in3, out] := hide mid in ( MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out]) where process MAX2[a, b, c] := a; b; c; stop  b; a; c; stop endproc Process Definition Behaviour Expression Process Instantiation
Action prefix ; May denote actions in sequence Composes an event and a behaviour description The action prefix cannot take 2 behaviours as arguments –Ex. Action ; Expressiona; b; c gate ; Expression i ; Expression
Inaction Operator stop Is the representation of a behaviour such that no event will ever be observed It can be used to express that a process finishes it’s execution It can be used to express deadlock situations –Ex. With MAX3 as basis c; stopb; c; stop a; b; c; stop
Choice Operator  Offers to the environment two (or more) alternatives. This is, the system may behave in several ways Choice composes two alternative behaviour descriptions. The environment will select among both behaviour descriptions
Choice Operator  (cont.) Ex Behaviour1  Behaviour2 - The system behaves as either Behaviour1 or Behaviour2 Ex. With the MAX3 as basis a; b; c; stop  b; a; c; stop
Operational Semantics Growing Trees From Expressions
Operational Semantics From a behaviour expression we derive the actions that a process performs The application of an action to a behaviour expression produces a new behavior expression From the application of each action we derive a labeled transition
Operational Semantics Each transition is of the form: B x B’ Where B and B’ are behavior expressions and x is an action that changes B to B’.
Operational Semantics The actions that are performed are all user- defined. They include the observable actions – the user defined gates for the behavior. They also include the unobservable or internal actions. In the syntax of the paper, this is the set
Operational Semantics We also need a special non-user definable action that shows the successful termination of the current process and the enabling of a subsequent process. The paper uses for this action. The complete set of actions is the set
Operational Semantics The action prefix behavior expression is defined by the axiom: ; B B In the context of the Max2 example, this becomes: a; b; c; stop a b; c; stop
Operational Semantics We can describe the entire behavior for a process by its sequence of transitions. This is represented by a transition tree or synchronization tree. The nodes of the tree are labeled by the behavior expressions and the arcs are labeled by the action that causes the transition.
Operational Semantics Drawing from the Max2 example: Given the process: a; b; c; stop we produce this transition tree.
Operational Semantics We can also represent this process in an action tree. We produce an action tree by omitting the labels from the nodes of a transition tree. i.e. by only labeling the arcs.
Operational Semantics However, we have only examined one part of the process in Max2. Max2 involves a choice operator: a; b; c; stop  b; a; c; stop Max2 can behave like either process. The process that it actually behaves like is determined by our first choice of action.
Operational Semantics If action a is selected, it behaves like: a; b; c; stop If action b is selected, it behaves like: b; a; c; stop
Operational Semantics This is described by the inference rules: B1 + B1’ implies B1B2 + B1’ B2 + B2’ implies B1B2 + B2’ For Max2 we have: a; b; c; stop a b; c; stop implies a;b;c;stopb;a;c;stop a b; c; stop
Operational Semantics Max2 gives us the choice of two action trees
Operational Semantics Since both action trees have a common starting point we draw them with a common root node:
Operational Semantics This process can be expanded to grow a tree of any size
As you can see this rapidly becomes cumbersome. This is where parallelism can simplify the process.
Parallelism “A Time and Place for Every Event.”
The Idea Parallel operators are used to model concurrency. They are useful for the synchronization of events. We can think of parallelism as a means to event ordering, prioritizing, preconditioning.
The Operators Partial Synchronization (General Case) Interleaving (Pure Interleaving) Full Synchronization In LOTOS, there are 3 types of parallel operators:
Partial Synchronization B1 |[g1, g2, …, gn]| B2 Process B1 Process B2 Synchronization Gates g1, …, gn || Partial Synchronization Operator Behavior Expression
What Does that Mean? Certain events must be synchronized. Starting school: (shopping; start_grade_1; new_crayons; new_friends; start_grade_2; ballet; YEAR) |[start_grade_1, start_grade_2]| (start_grade_1; learn_alpha; write_name; count_10; start_grade_2; KNOWLEDGE) There are certain things you must do before you start grade 1, while you are in grade 1, and when you are done grade 1.
Example in1 in2 mid in3 mid out MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out] Recall the above trees… We now compute
in1 in2in1 in2 mid in3 mid out in2 midout mid in3out in3 midout in2in3 in1 mid out in1 in3 mid out mid out in3 in2 in1 mid in1 mid in2 out in1in3 in2 in3 MAX2[in1, in2, mid] |[mid]| MAX2[mid, in3, out]
Interleaving B1 ||| B2 Process B1 Process B2 Set of Synchronization Gates is EMPTY ||| Interleaving Operator Behavior Expression
What Does that Mean? No events need be synchronized (independent processes). Reading text books for different classes: (b1_c1; b1_c2; b1_c3; BOOK1) ||| (b2_c1; b2_c2; b2_c3; BOOK2) As long as you read the individual books in sequential order, you can divide your time between classes. You do not HAVE to read all of book 1 before you start book 2 (although you may.)
Example in2out2in1out1 ||| where process BOX[in, out]:= in;out;stop end proc process BOXES[in1, out1, in2, out2]:= BOX[in1, out1] |||BOX[in2, out2] end proc in1, out1, in2, out2 in1, in2, out1, out2 in2, in1, out1, out2 in1, in2, out2, out1 in2, out2, in1, out1 in2, in1, out2, out1 Possible Sequences:
Full Synchronization B1 || B2 Process B1 Process B2 Set of Synchronization Gates is ALL Gates || Full Synchronization Operator Behavior Expression
What Does that Mean? All events must be synchronized. Jumping in the water holding hands: (walk; jump; land; YOU) || (walk; jump; land; ME) Everything must be done at the same time.
Example where … process BOXES[mid1, mid2, mid3]:= BOX1[mid1, mid2, mid3] ||BOX2[mid1, mid2, mid3] end proc mid1, mid2, mid3 Possible Sequence: mid3 mid1 mid2
Summary Partial Synchronization B1 |[g1, g2, …, gn]| B2 Interleaving B1 ||| B2 Full Synchronization B1 || B2 Synchronization at NO gates Synchronization at ALL gates General Case Special Cases
Types of Process Controls i)Hiding ii)Internal Actions iii)Non-Determinism iv)Process Instantiation v)Process Recursion vi)Process Termination vii)Sequential Composition (Enabling) viii)Disabling
Hiding Syntax: hide gate 1, …, gate n in behaviour expression Semantics: Hiding allows one to transform observable (external) actions into unobservable (internal) actions, thus making them unavailable for synchronization with other processes.
Example: process OUTER [in1, in2, out] := hide mid in INNER [in1, mid] | [ mid ] | INNER [mid, in2, out] endproc Hiding mid in1in2 out OUTER INNER
Hiding in1 in2 mid out in1 in2 i out Action Tree (after hiding mid) Action Tree (before hiding mid)
Internal Actions Definition: An internal action is an unobservable action: it cannot be seen from the environment. Example: i in1in2 out OUTER INNER
Non-Determinism Definition: Non-determinism occurs when more than one result is possible for a particular behaviour expression. Examples: a; b; stop  a; c; stop i; b; stop  i; c; stop a c stop b ? ai c b ? i
Process Instantiation Syntax: process_identifier [comma-delimited list of actual gates] Semantics: A process instantiation is formed by a process identifier with an associated list of actual gates. Example: SIMPLEX_BUFFER [in, out] out SIMPLEX_BUFFER in
Process Recursion Semantics: A process P is recursive if it is able to call itself. Recursion in LOTOS is used to express infinite behaviours. Example: process REUSABLE_SIMPLEX_BUFFER [in, out] := in; out; REUSABLE_SIMPLEX_BUFFER [out, in] endproc out REUSABLE_SIMPLEX_BUFFER in
Process Termination Syntax: exit Semantics: Exit is a process whose only purpose is to perform a successful termination action and thus transform itself into the dead process stop. Example: process DO_SOMETHING [a, b, c] := a; b; exit  b; c; exit endproc
Sequential Composition (Enabling) Syntax: B1 >> B2 Semantics: The execution of behaviour B2 is enabled if and only if behaviour B1 terminates successfully. Example: UNLOCK_DOOR [key] >> open_door
Disabling Syntax: B1 [> B2 Semantics: Behaviour B1 may or may not be disabled by behaviour B2 as follows: –If B1 terminates successfully, B2 is not executed. –Else, B2 interrupts B1 and is executed instead.