Digital Twin conceptual framework for improving critical infrastructure resilience

Informal model

The Digital Twin gets its name twin from its digital correspondence with the section of the real world, digitally reflecting the aspects of that section that are deemed relevant. Based on this leading concept, we define the Digital Twin as a meta-concept that contains both a real-world section and a virtual replica of it, a twinning mechanism to couple both, and accompanied by tools to perform smart actions and ensure the intended added value (Figure 4).

The real-world section can involve any set of systems of interest, from individual machine parts to factories, from buildings to cities, from processes to complex interconnected systems-of-systems, and from communities to networked socio-technical systems such as critical infrastructures. It is often alternatively referred to as an analog system, real system, or physical system, even though it may itself contain intelligent control systems implemented in software. The system boundaries define the section of the real world that is captured in the Digital Twin and depend on the use case.

Virtual replica and twinning

Initializing the virtual replica is the first step towards creating a Digital Twin with a modeling step and the launch of data acquisition (Figure 4). Structural models describe the composition and characteristics of the modeled section of the real world, such as a CAD model or a component list. They are accompanied by behavioral models that cover dynamics and functionality, such as simulation models or models created using machine learning or artificial intelligence. A sophisticated Digital Twin typically incorporates both types of models, with the structural model often serving as a semantic container for current and historical state information and the behavioral models. The kind and sophistication of the semantic container depends on the intended use case and the nature of the data, which may range from raw sensor data and unstructured information like natural language text or speech, non-normalized photos, etc., to curated instances of data types, schema-bound data, and ontology-compliant data.

In order to keep the virtual replica in sync with the real world, a twinning mechanism is required. A Digital Twin may capture state data only at distinct times along its life cycle, it may process numerous types of events that occur frequently, it may capture sensor readings at fixed intervals, or it may sample high-resolution time series of data that represent continuous processes related to behavioral models.

Modeling comprises ‘the art of abstraction’, i. e., the need to include everything necessary in the model to keep it relevant and precise, and to omit everything unnecessary in order to keep it understandable and comprehensible. Due to this abstraction effort, the virtual replica contained in a Digital Twin is always less than the section of the real world it corresponds to.

Added value and HCI

The Digital Twin contains functionality providing added value, which is the driving factor when creating Digital Twins. Added value of a Digital Twin is everything it offers that the real-world section does not. It comes into play as soon as the plain structural and behavioral models are augmented by capabilities not present in the non-digital world.

The models within the virtual replica may be fed and ‘driven forward’ via data acquisition at runtime, such that they keep up with the current state or reflect a past state of the modeled real-world section. Additionally, models may also be ‘driven forward’ by means of the modeled behavior, simulating future behavior. This is useful for exploring what-if scenarios or for predicting future states in terms of forecasts. This potential to extrapolate is one of the great strengths of Digital Twins.

Further functionality can be provided, pertaining to categories like analysis, monitoring, optimization, prediction, planning, etc. There are three ways in which such added value can be integrated with the Digital Twin and its surroundings (Figure 4, light orange parts):

1. it may be offered to human users in the form of tools by means of a more or less sophisticated human-computer interface (HCI), e. g., AR/VR based;

2. it may directly benefit the real-world section of interest by initiating smart actions on the real-world section, with the real world section converting to a smart system;

3. it may be exported to another Digital Twin to build systems-of-systems on a digital level or vice-versa, a Digital Twin can import added value of other Digital Twins, external services and information sources.

The third variant allows a system-of-systems approach for Digital Twins, which can be beneficial for several reasons, including modularization, reuse, and multi-tenant support. Import/export functionality can address data exchange, but also services offered and used, especially when software-oriented architectures are used.

Realization details

The conceptualization and implementation of Digital Twins have to reflect the methods and concepts that mark the ongoing digitalization in the domain considered. The data acquisition, model execution, and added value related components may be computationally demanding, and 24/7 availability may be required. Therefore, sophisticated Digital Twins may be realized as modular platforms that leverage cloud architectures [6]. Edge computing may complement the solution stacks, especially in the context of data acquisition and smart actions.

The possible categories of information storage are also diverse, as common terms such as data lake, database, or in-memory storage indicate. The degree of sophistication also depends on the degree of data refinement from raw data to curated data, where elaborate data preprocessing may even be part of the added value.

Table 2 provides a concise list of selected areas that must be considered during the conceptualization and implementation of Digital Twins. Each area is denoted together with a list of keywords indicating important aspects that may be relevant in the area.

Table 2

Selected areas to be considered during the realization of Digital Twins, along with keyword lists for important aspects.

System and purpose

In order to design the components within the Digital Twin system to meet I1 (characteristics), first the system boundaries of the real infrastructure under consideration need to be defined. The surrounding world, outside of the system boundaries, causes changes and disturbing events which impact the system.

In addition, the purpose of the Digital Twin must be defined so that stakeholders, users, use cases, data sources, and design goals for the replica and tools can be derived. In a first step, scenarios with relevance for the respective infrastructure type can be identified. For example, for urban infrastructures near rivers, scenarios related to extreme weather events or flooding are considered. In later versions, the Digital Twin can be enhanced to cover additional types of disruptions and services.

The federation of multiple Digital Twins provides a method for mapping regulatory requirements (I2 regulation) to infrastructures. Along the import/export interfaces, requirements for data governance, privacy and protection as well as regulatory processes can be addressed. With appropriate interfaces, system-of-systems can be connected to build similar virtual systems-of-systems with higher complexity and including sector couplings [39]. It is crucial that the networked Digital Twins and their models represent the emerging or self-organizing behavior of the real system.

Thus, the Digital Twin concept fulfills I1 (characteristics) and contributes to I2 (regulation) when fulfilling the following requirements:

1. define the system under consideration and the purpose of the Digital Twin:

   1. determine system boundaries and appropriate time and spatial scales such as device, building, area, city or country;

   2. derive stakeholders and design goals;

   3. include complex and networked behavior as well as human behavior within the selected real-world section;

   4. allow the coupling of Digital Twins similar to the coupling of real sectors and subsystems.

Virtual replica

In constructing a virtual replica of a critical infrastructure, I1 (characteristics) requires capturing the relevant processes, structure, and behavior such that its complex and interconnected behavior is virtualized. In the context of Digital Twins, smart tools rely on the virtual replica to satisfy I1 for providing resilience capabilities (R1–R4, anticipation, monitoring, response, learning) and be suitable for the tool use case. C1 (normal operation) and C2 (crisis situation) require modeling of the system behavior both in normal operation and in crisis situations, which include dysfunctional states. Especially for being able to monitor an infrastructure in all phases of a crisis (R2 monitoring) and to respond (R3 response), computing times for simulations and increasing reaction times need to be taken into account when determining type, scale and level of detail of models.

As an example, monitoring and response (R1, R3) are enabled, when for example a purely dynamic model is complemented by temporal-spatial information, which can be used to monitor and navigate relief forces inside an infrastructure building. For this task, a model of the building with pathways and doors as well as firefighting installations, explosive substances, or other persons in the building is useful. The requirement for efficient response (R3) further demands that the possible counteractions or mitigation measures can be simulated by the model, e. g., via changed parameter settings (e. g., adjusting operational parameters), configuration update (e. g., reflecting structural updates of buildings), process changes (e. g., after a new political law has been passed), or by changing the operational mode of the system (e. g., reflecting a shutdown in the event of an attack).

In order to match these use cases and requirements, various model types may be related to each other with regard to semantic containers in terms of a temporal-spacial structure or a graph of relations. This can be achieved when using 3D models to represent the spatial aspect of the real-world section, augmented with semantic, geometric, visual and contextual aspects. Adding the time domain, in terms of geometric changes or movement of objects, they provide a temporal-spatial model and can be used as a structure to integrate other functional or behavioral models. Geometric models can be enhanced by functional modeling, such as mobility, water or electrical network models within the selected area [40]. As a side effect, temporal-spatial models enable VR/AR techniques to immerse into the virtual models within the control center.

Human behavior is an important factor in infrastructure dynamics and add further aspects to the infrastructure characteristics (I1). Agent-based modeling (ABM) is a common micro-modeling approach for socio-technical systems [1], [17] and allows simulating complex behavior in networked systems. Humans within communities cause demand for supply that can be connected through agent-based simulation, resulting in agent-demand models matching the demand towards infrastructure services.

In addition, the human factor in terms of operator error, terrorist or cyber attacks must be taken into account and distinguished from permissible usage patterns. In this case, monitoring (R3) is enhanced by models of behavioral patterns. Machine learning approaches, for example, learn “normal behavior patterns” of humans and allow to detect and classify anomalies.

The validity of the virtual replica in both a functional and a dysfunctional state (C1, C2) requires that rare events are captured by the model. Probabilistic or state modeling techniques can be used for this purpose. Exploring threshold effects of complex systems that lead to dysfunctional states and incorporating them into models will be a necessary task.

Effective monitoring (R2) depends on a timely update of the system status, reflecting all internal states as well as disruptions within the system (safety incident) and outside the system (security incident) shortly after their occurrence. Both the virtual replica and the sensing components must therefore capture the system dynamics and environmental changes in high temporal resolution. A fully synchronized virtual replica represents the current state of all variables of interest of the real object, such as operational measures, maintenance conditions, or visual characteristics.

Requirement C3 requests the Digital Twin to be a reliable and resilient tool. As the core component in the Digital Twin concept, the replica always needs to stay in sync with the real infrastructure. When cloning and decoupling the virtual replica or parts thereof from the real system it is available for a variety of analytics and research without influencing the real system [41]. Such a virtual clone is then a simulation environment, that can be used for forecasts, for scenario simulation of potential attack vectors, potential interventions, or system changes. Optimization tools can make use of the simulators. For the implementation of simulators, classical approaches are suitable, but also ML-based models and predictors, decision support tools, what-if tools, and analysis tools, e. g., based on elaborated models for root-cause analysis.

Summarizing, the Digital Twin replica can be designed such that it meets I1 (characteristics), C1 (normal operation), C3 (resilient tool) and supports all resilience capabilities (R1–R4) by implementing the following requirements:

1. construct the virtual replica to be an up-to-date projection of the infrastructure:

   1. model the system such that the model includes all required static information and dynamic behavior in an up-to-date way;

   2. all replica components need to support normal infrastructure operation as well as partly or totally dysfunctional situations during a crisis;

   3. provide clones and simulators of the virtual replica.

Twinning

R2 (monitoring) formulates the requirement to monitor the current situation within the system as well as events from the environment at all times. Disruptions might be caused from within the system or from outside. Therefore, both the replica as well as the sensoring need to cover the system state and dynamics as well as events from the environment in a timely manner. This is realized by the Digital Twin’s twinning component.

In order to monitor (R3) a system during normal operation (C1) and crisis (C2), effective sensing components are required and data is as manifold as the models. For functional models, physical sensors may be used. Other sources include weather forecasts, surveillance data, or information resulting from social networks or management systems. It also needs to be mentioned, that sensing of human behavior will remain a challenge due to privacy concerns of surveillance systems and the complexity of the matter. The retrieved data might be uncertain, insufficient, or unobservable (e. g., in crisis situations). Therefore, states must be estimated to some extent by the virtual replica. Ideally, models and tools based on uncertain data and information incorporate this aspect. Furthermore, data provenance, ownership, and privacy of data needs to be ensured and tracked by the Digital Twin.

The response to a disruption (R3) as well as anticipation (R1) require that actions are taken within the real infrastructure. These may include reconfiguring or technical containment, mobilizing relief forces, evacuating communities, or changes of procedures. Actions can take effect on the technical systems of the infrastructure and the operators, or on the communities using the infrastructures.

Because of the manifold types of potential actions and due to rare usage in crisis situations (C2), it is impossible to install automated acting components to cover all potential actions. Instead, we extend the interpretation of smart actions to include human decisions and actions on the real infrastructure. Therefore, requirement R3 (response) additionally demands a decision support system as a tool available to human stakeholders. Defined decision processes with actions executed by humans establish an alternative acting mechanism within the Digital Twin concept. Defined processes ensure de-facto automated twinning.

The twinning mechanism increases the resilience of critical infrastructures with regard to the monitoring (R2), response to disruptions (R3), and anticipation (R1). In addition, it can be designed to meet I1 (characteristics), C1 (normal operation), and C2 (crisis situation) by implementing the following requirements:

1. implement twinning to ensure the replica is up-to-date and actions on the infrastructure can be taken:

   1. provide a sensing mechanism to capture the current state of the system as well as events resulting from the environment including uncertainty and provenance information; update the replica accordingly;

   2. provide an acting mechanism such that interventions can be applied to the real-world section and are available for human control; make sure, the Digital Twin replicates these changes.

Toolbox

The general purpose of the Digital Twin in the context of this paper is to improve resilience capabilities of critical infrastructures in terms of requirements R1 to R4 (anticipation, monitoring, response, learning). This added value is implemented as smart tools within the Digital Twin concept. The activities of those tools must be orchestrated over time to have maximum effect during the different phases of the resilience cycle (see Section 2.3). Some activities, such as monitoring, are performed continuously throughout the resilience cycle, while others are performed only briefly (e. g., response). Therefore, there is no direct correspondence between the phases of the resilience cycle and the activity types. Each activity type can contribute to the overall resilience capabilities of the infrastructure in the course of events (Figure 5).

Figure 5

Sequence of activities during and after a crisis. These activities are supported by the Digital Twin, and help to maximize resilience of the respective critical infrastructure.

Ongoing activity monitoring (R2 monitoring) needs to be performed continuously, such that potential incidents will be detected based on the virtual replica’s state and the sensing data. The tools include anomaly detection, risk and resilience monitoring, scenario identification, and scenario forecast. Situation awareness should be established in an all-hazards-approach (C2 crisis) and in case of an incident inform about the characteristics of the disruption and the affected system dynamics.

Within threat and crisis situations, additional activities are required in order to respond to the incident in a timely manner (R3 response). Depending on the nature of the crisis, responses may be aimed at containing the threat, intervening in the sequence of events, shutting down parts of the infrastructure to prevent further damage, providing aid and assistance to injured people, providing replacement services, or rebuilding the infrastructure. These responses must then be transformed into an action plan that can be executed automatically with the help of the acting component or manually in the real infrastructure. In case sufficient measures and knowledge are provided by the Digital Twin, or when the incident and its dynamics are managable by standard procedures, the crises can be appropriately handled. In case of an unforeseen type of crisis, new mitigation approaches must be developed and provided in short time – which depends on how well the Digital Twin is prepared for the unexpected e. g., by offering modular mitigation modules and deep, fast, and informed intervention for humans; otherwise, a major disruption may result, which may impair services, affect, or even injure the users and population concerned. At this stage, the tools provide simulation of the identified interventions, decision support, and assistance in creating an action plan. Alignment of stakeholders ensures a common approach among all organizations (I2 regulation).

After crisis situations, a learning activity (R4 learning) follows. The goal is to understand the causes and reactions during the crisis and the risk development. The course of events and developments is saved to a scenario database. Based on the improved understanding of the crisis, the system can be enhanced (R1 anticipation). System optimization and adaption by, e. g., technical changes, procedure updates, stakeholder and citizen participation, and staff training, deliver a refined system better prepared for future crises.

To support resilience of the infrastructure (R1 to R4) and effective crisis management (C1 to C2), the following requirements for the toolbox are derived:

1. the toolbox should include smart tools, which are operable at any point during the resilience cycle, and:

   1. include the ability to monitor the status of the system and its environment, provide situation awareness, and enable response in case of a disruption;

   2. provide the ability to analyze and learn from past crises, to increase preparedness and adaptability.

Control center

The control center is the human computer interface (HCI) of the Digital Twin and as such a key component to ensure the purpose of the Digital Twin. It helps to understand the situation and to use the tools to perform the appropriate activities according to R1 to R4 (resilience capabilities). The situation room (Figure 2) is extended by the Digital Twin and transformed into a situation control center (Figure 6).

Figure 6

Control center for effective crisis management. As part of the Digital Twin concept, a situation control center provides stakeholders with up-to-date information and access to the tools needed to handle the crisis. The control center contains both information from the real infrastructure and a digital infrastructure.

To meet requirement C1 (normal operation) the control center makes the Digital Twin available for everyday interaction with stakeholders as well as in crisis situations (C2 crisis). Stakeholders are for example crisis management teams, operators, emergency and relief forces, citizens, and decision-makers from economy. In crisis situations, stakeholders might be overwhelmed by information and grasping dynamics thus the user interfaces need to be carefully crafted. Human-centered design processes should be used to design the control center, to meet use case requirements, establish well-defined processes, and ensure acceptance of both the Digital Twin and the resilience concept [42].

If the virtual replica contains 3D models they can be integrated into the control center for immersive interaction. A 3D-enriched clone of the current situation, past, or what-if scenarios is ideally suited to deal with rare and unforeseen events. Such events cannot be effectively countered on the basis of past experience alone. Instead, ingenuity and experimentation are called for. A virtual clone allows to test the implications of a wide variety of possible actions, immersively visualize the results (e. g., via VR and AR), and decide between several options. Serious games can be used to provide effective training for changed processes and optimized damage control.

The control center represents the interface between humans and the toolbox and addresses R1 to R4, C1 and C2, with the following requirements:

1. control center providing human-computer interaction and visualization:

   1. a control center, providing the stakeholders with tools to gain control of the current situation, visualization techniques, and decision support;

   2. up-to-date information and appropriate tools throughout all stages of crisis development and the resilience cycle;

   3. innovative learning processes, e. g., training of selected scenarios using VR or AR methods.

Platform and data management

The Digital Twin is required to meet C3 (resilient tool), which can be achieved by modularity and standardization for the software implementation, elastic hardware resources, and defined processes for development and operation. The overall Digital Twin concept consists of both software and hardware components, where the latter is the real world with the acting and sensing components. In this paper, we concentrate on the software aspects of the core components, i. e., the replica, the clone simulators, the tools, and the user interfaces.

From a software architecture point of view, a Digital Twin concept is best implemented as a service oriented architecture (SOA). Services implement simulators, tools, HCI, databases, and connectors to external services and components. Data streams connect those services, thus handling real-time data and control communication to form workflows. Ideally, all components are loosely coupled and modular, in order to ease implementing Digital Twins for new real-world sections and adding more tools.

To ensure consistent and reproducible data handling complying with regulation (I2), standards need to be followed for data semantics and formats, modular and reusable components, interfaces and protocols. For example, standardized APIs simplify the use of data from geo servers or sensors and allow federation of several Digital Twins. Possibly, new standards need to be formulated and established.

To meet the C3 requirement, the software services are operated in a cloud infrastructure with elastic hardware resources or in a network of edge devices. Such virtualized or distributed infrastructures provide, among other things, elastic computing and storage resources that can accommodate the high dynamics of resource requirements resulting, for example, from recurring large-scale simulations. The software services and the computing infrastructure together form a Digital Twin platform, that can be connected to the real infrastructure and is then available for use. The operation of the platform needs to follow IT standard methods to secure operation and integrity as well as support continuous change regarding software components. The DevOps approach might be suitable to orchestrate development and operation processes.

To enable learning from past incidents (R4 learning), historic data needs to be archived and readily available. Ideally, the full course of events in a crisis situation can be analyzed retrospectively, by storing data on environmental context, system status, and taken countermeasures in the infrastructure as well as the protocol of how the Digital Twin has been used.

The resulting requirements on Digital Twin software components are:

1. provide a Digital Twin platform to operate the core software services including data management:

   1. a modular and flexible architecture for replica, clones, tools, data lakes, user interfaces and connectors, operated on elastic hardware resources;

   2. standardized interfaces and protocols;

   3. the ability to record and replay historic crisis situations as scenarios, storing scenario data in a scenario database;

   4. service and life cycle management of Digital Twin components, tools and data to ensure resilient Digital Twin development and operation.

Table 3

The components of the Digital Twin concepts fulfill the requirements to increase critical infrastructure resilience, making the Digital Twin a valuable approach for the given task. Components marked with ‘x’ contribute to the resp. requirement, ‘X’ marks core elements to the task.

Table 3 shows that the main components of a Digital Twin can be designed to meet the formulated requirements. Thus, it is feasible to use the Digital Twin concept as a key instrument to significantly increase the resilience of critical infrastructures and make it a central concept for further research in this application area.

Human in the loop control

We suggest that the Digital Twin should prioritize human interaction. This means that only lower-level decisions should be automated within a control loop, while crucial decisions should be made by humans. As a result, this implements human-in-the-loop control [43].

In order to closely integrate stakeholders in major decision processes, the Digital Twin needs to firstly provide reliable, understandable and well-prepared information as a basis for the decision-making processes, and secondly enable human intervention upon request. The control loop aims to optimize multiple criteria, such as the quality of service, risk level, and resilience.

Principle of parsimony and accepted uncertainty

The principle of parsimony, also known as Occam’s razor, describes, simply put, a heuristic in which, among several possible explanations of a phenomenon, the simplest is preferred over options that require more assumptions. We advocate that this principle should be applied when choosing among several options in model design, detail, and the amount of external sensor data.

However, a simpler model and tool design comes along with increased uncertainty with regard to the performance of, e. g., the monitoring system or forecasting results. Therefore, we suggest to determine a level of accepted uncertainty when it comes to decisions. The uncertainty information should be made transparent within the decision making processes.

Prepared for complexity, emergence and self organization

As the Digital Twin captures the dynamics of complex, networked infrastructures, the Twin too likely shows properties of complex, networked systems itself, such as emergence and self-organization. This is even more likely when Digital Twins are coupled, forming a system-of-systems themselves. Thus, a certain degree of unpredictability can be expected and methods to anticipate such effects as a cause to cascades need to be developed [2].

Safe experiments and training

We propose to design the Digital Twin to provide a safe experimentation and training environment for uncertain situations and crises in addition to normal operations. It needs to be guaranteed that the experiments leave the actual system untouched until a decision is made. Due to the high uncertainty associated with the future course of events and the data collection processes, a variety of potential future system changes and intervention strategies exist. Crisis teams might need to take action in stressful situations. Training of situations beforehand and guidance through all processes support safe Digital Twin operation as well as effective responses in crisis situations.