|
The curse of enumeration
by Dennis Holstein,
Publisher
January, 2000
|
How many fish are there
in the Sea - let's count them one-by-one.
Once again I mount my soap box to preach against the evil empire of
enumeration. We all know that Substation Automation requires reliable
communication between Intelligent Electronic Devices (IEDs), and that
information exchanged must be automatically interpreted by the receiver.
Simply stated, both sender and receiver must speak the same language
without ambiguity. Formally, the language is known as the
"semantics" of the data model. The question is: "How to define the
semantics of the data which is packaged for communication over a
Substation Local Area Network, or over the Utility's Wide Area
Network."
The approach taken by some "experts" in the standardization
community is to enumerate all data objects that will be exchanged. If the
data objects are specified in standard, then all vendor products which
conform to this standard, regardless of the manufacturer, will send and
receive data objects that are unambiguously defined. Truly a noble goal,
because the holy grail called interoperability is in place!
Every time I create one "standard" data object, two more
variations are created
So the task is to simply assemble a table of all standard data objects.
Well let's not be ridiculous. It is a much better idea to take a modular,
building-block approach to the specification. Perhaps a few well
specified data objects can be specified, reused and extended to build each
data object. Good plan -- what are the building blocks?
 | All data needs to be time-stamped. Good start - a building block
that specifies time. |
| All data has a unit of measure, which should be standard. Good
plan - a list of attribute names, each of which has only one unit of
measure. These names can easily be extended using qualifiers to
specify the exact data type and format. For example, a measurement
may be qualified as measurement.volts.float32, which means that the
value assigned to measurement is volts represented as a floating
point 32 bit number. For the object-oriented gurus we
have a polymorphism, the variable called measurement can be amperes,
volts, and can be represented as an integer or a floating point
number. |
| All data object attributes need a name that defines the semantics
of the variable. Ugh! There are as many names as there are fish in
the sea. Not a good idea, let's put this concept aside. |
| Since power system devices with embedded IEDs are in place to do
something beside talk to each other, data objects describing
operating parameters and configuration parameters need to be
specified. This type of enumeration is as ugly as the enumeration of
all attribute names. Not a good idea, let's put this aside also. |
 OPUS Subscribers are hard at
work finding a practical solution to the curse of enumeration.
Well, two good ideas is not a bad start. What should we do about the
bad ideas? Clearly, interoperability requires a complete understanding of
the semantics of the information exchanged. But attempting to enumerate
every instance of a data object and the name of every attribute is simply
not practical. After three long years of trying, some of the experts in
the standardization community are coming to the same conclusion. However,
the battle is not won until a framework is offered to achieve the same
objective.
The feedback that we get from our subscribers is beginning to offer
some real hope. Basically, the idea is this: the rules for naming an
attribute, and the rules for defining data objects, need to be standardized
by the experts. Enumeration should only be used to prove that the rules
work in an unambiguous way.
We are interested in your opinion, so please take some time to send me
an EMAIL at holsteindk@aol.com
with your contribution on how the rules should be specified. We will
continue to report on the Curse of Enumeration that flows from each
standardization venue in Que Pasa, which is only available to OPUS
Subscription Service subscribers. |
Where do you want to go now?
  
|
WiseOwl™