Modeling Heterogeneous Real-time Components in BIP
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Modeling Heterogeneous Real-time Components in BIP
Ananda Basu, Marius Bozga and Joseph Sifakis
Verimag, 38610 Gieres, France
{basu, bozga, sifakis}@imag.fr
Abstract software. Between the two extremes, a variety of interme-
diate and hybrid models exist (e.g., globally-asynchronous
We present a methodology for modeling heterogeneous locally-synchronous models).
real-time components. Components are obtained as the su- Another fundamental source of heterogeneity is the use
perposition of three layers : Behavior, specified as a set of models that represent a system at varying degrees of de-
of transitions; Interactions between transitions of the be- tail and are related to each other in an abstraction (or equiv-
havior; Priorities, used to choose amongst possible inter- alently, refinement) hierarchy. A key abstraction in system
actions. A parameterized binary composition operator is design is the one relating application software to its im-
used to compose components layer by layer. plementation on a given platform. Application software is
We present the BIP language for the description and largely untimed, in the sense that it abstracts away from
composition of layered components as well as associated physical time. The application code running on a given
tools for executing and analyzing components on a dedi- platform, however, is a dynamic system that can be mod-
cated platform. The language provides a powerful mecha- eled as a timed or hybrid automaton [3]. The run-time state
nism for structuring interactions involving rendezvous and includes not only the variables of the application software,
broadcast. We show that synchronous and timed systems but also all variables that are needed to characterize its dy-
are particular classes of components. Finally, we provide namic behavior, such as time variables and other quanti-
examples and compare the BIP framework to existing ones ties used to model resources. We need tractable theories
for heterogeneous component-based modeling. to relate component-based models at application and imple-
mentation levels. In particular, such theories must provide
means for preserving, in the implementation, all essential
properties of the application software.
1. Introduction
Unified frameworks encompassing heterogeneity in sys-
tems design have been proposed in [5, 8, 6, 4]. Neverthe-
A central idea in systems engineering is that complex less, in these works unification is achieved by reduction to a
systems are built by assembling components. System de- common low-level semantic model. We need a framework
signers deal with a large variety of components, each hav- which is not just a disjoint union of submodels, but one
ing different characteristics, from a large variety of view- which preserves properties during model composition and
points, each highlighting different dimensions of a system. supports meaningful analyses and transformations across
A central problem is the meaningful composition of hetero- heterogeneous model boundaries.
geneous components to ensure their correct inter-operation We present the BIP (Behavior, Interaction, Priority)
[12]. framework for modeling heterogeneous real-time compo-
One fundamental source of heterogeneity is the com- nents. BIP integrates results developed at Verimag over the
position of subsystems with different execution and inter- past five years. It is characterized by the following:
action semantics. At one extreme of the semantic spec-
trum are fully synchronized components, which proceed in • It supports a component construction methodology
lockstep with a global clock and interact in atomic transac- based on the thesis that components are obtained as
tions. Such a tight coupling of components is the standard the superposition of three layers. The lower layer de-
model for most synthesizable hardware and for synchronous scribes behavior. The intermediate layer includes a
real-time software. At the other extreme are completely set of connectors describing the interactions between
asynchronous components, which proceed at independent transitions of the behavior. The upper layer is a set of
speeds and interact non-atomically. Such a loose coupling priority rules describing scheduling policies for inter-
of components is the standard model for most multithreaded actions. Layering implies a clear separation betweenbehavior and structure (connectors and priority rules). include ports which are action names used for synchro-
nization.
• It uses a parameterized binary composition operator on
components. The product of two components consists • connectors used to specify possible interaction pat-
in composing their corresponding layers separately. terns between ports of atomic components.
Parameters are used to define new interactions as well
as new priority rules between the composed compo- • priority relations used to select amongst possible inter-
nents [11, 13]. The use of such a composition opera- actions according to conditions depending on the state
tor allows incremental construction. That is, any com- of the integrated atomic components.
pound component can be obtained by successive com-
position of its constituents. This is a generalization of We provide a description of the main features of the lan-
the associativity/commutativity property for composi- guage.
tion operators whose parameters depend on the order
of composition. 2.1. Atomic Components
• It encompasses heterogeneity. It provides a power- An atomic component consists of:
ful mechanism for structuring interactions involving
strong synchronization (rendezvous) or weak synchro- • A set of ports P = {p1 . . . pn }. Ports are action names
nization (broadcast). Synchronous execution is charac- used for synchronization with other components.
terized as a combination of properties of the three lay-
ers. Finally, timed components can be obtained from • A set of control states S = {s1 . . . sk }. Control states
untimed components by applying a structure preserv- denote locations at which the components await for
ing transformation of the three layers. synchronization.
• It allows considering the system construction pro- • A set of variables V used to store (local) data.
cess as a sequence of transformations in a three- • A set of transitions modeling atomic computa-
dimensional space: Behavior × Interaction × tion steps. A transition is a tuple of the form
P riority. A transformation is the result of the su- (s1 , p, gp , fp , s2 ), representing a step from control
perposition of elementary transformations for each di- state s1 to s2 . It can be executed if the guard (boolean
mension. This provides a basis for the study of prop- condition on V ) gp is true and some interaction in-
erty preserving transformations or transformations be- cluding port p is offered. Its execution is an atomic
tween subclasses of systems such as untimed/timed, sequence of two microsteps: 1) an interaction includ-
asynchronous/synchronous and event-triggered/data- ing p which involves synchronization between compo-
triggered. nents with possible exchange of data, followed by 2)
an internal computation specified by the function fp on
The paper is structured as follows. Section 2 presents the
V . That is, if v is a valuation of V after the interaction,
BIP language and the underlying concepts for component
then fp (v) is the new valuation when the transition is
composition. Section 3 presents the operational semantics
completed.
of the language and associated tools for execution and anal-
ysis. Section 4 shows that timed and synchronous systems
correspond to particular classes of BIP components. This is empty
illustrated by examples provided in Section 5. Finally, Sec- in
in
out
tion 6 discusses some more fundamental issues about the out
[0transition means that the associated guard is true and the connectors contain at most one port from each atomic com-
internal computation microstep is empty. The syntax for ponent. An interaction of γ is any non empty subset of this
atomic components in BIP is the following: set. For example, if p1 , p2 , p3 are ports of distinct atomic
components, then the connector γ = p1 |p2 |p3 has seven
atom::= interactions: p1 , p2 , p3 , p1 |p2 , p1 |p3 , p2 |p3 , p1 |p2 |p3 . Each
component component id non trivial interaction i.e., interaction with more than one
port port id+ port, represents a synchronization between transitions la-
[data type id data id+ ] beled with its ports.
behavior Following results in [11], we introduce a typing mech-
{state state id anism to specify the feasible interactions of a connector γ,
{on port id [provided guard] in particular to express the following two basic modes of
[do statement] to state id}+ }+ synchronization:
end
end • Strong synchronization or rendezvous, when the only
feasible interaction of γ is the maximal one, i.e., it con-
That is, an atomic component consists of a declaration fol- tains all the ports of γ.
lowed by the definition of its behavior. Declaration consists
of ports and data. Ports are identifiers and for data, basic C • Weak synchronization or broadcast, when feasible in-
types can be used. In the behavior, guard and statement teractions are all those containing a particular port
are C expressions and statements respectively. We assume which initiates the broadcast. That is, if γ = p1 |p2 |p3
that these are adequately restricted to respect the atomicity and the broadcast is initiated by p1 , then the feasible
assumption for transitions e.g. no side effects, guaranteed interactions are p1 , p1 |p2 , p1 |p3 , p1 |p2 |p3 .
termination.
Behavior is defined by a set of transitions. The keyword The typing mechanism distinguishes between complete
state is followed by a control state and the list of outgoing and incomplete interactions with the following restriction:
transitions from this state. Each transition is labelled by a All the interactions containing some complete interaction
port identifier followed by its guard, function and a target are complete; dually, all the interactions contained in in-
state. complete interactions are incomplete. An interaction of a
The BIP description of the reactive component of fig- connector is feasible if it is complete or if it is maximal.
ure 1 is: Preservation of completeness by inclusion of interactions
allows a simple characterization of interaction types. It is
component Reactive sufficient, for a connector γ to give the set of its minimal
port in, out complete interactions. For example, if γ = p1 |p2 |p3 |p4 and
data int x, y the minimal complete interactions are p1 and p2 |p3 , then the
behavior set of the feasible interactions are p1 , p2 |p3 , p1 |p4 , p2 |p3 |p4 ,
state empty p1 |p2 |p3 , p1 |p2 |p3 |p4 .
on in provided 0 < x do y:=f(x) to f ull If the set of the complete interactions of a connector is
state f ull empty, that is all its interactions are incomplete, then syn-
on out to empty chronization is by rendezvous. Broadcast through a port
end p1 triggering transitions labeled by ports p2 , . . . , pn can be
end specified by taking p1 as the only minimal complete inter-
action.
2.2. Connectors and Interactions The syntax for connectors is the following:
interaction ::= port id+
Components are built from a set of atomic components connector::=
with disjoint sets of names for ports, control states, variables connector conn id = port id+
and transitions. [complete = interaction+ ]
Notation: We simplify the notation for sets of ports [behavior
in the following manner. We write p1 |p2 |p3 |p4 for the {on interaction [provided guard] [do statement]}+
set {p1 , p2 , p3 , p4 } by considering that singletons are com- end]
posed by using the associative and commutative operation
|. That is, a connector description includes its set of ports fol-
A connector γ is a set of ports of atomic components lowed by the optional list of its minimal complete interac-
which can be involved in an interaction. We assume that tions and its behavior. If the list of the minimal completeinteractions is omitted, then this is considered to be empty. This connector describes transfer of value from x1 to x2 and
Connectors may have behavior specified as for transitions, x3 .
by a set of guarded commands associated with feasible in- Notice that contrary to other formalisms, BIP does not
teractions. If α = p1 |p2 |...|pn is a feasible interaction then allow explicit distinction between inputs and outputs. For
its behavior is described by a statement of the form: on α simple data flow relation, variables can be interpreted as
provided Gα do Fα , where Gα and Fα are respectively a inputs or outputs. For instance, x1 is an output and x2 , x3
guard and a statement representing a function on the vari- are inputs in C2 .
ables of the components involved in the interaction. As for
atomic components, guards and statements are C expression 2.3. Priorities
and statements respectively.
The execution of α is possible if Gα is true. It atom- Given a system of interacting components, priorities are
ically changes the global valuation v of the synchronized used to filter interactions amongst the feasible ones depend-
components to Fα (v). ing on given conditions. The syntax for priorities is the fol-
lowing:
C1 p2 C2 p2
x2 x2 priority::=
p1 p1
x1 x1 priority priority id [if cond] interaction < interaction
p3 p3
x3 x3
(a) (b) That is, priorities are a set of rules, each consisting of
an ordered pair of interactions associated with a condition
(cond). The condition is a boolean expression in C on the
Figure 2. Interaction types. variables of the components involved in the interactions.
When the condition holds and both interactions are enabled,
We use a graphical notation for connectors in the form of
only the higher one is possible. Conditions can be omitted
trees. The leaves are singleton interactions and the higher
for static priorities. The rules are extended for composition
level nodes are synchronization types. We denote an incom-
of interactions. That is, the rule begin1 < begin2 means
plete interaction by a bullet and a complete interaction by a
that any interaction of the form begin2 |q has higher priority
triangle. For example, consider the connector C1 described
over interactions of the form begin1 |q where q is an inter-
below:
action.
connector C1 = p1 |p2 |p3
behavior 2.4. Compound Components
on p1 |p2 |p3 provided ¬(x1 = x2 = x3 )
do x1 , x2 , x3 := MAX(x1 , x2 , x3 ) A compound component allows defining new compo-
end nents from existing sub-components (atoms or compounds)
by creating their instances, specifying the connectors be-
It represents a strong synchronization between p1 , p2 and tween them and the priorities. The syntax of a compound
p3 which is graphically represented in figure 2(a), where the component is defined by:
singleton incomplete interactions p1 , p2 , p3 are marked by
bullets. The behavior for the interaction p1 |p2 |p3 involves a compound::=
data transfer between the interacting components: the vari- component component id
ables xi are assigned the maximum of their values if they {contains type id {instance id[parameters]}+ }+
are not equal. [connector+ ]
The following connector describes a broadcast initiated [priority+ ]
by p1 . The corresponding graphical representation is shown end
in fig 2(b).
The instances can have parameters providing initial values
connector C2 = p1 |p2 |p3 to their variables through a named association.
complete = p1 An example of a compound component named System
behavior is shown in figure 3. It is the serial connection of three
on p1 do skip reactive components, defined as:
on p1 |p2 do x2 := x1
on p1 |p3 do x3 := x1 component System
on p1 |p2 |p3 do x2 , x3 := x1 contains Reactive r1 , r2 , r3
end connector C1 = r1 .inempty empty empty The extended automaton has a set of transitions of the form
C1 in C2 C3 C4
(s, α, g, f, s ), where:
in
out
in
out
out
full full full
• s = (s1 , . . . , sw ), si being a control state of the ith
r1 r2 System r3 atomic component.
• α is a feasible interaction associated with a guarded
Figure 3. A compound component.
command (Gα , Fα ), such that there exists a subset
J ⊆ {1, . . . , w} of atomic components with transi-
complete = r1 .in tions {(sj , pj , gj , fj , sj )}j∈J and α = {pj }j∈J .
connector C2 = r1 .out|r2 .in
behavior • g = ( j∈J gj ) ∧ Gα .
on r1 .out|r2 .in do r2 .x := r1 .y
end • f = Fα ; [fj ]j∈J . That is, the computation starts with
connector C3 = r2 .out|r3 .in the execution of Fα followed by the execution of all
behavior the functions fj in some arbitrary order. The result is
on r2 .out|r3 .in do r3 .x := r2 .y independent of this order as components have disjoint
end sets of variables.
connector C4 = r3 .out
• s (j) = sj if j ∈ J; otherwise s (j) = sj . That is, the
complete = r3.out
states from which there are no transitions labeled with
priority P1 r1 .in < r2 .out|r3 .in
ports in α, remain unchanged.
priority P2 r1 .in < r3 .out
priority P3 r1 .out|r2 .in < r3 .out The extended automaton is a machine with moves of the
α
end form (s, v) → (s , v ), where s is a state of the automaton
α
We use priorities to enforce a causal order of execution as and v is a valuation of its variables. The move (s, v) →
follows: once there is an in through C1 , the data are pro- (s , v ) is possible if there exists a transition (s, α, g, f, s ),
cessed and propagated sequentially, finally producing an such that g(v) = true and v = f (v).
out through C4 before a new in occurs through C1 . This
is achieved by a priority order which is the inverse of the 3.2. The BIP Execution Platform
causal order.
The BIP framework has been partially implemented in
3. Implementation the IF toolset [7] and the P ROMETHEUS tool [10]. We have
developed a full implementation of the toolset that includes:
In this section, we describe briefly the operational se-
mantics and the execution platform for BIP. • A frontend for editing and parsing BIP and generating
C++ code to be executed and analyzed on a backend
platform.
3.1. Operational semantics
• A backend platform consisting of an engine and the
A detailed and fully formalized operational semantics is infrastructure for executing the generated C++ code.
beyond the scope of this paper. We focus on aspects that
are crucial for understanding the underlying mechanism for • Connections to analysis tools of the IF tool-set.
execution of interactions between a set of components. For
the sake of simplification, we consider components without The execution engine directly implements the opera-
priorities. These are only a filtering mechanism for interac- tional semantics. At control states, atomic components post
tions. the port names of enabled transitions. The execution engine
Consider a compound component built from w atomic monitors the state of atomic components and finds all the
components by using a set of connectors and without prior- enabled interactions by evaluating the guards on the connec-
ity rules. Its meaning is an extended automaton with: tors. Then, between the enabled interactions, priority rules
• A set of variables, which is the union of the sets of are used to eliminate the ones with low priority. Amongst
variables of the atomic components. the maximal enabled interactions, it executes one and noti-
fies the atomic components involved in this interaction. The
• A set of states, which is the cartesian product of the notified components continue their local computation inde-
sets of control states of the atomic components. pendently and eventually reach new control states.Two options, one for multithreaded execution (each – φi (x, 0) = x, and
atomic component having a thread) and the other for a sin- – φi (x, t1 + t2 ) = φi (φi (x, t1 ), t2 ).
gle threaded execution (the execution engine being the only
thread) are implemented. An atomic timed component C represents a transition
The engine has a state space exploration mode, which system [2] in the following manner.
under some restrictions on the code for guards and func- Let si be a control state of C and (u, x) be a valuation of
tions, generates state graphs that can be analyzed by using (U, X). From the state (si , u, x),
model-checking tools.
The backend, which is the BIP exploration platform, • Either an enabled transition can be executed indepen-
has been entirely implemented in C++ on Linux and uses dently of its urgency type - the semantics is the same
POSIX threads. This choice has been made mainly for as for transitions of BIP components.
efficiency reasons but also to allow a smooth integration • Or time can progress by one unit, leading to state
of components with behavior expressed using plain C/C++ (si , u, φi (x, 1)), if all eager transitions are disabled.
code. The BIP frontend which includes the C++ code gener-
ator and some editing facilities, is implemented in Java. In
particular, the frontend uses Eclipse EMF technology and p r p r tick
associated tools for model representation and model trans- tick
Si Si x:= φi(x,1)
formations. r
p
r
p
gr gr
gpu∧gpt gpu∧gpt
fr fr
fp fp
4. Subclasses of Components Sm Sn Sr Sm Sn Sr
In this section, we show that timed and synchronous sys-
tems can be represented as BIP components. Figure 4. Transformation from Timed Compo-
nent to BIP Component.
4.1. Timed Components
We provide a translation from timed to BIP atomic com-
We define timed components and provide a structure pre- ponents. The principle of the translation is explained in
serving mapping from timed components to BIP compo- figure 4. It consists in implementing for each atomic com-
nents defined in section 2. ponent, time progress from si and subsequent state changes,
Timed components are built from atomic timed compo- by a loop transition with guard true and function φi (x, 1).
nents. The definition of atomic timed components for dis- This transition has a port tick for synchronization with
crete time is inspired from [2]. They have: other timed components.
• A set of ports P = {p1 . . . pn }. Priority: for all eager transition p, if(gp) Tick < p|q
for some interaction q
• A set of control states S = {s1 . . . sk }.
Tick
p tick r tick m tick
• A set of variables V partitioned into two sets U and
tick tick tick
X, respectively the set of untimed and timed variables. Si x:= φi(x,1) Sj x:= φj(x,1) Sm x:= φm(x,1)
• A set of transitions of the form (s1 , p, gpu ∧
gpt , fp , s2 )τp , representing a step from control state s1
to s2 . The urgency type τp which can be either eager Figure 5. Composition of Timed Compo-
or lazy is used to characterize the urgency of the tran- nents.
sition. As for ordinary transitions, gp = gpu ∧ gpt is a
guard, conjunction of conditions on untimed and timed
variables respectively and fp is a function on V . In the composition of the resulting BIP components from
the timed components, strong synchronization is necessary
• A set of evolution functions {φi }1≤i≤k in bijection for the tick ports as shown in the architecture of figure 5.
with control states. The function φi gives for a given That is, a connector T ick relating all the tick ports is used.
valuation x of X at control state si and a given value T ick has an empty set of complete interactions.
of a discrete time parameter t, the valuation φi (x, t) Furthermore, to take into account urgency of the transi-
reached when time progresses by t. Further, it satisfies tions, we use priorities. For each eager transition with guard
the following properties: gp , a rule of the form: priority P if gp T ick < p|q is usedwhere q is an interaction. This means that strong synchro- Priority: Syn < all interactions
nization through T ick can occur only if there are no enabled Syn
eager transitions.
syn syn syn
4.2. Synchronous Components
Synchronous components are a subclass of components Figure 7. Composition of Synchronous Com-
built from synchronous atomic components which have: ponents.
• A set of control states S, partitioned into three sets
S st = ∅, S un , S syn = ∅, respectively the sets of sta-
ble, unstable and synchronization states. leading from one global stable state to another. If all the
components are at stable states, then each component can
• A particular class of transitions, synchronization tran- execute a sequence of transitions leading to a synchroniza-
sitions. These have a special port syn, their guards are tion state. From synchronization states, strong synchroniza-
true and functions are empty. From synchronization tion through syn is enforced. This interaction cannot oc-
states only synchronization transitions are possible and cur as long as other interactions are possible, as it has the
lead to stable states. lowest priority. It may happen that during a synchronous
• Transitions from unstable states leading either to un- step some components stay at the same stable state, if the
stable states or to synchronization states. transitions leaving this state are not enabled. The synchro-
nization transition loops from stable states allow transitions
• Stable states with synchronization transition loops. All from synchronization states of the other components to be
other transitions from these states lead to unstable or executed.
synchronization states. There is a finite number of
transitions in a path between two successive distinct
stable states in the transition graph. This guarantees
5. Applications and Case Studies
that for dealockfree execution, stable states are visited
infinitely often. In this section we provide examples that were modeled
and executed in BIP. The first example, taken from [1], is a
performance evaluation problem with timed tasks process-
syn syn ing events from a bursty event generator. The second exam-
syn syn
ple is a synchronous modulo-8 counter.
syn
syn
5.1. Tasks with Bursty Event Generator
Figure 6. Synchronous Atomic Component. We model System which is the serial connection of a
bursty event generator with three tasks t1 , t2 and t3 , running
The general form of a synchronous atomic component on independent CPU’s. A task can execute as soon as its
is shown in figure 6. Composition of synchronous compo- predecessor has finished. The block diagram for System is
nents is characterized by the following requirements: shown in figure 8(a).
• Ports of transitions from unstable states must belong t1 t2
Even Even t1 t2
to complete interactions, that is, their execution cannot tGen CPU1 CPU2 tGen CPU2
be blocked due to synchronization constraints. t3
t3
CPU1
• All the syn ports are strongly synchronized via a con- CPU3
(a) (b)
nector Syn with empty set of complete interactions.
• Any interaction has higher priority than the syn inter- Figure 8. End to end delay measurement for
action. This enforces progress from stable states and tasks.
prevents livelock by looping on syn transitions.
The general form of a synchronous architecture is shown The atomic components of System are T ask and
in figure 7. The above requirements ensure lockstep exe- EventGenerator. For each atomic component, we spec-
cution. For such an execution, a run is a sequence of steps ify its ports, variables and behavior.get start preempt resume finish t3 (W CET = 1)
get ε connector C0 = e.tick|t1 .tick|t2 .tick|t3 .tick
c:=c+1
READY
φREADY(d,1)=d connector C1 = e.period
complete = e.period
finish δ start ε, [c>0]
[d T Figure 11. Architecture of System.
and has a minimum inter-arrival time D between successive
events being generated. Consider a modification of System where tasks t1 and
The compound component System is a serial connec- t3 share CPU1 and t1 can preempt t3 , whereas t2 runs on
tion of the EventGenerator and three instances of T ask, CPU2, as shown in figure 8(b). Its BIP description without
t1 , t2 and t3 , as shown in figure 11. In this model, the tasks the priorities enforcing urgency is given below:
are non-preemptable, so the ports preempt and resume are
component System
not associated to connectors. Component instances are pa-
contains EventGenerator e(T = 10, J = 40, D = 1)
rameterized: EventGenerator instance by the time-period
contains T ask t1 (W CET = 8), t2 (W CET = 4),
T, jitter J and minimum inter-arrival time D; Task instances
t3 (W CET = 1)
by their worst case execution time WCET. The BIP descrip-
connector C0 e.tick|t1 .tick|t2 .tick|t3 .tick
tion of System without the priorities enforcing urgency is
connector C1 = e.period
shown below:
complete = e.period
component System connector C2 = e.go|t1 .get
contains EventGenerator e(T = 10, J = 40, D = 1) connector C3 = t1 .f inish|t2 .get|t3 .resume
contains T ask t1 (W CET = 8), t2 (W CET = 4), complete = t1 .f inish|t2 .getconnector C4 = t3 .f inish|t1 .resume syn flip syn
complete = t3 .f inish Zero Zero’
syn
connector C5 = t1 .start|t3 .preempt flip flip
complete = t1 .start [x=1] [x=1]
y:=0 y:=1
connector C6 = t3 .start|t1 .preempt syn
One’ One
complete = t3 .start
syn
connector C7 = t2 .start
complete = t2 .start
connector C8 = t2 .f inish|t3 .get Figure 13. The Modulo2Counter component.
priority P1 t3 .start < t1 .start
priority P2 t3 .start|t1 .preempt < t1 .f inish|t2 .get The compound component Counter consists of 3 in-
priority . . . stances of M odulo2Counter namely b0 , b1 , and b2 , where
end b0 is the least significant bit. The C0 connector consists of
Mutual exclusion between t1 and t3 is enforced by the con- all the syn ports requiring strong synchronization. All the
nectors C3 , C4 , C5 and C6 . They guarantee that a task will f lip interactions are complete.
preempt if the other has to start, and similarly a task can re-
component Counter
sume only when the executing task finishes, as depicted in
contains M odulo2Counter b0 , b1 , b2
the architecture of figure 12. Priority P1 enforces the static
connector C0 = b0 .syn|b1 .syn|b2 .syn
priority between t1 , t3 and priority P2 ensures non preemp-
behavior
tion of t1 by t3 . The maximum end to end delay recorded
on b0 .syn|b1 .syn|b2 .syn
by the observer component in this example was 194 time
do b0 .x:=1, b1 .x:=b0 .y, b2 .x:=b0 .y∧b1 .y
units.
end
connector C1 = b0 .f lip
C2 C3 complete = b0 .f lip
get tick
finish
tick go get tick connector C2 = b1 .f lip
start
e
resume resume t2 C7 complete = b1 .f lip
period t1
connector C3 = b2 .f lip
C1 preempt finish
preempt start complete = b2 .f lip
C4 C6 C5 priority P0 b0 .syn|b1 .syn|b2 .syn < b0 .f lip
C0 start preempt priority P1 b0 .syn|b1 .syn|b2 .syn < b1 .f lip
priority P2 b0 .syn|b1 .syn|b2 .syn < b2 .f lip
finish
resume
t3 end
C8
get
tick
System The global data flow is encoded in the behavior of the syn
connector C0 . The input (x) of b0 representing the least sig-
nificant bit of the counter, is always set to 1, for b2 , the in-
Figure 12. Architecture of System with mu-
put is the conjunction of the outputs(y) of the previous two
tual exclusion.
bits(b0 , b1 ). The y values form the output of the Counter
on execution generates the count sequence 000 to 111. Low
priority of the syn interaction favours internal computations
of the atomic components.
5.2. Synchronous Modulo-8 Counter
We model a synchronous modulo-8 counter producing a 6. Discussion
3 bit count value. A bit is modeled as an atomic component
representing a modulo-2 counter. The modulo-8 counter is The BIP framework shares features with existing ones
obtained by composing three modulo-2 counters. for heterogeneous components, such as [5, 8, 6, 4]. A com-
The behavior of the atomic component mon key idea is to encompass high-level structuring con-
M odulo2Counter is depicted in figure 13. Zero’ cepts and mechanisms. Ptolemy was the first tool to sup-
and One’ are stable states whereas Zero and One are syn- port this by distinguishing between behavior, channels, and
chronization states respectively. The port f lip corresponds directors. Similar distinctions are also adopted in Metropo-
to a complete interaction. The variable x is the input and y lis and BIP, which offer interaction-based and control-based
is the output. mechanisms for component integration. The two types ofmechanisms correspond to cooperation and competition, Current work on BIP deals with both theoretical issues
two complementary fundamental concepts for system orga- and applications. Theoretical work directions include the
nization. study of a notion of glue for components and its properties
There is evidence through numerous examples treated in as well as a notion of expressiveness for component-based
BIP, that the combination of interaction and control mech- description languages. Applications aim at “componentiz-
anism allows enhanced modularity and direct modeling of ing” existing real-time software written in C++ including an
schedulers, quality controllers and quantity managers. MPEG encoder and an adaptive robotic application. Finally,
BIP characterizes components as points in a three- we are developing a tool for translating a subset of the BIP
dimensional space: Behavior × Interaction × P riority, language into THINK [9], from which implementations on
as represented in figure 14. Elements of the Interaction × bare machines can be generated.
P riority space characterize the overall architecture. Each
dimension, can be equipped with an adequate partial order, References
e.g., refinement for behavior, inclusion of interactions, in-
clusion of priorities. Some interesting features of this rep- [1] Workshop on distributed embedded systems, lorentz center,
resentation are the following: leiden, 2005. http://www.tik.ee.ethz.ch/ leiden05.
[2] K. Altisen, G. Gößler, and J. Sifakis. Scheduler modeling
P (+ restriction) based on the controller synthesis paradigm. Real-Time Sys-
tems, 23(1-2):55–84, 2002.
architecture [3] R. Alur, C. Courcoubetis, N. Halbwachs, T. Henzinger, P.-H.
Ho, X. Nicollin, A. Olivero, J. Sifakis, and S. Yovine. The
System algorithmic analysis of hybrid systems. Theoretical Com-
I
puter Science, 138(1):3–34, 1995.
(+interaction) [4] F. Arbab. Abstract behavior types: a foundation model for
components and their composition. Sci. Comput. Program.,
B (+ refinement) 55(1-3):3–52, 2005.
[5] F. Balarin, Y. Watanabe, H. Hsieh, L. Lavagno,
C. Passerone, and A. Sangiovanni-Vincentelli. Metropolis:
Figure 14. The Construction Space.
An integrated electronic system design environment. IEEE
Computer, 36(4):45–52, 2003.
[6] K. Balasubramanian, A. Gokhale, G. Karsai, J. Sztipanovits,
Separation of concerns: Any combination of behavior, in-
and S. Neema. Developing applications using model-driven
teraction and priority models meaningfully defines a design environments. IEEE Computer, 39(2):33–40, 2006.
component. This is not the case for other formalisms [7] M. Bozga, S. Graf, I. Ober, I. Ober, and J. Sifakis. The IF
e.g., in Ptolemy [8], for a given model of computation, toolset. In SFM, pages 237–267, 2004.
only particular types of channels can be used. Separa- [8] J. Eker, J. Janneck, E. Lee, J. Liu, X. Liu, J. Ludvig,
tion of concerns is essential for defining a component’s S. Neuendorffer, S. Sachs, and Y. Xiong. Taming hetero-
construction process as the superposition of elemen- geneity: The Ptolemy approach. Proceedings of the IEEE,
tary transformations along each dimension. 91(1):127–144, 2003.
[9] J.-P. Fassino, J.-B. Stefani, J. Lawall, and G. Muller.
Unification: Different subclasses of components THINK: A Software Framework for Component-based Op-
e.g.,untimed/timed, asynchronous/synchronous, erating System Kernels. In Proceedings of the Usenix An-
event-triggered/data-triggered, can be unified through nual Technical Conference, June 2002.
transformations in the construction space. These [10] G. Gößler. P ROMETHEUS — a compositional modeling
tool for real-time systems. In P. Pettersson and S. Yovine,
often involve displacement along the three coordi-
editors, Proc. Workshop RT-TOOLS 2001. Technical report
nates. They allow a deeper understanding of the 2001-014, Uppsala University, Department of Information
relations between existing semantic frameworks in Technology, 2001.
terms of elementary behavioral and architectural [11] G. Gößler and J. Sifakis. Composition for component-based
transformations. modeling. Sci. Comput. Program., 55(1-3):161–183, 2005.
[12] T. Henzinger and J. Sifakis. The embedded systems design
Correctness by construction: The component construc- challenge. Proceedings FM 2006, LNCS, 2006.
tion space provides a basis for the study of architecture [13] J. Sifakis. A framework for component-based construction.
transformations allowing preservation of properties of In Proceedings of the Third International Conference on
the underlying behavior. The characterization of such Software Engineering and Formal Methods (SEFM), pages
transformations can provide (sufficient) conditions for 293–300. IEEE Computer Society, 2005.
correctness by constructions such as compositionality
and composability results for deadlock-freedom [11].You can also read
