Skip to content
English
Kontakt
  • There are no suggestions because the search field is empty.

Structuring Technical Models Effectively

Learn how to structure technical models effectively, classify components correctly, and consistently maintain floor levels, attributes, and quantities.

 Recommendations for Classification, Storeys, Attributes and Quantities

A clear and consistent model structure makes it easier to combine, check and evaluate multiple discipline models in big®. This article explains how to structure discipline models effectively, classify building elements correctly and provide important information consistently.

Why is a clear model structure important?

In a BIM project, models from different disciplines are typically combined into an overall model. The more clearly these models are structured, the easier it is to:

  • view and coordinate them together
  • filter them by discipline, storey or element type
  • check for clashes and inconsistencies
  • use them for evaluations and reports
  • update them throughout the project

There is no single correct model structure. The appropriate structure depends, among other things, on the size of the project, the authoring software used and the conventions of the companies involved.

The following points should therefore be understood as proven recommendations rather than rigid requirements.

Separate discipline models by discipline

As a general principle, each discipline should provide its own self-contained model. Typical discipline models include:

  • Architecture
  • Structural Engineering
  • Heating
  • Ventilation
  • Plumbing
  • Electrical
  • Building Automation
  • External Works / Landscaping

This separation makes it easier to selectively show or hide individual disciplines in the overall view, check them separately and update them independently when required.

Identify the discipline in the element name

In addition, it can be useful to identify elements using a consistent discipline abbreviation in the name, for example:

  • ARC Wall
  • STR Column
  • HVC Pipe
  • ELE Light

Such a prefix is particularly helpful when several disciplines are contained within a single model or when the discipline affiliation cannot otherwise be reliably evaluated in the software being used.

Only use abbreviations if they are defined at project level and applied consistently. If discipline models are clearly separated and attributes are maintained correctly, an additional abbreviation is not necessary for every project.

Subdivide large discipline models appropriately

For large or complex projects, a discipline model can be further subdivided, for example by:

  • Building or building section
  • Construction phase
  • Sub-project
  • Zone
  • Storey group

The subdivision should provide a specific benefit for editing, coordination or file size. Too many small sub-models, on the other hand, increase administrative effort and make it more difficult to maintain an overview.

Classify building elements correctly

Building elements should, wherever possible, be exported using the IFC class appropriate to their function. Examples:

Building element Recommended IFC class
Wall IfcWall
Door IfcDoor
Window IfcWindow
Column IfcColumn
Slab / floor slab IfcSlab
Pipe segment IfcPipeSegment

Where possible, avoid using non-specific placeholders such as IfcBuildingElementProxy if a suitable IFC class exists for the element.

Correct classification makes filtering, model checking and subsequent evaluation significantly easier. An object exported as a proxy may be displayed geometrically correctly, but it cannot reliably be identified as a wall, door or other specific building element.

Name element types consistently

Similar building elements should have consistent and meaningful type names. An element type can describe shared properties such as construction, material, dimensions or fire resistance.

Recommendations for typing:

  • Use the same type name for similar building elements.
  • Avoid different spellings and unnecessary special characters.
  • Do not use purely temporary names such as Type 1 if the meaning is not clear.
  • Do not change established type names during an ongoing project without prior coordination.

If the authoring software does not provide suitable type management, a project-specific attribute can be agreed upon as an alternative. The important thing is that the chosen approach is clearly documented and applied consistently by everyone involved.

Keep storey assignments consistent

All discipline models should use the same storey names. Different names such as GF, Ground Floor and 00 for the same storey make filtering and evaluation more difficult.

The following should therefore be defined at project level:

  • Name and spelling of each storey
  • Order of the storeys
  • Elevation of the storeys
  • Handling of intermediate storeys and split-level areas
  • Assignment of elements spanning multiple storeys

Elements should be assigned to the technically appropriate storey or, in IFC, to the correct IfcBuildingStorey. Assignment based solely on the geometric position of an element is not always sufficient.

For refurbishment projects, it may also be useful to include the renovation or project phase as a separate attribute, for example:

  • Existing
  • Demolition
  • New Construction
  • Temporary
Provide the required information selectively

In addition to geometry, building elements require basic information so that they can be uniquely identified, filtered and evaluated.

Depending on the use case, this may include:

  • Unique element ID
  • Element type
  • Material or construction
  • Storey and room reference
  • Fire protection or fire resistance class
  • Status or project phase
  • Manufacturer and product information
  • Operationally relevant information

More attributes do not automatically mean higher model quality. What matters is that the required information is:

  • defined specifically for the project
  • named consistently
  • provided in the agreed format
  • maintained consistently and completely
  • available at the agreed time

Requirements should be defined as early as possible in the Employer's Information Requirements (EIR) and their implementation specified in the BIM Execution Plan (BEP).

Provide standard quantities

Building elements should contain the quantities relevant to their type. These may include, for example:

  • Length for pipes or structural members
  • Area for walls, slabs or façade elements
  • Volume for concrete elements
  • Count for doors, windows or installed components

Many authoring systems can automatically generate these IFC base quantities during export. Depending on the software being used, however, this option may first need to be activated or configured.

Before handing over the model, therefore, check samples to ensure:

  • Are the expected quantities available?
  • Are the units used correct?
  • Are the values plausible?
  • Are identical element types being evaluated consistently?
Recommended checks before model handover

Before each agreed data exchange, check at least the following points:

  1. Discipline model and file name
    Are the discipline, building or sub-area and revision status clearly identifiable?
  2. IFC classification
    Are the building elements exported using the appropriate IFC classes?
  3. Element types
    Are type names consistent and meaningful?
  4. Storey assignment
    Do the names and assignments correspond to the project requirements?
  5. Attributes
    Are the properties required for the respective data exchange present and correctly populated?
  6. Quantities
    Are the required base quantities included and plausible?
  7. Test in an independent viewer
    Can the IFC file be opened, and are the structure and properties displayed as expected?
Check the IFC file using the buildingSMART Validation Service

The free buildingSMART IFC Validation Service checks IFC files for compliance with the IFC standard. This includes, in particular:

  • STEP syntax
  • Referenced IFC schema
  • Normative rules of the IFC specification
  • Additional guidance on common industry practices

The service is suitable as a technical preliminary check before further project-specific quality controls are carried out.

Important: The Validation Service does not check project-specific EIR requirements, naming conventions or individual requirements relating to attributes and model structure. Such requirements must be checked separately, for example using defined checking rules or an IDS file.

The IFC file is transferred to the buildingSMART platform for validation. Therefore, clarify in advance whether the file may be uploaded to an external online service in accordance with your project's data protection and confidentiality requirements.

Information about the buildingSMART IFC Validation Service

In summary
  • Structure models clearly according to discipline.
  • Only subdivide large models when this provides a specific benefit.
  • Use appropriate IFC classes wherever possible instead of non-specific proxy objects.
  • Name and type similar building elements consistently.
  • Keep storey names and storey assignments consistent throughout the project.
  • Define required attributes at an early stage and avoid unnecessary information.
  • Export and check the base quantities required for the specific use case.
  • Use the buildingSMART Validation Service as a technical preliminary check, not as a replacement for a project-specific model check.

A clear model structure is not an end in itself. It ensures that discipline models can be reliably combined, coordinated and evaluated.

Are you unsure which model structure is suitable for your project? Your Kaulquappe project team will be happy to support you in defining and reviewing the appropriate requirements.