Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Section
Column
Insert excerpt
FAQ:My Header
nopaneltrue
FAQ:My Header
nopaneltrue
Section
Column

One of the most significant investments in substation engineering, construction and commissioning is the extensive cabling, terminations, isolating and shorting links associated with the connection of the primary current and voltage transformers to the protection IEDs. It is not uncommon to have thousands of wires and terminations, even hundreds of wires just for one bay.

Refer Process Bus - more than just CT/VT

Can you afford TO BE ANY LATER in implementing Sampled Values from CT/VT?

The Schniewindt SAMU provides the opportunity to benefit from:

  1. enable "5-minute restoration" when protection IED fails - refer Contribution to CIGRE 2012 SCB3
  2. reduces number of CT cores to just two protection cores (X prot, Y prot) plus any metering cores i.e. no need for separate cores for X BBP, X Line, Y BBP, Y Line
  3. allows smaller CT cores due to the lead burden for the CT kneepoint is based on short leads to the yard cabinet only
  4. eliminate need for special wire supervision - messages can be "inherently supervised"
  5. increased operational availability with automatic re-routing in case of network failure
  6. reduced risk of CT open circuit - shorter lead runs to SAMU cabinet
  7. eliminate hundreds/thousands of wires between primary plant and secondary IEDs
  8. eliminates extensive drawings - terminal numbering, isolating/shorting links, drawing approval
  9. eliminates extensive wire installation - less cable, less cost of copper, less installation time
  10. smaller cable ducts or simple buried/above-ground conduit
  11. eliminates extensive wire commissioning
  12. eliminates potential re-work of 7-11

IEC 61850 offers the possibility to replace all the wires connecting primary plant to the secondary equipment with the substation LAN.

Using existing CT/VT

The Schniewindt Stand Alone Merging Unit (SAMU) is the simple way to get the benefits of Process Bus applied to conventional 1 A CT and/or  110 V VT.

This  (SAMU) provides IEC 61850-9-2LE outputs for conventional CT/VT and hence providing a direct deployment of Process Bus solutions and benefits.

IEDs supporting IEC 61850-9-2 inputs (reference list) can therefore subscribe to these signals without any additional wiring and associated test/isolation points, thus saving considerable amount of engineering, construction and commissioning time.

This Stand Alone Merging Unit (SAMU) provides IEC 61850-9-2LE outputs for conventional CT/VT and hence providing a direct deployment of Process Bus solutions and benefits:
Schniewindt_SAMU_RHC.pdf

It is supported by this useful tool for viewing the SV measurements:
SV Viewer-S_RHC.pdf

 Schniewindt SAMU (click to enlarge)

 

Application Scenarios :

Units are available in Australia for evaluation.

Contact me for a quotation.

 

A word on synchronisation and IEEE 1588 C37.238 Profile

As far as synchronisation of IEDs sampling the current and voltage - there are already bus bar protection systems in service for 20 years that do this quite happily using 1PPS.  We have trusted that for really important protection such as BBP where wrong synchronisation of multiple sampling units can mean an entire busbar is tripped off.  Just look at the devices like MBCZ (released late 1980's?), MiCOM P740 (released around 2002) and competitors alternatives - these all have a bunch of individual boxes taking bay CT measurements and sending them to a central unit for summation.

The vendors have successfully mastered synchronisation in various forms even a bunch of other proprietary mechanisms that we don't know the detail of. 

Yes IEEE 1588 will put synchronisation and Sampled Values onto the same fibre connecting the Merging Units. but 1PPS does work in the meantime.

Column
width2%
 
Column
width18%

Insert excerpt
FAQ:Contact Menopaneltrue
FAQ:Contact Me
nopaneltrue


Extra Notes:

Insert excerpt
FAQ:Disclaimer
FAQ:Disclaimer