×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

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

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

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

(OP)
The thread thread238-167238: IEC61850 3rd part engineering tool 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.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

2
(OP)
To start the discussion, here is our experience with the tools that are available on the internet:

We tested the first three tools mentinoned on the previous post.
It´s umbelievable, but seems that the three tools fails to do their jobs... Or we are terribly wrong on how to use them.

- Visual SCL is "buggy" during the design stage, loosing conectivity nodes and creating a real mess when you start to rename entities (such as breakers, bars, voltage levels, whatever). The tool imports existing ICD files successfully. However, the wizards are too much confusing and the work to prepare Goose messages for horizontal communications is too much difficult (we tried and tried, but we don't understand why and how they are supposed to be created).

- SCL Manager has a better graphical interface for the single line diagram and less bugs. It also imports existing ICD files. However, when we try to create the goose messages between relays, a lot of errors are displayed and the application hangs and crashes painfuly.

- Helinks STS works better that the others. It has SCL (XML) parsers and validators that seem to be very usefull. But, no matter what we try, we cannot import existing ICD files on the IEDs sections. It starts blaming the ICD XML syntax and it does not import the IED. The ICD file was successfully validated by the ONLINE SIEMENS IEC 61850 VALIDATOR TOOL and were successfully imported on the other two softwares.

I know that the instantaneous answer to my question is:
"Read the Manual. Read the standard, etc."
Well, the manuals of the related softwares are horrible. There is no step by step instructions and most of the work are based on try and error approaches.
And the standard, believe me, we read.


RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi TudaPellini.
It's very special Q's.
RTFM, it's right, but not always help.
Try for example connect to Kalki support. Of course you need pay for this ( BTW, it's not so expensive).
I don't have expireince with 61850 protocol, but I would liken recommend only one: work with vendor tool: Areva, ABB, GE, SEL, Siemens (depend on your bay controllers or protection).
May be you need pay for SW, but this tool are tested and work.
Good luck
Slava

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

(OP)
Hi Slavag, thanks for posting.
We´re just considering buying for tech support from one of the companies. However, we don't have a clue about which software tools will do the work correctly. All programs seem to be filled with bugs and inconsistencies. We are even considering to build a quick and dirty software dedicated to our needs.

In fact, we are conducting a research to integrate about 40 protection IEDs from 5 different manufacturers (ABB, Areva, Siemens, GE Multilin and SEL).

Regarding the tools from the manufacturers, we found another problem.
What we heard about is that each manufacturer tools "seems" to be much focused on its own IED´s, and all that interoperability stuff is partially left aside. As we didn't have access to these tools yet, we do not know this for sure.
This is why i started this thread. Which software will save the day ?

Thanks again for the attention.
TudaPellini

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi TudaPellini.
I have some picture with ABB, Areva, Siemens, GE
relays work together. Nice pict., but not more.
Actually I know about only one real project, some big SS in the Germany, were ABB and Siemens operated together.
I'm not believe if today possible build this integration as you think. Only in theory.
I'm not believe, if ABB, Areva, Siemens, GE or SEL send to you real data. Why, I see only one think:
Areva and GE used in the projects not 3-rd party network switch, like to ABB or Siemens ( used Ruggedcom), for me it's indication something not O.K.
Sorry, may be I'm very scepti, but I think you'll need use some additional HW ( gateways from the vendors).
You know, we say: today we have 3 types of eng, HW, SW and PowerPointer.
Regards.
Slava

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hello.
US guys.
I heard about some first multivendor project in US with 61850 protocol. Some utilities build new 500kV substation with connection between control and protection by 61850 protocol.
Someone have any information about it .
Thanks.
Best Regards.
Slava  

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Slavag,

Not sure if this is what you were wanting, but SEL has a paper at http://www.selinc.com/61850/index.htm for multi-vendor IEC61850 at CFE.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

A paper on the first US based multi-vendor IEC61850 substation automation system was presented at last year's Georgia Tech Relay Conference.  The station is TVA's Bradley 500 kV Substation.  The presentation was prepared by Juregen Holbach and Julio Rodriquez of Siements; Craig Wester and Drew Baigent of GE Multilin; Lars Frisk and Steven Kunsman of ABB; and Luc Hossenlopp of AREVA.

TVA used the Siemens DIGSI software as the software configuration tool.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Thanks Jghrist.
I found data, unfortunately it's only common words, nothing technical.
But you stated very important point for me:
"TVA used the Siemens DIGSI software as the software configuration tool". not some 3rd part tool.
Regards.
Slava

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

And additional theoretical Q's after re-reading:
What is benefit put 4 vendors in same substation ( 35 IED's it's all)?
Not better used only one? I stop understand anything.
Slava

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

(OP)
Hi friends.
Some updates and comments.

We already read the TVA work with DIGSI software. But unfortunately there wasn't further details concerning the configuration procedure.
Later, we talked to Siemens people here in Brazil and we made a first contact with DIGSI software to understand its functionalities.
The DIGSI software works very well to setup the comunications and goose messagens between relays from Siemens and other manufacturers. But ONLY that. For other substation description issues, DIGSI cannot help to much.

*Nowadays we are successfully using the software from Helinks STS. The software is very well supported and is being constantly upgraded. And IT IS FREE AND IT IS GOOD.*

About our test: we are developing a test bench to approve the interoperability of 4 different relays manufacturers supporting IEC 61850. We are using 36 relays (9 from each manufacturer) on this test to simplify our work. The real scenario will probably be the biggest IEC 61850 project to this day, with *2300 IEDs* talking IEC between each other.

Helinks STS is helping us a lot on our tests. We don't know for sure if it could support hundreds or thousands relays. I guess any software could manage that. Probably, we may need to split the project in several pieces anyway.

Greetings to you all.
Pellini

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi.
2300 IED's!!!!! What is it. I'm hope it's region project.
But after your biggest hydrostation ( If I remeber right, about 20GW power), who know.
Gooud Luck at your project.
Regards.
Slava.
PS, I'm allways prefer work with "big" companies, not with 3rd part.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi Tuda! I've just arrived to this forum and read all about your experience with configuration tools because I'm starting using it too.

I tried SCL Manager from Kalki. Some connections disappear and is quite difficult to use it because, to resize the levels, etc.. However they launched recently a new version. It looks better but crashes several times... The configuration of IEDs is very simple, like you said, but it's not so easy to deal with CBs... The SCL validation fails due to incorrect variable names and other aspects that I had to correct by hand directly in the code ir order to achieve a successful validation.

VSCL from ASE is easier to use (levels do automatic resizing) but the configuration process is more difficult. I'm getting used to it (maybe you can give me some highlights:)) but I think that first we have to define the DATypes and LNTypes before creating LN instances within the IEDs. With SCLM we don't need to do this because it creates automatically DATypes and LNTypes, but in VSCL we have to do all that by hand.

Helinks from STS does a great job. Initially you said you couldn't import ICDs, don't now if you discovered a way to do that, I only know we can define IEDs like we do with the other tools, and we can create a SCD. However the process is more complex... I like to have access to SCL code, modify it and be able to open the modified one, but with STS I can't open a modified SCD because it deals only with its SLD format(the SCD is generated and saved, not edited).

I've got DIGSI too and I'm going to try it!

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

I forgot to mention, I work in an utility and we're thinking on going directly to pass our actual protection and controls systems specifications to SCL code. I explain:

Till now, we wanted a substation we had to deliver our specs to manufacturers by the traditional way, written in paper, and IEDs were built according to our specs but using proprietary communication protocols, so that traditionally we were pushed to single vendor solutions.

Now, with IEC 61850, we want to take the opportunity to present our specs to manufacturers directly in SCL code. Theoretically, if their products are 61850, they can put our code in their own configuration tools and generate the CID files to their own devices.

Isn't this correct? What do you think about it?

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Anyone?

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

(OP)
Hi pt389,

We are using Helinks STS a lot nowadays. The people at Helinks are working a lot to improve the software and to solve bugs. I would recommend you to send them emails about your particular problems. They are very helpful.

Concerning the ICD import procedure, nowadays Helinks STS CAN import ICD files easily. And I agree, it cannot open a SCD file directly as it does when you open its SLD file format. If you have an externally generated SCD file, you cannot open it in a graphical way on Helinks, but you can import and browse its contents and you can edit it directly on XML inside its editing environment.

Concerning your suggestion to send the SCD directly to manufacturers in order to "force" them to fit the IEDs inside *your strict specification*, i think you're right. As the involved file formats (SCD, ICD, CID, etc.) are very complete and easily expandable you can fully specify all IEDs functionalities and details. This scheme is very interesting and a lot of information can be easily exchanged between customers and manufacturers.
Anyway, in this process, I defend the idea that "third-part" software tools should be used by the customers in order to create these specifications. The process should be very manufacturer independent. The customers may focus much more on quality and cost/benefit rather than worrying about the maintenance and impact of proprietary solutions.

Greetings to you all.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hello TudaPellini,

Thanks for your post:) The problem is that manufacturers typically build their IEDs with predefined functions. As an example, suppose a manufacturer that only builds IEDs with PDIS, PTOC, PIOC, TCTR and TVTR. If I deliver him a SCD with IEDs containing PDIS, PTOC, PIOC, TCTR, TVTR, RREC, XCBR and more, how can he directly implement our demands?

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?



Thank you all for all the help you can give:))

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi PT389.
You have answers to your Q.
IEC61850 protocol defined function naming convention, communication, etc, etc.
But it never,never used for protection and control functionality.
I'm not work with this protocol ( on this moment), but according to manuals and one course:
Possible build SCL file from CID files only, bat not in back direction.
As I undrestood from lecture, first of all you must finished your set file ( IED configuration file) and only after this transfer it via ( SET, CET ot what ever) to SCL.
Regards.
Slava

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi.
Nice see you again, 521AB.
I hope next time I'll can continue this topic with more
data. We start serious course of 61850, on the next week.
Regards.
Slava

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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"?



RE: IEC 61850 - 3rd part engineer tools - HELP !!!!


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 sad
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... smile
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...






RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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?


RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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 smile
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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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
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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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.


RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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 sad.

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

"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:)

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

smile winky smile
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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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.





RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

521AB.
I agree with you, you can see attached thread:
thread238-202415: New concepts in substation interlocks?
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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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.)



RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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?...

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

@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...

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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?...

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

"... 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.


 

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!


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=

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hello w33ch00! I don't understand your point, we've referred SCD and its importance in our posts...

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

"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.

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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.


 

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

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: http://www.stri.se/index.pl?id=9733&isa=Category&op=show

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

Hi Nick75,

Seems U know much about STRI. Do U know what they show in their IEC61850 hands on course? The next one is on march 3rd - 6th in Germany (Frankfurt). Look:

http://www.stri.se/index.pl?id=9332&isa=Category&op=show

Are they showing how to engineer ABB and Siemens IEDs using this Helinks tool (...sounds much more clear to me, now!:)? Is it a tool of STRI? Are there demo versions available? Have you already worked with the tool? What about engineering Areva and SEL IEDs?

Tnx

RE: IEC 61850 - 3rd part engineer tools - HELP !!!!

STRI has tested the Helinks configuration tool for IEC 61850 engineering. There is a report on test for GOOSE subscription available at their web site:
http://www.stri.se/index.pl?id=9733&isa=Category&op=show

Goose publication is not mentioned. This is somewhat harder as it requires a greater knowledge of the target IEDs structuring of elements in the Substation Configuration file (an XML file according to part 6 of IEC 61850). Work is ongoing here.

The Helinks tool is still under development and according to Helinks will support IED specific mapping of general Logical Node type to specific Logical Node instance naming used by various IED manufacturers. Together with intelligent communication setting Wizards this has the potential to free the user from the most detailed knowledge of a vendors IEC 61850 implementation.

The STRI course will configure IEC 61850 systems also with Siemens, ABB and Areva tools, in parallel to the use of third-party tools.
 

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources