Holdfast Training Services Trial Blog

Yesterday I attended a PIANC workshop at the ICE. PIANC is the International Navigation Association, the body that produces codes for ports and waterways and governs much of what I am doing during Ph3. Coincidently, the chairman of PIANC works for CH2M.
The day focused on the ‘future of design’, challenging and refining codes, and expanding design in to new areas such as seismic (previously not covered).
In parts, the technical aspect when straight over my head as I lacked decades of practical experience however, some of the key takeaways for the day were completely generic across design disciplines.

Some generic points:

Updating of codes – M/515 (Extending the scope of Euro Codes)
There was a public acknowledgement that the updating of ENs due was overly complex, poorly publicised and understood. The main concern were the pending changes (M/515) to load factors, partial and combination factors across all areas of design.

Code Bashing
There is a concern that code writers have become wrapped up in code-bashing. For instance, the ψ (trident for Brad) factor, in ENs is used for long term effects such as creep. So why is that factor appearing, in the same context, in codes dealing with seismic design…surely the impact of the ground accelerating back-and-forth is far worse than a little creep. PIANC are attempting to identify these cases and add clarity/remove confusion within their own codes. They are also offering their finding to the EN and BS committee’s but acknowledge that changing principle codes will not be easy.

The legal requirement of codes
ENs use the would Shall which legally implies you must do it. BSs use Should which implies a recommendation but is supported but an understanding that without just reason or better knowledge it should be considered as shall. The bottom line and advice from PIANC was to treat these as the same ‘a legal requirement’ and only challenge the code if you undertake some form of monitoring, statistical or physical modelling during the design phase.

BIM
Not a single engineer present (over 100 from a wide range of companies) had used BIM for any non-government project. Furthermore, when asked to what degree it had been utilised for Gov projects, only sniggering could be heard. There is no doubt that if used correctly BIM is a fantastic data managing tool that would support the H&S/project files etc. However, this is not happening. The key concern is that as-builts are improving but supporting cals, assumptions, etc are not available which makes future alterations difficult. PIANC is attempting to manage this by introducing the requirement to produce a ‘Facilities Operating Manual’. In essence the factors and design assumptions made at every step of design are to be logged and presented with the drawing pack. This is not optional if designing to their codes. It does not require companies to expose their calcs or software details but an understanding of inputs and outputs along with factors.

Summary
The day highlighted a genuine desire across the industry to refine the policies and the codes in use. The senior PIANC committee were open and seemed active to explore ideas being presented to them rather than trying to justify their latest publications. There was a acceptance that the ENs are so vast that using them as a baseline and working alongside was the most proactive way to progress rather than trying to alter, amend or refine them. The day finished with a short discussion on what, if any, new codes should be written.

Genuinely a good day that expended my understanding of how the codes are born, developed and published. It was warming to see that the industry steers the codes and is not simply constrained by them!