Juha Liukas – Mr. Infra BIM
I’d like to start by making a confession: I’m a standardiser. Codesets, classifications and ranges – oh yes! So what’s the root of my passion for standardisation? Maybe it stems from the fact that, as a young designer, I also delved into the world of software development and coding.
This was during the famous ADB Era, when Automatic Data Processing was the big thing. Back during the mainframe era, when you could only dream of a graphical interface. Our company’s then gurus had already carefully built a foundation for a design system utilising databases. It was strongly based on the standardised classification of source and design data. This classification consisted of numerical codes and their corresponding text descriptions.
The software accepted input as line-encoded and column-bound data in text format. If you made a mistake or typed something unwelcome, the software quickly reacted with either a polite error message or a blunt syntax error. Results were also obtained by chaining different programmes, starting with the source data, with standardised sequential file names and standardised inputs and outputs.
You’d press run when you left work and the results would be waiting for you in the morning. Users had a good understanding of the requirements of standardisation and accuracy. It wasn’t worth going it alone.
From terrain models, ground surveys, route geometrics and ground plans, it gradually became necessary to manage the entire built environment. Maps, environmental data, buildings, structures, networks, systems and modes of transport – all on many levels. The design system was programmed with an internal classification covering the entire built environment, using characteristics from a range of sources and collating a number of codesets.
The same work was certainly carried out in the many organisations that started introducing their own data systems and softwares in the 1970s and 1980s. I bet that, pretty much every time, we have started with a supplier’s deployment project in which we worked with the customer to specify the environment and some sort of classification or codeset. As there has been no comprehensive national vocabulary or classification system, there are myriad codesets. Naturally everyone has, in their own mind, done a good job with their own technical field or specific classifications.
From the designer’s perspective, the various classifications, codesets and requirements for the final product mean extra work and resources to maintain all the correlation tables. It’s no wonder that an estimated 15-30 per cent of designers’ time is spent searching for data and converting it between different formats. Information is lost and altered, mistakes happen. Valuable time and professional skills are wasted on editing both source data and output. This soon adds up in tens and hundreds of companies and organisations, and in their various projects. In principle, similar final products require their own classifications and presentation methods.
Tools have evolved rapidly and brought more opportunities for users to vary outputs. Inspired by CAD software, final products (drawings) have been fine-tuned and layered for almost 30 years. We have improved the way in which the information contained in a drawing is split into layers, or compressed or combined in different ways. Even ADB replaced with the ‘fancier’ term ICT.
And the multitude of implementations is only increasing. The need for manual interpretation and editing is growing all the time, even though IT itself has advanced. The first forays into building information modelling – 3D models – have not necessarily helped to standardise classifications. 3D models look good, but their associated classification has not really been standardised. People must interpret the model and its content. Although information processing has been digitalised, we still need to do a lot of manual work.
Of course, we have also seen a lot of progress in many areas over the years. In the early 2000s, the infrastructure sector has in particular drawn up classification for construction elements, InfraRYL quality standards and InfraBIM classification for data modelling. However, the introduction of new classifications and the abandonment of old ones does not always seem to have been successful. A massive range of different source data is still found in, for example, municipal ground plans and information from various network owners.
Building information modelling – and harnessing its benefits – requires a standardised and comprehensive vocabulary and classification for the built environment. How do we get this to happen?
Standardized, digital data will gradually enable the automation of data management (RASTI project).
Everyone must understand the immense potential of standardising basic concepts. We can then use the time we save to implement better solutions for planning and building. The KIRA digi-project has highlighted the need for standardisation and harmonisation.
The results of the RASTI project (a road map for standardising the built environment) in particular also support this: a shared vocabulary and classification play a key role in promoting digitalisation and automation. All parties must understand the importance of standardisation and commit to implementing the results.
In fact, when it comes to digitalisation we must raise the abbreviation ADP to the honour again: as our goal is Automated Data Processing!
Juha Liukas is a leading advisor on infrastructure data management and modelling at Sitowise. He has been involved in data modelling development projects in the infrastructure sector since 2001. He chairs BuildingSMART Finland’s infrastructure standardisation group. Early in his career, Juha worked as a geotechnical designer and has also over 20 years of experience in software development.