We should move this discussion
to JIRA
http://tools.oasis-open.org/issues/browse/EMIX-291
All
--
I
hope this adds
focus from a different perspective.
We have two major requirements we need to address.
(1) In EMIX we need to address ENERGY MARKET
INFORMATION not just ELECTRICAL
energy market information.
We'd rule out existing energy markets were we to say
"only electrical
Energy Markets". For example, thermal is mentioned
in the charter which
would require units appropriate to low pressure
steam, high pressure steam,
chilled water, ice storage, and mineral salts
storage. District energy and the
others are all forms of energy with prices and
markets.
(2) Consequently, EMIX needs to be extensible
beyond the scope of IEC TC57
Power Management - and of the TC57 work we only
need a subset that is relevant
to power markets. For example, the units from CIM
14 include ones that would
never go to a market.
It's not reasonable to think that the Power
Management CIM would adequately
address the extensibility and information modeling
needs of things that are
outside their scope. So an extensible mechanism
is required to describe
products and resources. For example, in a natural
gas market (and where you
make tradeoffs between NatGas and other sources of
thermal energy) you'd need
CCF and Therms, neither of which are clearly in
the UnitSymbol enumeration in
CIM14. And is "g" grams or gallons?
Analysis:
Therefore even if you started with the UnitSymbol
enumeration you'd have to add
to it. This is a problem with enumerations. How do
you add to an enumeration in
a manner that's extensible not by a TC but by
someone using the standard in a
way that we didn't plan? The list is neither
comprehensive nor
sufficient, and most of it is not needed for the
Electrical Energy Markets
(only VA, VAr, J/s, J, and a few more).
That the CIM 14 list is inadequate is clear. We
need to be unrestricted in the
units that can be used (again, unreasonable to
assume that the Power Management
CIM would address the other domains). In a
specific domain (say chilled water)
the units need to restricted and specific -- all
of the things I mentioned may
have units not on the presumed list.
Anything expressed in the current wd23 schemas
(without extensions) can be
expressed in CIM14, and unambiguously.
Minor issues:
(3) This is also a conformance issue--if the units
or scale factor are mixed.
We'd have valid XML but not valid information
exchange. The more ways we can
generate valid XML (with respect to schemas) that
are NOT valid information
exchanges, the harder it is to automate validation
of message payloads.
In CIM 14 the multiplier and value are optional
(say in ApparentPower), with
only the unit string static/readonly/final as
"VA". This is
less useful than it might appear - we have for
e.g. power ramps two values, and
in some other cases three values. You can't factor
out the units, and for
automated processing you'd need to ensure that all
the values are of the same
units. Whereas you can have a unit that is applied
to all three values - no
need for a separate multiplier, unit, and value
for each of three, just include
one multiplier/scale factor, one unit, and three
values, all subject to
automated validation and guaranteed consistent.
The IRC has asked for information artifacts that
so far as possible can be
automatically validated. Custom code in every
implementation to compare units
is more cost and work than needed when the units
and scale factor are addressed
in XML validation to the schemas.
(4) The scale factor is adopted directly from
Gerry Gray's contribution.
(5) the CIM technique of final/readonly/static
does not work across schema
files; XML Spy (my tool of choice) rejects it as
invalid
Thanks!
bill
On 4/12/11 9:07 AM, Bartell, Bruce wrote:
I have attached the list of unit enumerators with the
documentation on usage. Note that for example VA
has the comment:
“Apparent power in volt ampere”.
The associated UML has VA as
the initial
value for unit as part of the ApparentPower class.
If you are worried about
misuse, I suppose this could be coded as a
restriction pattern in the schema,
although I have not seen it handled like that.
I have been
developing and coding with the proposed
changes to the POWER.XSD and they allow some very
strange outcomes. If I follow
the schema, and use no knowledge I have already,
Apparent Power can be
expressed in a number of units, including Ohms,
Radians, Degrees, Hertz, and
Kilograms/Joule (and many others). This reduces the
usability of the schema and
makes many obviously invalid information exchanges
(in terms of “you
can’t buy that”) fully valid (in schema validation
terms). This
reduces the utility and value of the artifacts
produced in inter-domain
exchanges.
They also
break compatibility between the unification
of measurement types urged by PAP10, in that they
establishes special
sub-classes of names of units and for that are used
within Power that are used
for no other areas of emix, for example, in quality
measures, or in pollution
warrants. By restricting in the schema all
measurement types to a defined set
only useful for power, they will require revisions
to the standard to extend
the classes to new metrics, say to new pollutant
types, or to include carbon
trading. If we reduce the base fungibility of
measurements in this way, we
decrease the ability of EMIX-based systems to
respond to new market dynamics
and new market regulations without returning to the
standards cycle. This sort
of hindrance to adaptability violates a core precept
of EMIX which is to enable
more rapid productization of technologies and energy
approaches.
EMIX as it has
grown establishes some core models for
exchanging information about products whose value
changes with time of
delivery. Power is but one of these. Certificates /
Pollutants / carbon trading
/ et al. are significant others that are closely
tied to power markets, and are
likely to be more so in the future. These markets
are much more changeable than
the base power exchanges. Power quality metrics vary
distinctly between US, European,
and Asian market already. We want to make sure that
our approach handles these
different metrics, including ones we do not know,
without returning to the
standards process.
EMIX already
has a clear distinction between the base
schema, and the particular instantiation of its
extensions for power. Other
groups are already looking at developing their own
extensions for other
energy-related products whose value changes with
time. There are discussions
underway about using domain extensions for the
distribution of natural gas, low
pressure steam, high pressure steam, chilled water,
and other district-based
distributions. When we move to an exceptionality for
power, we reduce the power
of the results.
None of this
is meant in any way to deprecate the importance
of alignment with the IEC TC57 CIM, particularly as
the IEC itself continues
its growing alignment with ISO where there subject
matters overlap. I mean
instead to that we have not achieved the optimal
alignment. Of course, we need
to keep ever mindful that alignment is not the same
as unity.
tc
“The single
biggest problem in communication is
the illusion that it has taken place.”
– George Bernard Shaw.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php