Showing posts with label polling. Show all posts
Showing posts with label polling. Show all posts

Monday, August 21, 2017

New Application Example for EvaDeHon Package

We have posted a new example extending the use of the Evaluation, Demonstration and Hands-On (EvaDeHon) Package.

We will publish from time to time additional models and documentation for interesting applications. The objective is to help you to understand the various topologies and possibilities to use the IEC 61850 technology for the process information exchange.

One focus is on the application of the IXXAT (HMS) Smart Grid Gateways.

The example offers polling and reporting (Server on PC, Client on IXXAT WEB-PLC Gateway). The download contains the client CID for the gateway, the server CID and the JSON file for the PC. The gateway polls every 2 seconds and receives reports every 5 seconds - these intervals can be configured. Additionally it includes some specific documentation.



Click HERE for more information.

Sunday, June 29, 2014

One Standard – multiple Terms for the same Thing

The Standard series IEC 61850 and IEC 61400-25 define hundreds of new terms for information models and communication models. Usually a term defined in one part and re-used in another part is the same (syntactically and semantically). In some cases you will find different terms for the same “meaning”.

Here is one example to explain what I mean:

The Standard part IEC 61850-7-2 (ACSI) defines in clause 12.3.3.3:

TrgOp [0..2] – trigger option

The attribute TrgOp of type TriggerConditions shall define the trigger conditions (associated to a data attribute of a data object) that may cause a report to be sent or a log entry to be stored into a log.

Three values are defined to be used inside the data object:

dchg data-change A report or a log entry shall be generated due to a change of the value of the associated data attribute

qchg quality-change A report or a log entry shall be generated due to a change of the value of the associated quality data attribute q

dupd data value update A report or a log entry shall be generated due to updating the value of a data attribute. An updated value may have the same value as the old
value. An example is freezing the value of a freezable data attribute updating the value of another data attribute, which could lead to the same value it already has.

The trigger conditions integrity and general-interrogation of the TriggerConditions type are used independent of instances of a data object.

The service parameter IntegrityPeriod is mapped to intgPd:

17.2.2.12 IntgPdintegrity period

IntgPd shall indicate the period in milliseconds used for generating an integrity report.

So far so good – even we have already three terms:

integrity, IntegrityPeriod, IntgPd, or integrity period.

What does part 6 (SCL) define?

<xs:complexType name="tTrgOps">
   …
   <xs:attribute name="period" type="xs:boolean" use="optional" default="false"/>

and for the value attribute of “period”: intgPd="2000" in the report configuration element.

So, we find six terms that mean more or less the same thing … you have to understand what they mean and when to use one or the other!

When it comes to IED Configuration Tools (ICT), you may have to learn new terms again:

image

Here the SCL attribute “period” is set to true, if the checkbox for “Included in Integrity/Poll” is set.

By the way, these terms describe something quite easy: Push all (!) values of a DataSet every n milliseconds. Without a request from the client. In addition to the cyclic push you may configure the server to report the value of a single signal after it has changed (data change)):

image

You want to learn how to use the standard? We offer training courses that help you to apply the standards in your daily business! It is more convenient to attend a training than to read all the standards … we have the long-term experience that we would like to share with you.

Friday, May 2, 2014

Could IEC 61850 be used for I/O applications as AS-i bus or Profibus DP?

Definitely one of the crucial objectives of IEC 61850 is to model, collect, and exchange Input and Output data! Many of the I/O technologies listed below (in a job description I just found today) are simply providing the exchange of bits and bytes over a communication link:

A well known company is looking (maybe) for you if you have – among other qualifications – “Experience with I/O technologies including FF, HART, WirelessHART, Profinet / Profibus DP, Ethernet IP / DeviceNet, Modbus / Modbus TCP, AS-i bus, IEC 61850, Wireless, Remote I/O technologies.”

IEC 61850 is much more than a I/O technology: BUT it is also a (very smat) I/O technology!! Sure it is! Why not?

So, is IEC 61850 competing with AS-i? No! I have written the first draft of the AS-i standard (IEC 62026-2) … some 20 years ago. It could provide the data we model and communicate to a higher level in an automation system. Data about a simple switch status or whatever. In the same way a Modbus device could provide I/O-data to an IEC 61850 server that provides input to a higher layer IEC 61850 or …

Yes, many signals are simply I/O data. IEC 61850 can handle them all …

What is the main difference between IEC 61850 and many of the field busses? Simply this: IEC 61850 applies an event-driven approach with DataSets and Controlblocks while most field busses run cyclic polling by a master device. The master polls for values … one field device after the other … again and again … IEC 61850 works like this:

image

IEC 61850 is usually (if used that way!) communicating useful information rather than bunches of Data – that just may tell the receiver: nothing has changed, nothing has changed, nothing has changed, … stop here and make it smarter. This could easily applied when Ethernet infrastructure is in place anyway.

This is one of the major paradigm shifts in process information exchange … that will take decades to understand by …

Thursday, March 6, 2014

Brief EPRI Report on Standards of DistribuTech 2014

EPRI has published a Brief Report of DistribuTECH 2014.

It seems that a hot topic was “DATA” … data from everywhere of everything! Sure there is a need to share the pool of “Big Data”. I have heard about a SCADA project that receives Terra Bytes of “big Data” from a huge wind power park trough IEC 61400-25. This seems to be “Big Data” and “little information” … good for hardware manufacturers.

The EPRI Brief reports from the DistribuTech 2014:

“This was also another good year for standards. The vendor community has heard loud and clear that standards are a preference of electric utilities and the vendors have done a good job of promoting where they are using standards including DNP3, IEC 61850, IEC 61968/61970 (the CIM), MultiSpeak, and more. One relatively new standard that had a strong presence was OpenADR (Open Automatic Demand Response).”

Click HERE for the complete report.

I hope that they are looking at useful information rather than bunches of Data – that just may tell the receiver: nothing has changed, nothing has changed, nothing has changed, … stop here and make it smarter:

image

This is one aspect of the philosophy of IEC 61850 – which needs to be understood by more people … it will take some time to understand this.