The Architecture provides a framework for connecting existing or newly developed hardware devices to a cloud platform, enabling remote monitoring and control via web browsers and native applications for various operating systems (Android, iOS, Windows, Linux, etc.).
To implement this concept, a combination of hardware and software components is utilized, which includes:
- Connected Device (CD);
- Gateway Device (GD);
- Server and Backend Software;
- Client Devices and Applications.
Connected Device (CD)
In most cases, this is an existing or newly developed hardware-software product that requires a Cloud connection for remote status monitoring and control. By doing so, the product operates within the IoT ecosystem.
CD Implementation
The CD must be hardware and software compatible with the Gateway Device (GD), which often necessitates certain modifications to the hardware/software of existing products or specific design implementations for newly developed products.
The CD and GD must communicate using a unified protocol across all OSI layers. The physical layer can rely on standard interfaces (e.g., UART, RS-485, 1-Wire, I2C) or proprietary custom interfaces. The logical layers must be fully supported by both devices to ensure correct data linkage. The application layer protocol is designed based on the volume and type of parameters transmitted from the CD to the GD and Cloud, as well as the data received from the Cloud to the CD. This part of the protocol often requires meticulous analysis and optimization due to the limited computational resources of embedded CDs and GDs.
CD Implementation Examples in Realized Projects
Tenko:
CleanCar:
Note: The specific protocol and any required hardware/software modifications for the CD are tailored and agreed upon individually for each custom system.
Gateway Device (GD)
The GD is a hardware-software complex that bridges the CD with the Cloud, primarily over the Internet. Conceptually, the GD facilitates two bi-directional communication channels:
- CD ↔ GD;
- GD ↔ Cloud.
As an exception, one or both channels can be implemented as uni-directional. Such solutions apply to severely resource-constrained systems or scenarios where only telemetry (status tracking) is required and guaranteed data delivery is not critical. However, this is mostly treated as a special use case.
CD ↔ GD Communication is typically implemented using a unified protocol. Exceptionally, different protocols can be used for each direction, or multiple CDs can connect to a single GD via varying channels. Such architectures increase system complexity and are only recommended when strictly justified.
GD ↔ Cloud Server Communication is realized over the Internet using wired or wireless interfaces such as LAN, Wi-Fi, mobile networks (GSM/GPRS), etc. For Wi-Fi implementations, the widely adopted ESP8266 module was utilized, while LAN implementations utilized the ENC28J60 controller.
Principle of Operation
Generally, all connections are initiated by the GD. The GD verifies Internet connectivity (e.g., connection to a Wi-Fi AP), then sends a request to the CD. The CD transmits data to the GD. The GD processes this data (or passes it as-is), appends additional metadata if necessary, packages it, establishes a TCP/IP connection, and dispatches it to the Server. In response, the Server sends either an acknowledgment (ACK) of successful receipt or a data packet containing user-inputted configurations and control commands. The GD unpacks the Server payload, processes it if required, and forwards the commands to the CD. Afterward, the GD sends a final acknowledgment back to the Server, confirming successful execution (often after receiving hardware confirmation from the CD).
This operational principle is highly robust and user-friendly. For the GD ↔ Server link, the end-user does not need a static external IP address or complex router configuration (e.g., port forwarding for Wi-Fi/LAN). For the CD ↔ GD link, it prevents empty polling cycles when Cloud connectivity is lost. As an alternative, the CD can act as the initiator, or the GD can act as a local Web Server with its own UI. However, this approach complicates the network infrastructure for the end-user.
In some cases, the GD requires initial setup—for instance, connecting a Wi-Fi GD to a local access point. For this, a localized Web Interface can be embedded within the GD. Example implementation: the GD features a physical hardware button. When pressed, the GD enters AP (Access Point) mode, broadcasting a specific SSID (password-protected if necessary). It scans for available local Wi-Fi networks and generates an HTML page listing them, alongside a password input field and a “Connect” button. It opens a specific port (usually 80) at a default IP address. Once the user connects to this AP and enters the IP in a browser, they can select their home network, enter the password, and connect. For status monitoring, the GD can utilize onboard indicators (e.g., multi-color LEDs, segment or graphic displays) or forward the network status directly to the CD’s display.
An additional local Web Interface can be implemented on the GD to control the CD directly over the local network in the event of an Internet outage.
GD Implementation Examples:
- Internet of Things (IoT) Solution for Tenko Premium Boilers;
- Internet of Things (IoT) Solution for Self-Service Car Washes.
Note: GD architectures vary significantly depending on the system requirements and are designed specifically for each project.
Server and Backend Software
The server component requires Internet access and specialized backend software. This can be deployed on physical hardware (dedicated servers, PCs, Raspberry Pi, etc.) or leased Cloud VPS platforms (e.g., DigitalOcean, AWS).
Custom backend software is developed to accommodate the system’s specific features. The server handles data ingestion from the GD, processing, database storage, response generation, and user interaction (displaying device telemetry and accepting user commands).
User interaction is facilitated through a responsive Web Interface accessible via browsers, and through robust Server APIs (REST) that power native mobile and desktop applications across operating systems like Android, iOS, Windows, and Linux.
The system supports dynamic user account provisioning. When the CD transmits its very first packet containing a unique identifier (e.g., a hardware serial number), the server automatically provisions a user account linked to that identifier. The user can then log in using this credential and later customize their profile and security settings within their personal dashboard.
Backend Implementation Examples:
- CleanCar – Includes a Web Interface. More details are available in the case study (includes a demo account).
- Tenko – Includes a Web Dashboard. More details are available in the case study (includes a demo account). The platform features a full API that drives native Android and iOS applications.
Note: Server architecture and backend software are custom-developed for each project. Advanced server-side security protocols can be implemented upon request.
Client Devices and Applications
Client equipment encompasses any internet-enabled device (tablets, PCs, laptops, smartphones). Access methods vary based on the specific Cloud architecture. Standard Web Interfaces are accessed via mobile or desktop browsers using an IP address, domain, or subdomain. If the backend provides an API, dedicated native applications can be developed for the respective client operating systems.
Client App Implementation Example:
Tenko – Developed and deployed native mobile applications for Android and iOS.
Note: Client software development is customized and negotiated individually for each project.