Section | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
...
Section | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
So that brings us to the meaning of time itself in say a GOOSE message. Interestingly, or annoyingly (!!), time is not necessarily real time …. “it depends …” Consider the network below where two GOOSE are issued by two publishers for the exact same event - let’s say an opto input being energised on each IED from the same external contact (the one scenario I can concede to the use of GGIO … although a "good vendor's tool" would allow me to rename GGIO to a more suitable specific semantic for my specific application - but that is a whole other discussion Say No to GGIO ). For the moment lets just assume that the internal processing time of detecting the opto input state change to publishing the GOOSE message on first fast retransmit are exactly the same for both IEDs. Let’s assume each GOOSE has a dataset of precisely one, and only one, bit being the on/off status of the GGIO i.e. that would be <<GGIO.Ind1.stVal>>. When the GOOSE is created to be published on the LAN, each IED will add a time stamp <<T>> in the GOOSE PDU “header” (refer IEC 61850-8-1 Ed2 Table A.1) . Which leads us to IEC 61850-7-2 (Ed2), clause 18.2.3.5 T – time stamp We might have some confidence of time synch amongst the publishers and the subscriber, so we could assume that the subscriber will therefore know when each message was created by each Publisher and then use that <<T>> to reconstitute the real sequence of messages being published. However in reality, at best, all that <<T>> gives us is some general idea of the latency of the LAN from creation of the GOOSE PDU to the reception by the subscriber, … not completely the full definition of GOOSE "3 ms" latency", but very close to it. Furthermore, that time stamp is updated each time a dataset element changes - we do not easily know which element that relates to. If we wanted to know when a particular element in the dataset changed status we would have to go back through all the previous messages received (if we have captured them in some way) to pick the one when our particular "element of interest" changed so we can see the time stamp!! So what does the subscribing IED/sniffer really know about time? It will know when it received each message .. but that is all it can be guaranteed to know. In fact any subscribing IED can only work on when it receives the first change of state of that element so the Subscriber's Sequence Of Events is really based on reception time of the message. The difference in the receiving time will be clear, but the actual time of reception is dependent on the time synchronisation of the Subscriber with the rest of the network IEDs and/or a clock master. And in fact, the two messages from the two different Publishers will arrive sequentially because that is the nature of Ethernet as a serial process of one message after the other, i.e. different times despite the trigger of the opto energisation being identical. … and further, depending on where in the network the subscriber is connected, one message will arrive before the other, whilst connecting somewhere else in the LAN they may arrive in the other reverse sequence, or at least with different time differentials between them. .. or worse, consider an RSTP ring network. So measuring the latency of a publisher to subscriber is dependant on the number of intervening switches and links. The virtual break point of the ring can change position in the ring when thing s"happen" that forces a ring re-convergence. Once that happens, the same publish/subscribing pair of IEDs will see a different number of switches and links between them so the latency will almost inevitably be different. So we are left with a very useful but subjective view of when things actually happened “at source” as a Sequence of Events. We can derive a “Sequence of Arrival” such as provided by the FMTP GridEX "GOOSE Multimeter" "Multimeter" for GOOSE and Sampled Values: The only way to know when things happened “at source” when the publisher IED had a function status chage is that each GOOSE dataset is formed including the <<.t>> Data Attribute of the respective Logical Node’s Data Object and Data Attributes … in this example case this means <<GGIO.Ind1.t>> or in other words, the dataset should include three elements of <<GGIO.Ind1.stVal>>, <<GGIO.Ind1.q>> and <<GGIO.Ind1.t>> as this is the time of the last change of either the <<.stVal>> or <<.q>> Data Attributes. Perhaps part of the reason why the <<.t>> Data Attribute is sometimes (often) not included in many datasets is that, as I first mentioned above, it is technically not required for the subscribing IED function in any way - GOOSE subscription works quite happily without knowing the actual date/hour/minute/second/millisecond. Wire based contact output - opto input systems don't know when the function that caused the contact output to change actually decided the function had changed state ... the receiving relay only knows what time the opto input was turned on/off. Finally we need to consider what each IED considers as the "current time". We have all seen those war movies where an attack is to happen "precisely at 11 o'clock" so the last thing the team leader says before the team breaks up is "synchronise our watches - the time now is ...". The reason that is the last thing to do is that the longer two free running clocks are able to drift from each other, the bigger the amount of drift, especially of one clock is not all that stable with high drift rate. So it is with multiple IEDs on the network. If they each have their own free running clock:
So Sub1 would see the two messages arrive based on its own time stamp, but the <<T>> of the PDU header from Pub1 and its <<.t>> in its dataset will be both VERY different to the <<T>> and <<.t>> in the message from Pub2. So what does this mean when we want to do some debugging of GOOSE in FAT/SAT/Commissioning/Maintenance where technicians and engineers are trying to sort out why something happened at the GOOSE level – when did a publisher IED see an event vs another IED vs when did a subscriber know about it from receiving GOOSE??? This then comes down to how well the dataset has been constructed by the IED Vendor (if it is fixed dataset) or by the Systems Integrator or by the Tester. If well-constructed, you can analyse the datasets to extract the <<.t>> Data Attribute time stamps as the basis for Sequence of Events .. of course assuming all IEDs are appropriately time synchronised.
all MUs must be precisely synchronised to start each 1-second window within 1 microsecond of each other, i.e. 1 microsecond COHERENCY. We don’t care even what year it is saying the date/time is but we MUST start each 1-second window with 1 microsecond COHERENCY. Consider a current differential application using two Merging Units: Other than for transformer differential applications, clearly the current flowing through the red sensor (be it conventional or non conventional instrument transformer) is the same as the current flowing through the blue sensor. The samples captured by each Merging Unit at each instant are contained in the Sampled Values dataset being published by each Merging Unit. No error In the example above each Merging Unit has its own independent clock and therefore there is no inherent time synchronisation between the two clocks, hence their 1-second windows will start at a different instant in real time. A common time synchronisation mechanism in substations for SCADA Sequence Of Events log purposes has been the IRIG-B or 1 Pulse Per Second signal, generally distributed over coaxial cable. The overall length of the coaxial cable path means there is a real time difference between the synchronisation of the first IED and that of the last IED in the loop due to the path latency. In general this means their is a spread of time across the IEDs but will generally within about one millisecond accuracy time stamp. We can now consider what effect a one, five and 10 millisecond difference in the start of the 1-second window means to differential relays in particular, or indeed any relay which is using two or more sets of Sampled Value streams: Use case 50 Hz, 4000 Hz sampling, DC offset at fault inception. Four results are provided:
This shows that COHERENCY of time synchronisation of the Merging Units is critical, even if they don't have the same actual time, they just need to start their respective 1-second windows at the same instant, or at worst, within one microsecond of each other. In theory you could use IRIG-B (U.S. military's Inter-Range Instrumentation Group, time code B) or 1-Pulse-Per-Second (1PPS) usually over coax. IEC 61850‑9‑2LE recommended 1PPS over fibre rather than NTP or SNTP, Even so most MU suppliers only provided IRIG-B over coaxial cable at least initially as that is how most relays were being time synchronised for Sequence OF Events. The “proper” synch method for Sampled Values is IEEE 1588 (2008) PTP v2 distributed over the same LAN as the SV, GOOSE and MMS. Note within the one substation, it doesn't matte of the Master clock is showing precise actual time, ... just that all devices within the sub are synchronised to start their one second window at precisely the same instant within one microsecond of each other. IEEE 1588 has a number of implementation profiles. Protection Operation Forensics Based On TimeAnyone who has tried to provide forensic analysis of this knows that the more information recorded about what happened and when (with respect to each other), the better. A common problem for many asset owners seeking to know why their circuit breaker tripped is the lack or somewhat limited Sequence Of Events records and/or waveform capture. My saying is:
The typical contractor excuse of not recording all signals is that individual wire‑based systems would require a 10‑fold or more increase in the number of wires and associated terminations to draw, install, and commission as well as an I/O count limitation on the relays and recording units in the first place. That equals $$$$ which may make them uncompetitive and/or the asset owners budget just doesn't stretch that far in consideration that such records will hopefully only be needed "once in a blue moon"!! Enter the virtual world of IEC 61850. No physical issues But first – what is the meaning of time (stamps) of GOOSE. Actually, the normal Ethernet message time stamp included in all frames is meaningless. The Ethernet GOOSE frame has a time stamp <<T>> of when it was sent. But GOOSE has the heartbeat and fast repetition so for any one change of status, there will be a continuous stream of repeat messages with that same status all with different <<T>>. The only REAL time as far as the various functions in the system is concerned is the time the first change of state message is RECEIVED by the subscribing IED. That message may not be the first of the repeat messages series if there has been for example an RSTP reconvergence. GOOSE is intended to be FAST so message frames were stripped down to bare minimum Ethernet length. Usually they contain several status elements as 1 or 2 bits each as Pxxx.op.stVal plus their associated 8 bits quality flag Pxxx.Op.q. So in principle there is no problem to have say “100” elements representing all stages of protection function operations. However equally the ONLY element that may be needed in the dataset is the "grouped" signal PTRC.Op.stVal and PTRC.Op.q in order to keep the "trip" GOOSE as FAST AS POSSIBLE with the smallest possible dataset and hence bandwidth requirement on the LAN. But of course protection functions and their forensics often need to know what something simply STARTED to operate – it was above threshold and started timing out, but not yet resulting in a Pxxx.Op.stVal change of state. We need to know the value of Pxxx.Str.stVal changed state. So our 4-stage OC and 4-stage EF functions now have 16 status elements alone. And not to forget that the protection forensics may also need to know when the quality flag Pxxx.Op.q (which has 12 bits itself) of the protection function changed state.
26 bits per Pxxx Logical Node. Hence just for 4-stage OC and 4-stage EF requires 204 bits in the dataset t be sent on the wire. If there was 100 Pxxx elements to be transmitted, it would be 2600 bits in the dataset plus of course the ethernet frame header and footer. You might say "So what? - the LAN is at least 100 Mb/s, perhaps 1 Gb/s on the backbone" But still that information does not tell us WHEN any <<stVal>> changed state in the publisher IED. The subscribing IEDs (including any traffic recording device as Sequence of Events /waveform capture) only know when they RECEIVE a message with the first changed value. It is almost possible to deduce when the first change of state message was sent by the publishing IED based on the subscribing IEDs analysis of the SeqNum of each message and the Ethernet frame time stamp <<T>> if you know what the initial setting of the fast repetition <<timeAllowedToLive>> value is for each publisher IED’s messages. A “simple” algorithm could then tell you what time the Ethernet message <<T>> was for the first change of state message. But STILL that is not the EXACT time the Pxxx.Op.stVal changed value! It is only the time the message was created to be published on the LAN which takes some processing time inside the IED after the change of state actually occurred. To understand the difference, the maximum GOOSE latency of three milliseconds is from the time of change of state of the function, not from when it appeared on the LAN. If we want the exact time that a function Pxxx.Op.stVal changed state we need to know its change of state time Consider the time stamp to the millisecond of the time <<2016-12-22 14:42:33:432>> ... that is a LOT of bits on the LAN!! Clearly sending every Pxxx.Op.t in every "trip Goose" is counter productive to teh intent of GOOSE as a FAST transmittal of signals. In any case the subscribing IED doesn't care what that value of time was. It only cares when it received the first message with a changed value of Pxxx.Op.stVal So we have a conundrum - we want to send GOOSE as fast as possible, but we also want to record the time stamp of every change of Pxxx.Op.stVal, Pxxx.Op.q, Pxxx.Str.stVal, Pxxx.Str.q We could rely on IEC 61850-8-1 MMS Reporting to send a complete message with all the necessary information from the source SERVER IED and somehow an MMS CLIENT IED device could process that to derive the Sequence of Events. However given that GOOSE is such a small bandwidth, we could structure two GOOSE messages:
|
...