4. Modelling of Cyber-physical Workflows with Consistency Style Sheets
4.9. Compatibility with Existing Business Process Notations
CPS workflows consisting of events, service calls, human tasks, control and data flow, process logic, subprocesses and also possibly process fragments from a reposi- tory. Besides these basic processes, the designer also needs to specify EPL patterns, SPARQL queries and goals, which are rather complicated expressions that should be supported by more sophisticated tools also connected to the knowledge base.
The End-user wants to create very basic CPS workflows to automate and cus- tomise simple routines involving only a small number of CPS devices. He/she uses the HoloFlows app to connect the respective virtual devices with each other in aug- mented reality (AR) and to set some simple parameters for the three types of con- nections (cf. Section 4.8.2). The AR app requires only very little knowledge about CPS and workflow composition in general and has a steep learning curve [SKGA17]. In order for the workflow IDE presented in Section 4.8.1 to be usable by end-users, non-computer scientists or non-domain experts, the IDE has to be simplified to a large degree. Service calls, events and other workflow components have to be pre- modelled and available from a repository to use simple drag and drop gestures to compose these workflow elements into complete process models [DR09]. The IDE also has to support the modellers with parameter configurations, automatic sugges- tions and auto-completion, workflow verification, and probably a wizard guiding the user through the steps of defining executable CPS workflows.
4.9. Compatibility with Existing Business Process Notations
Various works discuss the suitability of existing workflow notations to model business processes [WvdAD+06, B¨or12] (cf. Sections 2.3.3 and 3.3). As shown in this chapter
with our process metamodel and with the discussions of related work in Chapter 3, additional workflow elements are necessary to cover the special properties of CPS and IoT environments and to fulfil the identified requirements.
The more general concepts regarding the composite structure of processes and logic elements to describe (conditional) splits and merges of the control flow can be found in other workflow languages in similar ways. The detailed description of typed data flow consumed and produced by process steps and services as well as mappings among these data are only partially possible with current business process languages which makes extensions to these notations necessary.
The support of complex rules to define patterns within event streams and model complex high-level events also requires extensions to existing notations [BBDC+15]. Simple sensor-related events can often be modelled with built-in workflow elements related to the occurrence of an event as trigger for following actions or decisions (e. g., event-based gateways in BPMN 2.0).
Many BPM systems support the definition of Service Tasks to invoke web Ser- vices, usually deployed and registered locally in the WfMS or accessed based on SOAP. The workflow metamodel proposed in this chapter supports these invoca- tions as well, which allows a direct mapping to other BPM notations. In addition, it covers a wide variety of other web service protocols and proprietary services due to CPS consisting of highly heterogeneous resources that often already provide built-in web service interfaces with REST being the prevalent protocol in IoT. The under- specification of workflow activities to enable dynamic discovery of suitable services at runtime is only partially supported by existing workflow notations (e. g., Worklets
in YAWL [ATHEVDA06]). New workflow elements are necessary to realise the se- mantic resource discovery described in Section 4.4.
The concepts of a Human Task or similar manual tasks can also be found in existing BPM notations, which allows for a direct mapping to our concepts.
The specification of CPS aspects and other QoS, KPI or context criteria in goals and objectives is not supported by common BPM notations. These aspects have to be specified either as newly introduced metamodel attributes and classes or as new parameters for the particular process steps. The style sheet mechanism proposed in Section 4.7 facilitates the separation of concerns with respect to modelling the “regular” workflow and defining the outcome, effects or success criteria of the process steps in separate documents, which are evaluated during the execution of the MAPE- K feedback loops. Workflows can be defined using the respective notation in its original form and Consistency Style Sheets can be added to a workflow definition. These style sheets may include goals concerning different aspects (e. g., CPS effects, process conformance or distribution) that are used to configure additional process parameters at runtime. The goals are linked to the original workflow definition via the identifiers of the corresponding process steps. This way existing “legacy” process models can be reused without any modifications (cf. Section 4.7).
The workflow metamodel described in Section 4.2 can be viewed as a more tech- nical, imperative workflow language for implementing executable processes, which may be used as an intermediate language between high-level business process nota- tions (e. g, BPMN) and very technical descriptions of processes on the programming level. An evaluation of the expressiveness of our workflow langugage with respect to the Workflow Patterns [vDATHKB03] as well as the derivation of transformations or automated mappings to other workflow languages remain tasks for future work. Relation to BPMN 2.0
BPMN 2.0 is the most widely used process notation to describe business processes in an organizational context (cf. Section 2.3.3). In the context of this thesis, we use BPMN 2.0 to describe example processes from a more abstract perspective to show organisational aspects and to illustrate general concepts and workflows. From our evaluation of existing workflow notations, we conclude that BPMN 2.0 lacks expres- siveness and technical detail (e. g., with respect to describing the automated data flow between services, service tasks and other process steps) to implement processes for CPS to be executed completely automatically by a BPMN-based WfMS without requiring human intervention–unless modelled as part of a workflow (Human Task ). The semantics of some of the modelling elements (e. g., related to events and services as well as activities/tasks) are rather ambiguous and not precise enough to imple- ment fully automated processes for CPS. Partial (possibly automated) mappings between modelling elements of our workflow notation and BPMN 2.0 are possible, e. g., related to simple events, timeouts, service invocations and human activities. To handle errors and other exceptional behaviour during process execution, BPMN 2.0’s compensation events and compensation handlers could be used as part of a process- based feedback loop [RS16]. Our proposed process modelling language can be seen as a more concrete technically oriented process notation that BPMN can be used on top of, but that still abstracts from many implementation details of the underlying CPS control applications and processes (cf. Section 2.5.1).
4.9. Compatibility with Existing Business Process Notations
The investigation of related work regarding the modelling of CPS workflows in Sec- tion 3.3 shows that BPMN 2.0 lacks most of the modelling elements and concepts necessary to describe CPS workflows with respect to the identified requirements R1– R8 (e g., complex sensor events, dynamic actuator service selections, or interaction of distributed WfMSes). Many of the related approaches propose extensions of the BPMN language and corresponding implementations or adaptations of the related WfMSes (cf. Chapter 3), which shows that BPMN 2.0 per se is not suitable for de- scribing and enacting the complex interactions of sensors, actuators, smart objects, humans and the physical environments of CPS on the business process level as re- quired within the context of this thesis. These limitations are due to the fact that BPMN was designed for modelling and executing business processes. The extensions and modifications to BPMN 2.0 and a corresponding WfMS necessary to fulfil all requirements would be very complex and invasive, which is why we decided to base our CPS WfMS on an extensible and more implementation-oriented component- based workflow language. Some of our concepts, e. g., goals for defining success and error criteria [KK12], EPL patterns for defining complex sensor events [BBDC+15] and special semantic process tasks for dynamic service selections can be applied to BPMN 2.0 as well. The investigation of the applicability of our CPS workflow concepts to BPMN and an associated WfMS remains subject to future work.