OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emix] New Power Item Type proposals


Re: 1&2. The enumeration list can be restricted or expanded as needed by EMIX. CIM profiles are used to limit the values in use of specific messages; extensions can be submitted to the working groups.

Re: 3. I don’t agree that they should be optional. We can tighten our restriction and still be compliant.

4. Hope they are the same; we pulled the lists from the same UML model.

5. We need to talk about no. 5. Does across mean when using import or include? We had a similar problem earlier that resulted from an incorrect namespace prefix. I believe we did get it to work.

 

We should move this discussion to JIRA  http://tools.oasis-open.org/issues/browse/EMIX-291

 

 

Bruce Bartell

Xtensible Solutions

Mobile: +1.321.258.6500

bbartell@xtensible.net  |   www.xtensible.net


From: William Cox [mailto:wtcox@comcast.net]
Sent: Tuesday, April 12, 2011 2:10 PM
To: Bartell, Bruce
Cc: Toby.Considine@gmail.com; emix@lists.oasis-open.org
Subject: Re: [emix] New Power Item Type proposals

 

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

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

 



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.

 

Bruce Bartell

Xtensible Solutions

Mobile: +1.321.258.6500

bbartell@xtensible.net  |   www.xtensible.net


From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Saturday, April 09, 2011 8:07 PM
To: emix@lists.oasis-open.org
Subject: [emix] New Power Item Type proposals

 

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.


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

 
 
---------------------------------------------------------------------
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 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]