Physical and digital twins of the Köhlbrand Bridge (HPA) 

Four years into the SmartBRIDGE Hamburg programme and the Hamburg Port Authority (HPA) believes that the digital twin of the Köhlbrand Bridge has been successfully incorporated into the working processes of its engineers, all to the benefit of the structure.

The Köhlbrand Bridge is a cable-stayed bridge in Hamburg, Germany which spans a branch of the River Elbe and connects the port area on the island of Wilhelmsburg with Highway 7. Built in 1974 and managed by Hamburg Port Authority (HPA), today it is Germany’s second-longest road bridge as well as one of its busiest. The crossing has a total length of 3,618m including approaches but the section across the river is 520m long and consists of a three-span cable-stayed structure with a 325m-long main span that provides 53m of clearance. When the first modern container ships began arriving at the port, the transport of heavy goods increased massively in the northern German city and around 38,000 vehicles cross over the bridge daily. The toll this took on the structure eventually led to a restriction on trucks overtaking in 2012, followed by an extensive refurbishment in 2016, a limitation of 50m between trucks in 2019, and an announcement that the operational life of the bridge was expected to end in 2030.

The year 2019 also saw the introduction by HPA of the SmartBRIDGE Hamburg project, an ambitious initiative that aimed to explore the possibilities of future bridge maintenance management while, at the same time, addressing the condition of the Köhlbrand Bridge through structural health monitoring. “The challenge was to bring together these requirements to establish an economically viable and sustainable project,” explains Niklas Schwarz, project manager at HPA. “And while the project was regarded as visionary, it aimed to provide added value through addressing existing operational problems,” he adds. In practice, this meant finding a way of integrating sensor data, bridge information modelling and manual inspections within a single ambit.

A partnership was established with engineering firms Marx Krontal Partner and WTM Engineers, as well as customQuake, a software company specialising in customer experience. It was evident from the beginning that the data needed to be stored and processed in the cloud, recalls Schwarz, but at the time cloud computing was still considered innovative and the HPA did not have a cloud strategy. This was a key aspect for handling the data provided by 500 sensors installed on the structure. “A significant portion of the cloud strategy emerged from this project,” he says.

The SmartBRIDGE Hamburg platform is browser-based and was designed and developed in-house to be able to collect, analyse and visually present all bridge-related information, including manual inspection-derived and sensor data.

Raw sensor data is initially pre-processed on site to reduce its volume, then transferred to the cloud for further processing and evaluation. The data then becomes available for view on a dashboard for the Köhlbrand Bridge digital twin either in ‘expert’ mode ie including historical raw data, or in ‘fast overview’ mode ie overall structural condition. The condition indicators for the structure are split broadly into what HPA calls ‘aggregated condition indicators’ and ‘partial condition indicators’. Aggregated condition indicators are based on information sourced from manual inspections, monitoring and diagnostics and refer to the overall condition of a section of the bridge. Partial condition indicators reference a particular element, such as an individual bridge bearing.

The browser-based dashboard provides ‘expert’ and ‘fast view’ modes for reviewing overall structural condition or particular elements (HPA)

The data is collected in accordance with Sensorthings API, an open standard used to interconnect IoT sensing devices, data and applications over the web, and which in this case also enables the data to be connected to relevant bridge elements in the digital model of the Köhlbrand Bridge.

The digital twin of the structure was created using a common data environment - in this case Allplan Bimplus - which allowed individual sub-models to be combined in a single ‘federated’ model.

The digital twin has been developed with a level of detail of 300, which means it is accurate enough to be used for the construction phase of a project, providing accurate dimensions, location and detailing, plus material properties. “And, as we also wanted to use the project as a demonstrator, we also incorporated Unity, a gaming engine that is used here as a visualisation tool to engage the non-civil engineering audience,” says Schwarz. Other software applications used include Navvis Indoorviewer, which allows the inside of the structure to be examined and, in the future, could enable an immersive experience with augmented reality goggles.

As a self-styled showcase project that aimed to demonstrate what the future of bridge maintenance and management could look like, SmartBRIDGE Hamburg has ticked many boxes, “There are several components that are working well and have integrated in the day-to-day life of our engineers, which includes the monitoring and diagnostics measurements. The Structureview has been very successful in showing what is possible in the future with augmented reality,” remarks Schwarz.

(HPA)

Being ahead of the curve has highlighted areas where the automatic integration of data is not yet possible, especially as regards well-established processes such as inspection practices. Schwarz explains that it has not been possible to find a way of automating the integration of manual inspection reports within the digital twin. “In Germany, manual inspections of publicly owned bridges have to be carried out using SIB-Bauewerke, a specific software of the federal and state road construction administrations. We cannot connect to SIB-Bauewerke with our system, which has different information parameters. We are lobbying about the need for optimising the reporting process so that the exact location of damage can be input into that system.” Currently, inspection reports thus have to be first recorded in the state software, and then manually added to the SmartBRIDGE Hamburg demonstrator, which leads to a time lag between the two.

With the digital twin of the Köhlbrand Bridge now firmly embedded in the maintenance and management processes of the structure, the team is now entering a new chapter. “We have stopped development and entered a review phase. How do our engineers work with the software? What are the areas to improve in the future? Where are the main benefits, the main pain points, software improvements, and which sensors are really necessary?”

The answers are highly relevant because Hamburg Port Authority has expressed its intention to create BIM models for all its bridges, which it expects to complete in the next three years, and indeed around 60% of these are already mapped as such. “Here we see a direct added value, but we do not see any added value in instrumenting all our structures with sensors and providing each with complex visualisation. So we will be carrying out a sensitivity analysis for each - does it need monitoring? Does it even need a digital twin? And if so, with what kind of detail or visualisation? We definitely will continue using the concept of the digital twin, but we cannot predict to what extent.”

Looking back at what has been implemented in the last four years, Schwarz is still amazed by what has been achieved. “It was an enormous challenge in all aspects. We didn’t decide to just build a small prototype, but a huge, large-scale demonstrator. From the technical implementation to the contractual design, everything was new territory. The methodical approach was agile and proved very successful. One key aspect for the success was the close cooperation between the partners of the consortium. It was a very cooperative partnership with intensive communication and short feedback loops within the agile project-management method.”

That is not to say that there have been no learning points and Schwarz emphasises that a key one is that HPA’s current manual inspection processes are in no danger of replacement by sensor technology or robotics, but that they will be supplement by them. “We have realised that we will always have digital and analogue data streams in the digital twins, so they must therefore conceptually integrate manual and sensory condition assessment – in other words, they must be able to cope with human input.” It is into this space that, in the future, artificial intelligence may move. “Maybe there will be an AI assistant as a human-machine interface that ‘interrogates’ the structural inspector and transfers the queried conditions to the digital twin. This would allow consistent data in the digital twin, which could then be used to build relevant predictive models,” says Schwarz, adding that HPA will revisit AI in the context of predictive maintenance once enough historic data has been collected.

The four-year journey of SmartBRIDGE Hamburg has had some unexpected side-effects too, not least of which is a transition from having a strong technological understanding to a state of digital excellence in cloud computing, SHM, BIM and data modelling. Its expertise and experience has been recognised nationally, to the extent HPA assisted in the compilation of the Masterplan for digitisation in federal trunk road construction (Masterplan BIM Bundesfernstraßen V1.0). Developed by the Federal Ministry for Digital Affairs and Transport, the guidance provides a standard methodology for progressing BIM projects involving federal trunk roads, and will eventually be mandated for all new projects. “And we were a little surprised by the very positive response from the public on the implementation of the digital twins. We even won some awards, including a Buildingsmart International Award and a Next Reality Contest Award,” concludes Schwarz.

Köhlbrand e-bridge architecture

(Marx Kontral Partner)

The BIM model consists of a large number of models (Terrain, Diagnostic, Electric, Bridge, Monitoring, Damage) created by different disciplines in their specialised software applications. The models were exported as IFC files and checked in a model checker for compliance with the requirements defined in the exchange information requirements (EIR) and BIM execution plan (BEP) and loaded onto the common data environment (CDE) Bimplus.

This was particularly advantageous for the cross-disciplinary model creation, as project participants could access up to-date data regardless of location and collaborate on a model-by-model basis.

The requirements for the models were checked by the bridge owner at regular intervals. Deviations from the required data quality and information content were documented as viewpoints in the software Solibri Office, a model checker, and communicated as tasks via the Openbim collaboration format.

This iterative process was run several times until the model matched the requirements. At this point, it should be noted that despite the detailed EIR and BEP, some iteration loops were required because the model content (geometrically and semantic) is very large and complex.

After incorporating the necessary model adjustments and passing internal quality checks, which were performed using the Desite MD Pro model checker, new versions of the models were again uploaded onto the CDE Bimplus. The checking processes were rule-based and partially automated. In addition, visual and manual checks supported the continuous quality assurance process.

The damage from structural inspections (stored in SIB-Bauwerke), sensors and diagnostic examinations are modelled as separate models. Their attributes are also stored on the IOT server. On the one hand, an as-built model was created from the Lidar scan for comparison with the as-designed model. On the other hand, the scan is the basis for Structureview, which is embedded in Conditioncontrol.

The models approved by the bridge owner were then made available for the smartBRIDGE platform. The geometry of the models and the information content of the models were provided separately as IFC and CSV. The IFC models were prepared by the programs Autodesk 3Ds Max and Blender for further processing in the gaming engine Unity. In Unity, the models were graphically prepared for front-end visualisation. The exported attributes from the BIM models were merged with the frontend visualisation and other data streams on the IOT server. All real-time data is stored on the IOT server and visualised in Conditioncontrol and Expertcontrol on demand.