Levels of definitions
First published 8th April 2015, last updated 7th May 2015.
To define information delivery a reference library of definitions is required. Levels of definition may be either described in terms of geometry (levels of detail) or information requirements (levels of information). BDP Director of Information and Technology, Alistair Kell and NBS Business Consultant Stefan Mordue discuss how this UK reference library has been developed as part of the Toolkit.
By Alistair Kell
BDP was established as an interdisciplinary design practice in 1961 with the principles of collaborative team working at its heart. BDP’s founder, Sir George Grenfell-Baines, firmly believed in a holistic approach to project design and delivery, developing a series of procedures to support this philosophy. Grenfell-Baines also chaired the committee that developed the original RIBA Plan of Work in 1963; this document being heavily influenced by BDP’s interdisciplinary approach. In understanding the current drive towards BIM adoption, in particular the developing standards within the UK, the overarching principles required to effectively manage the project design and delivery process have actually changed little. They are however now governed by technology and process to such a degree that without comprehensive management the overall benefits BIM can enable will not be achieved.
Our approach recognises that the challenges of managing design development across disciplines do not vary dramatically between manual drafting, 2D CAD and BIM; the communication requirements of information remains constant. The application of standards supported by technology will however deliver more determined, efficient information with less inherent risk within it, providing improved building outcomes for our clients.
Following the Government ‘Level 2’ BIM mandate we recognised the primary change to established working practices as being the need for the project team overall to provide consistent digital information at an equivalent level across design stages; without this the innovation BIM can bring will simply not be realised. At BDP we therefore address standardisation across design disciplines and project workstages, ultimately leading to the normalising of outputs across all project participants. We have recognised that with project teams progressing in a collaborative environment there is far greater opportunity for BIM adoption on the project to succeed, this being our ultimate aim in an ever more competitive marketplace.
We manage the level of detail, or more importantly the progression of design development, through the RIBA Plan of Work 2013 (PoW).The PoW provides the structure and organisation for our project design and delivery methodologies. Through the standards developed following the UK Government BIM Mandate, applied across the PoW, greater uniformity across disciplines is being achieved.
Importantly we also see the PoW as a project orientated rather than discipline focussed document and whilst this is not a project programme in itself the workstages and necessary outputs define the intended level of detail to be delivered by each design discipline across workstages.
Whilst the principles of design development have not fundamentally changed to harness many of the benefits of BIM there is far greater need for common, aligned geometric and information outputs. Without this coordination, quantification, energy analysis and many of the other BIM uses can simply not be achieved. We utilise the BIM Execution Plan to ensure all team members work to a uniform set of standards. This document is developed on a project specific basis, addressing appropriate Employers Information Requirements where available.
The BIM Execution Plan (BEP) is developed for each project at inception. Our standard BEP template aligns to PAS1192:2 and its creation, application and regular review is linked to both the Technology Strategy outlined in both the PoW and is monitored through our internal QA Audit process. We develop the BEP in conjunction with all project participants and once confirmed it is available to all internal team members and is shared with external project participants.
By utilising the RIBA PoW across all professions we are able to better manage project deliverables, developing individual discipline models coordinated and guided by the BEP. Similarly we advocate the use of appointment documentation and supporting forms produced by the Construction Industry Council, BS1192:2007 and the PAS 1192 suite of standards applied to the BDP Design Process to rigorously control project workflows.
Fig 1 - BIM workflow diagram
Through the application of PAS1192:2 and BS1192:2007 we establish the mechanisms for successful technical project delivery however the preparation of an interdisciplinary Design Responsibility Matrix (DRM) is a key tool to guide project development.
The DRM is the controlling document for workstage outputs, outlining the ownership of each building element and the level of detail to be delivered at each workstage. We prefer to define these requirements early in the design process when they can become contractual deliverables prior to formal appointment documents are signed. Projects are then progressed with all parties having greater definition over what is to be delivered, when it is required and what the information can be used for.
With there being no published UK specific standards that supports the preparation of DRM to be prepared as part of a complete suite of aligned, UK centric, documents we currently attempt to address this by aligning the RIBA workstages to the BSRIA BG6 Guide, American Institute of Architects E202 BIM Protocol Exhibit and the more recent Level of Development Specification 2013 prepared by the US BIMForum.
With the necessary protocols in place we are able to progress projects with the confidence that design development, project collaboration and workstage outputs can all be uniformly delivered.
The development of the BEP, associated documents and their application is managed on a project by project basis through our Project Technology Managers group. These individuals are a dedicated resource, available within each office, with specialist skills and knowledge of BIM software, processes and standards. Working with project teams supporting both BIM Coordinators and Design Team Leaders to produce deliverable documents. Once prepared the Project Technology Managers then support the application of these documents, addressing training where necessary and increasingly are providing QA / Audit / data integrity checks as information is concluded. Their specialist knowledge assists with the upskilling of our technical teams, driving efficiency and allowing a greater focus on design creativity.
Fig 2 - ptm diagram
Moving forward it is clear that the ‘Digital Toolkit’ will provide a further level of understanding and ultimately commonality across the industry. With a set of aligned Level of Detail and Level of Information standards, revised classification system and the means of confirming compliance against a set of project defined deliverables the industry will be able to provide more coordinated, data rich information ultimately driving efficiencies in the design, construction and operation of buildings. Our hope is that by providing an industry baseline for information delivery the conversation will move from the production of digital information back to the quality of the built form and end user experience.
To ensure we are informing this debate BDP is supporting NBS on the ‘Digital Toolkit’ project over the last 12 months, specifically developing the graphical definition (LoD) for some 400 objects across the RIBA workstages. These definitions cover architecture, landscape, MEP and structure, tackling typical building elements and providing guidance on graphical and geometric requirements. Each element is assessed across RIBA workstages and the geometric definition prepared suitable for the necessary workstage activities; coordination, analysis, procurement etc. allowing for a meaningful approach to model development and design coordination across disciplines. Simplistically by outlining what information is to be provided, who is to provide this and what it can be used for at various points though the design and construction phases of a project greater efficiency can be brought to the project.
In progressing this work we have established an approach that acknowledges the development of information through each workstage and how this relates to the client brief. Our view is that the information available at the beginning of each workstage effectively defines the brief for that stage, the design activities are then progressed and the development of the briefing material is then encompassed in the workstage outputs, be they datadrops, planning submission, End of Stage reports etc. The volume and detail of the information will vary appropriate for the workstage however this principle can be applied across all workstages and other key activities such as Planning or procurement. Following this principle forward by confirming LoD and LoI requirements for each discipline against building elements the workstage brief provides the checking mechanism to confirm compliance of the end of stage outputs against the confirmed brief provided at the stage commencement. Equally, once confirmed these outputs then provide a more comprehensive brief for the following workstage.
Ultimately, with the ‘Digital Toolkit’ now available as it becomes established we expect to see both improvements to information development and efficiencies in overall project lifecycle. Clearly there are many challenges ahead, but significant progress has already been made and the target has now become clearer as the final components of the ‘Level 2’ specification have been finalised.
Fig 3 - Level of Detail principles
By Stefan Mordue
When you think about a model, perhaps the first thing that comes to mind is geometry. This is not surprising as models have been used for centuries to set out a designer’s intention - conveying shape, space and dimensions. The ‘Great Model’ of Sir Christopher Wren’s St Pauls Cathedral did this in the 1670s and can still be seen today.
However, while the geometrical or graphical data can tell us the width of a brickwork leaf and the height of the walls, at a certain point during construction it is the written word that is needed to take us to a deeper level of information. It is within this textual environment that we describe the characteristics of the brick itself such as density, strength and source; and it is words that are used to describe the kind and type of mortar joint and wall ties.
In the context of BIM, we are actually looking at a rich information model which, aside from graphical data − such as geometry and shape, also includes non-graphical information − such as performance requirements and associated documentation presented in a specification or manual format. The written specification is not new and has been around for centuries. However, it is only now by combining these aspects of graphical and non-graphical information that we get the ‘overall picture’. Today, clients are not only procuring a physical asset, they are also procuring information, typically in a digital format. The amount and level of information increases as we progress across the project lifecycle. For example, at an early strategic briefing stage, when the client is assessing needs, there may just be a requirement for spaces and activities. At concept stage this will be developed into the design intent of elements/systems to meet the Employer’s Information Requirements (EIR). This is then further developed at design stage when considering the characteristics of each deliverable in terms of performance requirements; this could relate to security requirements of a plant room space, an external wall element or a doorset system. At technical design stage, or at least prior to construction, product selection can be determined by the specifier or delegated as ‘contractor’s choice’ based upon generic product performance requirements.
The Government’s ‘Soft Landings’ guidance recommends that a building’s ’in operation’ phase should be considered throughout the whole project lifecycle. By establishing required performance outcomes and operational budget at an early stage, these can then be compared to the actual performance outcomes. From a concept stage the performance criteria − such as the structural performance of a partition system, can be considered. As the information develops, specific references to relevant standards and classes are stated, along with any testing methods that may be required. Certifications by accredited third party certification bodies are also considered as the information progresses, to ensure that the client’s outcomes are met at the end of the project. At project hand over, information specific to the installed object’s operation and maintenance is incorporated into standard COBie properties, as well as documentation such as links to PDF manuals.
Example: Partition system
|Banding code:||2. What is typical for concept stage?||Description:||A simple description outlining design intent.||Example:|| Partition system
To surround commercial kitchen area. Must have appropriate fire rating, structural strength suitable for holding kitchen units and acoustics to provide a comfortable environment for the adjacent restaurant.
|Banding code:||3. What is typical as the design develops?||Description:||The specified overall performance of the deliverable.||Example:||Partition system
|Banding code:||4. What is typical in technical design?||Description:||The prescribed generic products that that meet the desired overall performance requirements.||Example:||Partition system
|Banding code:||5. What is typical in the construction phase?||Description:||The prescribed manufacturer products that that meet the generic product specification.||Example:||Partition system
|Banding code:||6. What is typical for operation and maintenance?||Description:||The key properties to be transferred into an asset database.||Example:||Partition system
Example: Surveillance systems
|Banding code:||2. What is typical for concept stage?||Description:||A simple description outlining design intent.||Example:|| Surveillance systems
To have sufficient coverage of cycle storage and principle office entrance.
|Banding code:||3. What is typical as the design develops?||Description:||The specified overall performance of the deliverable.||Example:||Surveillance systems
|Banding code:||4. What is typical in technical design?||Description:||The prescribed generic products that that meet the desired overall performance requirements.||Example:||Surveillance systems
|Banding code:||5. What is typical in the construction phase?||Description:||The prescribed manufacturer products that that meet the generic product specification.||Example:||Surveillance systems
|Banding code:||6. What is typical for operation and maintenance?||Description:||The key properties to be transferred into an asset database.||Example:||Surveillance systems