What Does Complexity of a Protocol Mean?

There is always a discussion on one protocol being more efficient and less complex than another or all other. Does this discussion help? I don’t think so.

The key issue is the “SYSTEM” – which is MUCH more than a protocol.

Let’s discuss briefly the configuration of a device with regard to reporting a value based on a deadband configuration and the range and multiplier of an analog value.

Usually the deadband values and range configurations and other crucial information are specified in a pdf file or – if you are lucky – in an excel sheet or XML file. So, to interpret a message the receiver has to know the configuration. The tables contained in the pdf file (below) have to be translated by somebody manually … and how can I find out in 10 years from now, what the limits of the Band width voltage are? Hm. No idea?! Usually you cannot ask the device. So, what now?

I am sorry, if you don’t have the pdf you may guess what the limits are – but you don’t know. Maybe somebody from the vendor is still there and can answer the question.

Example of a DNP3 SPECIFICATION - DEVICE PROFILE

Excerpt on deadbands and configuration:

A good thing is, that many vendors publish these files. Sur, you never know if they are up-to-date or applicable for your device you installed some time ago.

The information models of IEC 61850 provide dedicated attributes for a value that provide these meta data like deadband configuration, min, max, multiplier, SIUnit. These attributes could be used in the corresponding SCL file only or they could additionally be exposed by the device and made accessible through a simple read message.

With IEC 61850 in place we could easily expose the limits of power production and load and further attributes. The logical node MMXU (IEC 61850-7-4) could be used for the limits in which a value is valid:

Data Object TotW of class MV (measured value, IEC 61850-7-3) - Total active power (total P)

could provide the actual value, quality, range, Scale, limits, units, deadband in the details provided through the MV CDC:

mag.f	deadband filtered AnalogueValue coded as floating point
q	Quality
range	ENUMERATED normal|high|low|high-high|low-low (out of range would change quality value)
rangeC	RangeConfig: hhLim hLim lLim llLim min max
sVC	ScaledValueConfig (scale and offset) for Integer values
db	Deadband filter in % of range (min – max)
units	SIUnit and multiplier

min: the min (minimum) attribute shall represent the minimum process measurement for which values of i or f are considered within process limits. If the value is lower, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

max: the max (maximum) attribute shall represent the maximum process measurement for which values of i or f are considered within process limits. If the value is higher, q shall be set accordingly (validity = questionable, detailQual = outOfRange).

In our case, the TotW for the CHP generator may be limited between 0 W (min) and 35 kW (max). A value of “minus 600” MW would have to be flagged as questionable and outOfRange !! Negative values and values higher than 35 kW would be flagged out of range!

The receiver (a control center) could check the limits of the values (either by reading the range configuration online by a service or getting it from the corresponding SCL file). It could figure out that the range is 0-35 kW. Even if the gateway (RTU) would send “minus 600” MW (load) … the CC could understand that this is a bad value – recommended not to use.

The ScaledValueConfig exposes the scale factor and offset value – required to interpret an integer value.

The deadband db defines when to report a new value: when a change of the value is “+/- db of the range”: a range of 100 A and db=2000 (2 %) means –> every change of 2 A will be reported; the last reported value was 78 A, then the next report will be issued when the value reaches 76 A or 80 A.

The units contain the SIUnit (e.g., A) and the multiplier (10**0 –> 1).

The meta-data of the measured value serve as a means to help interpreting the plausibility and validation of a value communicated.

To focus on a message “Report a changed value based on a deadband configuration” and discuss which protocol does it more efficient is not helpful! Modbus can communicate the total Power – as can any other protocol. But: HOW to INTERPRET a received value? Is the value within the limits defined for an application? Is the value given in W, kW, MW or GW??

A system should be able to provide more than just A value – all crucial meta data that help to interpret the value are needed in any case. Either you get it – or …

Please focus on the “System” – a holistic approach is what we need.

This blog post will likely not stop protocol efficiency discussion … ok. And?

If it makes you happy when you discuss protocol issues … do it.