In this chapter, we first motivate an integrative behavior-centered perspective on representing development knowledge, such as digital twins which serve as baseline and frame of reference for design and execution. Following the concepts presented in Stary (2020b), we introduce the Internet of Behavior as system carrier and advocate design-integrated engineering based on role and task understanding of active system elements. As distinct features, (1) functional and communication aspects are treated equally, and (2) models carry on all required information for automated execution. Thereby, the major development task is semantic modeling.

1 The Internet of Behaviors as System Carrier

Digital transformation increasingly binds individual activities to digital actions through various technologies which has led to the “Internet of Behaviors” (IoB) (Panetta, 2019, p.1) as follow-up to the Internet of Things (IoT) (Kidd, 2019, p.2). Consequently, behavior data direct activities of socio-technical systems in real time, encouraging or discouraging human behavior. For instance, a home healthcare support system can adapt its behavior to the situation at hand based on received sensor data and trigger specific actuator behavior based on algorithmic processing and data analytics. This trigger could lead to adjustments of human behavior, e.g., taking care of a certain order of using healthcare appliances (cf. Tan & Varghese, 2016).

Hence, the design of IoB systems based on behavior (specifications) is a moving target. As such, it is an immanent and pervasive engineering task. It requires technical and technological capabilities, when “by 2023, 40% of professional workers will orchestrate their business application experiences and capabilities like they do their music streaming services” (Panetta, 2019, p.4). Due to their cyber-physical nature—they are based on the IoT—IoB systems require a model representation (termed digital twin) as baseline for continuous design-integrated engineering (cf. Lee, 2008).

Any modeling approach should enable the dynamic arrangement of networked behavior encapsulations and, thus, represent an operational framework of informed and continuous transformation. Thereby, transformation should be able to utilize IoB data for predictive analytics. Recent results indicate for specific domains the utility of algorithmic data analytics (cf. Zhiyuan et al., 2020). Featuring autonomy and digital selves, we rather need to target opportunistic IoB system behavior (cf. Guo et al., 2013), building on mutual actor awareness (cf. Gross et al., 2005) and value-based co-creation (cf. Pera et al., 2016), than unidirectional control of stakeholder or system element behavior (cf. Savitha & Akhilesh, 2020).

When aiming to identify meaningful behavior patterns, the IoB, analogous to the IoT, provides an Internet address for behavior patterns. It enables accessing systems or addressing individuals engaged with a specific behavior. Such a connection can be used in various ways and directions, for data delivery, joint processing, or taking control. Like for IoT, the power of IoB is the scale that matters. Several billions of systems and/or actors and, thus, behavior patterns populate the network and represent a unique source of collecting data and passing it on for processing, controlling, and, thus, influencing behavior through generated information.

Figure 3.1 aims to categorize the technological advancements that are characteristics of IoB developments on the left side and to develop a corresponding behavior perspective on the right side. After introducing IoT on an elementary or syntactic level, system components have been captured by semantic technologies which enabled contextual process design. Turning passive actors to active ones, and adding intelligence to system components, has led to self-organizing actors, which allowed the emergence of novel system behavior (Guo et al., 2011) referring to the active system elements and future developments.

Fig. 3.1
figure 1

IoB conceptualization with design intelligence

Full size image

Complex Adaptive Systems, as previously discussed, focus on the interdependence of behaviors. The concept raises awareness for the consequences of individual behavior on other actors or system components, as individual behavior influences the activities of other actors in the system. In this way, self-referential interaction loops develop in a specific networked setting. Understanding such a mechanism helps in the development of predictive analytics, since behavior can be anticipated based on the history of individual action and received inputs from other actors driven by those actions.

From an operational perspective, IoB systems are based on Internet-connected technologies. Thereby, the IoT architecture serves as baseline and is represented traditionally as a stack (see Fig. 3.2). IoT-based architectures facilitate interaction and data exchange between systems, their components, and users. They take into account the business perspective as well as the environment of an IoB system influencing its use and the behavioral integration of its components. The operational core consists of sensor components and the software managing them (asset part) as integrating software and hardware allows for embedded system design. Architecture components connected with the asset part are Internet components to share all kinds of collected data. They ensure connectivity of networked assets and the exchange of data. The logic to manage collected data and their transmission for processing is operated in the cloud.

Fig. 3.2
figure 2

The IoT stack (according to Kwon et al., 2016) as baseline to design-integrated engineering

Full size image

Cloud computing services allow omnipresent and scalable access and distribution of system features. They comprise storing data in a database, applications and platforms to run services, rule engines to enforce (business) regulations, and analytics to generate decision-relevant information. Finally, all elements need to be related to the context of an application. It contains all relevant information for design and operation (termed external information in the stacked architecture). Another part of the stack components is composed of overarching performance-relevant topics, in particular authentication and security. Both affect the interactive and automated use of architecture components, thus running the overall system.

It is the upper part of the stacked architecture injected by external information that is crucial for design-integrated engineering (see Fig. 3.2). At some point in time, stakeholders acting in specific roles need to access the IoT system, triggering data collections or interpreting the results of analysis. They also need to know the involved component for developing and maintaining the IoT technologies, either directly or via a corresponding model (digital twin).

The ongoing proliferation of connected system components drives current application development and propagation in essential domains, such as healthcare (cf. Bhatt et al., 2017) and production industry (cf. Gilchrist, 2016). Large capabilities for intelligent system design are enabled by autonomous data collection through sensor systems, as well as the dynamic adaptation and remote control of devices through actuators. Internet-based services (cf. Bertino et al., 2016) are coupled with physical objects extending their capabilities, such as signaling the possibility of exhaustion in the case of smart shoes. The provision of such services is based on the recording of sensors and operational data, the transmission via digital networks, and the interpretation and delivery of analysis results, e.g., via apps.

When products originally designed for a specific use get enriched in scope, the design process needs to take into account further services and processes. Consider clients of a healthcare appliance including smart shoes who need to be provided with health intelligence according to their individual use of the product. Design tasks need to encounter components for monitoring and requirements articulation, leading to (dynamic) adaptation of an IoB system. It enables novel relationships between stakeholders (in particular between producers and consumers) and components, intermingling operation and development (cf. Larivière et al., 2017).

2 Semantic Modeling for Dynamic Evolvement

A digital twin architecture can build upon patterns of interaction as design elements for analysis and refinement to operation. Any organization can be represented as a value stream network (cf. Allee, 2003, 2009) that corresponds to a self-adapting complex system. Such a system can be modeled by identifying patterns of interactions representing relations between Behavior-encapsulating Entities (BeEs) as nodes of the network. Each BeE in a certain organizational role produces and delivers assets along acts of exchange (transactions).

Since transactions denote (organizational) task accomplishment through exchanges of goods or information, they encode the currently available network intelligence (determining the current economic success). Each BeE can be considered as IoB element in an Internet-based economy. BeEs send or extend deliverables to other BeEs. One-directional arrows represent the direction in which deliverables are moving in the course of a specific transaction. The label on the arrow denotes the deliverable. Deliverables are those entities that move from one BeE to another. A deliverable can have some physical appearance, such as a document or a tangible product, or be of digital nature, such as a message or request for information.

The concept of exchange is considered a bi-directional value stream: An exchange occurs when a transaction results in a particular deliverable coming back to the originator either directly or indirectly. It ranges from feedback on a BeE deliverable to a new request “for more of the same” or to a change of behavior. Exchanges reveal patterns typical of organizational relationships, e.g., goods and money.

In the following, we exemplify a BeE map for home- and healthcare involving a service company providing innovative instruments (methods and technologies) for customers with specific healthcare needs. The IoB system should help tracking a person’s blood pressure, sleep patterns, diet, and blood sugar levels. It should alert relevant stakeholders to adverse situations and suggest behavior modifications to them toward a different outcome, such as reducing blood pressure through a different diet or reducing the dose of pills for the sake of daytime agility. Moreover, the system should provide everyday convenience, in particular alerting for timely healthcare and medical supply.

The BeE network helps scoping the design and transformation space and leverages potential changes for each BeE. Accurate service provision for wellbeing of a customer in home- and healthcare is the overall goal of the exemplified IoB system. It monitors health and living conditions to continuously improve service provision.

The first step designers need to consider in the modeling process is the set of organizational tasks, roles, or units, as well as functional technology components and systems that are considered of relevance for service provision. They represent BeEs and include the IoT devices Blood Pressure Measurement, Sleep Pattern Monitoring, Diet Handler, Medication Handler, and Personal Scheduler, as well as external medical services. Each of the identified roles or functional task represents a node in the BeE network which is partially shown in Fig. 3.3.

Fig. 3.3
figure 3

Part of a BeE network scoping and structuring the transformation space

Full size image

In the BeE network in Fig. 3.3, a specific pattern can be noticed. The Medication Handler triggers Blood Pressure Measurement, involving the Personal Scheduler to start in time. In the network without dotted transactions, Blood Pressure Management is a sink of information. Hence, in order for information not to result in “dead ends,” information on blood measurement needs to be passed on explicitly to the Medication Handler and Personal Scheduler. In this way, significant knowledge can be exchanged, and further action can be designed in the case of adverse conditions.

At this stage of design, exchange relations can be added, as indicated by the dotted transactions in Fig. 3.3. In the simple example, Blood Pressure Measurement should be in exchange relations to the Medication Handler and Personal Scheduler, as the medication could be adapted and optimized according to the time and current condition of the client. It needs to be noted that this is a semantically grounded supplement requiring systemic domain knowledge and human intervention, in contrast to syntactically checking whether each BeE interacts with all others in the network.

Refining design representations, such as the BeE network, toward digital models of IoB systems serves as the baseline for engineering. Recognizing the behavior of networked actors or system components requires not only to capture the duality of activities, namely, in terms of functional (or technical) and communication actions, but also their autonomous while synchronized acting as networked nodes. Hence, we propose to utilize the choreographic representation and engineering scheme stemming from the Subject-Oriented Business Process Management (Fleischmann et al., 2012a, 2015). It enables embodying BeE network and refining the involved (socio-technical) components, thereby generating behavior-centered digital twins.

For design-integrated engineering, subject-oriented models can be refined until being executable, in order to provide operational feedback to designers. These modeling and execution capabilities view systems as sets of interacting subjects. Subjects are defined as behavior encapsulation. They address tasks, machine operations, organizational units, or roles people have in a specific context, such as business operation, and correspond to the Behavior-encapsulating Entities (BeEs) defined for analyzing value streams as described above. From an operational perspective, subjects operate in parallel. Thereby, they exchange messages asynchronously or synchronously. Consequently, the transactions forming value streams can be interpreted as transmissions of messages between subjects.

IoB systems specified in terms of subject-oriented models operate as autonomous, concurrent behavior entities representing distributed (IoB) elements. Each entity (subject) is capable to performing (local) actions that do not involve interacting with other subjects, e.g., calculating a threshold value of blood pressure for a measurement device in medical care. Subjects also perform communicative actions that concern transmission of messages to other subjects, namely, sending and receiving messages.

Subjects as behavior encapsulations are specified in adjacent diagram types: Subject Interaction Diagrams (SIDs) and Subject Behavior Diagrams (SBDs). They address different levels of behavior abstraction: SIDs a more abstract one, denoting behavior entities and an accumulated view on message transmissions, and SBDs refining the behavior of each subject of a SID by revealing the sequence of sending and receiving messages as well as its local actions (i.e., functional behavior).

SIDs provide an integrated view of an IoB system, comprising the subjects involved and the messages they exchange. A part of the SID of the already introduced home- and healthcare support system is shown in Fig. 3.4. According to the SID BeEs, it comprises several subjects involved in IoT communication. In the figure, the messages to be exchanged between the subjects are represented along the links between the subjects as rectangles, already including the supplemented ones from the value stream analysis:

  • The Personal Scheduler (subject) coordinates all activities wherever a client is located (traditionally available on a mobile device).

  • The Medication Handler takes care of providing the correct medication at any time and location.

  • The Blood Pressure Measurement subject enables sensing the blood pressure of the client.

  • The Shopping Collector contains all items to be purchased to ensure continuous quality in home healthcare.

Fig. 3.4
figure 4

Sample Subject Interaction Diagram representing a home healthcare appliance

Full size image

The client user handles the measurement device and needs to know when to activate it and whether further measurements need to be taken. The Shopping Collector receives requests from both, the Medication Handler when drugs are required from the pharmacy, physician, or hospital and the Personal Scheduler, in case further medicine for the client user is required.

State transitions are represented as arrows, with labels indicating the outcome of the preceding state. The part shown in Fig. 3.5 represents a scheduling request to the Personal Scheduler subject sent by the Medication Handler subject, in order to demonstrate the choreographic synchronization of behavior abstractions (cf. Wen et al., 2017). The figure reveals the parallel operating nature of the two subjects involved in the interaction. Once the need for (re)scheduling—modeled as send activity—is recognized by the Medication Handler, a corresponding message is delivered to the Personal Scheduler. When the Personal Scheduler has received that message, the request can be processed, either recognizing a conflict or fixing an entry into the schedule. In both cases, the result is delivered by “send reaction” to the Medication Scheduler. The subject that has initiated the interaction can now process the results, i.e., the Medication Handler processes the reaction of the Personal Scheduler (modeled by the function of the respective SBD).

Fig. 3.5
figure 5

Sample Subject Behavior Diagrams and message exchange upon request

Full size image

Each subject has a so-called input pool as a mailbox for receiving messages (including transmitted data through messaging that are termed business objects). Messages sent to a subject are kept in that input pool together with their name, a time stamp of their arrival, the data they transport, and the name of the subject they come from. The modeling designer can define how many messages of which type and/or from which sender can be deposited. The modeler can also define a reaction, in case messaging restrictions are violated, e.g., to delete arriving messages or to replace older messages in the input pool. Hence, the type of synchronization through messaging can be specified individually.

Internal functions of subjects process (the transmitted) data. In our example, the subject Blood Pressure Measurement has a counter for each application. An internal maintenance function increases the counter by one when the client user activates the device. The function can either end with the result “sufficient energy” or “change battery.”

Once a Subject Behavior Diagram, e.g., for the Blood Pressure Measurement subject, is instantiated, it has to be decided (1) whether a human or a digital device (organizational implementation) and (2) which actual device is assigned to the subject, acting as technical subject carrier (technological implementation). Validation of SBDs is sufficient for interactive process experience and testing process completion. Besides academic engines, e.g., UeberFlow (Krenn & Stary, 2016) or SiSi (Elstermann & Ovtcharova, 2018), commercial solutions, such as Metasonic (www.metasonic.de), Compunity (www.compunity.eu), or actnconnect (www.actnconnect.de), can be used. Since neither the input pool nor the business objects are part of the modeling notation, it depends on the environment and runtime engine used for development, at which point in time, and in which form data structures and business logic determining the communication on the subject instance level can be specified for pragmatic process support.

Dynamic adaptation is based on a trigger, such as a result from performing a function or a sensor signal, which requires special behavior specification. It can be handled according to S-BPM’s concept of event processing, thus allowing to capture variants of organizational behavior at design time (cf. Fleischmann et al., 2012b). The trigger to dynamic adaptation independent to its implementation can carry some data as payload. For instance, with the trigger “blood pressure above threshold,” some information can be tagged to the physical device. Like an event, a data object representing a trigger can carry three types of information: header, payload, and plain content. The header consists of meta-information about the trigger like name, arrival time, priorities, etc. The payload contains specific information about the triggering event. Finally, a trigger can also contain free format content.

With respect to operation and model execution, triggers are messages. Messages of a S-BPM model represent event types. Once a process instance is created and messages are sent, these messages become events. If messages are sent and kept in the input pool, they get a time stamp documenting their arrival time. Instantaneous events can be handled by Message Guards. They are modeling constructs to represent behavior variants including the conditions when which variant is relevant and should be executed (see Fig. 3.6).

Fig. 3.6
figure 6

Dynamic behavior adaptation using Message Guards

Full size image

For instance, the message “call emergency service” from the subject Blood Pressure Measurement can arrive at any time when delivering data from measurement. This message is handled by a Message Guard. In that Message Guard, the reaction of an instantaneous message is specified, e.g., the emergency service is called by the Personal Scheduler subject, since reaching a certain threshold of the blood pressure indicates the need for medical expert intervention for the concerned client.

Message Guards as shown in Fig. 3.6 allow handling adaptive behavior at design time. The specification shows how critical cases are handled at runtime (i.e., once the subject has been instantiated), either by humans or technological systems. The general pattern reveals that jumping from routine behavior (left side) to non-routine behavior is based on flagging functions serving as triggers and (re-)entry points. In the addressed home healthcare example, the Message Guard can be applied when a threshold of Blood Pressure has been reached. Once the flag is raised at runtime, either substitutive procedures, returning to the regular SBD sequence (see left side of Message Guard), or complementary behavior, leaving the originally executed SBD (see right side of Message Guard in Fig. 3.6), is triggered.

Message Guards can be flagged in a process in various behavior states of 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 each state in which it is relevant. The design decision that has to be taken concerns the way how the adaptation occurs, either extending an existing behavior or replacing it from a certain state on.

In the home healthcare example, returning to the original sequence (regular SBD sequence) is given when the called emergency service in the case of high blood pressure does not require any further intervention of medical experts. Replacement of the regular procedure, however, is required, in case the Medication Handler subject and, as a follow-up, the Personal Scheduler subject (referring to the time of medication) have to be modified.

Once the organizational transformation includes predictive analytics, its integration needs to be structured according to its context (cf. Sodero et al., 2019). Figure 3.7 shows an organizational approach for embodying predictive analytics. The developed pattern is based on a Monitor subject that is triggered by a function in an idle loop observing an IoB system. The monitored data needs to be evaluated to identify the need of adaptation. For algorithmic decision-making, a (business) rule base could be of benefit.

Fig. 3.7
figure 7

Sample SID for dynamic behavior adaptation using Predictive Analytics

Full size image

Recognizing the need of adaptation requires business intelligence stemming from a Predictive Analytics subject. According to the behavior data available and the calculation model to either predict the behavior of the acting or the behavior of other interacting subjects, a proposal is generated. In order to avoid re-iterating certain behavior patterns, the adaptation request is stored, together with the newly generated proposal. The latter will be evaluated for effectiveness and efficiency.

With respect to our home healthcare case, organizing the setting could be challenged on whether medical experts need to be contacted once the blood pressure is higher than a specific threshold by predicting that an additional data analysis (e.g., diet patterns) could help avoiding triggering emergency services. Implementing such a proposal requires extending the SID with a Diet Handler subject that can deliver timely data on the diet behavior of the client. It would need to interact with all other subjects, as its functional behavior to provide the requested data leads to novel patterns of interaction.

Each enrichment can be iteratively tested along design-evaluation iterations of various granularities. Consequently, whenever the transformation space is to be enhanced with choreographic intelligence, the resulting additional requirements for a solution can be exemplarily met by (re-)designing the artifact, demonstrating and evaluating the envisioned enhancement. In this way, even variants of system intelligence can be explored and checked for viability.

Digital twins based on executable models enable threads for simulation and operation of IoT-based systems and have gained recent research attention (cf. Pang et al., 2021; Stary, 2021), also driven by Industry 4.0 needs for real-time operation, integration capabilities, and high-fidelity representation. From the three perspectives introduced in the beginning for structured understanding, a development cycle can be concluded for digital twins (see Fig. 3.8). Individual role understanding leads to model and structure collectives that are operated by technologies and can be adapted to further needs, including socio-emotional behavior finally leading to digital selves.

Fig. 3.8
figure 8

Digital twins as behavior representations

Full size image

The notation has not only the character of a modeling language but rather serves as means of orientation for various stakeholder groups, including users and developers. Hence, a certain representation scheme, such as subject-oriented modeling, has specific roles for digital twin development:

  • It helps in organizing a collective by means of structure elements.

  • It supports the design of ecosystems as a boundary object mediating between various stakeholder groups, including domain experts, developers, and users.

  • It facilitates implementation through detailing structures and processes for operation.

In the role of a user of digital twins, stakeholders make use of a systems or product and experience the functionality through its features. By putting the functionality into individual context of use, it is not only shaped by individual situations of use but also shapes its future use and actions of the user. By utilizing the features of the product, not only cognitive factors but also affective, emotional, and social aspects play a crucial role and build up experiential knowledge.

In the role as developers, humans utilize organizational and technological capabilities to refine and engineer functional requirements referring to user demands and support needs. Technology-driven activities include performance-related items aside from usability and user experience. In the case of cyber-physical settings, decisions on heterogeneity and connectivity play an important role from an engineering perspective. They influence adaptability during runtime to a large extent.