7. Prototype Implementation
7.4. Implementation of the Adaptation Logic Manager
7.4.2. Adaptation Logic Manager: Planning Modules
In the following, this section describes the implementation of three planning modules used for self-improvement in the SmartHighway system [223]. These modules have been further standardized. They offer (i) dynamic parametric self- improvement through rule learning, (ii) structural self-improvement based on a fixed rule set, and (iii) dynamic model-based structural self-improvement. For all three approaches, this section highlights the generic reusable parts and the parts that require customization. Alternatively, it is possible to use related work, e.g., the strategies for meta-adaptation presented in [149], the mechanism for generating adaptation paths to achieve the desired target system configuration from [304], or one of the other approaches analyzed in Section 4.3.
7.4.2.1. Parametric Self-improvement
The first module offers continuous meta-adaptation of the adaptation logic’s Event-Condition-Action (ECA) rule set. Such a rule consists of events speci- fied by a set of conditions and a set of corresponding actions for adapting the managed resources. These actions are applied if the conditions are met by the managed resources or the environment variables. Having found a matching rule, the planner returns the corresponding action(s).
Rule Evaluator
Request
Candidate
rules
Rule Learner
Utility Function
Best
rule
New
rule
Rule
Adapter
Rule
Generator
Simulation
Figure 7.15.: The module for learning rules generates and evaluates new rules. If the rule learner finds an optimized rule, the module for parametric self-improvement adapts the rule set in the adaptation logic.
The ALM is able to change the adaptation logic’s rule set, i.e., adding, remov- ing, or updating rules. Figure 7.15 presents the module for rule learning. The
7.4. Implementation of the Adaptation Logic Manager
learning module integrates a simulation of the managed resources. The simula- tion is constantly started with new parameter combinations that represent the properties of managed resources and rules for adaptation. The module uses the simulations to retrieve the reaction of the managed resources to the adaptation specified by the rules. As a next step, a utility function is applied to the col- lected data of the simulation runs. The function assigns a utility value to each simulation run, i.e., to each combination of condition and action of a rule candi- date. Then, the module analyzes which rule is the best for a specific situation by comparing the utility values of the runs.
1 public ALMData changeRulebase(ALMData request) { 2
3 if (request.getPropertyValue("action").equals(ALMProperty.
ADD_RULE)) {
4 addRule(request.getPropertyValue("element"), request.
getPropertyValue("rule"));
5 }else if (request.getPropertyValue("action").equals(ALMProperty.
REMOVE_RULE)) {
6 removeRule(request.getPropertyValue("element"), request.
getPropertyValue("rule"));
7 }else {
8 return new ALMData(ALMMsgType.ERR, ALMCommand.LOG);
9 }
10
11 return new ALMData(ALMMsgType.RESP, ALMCommand.RUL);
12 }
13
14 private void addRule(String ALObject, String rule) {
15 [...] // code removed
16 }
17
18 private void removeRule(String ALObject, String rule) {
19 [...] // code removed
20 }
Listing 7.8: Implementation of the method for rule meta-adaptation in the Proxy ALM.
The ALM Planner triggers an update of the rules in the adaptation logic. The FESAS Framework integrates a mechanism for exchanging rules. Listing 7.8
7.4. Implementation of the Adaptation Logic Manager
provides the implementation of this mechanism in the Proxy ALM. The ALM uses this mechanism for modifying the rule set. It is possible to use other frameworks for the adaptation logic if they offer a rule change mechanism.
The simulator and the utility function are application-specific. Through mod- ularization, it is possible to exchange the simulator and the utility function. Consequently, the mechanisms for learning can be reused by integrating another simulator and defining the relevant parameters for learning and the utility func- tion. This allows to customize the learning module for a specific application.
In [223], we presented a rule learner for the SmartHighway scenario. This learning module calculates the speed limit for a specified traffic flow using the
SUMO traffic simulation18. As learning parameter, different speed limits for a
specific traffic flow are applied. The module uses the following utility function for finding the best rule for a traffic situation:
UHighway := α −
β ∗Xwait +XlostTime (7.4.2.1)
P
wait is the accumulated number of simulation steps where the speed of a
vehicle was below 0.1 m/s,P
lostTime is the accumulated number of seconds that each vehicle lost due to driving below its target speed. These values are logged by the SUMO simulation for every vehicle. Simulation runs with different weighting factor β lead to a weighting factor of 7 for a balanced utility function. However, for having a correlation between a large result and a high utility, the function subtracts the sum of the two parts from a constant factor α. Simulation runs showed that the sum does not exceed 1,000 for the track used in the simulation, therefore, we chose 1,000 for the factor α. It may vary for other tracks. The module then uses the result with the highest utility and constructs a new rule consisting of the average flow per lane as the condition and the calculated speed limit as the action. Listing 7.9 shows an example for such a rule. This rule states that if the amount of vehicles exceeds 600 vehicles/hour the speed limit is set to 100 km/h (33.33 m/s). Section 8.3.2 presents the evaluation of the module.
18SUMO’s website: http://www.dlr.de/ts/sumo/en/
7.4. Implementation of the Adaptation Logic Manager
1 <rules>
2 <condition>
3 <entry>
4 <key>flow</key>
5 <value>600.0</value>
6 </entry> 7 </condition>
8 <action>
9 <entry>
10 <key>speedLimit</key>
11 <value>33.333</value>
12 </entry> 13 </action>
14 <attributes />
15 </rules>
Listing 7.9: An example for a rule in the SmartHighway scenario from [223].
7.4.2.2. Structural Self-improvement
The structure of the adaptation logic and the managed resources can be mod- eled as a graph, i.e., changes in the adaptation logic and managed resources are reflected as changes in the graph. We implemented two graph-based modules for structural self-improvement. Both modules integrate a graph-based representa- tion of the SAS structure with rule-based and model-based planning for structural self-improvement. They specify when to switch the coordination pattern of the adaptation logic as shown in Figure 7.16. There, the approaches have triggered a switch from a fully decentralized non-coordinated setting to a hybrid Mas- ter/Slave pattern (cf. [401]). Next, this section presents a graph-based structural self-improvement approach using a static rule set and the Topology Adaptation Rule Language (TARL) [345]. Afterwards, this section introduces a variant using a dynamic rule set implemented with the Neo4j graph database.
The TARL Module
TARL [345] offers a general topology adaptation model. A TARL rule consists of a condition specification and an execution specification. The condition contains (potentially multiple) graph patterns and matches those on the input graph. The
7.4. Implementation of the Adaptation Logic Manager
corresponding execution statement specifies the changes to the input graph. If a condition matches, the corresponding execution statement is triggered. Contrary to the dynamic rule learner, for structural meta-adaptation of the adaptation logic, the current state of the adaptation logic (e.g., its distribution) is relevant. Therefore, TARL registers as an observer for the FESASGraph to receive updates when the adaptation logic changes. TARL compares the graph with the pat- terns that are defined in the TARL rules. The patterns integrate the current or predicted traffic situation. If TARL finds corresponding patterns, it returns the associated execution parts of the matching rules. The execution statements contain adaptation actions. The functionality of the module is generically usable and, hence, can be used in different applications. However, developers have to ad- just the module by specifying patterns and writing corresponding TARL rules. A listing showing the implementation can be found in Appendix C.3. Appendix C.4 provides an example of a TARL rule from the SmartHighway system [223].
The Neo4j Module
We implemented a second module for structural improvement using the
Neo4j19 graph database (called Neo4j module in the following). When the ALM
Planner triggers the Neo4j module, the module generates queries for the Neo4j graph database using pre-defined but customizable rule templates. The Neo4j module registers as observer at the FESASGraph, hence, it gets informed about the current structure of adaptation logic and uses the information of the FESASGraph, the data captured from the managed resources as well as the predicted data of the ALM analyzer to build up the query. These queries change the graph of the adaptation logic structure stored in the Neo4j graph database. The Neo4j module
19Neo4j website: https://neo4j.com/
Figure 7.16.: The figure shows structural self-improvement of a distributed adap- tation logic. The distribution pattern switches from a fully decen- tralized pattern to a hybrid Master/Slave pattern.