RE: [obix-xml] RE: [obix] Contracts in v1.1

Thank you for that precision. 

 

So perhaps the issue is that we
have never made explicit enough that for now, the defining of new levels of
standard contracts is an “extra-oBIX” activity. That statement
tickles some long inactive memories, and feels more like we said way back when.
Indeed, we may have claimed then that that gave us a security feature….

 

If so, then the only new piece is
being able to trend invocation of contracts as anything else.

 

Let me touch base with the silent
and see if the perspective you have refreshed in my mind meets their needs…

 

tc

 

"When one door closes,
another opens; but we often look so long and so regretfully upon the closed
door that we do not see the one which has opened for us." -- Alexander
Graham Bell

 

  
  
Toby Considine

  
Chair, OASIS oBIX TC

  Facilities Technology Office

  University of North Carolina

  Chapel Hill, NC

  
  
  
  

  
  
  
Email: Toby.Considine@
  unc.edu

  Phone: (919)962-9073 

  
http://www.oasis-open.org 

  
blog: www.NewDaedalus.com

  
 

 

 

From: Brian Frank
[mailto:] 

Sent: Tuesday, May 27, 2008 9:06 AM

To: Considine, Toby (Campus Services IT); Paul Ehrlich;


Cc: 

Subject: RE: [obix-xml] RE: [obix] Contracts in v1.1

 

Just to clarify – contracts do not need to be defined in the
lobby – they are simply URLs to an XML document that describes a
“type”.  Although certainly a system could publish all the
contracts it supports under the lobby.  In Niagara we typically publishes
all its contracts under “/obix/def/”.

 

Anyone can define contracts including system integrators –
contracts are just an XML document at a given URL.  The question is really
how easy does a given vendor’s tools make creating contracts for
non-programmers.  In Niagara, just about everything is accessible in the
oBIX namespace, so pretty much everything a system integrator does is published
via oBIX.

 

Building up a library of predefined contracts is of course the
original vision.  The real question is who is going to do the work and
gather consensus?  The existing OASIS committee has prioritized scheduling
as the next task to standardize via contracts.  We can certainly revisit
that prioritization, but whatever we do in the existing committee isn’t
going to move very fast because we don’t have many resources.  But
the beauty of oBIX is that we’ve empowered *anyone* to create their own
contracts.  I envision this working like open source – contract
libraries needs to be developed organically and distributed across many groups
and organizations.  

 

Brian

 

From: Considine, Toby
(Campus Services IT) [mailto:] 

Sent: Monday, May 26, 2008 7:42 PM

To: 'Paul Ehrlich'; 

Cc: 

Subject: [obix-xml] RE: [obix] Contracts in v1.1

 

If I am not mistaken, the vendor
can indeed define contracts in the foyer.

 

What I do not see is how the
integrator can.

 

tc

 

"When one door closes,
another opens; but we often look so long and so regretfully upon the closed
door that we do not see the one which has opened for us." -- Alexander
Graham Bell

 

  
  
Toby Considine

  
Chair, OASIS oBIX TC

  Facilities Technology Office

  University of North Carolina

  Chapel Hill, NC

  
  
  
  

  
  
  
Email: Toby.Considine@
  unc.edu

  Phone: (919)962-9073 

  
http://www.oasis-open.org 

  
blog: www.NewDaedalus.com

  
 

 

 

From: Paul Ehrlich
[mailto:] 

Sent: Monday, May 26, 2008 5:51 PM

To: Considine, Toby (Campus Services IT); 

Cc: 

Subject: RE: [obix] Contracts in v1.1

 

Attached is a presentation that Brian Frank had put together to
provide a high level explanation of oBIX v1.  Slides 7, 8 explain the
concept of contracts.  Essentially they are a way to extend the protocol
in an open standard manner by users or suppliers.  Contracts always have
the option to be published (defacto standards) or to come back to the committee
and become standard contracts (see slide 12).  This method is designed to
allow for easy expansion in an open manner.  It is designed to be applied
in many ways and could possibly be used for functions such as DR.  What
oBIX v1 does not do is to provide any type of abstraction or underlying
knowledge of the control system.  

 

Paul
Ehrlich

 

 

From: Considine, Toby
(Campus Services IT) [mailto:] 

Sent: Sunday, May 25, 2008 2:16 PM

To: 

Cc: 

Subject: RE: [obix] Contracts in v1.1

 

Interesting question. My impulse
is that these batch contracts are a step up the abstraction layer, but not
enough of a step.

 

Hardware comes from the vendor
with various functions. These can be listed in the Lobby. This allows
pre-definition.

 

I think a service might be
“Able to perform to DR”

This might be answered by the
integrator defining 3 ADR contracts.

“Power_Normal,
PowerShed_Routine, PowerShed_Extreme”

 

Each of these is invoked as a
simple command – Together they define the service.

 

Another service might be
“Able to document current HBI index”

This might require various batch
operations on the current air state including knowledge of current occupancy
numbers.

 

 

"When one door closes,
another opens; but we often look so long and so regretfully upon the closed
door that we do not see the one which has opened for us." -- Alexander
Graham Bell

 

  
  
Toby Considine

  
Chair, OASIS oBIX TC

  Facilities Technology Office

  University of North Carolina

  Chapel Hill, NC

  
  
  
  

  
  
  
Email: Toby.Considine@
  unc.edu

  Phone: (919)962-9073 

  
http://www.oasis-open.org 

  
blog: www.NewDaedalus.com

  
 

 

 

From: Bob Smith
[mailto:] 

Sent: Sunday, May 25, 2008 2:20 PM

To: Considine, Toby (Campus Services IT)

Subject: RE: [obix] Contracts in v1.1

 

Hi Toby

 

Just a few na鴳e questions about these Pre_Contract ideas contained
within the last few emails:

 

1)   
What might be the relationship between Pre_Contracts and BIM
Templates? 

2)  
 Is Deborah MacPherson work on the Building Service
Performance Forum now working on “templates” an instance of a
Pre_C?

3)  
Could the US Coast Guard’s BIM efforts under David Hammond
exposed an opportunity to simulate oBIX Pre_Contracts

4)  
Might this Pre-Contract capability be “simulated”
within a future BIMStorm exercise?

 

 

 

Cheers,

 

Bob

 

From: Considine, Toby
(Campus Services IT) [mailto:] 

Sent: Sunday, May 25, 2008 10:39 AM

To: ''; 

Cc: 

Subject: RE: [obix] Contracts in v1.1

 

Just re-read entire document,
every paragraph including the word contract, and I see reference to vendor
defined contracts, no means to inspect such contracts, and no reference to
integrator defined contracts.

 

I agree we always intended this.
I think we did not flesh it out adequately. Several conversations this last
week left me the impression others feel this, too. 

 

The design philosophy section
(7.1) acknowledges this direction, but I do not see the mechanism.  It
could be argued that I am asking for formal batch names, but again, I would
like more explicit discussion of batches in the lobby. I would certainly be
delighted to be wrong, but I am not seeing what I am looking for.

 

It may be only some
documentation away. 

 

 

"When one door closes,
another opens; but we often look so long and so regretfully upon the closed
door that we do not see the one which has opened for us." -- Alexander
Graham Bell

 

  
  
Toby Considine

  
Chair, OASIS oBIX TC

  Facilities Technology Office

  University of North Carolina

  Chapel Hill, NC

  
  
  
  

  
  
  
Email: Toby.Considine@
  unc.edu

  Phone: (919)962-9073 

  
http://www.oasis-open.org 

  
blog: www.NewDaedalus.com

  
 

 

 

From: Aaron Hansen
[mailto:] 

Sent: Sunday, May 25, 2008 12:42 PM

To: Considine, Toby (Campus Services IT); 

Cc: 

Subject: RE: [obix] Contracts in v1.1

 

Unless I misunderstand, contracts can already do this.  This
has always been the intent.

 

From: Considine, Toby
(Campus Services IT) [mailto:] 

Sent: Saturday, May 24, 2008 4:40 PM

To: 

Cc: 

Subject: [obix] Contracts in v1.1

 

I would like to revisit the our concept of contracts in
version 1.1 of oBIX. Contracts allow you to define the operating posture of the
control system behind an oBIX server. Contacts can include schedules and set
points; contracts can define logging and trend reports.

 

Creating a contract can be a daunting prospect for any but
the simplest systems, for anyone other than the system integrator. This can
limit oBIX to central command and control by the central building system
server, leaving us with old model updated with shiny new whitewalls.

 

Several people have requested in private conversation that
we have some means to pre-define these contracts. This would be useful in a
couple scenarios (at least). 

 

1)     
In a peer to peer scenario, particularly between
systems of different domains, it would allow each system to invoke pre-defined
behaviors in its peer system. Each system integrator would be responsible for
defining the contracts within his own system. These contracts would define the
interface used by the peer system.

2)     
These
contracts could be the basis for easy interaction outside the domain of the
control system.  OpenADR provides a compelling high-profile use case for
this. In the light-weight scenario, the oBIX server itself could respond to ADR
requests (Invoke contract “Shed Load” / ”OK”).  In
the more compelling Enterprise Agent scenarios, the agent could coordinate the
response across many group of oBIX, picking the services to shed, while
remaining happily unaware of the deep process.

 

The lack of such pre-defined contracts is seen as
significant missing functionality by more than one oBIX supporter.

 

 

"There are a thousand hacking at the branches of evil
to one who is striking at the root." -- David Thoreau

 

  
  
Toby Considine

  
Chair, OASIS oBIX TC

  Facilities Technology Office

  University of North Carolina

  Chapel Hill, NC

  
  
  
  

  
  
  
Email: Toby.Considine@ unc.edu

  Phone: (919)962-9073 

  
http://www.oasis-open.org 

  http://www.NewDaedalus.com