Rigorous Component-Based System Design Using the BIP Framework

TL;DR: An autonomous robot case study illustrates the use of the behavior, interaction, priority (BIP) component framework as a unifying semantic model to ensure correctness of essential system design properties.

Abstract: An autonomous robot case study illustrates the use of the behavior, interaction, priority (BIP) component framework as a unifying semantic model to ensure correctness of essential system design properties.

Summary

The BIP Component Framework

• The BIP framework uses connectors to specify possible interactions between components and priorities to select among possible interactions.
• Interactions express synchronization constraints between the composed components' activities, and priorities filter possible interactions to steer system evolution toward meeting performance requirements.
• The combination of interactions and priorities is the source of BIP's expressive power.
• It defines a clean, abstract concept of architecture separate from behavior.
• The execution is an atomic sequence of two microsteps: first, execution of the interaction involving the port, which is a synchronization between several components with possible data exchange, followed by execution of the action associated with the transition.

Example 1: Atomic Components

• The right side of Figure 1 shows two atomic components, Service-Controller and Activity, for the Dala robot controller.
• Activity wraps the long-time computation of some specific application function.
• Service-Controller provides execution control (triggering, canceling, error control, and so on) over the associated Activity component.
• For simplicity's sake, the figure presents only the skeleton control behavior (ports and.

RELATED WORK IN COMPONENT FRAMEWORKS

• BIP differs significantly from existing component frameworks for software engineering.
• Another significant difference from other frameworks is that BIP is intended for system modeling.
• Connectors defi ne relationships between ports of interacting components.
• Its execution consists of transferring the data and then, notifying the components involved in the interaction.
• When the condition holds and both interactions of the corresponding pair are enabled, only the one with higher-priority can be executed.

Example 2: Composite Components

• The Service component on the left side of Figure 1 is a composite of Activity and Service-Controller through connectors that enforce strong synchronizations of several actions (for example, start, exec, finish, fail).
• Service is further composed with the Service-Proxy component by using the ports available on the Service interface, which are explicitly redirected either to subcomponent ports or to inner connectors.
• A trigger action is either executed alone or synchronized with request actions when they're enabled.
• A concrete modeling language supports the BIP framework.
• It also provides additional structural syntactic constructs for defi ning component behavior and describing connectors and priorities.

The BIP Design Flow

• Translating the application software into a BIP model.
• The translation focuses on the defi nition of adequate interfaces.
• It encapsulates and reuses the application software's data structures and functions.

Translating Application Software into BIP

• The authors have developed a general method for generating BIP models from languages with welldefi ned operational semantics.
• The authors developed BIP model generators for several programming models used by embedded system developers .
• The generated models preserve the structure of the initial programs, their size is linear with respect to the initial program size, and they're easy for the system developers to understand.

Using D-Finder for Compositional Verifi cation

• D-Finder bases its compositional verifi cation method on computing invariants.
• It computes increasingly stronger invariants for composite components as conjunctions of atomic components' local invariants and interaction invariants that characterize the composition glue.
• The authors recently improved this method to take advantage of the incremental system design process, which proceeds by adding new interactions to a component under construction.
• If these conditions aren't satisfi ed, D-Finder generates new invariants by reusing invariants of the constituent components.
• 7 Experimental results on classical benchmarks show that D-Finder can run exponentially faster than existing monolithic verifi cation tools, such as NuSMV.

Generating Implementations

• The BIP toolset offers several compila-tion chains, targeting different execution platforms.
• BIP currently provides two engines: one for real-time single-thread and one for multithread execution.
• First, given a userdefi ned partition of a BIP system model's interactions, the authors break the atomicity of its transitions by separating the interaction from the computation.
• The interaction protocol layer consists of a set of components, each of which manages a class of the par- tition's interactions.
• The protocol detects whether interactions are enabled and executes them after resolving confl icts either locally or with assistance from the third layer.

Figures

FIGURE 3. BIP toolset. The tools include translators from various programming models, veri cation tools, source-to-source transformers, and C/C++ code generators for BIP models.

FIGURE 1. BIP component schematic. The Service composite component on the left, for a Dala robot service, consists of two atomic components: Service Controller and Activity.

Full text

© 2011 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating
new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
For more information, please see www.ieee.org/web/publications/rights/index.html.
www.computer.org/software
Rigorous Component-Based System Design
Using the BIP Framework
Anandu Basu, Saddek Bensalem, Marius Bozga, Jacques Combaz,
Mohamad Jaber, Thanh-Hung Nguyen, and Joseph Sifakis
Vol. 28, No. 3
May/June 2011
This material is presented to ensure timely dissemination of scholarly and technical work.
Copyright and all rights therein are retained by authors or by other copyright holders. All
persons copying this information are expected to adhere to the terms and constraints
invoked by each author's copyright. In most cases, these works may not be reposted
without the explicit permission of the copyright holder.

0740-7459/11/$26.00 © 2011 IEEE MAY/JUNE 2011 | IEEE SOFTWARE
41
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS
MULTIPARADIGM
PROGRAMMING
FOCUS
MULTIPARADIGM PROGRAMMING
SYSTEM DESIGN DIFFERS radically
from pure software design in that it
must account not only for functional
requirements but also for extrafunc-
tional requirements regarding the use
of execution platform resources, such
as time, memory, and energy. Meet-
ing extrafunctional requirements is
essential in embedded system design
and requires evaluation of how design
choices affect overall system behavior.
It also implies a deep understanding of
how the application software interacts
with the underlying execution plat-
form. Yet system designers currently
lack rigorous techniques for deriving
global models of a given system from
models of its application software and
execution platform.
We dene a rigorous design ow
as one that guarantees essential sys-
tem properties. Most existing design
ows that aspire to this goal privilege a
unique programming model and asso-
ciate it with a compilation chain that’s
adapted for a given execution model.
For example, synchronous system de-
sign relies on synchronous program-
ming models and usually targets hard-
ware or sequential implementations on
single processors.
1
Alternatively, real-
time programming, based on sched-
uling theory for periodic tasks, tar-
gets dedicated real-time multitasking
platforms.
2
At the Verimag Laboratory, we’ve
been developing the behavior, interac-
tion, priority (BIP) component frame-
work to support a rigorous system de-
sign ow. The BIP framework is
• model-based, describing all soft-
ware and systems according to a
single semantic model. This main-
tains the ow’s overall coherency
by guaranteeing that a description
at step n+1 meets essential proper-
ties of a description at step n.
• component-based, providing a
family of operators for building
composite components from sim-
pler components. This overcomes
the poor expressiveness of theoreti-
cal frameworks based on a single
operator, such as the product of au-
tomata or a function call.
• tractable, guaranteeing correctness
Rigorous
Component-Based
System Design
Using the BIP
Framework
Ananda Basu, Saddek Bensalem, Marius Bozga, Jacques Combaz,
Mohamad Jaber, Thanh-Hung Nguyen, and Joseph Sifakis,
Verimag Laboratory
// An autonomous robot case study illustrates the use
of the behavior, interaction, priority (BIP) component
framework as a unifying semantic model to ensure
correctness of essential system design properties. //
FOCUS: SOFTWARE COMPONENTS: BEYOND PROGRAMMING

42 IEEE SOFTWARE | WWW.COMPUTER.ORG/SOFTWARE
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS
MULTIPARADIGM
PROGRAMMING
FOCUS
MULTIPARADIGM PROGRAMMING
FOCUS: SOFTWARE COMPONENTS: BEYOND PROGRAMMING
by construction and thereby avoid-
ing monolithic a posteriori verica-
tion as much as possible.
BIP supports the construction of
composite, hierarchically structured
components from atomic components
characterized by their behavior and
interfaces. It lets developers compose
components by layered application of
interactions and priorities. This en-
ables an expressiveness unmatched
by any other existing formalism (see
the related work sidebar).
3
Architec-
ture is a first-class concept in BIP,
with well-defined semantics that
system designers can analyze and
transform.
In this article, we present the BIP
component framework, highlight-
ing its design ow and the main steps
for deriving correct implementations
from a given application’s software
and a target platform. Case study re-
sults from a BIP implementation of the
Dala autonomous robot demonstrate
its effectiveness.
The BIP Component
Framework
The BIP framework uses connectors to
specify possible interactions between
components and priorities to select
among possible interactions. Interac-
tions express synchronization con-
straints between the composed com-
ponents’ activities, and priorities lter
possible interactions to steer system
evolution toward meeting performance
requirements. The combination of in-
teractions and priorities is the source
of BIP’s expressive power. It denes a
clean, abstract concept of architecture
separate from behavior.
Atomic components are nite-state
automata or Petri nets extended with
data and ports. Ports are action names
that can be associated with data and
used for interactions with other compo-
nents. States denote control locations
where components wait for interac-
tions. A transition is an execution step,
labeled by a port, from one control lo-
cation to another. Each transition has
an associated guard and action—re-
spectively, a Boolean condition and a
function dened on local data. In BIP,
complex data and their transformations
are written in C/C++.
A transition can be executed if its
guard evaluates to true and some inter-
action involving its port is enabled. The
execution is an atomic sequence of two
microsteps: rst, execution of the in-
teraction involving the port, which is a
synchronization between several com-
ponents with possible data exchange,
followed by execution of the action as-
sociated with the transition.
Example 1: Atomic Components
The right side of Figure 1 shows two
atomic components, Service-Controller and
Activity, for the Dala robot controller.
Activity wraps the long-time computa-
tion of some specic application func-
tion. Service-Controller provides execution
control (triggering, canceling, error
control, and so on) over the associ-
ated Activity component. For simplici-
ty’s sake, the gure presents only the
skeleton control behavior (ports and
RELATED WORK
IN COMPONENT FRAMEWORKS
BIP differs signicantly from existing component frameworks for
software engineering. These often use multithreaded program-
ming and point-to-point interaction mechanisms, such as function
calls, for coordination between components. In contrast, BIP ex-
ecutes atomic components concurrently and coordinates them in
terms of high-level mechanisms such as protocols and scheduling
policies.
Because BIP focuses on the organization of computation
between components, it can be viewed as an architecture
description language (ADL). Like other existing ADLs, such as
Acme (www.cs.cmu.edu/~acme)
1
and Darwin,
2
BIP uses the
connector concept to express coordination between components.
Nonetheless, connectors in BIP are stateless. The architecture,
consisting of connectors and priorities, is clearly distinguished
from behavior.
Another signicant difference from other frameworks
is that BIP is intended for system modeling. It directly
encompasses timing and resource management. Other system
modeling formalisms either seek generality to the detriment of
rigorousness, such as (Systems Modeling Language (SySML)
3
and (Architecture Analysis and Design Language (AADL; http://
standards.sae.org/as5506a),
4
or limit their scope to specic
computation models, such as Ptolemy.
5
References
1. D. Garlan, R. Monroe, and D. Wile, “Acme: An Architecture Description
Interchange Language, Proc. 1997 Conf. Centre for Advanced Studies on
Collaborative Research (CASCON 97), IBM Press, 1997, pp. 169–183.
2. J. Magee and J. Kramer, “Dynamic Structure in Software Architectures,”
Proc. 4th ACM SIGSOFT Symp. Foundations of Software Eng. (SIGSOFT
96), ACM Press, 1996, pp. 3–14.
3. OMG Systems Modeling Language SysML (OMG SysML), v. 1.2, Object
Management Group, 2010; www.omg.org/spec/SysML/1.2.
4. P.H. Feiler, B. Lewis, and S. Vestal, “The SAE Architecture Analysis and
Design Language (AADL): A Standard for Engineering Performance Critical
Systems,” IEEE Conf. Computer Aided Control Systems Design (CACSD
06), IEEE Press, 2006, pp. 1206–1211.
5. J. Eker et al., “Taming Heterogeneity: The Ptolemy Approach,” Proc. IEEE,
vol. 91, no. 1, 2003, pp. 127–144.

MAY/JUNE 2011 | IEEE SOFTWARE
43
transitions) and omits the data and
associated code. For example, Activity
is initialized (start transition) and then
executes its associated functions (exec,
internal_exec transitions). The execution
might  nish normally ( nish transition),
fail (fail transition) or be interrupted
(inter transition).
Compositecomponents a r e d e  n e d
by assembling constituent components
(atomic or composite) using connec-
tors. Connectors de ne relationships
between ports of interacting compo-
nents. They represent sets of interac-
tions—that is, nonempty sets of ports
that must be jointly executed. Within
a connector, an interaction can occur
in two situations: when all involved
ports are ready to participate (strong
synchronization) or when a port trig-
gers the interaction without waiting
for other ports (broadcast).
The valid interactions within con-
nectors are formally de ned by al-
gebraic expressions on ports using a
binary fusion operator and a unary
typing operator.
4
Typing associates
connector ends (ports or connectors)
to synchronization types: trigger (ac-
tive port, initiates broadcast) or syn-
chron (passive port). Moreover, every
connector interaction is associated
with a guard and a data transfer func-
tion. An interaction can be executed
only when its guard is true. Its execu-
tion consists of transferring the data
and then, notifying the components in-
volved in the interaction.
Finally, the priorities for choos-
ing between simultaneously enabled
interactions within a BIP component
are de ned as rules, each consisting
of a pair of interactions associated
with a condition. When the condi-
tion holds and both interactions of the
corresponding pair are enabled, only
the one with higher-priority can be
executed.
Example 2: Composite Components
The Service component on the left side
of Figure 1 is a composite of Activity
and Service-Controller through connec-
tors that enforce strong synchroniza-
tions of several actions (for example,
start, exec, finish, fail). The connectors al-
low the Service-Controller to initiate and
follow the computation performed
within Activity. The composite com-
ponent is equipped with priorities to
privilege the execution of a fail inter-
action—that is, error handling—over
finish and exec interactions, which cor-
respond to normal behavior.
The example also illustrates the
encapsulation principle used in BIP.
Service is further composed with the
Service-Proxy component by using the
ports available on the Service interface,
which are explicitly redirected either
to subcomponent ports or to inner
connectors. The trigger-request connec-
tor between Service-Proxy and Service il-
lustrates a broadcast initiated by the
trigger port. A trigger action is either
executed alone or synchronized with
request actions when they’re enabled.
A concrete modeling language
Ether
Start
Control
Exec
Abort
Report
getStatus
getStatus
getStatus
abort
error
fail
nish
inter
getStatus
send_nal_report
getStatus
abort
control
start
abort
internal_start
start
codel_is_executed
inter
internal_inter
codel_is_executed
exec
internal_exec
nish
fail
codel_is_executed
internal_nish
internal_fail
send_nal_report
codel_is_executed
inter
inter
exec
getStatus
startstart
exec
fail
fail
Service
nishsend_nal_report
abort getStatus
Service controller
codel_is_executed
Activity
codel_is_executed
exec send_nal_reportnish
exec, nish < fail
codel_is_executedgetStatusabort
request
request
request
get_report
abort_conict
check_req
get_report
get_report
get_report
abort_conict
reject
read_req
trigger
Service proxy
trigger
get_report
no_req
send_nal_report
reject
check_req
no_req
read_req
Ether
Start
Exec
Abort
Istart
Sleep
Run
Inter
End
iEnd
iFail
Fail
Read
Idle
Check
Abort
FIGURE 1. BIP component schematic. The Service composite component on the left, for a Dala robot service, consists of two atomic
components: Service Controller and Activity.

44 IEEE SOFTWARE | WWW.COMPUTER.ORG/SOFTWARE
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS: MULTIPARADIGM PROGRAMMING
FOCUS
MULTIPARADIGM
PROGRAMMING
FOCUS
MULTIPARADIGM PROGRAMMING
FOCUS: SOFTWARE COMPONENTS: BEYOND PROGRAMMING
supports the BIP framework. The BIP
language leverages C++-style variables
and data-type declarations, expres-
sions, and statements. It also provides
additional structural syntactic con-
structs for de ning component be-
havior and describing connectors and
priorities. Moreover, it provides con-
structs for handling parametric and hi-
erarchical descriptions and for express-
ing timing constraints associated with
behavior.
The BIP Design Flow
Figure 2 illustrates a rigorous system
design  ow that uses BIP as a unifying
semantic model to ensure consistency
between the different design steps.
The design  ow involves four dis-
tinct steps that translate the applica-
tion software into a BIP model and
progressively derive an implementa-
tion by applying source-to-source
transformations:
 1. Translatingtheapplicationsoftware
into a BIP model. The translation
focuses on the de nition of adequate
interfaces. It encapsulates and reuses
the application software’s data struc-
tures and functions.
2. Integratingarchitecturalconstraints
in the application software model.
The integration derives a system
model in BIP from a model of the
hardware target platform and a
mapping.
3. Translating interactions and pri-
oritiesof the system model in terms
of protocols using send/receive
primitives.
4. GeneratingdeployableCcodefrom
which an implementation can be
obtained.
The transformations are “correct by
construction” because the obtained BIP
models are observationally equivalent
to the original model. In particular,
they preserve the application software’s
safety properties. Furthermore, we de-
veloped D-Finder, a veri cation tool
that checks essential safety properties
of the application software.
Figure 3 shows an extensible toolset
that supports the entire BIP design
 ow, including D-Finder.
Translating Application Software into BIP
The  rst step in the design  ow con-
sists of generating a BIP model for the
application software. We have devel-
oped a general method for generating
BIP models from languages with well-
de ned operational semantics. It in-
volves the following steps for a given
application software written in a lan-
guage L:
 1. TranslatingthesourcelanguageL’s
atomic components into BIP com-
ponents. The translation focuses
on the de nition of adequate inter-
faces. It encapsulates and reuses the
application software’s data struc-
tures and functions.
 2. Translatingthecoordinationmecha-
nisms betweenapplicationsoftware
components into the target BIP
model’s connectors and priorities.
 3. Generating a BIP component that
models L’s operational seman-
tics. This component plays the role
of an engine coordinating the ex-
ecution of the application software
components.
We developed BIP model genera-
tors for several programming models
used by embedded system develop-
ers (the source-to-source transformers
in Figure 3). The generated models
preserve the structure of the initial
Mapping
Deployable code
Translation
Performance
analysis
D−Finder
Hardware execution platform
Integration of
architectural constraints
Application software
System model in BIP
Code generation
software model in BIP
Application
Integration of
communication protocols
Distributed system model in S/R−BIP
FIGURE 2. BIP design  ow. An implementation—that is, deployable code—is generated
from the application software, a model of the hardware platform, and a mapping.