Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations SSS148 on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

IEC 61850 - 3rd part engineer tools - HELP !!!! 4

Status
Not open for further replies.

TudaPellini

Electrical
Nov 21, 2007
5
The thread thread238-167238 started to discuss the available IEC 61850 engineer tools.
These engineer tools are supposed to act as vendor-independent integrator tools, allowing the specification of the substation topology and its functionalities (SSD file), integrating IEDs ICD files, configuring the IEDs, programming the information exchange between them (GOOSE/MMS) and creating the system SCD file and the IEDs CID files.

Up to now, we found three software tools that are available on line (evaluation versions that could be downloaded):
- Visual SCL from ASE;
- SCL Manager from Kalkitech;
- Helinks STS from Helinks.

Other tools exist, such as:
- Siemens DIGSI, anb;
- ABB IET/CCT.

The question that remains is:
WHAT TOOLS WORKS !?!

We could not test DIGSI or IEC/CCT but the other three supposed solutions (VisualSCL, SCL Manager and Helinks) fail to do their jobs.

Please, tell us your comments and personal experience.
 
Replies continue below

Recommended for you

And additional.
Tuda say about system with 2300IED's
Folks, please try put in services system with 50IED's with peer to peer comminication. We need now commissioned system with 75IED's for this we split system to two small with one
master relay. Isn't 61850 protocol.
Regards
Slava
 
SLAVAG SAID:
"...And additional.
Tuda say about system with 2300IED's
Folks, please try put in services system with 50IED's with peer to peer comminication. We need now commissioned system with 75IED's for this we split system to two small with one
master relay. Isn't 61850 protocol...."

I agree, there is something wrong with this.
I have seen and worked on projects with 35 + 35 IEDS, on 2 different IEC61850 buses: one for control (interlocking), one for protection.
Of course you spend some hours on the network analyzer (guys, I am a protection engineer... network analyzer? Gosh!)
Before you used to spend days in testing cable connections, one by one.

Testing is always testing.

But we should open a new topic: what does TESTING mean today? I have tried several times, but I think that no conclusion came out.
Why? It is difficult.
First you have to know the system very well, then you have decide some tests that in case the tested system would fail, you will be asked to take actions.
Not easy.





 
521AB.
I agree with you, you can see attached thread:
thread238-202415
I work with peer to peer interlocking and protection systems 10 years, we puted in services about 40 substations.
Only before two weeks, we provide within two days peer to peer communication instead cables ( it's other story why).
Those systems works and works fine. With SCADA you have great tool for prevents fault and analazing.
But what is a problem: maintanece personal.
for 61850 aplication you need other level of personal.
you need build system for electricans, not for SW and communication guys. Network analyzing,will learn too.
My problem isn't 61850, my problem is multivendor solution.
Regards.
Slava
 
And forgot something.
One, only one problem stopped many prjects.
Additional bays or buses. With HW it's more or less simple, with SW interlocks is request very serious work with big risk.
BTW, recommendation for 521AB, take in account as possible additional bays in future. Believe me, is very important.
Id you want,we can continue topic, "what you need for test such systems"
Regards.
Slava
 
Hey 521AB.
Test of relay is good topic, but I also would like continue with this topic.
35IED and 35IED isnt small project.
Are you learn tools and protocol by yourself or was on some courses. Are you connect this relays to some SCADA or use only GOOSE messages. Pushing on me is up and I would like understand, what I need: electrical and protection eng with some knowlegable at computers and communication or some computer and comminication man with some electrical expirience.
PT389, Tuda, what is your opinion.
Regards.
Slava
 
Slavag.you asked for it and I have to tell you.
I also work for a company that does all of this. I also teach those things, and I use those things. But I prefer to be as engineer as possible, and as neutral as possible in our discussions, because before working for a company, I am an electrical engineer, and my "competitors", are firstly colleagues, than of course also competitors.

I am a protection guy, so I decided to "stay away" from SCADA reporting and interlocking. What I need to be able to do, is to say to the 61850 engineering engineer: "please move away from the engineering tool, I'll do my protection scheme now and you will not touch ANYTHING of it".

So, I know the basics for reporting (vertical communication) but I firmly decided to stay away from it. The basics are the same as for the horizontal communication: datasets, reporting control blocks (instead of GOOSE control blocks), the difference is that you need to "tell" the IED that there is a SCADA system, and this you to by "putting" in the SCD file the SCL decsription of the SCADA, let me say icd file of the SCADA. This because reporting is a "high level" IP communication, based on IP address, and client and server need to handshake.
GOOSE is a multicast (which means broadcast within the same virtual network) message, let's say "low level message", not based on IP addressing.

Regarding interlocking, they are based on GOOSE messages, but the philosophy of what you do with this information is not standardized. Unless you make everything buy yourself using boolean logic. This means you night need to design from scratch the reservation principle, you have to check that communication is always ok etc. NOT EASY. To what I understood, any IED manufacturer has done it according to its own experience (correct I think), so it might be not so easy to use IEDs from different vendors for interlocking schemes, unless as I said, you do everything "by yourself" (communication checks, quality attribute control, reservation, bypass in case of troubles etc.)



 
512AB.
Thanks a lot. I understand you.
Your information is very important to me, becouse Im also protection eng. But now Im project manager for both SCADA and protection issue.
Best Regards.
Slava
 
Hi 61850 pioneers! One thing is to read and understand the standard (I guess I can say already did it), another thing is to put it working fine in the real world installations...

Tell me one thing, the standard gives us the freedom to create new LNs and this is great for vendors! But, from an utility point of view, what's the point of creating new LNs if, even fulfilling the right format, vendors don't have ICDs including them?...
 
My last question considers ONLY the point of view of an utility, i.e., it assumes an utility writing its IEC 61850 specifications without vendors' collaboration...

In that case, what would be the advantages of defining new LNs, if vendors would not be prepared to implement them in their IEDs?...

In other words, if I deliver a SCD with some own LNs to a vendor, can he easily interprets the new LNs and build them in their products?... I think not...
 
@pt389

Im with you. Utilities defining their own LN is probably a waste of time. I think that the SCL is to be used to convey the connections, funtions and adresses. Not the data model...
 
I think you (pt389) are referring to the so called "top/down" engineering, and you instead (pepx) are referring to the so called "bottom-up engineering".
Am I right?
In the first case you define the SCD file and "automatically" the functionality of all the IEDs in the substation.
In the second case you specify the substation in "normal words", then you design the IEDs and take the 61850 description of all the IEDs and put them together forming the SCD file.
Then you do 61850 engineering on this SCD file (horizontal communication, called GOOSE, and/or vertical communication to station HMI, called reporting).

I have never seen building houses from the roof, even if I believe it would be possible..
 
I'm saying that if an utility tries to define a SCD by its own (ir order to build an entirely vendor independent - universal - solution) it will have to decide how to group the LNs in the LDs and the LDs in the IEDs...

But different vendors can have different architectures for their IEDs and the allocation of functions that the utility define in its SCD can become incompatible with some (or even all) the vendors' offers.

The 61850 configuration process doesn't seem to be so "vendor-independent" as it is announced and utilities will always have to involve vendors on the definition of SCD or, at least, to know by hand the architecture of their products and try to define a common solution...

Maybe I'm making some confusion here... In this context (and regarding my initial question), if I want, as utility, to build a SCD and need new LNs to represent some particular functions of my power substations, how do I know that, even building them according to 61850 extension rules, I will be able to deliver my SCD to any 61850 vendor?...
 
"... Maybe I'm making some confusion here... In this context (and regarding my initial question), if I want, as utility, to build a SCD and need new LNs to represent some particular functions of my power substations, how do I know that, even building them according to 61850 extension rules, I will be able to deliver my SCD to any 61850 vendor?... "

NO.
I would suggest you to strictly devine the Logical Nodes according to the standard.
Consider the logical node (LN) PTRC (trip function if we can say like that). It's according to the standard. Also the logical node SMPPTRC is according to the standard, as the manufacturer is allowed to add 3 characters in front of the basic for characters. You don't need to know that one utility calls its function SMMPTRC and another maybe just PTRC or maybe 111PTRC. You just care about "PTRC". Of course no relay manufacturer will probably be able to import your SCD file in their IED-tools, but the SCD file can be opened with any "SCD viewer" and can be understood by anybody who "speaks" 61850 language.
The manufacturer might then return to you the SCD file adapted with its own name (fully according to the standard, so it is not a dialect).

But then what do you gain by spcefying one SCD file? Why don't you specify what you want "in words" and let manufacturers give you their SCD file?Please let me know, I am very interested in this.


 
Just a question pt389: why do you call us "pioneers"?
There are already hundreds of 61850 projects in the world... RUNNING.
And new projects: several per months.
 
Hi 521AB,


I know that there are already lots of power substations "talking" 61850, but very work has to be done yet and those projects have been contributing to show in more detail some lacks that standard had in its 1st edition and that are already being clarified (indeed, most part of that lacks could only be seen in real world practice!).

So, even with the large number of installations already running, I think we can consider that all the people involved in this amazing standard (TC 57, manufacturers, integrators, utilities, ...) are still opening some roads! I called you all "pioneers" as a compliment, but sorry if it was misunderstood... :)

"But then what do you gain by spcefying one SCD file? Why don't you specify what you want "in words" and let manufacturers give you their SCD file?Please let me know, I am very interested in this."

In this point I disagree with you... Currently the 61850 configuration process is mostly on vendors' side, but I think that real interoperability only can be achieved with a balanced participation of all the involved!

An utility that keeps delivering its specifications "in words" and that lets 61850 stuff on vendors' hands can't have a close control on the implementation choices... In addition to not take full advantage of standard's benefits, it can have problems if wants to expand one of its substations with devices from a vendor that is not the original one...
 

after reading so many conversations in this thread, it seems that everyone is forgotten about the existence of the SCD of the specific substation..

AFAIK, the heart of 61850 is SCD...
without SCD, you can not expand/integrate with third party IED...

CMIIW,
w33ch00
=61850newbiers=
 
Hello w33ch00! I don't understand your point, we've referred SCD and its importance in our posts...
 
"WHAT ABOUT test equipments (FREJA, OMICRON, DOBLE etc). What should be their role in this world? What should we ask or expect from them?
============
521AB, you know that Omicron already implemented 61850 interface in it's latest version of TestUniverse. I still haven't a chance to work with it. Anyway I am a bit skeptic how far such direct communication should be used in field testing. For some specific functions it could be OK, as well as for tracing of some problems with GOOSE-based protection functions interaction (as simple busbar protection on reverse-interlocking principle, for example). But the purpose of field testing is to verify that relay protections really trip circuit breakers, so I am not going to test anything related to real output contacts, LED's and alike looking only on incoming info via the Ethernet port of tester. May be I am conservative, but ... sad "

I have worked with the OMICRON on several projects with 61850, including interoperability. It has several tools for testing. On can receive and transmit GOOSE Messages. A common practice is when a new function is added, test it via contact, then via GOOSE and also together to verify the delay time.

The second module is like a protocol sniffer. It can read all messages which is useful for what I call an avalanche test (try to cause mis operation due to network overload, etc).

I've spoken to many utilities who are utilizing this system this way and they are quite happy. I've been told the real beauty of 61850 is if something was missed, it can be easily added in the field, tested and put into service. This is the real beauty vs. copper wires and all of the drawings that need to be changed. The relevant 61850 files are updated, which is documentation.
 
At kinectrics, we have built the first - IEC 61850 interoperability testing lab in the world. We also provide hands-on training on IEC61850. The configuration softwares from the third-party can generate the SSD file successfully.

However, when comes to data folowing engineering such as GOOSE dataset/control block (GCB) and report dataset/control block (RCB) configuration, it has problems working with the manufacturer IED configurators.

You will be frustrated by having you SCD generated from the third-party software, and having problems importing it to IED configratures.


 
The quality of third-party engineering tools is developing fast. It is today possible to do more than just the System Specification Description (SSD-file which describes the single line diagram and required Logical Nodes (functions) of the substation.)

Another IEC 61850 interoperability laboratory has verified GOOSE engineering between ABB and Siemens IEDs using Helinks STS as a vendor independent third-party tool. See:
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor