Overview
ArgusIQ is an eight-module operational intelligence platform built on a single shared data model. This brief covers the platform’s architecture: how the modules relate to each other, what data flows between them, and the design decisions that enable integrated operational intelligence.
Understanding this architecture is relevant for technical evaluators, system integrators, and enterprise IT teams responsible for deploying ArgusIQ at scale.
The Architectural Foundation: One Data Model
The defining architectural characteristic of ArgusIQ is that all eight modules operate on the same underlying data model. There is no inter-module API layer — one data model, zero sync jobs.
Why this matters operationally:
When a sensor reading arrives through IoT Hub, it is stored in the time-series database. That write operation immediately makes the new reading available to:
- Asset Hub (for health score recalculation)
- Alarm Engine (for threshold evaluation)
- Dashboard widgets (for real-time display)
- Ask Argus (for natural language queries)
None of these modules “fetch” data from IoT Hub. They all read from the same underlying records that IoT Hub wrote.
When the Alarm Engine detects a threshold condition and the CMMS creates a work order, the work order record links directly to the alert event, asset record, and sensor readings — because all of these records are in the same data model, not in separate systems requiring linking.
Module Architecture Overview
Each module has a defined data domain within the shared model. The boundaries are logical, not physical — they define what each module owns and manages, not where the data is stored.
Module 1: IoT Hub
Primary function: Protocol translation, device authentication, data ingestion, and OTA firmware management.
Data domain: Device records (credentials, provisioning status, protocol configuration, payload decoder assignments), raw ingest records (pre-decode), and device connectivity events.
Protocols supported: MQTT (v3.1.1, v5.0), REST/HTTP, LoRaWAN (via embedded LNS or external network server integration), AWS IoT Core, Modbus RTU/TCP, OPC-UA, CoAP, LWM2M, Kafka.
Decoder system: Each device type in IoT Hub has a payload decoder — a JavaScript function that transforms the raw device payload into the normalized field:value structure that Asset Hub stores. Decoders run in a sandboxed execution environment; the normalized output is what all other modules see.
Connectivity to Asset Hub: IoT Hub’s ingest pipeline writes decoded telemetry to Asset Hub time-series records. The mapping from device_id to asset_id is maintained in the device-asset linkage table. A single asset can have multiple contributing devices; a single device can contribute telemetry to multiple asset fields.
OTA firmware management: IoT Hub maintains firmware inventory for device types that support OTA updates. Firmware update campaigns (targeted by device type, tenant, or individual device) are managed through IoT Hub. Update status (pending, in-progress, succeeded, failed) is tracked per device.
Module 2: Asset Hub
Primary function: Digital twin records — identity, state, history, baseline, and health scoring for every physical asset.
Data domain: Asset identity records, time-series telemetry, current state records, baseline statistics, health scores, asset relationships (parent-child, group membership, location).
Time-series database: Asset Hub’s time-series layer uses a columnar time-series storage engine optimized for range queries and aggregation. Default raw retention: 1 year at full resolution. Downsampled aggregates (hourly, daily) retained indefinitely.
Baseline calculation: Daily background job calculates rolling 30-day statistics per telemetry field per asset. Baselines exclude periods marked as maintenance windows or operational exceptions. Baselines are used by the Alarm Engine for relative threshold evaluation and by Ask Argus for anomaly context.
Health scoring engine: Health scores are recalculated whenever any contributing input changes: new telemetry (affecting current deviation from baseline), a new alert event (affecting alert frequency component), or a maintenance event closure (affecting time-since-maintenance component). The health score is a composite index, 0–100, with configurable weights for each component.
Asset relationships: Asset Hub maintains a directed graph of asset relationships — hierarchical (motor → machine → production line → facility), spatial (asset in zone in building), and dependency (this pump requires this motor). Relationship queries enable navigation from any asset to its context.
Module 3: Space Hub
Primary function: Spatial context — floor plans, site maps, device location, RTLS live views, and geofencing.
Data domain: Floor plan records (uploaded images), device pin positions (coordinates on floor plan), zone definitions (polygonal zones on floor plans or geospatial polygons), RTLS location events, geofence rules.
Floor plan rendering: Floor plans are uploaded as standard image formats (PNG, SVG, CAD export). Device positions are pinned as coordinate pairs on the floor plan image. In the live view, device status icons (color-coded by alert status, pulled from Asset Hub health scores) overlay the pinned positions.
RTLS integration: For facilities with BLE or LoRaWAN RTLS infrastructure, Space Hub receives location events from the RTLS location engine. Location events are stored as time-series records in Asset Hub against the tracked asset, with the Space Hub layer providing the floor plan visualization and zone assignment.
Geofence evaluation: Geofence rules define whether a tagged asset should be inside or outside a defined zone. When an RTLS location update places an asset outside its allowed zone (or inside a prohibited zone), the Alarm Engine evaluates the geofence rule and fires the configured alert.
Module 4: CMMS
Primary function: Work order management, PM scheduling, parts inventory, and maintenance analytics.
Data domain: Work orders (all metadata, findings, parts, labor, status), PM schedule records, parts catalog, inventory records, maintenance cost records.
Work order lifecycle: Created → Assigned → In Progress → Pending Parts → Completed → Closed → [Verified]. Each state transition is timestamped. Work orders link to: the asset record in Asset Hub, the alert event (if alert-triggered), the technician record, and the parts records for consumed inventory.
PM scheduling engine: PM schedules define triggers — calendar interval, operating hours threshold, condition trigger (health score below threshold, specific sensor reading). The scheduling engine evaluates all active PM schedules daily (calendar-based) and on every Asset Hub health score update (condition-based), generating work orders when triggers are met.
Integration with Alarm Engine: The Alarm Engine can be configured to create CMMS work orders as one of its alarm actions. The work order is created with a pre-populated template that includes the alert condition, current sensor readings, and the asset’s maintenance history for the relevant condition.
Module 5: Alarm and Automation Engine
Primary function: Threshold evaluation, rule logic, and automated action execution.
Trigger types:
THRESHOLD: reading above/below a configured value (absolute or relative to baseline)RATE_OF_CHANGE: change in reading exceeds configured rate over configured windowDURATION: condition persists for longer than configured timeOFFLINE: device has not reported within configured timeoutSCHEDULED: time-based triggerMANUAL: triggered by user action or API call
Logic operators: AND/OR logic across multiple conditions. Compound rules can require multiple conditions simultaneously (AND: both temperature above threshold AND vibration above threshold) or any condition (OR: temperature above threshold OR vibration above threshold).
Action types:
NOTIFY: SMS, email, push notification, webhookCREATE_WORK_ORDER: generate CMMS work order with configured templateCREATE_TICKET: generate service ticket in Ticketing moduleWRITE_DEVICE: send a value back to a connected device (for feedback control)LOG_EVENT: write an event record to the asset history
Deduplication: Alert deduplication prevents alert floods during persistent conditions. A new alert is generated only when the condition clears and then re-occurs.
Module 6: Dashboard and Widget System
Primary function: Real-time and historical data visualization in configurable dashboard layouts.
Widget types (25+): Gauge, trend chart (single series, multi-series), bar chart, table (sortable, filterable), KPI card (current value + trend indicator), status indicator (color-coded), geographic map (assets on map with status), floor plan embed (Space Hub view in dashboard), alarm list, work order list, health score card, asset hierarchy browser.
Real-time data binding: Dashboard widgets subscribe to state record updates from Asset Hub via WebSocket. Subscribed widgets update without page refresh, within 30 ms.
Role-based dashboard configuration: Different dashboard configurations can be assigned to different user roles. The plant manager sees a site-wide health summary; the maintenance supervisor sees the work order queue and assets in alert status; the field technician sees their assigned work orders.
Module 7: Ticketing and Service Management
Primary function: Service ticket lifecycle management for request-driven workflows.
Distinction from CMMS: CMMS work orders are generated from equipment conditions (alert-triggered or PM-scheduled). Tickets are generated from service requests — user-submitted, customer-submitted, or automatically generated from business rules that don’t map to equipment conditions.
Data domain: Ticket records, service categories, SLA definitions, queue configurations, assignee records.
SLA tracking: Tickets have configurable SLA timers — time to first response, time to resolution. When an SLA timer is approaching or exceeded, escalation alerts notify the responsible supervisor.
Module 8: Ask Argus
Primary function: Natural language interface to the ArgusIQ data model.
Architecture: Ask Argus consists of two components: the user interface (natural language input, response display with citations) and the MCP server layer (domain-specific context retrievers for each ArgusIQ data domain).
MCP server domains: Separate MCP servers provide context retrieval for Asset Hub (telemetry, health, baselines), CMMS (work orders, maintenance history, PM schedules), Alarm Engine (alert history, active alerts), Space Hub (locations, zones), and Ticketing (tickets, SLA status).
Query processing: When a natural language query is received, the Ask Argus intent classifier determines which data domains are relevant to the query. The relevant MCP servers are invoked to retrieve structured context. The LLM receives the query and the retrieved context together and generates the answer. Citations (source records) are included in every response.
Cloud vs. on-premises LLM: Cloud ArgusIQ deployments use an external LLM API for Ask Argus inference. On-premises and air-gapped deployments use ArgusAI (on-premises LLM hosting) for inference. The MCP server layer is identical in both cases; only the inference endpoint changes.
Deployment Architecture
ArgusIQ is available in three deployment configurations:
Cloud (AWS or Azure): Hosted on Viaanix infrastructure. Single-tenant or multi-tenant deployment. Regional deployment available for data residency requirements.
On-premises: Full ArgusIQ stack deployed on customer-provided infrastructure. Supported on standard server hardware (Linux, x86-64). Customers maintain the infrastructure; Viaanix provides software updates.
Air-gapped / isolated: Same as on-premises, with network configuration designed for environments without internet connectivity. ArgusAI replaces external LLM for Ask Argus functionality.
API and Integration
ArgusIQ exposes a REST API for all module functions. The API is used by:
- ArgusForge (solution configuration)
- ArgusOps (fleet operations)
- External system integrations (ERP, CMMS, production management systems)
- Custom reporting and analytics tools
API authentication: API key or OAuth 2.0 / JWT. Role-based access control applies to API access identically to the user interface — an API key scoped to a specific tenant and role cannot access data outside its authorized scope.
Talk to our team about ArgusIQ architecture and deployment options.