Sorry, this should have been on the list all along.
There is a lot of interesting stuff in this thread, please read it all and chime in.
tc
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
Toby Considine 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 http://www.tcnine.com/ |
From: Anne Hendry [mailto:ahendry@pacbell.net]
Sent: Friday, March 25, 2011 9:24 PM
To: Gerald Gray
Cc: Toby.Considine@gmail.com; 'Bartell, Bruce'; 'Aaron Snyder'; 'William Cox'; 'Ed Cazalet'; 'Joshua Phillips'; 'Rish Ghatikar LBL'; ''David Holmberg''
Subject: Re: Items for measurement and sale and pricing
Yes, I think it's a situation of comparing apples to oranges. Whereas CIM appears to be focused on the development of a model and APIs for EMSs, and defning architecture for middleware, all I was talking about originally were the units themselves and their symbols, nothing to do with the models being developed around those, or how the units are conveyed in messages.
My primary question was, when this standard is released and implemented, will it be usable in SA or Canada (or other countries that use different systems of measure than the US)? For instance, if we send a message to, say, Canada and the unit is 'meter', but they expect 'metre', or we send 'metric ton', and they expect 'tonne', is that going to be an issue? The best way to avoid that is to either use a code list that has all the above, or decouple the code values from the implementation. I favor the latter to give users flexibility.
The only reason it came up is that there were discussions around the units when discussing the CIM, and it appeared there were units hard-coded into the CIM Model.
Now, a loooong time ago I recall trying to find out if the CIM was based on un/cefact CCTS (core components technical specification), because I came across some presentations like this one from Jean LucSanson:
http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBQQFjAA&url=http%3A%2F%2Fcimug.ucaiug.org%2FGroups%2FEAII%2FUNCEFACT%2520Methodology%2520for%2520CIM-Jean-LucSanson.ppt&rct=j&q=cim%20core%20components&ei=FjmNTY60KJOisAPa-amCCQ&usg=AFQjCNE94bRN-j_DU21FQiDeluZ4o7ZVYw&cad=rja
(sorry for the very long url)
The slide set is from 2005. I wondered if this had, in fact, been done?
It would most likely be evident in aspects such as the iso 11179-based naming (object class, property term, representation term)
and the 10 basic dataypes (slide 23).
And perhaps slide 25 might make some sense.
The EA file I sent you after the OpenSG meeting is the implementation of CCTS for several areas of ecommerce (UBL).
-A
Gerald Gray wrote, On 3/25/2011 5:26 PM:
Hi Toby, I may be able to shed some light on this, although Aaron may be able to speak more eloquently re:SI units.
To refer to OpenSG CIM or US CIM is a bit of a misnomer. The “CIM” is the IEC 61968, IEC 61970 international standards, so there isn’t a “US” CIM.
What the OpenSG developed as part of say for example, OpenADR, was a CIM extension; that is, the embodiment of business requirements represented in artifacts that leveraged CIM (the International standard- not a US standard), with other reference models contributed from the IRC (CIM-based, not CIM exact) and SEP2 (CIM-based, not CIM exact). Where the CIM provided a normative reference it was used. Where gaps existed in the CIM extensions were created to address those business requirements. Eventually those extensions would have to be fed back to and vetted by IEC TC57 WG14 for inclusion in a future edition (the other path is of course NASEB which work has been on-going to ensure alignment with that body).
IEC 61968/61970 is for meter reading and control and the application integration of said information, and is based on UN/CEFACT. In WG14 there have been discussions on future editions of the CIM using SI units (perhaps Aaron can fill in some here). At this point in time, IEC 61968/61970 1st Edition is the normative reference until such time that the 2nd Edition is formally released. Where there is clear normative guidance from IEC 61968/61970 it will be used.
Regards -
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Friday, March 25, 2011 7:12 PM
To: 'Bartell, Bruce'; 'Gerald Gray'; 'Aaron Snyder'; 'William Cox'
Cc: 'Anne Hendry'; 'Ed Cazalet'; 'Joshua Phillips'; 'Rish Ghatikar LBL'; ''David Holmberg''
Subject: RE: Items for measurement and sale and pricing
There is a multi-part problem here, that includes:
The international TC57 CIM team, that does not appear to be moving in parallel with the OpenSG CIM
There is the stated intention of the IEC to harmonize with the more fundamental ISO standards
Scale/Multiplier/whatever.
The fundamental document is behind an ISO paywall, but the canonical US version of that document, alas not an XSD I have found yet, is here.
http://physics.nist.gov/cuu/Units/
Anne summarized the fundamental issues well in the attached email, which should guide the CIM work when it comes to fundamental units. The US CIM is not enough, we need the international CIM for this to be a complete success, and the guidance we have gotten internationally is a move to alignment with the ISO terms.
The Chantilly agreement was that we will use the CIMs for each domain as appropriate, with an eye toward internationalization and getting out of silos. Clearly, TC57 is the CIM for Power and Load Management. UN/CEFACT is the CIM for international trade facts. ISO200022 is the CIM for financial trades. The new PAP will get NOAA to lead the development of the CIM for weather.
tc
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
Toby Considine 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 |
From: Bartell, Bruce [mailto:bbartell@xtensible.net]
Sent: Friday, March 25, 2011 4:16 PM
To: Gerald Gray; Toby.Considine@gmail.com; Aaron Snyder; William Cox
Cc: Anne Hendry; Ed Cazalet; Joshua Phillips; Rish Ghatikar LBL
Subject: RE: Items for measurement and sale and pricing
Thanks Jerry.
Toby & Bill – do we still need to have session to review the CIM model for these items?
From: Gerald Gray [mailto:gerald.gray@guiding-principle.com]
Sent: Friday, March 25, 2011 4:11 PM
To: Bartell, Bruce; Toby.Considine@gmail.com; 'Aaron Snyder'; 'William Cox'
Cc: 'Anne Hendry'; 'Ed Cazalet'; 'Joshua Phillips'; 'Rish Ghatikar LBL'
Subject: RE: Items for measurement and sale and pricing
I don’t know if this will be helpful but I thought I would take a stab at generating an equivalent “CIM-ish” power profile for comparison against the current emix power hierarchy.
In CIM the fundamental structure looks like this (I dummied in the PowerTypes):
I have also attached an XSD to reference. Ignore the namespace as I just filled in an example for the purpose of this exercise.
From: Bartell, Bruce [mailto:bbartell@xtensible.net]
Sent: Friday, March 25, 2011 1:00 PM
To: Toby.Considine@gmail.com; Aaron Snyder; William Cox
Cc: Anne Hendry; Ed Cazalet; Joshua Phillips; Rish Ghatikar LBL; Gerald Gray
Subject: RE: Items for measurement and sale and pricing
Bill, we can review the cim.eap model again so that you can find the power/energy units and can bring them into your model.
From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine
Sent: Friday, March 25, 2011 12:18 PM
To: 'Aaron Snyder'; 'William Cox'
Cc: Bartell, Bruce; 'Anne Hendry'; 'Ed Cazalet'; 'Joshua Phillips'; 'Rish Ghatikar LBL'
Subject: Items for measurement and sale and pricing
Thanks for the guidance yesterday. We have a strong need for something that has a string description, that has units, that has scale(multiplier). It doesn’t always have a quantity (it might be part of a price announcement) Even when it has a quantity, it may not have anything to do with a measurement. It may be in a block purchase tender. It may be in granularity (this market only accepts bids in multiples of 50MW). So it is not measurement.
As some of you know, Ann worked long in the development of UBL (Universal Business Language), the underlying CIM of e-commerce, including supply chain management and negotiations, and, surprisingly, international commercial regulation and law enforcement. I asked her what it was, with her UBL hat on. It appears it is the item.
In UBL, the Item is the minimal specification that appears in many business documents with the term Item. There are items on a PO, items on a Requisition, Items on a Bill of Lading, Items on … Sometimes they have a price (PO). Sometime that have only a quantity (Shipping documents), sometimes neither, yet. Sometimes they are abstract in odd ways from the underlying product (think of the relationship between board-feet and the wood actually in that home extension with 10.5 ft ceilings.
So I think the xml below meets the spirit of the request. If there is no objection from this crowd, I will move it into the respective Jira notes, and resolve and close them.
First, in EMIX, there is the SiScale (as before) and untyped type and units. (I’m sorry, I went through several EAPs and still did not find the names you wanted. Subject to the discussion elements are still easy to rename.
<xs:element name="itemBase" type="emix:ItemBaseType" abstract="true" />
<xs:complexType name="ItemBaseType" abstract="true" mixed="false">
<xs:annotation>
<xs:documentation>Abstract base class for units for EMIX Product delivery, measurement, and warrants. Item as in UBL PO Item, Requisition Item, Lading Item. Item does not include Quantity or Price, because a single product description or transaction may have multiple quantities or prices associated with a single item.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="type" type="xs:string"/>
<xs:element name="units" type="xs:string"/>
<xs:element ref="emix:scale"/>
</xs:sequence>
</xs:complexType>
Note that the type above is abstract, meaning no-one can use the un-specified strings, but they can extend them. Next, in power.xsd we have the power-specific items:
The base classes for power and energy, also abstract:
<!-- 9.9.3 Energy Base Class -->
<xs:element name="energyItem" type="power:EnergyItemType" substitutionGroup="emix:itemBase" abstract="true"/>
<xs:complexType name="EnergyItemType" mixed="false" abstract="true">
<xs:annotation>
<xs:documentation>Denominations for the measurement of energy</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="emix:ItemBaseType">
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- 9.9.5 Power Base Class **-->
<xs:element name="powerItem" type="power:PowerItemType" substitutionGroup="emix:itemBase"/>
<xs:complexType name="PowerItemType" abstract="true" mixed="false">
<xs:annotation>
<xs:documentation>Denominations for the sale and measurement of Power</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="emix:ItemBaseType">
<xs:sequence>
<xs:element ref="power:powerAttributes"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="powerAttributes" type="power:PowerAttributesType"/>
<xs:complexType name="PowerAttributesType">
<xs:sequence>
<xs:element name="hertz" type="xs:decimal"/>
<xs:element name="voltage" type="xs:decimal"/>
<xs:element name="ac" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
Energy:
<!-- 9.9.2 Energy Units -->
<xs:element name="energyApparant" type="power:EnergyApparantType" substitutionGroup="power:energyItem"/>
<xs:complexType name="EnergyApparantType" mixed="false">
<xs:annotation>
<xs:documentation>Apparent Energy, measured in volt-ampere hours (VAh)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="power:EnergyItemType">
<xs:sequence>
<xs:element name="type" type="xs:string" fixed="ApparantEnergy"/>
<xs:element name="units" type="xs:string" fixed="VAh"/>
<xs:element ref="emix:scale"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="energyReactive" type="power:EnergyReactiveType" substitutionGroup="power:energyItem"/>
<xs:complexType name="EnergyReactiveType" mixed="false">
<xs:annotation>
<xs:documentation>Reactive Energy, volt-amperes reactive hours (VARh)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="power:EnergyItemType">
<xs:sequence>
<xs:element name="type" type="xs:string" fixed="ReactiveEnergy"/>
<xs:element name="units" type="xs:string" fixed="VARh"/>
<xs:element ref="emix:scale"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
And Power:
<!-- 9.9.4 Power Units -->
<xs:element name="powerApparant" type="power:PowerApparantType" substitutionGroup="power:powerItem"/>
<xs:complexType name="PowerApparantType" mixed="false">
<xs:annotation>
<xs:documentation>Apparent Power measured in volt-amperes (VA)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="power:PowerItemType">
<xs:sequence>
<xs:element name="type" type="xs:string" fixed="ApparantPower"/>
<xs:element name="units" type="xs:string" fixed="VA"/>
<xs:element ref="emix:scale"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="powerReal" type="power:PowerRealType" substitutionGroup="power:powerItem"/>
<xs:complexType name="PowerRealType" mixed="false">
<xs:annotation>
<xs:documentation>Real power measured in Watts (W) or Joules/second (J/s)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="power:PowerItemType">
<xs:sequence>
<xs:element name="type" type="xs:string" fixed="RealPower"/>
<xs:element name="units">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="W"/>
<xs:enumeration value="J/s"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element ref="emix:scale"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="powerReactive" type="power:PowerReactiveType" substitutionGroup="power:powerItem"/>
<xs:complexType name="PowerReactiveType" mixed="false">
<xs:annotation>
<xs:documentation>Reactive power, measured in volt-amperes reactive (VAR)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="power:PowerItemType">
<xs:sequence>
<xs:element name="type" type="xs:string" fixed="RealPower"/>
<xs:element name="units" type="xs:token" fixed="VAR"/>
<xs:element ref="emix:scale"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
"If something is not worth doing, it`s not worth doing well" - Peter Drucker
Toby Considine 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 |