Cardno Victoria Pty Ltd
Melbourne VIC 3000
Australia
North East Link is the biggest road transport project in Victoria’s history. It will fix the missing link in Melbourne’s freeway network, connecting the M80 with an upgraded Eastern Freeway. The Early Works Package comprised the critical enabling works to enable efficient and value-for-money delivery of the Primary and Secondary packages, along with minimising critical interfaces and de-risking the North East Link. Cardno were engaged by CPB Contractors as Lead Designers, Utility Coordinators and Digital Engineering Leads for the planning phase of the project to assist with the relocation of a selection of critical utilities.
As the lead Digital Engineering & Utility Coordinators Cardno were responsible for coordinating 3D design between multiple different Utility designers in highly congested and constrained sites across the three project zones. A rigorous approach to Model Federation and clash detection was required to meet the utility owner approval requirements. The project client also had comprehensive 3D model file format and object metadata (attribution) requirements. IFC provided the data model interface from the Utility design applications, 12D Model and Autodesk Revit, for fully attributed 3D models to Autodesk Navisworks for Model Federation, and to ESRI Geodatabase and 3D DGN.
Motorway scheme in Melbourne, Australia, to connect the Metropolitan Ring Road at Greensborough with the Eastern Freeway at Bulleen, where the freeway would be upgraded from Bulleen Road to Springvale Road at Nunawading.
The North East Link Project (NELP) will fix the missing link in Melbourne’s freeway network. The proposed North East Link Project will connect the Metropolitan ring road (M80) and Eastern Freeway (M3) completing a ring road around Melbourne which includes the Monash Freeway (M1). It will be a safe and efficient freeway connection for 100,000 vehicles a day, linking key growth areas in the north and south-east. The North East Link will include:
- Victoria’s longest road tunnels: three-lane twin tunnels travelling for six kilometres, protecting properties and the sensitive Banyule Flats area.
- Interchanges at the M80 Ring Road, Grimshaw Street, Lower Plenty Road, Manningham Road and Bulleen Road.
- Melbourne’s first dedicated busway with express lanes along the Eastern Freeway from Doncaster towards the city.
The NELP Early Works package comprises critical enabling works, to enable efficient and value-for-money delivery of the NELP Main Works packages (Primary and Secondary) and minimising critical interfaces thus de-risking the Main Works delivery.
The Early Works are being undertaken across two phases, planning and delivery, under a Managing Contractor arrangement between CPB Contractors and the State. The scope of the NEL Early Works is comprised of:
- Treatment of 100+ services allocated to Early Works scope dispersed along the NEL alignment
- Temporary Works at the Simpsons Barracks
- Construction of sport ovals
- Other potential scope for service relocations
As the lead Digital Engineering & Utility Coordinators Cardno were responsible for coordinating 3D design between multiple different Utility designers in highly congested and constrained sites across the three project zones. A rigorous approach to Model Federation and clash detection was required to meet the utility owner approval requirements. The project client also had comprehensive 3D model file format and object metadata (attribution) requirements. IFC provided the data model interface from the Utility design applications, 12D Model and Autodesk Revit, for fully attributed 3D models to Autodesk Navisworks for Model Federation, and to ESRI Geodatabase and 3D DGN.
North East Link (NEL) is one of the first projects in Victoria to be guided by the principles and expectations of the new Victorian Digital Asset Strategy (VDAS). The Victorian Digital Asset Strategy sets out the vital process for safeguarding the digital systems that will allow state government to monitor and improve the creation and management of infrastructure assets in Victoria. The VDAS provides a modern and best practice approach, developed in collaboration with industry and is aligned with international standards and best practice, such as International Standard ISO 19650: Organisation and digitization of information about buildings and civil engineering works. VDAS recommends that BIM collaboration occurs using OpenBIM formats such as IFC, except where proprietary formats may be more beneficial.
NELP, the Victoria governments NEL project team, have defined the BIM requirements to manage the complex interfaces of the project. Such as Early Works interfacing with Utility Service Providers (USP’s) and the projects Primary Works teams; and utilities interfacing with roading / rail / tunnelling / structures elements etc. The BIM requirements dictated several file formats be generated from the source modelling, in this case all the existing and proposed water, drainage, gas, comms, electrical utilities in 12D Model. These formats were IFC (trimesh), ESRI Geodatabase (Z-enabled lines and nodes), 2D DGN (lines and nodes) & 3D DGN (trimesh), all with lots of custom attributes.
For Utilities the Australian Standard AS-5488:2019 Classification of subsurface utility information, is both a required project Standard and a guiding document to ensure good utility management practices are followed. Cardno have been closely involved in the development of this Australian standard and have developed strong practical implementation processes and methods for projects of this scale and utility complexity. The North East Link project is one of the largest utility relocation projects in Australia and the Early Works project team have been able to lay a foundation of good utility data and risk mitigation practice for the Primary & Secondary works packages to benefit from.
With the project’s BIM guidance and Standards defined, the Early Works project team set about identifying the BIM software ecosystem and detailed data workflows to meet these requirements. It is well known that horizontal Civil Infrastructure has only had a coordinated OpenBIM focus within the last few years. Horizontal Utilities specifically are still seeing very little focus. The development and implementation by software developers of OpenBIM Standards for civil elements has lagged behind those for vertical Building Infrastructure. Project specifications and best practice data workflows between authoring and downstream consuming applications are not well established, particularly for utilities. The NEL Early Works project team therefore had to develop custom data workflows to work around the lack of Standards and demonstrated and established industry best practice.
With IFC being defined as both a federal government recommendation and a project requirement, the project team sought to pivot as much of the data workflows and 3D analytics around this OpenBIM format. The lack of specific semantic definition for the projects complex utility objects in the current IFC versions, pushed objects to trimesh and the IfcBuildingElementProxy element definition, and metadata to custom IFC Attributes Trees. Whilst this resulted in loss of network information it did allow a consistent method across both pipeline type utilities (water, sewer, stormwater and gas) and conduit type utilities (power and comms) for interpretation in federated models, clash detection and downstream model file formats. FME was used extensively for QA and file transformation.
There were four separate technical elements utilising/working with the openBIM IFC standard, within four separate BIM software applications within the project software ecosystem.
IFC & Clash Detection (NavisWorks)
- Description: Model Federation from different source applications, for the purposes for clash detection.
- Workflow: Early Works project 3D models exported directly as IFC 2x3, included utility models exported from 12D Model, mechanical / electrical / structural models exported from Autodesk Revit, federated with the primary Reference Design roading / tunnels / structural / ITS / drainage models etc. provided by others. Federated in NavisWorks for clash detection of proposed Early Works Utilities.
- Benefits of IFC: Use of an openBIM standard allowed for rapid and consistent model federation without intermediate data transformation and reliance on proprietary file formats.
- Project Achievements: This is a very common application of IFC on complex multiple discipline / design team projects. The particular achievement for this project was ease with which a) model objects from the projects primary Reference Design (by others) could be imported into the utility design application 12D, and conversely how b) the Early Works design could be federated in with the projects primary Reference Design for interface development by others.
IFC & Attribution (12D)
- Description: Effective attribution (metadata) management for utilities models
- Workflow: Pushing attributes from external utility metadata registers (excel) to Trimesh objects in 12D model, then export to IFC with IFC attribute families (trees). Then use of FME to read the IFC source and transform to Bentley DGN models as trimesh objects with attribute ‘tags’.
- Benefits of IFC: IFC attribute families (trees) allowed for a flexible attribute management approach using multiple different attribute sets (registers), linked by unique object ID.
- Project Achievements: The effective management of attributes on objects was a significant requirement of this project. An emerging expectation on DE driven projects is to have lots of LOI (Level of Information) on 3D modelled objects. This information is where the real value and power of DE can come from through the project / asset lifecycle. With lots of LOI, there needs to be a more sophisticated approach to attribute management than just loading ALL attributes on ALL objects. There has been a move to a more GIS style model to manage attributes, with the objects only holding a unique ID, and with different themed attribute tables managed outside the 3D model application in databases. These databases can be as simple as excel spreadsheets. These attribute tables are only pushed to objects when analysis needs to be performed in the 3D model application OR when 3D files need to be exported for sharing. The biggest achievement of this project was the implementation of this project attribute approach, through very effective data automation routines to push attributes to model objects AND effectively group attributes in IFC attribute families.
IFC & Data Integration (FME)
- Description: The client required project models (3D & 2D) in several different file formats, many with full object level attribution. Cardno utilitised FME to transform our source files (IFC for trimesh models & 12dxml for network models) to 3D DGN and GDB (ESRI Geodatabase) with attributes and to client symbology standards. Also 2D DGN without attributes.
- Workflow: Two workflows were needed in FME to generate the DE file formats required by NELP. The first was for the trimesh objects from IFC to 3D DGN. The second was for networked objects (lines and nodes) from 12dxml as source for GDB and 2D DGN.
- Benefits of IFC: Having an openBIM standard has allowed Safe Solutions to develop FME readers and writers from and to IFC, allowing effective automated transformations to ESRI File Geodatabase and Bentley DGN Trimesh objects, with full attribute tables / tags.
- Project Achievements: Single source of truth for all project DE files. In reality there were two sources in the 12d projects, the trimesh model and the network model (WN’s or superstrings), with automation to manage these in 12d. We introduced additional QA checks in FME to compare object counts and attributes between the trimesh and network source derived models, to make sure the conversion in 12D chains and FME we’re dropping anything. The opportunity for openBIM development to remove the need for two separate workflows for network and 3D is discussed later in this submission.
IFC & CDE (Synergy)
- Description: Model Federation using IFC source from the Common Data Environment (CDE), in this case Synergy is design-side CDE.
- Workflow: Checkout source IFC from Synergy database to local drives, generate and link NWC from IFC, update federated model, check back in to CDE.
- Benefits of IFC: Full version control and associations of sources used in published federated model, wholly managed within the CDE. No need for any network drives.
- Project Achievements: A challenge with any model federation is the management of the source IFC file versions to ensure the federated model is appending the latest approved files. In a Windows Explorer based WIP environment (typically network drives), version control of files can be problematic. By building the Federated model from with a formal DMS like Synergy it is possible to use the benefits of the DMS’s document version control and file association functions to a) ensure only the correct approved source files are used in the federation model build, and b) link the resultant published federated model file (NavisWorks NWD) with the actual source file versions for full traceability.
The benefits of using openBIM in general terms are well understood. The most applicable ones for this phase of this project is around the ability to standardise project delivery requirements by clients; allow all stakeholders (including future ones) to plan for downstream data use, and; the opportunity for users to develop new workflows and automations to reduce time and improve quality assurance.
The specific measurable benefits of use of IFC for the Early Works project team and for the NEL project are listed below:
- Confidence in pricing for delivery of requested BIM data file formats, which includes savings from automation.
- Confidence in pricing and execution of fortnightly model federation and clash detection
- Ability to use the schema documentation and third party data transformation tools to push the comprehensive object LOI (attribution) into all 3D model export formats, including to spatial database and DGN as tags.
- Satisfied client with delivery on time and to budget, and demonstrated benefits of Digital Engineering approaches to further justify the states investment in the Victorian Digital Asset Strategy
- Establishment of usable and well developed utility models for downstream project and asset users.
The main technical achievement, and therefore the innovation achieved for this project, was in the overcoming of different vendor readers and writers of the IFC standard for the different utility object types, on large object models.
The IFC format provides us with the ability to transfer 3D models from one design tool to another. During the development of this process we identified a few obstacles with the transformation of this data from the source design package to the deliverable design packages for the client. In understanding these issues, we needed to identify how the source design package was writing the data to the IFC format especially in the context of linear utility network design.
Problems identified:
- Attributes associated to features needed to be exposed.
- Some features within the IFC file did not identify with a geometry type.
- Segmented (networked) IFC features proved difficult to retain the linear feature segments and geometries.
- Writing the features to the customers design package requirements
The solution Cardno developed utilised the FME Desktop package to help transform the IFC design models to the client’s deliverable formats. FME was chosen as the tool of choice for this due to its versatility in reading and writing multiple formats whilst being able to clean up and transform information in an automated process.
During the development of this process we identified complexities that came with the way particular vendors utilised the IFC standard file format, this was particularly evident between the FME generic IFC reader and the Revit IFC reader with FME. Key items we identified;
- The generic reader handled the geometries within the IFC class definition correctly although lacked the ability to retrieve the attribution associated with the features.
- The Revit IFC reader was able to identify more IFC class definitions such as pipes and also understand the attribution associated with the features. Although some of the linear features failed to identify the geometry type associated with those features.
Elsewhere in this submission we have highlighted that development and implementation by software developers of OpenBIM Standards for civil elements has lagged behind those for vertical Building Infrastructure. Project specifications and best practice data workflows between authoring and downstream consuming applications are not well established, particularly for utilities. The NEL Early Works project team therefore had to develop custom data workflows to work around the lack of Standards and standardisation.
The lack of specific semantic definition for the projects complex utility objects in the current IFC versions, pushed objects to trimesh and the IfcBuildingElementProxy element definition, and metadata to custom IFC Attributes Trees. Whilst this resulted in loss of network information and the segmentation of curved trimesh objects, it did allow a consistent method across both pipeline type utilities (water, sewer, stormwater and gas) and conduit type utilities (power and comms).
It is acknowledged that for a standard to be developed to overcome the current limitations the utilities industry must be able to agree a common semantic definition. This is a significant challenge for the utilities industry. The introduction of Alignments in IFC 4.1 is a good start point, as this lays the foundation for complex horizontal and vertical string segment geometric representation, from which future IFC UTILITY standards to map to 3D objects might be agreed. One potential option might be to base IFC UTILITY consensus around the growing number of national Utility Depiction Standards, such as AS-5488:2019, which have many common element definitions and language.
Some considerations for linear utility semantic definition include:
- Support for horizontal & vertical segments with full geometric definition of segment type. To avoid the 3D alignment line segmentation limitation (curves converted to line segments)
- Support for network topology definition
- Hierarchical attributes for vertex and segments (not just strings and trimesh as per IFC2x3)
- IFC extrusions for 3D solids (requires vendors to support)
- Object reference point (invert / obvert / centreline)
- Object type (pipe, conduit, culvert, custom)
- Conduit configuration (where there is a bank of pipes, conduits, cables…)
- Mandatory codes for strings
Until an IFC UTILITY standard is developed the industry will continue to use custom trimesh for 3D objects, custom attributes, accept the loss of network intelligence and suffer the curve (string and 3D trimesh object) segmentation issue.
CPB Contractors Pty ltd, Melbourne, Australia,
https://www.cpbcon.com.au/, Managing Contractor, Chris Hunt
