Input and output p. The first time the plan algorithm is run, p will be empty. It will be populated with either a sequence of actions that is known to be effective in increasing the system’s state utility (namely, a plan from the bank) or, if no such sequence exists for the given initial utility, with a randomly selected action from the actions set.
Input planBank. Initially, the plan bank is also empty. After executing the plan algorithm in a loop, the current plan p will be saved in the bank, if the utility of the system state reached after executing the sequence of actions in p is higher than the initial utility u. Relative to the running example, a plan will be saved in the bank if it drives the system to a state with a utility greater than 5.
5.3
Implementation Scenario
One step of the generic KAS methodology in Table 4.5 is illustrated on the running example used throughout this chapter. This will show how the KAS architecture can be instantiated and run in the SAR problem domain by following the algorithm logic in 4.4. The process is captured by the flow diagram in Fig. 5.10.
5.3.1 Setup and ontology learning
Policy formulation. KAS deployment in the SAR problem domain starts with defining state utilities, candidate plan actions and heuristics, a task performed by the domain expert. System states
createPolicy KT monitor analyse plan execute null, false, thresholds
u, actions o p policy reasoner planBank
Fig. 5.10:The KAS methodology instantiated in the SAR problem domain - the architecture tools are displayed in the centre and connected via linear arrows to show the sequence in which they are executed; the tools’ inputs and outputs are displayed on either side and connected via block arrows
are combinations of value ranges applicable to monitored inputs (audience focus and battery charge level), whereas plan actions are generated with respect to the controlled (output) parameters (font size and display brightness). Heuristics capitalise on the expert’s previous knowledge and can be viewed as known good strategies to apply in order to drive the system into a state with a utility higher than the current one. The recommended complete layout of the SAR policy document is available in Tables 5.2 (utilities), 5.3 (actions) and 5.4 (heuristics).
Creation of the initial ontology. Since SAR is a domain with continuous monitored inputs, no legacy description (input file) is necessary. The KT algorithm will create the Entity hierarchy via discretisation (as explained in 5.2.1), hence the first input parameter (inputFile) will be null and the second (isDiscrete) will be false. The third KT input, thresholds, containing the values used for discretisation, is prescribed by the application developer (an example is provided in Table 5.1). The initial ontology produced by KT and illustrated in Fig. 5.3 is an instance of Onto++ from the general KAS architecture (Fig. 4.1), in that all Onto++ concept hierarchies are present in the SAR ontology, save Link, since this problem domain can be modelled without multi-faceted properties. Note the role of the reasoner during the discretisation process, as illustrated in 5.2.2.
5.3.2 Monitoring and analysis
Input processing. In the SAR application domain, KAS processes three inputs during the monitoring phase: the time of day and the battery levels are read from the computer (that the presentation is running on) clock and power manager, respectively, whereas the data representing the area of exposed eye (averaged over the entire audience) is simulated. At 10 am on a November day, with 30% battery charge and an average exposed eye area of 45%, the monitor will assert three concepts in the ontology, CurrentTime (Fig. 5.7), CurrentFocus and CurrentBattery (Fig. 5.8). After the monitor phase, the ontology in Fig. 5.3 is enriched with the three concepts above, each subsumed by the reasoner as shown in Fig. 5.6. Additionally, the reasoner implicitly validates sensor data as explained in 5.2.2.
Analysis. Given the inferred super-classes for the three concepts asserted in the ontology during monitoring, the analysis module will identify the current state of the system as State17 (Fig. 5.9). The associated utility will be returned for the use of the planner. Since there are no heuristics in the policy
document adivising which actions to avoid early in the morning, when the audience focus and battery level are both in the medium range, the analyser will return the full set of candidate actions (Table 5.3) to be considered during planning.
5.3.3 Planning
Let us assume that a plan may be, at most, three actions long (L = 3) and illustrate the planning loop from the general KAS methodology (Table 4.5, lines 11 - 16) on the running example.
Iteration 1. The utility of State17 (medium focus and medium battery level) is 5, thus lower than that of the goal state (Table 5.2 shows that the maximum utility, 9, is associated to high focus and high battery level). Since the plan bank is initially empty, an action will be selected from the available set in Table 5.3: let us assume that is a2 (increase font and maintain brightness). Let us also assume that executing action a2 will successfully increase audince focus. Hence, the values of the input signals detected by the monitor are 10 am for time, 30% for battery level and, say, 70% for exposed eye surface, corresponding to concepts EarlyMorning, HighFocus, MediumBattery. The associated system state determined by the analyser is State29 with utility 8 and no policy heuristics referring to it.
Iteration 2. Since State29 does not coincide with the goal one, the algorithm continues by selecting another action from Table 5.3, for instance a4. Assuming that maintaining the font size and increasing the display brightness has no impact on audience focus but lowers the battery charge level to 20%, the concepts asserted during monitoring will be subsumed under EarlyMorning, HighFocus and LowBattery, respectively. During analysis, the system state is found to be State25, with utility 7 and referred to by the second heuristic (Table 5.4). Consequently, the set of candidate plan actions is reduced to {a2, a3, a5, a6}.
Iteration 3. The goal state utility has still not been reached, therefore another action (for example, a6) is selected from the set of candidates produced during analysis. The font size is maintained whereas the appropriate effector will decrease screen brightness, leading to no change (relative to the previous iteration) in the three monitored inputs. The analyse stage will preserve State25 with utility 7 as the current system state, apply the second policy heuristic and return the same set of candidate plan actions as before. However, the fourth iteration will not take place since the maximum allowed number of plan actions (L = 3) has been reached.
5.3.4 Maintaining the plan bank
The final utility achieved by executing the previously constructed plan is 7, a higher value than the utility of the initial State17, namely 5. This validates the condition on line 18 in the general KAS methodlogy (Table 4.5) and leads to plan {a2, a4, a6} being included in the plan bank.
5.3.5 Self-management support
The KAS implementation in the SAR domain supports the realisation of the four self-management properties [101].
• Self-optimisation. The autonomic system’s behaviour is optimised with regards to the managed resource (the document rendering media, namely, the computer monitor and the software document
manager, for example Adobe Acrobat Pro) and the autonomic control element alike. The former optimisation aspect entails adjusting document font sizes and screen brightness to account for the time of day, battery level and audience focus. The latter type of optimisation stems from the inner logic of the planning algorithm (4.3.5), where sequences of actions that have previously been successful at increasing the utility of the system state are stored in a bank and re-utilised as necessary. In other words, the MAPE-K loop exploits its own past experience, thus this facet of optimisation may also be labelled self-learning.
• Self-protection. In its current implementation, the KAS instance deployed in the SAR context is exposed to sensor malfunction. Should there be any data corruption with monitored input, for instance, a reported time of the day outside of the 0 – 24 range, a battery level grater than 100 or an average exposed eye area in the negative domain, the reasoner would reject the corresponding ontology entries as shown in section 5.2.2. The autonomic element protects against its own algorithmic pitfalls: if the random action selection process used to dynamically build a candidate plan fails to reach the goal state in a reasonable number of iterations, the perceivable lag in the system’s response would be unacceptable. To prevent that, there is a programmable limit in place (Table 4.5, line 11) to restrict the maximum plan length to a sensible value.
• Self-healing. The system is not currently equipped to handle environmental hardware issues. The future development agenda includes support for healing strategies such as switching to an alternate display when the lead monitor is malfunctioning and adjusting the other light sources in the room (close/open the blinds, dim the ceiling lights, etc.) when the main monitor’s brightness controls are not responsive. This would require a more integrated control set-up (an actual “smart environment”) than the one simulated here.
• Self-configuration. This property is relevant when the managed resource is a network (comprises several, linked components). In the SAR domain, the KAS compliant autonomic manager could be used to control several monitors in the presentation room and configure those independently. In one of the possible scenarios, where the room’s energy consumption needs to be reduced while the detected level of audience focus is low, the autonomic manager would configure the array of room monitors by dimming/switching off the side ones, while increasing the brightness of the frontal display only.