bsp-forum
[Top] [All Lists]

Re: [bsp-forum] Fwd: [ontolog-forum] [Fwd: The Open Group SOA Ontology]

To: 'BSP Forum' <bsp-forum@xxxxxxxxxxxxxxxx>
From: "Considine, Toby (Campus Services IT)" <Toby.Considine@xxxxxxx>
Date: Tue, 15 Jul 2008 16:16:32 -0400
Message-id: <49388A5276025649AC24AF97ADB9DA6215C78A64B7@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

I can feel our minds meeting.

 

Aside from those doing building analytics, how much of the process details do we need in the IDMs?

 

I would hazard that in most buildings designed and built today, the control systems, quite simply, are not designed. To the extent they are designed, they are not implemented. A sub-contractor of the mechanical sub (for hvac) designs the actual control system while standing on a mud-bucket in the hallway.

 

I think the future of mechanical systems is autonomous controllers that discover what it is they have actually got, and then tune themselves.

 

I think the future of design for mechanical should be to specify performance and cost per SF, where cost may be expressed in terms of energy to isolate it from volatile energy prices. I think the future of design for elevators should be to specify the service levels desired (speed, weight, responsiveness) and make the bidder be responsible for it. Performance contracting – re-defined from inspecting how bolts are tightened down to service performance.

 

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: bsp-forum-bounces@xxxxxxxxxxxxxxxx [mailto:bsp-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Deborah MacPherson
Sent: Tuesday, July 15, 2008 4:07 PM
To: BSP Forum
Subject: Re: [bsp-forum] Fwd: [ontolog-forum] [Fwd: The Open Group SOA Ontology]

 

So - naming SOA services, to then creating IDMs around those services….

How to start? A list of ideal SOA services for the reasons you state below plus problems presented by Bob and Rex,

To brainstorm a broad but ideal list, maybe even a chart that would with notes like "primary user Owner", "potential IP issues"

Then, a reconciliation to service primitives along with units of measure

Then reaching into the depths of specifications and actuator valves, the result which is to create IDM that work through the whole process, with semantic relationships mainly hidden from Owner Operators but accessible to those who want more ?

Then limited list that can get overlaid and compared with use groups and other typical building driving factors, real classifications down to the nth degree like actuators or devices that would be monitored some day for a long time...

A set of IDMs simulated or semantically laid out all the way through the process with all the view points maybe using different classes like UniFormat, or different query methods depending?

Deborah


On Tue, Jul 15, 2008 at 3:24 PM, Considine, Toby (Campus Services IT) <Toby.Considine@xxxxxxx> wrote:

To me, the Service in SOA and the Service in Building Services (of BSP fame) are *precisely* the same. This conception of mine is part of

 

-          My focus on the services derived from the application of IT in building space rather than yet another list of libraries/offices/schools/dorms/…

-          My attempts to hide building system process, which is ill-defined and not performance oriented and expose a service/surface only

-          My frustrations that we are as I see it broadening our scope / diluting our effect.

 

Wikipedia states that SOA is "a computer systems architectural style for creating and using business processes, packaged as services". I want a "systems architectural style for creating and using building system processes, packaged as services"

 

More from Wikipedia"

 

"SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications.[1] SOA separates functions into distinct units, or services[2], which are made accessible over a network in order that they can be combined and reused in the production of business applications.[3] These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing[3][2] and modular programming."

 

In the SOA world, the logistics function provided by UPS lets Amazon report where your books are right now, without even needing to know about the drivers/radio transmitters /trucks/scanners/planes/hand-held signature devices. The Performance metrics are simple; on-time delivery, percent lost or delayed packages, percent damaged packages. The service is invoked by Amazon's services contacting UPS's services.

 

We have complex systems that are interactive throughout buildings. No one cares about how they work (except for the guys with ladders on their trucks). No one cares what protocols they use. No one cares how they make their loop tuning decisions, or how they prevent mold growth. No one cares if they short cycle or not. No one cares how the alarm system detects metal oxide on the sensors and so discounts false alarms. No one cares what technology is used to compress video to scenes in which movement or unknown faces are detected only. No one, outside the specific engineering and maintenance domain for each system cares about the process at all.

 

Everyone cares if the service falls down. Everyone cares if the service is provided at an uncompetitive energy budget, or if moisture damages the archived materials or furnishing, or if false alarms ring too often and real alarms not enough. These are the building services. Deborah, I think you observed the other day that some associates did not realize that healthful office environments for alert workers was a service provided by the building.

 

I think we will discover some service primitives. I think that there will be a maximum ventilation service primitive, a no ventilation service primitive, and a service primitive for effective ventilation for (n) occupants. These primitives will be reused in different service domains, appearing in the Alert Tenant Service and the Emergency Weather Response service of Michelle, and in others besides.

 

I n the buildingSmart alliance last week, I shared some documents on service, and systems architecture. I am re-sharing them here.

 

One is Pat Helland's Metropolis article, in which Helland uses the built world as an analogy to explain service oriented architectures to the IT world. Metropolis provides a metaphor for the evolution of information technology into the world of service-oriented architectures,"  What is fascinating to me is that this same article can go back to the built world, and explain not only how we should organize access to information from the BIM, but how we should think of the services provided by buildings.

 

http://msdn.microsoft.com/en-us/library/aa480026.aspx

 

Another article that I highly recommend is the SOA Reference Model developed by OASIS. It is a tight description of Service Orientation that is vendor and technology agnostic, while describing how to think about these systems. It formalizes what Steve has described below and defines the semantic for understanding and discussing the services which BIM/BuildingSmart must grow into to meet their full potential. As gaining a common understanding of the words is the first hurdle on the path to a meeting of the minds, I highly recommend anyone who is interested on intrigued by Steve's observations should also download and read the SOA reference model.

 

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

 

I hope what we are doing is naming SOA services, to then creating IDMs around those services….

 

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: bsp-forum-bounces@xxxxxxxxxxxxxxxx [mailto:bsp-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Deborah MacPherson
Sent: Tuesday, July 15, 2008 2:52 PM
To: BSP Forum
Subject: [bsp-forum] Fwd: [ontolog-forum] [Fwd: The Open Group SOA Ontology]

 

Does the.....high level concept of Activity (which we believe to be substantially the same as the BPMN concept) with concepts of Service and also of Architecture.

Have relevance to BSP? If so, does anyone have any comments? Just FYI, even though of course the aim is to work with NBIMS, OBIX, Fiatech, OGC - everything...the BPMN guidelines for NBIMS are attached for reference.

Deborah

---------- Forwarded message ----------
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Tue, Jul 15, 2008 at 12:38 PM
Subject: [ontolog-forum] [Fwd: The Open Group SOA Ontology]
To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>


FYI.

 From Chris Harding of The Open Group:

For some time now, The Open Group has been developing a formal
ontology for SOA. We made an early version available for comment by
OMG members over a year ago - indeed, I came to one of your meetings
at the end of 2006 and presented our then-current draft. We have now
reached the stage where we believe that it is almost complete, and
are exposing it to outside bodies for review and comment prior to
its final review within The Open Group.

The ontology is a formal OWL ontology, but the draft also includes
extensive heuristic explanations of its concepts. It should be of
particular interest to the OMG, firstly because of its relevance to
Model-Driven Architecture, and also because it relates, at a high
level, a concept of Activity (which we believe to be substantially
the same as the BPMN concept) with concepts of Service and also of
Architecture.

The draft is publicly available at
http://www.opengroup.org/projects/soa-ontology/doc.tpl?gdid=16940
We would very much appreciate input from OMG members, and will
address comments received at this stage before creating the draft
for final Open Group review. [OMG is invited] to review the draft
and send comments to [Chris].

========================================================================
Dr. Christopher J. Harding
Forum Director for SOA and Semantic Interoperability
THE OPEN GROUP
Thames Tower, 37-45 Station Road, Reading RG1 1LX, UK
Mailto:c.harding@xxxxxxxxxxxxx Phone (mobile): +44 774 063 1520
http://www.opengroup.org
========================================================================

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx




--
*************************************************
Deborah L. MacPherson CSI CCS, AIA
Projects Director, Accuracy&Aesthetics
Specifier, WDG Architecture PLLC

**************************************************



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/bsp-forum/
Subscribe: mailto:bsp-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/bsp-forum/
Shared Files: http://ontolog.cim3.net/file/work/BSP/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance




--
*************************************************
Deborah L. MacPherson CSI CCS, AIA
Projects Director, Accuracy&Aesthetics
Specifier, WDG Architecture PLLC
**************************************************


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/bsp-forum/   
Subscribe: mailto:bsp-forum-join@xxxxxxxxxxxxxxxx 
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/bsp-forum/  
Shared Files: http://ontolog.cim3.net/file/work/BSP/ 
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?BuildingServicePerformance    (01)
<Prev in Thread] Current Thread [Next in Thread>