USE CASE DESCRIPTION: BASELINE AND INFORMATION CONTENT
- G ENERAL
- D OCUMENT CONTENT
- U SE C ASE NAME AND APPLICATION AREA
- S COPE
- Data exchange purpose and general information content
- Parties and applications
- Use Case sub-cases
- C ONSTRUCTION PROCESS POSITIONING
- P RESUMPTIONS
- P ROJECT
- S ITE / PLOT
- B UILDING
- B UILDING S TOREYS
- S PACES
- B UILDING ELEMENTS
- Building element types
- Location information
- Building element construction types and material properties
- S UMMARY OF INFORMATION CONTENT
- G UIDELINES FOR PRODUCT MODELLING OF THE BUILDING
- T HE INFORMATION CONTENT SCOPE IN DIFFERENT PRACTICAL DATA EXCHANGE CASES
This document contains the specification of the Data Exchange Use Case for the data exchange from Architectural Design to HVAC Design. This Data Exchange Use Case is specifically about the exchange of the digital 3D model and product data between software applications. A Data Exchange Use Case (Use Case for short) is an identified practical need for data exchange, for example in a construction project, where the data exchange requirements and their implementation are documented in detail (Figure 1).
The document describes the purpose, scope and baseline of the Use Case and specifies the information content of the data exchange in an implementation-independent form. In addition, the document describes how the Use Case data exchange is implemented using the IFC data exchange standard. The purpose of the Use Case is to transfer the 3D geometry information of a building or the building product model produced by architectural design as input for HVAC design.
The Pro IT process model [5] is used here for the identification of the Data Exchange Use Case within the building construction process. The information content of the Use Case data exchange is represented by information streams Initial Building Design and Building Design and Product Models. The building is a mandatory part of the Use Case information content, and the building is used as a container object for the building floors.
The essential types of building elements for the data exchange use case are shown in Table 1.
USE CASE IMPLEMENTATION: IFC IMPLEMENTATION
- M INIMUM CONTENT OF THE IFC PRODUCT MODEL
- I MPLEMENTING BUILDING ELEMENTS USING IFC CLASSES
- T HE U SE C ASE IFC A SPECTS
- IFC DATA EXCHANGE FORMATS
In the data exchange implementation, the means and methods of the exchange (data exchange representation and format) for exchanging the information content are specified. For the data exchange implementation, the Use Case defines only the representation and format of the implementation, i.e. For this Use Case, the required minimum IFC product model content is specified separately in Table 3 for the exchange of the 3D reference model and building product model exchange subsub. -incidents.
The minimum content of the IFC product model in the two sub-cases of the use case. This section describes the various parts of the IFC Product Data Model, IFC Aspects [7], that are required to implement use case data exchange. The IFC aspects required to implement the data exchange use case are listed in Table 5.
IFC data exchange has two alternative formats for exchanging the same information content. The ifcXML format, which is based on an XML schema definition of the IFC product data model [13].
SHORT DICTIONARY
IFC aspect A grouping of an IFC object model together with instance instantiations into subsets, each defining a whole to enable the representation of specific aspects or characteristics of objects. IFC aspects support the specification of data exchange use cases and their implementation in software applications. Note: Since the scope of IFC covers more than the product itself (the building), the term project data can be used instead of product data.
IFC Specification The entire IFC Release documentation, including the IFC Object Model in EXPRESS/EXPRESS-G, the semantic definitions and explanations, and the IFC Property Set definitions. In object or product modeling, things are modeled as objects that have properties and relationships to other objects. Note: Sometimes in general terms the term object can mean either a class or an instance of a class.
If it is necessary to explicitly distinguish between the two, the latter terms should be used. An idea of a rough phasing of the development and accumulation of construction product model data over time. Product data A representation of information about a product in a formal manner that is suitable for communication, interpretation, or processing by humans or by computer applications.
For example, information about a building and the construction project stored in an exchange file in IFC format. For example, IFC Object model is a product data model defined for AEM / FM product data. A product model of a specific building represents product data about the building in a form defined by a product data model.
Reference model A 3D model that can be imported into a CAD application to serve as reference or snap points when creating new objects and their 3D geometry. In IFCs, a defined subset of the IFC Object Model that a number of implementers have agreed to support in their implementations. Short Checklist for Data Exchange Information Content In data exchange transactions in practice, it is essential that the parties to the data exchange.
SHORT CHECKLIST FOR DATA EXCHANGE INFORMATION CONTENT
Short checklist for data exchange implementation When agreements on data exchange are made, at least following positions should be.
SHORT CHECKLIST FOR DATA EXCHANGE IMPLEMENTATION
IFC ASPECT CARDS FOR THE IFC IMPLEMENTATION OF THE DATA
NOTE: The aspect map code in the header section is for reference purposes only - the numbering has no semantic meaning. The instance of the class IfcColumn (#1) has a globally unique ID, which is generated according to the IFC specifications. The column has an owner history (#2) with the last change action added, and points to the application (#3) and person and organization (#4, #5, and #6) that owns the column information.
The owning user has a specific Consultant role stored in an instance of the IfcActorRole class (#7). At the bottom of the hierarchy can be found the note values for columns and beams (respectively '1223' and '1224'). In this case when handling construction types, the attribute value will be 'ConstructionTypeClassification' (see next page for instantiation instructions).
The clear text description of the construction type is given in the value of the Name attribute of instance #11. IfcCartesianPoint and the lengths of the three sides measured in the directions of the coordinate axes represented by properties XDim, YDim and ZDim of type IfcLengthMeasure. The extruded area solid is defined by its position, swept area and direction and depth of the extrusion.
The depth or length of the extrusion along the direction is expressed by the attribute Depth, which is of type IfcPositiveLengthMeasure. The type of profile definition to use in various specific use cases should be checked in the Geometry Usage Definitions in the IFC Web Specification. The main classes are IfcSolidModel, its subtype IfcManifoldSolidBrep and its subtypes IfcFacetedBrep and IfcFacetedBrepWithVoids (see Partial Schema in EXPRESS-G 3/3), which are subtypes of IfcGeometricRepresentationItem.
Attributes are omitted in some of the basic examples in order to keep the diagram unordered. A map item can be scaled or transformed from its source through the MappingTarget attribute, which points to a subtype of the IfcCartesianTransformation Operator. Attributes are omitted in some of the base instances in order to keep the diagrams uncluttered.
This aspect describes the sub-hierarchy for the spatial elements of the IFC object model and how they can be related according to the IFC specification. An instance of IfcProject is also always present at the top of the parsing as a navigation starting point. This aspect describes the sub-hierarchy for the building elements of the IFC object model and how they can be related to their type information according to the IFC specification.
The building elements can be related to type information through objectified relationships of the IfcRelDefinesByType class.
