Real-Time Analytics and Digital Twins for Smart Operations

Hands-on lab notes from LAB532: Real-Time Analytics and Digital Twins.

Why this session matters

Digital twins are one of those terms that has been PowerPointed to death. Every vendor in the industrial space claims to offer them. Every conference has a session about them. But the gap between marketing material and production reality remains vast — and this lab session at Ignite 2025 attempted to close it by putting attendees hands-on with the actual architecture required to make digital twins operational.

For me, this was not an academic exercise. At Weir Minerals, we work with IoT telemetry from mining equipment operating in some of the harshest environments on the planet. Slurry pumps, hydrocyclones, and comminution equipment generate continuous streams of vibration, temperature, pressure, and flow data. The promise of digital twins — that you can model these physical assets digitally, simulate their behaviour, and make predictive decisions before failures occur — is the entire reason our engineering team exists.

The question is whether the tooling has caught up with the vision. LAB532 offered some answers.

The architecture: Event-driven foundations

What the lab actually builds

The lab walks participants through constructing an end-to-end digital twin solution on Azure. The architecture follows a pattern that will be familiar to anyone who has built streaming data systems, but with digital-twin-specific extensions that are worth examining.

The data pipeline:

Physical Sensors → IoT Hub → Stream Analytics → Azure Digital Twins → Event Grid → Storage/Analytics

This is not revolutionary, but the integration points matter. Azure Digital Twins sits at the centre of the architecture as a live, queryable graph of physical assets and their relationships. Stream Analytics processes incoming telemetry in real time, updating twin properties as sensor readings arrive. Event Grid propagates changes downstream for alerting, storage, and further analytics.

The key insight: Digital twins are not just data stores. They are live models with relationships, properties, and behaviours that update in real time. A pump twin knows which pipeline it belongs to, which motor drives it, what its current vibration signature looks like, and how that signature compares to its baseline.

DTDL: The modelling language that makes or breaks your twin

Digital Twin Definition Language (DTDL) is where the real engineering happens. The lab uses DTDL to define twin models — essentially schemas that describe what a physical asset looks like digitally.

{
  "@type": "Interface",
  "@id": "dtmi:example:Pump;1",
  "displayName": "Pump",
  "contents": [
    {
      "@type": "Telemetry",
      "name": "vibration",
      "schema": "double"
    },
    {
      "@type": "Property",
      "name": "operatingStatus",
      "schema": "string"
    },
    {
      "@type": "Relationship",
      "name": "connectedTo",
      "target": "dtmi:example:Pipeline;1"
    }
  ]
}

The modelling challenge: Getting DTDL right is harder than it looks. In the lab, participants model a relatively simple system — a handful of assets with straightforward relationships. In production, a mining processing plant has thousands of assets with complex hierarchical and lateral relationships. A hydrocyclone cluster connects to feed pumps, underflow discharge systems, overflow launders, and instrumentation loops. Each of those has sub-components. Each sub-component has its own telemetry streams.

The lab teaches the mechanics of DTDL. What it cannot teach in 75 minutes is the domain modelling discipline required to represent an industrial operation accurately. And this is where most digital twin projects fail — not in the technology, but in the modelling.

Real-time processing: Stream Analytics in practice

The streaming pattern

The lab demonstrates Azure Stream Analytics processing IoT telemetry and routing updates to Azure Digital Twins. The pattern follows a familiar structure.

Ingest: IoT Hub receives telemetry from simulated devices. In production, this would be physical sensors transmitting via MQTT or AMQP, typically through an edge gateway.

Process: Stream Analytics applies windowed aggregations, anomaly detection, and threshold checks against incoming data. The lab uses tumbling windows for periodic aggregation and sliding windows for trend detection.

SELECT
    IoTHub.ConnectionDeviceId AS DeviceId,
    AVG(vibration) AS AvgVibration,
    MAX(temperature) AS MaxTemperature,
    System.Timestamp() AS EventTime
INTO
    [digital-twins-output]
FROM
    [iothub-input]
TIMESTAMP BY EventEnqueuedUtcTime
GROUP BY
    IoTHub.ConnectionDeviceId,
    TumblingWindow(minute, 5)

Update: Processed results update twin properties in Azure Digital Twins via the REST API. The twin graph reflects the current state of all monitored assets.

React: Event Grid captures twin property changes and triggers downstream actions — alerts, dashboards, automated responses.

The honest assessment of Stream Analytics

What works well: For straightforward aggregation and threshold monitoring, Stream Analytics delivers. The SQL-like query language has a low learning curve. Integration with IoT Hub and Event Grid is seamless. For the lab scenario, it is more than adequate.

Where it falls short: Stream Analytics is a managed service with fixed capabilities. Complex event processing — pattern detection across multiple streams, stateful correlation of events from different assets, or machine learning inference within the stream — pushes you towards alternatives like Azure Data Explorer (ADX), Apache Kafka with stream processing, or custom solutions.

The industrial reality: In our work at Weir Minerals, we moved significant analytics processing to Azure Data Explorer because the query flexibility and time-series analysis capabilities far exceed what Stream Analytics offers. ADX handles 58% of the calculations that were previously done in AVEVA PI — a number that continues to grow as we discover more patterns expressible in KQL. Stream Analytics has its place for simple routing and aggregation, but production industrial analytics demands more.

Simulation and scenario testing: The twin's real value

Beyond monitoring

If all a digital twin does is mirror the current state of a physical asset, it is an expensive dashboard. The real value comes from simulation — using the twin to test scenarios that would be dangerous, expensive, or impossible to test on the physical system.

The lab demonstrates basic simulation capabilities: changing twin properties programmatically to model "what if" scenarios. What happens if pump vibration increases by 20%? What if flow rate drops below threshold? How does a downstream asset respond to upstream changes?

The pattern:

# Update twin property to simulate scenario
patch = [
    {
        "op": "replace",
        "path": "/vibration",
        "value": 12.5  # Elevated vibration scenario
    }
]
service_client.update_digital_twin(twin_id, patch)

# Query downstream impacts
query = "SELECT * FROM digitaltwins WHERE IS_OF_MODEL('dtmi:example:Pipeline;1') AND connectedTo = 'pump-001'"
results = service_client.query_twins(query)

Where simulation gets interesting — and hard

The lab covers: Simple property updates and relationship queries. Adequate for understanding the mechanics.

What production requires: Physics-based simulation engines that model fluid dynamics, thermodynamics, structural mechanics, and wear patterns. A digital twin of a slurry pump needs to model erosion rates based on particle size distribution, flow velocity, and impeller geometry. That is not a property update — it is a computational simulation that requires domain-specific models.

The gap: Azure Digital Twins provides the graph and the state management. It does not provide the simulation engine. Production digital twin deployments integrate external simulation tools — ANSYS, COMSOL, or custom physics models — with the twin graph. The lab does not address this integration, and it is where the hardest engineering happens.

The question for Microsoft: Is Azure Digital Twins a simulation platform, or is it a state management layer that other tools simulate against? The answer appears to be the latter, which is honest but means the "digital twin" label overpromises what the Azure service alone delivers.

Event-driven design: Making twins responsive

The Event Grid integration

The lab demonstrates how twin property changes propagate through Event Grid to trigger downstream actions. This is the event-driven architecture that makes digital twins operationally useful.

The pattern:

1. Sensor data arrives via IoT Hub
2. Stream Analytics processes and updates twin properties
3. Twin property change fires Event Grid notification
4. Azure Function receives notification and executes business logic
5. Actions taken: alert raised, dashboard updated, work order created

What this enables: Closed-loop operations. The digital twin is not a passive model — it reacts to changes and drives responses. A vibration anomaly detected in the twin can automatically trigger a maintenance work order, notify the operations team, and adjust upstream processes to reduce load on the affected asset.

The operational maturity question

Level 1 — Monitoring: Twin reflects current state. Humans observe and decide. This is where most implementations stop.

Level 2 — Alerting: Twin detects anomalies and alerts humans. The lab demonstrates this level.

Level 3 — Automation: Twin triggers automated responses. Requires trust in the model and robust safety controls.

Level 4 — Optimisation: Twin continuously optimises operations based on simulation and prediction. Requires mature data science and domain expertise.

The honest reality: Most industrial digital twin deployments are stuck at Level 1 or early Level 2. The technology for Levels 3 and 4 exists, but the organisational maturity — data quality, model validation, operational trust, change management — lags behind. The lab teaches the technical mechanics. It does not address the organisational challenges that determine whether a digital twin project succeeds or becomes an expensive monitoring dashboard.

What this means for industrial IoT

The mining context

In mining, digital twins face unique challenges that this lab hints at but does not fully address.

The environment: Mining equipment operates in extreme conditions. Sensors fail. Connectivity is intermittent. Data quality is inconsistent. A lab environment with simulated devices producing clean, reliable telemetry bears little resemblance to a processing plant in the Australian outback where temperature swings of 40 degrees Celsius cause sensor drift and dust ingress corrupts optical measurements.

The scale: A single mining processing plant can have thousands of monitored assets. The twin graph becomes complex. Query performance matters. Relationship traversal at scale requires careful modelling and indexing.

The domain knowledge: The value of a mining digital twin comes from domain-specific models — wear curves for pump liners, classification efficiency models for hydrocyclones, power draw models for mills. Azure Digital Twins provides the infrastructure. The domain knowledge lives in the engineering team.

What I would change about this lab

Add edge processing: Production IoT architectures need edge computing for latency-sensitive decisions and bandwidth optimisation. The lab goes straight from device to cloud. Real deployments need Azure IoT Edge or equivalent for local processing, aggregation, and store-and-forward.

Address data quality: The lab uses clean simulated data. Production telemetry is noisy, has gaps, contains outliers, and drifts over time. A section on data validation, cleansing, and anomaly detection in the ingestion pipeline would be valuable.

Show ADX integration: Azure Data Explorer is the natural analytics companion to Azure Digital Twins for industrial scenarios. Time-series storage, KQL queries, anomaly detection functions, and render charts — ADX fills the analytical gaps that the twin graph alone cannot address.

Demonstrate hybrid twin patterns: Some assets need physics-based simulation. Others need machine learning models. Most need both. Showing how external models integrate with the twin graph would bridge the gap between lab exercise and production architecture.

The technology stack assessment

What Azure Digital Twins does well

Graph modelling: The twin graph with DTDL models is genuinely useful. Representing physical assets and their relationships as a queryable graph enables spatial reasoning and impact analysis that flat telemetry databases cannot match.

Event integration: The Event Grid integration enables responsive, event-driven architectures. Property changes propagate reliably. The pub/sub pattern scales well.

API surface: The REST API and SDKs are mature. Programmatic twin management — creating, updating, querying — works as expected.

Where it falls short

Simulation capabilities: Azure Digital Twins does not simulate. It stores state and relationships. Calling it a "digital twin" platform without built-in simulation capability is a stretch. It is a twin state management service.

Visualisation: The lab does not address how you visualise a complex twin graph. Azure Digital Twins Explorer exists but is limited. Production deployments need custom 3D visualisations, often using tools like Unity, Unreal Engine, or specialised industrial visualisation platforms.

Cost at scale: Azure Digital Twins pricing is based on messages and queries. At industrial scale — thousands of assets, millions of telemetry points per day — costs escalate quickly. The lab does not address cost optimisation strategies.

Competitive landscape: AWS IoT TwinMaker and Siemens MindSphere offer competing digital twin platforms. NVIDIA Omniverse provides physics-accurate simulation that Azure Digital Twins cannot match. Microsoft's offering is solid infrastructure, but it is not the only option and may not be the best option depending on simulation requirements.

Key takeaways

The technology works: Azure Digital Twins, combined with IoT Hub, Stream Analytics, and Event Grid, provides a functional architecture for building digital twins on Azure. The lab demonstrates this effectively.

The real challenge is modelling: DTDL models must accurately represent physical systems. This requires domain expertise that no lab can provide. Invest in modelling discipline before investing in infrastructure.

Simulation is the gap: If your digital twin needs physics-based simulation, Azure Digital Twins is necessary but not sufficient. Plan for external simulation engine integration from day one.

Event-driven architecture is essential: Digital twins that do not drive operational responses are expensive dashboards. Design for event-driven reactivity from the start.

Edge computing is missing: Production IoT architectures need edge processing. The lab's cloud-only architecture is a simplification that does not translate directly to production.

Start small, model well, scale deliberately: The lab's progression from simple twin to connected graph is the right approach. But scale introduces modelling complexity, query performance challenges, and cost management requirements that need architectural attention.

For teams beginning their digital twin journey, this lab provides solid foundations. For teams operating at industrial scale — the kind of scale we deal with in mining — the lab is a starting point, not a destination. The hard work happens in the domain modelling, the data quality engineering, and the organisational change management that no Azure service can automate.

Related coverage:

• Physical AI with NVIDIA and Azure - Simulation and digital twins at scale
• Ignite 2025 Keynote - The AI platform strategy
• Ignite 2025 Synthesis - Connecting the dots across all sessions

Analysis from Microsoft Ignite 2025, San Francisco, 18-21 November. Steven Newall is a Platform Engineering Manager specialising in IoT and digital twins for industrial operations.