Industrial Asset Event Standard

What is IAES?

IAES defines how industrial asset signals, diagnoses, and maintenance intents are represented and transferred across heterogeneous operational systems.

IAES is not a product. It is a data contract. Any system — sensor platform, AI engine, CMMS, historian, or dashboard — can produce or consume IAES events without knowing the implementation details of the other side.

Principles

1. Vendor neutrality — No dependency on SAP, PI System, Odoo, or any specific vendor.
2. Legacy compatibility — Events map cleanly to CMMS, historians, SCADA, and IoT platforms.
3. Event-oriented — Each object represents something that happened (measurement, diagnosis, intent).
4. Complete traceability — Every event traces back to its origin via event_id, correlation_id, source_event_id.
5. Extensibility — The data payload and metadata field allow new fields without breaking consumers.

Terminology

Common Envelope

Every IAES event shares this envelope structure:

{
  "spec_version": "1.0",
  "event_type": "asset.health",
  "event_id": "uuid",
  "correlation_id": "uuid",
  "source_event_id": "uuid" | null,
  "timestamp": "ISO 8601",
  "source": "vendor.system.subsystem",
  "content_hash": "sha256_16char",
  "asset": {
    "asset_id": "string",
    "asset_name": "string" | null,
    "plant": "string" | null,
    "area": "string" | null
  },
  "data": { }
}

Field Definitions

Asset Identity

{
  "asset_id": "MOTOR-001",
  "asset_name": "Motor Bomba P-101",
  "plant": "Pesqueria",
  "area": "Turbinas"
}

The standard deliberately does not define a full asset hierarchy. Different organizations model hierarchies differently (ISO 14224, ISA-95, custom). IAES only requires enough context to identify the asset.

Event Types (v1.0)

IAES v1.0 defines three event types covering the full observe → diagnose → act pipeline:

asset.measurement

A physical sensor reading.

{
  "event_type": "asset.measurement",
  "data": {
    "measurement_type": "vibration_rms",
    "value": 4.2,
    "unit": "mm/s",
    "sensor_id": "SENSOR-045",
    "location": "bearing_drive_end"
  }
}

asset.health

AI diagnosis, rule engine alert, or human expert health assessment. Includes recommended action.

{
  "event_type": "asset.health",
  "data": {
    "health_index": 0.16,
    "anomaly_score": 0.92,
    "severity": "critical",
    "failure_mode": "bearing_inner_race",
    "fault_confidence": 0.87,
    "rul_days": 5,
    "recommended_action": "Replace bearing immediately",
    "estimated_downtime_hours": 4
  }
}

maintenance.work_order_intent

Declares the intent to create a work order. The consumer decides whether and how to act.

{
  "event_type": "maintenance.work_order_intent",
  "data": {
    "title": "Bearing failure predicted",
    "description": "Inner race defect detected by AI diagnosis",
    "priority": "critical",
    "recommended_due_days": 3,
    "triggered_by": "alert"
  }
}

Severity Levels

IAES defines five severity levels:

Idempotency & Deduplication

Every event includes:

• event_id — unique, never reused
• content_hash — SHA-256 of the data payload (16-char prefix)
• correlation_id — groups related events in a flow

Event Producers

IAES events are produced by systems capable of interpreting operational signals — not by the signals themselves. A PLC knows vibration_rms = 4.6. That is telemetry. IAES begins where interpretation begins.

Intelligence layer producers

Signal sources (upstream of IAES)

Operational systems such as PLCs, SCADA platforms, sensor gateways, and historians emit raw signals or measurements. These are converted into IAES events by downstream intelligence layers.

An edge device MAY produce IAES events directly if it has sufficient intelligence (edge AI, embedded rule engine). But the typical flow is: signals are ingested by an intelligence layer, which then emits IAES events.

The source field is what makes IAES vendor-neutral. A technician with a stethoscope and an AI model both produce the same asset.health event — the consumer doesn't need to know the difference.

Producer Guidelines

Systems that emit IAES events MUST follow these rules:

Required behavior

1. Set all required envelope fields. Every event MUST include spec_version, event_type, event_id, correlation_id, timestamp, source, asset (with at least asset_id), and data.
2. Generate unique event_id values. Each event MUST have a globally unique event_id (UUID v4 recommended). Never reuse an event_id across events.
3. Use dot-notation for source. The source field MUST follow the pattern vendor.system[.subsystem]. Use lowercase, alphanumeric characters, dots, and underscores only.
4. Use ISO 8601 for timestamps. The timestamp field MUST be in UTC with timezone designator (e.g. 2026-03-06T17:50:17Z).
5. Do not assume consumer behavior. A maintenance.work_order_intent declares intent — the producer MUST NOT assume the consumer will create a work order, or create it in any specific format.

Recommended behavior

1. Set correlation_id to group related events. When a measurement triggers a diagnosis that triggers a work order intent, all three events SHOULD share the same correlation_id.
2. Set source_event_id for causal chains. When an event is caused by another event, set source_event_id to the event_id of the cause.
3. Compute content_hash for deduplication. Producers SHOULD compute content_hash as the first 16 characters of the SHA-256 hex digest of the serialized data payload (canonical JSON, sorted keys).
4. Include asset_name, plant, and area when available. These fields are optional but significantly improve human readability in logs, dashboards, and audit trails.
5. Use standard failure_mode values when possible. Common values: bearing_inner_race, bearing_outer_race, misalignment, unbalance, looseness, cavitation, overheating, electrical_fault. Custom values are allowed.

Consumer Guidelines

Systems that receive IAES events MUST follow these rules:

Required behavior

1. Tolerate unknown fields. Consumers MUST ignore fields in data that they do not recognize. Never reject an event because it contains extra fields. This is essential for forward compatibility.
2. Tolerate unknown event_type values. If a consumer receives an event with an event_type it does not support (e.g. a future asset.hierarchy), it MUST NOT error. It MAY log the event and skip processing.
3. Validate spec_version. Consumers SHOULD check spec_version and MAY reject events from unsupported major versions.

Recommended behavior

1. Deduplicate using content_hash. Consumers SHOULD detect duplicate events using content_hash + asset.asset_id + event_type. If content_hash is not present, fall back to event_id uniqueness.
2. Use correlation_id to reconstruct flows. Consumers that display or analyze event chains SHOULD group events by correlation_id and order by timestamp.
3. Use source_event_id for traceability. When displaying a work order intent, consumers SHOULD link back to the health event that triggered it.
4. Map severity to native priority. Consumers SHOULD map IAES severity levels to their native priority system:

Event Flow

A complete observation-to-action pipeline:

System Compatibility

Future (v1.1)

Planned additional event types:

Versioning

IAES uses semantic versioning for the specification:

• Minor versions (1.1, 1.2) add new optional fields or event types. They never remove or change required fields. Consumers built for 1.0 SHOULD accept events from 1.x without error.
• Major versions (2.0) may introduce breaking changes: removing fields, changing required fields, or renaming event types. Consumers MAY reject events from unsupported major versions.
• Producers MUST set spec_version to the version they implement.
• Consumers SHOULD accept events where the major version matches, even if the minor version is higher than what they support.