How is the communication between HMI and IEDs taken place?Can we just use GOOSE for that purpose?

so how to configure it?

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

29 comments Jump to most recent comments

MiguelUnfollow Follow Miguel Miguel Bengla Map it to MMS instead. 11 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist I agree. I would not use GOOSE for communications betwen HMI and IED except perhaps for monitoring and logging protection activity. The client/server profile (what

some people call the "MMS stack") was designed specifically for retrieving the type of information that an HMI would want to display. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh The best method shall be using Un-buffered reports. How ever, you may need to use polling of individual Nodes may be if the data you require is not mapped in Datasets or Reports. The tricky part is Dynamics Datasets, if the IED requires to create dynamic datasets, then the HMI application need to support such features. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Luis AlexanderUnfollow Follow Luis Alexander Luis Alexander Camacho G. The structure for GOOSE msgs is quiet different than report messages, in fact the communication layer for GOOSE has other ethernet properties. However, and it depends of the vendor, the device might have the same LD used for both porpuses, but that does not mean it is the same one going everywhere 10 days ago Unlike Like

Reply privately

Flag as inappropriate Flag as promotion

Luis AlexanderUnfollow Follow Luis Alexander Luis Alexander Camacho G. So, you can't use GOOSE msg for your HMI! 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz It is possible to get GOOSE data into a SCADA/HMI application. Products exist. I would tend to agree with Grant that it is generally better to use client/server reporting because HMIs and SCADA would typically require data that is not available via GOOSE and don't need the data delivered at that rates at which GOOSE data is delivered. But it is possible to do it if needed. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

TexUnfollow Follow Tex Tex Gamvrelis, P.Eng. While on the subject of HMIs and GOOSE, I know by definition GOOSE was intended for use on the station or process bus primarily for interlocking and permissive tripping. I can conceive of at least one EMS or DMS application (load shedding) where it may be appropriate to use it under avalanche conditions. Does anyone know if GOOSE was ever intended to be used in this fashion? 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

LaxmanUnfollow Follow Laxman Laxman Rao Can we get more information regarding the products which can be used to get GOOSE data into a SCADA/HMI application. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hi Tex GOOSE is certainly not restricted to any particular use on Station or Process Bus. It is simply a message that tells other IEDs that subscribe what is the status of the function (operated or not operated) in the publishing IED. So it is used that when the subscribing IED receives the message, depending on the IED it might start an autoreclose, a CB Fail function, or as in your case start an Under Freq Load Shed .... CIGRE have just published a Technical Brochure 540 which discusses a whole bunch of

functions including UFLS - www.e-cigre.org CIGRE Member companies or Individual Members can download PDF for free (with copyright distribution limitation of course) 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hi Tex GOOSE is certainly not restricted to any particular use on Station or Process Bus. It is simply a message that tells other IEDs that subscribe what is the status of the function (operated or not operated) in the publishing IED. So it is used that when the subscribing IED receives the message, depending on the IED it might start an autoreclose, a CB Fail function, or as in your case start an Under Freq Load Shed .... CIGRE have just published a Technical Brochure 540 which discusses a whole bunch of functions including UFLS - www.e-cigre.org CIGRE Member companies or Individual Members can download PDF for free (with copyright distribution limitation of course) 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Seyed AmirUnfollow Follow Seyed Amir Seyed Amir Alavi Ok if we use MMS to communicate,we are going to use BRCB for example,it may be no data change for 1 hour and the HMI is not informed then.How much would be the change band for a simple measurement to activate a buffered report? 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Don't forget you can poll for information as well just like 'conventional' scada polling 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz Or you can use an integrity period on a BRCB to receive periodic reports even if the data does not change. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph

Ralph Mackiewicz SISCO offers an OPC server supporting GOOSE pub/sub with its AX-S4 61850 product. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RalphUnfollow Follow Ralph Ralph Mackiewicz ALSO: There are deadband settings available in some devices that enables you to control the amount a measured value can change before it will trigger a report. Support for deadband is optional so you need to check with the device ICD file to see if the db attribute is supported. 10 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist The amount of the deadband is a system engineering issue and is not unique to IEC 61580. For instance, DNP3 also uses deadband parameters. Typical values for deadbands are about 2% of full-scale, although they could range widely, for instance from 0.5% to 5%. The amount of the deadband setting depends mostly on two factors: 1. How much the value displayed on the HMI should vary from the actual value at any moment, and 2. How many data reports per second the HMI is capable of processing On a lower-bandwidth link you would also worry about the amount of traffic on the link, but

over Ethernet this is not usually a problem unless you have a lot of data points. Remember in IEC 61850 that although a single report may contain changes to several different points, if the same point changes more than once the server must generate a new report to send it. 9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

BirinderUnfollow Follow Birinder Birinder Singh 1. We need to understand the requirements here. GOOSE were not designed / required for HMI Communication. But there are scenarios where GOOSE need to integrated at HMI level, such as, Substation is already configured and HMI is installed afterward, now IEC 61850 parameters cannot be changed as this will require restart of IED and shutdown, so HMI may need integrate the MMS / GOOSE messages as it is. 2. Other method in this scenario will be using dynamic data sets, as HMI may create the Dynamic dataset and hence the reports can be configures as per requirement. 3. Polling should be supported by HMI, to send MMS read command for the nodes as required. I think with above 3 features, HMI can work in any scenario. 9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Seyed AmirUnfollow Follow Seyed Amir Seyed Amir Alavi Thanks every one for your help.It seems that 61850 has changed the way HMI connects to slave devices dramatically.As I got the idea,it seems HMI should use reports for data gathering in addition it needs to poll devices for some of it's tasks to be done.GOOSE

subscription is not mandatory but if implemented it shouldn't get so much cpu cycle from the HMI to make it responsive and persistent. 9 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

Unfollow Follow Arfu I don't know my option is right or not.. I think for a small system , it maybe ok , becuase Goose is a heart beat mode , when any data point of dataset is changed , LAN dataflow is more impact than gerneral protocol used. And for optimize your GOOSE LAN, you should know following factor impact to each other in the same Goose LAN , that;re Mac , APPID , V-LAN .....all Goose fuction need to setting. I can not estimate so many IED using Goose ( like a brocaste way ) way in a LAN ; what happen will show for LAN dataflow ? 7 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JohnUnfollow Follow John John Kontolefa Where the IEDs also support DNP, I would use that. The HMI (I assume you mean a PC used for local monitoring, control and annunciation) shouldn't be out on the same network as the Goose messages anyway. 6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

0
true 30 30 groupItem?seeMo

RodneyUnfollow Follow Rodney Rodney Hughes Hi John It would be good to explain why not ... 6 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DavidUnfollow Follow David David Ingram John, an important part of any substation automation design that uses Ethernet (61850, Modbus TCP, DNP IP etc) is to design the network too. This includes estimating traffic flows, send and receive endpoints, multicast visibility etc. I can't see why GOOSE, MMS and DNP3 can't share a network. The applications for for MMS and DNP3 are similar and both can have lengthy frames since IP is used, but the repetition rate is low. GOOSE is limited to one frame, but is probably sent more often. If you prioritise important GOOSE message (inter-trips for example) over IP traffic then the applications will coexist nicely. TCP has the retry mechanism and is quite tolerant of delay (heck, it runs over PPP on 1200 bps links in some places), so I can't see how DNP3 or MMS would be impacted by GOOSE. The practice I've seen for SAS design is to use MMS from the HMI and Gateway to control the IEDs (true client server with confirmation), GOOSE for inter-trips and one-way status (where

there is no control element) and DNP3 to communicate between the Gateway and the Control Centre (avoiding any changes to the EMS platform). There is a little bit of work required to make this happen, but not a whole lot. For small substations you could probably get away with plugging it and hoping ('plug and pray' vs 'plug and play'). It is better over all to do some simulations and model your network so you know it will work. That's where tools like OPNET and OMNeT++ are useful (provided you or people with you have the expertise to drive them). 5 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

JohnUnfollow Follow John John Kontolefa DNP can be on the network, just keep the HMI on a separate segment (separated by a gateway or firewall) so that the various Windows, third party applications and possible accidental/malware traffic (think someone typing "nmap") does not share the same network with the 61850 traffic. 4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

DavidUnfollow Follow David David Ingram John, the network permissions for an HMI (regardless of whether it is running Windows, Linux or Solaris) should be limited to the bare minimum to operate anyway. If the HMI is part of a multi-use computer (perhaps it is also the Engineering Workstation) then I'd suggest that virtualisation be considered. That means that only users with a need to use the

general purpose engineering machine can do so, while any person with physical access and a password can use the HMI (which might be needed for emergency switching under the direction of the control centre if SCADA-EMS comms fails). If you are allowing people to use tools like nmap in an unauthorised manner then there are bigger problems than the network design. Even so, with the proper design of port rate limiting and prioritisation the GOOSE/inter-tripping functions should not fail even if someone does an intensive port scan or traffic flood. It is quite feasible that an Ethernet card 'goes bad' on a PC and floods the network. I've had a PTP clock that tried to send 20Mb/s of broadcast ARP traffic after it had a firmware update, and traffic management let the LAN operate just fine. Layer 3 switches are more expensive than Layer 2 switches, so if you can manage traffic by VLAN rather than routing or firewalls then the substation automation system costs can come down. Each situation will vary though, and in some cases the 'belts and braces' approach of layer 2 and layer 3 traffic management can be justified. I'd hope this was used in 500kV substations where the data network costs would be in the rounding error of the primary plant costs. 4 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KevinUnfollow Follow Kevin Kevin Mahoney We recently completed multiple large 61850 installations. In our platform we used GOOSE for relay to relay tripping and interlocks, and MMS for RTU & HMI supervisory communication with the IED's. We used Buffered Reports for binary event information and polled datasets for all analog data. This worked well for us but is only one approach, both GOOSE and MMS can be implemented a number of different ways and adapted to fit your situation. You could for example use GOOSE for HMI/RTU to IED communications. As Ralph mentioned SISCO offers an OPC server that supports GOOSE messaging, so that would be one way to provide data to your HMI. If you have a situation where the station is already in service and the relays are publishing GOOSE messages, you could possible get the data you need via GOOSE. However it is likely

that not everything the HMI needs will be mapped into the GOOSE message, so you are most likely going to have to reconfigure the IED's CID files or settings to get what you need. You may be better of adding MMS reports and datasets so you don't have to modify the GOOSE messages. If you do change the GOOSE messages you will have to modify all subscribing IED's and are most likely going to need to recommission the relays. KEPware, GE Intelligent Platforms, and other vendors offer 61850 MMS OPC servers. This is the more traditional approach to provide HMI with data from the IED's. With MMS you can use either Buffered or Unbuffered Report by Exception, or Polling to gather data. Configure the various approaches as best fits your application. 3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Have you ever seen one of those houses that have been extended a few times by different owners wanting "something extra" - they can look a real hotchpotch of random additions where the floors are at different levels, the walls are of different materials, some windows are wood, some are aluminium .... Or have you ever played with Lego and got half way through the construction and either you or your play mate wanted to do something different and you had to destroy part of your creation to head off in another direction .... The issue of having to reconfigure existing IEDs when you add a new function of some sort (perhaps add a new bay of primary plant or a new protection function or comms with the HMI) keeps coming up. It is a valid issue. The solution is basic first principles of engineering - deciding at the start what problems you are trying to solve and design a system accordingly. The context of a substation is tricky - it involves, protection, control, automation, SCADA, primary plant, condition monitoring, grid control, asset maintenance, testing ...... all over a 100 year-existence of the substation .... and to draw the analogy of that old joke "I still use my great great grandfathers axe - it just has had 10 new handles and 5 new heads"

IEC 61850 is NOT a random collection of boxes that we suddenly decide to connect up and "hey presto - something works". IEC 61850 is about a SYSTEM and the engineering/configuration of the devices to be able to communicate within that system. This implies, no.... obligates us to put appropriate effort up front to understand what the System will be and incorporate - now and in the future. If we don't do this, we can see the sort of result in the ENSTO-E reports of last year - building "something" that the vendor says will work at the outset, later on suddenly "by surprise" can easily end up not being expandable or interoperable with new functions. It is paramount to start with some sort of Design Concept Specification that guides the System Integrator to avoid "cul de sac" solutions that require IED reconfiguration as we seek to expand the system even as only more and more stakeholders get involved in wanting something extra. 3 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

GrantUnfollow Follow Grant Grant Gilchrist Hi Rodney, That's a good summary of the long-term advantages of an IEC 61850 system, but I don't understand how it applies to the original question about when to apply GOOSE vs. the client/server stack? Most of the answers here have been "GOOSE for protection, client/server for monitoring". Do you disagree? 2 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

RodneyUnfollow Follow Rodney Rodney Hughes Hi Grant I was picking up on Kevin's comment: "so you are most likely going to have to reconfigure the IED's CID files or settings to get what you need" I see a lot of utilities and integrators taking an approach of just a very minimalist view of I'll build a sub with just this one function using 61850 (so they can boast they have something that feels like IEC 61850?) and then are surprised when later they want to do the next stage and they have to go back to reconfigure IEDs - the whole objective of the Standard is to be able to do the engineering to configure the IEDs to communicate as a SYSTEM - a system implies understanding the objective and needs of the system up front, and less like making it up as you go. 2 days ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion

KevinUnfollow Follow Kevin Kevin Mahoney I agree that you should consider the entire system during the design stage. This should include consideration of how the system may evolve or be expanded over time. In our implementation we used 61850 communication across the entire station, with the only hardwiring being breaker trip/close circuit and PT/CT circuits. Everything else including lockouts, control selectors, status lights, etc. are implemented virtually. With everything being moved onto the network we had to consider all aspects including performance, LAN/VLAN configuration, interlocks, maintenance, equipment monitoring, alarms, network & IED health monitoring, event recording, DFR, NERC/CIP compliance, security, SCADA, local & remote HMI, test procedures, commissioning, and other items necessary to provide a fully featured, maintainable system. We also included spare points in both GOOSE and MMS data sets to hopefully limit the changes should new functions be needed in the future. After many months of design and lab testing we determined that GOOSE would be used strictly for real time relay to relay trips and interlocks. All supervisory communications would be done with MMS. This allowed the team to keep the critical protection functions on the highest priority VLAN and limited risks during future changes over the life of the substation. I believe this

approach to be solid and has worked well for us. But to answer your original question you could technically use either MMS or GOOSE between the HMI and IED, the choice of protocol should be determined only after careful consideration of your entire application. Ps in my original post I forgot to mention that SISCO also supports MMS via its OPC interface. There are of course many hardware and software vendors supporting 61850 and you will need to evaluate your specific needs. 1 day ago Unlike Like

Reply privately Flag as inappropriate Flag as promotion