There is quite a lot of interest in ‘BIM for Infrastructure’ at the moment.
From my perspective: it is great that digital design & construction is becoming more widespread. However, infrastructure design is quite different to ‘traditional’ BIM.
Some infrastructure projects include a ‘borrowed’ BIM specification from a building project. A well intentioned (but misguided) client engages a BIM consultant & ends up with something practically useless.
For example, specifying COBie & a LOD 5oo model of a road and earthworks is pointless. You really don’t want a Revit model of train tracks & overhead wiring.
You can’t assume that the same BIM tools, techniques and processes can be applied to all construction projects. That is not to say that ‘BIM’ can’t be used in infrastructure, but it is a very different beast.
[As an aside, a software salesman (who calls himself a ‘thought leader’) told me that designing linear infrastructure is the same as designing a building, “it is just laying down on its side”. No, it is not, and that is a stupid thing to say]
2 Tribes: Strings vs Elements
Design in linear infrastructure such roads, rail or tunnels is string based and is fundamentally different to element-based design, such as buildings, structures or plant.
A string represents a path in three dimensional space. So you might have a string that represents a road carriageway material edge, the top of a kerb, or the obvert of a pipe. The string itself is normally a non-dimensional entity (i.e has a zero thickness) and either the layer or name of the string denotes what it is, or it might have a few attributes.
Another variant (which I will treat as an ‘array of strings’) is triangulated mesh design. Instead of being joined to just 2 linear neighbours, each point is joined to at least 3 neighbours. This is also a slightly abstract method to approximate a surface or strata. The mesh itself is dimensionless and represents say the upper surface only. Placement of points is along important features such as changes in direction or high/low points, with an interpolation between points using mathematical methods such as delaunay triangulation.
In simple terms: it isn’t necessary to model every chunk of concrete and pipe such that the model exactly represents the aforesaid concrete or pipe. A string to represent it is enough.
This is compared to say, a model of a building that includes elements such as beams, columns, walls, doors,pipes and ducts, where the element itself has dimensions and a large number of properties or attributes.
Large infrastructure projects also cross over into the world of GIS, which can be 3 dimensional, but is typically less concerned with the vertical dimension and is more about mapping on a hypothetical earth surface (geoid).
I also think that many people in civil/infrastructure design would say that they have been using model-based techniques and tools successfully for many years. Rebranding this as ‘BIM’ and presenting it as something new is misleading.
Geometry
The geometry in infrastructure design is often more complicated than other BIM.
Rather than being orthogonal or simple lines & arcs, it is based on clothoids, cubic spirals & parabola, sinusoidal curves, superelevation, points of tangent and other mysterious mathematical stuff.
Revit doesn’t know any more about clothoids than I do (unless using external tools such as Dynamo)- it just knows about lines, arcs and at a stretch, splines.
Where the two tribes meet
Many projects have a mixture of string and element based design.
For example, a road tunnel project might have buildings or ventilation systems (element) as well as tunnel/road alignments (string).
Although it is possible to bring the two together, this often involves dumbing down the data- often to the lowest common denominator of formats such as DWG.
So in the above example, the architect might have to convert their Revit model to DWG so that the civil engineer can use it. In the other direction, the road or civil engineer might need to convert MX or Civil3D data into solids, also using the DWG format.
Although there are formats such as GENIO or LandXML which offer some data translation and tools such as Revit & Civil3D & Infraworks have limited interoperability, it isn’t pretty. The root cause is that these systems have developed independently, and are gradually converging into this thing we now call ‘BIM’.
Design processes
Processes such as ‘clash detection‘ used in building design do not necessarily translate into infrastructure design. Checking a dimensionless string against a dimensional element doesn’t make sense. It is a case of apples & oranges.
Furthermore, it is quite different to say a building, where if a duct goes through a slab, then you would expect a suitable penetration to be modelled in the slab. In a civil/infrastructure context, if a pipe goes through compacted fill & a retaining wall- then it is pretty obvious & the void for the pipe would not be modelled.
That said, some of the techniques in broader BIM such as model federation can have a benefit for design coordination, if the interoperability & file format issues I cover above can be addressed.
IFC
The whole IFC thing is quite bewildering to me. I can’t imagine anything more unnecessarily complex or poorly documented and explained. I guess an academic somewhere in Sweden understands it. But I digress. My understanding is that the future IFC5 schema will include Civil/Infrastructure object classifications, in addition to the current focus on buildings.
As it stands, some civil design applications have the ability to export IFC files- but it seems to me more of a box-ticking exercise for the software vendors. Yes, a file with a .IFC extension will be produced, but useless for most purposes particularly since the schema does not contain appropriate objects.
Why BIM ?
Rather than blinding specifying that a particular project will be delivered using BIM, it is important to define what will be modelled, how & why.
The starting point is the end.
In other words. you need to work backwards from the requirements to design, produce documentation and also in the end-use of the data.
As I have said, specifying a LOD 500 IFC model and COBie for a rail or dam project is pointless unless the client or operator will make use of the data.
Operational use of data
The operational aspects of a infrastructure project such as a road, bridge or tunnel are obviously quite different to a building.
For a road, a COBie style record of warranties, spare parts and service requirements is generally not necessary, apart from minor bits & pieces such as street lighting or drainage. But you might need some kind of maintenance tracking system to record pavement deterioration and repairs.
Summary
BIM or ‘digital engineering’ does have a place in infrastructure design.
However, it is essential to define the objectives, to apply an appropriate brief & then develop method & processes to meet this. This applies specifically to the end use of data where it can be of value to the owner or operator.
Otherwise, it is just hype or window dressing.
HANNELL on BIM 