Beck IPC and NettedAutomation conducted two workshops on the latest development of IEC 61850 and IEC 60870-5-104 monitoring and automation IEDs and gateways. Experts from 12 companies (users and vendors) attended the workshops. The attendees appreciated the inside view into the standards and how easy it is to implement standard conformant IEDs.
One attendee responded the day after:
“Dear Mr Schwarz, I had a safe return fortunately. Thanks again for your documents and your very interesting presentations yesterday. It is very likely that I contact you in the near future for some questions/help.”
During the first workshop there was a very crucial question on the long names that are used as references to signals (data attributes) like: “MyLogicalDevice/QE1XSWI5.Pos”: How do these long names impact bandwidth needs and consumption? It seems to be quite in-efficient to use IEC 61850 for low bandwidth communication channels! Or?
Here is the solution for Reporting (Meldungen) in IEC 61850: The Report Message uses DataSets to describe the semantic content of the message and the syntactical position of each member of the DataSet. The example below shows five members. The order of the members in the DataSet is important!
A single change in a one of the signals represented by a hierarchical reference, e.g., “MyLogicalDevice/QE1XSWI5.Pos” causes a spontaneous report message with the value of exactly this member (Boolean=True in our example). The POSITION of the member within the DataSet is marked in an inclusion bitstring (or Index) in the message. For the five members we need one octet for the bitstring. The message also carries the name of the DataSet “SwitchPositions”.
The Client can interpret the semantic of the single Boolean (=True) by just looking into the DataSet configuration. The member number 5 means: “MyLogicalDevice/QE1XSWI5.Pos” (of the server). The client needs to understand the syntax (position of the member in the DataSet) and the semantic of the received value(s). The client uses the Configured IED Description (.cid) to understand the shipped package (report).
Any question. Please keep in touch.
For GOOSE and Sampled Value messages it is even more efficient: by just sending the values of all members of a DataSet (in the order of the DataSet) there is no need to provide any identifier (name or index) in the messages. The semantic is determined by the order of the corresponding DataSet. So, subscribers need to receive in the GOOSE or SV the reference of the DataSet used. The efficiency much better than what many people expect – people that know the efficient encoding of IEC 60870-5-104 or DNP3.
That’s it. You want to learn more about IEC 61850 and related standards – and how to implement them, please check the program for the next hands-on training on 07-09 May 2014 in Frankfurt/Germany.
Posts
2 comments:
Yes, this is a common confusion. The GOOSE message simply has the value of the particular function as a "0" or a "1" in the actual message - none of the prefix identifier or even the LN name. The message doesn't need to contain all that extra stuff but it does contain the GOOSE identifier number. All the subscribing IED needs is to be configured to subscribe to a particular GOOSE Id and extract the particular bit out of the dataset.
It is the engineering tools that need to be able to understand the prefix information and hence the structure of the SCD file and the extracted CID file so that each engineering tool, i.e. each ENGINEER knows what is being configured.
Yes – this a common confusion about the structure of a GOOSE message and in particular the Dataset.
The dataset doesn’t include the prefix/suffix, or the Logical Node name, or the name of DA or DO.
It only includes the value as a “0” or “1”.
As far as the real time communications are concerned, the subscribing IED has previously been configured to receive particular GOOSE messages and extract the particular data elements it needs – the names are irrelevant.
The full names are only needed for humans to understand what each piece of information is so that we can use the tools efficiently, so the SCL files have a specific structure that enables those names to be conveyed from one tool to the other – this is what I think is the real “human interoperability” of IEC 61850
Post a Comment