Twin Architecture Patterns

Three Levels of Twin Capability

Not all digital twins do the same thing. The capability you need determines the architecture you build. Three levels are widely recognized in practice, and each builds on the one before it.

Monitoring Twins

A monitoring twin reflects the current state of the physical system. Sensor data flows in, the twin updates, and operators see a live dashboard of what the system is doing right now. No prediction, no control — just visibility.

What it does: Aggregates, organizes, and visualizes operational data in the context of the system's structure. Instead of reading raw sensor feeds, an operator sees temperatures, pressures, and states mapped onto the system architecture — the pump, the heat exchanger, the control valve — in real time.

Architecture decisions:

• Data ingestion must handle the volume and velocity of sensor streams without falling behind
• The twin's structural model (which components exist, how they connect) comes directly from the system model built in MBSE. The blocks in your SysML or CAPELLA model become the components in the twin's data model
• Visualization layers map data to system structure — a dashboard that shows temperature at each component, not just a flat list of sensor readings
• Storage must support time-series queries: "What was the temperature of pump P-101 at 14:32 yesterday?"

When it is enough: When the primary problem is visibility. Many industrial operations lack basic awareness of what their systems are doing in real time. A monitoring twin solves this without requiring predictive models.

Predictive Twins

A predictive twin goes beyond "what is happening now" to "what will happen next." It uses models — physics-based, data-driven, or hybrid — to forecast future states: remaining useful life of a component, performance under projected load conditions, or the probability of a failure mode occurring within a maintenance window.

What it does: Runs models forward in time using current state (from sensors) and projected conditions (from operational plans or environmental forecasts) to predict outcomes.

Architecture decisions:

• Everything the monitoring twin requires, plus a model execution layer
• The models need current state as initial conditions — the monitoring twin's data becomes the predictive twin's input
• Model execution frequency depends on the application: once per shift for maintenance planning, continuously for safety-critical systems
• Prediction results need confidence intervals, not point estimates. A prediction of "47 days remaining life" is less useful than "between 35 and 60 days remaining life with 90% confidence"
• The system model's behavioral definitions (state machines, activity flows, parametric constraints from DGTLENG 201) provide the structural framework for the predictive models. The twin's physics or ML models operate within the architecture the system model defines

When it is needed: When decisions depend on future system state — maintenance scheduling, capacity planning, risk assessment, or operational optimization.

Prescriptive Twins

A prescriptive twin closes the loop: it not only predicts what will happen but recommends or executes actions to achieve a desired outcome. It moves from "the bearing will fail in 30 days" to "reduce speed by 10% and schedule replacement during the next planned downtime" — or, in fully automated cases, it sends the control command directly.

What it does: Combines prediction with optimization. Given a predicted future state and a set of objectives (minimize downtime, maximize throughput, maintain safety margins), the prescriptive twin computes the best action.

Architecture decisions:

• Everything the predictive twin requires, plus an optimization or decision engine
• The action space must be well-defined: what controls can the twin adjust? What constraints must it respect?
• Human-in-the-loop versus closed-loop: does the twin recommend actions for a human to approve, or does it act autonomously? This is a design choice with significant safety and organizational implications
• Feedback loops must be stable — the twin acts, the system responds, the twin observes the response and adjusts. Unstable feedback loops are dangerous, particularly in physical systems
• The interfaces defined in the system model (the ports, flows, and protocols between components) map directly to the control channels the prescriptive twin uses. What the model defines as an interface, the twin uses as a data connection or control path

When it is needed: When the system operates in conditions that change faster than human operators can respond, or when optimization across many variables exceeds human cognitive capacity.

Architecture Foundations

Regardless of the twin's capability level, several architecture decisions apply to all digital twins.

The System Model as Blueprint

The system model from MBSE (DGTLENG 201) is not a separate artifact from the digital twin — it is the twin's structural definition. The decomposition of the system into subsystems and components in the model becomes the decomposition of the twin into computational components. The interfaces between model blocks become the data flows between twin modules.

This connection is not metaphorical. In a well-architected twin, changing the system model's structure (adding a component, modifying an interface) should propagate to the twin's structure. The twin is an instance of the model, instantiated with real data from a specific physical asset.

Data Architecture

Every twin needs a data architecture that answers:

• What data? Which measurements from the physical system does the twin need? The system model's parametric constraints and behavioral models identify the critical parameters.
• How often? Sampling rates, latency requirements, and batch versus streaming decisions.
• Where stored? Time-series databases for operational data, model repositories for the twin's computational models, configuration databases for asset-specific parameters.
• How long? Retention policies: keep raw data for 30 days, aggregated data for 5 years, model predictions indefinitely?

Model Architecture

The computational models inside the twin — whether physics equations, ML models, or rule-based logic — need their own architecture:

• What models? Thermal, structural, fluid, electrical, degradation, control logic — determined by what the twin needs to represent
• How connected? Models that share state (the thermal model's output is the structural model's input) need defined interfaces and execution order
• How updated? Models calibrate as new operational data arrives. The calibration mechanism is part of the architecture, not an afterthought

Infrastructure

Where does the twin run?

• Cloud: Scalable compute, easy to manage fleet-level twins, but introduces latency and requires network connectivity
• Edge: Low latency, operates during network outages, but limited compute and harder to manage at scale
• Hybrid: Edge for time-critical monitoring and control, cloud for heavy-model prediction and fleet analytics

From Concept to Implementation

Building a digital twin is not a single project — it is an incremental capability build. Most successful twins start as monitoring twins and evolve:

1. Start with visibility. Connect sensors, build the data pipeline, display current state on the system structure. This alone delivers value and reveals data quality issues early.
2. Add prediction for the highest-value use case. Pick one failure mode, one performance parameter, or one optimization opportunity. Build the predictive model for that single use case. Validate it.
3. Expand prediction coverage. Add more models, cover more failure modes, predict more parameters. Each addition uses the same data pipeline and structural model.
4. Add prescription where justified. Only where the prediction is trustworthy, the action space is well-defined, and the risk of autonomous action is acceptable.

This incremental approach manages risk: each stage delivers value, validates the data pipeline, and builds organizational trust in the twin before the next stage adds complexity.

Assessment