3. Related Work
3.5. Cyber-physical Synchronization
After evaluating related work regarding the design and implementation/configura- tion phases of the BPM lifecycle [VDA13], we move the investigations towards more runtime-oriented aspects. Under the term Cyber-physical Synchronization, we un- derstand the issue of projecting a physical entity’s state and properties to its virtual representation and vice versa as well as maintaining the consistency between both models in case of changes to one of the other (Requirements R5 and R6 ). Our focus is on investigating Cyber-physical Synchronization in the context of workflows and (business) processes [Wom11a, Wom11b, MMS14, MDCM17] but we will also eval- uate more general approaches regarding physical objects, (environmental) context factors and systems [PLM16, CR15, RvWLB15, CSB16, Sto15, RSI+17, dR12].
The aspect of Cyber-physical Synchronization is closely related to representing and synchronizing physical things, systems and environments to virtual entities– referred to as Cyber-physical Objects [PLM16], Cyber-physical Equivalence [Sto15], Augmented Worlds [CR15], Thing/Device Shadows17, Cyber Twins [LBK15] and most prominently as Digital Twins [RvWLB15].
In [PLM16] Petrolo et al. describe Cyber-physical Objects as key elements and actors of CPS. Similar to Smart Objects [KKSF10], cyber-physical objects are aware of their surroundings, able to interact with users and to react to events. The authors
17
3.5. Cyber-physical Synchronization
discuss possible applications and programming models as well as basic platforms for implementing cyber-physical objects and CPS in general.
Stork discusses challenges regarding the realization of Cyber-physical Equivalence for Industry 4.0 applications in the context of visual computing [Sto15]. He argues that all characteristics of physical objects have to be represented by their virtual equivalences including geometry, functionality and behaviour. In case of a mismatch between the physical and digital objects, the corresponding models have to be up- dated or actions have to be performed to restore consistency between both entities. In addition, Lee et al. propose to use sensor data from production machines and their contexts to create a Cyber Twin for the machines of a smart factory [LBK15].
human user MIRROR WORLD hello msg pos pos hello PHYSICAL WORLD user ass. agent mirror-example workspace SituatedMessage Agent Body pos perceive 5 nTouches ghost agent touch perceive Agent Body perceive
Figure 3.6.: Example for a Mirror World from [CR15].
Croatti and Ricci present their work regarding programming abstractions for aug- mented worlds in [CR15]. Their concept of Augmented Worlds links a computational object to its physical location. Such an augmented object–including its state and behaviour–can be represented and implemented through concepts of classical object- oriented programming approaches (i. e., classes and objects). Additional models have to be applied to handle concurrency, though. Mirror worlds [RPTC15] are the software-level representations of physical worlds and provide services to users based on software agents and the user’s physical location. As shown in Figure 3.6, location- based (situated ) messages are contained at specific points in the mirror world. Once the user reaches a physical location associated with a situated message, its mobile assistant user agent–running either on a smartphone or smart glasses–interacts with the corresponding agent in order for the user to perceive the message. There also exist ghost agents autonomously moving along the streets and interacting with the location-based services/agents or hugging the human users upon their encounter.
Among others, Rosen et al. discuss the importance of Digital Twins for future IT- based manufacturing solutions in the context of Industry 4.0 [RvWLB15]. Digital Twins are complete representations of physical products and systems including struc- tured semantic information created throughout all stages of the lifecycle (Design, Build, Operate) of the respective system or product. This information is contained within a Digital Thread and available to all subsequent stages of the lifecycle. Ac- cording to the authors, Digital Twins are key enabler for realizing and optimizing
Listing 3.2: Device Shadow Example for the State of a Traffic Light. 1 { " s t a t e " : { 2 " d e s i r e d " : { 3 " l i g h t s " : { 4 " c o l o r " : " RED " } , 5 " e n g i n e " : " ON " } , 6 " r e p o r t e d " : { 7 " l i g h t s " : { 8 " c o l o r " : " G R E E N " } , 9 " e n g i n e " : " ON " } , 10 " d e l t a " : { 11 " l i g h t s " : { 12 " c o l o r " : " RED " } 13 } } , 14 " m e t a d a t a " : { ... 15 " d e l t a " : { 16 " l i g h t s " : { 17 " c o l o r " : { 18 " t i m e s t a m p " : 1 2 3 4 5 6 19 } } } } , 20 " v e r s i o n " : 10 , 21 " t i m e s t a m p " : 1 2 3 4 5 6 7 8 9 }
Industry 4.0 solutions, e. g., production intelligence, production planning, product design and production system engineering [RvWLB15].
Practical solutions closely related to the idea of cyber-physical synchronization are already provided by various existing commercial IoT platforms to represent properties and states of things and devices. The Amazon AWS IoT platform18 integrates the concept of Thing Shadows or Device Shadows, which are documents containing state information for IoT entities (things, devices, apps, etc.) that can be queried via web services. Listing 3.2 shows an excerpt of a Device Shadow for a traffic light19. It contains its states, metadata and also information about
mismatches regarding the desired and the reported state. Similarly, the Eclipse Ditto project for development of IoT solutions features Digital Twins20to represent a real world device or asset with all its capabilities and aspects as virtual entity. Chang et al. propose to use specific Virtual Thing Adaptors to integrate physical (manufacturing) systems into digital software systems [CSB16].
As an extension to the Physical Web for IoT presented in [WSJ15] where people, places and things have webpages and services to interact with, Ruta et al. describe their vision of the Physical Semantic Web in [RSI+17]. Their framework relies on semantic descriptions being exposed and propagated by representations of things and humans to enable dynamic knowledge discovery and sharing in the IoT. Services and suitable entities can be found dynamically by logics-based queries with respect to specific capabilities and context constraints.
18
https://aws.amazon.com/iot/?nc1=h_ls
19https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-document.html
20
3.5. Cyber-physical Synchronization
Figure 3.7.: Overview of the Verification and Analysis Process of Physical Models from [DRSA12].
De Roo et al. discuss in [DRSA12, dRSA11, dRSA14] various aspects of composing physical models with virtual models in embedded control software. They show how to formally verify the physical models at runtime with the help of sensor informa- tion and events, and adapt the models in case of inconsistencies for a cyber-physical example, namely the heating process of a laser printer. Figure 3.7 gives an overview of their approach. Software engineer and domain expert write the physical domain- specific models, whereas the general purpose software module is implemented by the software engineer. Composition filters are used for composing the physical models and software models. They communicate with the physical models via events and with the software modules via messages. Static analysis is used to verify the phys- ical models and composition filters at design time and a special interpreter for the domain-specific physical models performs the runtime verification.
Wombacher discusses the correlation of physical objects and business processes in [Wom11b] and the issue of detecting potential errors in the corresponding sensor infrastructure in [Wom11a]. He distinguishes between two possibilities of correlat- ing workflow and sensor data: a) to trigger a state transition in the control flow of a process based on sensor data; and b) to monitor the effects of the workflow instance execution based on changes within the corresponding sensor data. From that, Wombacher derives multiple classes of potential errors [Wom11b]:
• Successful workflow execution with reliable sensor data, i. e., everything is ok; • successful workflow execution with unreliable/erroneous sensor data, i. e., the workflow was executed successfully but the sensor data associated with the workflow is incorrect;
• successful workflow execution with undocumented changes, i. e., ad-hoc changes within a specific workflow instance are not documented, but the instance is executed successfully;
• effect of workflow evolution, i. e., the workflow is adapted and applied to new resources that are not able generate the necessary sensor data;
• effect of changes on sensor infrastructure, i. e., faulty or broken sensors lead to corrupt data that cannot be correlated to the respective workflow instances. In [MDCM17] Meroni et al. present an artefact-driven approach to monitor busi- ness processes. Artefacts of a BPMN process are enriched with additional data and information regarding their runtime states and process-related events to enable the monitoring and compliance checking of the artefact’s and process instance’s lifecy- cle among all involved process participants. They use a scenario from logistics as running example, which is implemented by an IoT software infrastructure.
As part of their SmartPM process management system [MMS14], Marrella et al. apply the Situation Calculus [LPR98] to formally specify preconditions and post- conditions of the execution of process activities. That way, they are able to determine deviations of the expected outcome of the process execution from its actual effects on context factors or process resources. A more detailed description of the SmartPM system is given in Section 3.6.
Conclusion
Table 3.4.: Evaluation of Related CPS Cyber-physical Synchronization Approaches for Workflows 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-* R8 Retrofit [PLM16] o - o - o - - - [Sto15] - - - - + - - - [CR15] - + o - + - - - [RvWLB15] - - - - + - - - [RSI+17] - ++ + - o - - - [DRSA12] + o - - + + - - [Wom11b] + - - - + o - - [MDCM17] + o o - + - - -
++ = Special Feature (USP); + = supported; o = partially supported; - = not supported
Table 3.4 presents an overview and evaluation of work related to the aspect of Cyber-physical Synchronization for WfMSes that we investigated with respect to the identified requirements. We distinguish between four levels of support regarding the fulfilment of the individual requirement: Special Feature/Unique Selling Propo- sition (++); supported (+); partially supported (o); not supported (-).