FM Handover Aquarium Questions & Answers
General explanations and answers to frequently asked questions about the goals, requirements to participate, and other inquiries about the buildingSMART FM Handover aquarium project, including the technical questions about the IFC FM Handover View Definition and the mapping into the COBIE2 handover format.
- General Q&A about the process, participation and goals
- Technical Q&A about the FM handover data format
- Technical Q&A about the FM Handover target COBIE2 format
Q: Are there fees required from software developers to participate in the aquarium?
A: The participation in the aquarium process is free for software developers, they bear their own costs for involvement (time, internal testing, participation in the final event). The costs incurred by the aquarium process (facilitation, running the teleconferences, website maintenance, questions and answers, etc.) are covered by the problem owners (sponsoring organizations). If participants opt to go further with the certification process (in advance to the challenge) then the buildingSMART certification fee applies.
Q: Is the aquarium a practical exercise to see what works already?
A: Partially as it does not define the process, nor the buildingSMART IFC interoperability support from scratch. It does however include areas of improvement and adaptation to the particular needs for the FM Handover process. These adaptations are defined using a subset of the IFC structures that are already implemented and certified as IFC2x3 coordination view. A few additional requirments, specific for the FM handover process, are added in correspondance to that.
Q: What are the data formats to be used for the interoperability (design to CAFM/CMMS, and construction detailing to CAFM/CMMS) within this buildingSMART aquarium?
A: For the buildingSMART certification and the international requirements for demonstration (challenge) the applicable data formats are IFC and ifcXML. For the US market challenge for COBIE the export can be shown in addition using the excelXML format of COBIE.
Q: What level of expertise is required to participate? Do we need a knowledgeable application user to drive our software in the aquarium, or would we expect to have a software developer as well to deal with issues that arise?
A: If you are a solution provider (software company) the requested participation would typically include a product manager (for limited time) to discuss the necessary process support and a software engineer to add and verify the support to the IFC interoperability component of the software.
Q: The FM aquarium process seems to deal with the handover of architectural data (space lists, FFE lists) and MEP data (MEP components and systems linked to the spatial system), is a participant required to support both?
A: No, it depends on the software portfolio and the business area of the participant. It is expected to have different data flows from architectural BIM and MEP applications. Participants having solutions for both areas may opt to participate with architectural and/or MEP solutions.
Q: Is this exercise a precursor to proposing a certification of the work flow?
A: Yes one goal of the FM Handover aquarium is to prepare a buildingSMART IFC certification for the design and construction to operation and maintenance work flow. The certification is based on the IFC model view definition MVD being based on the coordination view and currently available as a final draft. One additional goal of the aquarium process it to finalize the MVD with input by the participants and get it finally adapted by buildingSMART International.
The certification involves FM Handover export from BIM applications, and FM Handover import into CAFM and CMMS applications. The actual certification process will be carried out under the supervision of buildingSMART international.
Q: What is the deadline for the demonstration (challenge) and the certification process?
A: The deadline for this year is the 08.-10.12.2009, the AEC/ST and buildingSMART alliance conference in Washington DC.The challenge will take plac during this time with all participating companies that are ready at this time. The certification will start few days earlier (the quality of the results will determine whether the certification award can be awarded already or whether further test rounds are required).
The next challenge is planed for the following year in December 2010.
Q: What is a Zone (IfcZone) and how does it differ from Space (IfcSpace)?
A: Zones are aggregations of spaces that can be used for a number of purposes, such as public/private circulation, departmental allocation, or distinct servicing. They are essentially aggregations of spaces for any reason other than the assignment of spaces to the spatial structure of a facility (building -> story -> space). Zones can span across floors, and need not be contiguous in space. Any space can be aggregated in zero, one, or several zones. For IFC definitions see IfcZone and IfcSpace.
Q: Can zones and systems include other sub-zones and sub-systems?
A: Yes, both zone and system can include other zones and systems, however the relationships have to be hierarchical. Therefore systems and zones can be defined recursively.
Q: Coverings, e.g. a flooring, can be defined either as an attribute at the space, or as an individual object contained in the space. What are the rules for using an attribute or an object approach.
A: Yes, both representations are possible. The prefered representation is using the object approach, i.e. IfcCovering assigned to a space through IfcRelContainedInSpatialStructure. The IfcCovering can then hold own properties and quantities (GrossArea, NetArea). There are some cases where using IfcCovering object is mandatory: (1) there are more then one flooring (ceiling, cladding) in a space, (2) the thickness, material layer information, etc are essential, (3) an own shape representation is important (as for suspended ceilings).In these cases an IfcCovering instance is to be used that is assigned to an IfcSpace using the IfcRelContainedInSpatialStructure relationship.
The use of attributes (FloorCovering, WallCovering, CeilingCovering within Pset_SpaceCommon) at IfcSpace is allowed, if there is only one flooring, cladding, and/or ceiling and the quantities can be obtained from the base quantities of IfcSpace (NetFloorArea, NetCeilingArea, NetWallArea). In those cases (particularly in the design phase) no instance of IfcCovering is used.
Q: How are doors and windows assigned to spaces. Is an internal door and window already assigned to a single space?
A: The FM Handover View recognizes the different views of an construction oriented BIM view, where a door or window is seen as inserted into a wall, and the FM view, where a door or window is managed as an furniture from a single space. The selection of which of the two spaces bounding a door or window becomes the single space assigned in FM depends on local or project specific rules.
The FM Handover View therefore allows both methods: (1) the door or window is already assigned to a single space in the BIM application, then it is exchanged with the single door/window to space assignment (IfcRelContainedInSpatialStructure) and (2) the door or window is bound by two spaces (two instances of IfcRelSpaceBoundary).
Q: How are internal and external doors and windows distinguished?
A: In addition to (and in absence of) a distinction by the associated classification system, like DIN276 334 (for external doors and windows) and DIN276 344 (for internal doors and windows), a classification independent property attached to IfcDoor and IfcWindow common property sets, IsExternal, has to be used. An internal door or window is identified by IsExternal=FALSE, an external door or window by IsExternal=TRUE.
Q: What tools are available to support the mapping between IFC and COBIE2?
A: The IFC<->COBIE mapping command line utilities are now available and will be published soon. The COBIE2 checker command line utilities will be made available shortly.
Q: Is the COBIE2 xml format now stable (as of August 2009)?
A: The COBIE2 xml spreadsheet format is now fixed. The more condensed format of COBIE2 is intended to make it easier to use COBIE with clients and users. There have been few changes over the recent several weeks. The last changes were to make System and Zone rows consistent with a unique name and a comma delimited list on their contents, and to remove the FacilityName columns from Systems, Zones and Floors, as the assumption is now that there will be only one Facility.
Q: Can the COBIE2 PickLists be changed?
A: COBIE2 is intended to be standardised but configurable for regional and project practice and so the only changeable columns in the PickLists are the national/regional classifications (shown in green). Other lists should NOT be changed because there are the obvious risks that applications reading the sheet will not find expected terms or that applications writing out spreadsheets will not use any novel terms. For example, the values for 'FloorType' is always one of the three values 'Site', 'Floor', or 'Roof' and coordinates are taken from the 5 values that describe a point, line, or box.
Q. What is required to be unique within COBIE2?
A: There is an unique implied key for rows in each table. In all cases making the Name (or Email) unique is sufficient. Key names should match regardless of case. This applies for:
“Attribute”, Name, SheetName, RowName
In general, Names should avoid unusual punctuation. Numeric keys used by other applications can be stored in ExternalSystemId if no other IFC GlobalId is avilable. Using text based keys makes cut-and-paste operations valid. For example each worksheet can be prepared from reports produced by disparate applications. Also character names have been preferred as a miss-typed character is more likely to make a key invalid, whereas a mistyped number is more likely to be a valid but wrong key.
Q: How are Spaces, Components and Resources assigned to Zones, Systems and Jobs?
A: In each case a single cell contains a comma-delimited list of the names.
Q. How do the comma-delimited list of the names work?
A: Name lists are comma separated. The final comma is optional. These occur in the following columns:
ComponentNames for a System,
SpaceNames for a Zone,
ResouceNames for a Job
Space(s) of shared Components (such as doors).
It follows that Space and Component and Resources names should not contain commas. Using this convention, a Component may span between two (or more) spaces. This does NOT allow Components to be duplicated in two (or more) Spaces. Additionally, in the Description of a Job, one may optionally created a comma delimited list of tasks.
Q: Is there documentation of the COBIE2 fields and other rules?
A: The rule set is available. Further documentation will follow. In summary text fields may be up to 255 characters. Dates shall be in ISO format.
Q: How is the Attribute sheet used?
A: The attribute sheet can theoretically refer to any other sheet, but it is most commonly used to record the attributes of the Components, Types, Systems, Zones and Spaces. Only one value should be recorded for a given Attribute Name, SheetName and RowName. Values held for a Type and System may be overridden by values held against an individual Component. Values held for a Zone may be overridden by values held against an individual Space.
Q: How is the Register of submittals held?
A: The Register is held within the Document catalogue. An expected document can be recorded, before the actual delivered file name is known, so a BIM application could create a “Product Data” Document record for each Type.
Q: Can spaces contain other spaces ?
A: No. Spaces cannot contain other spaces. Zones should be used instead as super elements that may contain multiple spaces.
Q: Must COBie-compliant applications handle components assigned to more than one space ?
A: Listing multiple spaces for a component signifies spanning, not duplication. Where an application has a need to assign it to one single space, then it may take the first space in the list.