Towards a CPS WfMS Reference Architecture for Other Domains

Sensor holograms include a type-specific icon, an identifier and their current value (cf. 1 in Figure 5.20(a)). They show a connector box for creating connections/work- flows with other devices (cf. 2 in Figure 5.20(a)) and an anchor box for manual placement of the hologram in the holographic scene (cf. 3 in Figure 5.20(a)).

Actuator holograms also include a type-specific icon, an identifier, their current states and available control options that can be directly activated via an air tap gesture (cf. 1 in Figure 5.20(b)). They also show a connector box for creating con- nections/workflows with other devices (cf. 2 in Figure 5.20(b)) and an anchor box for manual placement of the hologram in the holographic scene (cf. 3 in Figure 5.20(b)).

5.7. Towards a CPS WfMS Reference Architecture for

Other Domains

When designing the WfMS for CPS workflows, we followed the general suggestions of a reference architecture for WfMSes in [GdV98] and [DLRM+13]. PROtEUS features a core process engine for executing formalized process models, a process manager, process repository, external services, monitoring tools and user applica- tions (cf. Sections 2.3.4 and 5.2). However, from the previous sections we conclude that with CPS, additional components become necessary to implement a fully func- tional workflow management system for CPS. The reference architecture has to be extended with components for interacting with new CPS devices–namely sensors and actuators–and with the physical environment. PROtEUS can be regarded as an implementation of this extended reference architecture.

Due to the possibly high number of sensors and other event sources in CPS and IoT, a complex event processing engine or a similar component for the processing of event streams is indispensable to allow for a fast event stream processing and context-sensitive behaviour related to multiple event sources and sensors. Service- based communication–either synchronous or asynchronous–is currently the de facto standard for communication with external IoT devices, which is why a component for invoking these services via remote procedure calls or publish/subscribe (event- driven) mechanisms has to be available as part of the CPS WfMS. However, this ser- vice invoker and the corresponding external services have to be relatively lightweight (e. g., relying on the REST paradigm) due to the limited availability of computing resources in CPS. Along with these limited resources and a high level of mobility there is a fluctuating availability of devices and services, which is why the under- specification and dynamic selection and assignment of services from a process has to be supported by the service invoker.

The process distribution component can be viewed as optional depending on whether the network structure supports this mechanism and this functionality is required for the respective domains and use cases. If there is a high number of CPS devices and CPS workflows and instances to be managed in large smart spaces, then a hierarchical overlay network of peers and super-peers executing process instances in a distributed way provides a scalable way to manage the process resources and executions. End-user applications have to be provided for designing and managing CPS workflows–not only on stationary desktop computers but also on mobile de- vices as these are the predominant class of interactive devices for future CPS and ubiquitous systems [Wei91]. This requirement also includes flexible and lightweight

(well-documented) bi-directional communication and programming interfaces to be provided by the CPS WfMS to interact with the WfMS and develop applications that use the WfMS programmatically.

Due to the large variety of possible CPS and IoT devices from various vendors providing heterogeneous programming and control interfaces, a middleware for uni- fying these CPS entities as well as for routing application calls to the respective devices has to be a dedicated component working independently of the WfMS due to its own complexity and use by other applications and systems. The middleware also has to provide service-based interfaces to interact with it and with its associated devices. Along with that middleware, a knowledge base containing the ontologically founded descriptions and relations of the CPS entities has to be available as dedi- cated external component to be accessed by the WfMS, middleware and other CPS applications for the purpose of dynamic resource selection.

The Feedback Service implementing a MAPE-K-based control and adaptation loop (cf. Section 6.2.1) also has to be considered as integral part of a more general refer- ence architecture for a CPS WfMS to enable self-* capabilities. With new physical error sources and dynamic availability of resources, the workflow executions and WfMS have to be able to react autonomically to unanticipated situations as part of the self-management capabilities. The feedback loops should be executed implicitly as internal processes as corresponding process models having the MAPE-K steps modelled and executed explicitly would become very bloated and complex. With the requirement of being able to retrofit existing WfMSes with self-x capabilities, we propose to have a dedicated external component (Feedback Service) to imple- ment the corresponding feedback loops as it can be reused with other information systems. More elaborations on this component and its applicability in other CPS domains can be found in Chapter 6.

In this thesis, we show the application and feasibility of the PROtEUS system and associated tools in Smart Home environments as examples for CPS. The applica- bility of the generalized system’s structure as a reference architecture for other CPS domains remains to be further investigated. Many of the requirements of smart home environments can also be found in other domains (e. g., Smart Offices [FLSK13] or Smart Factories [SHH+14]) and vice versa, which is why the PROtEUS sys- tem as an implementation of a CPS WfMS reference architecture can be transferred to these domains and may prove suitable for executing workflows in other smart spaces (Smart Buildings [KA10]). With an active process distribution component and a multi-level peer–superpeer hierarchy, the system of workflow systems can also be scaled to the level of Smart Cities [PLM17]. All these environments have in common that they consist of a large number of sensors and resource constraint het- erogeneous devices interacting with the physical world, which is why sensor event processing, dynamic resource selection, human interactions and resilient process exe- cution are important requirements for these CPS domains, too. The generic concepts and approaches identified in related work (cf. Section 3.8) and applied within the PROtEUS system and the Feedback Service (cf. Chapter 6) have proven suitable to be used in various CPS domains and smart spaces as discussed in this thesis.

Some CPS domains introduce new requirements to the WfMS, which have to be evaluated further, though. The domain of Industrial IoT (Smart Production) imposes additional requirements on a corresponding CPS WfMS due to stricter real-

5.7. Towards a CPS WfMS Reference Architecture for Other Domains

time and safety constraints [BS15]. The involved devices (production machines) often do not provide open programming interfaces or service-based access, which is why the WfMS has to be coupled tighter with the existing control applications (e. g., the SCADA system [DS99]) or using the emerging OPC-UA standard for industrial IoT [LM06]. The overheads regarding computations and communications introduced by a SOA often do not suffice the corresponding real-time constraints. Even stricter real-time and safety demands as well as closer software components and many parallel process instances influencing each other can be found in the Avionics and Automotive domains [LS16], which is why the suitability of our proposed concepts and reference architecture needs to be further evaluated. Here, real-time behaviour, safety guarantees/contracts as well as process execution verification have to be provided by the core process engine and its associated components. We do not discuss these aspects within the scope of this thesis. The proposed system architecture addresses the orchestration of workflow tasks at a more abstract higher level among multiple devices and across the boundaries of individual systems on the business process level. The execution of safety-critical and real-time demanding control actions is mostly left to the lower layers closer to the hardware within the particular system’s or device’s control software (cf. Section 2.5.1). Security and privacy are additional cross-cutting concerns not addressed in this thesis. However, they are important for many CPS domains (e. g., Smart Hospitals [HRZ15] or Smart Mobility [WBJ08]), which is why future developments and applications of our proposed CPS WfMS reference architecture also have to cover these issues.

6. Scalable Execution of Self-managed