Adaptation during runtime of digital selves in an actor system is enabled through running digital twins as reference subjects. Dynamic adaptation is based on a trigger, such as an emotional signal or the output of a cooperation function, which requires special behavior specification. Message Guards as introduced in Part I of this book allow defining at design time how special context factors influencing behavior can be handled at runtime (i.e., once an actor (subject) has been instantiated).

Switching from routine behavior to another (non-routine) behavior is based on flagging states in the regular behavior sequence serving as triggers and (re-)entry points. In the addressed teaching class example, the Message Guard can be applied when a threshold of students is not willing to leave the room in case an emergency has been reached. Once the flag is raised at runtime, either substitutive procedures that eventually return control to the regular behavior sequence or complementary behavior is triggered that does not return control to the regular behavior sequence.

Message Guards can be flagged in a regular behavior process in any state of an actor when modeled as subjects. The receipt of certain messages, e.g., to abort the process, always results in the same processing pattern. Hence, this pattern should be modeled for every state in which it is relevant. The design decision that has to be taken concerns the way in which the adaptation occurs, either extending an existing behavior or replacing it from a certain state on. In the teaching class example, returning to the original behavior sequence (regular SBD) is given when the emergency case has been handled, and no further intervention of other actors is required when lecturing the class. Replacement of the regular procedure would be required when the SoS Handler subject and, as a follow-up, other actors have to be modified in the behavior sequences.

Message Guards can be applied to any context management issues as part of the digital twin representation. Each digital twin component can be enriched with behavior sequences required for contextual inquiries and processing affecting actor behavior (see Fig. 11.1). The behavior extension is based on the analysis of requirements and messages exchanging context data between the components.

Fig. 11.1
figure 1

Generic SoS architecture

Full size image

The component marked in red in Fig. 11.1 is the SoS entry point for handling contextual requirements, e.g., stemming from a certain situation. Each component has a Message Guard for handling SoS requirements, e.g., taking care about the cooperation status of an actor. It communicates with the SoS Handler, e.g., taking into account cooperation with respect to sympathy or other emotional actor states. The latter supports the specification of context requirements and is able to send and receive data from all CPS components.

On request, CPS components deliver data that is matched with context requirements. As the SoS Handler could have access to conventions and regulations, it can recommend activities to actors and address the components involved to meet the contextual requirements. For instance, in case external students should become part of a project team, messages containing information on cooperation willingness are exchanged with other actors until the respective requirements can be met.

Once each actor is represented in an executable subject-oriented model, it can control the exchange of context-relevant data supported by a proper operational platform, such as the compunity suite (http://www.compunity.eu). By monitoring the flow of messages between the networked CPS components, actors can reflect on the current status of achieving contextual requirements. In case they decide to change that flow of information, the approach offers access to the digital twin modeling capability via subject-oriented models. When every twin model can be executed automatically, actors can adapt their requirements to changing context during runtime.