A goal Go aggregates objectives oi∈ O that define the expected influence of a par-
ticular process step on the physical world. As pointed out in requirement R5, the aspect of Cyber-physical Synchronization is especially important for CPS to ensure a consistent view between the virtual and physical world (cf. Section 2.6). The infor- mation contained in the goals is used to check if the process execution was successful and if its outcome is as expected (w. r. t. the satisfied condition sc) or–if not–to find possible compensation actions for the erroneous process instance (w. r. t. the com- pensation condition cc). In this work, the notion of Cyber-physical Consistency CP C is introduced as an extension of the well-known Atomicity, Consistency, Isolation, Durability (ACID) criteria for distributed systems and databases [GR92].
State Synchronization Actuator Call C ybe r W or ld Smart Ho me SwitchOnLight Start End Phy sic al W or ld Ho me ActivateLight Switch assumed state actual state Response SC,t SP,t
Figure 4.19.: Synchronization Between Cyber World SC,t and Physical World SP,t.
In order to verify that the process execution is in a state of cyber-physical consis- tency, its assumed physical state (Cyber State SC,t as defined as target values in the
satisfied conditions of process objectives) is compared to the actual real world state (Physical State SP,t as measured by sensors) of the entities involved in the process
execution as shown in Figure 4.19 for the smart lighting scenario process. Cyber- physical consistency (cf. Definition 3) is reached if both states correspond to each other or if they can be synchronized. It is violated if there is a mismatch between both states. With reaching cyber-physical consistency, we are able to verify that the process execution was successful or detect exceptions/errors. The example shows a simple process issuing a service call to a dimmer actuator to switch on the light in
4.6. Cyber-physical Consistency
a certain room in the smart home. A positive service response indicates that the request was executed successfully and the process terminates. However, a broken or worn off light bulb, hardware issues, real world obstacles or wrong parameters may lead to an undesired physical state SP,t of the light switch, which may not be
detected by the IoT device’s control software or WfMS. In case the service is not able to detect these issues, the cyber state SC,t (light on) and process execution
state (successful ) do not correspond to the physical state SP,t(light off ) and actual
execution state (unsuccessful ), which means that cyber-physical consistency is vio- lated and needs to be restored for that example.
To have a more formal representation of the concept of Cyber-physical Consis- tency (CP C) we denote:
Definition 1 Physical Process Context SP,t
Ct= {c1,t, . . . , cn,t} is a set of all physical context attributes ci,t of CPS at a given
point in time t. A context attribute is defined as a tuple ct= (n, vt), where n ∈ N
represents a unique identifier from a set N of identifiers and vt ∈ Vt represents a
value from a set Vt of context values at a given point in time t. We define SP,t⊆ Ct
as a set of all physical context attributes that are manipulated by or relevant for the execution of a specific process (step) at time t as defined within the objectives oi ∈ O
of the process step’s goal Go (Physical Process Context). SP,t represents the actual
(physical) state of the process execution in CPS at a given point in time t.
Values can be numeric values for measurable factors but also more abstract con- cepts, e. g., execution states or locations. The physical process context refers to phys- ical factors whose states can be measured by sensors or abstract values depending on the respective sensors (e. g., light=on) as addressed by the corresponding context paths cpi ∈ CP . For our light example, a context attribute ci,t ∈ SP,t could be the
light influenced by the respective process instance identified by n=lightSource1 and having a specific value at time t: vt=700 Lux.
Corresponding to the previous definition we denote: Definition 2 Virtual Process Context SC,t
Ct′ = {c′1,t, . . . , c′n,t} is a set of all virtual representations of physical context at- tributes c′i,t at a given point in time t (assumed state of the physical world). A virtual context attribute is defined as a tuple c′t = (n′, v′t), where n′ ∈ N repre- sents a unique identifier and v′t∈ Vtrepresents a value at a given time t. We define
SC,t⊆ C
′
t as a set of all virtual context attributes that are manipulated by or relevant
for the process execution (Virtual Process Context). SC,t is the assumed (virtual)
state of the physical process execution in CPS at a given point in time t.
The virtual process context attributes correspond to the right sides of the condi- tions referred to in the compensation condition cc and satisfied condition sc via the corresponding context paths cpi∈ CP used within the objective specifications. The
process designer specifies virtual context attributes as target values in the satisfied conditions for the execution of individual process tasks or process instances. At
runtime, the values of these virtual context attributes are the values that the com- puter assumes for the corresponding physical context attributes at a specific point in time t–inconsistencies/deviations from the actual physical context values can be possible.
From the previous definitions we derive the condition for the process execution being in a state of cyber-physical consistency (CP Ct) at a given point in time t:
Definition 3 Cyber-physical Consistency CP Ct
For all relevant context attributes ct∈ SP,t(defined in the objectives’ context paths)
of the actual physical state (cf. Definition 1), there exists a corresponding virtual context attribute c′t∈ SC,t of the assumed state (cf. Definition 2) where n = n′ and vt= v
′
t (i. e., the identifier and value of both context attributes are equal).
(4.1) CP Ct⇔ ∀ct: ct∈ SP,t, ∃c ′ t: c ′ t∈ SC,twhere ct≡ c ′ t with ct ≡ c ′ t : (n = n ′ ) ∧ (vt= v ′ t)
Analogous to that, we define the condition for the process execution not being in a state of cyber-physical consistency at a given point in time t based on the criteria defined in the corresponding objective:
Definition 4 Cyber-physical Inconsistency ¬CP Ct
There exists at least one context attribute ct∈ SP,t of the physical state (cf. Defi-
nition 1) that has a corresponding virtual context attribute c′t∈ SC,t of the assumed
state (cf. Definition 2) where n = n′ and vt̸= v
′
t (i. e., the identifiers of both context
attributes are equal but their values are different and therefore inconsistent). (4.2) ¬CP Ct⇔ ∃ct: ct∈ SP,t, ∃c ′ t: c ′ t∈ SC,twhere ct̸≡ c ′ t with ct ̸≡ c ′ t : (n = n ′ ) ∧ (vt̸= v ′ t)
So far, the definitions relate cyber-physical consistency CP Ct to a specific point in
time t. One or more objectives define the expected target values for relevant context factors from SP,t and SC,t that also refer to that specific time t. Goals aggregate
multiple objectives referring to multiple points in time. Hence, goals can be used to specify overall cyber-physical consistency CP C criteria for a certain process activity, subprocess or process referring to multiple points in time.
Robot Movement Example: Figure 4.20 shows a more complex example of mul- tiple objectives specified for the process-controlled movement of a service robot. The overall goal is to move the robot from its docking station to a specific room identified via its x,y-coordinates on the robot’s internal map (6,10). The correct starting and end points as well as two intermediate stopping points of the robot’s trajectory are defined as individual objectives of the corresponding process step in the order the objectives need to be fulfilled. The fulfilment of these objectives has to be analysed and possibly corrected continuously during the execution for the sin- gle process step. The four objectives relate to the specific physical context factors from the actual physical state SP,t as target values that represent the robot’s loca-
4.6. Cyber-physical Consistency
time t does not necessarily need to be an actual date but it can also be related to a particular sensor event (e. g., when the robot passed a light barrier or reports its arrival). From the figure, we see that during the actual movement of the robot, an inconsistency between the physical state SP,t and the cyber state SC,t occurred due
to an incorrect positioning of the robot at time t2 in the physical world. The robot
assumed the correct position (4,6) and stopped, publishing an “arrived” event. The corresponding objective’s satisfied condition defines successful process execution as the robot emitting an “arrived” event and an external tracking system confirming the correct physical location (4,6). The compensation condition indicates an in- consistency and error during process execution when the robot emits the “arrived” event and the external coordinates not matching the specified target coordinates. The compensation condition became true for the third objective at time t2 as the
external system measured other coordinates (4,8). Therefore, the corresponding ob- jective was not fulfilled and with that, the goal is left unsatisfied and the overall cyber-physical consistency is violated. Although the robot reached its correct final position at time t3, one of the objectives is unsatisfied. We rely on the process
designer to specify reasonable and important objectives for the individual process steps, which is why we consider all objectives as equally important. Therefore, the unsuccessful fulfilment of one objective leads to a violation of the overall consistency. Optional or weighted objectives and also more advanced concepts, e. g., regarding Eventual (Cyber-physical) Consistency [Bur14] have to be discussed as part of fu- ture investigations. One of the major goals of this thesis is to detect inconsistencies during process execution as described in this example (Requirement R5 : CPS Sync) and to “repair” the inconsistency before the process execution continues (Require- ment R6 : CPS Errors). We aim at detecting and repairing these inconsistencies at the workflow level to remedy missing functionality, issues or errors, and imprecisions related to the individual process resource (i. e., CPS entity, here: robot). An alterna- tive to specifying the movement targets of the robot by four objectives in one goal for one process step and checking this goal continuously during execution, would be to model four individual process steps for driving to the individual targets and defining the goals to contain one objective each per process step, which is checked during the execution of the individual process step.
Figure 4.20.: Inconsistent States of the Movement Path Coordinates of a Service Robot controlled by a Process.
CPS workflows are abstract virtual concepts that do not have a physical equiva- lent. The execution of CPS workflow instances can be traced through their effects on the physical world, i. e., changes within context attributes, states and other prop- erties of the physical environment, of things and objects, or of humans. The parts of a workflow that are able to modify these factors are related to tasks involving sensors and actuators, which are the interfaces to interact with the physical world (cf. Figure 4.19). Other workflow elements, e. g., split and merge operators or the concepts of processes and subprocesses cannot be directly synchronized to physical representations. The extension of the workflow meta-levels depicted in Figure 4.1 into the physical world and introduction of a new InstanceOf relation to represent the virtual workflow instance in the physical world is therefore only partially possi- ble or reasonable–mostly related to service invocation tasks to call physical actuator commands. As proposed with the newly introduced concept of Cyber-physical Con- sistency (cf. Definition 3), the evaluation of relevant context values and states in the physical world that were influenced by a workflow instance presents a reason- able way of correlating the physical effects of the process execution with the virtual model/representation of the process (instance). We will elaborate on the relation be- tween CPS workflows, cyber-physical consistency and cyber-physical objects/digital twins as well as on cyber-physical transactions and ACID criteria for CPS workflows in Sections 6.10 and 6.9.
Consistency Levels and Ranges
Depending on the application domain, maintaining a strict level of cyber-physical consistency CP C regarding all relevant physical context attributes from SP is not
always necessary or feasible–especially in the physical world where a lower level of precision is usually sufficient for tasks to be completed than for processes in the virtual world. While, for example within smart factories a high level of precision is required to yield a high product quality, context factors and other criteria defined in goals and objectives for smart home environments can be in a certain range or below/above certain thresholds to achieve the desired levels of comfort and qual- ities (e. g., with respect to the room temperature or illumination). As shown in the exemplary objectives, we support the definition of conditions for success and error criteria in a more fuzzy way based on comparison operators to specify–besides equality–thresholds and ranges for measurable (numerical) context attributes as ap- plied in classical control theory.
This is complemented by an optional Consistency Level Lo for an objective o:
Definition 5 Consistency Level Lo
The Consistency Level Lo can be specified optionally as part of an objective oi =
(on, CA, sa, ca, Lo). It defines the minimal threshold on a relative scale (i. e., 0 to
100 %) that has to be reached for the particular numerical context attribute to fulfil the objective oi (i. e., to evaluate the satisfied condition positively).
We took this concept from the field of Approximate Computing as it promises to reduce costs and overhead introduced by additional computations for analysis of objectives and execution of compensating actions in error cases [HO13]. With