At the moment of writing we do not have a clear understanding or a definition of the concept of BIM. Does it mean 3D models, is it a tool, is it a process, is it a method, or is it a business model? The questions are manifold and this is reflected in multiple definitions to be found in the construction industry. The current answer is that the concept of BIM encompasses a little of everything. The purpose of this guide is to give some answers on how to deal with the challenge of rapidly progressing digitization in the construction industry. This guide is about what we can do now to bring value to architects, projects, partners and our clients who are working in a fast-evolving digital environment. Here and now. How can architects improve their IT capabilities and expand their traditionally visual, geometry-based form of communication to include alphanumeric data associated with BIM models and data objects/building parts? This guide explains the relations between the Architect’s Scope of Service1, (ACE-SoS) and the use of digital 3D models. This guide explains key findings in established European BIM practice. We aim to give advice on how to deal with challenges that emerge when a project is to be designed using BIM and provide an example of what can be considered as established practice when working with 3D software and BIM related processes. This guide does not represent a strategic plan covering future aspects of digital transformation and the use of BIM, databases and 3D software. Nor does it define specific methods or recommend specific software for working with BIM. Nor does it cover or explain the need for model input from third parties. We believe it is of value to establish a shared pool of BIM terms and technology; that means an open CDE and open platforms for data exchange instead of proprietary solutions. We do not agree that technology should dictate transformation or force disruptive hypotheses onto the building industry and beyond. ACE supports the premise that guidelines are rooted in practice, based on experience and evidence gathered in real-life projects.

The purpose of this chapter is to explain the most important and most common issues and tasks related to SoS and BIM. Across Europe, the function of an architect depends on many factors such as the size of the project and the legal basis of project contracts. The architect is a member of the design team as well as leading the project and acting as a coordinating instance. There are differences between the architect’s function in the Netherlands, France, Spain, Germany, Austria, Denmark and Switzerland. Today public and private contracts often include ICT (Information and Communication Technology) addenda which require the use of BIM. These ICT addenda, often extending to 200-300 pages and more, will be discussed and compared to the Scope of Service and the architect’s deliverables. In fact, we are being challenged by often premature and untried ICT demands and BIM specifications. BIM demands make it more important than ever for architects to have understanding and a strategy of how to handle clients’ ICT/BIM specifications in optimum fashion, as early as the competition or tendering phases. The first step in avoiding problems is to address ambiguities as soon as possible in the tendering or competition phases. Fig. 1 shows how projects with BIM requirements can be handled. The contractual documents are shown above the blue line and the technical implementation processes are shown under the blue line. Normally a contract is signed and the implementation is then handed to project managers. Therefore, it is wise to allow some room for manoeuvre when moving from requirements to implementation. ICT that is handled badly can have a negative impact on a project. Questions which are often discussed too late are conflicts which arise regarding the interpretation of requirements in between Scope of Service and ICT specifications. Disagreements can refer to licencing costs, training and responsibility for software, ownership of databases, ownership of data and data delivery in open or proprietary file formats. To this can be added design and build issues such as data drops, model content on the technical discipline level and the reliability of BIM models and for what purpose they are valid when used by other project partners. All this makes it essential to be able to handle contractual aspects as well as the technical project specifications.

Fig. 1 : Contractual level and project-specific planning - see original

Several EU members have developed their own interpretation of LOD as the point where new technology meets established practice. The concept of LOD or Level of Definition describes how detailed objects should be in terms of graphic representation and data content in order to support dataflow and process execution between one software platform and another. The LOD concept is not aligned to, nor does it serve the same purpose as the Architect’s Scope of Service. LOD only describes model content in a software context. Often the two concepts are confused in a contractual context where LOD levels are thought to be the same as deliverables according to SoS. It is important to understand the difference and to find a pragmatic way to handle this issue. The first step in this direction is to establish a practical foundation for improving interdisciplinary coordination. The second step is the question of how much information LOI objects should contain. This is influenced by a project or company-specific decision of what brings value. A lack of practical experience with BIM has led to the importance of the graphic detail of objects and models in the client’s EIR being overrated. For design professionals the level of graphic detail of objects as illustrated in LODs such as the one from BIMFORUM are not that important. Why? because it´s not profitable to model data i 3D. At present customers’ requirements regarding BIM output and digital workflow exceed project deliverables as outlined in our Scope of Service2. That is not a tenable situation. 3D models do not have a scale and for the untrained eye BIM models look the same in phase 1 or phase 6. So it is necessary to establish a definition of the “reliability” of models and objects/ building parts. But more important still is how objects are viewed in a 2D representation, because drawings are still superior and the best and most reliable way of explaining and documenting what is to be built. The main concern when working with 3D models is to clarify to what extent the outer perimeter geometry and location of objects can be trusted, and to reflect that in 2D drawings within an agreed tolerance, scale and notation. That is our basic documentation. Furthermore, the production of valid clash detection reports also depends on a valid object geometry rather than visual representation and this can be as simple as a box. To sum up: it is necessary to find a way handling the ACE-SoS in accordance with the BIM/LOD as defined in the emerging standards of CEN (European Committee for Standardization) and other commonly used national standards. A contractual frame for the reliability of models/objects LOR (Level of Reliability) and model content must be established. If not specified on the contractual level, all models exchanged must carry a precise description of their validity and purpose of use; however, that is scarcely possible.

Fig. 2 : Example for aligning Scope of Service3 to the BIM concept using LOD, LOR, LOG and LOI - see original

The example shows only an interior wall in the graphic. Similar illustrations must be worked out for all objects in a real project. Establishing objects of external geometry and the objects’ location in the model LOR (Level of Reliability). (This is not an internationally defined term! Please note the definitions of accuracy in Fig. 2). Establishing (LOG) Level of Geometry. Establishing (LOI) alphanumeric information (LOG and LOI see Chapter 6).

Definitions of accuracy of geometry

Expected main geometry indicates that the geometrical shape of the object/building element has not been defined and that the location in the construction has not been determined

Established main geometry indicates that the geometrical shape and location of the object/building element in the construction have been clarified and established, but adjustments may be made before the final shape and location are defined and decided

Final main geometry indicates that the object/building element has been finally clarified with respect to shape and location

Selected: the architect selects important elements/parts which are detailed in the model. The selected parts illustrate typical parts (repeated many times) or critical parts (difficult with respect to the technical solution or buildability). A good typology or classification system is fundamental to creating a reasonable responsibility matrix. (See Chapter 9).

How to model in 3D?

That is not an easy question to answer in a short statement. As mentioned in the previous chapter, EU countries are developing BIM standards in accordance with local building regulations and standards. Digital planning requires early project decisions. Changes to a project’s (BIM) execution plan will most likely have negative consequences for consistent data production in a BIM project. To give an example: if the tender strategy or process is changed in the middle of the project, data producers will most likely have to make a new segregation of models/data and the arrangement of data handout. This means more effort, time, and costs for the design and construction team. It is a paradox, but these kinds of changes are very costly and not easy to handle in data models. What is often forgotten when talking about BIM is the need to produce documentation for the planning phases and to document steps and changes. Documentation can take the form of 2D drawings, diagrams, schematic diagrams and descriptions. Documents such as drawings, for example, are a very old but nevertheless still an effective form of documentation, and readable without a software-based system! Communication in the building industry is switching more and more to paperless documents. That poses a certain dilemma, because the date/time and stage must be tracked and entered in the project planning documentation history as well as what information was sent to other members of the planning team and how they processed and modified it. Producing paper-based drawings means we produce a huge amount of paper sheet files. Using BIM, we produce a huge amount of data files to be saved in our documentation system. Will drawings become merely an outdated way to communicate technical information? BIM it is still vision for the standard construction market, since there is no plug and play software or method in the market that can make complex BIM useful for a bigger number of users. Cloud technologies have been developed to create an opportunity, but the open source-based software or platform is still to be developed. Cloud-based solutions have to be geared up for data security. As mentioned earlier, there are many assumptions of how detailed building models must be to satisfy different needs in the supply chain. An architect should consider the amount and “granularity” of model data needed: what graphical data is needed to produce a drawing? And what data is needed to be processed as alphanumeric information to support the planning team and the supply chain? (See Chapter 7-8). It seems simple, stuffing a model with data. Keeping track of changes in time and space, across software platforms is a different, and underestimated, critical issue. Keeping track of changes and validity challenges our design software and human capabilities, and when set within a liability context, this is where it starts to get serious because we are facing a political desire to see BIM as a business model and a virtual tool for controlling cost, time and quality. The handling and documentation of changes should not be underestimated when embarking on BIM projects. This is a serious and challenging task for the architect when filling the role as leader of planning teams and BIM coordination. A great advantage of using 3D and data models is the ability to better coordinate design, especially when aligning the construction and MEP models. This is a quality assurance process and it is not a new thing. For the technical aspect, this is done through collision controls, visual controls, etc. In brief: Good quality of data in terms of structure makes it possible to run digital controls effectively. Poor data quality makes it impossible. Open BIM or closed BIM refer to the use of open data formats instead of using proprietary software. However, the strategy of the major software companies seems to be: we develop possibilities, but the user must accept solutions that are incompatible with other systems, national standards or regulatory methods. In ACE, we believe that is important to support the development and use of open data format!

Most countries have their own classification systems and they have their way of creating cost breakdown structures. These cost structures tend to work as a basic structure suitable for BIM and 3D modelling. But bear in mind that structures made for calculations are most likely not detailed enough to organise and control object information needed in the design and build process. This statement also applies to newly created standards for cost calculation. Most classification systems are built on the ISO 12006 framework, which is a conceptual standard for the built environment in general, but it is not a standard covering naming conventions of objects/building parts to be used in digital systems. Numbering structures in older paper-based classification systems are not intended to work in a digital world and that has proven to be a major challenge when programming software and databases. The consequence for the end-user is that logic and an understanding of how to work with the digital interface suffer. Functionality in terms of classification and interface programming must be improved. We must question the term “machine readability” and how this affects our profession and alienate people. To create good user interfaces is also an extraordinary challenge to any software developer. As said previously, when classification is placed in a digital context, consistent and simple coding principles for numeric and text information are important to enable model data to be exported and be represented in drawings and spreadsheets. Structured principles for object naming and defined fields/values property sets for data must be established. Generally speaking, it is vital to keep numbering/naming sequences short to ensure readability for humans and for practical reasons when information is used on drawings where only limited space is available. Below is an example of a simple numbering structure that is broken into separate data fields, for example, and can be used for “tagging” on to drawings and data output for BIM models can be sorted in order.

Fig. 3 : Examples of data tags - see original

Worldwide there are many country-specific LOG descriptions to be found. All are generated from the same schematic principle and based on a common assumption, namely, that digital objects/building parts are becoming progressively more detailed in terms of their graphic representation from phase to phase. Whether this generally true or simply an assumption is hotly debated in the industry. The core of the debate is, of course, to what extent is a 3D model a representation of the physical building, or is a model an abstraction? This is where the arguments of serial production versus design of unique, single build structures come into play. The best advice is not to model objects with no geometrical importance. These could be objects such as a door handle. When a national LOG is based/copied from BIMforum.org you will find a high level of graphical detail. When using BIM, it is important to be specific regarding the level of detail you and your project partner are obliged to model to. Failure to keep detailing levels down are certain to cause bad performance regarding the digital coordination of design processes. To avoid possible unproductive discussions and unsatisfied expectations address this issue as soon as possible, during or before contractual negotiations. The level of detail is an important basis for delivering a building model with a good and sustainable digital performance. Be aware that BIM objects created by the product industry often contain a superflous amount of data because they often convert their production data files into BIM data using the models of hidden surfaces (vanity unit or water closet, with invisible inside surfaces) which result in a huge amount of unnecessary, useless and invisible data, often creating extra work to reduce the amount of data by redrawing and simplifying surfaces. Remember that LOG does not tell us anything about the geometrical accuracy or location of an object in a model. (See Chapter 3).

Breaking down the complex world of properties reveals relations between classification theory and naming conventions and practical processes in the design, building and production industry. Combine that with digital technology and you have an explosive BIM cocktail. To make use of properties in practice is a monumental challenge. So the best advice for the moment is to be conservative and focus on which data support your own processes and business. Selfish perhaps? Not at all. If you can make that approach work, the quality and value of your digital production of data will increase. Handling data in models means dealing with property sets. Property sets are basically data fields associated with values or sets of values. As an example, we can take the property “fire rating” where the values can be associated with European standard EN 13501-01 and defined as (A2 – s1 d1) and so on. Please bear in mind that most property sets and associated values are not defined in standard software. That means that design software needs to be configured to handle national data and property specifications and that is a responsibility you bear as a data producer. The next practical challenge of working with properties is to distinguish between properties related to a certain type of object and properties related to an occurrence/instance of the type of object. As an example, a door type can have several combinations of unique occurrence/instance parameters, according to location, fire zoning) and functions such as access control and many more. It should be obvious that it is not possible to have a unique object type for every possible combination of property sets. (See Chapter 5 Classification/typology). It is important to determine and agree on the extent and use of Pset associated with objects in BIM models - primarily according to the contract and ICT specifications and in association with deliverables and data drop. CEN TC442 WG4 is now exploring the creation of a framework called the data dictionary, in which property sets and data values will be defined and mapped in national languages. The most commonly used Psets are defined in the IFC standard and ACE recommend that IFC property sets should be used. Where national standards have been established, they must of course be followed. Handling this task at a professional programming level is a major concern facing the software industry. Easy handling of definitions and national standards while creating BIM and data models is already an obligation for any user of CAD and BIM Software when producing BIM models. This must also be affordable, especially for SMEs which represent most professional architectural firms in Europe. It is important that handling of properties is improved and included in the basic localisation of BIM software and products.

The issue of how to handle project documentation, such as drawings, descriptions and references to standards, is scarcely dealt with in any publication on BIM. And yet it is an important issue. In a model, the description of work completes the need for information that cannot in any logical way be associated with a single object in a BIM model. The description fills in the gap between the levels of detail expressed in LOD/LOG/LOI. It is not cost-effective for a single build to model a building as a 1:1 representation of the physical final product, namely “the building”. That is one reason why not all information can reside in a 3D model and that is why it is essential to know which objects are to be modelled and which information will be represented in drawings, descriptions and other documentation. This issue is important when the BIM models are used for quantity take-off and cost calculation.

Which formats can the client demand ?

It is necessary to define delivery in the contract or the scope. It is a problem that the IFC format still has its challenges in terms of data, so that other formats must support the design process and delivery within the planning team and vis-à-vis the client. The architect’s or architectural model is the basic model for any other player or function in the planning and delivery team, including construction and MEP engineers. Most likely the architect has to specify witch data are transfered to the CDE (Common Data environment). This is BIM coordination. And, of course, the CDE should use an open platform in the sense of open BIM if proprietary formats are required by the client, and we recommend that this be specified in contracts. In addition, if a new software product is required to be used by the planning team, the costs of purchase and training have to be clarified.

Permitted purposes/intended use

BIM models contain a huge amount of data and information, information which can be used and must be selected for different purposes. The information in the model will be quality-assured based on the purpose for the model will be used. For example, the data for the construction or delivery of a building are frequently not consistent enough to ensure a satisfactory life-cycle cost analysis, even if the information needed is included in the model. • It is important to define the permitted use of information for the scope of work of the design team or even the client in the contract. • It must be clarified in the contract that if the client receives information that is not part of delivery, he has no right to use this information.

The client’s right to the project material

The client has the right to use project data he has paid for in the contractually defined project and purpose. The architectural “work in progress” model in proprietary format should not be part of the delivery, as it contains a lot of information provided upfront , libraries and information/solutions that are not part of the delivery. It is important to demand that the quality of IFC implementation and data exchange be improved by software developers.

Defining the project

It is important to define the project in such a way that the client or design partners cannot misuse the project data for any element in other projects in other circumstances. Defining the data delivery of a project is key to verifying the additional workflow when implementing changes in the data management model as result of changes to project requirements. The BIM project needs to be defined in the contract or in the scope of work. Data, drawings, files, models, descriptions etc. prepared by architects must not be used without written consent for any other purpose or to any further extent than /agreed upon.

Rank/priority of models and documentation

Make sure that rank/ priority issue is regulated in the contract or agreement.

Model delivery

Currently it is not useful to deliver the model without additional drawings and descriptions. 3D models contain information and objects ahead of delivery. Only agreed data for “data drop” purging and cleaning models needs to be filtered out, and it is a time-consuming process before models can be exchanged. Ensure clarity on data authority and data deliverables. Set the architect as a BIM coordinate. Define functions and responsibilities. Define rules of measurement. Define software/versions and exchange formats in the contract or in the BIM execution manual. There are unmanaged risks during data exchange: data errors when using IFC are to be expected and controlled and dealt with. This is a new service and is both part of BIM coordination and management. Make sure that contract requirements continue back-to-back down the supply chain to ensure consistency of process and avoid gaps in responsibilities and liabilities. To avoid liability, it is necessary to regulate in the contract which format the client will receive, what software and what version will be used to open files. The consequences of using cloud technology must be considered carefully. Interdisciplinary exchange of files can possibly change/harm the work/data of other parties due to software differences when it comes to structural changes and loss of quality through export/import. Software updates can lead to loss of information or introduce changes to objects of the model. Settings/properties can be reset. Software developers normally include extensive disclaimers. Hosting, data-security, backup, IT infrastructure and web speeds take high priority when embarking on BIM projects. This guide cannot focus on the issue in general but the impact, especially on SME structures in architectural firms and several projects, may be massive. New issues concerning ownership of data, delays due to systems failure, for example, are certainly questions for the future.