Managing Industrial IoT Assets in UniAsset

Why connect industrial assets to UniAsset

Industrial assets — chillers, compressors, motors, conveyors, generators, switchgear, pumps, HVAC plant — emit telemetry continuously. Without somewhere to put that telemetry, it stays trapped inside a vendor portal or a SCADA historian, disconnected from the maintenance team's day-to-day workflow.

Connecting industrial assets to UniAsset means every signal is captured next to the asset record itself. The asset card now reads as a single source of truth:

What the asset is, where it lives, who owns it.
Its maintenance history and upcoming PM rules.
Its incidents and supporting documents.
And its live telemetry stream.

That consolidation is the operational benefit of the IoT Signal foundation. You stop alt-tabbing between vendor dashboards and start working from one place.

Plan required: Enterprise

What "industrial IoT" looks like in UniAsset

Phase 1 deliberately stays out of the protocol layer. UniAsset does not run an MQTT broker, OPC UA client, or Modbus poller — it sits behind your existing edge infrastructure and accepts whatever it forwards.

SCADA / PLC / BMS / Gateway
        │
        ▼
Azure IoT Hub  /  AWS IoT  /  custom MQTT bridge
        │
        ▼   HTTPS POST
UniAsset  →  IoT Signal store  →  Asset page

That separation matters: your operational technology (OT) network stays untouched, and UniAsset is purely an information-technology (IT) consumer.

Setting up an industrial asset for signal capture

A workable pattern for each industrial asset:

Register the asset in UniAsset under its physical location with a meaningful category (e.g. "Chillers", "Air Compressors", "Generators"). Assign a serial number so the asset is uniquely addressable.
Record the device identifier(s) that the IoT pipeline knows the asset by. UniAsset accepts an externalDeviceId on every signal, so even if you don't link assetId, you can later reconcile devices to assets.
Configure your IoT pipeline (see Connecting Azure IoT Hub to UniAsset) to POST signals.
Verify by opening the asset and confirming signals appear under IoT Signals.
Set criticality on the asset (CRITICAL, HIGH, MEDIUM, LOW). This is used today by the work-order SLA system and will be used in later phases to weight rule severity.

Operational visibility patterns

Three patterns we recommend for industrial fleets:

1. Continuous heartbeat

Each asset emits an asset.heartbeat signal every 1–5 minutes with no severity. The presence of these heartbeats is itself the signal: a sudden silence is information.

{
  "source": "AzureIoTHub",
  "signalType": "asset.heartbeat",
  "payload": { "uptime_s": 1820, "firmware": "3.4.1" }
}

2. Threshold-triggered events

Edge logic emits a signal only when a metric crosses an operational threshold. Keep the payload rich so the (future) rules engine has enough context to act:

{
  "source": "CustomMQTT",
  "signalType": "temperature.high",
  "severity": "HIGH",
  "numericValue": 92.5,
  "payload": {
    "sensor_id": "T-04",
    "temperature_c": 92.5,
    "threshold_c": 85,
    "duration_s": 120
  }
}

3. State-change events

For binary state assets (doors, valves, motors), emit a signal on each transition:

{
  "source": "AWSIoT",
  "signalType": "door.state.changed",
  "severity": "INFO",
  "booleanValue": true,
  "payload": { "previous": false, "current": true }
}

Tying signals to your maintenance strategy

Even without automation, signal capture changes the way maintenance teams work:

Walk-the-plant inspections become evidence-backed. Before doing the round, sort the global explorer by the past 24 hours and CRITICAL severity. Show up to the inspection with the list.
Replace-vs-repair decisions improve. A high-signal-volume asset that is also high TCO is a candidate for replacement, not another repair pass. Use the global explorer's asset filter alongside the TCO column on the asset table.
Vendor SLAs become enforceable. Vendor-emitted signals (vendor.callout.opened, vendor.parts.delivered) sit alongside your own incident records, making the timeline auditable.
Compliance reports get teeth. Audit-period exports of relevant signal types provide regulator-ready evidence that environmental thresholds were monitored.

Naming conventions that age well

signalType is free-form, but conventions pay off the moment the rules engine ships. Recommended structure:

<domain>.<event>[.<qualifier>]

Examples:

temperature.high
temperature.low
temperature.recovered
vibration.spike
vibration.sustained
motor.runtime.threshold
motor.stop.unexpected
door.open
door.held_open
power.outage
power.restored

The dotted path lets you write future rules with prefix matches (temperature.*) without rewriting your edge transforms.

Roles and access

Within an Enterprise tenant, the IoT signal surfaces follow standard UniAsset role rules:

Owner / Manager / Admin can see all signals across the organization.
Employee users see signals on assets they are assigned to (consistent with the broader employee scoping rule).
Viewer users can read signals but not change them — and Phase 1 has nothing to change anyway.

API keys carry their own permission set. Issue iot:signal:ingest to ingestion integrations only; do not bundle it with write permissions like asset:create.

What this looks like at scale

A single industrial site instrumenting ~200 assets at 1 signal/minute averages ~290,000 signals/day. UniAsset's (tenantId, receivedAt) index keeps the global explorer's first-page query under 50 ms at that volume. For multi-site rollouts in the millions/day range, plan ahead:

Partition IoTSignal on receivedAt (PostgreSQL native partitioning, monthly).
Adopt the retention policy when the cron ships (Phase 2).
Pre-aggregate at the edge for high-frequency telemetry (1 Hz sensors should usually summarize per-minute upstream).

Future automation

The same signal store will power:

Auto work-order creation when a CRITICAL signal arrives for an asset, with SLA timing seeded from the asset's criticality.
Predictive maintenance suggestions computed from historical signal streams.
AI correlation to merge related signals into a single actionable incident.

Adopting signal capture now is the prerequisite — you don't have to redesign anything when those phases land.

Need Help?

If you have questions not covered in this article, our support team is here to help.

Contact Support