Dynamic Reconfigurable BIP
Modeling, simulating and verifying dynamic reconfigrable systems
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.
- Languages : Java/C++
- Demo Repo : Platoon System
- Lab : Verimag | RSD
Architectural Motifs
Motifs act as blueprints to describe the dynamic architecture.
They are dynamic structures composed of:
- A set of managed components
- A Map describing an abstract view of positions/roles
- 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:
- Modify motifs: components, maps and addressing functions
- Modify connectors: changing how components are connected
- 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.
Configurations
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.
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++.
Imports
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:
- BIP Package Name - model
Import components and connector types from the .bip file - 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. - 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. - 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 {
//Getters
const bool isLeader(Node)
const bool isTail(Node)
const bool validSplit(Node)
//Setters
void merge(PlatoonMap)
/* More functions */
}
addressing PlatoonAddressing { /* ... */ }
}// Declare motif Platoon
motif Platoon<PlatoonMap, PlatoonAddressing> {
/*
Add rules that affect each
Platoon instance independently
*/
}
Motifs
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:
- 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.
- 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. - Reconfiguration Actions
Rules define a sequence of reconfiguration actions that modify the motifs and the configuration. Actions can:- Modify Elements
Create or delete instances of components or motifs. - 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.
- Connect Components
Create connectors on components.
- Modify Elements
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
}
}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.
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.
Raw Trace
An executable DR-BIP system outputs raw information while executing:
- Creation, deletion of instances of components and motifs
- Execution of reconfiguration rules
- 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.
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: 4551Verification 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
SEFM 2020. To appear.
PDF