¶ IFC Route - Definition of information exchange for route structural model
The final products of the project:
- Documentation of the IFC data exchange methods
- Use case descriptions for selected use cases
- This wiki article describing the project's conclusions and recommendations for further development, as well as implementation methods for IFC localization.
Published documents are:
Use case descriptions:
- Data transfer from design to construction (in Finnish)
- Quantity takeoff (in Finnish)
- Digital handover (limited to during/after construction, in Finnish)
¶ Foreword
Inframodel format is widely used in Finland for the data excange use cases mentioned above. However, it is based on aging LandXML which is setting some limititations for the design file content. For this reason, many dierent types of documents (ie. drawings, spreadsheets, pdf) are typically used together with Inframodel. On the other hand, IFC 4.3 provides too diverse set of features to be properly machine processed, unless further rules are applied. This document defines an minimal subset of IFC4.3 functionality which cover the defined data exchange use cases. Transition to IFC-based data exchange would allow machine readable feature rich communication.
The goal of the project was to define the information exchange needs for route projects, but limiting the scope to road and street models at this time. The scope was refined during the work, and for instance, base reinforcements, fittings, road markings, and structures like speed bumps were excluded from the work.
Three data transfer use cases were selected for the project:
- Design to construction
- Quantity takeoff
- Digital handover (limited to during/after construction)
Link to the project's GitHub repository: GitHub Repository Link
¶ Project content
The project defined IFC 4.3 data transfer documented in limited use cases. The documentation specifies information exchange in IFC 4.3 format for selected use cases. During the work, the required basic information, geometry, hierarchy, and properties of the use cases were defined and implemented with the IFC 4.3. The work was based on existing Inframodel definitions, Finnish common InfraBIM requirements (YIV), and infromation transfer requirements of selected client organizations.
The project was not aimed at publishing an actual technical specifation but laying the groundwork for future standardization efforts, focusing on limited use cases and comparisons between Inframodel (LandXML) and IFC4.3.
Several key definitions and clarifications were made during the project. The first infrastructure use cases were described in the project, so the basic and technical definitions had to be clarified first to successfully define the actual use cases. Basic matters include standard IFC structure and general project-related information such as IFC File Structure, File Headers, ifcProject and Classification. Additionally, the documentation structure and description method were designed, which will serve as the foundation for future work and IFC 4.3 localization in Finland.
The entity hierachies, geometric representations and property sets for information exchange for use cases were defined by using UML language, tables and illustrative images.
Documentation was written with enhanced markdown, UML and markdown were compiled as final PDF document using build automation provided by Github. Github is also used for version control, issue tracking and releases.
¶ Observations during the project
Several areas of improvement were identified during the project.
Full transition to IFC4.3 based information exchange would need lot of definition and documentation work and requires long-term commitment, as well as extensive participation from the industry.
IFC4.3 offers too diverse options for information exchange compared to the current Inframodel exchange, so strict subset of capabilities needs to be defined for each use case.
During the work we also noted that breaking down larger use cases into smaller ones would be advisable. This requires a lot of groundwork and participation of subject matter experts.
On the other hand, breaking the use cases into too small parts is not always an optimal approach. Breaked down issue may be part of a broader context, and could lead to missing bits and pieces on definition. This can easily lead to project expansion as a considerably more significant amount of rework and clarification may be required.
As one of the results of the project the foundation for future specification work was established. This enables more agile IFC information exchange specification development in the future.
Key findings:
- Fundamentally, specification should be machine-readable, excluding descriptive text content intended for humans and developers. Currently there is no technology available which could be used for machine-readable specifications, only partial solutions are available (ie. UCM,IDS,bSDD,mvdXML)...
- New modern technology and tools are required to manage, describe, and share the informational, hierarchical and geometric representations required by different use cases.
- There should be a way to generate entity relationship diagrams such in UML or BPMN for human readers from machine-readable specification.
- UML diagrams significantly open up and clarify the proper use of IFC entities, but the diagrams should be formed from specification, it is simply too much work to remodel each diagram from IFC schema and documentation.
- Illustrative images were found challenging, and it is proposed for future projects to include a graphic artist to support the production of high-quality illustrative images.
- Close cooperation with software vendors is needed for full implementation at the field, specification alone is useless.
- Development of a better publication platform is needed to support standardization work. As an example, writing use cases should be part of the process done with build automation. In this project, the use cases were written as a separate part of the project, and we weren’t directly able to use property sets defined in the main document, which causes unnecessary “cut-copy-paste” actions and makes maintenance and change management of the use case definitions really complicated.
- IFC schema doesn’t work for validation purposes, part of the requirements are set at documentation.
- IFC documentation is confusing, challenging to interpret, and extensive. Challenges identified include the lack of user guides, implementation examples, and methods to define your own localization/subset.
- The lack of a guide titled "How IFC works" was seen as a challenge, and creating this would be highly recommended by bSI.
- Additionally, a comprehensive Finnish introduction to using IFC is needed in addition of specification(s).
- Development and maintainment of documentation for IFC information exchange specifications is far from optimal. Current IFC documentation and technologies do not support the work. Different bSI technologies are needed for software developers and even end users. This should be solved rather at bSI than bSF level.
- How would the specification be most reasonable to implement? For example, bSDD or IDS do not solve the entirety but serve as tools to complement requirements and share them.
- Defining only the local informational contents is not enough; geometric representationa and strict entity hierarchies are also needed.
- UCM is meant for describing use cases, but this is a separate tool for sharing human readable information, so it is not usable tool for specification development process. It would also be an extensive amount of work to cover all use cases of current Inframodel specification.
- It is not guaranteed that the links and references to IFC documantation (and other bSI technologies and tools such as bSDD) are permanent and realiable to be referred from specification.
- Some needs, especially ones of the infrastructure contruction sector haven’t been considered during the development IFC 4.3 specifications.
- The definition of IFCMaterial is not clear, enumerations are insufficient, and usability is not practical. This encourages defining various material information with Property sets which is far from optimal.
¶ Next steps
A broader Finnish IFC4.3 use case definition, specification and documentation requires long-term commitment and lots of work. Extensive participation from the construction industry is needed.
The current practices present challenges. IFC4.3 is richer in data transfer than current formats and enables many new use cases. However, the current standardization and documentation processes, which are not continuous and standardized restrict and slow down development efforts.
There is no clear vision and determination for what the development aims to achieve regarding information exchange specification development. A more detailed development path with phases, i.e., a road map, would support planned development and the adoption of new technology.
Naturally, this development requires sustainable funding and practitioners, as well as the commitment of the industry to development. The timing for broad adoption of IFC is difficult to predict; the work essentially requires thousands of expert work hours, policies supporting standardization, tools, and a bright goal.
In the future, all information exchange definitions, requirements, guidelines, and other documentation should be maintainable and shareable in one place as a whole, where desired or selected views can be inspected. The specifications and requirements must be accessible openly in machine-readable forms. This allows validating information during the information production and transfer process and at other information exchange points. Methods such as bSDD and IDS can work well for sharing this information. Tools and methods are needed to manage the entirety, i.e., a standardized process and technology for developing, producing, managing, and sharing content with users.
This requires technology and a process for managing the publication entirety, from which information can be shared in human-readable formats to users and machine-readable formats to technology.
Things to be clarified and defined include the related process, logic, ownership, use cases and rules:
- Goals and planned development:
- What are we aiming for, with what timeline, which work packages and wholenesses the work consists of, ensuring funding, etc.
- buildingSMART International technologies and definitions:
- bSDD - buildingSMART Data Dictionary, IDS - Information Delivery Specification, UCM - Use Case Management, mvdXML, and IFC data exchange documentation.
- How to implement technologies above in Finland. Rules, ownership, and use?
- Where these are used and which are the boundaries of use of each one, since there is some functional overlap between the different technologies.
- Development of Finnish comprehensive introduction to IFC.
- New development project to enhance Finnish InfraBIM classification system an guidelines.
- Develop standardized workflows and tools to support management, development, sharing of IFC information exchange specifications, classifications, and informational content.
¶ Project team
Juuso Virrankuja, Sitowise (Project manager)
Jari Kainuvaara, Sitowise
Juha Hyvärinen, JHy Consulting
Mikko Vesanen, Novatron
Niki Tapper, Ramboll
Timo Pitkänen, Arkance
Juha Liukas, Sitowise (quality assurance)