Documentation · 03
Annex B - Interlock specifications
Annex B: cross-network interlock specifications, signal mapping, RACI for interlock failures.
Annex B — Long-Distance Interlock Specifications
Referenced by MSA § 5. One entry per active long-distance interlock crossing the IT backbone between Manufacturing Operations networks. Schema below; example entries follow.
Schema
Each interlock registers:
| Field | Required | Notes |
|---|---|---|
| Interlock ID | yes | Short slug (e.g. mach1→conv-main:part-ready) |
| Producer endpoint | yes | <network-id>:<controller-id>:<tag> |
| Consumer endpoint | yes | <network-id>:<controller-id>:<tag> |
| Semantic | yes | What the bit means in plain English. One-line. |
| Payload size | yes | Bytes; fixed per MSA § 5.1. Always the same bytes, always the same meaning |
| Expected update interval | yes | Milliseconds — how often the producer transmits |
| Maximum allowed loss window | yes | Milliseconds — IT § 3.3 redundancy must hold inside this |
| Fail-safe action | yes | What the consumer does at 4× expected update interval with no message |
| Priority class | yes | Always highest control-signal class per MSA § 3.2 |
| Bandwidth reserved | yes | Bits/sec dedicated end-to-end |
| IT backbone path | yes | Primary path identifier — IT-side switches traversed |
| Backup path | yes | Redundant path identifier per MSA § 3.3 |
| Test method | yes | How either side verifies health (per MSA § 3.5 / § 5.4) |
| Annex C runbook reference | yes | Pointer into the joint troubleshooting runbook |
Example entries (illustrative — automotive plant)
Interlock mach1→conv-main:part-ready
| Field | Value |
|---|---|
| Producer | machining-1:PLC-01:M_OUT_READY |
| Consumer | conveyance-main:PLC-03:M_IN_READY |
| Semantic | ”A new part is ready at machining-1 station 7 for conveyor pickup.” |
| Payload size | 5 bytes — sequence number (2) + bit field (1) + station ID (2) |
| Expected update interval | 100 ms |
| Maximum allowed loss window | 250 ms |
| Fail-safe action | Conveyor stops at boundary, alarms operator, awaits manual confirm |
| Priority class | CS-HIGH (highest control-signal class) |
| Bandwidth reserved | 16 kbps end-to-end |
| Primary path | mach1-fw → it-l3-core → conv-main-fw |
| Backup path | mach1-fw → it-l3-secondary → conv-main-fw |
| Test method | Producer issues heartbeat test sequence on demand; consumer logs round-trip and sequence gaps |
| Runbook reference | Annex C § “Part-Ready Interlock Family” |
Interlock conv-main→asm1:part-handoff
| Field | Value |
|---|---|
| Producer | conveyance-main:PLC-03:C_OUT_HANDOFF |
| Consumer | assembly-1:PLC-07:A_IN_HANDOFF |
| Semantic | ”Part is at assembly-1 station 1 entry, ready for pickup.” |
| Payload size | 5 bytes |
| Expected update interval | 100 ms |
| Maximum allowed loss window | 250 ms |
| Fail-safe action | Assembly entry station alarms and refuses pickup until manual reset |
| Priority class | CS-HIGH |
| Bandwidth reserved | 16 kbps end-to-end |
| Primary path | conv-main-fw → it-l3-core → asm1-fw |
| Backup path | conv-main-fw → it-l3-secondary → asm1-fw |
| Test method | Same as above |
| Runbook reference | Annex C § “Part-Handoff Interlock Family” |
Interlock powerhouse-1→all:steam-available
| Field | Value |
|---|---|
| Producer | powerhouse-1:PLC-02:STEAM_AVAILABLE |
| Consumer(s) | paint-1:PLC-04:STEAM_IN, assembly-1:PLC-07:STEAM_IN |
| Semantic | ”Steam pressure adequate for downstream consumers.” |
| Payload size | 5 bytes |
| Expected update interval | 500 ms |
| Maximum allowed loss window | 1000 ms |
| Fail-safe action | Consumer goes to steam-unavailable mode; production halts at consumer; operator alerted |
| Priority class | CS-HIGH |
| Bandwidth reserved | 4 kbps per consumer |
| Primary path | powerhouse-1-fw → it-l3-core → {paint-1-fw, asm1-fw} |
| Backup path | powerhouse-1-fw → it-l3-secondary → {paint-1-fw, asm1-fw} |
| Test method | Each consumer independently runs link-quality probe to producer |
| Runbook reference | Annex C § “Utility Availability Interlock Family” |
Rules
-
Implicit messaging only. No explicit-message-based interlocks cross the boundary per MSA § 5.1. If you find yourself reaching for explicit messaging, the interface is not an interlock — register it as a § 6 cross-boundary published service instead.
-
Sequence number required, in-sequence not required. The receiver discards stale messages by sequence number; missed messages are not retransmitted. Old data is meaningless to a control algorithm.
-
Fail-safe after 4× expected update interval. Hard rule per MSA § 5.2. Tune the interval, not the multiplier.
-
Bandwidth and priority are non-negotiable once registered. IT acknowledges the reservation in writing as part of registration. Subsequent IT capacity changes that affect a registered interlock are a Major Incident under MSA § 7.
-
Test method must be runnable from MO side without IT permission. Per MSA § 3.5.
-
Photoelectric interlock pattern. The semantic is: “Unless you get a positive indication you’re able to go on these tracks, you don’t go on these tracks.” No assumption of safe-to-proceed. Default state is always fail-safe.
-
Operator visibility into the middle is unresolved. Each registered interlock must point to a section of Annex C describing what the operator does when the interlock falls silent and they can’t see into the IT backbone middle.
Open items
- Standard payload format. Five bytes (seq-2 + bits-1 + station-2) is a starting suggestion, not a mandate. A formal control-signal frame definition would help with monitoring tooling.
- Whether multicast is acceptable for one-to-many interlocks (powerhouse → multiple consumers) or whether each consumer needs its own unicast pair. Multicast is simpler; unicast is easier to monitor.
- Capacity-planning template for registering a new interlock — needs IT signoff on the bandwidth-reservation pool size before this annex can scale past ~20 interlocks.