OpenComRtos 1.4_tutorial_1o4_presentation

Session #1.1: The Theoretical foundations of
OpenComRTOS

Bernhard Sputh
bernhard.sputh@altreonic.com

Altreonic NV
Gemeentestraat 61 Bus 1
3210 Linden
Belgium

January 12, 2012

Bernhard Sputh (Altreonic) Session #1.1 January 12, 2012 1 / 71

Who am I

Name: Bernhard Sputh
Highest Degree: PhD in Electronics from the University of Aberdeen
(Scotland)
Current Occupation: Software Engineering Researcher Altreonic N.V.
(Belgium)


Outline of this Workshop

Session #1.1: The Theoretical foundations of OpenComRTOS.
Session #1.2: Introduction to OpenComRTOS and the
OpenComRTOS Designer Suite
Session #1.3: OpenComRTOS Internals
Session #1.4: Hands on with the OpenComRTOS Designer Suite


1 Introduction
Examples of Distributed Heterogeneous Systems
Advantages of Distributed Heterogeneous Systems
Problems to take into account
2 Communicating Sequential Processes
Term Deﬁnitions
Sequential Processes
Parallel Composition
Compound Events
3 Applying CSP to Real World Problems
Modelling a Counter with CSP
Checking the model for a deadlock
Hiding Internal Events
Reﬁnement Checks
4 Paradigms of OpenComRTOS
5 Summary


Outline
1 Introduction
Problems to take into account
2 Communicating Sequential Processes
Term Deﬁnitions
Sequential Processes
Compound Events
3 Applying CSP to Real World Problems
Reﬁnement Checks
4 Paradigms of OpenComRTOS
5 Summary


System on Chip (SoC)
Network on Chip (NoC)
Distributed Computing


Network on Chip TI 8 Core DSP


Distributed Computing

High Performance Computing
Rendering farms
Grid Computing



Ability to use the processing entity that ﬁts best for the task.
Lower power consumption.


Separate Memories

Data needs to be copied from one entity / node
A mechanism that allows this securely is necessary.
Increased latency due to copying of data.


Communication between Entities

Bandwidth
Latency
Byte Order


Parallelism Problems

Deadlocks
Livelocks
Finding and resolving problems cause by parallelism is a complex task and
requires very often the help of formal methods. In the remaining part of
this lecture I’ll give an introduction to Communicating Sequential
Processes (CSP) a formal method and a mind set that helps to ﬁnd such
problems and also to prove the absence of them using model checkers.


Communicating Sequential Processes (CSP)

Formal Method developed by C.A.R Hoare [1];
Allows to reason over concurrent / parallel systems, and allows to
identify whether systems:
Deadlock
Livelock
Applies both to hardware and software systems.


Sequential System

A sequential system, has one thread of execution, one instruction is
handled after the other. A typical example of a sequential system is a
counter.


Concurrent Systems

A concurrent system has multiple threads of execution, so it can perform
multiple tasks at the same time. For instance, a system could wait for
data to arrive, while processing previously received data.


Processes as Finite State Machines

con1 con2

START INTER STOP


Naming Processes

Similar to a Finite State Machine (FSM) Processes can be named. The
convention here is that a process name always consists of all upper case
letters. To separate the words of multi word names the underscore ( ) is
used. Equation 1 is an example for a named process.

START =con1 → INTER
(1)
INTER =con2 → STOP
STOP means that the process does not engage in any event any more.


Alphabets

All events a process shares with its environment are part of its alphabet.
Events a process does not want to share with the environment are omitted
from the alphabet. The name of an alphabet consists of the Greek letter
alpha α followed by the name of the process which alphabet it is:

αSTART = {con1 , con2 } (2)


Examples for Alphabets

1 A web server, represented by process WS, can accept requests and
then service them. The alphabet of a web server (αWS) can be:

αWS = {request, serve} (3)

2 A computer mouse (process MOUSE ) has three buttons (b1, b2, and
b3), one scroll wheel (sw up and sw down), and can move in two
dimensions (left, right, up, and down). The alphabet of the mouse
(αMOUSE ) is therefore:

αMOUSE = {b1, b2, b3, sw up, sw down, left, right, up, down} (4)

This set precisely describes how the mouse interacts with its
environment, or its user.


Performing Events

con
−1
(con1 → INTER) − → INTER (5)


Signalling the end of Execution
When a process does not want to engage in any more events, it transits to
the process ‘STOP’. The process STOP does not engage in any events.
One can think of the process STOP as behaving like a turned off web
server, which will neither accept nor service any requests.
Utilising the STOP process it is possible to define a one-shot
implementation of the web server (Equation 6):

WS = request → serve → STOP (6)
Equation 7 defines the alphabet for the process WS.

αWS = {request, serve} (7)
The corresponding FSM is given in the following figure.
request serve

WS (serve → STOP) STOP


Recording what happened using Traces

To analyse whether or not a system behaves as expected it is useful to
have a recording of all events it presented to the environment. In CSP this
list is part of the language and is called a trace. A trace only records the
events a process explicitly exposes to its environment!
Example: Equation 8 gives one possible trace of the process WS
(Equation 6).
request, serve (8)


Obtaining all Traces a Process can produce

The function traces(P) returns a set containing all possible traces of
process P. Every process can create the so called empty trace: ‘ ’, which
indicates that the process has not engaged in any event!
The process STOP produces an empty trace ( ) as it does not engage in
any events:
traces(STOP) = (9)
Example: Equation 10 gives a set containing all possible the traces of the
process WS (Equation 6).

traces(WS) = { , request , request, serve } (10)
Example: The traces of the process START are:

traces(START ) = { , con1 , con1 , con2 } (11)


Appending a Trace to another Trace

To append tr2 to the trace tr1 , the concatenation operator ( ) is used:

tr1 = e1 , e2
(12)
tr2 = e3 , e4

tr3 =tr1 tr2
(13)
= e1 , e2 , e3 , e4


Sequential Composition: The SKIP Process

So far all our processes transited to the process STOP once they ﬁnished
their execution. However, when a process transits to the STOP process its
execution stops, instead of returning control to the process that called it.
So a signalling mechanism is required that allows a process to signal
successful termination. CSP provides the process SKIP for signalling the
successful termination to its calling process. The SKIP process engages in
the successful termination event ‘ ’, before transiting to STOP. Equation
14 gives the deﬁnition of the SKIP process.

SKIP = → STOP (14)


The Sequential Composition Operator

For a process to wait for the successful termination of a process it just
called, the sequential composition operator ‘;’ is used instead of the then
operator ‘→’.
Example: Equation 15 shows process A which is a sequential composition
of the processes B (Equation 16), C (Equation 17), and STOP.

A = B; C ; STOP (15)

B = e1 → e2 → SKIP (16)

C = e3 → e4 → SKIP (17)


Traces for Sequential Composition

To determine the traces a sequential composition such as:

P1 ; P2 (18)


It is necessary to first determine all traces of process P1 (traces(P1 )).
However the successful termination event ( ) must not be present, and
must therefore to be filtered out. To perform the filtering the trace
tr ∈ traces(P1 ) is converted to an unordered set (σ(tr )) and it checked
that the successful termination event ( ) is not part of it ∈ σ(tr )
Equation 19 gives the complete expression to obtain this set.

{tr | tr ∈ traces(P1 ) ∧ ∈ σ(tr )} (19)


Then all traces of process P2 have to be preceded by a trace, where P1 has
terminated successfully but without the successful termination event
(tr1 ∈ traces(P1 )).
By appending the to the trace tr1 and checking whether this trace is in
the traces of P1 (tr1 ∈ traces(P1 )), we only get the traces where P1
terminated successfully but without the successful termination event .
The complete set is given in the following equation:

{tr1 tr2 | tr1 ∈ traces(P1 ) ∧ tr2 ∈ traces(P2 )} (20)


To combine two sets, the union operator (∪) is used. This operator
furthermore eliminates any double entries.
Equation 21 gives the complete formula to construct all traces of a
sequential composition.

traces(P1 ; P2 ) ={tr | tr ∈ traces(P1 ) ∧ ∈ σ(tr )}
∪ {tr1 tr2 | tr1 ∈ traces(P1 ) ∧ tr2 ∈ traces(P2 )}
(21)


Example: Determining the Traces of Process A

Process A (Equation 15) is a sequential composition of the processes B
(Equation 16) and C (Equation 17) The following enumeration is a step
by step guide on how to obtain the traces of process A (traces(A)):


First we need to determine the traces of B where B but omitting the
successful termination event!
{tr | tr ∈ traces(B) ∧ ∈ σ(tr )}
(22)
= { , e1 , e1 , e2 }


Then we need to determine all traces of B where B terminates successfully
but again ﬁltering out the successful termination event ( )

{tr1 ∈ traces(B) • tr1 }1
(23)
= { e1 , e2 }

1
Remember ∀ x • S means: for all x S holds

Now it is necessary to determine the traces of process C , this time
including the successful termination event ( ).

{tr2 ∈ traces(C ) • tr2 }
(24)
= { , e3 , e3 , e4 , e3 , e4 , }


In the next step we append every trace of process C to every trace where
process B terminated successfully:

{tr1 tr2 | tr1 ∈ traces(B) ∧ tr2 ∈ traces(C )}
(25)
= { e1 , e2 , e1 , e2 , e3 , e1 , e2 , e3 , e4 , e1 , e2 , e3 , e4 , }


In the last step the traces where process B does not successfully
terminates, and the traces obtained in the previous step are combined:

traces(A) ={ , e1 , e1 , e2 }
∪ { e1 , e2 , e1 , e2 , e3 , e1 , e2 , e3 , e4 , e1 , e2 , e3 , e4 , }
={ , e1 , e1 , e2 , e1 , e2 , e3 , e1 , e2 , e3 , e4 , e1 , e2 , e3 , e4 , }
(26)



Until now we only discussed sequential processes, i.e. sequential systems.
A system consisting of two or more processes is concurrent. CSP uses the
parallel operator to deﬁne a parallel composition of processes.
Furthermore, the parallel operator ( ) also deﬁnes how concurrent
processes communicate with each other.
The parallel operator allows to specify the alphabets each process wants to
share with the environment, or synchronise on: |[ αP1 | αP2 ]| . To evaluate
which events are shared between both processes, the parallel operator
determines the intersection of the two alphabets,


Parallel Operator

Equation 27, shows the parallel composition of the processes P1 and P2 .

P3 = P1 |[ αP1 | αP2 ]| P2 (27)
The alphabet of a parallel composition ( ) is the union (∪) of the
processes involved in the composition:

αP3 = αP1 ∪ αP2 (28)


Example for Parallel Composition

Equation 29 deﬁnes process C as parallel composition of processes A
(Equation 31) and B (Equation 33). Lets evaluate the traces of process C :

C = A |[ αA | αB ]| B (29)

αC = αA ∪ αB (30)
A = a → sh1 → SKIP (31)
αA = {a, sh1 } (32)
B = sh1 → b → SKIP (33)
αB = {sh1 , b} (34)


Determining the Shared Events between A and B

The processes A and B synchronise on the intersection (∩) of the
alphabets αA and αB:

αA ∩ αB ={a, sh1 } ∩ {sh1 , b}
(35)
={sh1 }


Traces of Process C

Synchronisation here means that if process A is ready to engage in the
shared event sh1 it waits until process B is ready to engage in event sh1 as
well. Therefore, the traces for process C are:

traces(C ) = { , a , a, sh1 , a, sh1 , b , a, sh1 , b, } (36)


Compound Events
Events are considered to be atomic2 and indivisible in their occurrence.
However, an event can contain various pieces of information. Thus events
can have a structure. Examples for structured events are events that
consist of multiple parts separated by a dot: ‘.’.
Example: The process S E (Equation 37), engages in three events (e.1,
e.2, and e.3) before terminating.

S E = e.1 → e.2 → e.3 → SKIP (37)
The alphabet of process S E is:

αS E = {e.1, e.2, e.3} (38)
Alternatively this alphabet could also be written as:

αS E = {e.x | x ∈ {1, 2, 3}} (39)

2
An atomic operation can not be interrupted, it either happens or not.

Channels

Another version of a structured event is a communication channel carrying
messages. To model values v begin transferred over a channel c each
possible communication is described as a separate event c.v . A process P
with a channel c that can carry the messages 1, 2, and 3 will have the
events: c.1, c.2, and c.3 in its alphabet. The event c.1 describes the
appearance of the message 1 on channel c.
Channels in CSP are unidirectional. Unidirectional means that a message
is transferred from a writer to a reader. A process writing a message to a
channel waits until another process has read the message. Vice versa, a
process trying to read from a channel waits until another process has
written a message to this channel.


Writing to a Channel

To write a message m of type T (m : T ) to a channel c which can carry a
message of type T (c : T ) the channel output operator ‘!’ is used:

c!m (40)


Example: The process P1 writes the integer values 1, 2, and 35 over the
channel c:
A = c!1 → c!2 → c!35 → STOP (41)
The alphabet of process A is:

αA ={c.1, c.2, c.35}
(42)
= {c.x | x ∈ {1, 2, 35}}


Reading from a Channel

To read a message from a channel c of type T , the channel read operator
‘?’ is used. The message must be stored in a variable (x) and this variable
must be of type T as well (x : T ).

c?x : T (43)


Example: Process B is the counter part to process A and reads three
messages from channel c of type N, into the variable v : N:

B = c?v : N → c?v : N → c?v : N → STOP (44)
The alphabet must contain all possible events, as messages of type N are
read from the channel c the alphabet of process B is:

αB = {c.x | x ∈ N} (45)


Channels and Traces

Channel transactions are only structured events, thus in traces they appear
as a structured event.
Example: Process C is the parallel composition of the processes A and B.
Both processes communicate using the channel c:

C = A |[ αA | αB ]| B (46)
The shared events between processes A and B are:

αA ∩ αB = {c.1, c.2, c.35} (47)

The traces of process C are:

traces(C ) = { , c.1 , c.1, c.2 , c.1, c.2, c.35 } (48)



Lets model a simple counter counting from 1 to ∞. We can do this by
connecting the input of an incrementer with its output. To observe count
values we need to tap into the feedback line using a process that receives a
message from one channel, copies it and sends it out over two channels,
this process is called a ∆-process.
Equation 49 gives the speciﬁcation of the desired functionality.

COUNTER SPEC (out, i) = out.(i + 1) → COUNTER SPEC (out, (i + 1))
(49)

αCOUNTER SPEC (out, i) = {out.x | x ∈ N} (50)


Modelling the Increment Process

First lets model a recursive incrementing process INC (in : N, out : N).
This process reads a natural number from the channel in : N, increments it
by one and sends the result over the channel out : N and then recurses.
Equation 51 gives the process deﬁnition, while Equation 52 gives the
alphabet

INC (in, out) = in?m : N → out!(m + 1) → INC (in, out) (51)

αINC (in, out) = {in.x, out.x | x ∈ N} (52)


Model of the Delta-Process

The process DELTA(in, out1 , out2 ) reads data from the channel in and
sends it over the two channels out1 and out2 concurrently.

DELTA(in, out1 , out2 ) =
(53)
in?m : N → SEND(m, out1 , out2 ); DELTA(in, out1 , out2 )

Please note, that this process oﬀers the message concurrently to both
channels (out1 and out2 )!

SEND(m : N, out1 , out2 ) =
(54)
(out1 !m → SKIP) |[ {out1 !m} | {out2 !m} ]| (out2 !m → SKIP)

αDELTA(in, out1 , out2 ) = {in.x, out1 .x, out2 .x | x ∈ N} (55)


Counter Version One
Using the INC (in, out) and DELTA(in, out1 , out2 ) process it seems to be
possible to construct a counter.

COUNTER(out) = INC (a, b) |[ αINC (a, b) | αDELTA(b, a, out) ]| DELTA(b, a
(56)

αCOUNTER(out) = αINC (a, b) ∪ αDELTA(b, a, out) (57)
The following graphic shows the structure of the process COUNTER(out).

out
b
INC (a, b) DELTA(b, a, out)

a



We can employ a model checker to determine whether or not a system
deadlocks. A commonly used model checker for CSP is
Failures-Divergence Reﬁnement (FDR) [2].
Figure 1 shows the result of a deadlock check using FDR. However, FDR
is not only able to determine whether or not a system deadlocks, it can
also show the trace which resulted in the deadlock state. Figure 2, shows
this information.


Figure: Checking for Absence of Deadlocks of Process COUNTER(out)


Figure: Trace that lead to the Deadlock of Process COUNTER(out)


Overcoming the Deadlock

To overcome the deadlock it is necessary to inject a message into the
system to start the system. For this purpose we deﬁne the process
PREFIX (init : N, in, out), which send the value given in the parameter init
over its output channel out, and then transits to the process
RELAY (in, out). The process RELAY (in, out), fetches a message from the
channel in and sends it out over channel out.
Equation 58 gives the deﬁnition of process PREFIX (init : N, in, out).

PREFIX (init : N, in, out) = out!init → RELAY (in, out) (58)

RELAY (in, out) = in?m : N → out!m → RELAY (in, out) (59)

αPREFIX (init : N, in, out) = {out.init, in.x, out.x | x ∈ N} (60)


Figure: Checking for Absence of Deadlocks of Process COUNTER2(out)



The process COUNTER2(out) consists of three processes communicating
over three channels (a, b, and c). The messages passed over these three
channels are only relevant to the three processes INC (a, b),
DELTA(b, c, out), and PREFIX (0, c, a). However, by default all events are
exposed to the environment. This can have undesired side eﬀects, such as
two processes synchronise unintentionally on the same events. To avoid
this it is necessary to hide the events from the environment. This is done
by using the hiding operator: together with the set of events that should
be hidden.


In our counter example, all transactions on the channel a, b, and c are
internal and therefore should be hidden. Equation 61 shows process
COUNTER3(out) which hides the internal events.

COUNTER3(out) = COUNTER2(out) {a.x, b.x, c.x | x ∈ N} (61)

The alphabet of process COUNTER3(out) (Equation 62) only contains
the events of the outgoing channel out.

αCOUNTER3(out) = {out.x | x ∈ N} (62)


Using FDR for Refinement Checks

To determine whether or not the process COUNTER3(out) satisfies the
specification given with process COUNTER SPEC (out) (Equation 49) we
have to perform a refinement check:

COUNTER3(d) COUNTER SPEC (d) (63)


Figure: Does Process COUNTER3(out) fulﬁll the speciﬁcation?


Paradigms of OpenComRTOS

Interacting Entities
Virtual Single Processor (VSP) Programming Model.


Interacting Entities

Entities:
Tasks (Active Entities)
Hubs (Passive Entities):
Event
Semaphore
Port
FIFO
MemoryPool
Resource

Interactions


Virtual Single Processor (VSP) Programming Model.

Entities can be distributed in any form over the system,
OpenComRTOS ensures that the logical behaviour is preserved.
Separates Hardware from Software. Both can be changed almost
independently.
Interactions take place independent of placement.


Summary

Introduction to Distributed Heterogeneous Systems.
The basic theory of CSP;
Applying CSP to build a distributed system;
Using CSP to check whether or not a system deadlocks.
Using CSP to determine whether or not a system complies to its
speciﬁcation.
Paradigms of OpenComRTOS.


References

C.A.R. Hoare.
Communicating sequential processes.
Communications of the ACM, 21(8):666–677, August 1978.
Formal Systems (Europe) Ltd.
FDR2 User Manual, sixth edition, May 2003.


OpenComRtos 1.4_tutorial_1o4_presentation

Recommended

Recommended

More Related Content

Similar to OpenComRtos 1.4_tutorial_1o4_presentation

Similar to OpenComRtos 1.4_tutorial_1o4_presentation (20)

Recently uploaded

Recently uploaded (20)

OpenComRtos 1.4_tutorial_1o4_presentation