Digital twin: device shadow, digital twin, twin synchronisation, OTA (Over-the-Air) update, fleet management
0 / 5 completed
1 / 5
An architect explains edge computing to a cloud-native team: "In cloud computing, processing happens in centralised data centres. Edge computing moves processing closer to where data is generated — in factories, retail stores, vehicles, or network equipment. We use edge nodes to process sensor data locally and only send aggregated results to the cloud. This reduces latency from 100ms (cloud round-trip) to under 5ms (local processing)." What is the primary motivation for edge computing?
Edge computing: computation performed at or near the data source — factory floor, vehicle, retail store, base station — rather than in a centralised cloud. Benefits: Low latency — local processing under 5ms vs. 50–200ms cloud round-trip. Critical for real-time control, AR, autonomous vehicles. Bandwidth reduction — process raw sensor data locally; only send aggregated/filtered data to cloud. A factory with 10,000 sensors generating 1GB/s would saturate a WAN link. Offline operation — edge continues functioning if cloud connectivity is lost. Data sovereignty — keep sensitive data local (GDPR, healthcare). Edge vocabulary: Edge node — a small computing device at the edge. Examples: industrial PC, Raspberry Pi, AWS Outposts, Azure Stack Edge. Fog computing — a layer between edge devices and the cloud; aggregation nodes closer to edge than cloud. Multi-access Edge Computing (MEC) — edge computing hosted in telco base stations (5G edge). CDN edge function — serverless compute at CDN PoPs (AWS Lambda@Edge, Cloudflare Workers). Reduces latency for web requests. Edge inference — running ML model inference on edge hardware (GPU edge devices, NVIDIA Jetson) instead of cloud. Latency budget — the maximum acceptable end-to-end latency for a system; determines what processing can be done remotely. In conversation: "Our conveyor belt defect detection model runs at the edge — we can't afford 150ms cloud round-trips when the belt moves at 2 metres per second."
2 / 5
An IoT engineer explains MQTT to the team: "MQTT is a lightweight publish-subscribe protocol designed for constrained IoT devices. Devices publish messages to topics on a broker. Subscribers receive messages from topics they've subscribed to. The broker decouples publishers and subscribers. MQTT has three QoS levels: 0 is fire-and-forget, 1 is at-least-once, 2 is exactly-once. For battery-constrained sensors, QoS 0 is fine." What does QoS level 1 guarantee in MQTT?
MQTT QoS levels: QoS 0 (At most once) — fire and forget. Message sent once; no acknowledgement. May be lost. Lowest overhead. Best for: frequent telemetry where occasional loss is acceptable. QoS 1 (At least once) — the broker stores the message and retries until it receives a PUBACK acknowledgement from the subscriber. Message may be delivered more than once (subscriber must handle duplicates). QoS 2 (Exactly once) — four-step handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP). Guaranteed exactly-once delivery. Highest overhead. Best for: billing events, critical commands. MQTT vocabulary: Broker — the central server that receives published messages and routes them to subscribers. Examples: Mosquitto (open-source), HiveMQ, AWS IoT Core, EMQX. Topic — a hierarchical string used to route messages: `factory/line1/sensor/temperature`. Wildcards: `+` (single level), `#` (multi-level). Retain — a retained message is stored by the broker; new subscribers immediately receive it on subscribe. Useful for device state. Last Will and Testament (LWT) — a message the broker publishes automatically if a client disconnects unexpectedly. Used for device offline detection. Keep-alive — interval (in seconds) after which the broker disconnects a client if no message is received. In conversation: "We use retained messages for device configuration — when a device reconnects after a restart, it immediately gets its current config without waiting for the next publish cycle."
3 / 5
A solutions architect compares IoT protocols for a rural agriculture project: "Our soil sensors are in fields with no WiFi or cellular. LoRaWAN gives us 10km range with very low power — a sensor can run on a battery for 5 years. The trade-off: low bandwidth — only a few bytes per message, maybe 10 messages per day. NB-IoT uses the cellular network — better bandwidth but needs a SIM card and ongoing fees. For this use case, LoRaWAN wins on battery life and cost." What makes LoRaWAN suitable for IoT deployments in areas without WiFi or cellular coverage?
LoRaWAN (Long Range Wide Area Network): a low-power wide-area network (LPWAN) protocol using LoRa (Long Range) radio modulation (spread spectrum). Characteristics: Range: 2–15km urban; up to 50km rural line-of-sight. Battery life: 5–10 years on AA batteries. Data rate: 0.3–50 kbps; typical payload 10–50 bytes. Cost: low; no SIM, no ongoing telco fees; gateway + cloud subscription. LPWAN protocol comparison: NB-IoT (Narrowband IoT) — uses LTE cellular network; better coverage indoors; higher data rates; requires SIM + carrier fees. Good for: smart meters, indoor assets. LTE-M (Cat-M1) — higher bandwidth than NB-IoT; supports mobility (handover); higher power than NB-IoT. Good for: vehicles, mobile assets. Sigfox — proprietary LPWAN; ultra-low power; very limited payload (12 bytes). Zigbee — short-range (10–100m); mesh network; used in smart home. Z-Wave — similar to Zigbee; smart home focus; lower frequency (less interference). Matter — the new unified smart home standard supported by Apple, Google, Amazon, Samsung. Built on Ethernet/WiFi/Thread. In conversation: "LoRaWAN is perfect for the farm sensors — we only need to transmit temperature and moisture once an hour; the 5-year battery life means we don't send a technician to change batteries."
4 / 5
An embedded systems engineer explains real-time constraints: "We're building a motor control system. It has hard real-time requirements: the control loop must execute within 1ms — every time, without exception. If it misses the deadline even once, the motor can overheat or the robot arm can damage itself. That's why we use an RTOS instead of Linux. Linux has non-deterministic scheduling jitter that would occasionally miss our 1ms window." What is the difference between hard real-time and soft real-time systems?
Hard real-time: every deadline must be met. A single miss is a system failure. Examples: airbag control (failure = injury), pacemaker (failure = death), industrial robot control. Soft real-time: deadlines are targets; occasional misses degrade performance but the system continues. Examples: video streaming (dropped frame = stutter), trading systems (missed tick = slower response), UI rendering. RTOS vocabulary: RTOS (Real-Time Operating System) — an OS with deterministic, bounded scheduling. Examples: FreeRTOS, Zephyr, VxWorks, QNX, ThreadX. Determinism — given the same inputs, the system always responds within a predictable bounded time. Linux with PREEMPT_RT patch approaches real-time but rarely meets hard deadlines. WCET (Worst-Case Execution Time) — the maximum time a task will ever take to execute; must be proven to meet the deadline. Measured by static analysis + hardware characterisation. Priority inversion — a high-priority task is blocked by a low-priority task holding a shared resource. Resolved by priority inheritance. Interrupt latency — time from hardware interrupt to ISR execution. Critical for hard real-time. Scheduling jitter — variation in task execution time; must be bounded and included in WCET analysis. In conversation: "We run Linux for the HMI and logging, and FreeRTOS on the dedicated control MCU — never mix hard real-time requirements into a general-purpose OS."
5 / 5
An IoT architect explains digital twins: "A digital twin is a virtual representation of a physical device that stays synchronised with the real device in real time. In AWS IoT Core, it's called a Device Shadow. The shadow stores the device's current and desired state in JSON. If the device is offline, you can still send a desired state update to the shadow. When the device reconnects, it retrieves the delta — the difference between desired and reported state — and applies it." What problem does a device shadow solve in IoT architecture?
Device shadow (AWS IoT Core) / Device twin (Azure IoT Hub) / Digital twin (broader): a JSON document in the cloud that represents a device's state. Structure: reported — state the device has reported (current actual state). desired — state the application wants the device to be in. delta — the difference; sent to the device when it reconnects. Problem solved: Async device management — you can send a configuration update to an offline device; it applies when reconnected. State visibility — applications always have the last known device state. Command delivery — desired state = command; device applies on reconnect. Digital twin vocabulary: Twin synchronisation — the process of keeping the digital twin in sync with the physical device. OTA update (Over-the-Air) — delivering firmware or software updates to devices wirelessly. Critical for fleet management. Fleet management — managing thousands of devices: configuration, updates, monitoring, diagnostics. Shadow conflict — when the device reports a state different from desired; the delta shows the conflict. Thing registry — AWS/Azure IoT catalogue of all registered devices with metadata. In conversation: "The device shadow means we can show the current thermostat setting in the mobile app even when the thermostat is sleeping to save battery — we just read the shadow."