Tools for Modelling of CPS Workflows

After the description of elements and concepts necessary to specify CPS workflows and associated CPS entities, we present the tooling infrastructure to apply the new concepts and model the respective processes for CPS. We developed multiple appli- cations to support users with creating CPS workflows and the corresponding CPS entities–also to provide more sophisticated means for workflow modelling and human interaction (Requirement R3 ). These tools are related to the Design (Modelling) phase of CPS and CPS workflows.

4.8.1. Workflow IDE

In accordance with the process modelling language and extensions suggested in the previous sections, we developed a process model editor based on the Graphiti2 tool- ing infrastructure framework as Eclipse plugin. As the process metamodel is an

2

4.8. Tools for Modelling of CPS Workflows

1

2

3

Figure 4.21.: Eclipse-based Process Model Editor.

Ecore model from the Eclipse Modeling Framework (EMF)3_{, we decided to use the}

Graphiti framework for creating the editor. Figure 4.21 shows the Integrated De- velopment Environment (IDE) for CPS workflows as described in [SKNS13] with the canvas for modelling a process (1), the set of graphical process modelling el- ements (2), and the properties view for defining the attributes of the individual process elements (3). The workflow designer first drags the desired process element (i. e., process step or one of its specializations) from the list of available elements (2) and drops it onto the modelling Canvas (1). Then, he/she configures parameters of this process step in the Properties view (3). Following, the designer creates ingo- ing and outgoing control flow and data flow ports–and probably the associated new data types–for the process step from the list of modelling elements. These ports are then connected with the respective ports of other process steps by choosing a transition from the list of modelling elements and selecting source and target ports. The editor also provides some basic means of verification and constraint checking regarding aspects that are not reflected in the metamodel, e. g., the checking of type compatibility between data ports or the checking of mandatory input fields. We also support the use of process fragments and templates from a connected Process Repository within the workflow IDE (cf. Section 5.2.7).

With this IDE, the process designer is provided with a tool focused towards end- user development of workflows using drag and drop gestures. However, due to the

3

rather technical notation and components of a process, the designer needs deep knowledge of the process composition (e. g., regarding the modelling of data flow between ports), technical details (e. g., regarding specific service parameters), as well as domain knowledge (e. g., regarding the definition of the effects of a process step in objectives). An extension of the IDE to support the use of gestures to draw graphi- cal process elements is described in [NSKS14]. Future developments to increase the usability and end-user friendliness of the workflow IDE could comprise providing a predefined set of available process steps that can be easily composed (wired) by drag and drop from a process repository (cf. Mixed reality workflow composition with HoloFlows in Section 4.8.2); DSLs and corresponding extensions of the IDE to ease the definition of goals and objectives, EPL patterns and SPARQL queries with live recommendations and auto-completion using the knowledge base [MVKM16]; as well as a more sophisticated Consistency Style Sheet editor. As the knowledge base is founded on a semantic ontology, suitable ontology editors (e. g., the Top- Braid Suite4 _{or Prot´eg´e}5_{) can be used to extend and modify the underlying models.}

Future development stages may include a workflow store/ecosystem that lets people contribute, share, sell and rate their cyber-physical workflows created with the IDE. 4.8.2. HoloFlows: Mixed Reality Workflow Editor

A first prototype of a mixed reality application for creating basic CPS workflows compatible with the metamodel was also developed as part of addressing the re- quirement of ubiquitous human interaction (Requirement R3 ) in the context of this thesis with a special focus on creating an end-user friendly intuitive workflow mod- elling application. The HoloFlows6 app implemented for smart glasses (Microsoft HoloLens7_{) uses mixed reality technology to display holograms containing informa-}

tion about current sensor and actuator states as well as control functionality above the respective physical device (cf. Figure 5.19) [SKGA17]. Besides direct interaction with sensors and actuators, users are able to create simple workflows between ac- tuators, ECA rules between sensors and actuators as well as direct sensor–actuator workflows by connecting the respective devices via a virtual wire in augmented re- ality. These workflows can be mapped to the workflow metamodel described in Section 4.2 and then executed by the PROtEUS WfMS (cf. Chapter 5). Due to the augmented reality technology displaying sensors, actuators and workflows at their respective physical locations, end-users are able to explore their surroundings and compose simple workflows in a relatively easy way, which enables them to automate, customise and individualise their own CPS processes. The HoloFlows app exploits the physical location of CPS devices as one important context factor of CPS to provide an increased usability and user experience. In its current state, the app is a first prototype for composing CPS workflows compatible with the core classes of the workflow metamodel–supporting the creation of control flows among sensors and actuators as described in the following sections. More advanced concepts (e. g., data flow, complex events, human interactions, distribution, dynamic services or goals for managed process steps) cannot be modelled with HoloFlows, yet.

4_{https://www.w3.org/2001/sw/wiki/TopBraid} 5 http://protege.stanford.edu/ 6_{https://github.com/IoTUDresden/HoloFlows} 7 https://www.microsoft.com/de-de/hololens

4.8. Tools for Modelling of CPS Workflows

(a) Conditional Sensor–Actuator Workflow. (b) Direct Sensor–Actuator Workflow.

(c) Actuator–Actuator Workflow.

Figure 4.22.: Mixed Reality App HoloFlows for Simple Workflow Composition.

Conditional Sensor–Actuator Workflows: These ECA workflows are created by connecting a sensor with an actuator (cf. Figure 4.22(a)). Upon drawing a virtual connection between these devices by first selecting the particular sensor and then selecting the corresponding actuator (cf. Section 5.6.3), a condition defining the threshold for triggering an event related to the sensor’s value has to be defined. Second, the action to be activated by the actuator is selected. The workflow can then be started, it will trigger an event and with that the activation of the actuator once the defined condition related to the sensor value becomes true.

Direct Sensor–Actuator Workflows: These workflows are created by directly con- necting sensors producing continuous data with actuators consuming continuous data that is compatible with each other (cf. Figure 4.22(b)). The sensor emits data, which is directly used as input parameter for the actuator once both devices are connected and the workflow is activated. Examples of these type of workflows can be the direct mapping of the color value detected by a color sensor to a connected lamp able to show this color, or the direct mapping of the state of a potentiometer (0 .. 100 %) to the light level of a dimmer switch (0 .. 100 %).

Actuator–Actuator Workflows: These workflow are created by connecting an actu- ator with another actuator (cf. Figure 4.22(c)). Upon drawing a connection between these devices, the action to be activated for the first actuator has to be selected, and then the action for the second actuator. Once the workflow is started, both actions are executed sequentially in the order they were defined.

4.8.3. CPS Modelling Process Knowledge Base Process Repository CPS Designer Workflow Designer End-user Model CPS Device

Extend Ontology Create Device Instances

<<include>> <<include>>

Model CPS Workflow

Model Basic

Workflow Define EPL Patterns Define SPARQL Queries Define Goals

<<include>> <<include>> <<include>> <<include>>

Model Basic CPS Workflow Create Direct Sensor-Actuator Workflow Create Actuator- Actuator Workflow Create Conditional Sensor-Actuator Workflow <<include>> <<include>> <<include>>

Figure 4.23.: Modelling Activities of Different Types of Users of CPS. Figure 4.23 shows the modelling activities of different types of users of CPS. The main actors involved in the modelling and design of CPS are the CPS Designer, the CPS Workflow Designer and the End-user.

The CPS Designer is an expert in the field of CPS and is responsible for modelling and integrating new CPS devices into the knowledge base and existing infrastructure. If the devices–their properties, functionality, capabilities, context, etc.–can already be modelled with the knowledge base’s underlying ontology, the CPS designer only needs to create new instances of the respective devices to add them to the existing CPS infrastructure and knowledge base/triplestore; otherwise the modeller has to extend the concepts of the ontology accordingly to represent the new CPS devices and entities. The CPS Designer uses an ontology editor to model the CPS devices. The CPS Workflow Designer is a domain expert, who models domain-specific CPS workflows based on the workflow metamodel. Besides domain knowledge, the designer needs deep knowledge of the metamodel and the specific processes as well as service parameters and data models. He/she uses the workflow IDE to model