Lost logic: have you forgotten something?
There was a time when industrial Protection Engineers could design their electrical protection to work at fixed settings for the life of the equipment. Utility power supplies were assumed to have a fixed fault level and there were few other energy sources on the network. Modern networks are much more dynamic; renewable energy sources connected near the end of the system can vary the fault level from one minute to the next. Some industries may also want to implement fast load shedding schemes to avoid penalties under the UK National Grid’s TRIAD tariff scheme. Therefore, protection schemes have to react quickly to changes in fault level and power flow. Automating these processes requires careful design of control logic and the sharing of data between protective devices. 

Programmers and Software Engineers have long known about the need for leaving records of design decisions embedded within the code that they write. For Electrical Engineers and Protection Engineers the challenge is greater because logical control is derived from many inter-connected devices rather than a single computer. Keeping track of design changes (both to hardware and software) is therefore critical in ensuring proper function.  
Why don’t I centralise everything?
One solution to the problem of interconnected control devices is to make all remote devices (protection relays etc.) “slaves” which only perform basic protection functions. Any inter-tripping or automated switching is regulated by a central control device or “master” unit. Provided the same inputs and outputs are retained, the logic can be changed at the control device without the risk of creating conflicting control signals. This approach could work for small systems using older, less advanced protection relays; if you are looking to interface an old system with more modern equipment, ask us about the PS8000 system.

There are however a number of disadvantages to centralisation: 
  • The central controller is a common-mode failure mechanism. If it fails, the entire protection system fails 
  • Modern relay products contain built-in features such as synchronisers, re-closers and customisable logic; these features would be unused.  
  • In a very distributed system, control signals would have to be sent long distances and could be vulnerable to disruption.  
Why don’t I standardise logic in all of my relays?
Generic Relay Setting
This is a useful tool when running a system which uses lots of identical relays to perform identical functions. CEE’s latest NP900 range of relays is designed such that all parameters can be saved to an external computer using our SMART9 software then duplicated on any other NP900 relay of the same type.
It is recommended that each relay is assigned a unique name so that it appears correctly when connected to a central SCADA system.
Standardised logic may not always be the best option in more complex systems however.
I keep good records. That should be enough, right?
Good record keeping is always advantageous, but it can sometimes be compromised as systems are added to or changed. Typically this might mean that an outdated drawing is kept on site whilst the “Master” drawing is held in a design office. CEE’s NP900 relays circumvent this problem by storing notes and comments in the relays themselves. Notes can be added to the internal logic diagram and retrieved whenever the relay settings are downloaded onto a computer. There is also a Comments section to allow Protection Engineers to record details of changes or design decisions made to each protection function.

Unauthorised changes can also disrupt record keeping, particularly if system logic is changed temporarily during commissioning without the proper checks to return the control system to its normal running state. CEE’s NP900 relays incorporate a three-level password system which can be used to prevent unauthorised persons from making programming changes either locally or remotely. Most protection functions can also be assigned to different password groups so that the system designer can decide which users have access to each function.
How do I know which signals are being used?
Screenshot of SMART9's logic editor for the NP900
SMART9 screenshot
Updating the logic of protection relays and programmable devices can be difficult if you don’t know which internal I/O signals have been used in internal logic and which are available.

CEE’s SMART9 software includes the “Find Signal Usage” feature to track where each signal has been used in an NP900 relay. You can also see which signals are used as inputs/outputs, which are linked to the disturbance recorder and which are used as internal logic signals. If you aren’t sure whether a software or hardware signal is currently active, all logic block diagrams and I/O tables in the NP900 relays track which signals are active in real time.
I have several revisions of an NP900 setting file stored on my computer. How can I tell what the differences are?
CEE’s SMART9 software includes a tool to quickly identify which inputs, outputs and protection settings are different when asked to compare two setting files. It will also notify you if the internal logic is different between the two files. If you need to easily record your logic in a project file, SMART9 has an option to print the NP900 relay’s customised logic diagram directly without the need for performing a screen capture.
SMART9 compare files tool
I want plant operators in the switchroom to easily see the status of some signals
Why not make use of the NP900’s 16 user-configurable LEDs? Each one can be linked to an internal or external logic signal, latched or un-latched, and can be assigned a description which is visible on the NP900 screen. Because LED descriptions are assigned in the program, it is possible to remotely update them without the need to be physically present on site. This feature is useful when there is a need to re-configure relays on un-manned or remote operating sites.
Tips for updating your logic
Avoid circular logic. Let’s say “logic signal 1” is set to 0 or 1 depending on the status of “switch 1”, but “switch 1” is set using “logic signal 1”. This creates a situation where the status of both “logic signal 1” and “switch 1” will never change state; it is more likely to happen when the “logic signal 1” and “switch 1” are connected via more complex logic, or when they are properties of two independent devices which communicate with each other.  

Be careful how signals are latched and un-latched. With every latched signal there must always be a means of un-latching it; otherwise it would remain active forever.  

Make things easier for the Commissioning Engineer. For complex logic, make it possible to verify intermediate steps in the calculation; especially when internal logic signals are used that don’t link directly to relay outputs. It is also good practice to allow logic to be tested during commissioning. To make things easier, the NP900 relays can have up to 5 programmable control switches assigned to the mimic screen. These can be password-protected and could be used for testing logic signals if required.  

Make your system fail-safe. Consider what will happen when power is lost. The output contacts on NP900 relays can be configured as either “normally open” or “normally closed” in the SMART9 software. However, when power is lost to the NP900 the output will open or remain open regardless of whether it has been set to “normally open” or “normally closed” in the software. If in doubt, use the watchdog (changeover) contact to activate an external alarm if power is lost to the NP900 relay.
Don’t lose track of your logic signals! 
Don’t forget the operator! Even if your newly updated system works perfectly, operators will need some means of verifying that everything is working correctly. Make sure that all new status signals are linked to the SCADA GUI and, where necessary, appear on the mimic screens of your NP900 relays. The NP900 mimic can also be a useful way of displaying the status of items such as earth switches, even if those status signals aren’t used in any control logic.