Architecture

2. Architecture

Data Flow Overview

The system consists of three main components:

• OSS8 (Sensor System)
  Sends telemetry, alarm events, and image data. Receives configuration and control commands from the backend or authorized clients.

• W3S (Backend + Middleware)
  Acts as the central authority for all message routing, validation, and permission enforcement. It applies schema validation, verifies message direction and sender roles, and may consume, forward, or reject messages based on policy.

• Client (User Interface, Machine or Human Admin)
  Authorized web or mobile applications, or backend automation systems, capable of sending commands and receiving sensor data and images. Some clients may have elevated roles, such as IQT Admins, with access to internal commands.

All communication flows through W3S, which performs strict introspection and validation before any data is routed.

Typical flows include:

• OSS8 → W3S → Client (e.g., status updates, alarms, images)
• Client → W3S → OSS8 (e.g., configuration commands)
• OSS8 → W3S (e.g., internal diagnostics or logs not forwarded to clients)

---

Message Flow Types

Messages are classified into the following types:

• Status & Telemetry: Periodic data such as health state, performance metrics, or uptime
• Configuration: Sensor settings, config uploads, and parameter negotiation
• Commands: Explicit control actions initiated by clients (e.g., restart, calibrate, toggle components)
• Event/Alarm Messages: Real-time alerts such as smoke/fire detection, motion events, or environmental thresholds
• Internal/System: Backend-only diagnostics, debug traces, IQT Admin commands; never forwarded to clients
• Image Frames: Binary messages combining a JSON metadata header and JPEG XL encoded image data

---

Directionality Conventions

Each MessageTypeId has an implied and enforced direction:

• Sensor-Originated — messages initiated by OSS8
• Client-Originated — messages initiated by users or client systems
• Backend-Originated — messages generated internally by W3S, such as system responses or automated actions

Unauthorized or invalid message directions are rejected by the W3S middleware, based on:

• The authenticated identity and role of the sender
• The MessageTypeId definition, including allowed senders and recipients