1) Problem & Goal IoT Hub emits non-telemetry events (for example, device twin change events and digital twin change events). Today, when those land in Fabric Event Streams, operators still have to manually wire model context into the Fabric Digital Twin. We want this to be automatic: whenever IoT Hub sends a twin-related event, Fabric should (a) create or update the Digital Twin in the Digital Twin Builder, and (b) map reported properties onto the twin instance. Out-of-the-box for DTDL/Plug-and-Play; extensible to other digital twin standards. This enables operators to click an “interesting event” (e.g., an alarm) and immediately review the twin’s configuration/state as-of that event, then run graph queries (GQL) in Kusto to understand blast radius and impact paths. IoT Hub supports routing these event types; Event Streams already integrates those sources and routes to Fabric destinations. 2) User Scenarios Scenario 1: Operator reviews an alarm with Digital Twin context An operator is monitoring a fleet of refrigeration units across multiple retail stores. During normal operations, temperature sensors and compressor controllers send telemetry to IoT Hub. One evening, an alarm event is triggered because the temperature in one of the refrigerated cases exceeds its safety threshold. The event is routed through Event Streams into Fabric. From the event card, the operator clicks “Open twin at event time.” The Digital Twin Builder opens a snapshot of the twin representing that refrigeration case. The operator sees: Reported properties such as last measured temperature, compressor cycle count, and defrost configuration. Desired properties (e.g., target temperature range) for comparison. Device metadata (firmware version, component models) tied to the DTDL model. By reviewing this historical snapshot, the operator determines that the configuration was correct, but that the compressor reported longer duty cycles than expected. They then use graph queries (GQL in Kusto) to determine the blast radius, checking which other refrigeration cases depend on the same power supply or share the same controller vendor. Scenario 2: Integrator onboards Plug and Play (PnP) devices automatically An integrator is tasked with connecting a new set of HVAC controllers with published DTDL models. The devices report configuration and operational data (airflow rates, fan speeds, filter status) as reported properties to IoT Hub. As soon as the devices connect, IoT Hub issues digital twin change events. Event Streams forwards these to the Digital Twin Builder, which automatically: Creates twin instances for each HVAC controller. Maps reported properties to the appropriate DTDL properties without manual mapping. Establishes relationships between HVAC controllers and their associated rooms/zones. The integrator verifies in Fabric that the twins are present and complete. No manual schema mapping was needed. They also test by raising the fan speed in a controller and confirming that the updated reported property appears immediately in the twin. Later, when building a system dashboard, the integrator queries across all HVAC twins to check which units are overdue for filter replacement. This is possible because reported properties were consistently mapped and stored as part of the digital twin.
... View more