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

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

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


Subject: 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:Paul@buildingintelligencegroup.com]
Sent: Monday, May 26, 2008 5:51 PM
To: Considine, Toby (Campus Services IT); obix@lists.oasis-open.org
Cc: obix-xml@lists.oasis-open.org
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:Toby.Considine@unc.edu]
Sent: Sunday, May 25, 2008 2:16 PM
To: obix@lists.oasis-open.org
Cc: obix-xml@lists.oasis-open.org
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:bob@1talltrees.com]
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´ve 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:Toby.Considine@unc.edu]
Sent: Sunday, May 25, 2008 10:39 AM
To: 'a.hansen@controlco.com'; obix@lists.oasis-open.org
Cc: obix-xml@lists.oasis-open.org
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:a.hansen@control.com]
Sent: Sunday, May 25, 2008 12:42 PM
To: Considine, Toby (Campus Services IT); obix@lists.oasis-open.org
Cc: obix-xml@lists.oasis-open.org
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:Toby.Considine@unc.edu]
Sent: Saturday, May 24, 2008 4:40 PM
To: obix@lists.oasis-open.org
Cc: obix-xml@lists.oasis-open.org
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

 

 



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