Demystifying IoT Architecture Validation:

Lessons from Doppelio

Doppelio Platform: IoT Architecture Support Framework

Overview

IoT solutions vary widely depending on legacy infrastructure, security needs, regulations, and modernization goals. While often described as “edge vs. cloud,” real deployments usually combine devices, gateways, and applications with different communication models. Doppelio’s test automation platform supports these diverse architectures, enabling simulation, validation, and stress testing of connected systems that mirror real-world conditions.

 

Architecture 1: On-Premise Connected Products

How It Works

Devices and control systems communicate only over local networks. No cloud involvement. Operators monitor and control equipment using HMIs, SCADA, or building management consoles.

Why Organizations Use It

• High-security environments (defense, utilities, hospitals)
• Sites with poor or unreliable internet connectivity
• Compliance mandates for data sovereignty

Technical Distinction

• Runs entirely on LAN or fieldbus protocols (e.g., Modbus RTU, BACnet MS/TP).
• Often relies on proprietary or legacy protocols.
• No external connectivity = limited visibility outside the local site.

Validation Complexity
Testing requires reproducing air-gapped, protocol-heavy environments with legacy devices and very limited automation hooks.

Architecture 2: On-Prem + Cloud Enabled

How It Works

Gateways connect local devices to the cloud. They aggregate and forward data while still supporting local control.

Why Organizations Use It

• Incremental modernization of legacy systems
• Balanced need for local operation and cloud analytics
• Cost-effective way to extend existing infrastructure

Technical Distinction

• Southbound protocols (Modbus, BACnet, KNX) translated into cloud-friendly protocols (MQTT, HTTP, CoAP).
• Hybrid operation: devices still run offline if the cloud is unavailable.
• Gateways often add edge processing for filtering or event detection.

Validation Complexity
Testing must account for protocol translation errors, dual-path failures, and synchronization between local and cloud systems.

 

Architecture 3: Client-Device Architecture

How It Works

Devices act as clients, initiating outbound connections (e.g., MQTT, HTTPS). Data flows up, commands flow down over the same secure channel.

Why Organizations Use It

• Works behind NAT/firewalls without exposing device IPs
• Well-suited for low-power or battery-operated devices
• Simplifies security by using outbound TLS channels

Technical Distinction

• Cloud-first, highly scalable model.
• Devices depend on session management with the cloud.
• Suited for consumer IoT (smart thermostats, wearables, GPS trackers).

Validation Complexity

Challenges include intermittent connectivity, battery optimization, reconnection logic, and large-scale concurrency.

 

Architecture 4: Device as a Server Endpoint

How It Works

Devices act as servers with routable IPs. Control centers initiate sessions directly.

Why Organizations Use It

• Utility and industrial environments where devices must be remotely interrogated or controlled
• Deterministic systems where the client-pull model is not viable

Technical Distinction

• Devices expose TCP/UDP, REST APIs, or SNMP interfaces.
• Requires dedicated, managed network infrastructure.
• Often used in smart metering and telecom networks.

Validation Complexity
Hard to test at scale because it requires simulating millions of routable endpoints, DoS resilience, and low-latency responsiveness.

 

Architecture 5: Multi-Protocol Gateway-to-Cloud

How It Works

Gateways support multiple device protocols and standardize upstream communication. Example: collecting BACnet, Modbus, OPC-UA data and pushing it via MQTT.

Why Organizations Use It

• Mixed vendor/device ecosystems
• Enterprises looking to standardize data models
• Smart cities and large facilities with heterogeneous infrastructure

Technical Distinction

• Must maintain protocol interoperability on both sides.
• Can involve edge servers running containerized adapters.
• Common in smart buildings and industrial automation.

Validation Complexity
Validation is challenging due to conflicting device behaviors, inconsistent payload formats, and evolving standards.

Architecture 6: Data Type Variations (Structured vs. Unstructured)

How It Works
Some IoT systems handle structured telemetry (sensor readings, status updates). Others handle unstructured media (video, audio, imaging). Both flow differently through the network and storage stack.

Why Organizations Use It

• Structured data supports telemetry, analytics, and automation.
• Unstructured data is essential for surveillance, diagnostics, or inspection.

Technical Distinction

• Structured = predictable schemas, numerical values.
• Unstructured = large payloads, streaming, high bandwidth.
• Requires different ingestion, processing, and storage systems.

Validation Complexity
Testing must cover schema validation, accuracy, and scale (structured) versus latency, jitter, and quality-of-service (unstructured).

 

Architecture 7: Connected Assets

How It Works
Each physical asset (HVAC unit, generator, vending machine, medical device) connects individually via built-in controllers or telematics modules. Assets are monitored and managed as standalone entities.

Why Organizations Use It

• Enables predictive maintenance and remote support
• Monetization through subscription or pay-per-use services
• Supports distributed fleets (construction equipment, healthcare devices)

Technical Distinction

• Asset-level connectivity via cellular, Wi-Fi, or satellite.
• The lifecycle of assets can span decades.
• Data models tied to the asset type.

Validation Complexity
Testing must simulate distributed, long-lived assets with diverse connectivity and usage profiles, including failure conditions that only appear over time.

 

Architecture 8: System-of-Things

How It Works
Multiple subsystems (robots, sensors, controllers, conveyors, HVAC, etc.) interoperate locally and/or via the cloud. They exchange data with each other to coordinate workflows, not just with the cloud.

Why Organizations Use It

• Mission-critical environments (factories, airports, warehouses)
• Need for autonomous decision-making and failover
• Complex orchestration across multiple device types

Technical Distinction

• Device-to-device communication, not just device-to-cloud.
• Requires orchestration engines and workflow management.
• Involves redundancy, event sequencing, and error recovery.

Validation Complexity
The most complex: requires multi-device orchestration testing, failure cascades, timing accuracy, and workload balancing under real-world stress conditions.