Proof of Concept (PoC) Architecture

Who this is for: Anyone using the bundled proof of concept to validate, test, or demonstrate the SDK.

What you'll learn: What the PoC is, what it validates, and how its Device and Gateway executables and ports are laid out.

What the PoC is

The PoC is a reference implementation used for validation, testing, and demonstration. It is not a mandatory SDK component, it's a tool for proving the SDK works end to end. It validates:

• correct initialization of both the Device and Gateway executables,
• the mutual-authentication flow between Device, Gateway, and Server,
• concurrent handling of multiple Device authentication requests by the Gateway, and
• the fault-injection and Error-Management mechanisms.

The PoC_SDK_v3 + TrustBridge runtime architecture (Device, Gateway, MQTT broker, Cloud agent, CyberRock, TrustBridge BE). 

How it runs

The PoC runs as independent executables:

• Device executables, each compiled in DEVICE_MODE with its own crypto token over USB/SPI.
• One Gateway executable compiled in GATEWAY_MODE, which listens on consecutive socket ports starting from PORT_BASE, one per Device channel.

Channel and port mapping

The Gateway runs one channel per device (MAX_DEVICES = 3) and listens on consecutive TCP ports from PORT_BASE = 8080:

Per-executable config_poc.h

• Gateway: MAX_DEVICES, PORT_BASE, the MQTT broker settings (MQTT_BROKER / MQTT_PORT / MQTT_USER / MQTT_PASS / MQTT_KEEPALIVE), and the crypto-token USB port (USB_COM_PORT on Windows, USB_TTY_PORT on Linux).
• Each Device: PORT (matching its Gateway channel), SERVER_IP (the Gateway's IP, not the broker or cloud; 127.0.0.1 for an all-local run), and its own USB token port.

Related articles: Validation, Test Procedures & Certification · System Architecture Overview · Environment & Runtime Configuration · Split Deployment on Raspberry Pi