Safety-system diagnostics — Detection Telemetry

Collection and providers

Use vendor-supported read-only exports with process-safety approval. Never initiate trips, bypasses or unsafe state changes just to test a detection.

• OPC UA audit-capable servers: Auditable actions where supported and enabled; inspect server conformance and vendor documentation.
• Controller, HMI and historian exports: Vendor-specific process values, quality flags, alarms and operational context.
• Independent lab sensors / safety records: Physical-effect corroboration, not a universal cybersecurity log format.

Configuration

• Agree the measurement points, read-only interfaces, sampling intervals and safety boundary with the process owner. Use a simulator or non-production fixture.
• Subscribe to supported audit/alarm events or approved historian exports. Preserve source timestamp, quality, engineering units, asset/tag identity and clock offset.
• Compare independent measurements and record gaps/latency. Do not enable intrusive polling, change controller logic or alter safety setpoints merely to generate logs.

Synthetic event example

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "proposed-safety-system-diagnostics",
  "collector": "illustrative-lab-collector",
  "observation": {
    "asset_id": "lab-safety-1",
    "diagnostic_status": "healthy",
    "bypass_active": false
  }
}

Visibility and validation

There is no universal PLC event ID or configuration command. Visibility depends on vendor, protocol and process. An alarm or process deviation demonstrates an effect, not necessarily a cyberattack.

• Record the lab scope, collector version, effective configuration and expected source fields before testing.
• Use an approved benign action or read-only snapshot appropriate to this type. For destructive, privileged or physical effects, use a reviewed fixture or existing authorized evidence instead of causing the effect.
• Verify the native source record locally and at the collector; compare timestamps, identity, object, action/result and the type-specific fields listed below. Save a redacted real capture separately from the synthetic example.
• Check a normal baseline and collector-loss case. Fixture parsing proves parser behavior only; it does not prove sensor coverage or malicious-behavior detection.

Primary sources

• OPC UA audit event model
• NIST SP 800-82 Rev. 3: OT security