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: BIM and oBIX (UNCLASSIFIED)


If we restrict our conversation to HVAC… (not proposed) then we need to know not only what room a thermostat is in, but what other rooms are in the same zone.

 

A similar concern links access control to the suite, and not just to the door.

 

A similar concern links intrusion detection (broken glass, etc.) to the suite, not just to the window.

 

A policy on operating hours may minimize HVAC, and lock the door.

 

A security policy may lick the doors and put the building alarms on panic for all the intrusion sensors in a suite.

 

Space and geometry ties these together. Space is the geometry of the floor plan. Building systems are tied to space/groups of spaces.

 

 

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

Editor, OASIS EMIX, Energy Interoperation
Campus Services Information Technology
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

 

From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Bogen, Chris ERDC-RDE-ITL-MS
Sent: Tuesday, March 26, 2013 2:47 PM
To: obix@lists.oasis-open.org
Subject: [obix] BIM and oBIX (UNCLASSIFIED)

 

Classification: UNCLASSIFIED
Caveats: FOUO

Recall that last week I uploaded a new draft document  that provides an abbreviated example of how oBIX information is represented in a BIM using the BAMie (Building Automation Modeling information exchange) specification.  We’ve talked about including some BIM information in 2.0, and I imagine this to be a lightweight integration that simply relates the data points to equipment in an open BIM model.  BAMie, in many respects, is a similar sort of integration, but from the BIM side instead of the oBIX side. I want to provide some background information about how this integration is tackled on the BIM side to setup future conversations about oBIX 2.0 and BIM.

 

If you opened my example file without any prior experience with BIM then you may have thought, “A spreadsheet…what?”  (https://www.oasis-open.org/apps/org/workgroup/obix/download.php/48618/2012-03-20-Duplex-BAMie.xlsx).

 

So, what does a spreadsheet document have to do with BIM?  The answer is that this spreadsheet format was prepared according to the Construction Operations Building information exchange (http://www.wbdg.org/resources/cobie.php) (COBie) standard.  The COBie format is a buildingSMARTalliance standard that was introduced as a way that valuable data from BIM models may be presented in a file format that is useful for building operators, owners, and occupants – afterall, only architects and designers have the expensive software that authors the CAD/BIM models.  The COBie format is also mapped to the Industry Foundation Class data model (ISO/PAS 16739) (IFC), the de-facto international data standard for representing CAD/BIM models.  COBie data presents only a small subset of the information that could potentially be in an IFC model and is primarily a specification of the building’s logical decomposition (floors, zones, spaces), location of equipment, warranty information, links to equipment manuals, etc.  There is also a COBie XML schema emerging (http://buildingsmartalliance.org/index.php/projects/cobielite/) that is MUCH more accessible to programmers – unless you know application developers that prefer spreadsheet data bindings to XML schema.   

 

Because the IFC data model supports several application domains (HVAC, electrical, water, audio/visual, architectural) it is an enormous data model with over 700 entity types and more native types, property set templates, etc.  So, model view definitions (MVD) are also defined to specify exactly how the IFC model should be used to model specific information exchanges – e.g. design coordination, facility management handover.  Recently the draft BAMie model view definition was released (http://www.buildingsmartalliance.org/index.php/projects/activeprojects/180). 

 

The BAMie model view specifies how to represent the logical and physical connections between automation/monitoring equipment and the building, logical/physical connections between the automation/monitoring equipment, automation/monitoring product information, addressing information (for accessing data), equipment configuration information, and summaries of performance data.

 

In my BAMie example there are a number of columns and tabs that are not relevant to this discussion, so I color coded the “interesting” worksheets in red.  The example is simply showing how I am representing the following automation/monitoring facets:

·         3  product “Types” that occur in a building:  a receptacle, energy sensor, and a controller 

·         Occurrences (Components) of these equipment types that are placed in specific rooms (Spaces) in the data. 

·         There is a logical grouping of the automation system components (System).

·         Links to oBIX data points corresponding to the sensors (Document).

·         Physical connections between the Components (Connections)

 

So, how much of the BIM to we model in oBIX 2.0?  Do we assume that the sensors are modeled in the BIM, thus relating them to rooms/other components, or do we assume that we will only get spatial decomposition from the BIM?  It’s all up for discussion on our road to oBIX 2.0. 

 

Chris Bogen, Ph.D.

Computer Scientist

US Army Corps of Engineers

Engineer Research Development Center

Vicksburg, MS

 


Classification: UNCLASSIFIED
Caveats: FOUO



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