Ws-* provides basics like messageId, endpointRef and most importantly, a place for extensions (custom headers). It does not provide though content metadata/desc (ebMS), distinction between signals and user messages, message sequencing and grouping (batch style), boxcarring, optimistic or pessimistic protocol (resendrequest or ACK/NACK).
So, in short, WS-A is a great framework upon which to build.
Best is to start with requirements.
I can donate the requirements that led to our internal development effort as I have also done the same in iso20022 which now has a business app header and a file header pending.
-D
For identifying endpoints, WS-Addressing is the way to go. I'm not so
interested in pushing a lot of mechanism on multihop, but endpoint
identification is critical. Derek, how much needs to show up in the
Energy Interop spec? I'd like to stick to WS-Addressing and perhaps
possible profiles.
Thanks!
bill
Derek N LaSalle wrote:
82ADB140D56CC34B83B6B3F4A982B70006353384E5@EMASC214VS01.exchad.jpmchase.net" type="cite">
Great enrichment Tim.
We achieved multi-hop by implementing WS-Addressing endPointReference
extension of Target chains and SOAP UltimateDestination attribute over
AS4 profile.
Tracking ebMS 3.0 is a good idea. Thx.
And I would like to remind everyone that ebMS 2.0 is a mature OASIS
standard for data exchange transport and has a very mature stable of
interoperable implementations -- Drummond Certified interoperable if I
may shamelessly plug. Beyond that, ebMS 3.0 is more firmly based on
WS-* standards that is really one of the only standards group that is
addressing WS mult-hop scenarios, which I think may be pertinent to
nodal smart grid distribution designs. ebMS 3.0 also has a streamlined
profile called AS4, which is targeted at simplified, interoperable WS
data exchanges.
Derek N LaSalle wrote:
82ADB140D56CC34B83B6B3F4A982B70006353384E2@EMASC214VS01.exchad.jpmchase.net" type="cite">
We leverage
ws-addressing w/ ebMS user and signal message body
components. This allows piggy-backing of signal messages with user
messages which optimizes flow utilization especially when combined w/
box-carring (message groups). WS-* adherence provides the benefit of
widespread development tools and software services support from
commercial vendors and open source. This includes W-SecureConversation
for authentication and authorization.
Regards,
Derek LaSalle
Head of Information Architecture
JP Morgan Investment Bank
Bob,
Great comments, thanks!
I agree with everything on A - thanks for the emergency/reliability
signal reminder. I talk about this all the time, don't I? I think they
are very similar and the only difference may be the issue/notification
time.
On B - this is a meter access issue. I am assuming it also depends on a
contract outside of the b2g interface. If the meter access is a
standard communication (with security), any entity that the customer
allows can have access. As far as double dipping - yes the priority and
communication has to happen at the level where your kWs are valued (so
still not at the b2g interface)
On C - Not at the B2G interface but a good thing to think about on the
utility side.
On D - looks like more discussion is needed.
Sila
On 2/3/2010 6:52 AM, Old, Bob wrote:
A9B77DA2F009964B8C55C575F04A9CB8057BC011@USLZU102MSX.ww017.siemens.net" type="cite">
Hi
Sila,
I
would like to add:
A.
In
the Grid to Building direction:
a.
I
think
there should be separate Emergency/Reliability signals, not just
price. The
signal should be clear and not blurred by mapping to a price.
b.
Especially
with DER becoming more prevalent, upcoming maintenance/outage
management events
need to be announced. Buildings would like to know when to turn on the
backup generators. And the construction crews would appreciate the
building make the circuits safe for them.
c.
A
unique Program Identifier is required because the building/meter/feeder
might
be involved in a number of programs with a number of different service
providers.
d.
Other,
program specific information is required. As usual, Ed homes in to the
heart of it in the Curtailment program example, the baseline.
B.
In
the Building to Grid direction:
a.
To
whom does the custodian allow access to the data, for how long, which
items,
and when each item was effective? And where should the custodian send
the
report of who accessed what and when of my data. I don’t want
to be promiscuous with my data—I wouldn’t want burglars to identify
when my facility will be closed for Founder’s Day.
b.
Since
I may want to sell curtailment to more than one CSP, I will have to
permit both
to access the same data. I leave it up to them to figure out a way to
make sure I’m not selling the same curtailment to two CSPs. Though
if someone can come up with a clear mechanism, I would love to hear it.
C.
Trusted
custodian of the data:
a.
Electricity
Distribution Entity – the one who has the data, now. Is always
affected by the load on the distribution infrastructure. Is the
natural
monopoly the will likely always be regulated by politicians.
b.
Root
Certificate Authority-like entities. Used to authenticating.
Verisign doesn’t give me warm fuzzies, though.
c.
Others
you suggest.
D.
And
while I was blathering away here, I see Toby’s assessment
of customer forecasts. I like it. What’s it worth to
ya? Perhaps it’s a clause in the Program.
So
much for fun, back to work,
B.O.
February 3, 2010
Robert
Old
Siemens
Industry, Inc.
Building
Technologies
1000
Deerfield Pkwy.
Buffalo
Grove, IL 60089-4513
Tel.:
+1 (847) 941-5623
Skype:
bobold2
bob.old@siemens.com
www.siemens.com
From: Larry
Lackey [mailto:llackey@tibco.com]
Sent: Tuesday, February 02, 2010 11:23 PM
To: Sila Kiliccote; Ed Cazalet
Cc: Considine, Toby (Campus Services IT); Energy Interop
Subject: RE: [energyinterop] Scope questions for discussion
Great
start, Sila. To the list
I’d suggest adding the building or facility’s bid/ask price for
consumption/DER over the relevant time period(s).
This
could, and probably should,
be iterative with the “Grid”, which might be multiple institutions,
providing forward costs for different intervals and buildings
responding.
Larry
From: Sila
Kiliccote [mailto:skiliccote@lbl.gov]
Sent: Tuesday, February 02, 2010 9:30 PM
To: Ed Cazalet
Cc: Considine, Toby (Campus Services IT); Energy Interop
Subject: Re: [energyinterop] Scope questions for discussion
If the grid has
the
historical data
from each facility plus weather data from each location, it can
generate
forecasts for each building as well as the aggragate. The building's
prediction
is an fyi for the grid This happens in the grod between utilities and
ISOs all the time sort of like a check/balance but may not be
necessary if not trusted.
The
grid usually forecasts load in the aggregate. What is
the building forecast for? If it is a baseline for a DR program, then
who
should be responsible for the forecast? The customer should not do it,
because of the incentive to bias the forecast.
From:
Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Tuesday, February 02, 2010 7:31 PM
To: Energy Interop
Subject: RE: [energyinterop] Scope questions for
discussion
Traditionally,
building load management has been crude, and
aggregated in certain large time granules. Industrial sites, however,
have had
strong incentives to manage peaks.
As
operating safety margins get smaller, it may become
increasingly important to manage peaks aggressively, even within the
neighborhood or even home. Is some sort of detailed peak /load shape of
interest in the new world? What about power factors? Is the forward and
backward reporting of curves rather than points of measurement the
future of
smart metering?
tc
"If
flies are allowed to vote, how meaningful would a poll on
what to have for dinner be, and what would be on the menu?" -
Unknown
From: Sila
Kiliccote
[mailto:skiliccote@lbl.gov]
Sent: Tuesday, February 02, 2010 6:09 PM
To: Energy Interop
Subject: [energyinterop] Scope questions for discussion
All,
David Holmberg
and
I had a great conversation today on the
scope of EI (which will hopefully feed into section under discussion).
I’d like to open up some of my ideas and get your feedback before I
propose a few paragraphs for the scope section.
I’d like to
look
at the scope from a B2G
interface point of view and the questions I suggest we try to answer
are:
1.
What information do the buildings
need
from the
electricity grid?
2.
What information does the
electricity
grid need from
the buildings?
Buildings’
need from the
Grid:
- Electricity prices
(various forms such as absolute,
relative, level,
etc)
- DR contract parameters
– excluding direct load control: A
contract
can have the following parameters:
- Issue time,
start time, end time
- Within the start time and end
time there may be a request
from the grid
for load reduction (%, absolute, relative, etc) (or load increase -
when there
is too much generation)
- Power quality (Do we care how “good” the power
we get from the Grid? Probably! What are the indicators to be
communicated to a
building?
- Location of the resources needed
Grid’s need
from
buildings:
- Measured (current,
historical) demand
- Predicted demand
- Available DR (over next
24 hrs?, 1 week?)
- Location identifier (meter, address, grid location
indicator?)
I welcome
your
comments. All of the above assumes that
the meter is the demarcation point. And just to add, the expansion of
this to
DER can be again categorized as on the utility side and on the building
side
but should be a super set.
Sila
This
email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of securities,
accuracy and completeness of information, viruses, confidentiality,
legal privilege, and legal entity disclaimers, available at
http://www.jpmorgan.com/pages/disclosures/email.
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of securities,
accuracy and completeness of information, viruses, confidentiality,
legal privilege, and legal entity disclaimers, available at
http://www.jpmorgan.com/pages/disclosures/email.
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.