[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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 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:Toby.Considine@unc.edu] 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
From: Paul Ehrlich
[mailto:Paul@buildingintelligencegroup.com] 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] 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
From: Bob Smith
[mailto:bob@1talltrees.com] 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] 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
From: Aaron Hansen
[mailto:a.hansen@control.com] 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] 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]