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

[TudaPellini]

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.

 

[521AB]

Slavag,
you mentioned: "...PS, I'm allways prefer work with "big" companies, not with 3rd part."..

Well, my opinion is thatthe success of IEC 61850 idea is in the hands of third part IEC 61850 engineering tools.

I do not want to take any position, but it quite clearly seems to me that IEDs manufacturer tend to produce engineering tools for their own IEDs. Are they mean? No, probably it is the only thing they know well.

The third part market will have all the interest in knowing all of them.
It will also pop-up (as it is already clear) the difference between "native 61850 devices" and "not native".
The "non native" devices have a "converter" between the old relay database and the IEC 61850 mapping. SCD files impossible to read or understand, they are full of "GGIO" signals. A disaster!

Only the third part engineering tool will be able to put some order onthis, and also to put some claims.

I am reading with interest at the Brazilian experiment,please keep us updated.

I would like to draw your attention on another issue (still 61850 related): you have identified the IEDs, the engineering tools, probably some SCADA systems for the reporting etc.

WHAT ABOUT test equipments (FREJA, OMICRON, DOBLE etc). What should be their role in this world? What should we ask or expect from them?

and more:

INTEROPERABILITY.....
interesting and completely in agreement with it, but....

what about the poor people working in the substation? One bay is ABB, another bay is Siemens, the third bay AREVA... they GOOSE together, fine, but the devices are STILL protection relays with their complexity. Shouldn't we try to show respect to the people that at the end, have to handle this "interoperability"?

 

[521AB]

HELLO PT389! You say:
"... -) how can we define some conditional functionalities in SCL? Suppose I have a substation with 2 different operation modes: one for normal operation and another for special operation (during servicing and maintenance). In normal operation I want automatic reclosing and timed protection functions, but in special operation I want automatic reclosing disabled and protection functions tripping immediately. Can I define these conditions in SCL?..."

ANSWER: NO :-(
This has nothing to do with the System Configuration Language.
How the logical nodes, the logical devices, the logical attributes (sorry, how the function blocks and their signals like start and trip) interact, has nothing to do with the SCL language (my understanding, but I'm quite sure I'm right).

BUT YES...
I mean, it has nothing to do with the SCL, but it can be done. It depends if the IEDs support different setting groups and are fully/dynamically configurable (connections among function signals).
Put one IED in test mode, or send it one GOOSE message for doing it (for all the IEDs), and the IED will go in setting group 2, with no time delays. and A/R disactivated.

QUESTION: what is the purpose of that? The protection system should be as simple as possible, and -I mean- you are running the substation in "normal mode", not in "test mode". Do you want the test people to test something that has nothing to do with the reality?

I have reached one conclusion: any idea with GOOSE that I listen, I replace the word GOOSE with the word "contact". Sometimes is trip, sometimes it is start, sometimes is a binary input like carrier receive or blocking signals.
If the idea is ok after the replacement, fine. Otherwize I simply not consider it. Maybe I am too much conservative, but relay people ARE conservative, and thanks God they are...

 

[521AB]

I gave a look into helinks...

some questions.
As protection relay engineer I am not interested into IEC61850 reporting to Station HMI (Scada or similar).
The only think that is of interest for me, at IEC61850 level, is the possibility:

1) generate one SCD file by importing ICD file (just the 61850 description) from different IEDs (can be protection relays from different vendors, but also test set.
The ICD files are generated with the vendor tools, according to the standard. To make it simple: PCM600 for ABB and Digsi for Siemens.
2) As I said, in the engineering tool I import those ICD files, and tsart to create datasets and GOOSE control blocks for each IED.
I also decide what will be sent (published) and what will be received (subscription, or client definition) for the GOOSE messages, that for me are protection signals like blocking, trip, start A/R etc. My GOOSE messages are of boolean type. True or False.
3) From the engineering tool, I want to export the SCD file.
5) The SCD file will be imported in the local tools (PCM600, Digsi to let you understand what I mean) and from them the IEDs will be instructed to do what is written in the SCD file.

This is a bottom-up approach, but I think all of you are thinking about the top-down approach.

The question:
can this HELINKS to this job? Have you tried?

 

[slavag]

Hi.
IEC61850 is only new standard.
Many years we all work with UCA2, LON, 103, 101, 104, DNP3.0, etc. with SCADA peer to peer communication same to GOOSE.
What is a difference.
Maybe is not good parallel, but for me 61850 is MODBUS, but for substation automation and protection.
Please don't forgot we are Protection and Control eng and not soft and communication eng. 2300 IED's with GOOSE mes, sorry, TVA on project with 35 IED's worked more than year with all backup of Siemens, ABB, Areva anf GE. Sorry, for what you need connection with 2300 IED's, what is a benefit? OK you have 3rd part of 61850 tool and five eng tools for IED, after one year you need add some interlock, I would like see site eng.
Up today only about 8% of utilities have 61850 protocol.
W/O names, before one year I discaussed with one vendor about multivendor application, he said me, in one project he replaced all distance protection to his mnf. instead devolped 61850 connection to others. Our utilities start now with this type of project and start add gateways between vendors.
Regards.
Slava

 

[lz5pl]

Slavaq, I have a friend in one of European Big Three specialized in SCADA engineering from many years . He is in despair from problems created by 61850. He told me roughly the following: OK, the standard gives us so many possibilities. But who really needs them? How often GOOSE functionality is really necessary? It is true that relays from different vendors could be interconnected in one system, but with 60870-... standards it is achieved also and many substations are in successful operation from many years. According to him at the moment problems with the new protocol are not compensated by it's benefits.
I cannot agree or disagree with him, as I am not too deeply in that matter. But for me as a protection engineer there are only few cases where these features could be used. Anyway in our company we are looking also to follow the trend

http://www.triel.bg

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[slavag]

Exactly. Why need? New trend,maybe. But I think GOOSE or peer to peer communication is very important. We used it and it help. And at one of the projects now is very helped me, all interlocks we build and checked in few days with peer to peer communication instead HW, becouse poor design.
On this moment I'm start course for 3 weeks and one part of course is 61850. Once we discused with you about RE670, it's course of 670 series.
Regards.
Slava

 

[lz5pl]

Yes, we are planning also MicroSCADA and 670-series courses in this year. But it depends mostly of local ABB's schedule.
Actually we work more with Siemens - not some special preference, just it happens to establish links with them. For one of our current projects I will have several Siemens relays for a couple of weeks, until panels will be manufactured. Another contractor will do SCADA using SicamPASS, but I will try the occasion to test Helinks software (and myself !).

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[slavag]

Good luck to you, Lz5pl.
My planning was changed, next time we'll learm RE670 ( now we learn it by ourself, we won one project with generator protection REG670).
I need work now on the urgency project.
But I'm now at the Baden, and see guys from ABB Bulgaria.
And I sure, we'll work together on one of the project.
Best Regards.
Slava

 

[lz5pl]

Good luck in your training in Baden, Slava. Similarly to you, self-education is the way we did many of our projects. I never have been in Siemens, for example, but have completed most of my projects with their relays!
If you like you can contact me via our website address.
Plamen

http://www.triel.bg

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[lz5pl]

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 ... :-(

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[slavag]

Plamen.
You are not conservative, you are field eng!!!!
You are know what is important and what is a games.
521AB is not against you, is against some kind of EE.
CT, VT, trip circuits not tested as needed, but wrote me about fault communication to some meter.
BTW, reverse interlocking work on the peer to peer comunication fine .
Regards.
Slava

 

[pt389]

Hello, sorry for being late and thanks for your answers!

I'll tell you about something I saw related with my initial questions:

"how can we define data flow within LNs with SCL? Let's say I have a PDIS instance and want it to receive data from a TCTR and a TVTR instances. How can I define this? Part 6 doesn't specify anything like that and the only reference I saw about this is "external input", in the definition of the IED..."

The "ext refs" tags of SCL are sufficient to do this job? Part 6 gives a brief description (only a small paragraph...).

Another two questions I have:

-) how can we define data flow within LNs with SCL? Let's say I have a PDIS instance and want it to receive data from a TCTR and a TVTR instances. How can I define this? Part 6 doesn't specify anything like that and the only reference I saw about this is "external input", in the definition of the IED...

"how can we define some conditional functionalities in SCL? Suppose I have a substation with 2 different operation modes: one for normal operation and another for special operation (during servicing and maintenance). In normal operation I want automatic reclosing and timed protection functions, but in special operation I want automatic reclosing disabled and protection functions tripping immediately. Can I define these conditions in SCL?"

Instead of logic diagrams, can we use GSSE to do it? I was thinking of a SGCB with a SG for each mode's configuration values and a GsCB seeing the operation mode index... On a variation of OM, GsCB could send a message with the index to SGCB and this CB could activate the corresponding SG...


I know that certainly are stupid questions for you but I'm just starting with this standard and feel a little lost...



Thanks


Slavag, I'm trying Helinks too! Following your steps I can achieve the .SCD files without big problems but I haven't tried yet to build the .CID file from a vendor tool...

 

[slavag]

Yeh PT389.
I can't help you, my level on this issue about "zero".
I only read documents, I only start think about 61850.
Several customers push on me, but on this moment I "hold hourses".
Regards.
Slava

 

[521AB]

lz5pl: ......521AB, you know that Omicron already implemented 61850 interface in it's latest version of TestUniverse. ..

521AB : yes I know it and I use it almost everyday.


lz5pl: 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.

521AB: If relay do not trip with binary output, but only via GOOSE message, you must start to think how to test this. Both in commissioning, but also for routine tests.

 

[slavag]

No problem, w/o any additional test-set.
What do you do for test diff protection with optical connection or BBP with disributed bay units?
You send signal and check event list on another side or close signal on another side.
If it's interlock, for example,you connect BB earth switch and check event list of all relays or you only change two BI on the Bay controller.
On commissioning time, I must check all from point to point.
I "like" GPS synchronization for two test-sets on both line side too. Great idea, but why need it?
New technologies are good and important, but from time to time I see it as expensive games only.
Regards.
Slava

 

[lz5pl]

521AB : yes I know it and I use it almost everyday.
========
521AB, I really envy you! Last year I went mostly on preparing of offers, conceptual design, checking of drawings prepared by younger colleagues and giving advices - how boring! With advancing in age and position we loose possibility to play with our expansive toys, what in my opinion is the most interesting part of this profession :-(.

------------------------
It may be like this in theory and practice, but in real life it is completely different.
The favourite sentence of my army sergeant

 

[pt389]

"Slavag, I'm trying Helinks too! Following your steps I can achieve the .SCD files without big problems but I haven't tried yet to build the .CID file from a vendor tool..."

Sorry, this note about Helinks was to 521AB

 

[slavag]

;-)
No problem.
Actually, i'm now herad so much about 61850, from guys from many countries and companies. I don't know if possible say
something like to " is good or not" "is need or not".
I think we see it in the future.
On this moment, I think lot of projects provided with GOOSE messages and HW wiring together.
Regards.
Slava

 

[521AB]

Hello slavag!

Are you sure when you say "... What do you do for test diff protection with optical connection or BBP with disributed bay units?
You send signal and check event list on another side or close signal on another side...."

Why don't you just check the disturbance recorder for a normal trip issued by binary output and instead you stop the test equipment from the contact itself?

The GOOSE message must be checked as if it were a trip contact.
You should connect the test set directly to the ethernet port of the IED if you are just checking the IED itself.
Then you connect the test set as close as possible to the point where the GOOSE message is supposed to be received, to perform a system test (like in the "old" technology, when you stop the test set from the contact of the final trip unit).

If the station network is "disturbed" or overloaded by some other communications which run on on the same network, the GOOSE message can be delayed, and the system test will show this. The GOOSE message itself is created to manage such situation. Just think about what happens when a GOOSE message is sent because its binary value changes (from 0 to 1 in case of trip): the message is sent as soon as possible (4 ms), than it is sent again (after 8 me), then again (after 16 ms) etc. till it goes back to it's steady state keep alive frequency (typically 10 seconds).
If the switch misses the first message, it will probably manage the second one, with a delay of 4 ms. If it still will miss the secod message, it will manage the third one, with a delay of 8 ms etc. All of this might be detected by the system test.


Regards
521 AB

 

[slavag]

Hello 521AB.
It's long, long story, like to "what is right test of numerical relay".
I don't say, that new test set with optional of goose messages test is something bad. Maybe for some kind of test is good.
What is a difference for me.
1. I checked AD of relay with contacts, back it to field, check CT and now I'm sure (99%)that system will be OK.
2. I checked relay with GOOSE test set back it to field and... this GOOSE messeges come to relay after two-three
network switch connected in star or ring. for example it's signal BFP trip, tested it on the live system unpossible or you need some operation on the side. If I start with this operations,I will check this signal from point to point w/o test set. BTW, for test communication signals we used once turnaround signals, are possible provide same in the 61850?
Next point, lot of relay only send signals and not recieved them.
Regards.
Slava