Share This
Scroll Down
Back to home

Dynamic Reconfigurable BIP

Modeling, simulating and verifying dynamic reconfigrable systems

Let's Start

DR-BIP Overview

DR-BIP separates between reconfiguration causing changes in the system architecture and the execution of a fixed system configuration.

The Dynamic Reconfigurable BIP (DR-BIP) framework is an extension of the Behavior Interaction Priority (BIP) component framework enriched with dynamic exogenous reconfiguration primitives, intended to support rigorous modeling of reconfigurable systems.

DR-BIP separates between execution of reconfiguration operations and execution of a fixed system configuration. Such a separation of concerns offers the advantage of re-using the mature and efficient BIP engine as well as existing associated analysis and verification tools.

Another direct benefit is the possibility to monitor a holistic view of a system’s behavior captured as a set of traces involving information about both the state of the system components and the dynamically changing architecture. Monitoring and analyzing such traces allows the formalization and runtime verification of properties of reconfigurable systems.


Architectural Motifs

Motifs act as blueprints to describe the dynamic architecture. They are dynamic structures composed of:
  1. A set of managed components
  2. A Map describing an abstract view of positions/roles
  3. An addressing function that assigns managed components to their given position/role in the map


Reconfiguration Rules

Used to reconfigure the architecture. Rules define when reconfigurations occur in a declarative manner and what is changed in an imperative manner.

Rules use information from the motifs' managed components, maps and addressing functions to select the components and motifs that need to be changed:
  1. Modify motifs: components, maps and addressing functions
  2. Modify connectors: changing how components are connected
  3. Add and remove components dynamically to the system

Rules are either defined for a given motif, or can impact multiple motifs globally. Global rules can create/delete motif instances, and migrate components between motifs.



Once reconfiguration rules are executed, components and connectors may be added or removed. The result is a configuration.

The new system can be executed with the BIP engine as if it were a static BIP system until further reconfiguration is needed. It can also be verified using the classical BIP tools.

When combining configurations with the state of components, we obtain stateful configurations. The combination makes it possible to analyze changes in the dynamic architecture while also accounting for the state of components.


DR-BIP Modules

The DR-BIP framework is composed of many modules working in concert to provide a cohesive view of the executing dynamic and reconfigurable system:

The DR-BIP framework has been designed to re-use existing BIP Tools, in particular: the BIP Compiler and the BIP Execution Engine. It introduces a Reconfiguration Layer that conceptually separates between reconfiguration and the execution of a static BIP system. The reconfiguration layer deals only with reconfiguration concerns. To accomplish re-use, the BIP engine has been modified to be given interrupt conditions allowing it to stop executing when one such condition holds, to transfer control to the reconfiguration engine. Then the reconfiguration engine is capable of modifying the system at runtime yielding back to the BIP engine to execute again.

More details are listed per module for more information.

// DR-BIP Language

The DR-BIP Language is used to describe architectural motifs and reconfiguration rules while importing the underlying BIP model that describes the types of components and connectors. In addition, it also imports the API of maps and addressing functions already implemented in C++.


The DR-BIP language deals only with motifs and reconfiguration rules. However, it is possible to import elements for usage in the DR-BIP model:

  1. BIP Package Name - model
    Import components and connector types from the .bip file
  2. BIP Predicates- condition
    C++ function signature that evaluates some condition on the state of the BIP system (e.g., check if a component instance is in a given location). Used as predicate when writing rule conditions.
  3. Map - structure
    Signature of a map implementation, with its accessible methods. Specifying a method is const allows it to be used as a predicate when writing rule conditions.
  4. Addressing Function - addressing
    Similar to the Map import, signature of an addressing function implementation

//import CAR component and connectors
//from platoon.bip
model platoon

import from "platoon.cpp" {

  // check if two cars are close
  condition CarProximity(CAR, CAR, float)
  // car wants to split/merge
  condition AtLocSplit(CAR)
  condition AtLocMerge(CAR)

  structure PlatoonMap {
      const bool isLeader(Node)
      const bool isTail(Node)
      const bool validSplit(Node)
      void merge(PlatoonMap)
      /* More functions */
   addressing PlatoonAddressing { /* ... */ }
// Declare motif Platoon
motif Platoon<PlatoonMap, PlatoonAddressing> {

      Add rules that affect each
      Platoon instance independently



Motifs are delcared using the keyword motif followed by their map type and optionally addressing function type. It is possible to ommit a map in which case the motif only uses the set of managed components.

Reconfiguration rules defined inside the motif apply to instances of the motif independently.

Reconfiguration Rules

Reconfiguration rules consist of 3 elements:

  1. Parameters
    Specify the type and tuples of elements the rule uses to (e.g., if there are 2 parameters, the rule will be executed for all pairs). These are usually components, but could also be motifs for global rules.
  2. Condition- when
    It is used to assign components or motifs to the parameters. It works as a filter restricting all possible assignments to those for which the condition is true.
  3. Reconfiguration Actions
    Rules define a sequence of reconfiguration actions that modify the motifs and the configuration. Actions can:
    1. Modify Elements
      Create or delete instances of components or motifs.
    2. Modify Existing Motifs
      Change the managed components, map, and addressing function of a given motif. Maps and adressing functions are modified by calling their imported methods.
    3. Connect Components
      Create connectors on components.

motif Platoon <PlatoonMap, PlatoonAddressing> {
  // Look for all pairs of cars where "when" holds
  rule connecting SplitRule(CAR leader, CAR follower)
    when (
      // Platoon size must be at least 3
      // car must be leader
      (C.size() >= 3)    && S.isLeader(@leader),
      // second car must be one where a split can occur
      follower != leader && S.validSplit(@follower))
        //Create a connector on each pair
        new Splitstep(leader, follower)
  // Simple rule to add a car to a platoon
  // if it has less than 10 cars
  rule modifying addCar() when(C.size() < 10)
    car  = new CAR()  // Create component
    node = S.create() // Create map location
    // Add
    (CAR FROM C).insert(car) // managed
    S.insert(node)                     // map
    @.bind(car, node)             // addressing

// Executable DR-BIP System

An executable DR-BIP system is a single executable which when launched simulates the execution of the system described by the model. The execution alternates between the BIP execution engine which executes an instatiated BIP model according to the BIP2 language semantics, and the reconfiguration engine which updates motifs and executes reconfiguration rules to modify the instantiated BIP model. The instantiated BIP model is shared between the two engines (conceptually) and consists of instances of components, connectors, and interrupt conditions.

Reconfiguration Engine

The reconfiguration engine is tasked with executing reconfiguration rules, updating motifs, and updating when to stop for the next reconfiguration cycle.

Rules that modify motifs are executed first until stabilization, followed by rules that generate connectors. Lastly, interrupt conditions are updated to account for the dynamic change in the system.

After changing the instantiated BIP model, the reconfiguration engine yields to the BIP engine to execute the new instantiated BIP model.

BIP Engine

The BIP engine is tasked with executing an instantiated BIP model according to the BIP2 language semantics.

The BIP engines first evaluates interrupt conditions to determine if it needs to suspend its' execution. If no condition holds, it computes possible interactions between the components. If an interaction is possible, it executes it and re-starts the cycle. If no interaction is possible, then the entire execution halts.

When at least one interrupt condition holds, it suspends execution yielding to the reconfiguration engine.

// Code Generation

The DR-BIP compilation process takes as input the described system in BIP and the DR-BIP language, generating C++ code of the DR-BIP reconfigurable system. The code can then be compiled using a C++ compiler with different flags for simulation, tracing and profiling.

BIP Compilation

The BIP compiler reads the BIP model described in the .bip file using the BIP2 language. It generates C++ code of type information for components and connectors, and the BIP execution engine which executes BIP models according to the language semantics.

The BIP compiler has been modified to introduce interrupt conditions that stops the engine from executing when at least one holds. Furthermore, the code has been modified to work on a dynamic number of components and connector instances since the system evolves as it executes.

Reconfiguration Layer Compilation

Motifs and Reconfiguration Rules are compiled by the Reconfiguration Compiler which generates C++ code containing all the data-structures for motifs and rules.

It also generates the necessary code for the reconfiguration engine to determine which rules can be executed and on which components or motifs, and the code to execute their reconfiguration actions.

// Tracing

Raw Trace

An executable DR-BIP system outputs raw information while executing:

  1. Creation, deletion of instances of components and motifs
  2. Execution of reconfiguration rules
  3. Execution of interactions by the BIP engine

The raw trace is suitable for streaming information as the system executes.

<TRACE> <BIP> snapshot component CAR_0_11 { _m__pos:23.4,_m__v:0.2,_m__minSteps:8 }
<TRACE> <DRBIP> apply Global SplitPlatoonsIMR_0_0 with Platoon_0_0 CAR_0_8
<TRACE> <DRBIP> spawn motif Platoon_1_1
<TRACE> <DRBIP> spawn motif Platoon_1_2
<TRACE> <DRBIP> spawn motif Merger_1_0
<TRACE> <DRBIP> despawn motif Platoon_0_0
<TRACE> <DRBIP> apply CR SplitIR_1_1 in Platoon_1_1 with CAR_0_0 CAR_0_2
<TRACE> <DRBIP> spawn interaction Splitstep_1_9 CAR_0_0 CAR_0_2
<TRACE> <BIP> interaction Speedupdate_1_1
  "steps": 562
, "switches" [
   { "start": 119, "end" : 129, "type" : "DRBIP",
    "snapshot": { "motifs": [
       { "motif" : "Platoon_1_1",
         "comps" : [ "CAR_0_5", "CAR_0_4", "CAR_0_3", "CAR_0_2", "CAR_0_7", "CAR_0_6", "CAR_0_1", "CAR_0_0" ]}
    , //..
   ], "components" : [
    { "component" : "CAR_0_5", "state" : { "_m__pos" : 29.4, "_m__v" : 0.2, "_m__minSteps" : 33 }}
 , "sequence" [
   {"name" : "SplitPlatoonsIMR_0_0"}
 , {"name" : "SplitIR_1_9", "motif" : "Platoon_1_1", "interaction" : {"name" : "Splitstep_1_9", "comps" : [[ "CAR_0_0" ], [ "CAR_0_2" ]] }}

Structured Trace

The DR-BIP framework provides tools to process raw traces.

A simple library allows traces to be read and manipulated for Java applications.

It is possible to read raw traces and output structured JSON traces.

// Analysis & Profiling

Trace Viewer

DR-BIP Trace Viewer is a web tool for visualizing the JSON traces obtained after executing a DR-BIP system.

You can even try it out online on a set of example traces.

01.To have a more in-depth look at the execution. It is possible to view logical sequences of executed rules and interactions. Observing patterns of rule executions helps understand more how the reconfiguration rules impact the system's behavior.

.02 Sequence view makes it possible to inspect the configuration for each motif instance at a given point of the execution. It also shows the connectors created by the rules.

03.Combine infomation found in configurations, motifs, and the state of a component to have a richer view of the system at a given moment in its' execution. Compute scores to summarize the combined information.

.04 The evolution of scores is tracked as the system evolves.

Quantitative properties can combine scores to express a desirable behavior of the system, seeing if the dynamic and reconfigurable behavior converges towards the desirable configuration.

Execution Profiling

It is possible to compile the DR-BIP model with a performance mode flag. This disables tracing and any additional printing overheads, and executes a benchmark of the model.

At the end of the execution, it displays performance counters that can be used to study the behavior of the simulated model.

For example, it is possible to detect if the current reconfiguration rules cause the model to spend more time reconfiguring than executing.

bip-time: 1.082438 sec
drbip-time: 1.18545 sec
total-time: 2.55910 sec
bip-interactions: 89999
drbip-phases: 3035
drbip-globalrules: 3034
drbip-localmodifying: 0
drbip-localconnecting: 147263
drbip-create-comps: 50
drbip-destroy-comps: 0
drbip-create-motifs: 4553
drbip-destroy-motifs: 4551
// Verification

Verification of Configurations

It is still cooking. This is the focus of our current work on the tool. We have good results so far, and we are finalizing pushing the verification approach.

Related Papers

A Layered Implementation of DR-BIP Supporting Run-Time Monitoring and Analysis

Antoine El-Hokayem, Saddek Bensalem, Marius Bozga, Joseph Sifakis

SEFM 2020. To appear.


Four Exercises in Programming Dynamic Reconfigurable Systems: Methodology and Solution in DR-BIP.

Rim El Ballouli, Saddek Bensalem, Marius Bozga, Joseph Sifakis

ISoLA 2018: 304-320

Programming Dynamic Reconfigurable Systems.

Rim El Ballouli, Saddek Bensalem, Marius Bozga, Joseph Sifakis

FACS 2018: 118-136

© Antoine El-Hokayem 2020 // All rights reserved.
Get in Touch