02 · Logic
Protection Logic & Scheme Design
Protection philosophy, programmable relay logic, I/O definitions and communications schemes that can be reviewed before they are configured.
- 50BF
- 79
- 25
- 86
- 94
- Interlocking
Numerical relays are programmable, which makes logic both powerful and easy to get wrong. A single incorrect assignment can block a trip or trip the wrong breaker. We define logic as reviewable diagrams and signal lists first, so that the intended behaviour is clear before anyone configures a device.
When this work is relevant
- A new scheme needs its tripping, interlocking and breaker-failure logic defined.
- An operation has raised questions about existing logic.
- A panel builder or integrator needs I/O and signal definitions.
- Hardwired signals are being considered for replacement by communications.
Typical inputs
- Single-line diagram and protection philosophy, if one exists
- Relay models or candidate platforms
- Existing schematics and logic, for modifications
- Station control or SCADA signal requirements
Missing information is common. We list what is missing and agree how to handle it — for example by stating assumptions.
Possible scope
What the work can include
The scope for each project is agreed in writing. These are the elements most often included.
-
01
Protection philosophy
Zones of protection, main and backup functions and how they overlap — written down so later changes have a reference.
-
02
Logic design
Tripping, breaker failure, auto-reclose, synchronism check, interlocking and lockout logic as vendor-neutral diagrams.
-
03
I/O and signal definition
Binary inputs and outputs, trip assignments and alarm signals for each relay, kept consistent with the logic diagrams.
-
04
Communications signals
Definition of signals exchanged over station communications, including how loss of communication should be handled. Protocol and platform details depend on the project.
-
05
Logic review and test definition
Review of logic against the philosophy and definition of the tests that should demonstrate it once configured.
Expected deliverables
Advice, engineering — or both
Advice & review
Independent reviews, investigations and second opinions that help you decide what to do — and explain why.
- Philosophy and scheme review
- Review of logic after an unexpected operation
- Hardwired versus communications-based signalling options
- Interlocking and operating philosophy workshops
Engineering deliverables
Calculations, settings, logic and documentation developed to an agreed scope, ready for your team's review and implementation.
- Protection logic diagrams
- I/O and signal matrices
- Logic test specifications
- Relay logic configuration, where the platform, tools and scope allow
See illustrative previews: Protection logic diagram · I/O and signal matrix · Test specification or verification plan
Dependencies and scope boundaries
- Settings, logic, I/O mapping and communications are separate pieces of work; the scope states which are included.
- Logic diagrams describe intended behaviour. They are not validated until configured and tested in the selected relays.
- Deliverables depend on the relay platform, the information available, the tools accessible and the agreed scope.
How the work usually runs
- 01PhilosophyAgree zones, redundancy and operating principles with your team.
- 02Logic and signalsDevelop logic diagrams and the matching I/O and signal matrix.
- 03ReviewWalk through the logic with your engineers and resolve comments.
- 04Test definitionSpecify the tests that should demonstrate the logic once configured.
Questions we are often asked
Do you design for one relay manufacturer only?
No. Logic is first defined in a vendor-neutral form, then implemented in each platform where that is in scope. Platform-specific limitations are identified during design.
Can hardwired signals be replaced by communications?
Often, but it needs deliberate design: supervision of the communication, handling of quality and test modes, and a clear view of where hardwiring should remain. We assess this case by case.
We had an unexpected operation. Can you help find out why?
We can review the records, logic and settings you provide to identify likely causes and propose corrections. Confirming a cause may need further records or testing on site.
Start a conversation
Tell us what your system is doing — and what you need it to do.
A few lines are enough to start. We will ask for drawings, settings or records later, through a channel agreed with you — there is no need to send them with your first message.