Technical Brief: ArgusForge — Building Vertical Solutions Without Writing Platform Code

Overview

ArgusForge is the solution-configuration layer for ArgusIQ. It enables system integrators, OEMs, and enterprise organizations to define, package, and deploy vertical IoT solutions using ArgusIQ’s modules as the underlying platform — without writing platform infrastructure code.

This brief covers the technical structure of ArgusForge solutions: what constitutes a solution definition, how the components are configured, and how solution definitions are used to deploy consistent, repeatable installations.

The Solution Definition Model

An ArgusForge solution is a named collection of configuration components that together define a deployable IoT application. When a solution definition is instantiated for a new customer or site, all configured components are applied to the new tenant — creating a working deployment that matches the solution specification.

The solution definition has six component layers:

Component 1: Device Profiles

Device profiles define the hardware that the solution uses — how it communicates, how to decode its data, and what fields the decoded data produces.

Structure of a Device Profile

device_profile:
  name: "Feasy Fresnel Temperature Sensor"
  hardware_vendor: "Feasy"
  hardware_model: "FCW001-TH"
  protocol: "lorawan"
  lorawan_config:
    region: "US915"
    class: "A"
    join_method: "OTAA"
    supported_data_rates: [0, 1, 2, 3]
  decoder:
    language: "javascript"
    function: |
      function decode(bytes) {
        var temp = ((bytes[2] << 8) | bytes[3]) / 100;
        var humidity = ((bytes[4] << 8) | bytes[5]) / 10;
        return {
          temperature_c: temp,
          humidity_pct: humidity,
          battery_v: bytes[6] / 10
        };
      }
  output_fields:
    - name: temperature_c
      unit: "°C"
      type: float
    - name: humidity_pct
      unit: "%RH"
      type: float
    - name: battery_v
      unit: "V"
      type: float
  provisioning_defaults:
    reporting_interval_min: 15
    confirmed_uplinks: false

Key elements:

• protocol: The communication protocol (lorawan, mqtt, modbus_tcp, opc_ua, http)
• decoder: For protocols with binary payloads (LoRaWAN, Modbus), the decoder function transforms raw bytes into named fields
• output_fields: The normalized field names and units that Asset Hub stores — these are what dashboards, alarm rules, and Ask Argus queries reference
• provisioning_defaults: The default configuration applied when a new device of this type is provisioned

Protocol-Specific Configurations

For Modbus devices: Device profiles include the full register map — each register address, data type, scaling factor, and output field name. A VFD profile includes register definitions for output frequency, motor current, power, and fault status.

For OPC-UA devices: Device profiles include the node IDs to subscribe to. The decoder is not needed (OPC-UA is self-describing), but the field name mappings are required.

For MQTT devices: Device profiles define the topic structure and the JSON payload path to each field. A gateway-aggregated device (multiple sensors in one JSON payload) has a more complex path mapping than a single-sensor device.

Component 2: Asset Templates

Asset templates define the data model for the physical assets the solution monitors — what fields an asset record includes, what sensor mappings are expected, and what baseline and health scoring parameters are appropriate.

Structure of an Asset Template

asset_template:
  name: "Commercial Refrigeration Unit"
  asset_type: "refrigeration_unit"
  identity_fields:
    - manufacturer
    - model
    - serial_number
    - installation_date
    - refrigerant_type
    - temperature_setpoint_c
    - location_description
  monitored_fields:
    - field: temperature_c
      display_name: "Internal Temperature"
      unit: "°C"
      baseline_enabled: true
      baseline_window_days: 30
    - field: humidity_pct
      display_name: "Humidity"
      unit: "%RH"
      baseline_enabled: false
  health_score_config:
    components:
      - field: temperature_c
        weight: 0.7
        reference: baseline_deviation
      - field: alert_frequency
        weight: 0.2
      - field: time_since_maintenance
        weight: 0.1
  pm_schedule_template:
    intervals:
      - name: "Annual PM Inspection"
        trigger_type: calendar
        interval_days: 365
        checklist:
          - "Inspect and clean condenser coils"
          - "Check refrigerant pressure"
          - "Inspect door seals"
          - "Calibrate temperature sensor"

Key design decisions:

Which fields have baselines: Baselines are computationally expensive and only meaningful for fields that have a consistent operating “normal.” Temperature has a meaningful baseline for refrigeration equipment; door open/close counts may not.

Health score component weights: The weights should reflect what actually indicates health degradation for the asset type. For refrigeration equipment, temperature deviation from setpoint is the dominant indicator (70% weight); for motors, vibration deviation may carry more weight.

PM schedule alignment with vertical standards: A cold chain solution’s PM schedule should match the service intervals that refrigeration manufacturers and food safety programs specify, not generic IoT platform defaults.

Component 3: Dashboard Templates

Dashboard templates define the pre-built dashboard views that the solution provides. When a solution is deployed for a new customer, these dashboards are created in their ArgusIQ tenant pre-configured.

Dashboard Template Structure

Dashboard templates specify:

• Dashboard name and purpose
• Layout (widget grid configuration)
• Widget types and their data bindings (which asset fields, which time windows)
• Default filters (which asset type, which location scope)
• Role assignment (which user roles see this dashboard by default)

Example template component — Cold Chain Overview Dashboard:

dashboard_template:
  name: "Cold Chain Overview"
  layout: "2-column"
  role_visibility: ["TenantAdmin", "Operator", "Viewer"]
  widgets:
    - type: "status_grid"
      title: "Unit Status"
      data_binding:
        asset_type: "refrigeration_unit"
        field: "health_score"
        group_by: "location"
    - type: "excursion_count_kpi"
      title: "Active Excursions"
      data_binding:
        asset_type: "refrigeration_unit"
        alert_type: "temperature_excursion"
        time_window: "24h"
    - type: "trend_chart"
      title: "Temperature Trends"
      data_binding:
        asset_type: "refrigeration_unit"
        field: "temperature_c"
        time_window: "7d"
        display_baseline: true

The dashboard template defines the configuration but not the specific assets — when deployed, the widgets bind to the assets in the customer’s own tenant that match the asset_type filter.

Component 4: Alarm Rule Sets

Alarm rule sets define the detection logic appropriate for the solution’s use case. Pre-configured rule sets eliminate the need for each customer deployment to build alarm logic from scratch.

Alarm Rule Structure

alarm_rule:
  name: "Cold Chain Temperature Excursion"
  trigger:
    type: THRESHOLD
    asset_type: refrigeration_unit
    field: temperature_c
    operator: GREATER_THAN
    value_type: absolute
    value: 41  # FDA threshold for refrigerated food storage (5°C / 41°F)
    duration_minutes: 15  # Must persist 15 minutes before alert fires
  actions:
    - type: NOTIFY
      channels: ["email", "sms"]
      recipients: ["role:TenantAdmin", "role:Operator"]
      message_template: |
        Cold chain excursion detected.
        Unit: {asset.name}
        Location: {asset.location}
        Temperature: {reading.value}°C (limit: 5°C)
        Time: {trigger.timestamp}
    - type: CREATE_WORK_ORDER
      cmms_template: "cold_chain_excursion_response"
      priority: HIGH
      due_hours: 4

Solution-specific alarm logic:

A cold chain solution’s alarm thresholds are derived from FDA food safety requirements. A motor health solution’s alarm thresholds are derived from bearing temperature baselines and vibration industry norms. The rule set templates encode this domain knowledge, which would otherwise require each SI customer to research and configure independently.

Component 5: CMMS Workflow Configuration

CMMS workflow configuration defines the maintenance workflows appropriate for the solution — PM schedule templates, work order types, checklist templates, and parts catalog defaults.

CMMS Template Structure

Work order type configuration:

work_order_types:
  - name: "Cold Chain Excursion Response"
    priority: HIGH
    default_due_hours: 4
    checklist_required: true
    checklist_items:
      - "Document current temperature reading"
      - "Identify excursion cause (equipment failure / door ajar / other)"
      - "Take corrective action"
      - "Verify temperature return to acceptable range"
      - "Complete FSMA 204 excursion documentation"
    post_work_sensor_verification: true
    verification_field: temperature_c
    verification_threshold_above: 41  # °F

The CMMS workflow configuration defines what happens after an alarm fires — not just that a work order is created, but what that work order requires the technician to document. For a cold chain solution, FSMA 204 compliance documentation is a required checklist item on every excursion response work order.

Component 6: White-Label Configuration

White-label configuration defines the brand experience for the deployed solution:

white_label:
  solution_name: "Connected Refrigeration"
  domain: "connected.{customer-domain}.com"
  logo_url: "{customer-logo-path}"
  primary_color: "#2D5BE3"
  secondary_color: "#E8F0FE"
  terminology:
    assets: "Units"
    work_orders: "Service Tickets"
    health_score: "Condition Score"
  support_contact: "support@{customer-domain}.com"
  hide_powered_by: true

Terminology customization allows solutions to use the language of the vertical (a cold chain solution might use “Excursion” instead of “Alert”; a hospital equipment solution might use “Device” instead of “Asset”) without modifying the underlying platform.

Solution Instantiation: From Definition to Deployment

When a solution definition is instantiated for a new customer tenant:

1. ArgusForge creates the tenant in ArgusIQ’s multi-tenant structure
2. White-label configuration is applied to the tenant (domain, branding, terminology)
3. Device profile library is provisioned — available device types for this tenant
4. Asset templates are applied — the asset types and their field schemas are available
5. Dashboard templates are deployed — pre-configured dashboards are live in the tenant
6. Alarm rule sets are activated — detection logic is running for the asset types
7. CMMS workflow configuration is applied — work order types and checklists are ready
8. A deployment checklist is presented — items for the deploying SI or OEM to complete (connect actual devices, create actual asset records, customize site-specific settings)

The deployment team handles the site-specific work (actually provisioning sensors, populating asset records with the customer’s actual equipment). The platform configuration — all the domain knowledge baked into the solution definition — is already done.

Deployment time comparison:

• Solution built from ArgusForge template: 1–3 days for site-specific work
• Solution configured from scratch: 3–6 weeks including platform configuration

Solution Versioning and Updates

ArgusForge maintains versioned solution definitions. When the solution creator updates the solution definition — new device profile support, updated alarm logic, improved dashboard layouts — the update can be applied to all existing deployments through a controlled update process.

Updates are non-breaking for the core customer-specific configurations (actual device provisioning, actual asset records) — the update adds or modifies the template layer while preserving the site-specific layer.

Talk to our team about ArgusForge for your vertical solution.