Digital twin: device shadow, digital twin, twin synchronisation, OTA (Over-the-Air) update, fleet management
0 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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."
6 / 10
Review Comment: 'I'm seeing a lot of data being sent to the cloud from this edge node. Are you sure we're not over-reporting? The sensor readings are already quite granular.' Considering the context of edge computing, what is the most likely reason for this concern?
This comment highlights a potential issue with unfiltered data transmission. Edge computing emphasizes local processing and aggregation to minimize bandwidth usage and reduce the volume of raw data sent to the cloud. Option B is the correct answer because it suggests a standard edge computing practice – pre-processing data locally before sending aggregated results.
7 / 10
Slack Message: '@john.doe just flagged an anomaly in the temperature readings from our smart factory sensors. The data is being processed by the edge node running on a Raspberry Pi, but the response time is unexpectedly slow – over 20ms.' What's the most likely root cause of this latency issue?
Given the scenario – a Raspberry Pi handling sensor data and experiencing high latency – insufficient processing power is the most probable reason. Edge nodes, especially those using low-powered devices like Raspberry Pis, can struggle with computationally intensive tasks, particularly if they aren't optimized for the specific data format.
8 / 10
PR Description: 'Implemented a new protocol to stream sensor data from the field. Using CoAP over UDP allows us to achieve lower latency and reduced overhead compared to HTTP.' What is a key advantage of using CoAP over UDP in this context?
The description highlights a trade-off: low latency and reduced overhead. UDP is inherently lightweight and connectionless, making it ideal for IoT applications where minimizing bandwidth usage and network congestion are priorities – especially important for battery-powered devices. CoAP leverages this efficiency.
9 / 10
Standup Update: 'We're seeing intermittent connectivity issues with our remote wind turbine sensors. They're using NB-IoT, but the cellular coverage is patchy in some areas.' What's a potential mitigation strategy for this intermittent connectivity?
Intermittent connectivity often stems from unreliable signal strength. A robust error handling and retry mechanism within the sensor's firmware allows it to automatically re-attempt transmissions when connection losses occur – a standard practice for resilient IoT deployments dealing with fluctuating network conditions. This avoids data loss and maintains functionality.
10 / 10
Code Review Comment: 'The device is publishing its state to the MQTT broker using QoS level 0. This means there's no guarantee that the message will be delivered.' Considering the IoT use case, what potential consequence could this lack of delivery guarantees have?
QoS level 0 (fire-and-forget) offers no delivery guarantees. In IoT applications where accurate state tracking is critical – for example, monitoring a machine's performance or ensuring safety – missing data points can lead to incorrect interpretations and potentially dangerous consequences. A reliable system needs at least QoS 1 or 2.
What does the "Edge Computing & IoT Protocols Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to edge computing & iot protocols vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.