Comparing IFC Exports from AVEVA E3D, Autodesk Revit and SolidWorks/3DEXPERIENCE

IFC is a standard exchange format, but IFC files exported from different authoring systems do not look identical in practice.

That becomes very obvious when building an IFC comparator.

The current Model Bridge development is tested with files exported from AVEVA E3D, Autodesk Revit and SolidWorks/3DEXPERIENCE.

All three can produce valid IFC. The engineering meaning available to the comparator can still be very different.

Revit IFC

Revit exports typically provide a useful combination of standard IFC classes, names, object types and property information.

For building and MEP models this can make it possible to distinguish categories such as flow segments, fittings, terminals, cable trays, equipment and structural/construction objects.

That semantic information is valuable for progress KPIs because a Design Manager usually wants to know more than the total model size.

They want to know which part of the design changed.

AVEVA E3D IFC

Plant design introduces a different structure.

AVEVA E3D models can carry engineering information through attributes such as DBREF, OWNER and TYPE.

This information can help reconstruct plant-oriented identity and hierarchy beyond generic IFC class names.

For EPC projects, that is important.

A pipe component, equipment object and structural item have very different engineering meanings even if all are ultimately represented through IFC geometry.

A source-aware adapter can use the information that survived the export rather than discard it.

SolidWorks / 3DEXPERIENCE IFC

Mechanical CAD exports can be semantically more generic.

A SolidWorks/3DEXPERIENCE IFC model may contain many objects represented as generic IFC proxies.

The comparator can still analyse geometry, placement and revision changes, but category-level engineering interpretation may be less detailed.

This is not a failure of the comparator.

It reflects the information that the exporter actually provided.

A trustworthy report should preserve that distinction instead of pretending that missing semantics can be reconstructed with certainty.

Why source awareness matters

A generic IFC parser can count classes.

An engineering comparator needs to answer harder questions:

• Which represented objects correspond to meaningful engineering elements?
• Which hierarchy is informative and which is only export structure?
• Can objects be matched across revisions?
• Which properties are stable enough to support identity?
• How should generic proxies be handled?
• Can category KPIs remain comparable from one revision to the next?

These questions depend on the authoring source.

That is why Model Bridge includes source-oriented interpretation logic before producing management-level KPIs.

One KPI framework, different semantic depth

The current goal is not to force all three authoring systems into identical semantics.

It is to produce the strongest reliable analysis possible from each source.

Across all sources, the common framework includes:

• revision chronology;
• unique represented 3D elements;
• additions;
• deletions;
• modifications;
• placement changes;
• model-development trends.

When stronger source semantics are available, the report can add more meaningful engineering categorisation.

Interoperability as a practical problem

OpenBIM workflows are often described at the format level: export IFC, exchange IFC, federate IFC.

Real projects operate at the information level.

A model is useful only if the receiving workflow can interpret the data correctly.

For comparison, the challenge is even greater because meaning must remain stable across time.

A property that exists in one revision but disappears in the next can affect identity. A hierarchy that changes between exporters can alter counts. A source application update can change the exported representation.

These are exactly the problems that make real-world comparator testing essential.

Why this matters for future project-wide control

A future project-level analysis may need to combine IFC deliveries from several authoring systems at the same time.

For example:

• process plant and piping from AVEVA E3D;
• buildings or MEP from Revit;
• mechanical packages from SolidWorks/3DEXPERIENCE;
• additional IFC models from subcontractors.

Project-level analytics will only be useful if those sources can coexist without losing their individual meaning.

The source-aware work being done in the current comparator is therefore not only a first-release feature.

It is also a foundation for the larger multi-model project-control concept.