designing for adaptation in deeco-based...

CHARLES UNIVERSITY IN PRAGUE

http://d3s.mff.cuni.cz

faculty of mathematics and physics

Designing for adaptation in DEECo-based systems

Ilias Gerostathopoulos [email protected]

Component Group Jaroslav Keznikl

Michal Kit Dr. Tomas Bures

Dr. Petr Hnetynka Prof. Frantisek Plasil

This presenta=on is based on

Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 2/XX

Bures, T., Gerostathopoulos, I., Hnetynka, P., Keznikl, J., Kit, M., Plasil, F. and Plouzeau, N. 2014. Adapta=on in Cyber-‐Physical Systems: from System Goals to Architecture Configura=ons. SubmiJed to ICSE ’14.

Previous Case Study

SoluMon

Problem

Implem. level

soluMon

Recall

Context Dependable & adaptable Cyber-‐Physical Systems

Design of DEECo-‐based systems is challenging (dynamic architecture, scale)

•  classic requirements-‐driven approaches do not suffice

Dependable Emergent Ensembles of Components •  components: units of deployment and execuMon •  ensembles: interacMon templates

Invariant Refinement Method •  start with high level goals •  end with component processes and ensembles

Intelligent navigaMon of electric vehicles


SoMware Engineering of CPS

A soluMon based on So^ware Components


Engineering RDS via SoMware Components

à Integrates ideas & concepts from different areas à Provides abstracMons for engineering CPS à Brings separaMon of concerns to the extreme

DEECo: Distributed Emergent Ensembles of Components

Component-based engineering (software engineering concepts)

Agent-oriented Computing(autonomy)

Control system engineering(operational normalcy)

Ensemble-oriented systems(attribute-based communication)

DEECo


DEECo model – Component Components are strictly autonomous units featuring cyclic periodic execuMon.

Component

Process C Process D Process A

Process B1 Process B2

Component

Component Component Component


DEECo model – Ensemble Ensembles are (stateless) interac=on templates that describe a) When to communicate b) What to communicate

Component

Component Component Component

Component

Membership condiMon holds

Coordinator

Member

Member

implicit knowledge exchange


DEECo – implementa=on level

jDEECo: container and runMme framework for DEECo components and ensembles that are wriJen in internal Java DSL. Available on Github: hJps://github.com/d3scomp/JDEECo


Currently: Refactoring of jDEECo core Why? •  To decouple implementaMon parts à extensible •  To introduce (Ecore) models@runMme •  To support deployment in real hardware (MANETs)

DEECo – design level

9

Invariant Refinement Method

Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems

Invariant

10

Opera.onal normalcy: the property of being within the limits of normal operaMon

Invariant: condiMon on the knowledge valuaMon of a set of components that captures the operaMonal normalcy to be maintained by the system-‐ to-‐be

The valuaMon of the components’ knowledge evolves as a result of their autonomous behavior and of knowledge exchange


Invariant Refinement Method

11

System Level

Ensemble Level

Component Level

Implementation

Refinement step

Idea: IteraMvely refine and concreMze invariants at the system level up to the point where they can be mapped to: •  Component processes (process invariants) •  Knowledge exchange (exchange invariants)

Components specificaMon

Ensembles specificaMon

Process invariants

Exchange invariants


DEECo – new case study

12

Firefighters TacMcal Decision System


AbstractThe Firefighter tactical decision system is a real-life, real-scale application thatserves as a large case study for evaluation results on distributed adaptiveapplications.

The specifications of this use case are tailored to generate interesting researchand development problems on the following domains:

dynamically & self evolving clouds of sensor/computation nodes;

validation of continuously evolving architectures with respect tospecifications (services offered, deployment constraints,…).

Introduction

Firefighters on a call need efficient sharing of real time information on thesituation and the ongoing and planned actions. The French firefighters areusing tactical guide rules known globally under the name MRT (TacticalReasoning Method). These rules include information representation standards,command structure organization, problem solving patterns, communicationorganization.

Commanding officers currently use white boards and wipeable markers to drawa graphical model of the situation at a given time, define the position and tasksof engines and more globally keep records of items of attention, messages tohigher command, and so on.

Nota bene

The descriptions below are simplification of reality. Many “all x are such andsuch” are approximations, as unfrequent cases are not mentioned, for sake ofbrevity.

Overall organization of french firefighters

In France firefighters are organized as a group of SDIS (Service départementald’incendie et de secours). Each SDIS has its own vehicles and personnel. Themain operational structures are:

the CODIS (Centre opérationnel départemental d’incendie et de secours),which is an organizational structure that supervises actions and resourcesduring emergency situations;

the set of CIS (Centre d’incendie et de secours), which hosts engines andpeople to man these engines.

Inside the CODIS, phone calls from the public are received by internal callcenters. A call center has a specific emergency information system. All callsand all data regarding call management is stored in this system. In thisdocument we will call this system the EIS. The EIS is managed by operators,under the supervision of a commanding officer.

The EIS

The Emergency Information System (EIS) is connected to the phone network,to receive calls and call exterior agencies.

Definition of MRT

The MRT is the official tactical reasoning technique, as defined at a nationallevel in France for all firefighter leaders. The MRT includes :

1. a specific graphical notation to draw the situation on boards;

2. pre-formatted tables to account for engines, personnel and messages;

3. patterns of reasoning, such as the SOIEC.

SOIEC definition

SOIEC is an acronym to help commanders in structuring their tactical reasoningwhen facing an emergency:

S for Situation: what are the risks (ie sources of danger, vectors ofdangers, targets of danger);

O for Objectives: sorting risks, from the most important to the leastimportant;

I for _Ideas: general technique to suppress or reduce the risks, byselecting patterns of risk control;

E for Execution: distribution of the roles from the pattern set selected atthe previous step;

C for Command: definition of the command structure, recall of specificsecurity rules.

Graphical tools

The MRT relies on a graphical notation to draw plans of the situation, of theaction currently performed or planned. The graphical convention is based onspecific shapes (e.g. rectangles, arrows), on colors (e.g. red for fire-relatedinformation, green for person related information, blue for water-relatedinformation, etc).

Resource table

At all times a table contains the following information on the engine situation.For each engine involved in a call, there is information on:

time of requesting;

time of dispatch;

time of arrival;

current work assignment (including standby at the engine pool);

time of dismissal.

Agetac

The Agetac system is meant to replace paper and whiteboard as much aspossible. Agetac means Aide à la Gestion Tactique (Tactical managementassistance). Agetac is currently made of several subsystems:

Electronic boards

The first Agetac subsystem is centered around a multi-user shared board,running on Android tablets; the tablet communication is managed in a clientserver fashion at the moment, but a peer-to-peer implementation is beingdesigned; the underlying framework named DAUM supports self adaptivecomponent based applications.

DAUM itself relies on the Kevoree component model. Kevoree is designed torun on an extremely wide range of execution platforms, from very lost cost, lowpower microcontrollers (eg Arduino), up to large scale high power cloudplatform (eg Amazon EC).

Tools for tactical reasoning

In the current system the group leader relies on the following tools:

a white board with specific sections;

a radio to send and receive voice messages to and from the commandcenter.

The command center acts as a supervisory entity: at all times the centralcommand keeps its own model of the situation, in order to double check thatproper actions are being taken either on the field or at the central commandsite. Moreover, the central command is responsible for communicating andinforming civil authorities, the police command center and the medicalcommand center. This shows that accuracy and sharing of real time informationis a key point in this system.

The Agetac system aims at improving the safety and the efficiency of thetactical model management, for the commanding officer on the field and for theofficers at the command center.

In the Agetac system, the group leader uses the tablet to setup the initial SITAC(tactical situation), using layers of maps and symbols. The layers are thefollowing ones:

a map layer, which provides background information;

a point of interests layer, which provides static information specific tofirefighters (e.g. hydrants, main power switches);

a layer that contains specific symbols for call specific items (e.g. positionof engines, position of regroupment location);

a layer that contains symbols stating the position and kind of dangersources and danger targets;

a layer that contains symbols for ongoing and planned actions (firesuppression, protection, evacuation, etc).

sitac_19_04_2012.png

Pervasive sensors networks

A second subsystem is centered on a network of sensors connected wirelessly.These sensors are connected to low power nodes, which are integrated into thepersonal protective equipment of firefighters. The sensor network aims atenhancing safety and efficiency of the team:

Safety enhancement

In the protecting equipment, individual nodes are configured in real timedepending on the task assigned to the equipment bearer. For instance, in thecase of a building fire, the node is monitoring external temperature closely, inorder to detect hot gases overhead. Movements are also recorded, andwarning signals can be triggered when the firefighter is not moving or is lying onthe ground. As GPS is usually unavailable within a construction, itscorresponding software component is configured to send a signal when theGPS signal is lost and available again. This helps in detecting entry and exit ofa building.

In the case of a vegetation fire, the node is sending its position using a GPS.The external temperature is monitored only to adjust the threshold of bodyoverheat warning. Also, the self contained breathing apparatus (SCBA)monitoring is off, because vegetation fires are managed without SCBAs.

Efficiency enhancement

Since the sensors are all conected to the on site wireless network, the tacticaldecision system can use these to get continuous update of information onvarious parameters, e.g.:

heat levels in a building at various locations, to annotate the dynamic mapof the situation;

personnel dissemination on the ground (for vegetation fires) orinside/outside a building.

Sensor nodes are interconnected with various wireless technologies, e.g.Bluetooth, Wifi or Xbee.

Scenario #1

Remarks

In the following scenario we assume that engine leaders do not have apersonal tablet available. If all leaders have a tablet than the system is moreefficient but more expensive.

A typical call

To provide a concrete situation, we will assume in this example that the incidentdetails are as follows.

On a Sunday afternoon

On a sunny winter Sunday, around 14:00, Mr Smith, living in a house at 10,Setting Sun Street, in the rural town of Manyfarms, notices that some smokeoutside. It seems to be coming from the neighbour’s home, at #12. M. Smithgoes and check what is going on, and he can see that smoke is indeed comingfrom under the #12’s roof. Peeking into the neighbor’s living room, he noticesmore smoke and orange flames inside. M. Smith then dials 112 on hiscellphone. The call is routed to the regional EIS, and after a few seconds anoperator answers.

Operator: this is the fire department, we are listening. Mr Smith: The house of my neighbor is on fire! Operator: Do you see smoke? flames? Mr Smith: Yes, smoke and flame can be seen in the living room. Operator: What is the neighbor's address? Mr Smith: 12, Setting Sun Street, Anytown. Operator: and what is your name? Mr Smith: Mr Smith.

The operator enters this data in the emergency information system, andchooses a code that describes the general kind of problem, in this case: housefire. The code implies a basic detachment type. In the case of a house fire, thebasic detachment is made of two pumpers, one aerial ladder, one group leader.

Engine selection

Using information such detachment type and address of the call, the EISselects engines that are currently available and that can be manned with properpersonnel. The engines are generally from the fire stations closest to theproblem, but engine availability and personnel availability might require the useof engines from other stations. The EIS assigns personnel to roles within theengines. Once the engines have been selected, the operator validates the call.The EIS notifies the personnel through various means, such as individualpagers or mobile phones. At the same time, a document is printed on a specificworkstation in each of the fire stations involved.

Information sent to the personnel

The following information is made available to the personnel:

address of the call;

category of problem;

description of problem, as entered by the operator during the phone call;

list of engines, and for each engine:

fire station,

personnel in the engine;

specific indications stored in the EIS for the kind of call and/or location.

Initial call management

to be done

Arrival of first engine on site

Since the engines come from several stations, they arrive at different moments.The first engine on site has command, and the engine leader does an initialassessment of the situation. A first message is sent to the dispatch controlusing a radio. This message contains the following information:

confirmation or correction of address;

description of risks

sources of danger,

vulnerabilities, etc;

actions that are being performed;

reinforcement needs.

The operator at EIS enters this information into the emergency managementsystem. This information is available to the engines that are en route, especiallyfor the group leader who is going to lead the actions upon arrival. In otherwords, the tactical information is updated for this call. The initial update is doneby the CODIS, as we assume in this document that fire engines are notequipped with tablets. This assumption comes from the current work practice ofengine leaders: they do not write down their tactical analysis results, becauseeither the problem to solve is limited and does not require reinforcements, orbecause they have to act quickly and do concrete actions at once (e.g.evacuating a building, saving people using ladders, etc).

Setup of first SITAC

Upon arrival of the first engine, the engine leader radios the following message:

Command center, this is fire engine #1, arriving at 10, Setting Sun Street, Manyfarms. Active house fire, with heavy fire on the ground floor, I confirm the need for the detachment.

In the current procedure, this message is sent by radio. The en route groupleader can usually hear this message and he/she is waiting for details. In theAgetac system, this information is typed at the command center and stored inthe tactical decision system, both as a text and as an audio record. Thisinformation is therefore immediately available to the other engines, to the groupleader and to the officers at the command center.

The first engine leader asses the situation in more details, takes first decisions,give orders to the engine personnel and then goes back to the engine to radiothe first tactical message (“ambiance message”):

Command center, this is engine #1. We are facing a violent house fire, with two persons missing. I'm conducting a search and rescue operation on the ground floor with a protecting hand line on that floor.

Services provided by the Agetac/DAUM system in thissituation

With the Agetac/DAUM system, all users involved on a given call receive thecall data in real time on a tablet or on a PC. In the context of the ongoingexample, this user set is made of:

the first group leader;

the command center officers;

the company leader on duty for the area.

The information shared is made of the following sets of data (see SectionAgetac):

map of the tactical situation (the current one, as well as history of pastones);

table of engine situation;

table of messages sent/received;

table of persons involved (evacuated, non critically wounded, criticallywounded, deceased, missing);

table of radio channels allocation.

The first group leader knows what resources (engines) have been allocated forthe current call. Using this data and the evaluation of the tasks to be performed,the group leader can ask for more resources. With the traditional system, thegroup leader requests additional resources using a voice message on the radio.With the Agetac/DAUM system, the group leader uses graphical tools to selectand place additional engines either on the tactical map or in the resource table.Such additions are automatically sent as requests to the EIS, where anoperator can allocate resources in reply. In turn, the Agetac application displaysthe resources granted on the group leader’s tactical map and resource table.

Call escalation

The french rules for tactical command management require that a commandingofficer has at most 4 subordinates on the field. In the case of our case study, asthe first group leader has requested 3 more engines, the total expected numberof subordinates will be 7. The EIS automatically notifies the operator that a newcommand level must be activated. In our case study the EIS will activate acompany level officer, with a mobile command post manned by two otherofficers.

In the traditional system, the company officer on duty is either paged by the EISor called by phone. Similarly, two officers must be assigned and paged to helpwith the company command post.

Before arrival

The company officer has some information on the current call, this informationbeing given by voice at the time of the phone call. As the informationtransmitted comes from the information received by the EIS operators, thisinformation is often incomplete or partially wrong.

In the traditional system, the information on site is maintained on white boards.This requires lengthy and error probe copy work. In the Agetac/DAUM system,the company officer has all the group leader information, the current and pastactions and events, thanks to the shared tactical information system on thetablets. In this way, the company officer is aware of the situation at all times,and he/she can follow the evolution of the situation even before his/her arrivalon site.

Upon arrival

The first action of the company officer upon arrival on site is the communicationof the past and current situations, and the tactical decisions taken by the groupleader, using the SOIEC pattern of tactical reasoning. The company officer thenapplies an extended version of the SOIEC pattern, named SAOIECL. Theadded A and L steps stand for Anticipation and Logistics.

Reorganisation

The company officer has to reorganize the tactical structure to deal with anincrease in work load and to improve the overall safety and efficiency.

The reorganization often relies on division into sectors. A division can belocation-based or function-based.

A location-based division defines boundaries on the field to cut this fieldinto geographical sectors (e.g. north side of building, east of the road,etc).

A function-based division defines boundaries by responsibility type (e.g.fire suppression, water supply, medical assistance, air supply, etc).

Each sector is managed by a sector leader (who can subdivise further).

Data edition protocols

Since the tactical data is a multiuser information space, and since the users areworking wirelessly with intermittent connections, data conflicts may occur. TheAgetac system relies on builtin mechanisms to detect concurrent edition of data(e.g. using vector clocks or other causality tracking systems). Because the datais edited asynchronously, some user may perform a write operation on an item(for instance, moving an engine on a map), while another user is reading thisdata to write another data item (for instance, drawing a task arrow from anengine to a point of action for this engine). The causality tracking mechanismallows for detection of such conflicting actions a posteriori. The mechanism isapplied on low level data, i.e. at the inter component communication level.Conflict resolution must be managed by an upper level, usually using businesslevel conflict resolution strategies.

Resolution of conflicts

The users of the Agetac/DAUm system are organized in a hierarchicalstructure. This hierarchy notion provides a first way to manage data editionconflicts. At each level of the hierarchy, operational roles (using duties andmeans) are allocated.

For instance, a group leader is in charge of managing the position of theengines in his/her group. If there are conflicting writes on the position of theengine then the one done by the group leader supercedes the one made bysomeone else, even if this person is higher in the hierarchy of command. Inother words, this role allocation provides a kind of priority.

Ideas for Human Computer Interface

Semantic filtering with a varying zoom level, dimensions.

Define viewpoint sectors, for instance:

COS viewpoint;

medical support viewpoint;

infocom support.

Medical support viewpoint

Using sensors on PPE (personal protective eqipment), the medical personnalcan observe the overall and the individual life sensor values:

heart rate;

body temperature;

carbon monoxyde exposition.

The system presents a semantic map with a classification along values or userdefined functions on these values.

Technical support viewpoint

Team leader’s tablet

Firefighter’s node

•  acceleraMon •  temperature •  posiMon •  oxygen level

Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 13

IRM model of the case study

(3) GL keeps track of the condition of the relevant members

(4) Up-to-date GL::sensorDataList, w.r.t. GM::sensorData, is available

[GM]

(7) GL::sensorDataList - GL’s belief over the GM::sensorData – is up-to-date

X

(6) GM::sensorData is determined

GroupLeader - GL

+ id+ sensorDataList+ GMInDanger

[GL]

(5) GL::GMInDanger is determined from the GL::sensorDataList

P

1[GL]

(9) GM::acceleration is monitored

P

(10) GM::temperature is monitored

P(11) GM::position is

determined

P

[GM]

1[GL]

1[GM] 1[GM]

*[GM]

[GM][GL]

(8) Monitoring equipment is functioning

A

1[GM]

takes-rolerelation

invariant

P

Process invariant

Exchange invariant

X A

Assumption

(1) GL keeps track of the condition of his/her group’s members

GroupMember - GM

+ id+ sensorData+ position+ temperature+ acceleration+ groupLeaderId

(2) GM::groupLeaderId == GL::id

A

[GM] [GL]

[GL][GM]

[GM]

AND-decomposition

component


Problems & Challenges


How to ensure that nodes retain their •  autonomy (conMnuous operaMon in any situaMon) •  autonomicity (keeping system-‐level goals without supervision)?

Many things can go wrong: •  Loss of communicaMon •  Sensor malfuncMoning •  Data inaccuracy •  Unexpected situaMons

More generally, how to design CPS that are self-‐adap=ve, while preserving the dependability aspects (safety, predictability)?

à Extend IRM with self-‐adaptaMon variants!

Extending IRM

(9) Up-to-date GL::sensorDataList, w.r.t. GM::sensorData, is available

(11) GM::sensorData is determined

(10) GL::GMInDanger is determined from the GL::sensorDataList

P

(8) GM::nearbyGMInDanger – GMs’ belief of GL::GMInDanger – is up-to-date

X*[GM]

*[GM]

1[GL]

1[GL]

(12) GL::sensorDataList - GL’s belief over the GM::sensorData – is up-to-date

X

GroupLeader - GL

+ id+ sensorDataList+ GMInDanger

GroupMember - GM

+ id+ groupLeaderId+ sensorData+ position+ temperature+ acceleration+ airLevel+ nearbyGMInDanger

(3) GL keeps track of the condition of the relevant members

(1) GL keeps track of the condition of his/her group’s members

(2) GM::groupLeaderId == GL::id

A

1[GL]

[GM]

[GL]

(6) GL::GMInDanger>1

A

(7) GL::GMInDanger==0

A

(5) No GM in team in danger

(4) Some GM in team in danger

A A

1.  �AlternaMve decomposiMons à alternaMve system realizaMons 2.  AssumpMons capture necessary condiMons for environmental situaMons 3.  Computable assumpMons “drive” the adaptaMon


Extending IRM (11) GM::sensorData is determined

(21) GM::acceleration is monitored

P

13

(22) GM::temperature is monitored scarcely

P

(27) GM indoorsA

(28) GM outdoorsA

2

(14) Nearby GM in danger

A

Subtree for “Search and Rescue” situation

(20) GM::temperature is monitored closely

P

(29) GM::position is determined from indoors tracking system

P

(18) GM::nearbyGMInDanger==1

A

(23) GM::position is determined

(26) GM::airLevel is monitored

P

(25) Breathing apparatus is used

A

(24) Breathing apparatus is not used

A

(37) PASS alert is sounded when needed

1

(38) PASS alert is active

P

requires

2

(19) GM::oxygenLevel is monitored when possible

(13) No life threatA

3

(16) AVG(GM::acceleration)>0 in past 20 sec

A

(15) AVG(GM::acceleration)==0 in past 20 sec

A

(12) GM in critical situation

A

(17) GM::nearbyGMInDanger==0

A

(30) GM::position is determined from GPS

P

takes-rolerelationcomponent OR-

decompositioninvariant

A

Assumption

P

Process invariant

Exchange invariant

X

AND-decomposition

dependencyrelation

potenMally overlapping situaMons

in emergency, temperature is measured more o^en to get more accurate informaMon


Physical world constraint: PASS is aJached to SCBA

18

Driving self-‐adaptaMon with IRM-‐SA


IRM-‐Self-‐Adap=vity

Driving self-‐adapta=on with IRM-‐SA IRM-‐SA graph captures

•  all possible architectural configuraMons •  together with assumpMons of when they are applicable


Determining current situaMon

SelecMng a configuraMon applicable to the current situaMon

Applying the configuraMon within the system

Self-‐Adapta.on loop

1

2 3

1. Determining current situa=on


What to be monitored?

•  Leaf invariants (process and exchange invariants) •  AssumpMons

•  Non-‐leaf invariants

if computable (programmaMcally evaluated)

How to be monitored?

•  AcMve monitoring

•  PredicMve monitoring

•  Implicit determinaMon

Current knowledge of components

Provided predicate History of invariant evaluaMon

Assume saMsfied, if not computable

2. Selec=ng an applicable configura=on s1

s2 s3

s4 s5

s7 s6 s7 s8 s9

s11 s10 s31

s32 s12 s13 s14

s18

s23

s29 s27 s28 s30

s22

s17 s16 s15 s19 s20 s21

s26 s24

s25

d12 d11

d22 d23 d21 d51

d42 d41 d32

d31

1.  IRM graph is translated to a WPMSAT problem 2.  SoluMon captures the best valid configuraMon 3.  Translated back to component modes


1 3 2 2 1

3

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. …

s2∧s3↔ s1d11⊗ d12↔ s3s4∧s7∧s8∧s9↔ d11s5∧s8∧s9↔ d12s10∧s11↔ s8d21⊗ d22⊗ d23↔ s10

s1

s12∧s19∧s20∧s21∧s23↔ d21s13∧s21∧s22∧s23↔ d22s12∧...↔ d23d31⊗ d32↔ s19s24∧s25↔ d31

Hard clauses:

...

1. 2. 3. 4. 5. …

d11= trueSo^ clauses:

d12 = trued21= trued22 = trued23= true

// cost 20 [1*(5*(3+1))] // cost 20 [1*(5*(3+1))]

// cost 15 [3*(1*(4+1))]

// cost 10 [2*(1*(4+1))]

// cost 5 [1*(1*(4+1))]

rank Base value: bj = bj+1 * (nj+1+1)

3. Applying the configura=on in the system

Depends on the mechanisms provided by the execuMon plauorm.


jDEECo: Scheduler can be instrumented by third-‐party enMty

AdaptaMon Manager

SAT solver

Knowledge Repository

Physical Node

jDEECo runMme

Scheduler

Physical Node

jDEECo runMme

Scheduler

Current prototype: SAT4J

23

Dealing with undetermined environment*



*so that the system’s operaMon degrades gradually in a controlled manner

Strategy #1


•  Overlapping alternaMves à fault-‐tolerance

•  Fail-‐safe alternaMve •  Monitoring of higher-‐level invariants à failure observaMon

•  caused by flawed design (missing alternaMves) / hidden assumpMons

Run.me strategy

Strategy #2


We needed to diagnose the adaptaMon problem…

Re-‐design strategy

Hidden assumpMon in decomposiMon!

2) Ip OR-‐decomposed into I1, …, In: (Ip) && (!I1) && … && (!In)

Too strict assumpMons in refinement!

2) Ip OR-‐decomposed into I1, …, In: (!Ip) && (!I1) && … && (!In)

UnanMcipated situaMon! (New alt. needed!)

1) Ip AND-‐decomposed into I1, …, In: (!Ip) && (I1) && … && (In)

Strategy #2


(22) GM outdoorsA

(27) GM::position is determined from GPS

P

(26) GPS not responsiveA

(25) GPS responsiveA

(28) GM::position is determined by nearby GMs

(30) GM::position is estimated based on GM::nearbyFFsPositions and on the search

radius for nearby FFs

P

(29) GM::nearbyFFsPositions – belief of GM over nearby FFs’ positions – is up-to-date

X

(20) GM::position is determined

[GM]

GroupMember - GM

+ id+ sensorData+ position+ temperature+ acceleration+ nearbyGMInDanger+ groupLeaderId+ nearbyFFsPositions

1[GM]

1[GM]

*[FF]1[GM]

Example: the hidden “GPS responsive” assumpMon becomes explicit and drives the adaptaMon

27

Extension points



Decentralizing configura=on selec=on


Single centralized AdaptaMon Manager is problemaMc. x  performance boJleneck x  single point of failure

SoluMon strategy 1)  Associate each invariant with a single component

2)  Spread the invariant valuaMon through ensembles 3)  Perform global configuraMon selecMon locally

4)  Announce the outcome to the other components

5)  When outcome is the same, accept and apply

More elaborate soluMon à Use of distributed SAT/COP algorithms

Relaxing requirements via fuzzy logic


UNSAT à no applicable configuraMon

Idea: Find architectural configuraMon that saMsfies the top-‐level invariant “to the best extent”

›  Invariant acceptability as conMnuous value in [0,1]

›  How to aggregate acceptability levels?

Product fuzzy logic:

Ap = (ap )ap *Πi=1..m (Ai )

ai

Acceptability level of Ip

Aggregate acceptability of Ip

Concavity/convexity of the funcMon

Aggregate acceptability of Ii

Conclusions

✔  Explicit traceability between ✔  high-level goals

✔  assumptions about the environment

✔  available architectural configurations

✔  Mapping of ✔  high-level goals (invariants)

✔  to implementation-level constructs (comp. processes & ensembles)

✔  Supports design of CPS ✔  In-build notion of “striving to achieve” at both design and runtime


designing for adaptation in deeco-based...

Documents