Feedback Loop for Cyber-physical Consistency

In this section we show the application of the MAPE-K-based feedback loop using the Feedback Service to check and restore Cyber-physical Consistency (CPC) [SHHA16] for the smart lighting process step of the Morning Routine scenario process (cf. Sec- tion 2.2.1). The managed elements are the SwitchOnLight process step and the corresponding process resource (cf. Figure 6.1). Additional scenarios and applica- tions of the MAPE-K loop to maintain CPC can be found in Chapter 7.

6.3.1. Knowledge Base

This scenario refers to the specific sensor and actuator models contained in the knowledge base. The involved sensors are light sensors to measure the light lev- els (cf. Figure 4.11) and the actuators are dimmer switches to control the lights (cf. Figure 4.12).

6.3.2. Goal and Objective

The corresponding goal definition written as a Cypher query can be found in List- ing 6.1. The goal “enough light for working” (Line 2) contains the objective “kitchen light > 700 lux in 5 seconds” (Line 4). The corresponding satisfied condition (Line 5) defines light levels in the kitchen above 700 Lux as success criterion. If these levels are not reached within 5 seconds after the execution of the basic process activity, then an error is assumed and a compensation is searched for (Line 6). The context path retrieves the light levels of sensors of type “LightSensor” in room “Kitchen Mueller” (Lines 7–13). The execution of the MAPE-K feedback loops for this scenario is depicted in Figure 6.4.

6.3. Feedback Loop for Cyber-physical Consistency

6.3.3. Deployment and Instantiation

The Process Engine executes the process instance containing the process step of type RESTInvoke in the regular way. It initiates the Service Caller as a client to invoke the specific REST method on the resource (web server) or middleware controlling DimmerSwitch1. The web server reports the successful execution back to the Process Engine. For this process step, the cyber-physical flag is set and its Goal attribute corresponds to the contents of Listing 6.1. Consequently, the Feedback Service (FB Service) is called from the Process Engine in parallel to the REST service call to the dimmer switch. The FB Service receives the goal and instantiates the MAPE-K loop to be run in parallel to verify the execution of the process step instance for the specific objective.

6.3.4. Monitor

The Knowledge Base KB is subscribed to all available sensors. The Light Sensor in question updates its values about once every second. Upon initiation of the MAPE-K loop, the Monitor subscribes to the KB with respect to the light sensor values ct as defined in the context path cp (cf. Section 4.8.3). From that point on,

it receives all updates concerning the sensor from the KB. With every significant update (Symptom) of the light levels from the sensor, the corresponding monitoring agent sends a request to the Analyser.

6.3.5. Analyse

The Analyser checks the compensation condition and satisfied condition w. r. t. the received symptoms. As in our example the light levels from the sensor do not exceed the defined threshold of 700 Lux, the Analyser triggers a timeout after 5 seconds as defined in the compensation condition. At this point in time, we assume that CP Ct is violated due to the assumed state SC,t regarding the current light levels c

′

t

of DimmerSwitch1 (On) not matching the actual state SP,t (Off ) and light levels ct

(cf. Equation 4.2). A Change Request is then issued and transferred to the Planner. 6.3.6. Plan

The Analyser determined that the mismatch regarding the relevant light levels is too low. Based on this mismatch and the context of the MAPE-K execution (check- ing for Cyber-physical Consistency CPC ), the Planner queries the Compensation Repository for a suitable compensation strategy. Parts of this repository are Com- pensation Queries to be executed for the knowledge base. The compensation query concerning CPC restoration can be found in Listing 6.2.

The essence of this query is that the Planner looks for actuators in the same room (here: Kitchen Mueller) as the light sensor is in (Line 5). The devices–actuators and sensors–have to be linked to the same context attributes (here: light levels) (Line 6). The rest of the query is used to retrieve the actuator (here: DimmerSwitch2) based on its functionality and with that, the control commands to influence the context attribute (Lines 7–20) as modelled and contained in the Knowledge Base. Based on the too low mismatch, the Planner then selects the found compensation action (here: UP ) to increase the value of the context attribute (here: light levels). The

Figure 6.4.: Sequence Chart for the MAPE-K Loop applied to the Smart Lighting Process Step.

6.3. Feedback Loop for Cyber-physical Consistency

Listing 6.2: Compensation Query regarding the Restoration of Cyber-physical Consistency. 1 M A T C H ( s e n s o r ) -[: h a s S t a t e ] - >( s e n s o r S t a t e ) 2 M A T C H ( a c t u a t o r ) -[: h a s S t a t e ] - >( a c t u a t o r S t a t e ) 3 M A T C H ( a c t u a t o r S t a t e ) -[: h a s S t a t e V a l u e ] - >( a c t u a t o r S t a t e V a l u e ) 4 M A T C H ( a c t u a t o r S t a t e V a l u e ) -[: u n i t O f M e a s u r e ] - >( a c t u a t o r S t a t e U n i t ) 5 M A T C H ( s e n s o r ) -[: i s I n ] - >( r o o m ) < -[: i s I n ] -( a c t u a t o r ) 6 M A T C H ( s e n s o r S t a t e ) -[: t y p e ] - >() -[: s u b C l a s s O f *0..1] - >() < -[: t y p e ] -( a c t u a t o r S t a t e ) 7 M A T C H ( a c t u a t o r ) -[: h a s F u n c t i o n a l i t y ] - >( f u n c t i o n ) -[: h a s C o m m a n d ] - >( c o m m a n d ) 8 M A T C H ( c o m m a n d ) -[: t y p e ] - >( c o m m a n d T y p e ) 9 M A T C H ( f u n c t i o n ) -[: t y p e ] - >() -[: s u b C l a s s O f *] - >({ n a m e : " C o n t r o l F u n c t i o n a l i t y " }) 10 11 W H E R E id ( s e n s o r S t a t e ) = { s t a t e I d } AND has ( c o m m a n d . r e a l C o m m a n d N a m e ) AND has ( c o m m a n d T y p e . n a m e ) 12 13 R E T U R N D I S T I N C T 14 a c t u a t o r S t a t e . n a m e AS a c t u a t o r , 15 c o m m a n d T y p e . n a m e AS c o m m a n d T y p e , 16 c o m m a n d . r e a l C o m m a n d N a m e AS c o m m a n d N a m e , 17 a c t u a t o r S t a t e V a l u e . r e a l S t a t e V a l u e AS a c t u a t o r S t a t e , 18 a c t u a t o r S t a t e U n i t . n a m e AS a c t u a t o r S t a t e U n i t

reference to the command including the respective service URI to be invoked is then transferred as part of the Change Plan to the Executor.

6.3.7. Execute

The Executor invokes the corresponding command contained in the Change Plan to activate DimmerSwitch2. The Monitor is still subscribed to the light levels as defined in the context path. It receives the changed light levels, which are analysed again with respect to the fulfilment of the compensation condition and satisfied condition. The current light levels now match the criterion defined in the satisfied condition leading to the termination of the MAPE-K loop and Feedback Service. Before terminating, the Analyser updates the data related to the MAPE-K executions (goals and objectives) in the knowledge base. Figure 4.17 shows the corresponding entries. Cyber-physical Consistency is restored with the positive evaluation of the satisfied condition and therefore, the fulfilment of objective and goal associated with the process step is achieved.