buildingSMART Forums

Feedback on the IFC4.2 Draft

#1

Dear International IFC community,

The IFC-Bridge extension is ready for inspection. Please provide feedback on IFC 4.2 DRAFT in this forum until November 30th, 2018. You can find the schema and the HTML doc as well as the conceptual model underlying the extension here:

https://buildingsmart.sharefile.com/share/view/s619ceb7623d4b099/fod4202e-f039-49d7-8e4e-cddabe6efd3c 

Thanks!
André

3 Likes
4.2 - Domain/ Extension/ Update etc
pinned globally #2
#3

Dear sir / madam

Here is the feedback from Norwegian Public Roads Administration and representatives from other Norwegian consultancy companies regarding the IFC Bridge project. This is a collaboration group in infraRoom in buildingSMART Norway.
We appreciate the work you have been doing to create a standard for BIM modelling for bridges and developing the IFC Bridge standard. As requested in the last expert panel, we now provide feedback on the IFC 4.2 DRAFT. As we don’t have the full understanding of IFC Bridge, we have a few questions we hope you can help us answer.

All bridges in Norway are subject to an independent verification/design control. Structures designed for national and country roads have to be verified and approved by the Directorate of Public Roads before construction. Earlier this resulted in approved working drawings, but as the number of BIM projects increased, we now have a system for verifying models. In June 2017 we allowed independent design control of BIM models, and today we have 134 models registered in our “control system”. The Directorate of Public Roads are currently working on developing a national guideline concerning model structure, attributes and filters in BIM models. We aspire to ensure that these guidelines coincide with the international IFC Bridge project.

We have some questions regarding IFC Bridge and management systems. The management system in Norway is BRUTUS, which is a modul-based IT system for administering, operating and maintaining bridges. To make use of the information in the model within the bridge’s service life, it’s important that the model structure, filters and classifications in IFC Bridge support and are compatible with the management system in Norway. Do you have a plan for implementing IFC Bridge in the different national management systems? How can we implement the classifications in our management system in IFC Bridge?

Other comments and questions regarding IFC Bridge are:

  1. Soil/Ground
    The interface between geotechnics and bridge is a challenge in current models (and in the design control), and this issue needs to be solved. What about backfilling, frost protection, scour protection, sheet pile and how is this implemented in IFC Bridge? Is this covered by Common Schema?
  2. Equipment/Installations
    How can we implement these installations in IFC Bridge?
  3. Tunnel portals, retaining walls, ferry quays and avalanche protection
    Portals, retaining walls (height > 5 m), ferry quays and avalanche protection are considered as load-bearing structures/bridges in Norway. How should we implement and adapt these construction types to IFC Bridge?
  4. Composite and wooden bridges
    We have several composite and timber bridges in Norway. How is IFC Bridge adapted to these materials? What about unique details, components, joints for these bridges?
  5. Modelling of details
    Today different details that are crucial for verification/approval work we do, are modelled. Some are listed below. How do you recommend to model these details in IFC Bridge?
    a. Areas for jacking systems (bearings)
    b. Embedded (steel) details (exact position)
    c. Cathodic protection
    d. Formwork
    e. Joints in timber brigdes
    f. Grounding/earthing system (electrical)
    g. Requirements regarding free space for traffic (height, width)
  6. Railing/Parapets/barriers
    We have different types of railings in Norway. Examples are railing for roads, bridges (including barriers preventing snow from falling down on underlying roads), pathways, rail over railroad, noise barriers, etc. Should this be different types of railing?
  7. Does IFC Bridge differ on cast in place and prefabricated elements?
  8. How does IFC Bridge incorporate different construction stages?
  9. How are the axes of the bridge defined in IFC Bridge?
  10. We cannot find any information about movable or floating bridges. Are those within the scope of IFC Bridge?
#4

I have three comments to the IFC 4.2 draft:

  1. As far as I understand, it is a change in the core that new abstract entities are established between IfcSpatialStructuralElement and IfcBuilding and IfcBuildingStorey. I would suppose that such changes in the core cannot be done in a minor release and was expected to happen in IFC5?

image

  1. In the IFC Infra Overall Architecture project, Final (01/03/2018), those new abstract classes had other names, IfcBuiltFacility and IfcBuiltFacilityDecomposition. I don’t find any explanation of why this is changed, and I would prefer the names from the Overall Architecture Project.

image

  1. In the documentation, IfcSpace is used for outdoor areas like lanes and roadshoulders. I would propose to establish a new entity IfcCivilSpace to avoid confusion between the traditional use of IfcSpace in buildings and this use in infrastructure models. This would be in line with establishing IfcCivilStorey.

image

1 Like
#5

answer to question 1.)

the rules and criteria for upward compatibility between IFC releases (as created during the IFC4 development process) stated, that any change that does not infer with the part 21 exchange structure (the structure of the IFC STEP physical file, or *.ifc file structure) is acceptable. The introduction of an intermediate supertype without having own attributes does not change it and is acceptable.

Therefore I don’t see a compatibility reason to not include them in IFC4.2.

#6

Thanks for the clarification, @TLiebich. But wouldn’t @kjell.ivar.bakkmoen’s point about the name still be relevant? I would think that even these supertypes would be harmonized across the Infra module of the schema.

#7

1.) There was a long and intensive discussion in the frame of the “Common Schema” project which serves as a plattform for coordination across all running infrastructure extension projects. The outcome can be seen above: A new superclass Facility and a new superclass IfcFacilityPart.

  1. [kjell.ivar.bakkmoen] is right. The proposal by the Overall Architecture project was different. However, that part did not reach consensus to become standard so far (and not of the schema). The discussions were continued in the Common Schema project and resulted in a diverging resolution.

  2. IfcCivilSpace and IfcCivilStorey were discarded by the Common Schema project. Most probably, the IfcRoad project will use IfcSpatialZone. But this is ongoing work.

#8

a remark to the naming issue in general (IfcFacilityPart vs. IfcFacilityDecomposition vs. xxx). We need to decouple the discussion of naming of IFC classes from their appearance in a user interface. Here I want to emphasize the IFC translation project, where we want to provide natural language translations of the IFC Terms, this also includes Englisch as a language.

#9

To make it easier for domain people to review, it could be beneficial to include some sort of traceability/mapping from the (numbered) requirements through the conceptual model elements to the IFC Bridge extensions in the EXPRESS schema. Maybe a table would suffice?

#10

Dear Sir / Madam,

We thank you for your valuable feedback.

Here are the project team’s responses to your remarks:

Do you have a plan for implementing IFC Bridge in the different national management systems? How can we implement the classifications in our management system in IFC Bridge?

As an international project, we do not have the resources for implementing IfcBridge in the different national management systems. This task remains for the national authorities. However, the Infra Rooms will setup a deployment project. If you join this project you will get support in implementing the standard in your national maintenance system.

IfcBridge does not provide a fine-grained classification. Instead it makes sure that reading and writing applications make consistent use of the provided entities for transporting bridge information. However, there a well-defined mechanisms to integrate national classification systems with IFC, using property sets and specific IFC entities (IfcClassification). A detailed explanation can be found in the IFC Infra Overall Architecture Report, pp. 32-35.

  1. The interface between geotechnics and bridge is a challenge in current models (and in the design control), and this issue needs to be solved. What about backfilling, frost protection, scour protection, sheet pile and how is this implemented in IFC Bridge? Is this covered by Common Schema?

Yes, the Common Schema project is developing data structures covering theses aspects. We have forwarded any requirements regarding Soil and Geotechnics from the bridge domain to Common Schema.

  1. Equipment/Installations
    How can we implement these installations in IFC Bridge?

Road equipment will be covered by IfcRoad. Some of the equipment objects are covered by the IFC schema already, such as IfcRailing, for example. In any case, you will be ale to use proxy objects and associate them with a national classification.

3.Tunnel portals, retaining walls, ferry quays and avalanche protection: Portals, retaining walls (height > 5 m), ferry quays and avalanche protection are considered as load-bearing structures/bridges in Norway. How should we implement and adapt these construction types to IFC Bridge?

The project team does not agree that all of the mentioned constructions are bridges. However, it is possible to model everything in IFC, if you use generic types and placeholders, such as IfcFacility and IfcBuildingElementProxy. You are advised to make use of “user-defined types” and the aforementioned possibilities to use national classification systems.

  1. Composite and wooden bridges: We have several composite and timber bridges in Norway. How is IFC Bridge adapted to these materials? What about unique details, components, joints for these bridges?

It is possible to assign all kinds of materials to individual components. Details and joints: On the semantic side, makes use if IfcMechanicalFastener and associate it with your classification. In the requirements analysis conducted in WP1 (finished in 01/2018) it was decided (and approved by the expert panel) not to include wooden bridges in the scope of the fast-track IfcBridge project. However, we believe that you are able to model these bridges in IFC.

  1. Modelling of details. Today different details that are crucial for verification/approval work we do, are modelled. Some are listed below. How do you recommend to model these details in IFC Bridge?

This question is a too detailed to be answered in this forum. If you join the Deployment project, you will get the required support. Most of the details can be modelled geometrically and combined with existing semantic classes.

  1. Railing/Parapets/barriers: We have different types of railings in Norway. Examples are railing for roads, bridges (including barriers preventing snow from falling down on underlying roads), pathways, rail over railroad, noise barriers, etc. Should this be different types of railing?

All rails can be described using IfcRailing. More detailed requirements can be modelled by classifications. Geometry concepts are plentyful and standardized. We will produce sample files illustrating this.

  1. Does IFC Bridge differ on cast in place and prefabricated elements?

You can, but you do not have to. You can use the PropertySet Concrete Element General to define specific properties.

  1. How does IFC Bridge incorporate different construction stages?

This is only partially handled so far. You can assign schedule information to indvidual parts. However, construction stage deformations are not yet explicitely adressed (not in scope of IfcBridge 1.0). However, we propose to use different models for each construction stage.

  1. How are the axes of the bridge defined in IFC Bridge?

You can use IfcAligment(s) and define additional reference lines (axes) by means of offsets, for example.

  1. We cannot find any information about movable or floating bridges. Are those within the scope of IFC Bridge?

No, not in the IfcBridge 1.0 Fast Track Project.

The IfcBridge project team

1 Like