COBie Guide
[1]
Public Guide to COBie version 05 [2] issued by Nantional Institute of BUILDING SCIENCES includes (quoted):
This document is not a software manual. The document consists of two parts. First there are common requirements that must be met regardless of the customer. The second part is a set of customer-specific requirements that need to be additionally met with general requirements; COBie information This is used to check if the designed object meets the owner's program guidelines. Because COBie is an extract from the items supplied within the schema, the information in the COBie data files must match the information about the spaces and architectural products and schedules found in the schema;
During the course of a project, different team members are primarily responsible for creating COBie Products. As many teams will use Building Information Modeling tools, especially during the design phase, to create the required contract drawings, the identification of COBie Responsibilities should be explicitly included in the team's BIM execution plan. One Tool That Can Help Teams Determine Production Responsibilities What COBie provides is the COBie Responsibility Matrix (COBie Responsibility Matrix). This matrix allows the team to color code different parts of the COBie delivery to define precise requirements as to which person and company will be responsible for creating specific COBie data. While project teams will identify specific people in their companies, the following should be adhered to overall responsibility for creating COBie data.
The listed COBie worksheets (or equivalent IFC file data) in the figure below should be provided as indicated in the "Asset Requirements" and "Delivery Sections" Assessment Criteria ". The purpose of these requirements is to standardize product and equipment schedules in design drawings and reflect this information in these schedules for the associated COBie delivery. The content of the development project provided should reflect the space and planned products and equipment assets as depicted in the relevant deliverable drawings. The architect is responsible for correcting any deviation in content between the associated design development, drawings and information provided in this section.
Unique resource naming: Without unique names, specific resources cannot be effectively maintained. All managed spaces, products, and equipment in schedules and design drawings should have a unique name. These names must contain resource information outside the context of the design schedule. The names in the design drawings must match those in the COBie shipment. During the design phase, the Architect will be responsible for resolving all duplication conflicts of names by his own staff and all consultant engineers.
Component spatial layout: For each COBie.Component component, you must provide a COBie.Attribute attribute named "SpatialPlacement". This Attribute identifies the information needed by the facility manager, operator, or maintainer to access this component. Common SpatialPlacement values include "UnderFloor", "AboveCeiling", "InWall", "InSpace", "OnRoof", "OnSite"
Categories: Large public clients manage all sorts of facilities on multiple campuses. To effectively manage these portfolios, COBie delivery items are required to receive building information in a consistent manner. In COBie this is achieved through the use of several different types of Classifications. Classifications are "category codes" of different types used in COBie. NBIMS- United States requires the following COBie sheets to be classified. • Contact • Object • Space • Type • System. NBIMS-US designates OmniClass (OMNIClass Structural Classification System) as the default classification method to be used if no other method is specified in the contract. The default list of mandatory COBie classifications to be considered for a given client is listed in Appendix A. Please note that relying on the client only on OmniClass may not ensure consistency between projects over time. The OmniClass classification tables, like all classification systems, change over time as updates are turned on. It is up to the customers to define and publish the precision of the classification scheme required for all projects.
zones: Buildings contain groups of spaces that, when combined, provide specific opportunities for the owner. The COBie.Zone sheet aims to identify the spaces that make up a given zone. In general, zones should be identified according to the type and characteristics of the zone. Large object zone names should also be marked as attached to the floor and wing. The names of zones and sub-zones should: be approved by the owner. Ddefault list of zones that will be used for a given client.
In the future, customers are expected to specify the use of prepared template objects for mandatory properties that reflect their unique requirements. In the absence of customer-specified regional, national, or customer-specific property kits, the design team may develop equipment and product schedules in accordance with current business practices and submit those schedules for customer approval to be checked against the quality standards set out in this guide.
Unique Component Name and Type Name: All device schedules that identify each item begin with the attributes listed below. The resource name "Component.name" and the resource type name "Component.Type" are provided in all project schedules should be unique for all asset classes.
Irrelevant Attributes: The attributes provided in the COBie deliverables are limited to those that provide information about the specifications or performance of the asset being managed, and not information regarding the internal configuration of the software system or the output formats provided by the software systems implementation.
Sources:
[1] pixabay.com
[2] COBie Guide: Commentary on NBIMS-US COBie [draft] Standard: Dr. Bill East, PhD, PE, F.ASCE 1, Mariangelica Carrasquillo-Mangual 2; Nantional Institute of BUILDING SCIENCES; 2013-03-12-COBieGuide-Public-v05 https://www.nibs.org/
Comments
Post a Comment