Upload
trinhque
View
230
Download
0
Embed Size (px)
Citation preview
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 3/XX
SoMware Engineering of CPS
A soluMon based on So^ware Components
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 4/XX
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 5/XX
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 6/XX
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 7/XX
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 8/XX
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems
DEECo – new case study
12
Firefighters TacMcal Decision System
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 14
Problems & Challenges
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 15
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 16
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 17
Physical world constraint: PASS is aJached to SCBA
18
Driving self-‐adaptaMon with IRM-‐SA
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 19
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 20
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 21
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.
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 22
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*
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems
IRM-‐Self-‐Adap=vity
*so that the system’s operaMon degrades gradually in a controlled manner
Strategy #1
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 24
• 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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 25
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 26
(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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems
IRM-‐Self-‐Adap=vity
Decentralizing configura=on selec=on
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 28
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 29
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
Ilias Gerostathopoulos, D3S Seminar, 06/11/2013 Designing for adapta/on in DEECo-‐based systems 30