Q19Internet of Things

Designing an IoT system is generally split into two complementary views: the Physical Design, which deals with the actual hardware and low-level protocols, and the Logical Design, which deals with the abstract data flow and software architecture independent of specific hardware choices.

The Physical Design of IoT encompasses the physical devices ('Things') and the protocols used to connect them. This includes Node devices (sensors, actuators, and microcontrollers such as Arduino or ESP32) and Network/Communication protocols at the link and network layers (Wi-Fi, BLE, Zigbee, LoRa). It represents the concrete hardware infrastructure: what silicon runs the firmware, what radio it uses, and how much power it consumes. Two IoT nodes can be functionally identical in logical design yet look completely different physically, one battery-powered and Zigbee-based, another mains-powered and Wi-Fi-based, depending on deployment constraints.

The Logical Design abstracts the physical entities into functional blocks and defines how data is managed, processed, and communicated without reference to specific hardware. It includes:

• Functional Blocks: Device, Communication, Services, Management, Security, and Application blocks that describe what the system does, not how it is physically implemented.
• Communication Models: such as Request-Response (client-server architecture), Publish-Subscribe (broker-based messaging), Push-Pull, and Exclusive Pair, describing how information flows between entities.
• Communication APIs: such as REST (stateless, HTTP-based, URI-identified resources) and WebSockets (stateful, bidirectional communication over a single socket), describing how software components expose their functionality to each other.

The logical design maps out the software architecture overlaying the physical network, letting architects design data flow and interaction patterns, such as deciding that sensors will publish to topics and a dashboard will subscribe, before committing to specific chips or radios.

In practice, a project typically starts with the logical design to establish what functional blocks and communication patterns are needed, and only then selects the physical components that satisfy those requirements within cost, power, and range constraints. For example, a logical design calling for a Publish-Subscribe model with battery-powered nodes reporting once per hour might lead to a physical design using an ESP32 microcontroller with a DHT22 sensor, communicating over Wi-Fi to an MQTT broker, whereas a logical design requiring multi-year battery life across a large mesh might instead lead to a Zigbee-based physical implementation with 6LoWPAN for IP connectivity.

Keeping the two views separate has practical engineering value. If a manufacturer later needs to swap the Wi-Fi module for a cellular modem due to a supply shortage, the logical design, including the communication model, API contracts, and application logic, does not need to change at all; only the physical layer implementation changes. Conversely, if requirements evolve so that the application needs a new real-time alert feature, the logical design can be updated to add a WebSocket-based Exclusive Pair connection without necessarily requiring new hardware, as long as the existing radio can support the additional traffic. This separation of concerns is what allows IoT product teams to iterate on hardware and software independently, which is essential given how much faster software requirements typically change compared to hardware refresh cycles.