Knowledge Base

4.3. Knowledge Base

The MAPE-K feedback loop is one of the central principles from the engineering of self-managed systems field [DLGM+13]. The individual phases of this loop rely heavily on the information contained in a Knowledge Base shared among the entities of the CPS. The knowledge base stores the models used to describe the CPS entities and workflows as well as their contexts. It also contains and updates runtime and history information regarding the respective instances. In order to increase the resilience of the WfMS, this information is used within the individual MAPE-K phases as shared Knowledge for analysis and planning purposes (cf. Chapter 6).

Figure 4.11.: Parts of the Context Model for an Instance of a Light Sensor. In our work, the knowledge base is founded on the DogOnt ontology, which pro- vides an ontological model for describing intelligent domotic environments [BC08, BGT17]. This ontology follows a functionality and capability-based approach for the semantic description of sensors and actuators–including their context–in smart home settings. Therefore, it is suitable to be used as the basic model to describe CPS entities within the scope of this thesis. We combine and apply this ontol- ogy to the openHAB middleware1 _{and its entities (Items as first class citizens).}

The following sections show the application of the DogOnt ontology to model CPS devices–Items–from openHAB (e. g., sensors and actuators) and exemplary exten- sions that we introduced to model workflow related data as well as more complex combinations of sensors and actuators in the form of robots and humans. These models are described in more detail in [HSKS16b, SSAS15]. We decided to use a semantic model (Ontology) as foundation of our knowledge base as it provides a bet- ter expressiveness for modelling entities, concepts and their relations among each

1

other and it allows for deriving new knowledge via inference, which will be useful for future extensions of the system [KKMZ17].

4.3.1. Sensors

Sensors are vital elements of CPS and IoT. Figure 4.11 shows details of the sensor model graph in the knowledge base for an instance of an ambient light sensor (am- bient light 1 node). Besides its type (Light Sensor ), the knowledge base contains a URI and a unique identifier; its context (i. e., physical location Kitchen and associ- ated location coordinates within a map of the building); its functionality and type (Light Sensing); and its state including the concrete value for the current luminance of this sensor instance (node1b). The Type classes associated with a sensor represent the physical values being measured by the respective sensor. They are also the basis for the event data model applied within the CEP engine (cf. Section 4.2.9).

4.3.2. Actuators

Figure 4.12.: Parts of the Context Model for a Dimmer Switch.

In analogy to sensors, actuators are also represented within the knowledge base as shown for two instances of light dimmer switches (Dimmer1 and Dimmer2 ) in Figure 4.12. The State node represents the current state of the light switch (i. e., its power level in percent). Its Light Level Control functionality refers to light level control commands as nodes (On, Off, Up, Down), each of which can be invoked via a specific service URI. These states and commands are derived from openHAB’s internal model for actuators. The Light Level Control functionality also has a rela- tion to the Light Intensity node. This relation is used to connect actuators to the physical values they are able to manipulate and therefore to also connect them to the respective sensors. Listing 4.1 shows the textual representation of an instance of a HomeMatic KeyMatic door actuator in Resource Description Framework (RDF) notation for semantic data following the Manchester syntax [HDG+06, HSKS16b].

4.3. Knowledge Base

Listing 4.1: Instance of a HomeMatic KeyMatic Door Opener in RDF Description. 1 i n s t a n c e : T h i n g _ k e y m a t i c _ 1 2 rdf : t y p e d o g o n t : D o o r A c t u a t o r ; 3 d o g o n t : h a s F u n c t i o n a l i t y i n s t a n c e : F u n c t i o n _ K e y m a t i c _ 1 ; 4 d o g o n t : h a s S t a t e i n s t a n c e : S t a t e _ K e y m a t i c _ 1 ; 5 d o g o n t : i s I n i n s t a n c e : L o b b y _ 0 . 6 7 i n s t a n c e : F u n c t i o n _ K e y m a t i c _ 1 8 rdf : t y p e d o g o n t : O p e n C l o s e F u n c t i o n a l i t y . 9 10 i n s t a n c e : S t a t e _ K e y M a t i c _ 1 11 rdf : t y p e d o g o n t : O p e n C l o s e S t a t e ; 12 d o g o n t : h a s S t a t e V a l u e [ rdf : t y p e d o g o n t : O p e n S t a t e V a l u e ; 13 d o g o n t : r e a l S t a t e V a l u e " C L O S E D " ^^ xsd : s t r i n g ] . 14 15 i n s t a n c e : L o b b y _ 0 16 rdf : t y p e d o g o n t : L o b b y ; 17 r d f s : l a b e l " L o b b y " ^^ xsd : s r i n g . 4.3.3. Robots

The previous sections describe how to integrate relatively simple sensors and actua- tors into the knowledge base used in the context of this thesis. Robots are currently on the verge of becoming ubiquitous assistants throughout almost all domains and phases of everyday lives [SG07]. They are perfect examples of more complex com- binations of sensors and actuators, which interact with each other and require more abstract models and levels of detail to be represented in the knowledge base.

Robots are usually composed of several subdevices–either sensors, actuators or computational units–which can be represented as individual entities (Items) belong- ing to the robot’s context in the knowledge base. Figure 4.13 shows the example of a TurtleBot service robot having several subcomponents (e. g., a Kobuki locomotion engine, an Asus Xtion camera and a control laptop). The robot has a set of runtime metrics (RTMetric) including the power/battery level and a liveliness timestamp (heartbeat) as well as its current location based on a map of the respective building. As the robot may also be able to host an instance of the workflow engine, it can have several (sub)processes running on its computing unit. A robot’s functionality can become very complex and specific for that robot type. The level of detail nec- essary to describe all properties and functionality may become to fine grained and implementation-specific to be able to support a wide range of service robots. In addition, the composition of workflows involving service robots or the development of robotic applications may also be hindered by the complexity and level of detail of current robot control software (e. g., ROS [QCG+09]). Therefore, the knowledge base contains the hasCapability relation to have a more abstract and general view on a robot’s capabilities–with a service robot being an example of a complex com- bination of sensors and actuators. In Section A, we present the DROiT API –an approach of a capability-based abstraction for the class of small domestic service robots as described in [SSAS15]–and its underlying models for implementing the abstraction for concrete service robots and the capabilities shown in Figure 4.13.

Figure 4.13.: Parts of the Context Model for a TurtleBot Robot.

The aforementioned models based on the DROiT API are one example of ab- stracting and integrating more complex CPS devices into the knowledge base. The capability-oriented approach provides a more abstract view on the robots than the functionality-based approach, which is why it can be applied to a wider range of service robots. Application development and workflow integration are simplified as many implementation and technological details regarding the offered capabilities are hidden behind the API. Capabilities integrate well with the knowledge base provid- ing an additional view on the CPS devices. We have used the DROiT API within various workflow related use cases and CPS applications [SLSS16, SNS14a, SHA17, SNK+15]. Besides an easier integration and support of a wider range of robots–due to it being on a more abstract level–the capability-based abstraction also facilitates the dynamic resource selection at runtime. Applications and workflows can request a suitable device based on required capabilities (e. g., a robot able to fetch things), which may result in more resources available and able to execute the specific task than using functionalities or other properties to specify resource requirements.

In general, the simplification of complex functionality CPS devices provide to a more abstract view is a necessary step to integrate these devices into the knowledge base and to use their functionality and capabilities on the workflow level. In our ap- proach, we represent the complex device as well as its set of possible subcomponents as main entities. The functionality of the device and with that, its capabilities vary depending on the availability of certain components. This abstraction process of viewing complex devices as a composition of smaller devices, which add functional- ities and capabilities to the overall system can also be applied to other CPS devices (e. g., production machines, household appliances or personal devices). CPS devices interact with physical objects and their environment, which requires a certain degree of context awareness and a representation of objects and locations as their physical

4.3. Knowledge Base

contexts in the knowledge base. By also including these concepts (here: Movement- Target and GrabbingTarget locations) in our abstract models (cf. Section A), we enable their augmentation with additional context information (e. g., the physical conditions at a movement target or the physical location of a grabbing target).

Robots are also good examples to show the complex interactions of sensors, ac- tuators and computing units. Programmed processes run on various levels of the hardware platforms: within single devices (e. g., microprocessors controlling specific motors or processing camera data), single systems (e. g., computers controlling the entire robot), or across system boundaries (e. g., workflows orchestrating multiple devices in the smart home) (cf. Section 2.5.1). The focus of this work is on the latter level of workflows among systems and systems of systems (PACPS). Functionalities and capabilities of a device or a system have to be accessible via service-based in- terfaces in order to be included in a process model. The invocation of a service from the workflow layer may trigger internal processes on the device or system level, which are regarded as black boxes and not considered by this work. That way, more (safety-) critical and other safety-related features can be implemented closer to the actual hardware involved in the respective processes. For example, the processes regarding obstacle avoidance can be executed directly on the computer controlling the robot and not necessarily by the workflow engine.

4.3.4. Humans

CPS, IoT and especially ubiquitous systems put a strong emphasis on integrating users into the overall systems, which is why the representation of a person is also needed in the knowledge base (Requirement R3 : Human Interaction). However, there is only little to no related research regarding the ontological representation of humans, their capabilities and contexts. The Friend Of A Friend (FOAF) ontology mostly specifies properties of persons and their relations among each other [GCB07]. The SOUPA ontology adds more properties as well as Beliefs, Desires and Inten- tions (BDI) from agent-based systems to the models to describe goals and plans of people [CPFJ04]. These works focus on humans as central entities of the whole sys- tem. In our approach, people are considered as first class citizens of the CPS along with the aforementioned sensors, actuators and more complex entities. In analogy to sensors and actuators described in the previous sections, the Person class in the knowledge base is also linked to context factors (e. g., a location) as well as to capabilities the individual instance of a person has (e. g., grabbing, movement or communication from the robot example in Section A). The SOUPA ontology could be used to extend the information in the knowledge base with respect to humans, their behaviour and intentions in the CPS.

4.3.5. Workflows

Workflow-specific data is contained in the knowledge base according to the descrip- tions in previous sections of this chapter. This information comprises process (step) and instance attributes as well as the runsOn relation, which links a (sub)process instance to its executing device (i. e., resource) as shown in Figure 4.13. Additional process-related data concerning the physical effects of activities will be introduced in Section 4.5. Goals and Objectives will be used to describe and verify the expected

outcome of the process execution, to detect exceptions and undesired behaviour, and to adapt the process in case of errors.