Identificación de los miembros del 27 con el surrealismo

Table 3.2.: Evaluation of Related CPS Workflow Modelling Approaches with respect to Requirements. P P P P P P P PP Work Req. R1 Complex Sensors R2 Dynamic Resources R3 Human Interaction R4 Distributed Processes R5 CPS Sync R6 CPS Errors R7 Self-* RetrofitR8 [DMC14] + o o - - - - - [KSKP11] + - o - - - - - [SSOK13] + + o o - - - - [BBDC+15] ++ o o - - - - - [AKF+14] ++ o o - - - - - [MRM13] + + o - - - - - [YBSD16] + o ++ - - - - - [GKGK16] o + o - - - - - [BDGP17] + o o - - - - - [MD17] o o o - - - - - [SGCG17] o + + - - - - -

++ = Special Feature (USP); + = supported; o = partially supported; - = not supported

dividual sensors and sensor tasks, which are communicated with via active service calls or publish/subscribe mechanisms. For larger networks of various types of sen- sors in CPS, the approach of addressing sensors individually becomes infeasible, which is why CEP was introduced as a solution to process more complex streams of sensor events (Requirement R1 ). The aspects of human interaction (Require- ment R3 ) and distributed processes (Requirement R4 ) are addressed only to a very limited extend by few works. All of the proposed extensions to existing more or less standardised workflow notations also lead to the implementation of proprietary ex- tensions to existing or completely new proprietary WfMSes. The more CPS-related requirements of synchronization, error handling, self-management and retrofitting (Requirements R5–R8 ) are not addressed explicitly by any of the investigated works.

3.4. CPS Workflow Systems

Following the modelling of CPS workflows (Design Phase), the implementation and execution of the particular workflows by a CPS workflow system (Implemen- tation/Configuration Phase) need to be investigated. Various works present ap- proaches for WS-BPEL-based, BPMN-based or proprietary WfMSes that address specific properties of CPS and IoT environments for different contexts and do- mains [GEPF11, CS11, JDK15, BCD+15, TSD+12, HHGR06, SHH+14, PRBA15, JROK11, MCS16, MM05, MPMR16]. A comprehensive overview of BPM architec- tures discussing WfMSes with respect to reference architectures, adaptive processes and service composition can be found in [Wes12]. In this section, we discuss WfM- Ses for CPS with a focus on realizing the basic set of requirements R1 –R4. More advanced approaches that also investigate the self-management aspects including

autonomic error handling (self-healing) and cyber-physical interactions (synchro- nization) are presented in Section 3.6.

Glombitza et al. present an approach for using WS-BPEL to realize business processes for the IoT in [GEPF11]. They propose a SOA-based architecture to transform and execute WS-BPEL processes on sensor nodes and WSNs acting as runtime environments for web services and application logic as defined in the re- spective WS-BPEL processes. The goal is to use resource-constraint IoT devices to enact heavy-weight business processes after being transformed to the respective target platforms. The authors do not provide any IoT or CPS-specific WS-BPEL extensions to model processes. The Flogo16 project follows a similar approach of modelling workflows involving micro-services for IoT and transforming these work- flows to executable code for the respective edge devices (cf. Section 2.3.5).

With ERWF, Chen and Shih developed an “Embedded Real-Time Workflow En- gine for User-centric Cyber-physical Systems” [CS11]. This engine uses proprietary workflow scripts to describe and execute predefined activities as processes on a hu- manoid robot serving as an example of an embedded system combined with actuators and sensors. The authors define a formal model for the execution times and proba- bilities of workflow activities in order to enable real-time capabilities of the workflow engine. Figure 3.3 presents an overview of ERWF’s system architecture. Workflow Scripts are instantiated by the Workflow Manager & Processor. The Scheduler is responsible for assigning Threads to workflow tasks, which are then dispatched to execute the workflow instances–possibly with real-time behaviour. Specific Device Drivers are used to communicate with the robot’s built-in sensors and actuators.

Figure 3.3.: System Architecture of the ERFW System from [CS11].

In [JDK15] Juh´asz et al. present the Rea framework for programming workflows for CPS. It follows a task-oriented programming approach for implementing work- flows on a hardware-related level consisting of loosely-coupled tasks, combinators (sequences, parallels, controllers, pipes) and constraints. The Rea language is a DSL founded on an extended version of the Erlang programming language. The workflow system runs on the corresponding IoT devices and interacts with its sen-

16

3.4. CPS Workflow Systems

sors and actuators. The framework provides means for failure detection and handling as well as interaction with the workflows via a simple client application.

Figure 3.4.: High-level Architecture for Real-time Monitoring of Business Processes through CEP from [BBDC+15].

The implementation of event-driven process applications in the domains of logis- tics and IoT was proposed in several works by Herzberg et al. [HMW13], Baumgraß et al. [BBDC+15, BCD+15] and Mandal et al. [MHW17]. The authors propose to use CEP to evaluate complex event streams from various sensor sources based on EPL patterns defined in the respective process models. Figure 3.4 shows a high-level architecture for real-time monitoring of business processes using CEP as presented in [BBDC+15]. The Process Engine subscribes to an Event Service, which is part of the Event Engine. Various Event Sources are connected to the Event Processing component via Event Handlers. Once a significant pattern is detected, the event processing component emits a notification, which is forwarded to all subscribed pro- cess engines through the respective event services. Another approach applying CEP in the context of business processes to analyse sensor streams is presented by Jung et al. in [JROK11]. Event Stream Processing Units (SPU s) proposed by Appel et al. for event processing tasks in business processes [AKF+_{14] were already introduced in}

Section 3.3.

Figure 3.5.: Methodology for Implementing Transactional Workflows from [MMG08].

Pervasive workflows supporting long running transaction in distributed environ- ments are discussed in detail by Montagut et al. in [MM05, MMG08]. The authors propose a fully decentralized workflow engine based on web services, the dynamic assignment of business partners to workflow tasks, and WS-BPEL as underlying workflow language. Along with that workflow system, a transactional protocol for workflow tasks was developed to deal with failures occurring in the decentralized infrastructure of process resources. Figure 3.5 shows their proposed methodology for implementing transactions for workflows. A Critical Zone C is defined for a part of a workflow along with Transactional Requirements (TR) for C. During the Assignment procedure, available partners are evaluated with respect to their offered transactional properties. In case a partner fulfils the requirements, an Instance Cd

of the respective workflow activities in C is created and executed with respect to the transactional requirements.

Complementary to the previous approaches, the ADEPT WfMS also supports the distributed execution of workflows based on instance migration as well as ad- hoc changes to the underlying processes [RRD03, DR09]. Using the ADEPT system as basis, M¨uller et al. propose the AgentWork WfMS supporting rule-based work- flow adaptations [MGR04]. The ADEPT system and the corresponding AristaFlow WfMS [DRRM+09] for flexible, adaptive and highly scalable business processes is currently being used in various IoT-related projects to implement flexible and mobile production processes [PRBA15].

Worklets proposed by Adams et al. represent self-contained subprocesses in SOAs flexibly selected at runtime depending on the specific workflow tasks and their con- text [ATHEVDA06]. Exlets are specializations of these dynamic subprocesses specif- ically designed to deal with exceptions during process execution [ATHVDAE07]. The AristaFlow system also implements robust and flexible error handling mecha- nisms [LRD10].

Dar et al. present in [DTB+15] a process-based and resource-oriented integration architecture for the IoT. Their approach is set in smart home and AAL settings to provide users with assistance. The corresponding processes are described using BPMN. The framework supports dynamic service discovery and replacement based on web service descriptions and registries; event-based communication based on publish/subscribe mechanisms; and distributed process execution based on BPMN’s choreography capabilities–also on mobile IoT devices.

Another approach for mobile and distributed business process in the context of IoT is proposed by Pryss et al. [PTKR10, PRBA15]. Their focus is on designing a flex- ible light-weight workflow system to be used on mobile devices. The system uses context information and additional sensor data to provide a mobile task execution environment in a nursing home scenario. A 3D augmented reality application can be used to model, configure and visualise the corresponding workflows. With Presto and Parkour, Giner et al. discuss similar approaches of mobile workflow support in the IoT [GCFP10]. Their focus is on supporting human workers with executing tasks within business processes and on implicit interactions for pervasive workflows in subsequent work [GCFP11]. An approach for integrating external context infor- mation from wearables into business processes in a production context can be found in [SAEJ18]. Peng et al. also present a mobile WfMS in a Cloud computing set- ting [PRS+13]. The central process executor and coordinator is deployed on a Cloud

3.4. CPS Workflow Systems

server, which distributes subprocesses and tasks to a mobile process engine. The mobile engine is able to incorporate context information from various sensors and to dynamically invoke required services in the Cloud as part of the activity execution. In [MCS16] Mass et al. describe a device-to-device-based BPMS for industrial IoT. The BPMS enables decentralized process execution, also with unreliable IoT devices. A Migration Module, which is part of the Process Executor is capable of migrating a process instance from one node to another by creating a snapshot of its current state and transferring this instance to a new process executor.

Other related works comprise a general context-aware and workflow-based frame- work for pervasive environments, which can be used with various CEP and work- flow engines [AE14]; a WS-BPEL-based workflow execution engine for mobile de- vices [HHGR06]; a Cloud Process Execution Engine (CPEE ) [MRM14]; and a con- ceptual framework for process-based Cloud manufacturing [SHH+_{14]. The concept}

of Osmotic Computing for distributing simple process tasks between Cloud and Edge in an IoT context is presented in [NND+17]. An approach describing the smart con- figuration of smart environments based on the semantic description of IoT resources and with that, the goal-oriented derivation and configuration of processes in the context of smart homes and smart factories can be found in [MVKM16, MPMR16].

Conclusion

Table 3.3.: Evaluation of Related CPS Workflow System Approaches with respect to Requirements. P P P P P P P PP Work Req. R1 Complex Sensors R2 Dynamic Resources R3 Human Interaction R4 Distributed Processes R5 CPS Sync R6 CPS Errors R7 Self-* RetrofitR8 [GEPF11] o o - - - - [CS11] + o - - - - [JDK15] o - o - - - - - [BBDC+15] ++ o o - - - - - [MMG08] - ++ - ++ - - - - [DTB+_{15] + + o + - - + -} [PRBA15] + o + + - - - - [GCFP10] + o ++ o - - - - [PRS+13] + + o + - - - - [MCS16] + + o ++ - - - -

++ = Special Feature (USP); + = supported; o = partially supported; - = not supported

Table 3.3 presents an overview and evaluation of work related to the execution/im- plementation of CPS workflows that we investigated with respect to the identified requirements. We distinguish between four levels of support regarding the fulfilment of the individual requirement by the respective approach: Special Feature/Unique Selling Proposition (++); supported (+); partially supported (o); not supported (-).

Within the investigations of related work regarding CPS WfMSes we found ap- proaches discussing several relevant aspects. Event-driven architectures as well as CEP were identified as important technologies to cope with sensor and context data within CPS (Requirement R1 ). Web services are the most important means of en- capsulating and remotely invoking device functionality. Several works address the issue of dynamic service invocation due to unreliable and limited resources of IoT devices (Requirement R2 ). The aspect of ubiquitous human interaction in the con- text of business processes is only discussed in few works (Requirement R3 ). The importance of mobile and distributed process execution also increased with the de- velopment of more decentralized systems (Requirement R4 ). Most workflow systems proposed are proprietary developments resulting from the necessity of adding new software components to realize specific IoT or CPS functionality to WfMSes. We have also seen alternatives to BPMN and WS-BPEL for describing the underly- ing IoT-related processes. Despite being an important aspect in CPS, real-time is addressed by almost no related approaches in the workflow context. Flexibil- ity in business process systems was identified as an important aspect by various works. As discussed in Section 2.4.6 this aspect also plays an important role in the smart home domain and in CPS in general due to the dynamic availability of re- sources and emergence of new situations. Ad-hoc changes to process instances as well as structural adaptations and evolution of process models [RWRW05] as proposed within the works related to the ADEPT project have to be considered complemen- tary to our investigations, which focus on the CPS resources. The CPS-related requirements of synchronization, error handling, self-management and retrofitting (Requirements R5–R8 ) are not addressed explicitly by the investigated works.