Dynamic Services

Figure 4.14.: Extension of the Workflow Metamodel for Dynamic Service Selection. Thus far, components within CPS can only be accessed based on rather static IoT service address definitions and requests (cf. Section 2.4.4). As pointed out in Section 2.6 (Requirement R2 : Dynamic Resources), the availability of devices and resources within CPS may vary heavily over time, making static service calls infea- sible and error prone [CSOL15]. Therefore, the workflow metamodel also supports special process steps to enable a more general (under-)specification of workflow ac- tivities as described in [HSKS16b]. This specification relies on semantic SPARQL Protocol And RDF Query Language (SPARQL) queries to be executed on the un- derlying ontology. The queries specify necessary functionalities, capabilities and context constraints of resource instances available from the knowledge base (cf. Sec- tion 4.3) to execute the respective workflow task. As suggested in [DBBM11], a semantic model to describe the components of an IoT environment is feasible to enable a more dynamic and flexible discovery of resources and services. We distin- guish between three types of SPARQL-based knowledge base (ontology) queries as subclasses of a Semantic Invoke (cf. Figure 4.14) process step to retrieve specific devices, IoT service parameters associated with the device functionality, or sensor values from the knowledge base:

• Semantic Select: This query is used for a one-time retrieval of the current state of actuators or values of sensors in a certain context. Listing 4.2 shows an exemplary query for retrieving the current brightness level in a given location. • Semantic Ask: This query is used for a one-time retrieval of certain data and values (e. g., sensor values) from the knowledge base and evaluating these values based on a given condition. Listing 4.3 shows an exemplary query for checking if the brightness levels in the current location are below 290.1 Lux.

4.4. Dynamic Services

Listing 4.2: Semantic Select Query for Retrieving Current Luminance Levels. 1 S E L E C T ? r e a l L o c ? c u r R e a l L o c ? l i g h t S t a t e ? c u r r e n t V a l u e 2 W H E R E { 3 i n s t a n c e : S t a t e _ C u r r e n t _ L o c a t i o n d o g o n t : h a s S t a t e V a l u e ? s t a t e V a l u e . 4 ? s t a t e V a l u e d o g o n t : r e a l S t a t e V a l u e ? c u r R e a l L o c . 5 ? t h i n g d o g o n t : h a s S t a t e ? l i g h t S t a t e . 6 ? l i g h t S t a t e d o g o n t : h a s S t a t e V a l u e ? l i g h t V a l u e . 7 ? l i g h t V a l u e rdf : t y p e ? t y p e . 8 ? t y p e r d f s : s u b C l a s s O f * d o g o n t : B r i g h t n e s s S t a t e V a l u e . 9 ? l i g h t V a l u e d o g o n t : r e a l S t a t e V a l u e ? c u r r e n t V a l u e . 10 ? t h i n g d o g o n t : i s I n ? loc . 11 ? loc r d f s : l a b e l ? r e a l L o c . 12 F I L T E R (? c u r R e a l L o c = ? r e a l L o c ) }

Listing 4.3: Smenatic Ask Query for Checking Current Illuminance Levels. 1 ASK 2 W H E R E { 3 i n s t a n c e : S t a t e _ C u r r e n t _ L o c a t i o n d o g o n t : h a s S t a t e V a l u e ? s t a t e V a l u e . 4 ? s t a t e V a l u e d o g o n t : r e a l S t a t e V a l u e ? c u r R e a l L o c . 5 ? t h i n g d o g o n t : h a s S t a t e ? l i g h t S t a t e . 6 ? l i g h t S t a t e d o g o n t : h a s S t a t e V a l u e ? l i g h t V a l u e . 7 ? l i g h t V a l u e rdf : t y p e ? t y p e . 8 ? t y p e r d f s : s u b C l a s s O f * d o g o n t : B r i g h t n e s s S t a t e V a l u e . 9 ? l i g h t V a l u e d o g o n t : r e a l S t a t e V a l u e ? c u r r e n t V a l u e . 10 ? t h i n g d o g o n t : i s I n ? loc . 11 ? loc r d f s : l a b e l ? r e a l L o c . 12 F I L T E R (? c u r R e a l L o c = ? r e a l L o c && xsd : d o u b l e (? c u r r e n t V a l u e ) < 2 9 0 . 1 ) }

• Semantic Command: This query is used for finding certain types of actu- ators in a specific context. The execution of an instance of this process step leads to the invocation of the respective functions as defined in the query for all instances of actuators matching the query criteria. Listing 4.4 shows an exemplary query for finding all actuators of type Dimmer Switch in a given location able to execute the OnCommand.

In addition, we support the specification of a goal within a GoalBasedInvoke pro- cess step for defining the outcome of a certain process and additional non-functional properties using the TROPOS specification methodology [BPG+04]. These speci- fied goals are evaluated and partially converted into the SPARQL queries described above [HSK+16]. More detailed elaborations by Huber on applying goals and the TROPOS methodology for dynamic service discovery and workflow adaptations for role-based resources in the IoT can be found in [Hub18]. These more abstract spec- ifications of properties and context constraints that need to be fulfilled by process resources in order to execute the respective tasks enables a more flexible allocation

Listing 4.4: Semantic Command Query for Retrieving Dimmer Actuators. 1 S E L E C T ? f u n c 2 W H E R E { 3 i n s t a n c e : S t a t e _ C u r r e n t _ L o c a t i o n d o g o n t : h a s S t a t e V a l u e ? s t a t e V a l u e . 4 ? s t a t e V a l u e d o g o n t : r e a l S t a t e V a l u e ? c u r R e a l L o c . 5 ? t h i n g d o g o n t : h a s F u n c t i o n a l i t y ? f u n c . 6 ? t h i n g rdf : t y p e ? t h i n g T y p e . 7 ? t h i n g d o g o n t : i s I n ? loc . 8 ? t h i n g T y p e r d f s : s u b C l a s s O f * d o g o n t _ D i m m e r S w i t c h . 9 ? f u n c d o g o n t : h a s C o m m a n d ? cmd . 10 ? cmd rdf : t y p e ? c m d T y p e . 11 ? c m d T y p e r d f s : s u b C l a s s O f * d o g o n t : O n C o m m a n d . 12 ? loc r d f s : l a b e l ? r e a l L o c . 13 F I L T E R (? r e a l L o c = ? c u r R e a l L o c ) }

of resources at runtime. Available resources and their specific service addresses do not have to be known at workflow design time. They can be discovered and invoked dynamically based on the presented queries, model and instance information con- tained in the knowledge base. In addition, the complexity of process models can be reduced as not every service invocation has to be modelled as an individual process step for multiple devices or services. The results of the semantic invoke extensions may comprise the querying and triggering of multiple sensors and actuators that match the specified criteria. That way, we can for example trigger all lights in a specific room to be switched on without requiring a priori knowledge about avail- able light sources and without the specification of the individual process activities to switch on each individual device.