Episode Details

Welcome to a brand-new episode where we cut straight through vendor hype and tackle the real problems of digital twins on Azure. Everyone wants a digital twin, but almost nobody starts with the actual problem their plant needs to solve. Data already lives across your ERP, MES, historians, and IoT layers, yet operators still rely on manual phone calls, spreadsheets, and scattered alarms to figure out what a fault actually affects.

START WITH THE DECISION, NOT THE ASSETBefore building elaborate architecture diagrams or asset hierarchies, you need to begin with a repeating business decision that already causes delays, confusion, or handoffs between teams. If nobody can name the person making the decision, the precise timing, and the required action, you do not have a digital twin use case—you simply have a data collection idea. A true digital twin is not a polished CAD file or a dashboard tile that turns red when a sensor value changes; it is an instance of a model that carries identity, current operating facts, change history, and the contextual relationships that explain why anyone should care.

MODEL IDENTITY BEFORE TELEMETRYBefore wiring a single PLC tag to a twin property, you must solve the fundamental problem of equipment identity. Different systems call the exact same machine by entirely different names—the PLC program, the MES, the ERP system, and the legacy maintenance register rarely agree. Pushing data without a canonical twin ID results in fragmented twins that disagree with each other. Establish a stable, unique identifier that stays consistent through normal operational changes, and map your source system references clearly beside it.

SEPARATING CURRENT STATE, EVENTS, AND TIME SERIES HISTORYA common trap is trying to cram every high-frequency sensor reading and historical log directly into the twin graph, which quickly fills up with noise. To keep your architecture scalable and clean, responsibilities must be split across dedicated layers:

• The Twin Graph: Holds the current operating context and relationships that support immediate decisions right now.
  
• Event Streams: Capture meaningful occurrences—such as a machine fault raised or a batch moved—that change workflows and require a response.
  
• Time Series Storage: Preserves raw telemetry like spindle temperatures, vibration streams, and power draws for deep historical analysis and pattern tracking.
  

RELATIONSHIPS CARRY THE OPERATIONAL MEANINGA traditional containment tree only tells you where physical equipment sits within a plant, but it cannot explain how workflows ripple across the floor. Operating relationships—such as a machine feeding a downstream pack line, an operation consuming a material lot, or a shared fixture creating a capacity constraint—provide the context planners desperately need during an exception. By anchoring your model around orders, active operations, tooling constraints, and material genealogy, your architecture moves away from static asset registers and evolves into a true operating map of the plant.


Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.