You are on page 1of 194

What & Other are the benefits of the IEC 61850 over other protocols...?

8 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Dhiren Thakker, Isak KEROLLI and 2 others like this You, Dhiren Thakker, Isak KEROLLI and 2 others like this 7 comments

RodneyUnfollow Follow Rodney Rodney Hughes This question appears every now and then. My first response to these questions is that it is not JUST a protocol. First it is an engineering process for an entire system the significance of this single-source-ofdesign-truth SSD and SCD files covering the entire system is often overlooked when just using device specific tools to configure individual IEDs. Second it is a defined data structure and naming convention of every piece of information in the IED. This is also often overlooked as how it applies to, and benefits, every piece of information in the system that needs to be passed from one place to another obviously protection, obviously SCADA but dont forget metering, condition monitoring, automatic controls all defined regardless of the particular vendor chosen. The PTOC.StrVal, .TmACrv and .TmMult are always the pick-up, curve and time multiplier settings of every overcurrent stage regardless of vendor. PTOC .Op is always the operate output of the overcurrent element. The first two alone dont exist in any mere protocol, but their combination in IEC 61850 used in the right way can give you Reusable Engineering both now and at every IED replacement in the

future a message containing PTOC.Op being sent to an XCBR to cause a trip is always the same message for every IED you choose now and for every IED you add at the next refurbishment of the system or replacement of that IED if it fails even if that is in 20 years time and the original brand of IED is no longer available. Third it has GOOSE which are for sending event status information in very short times mere protocol based polling of information cannot achieve this response peer-to-peer. Fourth it has Sampled Values which is information relating to instantaneous samples taken every 78 MICROseconds (power quality) also just not possible in polling protocols. The third and fourth lead to another favourite saying sorry and respect to my DNP friends - is DNP doesnt stand for Distributed Network Protocol but rather Does No Protection :) . We also must remember that IEC 61850 is no longer just about a substation it has data models and applications for energy storage systems including Electric Vehicles (potential storage, actual storage, rate of storage/discharge..), distributed energy resources (controls, setpoints, schedules, pricing), hydro power (position of gates, height of water), wind (direction of turbine, angle of blades, position of lift in the tower). So you can see it is far more than just about a protection relay function and a SCADA control of a circuit breaker. So to paraphrase several posts by Kalrheinz Schwarz in his IEC 61850 Blog - Its simple! IEC 61850 has everything the protocols have plus all the good stuff they dont
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

HerbUnfollow Follow Herb Herb Falk I like Rodney's summary, but I would like to add a couple of items: 1). A standardized configuration language (Substation Configuration Language - IEC 61850-6) that includes the ability to represent power system topology. This configuration language also include communication addressing information. 2). Due to SCL, 61850 offers the ability to auo-configure SCADA system front ends.

3), There is ongoing work to harmonize CIM and 61850. This would lead to a more robust/easy workflow between EMS and Substation deployments (a real cost saver). 4). All of this demonstrates the concentration of 61850 is to dramatically decrease life cycle/integration costs. This is the business driver, not the conveying of information from point A to point B, that truly differentiates 61850.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

EricUnfollow Follow Eric Eric Stranz Well said gentlemen.


6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Or as Erich Gunther is fond of saying, "IEC 61850 isn't a protocol, it's a way of life." Unfortunately, many utilities can't see past the retraining costs to the long-term lifecycle savings. I just finished interviewing six utilities about the migration from serial to IP-based protocols, and even those who were leaders in the changeover to IP said they weren't considering IEC 61850 for that reason. How can we help eliminate that barrier?
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

TomUnfollow Follow Tom Tom Berry Rodney - can you clarify what you mean by "entire" system? As I understand it, IEC61850 is designed for automation (monitoring, control, protection interlocks, configuration, etc) within a single substation. Clearly it can be extended to cover mulriple substations, but how scalable is it? In a previous discussion in this group about the application of 61850 to distribution automation, people mentioned systems of only 100 nodes.
5 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes 'System' is whatever IEDs need to talk to each other - yes, generally the substation is one system but I have seen many IEC 61850 systems engineered as only using the device specific tool to configure the communications - i.e. in crude terms instead of mapping the function trip output to a physical contact of the IED in the proprietary scheme logic, they map it to an IP address - OK this saves a lot of engineering of external wire numbers but it is still device-by-device, signal-by-signal specific engineering whereas the top down approach of Part 6 (SSD=>>SCD=>>IID/CID) generates the system engineering out of which "falls" the individual device configurations ... and that is Reusable engineering since the PTOC.Op signal being sent to the XCBR to trip the breaker is the same today and forever, regardless of whose IED it is whereas the device-specific tool means you have to jump into that detail and re-do that process every time for every IED and every time you change the relay. That sounds very critical of processes to date but there has been very little choice before to so anything else. However there are increasingly better vendor-independent tools and increasing

numbers thereof nowadays. I'm also pleased to see you mention 'monitoring' as being part of the 'system' - Condition Monitoring has the potential for thousands more data points and information flow around the substation. IEC 61850-90-3 identifies some 155 Data Objects (and so say 1000 Attributes) just associated with a transformer CM application. The number of nodes (presumably you mean IEDs?) connected to the LAN is all about IP addressing and segregation - just like a huge office has more than 100 PCs all connected to the overall LAN all happily talking, you just need an appropriate LAN architecture which has to be thought about in all respects - i.e. no of devices, addressing, what is the effect of a switch or fibre failure, traffic flow, and bandwidth, what happens when doing maintenance on the primary/secondary or LAN etc. Sampled Values we know is particularly bandwidth consumer so within a particular network segment you may have limitations of the switches - either split the physical LAN segments or VLAN or domains or get faster switches or all of the above...
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Tom R.Unfollow Follow Tom R. Tom R. Janca Rodney, Great explanation on the network side--network segmentation is important to achieve the necessary node counts reliably with scalable capacity. What is necessary to enable the real value in multiple substation automation systems say over a regional circuit, is to consider the different traffic flows and structure the network to serve the circuit not just connect the nodes. Consider the data or in teleprotection the zones that need to be mutually aware and structure the network appropriately. GIS and electrical system information can be used to create a tailored network which serves a function securely without routing. I think we can leverage some of the great advantages you discuss with 61850 when utilities build the right packet and optical networks to enhance automation not just pass information. Assisting better processes in 61850 implementation as you describe and enabling the benefits beyond a single substation are important to unlocking the value in packet based electrical system automation.

Great post and comments! Thank you

BharathirajaUnfollow Follow Bharathiraja

Is it possible that Scada server can send/receive GOOSE message to the IED's. If it is possible which are the scada server supporting GOOSE with native IEC61850 driver.
23 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

26 comments Jump to most recent comments

WikuUnfollow Follow Wiku Wiku JULIANTONO IMHO.. computer HMI role is client... IED's are the servers.. and.. communication between IED and computer is vertical communication, which is use MMS, not GOOSE.. GOOSE is intended for horizontal communication, communication between IED. but.. if you insist that your SCADA server can receive/send GOOSE, then you must implement the GOOSE capability in your server.. ... impossible is nothing ... :D 22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BrianUnfollow Follow Brian Brian Stickney ReLab Software has an OPC Server with IEC-61850 GOOSE Driver. This product was design to specifically meet the requirements you have identified. You can download a demo version at www.relabsoft.com. You can send me an e-mail at bd_stickney@relabsoft.com if you would like information on the applications of the product. This solution will work for any SCADA that supports OPC. 22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

NikunjUnfollow Follow Nikunj Nikunj Patel RBHSolutions has an IEC61850 Server with IEC-61850 GOOSE Driver (Also OPC ---> IEC61850 protocol conversion). This product was design to specifically meet the requirements you have identified. If you want more information and details please kindly send me an email to nikunj.patel@rbhsolutions.com or birinder.singh@rbhsolutions.com or call Mr. Birinder on +91 9872807437 We have proven solutions for this kind of systems. 22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes A similar lengthy discussion came up about a month ago in the Linked In "Substation Automation" Group "In your view, what are the differences between a substation gateway vs a substation server?" Fred Ma eventually asked in that Discussion "if you believe both gateway and server only differ in terminology, can we put GOOSE FUNCTION in both?" so its worthwhile to join the Group to view. Im assuming that you are using the word server to mean a computer of some sort at the substation level acting as a HMI/gateway/RTU type substation level functions. I'll just ignore the nuance that by definition all devices would receive a GOOSE message as a multicast message but it is a question of whether it Subscribes to the GOOSE. Substation level server PCs definitely need to Subscribe to GOOSE. It is very rare that they definitely are truly the Event source and hence definitely need to Publish GOOSE. The acronym is GOOSubstationEvent. It is intended to deliver messages very fast to other

IEDs for the critical real time operation of the substation in a Publisher/Subscriber relationship. The substation IEDs will probably have both GOOSE Publisher (sending) and GOOSE Subscriber (receiving) capability. This is distinct from a Client/Server relationship used for most SCADA communications where the gateway/HMI/substation level PC is the Client and the protection IED is the Server (note the terminology confusion of a substation level PC as a computer server hardware whereas the relay is the communication services Server) The substation level functions on the gateway/HMI/RTU. definitely need to Subscribe to (i.e. receive) GOOSE - they have to detect messages that indicate when something has happened prot operated, CB opened. Etc We then have to ask what Event is only detected by the gateway PC (server hardware) that would need it to act as a Publisher of GOOSE that other IEDs need to know about as critical real time information? Unless there is some sort of direct I/O to the substation level or some special algorithm that result in an event that needs to be sent to the IEDs with critical time limits from occurrence to reception of a few milliseconds, it is hard to conceive of many signals that the station level functions sitting on a substation PC server will need to issue as GOOSE messages for the substation IEDs to subscribe to. Yes the gateway will issue SCADA commands to the IEDs but this is the gateway acting as the Client and the IED as the Server in a Client/Server communication relationship. The station level may well have some algorithm like voltage regulation or auto reclose whose output could be classed as an "event" (just like a relay algorithm operates it is classed as an event that is related to GOOSE). When these functions operate they also need to issue commands from this level to the IEDs but these can use normal commands they "could" use GOOSE as a command mechanism but to me youd have to have a high speed/performance related reason why the normal commands defined in the Abstract Communications Service Interface arent suitable. There is the general discussion of course of how to send GOOSE between substations for say intertripping related to IP domain limitations of GOOSE on the Ethernet and tunnelling which need special treatment. However the question is still whether the gateway is the true source of that GOO Substation Event or it is just passing a message from an IED in one substation to an IED in another through the gateway. 22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DustinUnfollow Follow Dustin Dustin Tessier I agree with the bulk of what you're saying Rod, but we have encountered instances where clients would like to see GOOSE functions that traverse between the Station bus and Bay Bus. There are usually two drivers for this functionality: one being for complex SPS schemes (When TL1 is I/S, and TL2 is O/S & the line loading of TL3 is greater than X MVA, disable A/R on TL4) in which case the Station Bus/Data Conc. is the only source that contains all this information. Considering that this has been deemed a protection class function, speed is of the essence. The second driver is in cases where clients want to have a standardized control mechanism (ie. GOOSE), whereby every time a switch is operated (either manually or via a protection) it's done through a GOOSE message. This allows the clients to easily filter and analyze their SOE/protocol analyzer data without needing to drill into any MMS reports, etc. As to whether there's a use case for GOOSE functions between the Enterprise/EMS bus and station bus, I have yet to see this requested, although there's a growing curiosity for GOOSE between the station bus and field devices (ie. reclosers,etc). In my opinion these unique applications; if you can live with the security risks and >100ms delays with a DA GOOSE application, then it makes sense. However for a SCADA application, I can't see there being a need. There's no P in SCADA.... 21 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes As I said, there may be some sort of algorithm in the station computer to control interlocking, autoreclose, volt reg etc which "operate" kind of like an "event" in as much as a protection algorithm which operates is an event that we would normally communicate through GOOSE.

Remember that GOOSE is not a command like "disable A/R on TL4". Using it as such is overburdening the IEDs, Station Computer and your bandwidth. As my Dad always said, use the right tool for the right job GOOSE is designed for the ultrafast messages less than a few milliseconds where there is no possibility in the available time to verify the message has been received and responded to. A command to Enable/Disable A/R is not so time critical and in any case you would really want to have the command verified as have been received and carried out. GOOSE is a message that says "This function status is true/false" and the receiving device has to know what to do as a result of noticing a change in that status. e.g taking a PDIS element operation which changes the PDIS .Op attribute = True/False (or for CB position it would be XCBR.Pos=Open/Closed etc for other functions), the IED Publishes a multicast GOOSE to the network (with absolutely no knowledge of what devices are Subscribing to receive the message) which keeps saying every second "PDIS.Op = False" "PDIS.Op = False" "PDIS.Op = False" Then eventually when the event happens it changes to say in a fast repetition "PDIS.Op = True", "PDIS.Op = True", "PDIS.Op = True", "PDIS.Op = True", eventually slowing to 1 second repetition until it again changes back to "PDIS.Op = False" when the fault clears and the PDIS resets. The IEDs which Subscribe to the GOOSE then have to detect the change from False to True and decide in that case I will now trip the CB/start autoreclose cycle/start CB Fail function .. whatever the device is supposed to do. It is essential to the security of the protection function that this repetition is maintained in order to keep proving the system is able to transmit and receive the ultra-critical protection operation event. Using GOOSE to send commands to specific functions means a LOT of unnecessary GOOSE (and hence totally counterproductive to the purpose of GOOSE) i.e. assuming 4 TLs as per your example you would need to have 4 individual GOOSE Published by the Station Computer every second saying "A/R on TL1 = Enable" "A/R on TL2 = Enable" "A/R on TL3 = Enable" "A/R on TL4 = Enable" "A/R on TL1 = Enable" "A/R on TL2 = Enable" "A/R on TL3 = Enable" "A/R on TL4 = Enable" "A/R on TL1 = Enable" "A/R on TL2 = Enable" "A/R on TL3 = Enable" "A/R on TL4 = Enable" Which then changes in your example to "A/R on TL1 = Enable" "A/R on TL2 = Enable" "A/R on TL3 = Enable" "A/R on TL4 = Disable" Noting that for each and every receipt of these GOOSE every second, each IED has to send back IED1: TL1 A/R Enabled/Disabled IED2: TL2 A/R Enabled/Disabled

IED3: TL3 A/R Enabled/Disabled IED4: TL4 A/R Enabled/Disabled One outgoing GOOSE creates four return every second. So you end up wasting bandwidth with unnecessary GOOSE and processing power of the IEDs and the Station Computer having to decide what to do as a result of receiving the GOOSE. As distinct from a one off command to one IED TL4: Enable A/R and a 1 off response Done I liken this to a to a fire alarm system over the public address speaker in your building which is effectively [hopefully] constantly saying no fire alarm, no fire alarm versus the boss using the public address system to tell you and every other person every second saying Do this task, do this task and you and every other staff member every second having to respond over your own microphones for everyone to hear Heard you, Heard you .. Please don't abuse/overuse GOOSE - they bite back! 21 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DustinUnfollow Follow Dustin Dustin Tessier Understood....GOOSE is required for time critical applications, and A/R, xfmer tap back. etc and other ancillary controls - agreed - are not time critical on their own. However, when these same controls are incorporated into an SPS scheme they must adhere to the stringent req's that come along with protection applications. I remember implementing an SPS that initiated a three stage automatic xfmer tap back, and since it monitored and controlled a tie line, the same rules (and more) applied to it's functional req's. At the time we were forced to use a TFDR (only IED that had that many AI) so we were already introducing latencies. If a SAS, which housed all the pertinent data, was available, this scheme would have been easily implemented with MMS reports to the DC, whom would then process the logic and execute GOOSE commands as required. As for the following, I'm a bit confused. "Noting that for each and every receipt of these GOOSE every second, each IED has to send back IED1: TL1 A/R Enabled/Disabled" You mention a frequency of ("every second") which sounds more like an integrity period of a UBRCB/BRCB, and not so much a GOOSE message??? The integrity period is not meant to

correspond with an "event" change, whereas the GOOSE (GOO-Substation-Event) is.... I'm with ya on overusing GOOSE.....fortunately many - not all - vendors only support a half a dozen or so GOOSE messages so for the time being we're forced to be frugal with our Geese. 20 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hi Dustin. GOOSE is a repeating message which when there has been no change of status (no event) it keeps repeating once every second. i.e it keeps sending its last status of the attribute eg that the PDIS has not operated.When the PDIS element operates, it changes to a new message "PDIS has operated" with fast repetition which slows down 1st repetition 5ms, second 10ms, thrid 20ms etc untill it is just being repeated every second again. When the PDIS resets, a new change of status is sent "PDIS not operated", again with the fast repetition eventually reverting to once every second.So your example is sending out a command (as a GOOSE) every second "turn A/R off". This message keeps repeating every second . Therefore as a command which the sender has no idea which devices are subscribing to this message, so it will need to get another GOOSE coming back every second to confirm "The A/R is off". The next second the receiving IED receives the same command to "turn A/R off" so since its own status has not changed it will keep sending back a GOOSE confirmation that indeed "A/R is [still] off". Until the conditions change to cause a new message "turn A/R on" which is repeated quickly, the receiving IED then notes the new GOOSE as a command, changes its A/R status which as an event triggers a change to the GOOSE "A/R is now on". which it quickly repeats, eventually slowing to "A/R is [still] on" Oh, and silly me how could I have forgot what is the Logical Node and Attribute that corresponds to TL4 A/R Enable/Disable that would trigger a change in the GOOSE dataset being sent from the Station Computer? Is it GGIO? You know where this is going . This

would result in another non-descript GOOSE dataset which will look something like this meaning for the four A/R elemenst in the 4 TLs: GGIO45612.SPCSO1 = False, GGIO675443.SPCSO1 = False, GGIO13452.SPCSO1 = False, GGIO76239.SPCSO1 = True The numbers after the GGIO is theinstance number of the GGIO but nowehere is this inherently described as an A/R anything.so you are back to the problem of "mere protocols" with an ad hoc signal list of data points with no semantics. Not very meaningful! i.e. not in the spirit of self description that the Standard calls for. I'd rather use an ACSI command that has semantics something like (ignoring the actual ACSO SetVal... part and whatever the correct attribute is going to be.: RREC23.AutoRecSt=On Much more meaningful for your message-logger than another GGIO "thing" 20 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Hi, As at the 61850 client level, Indications are only required for monitoring purpose, we have not seen GOOSE requirements at practical implementations. GGIO set for GOOSE are also made part of Reports, so client have the report data with required GGIO status. For commands GOOSE is never recommended as we need confirmed services that command is received and most of the implementation is in the control system are SBO type, so it is mandatory to have a Connected Confirmed service for Control. The one example I could see 61850 Clients where in the existing systems customers dont allow to change anything and ask to integrate as it is, so if whatever GGIOs etc. are configured as GOOSE shall have to be considered as it is. Mr. Bharat, provide more details about the GOOSE usability requirements for CLIENT so that we can provide more information.

Regards Birinder Singh www.rbhsolutions.com 19 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

Jos LusUnfollow Follow Jos Lus Jos Lus Pinto de S I agree with Mr. Tessier, in that sometimes we need a PC capable to both subscribe and publish GOOSE. Not for the sake of any SCADA function, but for some complex substation-wide automation logic. Actually I have just finished a prototype project on that topic, but the thruth is that it is not easy to find a PC software capable to quickly publish GOOSE. The reason for the PC is the desire to employ Open PLC software and IEC 61131-3 logic programming. Some people here is saying that to command GOOSE are not suitable. That is right regarding SCADA functions, but GOOSE are just an option for hardwired connections. If we want to replace some old Substation automatic controllers, in which there were hundreds of signaling wires and dozens of command wires to the CB, GOOSE are the right tool - for both to "read" status and to "write" swithcing orders - provided they are fas enough. 19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku

Wiku JULIANTONO AFAIK... for complex-substation-wide automation logic, I believe it is distributed already on each IED, which then all IED communicate each other on the selected events and status via GOOSE as per in the goose_control_block on each IED... in this case, I think, in such way, we do not need old-skool centralized automation-logic in one server anymore.. even further, we can leave those IEDs talk/communicate each other creating/operating the complex-substation-wide automation logic. as per configured. without any PC involved.. PC, only then needed to see what is going on in the system.. PC, only then needed for record event-list and store them in an archive... in case we would like to see the GOOSE traffics, then we can run such a GOOSE sniffer on the PC... CMIIW..

so... let's take back to the first question... what is the actual intention of the questioner so that he want a PC which could send/receive GOOSE.. by then, we can start to understand his requirements.. Either he want to use the PC to be actively involved in GOOSE traffic creating/operating the complex-substation-wide automation logic... or... he want to use PC to send commands to IED... If he want to use the PC to send/write commands to IED and receive/read the status back, then it is already there with MMS traffic with this kind of report_control_block scheme... no need to apply GOOSE driver in the PC... If he want to use the PC to be actively send/write or receive/read GOOSE to each of IED, then sure he needs PC with GOOSE driver on it...

I think, it is not the matter of it can or it can not... allowed or not allowed... suitable or not suitable....but, as per Rodney said, we must back to the spirit of the technology offered by the standards... 19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

HerbUnfollow Follow Herb Herb Falk There are several OPC Servers that allow a PC in a substation to send/receive GOOSE messages (SISCO has one). However, the better question is what is meant as SCADA (e.g. in a substation or in a control center). Having GOOSE "brouted" to a control center is possible and being done within several systems. The question is whether the control center SCADA system has a front end processor that is capable of GOOSE send/receive, Obviously, that answer depends on the SCADA system. 19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Hi, We do have native GOOSE (Send / Receive) support in our SCADA Client software, it is good and fast but offcourse PC cannot have the speed of embedded system. But again as Mr. Wiku mentioned and i have mentioned in my earlier post, there is no practical requirement at client side. I am waiting for the Question actual requirements, then we can discuss this further. Regards Birinder Singh 19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jos LusUnfollow Follow Jos Lus Jos Lus Pinto de S To Wiku: Protective relays can not be programmed for complex logic whit IEC 61131-3. If you want to do that (complex logic programmed through 61131-3), you have to use a PLC. The problem is that PLC manufcturers do not devellop IEC 61850 fast interfaces (with GOOSE), because the Power Systems market is too small for them. That is why PCs are an option for that. PCs are not designed for real time, but their processors are much more powerfull than most IEDs processors. In addition, for complex logic only they do not have to perform real-time demanding algorithms, such as Fourier Transforms on milisecond samples. The fact is that there are some Soft PLC very fast running in PCs, so the only problem is really the speed of the 61850 interface. 1 to 5 ms would usually be enough, but the 50 to 100 ms of interfaces using MMS are too much for automation, allthoug not for SCADA functions. Thats the point 18 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO @Jos: could you please take a look at following link? o http://www.google.com/search?q=cap531+1131&ie=utf-8&oe=utf8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a o http://www05.abb.com/global/scot/scot296.nsf/veritydisplay/b5ccd4ce19a43423c1256fce00120d f4/$file/1MRK511056BEN_en_CAP_531_1.3__Graphical_configuration_tool_according_to_IEC_1131.pdf o

http://www05.abb.com/global/scot/scot354.nsf/veritydisplay/2d645b494c09ead4c12578570041e 5f6/$file/1mrk511088-uen_en_cap_531_1.5__useras_manual.pdf 18 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO This Siprotec also has CFC logic which is conform to IEC 61131 in Structured Text format. http://siemens.siprotec.de/download_neu/devices/1_General/System_Manual/SYSTEM_MANU AL_B3_SIPROTEC4_DIGSI4_EN.pdf 18 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO while this one, also has PSL (Programmable Scheme Logic) which is fully compliant with IEC 61131-3 http://www.global-download.schneiderelectric.com/85257849002EB8CB/all/B391A9D446189109852578620078087E/$File/c%20264p _1826en.pdf 18 days ago Unlike Like

Reply privately

Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Two points: PLC manufacturers are beginning to support IEC 61850. The challenge for them is not so much the size of their market as it is the challenge of adapting IEC 61850 to a completely generic product like a PLC. The IEC 61850 object definitions must be mapped to PLC programs that are completely determined by the user. The PLC interface must provide not just an IEC 61850 interface, but also design tools that work with their PLC language and memory structure. Such products are under development if they have not already been released. I would also question that it takes 50-100ms to process an IEC 61850-8-1 command. That may be true for some small devices using very small processors, but IEC 61850-8-1 performs MUCH better than that on many plaforms. 18 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MansourUnfollow Follow Mansour Mansour Jalali Hello Friends I believe development will not be stopped by IEC61850. In contrary standard is capable to support any architecture and SA design. We all know Goose massage is intended to be for time critical event, which server client type of communication could not be considered. Todays Station level devices, such as HMI (PC), Gateway (RTU or PC) or PLC (if is used) are not yet fast enough to be utilized for most of the time critical signals, But I assume marketing and competition will force the manufacturer to have it available, and I will not be surprised when more devices are available in the market place which could perform, some of the bay level functionality will be migrated to these (station level)

devices. And our todays SA architecture will be influenced by such development but this is future. 16 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Indeed the Standard has been designed to be a catalyst and support innovation. I think we all agree that a Gateway or Station Computer will need to act in a Client role and a Subscriber role to IEC 61850 messages. It is good to see that some vendors already have the CAPABILITY to Publish GOOSE to make sure they can comply to any and every user's specification. The question is really When does a Gateway/Station Computer NEED to act in a GOOSE Publisher role? There may be new innovations searching for good answers to problems where Gateways Publishing GOOSE might be the right answer. However in the same way as the original decision to provide GGIO Logical Nodes was probably a good idea for applications/functions not yet otherwise modelled, this quickly devolved into lazy and incorrect over use of GGIO which we now hate, when one of the 230 LNs available today would probably be more appropriate as "the right tool for the right job". To identify the NEED to Publish GOOSE by a Gateway or Station Computer we need to look at the whole SAS operation and ask: what event in the substation or information is known/detected ONLY by the Gateway that may be of interest to the other IEDs and which NEEDS a 4-millisecond communication time across the network that ACSI could not do and therefore to warrant using GOOSE Publisher functionality ? Eg the Gateway may find out about the CB position but it has probably learnt this from a message from another device so the Gateway does not need to initiate a GOOSE to repeat this same information over the network.

If the Gateway actually has its own physical I/O (i.e. as an RTU & gateway combined) then there may be some hardwired signals which are ONLY connected to this box which other IEDs might benefit from knowing - e.g. suppose the position of the earthing switch is ONLY connected by hardwires to the RTU then the other devices would NEED to have a GOOSE Published from the RTU for interlocking purposes. In this case the Gateway is the sole SOURCE of the physical event/information on the network. If it is a Station Computer without any direct physical I/O but is doing a bunch of calculations e.g. voltage regulation, then the requirement to raise or lower the tap position (based on calculation involving actual volts, actual line current, tap position discrepancy etc) needs to be communicated to the appropriate device. This could be sent as GOOSE status to be interpreted as Commands with two pieces of information being continuously sent with the repetition delay every second as "Volts low=false, Volts high = false" - the Subscribing IED would then decide to not do anything. When an calculated undervoltage condition occurs this would change to "Volts low=true, Volts high = false" - the logic of the Subscribing IED then understands this as requiring it to raise the tap position. Yes you COULD do it this way if the Station Computer has the capability to Publish GOOSE. However this is lazy engineering using a mechanism that is designed for super-fast protection response times and which loads up the GOOSE repeat message every second on the bandwidth requirement to solve a problem that only needs to be done with a response time of a few seconds or more anyway using just one ACSI command specifically designed for this purpose and which, as the Client role, the Station Computer would be required to support anyway. So is it possible that a gateway (the original question used the word server) publishes GOOSE answer is Yes some vendors apparently support that. How do you use it and is it essential compared to ACSI is a different question today and potentially different again tomorrow.

(8) How much are used SCADA tools from independent vendors?
Almost every relay protections manufacturer has it's own tools also for engineereing of substation automation system - MicroSCADA, Sicam PASS, PACiS, etc. But more or less these tools are optimized for use with relay protections from it's product line. I am interested how widely are used such tools from other vendors. Independent engineering companies like our's usually cannot afford themselves to be fixed to one of big manufacturers from many reasons. So probably third party tools can give them more freedom to choose equipment for different projects based on client requirements. Could you share your opinions on this point, as well as which tools you are using?
11 days ago

Close viewer Like

Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

6 comments

BrianUnfollow Follow Brian Brian Stickney Plamen: Interoperability is becoming a major issue which is driving the sales of thrid party SCADA software as well as thrid part OPC device drivers for interfacing different brand s of IEDs with different brands of SCADA software. ReLab has both a SCADA package and OPC Communications products that you can download and test, www.relabsoft.com.
10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

NirUnfollow Follow Nir Nir Cohen RAD recently developed unique solutions for SCADA and teleprotection combined with its wide range of telecommunication solutions. Please see the link below for further information:

http://www.rad.com/21/Teleprotection-over-Packet/22027/
10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

PlamenUnfollow Follow Plamen Plamen Natchev Thank you Brian and Nir, I will consider your proposals and contact directly.
10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JrgenUnfollow Follow Jrgen Jrgen Resch Of course the tools form the big vendors are used widely. However, standards such as IEC 61850 bring independent vendors into the game. Sometimes with nice advantages like reaction time or implementation of new features faster than the big ones. As utilities learn a lot about the possibilities of IEC 61850 when they start with new projects they require more than offered by the vendors. In this situation software suppliers like COPA-DATA (www.copadata.com/energy) are a good alternative.
9 days ago Unlike Like

Reply privately Flag as inappropriate

Flag as promotion

MiguelUnfollow Follow Miguel Miguel Bengla Fortunately thats not a problem for us. Since we at EFACEC integrate in our substation automation systems IEDs from other suppliers, like protection relays, our IEC 61850 software tool was developed with that in mind. We have supplied IEC 61850 automation systems with our equipment together with Siemens, ABB, SEL, GE, AREVA, and others IEDs. Thats one advantage of not being too big as the bigger ones: we can adapt and use in our automation systems our equipment together with the equipment that the customer most likes. And the substation automation system software tool is just one.
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

PlamenUnfollow Follow Plamen Plamen Natchev OK Miguel, see you at Rujitsa windfarm project then :-)

(9) We don't need a tool to configure everything, as we don't need a Office with all its applications (word, excel, etc) in a single tool. What we need is interoperability between the tools, as in Office.
1 month ago

Close viewer

Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Hao Tian likes this You, Hao Tian like this 19 comments

HaoUnfollow Follow Hao Hao Tian Thanks Jose. It sounds simple and obvious but it is so easy to get carried away in this 'fully integrated' world. We do need this kind of reminder from time to time. The other side of coin is, due to the transition between legacy to new, try to make everything inter-operable might require far more effort than develop some super package new. With a mind of 1 tool does all and develop multiple pieces of tools could be a good way
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney

Rodney Hughes IEC 61850 defines an engineering PROCESS. Processes are carried out using tools. Edition 2 of Part 6 section 5.3: To make the engineering tasks and responsibilities clear, tool roles are introduced for an IED configurator and a system configurator. A real tool can play both roles. Perhaps it is a little controversial to suggest that a tool that doesnt do both roles is not a real tool but the point is there are certain roles within the SCL process that must be fulfilled but they may be in the same or different software packages. In the same way that I can produce and print a 3 x 4 table in Word/Excel/Powerpoint, it is the extra capabilities that each of those tools brings and what Im going to do next that may make me choose one or the other. These totally different tools may well be packaged together as Office but they are different tools. Use the right tool for the right job. Based on certain information/file input: The role of the IED configurator tool is to give outputs of ICD, CID and IID. The role of the System Configurator tool is to give outputs are SSD, SCD and SED. This requires these files be imported and exported seamlessly hence tool interoperability and the curent work looking at how this is to be defined and tested for conformance. Some vendor tools are based on their own processes which are focused on selling their box in particular in the same way they had proprietary tools. In some cases they do not accept SSD/SCD file inputs whilst in other cases some dont quite understand the nuances of another vendors ICD file. In some cases the tools totally ignore the objective and benefit of having a complete top down SSD & SCD approach and can jump from ICD to CID directly. Nor is IEC 61850 is the complete configuration of an IED. There are is the configuration of the LCD display and depending on how many of each the assignments of physical I/O, the allocation of the front LEDs and push buttons. So until IEDs have identical physical and firmware construction, there is always a specific tool required for the proprietary configuration. Then, who is involved throughout the process as inhouse and outsourced engineering groups and of course their own engineering processes and tool investments, and indeed the editorial control of this at any point in time. One super tool with multi facets? Well how much of the engineering process does that encompass throughout the life cycle, what documentation do they need to produce for us humans and does everyones engineering process look the same? The engineering life cycle includes settings using simple paper records through to Excel or databases of all sorts and systems even linked to work order issue to field crews and the stages of draft-approved-pending-applied-replaced (CIGRE Working Group B5.31 has nearly finished its work on lifecycle management). Somewhere these settings are linked back to an engineering process with some calculations or a grading program. Many of these settings end up as part of the Logical Node attributes but IEC 61850 doesnt define the tool to do a relay grading study or

define the life assessment algorithm for the transformer based on the condition monitoring information provided from an IEC 61850 system. The CIGRE B5 meeting in Lausanne in September has a Preferential Subject 1 Which Tools for Which User with 19 papers being discussed. http://www.cigre-scb5-lausanne2011.org/index.html There is also a CIGRE Working Group B5.39 starting to grapple with the subject of Documentation requirements from design to operation to maintenance for Digital Substation Automation Systems Documentation comes from tools so this will be an interesting and complex investigation.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JosUnfollow Follow Jos Jos Gonzalo Hi All, I agree with most of Rodneys points. However, from my point of view, it could be considered that Office is a single tool which is composed of different blocks. In such a case, in IBERDROLA we use one single tool for configuring EVERYTHING (meaning everything susceptible to be configured) inside an IED. In order to achieve this, as Rodney says, some additional aspects should be included in the standard (LCD Display, LEDs, control logics, etc.), stating how to include these aspects in the data model and the services available for them. However, the standard does provide rules on how to extend the data model, so we have used those rules to model those aspects which are not included in the 61850 standard yet. From the utilities point of view, it is much better to only have one single tool instead of several tools (although they are compatible) in terms of managing different software packages and configuration files. We have contributed with one paper (paper number 113) to the CIGRE B5 meeting in Lausanne in September as Rodney comments, inside the Preferential Subject 1. In that paper we explain why the need of such a universal tool.

22 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist I would suggest that if the user really needs a single tool for the whole substation, what you mostly need is an agreement on an API that would let a system level tool launch IED-specific tools at the appropriate moment, and then let the IED-specific tool return control to the system tool when it's done adding adding proprietary information. The SCL files already exist to exchange information between the tools: SCD and IID. And the IED tool can fill in proprietary information in private sections. If you do it this way, you don't need to standardize everything, like LCD display, LEDs, control logic. Instead, all you need is an agreement about when one tool or the other takes over.
19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jos LusUnfollow Follow Jos Lus Jos Lus Pinto de S I completely agree with Grant Gilchrist.
19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JosUnfollow Follow Jos Jos Gonzalo Hi Grant & Jose Luis, You say that thanks to the different tools and the proprietary information each one of them is capable to handle there is no need for standardizing everything. But I see it the other way around: If you standardize everything, there is no need for proprietary parts in the configuration files, there is no need for several configuration files for the same IED and there is no need for several configurating tools....*One ring to rule them all*...
19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO I believe, each IED has it own internal communication bus... which is manage how the software/firmware part of IED communicate/map to the hardware part of IED... For sure, during configuration of an IED for one application, we must to assign each binary input/output or analog input/output required for the application.. I don't think vendor will open this... The analogy is like our handy... with Android... the open system one... Although is open... can we put Android OS of Samsung into HTC directly...?
19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO What we can have is to create such a system which each IED could communicate/operate on the same language same result same engineering process... but... to configure IED itself, then it requires the legacy tool....
19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes For my interest it is not a question of the number of tools but that the information being exchanged can be as interoperable between the tools and to the devices as much as possible. Jose's CIGRE paper is indeed quite interesting from a concept point of view although I have my concerns about whether this uses the full the benefit of all the SCL files it sounds like iSAS uses a library of CID files which are then presumably copied and individually modified for the next project so are the benefits of the SSD stage and the substation section in the SCL files totally lost. Whilst the paper well explains the benefit of having one file which describes all the standard IEC 61850 data model, communication aspects and attribute settings for the IED. It then describes the concept where extensions according to the Standards rules are used to include things like allocation of I/O, front leds, front push buttons, display configuration and the scheme logic in the XML files. But what is not clear from the paper is how iSAS deals with every manufacturers proprietary configuration requirements for these things eg distance relay A has 20 outputs whilst relay B

has 16 outputs, A has 8 LEDs whilst B has a programmable screen display Then of course is whether the device will accept an XML CID file as the downloadable file or how it builds a proprietary downloadable file that the proprietary devices will accept (although I know some utilitoes who have reverse engineered those files so that they can generate each proprietary format from a central settings database) can you give further explanation of how the scheme logic is described into universal XML extensions according the standard which all the relays would universally accept as the downloadable file? Indeed how much effort is required to create a new [Iberdrola proprietary?] extension for a new device such as a new relay, bay controller, MU, intelligent CB, tap changer or any of the plethora of condition monitoring devices . If woukld be good to see how this diversity and volume of proprietary configuration has been standardised. Im sure these and other questions will be discussed at CIGRE in Lausanne on Wed 14th September
19 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JosUnfollow Follow Jos Jos Gonzalo Hi Rodney, you have given a really good resume of the key points of the paper. As you have come out, the main file for the iSAS structure is the CID file, and we base all the others around it. For dealing with every manufacturers configuration requirements...lets put it the other way around: what do manufacturers need to adapt / modify in their IEDs/tools so the iSAS can deal with them? the answer to this question is the IBERDROLAs 61850 specification document or, a very similar one, the E3 Group on IEC 61850 specification document. Using your example, the specifications should stablish a minimum amount of outputs, LEDs, etc.(capabilities) for the 61850 IEDs in a way that the most demanding situations are covered. when asking about the scheme logic, I am assuming you refer to how to model logics using extensions of the model which can be deal with XML files. For this explanation, I recommend you the reading of Anex A of the E3 Group in IEC 61850 specification document. The amount of effort for a new IED compilant with the specifications depends on how close to

the specifications the IED is before starting. If the new IED to be developed has been designed with enough capabilities, (comparing with the E3 Group specifications), services, flexibility, etc., it should not take too much extra effort comparing with other 61850 IEDs.
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

ChristophUnfollow Follow Christoph Christoph Brunner Jos - I have just a small remark for clarification. I am not sure if the file that you use as the main file for the structure is really a CID file. Remember - a CID file is what you can download i the IED to configure it. It contains all the information the IED needs to operate correctly. In terms of SCL file sections that means the CID file includes the complete IED section of the IED it is intended to configure as well as at least parts of IED sections from all the IEDs where the IED to be configured receives GOOSE messages. Such a file can only be produced if you already have created all the instances of IEDs that you need for your substation automation system and if you have configured all the information exchange required through GOOSE messaging.
5 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JosUnfollow Follow Jos Jos Gonzalo Hi Christoph. I think the SCL file we use is a truly CID file. Concering the incoming information from other IEDs for GOOSE messages subscription, you might require those IED sections in your SCL file (as you indicate), or you might model the subscriptions in

different instances of dedicated LNs. Both solutions are contemplated in the E3 Group on IEC 61850 Specifications document (Annex D). http://sites.google.com/site/e3groupiec61850/documents-2
3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

ChristophUnfollow Follow Christoph Christoph Brunner Hi Jos, I agree that you can model the subscriptions in the instances of dedicated LNs. But according to my knowledge, you can not - in a standardized way - model in the input section where in the GOOSE mesage the specific data you want to subscribe can be found nor what the MAC address and GOSSE ID of that GOOSE message is. And it looks like the receiving IED should know this.
3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jos LusUnfollow Follow Jos Lus Jos Lus Pinto de S Well, my friends, I wonder if some points and comments here are really realistic. First, I need to clarify that the work repported in my paper is not just a concept, it has been fully tested in laboratory and is going to be applied in the field. Second, I dont care about what piece of a GOOSE message means this or that. The beauty of the IEC 61850 SCL is just in that I don't need to care about that. It is just as coding in C or Pascal

versus coding in Assembler. Third, I don't want IEC 61950 specificying the way I code automation logic. I already have a IEC standard for that, the 61131-3, not to mention 61499. And that's really important, because I don't even code in any IEC 61131-3 language; instead, I design my logic functions through Petri Nets, and IEC 61131-3 is important for me because besides being a standard, there are formal and available tools to translate a Petri Net in a 61131-3 program, and this is just because 61131-3 is a standard! It is already good that there are tools to deal with Petri Nets, IEC 61131-3 programs, and IEDs to run them. I don't need a unique tool to do that AND to integrate those programs (running into IEDs) in the Substation. I only need that those black boxes running those programs can be connected to some LN in some IEDs - and that is everything I need from a SCL 61850 tool! Encapsulation, objects, modules, abstraction, those are key concepts in software development. A unique tool does'nt help that.
3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Well one tool for supporting IEDs / SCADA / BCUs from one manufacturues exist / or could be possibe. But what about, when integrating diffent make products within one implementation. This mix is very common and i think one tool philosophy will not be applicable in such cases.
3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DanUnfollow Follow Dan Dan Brancaccio I don't completely agree with the MS office analogy. The office suite can interoperate to a degree but it is not the same paradigm we are discussing here. I think there is a definite need for a single application that could be used to configure every device in a substation. Isn't this what the 61850 SCL was intended for? Think of all these devices as containing their own small databases with proprietary schema. It is these databases that contain the device configuration. What is needed is an application that can use SCL to retrieve the data, display it in a normalized fashion, allow modification, and then save it back to the device using SCL
2 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jos LusUnfollow Follow Jos Lus Jos Lus Pinto de S "Think of all these devices as containing their own small databases with proprietary schema. It is these databases that contain the device configuration. What is needed is an application that can use SCL to retrieve the data, display it in a normalized fashion, allow modification, and then save it back to the device using SCL" - well, it would be nice, but this is not a SCL 61850 problem. It is a much complex problem. Consider oscilographic data, for example: to be able to retrieve it no matter the IED, you need to standardize the format of that data. That was done by COMTRADE. Consider now the Sequence-Of-Events (SOE) data. The same. It is now done by COMFEDE. Both were defined by Protective relaying folks (in the IEEE), which of course ease the task to handle the data retrived by SCL 61850, but has nothing to do with 61850. IEC 61850 is for systems and communication, for deviced seen as communitating black boxes, or objects, to be precise.
2 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Dan says, " I think there is a definite need for a single application that could be used to configure every device in a substation. Isn't this what the 61850 SCL was intended for? " The answer is no. SCL was never designed to have a single application configure every device in the substation. The creators of the spec understood that there will always be proprietary information that needs to be configured in each device. Devices will always have value-added features that differentiate them from their competitors. Without innovation, there is no pressure to keep prices on basic features low. It is important to note there is a big difference between devices that are interoperable and devices that are *interchangeable*. The IEC 61850 specification never intended to make devices interchangeable, just interoperable in the data that they exchange. Similarly, SCL is not intended to permit a single tool to configure *every* parameter in a substation, just those parameters that control communications via IEC 61850. For the other parameters, SCL provides the ability to include "private" sections so the configuration of these parameters can go in the same file. There will always be a need for vendor-specific tools to add and modify this proprietary information. But as I mentioned previously, there is no reason we couldn't standardize the process of launching and returning data from these vendor-specific tools. The result would be several tools, grouped together so they looked like a single tool. You're correct, MS Office is the wrong analogy. A better one would be PDF, or maybe Open Office or Rich Text Format. Any standard that lets several tools from different vendors view and modify the same data.
2 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jos LusUnfollow Follow Jos Lus

Jos Lus Pinto de S You made it clear and right, Grant.I had mentioned MS Office probably not as the best paradigm, but just because I still remember the times when we did'nt have it. There were sifferent tools from different vendors, spreadsheets, text processors, data bases, and we could not interoperate them. MS Office has provided that interoperation and with that it killed the competition, but still offering different tools for text processing (Word), spreadsheets (Excel), and so on. IEC 61850 intends to provide interoperation among different tools from different vendors, as before MS Office, but of course we can't paste a table from Excel into a Word text, I mean we can't paste a configuration set from a Siemens IED into a GE IED. However, with IEC 61850 we can "hyperlink" a given value of an Excel table (Siemenss IED) into a Word text (GEs IED).

When will IEC 61850 be "mature"?


I hear quite a few people make statements like: we will wait a few more years until IEC 61850 is mature It is already 7 years since it was released, and some 18 years since its development started. There are several thousand substations world-wide with IEC 61850 deployment - getting more and more complex and even passing protection trip signals such as Circuit Breaker Fail and bus bar zone trips. There were 92 Logical Nodes in Edition 1; there are now over 230 to choose from in Edition 2 and 61400-24 As a technology that is designed to grow with our increasing needs (future proof) as shown in more features in Edition 2 and the discussions on other features that could well be the start of Edition 3 in a few years time, it will always be "maturing". So what do people perceive is not mature? - Is it the capability of the standard? - Is it the availability of tools? - Is it the availability of IEDs? - Is it staff training and experience? - Is it just comfort in being familiar with wire based engineering? Given the huge cost and time savings IEC 61850 provides, Id be interested in your feedback on what more "maturity" is needed.
2 days ago

Close viewer Like Comment Follow

Flag
o o o

Flag as Promotion Flag as Job Flag as Inappropriate Reply Privately

More
o

Zhibo Wang, Mayank Sharma and 2 others like this You, Zhibo Wang, Mayank Sharma and 2 others like this 5 comments

RalphUnfollow Follow Ralph Ralph Mackiewicz Maybe it is human nature to perceive that anything you do not have experience with and where the people you interact with don't have that experience either that it is immature. I would just observe that none of the questions you ask relate to maturity.
22 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BrianUnfollow Follow Brian Brian Stickney What is the definition of mature? Without that the discussion is open ended without the ability to reach a conclusion.
21 hours ago Unlike Like

Reply privately Flag as inappropriate

Flag as promotion

GrgoryUnfollow Follow Grgory Grgory Huon Hi Rod, I think we have to go the basics of IEC61850 to handle you question : what is the essence of IEC61850? I think it is mainly the capability of replacing copper wiring by optical fiber and permitting what we call "interoperability", like copper wiring permits it in a great way (in a multivendor environment). The problem of IEC61850 is that we are today only at the point to get what I call "instantaneous" interoperability. And it is not enough. What about interoperability over life cycle of assets? According to me, it is not a technical problem, it is a strategical market issue. So far the suppliers don't play the game as it was initially intended to be, so far you will not get buy-in of the users, and certainly from the TSO's. This is to be considered when you are speaking about "huge costs savings" ...
19 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Alvaro TadeuUnfollow Follow Alvaro Tadeu Alvaro Tadeu Pereira Its a very interesting question. We have adopted IEC 61850 in practical applications including interlocking and protection schemes since 2007 and I am myself an ethusiast. However, we have faced so many problems, like: - still great difficulties in interoperability between vendors IEDs and tools, despite some kind of old demonstrations already shown around the world; - pitfalls with Goose messages remapping, when handling the tools; - risks in downloading configuration to the IEDs, considering the configuration revision; - different interpretation and use of optional funcionalities by the vendors; - a proliferation of GGIO messages(limited MICs, LNs etc), with loss of semantics;

- complexity and lack of training in the standard. A maturity process is natural for any new technology, IEC 61850 has a great potential. Feedback from integrators, clients and vendors could be more carefully considered in vendors solutions and new Editions of the standard, but more complexity should be avoided in the standard. Otherwise, there may be that uncomfortable feeling that it is not mature enough, specially now when the market is driving to process bus, with more critical applications.
5 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz I agree with you completely about the GGIO issue. GGIO was used in some of the early interoperability demos. Because the demos were not operating on live power systems, the semantics used seemed secondary to illustrating interoperability. Unfortunately, that practice seems to have proliferated in actual use even where there are existing LN/CDC semantics to represent much of the data being exchanged. I think it is taking some time for both suppliers and practitioners to understand that numbering data is not as productive as naming it. One of the aspects of IEC 61850 that has always impressed me was the level of cooperation in the supplier community to test and improve interoperability in public. That has not generally been the case in the past. I think IEC 61850 has helped increase the availability of public interoperability testing. While some of the old demos were indeed primitive there is progress in this area also. Recently there was a very large interoperability test that was conducted under the auspices of UCAIug and sponsored by EDF. This happened in March 2011 in Paris. A presentation summarizing the testing and a report with the details has just been posted at UCAIug's website: http://www.ucaiug.org/IOP_Registration/IOP%20Reports/Forms/AllItems.aspx As you will see, interoperability testing is getting a lot more detailed and formalized. It is no longer a trade show demo. It think it is a sign of maturity that this kind of testing is being done among all of these different developers and that the results are available. You will need to register on the site to access the presentation and be a UCAIug member to access the detailed report. There is always room for improvement as you will see. This testing will have a positive impact on the standard in the future.

What factors which make people worry in applying GGIO's for Inter-tripping and Interlocking ?
In some projects, among my internal members, frequently I heard following statements: "Using GOOSE in protection is not accepted!" "Never use GOOSE in protection scheme!" While I found in the customers side, whether it is end-users or the consultants, I never heard this statements. They are very curious with this GOOSE and even some of them already put in their technical specifications, "preferably to use GOOSE". Now, here I would like to gather some comments from this group, what makes the objection to use GOOSE in inter-tripping and/or interlocking. I really persuade any valuable comments. Many thanks in advance for the share.
23 hours ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

1 comment

AlexandreUnfollow Follow Alexandre Alexandre Piatniczka On my point of view, all the new technology will cause rejection by some people and euphoria on some other. The balance comes with experience. We have already delivered hundreds of stations using GOOSE for inter tripping, interlocking and

some other purposes. As you said, some customers still do not use GOOSE and say they will not use at all, but when numerical relays were introduced in the market, several people doubted it would work. the LinkedIn app for iPhone and Android.

YuchenUnfollow Follow Yuchen

Challenge of testing and maintenance of IEC 61850 systems


Lack of necessary methodologies, approaches, or tools for testing and maintenance of IEC 61850 systems remains one of the outstanding issues utilities are facing today. 61850 obsolete the existing utility testing/maintenance practices, but havent come up with a sound solution yet. For instance, (1) how to safely isolate an IED from network for test/maintenance? Testing switches won't help in this case. Unplug the Ethernet cable are not acceptable. (2) How to put IEDs in test mode and what test mode suppose to mean in the standard? (3) Is there any vendor implemented test bit in the GOOSE message yet? (4) How IEDs suppose to response to a GOOSE message with test bit == 1? (5) Any new features from standard edition 2 can help IED testing? In North America, utility P&C staff are required to test/maintain relays/IEDs on a regular basis for compliance with regulation standards. Therefore, testing functionalities in IEC 61850 should not be an optional feature, it is a must. Lack of vendor implementation agreement could be another cause for the difficulty. Any experience or thoughts on this topic?
8 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Abu Zahid M.Sc. M.Eng. P.Eng., Yuchen Lu like this You, Abu Zahid M.Sc. M.Eng. P.Eng., Yuchen Lu like this

10 comments

AlexandreUnfollow Follow Alexandre Alexandre Piatniczka Hello Yuchen, interesting topic! As important as project development and comissioning tests we have the need of maintain the system up and running. An interesting maintenance tool is ITT Explorer, (refer to the link): http://www.abb.com/product/db0003db004281/172c84eb48d9af3dc12575c900274d72.aspx More than tools i belive it still need to develop a maintenance procedure and train the staff intensivelly.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO Well, somehow, when test-switch is plugged-in, internally in the IED will automatically set the quality of the GOOSE to 0. By set the quality value of each GOOSE data, the receiver will not process the received signal. Instead of that, by plugging-in the test-plug also will automatically block the trip-contact (binary output) from operation. This is the practical way with what I've been setup with my IED.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

YuchenUnfollow Follow Yuchen Yuchen Lu Thanks for the comments. I think the "test switch" I referred to, and most P&C folks understood, is the mechanical device which can physically and electrically isolate CT/PT and I/O connections from a relay for injection testing. Sorry, I am not sure what "test-switch" Wiku referred to. Additionally, does it follow the standard to use "quality" for GOOSE testing? If not, how can we achieve interoperability? Worldwide there are many IEC 61850 substations are in service now, if GOOSE has been used to replace hard wires for P&C applications, how do they handle the testing/maintenance? Or haven't realized how challenge this could be? Any comments are appreciated.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO Yes. I refer to that mechanical test-switch, which you must wire to a binary-input to have in-test status when the test-switch inserted. As far as I know, to make GOOSE works properly, I always put the PTRC1.Op.stVal and its PTRC.Op.q in the GOOSE dataset. the "q" value is for the GOOSE data validation. When "quality" is BAD, the "stVal" will be ignored. For testing and maintenance, several relay testing tool is capable to receive GOOSE. Such Omicron CMC or Doble F6150. So you do not need to wire the trip output to the relay

tester. Even with ed. 2, you can inject "Sampled Value" from the relay tester to the relay being tested. So, there will be no wiring required. But with current status, CT and VT secondary injection still done by hard-wiring, that's why we still need the mechanical switch. Surely we can setup a GOOSE signal to broadcast to the network that a relay is under-test.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO It might be an interesting article related to this topic: http://www.pacw.org/issue/winter_2008_issue/protection_goose/high_performance_iec_61850_ goose_and_protection_relay_testing.html
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

YuchenUnfollow Follow Yuchen Yuchen Lu Thanks Wiku! In your testing scheme, how to handle the situation that the test set (Omicron/Doble or others) need to inject goose messages to simulate some signals changes? In this case, the relay (in test) may receive conflict information if it's not being isolated from

network. for a standalone relay, I think the situation will be much simpler. Again, that's back to the first question: how do we isolate relays for testing? Thanks also for the pac world link.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO For sure, since the engineering stage of the system, you must prepare GOOSE receiver function block on each relay for test. We can't just plug in the relay tester, and directly injecting the GOOSE to the IED via network. The steps which I have been done is as follow: Basically, each IED must subscribe to the GOOSE dataset of the Omicron or Doble. One dataset in Omicron, for each IED, means, if you 16 protection devices in one network, then you must have 16 different dataset (contains same DO - DataObject dan DA - DataAttribute for the test). This dataset will use by Omicron or Doble to initiate in-test status in the IED. By having this subscribing scheme, then we can make sure that which IED will only affected on test. This subscribing scheme is specified in the IEC 61850. By having this in-test status, internally in the IED, you must configure in such way to block any trip contact output of the IED under test. In the other hand, omicron or doble also subscribe to the goose dataset in each IED. Dataset from IED to Omicron/Doble will only the Trip.Operate.status to stop the current or voltage injection of Omicron. Since the binary-output is blocked, and data-quality is bad, then the trip output and trip signal will isolated from the network. That is my practical way to isolating an IED from the network and from the trip circuit during the test. To isolating the CT and VT connection, I still use the conventional wiring, that will be disconnected every time I plug in the test-switch. I don't have any installation base with Sampled Value (61850-9-2) yet. Only had done this in lab.

To setup the dataset, you must do it in SCD configurator since beginning the installation. To setup the IED behaviour during test, you must configure the internal logic the IED itself use the IED configurator since beginning the installation. If you modify in the middle of running system, then there will be tremendous work to load new correlation between relay tester and the relay within a network. Sure it is not possible to be done. Sure, there many other practical ways to do this kind of 'software' relay testing instead of 'hardware' relay testing, as per described in the PACW article. I hope there will be some other comments submitted.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO Hereby I copy pasting from the Application Manual from a one product: ============================================================== Test mode functionality TESTMODE The protection and control IEDs have many included functions. To make the testing procedure easier, the IEDs include the feature which allows to individually block a single, several or all functions. There are two ways of entering the test mode: By configuration, activating an input signal of the function block TESTMODE By setting the IED in test mode in the local HMI While the IED is in test mode, all functions are blocked. Any function can be unblocked individually regarding functionality and event signalling. It enables the user to follow the operation of one or several related functions to check functionality and to check parts of the configuration etc. ==============================================================

That is the concept. The details should be done and suited with the configurator tool which suitable of a system to meet the concept mentioned above.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DonaldUnfollow Follow Donald Donald McHugh Wiku, how to handle a situation where a single IED is sending signals to many IEDs? If testing a transmission line relay where you want to send a trip to the breaker under test, and simulate stuck breaker. How do you instruct multiple IEDs to ignore the breaker failure trip from the test relay, but act on a breaker failure trip received from another? Also, in the case where a GOOSE initiates logic internal to an IED, and you want the RCVd GOOSE to initiate the logic, but not output. Isn't a "test GOOSE" necessary?
21 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

WikuUnfollow Follow Wiku Wiku JULIANTONO GOOSE "q" flag is required for the subscriber to verify the signals is TRUE or FALSE. For instance, if the stVal is TRUE, but q is BAD. This is the use of being transmitting the "q" flag and "stVal" at the same time. This is the illustration:

If A under test. In normal condition A sends GOOSE to subscriber B, C and D. At the same time: B also subscribe GOOSE from C and D instead of A C also subscribe GOOSE from B and D instead of A D also subscribe GOOSE from B and C instead of A Each subscribed GOOSE will received by different channel, either in one Goose Receiver Function Block or different Goose Receiver Function Block. Since A under test, then "q" flag from A wil be in BAD, then B, C and D will ignore trip signal from A, but will acknowledge trip signal from other than A. In your example, Breaker Failure scheme, then the GOOSE trip signal will be taken directly from RBRF1.Op.General.stVal. If we use test status to block the Function Block RBRF1, then the Function RBRF1 itself will not work in any output, either contact output or GOOSE, because it is blocked from operation.

ArslanUnfollow Follow Arslan

require suggestion: anyone suggest the minimal information for configuration of any device with the server communicating over IEC-61850...
1 month ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

5 comments

KaminUnfollow Follow Kamin Kamin Dave IP address, VLAN Id, VLAN Priority, GOOSE Appl ID etc.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Won-GyUnfollow Follow Won-Gy Won-Gy Lee I understand you want to configure a IEC61850 report server. (In case of GOOSE, we don't call it a server, but call them either as a sender or receiver.) To configure a IEC61850 report, you can define a data set with defined parameters. I see many people doing that using a dedicated IEC61850 configurator tools such as SEL Architect, IED Configurator (ALSTOM), CCT (ABB), DIGSI (SIEMENS).... taking mostly default data set and parameters. You can either generate a .CID file or .SCD files and either simply download the file directly to the relay or import the file into the relay setting file and download it. I don't recommend configuring them manually because it takes hugh time with more mistakes.
20 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Won-GyUnfollow Follow Won-Gy Won-Gy Lee I forgot to mention that the same .CID file or .CID file needs be imported into your SAS server (which is IEC61850 client) to configure corresponding SCADA database points for further processing.
20 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Won-GyUnfollow Follow Won-Gy Won-Gy Lee Informations that are required for the IEC61850 client machine are : IP address, Device ID, Report Control Blocks (Buffered or Unbuffered).
20 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GurpsUnfollow Follow Gurps Gurps Sohal I am currently looking to speak with immediately available RTu engineers and Transducer engineers. If you are available at short notice and keen on short term contracts then please send me your up to date CV to gurps.sohal@randstadcpe.com

ShyamalaUnfollow Follow Shyamala

How may IEC61850 compliant substations have been commissioned so far in India, with a breakup of PowerGrid s/s and others.
25 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

4 comments

KaminUnfollow Follow Kamin Kamin Dave Dear sIR/Madam, There are more than 30 nos. of IEC61850 Compliant Power Grid S/S in India. Some of the Power Grid S/S ARE; Bina 400KV/765KV, Gwaliar 400KV/765KV, Seoni 400KV/765KV, Damoh 400KV/765KV, Bhatapara 400KV, Patna 400KV, Muzzafarpur 400KV, Warangal 400KV,

Wardha 400KV/765KV, Kalavirappatu (Near to Chennai) 400KV, Ludhiana 400KV etc....... There are other S/S at Electricity boards also like; GETCO 400KV at Kosamba RRVPNL 400KV at Ganganagar TNEB 220KV at Chennai MSETCL 220KV at Aurangabad KPTCL 220KV Hubali There are S/S of other utilties also like; TATA POWER, Mumbai NTPC has also used IEC61850 prptocol for interlocks for new coming generating stations or units (Expansion).
24 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SaifUnfollow Follow Saif Saif Ahmed ABHIJEET POWER PLANT NAGPUR


24 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FirdousUnfollow Follow Firdous Firdous Ansari Thanks for update Mr.Kamin , Can you tell that How fast the system is in contigengy Load shedding i.e how much time it takes detecting an input ( fault, UV, UF, df/dt, dv/dt etc) and energising an output for trip of breakaer. min ...... ms , max ...............ms.
21 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KaminUnfollow Follow Kamin Kamin Dave Right now, IEC61850 protocol has not been implemented for trippings as there are certain limitations of HV equipment/s. Process bus implementation will be initiated in 2012. It is mainly implemented for interlocks and control circuits. Timings are varying and depends on IEDs design. But, obvisiously it is faster than the signal transmistting through hard wiring. As per standards; signal has to be transmist with in 10ms for performance class1 and 4ms for performance class2, but this is point to point transmission so, we need to consider the time delay of ethernet switch/es also.

How may IEC61850 compliant substations have been commissioned so far in India, with a breakup of PowerGrid s/s and others.
1 month ago

Close viewer Like Comment Follow Flag

o o o

Flag as Promotion Flag as Job Flag as Inappropriate Reply Privately

More
o

4 comments

KaminUnfollow Follow Kamin Kamin Dave Dear sIR/Madam, There are more than 30 nos. of IEC61850 Compliant Power Grid S/S in India. Some of the Power Grid S/S ARE; Bina 400KV/765KV, Gwaliar 400KV/765KV, Seoni 400KV/765KV, Damoh 400KV/765KV, Bhatapara 400KV, Patna 400KV, Muzzafarpur 400KV, Warangal 400KV, Wardha 400KV/765KV, Kalavirappatu (Near to Chennai) 400KV, Ludhiana 400KV etc....... There are other S/S at Electricity boards also like; GETCO 400KV at Kosamba RRVPNL 400KV at Ganganagar TNEB 220KV at Chennai MSETCL 220KV at Aurangabad KPTCL 220KV Hubali There are S/S of other utilties also like; TATA POWER, Mumbai NTPC has also used IEC61850 prptocol for interlocks for new coming generating stations or units (Expansion).

1 month ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

SaifUnfollow Follow Saif Saif Ahmed ABHIJEET POWER PLANT NAGPUR


1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FirdousUnfollow Follow Firdous Firdous Ansari Thanks for update Mr.Kamin , Can you tell that How fast the system is in contigengy Load shedding i.e how much time it takes detecting an input ( fault, UV, UF, df/dt, dv/dt etc) and energising an output for trip of breakaer. min ...... ms , max ...............ms.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KaminUnfollow Follow Kamin Kamin Dave Right now, IEC61850 protocol has not been implemented for trippings as there are certain limitations of HV equipment/s. Process bus implementation will be initiated in 2012. It is mainly implemented for interlocks and control circuits. Timings are varying and depends on IEDs design. But, obvisiously it is faster than the signal transmistting through hard wiring. As per standards; signal has to be transmist with in 10ms for performance class1 and 4ms for performance class2, but this is point to point transmission so, we need to consider the time delay of ethernet switch/es also.

What is difference between Settings and configuration


I'm new to this topic of IEC61850. could anyone help me to understand what is the basic difference between the Settings(SG) and configuration (CF) of the logical node.
8 months ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

7 comments

WikuUnfollow Follow Wiku

Wiku JULIANTONO from IEC 61850-7-2, CF and SG are Functional Constraints.. CF semantically described as Configuration. In the term of Service Allowed, CF is described DataAttribute shall represent a configuration information whose value may be written and read. Values written may become effective immediately or deferred by reasons outside the scope of this standard. The Initial value of the DataAttribute shall be as configured; value shall be non-volatile. SG semantically described as Setting group. In the term of Service Allowed, SG is described as Logical devices that implement the SGCB class maintain multiple grouped values of all instances of DataAttributes with functional constraint SG. Each group contains one value for each DataAttribute with functional constraint SG which shall be the current active value (for details see 13). Values the of DataAttributes with FC=SG shall not be writeable. The Initial value of the DataAttribute shall be as configured; value shall be non-volatile.
8 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SumanUnfollow Follow Suman Suman Mummaneni Hey man still working on PLC move on :)
7 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SumitUnfollow Follow Sumit

Sumit Kango Thank you Wiku for the information you provided . Now it's clear to me before it was little confusing :) . CF and SG are Functional Constraints for the DataAttributes of DataObjects. and based on these Constraints the behavior of DataAttribute are defined .
7 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Hi Sumit, That's right. Functional contstraints are a different way of grouping the data attributes so you can understand what they're used for. The FC actually appears in the name of the data attribute when it is transmitted in MMS. Here's another way to look at it. Data attributes that are marked as CF or SG can be set by the client, set through substation configuration language, or set through some proprietary means. Data attributes that are marked as SG, however, are special because they belong to a setting group. Once a setting group has been initialized, the client can switch all the settings in that group back and forth from one set of values to another by writing to a single attribute. This is particularly useful for relays, that may need changing of all settings from one season to the next or from "storm" to "non-storm" settings. CF data attributes do not have this capability and must be changed individually.
7 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

ChristophUnfollow Follow Christoph Christoph Brunner Maybe we should not compare SG with CF, but SP with CF. SP may be the same atributes like SG, but not belonging to a group. There are a couple of more differences than just the fact it belongs to a group. SP attributes are the "main operational atributes" of a data object. I.e., SPs appear for data objects that are as such settings for an application function. CF attributes are "auxilliary attributes" that appear together e.g. with a data object that is a measurand or even with a data object that is a seting parameter. CF attributes therefore are less a setting for the application function; they are a configuration of some characteristics of that data object they belong to. Lets take a simple example: In Edition 2 of part 7-4, a data object for the band center voltage of a automatic tap changer controller is defined (Do BndCtr). That data object is of the common data class ASG - Analog setting. The ASG CDC has a data attribute setMag with FC (functional constraint) SP or SG/SE. Assuming we are not using setting groups, then the data attribute setMag with FC SP is the value where we set the band center voltage. However, that same CDC ASG has as well e.g. a data attribute minVal with FC CF. This attributes determines the minimum allowed value for the setting of the band center voltage. So while the attribute with SP influences the application function, the atribute with CF only influences the behaviour of the data object as such. A difference is as well, how changes to these attribute values are indicated. For a change of a setting (FC=SP), this is indicated with "paramRev"; a change of a configuration is indicated with "valRev" - these are atributes of the logical node name plate and are explained in Annex C of part 7-3.
7 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Raphael PhilipeUnfollow Follow Raphael Philipe

Raphael Philipe Mendes da Silva Hi, I'm interested in something related to this subject, so I decided not to open a new post. As Grant said, the FC actually appears in the name of the data attribute when it is transmitted in MMS and that Data Attributes marked as CF or SG can be set by the client, set through substation configuration language or a proprietary method. In SCL a data attribute can have multiple values(Figure 17 of 61850-6 ed1.0), possible with the FC=SG. Each value can be differentiated one from another by the property sGroup. My question is, how these values belonging to different Setting Groups are mapped onto MMS since each data attribute is mapped into a MMS named variable? For example: the ldevice1/PTOC1.tmACrv.setParA is mapped to ldevice1/PTOC1$SG$tmACrv$setParA but each setParA can have multiple values. These multiple values are accessible by an client or the client can just access the active group values?
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

ChristophUnfollow Follow Christoph Christoph Brunner The multiple values are available together with setting groups. Setting groups are made available with setting group control blocks and the FC=SE. So when you have setting groups, the setting group control block determines - which setting group is currently active - which setting group can currently be edited The values from the active setting group you get through the FC=SG (you only can read them). The values from the setting group that you can edit, you access through the FC=SE on the same variable name.

Is there any specific difference between Client/Server and Master/Slave Architecture while we apply them in different scenarios?
I am looking on it from industry approach like application of these architectures in substation automation. Can we say for Modbus and DNP/61850 there is no difference? Thanks all in advane!
1 month ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Tom R. Janca, Dustin Tessier and 1 other like this You, Tom R. Janca, Dustin Tessier and 1 other like this 27 comments Jump to most recent comments

AjayUnfollow Follow Ajay Ajay Biswas Speed of communication seems to be the basic issue, with increase in I/Os this becomes very relevant Moreover most of the IEDs use DNP/IEC, modbus is mainly used for process industry Time stamping is one more issue with modbus
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GeoffUnfollow Follow Geoff Geoff Garber We use a combination of both Client/Server (TCP over Ethernet) and Master/Slave (Serial over RS-232 or Fiber) in the design of our substation and plant data and control systems. There are several inherent differences between the two that should be considered in substation automation. Both Modbus and DNP3.0 can have compatibility issues when using devices from different vendors. Both of these protocols were originally designed for serial communications. They more often exhibit these compatibility issues when using the TCP versions. (IEC 61850 does not have a serial counterpart but still can have major issues when trying to integrate devices from diferent manufacturers.) There are NERC CIP compliance issues to be considered when putting any TCP device on a network. What other routable protocols (I.e. TCP) does the IED respond to? Can settings be changed or controls issued? While these issues can be mitigated through better security devices and procedures, the job is much more simply designed when using serial communications. Can these devices be accessed from outside the 6-wall substation perimeter? Our firewalls usually have one or more rules per IP to prevent any direct access to IEDs. If this access is required (i.e. relay event reports, or meter trend or PQ logs), we have a substation server access the devices and provide the isolation needed for outside access. Is high-speed protection or other very fast messaging required over the same network? IEC 61850 GOOSE messages can travel over the same TCP link as lower priority SCADA and other automation. Serial communications requires a separate link for this type of high-priority messaging (i.e. SEL mirrored bit, etc.) Last but not least is system cost. If many IED's (more than 32) need to be polled, using Ethernet may seem to offer a cost savings. The cost of substation-hardened switches, routers, and other network devices can easily offset any apparent savings. If some of the IED's are distant or require GPR protection, fiber optic interfaces for TCP can quickly increase the cost.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JimUnfollow Follow Jim Jim Christensen In general a Server can serve multiple Clients, while a Slave can only serve one Master. Again in general, if a field device is acting as a Server, this should only be used for accessing but not modifying data in the Server, since there could be unpredictable results if the data is modified in an unsynchronized way by multiple Clients. If it is desired to modify data in the field device, e.g., to change control set points, this should be done with a Master/Slave architecture.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

srishankarUnfollow Follow srishankar srishankar k I have already discussed the same on control.com and here is the link http://www.control.com/thread/1295434153
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jasjeet SinghUnfollow Follow Jasjeet Singh

Jasjeet Singh Hanjrah Thanks Ajay, Geoff and Jim. Please correct me for this analogy: Master= Client and Slave=Server. Jim: I got this difference from many sources that slave can serve one master only but help me to demystify the fact when 2 or more relays/IED's(Master) communicate to Slave(RTU) then how this is taken care of. Also in 2 way communications, say when RTU(Slave) give command to CB(Master) to open or close based on algorithms, does this analogy change? i.e now RTU acts as master and CB as slave? Appreciate your response guys!
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jasjeet SinghUnfollow Follow Jasjeet Singh Jasjeet Singh Hanjrah Thanks Srishankar for the link. But i am yet to understand if IEC 61850 is based on Client Server or Master Slave architecture based? If there is any help on that, please extend
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

ChristophUnfollow Follow Christoph Christoph Brunner to Jasjeet: I think in your comment above you mix up slave and master. The IED would be the slave - the

RTU would be the master. And the RTU would still be the master that sends the command to open or close to the slave (CB in your example). Doing the same with IEC 61850 - The IED would be the server, the RTU the client. to Jim: You state: "If it is desired to modify data in the field device, e.g., to change control set points, this should be done with a Master/Slave architecture." That would mean, with IEC 61850 it is not possible to change control setpoints, which is of course not true. What needs to be considered however, are access restrictions. A client / Server architecture may limit the visibility of certain data (e.g. control setpoints) to certain clients.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

IlangoUnfollow Follow Ilango Ilango Ganesan To Jasjeet: To certain extend the analogy "Master= Client and Slave=Server" is correct, but slightly differs. In a Master-Slave architecture, communication transaction is always initiated on sending command by the Master device (say RTU), and slave device (say Relay) in-turns responds. Slave is not supposed to start communication in general. Rarely, you are likely to have multi-Master where there is a need for redundat network / data collection mechanism. In a Client-Serve architecture, although Client initiates the communication by requesting the server to get data many a times, Server also at times / periodically sends broadcast / Unicost messages. Most importanatly, peer-to-peer communication (i.e. Server-to-Server & ClientClient) is possible in Client-Server Architecture. Sharing of a file folder in your PC to the PC of your collegue over the office LAN is a classic example of peer-to-peer communication. IEC61850 is based on Client-Serve architecture. Here, IEDs (say Relays) acts as a Server and RTU or Station Operator Console acts as a Client. In reality, there can be multiple servers and clients on the same networ, i.e. substation LAN. The peer-to-peer communication possibility helps here to make use of GOOSE messages for interlock control apllication among the server (i.e. relays or BCUs), in addition to the control command to CB.

1 month ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

Jasjeet SinghUnfollow Follow Jasjeet Singh Jasjeet Singh Hanjrah To Christoph: Thanks for your kind response. However i understand the one who initiates the communication/can iniitate is master (relay can initiate that CB is trip to RTU) and hence RTU will be slave. I am not sure but just trying to be confirm on same.. Thanks Illango: But i am not yet clear if RTU acts as Master or Slave? I saw the link given by srishankar, and it is mentioned RTU acts as (slave or client) Also, IEC 61850 is Client Server architetcure, is it because of GOOSE messages? or because of peer-to-peer is possible in this architecture? Does Master/Slave not support peer-to-peer communication? Kind Regards Jasjeet
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

IlangoUnfollow Follow Ilango Ilango Ganesan In the overall system, RTU acts as an intermediate device. For a central station (or) remote control centre (say central control in LDC), the RTU in a substation acts as a slave. The same RTU when it collects data from (or) command to the IEDs (say relays, tap chaner and so on), it act as a master. For example, the RTU would act as IEC60870-5-104 slave to the

remote control centre and the same RTU would act as IEC60870-5-103 master to collect data from the relays in the substation. In a nut shell, a RTU can have many Master & slave communication protocols running inside it. These various communication protocols are decided based on the overal SAS requirement. I'd like to correct my statement in my previous comment. Peer-to-peer communication is not a part of Master-Client, Peer-to-peer communication itself is a seperate network topology like Master-Client. In fact, IEC61850 supports both :-). Just to add, a few of the objectives of IEC61850 synergize with the advantage of Client-Server architecture, as given in Answers.com (http://wiki.answers.com/Q/Advantages_of_Client_Server_system_using_LAN): Centralization - access, resources, and data security are controlled through the server Scalability - any element can be upgraded when needed Flexibility - new technology can be easily integrated into the system Interoperability - all components (clients, network, servers) work together To emphasize, 'INTEROPERABILITY' is the key word in IEC61850 ! Peer-to-peer networking eliminates the need for central servers, allowing all computers to communicate and share resources as equals. Master-Slave architecture would not provide peer-to-peer communication.As the name implies, Master would have entire control on the transaction of data over the network, and also the slaves are not allowed to talk to each other :-)
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

HerbUnfollow Follow Herb Herb Falk 61850 is not quite as simple as DNP/Modbus. DNP/Modbus truly makes use master/slave. In 61850, there are 2 paradigms. One is client/server (e.g. MMS based profile) and peer-to-peer (GOOSE). For client/server, MMS defines a difference between the entity that establishes a connection/association (known as the Calling entity) and the entity that accepts the association required (known as Called). Once the association, either entity in the association can act as a

requestor (client) or responder (server). In today's systems, clients/calling are typically the same (e.g. they set up the information that needs to be reported). Once the report is set-up, the reporting node actually issues unsolicited requests (InformationReports/61850 Reports) withough the intervention of the "master" at all (as long as the association is still active). In the future, it could be possible for the IEDs to be the calling node (e.g. to the RTU) and then the RTU acts as the client to aggregate/concentrate information. Through this future process, the RTU doesn't have to continuously attempt to establish associations to "offline" IEDs.

GOOSE is peer-to-peer and is point-to-multipoint (e.g. multicast). If the "subscriber" wants the information, it may not need to interact with the publisher at all. Hope this helps.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Hmmm...Master/Slave vs. Client/Server? The short answer is that no, they are not the same, but the differences are subtle. To start with, I will point out that DNP3 no longer uses the term "Slave" because it is offensive to some people. The term used in the DNP3 specification for about the last decade is "Outstation". I believe the "Master/Slave" concept origininated with the serial versions of many utility protocols, some of which grew out of earlier industrial protocols. In these protocols, there was no distinct layering, so access to the data link was controlled by what we now call the application layer. Essentially, one station not only collected all the data, but it also controlled access to the physical link; nobody spoke unless the "master" spoke to them first. Hence the terms "master" and "slave". Some industrial protocols have retained this concept but moved the master control of media access down into the data link layer where it belongs, freeing the application layer to concentrate on the job of data retreival. When the DNP3 specification was released, it differed from most of these protocols (there were

hundreds) because it permitted the outstation to transmit "unsolicited responses" without being polled, if the physical layer was able to resolve collisions. This was a big "if". You could rig up an RS-485 or Bell 202 modem system to make it work within a substation, but mostly the concept worked best with dial-up systems where the telephone network would resolve collisions with busy signals. DNP3 was unique in that the "unsolicited" message contained all the metadata needed to parse the response, unlike other protocols that required the master to remember what it originally asked for. So although DNP3 could still be used in "Master/Slave" mode, it began to look a lot more like the "Client/Server" model that had been popularized through the Internet. The terms "Client" and "Server" in the Internet context really have to do with who initiates the connection, not necessarily the direction the data flows. However, in the World Wide Web, they are almost always the same: your web browser "client" always initiates the connection and the data mostly flows from the web "server" to the client. But consider a DNP3 over TCP/IP implementation that permits unsolicited responses: The DNP3 outstation can initiate a TCP connection and send an unsolicited response to a DNP3 master. Technically, it is a TCP "client" in this situation and the master is a TCP "server" because it accepted the connection. That connection may then drop and the master can later act as the "client", initiating a connection to poll the outstation. So part of the the answer is that in the majority of situations, "master/slave" and "client/server" are the same, but this is mostly a combination of the fact that most systems are still polled and the fact that people confuse network and data link access with data collection. IEC 61850 further confuses the issue because its "unsolicited responses" (known as reports) must first be initialized by the client. In this way, it follows a third model, called "publish/subscribe" which is distinct from either "client/server" or "master/slave". GOOSE is the same way. Others in this conversation have also noted, that generally a "server" can handle requests from multiple "clients". This is true for IEC 61850 but not true for DNP3 or Modbus, which asssume one master and one outstation. If a second master needs simultaneous access, a second instance of DNP3 software must run on the outstation. In summary, 1. Master/Slave was originally about data link access 2. Client/Server was originally about transport layer connections 3. Both sets of terms get confused with the idea of who is initiating the transfer 4. Both sets of terms get confused with the idea of who is collecting the data 5. Another term, publish/subscribe, more accurately describes some of IEC 61850
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Master Slave traditional SCADA * Master asks a question (what is the value of point 346532 which the engineer knows is B phase Amps on Feeder 3) or sends command (operate output point 8765439 which the engineer knows means close CB on Fdr 2) * Slave answers with data (point 346532 is a value of 10 which the engineer knows is 10A primary) or carries out command, otherwise Slave is silent RTU is definitely a Master Relays are definitely slaves. Client Server appears in IEC 61850 but in principle can also be general SCADA as it encompasses same capability as Master-Slave. Note a client may also be a server to a higher level client. The Server has the source of data, the Client uses the data. * Client asks a question or sends command (just like Master except as IEC 61850 asks "what is Fdr3 Bphase Amps" or sends command "Fdr2 CB close") * Server answers with data or carries out command (just like Slave except as IEC 61850 answers as "Fdr3 B Phase Amps is 10Amps primary") * Server also can send predetermined reports to a specific client based on certain events/triggers occurring (this is not GOOSE as it is a one off message of the event and not repeated) So a Gateway/RTU is definitely a Client. It may also be a Server to the Master Station Client. Or it may be a Slave to the Master Station. A relay is definitely a Server. It may possibly be a Client if it is running some sort of control system if it is using data from Reports from other IEDs but the specific communications relationship has to be established Publisher Subscriber GOOSE and Sampled Values this is Peer to Peer i..e the Subscriber could be another IED which itself is also Publisher * Publisher sends out messages on the network doesnt care if anything is subscribing or not. * Subscriber listens for specific messages Relays are definitely publishers and subscribers (eg CB Fail scheme 'per to peer') RTU/Gateway are likely to be Subscribers. Could be Publishers but in general not an elegant thing to do (you wouldnt want it sending say a CB open/close command using GOOSE as this means that 99.999999% of time it is repeating every second two messages for every circuit breaker CB1 Close not required and CB1 Open not required) So In Master Slave there must always be a Master and always a Slave In Client Server there will always be a Client and always be a Server But in Publisher Subscriber there are sensibly both but can be a Publisher and no Subscriber, perhaps even vice versa

1 month ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

Jasjeet SinghUnfollow Follow Jasjeet Singh Jasjeet Singh Hanjrah Thanks Herb, Grant, Rodney. Rodney & Grant, excellent description!!! Grant: If GOOSE is peer to peer, can we assume that GOOSE messages are not meant for RTU & only for peer-to-peer between IED's (i.e relays, etc)
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes I'll get in before Grant .... :) GOOSE is meant for any IED who needs to listen - a 'peer' or another level. I describe it as a "fire alarm in your office" - it is continually sending out a message "no fire" by being silent (silence is a message too) and everyone in the office is potentially listening to it and will keep working as normal. One day it may change to send out a BEEP instead of silence and anyone in the room can hear that. It is then up to the individual to decide what they do as a result. So an RTU can listen (Subscribe) to a GOOSE as much as any IED - the Publisher (an IED of some sort) doesn't care if no-one is listening (in the same way the fire alarm will still go off even

if there is no-one in the building) eg the relay on Feeder 1 will be sending out a GOOSE "Prot Fdr 1 NOT operated" One day the relay will detect a fault and operate and send out a changed GOOSE "Prot Fdr 1 HAS operated" Other IEDs may be listening and on the basis of that changed GOOSE decide to initiate a CB Fail or Autoreclose etc. The RTU may also listen to that and record the event in the Seq Of Events log as a protection operation, raise an alarm on the HMI, it might also initiate A/R if that is configured in the RTU etc So the GOOSE has no inherent "command' - it is really just a repetiton signal of the STATUS of some function(s) - it is in the operated or non operated state - published for the use of any listening device. The Subscriber is configured to interpet the change of status as a reason to initiate some other action(s) Yes the Publisher will change the CONTENT of message when an event happens but it is repetitively sending the message forever.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jasjeet SinghUnfollow Follow Jasjeet Singh Jasjeet Singh Hanjrah Thanks a lot Grant :-) Very prompt and great explanation with excellent analogy with fire alarm!! One question comes to my mind, if GOOSE is like communication everytime to all IED's, does not it consumers up un-necessary bandwidth (i assume GOOSE is required for very high speed communication, less than 4miliseconds, please correct me on that)
1 month ago Unlike Like

Reply privately Flag as inappropriate

Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Yes it is sending messages repetitively so yes there is a CONSTANT data rate which you can easily calculate required bandwidth. The actual message is very small so we are not talking about Megabytes of traffic. If you add up all the GOOSE on the network you will get the max bandwidth assuming they are all sending at the same instant. The network bandwidth must obviously process the combined length of all GOOSE within 1 second when the next cycle would start. When an event happens there is the fast repetition so the bandwidth will increase for a short time but obviously one event in the substation will only cause a few GOOSE to go through that cycle. However some people talk about this as "an event happening which starts all the GOOSE flying and floods the network". This is obviously wrong as GOOSE are flying all the time and a few extra GOOSE may need to be catered for as a result of a couple of things happening but even so it would be hard to max-out a modern network running at 1GB or 10GB even adding in other general traffic requirements. But like all things it does need to be engineered and verified for the network topology, network load and of course whether there is any VLANs or filtering in the network switches. And yes you are correct GOOSE is designed for the fast communicatiosn requirement of protection operations between IEDs peer-to-peer even though others devices like RTUs may be interested to listen too. This is another reason why it is hard to imagine why an RTU "needs" to publish super fast GOOSE (possibly a few fast control schemes) when it can send specific commands as commands in a once off message that is acknowledged in the same way and performance times as 'traditional' SCADA. As my father always said "use the right tool for the right job"
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Jasjeet SinghUnfollow Follow Jasjeet Singh Jasjeet Singh Hanjrah Thanks Rodney! Yet another great explanation Key takeaway you have already mentioned " Right tool for the right job" This is the baseline to everything!!
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Hi Jasjeet; I agree with Rodney's answer. GOOSE messages are not intended for any particular type of device. They are most commonly used between relays, but as Rodney points out, it can also be useful to have a device that just monitors GOOSE traffic in the substation and reports the sequence of events to an external client.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KarlheinzUnfollow Follow Karlheinz

Karlheinz Schwarz Some 6 days ago Grant Gilchrist mentioned that the "IEC 61850 further confuses the issue because its "unsolicited responses" (known as reports) must first be initialized by the client." What is required to send a report from an IEC 61850 server to an IEC 61850 client? Must a client initialize the "unsolicitaed response"? It depends. A server needs to have a Data Set (referring to the data to be reported) and a Report Control Block (referring to a Data Set). Before the server sends a report, the Report Control Block must be enabled (rptEna=True). The Data Set, the Control Block and the rptEna=True can be configured upfront. When a client opens an association with the server, then the Reports will be sent to the client without any initialization by the client. If the Control Block is not automatically enabled, then the client has to enable the reporting by just sending a "True" to the attribute rptEna of that Control Block. The client may also configure a new Data Set and set the reference to the new Data Set in the Control Block and enable the Report Control Block.

ZafUnfollow Follow Zaf


World first installation of high voltage substation with IEC 61850 process bus myemail.constantcontact.com

The State Grid Corporation of China commissioned the Dalv Substation in January of 2009. This was the world's first installation of a High Voltage substation with IEC 61850 Process Bus where IEEE 1588 version 2 Time Synchronization and dynamic multicast filtering have been used.
2 months ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Share Link o Reply Privately

Ali ABUK, Helen Yujie Bai and 1 other like this

You, Ali ABUK, Helen Yujie Bai and 1 other like this 7 comments

VasantUnfollow Follow Vasant Vasant Lad Zag, can you please share the sub station topology and the number of bays in substation ? Howmany relays and goose reports utilized? Thank you.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

rezaUnfollow Follow reza reza layegh Dear Mr. Zaf, Thanks for your short report.Could you please share the substation network architecture and the number of bays in substation ? Thanks in advance
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

CharlieUnfollow Follow Charlie Charlie Swiesz, P.E. I'd be very interested in finding out more about the equipment used. Was all of the 61850 devices from a single vendor? How did you test data and network integrity and redundancy?
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

S SathishUnfollow Follow S Sathish S Sathish Babu Hi,.thanks for information. can i get some more details about this system...?
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

VasantUnfollow Follow Vasant Vasant Lad Reza, Charlie , Satish Can any one tell me about the information you received from Jef on your questions? I am looking forward to know more about the same information.

Jef, what method is used for far end device tripping?


1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

CampyUnfollow Follow Campy Campy H Atmahadi Mr Zaf Coelho, Thank you for your experience shared. Please share further information of : substations voltage level, position of substation in grid (a substation with one source Transmission or or multi source Transmission), system integrator (from state-grid or from main vendor or from professional body), network architecture, number of bays in substation, who is the major vendor, the vendor of gateway (local or import), the vendor of BCU (local or import), the vendor of ProtectiveRelay IEC61850 (local or import), the vendor of master-clock (local or import), the vendor of master-station (transmission-Area-Control-Center) , and is Is Rugged the only vendor from external ?.
29 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

L.S.Unfollow Follow L.S. L.S. Karandikar Can you share info re:Vendors of 61850 equipment?

neutral connection in generator synchronizing

Options

Mark as New Bookmark Subscribe Subscribe to RSS Feed Highlight Print Email to a Friend Report Inappropriate Content

01-18-2012 04:39 PM

Hello I am planning to connect the neutral of the entire three synchronized cat 608 kva similar generator set on the common ground bus bar (the ground will also be connected to the bus bar) without any neutral- grounding contactor (this is because I am using 3 pole contactors for the main synchronization). I have tried to gather information about this idea on the internet and I have seen different ideas posted which contradicts. Will this create problem? Please advise me from practical point of view. If it is possible advice me, any ways which could avoids the possible risks without using the neutral contactor
Thanks in advance

Depreciation of 3516 gen set


Options

Mark as New Bookmark Subscribe Subscribe to RSS Feed Highlight Print Email to a Friend Report Inappropriate Content

12-26-2011 08:41 AM Kindly i need to know how to make depreciation for diesel generator such as 3516 gen sets

I want to know the maximum life time of the gen sets , the depreciation factors to could calculate the {salvage value, book value } after a number of years

Awaiting for your help Best Regards Message 1 of 2 (851 Views) Reply 0 Kudos acousticwork Visitor

Re: Depreciation of 3516 gen set


Options

Mark as New Bookmark Subscribe Subscribe to RSS Feed Highlight Print Email to a Friend Report Inappropriate Content

01-31-2012 07:24 AM Diesel gensets such as the 3516 have been appreciating in relative value for the last few years for several reasons:

1) The Caterpillar 'Extended Service Coverage' program (ESC) for used generator sets. This allows standby diesel generator sets to remain under full Caterpillar factory warranty for up to 25 years....and prime power units may use this program as well as Caterpillar's 'Overhaul Protection Coverage' for units with over 25,000 hours. No other manufacturer stands behind their equipment for anywhere close to this time frame.....which effectively equates to the industry standard 'life' of this equipment. You should budget for replacement at the 25 year interval on any standby unit, and at the ten year interval for a prime. Please note I stated BUDGET....how well the equipment is maintained will ultimately decide how long it stays in service. It is still quite common to see Cat D399's in very useful service (all over the world) after over 40 years of service.

2) Upgrade / Upfit 'Kits - Caterpillar has offered the 'EMCP2 / 2+' digital control panel in kit form for well over a decade now. Top that with the Cat CDVR and VR6 voltage regulators, and you can upfit / modernize just about any generator set out there, regardless of the make. They also offer component level parts lists for conversion to the EMCP3. Now that the EMCP4 has been released, it only gets better. With a properly maintained engine and generator, the addition of modern controls will extend the useful life of your generator set by many years.

3) Emissions - Older generator sets have gone up in value due to the tough emissions standards imposed in the USA. Most regions of the world have not allowed money to infiltrate their politics as we have in the USA....and thusly, their regulations reflect less 'palm greasing'. In the USA, an older standby genset has gone up in value because it is allowed to remain a simpler technology (more reliable). And since this type of generator set is still allowed to be manufactured and sold everywhere else in the world, it remains a highly prized commodity.

Want to find out how much your genset is worth? Put it on eBay or a similar web-based site and place a high reserve on it. Or, search for similar generator sets on the web and see what they are fetching. If you have a Caterpillar, it will always be worth more money because of the aforementioned programs....and they have been globally supported longer than any other.

If you have a serial number, post it here and maybe we'll get a few 'bites'.....

MaciejUnfollow Follow Maciej

What are the European initiatives or regulatory policies for cyber security in the Smart Grid?
I am wondering if you are aware of any standardization or regulatory efforts in European countries that are related to cyber security in critical infrastructure that would affect Smart Grid and utility substations. I would like to know what are the different countries doing in order to define standards, guidelines or best practices to secure utility networks. In North America there is NERC CIP which mandates utilities to comply with detailed requirements and procedures as well as oblige them to provide audit trails, compliance reports, etc. In Europe seems there is no common strategy, governments or agencies in some countries created working groups or started activities to define cyber security recommendations. I am aware of CPNI in the UK and CyberTEC in the Netherlands. Are you aware of other cyber security focus groups or regulatory efforts in Europe?

18 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Emmanuel Britto, David Bru i Bru like this You, Emmanuel Britto, David Bru i Bru like this 6 comments

MartinUnfollow Follow Martin Martin Dobie Hello Maciej, Check out bodies like: CEN/CENELEC/ETSI/ENISA good starting points in relation to your question. Regards, Martin
18 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MaciejUnfollow Follow Maciej Maciej Goraj Thanks Martin, I did a bit of research and found interesting information about CSCG (the CEN/CENELEC/ETSI effort) and European Commission driven initiatives like ERNCIP. I am wondering when we can expect a Pan-European cyber security enforcement law for utilities equivalent to the NERC-CIP. On the other hand NERC-CIP is pretty much focused on transmission utilities and seems to exclude DA and AMI applications. It would be interesting to know if EU will be ambitious enough to cover all levels of Smart Grid and not just bulk transmission systems.
17 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MartinUnfollow Follow Martin Martin Dobie Smart grids are still governed under IEC standards of course. I found some other relatedf interesting reading In Bits and Pieces Vulnerability of the Netherlands ICT-infrastructure and consequences for the information society, March 2000 www.iwar.org.uk/cip/resources/tno/cip-netherlands.pdf PROTECTING CRITICAL INFRASTRUCTURE IN THE EU CEPS TASK FORCE REPORT 2010 http://www.isn.ethz.ch/isn/Digital-Library/Publications/Detail/?id=125704&lng=en On Critical Infrastructure Protection and International Agreements http://www.isn.ethz.ch/isn/Digital-Library/Publications/Detail/?id=128205&lng=en Yes..... it is a can of worms
17 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JimUnfollow Follow Jim Jim Christensen It would be more accurate to say that IEC Standards "apply" to smart grids than that they "govern" them. IEC standards are voluntary unless and until they are defined as regulatory requirements by national or regional authorities.
17 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

EmmanuelUnfollow Follow Emmanuel Emmanuel Britto In Brazil there is one government associated company called ONS (System National Operator) which states rules for any kind of condition to one who intends to join the EHV Brazilian National Grid. It applies to all those under at least 230kV or above. Their requirements are free and can be visited in the following site: www.ons.org.br Unfortunately the site is in portuguese.
15 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MaciejUnfollow Follow Maciej Maciej Goraj I would like to thank all who contributed to this discussion. In the United States NERC relies on 8 Regional Entities that monitor and enforce compliance by performing regular and scheduled audits, random spot checks and specific investigations. In 2011 NERC started refocusing efforts on reliability excellence, eliminate undue regulatory burdens, streamline paperwork requirements, increase caseload processing, and encourage continued timely and thorough self-reporting and mitigation. After several years of delay, NERC finally began assessing actual penalties in 2011. I believe that Europe should follow the way NERC CIP compliance is enforced in North America. The trigger for European utilities to start taking cyber security seriously and apply common policies will be when the European Commission will create proper legislation and implementation and enforcement rules. The European Commission should have tools to monitor implementation of cyber security standards at TSOs and DSOs and when necessary lanuch the infringement procedures.

Transmission time of GOOSE


Hello I want to measure the transmission time of GOOSE to check which performance class it falls. How I can measure it? At what point of time I should start the measurement? Is it the time when the event really happened? Or is it the time when the ied detects the event? And isnt the measurement done till the GOOSE message hits the network?
14 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

2 comments

DavidUnfollow Follow David David Ingram IEC 61850-5, section 13.4 provides the defintion of transfer time. The tricky part is isolating the communications processing time from the rest of the IED processing time. Don't forget to consider other times like grid code tripping times. If the communications is fast, but the IED is slow to detect or to respond, you may not comply with your requirements. 61850 is all about communications systems, not protection systems (hence no current way of defining protection logic).
13 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

HerbUnfollow Follow Herb Herb Falk You should check some of the GOOSE Testing documents on the UCA website, if you are a member. There are several test cases that discuss this issue.

61850

Discussion | Poll

Now there's another great way to start a conversation with your group!
Click on "Poll" to get started. Close

Discussions Members Promotions Jobs Search More... o Updates o Your Activity o Your Settings o Subgroups o Group Profile o Group Statistics

BirinderUnfollow Follow Birinder

Obtain Fault record (trip log) from Siemens Relay over IEC 61850
Just wondering is it possible to obtain Fault records (trip log) over IEC 61850 from Siemens Relay such as 7SA522 etc.
1 month ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

5 comments

Juan CamiloUnfollow Follow Juan Camilo Juan Camilo MVM, Ingeniera de Software It is possible to obtain COMTRADE files from SIPROTEC 4 relays using MMS protocol (which is defined in IEC61850), but you can't download trip log information using MMS.
5 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

CdricUnfollow Follow Cdric Cdric Harispuru It is possible to retrieve COMTRADE files via MMS file transfer. Indications (details about the trip, start/operate, etc) can be retrieved via MMS reporting. You can find those details in Siemens PIXIT. Here the example file for your mentionned SIPROTEC4 relay 7SA522: http://siemens.siprotec.de/download_neu/devices/7SA6xx/Protocol/IEC_61850/Mapping/7SDSA VK_Manual_PIXIT_A4_V043000_en.pdf
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Many IEC 61850 relays support MMS file transfer including Siemens. The typical usage is for COMTRADE. While I can't speak to the specific capabilities of each individual brand or type of relay and what data it allows to be put into a COMTRADE file or which specific files it allows to be transferred, there is nothing from either an IEC 61850 or COMTRADE perspective to prevent a relay from putting trip log information into a COMTRADE file.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Thanks Everyone for your replies,We are able to get COMTRADE files and Fault Location using MMS (Read) operation, but still not able to get the fault record (Like Fault Curent, etc, like a complete fualt report) from the siemens IED using 61850.Thanks.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Then it would seem that the IED is not properly configured to capture the current measurements in the COMTRADE file. This probably has nothing to do with IEC 61850. It sounds like an IED configuration issue.

P543 Line Differential Protection: Technical discussion


It is possible with this model of protection, sending along with the differential message a trigger signal to the remote end, that is, to use this equipment as differential protection and as teleprotection simultaneously? I think that not, but I would like to confirm.
14 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

2 comments

MohamedUnfollow Follow Mohamed Mohamed Ibrahim I think it can be via interMicom function you can configure it in PSL to send any signal to remote end like teleportation equipment
12 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Gopala KrishnaUnfollow Follow Gopala Krishna

Gopala Krishna Palepu Line Differential Protection includes Tele-protection Signals. the both end currents are regularly compared and fault in the line/cable it will operate. Next Thing we can visualise the remote end equipment status. in case of GE/Alstom it can transmit 8 signals. where as Siemens(7SD532) we can Transmit the 28 Signals & in case of ABB(RED670) we can Transmit 16 Signals. That is more advantageous

As IEC61850 and ethernet getting more and more popular in electrical engineering application, courses like CCNA is helpful for working electrical engineers to add and edge in their career ?
Members kindly share your views.
15 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

SURENDRA CHAUHAN likes this You, SURENDRA CHAUHAN like this 4 comments

DavidUnfollow Follow David David Ingram CCNA is going to be useful if you use Cisco equipment. Not much help if you use RuggedCom, Hirschmann, Kyland etc. I would think that getting a good understanding of how 61850 based systems are created and engineered would be more use. Wrangling SCL based-files, and knowing the difference between ICD, CID, IID, SSD and SCD would be essential. It is very satisfying the first time you get GOOSE/MMS messages passing information between products from different vendors. Getting

SV to work is actually very simple. Having an understanding of networking principles is good (VLAN, multicast, rate limiting, redundancy protocols), and would work across vendors. I'm working with switches from Cisco, RuggedCom and Hirschmann, and while the interfaces are all different the principles are the same.
14 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DhirenUnfollow Follow Dhiren Dhiren Thakker Thanks David for your input.
12 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

EdgarUnfollow Follow Edgar Edgar Sotter Hi Dhiren, David is right when he mentions the main thing is understanding the networking principles. However if you are new in networks a CCNA course can give you that base you need. Other companies, like Ruggedcom, also offer network training but CCNA is available almost everywhere and it is cheaper. Yes, they will teach you how to program CISCO routers and switches, but you will see the concepts are the same in all brands and if you know how to

program a CISCO switch or router, you will know how to program a Ruggedcom, Hirschmann, Kyland, etc. It is like learning how to drive a manual car.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DhirenUnfollow Follow Dhiren Dhiren Thakker Thanks Edgar for your input.The idea of starting this discussion is to know what level of networking knowledge is required for the electrical engineers working at OEM or customer side working on substation automation field.As far as basic configuration of the switch is concerned it is is easy to understand but when it comes to RSTP or VLAN concept I have personally felt that it is really required to know networking well. As more and more substations will be migrated to IEC61850,it is important to know for the maintenance engineer how the network is behaving,how is the present loading of the network,what is future expandability etc.

What would be your best approach if you are to implement IEC 61850 in a transmission grid, the existing protection system is a mixture of old mech relays, to advanced digital relays 61850 capable?
3 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

2 comments

Vinoo SUnfollow Follow Vinoo S Vinoo S Warrier This is a very broadly-scoped question. There may be many answers focusing on different aspects of your proposed upgradation. One way of breaking down the problem domain is to ask What, Why kind of questions. What is your objective in detail? What is your budget? Why are you planning this? etc. If you want to completely replace your SAS with a 61850 solution, there are tons of solutions with single-vendor mode from all the major OEMs. There are precedents with multi-vendor solutions also but these are fraught with interoperability issues (this forum can show you many such discussions). Other lower cost solutions may be to use gateways/protocol-convertors if your objective is only to make devices "talk" to each other. If your IEDs do not support any communication protocol, you may still be able to extend their usage if they have IOs by using an IO Gateway or Module. I do not recommend single vendor solutions due to the obvious lock-downs to the vendor, but depending on the extent/scale to which you plan to upgrade this may still be a viable option to keep in mind.
17 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes The first step is to make sure there is Executive understanding of the BENEFITS of doing this. If this is done properly, then they will be whipping you to get on with it - any stumbling blocks and 'nay-sayers' will be quickly removed - strangely the Executives are interested, no...., MOTIVATED in saving 20% of their CAPEX cost and reducing engineering time by 6-12 months, and increasing reliability and getting Reusable Engineering. This is important as it is TOO easy for the Execs to see some engineer come to them saying "I want to play with a new toy" and then pull the rug out from under them because they don't see the

benefit. Without some sort of 'education', they certainly don't wake up saying "I wish an engineer would propose putting a GOOSE in the substation .." Having got them to see the benefit, they need to understand the investment. You don't get benefits for free. If you haven't spent a few $M over a couple of years in consulting support and training and tools procurement and integration to your processes - then don't expect to get the benefits - you will fail. A 10 - fold or more return on investment is usually well supported - even if you got the estimate wrong of the cost or the return by 10%! Leverage experience - refer CIGRE Tech Brochure 326, Fig 20 - there are a LOT of people who have already crossed this bridge and can tell you what to do - and most importantly what NOT to do. Set about DEFINING REQUIREMENTS - you'll only get them to your satisfaction if you and others know what they are. Procurement to MATCH REQUIREMENTS - not just comply to the Standard (not all roadapproved standard vehicles will match your particular use/preference) Then make sure you have what I call the 3 I's: * Intellectual Property - specifications, standards .. * Intellectual Capacity - the right tools and test equipment, the new work-flow procedures and documentation systems ... * Intellectual Capability - knowledge and skills - which means SIGNIFICANT TRAINING, not just attend a 2-day Essential Technology course (although that is really a pre-requisite starting point) and think you can do anything now ... the right number of staff trained in all aspects of the life cycle. This includes getting involved with knowledgeable groups like CIGRE and their many Technical Brochures referencing IEC 61850 - you can buy or if you/your company is a member (couple of $K per year) you can download for free - also go to some of their technical meetings once a year. LinkedIn is great but if you get something wrong and a blackout ensues, your boss won't accept an excuse "some unknown face on LinkedIn said..." oh, and not to forget subscribe to PAC World magazine - might have to seek Board approval for $25/year?? Perhaps even join UCAIUG, perhaps get involved with WG10 and the TISSUES process. Sounds scary/daunting? Out of all this after getting the Execs on board and pushing you, I would emphasise starting with leverage experience and training. This is an organisational Change Management programme and should be structured as such

What actuators refers to on the process bus in the architecture of 61850?


8 days ago

Close viewer

Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

5 comments

WeiUnfollow Follow Wei Wei Yang Merging unit with 61850-9-2, ECT EVT; Switch control unit with 61850 GOOSE;
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq OK. but a merging unit refers to a logical device, and it takes on values of current and voltage, samples them and passes on to the control and protection units. So are control and protection units also actuators?
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KstutisUnfollow Follow Kstutis Kstutis Motkaitis It doesnt matter where an actuator(a binary output) and a merging unit is "located" physically. You could have 10 IEDs , lots of 61850 bricks,lots of merging units, or you could have 1 IED which has lots of analog inputs(MMXU) lots of binary outputs and inputs. In the end you come up with some 61850 structure for controling and protecting an object. In other words you just hook all stuff you have into 61850 network, you get all list of logical devices and merging units and you configure them all to work as it need to work. And you just don't care where those are physical devices. process bus is not a physical device. I think the only physical device that could be refered as proces bus physically is just a LAN (which interconnect several 61850 devices)
19 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq Ya, you are right that process bus is physically a Ethernet switch, which interconnects devices. But the question is what devices are process bus devices except the CTs, VTs, and the analog I/0s?
7 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DavidUnfollow Follow David David Ingram The process level is defined in 61850-1 to be "Process level devices are typically remote I/Os, intelligent sensors and actuators". IF4 and IF5 are the interfaces that link the process and station levels, so this is the process bus. The definition that I use is that process level devices 'touch' the hardware. Any device that connects to switchyard equipment is a process device. This could be a transformer tap changer, circuit breaker, earth switch, CT, VT, gas density sensors, oil temperature probe etc. The matching LN can be instantiated anywhere: a standalone merging unit could be installed at the CT/VT and provide TCTR or TVTR LNs; or a protection relay with conventional inputs can provide the TCTR & TVTR. In the latter case the process interface is 1A & 110V analogues, rather than a process bus per se.

What do you see as the major obstacles in implementing IEC 61850 at your company?
posted 10 days ago 23 votes

Benefits don't out weigh the cost Business process change too difficult Limited product availability Technology still not mature Cybersecurity concerns

Vote

Benefits don't out weigh the cost

3 (0%)

Business process change too difficult

6 (0%)

Limited product availability

1 (0%)

Technology still not mature

12 (0%)

Cybersecurity concerns

1 (0%)
your vote

Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

23 comments Jump to most recent comments

PaulUnfollow Follow Paul Paul Myrda Please elaborate on your concerns with IEC 61850 as you feel appropriate. A lot of effort has been put into the concept by the TC57 - WG10 team and vendors over the years but implementation especially in North America is still limited. Any feedback on what is preventing progress with this technology would be helpful.
10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SujayUnfollow Follow Sujay Sujay Kulkarni I recently had a discussion with a mid level manager at a public utility in India. This particular utility has whole-heartily adopted IEC61850. All sub-stations constructed in last 4 years use only GOOSE based interlocks & have completely done away with hard-wired interlocks. In fact all BCU & BPU are in switch-yard, with only fiber-optic cable coming in the control room. Last month they wanted to add a bay to a recently constructed sub-station. As the sub-station was based on IEC61850 'standard' they assumed that they can now go to any manufacturer for the additional bay & integrate with existing one. However they found out that all vendors quoted reasonable prices for supplying bay equipment but the cost of integration was more that double the equipment cost. Incidences like these are now creating doubts about utility of this standard, main reason of adopting which was inter-operability. My company is also currently involved in implementing sub-station automation scheme in many sub-stations. Based on actual experience, it is easier to communicate with a IEC103 based relay than a IEC61850 one. This is further made worse by the fact that due to complexity of the standard, there is very less expertise with utilities who are now increasingly dependent on vendors for implementation. This of-course is Indian scenario & things could be very different in other parts of the world.
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney

Rodney Hughes @Sujay Your experiences sounds "par for the course" and there are many calls for tools and implementations to be improved. Just an observation on the comment - yes it is easier to communicate with a 103 device - that is a process of asking it a series of questions and it will answer yes/no or value = 45.7 (whatever that happens to mean) It is quite another matter to engineer one device such that it can give cause for another device to do something of a real-time (sub-millisecond) critical nature - this is what systems integration is all about. I think many in the industry still think of IEC 61850 as a mere protocol - a "DNP4" with more defined "multiple-choice" standardised questions. The real benefit of IEC 61850 is the re-usable engineering if the process and tools have been well used and of course the skills developed.
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh We have successfully integrated IEDs from ABB, SIEMENS, GE, AREVA, SEL over IEC61850 within 1 SCADA / 1 Gateway, and we being Indian company with our own Gateways / SCADA system have proven solutions for IEC 61850 Integrations involving various IEDs form different manufacturers.
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Mr, Sujay, The integration cost is only because of the changes required by Companies to implements another manufacture IEDs, key differences may be One Company IED only supports indexed reports while other manufacturer IED only support non indexed IEDs, and may be some IEDs only allows dynamic dataset creation etc... etc... that can only be resolved if the supplier has complete control over the products / firmware / software and access to the relays (or need to debus on site).
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Are these issues indicative of lack of maturity of the IED implementations and/or the tools that support them (to cater fro different vendors implementation) &/or too much flexibility of the Standard?
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh No its about implementation philosophy, for example, I am manufacturer of IEDs / SCADA & Tools, so the tools / the system are designed to support my own products as the developers / system designers / testers are the same people for all the product range so the design got limited to the implementation that I have in might. We being independent Gateway / SCADA Manufacturers have to ensure that we support all the leading brands Hardware, so had designed solutions that fit all requirements.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima The maturity of the IED implementations can't be greater, as the tools that support them. Too much flexibility of the Standard is the key: the "standard" that is not a "standard" is the problem. As a developer I can say that a standard specification that is grater than 1000 pages, too flexible in a lot of part, is so difficult to implement ad to integrate with other vendors. If there is a problem of integration, since the low level communication is not human-readable at all, is so hard to tell if something is wrong. And in most case, each vendor is compliant to the specification.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Clearly a standard that takes a 1000+ pages to describe is going to be more difficult to implement than a standard that takes 100 pages. IEC 61850 was designed to make using compatible products easier. It was not designed to make developing the products easier. With legacy approaches the developer could put the data anywhere in the device they wanted and document the register/index number for the user. Then it is up to the user to figure out where the currents, voltages, statuses, etc. are in each device, determine how they need to manipulate those values to implement a power system function, and keep track of all that so it can be maintained over time. With IEC 61850 much of that work is pushed onto the device developer who has to conform to a predefined model for the data and services. The benefit is to the user, not the product developer. Simplicity works only if you never try to do anything complex. If the only use case for evaluating the "easiest" to use protocol is based on the need to exchange 16 digital states once a second, then you will likely find Modbus the "easiest" to use. But if you let someone use "simple" protocols to address many other use cases that involve features like buffering, integrity scans, report by exception, data change triggering, quality change triggering, range alarms, signal descriptions, complex data, interlocks, control blocks, settings and synchrophasors along with hundreds of different protection functions, metering functions, switching functions, etc. etc. etc. it can't be done "easily" using simple protocols. While IEC 61850 is not perfect, there is always room for improvement, I do not believe that it is either too complex or too flexible. IEC 61850 handles complexity better than the legacy approaches. Power systems are inherently complex. A protocol optimized for power systems is going to have some complexity to it by necessity. There are definitely new things that must be learned before understanding can be acheived. But anyone that can understand bay control and protection schemes can learn IEC 61850. Once it is learned the benefits are there and systems (and products) can be designed, implemented, understood and debugged by humans. I would be very interested to learn more details about how cost factors are driven in multi-vendor phased integrations. That would be very useful. For instance, what were the specifics of that system where IEC 61850 is claimed to be the driving cost factor that makes integration of an existing bay with a new bay twice as expensive as the equipment cost for that new bay? How many buses, protection schemes, devices, etc. are in the new bay? The existing bay? What level of integration was required between them? How well was the existing system documented in the RFP? etc. etc. Without some detail it is very difficult to judge what was the actual primary driving cost factors.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Well said Ralph Your last para is extremely pertinent to help the industry move over the notional speed bumps that are being used to slow or block progress. Bring on the feedback!! It is not an SED - Simple Electronic Device - we had those from the 1970's through to the early 1990's. Nor is it just a CED - Communicating Electronic Device that the SCADA system could talk to in ever increasing engineering effort for the user which we had no alternative to until IEC 61850 came along. It is an IED with the emphasis on Intelligent which means capable of very complex stuff which can only be created by the developers who have lots of options to be able to create lots of different capabilities to suit a plethora of potential use cases. One could postulate that the change from a horse and buggy to a car involved a huge increase in complexity for the manufacturers but despite the simplicity of a horse, the users needed a more capable and easy to use means of transport that could cater for 1 passenger or pulling a 10 ton load - yes we did have to learn how to use a clutch, change gears, brake safely, check the oil level, build petrol stations, establish road rules such as left or right hand driving, signalling and good practice of maintaining safe distance between vehicles. Much of that has stayed the same for the user but the complexity and performance/comfort/emissions/safety/flexibility of use of the car from a Model T to the current range of vehicles is clearly a huge difference based on the work of the manufacturers.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio

Fabio Bima I work for Alstom, for Siemens and many other. I work with thousand of variables. I manage wind park and substations. And I prefer IEC60870-5-104: trigger, events, buffer and all the functions I need. If I have a plate of meat, I prefer to use a shining new and simple knife then a swiss knife. But this is a point of view. My point is that when I have to integrate a system with ABB and Alstom I have problems: each single device work great alone, but in team they are painful. And when we developed our own version of the protocol, we had to forgot the specification focusing on what other vendors have done. We are not lazy, we are pragmatic. You are right, the user experience is the target. But how is the user? Not the customer: he doesn't matter if the system work with protocols or with magic. Not the operator: he wants to see alarms on a blinking video. I suppose the user is the SCADA developer, the man how has to check if each variable is read/set correctly to animate graphic pages and to make automation programs. I thick that the SCADA developer prefer an "excel like" list where a signal is named: - Circuit Breaker 1 - Double point - 1 - Circuit Breaker 2 - Double point - 2 rather than - Circuit Breaker 1 - C1_3M12CONTROL/L52XCBR1$ST$Pos$stVal - Circuit Breaker 2 - C1_3M12CONTROL/L52XCBR2$ST$Pos$stVal (translating the xml notation).
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz I'm not trying to argue about a personal preference. I am no different. I prefer what I know. My goal is only to make the point that (because of my own personal bias/preference/opinion) IEC 61850 has a reasonable level of complexity and that many of the features that contribute to its complexity are very useful. To use the same analogy about knives, there are certainly a lot of things that can be done using a simple knife (http://tinyurl.com/d2p3n5q). I have used a knife for many things other than just cutting something. But a swiss army knife is not always the monstrously complex object that people find unwieldy (http://tinyurl.com/d5wf2xu). In my mind, IEC 61850 is more like the swiss army knife that I own: http://tinyurl.com/dx28waw. It is more complex than a simple knife but it is also

more useful, is reasonably handy and still easy to use. I am very interested in the specifics of the problems of integrating these vendors. Can you share some details? I think understanding that would be very helpful.
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima I have seen two kind of faults: 1. Protocol complexity In a plant we had two SCADA and 20 protections. I have seen each protection frozen for both SCADA due to some communication error (we had to restart the protections). The error was in the communication, since the first system was running for months alone. A big problem. Each part of the system is tested and compliant to the standard 61850. The customer called us to tell why the communication was broken and the protection frozen (a kind of thid party question) , but we cannot tell quite nothing: sometime it happens. This is not a fault of the protocol himself, but even with wireshark sniffing the communication, we cannot make a diagnosis. I quite sure the problem is in the protections firmware, but I have never seen a protection with a simpler protocol frozen due to communication issue. When the second SCADA was set on a different protocol, the system started working. 2. Vendor specific When we work with Alstom, we know that they use virtual output, a kind of signal that takes different meaning on different plant. More. Alstom has an automatic naming system for 61850: each time they add a signal to the protection or when they enable an alarm, the full list of tag 61850 can change. The standard permit this. The Alstom system can handle automatically each change, but any other cannot without reconfiguring and retesting its system. For the standard freedom is a good thing. For Alstom also is good because they have a good sistem and for other vendor is complex connecting to their system. For me is a disaster. Wich features of 61850 are very useful to you? Meybe I don't know them: I have subscribed this group to learn more about this protocol. Thanks.
6 days ago Unlike Like

Reply privately

Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Regarding #1. That is a very bad situation. Your customer unfortunately chose products from what would appear to be a poor quality supplier. There is no technical reason why IEC 61850 based devices would have protection (or any other function) freeze. In fact, IEC GOOSE used for protectoin is a relatively simple protocol that maps directly to Ethernet. It is unlikely that you could debug a programming mistake like that by looking at messages over the wire. There are many thousands of IEC 61850 devices that are operational and do not ever freeze, especially the protection functions. I am sure everyone would reasonably consider that as an absolute minimum requirement. The fact that non-61850 devices from this same supplier do not freeze is just a lucky coincidence. #2. That is interesting. I can see that a device that automatically regenerates its namespace when new signals are added would be advantageous. However, it would be better if it added the new signals in such a way that it did not rename all the other objects in the device. In other words, if you add a 3rd measurement to a device with MMXU1 and MMXU2 installed you would hope that the device would name that MMXU3 and leave MMXU1 and MMXU2 alone. This is interesting and it brings to mind some other comments I have seen. IEC 61850 does not eliminate the need to understand device features and how vendors have implemented them. Users must still have a good knowledge of the products they are buying to understand how the developer implemented them. Developers are always looking for ways to stand out so that they can differentiate themselves. Any standard must accommodate that or progress will stop. Although some think that IEDs are becoming commoditized I don't think that is necessarily a good thing for suppliers or users as it reduces the level of innovation that the industry will produce. Regarding useful features, maybe Rodney can post some more about how IEC 61850 improves the engineering process. I think that this is a very substantial benefit of IEC 61850 that is sometimes overlooked when examining the details of the models, services, and protocols. You will have to excuse me but I do not know much about 104 so it is hard for me to point out explicit differences and the benefits therein. But, as one example, when I consider the flexibility of the IEC 61850 reporting model I have to think that this is an advantage. The flexibility is that each individual client has a lot of control over how the server behaves in reporting. One client used for alarming applications can be looking at one set of data using a certain set of reporting characteristics while another client running a trending application can look at completely

different data using completely different reporting characteristics. Of course, if you never need this flexibility then it is hard to see it as an advantage. Here is an actual use case that a user requested that is easily handled by configuration: For a given feeder, they wanted to get a report of the average currents of each phase along with at least one voltage measurement every ten minutes but they also wanted to receive an immediate report anytime any voltage or current exceeded a normal range. This is easy to accomplish in IEC 61850 by carefully defining the dataset to contain the instMag values for the current averages (Edition 1) and voltages (which do not trigger data change reports) along with the range alarm attributes from the MMXU (which will trigger a data change report) and configuring the report with the appropriate integrity period, buffer times, and trigger options. This can be done without impacting any other reporting that the device is supporting to other clients. While I don't know how you would do this using 104 I do know the user was quite pleased that it could be done like this using IEC 61850.
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima Even with the 104 you can send different values to different masters, but you need to configure only the Server. Each Master will make a simple connection, without knowing anithing but the address that he requires. 104 have cyclic values (once in second or what else) or spontaneous values (triggered on change, on change with histeresys, on thresholds, on what ever the server can calculate), decided by who configures the server. In 104 the master can have all the values from the server without any configuration. If you add an association IOA Address (a number) = "Signal Description" you have fully configured the communication (yes, there are some other parameters, but to read information is enough). As you said in 61850 each Master can set its trigger option, and if the user is smart enought can set the appropriate dataset, trigget option and integrity periods. For me this is the biggest difference: in 104 the user (have to)/(can) only discard the information that he doesn't need, simple as checking a list.

104 is not greedy of bandwidth, so about your example, usually the server sends each measure 10 times in a minute. If it is not good enough for your system, a trigger must be defined on the Server for the Master that requires it. In my experience you will never need a trigger like that: if you have an over voltage or an over current the protection trips, and if you need only a warning of hi-consuption a delay of 5/10 sec is more than reasonable.
5 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SujayUnfollow Follow Sujay Sujay Kulkarni This discussion is getting interesting. I will like to add some of observations: 1. Complexity: As a manufacturer of relays, it is possible to make feeder protection relay based on a 30MHz Micro-controller with 128KB Ram. However when I want IEC61850 in it, I need minimum 100MHz processor with 64MB ram. (These are just illustrative numbers, not exact). One might argue that if a simple phone can support 4GB of memory, why not a relay. The answer is: it was possibly simple, off-the-shelf (phone) hardware which was used in the case Fabio has referred to. And I dont agree with Rodney about horse-cart & automobile analogy. Most cars owners have never opened cars bonnet. However, utility engineers (who are the real users) have to understand the standard to derive benefit out of it. 2. Over-hype: At least in India, vendors sold IEC61850 as one-solution-to-all-your-problem. Some key-phrases used were 'inter-operability' & 'vendor-neutral'. (In US it seems to be 'reusable-engineering'). This has still not proved it-self to be true in practice. 3. Vendor-specific: Real benefits of this standard are when you follow ICD-SCD-CID engineering methodology. However this is not clearly defined in the standard & most vendors don't follow this. For example I know manufacturers who support only icd files. Some support only cid files. Most manufacturers do not have tool to program relay with scd or cid file as input. In the standard 'IEDname' is not allowed to have embedded spaces. But some manufacturers allow this, which means only their software will work with their hardware. Time-synchronisation is a basic part in automation. But for some relay, we have to completely re-program the relay to set NTP server. Currently we are facing problem in one of sites where we are trying to communicate with Siemens relays. The communication breaks/ behaves erratically, possibly because of private extensions of the standard used, 4. Bandwidth requirements. This may or may-not be a serious issue. However just compare this with the fact that Indian Railways has about two dozen scada systems which control huge geographical area, but works on 1200 bps link & they are getting all the information they want for day-to-day operations.

2 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Dear Sujay: I have seen couple of vendor specific implementation like you have mentioned IEDName, this is where i always feel that the importance of having full control over the source code and the reason we developed our own IEC61850 stacks. We have executed coupled of sites with such problems and were able to resolve it.
1 day ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson In my investigations into Goose subscription, just from an observers point of view, I think there are 3 areas in IEC61850 where improvements could be made that would enhance interoperability. 1. Compliance. Sujay points out a case where a vendor has not properly followed the standard with IEDname, and I have discovered another with confRev (a vendor starts at 0 rather than 1 as per the standard). The Kema tests never really test compliance properly; they really just attempt to show (not disprove ?) that the bits the vendor says work, do work as claimed. Wherever a vendor doesn't follow the standard, either deliberately (to force use of that vendor) or simply accidentally, this has the potential to cause interoperability problems, which may not even be possible to work around.

2. Options. The standard has many optional parts. I think the reason for this is there is such a large range of possible equipment covered, from both a single contact IED all the way up to a very complicated IED with many 100s of IEC68150 nodes and other vendor functions (logic, programmability). It is unreasonable to say force the 'single contact' IED to produce say buffered reports, as it might be very cut down and just able to perform the contact function. I'm not sure of the best solution here. Rodney asks "is there too much flexibility [in the standard]?". Well no, because the standard must allow for the full range of implementations possible. I could imagine some scheme where various optional parts become mandatory once the IED complexity goes past a certain criteria, but setting those criteria might be very difficult, and of course doesn't help things as they are now. 3. It must be mandatory to be able to program Goose from a vendor independent site config tool exclusively, without having to redo it again in vendors tools. This implies, as others have mentioned, that tools or IEDs must be able to read CID files properly and fully. Of course you'd still expect to program other relay functions (non 61850) with the vendors tool.eg. Logic. Goose could also be done here too, as it is now, but you must not be forced to (and should not be 'the norm'). Report config may also be similar to Goose and may need similar mandates. Of course the vendors tool is allowed to complain if you have tried to ask the IED to do something illegal (eg. attempted to subscibe a Goose to a non-GGIO input when the IED only supports GGIO inputs), but this will force you back to the system design and then hopefully design change later would still be a lot easier. Put simply, to design the IEC68150 parts of the relay, you don't *have* to use the vendors tool, but you may have to use it to finally program the relay.
19 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Vinoo SUnfollow Follow Vinoo S Vinoo S Warrier Bruce, regarding your second point. I believe that the test certificate provided by agencies like KEMA is supplemented by a detailed test report which clearly indicates what test have been performed and what have been skipped. The skipped tests are specific to implementations which do not claim support for those features, according to the vendor provided PICS/PIXIT/MICS etc. files.

The best way to utilize the conformance information is to read together the test certificate, the test report and the vendor provided compliance docs including the ICD, PICS, MICS and the newer versions of the Implementation Conformance documents (I believe now we have a SCL Implementation Conformance or SICS document also). If a customer reads all these documents together he can get a reasonably clear picture of what he can expect to get from the IED. Summarizing, I think the current mechanism for conformance testing does give the flexibility to test devices that range from simple fixed function IEDs to complex multi-function IEDs, but the customer may not be aware of the intricacies of the information contained in all these documents. From these documents you can get clarity not only at a high level (are RCBs supported? How many can be configured? etc.) but also to a very detailed level (Does the IED support dynamic datasets? Does it support "buffer-period" in BRCBs? Are the "RptID"s fixed or dynamic? etc.) I agree fully with your point 3 however. The discrepancies in GOOSE configuration seem to be an outright contradiction of what the standard aims for, and is not because of "loopholes" or "lack of a suitably standard" mechanism.
18 hours ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson With point 2 I was not noting a lack of testing flexibility, but perhaps advocating a more rigid structure where once a defined (??) level of complexity is reached the choice to implement or not implement a feature is taken away from the vendor. ie. If you want to manufacture an IED of complexity level "B" some of the optional items in the standard now become mandatory. If it is level at say "F" complexity, the standard is as it is now. All existing IEDs would be 'F' by default, even if they really shouldn't be, based on how 'complex' they are. They can only declare other levels if all the feature set for the desired level and all those below are implemented and type tested. Why ? Purely for interoperabiltiy reasons. A customer doesn't need to pore over many Kema documents to discern if vendor A IED will talk with vendor B IED if they are at the same 'complexity' level. They can have a reasonable expectatation that they will play together.

Also, the limitations for talking between IEDs of different levels can be more easily quantified and known in advance of attempted integration. Really just a way of conveniently grouping levels of features together into a limited set of complexity levels or classes which make sense. Vendors will hate this of course, that's why it has to be imposed by the standard. Will it help ? I don't know; just throwing it in as an discussion point.

What do you see as the major obstacles in implementing IEC 61850 at your company?
posted 25 days ago 35 votes

Benefits don't out weigh the cost Business process change too difficult Limited product availability Technology still not mature Cybersecurity concerns

Vote

Benefits don't out weigh the cost

5 (0%)

Business process change too difficult

13 (0%)

Limited product availability

1 (0%)

Technology still not mature

15 (0%)

Cybersecurity concerns

1 (0%)
your vote

Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

28 comments Jump to most recent comments

PaulUnfollow Follow Paul Paul Myrda Please elaborate on your concerns with IEC 61850 as you feel appropriate. A lot of effort has been put into the concept by the TC57 - WG10 team and vendors over the years but implementation especially in North America is still limited. Any feedback on what is preventing progress with this technology would be helpful.
25 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SujayUnfollow Follow Sujay Sujay Kulkarni I recently had a discussion with a mid level manager at a public utility in India. This particular utility has whole-heartily adopted IEC61850. All sub-stations constructed in last 4 years use only GOOSE based interlocks & have completely done away with hard-wired interlocks. In fact all BCU & BPU are in switch-yard, with only fiber-optic cable coming in the control room. Last month they wanted to add a bay to a recently constructed sub-station. As the sub-station was

based on IEC61850 'standard' they assumed that they can now go to any manufacturer for the additional bay & integrate with existing one. However they found out that all vendors quoted reasonable prices for supplying bay equipment but the cost of integration was more that double the equipment cost. Incidences like these are now creating doubts about utility of this standard, main reason of adopting which was inter-operability. My company is also currently involved in implementing sub-station automation scheme in many sub-stations. Based on actual experience, it is easier to communicate with a IEC103 based relay than a IEC61850 one. This is further made worse by the fact that due to complexity of the standard, there is very less expertise with utilities who are now increasingly dependent on vendors for implementation. This of-course is Indian scenario & things could be very different in other parts of the world.
23 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes @Sujay Your experiences sounds "par for the course" and there are many calls for tools and implementations to be improved. Just an observation on the comment - yes it is easier to communicate with a 103 device - that is a process of asking it a series of questions and it will answer yes/no or value = 45.7 (whatever that happens to mean) It is quite another matter to engineer one device such that it can give cause for another device to do something of a real-time (sub-millisecond) critical nature - this is what systems integration is all about. I think many in the industry still think of IEC 61850 as a mere protocol - a "DNP4" with more defined "multiple-choice" standardised questions. The real benefit of IEC 61850 is the re-usable engineering if the process and tools have been well used and of course the skills developed.

23 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh We have successfully integrated IEDs from ABB, SIEMENS, GE, AREVA, SEL over IEC61850 within 1 SCADA / 1 Gateway, and we being Indian company with our own Gateways / SCADA system have proven solutions for IEC 61850 Integrations involving various IEDs form different manufacturers.
23 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Mr, Sujay, The integration cost is only because of the changes required by Companies to implements another manufacture IEDs, key differences may be One Company IED only supports indexed reports while other manufacturer IED only support non indexed IEDs, and may be some IEDs only allows dynamic dataset creation etc... etc... that can only be resolved if the supplier has complete control over the products / firmware / software and access to the relays (or need to debus on site).
23 days ago Unlike Like

Reply privately

Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Are these issues indicative of lack of maturity of the IED implementations and/or the tools that support them (to cater fro different vendors implementation) &/or too much flexibility of the Standard?
23 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh No its about implementation philosophy, for example, I am manufacturer of IEDs / SCADA & Tools, so the tools / the system are designed to support my own products as the developers / system designers / testers are the same people for all the product range so the design got limited to the implementation that I have in might. We being independent Gateway / SCADA Manufacturers have to ensure that we support all the leading brands Hardware, so had designed solutions that fit all requirements.
22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima The maturity of the IED implementations can't be greater, as the tools that support them. Too much flexibility of the Standard is the key: the "standard" that is not a "standard" is the problem. As a developer I can say that a standard specification that is grater than 1000 pages, too flexible in a lot of part, is so difficult to implement ad to integrate with other vendors. If there is a problem of integration, since the low level communication is not human-readable at all, is so hard to tell if something is wrong. And in most case, each vendor is compliant to the specification.
22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Clearly a standard that takes a 1000+ pages to describe is going to be more difficult to implement than a standard that takes 100 pages. IEC 61850 was designed to make using compatible products easier. It was not designed to make developing the products easier. With legacy approaches the developer could put the data anywhere in the device they wanted and document the register/index number for the user. Then it is up to the user to figure out where the currents, voltages, statuses, etc. are in each device, determine how they need to manipulate those values to implement a power system function, and keep track of all that so it can be maintained over time. With IEC 61850 much of that work is pushed onto the device developer who has to conform to a predefined model for the data and services. The benefit is to the user, not the product developer. Simplicity works only if you never try to do anything complex. If the only use case for evaluating the "easiest" to use protocol is based on the need to exchange 16 digital states once a second, then you will likely find Modbus the "easiest" to use. But if you let someone use

"simple" protocols to address many other use cases that involve features like buffering, integrity scans, report by exception, data change triggering, quality change triggering, range alarms, signal descriptions, complex data, interlocks, control blocks, settings and synchrophasors along with hundreds of different protection functions, metering functions, switching functions, etc. etc. etc. it can't be done "easily" using simple protocols. While IEC 61850 is not perfect, there is always room for improvement, I do not believe that it is either too complex or too flexible. IEC 61850 handles complexity better than the legacy approaches. Power systems are inherently complex. A protocol optimized for power systems is going to have some complexity to it by necessity. There are definitely new things that must be learned before understanding can be acheived. But anyone that can understand bay control and protection schemes can learn IEC 61850. Once it is learned the benefits are there and systems (and products) can be designed, implemented, understood and debugged by humans. I would be very interested to learn more details about how cost factors are driven in multi-vendor phased integrations. That would be very useful. For instance, what were the specifics of that system where IEC 61850 is claimed to be the driving cost factor that makes integration of an existing bay with a new bay twice as expensive as the equipment cost for that new bay? How many buses, protection schemes, devices, etc. are in the new bay? The existing bay? What level of integration was required between them? How well was the existing system documented in the RFP? etc. etc. Without some detail it is very difficult to judge what was the actual primary driving cost factors.
22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Well said Ralph Your last para is extremely pertinent to help the industry move over the notional speed bumps that are being used to slow or block progress. Bring on the feedback!! It is not an SED - Simple Electronic Device - we had those from the 1970's through to the early 1990's. Nor is it just a CED - Communicating Electronic Device that the SCADA system could talk to in ever increasing engineering effort for the user which we had no alternative to until IEC 61850 came along.

It is an IED with the emphasis on Intelligent which means capable of very complex stuff which can only be created by the developers who have lots of options to be able to create lots of different capabilities to suit a plethora of potential use cases. One could postulate that the change from a horse and buggy to a car involved a huge increase in complexity for the manufacturers but despite the simplicity of a horse, the users needed a more capable and easy to use means of transport that could cater for 1 passenger or pulling a 10 ton load - yes we did have to learn how to use a clutch, change gears, brake safely, check the oil level, build petrol stations, establish road rules such as left or right hand driving, signalling and good practice of maintaining safe distance between vehicles. Much of that has stayed the same for the user but the complexity and performance/comfort/emissions/safety/flexibility of use of the car from a Model T to the current range of vehicles is clearly a huge difference based on the work of the manufacturers.
22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima I work for Alstom, for Siemens and many other. I work with thousand of variables. I manage wind park and substations. And I prefer IEC60870-5-104: trigger, events, buffer and all the functions I need. If I have a plate of meat, I prefer to use a shining new and simple knife then a swiss knife. But this is a point of view. My point is that when I have to integrate a system with ABB and Alstom I have problems: each single device work great alone, but in team they are painful. And when we developed our own version of the protocol, we had to forgot the specification focusing on what other vendors have done. We are not lazy, we are pragmatic. You are right, the user experience is the target. But how is the user? Not the customer: he doesn't matter if the system work with protocols or with magic. Not the operator: he wants to see alarms on a blinking video. I suppose the user is the SCADA developer, the man how has to check if each variable is read/set correctly to animate graphic pages and to make automation programs. I thick that the SCADA developer prefer an "excel like" list where a signal is named: - Circuit Breaker 1 - Double point - 1 - Circuit Breaker 2 - Double point - 2

rather than - Circuit Breaker 1 - C1_3M12CONTROL/L52XCBR1$ST$Pos$stVal - Circuit Breaker 2 - C1_3M12CONTROL/L52XCBR2$ST$Pos$stVal (translating the xml notation).
22 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz I'm not trying to argue about a personal preference. I am no different. I prefer what I know. My goal is only to make the point that (because of my own personal bias/preference/opinion) IEC 61850 has a reasonable level of complexity and that many of the features that contribute to its complexity are very useful. To use the same analogy about knives, there are certainly a lot of things that can be done using a simple knife (http://tinyurl.com/d2p3n5q). I have used a knife for many things other than just cutting something. But a swiss army knife is not always the monstrously complex object that people find unwieldy (http://tinyurl.com/d5wf2xu). In my mind, IEC 61850 is more like the swiss army knife that I own: http://tinyurl.com/dx28waw. It is more complex than a simple knife but it is also more useful, is reasonably handy and still easy to use. I am very interested in the specifics of the problems of integrating these vendors. Can you share some details? I think understanding that would be very helpful.
21 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima I have seen two kind of faults: 1. Protocol complexity In a plant we had two SCADA and 20 protections. I have seen each protection frozen for both SCADA due to some communication error (we had to restart the protections). The error was in the communication, since the first system was running for months alone. A big problem. Each part of the system is tested and compliant to the standard 61850. The customer called us to tell why the communication was broken and the protection frozen (a kind of thid party question) , but we cannot tell quite nothing: sometime it happens. This is not a fault of the protocol himself, but even with wireshark sniffing the communication, we cannot make a diagnosis. I quite sure the problem is in the protections firmware, but I have never seen a protection with a simpler protocol frozen due to communication issue. When the second SCADA was set on a different protocol, the system started working. 2. Vendor specific When we work with Alstom, we know that they use virtual output, a kind of signal that takes different meaning on different plant. More. Alstom has an automatic naming system for 61850: each time they add a signal to the protection or when they enable an alarm, the full list of tag 61850 can change. The standard permit this. The Alstom system can handle automatically each change, but any other cannot without reconfiguring and retesting its system. For the standard freedom is a good thing. For Alstom also is good because they have a good sistem and for other vendor is complex connecting to their system. For me is a disaster. Wich features of 61850 are very useful to you? Meybe I don't know them: I have subscribed this group to learn more about this protocol. Thanks.
21 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Regarding #1. That is a very bad situation. Your customer unfortunately chose products from what would appear to be a poor quality supplier. There is no technical reason why IEC 61850 based devices would have protection (or any other function) freeze. In fact, IEC GOOSE used for protectoin is a relatively simple protocol that maps directly to Ethernet. It is unlikely that you could debug a programming mistake like that by looking at messages over the wire. There are many thousands of IEC 61850 devices that are operational and

do not ever freeze, especially the protection functions. I am sure everyone would reasonably consider that as an absolute minimum requirement. The fact that non-61850 devices from this same supplier do not freeze is just a lucky coincidence. #2. That is interesting. I can see that a device that automatically regenerates its namespace when new signals are added would be advantageous. However, it would be better if it added the new signals in such a way that it did not rename all the other objects in the device. In other words, if you add a 3rd measurement to a device with MMXU1 and MMXU2 installed you would hope that the device would name that MMXU3 and leave MMXU1 and MMXU2 alone. This is interesting and it brings to mind some other comments I have seen. IEC 61850 does not eliminate the need to understand device features and how vendors have implemented them. Users must still have a good knowledge of the products they are buying to understand how the developer implemented them. Developers are always looking for ways to stand out so that they can differentiate themselves. Any standard must accommodate that or progress will stop. Although some think that IEDs are becoming commoditized I don't think that is necessarily a good thing for suppliers or users as it reduces the level of innovation that the industry will produce. Regarding useful features, maybe Rodney can post some more about how IEC 61850 improves the engineering process. I think that this is a very substantial benefit of IEC 61850 that is sometimes overlooked when examining the details of the models, services, and protocols. You will have to excuse me but I do not know much about 104 so it is hard for me to point out explicit differences and the benefits therein. But, as one example, when I consider the flexibility of the IEC 61850 reporting model I have to think that this is an advantage. The flexibility is that each individual client has a lot of control over how the server behaves in reporting. One client used for alarming applications can be looking at one set of data using a certain set of reporting characteristics while another client running a trending application can look at completely different data using completely different reporting characteristics. Of course, if you never need this flexibility then it is hard to see it as an advantage. Here is an actual use case that a user requested that is easily handled by configuration: For a given feeder, they wanted to get a report of the average currents of each phase along with at least one voltage measurement every ten minutes but they also wanted to receive an immediate report anytime any voltage or current exceeded a normal range. This is easy to accomplish in IEC 61850 by carefully defining the dataset to contain the instMag values for the current averages (Edition 1) and voltages (which do not trigger data change reports) along with the range alarm attributes from the MMXU (which will trigger a data change report) and configuring the report with the appropriate integrity period, buffer times, and trigger options. This can be done without impacting any other reporting that the device is supporting to other clients. While I don't know how you would do this using 104 I do know the user was quite pleased that it could be done like this using IEC 61850.
21 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima Even with the 104 you can send different values to different masters, but you need to configure only the Server. Each Master will make a simple connection, without knowing anithing but the address that he requires. 104 have cyclic values (once in second or what else) or spontaneous values (triggered on change, on change with histeresys, on thresholds, on what ever the server can calculate), decided by who configures the server. In 104 the master can have all the values from the server without any configuration. If you add an association IOA Address (a number) = "Signal Description" you have fully configured the communication (yes, there are some other parameters, but to read information is enough). As you said in 61850 each Master can set its trigger option, and if the user is smart enought can set the appropriate dataset, trigget option and integrity periods. For me this is the biggest difference: in 104 the user (have to)/(can) only discard the information that he doesn't need, simple as checking a list. 104 is not greedy of bandwidth, so about your example, usually the server sends each measure 10 times in a minute. If it is not good enough for your system, a trigger must be defined on the Server for the Master that requires it. In my experience you will never need a trigger like that: if you have an over voltage or an over current the protection trips, and if you need only a warning of hi-consuption a delay of 5/10 sec is more than reasonable.
20 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SujayUnfollow Follow Sujay Sujay Kulkarni This discussion is getting interesting. I will like to add some of observations: 1. Complexity: As a manufacturer of relays, it is possible to make feeder protection relay based on a 30MHz Micro-controller with 128KB Ram. However when I want IEC61850 in it, I need minimum 100MHz processor with 64MB ram. (These are just illustrative numbers, not exact). One might argue that if a simple phone can support 4GB of memory, why not a relay. The answer is: it was possibly simple, off-the-shelf (phone) hardware which was used in the case Fabio has referred to. And I dont agree with Rodney about horse-cart & automobile analogy. Most cars owners have never opened cars bonnet. However, utility engineers (who are the real users) have to understand the standard to derive benefit out of it. 2. Over-hype: At least in India, vendors sold IEC61850 as one-solution-to-all-your-problem. Some key-phrases used were 'inter-operability' & 'vendor-neutral'. (In US it seems to be 'reusable-engineering'). This has still not proved it-self to be true in practice. 3. Vendor-specific: Real benefits of this standard are when you follow ICD-SCD-CID engineering methodology. However this is not clearly defined in the standard & most vendors don't follow this. For example I know manufacturers who support only icd files. Some support only cid files. Most manufacturers do not have tool to program relay with scd or cid file as input. In the standard 'IEDname' is not allowed to have embedded spaces. But some manufacturers allow this, which means only their software will work with their hardware. Time-synchronisation is a basic part in automation. But for some relay, we have to completely re-program the relay to set NTP server. Currently we are facing problem in one of sites where we are trying to communicate with Siemens relays. The communication breaks/ behaves erratically, possibly because of private extensions of the standard used, 4. Bandwidth requirements. This may or may-not be a serious issue. However just compare this with the fact that Indian Railways has about two dozen scada systems which control huge geographical area, but works on 1200 bps link & they are getting all the information they want for day-to-day operations.
17 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Dear Sujay: I have seen couple of vendor specific implementation like you have mentioned IEDName, this is where i always feel that the importance of having full control over the source code and the reason we developed our own IEC61850 stacks. We have executed coupled of sites with such problems and were able to resolve it.
16 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson In my investigations into Goose subscription, just from an observers point of view, I think there are 3 areas in IEC61850 where improvements could be made that would enhance interoperability. 1. Compliance. Sujay points out a case where a vendor has not properly followed the standard with IEDname, and I have discovered another with confRev (a vendor starts at 0 rather than 1 as per the standard). The Kema tests never really test compliance properly; they really just attempt to show (not disprove ?) that the bits the vendor says work, do work as claimed. Wherever a vendor doesn't follow the standard, either deliberately (to force use of that vendor) or simply accidentally, this has the potential to cause interoperability problems, which may not even be possible to work around. 2. Options. The standard has many optional parts. I think the reason for this is there is such a large range of possible equipment covered, from both a single contact IED all the way up to a very complicated IED with many 100s of IEC68150 nodes and other vendor functions (logic, programmability). It is unreasonable to say force the 'single contact' IED to produce say buffered reports, as it might be very cut down and just able to perform the contact function. I'm not sure of the best solution here. Rodney asks "is there too much flexibility [in the standard]?". Well no, because the standard must allow for the full range of implementations possible. I could imagine some scheme where various optional parts become mandatory once the IED complexity goes past a certain criteria, but setting those criteria might be very difficult, and of course doesn't help things as they are now. 3. It must be mandatory to be able to program Goose from a vendor independent site config tool

exclusively, without having to redo it again in vendors tools. This implies, as others have mentioned, that tools or IEDs must be able to read CID files properly and fully. Of course you'd still expect to program other relay functions (non 61850) with the vendors tool.eg. Logic. Goose could also be done here too, as it is now, but you must not be forced to (and should not be 'the norm'). Report config may also be similar to Goose and may need similar mandates. Of course the vendors tool is allowed to complain if you have tried to ask the IED to do something illegal (eg. attempted to subscibe a Goose to a non-GGIO input when the IED only supports GGIO inputs), but this will force you back to the system design and then hopefully design change later would still be a lot easier. Put simply, to design the IEC68150 parts of the relay, you don't *have* to use the vendors tool, but you may have to use it to finally program the relay.
16 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Vinoo SUnfollow Follow Vinoo S Vinoo S Warrier Bruce, regarding your second point. I believe that the test certificate provided by agencies like KEMA is supplemented by a detailed test report which clearly indicates what test have been performed and what have been skipped. The skipped tests are specific to implementations which do not claim support for those features, according to the vendor provided PICS/PIXIT/MICS etc. files. The best way to utilize the conformance information is to read together the test certificate, the test report and the vendor provided compliance docs including the ICD, PICS, MICS and the newer versions of the Implementation Conformance documents (I believe now we have a SCL Implementation Conformance or SICS document also). If a customer reads all these documents together he can get a reasonably clear picture of what he can expect to get from the IED. Summarizing, I think the current mechanism for conformance testing does give the flexibility to test devices that range from simple fixed function IEDs to complex multi-function IEDs, but the customer may not be aware of the intricacies of the information contained in all these documents. From these documents you can get clarity not only at a high level (are RCBs supported? How many can be configured? etc.) but also to a very detailed level (Does the IED support dynamic

datasets? Does it support "buffer-period" in BRCBs? Are the "RptID"s fixed or dynamic? etc.) I agree fully with your point 3 however. The discrepancies in GOOSE configuration seem to be an outright contradiction of what the standard aims for, and is not because of "loopholes" or "lack of a suitably standard" mechanism.
16 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson With point 2 I was not noting a lack of testing flexibility, but perhaps advocating a more rigid structure where once a defined (??) level of complexity is reached the choice to implement or not implement a feature is taken away from the vendor. ie. If you want to manufacture an IED of complexity level "B" some of the optional items in the standard now become mandatory. If it is level at say "F" complexity, the standard is as it is now. All existing IEDs would be 'F' by default, even if they really shouldn't be, based on how 'complex' they are. They can only declare other levels if all the feature set for the desired level and all those below are implemented and type tested. Why ? Purely for interoperabiltiy reasons. A customer doesn't need to pore over many Kema documents to discern if vendor A IED will talk with vendor B IED if they are at the same 'complexity' level. They can have a reasonable expectatation that they will play together. Also, the limitations for talking between IEDs of different levels can be more easily quantified and known in advance of attempted integration. Really just a way of conveniently grouping levels of features together into a limited set of complexity levels or classes which make sense. Vendors will hate this of course, that's why it has to be imposed by the standard. Will it help ? I don't know; just throwing it in as an discussion point.

Implementation of the XCBR Logical Node


If I have a 61850 capable circuit breaker IED modelling an XCBR, can that XCBR respond to more than one Goose in order to trip (POS state change initiated), or will the circuit breaker IED

also need to include a PTRC model in order to perform the logical OR of multiple Goose? Also, if you wish to command a circuit breaker to trip via a 61850 control, can you clarify the difference between doing this by controlling POS in an associated CSWI, or controlling POS direct in the XCBR model (which allows an optional CTRL) ?
4 months ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Gianni Tolo, Jasjeet Singh Hanjrah and 3 others like this You, Gianni Tolo, Jasjeet Singh Hanjrah and 3 others like this 29 comments Jump to most recent comments

RodneyUnfollow Follow Rodney Rodney Hughes Refer IEC 61850-5 Chapter 12 - although titled "informative", it gives some examples of use of XCBR and CSWI. In terms of number of GOOSE, vs PTRC, imagine a 4 stage OC and 4 stage EF relay - that is 8 separate PTOC in one box each with a Start and a Operate output. But it is never just thaose logical nodes - eg a 4-zone distance relay has 8 PDIS, probably some back up directional PTOC, PTOV, PTUV, PTUF, perhasp even some integral line PDIF ..... The functions that may need to know about the Start and/or Operate of all these tripping protection functions are the XCBR obviously, the RREC, RBRF, the IHMI ... plus if you have used say a Reverse Blocking bus bar protection scheme then the upstream relay may need those signals from EACH downstream feeder ... so you suddenly find the GOOSE data set becomes very large on a single protection function basis compared to an old hard wired scheme where you only have one output for start and one for trip - hence the PTRC gives you that equivalency of output.

4 months ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

JimUnfollow Follow Jim Jim Christensen Is there any documentation online of this alphabet soup of acronyms?
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SergiuUnfollow Follow Sergiu Sergiu Paduraru Jim, the acronyms - like the ones Rodney uses in the message above - represent mostly logical nodes and logical node classes, as specified by the standard. You can find them in many places, one of them being here: http://www.nettedautomation.com/download/std/LNs_2010-02-06.pdf
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JimUnfollow Follow Jim Jim Christensen Thanks, Sergiu. Now if only they were all mapped to IEC 61499 Service Interfaces ;-).
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Indeed it is alphabet soup - probably about the only 'criticism' of IEC 61850 that I would generally agree with that there are lots of new acronyms - it is a new way of life, of thinking about how we do our jobs but at least they have some inherent meaning once you understand the structure (i.e. you really need to have a copy of the Standard handy for the detail behind the meaning) compared with under C37.2 standard somehow knowing what a device number 5 is (being somewhat obscure), or worse device number '11' is ultra obscure as a device with "three or more comparatively important functions" . There are now some 230 Logical Node acronyms alone now available for use, plus then terms like PICS, SICS, MICS, PiXiT...... CIGRE SC B5 is 'trialling' - perhaps 'playing' is more accurate at this stage - with an idea for an on-line acronym look up - very much in its infancy.
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GianniUnfollow Follow Gianni Gianni Tolo To all thanks for your comments on my post. Rod, I'm interested in your initial comments. If I can perhaps rephrase my question. In order to make an IED modelling XCBR trip a circuit breaker, is it as simple as having the XCBR logical node subscribe to the Goose messages from other Logical nodes modelled in the various protection IEDs in the substation such as PTOC or indeed PTRC as you mention? Is it possible for the XCBR Logical node to subscribe to multiple Goose messages to trip the CB? Which data object in the XCBR model would subscribe to the Goose messages to undertake a trip? Is it Pos?
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes to be more precise yes the IED can subscribe to one or more GOOSE messages. Within each of those GOOSE messages is the data set which constitutes one or most likely several status from other LNs. You would also expect to see quality flag to go with it at least. So one GOOSE message may have several status elements in the data set which any one or more could lead to XCBR operation of the CB - or indeed used for any other required purpose (remember GOOSE is an event status, not a command) - it is a matter of knowing how the particular IED 'links' that LN attribute from the data set into the function eg the InRef in Ed2 or

whether it is linked directly to XCBR or as some vendors require linking it to a GGIO first (which of course loses the semantics - hate GGIO !). So yes, the XCBR could be using a signal from one or more LNs contained in one or more GOOSE to initiate the trip. Ch 12 shows the XCBR getting a status from a Pxxx.Op LN directly which would imply we want the CB to trip or from a CSWI - these could be two totally different GOOSE from two totally different IEDs.
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DaveUnfollow Follow Dave Dave Banham Here's the rub: HV protection systems consist of a mixture of 3-phase tripping functions (e.g. Phase over-current) and single phase tripping functions (e.g. line-diff, or line distance). The trip conditioner has to accept these 3-phase and 1-phase trip requests and send them to each single pole breaker. Moreover, the trip conditioner can be placed in a forced three phase trip mode such that all single phase trip requests are converted into a three pole breaker trip. Further complications arise from the integration of auto-reclose and CB-fail into such schemes.
4 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce

Bruce Paterson I'd like to ask a further question based on the replies to Gianni if I may. OK, so an XCBR device will be able to respond to multiple Goose (or to be more exact, particular data points within Goose dataset) to trip, reset etc. On a typical 61850 XCBR implementation, how is this specified within the 61850 configuration files and on the device ? The Goose is really just a means of communicating change of state of data points, so it's not really the Goose itself, but the data points we care about. To know about a data point implies knowledge of the server device's ICD which includes *all* the servers data points, and all the Goose datasets of datapoints it transmits, so I assume this lowly XCBR client must read *all* the ICD files of any server devices it needs to understand ? Secondly, somehow which data points (actually, which state of the data point, and possibly quality as well) within this potentially huge database actually cause a trip has to be specified in the XCBR (or program that configures it). How ? I guess this is really a general question about how 61850 clients are configured, but it helps to have an example. Note I am a little familiar with Siemens DIGSI and how it allows connection between (very specific) data points on different LNs, but where this information goes is a mystery. All vendor specific ?
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hi Bruce XCBR is a Logical Node that defines a data structure, inputs outputs and controls that a function has. The Logical Node doesn't do any reading of any ICD files - it is an element within the SCL files. but you are correct that the device will receive a GOOSE data set and extract the bits it needs. The configuration of the publishing IED to send a particular data set with a particular set of bits as well as the configuration of the receiving IED to subscribe to a particular GOOSE message and then extract which bits it is interested in and how it will respond is part of the offline system integration process. The ICD file is imported into the Systems Specification &/or Configuration tool as defined in IEC 61850-6. Once all the system is defined, the tools export appropriate files, perhaps even as CID or IID files, which the proprietary tools then load into the proprietary devices. These various files are not what is transmitted between the in-service devices

3 months ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist To answer one of Gianni's original questions, the difference between operating the breaker through CSWI (control switch) logical node versus the XCBR (circuit breaker) logical node has to do with what additional functions are performed. It is assumed that CSWI communicates with CILO (control interlocking logic) to determine whether it is actually safe for an operator to operate the breaker, and may also communicate with RSYN (protection-related synchronization) or other logical nodes to determine whether the control that is requested by the human being should be operated. Only when it is safe will CSWI operate the "Pos" on the XCBR. On the other hand, the assumption is that XCBR does no such checks. If someone tries to operate XCBR.Pos directly, it will open or close the breaker immediately regardless of interlocking logic or other rules. This raises the question of whether XCBR.Pos should actually be permitted to be remotely writeable for a safe system. I have never had anyone answer this question to my satisfaction, but my opinion is that IEDs should make it read-only despite the fact that it is a DPC (dual-point controllable) data object. It should just reflect the current state as requested by protection or control LNs. To Gianni's original question about PTRC, I suspect using a PTRC would be appropriate. However, the question of when and where to instantiate a PTRC seems to be a bit of a matter of opinion among IEC 61850 protection experts. As has been noted in this discussion, IEC 61850 is not very good at showing the internal logic within an IED, such as which protection elements are combined in a PTRC or which LNs can operate an XCBR.
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MansourUnfollow Follow Mansour Mansour Jalali I dont think any standards provide how we should be doing the design. In my view this is not scope of the standard, right now there are many engineering guide lines under development in WG10 to show to the domain population how they do the engineering in the substation using IEC61850. Controlling or tripping the circuit breaker never has been consistent among the utility, these are engineering and engineering practice issues and not necessary standard.
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson Thanks Rodney, Apologies for some of the incorrect terminology I used in my question. However, I believe you have confirmed exactly what I was thinking. The CID file for a particular LN will contain specific information about all points in other LNs that it needs to know about (ie. may come to my LN within a Goose dataset <- also defined in the CID). Part of the confusion is that our LN actually does directly read the raw CID file on startup itself, rather than being passed through some proprietary tool. I was interested in how the required information is conveyed within the CID file by the overall SCL tools. Not only will it have to contain information about each relevant point, but also about what it is going to do about that point when it observes it change state (eg. My LN has 'seen' some remote PTRC.Op stVal go to trip state via a Goose and now must actually know to trip the circuit breaker). My research so far indicates that maybe the <Inputs> term is used within the CID file, somewhere within the CID section relating to my XCBR LN, to achieve the "what action to take" definition. The <Inputs> refers to the point in another LN that is defined elsewhere in the

same CID file. Possibly this level of discussion is outside the scope of this board :)
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Bruce - still some terminology confusion. The CID file is simply a structured text file that relates to the configuration of a particular Physical Device. It is not "the CID file for a particular LN" Within that file is the configuration of each of the LN within that PD and the configuration of the communications between one LN within that PD and another LN, wherever the other LN is physically located. You seem to be referring to your device which has the CID file loaded into its memory and it uses this to configure itself on power up. Arguably this is an easier approach than as many vendors have done in using their proprietary tools to create a proprietary file to load into the relay, so IMHO 10 out of 10 for that! The systems integrator just needs a good tool that will generate the CID for your device and whatever tool to file transfer it into your IED memory. Remembering that the CID file is just structured text, it is not a program code like Basic, Fortran, C, JAVA or whatever. You could say the CID is just a means of telling the PD that it can expect to receive a message with certain bits which relate to certain meanings (dataset). What your operating firmware interprets that message as needing a certain action is up to the IED developer depending on what the role of the device is - eg if you heard a fire alarm in your office you would leave the building but the same signal would lead to a fireman entering the building and the people next door would just look out their windows - it is role based. Your IED firmware has some sort of program running that needs certain inputs and certain settings to do its function these are defined in the CID file but not what the program has to do with that information. Indeed there will be bits within the dataset of absolutely no relevance to your device at all which it will just ignore.
3 months ago Unlike Like

Reply privately

Flag as inappropriate Flag as promotion

UtkarshUnfollow Follow Utkarsh Utkarsh Verma Bruce - I guess I am too naive to comment. But as Rodney mentioned CID file only defines communication configuration and also defines what data should traverse on IEC61850 network. As GOOSE traverse on Ethernet so you define in your CID about what data ( or in what sequence ) at what rate (how fast) should travel but how/when to set and get that data should be handled by the IED firmware. I am pretty sure that you can configure your LNs (ex XCBR) in the CID file without having circuit breaker configuration in your IED :)
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson Thanks Utkarsh and Rodney. Also I'm humbled by the 10/10 Rodney, but I can't really claim the credit; that's how this particular 68150 stack operates anyway. [One potential pitfall I can see with this approach is scalability, however. Say the substation has a large number of different physical devices all wanting to send different Goose to this simple PD, the CID file could end up being very large, containing all the "ICDs" of all the many and various devices, so hopefully it will still fit !] Let me pose a simple example. I have a PD with a single LN which contains an XCBR model. Let's limit the actions that the firmware can take to just two: trip and reset of the XCBR. In a particular XCBR instance I have 3 external points that can cause a trip, and another external

point that can cause a reset. The CID contains 6 Goose datasets that contain a total of 15 points. I understand how the CID can contain the definitions for these 6 datasets, and all the 15 points to which they refer. Of course the CID cannot specify how my firmware can perform a trip or a reset, but *somehow* it has to be able to specify which of the 3/15 points cause a trip (op #1), and which 1/15 causes a reset (op #2), and which 11/15 do nothing at all. The firmware (without CID) has no knowledge about the external devices at all, so though it may be able to guess say that some stVal=TRUE causes the trip but only if the q=0 with t=don't-care, it cannot know which of the many arbitrary stVal[s] is trip, or reset, or ignore. The CID, or something else, has to contain this mapping information. In 61850-6, 9.3.13 it discusses binding to external signals, and I suspect the intAddr is the key. The rest defines the particular external reference, identically to dataset point definition. The intAddr is the only thing that binds the particular external point to a particular local action. Now the problem I'm having is understanding how the overall site designer tool (vendor independent hopefully) knows what to put in intAddr (which is specified "optional" anyway) ? The info to go in intAddr must come from my device's original ICD file exported to the SCL system designer. Do I provide a 'fake' GGIO input for each possible local action to give the designer tool something to latch onto ? (eg. Draw a line in a GUI tool) Does instead the designer make a link to the ctlVal of the POS of my XCBR, but somehow able to distinguish between trip and reset which are 2 of the N possible states of POS ? Or, to take Rodney's example. I have a Goose that indicates fire in the building, and another that indicates flooding. The fireman has to be told to go into the building when the fire alarm goes, but totally ignore the flooding. Now the role of the fireman is determined by the firmware, but what gets him onto the slippery pole in the first place has to be somehow conveyed by the CID. How ?
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Above all, avoid GGIO the Standard is explicit about why and how you should use GGIO as only when other mechanisms are not available.

Yes, the SCL files can end up very large, especially the SCD file as the central reference file. Some vendors manipulate ICD, CID and IID directly so it is important to understand precisely what role each has to play in the engineering process and what the specific tools are doing with them. The SCD file will contain multiple instances of ICD files according to the number of IEDs. The CID file should be a subset of the SCD file. In as much as the ICD is a template of capability of a type of device, the CID file relates to an individual PD and defines the specific settings and any specific information it needs to know about the other devices with which it is communicating. It doesnt contain all the other ICD as such. Beyond that, all the mapping you refer to is getting into considerable detail of IED firmware and tool development which I would recommend seeking some specific assistance for.
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

UtkarshUnfollow Follow Utkarsh Utkarsh Verma "Now the problem I'm having is understanding how the overall site designer tool (vendor independent hopefully) knows what to put in intAddr (which is specified "optional" anyway) ?" 1. If you are a firmware or tool developer then you must know how/what to set the intAddr. Since each vendor has there own way of setting it so I would be impossible for site designer tool (vendor independent hopefully) to assign intAddr for different vendors IEDs. 2. Also intAddr is something which is very much liked to your firmware. A site designer may have to have knowledge of what dataset should go or what inputs will come but not the intAddr.
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

StevenUnfollow Follow Steven Steven Hodder As a side consideration, I would like everybody to look at the entire thread of comments on this topic, which when looked at in terms of its basic functionality (one or more protections need to trip a circuit breaker) and consider the potentially excessive level of complexity in performing such a functionally simple task. To quote Rodney's first response to the initial question: "you suddenly find the GOOSE data set becomes very large on a single protection function basis compared to an old hard wired scheme where you only have one output for start and one for trip". Consider the fact that there is zero support anywhere within the vast volume for standardized test tools, equivalent in simplicity and universality to traditional hardwired schemes (such as the ubiquitous Flexitest switch). As protection engineers, we should all be wary of excessive complexity in what we design. Our discipline represents the first, last and, in some cases only, line of defence of power system assets and the overall reliability of our bulk power systems. Complexity only serves to reduce the overall reliability of a system, makes it harder to troubleshoot when problems occur (again - note lack of standard test tools), and creates far more opportunities for emergent behaviour to cause unexpected problems (Asimov's "ghost in the machine").
3 months ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BruceUnfollow Follow Bruce Bruce Paterson I tried the LinkedIn email reply feature. Doesn't seem to have worked ! I wrote yesterday in reply to Utkarsh: So IntAddr is vendor specific. A site designer is preferrably vendor independent, therefore cannot populate IntAddr. Presumably a site can be setup to send any number of aribitrary Goose (points) at an IED. The

target IED itself cannot magically know which Goose are important, and which are not, and which (of multiple possible actions) to take on the important ones. How is this information conveyed in 61850 configuration files ? Perhaps Goose reception configuration is always vendor specific ? That would seem to be to be a major impediment to inter-operabilty ! I am a firmware developer who is trying to make IEDs that are as vendor independent as possible. I want to be able to read IntAddr, but have no wish to also have to write it.

How can we compare GOOSE and MMS, in terms of their usage on the station and process bus in the IEC-61850 architecture?
1 month ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Regiane Rezende, Shaikh Rehan Abdur Rasheed and 3 others like this You, Regiane Rezende, Shaikh Rehan Abdur Rasheed and 3 others like this 24 comments Jump to most recent comments

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq Its more than a week,I haven't received a single reply from anyone. My question wasn't that hard
1 month ago Unlike Like

Reply privately Flag as inappropriate

Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist No, it wasn't, but there are a lot of ways the two could be compared. It wasn't clear which parts you wanted to hear about. Here's an attempt: The Client/Server stack, which you have called MMS, is primarily used on the station bus for what we would traditionally call SCADA or telecontrol purposes: monitoring measurements and status and controlling substation processes and switches with latency of a few seconds or perhaps tenths of seconds. Reliability is achieved through re-transmission if a failure occurs. It represents an attempt by a single server device to synchronize its database with that of a client. GOOSE may appear on either the station or process bus and is used for exchanging a limited amount of status and measurement information from each device with latency on a scale measured in a few milliseconds. It's primary use is for exchanging information for maintaining interlocking logic (that blocks unsafe controls) or for signals between relays to determine which relay will trip when a fault occurs. Reliability is achieved by always transmitting multiple copies. It is used when many devices must receive a copy of the same information, because the messages are multi-cast. Or put another way, Client/Server is for sending lots of data but not too fast, between two specific devices, while GOOSE sends a small amount data very quickly, between one device and any number of devices that want to listen to it. Is this what you were looking for?
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GeoffUnfollow Follow Geoff Geoff Garber I am no expert on the engine under IEC 61850, but I understand and use it this way. MMS is the basic protocol under 61850. This provides the SCADA basics of analog and digital input and output.One host (client) polls one of more hosts (servers) for data. The client can also send a digital output to one or more servers for SCADA control. This is not that much different in function than DNP-LAN or OPC protocols. GOOSE is an extension to MMS and allows a host to send (publish) a very fast and reliable signal over the network that is received (subscribed) by one or more other hosts on the network. IEC 61850-compliant Network devices like switches and routers, give priority to GOOSE messages over ordinary network traffic. Unlike the MMS digital output above, the GOOSE message is fast and reliable enough for protection. Old protection engineers like myself are sometimes a bit afraid of applying this to protection, but with suitable redundancy and backup, this can be very effective.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq Thank you Mr. Grant and Mr. Goeff for your comments. i was looking for those answers, just want to confirm that the trip commands issued from the station level devices to the lower end bay level devices must be transferred through GOOSE.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Hi Muhammad, That's true, but be careful about the wording. GOOSE messages don't send "commands", they send state changes that other devices may or may not act upon. For instance a device doesn't say, "I want you to trip" because it doesn't know who "you" is - any number of devices may be listening to the GOOSE message. Instead, the device may say, "I am blocked and will not trip" or "I have started but I have not yet tripped". This may cause other devices to decide to trip, but the decision is theirs alone; they are not "commanded" to trip.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq So there is a publisher who continuously publishes messages which indicates a particular state, and now its on the subscriber to respond to those publications at a time which he thinks is appropriate.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Exactly.


1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq Thanks a lot Sir
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Glad to help.


1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SimphiweUnfollow Follow Simphiwe

Simphiwe Ngwenya Couldn't have said it better than you did Grant. GOOSE doesn't issue operating commands but status changes only. Well said Grant, thanks
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JoshUnfollow Follow Josh Josh Khani "Old protection engineers like myself are sometimes a bit afraid of applying this to protection, but with suitable redundancy and backup, this can be very effective. " - Grant I find this very promising. As a student studying 61850 (as a protocol and for substation applications) one of the things people tell me is "dont forget about DNP3 because, in the US, 61850 adoption is questionable." However outside of the US, 61850 adoption is widespread. Is this strictly because the US power industry is skeptical about major changes to the protection paradigm like Grant was? Or do we know something about the limitations of 61850 that the rest of the world hasn't discovered yet?
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Shaikh RehanUnfollow Follow Shaikh Rehan Shaikh Rehan Abdur Rasheed Very good Ashar...Keep it up....
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Hi Josh, You were quoting Geoff, not me. I could never claim to be a protection engineer; I'm a SCADA and data communications guy. However, I do agree with his comments about IEC 61850 and protection. There has been at least one test that showed GOOSE is at least as fast as hardwired connections, because the Ethernet message doesn't need to be debounced.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist To answer your question, Josh, I would say it's not GOOSE and protection skepticism that is the problem. Instead, I think there are several factors affecting the adoption of IEC 61850 in North America: 1. In general, North American utilities pick and choose and mix and match between vendors and technologies in their automation networks, while European utilities tend to have more singlevendor substations. So IEC 61850 is easier to deploy in these cases because there is only one vendors' equipment to interoperate with. 2. Europeans, with their diverse cultures and history, have learned the value of standards. Therefore, when a new IEC standard is available for application, it is used immediately because there is a standing policy of using such standards. In North America, it's not enough that there is a standard; it must be proven to each utility that there is benefit to using it.

3. Many North American utilities previously had significant research and development departments for evaluating and piloting technologies like IEC 61850. However, cutbacks and deregulation have decimated these groups, making it difficult for utilities to take large revolutionary jumps. Instead, they have to make small, evolutionary steps. 4. I believe the NERC CIP security standards have discouraged utilities from deploying "routable protocols" like IEC 61850 in North America because they require widespread deployment of security training and equipment wherever such protocols are implemented. This not only delays the adoption of IEC 61850, but also other networking technologies like DNP3 or Modbus over TCP/IP.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RajUnfollow Follow Raj Raj Dyal, P.Eng Agree with Grant 100% Since most utilities in North America use multi-vendor solutions, IEC61850 will require extensive testing and most utilities do not have the manpower or budgets to accomplish this.
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq So is there a 'question mark' about the adoption of this standard worldwide...

7 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz There is no question mark. IEC 61850 is the future of power system communications world-wide. The fact that US utilities are behind in adoption will not stop adoption in all the countries that are using it in all new substations. You also have to keep in mind that utilities in the USA are subject to political regulation by the states. How they are allowed to make a profit and the level of profit that is allowed is tightly controlled by public service commissions that are typically appointed by elected politicians. This creates perverse incentives as it relates to reducing costs and contributes to the challenge of adapting new technologies aggressively. There is one very large utility in the USA where every single high-voltage substation is IEC 61850 and is multi-vendor. They have been doing that for almost 10 years now. They did not increase their budgets to accomplish this. They implemented a planned modernization program faster than any other approach. Outside of the USA and Europe there are many hundreds (if not thousands) of multi-vendor substations using IEC 61850. The early trend in Europe was single vendor substations because of the way that many European utilities procure substations (a single contract to a single vendor). But consider: Why did IEC 61850 become the dominant technology in Europe when the utiities did not have a formal requirement to use IEC 61850 at that time? a) IEC 61850 costs more to use and allowed the vendor to raise their prices? b) IEC 61850 costs less to use and allowed the vendor to increase their profit? Whether you are a utility interested in being able to increase the level of automation or implement better automation in more substations (or both) or whether you are a turnkey provider of substations interested in maintaining your profit levels while providing competitive prices and delivering better solutions IEC 61850 serves that purpose. That is because IEC 61850 is not just another way to organize the bytes on a wire used for communications between 2 devices. It is a new way to design, commission, test, and maintain power system automation that provides improvements in productivity and performance compared to other approaches. The IEC 61850 protocols serve that purpose, but the bytes on the wire are not the most important aspect of IEC

61850. IMHO, there is value in the IEC 61850 protocol that makes it superior to other protocols (self description/discovery, named/sructure objects, etc.). But, if all you look at is how the bytes on the wire are organized in IEC 61850 compared to other protocols then you will not see most of the value.
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Muhammad AsharUnfollow Follow Muhammad Ashar Muhammad Ashar Tariq So, IEC 61850 brings all new aspects to substation automation,the thing is utilities have to encourage themselves to look at the benefits that it provides, and should seek its implementation in the newer substations.
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Unfortunately some (I suspect a large number in US) still just call IEC 61850 "another protocol" - a "DNP4" - so the response is obviously that "I have invested so much training in DNP3, why should I change?" (I've invested so much in Word 2003, why change to Word 2007 or Word 2010 - all I want to do is type an email) For most the change would seem to be virtually pointless (pardon the pun). But as I jokingly say, DNP really stands for "Does No Protection" [sorry to my friend Andrew West :) ]

IEC 61850 is not a "mere protocol". This is the point that Ralph is making about bits on the wire. Yes it changes the physical implementation of a substation secondary system from tens of thousands of individual wires per sub to a fibre network so we save on the cost of copper in the substation. But how is that achieved from an engineering perspective? We could use "mere protocols" where every system could call the same signal a different name and have it going between differently named objects and functions. Chaos. What IEC 61850 brings to the IED is a structured naming of all the pieces of information and parameters of the functions. It then establishes standard communication process requirements. A protection function operation being interpreted by a CB function to trip is the same today as it will be in 20 years from now. or for that matter is the same in Bay 1 as it is in Bay 2, 3, 4..... We now have REUSABLE ENGINEERING regardless of whose device is at either end of the signal. Yes, greenfield subs is a no-brainer. You have a clean worksheet. However since we have to replace old secondary systems every 15-20 years now, your biggest engineering workload is the brownfield refurbishments/augmentations. A utility with say 100 substations must be replacing at least an average of 5-7 complete secondary systems per year assuming they were built at a reasonably consistent rate. I would dare suggest that most utilities are averaging perhaps a couple complete refits per year. Distribution utilities have perhaps 300500 substations so you do the maths. So can you afford or even have the resources to triple or quadruple your engineering effort? Not forgetting that in 10-15 years the new substation you build today is also part of that refurbishment requirement (a graduate working on a new sub today will see the 4th complete secondary system replacement by the time he retires). Not forgetting that as renewables all want to come onto the grid we have further partial augmentation expansion of the substation for new connection points Furthermore, about 20 years ago 11kV substations had about 5 SCADA I/O points per bay. By 2005, this had increased to around 30 points per bay with "moderate" degrees of IED capability. The IEDs are getting more and more comprehensive, more functions and information ..... we could be now looking at perhaps 50-100 points per bay and each one has to be individually named, mapped and confirmed .... And not to forget more complex protection, synchrophasors, condition monitoring...
6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes So the other part of IEC 6180 - the most significant part - is that it provides the engineering process and files for the head office engineering. How the design evolves from a single line diagram through to the complete system functionality and communication then down to individual device configuration. This is where most significantly IEC 61850 is "not a mere protocol". I dare suggest that here again we are our own worst enemy - if we continue to think in terms of having to configure individual boxes which we then magically connect together we are always left with piecemeal engineering. Engineering of a system from which the configuration of the individual IEDs is an outcome is a totally different mode of thinking - it is first and foremost a system. IEC 61850 is about a complete paradigm shift in thinking and process. Most managers tend to worry about the here and now with things they understand. The old saying "it is hard to remember the objective was to drain the swamp when you are up to your neck in alligators". We have to first STOP FEEDING THE ALLIGATORS!! The amazing thing is that so many baulk at the idea of all this new learning, new skills, new tools, new processes .... but the reality of those that have made the change is that they are saving 10-20% of the cost of the complete substation, not just the secondary system.

Master 61850: developing in the right way


The problem is simple: I want to read information from a protection. The protocol is 61850. I have a c++ compiler, a lot of time,and a good team: I want to implement the protocol from scratch. How? Wich docoments I have to trust on? Is there a guideline or something similar? The question is simple, but the answer may not, since I have already developed a version of the protocol with reverse engeneering (wireshark and some Master/Slave communication): this is not the right way (even if it works fine). I have all the INTERNATIONAL STANDARD IEC 61850-X-Y, but there are a lot of generic or optional specification, a great number of hi level description, but no real word / usefull specification on how to implement it. Maybe I have not found them, or maybe there are some other documents. Someone can send me a link or a title of a book or some other suggestion? Thanks.

15 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

17 comments

Vinoo SUnfollow Follow Vinoo S Vinoo S Warrier The full 61850 stack for client-server communications (reading protection info from a relay onto a PC client, for example) is 61850/MMS/TCP/IP/Ethernet. You can assume TCP\IP\Ethernet is supported on any PC platform. So the bottom layer of your own implementation is a socket call (well, not entirely that simple, but will do for illustration). You will need to implement a significant subset of the MMS protocol and then the 61850 layer over it. In 61850 you can focus on the ACSI (7-2), LNs (7-4) and CDCs (7-3). You will also need the SCSMs (8-1 for station bus comms). You can add the set of MMS standards to your documents list. Good Luck. The easy way out is to buy a source code library that already implements the entire 61850/MMS stack (like the SISCO product) and you can get your 61850 client running in 1 day.
14 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima No, 61850/MMS/TCP/IP/Ethernet is not the full stack. For example the first message sent is mandatory and is not an mms: < a href="https://docs.google.com/open?id=0BwAT-dUnSsCVVDVyaGRJYk1qeUU">link First Message</a> And the second message is an MMS but the documentation (61850-8-1) in not clear / complete on it. As you can see there are 5 (five) protocols underlying. < a href="https://docs.google.com/open?id=0BwAT-dUnSsCVYjRKcktpeVpOOVE">link Second Message</a> I already have a working solution, but is based on my intuition and there are a lot of bits that by now don't make sense. I have seen 4 masters in action and each one, after the first 2 messages, continued the communication in its own way. Each Master trys to receive a list and transforms that list in a tree. At the end waits that the slave sends a tree of information. Is there a right sequence of messages? Is there a better or a worse sequence? Where is documented how the mms are fragmented (not TCP /IP fragmentation)? In this example: < a href="https://docs.google.com/open?id=0BwAT-dUnSsCVM1U2NnY1RzNraWM">link Read Message</a> I have to do a confirmed service request : read. OK. Which document tells me that: * I have to set a progressive invoke ID * I have to implement suck tree * Which kind of response I have to wait for? What meaning will have? I need answer to question like that. (A library is not an option)
14 days ago Unlike Like

Reply privately Flag as inappropriate

Flag as promotion

TomUnfollow Follow Tom Tom Berry @Fabio: I'm impressed with your attempt to reverse engineer a protocol specification from Wireshark messages, but be careful that your code also handles error conditions correctly. Search for "mms manufacturing message specification" or ISO 9506 on google.com and you will find lots more information.
14 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KstutisUnfollow Follow Kstutis Kstutis Motkaitis maybe this link could help: http://nettedautomation.com/iec61850li/index.html
14 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima Thanks a lot: I have found ISO 9506 documentation in nettedautomation site. I will read those files asap.
14 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KstutisUnfollow Follow Kstutis Kstutis Motkaitis You say you want to rebuild 61850 from sratch. Do you want to make your own 61850 programmable chip or what ? :)
14 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima No: I have a multi-protocol gateway on a windows embedded system and some customer ask for 61850. I have developed a version of the protocol, and it works quite good. Really I will not restart from scratch, its only to explain better: I need to understand the protocol because now I have some communication frame that I send without knowing the exact meaning. The initialization frame is one of those frames, for example. The main problem is that each protection works in his own way. Sometimes the reports are painfull to subscribe and sometimes I can't subscribe them. Sometimes only 2 master can connect to the protection. Some protection, if I open a connection two times with the same socket, put my

ip in a black list. And many other issues: by now I have a workaround for each one, but this is not the right way to develop and in the future may be I cannot find a workaround. I need to know "where" I am wrong, and "if" I am wrong (in some case I suspect some protection fault).
13 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KstutisUnfollow Follow Kstutis Kstutis Motkaitis Once i was trying to implement hybrid protocol communication via OPC, but I didnt finished that. Idea is to try out relab(r) OPC server. It maps 61850 to OPC. Then map your other protocol to OPC. ANd make a client that reads data from one OPC and writes data to other OPC and vice versa( but I don't know about lag in such protocol via OPC communication ). (Once I wanted to make modbus and 61850 communication via OPC, but they say its better to have hardware communication(binary outputs from modbus goes to inputs of 61850) if you want to make interlocking or braker control in hybrid system... )
13 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KstutisUnfollow Follow Kstutis Kstutis Motkaitis By the way Relab OPC is using MMS ;)
13 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hi Fabio You have an interesting challenge. Reading, reading, reading is a tough way to gain knowledge - as you've no doubt found in just reading the 1500+ pages of the Standard, cover-to-cover and understanding how all the bits hang together. BTW - make sure you are using the Ed2 Parts where these have replaced the Ed1 Parts. Certainly one issue is the Stack. The link Kestutis supplied is to the Beck Chip supplied by SystemCorp http://www.systemcorp.com.au/ . There are a couple of other stacks such as Triangle Micro Works and SISCO as code or library very widely used by many of the major IED vendors. You will a few others around no doubt. (Hint: if the major vendors with all their experience from being involved in the development of the Standard since 1992 use procured stacks .....) But the stack is only part of it - the real trick is developing the combination of a good data model with the right LNs, with the right combination of Mandatory and Optional Data Objects with the right limitations/conventions with the right ACSI services with the right IED Configurator Tool capabilities that will make the Systems Integrator's job much easier that will make your product more (or less) attractive .... and don't forget we are talking about a Substation Automation System - or a Utility Automation System now as the applications expand outside the fence - where reliability is PARAMOUNT * having good well TRAINED expertise is ESSENTIAL. If an IED is the cause of a blackout due to poor implementation (I hope the 700 miliion people blackout in India isn't that ...), the utility - and hence your boss - won't be all that impressed if the reason is "no-one on LinkedIn told me about that..." LinkedIn can help here or there but it is no replacement for true expertise. There are courses around and there are IED implementation consultants that will put you in a much better position to produce a good result. Oh, and don't feel embarrassed in seeking training - a few of the major vendors are now back tracking to get such training and outside help despite having been directly involved in WG10 since 1992 but have now realised that their "home grown" expertise may have got it a little, or a lot ...., wrong. Remember KEMA certification is tens of thousands of Euros each time you go for approval - some go through that a couple/few times but despite all that, the ENSTO-E and VLGPO statements on IEC 61850 implementations is a wake up call to the industry that even

after 8 years of existence of the Standard (20 since development started) even the major long time vendors WITH KEMA Certificates haven't got it totally right (e.g. see TISSUE 864 under Part 10) from the User's perspective - they are the REAL JUDGES OF QUALITY PRODUCTS.
13 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

TomislavUnfollow Follow Tomislav Tomislav Pua For full understanding of IEC 61850 you should first get your hands on following ISO standards: RFC 1006 ISO Transport Service on top of the TCP (TPKT) ITU-T-REC X.681, X.682, X.683 and X.690 Abstract Syntax Notation One (ASN.1) ITU-T-REC X.224 ISO 8073 COTP (Connection Oriented Transport Protocol) ITU-T-REC X.225 ISO 8327-1 (OSI Session Protocol) ITU-T-REC X.215 ISO 8326 ITU-T-REC X.227 ISO 8650-1 (OSI Association Control Service) ITU-T-REC X.226 ISO 8823 (OSI Presentation Protocol) ISO 9506-1, ISO 9506-2 MMS protocol Last year, I implemented IEC 61850 Server for one of our alarm annunciators . That was my first encounter with IEC 61850 and I had similar questions. I used Triangle MicroWorks 61850 Test Suite (21-day free evaluation IEC 61850 Server & Client) and Wireshark for protocol analyzing and testing . I had a lot of problems because I didn't have complete documentation. For last six months I'm working on portable IEC 61850 Server API. It is quite possible that KEMA certification will be mandatory in the near future, so I read all related standards and started from scratch (again). You can find almost everything you need in ISO standards mentioned above.
13 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima @rodney: tranks for the suggestions. I have tried some lesson, but they told me that 61850 is XML based... Simply is not. By the way in my master there is no need of XML configuration ( I can ear the bad comments of the standard maker. I know! But my master works better without icd / scl / XML ). The certification for me is useless: if the slave I have deal with requires that I make some non standard call, for me is mandatory to follow the slave and not the standard. @tomislav: thanks! I am not alone! I have quite all the standards: now I have found the 9506. For sure I will try the triangle micro works software. Kema can not be mandatory: how they can? For me is also too expensive.
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Fabio - sounds like you are convincing yourself to leave the 61850 group?? I hope we can convince you of the benefits of really getting on board. You are right of course - IEC 61850 is not a software of the IED - it is the definition of the configuration and parameterisation and outputs of the software elements within the device. In fact the SCL files as XML based are in NO WAY specified to be loaded into the IEDs since the Standard dictates the role of the IED Configurator tool as the last step in the defined IEC 61850 process - what that tool creates to load into the IED is a vendor specific choice.- of course if the developers are clever enough, then it is conceivable that they do load the CID directly to the relay but that is a vendor choice.

The SCL files are purely for transferring the system specification/configuration of the entire system from one PC to another through out the engineering phase (where so much time and money is wasted in conventional wire-engineering)- hence they have to be XML in order to be readable by every other tool. Further there is no specific algorithm associated with a PTOC for example. However all the inputs and all the outputs and all the commands and all the data associated with that algorithm is defined. IE C61850 doesn't care whether you program in C++, basic, fortran, java ... nor does it care if it is an analog threshold detector using one amplifier and a couple of diodes or a sophisticated algorithm using a Fourier transform with a third derivative of the Gaussian followed by a Laplace transform... All that is your developer expertise which is still needed. If you only look at 61850 from the perspective of how you develop your own product, you will never appreciate what benefits the SCL files structured using XML does - these are what leads to saving 20% - yes twenty - of the total cost of a substation - not just the cost of the relays, but the entire substation!! Again, certification only makes sense if you hope that your product will be used by others in their systems - it doesn't guarantee that whatever you have done is necessarily a good application as a product with the right features but it does give the user a high degree of confidence that the supporting detailed information of what you have implemented will allow the user to select IEDs that will owrk together in real time and that the SCL engineering process will save a huge amount of effort. What ever training you have had is obviously a jaundiced view of the Standard - possibly by a less than well informed staff of a vendor?? There are a few of us who run truly vendor-independant training on how IEC 61850 is used from an application point of view and secondly how it is implemented. I would strongly recommend you attend them in that order.
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

HerbUnfollow Follow Herb

Herb Falk Fabio, there are other suppliers of 61850 source code besides Triangle, if you want to talk.
10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh Dear Fabio, I could see two reasons to develop the product in-house: 1. Cost of the IEC 61850 stack source code 2. Interest: You have interest in such developments and 3rd one which actually prompted us to develop our own stack was to show / demonstrate technical superiority and demonstrate domain expertise / leadership. If the cost is the only matter then we can help you with the required cost effective IEC61850 Stacks. Since you are developing for your gateways (as we did the same), the problem will come when you start interfacing with more and more SCADA / IEDs, as then you need complete / full understanding of the Protocol along with the understanding of the SCADA / IED manufacturers implementation. And the story doesnt end here, now you want to be Client and then the future requirement shall be to become Server, and it will go on and on, a dedicated team for IEC 61850 shall be required with development as well as Protection / SCADA engineers. We have developed solution where we can create ICD file from simple XLS file to Mapping and data definitions. So XML interfacing is required for IEC 61850 concept of easy integration where only the SCL file, CID files etc. from customer will be enough for you to configure your gateway.
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DanieleUnfollow Follow Daniele Daniele Pala openIEC61850 is still in early development, but it's LGPL licensed, you can download the source code and study it: http://www.openmuc.org/index.php?id=24
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DavidUnfollow Follow David David Ingram Fabio, when it comes to getting joint ITU/ISO standards, go to ITU to get them (I did for the ASN.1 standards) since ITU have free downloads.

Implementation of UFLS over 61850 for Distribution Automation


Consider the following scenario where a UFLS (under frequency load shedding) application is being considered, and where a UFLS controller residing inside the 61850 transmission station bus LAN needs to send TRIP signals to distribution level UFLS/61850 controllers on downstream feeders outside of the fence, somewhere in the field. Since UFLS signaling is going over GOOSE, a Layer 2 pipe is being opened from the substation ESP down to the field. And I can see you all security peeps now saying "oh no you didn't!!" Now you can put Layer 2 MAC/VLAN access lists on the switch or in a firewall for some levels of L2 security. However this isn't robust for sure. My question though would be in such a scenario, how can we define the NERC-CIP Electronic Security Perimeter at Layer 2 and what would be the minimum cybersecurity requirements one should implement?

This may be a question for the NERC-CIP folks but the reason I'm asking it here is to see if someone else has ran into such a situation.
6 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

2 comments

TomUnfollow Follow Tom Tom Berry Not an answer but I'm interested in the application. How far away is the "outside of the fence, somewhere in the field"? Does it have a dedicated optical fibre link? Do you want to use GOOSE because there is a tight timing constraint or just to avoid conversion into higher level protocols? I've worked on distribution automation projects that use conventional SCADA comms over radio or GPRS between substations and slave RTUs in the field. In these cases communication delays of a few seconds were acceptable.
5 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

EdgardUnfollow Follow Edgard Edgard Sammour Hi Tom - the location could be several Kilometers away with communication from the substation to the field being over an RF network. And the reason GOOSE is on the table is due to UFLS being part of an overall protection coordination scheme that has very tight latency requirements.

SBO control with enhanced security (Oper struct behavior)


Supose a client sends the SBOw struct with the desired values (ctlVal, origin, so on...). Then it sends the Oper struct and for some reason (e.g. the SBOw values do not match the Oper values or the control simply does not run). My question: should the server keep the last Oper values (struct) sent by the client (which did not work) or should retrieve the Oper values of the last successful control? In fact, this question applies for any control, but SBO is a good example. I could not find any mention about it in the standard documents and I would appreciate any help. Thank you Vitor Hugo
11 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

2 comments

Vinoo SUnfollow Follow Vinoo S Vinoo S Warrier You should simply act as if the control command was not received. Whatever the state of your Oper was (before receiving the SBOw and the non-matching Oper) should be retained as-is.
8 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz The values that a device reads from an Oper or SBOw or Cancel structure are without meaning. The only meaning for that data are the values that are written to the server by a client. The fact that someone had previously commanded a circuit breaker to open is not useful. Only the current position is useful because the position may have changed a hundred times since the last time the Oper structure was written. If you want to know the position of a breaker, you read stVal of the Pos attribute. If you want to know if the device is selected you read the stSeld attribute. If you want to know who selected it, you read the origin.orIdent attribute. Some devices will remember the values written to them but there is no requirement for the device to behave this way. There is no formal conformance test for reading these structures although most devices allow the data to be read. I should add it is very handy for the device to allow a read because it allows clients to treat that data no different from any other data found in the device.
15 hours ago Unlike Like

Reply privately Flag as inappropriate

I am communicating with MiCOM P139 Relay.When I use short length(2 meter) cable then It communicates but when I use long length cable (10 -15 meter) then communication breaks.Can any one sort it out?
12 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

7 comments

GherlanUnfollow Follow Gherlan Gherlan Cristian What tipe of cable? UTP or serial?
12 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FabioUnfollow Follow Fabio Fabio Bima In my experience is not a matter of length. In most case if the cable is hand made can be half working, even if recognized as working by a pc card . If you try a continuous ping, it

works only in 50% of packets. But may be this is not the case...
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GeoffUnfollow Follow Geoff Geoff Garber I would agree that the cable is the problem, though it could be a cable selection issue, rather than a faulty cable. The obvious test is to try another cable. Is this a factory-made or field-made cable? Ensure the continuity of each wire and make sure that it makes good connection with each pin or wire in the connector. Is this serial? RS-232 has a 15m limit. I've stretched this limit by a couple of meters occasionally, but at this length you may need to reduce baud rate. Is the cable shielded? You might be in a noisy environment. If using shielded cable, be sure the shielded is grounded (earthed) only at one end. This may be difficult with factory-made cables with metal connector shells. You might need an opto-isolator at one end. If all else fails, you might need to switch to balanced RS-485. Is this Ethernet? You are far under the length limit for 100BaseT. Still, in a noisy environment, you might need to use shielded cable. Again, ground the shield at one end only.
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Shaikh RehanUnfollow Follow Shaikh Rehan

Shaikh Rehan Abdur Rasheed Thank you all for the comments..I am actually using Schneider CAT 6 (UTP) straight cable with MiCOM relays, therefore the medium is Ethernet.. Yes my cable is hand made & I punch the RJ45 connectors myself but when I tested it with cable tester it showed proper continuity.Secondly when I use the the same long length cable between two laptops then cable works properly but when I use it between laptop & relay then sometimes ping works sometime not (request timed out)..
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FlipUnfollow Follow Flip Flip Helberg Confirm your cable is made to the correct IEC standard. Sometimes people make a straight trough cable, which works on short distances. But the correct pins are pin 5 and 6 and pin 4 and 8 are pairs also one on one.
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

FlipUnfollow Follow Flip Flip Helberg Actually pin 4 and 7 not 4 and 8.
10 days ago Unlike Like

Reply privately Flag as inappropriate

Flag as promotion

DavidUnfollow Follow David David Ingram The Wikipedia page shows the two common standards (of course there is more than one!) at http://en.wikipedia.org/wiki/Category_5_cable In Australia & New Zealand the TIA-568A is the most commonly used. If you are building your own cables then I'd stick to Cat5e (fewer twists, easier to get into the connector), and use a cable tester that looks at near and far end crosstalk. Cat5 and Cat6 RJ45 connectors are different too. This page shows the difference: http://www.accesscomms.com.au/reference/cat5&6plugcomparison.htm Basically, if the cores are all in a row, it is a Cat5 connector, and if there are two rows it is a Cat6 connector.

Can anyone provide me the ICD files for Alstom P442,P543 & P746 relays with the part numbers; a) P543216C7M0710M b) P74621BJ6M0030K c) P442216B7M0550K
14 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

1 comment

DavidUnfollow Follow David David Ingram Download S1-Studio by filling out the form at the from the Alstom website (http://www.alstom.com/grid/products-and-services/Substation-automation-system/protectionrelays/S1-Agile/), and once it is installed download the data models for the P442, P543 and P746. You can then copy the ICD files out from the S1 Studio directory. If you don't have any luck with Alstom, try the Schneider version (http://bit.ly/QFU11B) which can be downloaded directly.
8 days ago Unlike Like

Reply privately Flag as inappropriate

What would be your best approach if you are to implement IEC 61850 in a transmission grid, the existing protection system is a mixture of old mech relays, to advanced digital relays 61850 capable?
1 month ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

3 comments

GerbrandUnfollow Follow Gerbrand Gerbrand Ronsmans My first question would be why? Not that you shouldn't, but in finding out why gives you an answer on how to proceed. Is IEC61850 already available in the substation and you are planning for upgrading the protection or is it the introduction of IEC61850 on both protection and control. Finding out why leads to question what? What should the system do. If it is the purpose of getting alarms to the NCC you may want to install some kind of PLC based RTU solutions. On the contrary for upgrading the protection you'll need to select a vendor and work out typical solution. There is no real answer as to "the best approach". It comes as much to the people implementing the system as to planning the whole change over. Things can't be done over night so the challenge will be two master the steps and have concurrent systems running. You may want to google this topic, there some white-papers and other publications regarding this topic on the net.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hello Abbas Gerbrand is right - you need to start with what you want to achieve, that leads to requirements and that leads to solutions.. I'm not clear on what you mean by "implementation of IEC 61850 in a transmission grid" It is a progressive thing throughout the grid as you build new substations and refurbish/augment/replace equipment in existing substations However, the starting point is to get a proper understanding of the technology. Perhaps pushing my own barrow here, but just remember that vendor trainings often are focused on one criteria selling THEIR boxes. IEC 61850 is fundamentally about engineering processes and most importantly Reusable Engineering - this is THE objective for utilities..
3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Juan EstebanUnfollow Follow Juan Esteban Juan Esteban Hoyos I agree with Rodney and Gerbrand. Engineering, engineering, engineering that is our passion, find the best solution including economical and technical aspect maximizing the profits of the company.... some times, as Rodney said the manufacturer just want a sell you boxes. However if you have clear your goals, in the short and log term, you can design progressive upgrades, full upgrades or just stay with the actual technology because you don't need any upgrade in your substation. If what you are looking for is implement a wide area protection system using IEC 61850 there is a thread that Julian Eduardo Malcon began some weeks ago and could give you some answers.
1 day ago Unlike Like

Reply privately Flag as inappropriate

What would be your best approach if you are to implement IEC 61850 in a transmission grid, the existing protection system is a mixture of old mech relays, to advanced digital relays 61850 capable?
1 month ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

4 comments

GerbrandUnfollow Follow Gerbrand Gerbrand Ronsmans My first question would be why? Not that you shouldn't, but in finding out why gives you an answer on how to proceed. Is IEC61850 already available in the substation and you are planning for upgrading the protection or is it the introduction of IEC61850 on both protection and control. Finding out why leads to question what? What should the system do. If it is the purpose of getting alarms to the NCC you may want to install some kind of PLC based RTU solutions. On the contrary for upgrading the protection you'll need to select a vendor and work out typical solution. There is no real answer as to "the best approach". It comes as much to the people implementing the system as to planning the whole change over. Things can't be done over night so the challenge will be two master the steps and have concurrent systems running. You may want to google this topic, there some white-papers and other publications regarding this topic on the net.
1 month ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hello Abbas Gerbrand is right - you need to start with what you want to achieve, that leads to requirements and that leads to solutions.. I'm not clear on what you mean by "implementation of IEC 61850 in a transmission grid" It is a progressive thing throughout the grid as you build new substations and refurbish/augment/replace equipment in existing substations

However, the starting point is to get a proper understanding of the technology. Perhaps pushing my own barrow here, but just remember that vendor trainings often are focused on one criteria selling THEIR boxes. IEC 61850 is fundamentally about engineering processes and most importantly Reusable Engineering - this is THE objective for utilities..
11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Juan EstebanUnfollow Follow Juan Esteban Juan Esteban Hoyos I agree with Rodney and Gerbrand. Engineering, engineering, engineering that is our passion, find the best solution including economical and technical aspect maximizing the profits of the company.... some times, as Rodney said the manufacturer just want a sell you boxes. However if you have clear your goals, in the short and log term, you can design progressive upgrades, full upgrades or just stay with the actual technology because you don't need any upgrade in your substation. If what you are looking for is implement a wide area protection system using IEC 61850 there is a thread that Julian Eduardo Malcon began some weeks ago and could give you some answers.
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrgoryUnfollow Follow Grgory

Grgory Huon I agree with what is written above. System engineering is the key, but to me, we still need two important improvements: 1. An IEC61850 standard that suits with the transmission utilities needs (there are today too much domains covered by the standard; the amount of options makes it too much flexible and too little interoperable). 2. We need performant tools that make system engineering efficient (and not only effective) in a multivendor environment. I would like to refer to the ENTSO-E and VLPGO statements that emphasize the gap between the TSOs needs and the IEC61850 standard and its product & tools implementation of today. Based on these statements, our reference as TSOs, an ENTSO-E Task Force is dealing with these issues, together with WG10 of IEC and the other stakeholders (Cigr, IEEE, ...). To succed in this adventure, each player of the "market" has to contribute actively. I think the suppliers have surely an important role to play and they should be more active, accepting that multivendor systems is at a moment of at an other of the substation lifetime, an unavoidable situation for the users that we are. Indepedent tools are also welcome but not yet mature. The 100% interoperabliity that classical copper wiring offers should be THE target to reach by the IEC61850 standard and its product implementation, on the whole lifecycle of the substation. Only at that moment, we will be in state to fully benefit of the real added value of the standard at the level of engineering, commissioning, extensions, outages limitation, ... ENTSO-E statement: https://www.entsoe.eu/news/announcements/newssingleview/article/entsoe-statement-on-the-iec61850standard/?tx_ttnews%5BbackPid%5D=28&cHash=88772c059caa4ce488d12dd80d7ca41d VLPGO statement: http://www.vlpgo.org/news-events (see news of May 2012)
2 days ago Unlike Like

Reply privately Flag as inappropriate

ENTSO-E statement on the IEC61850 standard


Brussels, 2012-04-13 ENTSO-E calls for all IEC61850 stakeholders to take the appropriate actions in order to ensure the success of IEC61850 and to make sure the standard and the technologies developed around it remain sustainable and provide significant benefits for all stakeholders and the community.

This statement addresses the main stakeholders involved in the development and product implementation of the IEC61850 standard on communication networks and systems for power utility automation: secondary systems suppliers, International Electrotechnical Commission (IEC TC57, WG10 and others), conformance testing companies, third-party tool developers. This standard is of potentially large benefit to electricity transmission system operators (TSOs) as it addresses across different vendors many crucial aspects of TSO communications, with the promise of seamless interoperability of different vendors subsystems within

the overall TSO system management architecture. As the single association representing 41 TSOs from 34 European countries, ENTSO-E makes the following observations and recommendations regarding the development of this important worldwide standard.

http://www.vlpgo.org/news-events

V.L.P.G.A. = Very Large Power Grid Operators Association News and Announcements

June 2012

ICER and VLPGO Commit to Greater Collaboration

On 26 June 2012, the International Confederation of Energy Regulators (ICER) and Very Large Power Grid Operators Association (VLPGO) signed a Memorandum of Understanding (MoU) signifying a joint commitment on the part of both organizations to share information and explore good practices relating to investment in power network project investment. The intention of both bodies is to disseminate good practices in order to assist in the creation of a climate where efficient and necessary investments in energy infrastructure can take place. The MoU was signed in London by ICER Chair Lord John Mogg and 2012 President of VLPGO Dominique Maillard.

The MoU represents an initial step in the development of a deeper dialogue between energy regulators and VLPGO on issues relating to investment in energy infrastructure. Interaction between ICER and VLPGO ICER and VLPGO will endeavour to cooperate in promoting the awareness of policy makers in governments and enhancing the understanding of energy regulation and its role for creating sound investment climates and managing cross-border interconnection between energy markets. To achieve this ICER and VLPGO will identify areas of cooperation that can enhance mutual understanding of issues of common concern and pursue joint initiatives. ICER and VLPGO will explore, share and promote best practice and innovative ways in energy regulation in order to reduce risks and foster investments in energy infrastructure and services. ICER and VLPGO are committed to the rapid preparation of a joint work plan which will identify concrete priority projects.
Read entire press release

May 2012

VLPGO Statement on the IEC61850 Standard


VLPGO calls for all IEC61850 stakeholders to take the appropriate actions in order to ensure the success of IEC61850 and to make sure the standard and the technologies developed around it remain sustainable and provide significant benefits for all stakeholders and the community. This statement addresses the main stakeholders involved in the development and product implementation of the IEC61850 standard on communication networks and systems for power utility automation: secondary systems suppliers, International

Electrotechnical Commission (IEC TC57, WG10 and others), conformance testing companies, third-party tool developers. The IEC61850 standard is of potentially large benefit to Power Grid Operators (PGOs) as it addresses across different vendors many crucial aspects of PGO communications, with the promise of seamless interoperability of different vendors subsystems within the overall PGO system management architecture. As the association of the 16 largest Power Grid Operators serving more than 70% of the electricity demand in the world and providing electricity to 3 billion consumers, the VLPGO members support the position of ENTSO-E and make the following observations and recommendations regarding the development of this important worldwide standard.
Read entire statement

VLPGO White Paper


Download the full version of VLPGOs White Paper Download the condensed statement

Leading the Transition to Grid of the 21st Century


At the VLPGO 2009AnnualMeeting, held recently in Washington D.C., the VLPGO Steering Board agreed on a set of common actions to be conducted in the context of agreed upon worldwide strategic themes for the power grids. These include:

enhanced security and system restoration practices; advanced power grid monitoring and control systems; integration of renewable energy sources into power grids; increased use of HVDC links in synchronous power systems; electricity storage including the integration of Plug -in Hybrid Electric Vehicles (PHEVs) into the power grid.

Electricity and the Consumer


Electricity is considered the most significant contribution to human progress in the last century because it allows any source of primary energy (wind, solar, biomass, hydro, fossil, nuclear, etc.) to be converted into a form that can be transmitted in an efficient way to end users. The role of electricity will continue to be one of crucial importance, but how it is generated and delivered will change rapidly over the next few decades. As energy efficiency and smart grid technologies are adopted, consumers will have more choices on how they use electricity, while the transport of electricity will be more secure.

Supplying the Worlds Electricity


Power grids, and the continuous development of their supporting infrastructure, play an essential role in promoting the social welfare of populations around the world. The reliable and safe supply of energy is the responsibility of the Power grid operators (PGOs). In this framework the main objective of grid operators is to ensure the needs of consumers are met ;and, the main mission of the PGOs is to maintain high standards for power supply quality and reliability at minimum costs. The PGOs work constantly to plan, monitor, supervise and control the energy they deliver as a continuous process 24 hours a day. In delivering the electricity that powers modern societies, the PGOs recognise their critical role, which includes:

acting on behalf of Consumers, to ensure quality while minimizing costs and recognizing economic and societal dependence on electricity; a technical role in planning, designing, and managing the Power Systems; an interface role with generators, marke t participants and distributors, which are the most direct users of the transmission grid; a natural role of interlocutors with power exchanges, regulators and governments.

Facing the Challenges of Smarter Energy


PGOs are continuously developing their operations to incorporate technical advances and societal concerns. Specifically, PGOs are increasing their ability to integrate smart grid technologies, facilitating alternative and renewable power generation technologies integration, in order to address the pressing environmental challenge of reducing greenhouse gas emissions, while delivering reliably energy to the consumers.

IEC61850 network with VLAN support-Layer2 Switch


How Layer2 Swtich handle multiple VLAN for IEC61850 network. Most of IED have support of multiple service like, IEC61850-MMS, Relay setting and parametrization, Goose. I want to segreate traffice using VLAN. My IEDs(have one RJ45 port for communiction) are connected on layer2 swtich. Let say example.. SCADA is connected on port1, PC with setting tool on Port2, and IED1-10 are connected on port 3-13. How Switch will handle multiple VLAN. Most of switch have support of Single PVID(port Vlan ID) for each port. for example VLAN1 for port1(SCADA), VLAN2(for Setting tool), VLAN3 (for goose message between IED). All this VLAN belngs to IED which have information. As i have notice that most of layer2 switch will allow to configure only one PVID per port.
11 days ago

Close viewer Like

Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

5 comments

EdgardUnfollow Follow Edgard Edgard Sammour Palak, Typical substation LAN configurations have just 2 VLANs, one for GOOSE and one for IP. GOOSE frames leaving the IED should already have their VLAN tag set, say VLAN 3. As for IP-based traffic (SCADA/HMI/Settings/Events etc...) it leaves the IED untagged so the receiving port on the switch will impose its PVID tag on it, say VLAN 2. Since you mentioned PVID I'm assuming you have something similar to a RuggedCom switch, as such: Switch Port Corresponding to SCADA Gateway : - Set port to edge - PVID = 2 and untagged Switch Port Corresponding to Settings PC: - Set port to edge - PVID = 2 and untagged Switch Port Corresponding to Settings PC: - Set port to Trunk - PVID = 2 and untagged - Make sure you enable VLAN 3 (and 2) in Static Vlans and ensure that it's not forbidden on all IED ports

I hope this helps Edgard

11 days ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

palakUnfollow Follow palak palak shah Edgard Yes the Switch is rugged com RS900. if my IED . in my basic setup , i configured port 6 with PVID 3 and IED connected to port6 only received goose message from port 1-5 connected IED. This setup will work fine. but in substation requirement i want to send/receive goose message between IED and same time segregate goose message from IP based traffic. lets say 1-5 connected to port1 -5 with VLAN3 tagged. All this IED subscribe and receive goose message. Port 1-5 is configured with PVID 2 with untagged so my gateway can see the MMS and other IP based traffice and gateway(SCADA) port is configured with PVID 2. So the question is that how the Ethernet switch will know/handle the VLAN 2, & 3.
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

EdgardUnfollow Follow Edgard Edgard Sammour Palak, Just to make things clearer, let's settle on the assumption that VLAN 2 = SCADA/IP, and VLAN 3 = GOOSE. Consider this scenario: IED1----------<port1>SWITCH<port5>----------IED5

Port 1 and 5 are configured as follows: * PVID = 2, Untagged * Type = Trunk * VLANs 2 & 3 are allowed on all ports Here's how the switch treats and separates GOOSE and IP/SCADA: SCADA: When IED1 sends an IP/SCADA frame towards the switch, since this frame is untagged, port1 of the switch then imposes the PVID of 2 on it. Once this frame is "inside" the switch it is then part of the bridging domain for VLAN 2. If port 5 is a member of that VLAN 2 domain (and for simplicity we assume that the switch doesn't know to which port the destination MAC address belongs) the switch then floods this frame out of port 5. Since this frame has a VLAN tag = PVID = 2 of port 5, and since the port it set to untagged PVID, it then strips off that VLAN 2 tag and sends the frame on the wire as untagged. IED 5 receives the untagged frame and assumes it to be SCADA/IP and process it as such. GOOSE: IED1 sends a GOOSE frame tagged with VLAN 3. Once it's received by port1 of the switch, since it already has a VLAN tag on it, it simply just accepts it into the switch while maintaining its original VLAN, regardless of what the PVID is set to. While "inside" the switch, this GOOSE frame is now part of the Vlan 3 bridging domain. If port5 is part of that domain as well, the switch will then forward the GOOSE frame out of that port. Since this frame has a VLAN 3 which is different than the PVID of 2, it then sends the frame on the wire towards IED5 with its original VLAN 3 tag. IED5 receives this frame with VLAN 3 and treats it internally as a GOOSE frame. Inside the switch, VLANs 2 and 3 belong to two distinct/separate bridging domains, and are thus logically segregated. Edgard
9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MarioUnfollow Follow Mario

Mario Lpez Edgar, what happens if the port is configured PVID=2, tagged? If put a service of SNTP, how you will configured the ports?
7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

EdgardUnfollow Follow Edgard Edgard Sammour Mario - if the port is PVID2 + tagged then: 1- Ingress traffic into the switch port: gets treated just like PVID 2 untagged explained above 2- Egress traffic leaving port: frames with VLAN tag of 2 leaving that port will maintain the VLAN tag (it won't be stripped). This is similar to trunking that VLAN. However the end device will need to have 802.1Q enabled in order to accept that frame and strip off the tag before passing it on to the CPU. SNTP is based on IP so treat it like SCADA.

Hi.I am using modbus protocol. I use USB cable for physical layer. but some PC we are transmit and receive perfectly working. But Some PC get Time out error for some times. What is Problem. help me
5 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Muhammad Ashar Tariq likes this You, Muhammad Ashar Tariq like this 6 comments

RichardUnfollow Follow Richard Richard Warsza What type of ModBus are you using ModBus RTU or ModBus ASCII? ModBus RTU uses hexadecimal data and is time critical whereas ModBus ASCII uses ASCII data and is not time criticial. Depending on how many devices are connected to the USB interface there might be time slicing issues. Try using ModBus ASCII to see if you can maintain connection although the throughput might be slower.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SRIDHARUnfollow Follow SRIDHAR SRIDHAR MOHAN Thanks Richard. i am using RTU mode. Only one device i connect. Here RS485 no issue for transmit and receive only i saw problem for USB. its hardware issue or software problem. any calculation for USB Transmit and receive. any one help me.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RichardUnfollow Follow Richard Richard Warsza I haven't investigated this problem any further other than switching to ASCII mode to communicate to a PLC.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

MarkUnfollow Follow Mark Mark Phillips Not sure what this post has to do with 61850, but since I have dealt with similar problems on USB, I will offer my 2 cents. You haven't been very specific about the topology of your system. I am presuming that the communications is not native USB->USB, but that there are USB->serial converters involved? A big problem with these devices is that the USB transaction can happen much faster than the RS-232 (or RS485) transaction. As a simple example, if you send a bunch of data to a USB-toserial converter, the transaction will happen almost immediately, and the driver will report "All Sent" very quickly. Under the covers, though, the message hasn't actually been sent over the wire (since a 19.2 KB serial line is a lot slower than the USB traffic). If you're sending long messages, or if you have very tight timeout requirements, you will fail the transaction. I suggest this because you say that it works under some platforms, and not on others, and that has been exactly my experience. Some USB serial drivers will indicate "all sent" when the USB transaction is complete, others will wait until the data has actually been sent before giving this indication. Relax your timeouts, if possible, and provide more detail as to the exact setup (particularly, is this a True USB->USB connection, or where is it actually an RS232/485 connection?).

1 day ago Unlike Like


Reply privately Flag as inappropriate Flag as promotion

SRIDHARUnfollow Follow SRIDHAR SRIDHAR MOHAN thanks phillips.


1 day ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

SRIDHARUnfollow Follow SRIDHAR SRIDHAR MOHAN Hi. I am using Modbus RTU communication for USB 2.0 with serial converter its convert RS 232 signal. but i have Time out problem only in 19200 baud rate i.e, other baud rate some few times only got the time out error.what is problem.any one help
15 hours ago Unlike

how are benefit of implement IEC 61850 in Distribution Automation ? why 61850, their best benefit ?
5 days ago

Close viewer Like Comment

Follow Flag
o o o

Flag as Promotion Flag as Job Flag as Inappropriate Reply Privately

More
o

3 comments

RichardUnfollow Follow Richard Richard Warsza I think that the ultimate benefit of IEC 61850 is that you have one method to model your system with a common suite of protocols and a common database. In the future a common integration tools for programming, testing and commissioning rather the slough of vendor specific tools.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

HerbUnfollow Follow Herb Herb Falk The ability to use multicast (e.g. GOOSE) for feeder automation is also a major benefit.
4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

AmmadUnfollow Follow Ammad Ammad Ali Standardized and based on naming conventions which made it relatively easy to configure and can be commonly used with different vendors.
21 hours ago

Configuring GOOSE subscription on GE F60 relay ...?


I have a GE F60 feeder protection relay and I want it to receive a GOOSE from a C264. The manual is confusing and I cant get through the process of configuring GOOSE subscription on the F60 Has anyone configured GOOSE subscription on F60 from C264. ? Appreciate your help in any form ..
6 days ago

Close viewer Like Comment Follow Flag o Flag as Promotion o Flag as Job o Flag as Inappropriate More o Reply Privately

Mayank SHARMA likes this You, Mayank SHARMA like this 1 comment

LokeshUnfollow Follow Lokesh Lokesh Kodi Hi Mayank, Follow these steps. 1. Define the Remote device in the input/output submenu of Setup software 2. Define the remote inputs, the dataset-1, 2 as you required 3. In the IEC 61850/ RX configurable goose, match the exact data type like St/q/Mx etc to the remote signal data type. 4. Finally you can use Remote inputs operands of related data types into your logic. hope this helps

The point is that considerations related to IEC 61850 actually begin when the utility decides to add an asset (transformer, line, etc).
The naming of the asset is assigned maybe 5 years prior to commissioning. The high level system protection design is developed at this point also. What tool do I use to capture this high level information? The tool needs to be vendor agnostic since many utilities do periodic reviews of their approved vendors and the actual relay vendor may change over time. Also the tool needs to link to a variety of external & legacy drawings & utility standards, etc. I think the actual utility design process has not been well thought through in the design of the tools and processes that are needed to support IEC 61850 adoption. Others thoughts please? 6 days ago

Given that the Grid is in place today - what tool is needed to manage the transition from existing to IEC61850 considering the process actually begins 2-5 years ahead of the actual field installation.
What features does a tool need to have to provide for a solid transition from what is done today (starting with the capital expansion planning process through detailed engineering) with project diagrams, schematics, ladder logic diagrams, design specs & utility design standards to migrate and manage a mixed environment of legacy and 61850 based substation devices? That is the world most people live in. Even if one does a complete substation with drop in control house the other end of the transmission line will be legacy or a mixed environment. 6 days ago

You might also like