In the May/June issue of the AEC magazine, there were some excellent articles about IFC. Take a look at it here if you haven't already: https://issuu.com/x3dmedia/docs/aec mayjune22/66
The IFC schema is a vast subject. However, there are certain
crucial topics to cover, especially for those who don’t design buildings. When it comes
to IFC, Infrastructure (facilities and assets other than buildings) has been
the poor cousin to our colleagues working in vertical design. However, we
shouldn’t hold buildingSmart responsible because they have developed an open
file format that has achieved enormous success. It has made it possible to transfer
models accurately and with accompanying information and is already widely used.
We should acknowledge that as Infrastructure engineers, we to a while to recognise
the advantages of this solution, and that we might have received better service
if we had shouted earlier and louder. However, it is the past, and right now we
are enjoying the fruits of some excellent work that buildingSmart has done in
the background to bring us infrastructure-specific content in the IFC schema.
The
definition of IFC Alignment in IFC 4.1, which was a crucial first step in
defining the linear referencing system utilised for our transportation and
other linear route designs, is built upon in the projected release of IFC 4.3. It offers the framework on which we can “hang” the plans for our
pavement, rail and bridge designs upon. We now have definitions for IFC Rail,
IFC Road, IFC Bridge and IFC Ports & Waterways in IFC 4.3; tunnels will be
coming in the future.
In addition of IfcFacility as the top entity in the hierarchy,
with IfcBuilding sharing the same level as IfcRoad and IfcRailway, is another
minor but significant modification (alongside other entities). With this
framework, a multi-discipline asset model is now more accurate represented, and
it will be easier to federation multi-disciplinary models for larger projects
where both horizontal and vertical designs co-exist.
What benefits will IFC 4.3
provide?
In
the long run, the addition of infrastructure entities in IFC 4.3 will allow us
to start investigating open collaboration between various technologies and
fields.
Even
though we may federate models from several disciplines with the help of
technologies like Navisworks, we frequently exchange files in proprietary formats. Even if we may compare designs and their interfaces, in order to make adjustments, we must return to our design programme to make changes,
frequently without the advantage of being able to import and use all of the
models satisfactorily. Of course, there are ways to connect models; for
instance, we can link a Civil 3D model
to Revit,
but the outcome is frequently less
than ideal. I am looking forward to the day when we can link an infrastructure
IFC file into Revit
and be able to interrogate data and
objects regardless of the programme that created them. Perhaps design
consultants will be allowed to use whichever tools they have available, as long
as they support the most recent version of IFC and collaborate well with other
design teams.
Large projects are making commitments to sustainability goals, and
the data needed to crunch the numbers will inevitably come from the digital
models’ data. Our ability to provide all models, regardless of their source, in
the same machine-readable format, will allow the development of streamlined
tools to extract and collate this information efficiently.
IFC and Autodesk Civil 3D
As an experienced Civil 3D user,
I am very curious in how we can apply IFC in practice. Civil 3D’s most recent
versions support IFC2x3, 4 and 4x1. The
IFC 4.3 export tool Autodesk developed is currently undergoing Alpha testing,
and the initial results are promising. However,
as is typically the case, software that is still in development rarely has a complete
set of features, which poses a number of issues. How much can it be customised?
Since we don't just build roads, we also need to be able to assign properties and types, as well as employ corridor models
for various types of assets, like retaining walls or swales.
Having recent conversations with clients who require COBie data
from a Civil 3D model, IFC export would be one way that we could facilitate
this, which would let us generate COBie from the IFC file. Naturally, for us to be able to achieve this, we will need to be
able to assign suitable data structures.
The way we use Civil 3D differs
greatly from how many other design software, like Revit, are used. Large projects designed in Civil 3D require us to
split our designs among numerous model files, and objects like corridors, may
be linked across those files. I anticipate that one
of the difficulties we will have to solve is making sure we don't duplicate
information in IFC exports. The ideal export feature would be able to
comprehend the entire Civil 3D project, rather than just individual files.
How
we handle local and Geospatial coordinate systems is another topic that needs
some consideration. In a perfect world, we would be able to specify both in
Civil 3D, allowing the resulting IFC file to be linked or imported into other programmes
that heavily rely on local grid systems, like the majority of programmes used
for building design.
We can't now use IFC 4.3 since software providers are still
working on developing and testing new import and export tools, so we will need
to be patient. However, I would advise Civil 3D users to look into and play
with with the formats that are currently supported. With the available tools,
we can export objects from Civil 3D, but this does mean that most of the exported objects are
IfcBuildingElementProxy entities and do not have defined types. Although this
is not ideal, giving these objects the appropriate Property Data will give us
the definition we require. Linking an
IFC file created by Civil
3D into Revit can produce
some effective effects, such as adding site drainage designs. We have talked
with several of our clients about this subject, and we can offer solutions that
will make the switch to collaborative working on BIM projects much simpler. For
example, Symetri's Naviate tools for Civil 3D
can offer an automated solution for collecting information from Civil 3D and AutoCAD and adding it
to relevant Property Data Sets given to objects. Numerous properties, including chainages, sizes, lengths, and
volumes can be automatically allocated and subsequently updated to account for changes
made to the objects or their linked alignments or corridors.
Regardless of where you are in your BIM journey, we are always delighted
to talk about workflows and new concepts. I have always
found our customer interactions and discussions enlightening over the years, and my colleagues and I look forward
to being challenged with fresh issues and ideas. I’m hopeful that some of you
will accept the challenge to make use of IFC as an OpenBIM format on your
projects, and maybe together we can define some truly fantastic advantages.
Would you like to find out more about Civil 3D? At Symetri, we provide a wide range of Civil 3D training courses to help you improve project delivery, maintain more consistent data and processes, and respond faster to project changes. For more information, please contact us on 0345 370 1444 or info@symetri.co.uk.
Further information:
IFC Overview:
http://ifc43-docs.standards.buildingsmart.org/
IFC 4.3 Schema Definition:
https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC4-voting/HTML/
