A protection relay I/O list is not a terminal-number spreadsheet; it is the controlled translation of every functional requirement into an electrical or digital interface with a defined normal state, failure response, timing, ownership and test. If that chain is weak, a perfectly configured relay can be wired to the wrong source, share a hidden common, exceed contact duty or report an unsafe state as healthy.
This article gives a practical workflow from protection philosophy and cause-and-effect logic to signal dictionary, I/O matrix, relay configuration, terminal plan, IEC 61850 engineering and FAT/SAT evidence.
Executive rules
- Define the function and safe failure state before selecting a relay input or output.
- Give every signal one stable ID and one authoritative definition reused across all documents.
- Record source, destination, state semantics, voltage/current, contact form, timing, isolation, supervision and test method.
- Design I/O commons and auxiliary supplies as failure domains; do not discover them after relay hardware is ordered.
- Check output contacts at actual DC inductive make/carry/break duty, not only a generic ampere rating.
- Check binary-input pickup/dropout, wetting current, leakage and cable capacitance over the complete DC voltage envelope.
- Treat hardwired and IEC 61850 GOOSE signals as engineered interfaces with equivalent traceability and failure handling.
- Generate and cross-check terminal plans, schematics, I/O mapping, settings and SCL data from controlled records where possible.
1. Standards and information architecture
| Reference | Use |
|---|---|
| IEC 61082-1:2014 | General presentation rules for electrotechnical diagrams, drawings and tables |
| IEC 81346-1:2022 | System structuring and unambiguous object reference designations |
| IEC 81355-1:2024 | Classification/designation of information and documents |
| IEC 61850-6:2009+A1:2018+A2:2024 | SCL exchange of IED capability, communication configuration, substation functions and relationships |
| IEC 60255-27:2023 | Product-safety framework for protection equipment and associated auxiliaries |
| Relay/interface manufacturer | Exact terminal groups, ratings, isolation, pickup/dropout, timing, contact duty and configuration constraints |
These references support documentation and products; they do not decide the project’s trip philosophy, redundancy, DC system or fail-safe state. Those must be defined by the protection and control design authority.
2. The seven-layer traceability chain
- Requirement: what hazard/operation must be detected or commanded?
- Function: protection, interlock, control, alarm, measurement or supervision logic.
- Signal: precise state/event/data crossing an interface.
- Implementation: hardwired contact/analogue circuit or IEC 61850 data/GOOSE/report.
- Hardware/configuration: relay card/channel, logical node/data object, output relay or gateway.
- Physical/communication path: terminals/cable/DC supply or publisher/network/subscriber.
- Verification: design review, point-to-point check, functional/negative test and evidence.
Each matrix row should navigate both directions. A terminal must lead back to a requirement; a requirement must lead forward to its test. Orphan signals and unimplemented requirements then become visible.
3. Build a controlled signal dictionary first
| Field | Example / question answered |
|---|---|
| Signal ID | Stable, unique project identifier |
| Functional name | “Breaker 52a — closed indication”, not “BI7” |
| Source object | Breaker auxiliary switch, relay function, DC MCB |
| Destination/use | Interlock, SOE, SCADA, protection algorithm |
| State semantics | Contact closed means breaker closed; state at de-energised device |
| Failure state | Broken wire/DC loss/network loss response |
| Electrical profile | Voltage, wetting current, contact duty, polarity, isolation |
| Time profile | Pulse/maintained, debounce, SOE resolution, maximum transfer |
| Quality/security | Supervised, redundant, test-blocked, authenticity expectations |
| References | Requirement, schematic, terminal, cable, setting and test case IDs |
Avoid ambiguous names such as “CB status.” Use separate open and closed indications, define 00/01/10/11 handling and state whether the contact symbol represents the device de-energised, breaker open, or drawing normal-service condition.
4. Convert cause-and-effect logic into interfaces
- For every protection operation, list local trips, remote trips, lockout, breaker-failure start, autoreclose block, disturbance trigger and alarms.
- For every close request, list permissives, interlocks, synchronism/dead-bus condition, anti-pumping and inhibit causes.
- For every equipment state, define position contacts, validity logic, mismatch timer and operator indication.
- For every supervision function, define monitored path, alarm delay, latching, reset and operational response.
- For every external interface, define ownership and the authoritative source of truth.
- Add negative requirements: “must not close when earth switch closed” is as important as the valid close case.
5. Binary-input engineering
- Nominal/minimum/maximum DC input voltage and polarity.
- Guaranteed pickup/dropout thresholds and hysteresis across temperature/tolerance.
- Input current/wetting current and whether field contacts need a minimum cleansing current.
- Shared common terminal groups and channel-to-channel/earth isolation.
- Maximum allowable field leakage from lamps, surge suppressors, TCS resistors or other inputs.
- Cable capacitance/induced voltage on long runs and possible delayed dropout/false pickup.
- Hardware/software debounce versus required event timing and contact bounce.
- SOE timestamp location/resolution and synchronisation quality.
- Test voltage/current and terminal access without energising adjacent channels.
Calculate the complete loop at minimum DC voltage and maximum resistance. At maximum DC, verify input power and leakage paths. A high-impedance input may remain picked up through an LED, suppression network or capacitive coupling after the field contact opens; a properly engineered bleed/interposing solution may be required.
6. Binary-output engineering
| Output duty | Checks |
|---|---|
| Trip/close coil | DC inductive making/carrying/breaking, pulse duration, coil current at voltage extremes, 52a/52b interruption |
| Interposing/lockout relay | Coil inrush/hold, suppression, contact release time and failure mode |
| Alarm/SCADA | Wetting current, contact minimum load, common supply and pulse capture |
| High-speed output | Semiconductor leakage, withstand, polarity, fail state and isolation |
| Latched output | Reset authority, loss-of-power state, persistence and mechanical/electrical indication |
Do not select an output from “8 A” alone. Obtain the manufacturer’s DC inductive duty or L/R rating at the project voltage. Where the breaker auxiliary contact interrupts coil current, show that explicitly. Suppression protects contacts but can slow current decay and device release; verify the protection/closing timing consequence. Use an interposing relay when needed for duty, isolation or contact multiplicity, then include its own DC drop, delay, supervision and failure modes.
7. I/O commons are failure domains
Relay cards often share a common terminal, internal supply, fuse or isolation barrier among several channels. One loose common can remove apparently independent trips or indications. Before assigning channel numbers:
- map every common and card supply from the hardware manual;
- keep redundant protection channels on independent cards, DC feeders and terminal groups where required;
- separate trip and noncritical indication circuits so a field short does not disable tripping;
- respect isolation limits between different DC systems and external owners;
- include spare-channel commons and future additions in fault analysis;
- show internal commons on the schematic even if the relay symbol library hides them.
8. Hardwired versus IEC 61850 GOOSE
| Attribute | Hardwired | GOOSE |
|---|---|---|
| Identity | Terminal/wire/cable/contact | IED, logical node/data object, dataset, control block, VLAN/network path |
| Failure detection | TCS, line monitoring, dual contact plausibility | Quality, state/sequence, supervision, publisher/network/receiver alarms |
| Timing | Contact and input/output delays | Application transfer plus IED/network processing |
| Isolation | Galvanic/test switch | Test/simulation flags, configuration and network controls |
| Common mode | DC supply, cable route, common terminal | Switch, clock, configuration, multicast/VLAN, cyber controls |
| Evidence | Continuity/injection/functional test | SCL comparison, packet/application monitoring and end-to-end test |
The functional matrix should remain technology-neutral until performance, dependability, testability and independence are agreed. For IEC 61850, record the semantic data reference, quality handling, test/simulation behaviour, dataset/control-block identity, subscriber logic and fallback state. IEC 61850-6 SCL is a configuration exchange format; the approved SCD/CID/IID files and tool reports must stay consistent with the project signal dictionary.
9. From matrix to relay channel allocation
- Freeze mandatory functions and redundancy classes.
- Group signals by voltage, isolation, speed, duty, location and failure domain.
- Reserve dedicated trip contacts and independent breaker-failure/retrip paths as required.
- Allocate hardware channels using the exact card/terminal/common topology.
- Assign logical inversion only after contact state and fail-safe philosophy are approved.
- Reserve realistic spares per card/type, not only a percentage of total points.
- Check panel heat, auxiliary burden, terminals, cable cores and future space.
- Export/configure channel mappings and independently reconcile them against the matrix.
10. Terminal-plan generation
A terminal plan must preserve the interface semantics, not just number terminals sequentially. For every connection show terminal strip/number, device pin, from/to object, wire number, cable/core, voltage/system, conductor size/type, bridge/disconnect/test function, screen/earth and spare status.
- Place field interfaces at a clear ownership boundary.
- Use disconnect/test terminals for CT/VT/trip circuits according to their safety function.
- Segregate different voltages, DC systems, analogue quantities and communications.
- Avoid more conductors per terminal than certified; use distribution terminals/bridges.
- Keep redundant channels physically separated when the reliability requirement demands it.
- Control cross-panel links from both panels with one master cable/core allocation.
- Make terminal-side orientation and normal link positions explicit.
11. Example matrix row
| Signal ID | FEED01_CB52A |
|---|---|
| Function | Feeder breaker closed indication / open-close plausibility |
| Source | Breaker auxiliary switch 52a, closes when main contacts reach closed position |
| Destination | Protection IED binary input BI-03; SCADA derived via IED |
| Electrical | 110 Vdc wetted contact, input common group C1, project DC-1 |
| Normal/failure | Breaker open: contact open; broken wire is not uniquely distinguishable without 52b/mismatch logic |
| Timing | SOE at IED; debounce 5 ms illustrative—validate against mechanism bounce and event need |
| Physical | Breaker plug → cable core → panel terminal → IED X1:03 |
| Test | Operate breaker all positions; force 00/11 disagreement with 52b; remove DC/common |
Values above are illustrative. The important point is that the same row captures state meaning, hardware constraint and negative tests.
12. Change and configuration control
- Nominate one controlled signal database/matrix as master and define generated versus manually maintained documents.
- Use stable IDs; never recycle a deleted ID for a different meaning.
- Baseline relay firmware/hardware, settings, logic, SCD/CID, drawings and test cases together.
- Run automated checks for duplicate channels/terminals, missing destinations, mismatched inversion and orphan SCL subscriptions.
- Require impact assessment for common-terminal, DC supply, output-duty and cyber/network changes.
- Red-line site deviations immediately and close them into as-built data before energisation.
- Record who approved each semantic or fail-state change—not just the spreadsheet revision.
13. FAT/SAT verification matrix
- Static compare every I/O row to schematic, terminal, cable, hardware bill and relay configuration.
- Inspect actual card type, common groups, terminals, bridges, labels and segregation.
- Point-to-point test each hardwired input from field contact to IED state.
- Operate each output into representative load or approved simulator; capture voltage/current/timing for critical duties.
- Test contact inversion, pulse/latched behaviour, debounce and SOE timestamp.
- Remove each DC feeder/common and open/short field wiring to verify fail-state alarms.
- For GOOSE, verify publisher/subscriber references, quality, test/simulation, network loss and recovery end-to-end.
- Execute cause-and-effect valid and forbidden scenarios, including simultaneous operations.
- Check SCADA naming, quality, timestamps, alarm class and command select/execute where applicable.
- Archive test evidence against signal IDs and reconcile every defect/change into as-built baselines.
14. Frequent mistakes
| Mistake | Consequence | Correction |
|---|---|---|
| Matrix starts with BI/BO numbers | Hardware drives function | Start with requirements/signals |
| “NO contact” without state definition | Inversion/fail-state ambiguity | Define device state and energisation convention |
| Output selected by AC/general current | Contact weld/failure on DC coil | Check actual DC inductive duty |
| Shared common hidden | One fault defeats redundant channels | Map card/terminal failure domains |
| GOOSE only documented in SCD | Function/test traceability lost | Include semantic matrix and end-to-end test |
| Spare percentage only | No suitable isolated channel remains | Reserve by card/type/common/location |
| FAT checks IED screen only | Field path/failure response unproven | Test source-to-destination and negative cases |
15. Design-release checklist
- Every requirement has implemented signals and tests?
- Signal IDs/names/state semantics unique and stable?
- Source/destination/owner and normal/failure states defined?
- Input voltage, pickup/dropout, leakage and commons checked?
- Output DC inductive duty, suppression and timing checked?
- Redundant channels free of prohibited common failures?
- Hardwire/GOOSE decision supported by performance and testability?
- Terminal/cable/core allocation physically buildable and segregated?
- Relay configuration and SCL data reconciled to matrix?
- Valid, forbidden, loss-of-DC/network and restoration tests included?
- As-built/configuration baseline and change authority defined?
References and further reading
- IEC 61082-1:2014 — Preparation of electrotechnical documents
- IEC 81346-1:2022 — Structuring principles and reference designations
- IEC 81355-1:2024 — Classification and designation of information
- IEC 61850-6:2009+A1:2018+A2:2024 — SCL configuration description language
- IEC 60255-27:2023 — Protection-equipment product safety
Engineering note: Channel numbers, delays and ratings in examples are illustrative. Use the selected relay/interface manuals and approved project protection/control philosophy.