The Open Design Alliance (ODA) has a strong reputation for providing a series of software toolkits that enable developers of CAD and building information modeling (BIM) software to better support software interoperability via a variety of common file formats, such as AutoCAD drawings (DWG), Autodesk Revit (RVT) projects or Industry Foundation Classes (IFC).
ODA collaborates directly with buildingSMART, the international organization responsible for the development of a series of open standards for the construction industry. The IFC schema was contributed to ISO, where it has been adopted as an international standard in the ISO 16739 series. So far, three versions of the schema have been published by ISO: IFC 2x3 TC1 (ISO/PAS 16739:2005), IFC4 (ISO 16739:2013) and IFC4 ADD2 TC1 (ISO 16739-1:2018), with IFC4.3 planned for ISO publication in 2023.
More and more construction projects have come to rely on IFC as the ubiquitous open standard and related file format when sharing project information of buildings or infrastructure projects between software tools. With so many downstream processes relying on the format, quality control is essential. This is true not only during design or construction phases, but also even more so during the handover and operation stages. Open data formats fit very well within long-term strategies of continuous access to data—independent from software tools, license subscriptions or platform costs. Today, nobody can tell you which tools, formats or platforms will be relevant in 30 years, but chances are that you will still be able to parse IFC files or incorporate their content in future open standards. The same cannot be said about information captured in proprietary data formats.
The ODA IFC SDK, a software library to manage geometry and other information in IFC files, has seen a strong expansion in just a couple of years and the usability of the toolkit has just been expanded with a new system to validate IFC files, which is available for all ODA member levels: the IFC Validation Engine.
The engine can be used on itself, by integrating it into software, but it can also be applied via the latest version of the free OpenIfcViewer, making it accessible to non-developers as well.
This viewer for IFC files has quickly expanded its feature set over just a couple of releases and borrows heavily from other ODA software toolkits, for example, for efficient 3D real-time viewing, navigation, sectioning and even clash detection. It is also a cross-platform on Microsoft Windows and Apple macOS, although macOS users may be surprised to find a complete Windows-style interface, without the familiar red-amber-green window management gizmos that one might expect at the top left corner of the user interface. Functionally, it doesn’t matter that much as the features are the same on both platforms.
The new validation module within the viewer allows one to check the validity of an IFC file and generate an error report. The report lists where the file is not following the expected structure of an IFC file.
About Model Validation and Checking
When it comes to file and model validation, different approaches are used in the industry. We want to dive a little deeper into how they differ and where the ODA announcement fits into the whole quality assurance process for models exchanged from BIM authoring software.
Checking the Validity of the File Format
In the case of IFC, this would involve the verification against one of the published IFC schemes. IFC 2x3, the older version of the schema, is still widely used in the industry and has the best support across software applications, with many tools having obtained certification. The current IFC4 schema is still not as ubiquitous as the older files, which is a pity, as it has been reorganized and expanded to better align with industry expectations. The objective of file validation is first and foremost to determine whether the file follows the requirements of the data scheme.
The IFC schema and its related model view definitions (MVD) not only describe the kind of entities you may include in an IFC model, such as IfcWall, IfcSpace or IfcBeam, but many of its entities also contain so-called Where clauses or rules. These rules set additional constraints on certain attributes that are used to define the different entities. Such rules are inherently embedded as part of the scheme to indicate constraints or enforced agreements, which provides the opportunity for automatic verification.
The ODA IFC Validation Engine provides the necessary toolkit functionality to query, parse and validate an IFC file in one of the different supported schemes against these Where rules. A good example of such clauses or rules is the requirement to have at most one IfcProject occurrence in an IFC file (IfcSingleProjectInstance).
Another example is the requirement that all XY planes of the possibly different world coordinate systems be coplanar and identical (IfcRepresentationContextSameWCS).
Another rule that is common for the PredefinedType enumeration found in many entities of the scheme is the need to have it set either at the instance level or at the related object type, which can be shared by different instances of the entity.
And there are many more rules scattered across the scheme.
Think of these rules as a kind of sanity check. Is the file itself sound and valid before you start to rely on it in your workflows? Are there any mistakes against the schema?
While Where rules are part of the IFC schema, they are not currently that widely used or fully implemented in software tools. IFC files exported from common BIM authoring software don’t always follow those rules completely. The developers of IFC exporters have many decisions to make, and even though some files have been made configurable in the user interface, the end user is not in control of many others. The system decides for us how to generate an IFC file.
There are IFC exporters that allow you to create files that would have to be classified as being noncompliant if you followed the schema strictly. Sometimes developers acknowledge this and even state it explicitly into their documentation. A good example is the option in the Revit IFC exporter to support the decomposition of an element not into IfcBuildingElementPart entities but into actual defined entities, which is not what the IFC scheme prescribes. Apparently, IFC viewers are also quite relaxed in accepting such anomalies. Even when the file includes errors against these rules, most viewers still open them without providing a warning or error message. And to be honest, most users don’t really care, provided the model appears to be complete and usable in the receiving software.
The lack of enforcement of the Where rules possibly motivated buildingSMART Technical Director Léon van Berlo to question the eventual removal of the rules from the schema as part of the modernization of the whole technological underpinnings of the IFC schema that is in preparation. However, such rules are still part of the certification process, as confirmed by Thomas Liebich.
Implementer’s Agreements
In addition to Where rules, there are also so-called implementer agreements, which are important specifications or explanations for developers to ensure that the IFC files they export or import adhere to additional rules and that they have a more consistent implementation in the industry. Unfortunately, such agreements are less formal and are written in plain text. They are not embedded in the main schema or documentation. As a result, integrating such agreements is left to the goodwill and perseverance of developers.
Documentation Agreements
And finally, many clauses or agreements are simply written as part of the documentation, in textual explanations, in between the rest of the entity documentation. They are part of the IFC standard and are retained in the documentation paragraphs but are not at all embedded into the IFC scheme as computer-interpretable rules. As explained already, this puts a strong burden on developers of IFC-compatible tools or routines to take such agreements into account.
To conclude, not all rules or implementation agreements have been fully adopted by BIM authoring software. This is something to consider when receiving IFC files. For this reason, the IFC Validation Engine provided by ODA is an interesting solution that at least assesses the adherence of a file against these rules.
A Second Approach: Model Checking
Model checking has long been the almost exclusive playing field of Solibri in its Office or Enterprise product, but more and more software tools, such as Simplebim, BIMcollab Zoom Pro or DESITE BIM, now support model checking.
In contrast with the validation against the IFC scheme, these systems focus primarily on the content of the model, for example, by looking for geometric clashes, expected object sizes, positioning of elements or specific required properties, attributes and classifications. To a certain extent, an application like Solibri also provides a series of rules related to the quality of the file itself—like checking for duplicate IDs or if the spatial structure is available in the model—but in general, the Where rules are covered in detail.
Even when you generate a valid IFC file and have possibly checked it using the ODA IFC Validation Engine, it may still contain erroneous information. So, an IFC validation engine must be understood as a complementary step in the quality assessment of IFC files.
You could state that a validation engine checks the quality of the file, whereas the model checker validates the model against design rules, legislation or technical requirements for the project. These are two complementary activities in the quality assurance of information models, and it is recommended that you apply both approaches when performing a so-called health check of models that are exchanged in a project.
We have also seen an increased emphasis on model checking in various new and upcoming web platforms, such as Singular, Kreo, validationhub by matterlab or Regola.
They all use slightly different approaches, but they all provide a means of automatically checking a model checking against requirements and they all focus primarily on IFC files having the widest support regardless of the software used to create such models.
And let’s not forget the countless custom checking routines that people put inside their authoring software, such as a filtered view, where all problematic objects are isolated, or custom schedules to list and highlight objects that have erroneous properties or attributes. When a user sees such objects being highlighted and selected, they can more easily start to determine what is wrong and what measures to take.
Beware: none of the approaches above will solve a problem in a model. They all report errors and give the users the means to drill down to the objects involved but the resolution of model problems requires a step-by-step interpretation by an expert of the software, or by a construction professional in the case of design-related issues.
The Role of Standardization
In addition, for model checking and validation, we also see a few initiatives within standardization groups, such as ISO/TC 59/SC 13, CEN/TC 442 and buildingSMART, which all collaborate on international BIM standards.
Specifying Information Requirements
The Information Delivery Specification (IdS) project is an effort by buildingSMART, with input from a variety of experts from software developers, industry and a delegation from standardization working groups. This initiative focuses primarily on the alphanumerical information, where an information receiver can state the different required properties, including restrictions on data type or allowed values, and maps those against the IFC schema. The result is an XML file that can then be used to validate the content of a model delivery in the IFC format. Some developers have already implemented preliminary support for this format.
Another notable evolution can be found in the level of information need. This concept from ISO 19650 has been elaborated at CEN in the EN 17412-1:2020 standard. Without diving deep into the standard, it presents concepts and principles on how to define information requirements. Information requirements could be stated by an information receiver in plain language or, quite commonly, in a table of required properties. But to incorporate these requirements into automated processes requires computer-interpretable specifications of information requirements. This is currently in development.
Issue Tracking and Communication
While the IFC standard (ISO 16739) already contains the Where clauses as part of the scheme, we also must mention the BIM Collaboration Format (BCF), which has been widely adopted as a standardized way to communicate comments or issues that are linked to the unique ID of objects and contain a screenshot and camera viewpoint to be shared between software. BCF is not yet a published standard, but its support in the industry is widespread, both for BCF (zip) as a file format and via the standard BCF-API for direct interaction between software systems.
In fact, more and more checking or validation systems allow you to generate series of BCF-compliant issues as part of their output reports. The importance of this cannot be underestimated as this enables traceability and the organization of issue tracking workflows, which is not feasible when a checking report is simply a textual list or table of remarks and issue numbers. People cannot really resolve problems in a model if the problem report is just a long spreadsheet with thousands of rows with cryptic error codes, element IDs and generic rule descriptions. Having a BCF-based issue database or platform turns issue tracking into a managed process and effectively enables the issues to be tracked, from their first encounter to delegation and eventual resolution or closure, when they are deemed to be acceptable in the context of the project.
Conclusion
The announcement of the IFC Validation Engine by ODA fits well within current evolutions of BIM checking methods and we look forward to seeing the whole industry further improving the quality assessment processes, preferably using open standards-based workflows across platforms and across software systems.
Especially useful to the industry is the validation of the files themselves, as opposed to the already established model checking approaches. Validation provides a complementary tool in the arsenal of BIM quality assessment solutions.