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
- C ONSTRUCTION PROCESS POSITIONING
- P RESUMPTIONS
- P ROJECT
- S ITE / PLOT
- B UILDING
- B UILDING S TOREYS
- S PACES
- B UILDING ELEMENTS
- Building and equipment element types
- Location information of building and equipment elements
- Building element construction types
- C HANGE REQUEST INFORMATION
- 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 Design to Design Coordination. A Data Exchange Use Case (abbreviated Use Case) is an identified practical data exchange need, for example in a construction project, where the data exchange requirements and 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 minimum information to be exchanged in the Use Case consists of the 3D model (3D geometry) containing the building and equipment elements. The Pro IT Process Model [5] is used here to identify the Data Exchange Use Case within the construction process.
The information content of the Use Case data exchange is represented by information flows Building Design and Product Models. The essential Use Case information content consists of the various building and equipment elements of the building.
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
The Use Case information content specification presented in Part 1: Section 3 is independent of the method and format used to exchange the information between software applications. 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 only defines the representation and format of the implementation, i.e.
The minimum content of the IFC product model in the two sub-cases of the Use Case. This section describes various parts of the IFC product data model, IFC Aspects [7], which are necessary for the implementation of the Use Case data exchange. The IFC aspects required to implement the data exchange use case are listed in Table 4.
Data Interchange IFC 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 Complete IFC release documentation, including the IFC object model in EXPRESS/EXPRESS-G, semantic definitions and explanations, and IFC property set definitions. In object or product modeling, things are modeled as objects that have properties and relationships with other objects. Note: Sometimes, in general, the term object can mean a class or an instance of a class.
If it is necessary to make the distinction between the two explicitly, the latter terms must be used. An idea of rough phasing of the development and accumulation of building product model data over time. Product data A representation of information about a product in a formal manner suitable for communication, interpretation or processing by humans or by computer applications.
For example, building and construction project information stored in an exchange file in IFC format. For example, the IFC object model is the product data model defined for AEM/FM product data. The product model of a particular building represents product data about the building in a format defined by the product data model.
Reference model A 3D model that can be imported into a CAD application and used as a reference or snap point 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 information content data exchange In data exchange transactions, it is essential in practice that the parties are involved in the data exchange.
SHORT CHECKLIST FOR DATA EXCHANGE INFORMATION CONTENT
Short checklist for implementation of data exchange When making agreements about data exchange, the following principles must in any case be applied.
SHORT CHECKLIST FOR DATA EXCHANGE IMPLEMENTATION
IFC ASPECT CARDS FOR THE IFC IMPLEMENTATION OF THE DATA
NOTE: The Aspect Chart 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) added with the last change action, which points to the application (#3) as well as person and organization (#4, #5, and #6) that has ownership of the column information.
The owning user has a specific role Consultant stored in an instance of the IfcActorRole class (#7). At the bottom of the hierarchy, the notation values for bars and bars ('1223' and '1224' respectively) can be found. In this case, where construction types are handled, the value of the attribute must 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. 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 using the Depth attribute which is of type IfcPositiveLengthMeasure.
The main classes are the IfcSolidModel, its subtype IfcManifoldSolidBrep, and the subtypes of the latter IfcFacetedBrep and IfcFacetedBrepWithVoids (see Partial Schema in EXPRESS-G 3/3), which are subtypes of IfcGeometricRepresentationItem. Properties are omitted in some of the basic cases to keep the diagram neat. A mapped Item can be scaled or transformed from its source through the MappingTarget attribute, which points to a subtype of the IfcCartesianTransformationOperator.
Attributes are omitted in some basic instances to keep the diagrams clear. 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 associated with their type information according to the IFC specification. Construction elements can be associated with type information through objectified relations of the IfcRelDefinesByType class. This aspect describes the sub-hierarchy for Building Services Elements of the IFC object model and how they can be associated with their type information according to the IFC specification.
Building service elements can be associated with type information through objectified relationships of the IfcRelDefinesByType class.
