BS1192:2007 by Iftikhar ISMAIL BSc MSc MIET

BS 1192:2007 1192:2007+A2:2016 BS 1192:2007+A1:2015

BRITISH STANDARD

Collaborative production of architectural, engineering and construction information â&#x20AC;&#x201C; Code of practice ICS 01.100.30; 35.240.10

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

BS 1192:2007+A2:2016 Publishing and copyright information The BSI copyright notice displayed in this document indicates when the document was last issued. ÂŠ The British Standards Institution 2016 Published by BSI Standards Limited 2016 ISBN 978 0 580 92817 8 The follow BSI references relate to the work on this standard: Committee reference B/555 Drafts for comment 07/30163397 DC, 15/30326416 DC, 15/30335209 DC

Publication history First published as BS 1192-5:1990 Second edition, BS 1192-5:1998 Third (present) edition, 31 December 2007

Amendments issued since publication Amd. no.

Date

Text affected

October 2015

See Foreword

April 2016

See Foreword

BS 1192:2007+A2:2016

Contents Foreword iii Introduction 1 1 Scope 1 2 Normative references 2 3 Terms and definitions 2 4 Collaboration management processes 4 5 Naming of containers 14 6 Project 17 7 Originator 17 8 Divisions 17 9 Type 19 10 Role 21 11 Classification 21 12 Presentation 22 13 Number 22 14 Description 23 15 Status 23 Annexes Annex A (normative) Project space statement 27 Annex B (normative) Quality management 28 Annex C (informative) Conventions for layer naming in international projects 29 Bibliography 31 List of figures Figure 1 – Document and data management repository 6 Figure 2 – WORK-IN-PROGRESS (WIP) and share process for architects model 7 Figure 3 – Architects model uploaded from WIP for sharing 8 Figure 4 – Architect’s SHARED models referenced to Structures WIP area 9 Figure 5 – Structures co-ordinates its model files using the architecture files as a reference 9 Figure 6 – Co-ordinated, reviewed and uploaded models shared to the SHARED area and duplicate information removed 10 Figure 7 – Concurrent activities with continual upload and reference 11 Figure 8 – Suitability “D” is data or documents not authorized by the client 12 Figure 9 – Audit trail, data, documents, asset and facility management information held in ARCHIVE 13 Figure A.1 – Geospatial referencing 27

BS 1192:2007+A2:2016 List of tables Table 1 – Naming of directories and folder containers 15 Table 2 – Naming of file 15 Table 3 – Naming of containers within files including layers 16 Table 4 – Examples of field usage 16 Table 5 – Standard codes for suitability models and documents 25 Table C.1 – Differences between international and British layer naming fields 30

Summary of pages This document comprises a front cover, an inside front cover, pages i to iv, pages 1 to 32, an inside back cover and a back cover. ii • © The British Standards Institution 2016

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007

Foreword Foreword BS 1192:2007 Foreword Publishing information Foreword Publishing information isispublished Standards Limited, under This British British Standard Standard publishedbybyBSI BSI and came into effect BSeffect 1192:2007 Publishing information This published by BSI came into licence from Standard The British Standards Institution and came into effect B/555, on on 31British December 2007.isIt was prepared byand Technical Committee Publishing information on 31 December 2007. It was prepared by Technical Committee B/555, British published byand BSI Standards Limited, under 31 December 2007. Itiswas prepared by Technical Committee B/555, This British Standard Standard ismodelling published by BSI andexchange. came into Aeffect Construction design, data list of Foreword This ismodelling published by data BSI came into Construction design, and data exchange. Aeffect list ofrequest licence from Standard The British Standards Institution and came effect on Construction design, modelling and exchange. Ainto list ofon on 31British December 2007. It was prepared byand Technical Committee B/555, organizations represented on this committee can be obtained on 31 December 2007. It on was prepared by Technical Committee B/555, 31 its December 2007. It was prepared by Technical Committee B/555, organizations represented committee can be onon request organizations represented onthis this committee can beobtained obtained request Construction design, modelling and data exchange. A list of to secretary. Foreword Publishing information

Construction design,modelling and data exchange. Aeffect list ofrequest Construction design, exchange. A list ofon its secretary. to itsBritish secretary. organizations represented on thisand committee can be obtained This Standard ismodelling published by data BSI and came into Supersession organizations represented on this committee can be obtained on request organizations represented on this committee can be obtained on to Publishing information on its 31secretary. December 2007. It was prepared by Technical Committeerequest B/555, Supersession its secretary. to itsBritish secretary. This Standard is This British Standard ismodelling publishedBS by1192-5:1998, BSI andexchange. camewhich into Aeffect Construction design,supersedes and data listwithdrawn. of Supersession 1192:2007+A2:2016 1192:2007+A1:2015, which BS 31 1192:2007+A1:2015 1192:2007, isiswithdrawn. This British Standard supersedes BSBS 1192-5:1998, which withdrawn. on December 2007. Itsupersedes was prepared by Technical Committee B/555, organizations represented on this committee can bewhich obtained on request Supersession Relationship withsupersedes other publications is withdrawn. This British Standard BS 1192-5:1998, which is withdrawn. Construction to its secretary.design, modelling and data exchange. A list of Relationship within other publications Information about this document BS 1192:2007+A1:2015 supersedes 1192:2007, isiswithdrawn. This BritishisStandard supersedes BS 1192-5:1998, which withdrawn. Copyright claimed Figures toBS 9. Reproduction of these organizations represented on this1committee can bewhich obtained on request Relationship with other publications Information about this document Copyright isand claimed in Figures 1 from to 9. it Reproduction of that these Text or altered by Amendment No. 1 isinfringe indicated in the text by illustrations making products might copyright. Supersession to itsintroduced secretary. Relationship with other publications Information about this document illustrations and making products from it might infringe that copyright. Copyright is claimed in Figures 1 to 9. Reproduction of these Text introduced or altered by Amendments No. 1 and No. 2, respectively tags  . Minor editorial changes are not tagged. Details of the copyright owner (from whom any permission to use this This British Standard supersedes BS 1192-5:1998, which is withdrawn. Copyright is claimed in Figures 1 to 9. Reproduction of these Details of the copyright owner (from whom any permission to use this Text introduced or altered by Amendment No. 1 is indicated in the text by are indicated in the text by tags  and  . Minor editorial illustrations and making products from it might infringe that copyright. illustration may be sought) can be obtained by contacting the Supersession illustrations and making products from it might infringe that copyright. illustration may be sought) can be obtained by contacting the tags  . not Minor editorial changes not tagged. changes are tagged. Details of the copyright owner (from whom any permission to use this BSI Library, British Standards House, 389 Chiswick High is Road, Relationship with other publications This British Standard supersedes BSare 1192-5:1998, which withdrawn. Details of the copyright owner (from whom any permission to use this BSI Library, British Standards House, 389 Chiswick High Road, illustration may be sought) can be obtained by contacting the London W4 4AL. Copyright is claimed in Figures 1 to 9. Reproduction of these illustration may be sought) can be obtained by contacting the London W4 4AL. BSI Library, British Standards House, 389 Chiswick High Road, Relationship with other publications illustrations making products from it might infringe that copyright. The changesand incorporated in this revised standard include: BSI Library, British Standards House, 389 Chiswick High Road, London W4 Copyright is4AL. claimed in Figures 1 revised to 9.whom Reproduction of these Details of the copyright owner (from any permission to use this The changes incorporated in this standard include: • W4 Management processes to support collaborative working. London 4AL. illustrations and making products from it might infringe that copyright. illustration may be sought) berevised obtained by contacting the The • changes incorporated incan this standard include: Management processes to support collaborative working. • controlled naming to files and directories, Details ofExtending theBritish copyright owner (from whom any permission to as usewell this The Library, changes incorporated in this revised standard include: BSI Standards House, 389 Chiswick High Road, • Management processes to support collaborative working. • Extending controlled naming to files and directories, as well as layers sub-models. illustration may beand sought) can be obtained by contacting the London W4 4AL. • Management processes to support collaborative working. layers and sub-models. • as Extending controlled naming to files and directories, as well BSI Library, British Standards House, 389 Chiswick High Road, • Compatibility withinBS ENrevised 82045-2 and ISO 82045-5. The • changes incorporated this standard include: Extending controlled naming to files and directories, as well as layers and sub-models. London 4AL. • W4 Compatibility with BS EN 82045-2 and ISO 82045-5. • Incorporation of BS ISOto12006-2 classification as layers and processes sub-models. Management supportcompliant collaborative working. Compatibility with EN12006-2 82045-2 and ISO 82045-5. The • changes incorporated inBS this revised standard include: • Incorporation BS ISO compliant classification tables, such asof Uniclass. • Compatibility with BSnaming EN 82045-2 and ISO 82045-5. as well Extending controlled to files and directories, tables, such as Uniclass. • Incorporation of BS ISO 12006-2 compliant classification Management processes to support collaborative • Recommendations for implementation of BS EN working. ISO 13567-2. as layers and sub-models. • Incorporation of BS ISO 12006-2 compliant classification tables, such as Uniclass. • Recommendations for implementation of BS EN ISO 13567-2. • Extending controlled naming to files and directories, as well tables, such aswith Uniclass. Compatibility BS EN 82045-2 and ISO 82045-5. Use• of this document • Recommendations for implementation of BS EN ISO 13567-2. as layers and sub-models. Use of Incorporation this document Recommendations for implementation ofthe BS classification EN ISO 13567-2. of BS ISO 12006-2 As a •Code of Practice, this British Standardcompliant takes form of guidance • Compatibility with BS EN 82045-2 and ISO 82045-5. Use of tables, this document such asthis As Code of Practice, Britishnot Standard takes anda recommendations. ItUniclass. should be quoted as the if itform wereofa guidance Use of Incorporation this document •Code of BS ISOnot 12006-2 and It should be quoted as if itclassification were a guidance As a recommendations. of Practice, this British Standard takes the form of specification and particular care should becompliant taken that claims • Recommendations for implementation ofto BSensure EN ISO 13567-2. tables, such As a recommendations. Code of Practice, this British Standard takes the specification and particular care not should be taken that claims andcompliance ItUniclass. should be quoted asto if ensure itform wereof a guidance of are notasmisleading. and recommendations. It should not be quoted as if it were a of compliance are not misleading. specification and particular care should be taken to ensure that claims Use of this document forwith implementation of BS ENisISO 13567-2. Any • userRecommendations claiming compliance this British Standard expected to specification and particular care should be taken to ensure that claims of compliance are not misleading. As a Code of Practice, this British Standard takes the form of guidance Any user claiming compliance with this British Standard is expected to be able to justify any course of action that deviates from its of compliance are not misleading. Use of this document andable recommendations. It should notthis bethat quoted as iffrom it were a be justify any course ofwith action deviates itsexpected Any usertoclaiming compliance British Standard is to recommendations. As a user Code of Practice, this British Standard takes the form of guidance Any compliance thisthat British Standard is to specification and any particular care should bedeviates taken to ensure that claims recommendations. be able toclaiming justify course ofwith action from itsexpected Presentational conventions and recommendations. It should not bethat quoted as iffrom it were be able to justify course of action deviates its a of compliance areany not misleading. recommendations. Presentational conventions specification and careare should be taken to ensure that claims recommendations. The in particular this standard roman (i.e. upright) Any provisions user claiming compliance with presented this BritishinStandard is expected to Presentational conventions of compliance are not standard misleading. The provisions inany this are presented in roman (i.e. upright) type. Itstorecommendations are expressed indeviates sentences in which the be able justify course of action that from its Presentational conventions type. Its recommendations are with expressed in sentences the to The in this standard are presented inStandard romanin (i.e. upright) principal auxiliary verb is “should”. Any provisions user claiming compliance this British iswhich expected recommendations. The provisions in this standard are presented in roman (i.e. upright) principal auxiliary verb is “should”. type. Its recommendations are expressed in sentences in which the be able to justify any course of action that informative deviates frommaterial its Commentary, explanation and general is type. Its recommendations are expressed in sentences in which the principal auxiliary verb is “should”. Presentational conventions recommendations. Commentary, explanation informative material is presented in smaller italic and type,general and does not constitute a principal auxiliary verbstandard is “should”. The provisions in this aregeneral presented in roman (i.e. upright) presented in smaller italic and type, and does not constitute a Commentary, explanation informative material is normative element. Presentational conventions Commentary, explanation and general type. Its recommendations expressed ininformative sentences inmaterial which normative element. presented in smaller italicare type, and does not constitute a theis The word “should” is used to express recommendations of this standard. The provisions in this are and presented in roman (i.e. upright) presented in smaller italic type, does not constitute a principal auxiliary verbstandard is “should”. normative element. usedintothe express of thise.g. standard. The word “should” “may” is is used text torecommendations express permissibility, as an type. Its recommendations are expressed in sentences in which the normative element. Commentary, explanation and informative isan The “may” isprimary used the textgeneral torecommendations express as word “should” is usedinto express ofmaterial this standard. alternative to the recommendation of permissibility, the clause. Thee.g. word principal auxiliary verb is “should”. The word “should” is used to express recommendations ofofthis standard. presented in smaller italic type, does alternative to to the recommendation ofnot theconstitute clause. The word “may” isprimary used in the text and toe.g. express permissibility, as an “can” is used express possibility, a consequence anae.g. action or Commentary, explanation and general informative material is The word “may” is used in the text to express permissibility, e.g. as an normative element. “can” is used to express possibility, e.g. a consequence of an action alternative an event. to the primary recommendation of the clause. The word or presented in smaller italic type, and does alternative to to the primary recommendation ofnot theconstitute clause. The word or an “can” is used express a consequence anastandard. action Theevent. word “should” is usedpossibility, to expresse.g. recommendations ofofthis normative element. “can” is used to express possibility, e.g. a consequence of an action or an event. The word “may” is used in the text to express permissibility, e.g. as an an event. The word “should” is used to express recommendations of this alternative to the primary recommendation of the clause. Thestandard. word

© of BSIan 2007 • an iii The word “may” is used in the text toe.g. express permissibility, e.g. as “can” is used to express possibility, a consequence action or 2016 • iii © The British Standards Institution 2015 • iii © BSI 2007 • alternative an event. to the primary recommendation of the clause. The word iii © of BSIan 2007 • or iii “can” is used to express possibility, e.g. Standards a consequence action © The British Institution 2015 • iii

type. Its recommendations are expressed in sentences in which the principal auxiliary verb is “should”.

1192:2007+A2:2016 BS 1192:2007+A1:2015

BS 1192:2007

Commentary, explanation and general informative material is presented in smaller italic type, and does not constitute a normative element. The word “should” is used to express recommendations of this standard. The word “may” is used in the text to express permissibility, e.g. as an alternative to the primary recommendation of the clause. The word “can” is used to express possibility, e.g. a consequence of an action or an event. Notes and commentaries are provided throughout the text of this standard. Notes give references and additional information that are important but do not form part of the recommendations. Commentaries © BSI 2007 • iii give background information.

Contractual and legal considerations This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. Compliance with a British Standard cannot confer immunity from legal obligations.

iv • 2016 iv • © The British Standards Institution 2015

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007

Introduction Introduction Collaboration between the participants in construction projects is

Collaboration between delivery the participants in construction projects pivotal to the efficient of facilities. Organizations are is pivotal to theworking efficientindelivery of facilities.environments Organizationsinare increasingly new collaborative order to increasingly working in new collaborative environments order to achieve higher standards of quality and greater re-use ofin existing achieve higher of Aquality greater re-use of collaborative existing knowledge and standards experience. majorand constituent of these knowledge andisexperience. A communicate, major constituent of these collaborative environments the ability to re-use and share data environments is theloss, ability to communicate, re-use and share data efficiently without contradiction or misinterpretation. efficiently without loss, contradiction or misinterpretation. Each year considerable resources are spent on making corrections to Each year considerable resources are spentinonapproved making corrections to non-standard data, training new personnel data creation non-standardco-ordinating data, trainingthe new personnel in approvedteams data creation techniques, efforts of subcontractor and techniques, co-ordinating the efforts of subcontractor teams and solving problems related to data reproduction. solving problems related to data reproduction. The use of this standard is particularly applicable where technology The use processes of this standard is particularly applicableThese where technology enabled are used to support projects. processes enabled processes are used to support projects. These processes include: include: • automation 3D model, data, drawing and document automationof of drawing and document production processes; • production automationprocesses; of drawing and document production processes; • indexing and searching project material; • indexing and searching project material; • filtering and sorting; • filtering and sorting; • quality checking and document comparisons. • quality checking and document comparisons. Where the implementation of standards is adequately addressed, there Where the implementation of standards is adequately addressed, there are significant benefits to both the productivity of project teams and the are significant to both the productivity of project teams and the profitability of benefits the organization. profitability of the organization. This standard applies to all construction project documentation. The set This standard applies to alleach construction project of project documents and document withindocumentation. it are viewed asThe a set of project of documents and each Itdocument within it are viewed as a hierarchy named containers. gives recommendations for structured hierarchy of named containers. It gives recommendations for structured names to convey information (meta-data) about the containers required names to convey information (meta-data) the containers required for effective information management andabout exchange. for effective information management and exchange. It is clear that standards and this British Standard in particular, are one It is clear that standards andmembers this British Standard in particular, are one way to enable project team to work together more efficiently way accurately to enable project team members to work efficiently and on construction projects. This together standard more enables and accurately on construction This standard enables increasing confidence in the useprojects. of a common naming convention and increasingtoconfidence in the use offor a common naming convention and approach collaborative working use in architecture, engineering, approach to collaborative fordata useuse in architecture, engineering, construction and facilitatesworking efficient in facilities management. construction and facilitates efficient data use in facilities management.

1 Scope 1 This Scope standard establishes the methodology for managing the

This standard establishesand thequality methodology for managing the production, distribution of construction information, production, distribution quality of construction information, including that generated and by CAD systems, using a disciplined process including that generated by CAD naming systems,policy. using a disciplined process for collaboration and a specified for collaboration and a specified naming policy. It is applicable to all parties involved in the preparation and use of It is applicable to all parties involvedconstruction, in the preparation and and use of information throughout the design, operation information throughout thethe design, construction, operation andchain. deconstruction throughout project lifecycle and the supply deconstruction throughout the project lifecycle and the supply chain. The principles for information sharing and common modelling are The principles for information sharing common modelling are equally applicable to building and civil and projects. equally applicable to building and civil projects. This standard is also a guide for developers of software applications to This standard also a guide for developersthrough of software applications enable them toissupport its implementation the provision of to enable them tofiles support its implementation configuration or application add-ons. through the provision of configuration files or application add-ons. © BSI2015 2007 • 1 2016 © The British Standards Institution •• 1 1 © BSI 2007 • 1

BS 1192:2007 1192:2007+A1:2015 BS 1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 NOTE 1 The standard is an alternative where the formal meta-data recommendations as provided in BS EN 82045-2 and ISO 82045-5 cannot NOTE 1 The standard is an alternative where the formal meta-data be used because of the absence of a compliant and common document recommendations as provided in BS EN 82045-2 and ISO 82045-5 cannot repository withinofan project team. be used because theorganization absence of aor compliant and common document repository within an organization or project team. NOTE 2 This standard does not give guidance on the use of different data exchange file formats, exchange non-graphic data, structuring nor NOTE 2 This standardthe does not giveofguidance on the use of different data the exchange data held object classes and their instances nor the data exchange file of formats, theas exchange of non-graphic data, structuring nor structuring engineering the exchangeappropriate of data heldto asspecialist object classes and theiranalyses, instancesnor northe the data definition and use of data as instance parameters. structuring appropriate toheld specialist engineering analyses, nor the definition and use of data held as instance parameters.

2 Normative references 2 The Normative references following referenced documents are indispensable for the application ofreferenced this document. For dated the edition The following referenced documents arereferences, indispensable for the following document is indispensable foronly the cited applies. For undated references, the latest edition ofthe theedition application ofthis thisdocument. document. Fordated dated references, only application of For references, only the edition cited applies. For references, latest edition of the referenced document (including any the amendments) applies. cited applies. Forundated undated references, the latest edition of the referenced document any amendments) applies. referenced document(including (including amendments) applies. BS ISO 12006-2:2001, Buildingany construction – Organization of information about construction works– –Organization Part–2: Framework for ISO Building construction of information BS ISO 12006-2, 12006-2:2001, Building construction Organization of about construction works – Part 2:works Framework classification classification of information information about construction – Part for 2: Framework for classification of information NOTE The implementation of BS ISO 12006-2 in the UK is published under the name “Uniclass". of BS ISO 12006-2 in the UK is published NOTE The implementation under the name “Uniclass".

3 Terms and definitions 3 For Terms and definitions the purposes of this British Standard, the following terms and definitions apply. of this British Standard, the following terms and For the purposes definitions apply.

3.1 3.1

code sequence of characters, often a mnemonic, having defined meaning code

3.2 3.2

container named persistent set of data within a file system or application data container

when interpreted in the context of the field in whichdefined it is entered, used sequence of characters, often a mnemonic, having meaning to concisely convey when interpreted in meta-data the context of the field in which it is entered, used to concisely convey meta-data storagepersistent hierarchy set including, not alimited to, directory, sub-directory, named of databut within file system or application data data file,hierarchy or distinct sub-set of datalimited file, such as a chapter or section, storage including, buta not to, directory, sub-directory, layersfile, or or symbol data distinct sub-set of a data file, such as a chapter or section, layers or symbol NOTE 1 “Named containers” is the common pattern on structured information for design and management. Thepattern actual implementation NOTE 1 “Named containers” is the common on structured of “named containers” might be different in different operating systems and information for design and management. The actual implementation of proprietary file formats. “named container” is, however, “named containers” mightThe be different in differentpattern operating systems and distinct in that single name is associated to a collection. principles proprietary fileaformats. The “named container” pattern is,The however, of this standard be applied the actualThe principles distinct in that acan single name is independently associated to aofcollection. implementation of the pattern. of this standard can be“named appliedcontainer” independently of the actual implementation of the “named container” pattern. NOTE 2 Directories include sub-directories and folders. NOTE 2 Files Directories include sub-directories and folders. NOTE 33 Files includemodels, models, sub-models, documents, tables and include sub-models, sheets, data, sheets, documents, tables and schedules. schedules. NOTE 3 Files Files includemodels, models, sub-models, documents, tables and 3 include sub-models, sheets, data, sheets, documents, tables and schedules. schedules. NOTE 4 Containers within files include layers, sections and symbols.

3.3 3.3

NOTE 4

Containers within files include layers, sections and symbols.

conventional Cartesian axis geometric convention using positive conventional Cartesian axis co-ordinates (X, Y, Z) ordered as (East, North, upwards), so that conventional plans(X, useY,X,Z)Y;ordered and Z isas geometric convention using positive co-ordinates upwards (East, North, upwards), so that conventional plans use X, Y; and Z is upwards

2 2 •• © © BSI The2007 British Standards Institution 2015 2 • © BSI 2 • 2016 2 • © The2007 British Standards Institution 2015

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 3.4

document

BS 1192:2007

container for persistent information that can be managed and interchanged as a unit

3.4 3.5

document [BS EN 82045-1, ISO/IEC 8613-1, 3.2.3 modified] container for persistent information that can be managed and interchanged as a unit drawing document used toISO/IEC present 8613-1, graphic information [BS EN 82045-1, 3.2.3 modified]

3.6 3.5

field drawing

3.6

field and codes used in those fields.

3.7

part of a container name reserved meta-data document used to present graphic for information NOTE The standard controls the usage of fields for naming containers

part of a container name reserved for meta-data

instance

NOTE The standard controls the usage of fields for naming containers occurrence of an entity at a particular location and orientation within a and codes used in those fields.

model

3.7 3.8 3.8 3.9 3.9

instance

layer occurrence of an entity at a particular location and orientation within a container comprising selected entities, typically used to group for model purposes of selective display, printing and management operations layer

meta-data container comprising selected entities, typically used to group for data used of forselective the description management of documents and other purposes display,and printing and management operations containers of information meta-data NOTE Each item of meta-data resides in a field. Codes are the values data used the description and management of documents and other allowed forfor fields. containers of information

3.10

model

3.10

model NOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D),

NOTE Each item of meta-data resides in a field. Codes are the values collection of containers organized to represent the physical parts of allowed for fields.

objects, for example a building or a mechanical device

collection of containers organized represent the physical parts of and can include graphical as well asto non-graphical content. This standard objects, example a building a mechanical device is based for on generating, sharing, or etc., model files, not just drawings.

3.11

Drawings are produced when the model is complete, correct and NOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D), consistent. and can include graphical as well as non-graphical content. This standard is based generating, sharing, etc., model not just drawings. NOTE 2 on Models can include information byfiles, reference. Drawings are produced when the model is complete, correct and NOTE 3 Information Models are a collective of 3D Models, originator consistent. Information/Data, (non-graphical), documents, drawings and any other

agent responsible for production of a container

3.11 3.12

information neededcan to deliver theinformation project. by reference. NOTE 2 Models include NOTE See Clause 7.

originator sub-model agent responsible for production of a container

model included as an instance in another model NOTE See Clause 7.

3.12

sub-model model included as an instance in another model

4 Collaboration management processes 1192:2007+A2:2016 4.1 BS 1192:2007 1192:2007+A1:2015 BS 4.1.1

Process considerations Standard method and procedure

Projects should follow a common set of generic processes at the highest 4 Collaboration management processes

4.1

level, which are fine-tuned on a project-by-project basis. The procedures outlined apply to all approaches to project design Process considerations production, including:

4.1.1

• co-ordination the procedure project model files (2D and 3D) as they Standard methodofand

4.1.2

General project issues develop;

develop; Projects shouldfollow followaacommon commonset setofofgeneric genericprocesses processesatatthe thehighest highest Projects should production of 2Don drawings from 2D andbasis. 3D models; and level,•which are TheThe procedures level, which arefine-tuned fine-tuned ona aproject-by-project project-by-project basis. outlined to all approaches project production, and procedures outlined apply to alltoapproaches project design • apply production of 2D drawings usingdesign 2DtoCAD draughting co-ordination of the information model.  production, including: software. •

co-ordination of the project model files (2D and 3D) as they

The • project “standard and procedure” should be agreed production ofmethod 2D drawings from 2D and 3D models; andand committed to by all the relevant parties involved in the project (e.g. the • design production of 2D drawings using 2D CADetc.) draughting client, consultants, supply chain partners, at the presoftware. construction contract stage in the project lifecycle.

4.1.2

To implement the “standard General project issuesmethod and procedure” the following elements should be in place: The project “standard method and procedure” should be agreed and • Roles and should be agreed, particular committed to by allresponsibilities the relevant parties involved in theinproject (e.g.the the responsibility for design co-ordination of the various design client, design consultants, supply chain partners, etc.) at the predisciplines. construction contract stage in the project lifecycle. • Naming should and be adopted according to To implement theconventions “standard method procedure” the following Clauses 5 to 15. elements should be in place: • •

Arrangements should be inshould place be to create maintain the Roles and responsibilities agreed,and in particular the project specific codes as described in 6.3 to 15.4.3 responsibility for design co-ordination of the variousand design project spatial co-ordination as described in Annex A. disciplines.

• •

A “Common Data Environment” (CDE) approach be Naming conventions should be adopted accordingshould to adopted to allow information to be shared between all Clauses 5 to 15. members of the project team (see 4.2). This is a repository, for Arrangements should be in or place to create and maintain the example a project extranet electronic document project specific codes as described in 6.3 to 15.4.3 and management system. project spatial co-ordination as described in Annex A. A suitable information hierarchy should be agreed that A “Common Environment” (CDE) approach should be supports theData concepts of the CDE and the document adopted to allow information to be shared between all repository as indicated in 5.4.2. members of the project team (see 4.2). This is a repository, for example a project extranet or electronic document management system.

• • •

•

4 • © BSI 2007

4 • 4 • 2016 4 • © © BSI The2007 British Standards Institution 2015

A suitable information hierarchy should be agreed that supports the concepts of the CDE and the document repository as indicated in 5.4.2.

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007 4.2 4.2 4.2.1 4.2.1

Process and the Common Data Environment Process (CDE) and the Common Data Environment (CDE) Outline of a Common Data Environment Outline of a Common Data Environment NOTE 1 There are four phases of the CDE as illustrated in Figure 1. NOTE 1 There are four phases of the CDE as illustrated in Figure 1.

Information, once prepared, should be placed into the Information, once prepared, be placed into passed the WORK-IN-PROGRESS (WIP)should (see 4.2.2) area and through the WORK-IN-PROGRESS (WIP) (see 4.2.2) areathe andphases passedofthrough model in an anti-clockwise direction through its life. the model in an anti-clockwise direction through the phases of its life. NOTE 2 The naming, numbering and identification of all data held in the CDE in numbering Clause 5. and identification of all data held in NOTE 2 are Thedefined naming, the CDE are defined in Clause 5.

Key to to the the process processisisthe themanagement managementofofmoving movingthe thedata databetween between each each Key tofour the process is the management of moving the it data between each phases 4.2.2, 4.2.3, and that of the phases (see (see 4.2.2, 4.2.3,4.2.4 4.2.4 and4.2.5), 4.2.5), itisishere here thatvital vital of the fourapproving phases (see 4.2.2, 4.2.3, 4.2.4 and it is here that checking,  , authorizing and accepting  processes are vital checking, approving and issuing processes are4.2.5), executed. checking, executed. approving and issuing processes are executed.

4.2.2 4.2.2

WORK-IN-PROGRESS WORK-IN-PROGRESS

The WIP area of the CDE (see Figure 2) is where members of the project The area the CDE is where members software of the project teamWIP carry outoftheir own (see workFigure using2) their organization’s team carry out their work repository using theiror organization’s software systems. Whether theown common an organization’s in-house systems. Whether repository or anshould organization’s repository is used,the thecommon models and documents employ ain-house similar repository is used, the models and documents should employ a similar management process as that used for the total project. management process as that used for the total project. The organization is responsible for the quality of the WIP information The organization responsible for the qualityand of the WIPprocesses information and should ensureisthat appropriate checking review are and should ensure that appropriate checking and review processes are in place. in place. NOTE 1 Each model file only contains information for which each design team is1 NOTE Eachmodel model fileText only contains information for which each design 1 responsible. text deleted  contains for Each deleted only only containsinformation information forwhich which each  task  team is responsible. team is responsible. NOTE 2 The organization also includes work package subcontractors who develop based onalso consultants’ where contracts require NOTE 2 Thedesign organization includes design, work package subcontractors this specific who develop approach. design based on consultants’ design, where contracts require this specific approach.

The data continues to be updated in the WIP area and should be indexed The data continues continues to be be updated updated ine.g. theWIP WIParea area and should indexed to indicate minor version changes, P02.1, etc., until nextbe published data to in the and  options  to indicate minor version changes, e.g. P02.1, etc., until next published the SHARED area (see 4.2.3). should be indexed to indicate minor version changes, e.g. P02.01, to area (see 4.2.3). etc.the SHARED Text deleted

1192:2007+A2:2016 BS 1192:2007 1192:2007+A1:2015 BS

Figure 1

Document and data management repository

 CLIENT SHARED AREA SHARED

WORK IN PROGRESS

SUITABILITY S1

Check, Review, Approve

Verified design data shared with the project team: Ongoing design development

Non-verified design data used by in-house design team only:

SUITABILITY S0

REVISION Pnn

VER Pnn.n

Task Team 1 Task Team 2

CLIENT SHARED AREA

Task Team 3 Clients Authorization

PUBLISHED DOCUMENTATION

SUITABILITY An

VERIFIED

Coordination and validated design output for use by the total project team. Production information sutable for Stage Completion Acceptance or Construction:

ARCHIVE

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007

A process should be put in place to enable the continued availability of BS to 1192:2007 the ARCHIVE area information (see Figure 9), subsequent the design and construction phases to support the following:

ARCHIVE • history of the transfer of the project information; ARCHIVE A process should be put in place to enable the continued availability of

• change audits; the ARCHIVE area information (see Figure 9), to the design A process should be put in place to enable the subsequent continued availability of and construction phases to support the following: • asset register; the ARCHIVE area information (see Figure 9), subsequent to the design and construction to support following: • the transfer of thethe project information; • history models;ofphases • • • •

history the transfer of the project information; change of audits; documents; change audits; e.g. Health and Safety file; asset register; legal purposes, asset register; models; operation and maintenance information.

• • models; • The documents; NOTE ARCHIVE area of the CDE is for inactive or superseded material in addition to the final signed-off “As Built” • documents; legal purposes, e.g. Health and Safety file; data and documentation.

Figure 9

Figure 9 Figure 9

legal purposes, e.g. Health and Safety file; • operation and maintenance information. Audit trail, data, documents, asset and facility management • 1 The operation andarea maintenance TheARCHIVE ARCHIVE area of the CDE is or or superseded material NOTE of CDEinformation. isfor forinactive inactive superseded information held in ARCHIVE in additionintoaddition the final signed-off signed-off “Construction  and material to the final “As Record”. Built” data

NOTE The ARCHIVE area of the CDE is for inactive or superseded documentation. 2 addition For a serial the ARCHIVE be transferred into the client’s NOTE in material to client the final signed-offmay “As Built” data and Asset Information Model (AIM) for continued maintenance and update. documentation.

Audit trail, data, documents, asset and facility management information held documents, in ARCHIVEasset and facility management Audit trail, data, information held in ARCHIVE

1192:2007+A2:2016 BS 1192:2007 1192:2007+A1:2015 BS

5 Naming of containers 5.1

Structure of names NOTE 1 Different containers have different fields joined together but otherwise use the same conventions.

Names for containers should be created by joining together codes in the specified fields, in the specified order, using only the “-” hyphen character, which is therefore not allowed in any code. NOTE 2 Any “description” (see Clause 14) is appended following an underscore “_”. NOTE 3 The hyphen character may be used in a description field but this is deprecated.

5.2

Assigning codes Containers should have codes assigned for each of the specified fields. NOTE

The codes for fields are defined in Clauses 6 to 15.

Any container having more than one dominant code for any single field should be sub-divided.

5.3 5.3.1

Codes Sources of codes Codes should be selected from one of two sources: a) standard codes (see 5.3.2); or b) project specific codes (see 5.3.3).

5.3.2

Standard codes Containers should have standard codes assigned for the fields as listed in 6.2 to 15.2. Standard codes should be used wherever possible.

5.3.3

Project specific codes Project specific values for fields should be given codes that are unique and distinctive, with clear descriptions. Project specific codes should not be overly long as some repository systems cannot handle long file-identifiers. Containers should have codes assigned for the fields as specified in 6.3 to 15.3. Each code should not imply meaning that is duplicated in other fields. NOTE This is necessary to ensure that complex rules are not required to maintain consistency between the fields. For example, avoid putting meaning in a revision field that is related to the suitability field.

The codes should be published and maintained alongside the document register. Codes should be mnemonics, where possible, to ensure users can clearly identify them and differentiate between them.

14 • © 14 • 2016 14 • © BSI The2007 British Standards Institution 2015

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007 5.4 5.4 5.4.1 5.4.1

Naming of containers Naming of containers

Patterns for naming containers Patterns for naming containers Names for containers should be created according to three patterns: Names for containers should be 5.4.2); created or according to three patterns: a) directories and folders (see a) directories and folders (see 5.4.2); or b) files (see 5.4.3); or

5.4.2 5.4.2

b) (see 5.4.3); c) files containers withinor files including layers (see 5.4.4). c) containers within files including layers (see 5.4.4).

Directories and folders Directories and Directories should be folders transmitted and stored in repositories with names composed joining one mandatory andin two optional fields given Directoriesby should be the transmitted and stored repositories with names in Table 1. by Anjoining example given in 5.5. and two optional fields given composed theisone mandatory in Table 1. An example is given in 5.5. intermediate sub-directories NOTE Implementations might introduce

Table 1 Table 1

based fields present inmight the fileintroduce naming specified in 5.4.3. NOTE onImplementations intermediate sub-directories based on fields present in the file naming specified in 5.4.3.

Naming of directories and folder containers Naming of directories and folder containers

Field Field Project

Obligation Obligation Required

Clause Clause 6

A) Project Suitability A) Suitability Revision A)

Required Optional Optional

6 15.3.2 15.3.2 15.3.3

A) A) Revision If information

Optional 15.3.3track meta-data passes through an environment that cannot then this field can be included to environment identify the “suitability” “revision”. If information passes through an that cannotand track meta-data Thethen two this optional be used or omitted together. and “revision”. field fields can beshould included to identify the “suitability” A)

5.4.3 5.4.3

The two optional fields should be used or omitted together.

Files Files Files should be transmitted and stored in repositories in a context which makes clear be thetransmitted fields defined the directory (see 5.4.2). Files should Files should andfor stored in repositories in a context which be transmitted stored in repositories with names composed by makes clear theand fields defined for the directory (see 5.4.2). Files should joining the seven mandatory and three optional fields composed given in Table be transmitted and stored in repositories with names by 2 (an example is given in 5.5). and three optional fields given in Table 2 joining the seven mandatory (an example is given 5.5). NOTE The file name in also contains the extension suffix identifying the

Table 2 Table 2

type of application applicable. NOTE The file name also contains the extension suffix identifying the type of application applicable.

Naming of file Naming of file

Field Field Project

Obligation Obligation Required

Clause Clause 6

Project Originator Originator assets Zones Volumeand or system

Required Required

6 7 7 8.1.2

Zones and Levels and assets locations Levels and locations Type

Required Required

8.1.2 8.1.3 8.1.3 9

Type Role Role Classification

Required Required Optional

9 10 10 11

Classification Number Number Suitability A)

Optional Required Required meta-data  metadata Optional

11 13 13 15.2.2

SuitabilityA)A) 15.2.2 meta-data  metadata Optional 15.2.3 Revision A) A) Optional where there is no 15.2.3 Revision If files pass through an environment directory context, field canthrough be included to document the suitability revision. A) this If files pass an environment where there is noand directory context, Thethis optional fields “suitability” “revision” should beshould used or meta-data  fields“suitability” “suitability” and “revision” should beomitted usedor ortogether.  metadata  fields and “revision” be used field can be included to and document the suitability and revision. The optional fields “suitability” and “revision” should be used or omitted together. omitted together. omitted together. © BSI2015 2007 • 15 • 15 2016 • 15 © The British Standards Institution © BSI 2007 • 15

1192:2007+A2:2016 BS 1192:2007 1192:2007+A1:2015 BS 5.4.4

Containers within files Containers within files should have names composed by joining the three mandatory fields and one optional field given in Table 3 (an example is given in 5.5). NOTE The provisions applicable to containers within files do not apply to unstructured documents such as un-scaled sketches, narrative and renderings.

Table 3

5.5

Naming of containers within files including layers Field

Obligation

Clause

Role

Required

Classification

Required

Presentation

Required

Description

Optional

Examples of naming containers COMMENTARY ON 5.5 Table 4 shows how the fields associated to the containers are used to create the container names. The codes are taken from the standard codes or are examples that might be used for project specific codes.

Table 4

Examples of field usage

Fields

Directories (see 5.4.2)

Files (see 5.4.3)

Project

PR1

XYZ

Originator

Zones Volumeand or system assets

Containers within files including layers (see 5.4.4)

Clause

V1 01   Z1

8.1.2

Levels and locations

8.1.3

Type

Role

A G31 (optional) Uniclass  (optional)

Classification

A G322  Uniclass

Presentation

Number

0001

Description (optional) Suitability (optional) Revision (optional) Name

S1 PR1-S1-P2

P02 P2  PR1-XYZ-01-01-M3-A-0001  PR1-XYZ-Z1-01-M3-A-0001

16 • © 16 • 2016 16 • © BSI The2007 British Standards Institution 2015

11 12 13

Doors

P02 P2 

14 15.2.2 15.2.3

AUniclass-M_Doors A-G322-M_Doors

1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007

6 Project 6.1

Principles A single common project identifier should be defined at the initiation of the project; independent and recognizably distinct from any individual organization’s internal job number. Where possible it should match any existing contract code. Where a project involves several elements or one element with several phases, each should be assigned an identifier. NOTE A project can be divided into sub-projects.

6.2

Standard codes for project NOTE There are no standard codes mandated for the project field.

6.3

Project specific codes for project The code for the project and any sub-projects should be from two to six characters.

7 Originator 7.1

Principles A unique identifier for each organization should be defined on joining the project. The unique identifier should identify the organization responsible for creating the data.

7.2

Standard codes for originator NOTE There are no standard codes mandated for the originator field.

7.3

Project specific codes for originator The code for each originating organization should be from three to six characters.

8 Divisions 8.1 8.1.1

Principles Types of physical sub-division The project should be divided into manageable sub-divisions using two criteria: a) and assets (see 8.1.2); a) zones volume or system  (see 8.1.2); b) and locations locations(see (see8.1.3) 8.1.3)(see (seealso also Annex b) levels and Annex C).C). NOTE Buildings displaced named usingusing levels levels but most NOTE Buildingsare arevertically vertically displaced named butcivil most structures are horizontally displaceddisplaced and named using location or chainages. civil structures are horizontally and named using location or Civil projectsCivil occupying large areas suchlarge as oilareas refinery sitesasand chainages. projects occupying such oilairports refinerywould sites use the “location” codeuse based a grid basis based or poston code each In case and airports would theon“location” code a grid. In basis. each ““ volume sub-division. ” then adds additional subdivision. case “zone” then adds additional subdivision.

BS 1192:2007 1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007

8.1.2 8.1.2 8.1.2

Zones and assets Volumes and systems

Every container should document a single building zone or asset Every container shouldwithin document a single building volume or (location), contained a simple volume of space. Zones and assets system (location), contained within a simple volume of space. There should be should at leastdocument one set ofazones to be Every container singleexplicitly building designated zone or asset  volume per role  explicitly There should be at least one set of non-overlapping. (location), contained within a simple volume of space. designated to be non-overlapping. NOTE 1 The term “asset” might be more appropriate for infrastructure There should be at least one set of zones explicitly designated to be projects. Text deleted non-overlapping. NOTE 2Where Where possible be defined so as to identify possible “ “zones” volumesshould ” should be defined so as to identifyaa NOTE 1portion The of term “asset” might be more appropriate for infrastructure logical of work intended be delivered by a single team. logical portion work intended to beto delivered by a single team. projects.

8.1.3 8.1.3

8.2 8.2.1 8.2 8.2.1

NOTE 2 and Where possible “zones” should be defined so as to identify a Levels locations logical portion of work intended to be delivered by a single team.

Where a container documents a single building level (floor) or location, the code and for that level should be used. Where a container documents Levels locations multiple levels, a distinct code should be used. Where a container documents a single building level (floor) or location, NOTE The term “location” might be more appropriate for infrastructure the code for that level should be used. Where a container documents projects. multiple levels, a distinct code should be used. NOTE The term “location” might be more appropriate for infrastructure Standard codes for divisions projects.

General

Standard codes for divisions

The standard codes for the spatial divisions of the project should be used wherever possible. General NOTE

8.2.2 8.2.2

8.2.2

Building projects are more likely to use standard codes. The standard codes for the spatial divisions of the project should be used wherever possible.

Standard codes “volumes/system” Standard codesfor for “zone/asset”

NOTE Building projects are more likely to use standard codes. The “ zone/asset” code  should be should one orbe two characters. The following volume/system ” code one or two characters. The

code should be used for for a“zone/asset” whole following code should be used for alevel. whole level. Standard codes 00 ZZ All zones volumes should be one or two characters. The following All The “zone/asset” code code list should be used for a whole level. This should be expanded in the project specific codes.

00 All zones

8.2.3

Wherever codes possible,for repetition of theand same“location” codes, per Role, should Standard “levels”

8.2.3

Standard codes for “levels” and “location” ZZ Multiple levels

be avoided.  be expanded in the project specific codes. This list should The “level/locator” code should be two characters as follows:

XX No level text applicable deleted  should be as  Text deleted ”” code code should be two two characters characters as follows: follows: The “level “level/locator” code should be two characters as follows: GF Ground floor ZZ Multiple levels 00 Base level of building (where ground floor is not appropriate) XX No level applicable For floor levels above GF Ground floor ground floor, the floor number should be used as follows: is is notnot appropriate) 00 Base level level of of building building(where (whereground groundfloor floor appropriate) or linear assets 01 Floor For floor levels1above ground floor, the floor number should be used as 02 Floor 2, etc. NOTE 1 The location codes for linear assets are likely to require project follows: specific codes. For mezzanine 01 Floor 1the prefix “M” should be used as follows:

02 2, etc. M1 Floor Mezzanine above level 01 M2 Mezzanine above“level 02, etc. For mezzanine the prefix M” should be used as follows: For all below above the ground floor the prefix “B” should be used: M1levels Mezzanine level 01 M2 B1 Mezzanine above level 02, etc. B2,levels etc. below the ground floor the prefix “B” should be used: For all NOTE B1 For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2.

B1 B2, etc.

18 • © BSI 2007

NOTE

18 • 2016 18 • © The British Standards Institution 2015

18 • © BSI 2007

For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2.

The “level/locator” code should be two characters as follows: For floor levels above ZZ Multiple levelsground floor, the floor number should be used as follows: XX No level applicable

1192:2007+A2:2016 BS 1192:2007+A1:2015

GF Ground 01 Floor 1 floor 00 of building (where ground floor is not appropriate) 02 Base Floorlevel 2, etc.

For floor levels the above ground should be used as mezzanine prefix “M” floor, shouldthe befloor usednumber as follows: follows: M1 Mezzanine above level 01 01 Floor 1 M2 Mezzanine above level 02, etc. 02 Floor 2, etc. For all levels below the ground floor the prefix “B” should be used: For mezzanine the prefix “M” should be used as follows: B1 M1 Mezzanine above level 01 B2, etc. BS 1192:2007 M2 Mezzanine above see level NOTE 2 For Forfloor floornotation, notation, see BS EN ISO and BSBS ENEN ISO 4157-2. BS02, ENetc. ISO4157-1 4157-1 and ISO 4157-2. For all levels below the ground floor the prefix “B” should be used:

18 • © BSI 2007

8.3 8.3.1

18 • © BSI 2007

8.3 8.3 8.3.1 8.3.1 8.3.2 8.3.2 8.3

8.3.1 8.3.3 8.3.2 8.3.2 8.3.2

8.3.3 8.3.3 8.3.2 9 9.1 8.3.3

Project specific codes for divisions B1 B2, etc.

BS 1192:2007 Principles NOTE 2 For Forfloor floornotation, notation, see and BSBS EN ISO 4157-2. seeBS BSEN ENISO ISO4157-1 4157-1 and EN ISO 4157-2. BS 1192:2007 Project specific codes for divisions should be detailed in the project space statement (see Annex A). The specific codes should not Project specific codes forproject divisions conflict with the standard codes given in 8.2. Project specific codes for divisions

Principles NOTE Infrastructure projects are more likely to require project specific BS 1192:2007 codes. Principles Project specific codes for divisions should be detailed in the project space statement (seecodes Annex A). The project specific codes not Project specific codes for divisions should be detailed in theshould project Project specific for  volume “asset” ” and Project specific codes for““zone” and conflict withspecific the standard codes given in 8.2.specific codes should not space statement (see Annex A). The Project codes forproject divisions “system ” “conflict Zone” and “asset” identifiers should beindefined required, with with the standard codes given 8.2. to as NOTE Infrastructure projects are more likely require project specific detailed demarcation in system three dimensions andshould descriptions. “codes. Volume ” and “ ” identifiers be defined as Principles NOTE Infrastructure projects are more likely to require project specific required, with detailed demarcation in three dimensions and descriptions. codes. Project specific codes for divisions should be detailed in the project Project specific codes for “level” and “location” Project specific volume “asset” ” and Project specificcodes codesfor for““zone” and space statement (see Annex A). The project specific codes should not system ” codes Project specific for “zone” and “asset” “““Level” and “asset” location” codes should be defined with detailed Zone” and “ identifiers should be defined as required, with conflict with the standard codes given in 8.2. demarcation especially in the vertical dimension and a detailed detailed demarcation in three dimensions and descriptions. “Zone” Volume  ” and “  system  ” identifiers should be defined as and “asset” identifiers should be defined as required, with NOTE Infrastructure projects are more likely to require project specific description. required, with detailed demarcation in three dimensions and descriptions. detailed codes. demarcation in three dimensions and descriptions.

Project specific codes for “level” and “location” Project specific codes for “zone” “level” and “location” Project for and “asset” “Type Level” andspecific “location”codes codes should be defined with detailed

especially in theshould vertical dimension and a detailed “demarcation and ““asset” location” codes be defined detailed “Level” Zone” and identifiers should be definedwith as required, with description. demarcation especially in the vertical dimension and a detailed detailed demarcation in three dimensions and descriptions. Principles description. To aid recognition, container should contain a single type of Project specificevery codes for “level” and “location” information, e.g. a drawing, location model, typical assembly or detail “Level” and “location” codes should be defined with detailed information. demarcation especially in the vertical dimension and a detailed Principles description. Principles Standard codes for types of information To aid recognition, every container should contain a single type of information, e.g. a drawing, locationshould model, typical or of detail To recognition, every contain aassembly single type Theaid standard codes for filecontainer containers holding models and drawings the information. information, e.g. a drawing, location model, typical assembly or detail code should be exactly two characters as follows: information. DR Drawing Principles Standard codes for types of information M2 Two dimensional model Standard codes for typesshould of information M3recognition, Threecodes dimensional model To every contain a single type of the Theaid standard for filecontainer containers holding models and drawings MR Model rendering information, e.g. a drawing, location model, typical assembly or detail code should be exactly twocontainers characters as follows: The standard codes for file holding models and drawings the VS Visualization information. code should be exactly two characters as follows: DR SC Drawing Schedule or table M2 Two dimensional model DR Drawing SP Specification Standard codes types of information M3 Three dimensional model M2 Twoofdimensional model BQ Bill Quantityfor MR Model rendering M3 Three dimensional model SC Structural The standard codesCalculation for file containers holding models and drawings the VS Visualization MR Model The Standards Institution 2015codes. • 19 code be rendering exactly two©characters follows: NOTEshould 1 There is no provision toBritish extendas this for project specific SC Schedule or table VS Visualization DR Drawing NOTE For file containers SP SC2 Specification Schedule or table holding documents there are no standard codesM2 mandated. Twoofdimensional BQ Bill Quantity model SP Specification M3 Three dimensional model SC Structural Calculation BQ Bill of Quantity MR Model rendering Project specific codes for “Standards types of information SC1 Structural Calculation 2016codes. • 19 © The Institution 2015 • 19 NOTE There is no provision toBritish extend this for ” project specific VS Visualization NOTE 1 There no provision to extend this forthere project codes. Project “type” codesholding should be defined for documents. NOTE For fileis containers documents arespecific no standard SC2 specific Schedule or table

9 Type 9 Type

9.1 9.1 9.2

9 Type 9.1 9.2 9.2

9.2

9.3

9.1 8.3.1

1192:2007+A2:2016 BS 1192:2007+A1:2015

Principles

Principles To aid recognition, every container should contain a single type of information, e.g.codes a drawing, locationshould model, assembly or detail Project specific for divisions betypical detailed in the project information. space statement (see Annex A). The project specific codes should not conflict with the standard codes given in 8.2.

9.2

Standard codesprojects for types oflikely information NOTE Infrastructure are more to require project specific

8.3.2

The standard codes for file containers holding models and drawings the code should be exactly two characters as follows: Project specific codes for “zone” and “asset”

codes.

DR Drawing M2 Two dimensional model detailed demarcation in three dimensions and descriptions. Code Code File Type M3 Three dimensional model AF Animation file (of a model) AF Model MR rendering Project specific codes for “level” and “location” CM Combined model (combined multidiscipline model) CM VS Visualization CR Specific for the clash process “Level” CR “location” codes should be defined with detailed SC and Schedule or table DR 2D drawingin the vertical dimension and a detailed DR Specification demarcation especially SP M2 2DQuantity model file M2 Bill of description. BQ M3 3D model file M3 SC Structural Calculation MR MR Model rendition file for other renditions, e.g thermal NOTE 1 There is no provision to extend this for project specific codes. analysis etc. NOTE 2 ForVisualization file containers documents there are no standard VS fileholding (of a model) VS Fileand types for drawings models “ Zone” “asset” identifiersand should be defined as required, with

8.3.3

9 Type 9.1 9.3

9.2

9.3

codes mandated.

File types for documents Principles Code specific Code File Type codes for “types” of information Project To aid recognition, every container should contain a single type of

BQ BQ Bill quantitieslocation model, typical assembly or detail information, e.g. of a drawing, Project specific “ type” codes should be defined for documents. CA Calculations CO Correspondence information. NOTE is noplan mandate for any project specific codes for drawings. CO Correspondence CP ThereCost CP Cost plan DB Database Standard codes for types of information DB Database FN File note FN File note HS Health andfile safety The standard codes for containers holding models and drawings the HS Health and two safety IE Information Exchange file as follows: code should be exactly characters IE Information exchange MI Minutes / action notes file DR Drawing MI Minutes statement / action notes MS Method M2 Two dimensional model © BSI 2007 • 19 MS Method statement PP Presentation M3 Three dimensional model PP Presentation PR Programme MR Model rendering PR Programme RD Room data sheet VS RD Visualization Room data RI Request forsheet Information SC or table RI Schedule Request for information RP Report SP RP Report of accommodation SA Specification Schedule BQ Quantity SA Bill of Schedule of accommodation CA Calculations SC Structural Calculation SH SH Schedule SN SN Snagging list NOTE 1 There is no provision to extend this for project specific codes. SP SP Specification NOTE 2 For file containers holding documents there are no standard SU SU Survey codes mandated.

Project specific codes for “types” of information Project specific “type” codes should be defined for documents. NOTE There is no mandate for any project specific codes for drawings.

20 • 2016 20 • © The British Standards Institution 2015

1192:2007+A2:2016 BS 1192:2007+A1:2015

BSBS 1192:2007 1192:2007

1010Role Role 10.1 10.1Principles Principles Each Each organization organization should should be allocated be allocated to one to one or more or more roles roles within within thethe project. project. NOTE NOTEFurther Further subdivision subdivision of roles of roles cancan be implied be implied using using the the classification classification field, field, see see Clause Clause 11.11.

10.2 10.2Standard Standard codes codes forfor roles roles TheThe standard standard codes codes for for filefile rolerole should should be exactly be exactly oneone character character as as follows: follows: A B C D E F G H I K L M P Q S T W X Y Z

AArchitect Architect BBuilding Building Surveyor Surveyor CCivil Civil Engineer Engineer DDrainage, Drainage, Highways Highways Engineer Engineer EElectrical Electrical Engineer Engineer FFacilities Facilities Manager Manager GGeographical Geographical andand Land Land Surveyor Surveyor HHeating Heating andand Ventilation Ventilation Designer Designer I Interior Interior Designer Designer KClient Client LLandscape Landscape Architect Architect MMechanical Mechanical Engineer Engineer PPublic Public Health Health Engineer Engineer QQuantity Quantity Surveyor Surveyor SStructural Structural Engineer Engineer TTown Town andand Country Country Planner Planner WContractor Contractor XSubcontractor Subcontractor YSpecialist Specialist Designer Designer ZGeneral General (non-disciplinary) (non-disciplinary)

10.3 10.3Project Project specific specific codes codes forfor roles roles codes J,J,N, codes should beallocated allocated TheThe codes codes J, N, R, N,R, U R,U or Uor V orV or Vorlonger orlonger longer codes codes should should be be allocated for for non-standard project specific roles listed and published. non-standard non-standard project project specific specific roles. roles.

1111Classification Classification 11.1 11.1Principles Principles Every container container should should bebe classified beclassified classified bybyaby a single code, code, taken taken from from thethe text deleted  code, Every container should asingle  Text deleted  code, taken from the chosen reference to accurately describe the chosen chosen reference reference dictionary, dictionary, to accurately to dictionary, accurately describe describe thethe construction construction construction assets represented.  deleted  or more. assets assets represented. represented. The The code code should should beText two be two characters characters or more. A single A single code code from from oneone table table should should be used. be used.

20 20• •© BSI © BSI 2007 2007

2016 • 21 © The British Standards Institution 2015 • 21

1192:2007+A2:2016 BS 1192:2007+A1:2015 11.2

Use Uniclass Table G for Building elements and Table H for Civil elements, with Table J for services work and Table L for identified Products and Materials. Information relating to Spaces may be BS 1192:2007 classified using Table F.

Early stage design such as Scheme design and preliminary phases may initially use Table D for Facilities, Table E for Construction Standard codes for classification Elements, but these are deprecated. Classification codes shouldbebebody selected from afor system compliant Classification codes should selected from a system compliant to CPIC is the co-ordinating responsible maintaining and BSBS ISO 12006 Uniclass and the Uniclass publication.  tables to ISO 12006-2:2001, and in particular from equivalent updating the classifications. Reference should be made to to A.7 and A.8 for Elements, A.9 for Services work and for their website http://www.productioninformation.org/ forA.13 updates. deleted  Text

identified Products and Materials. NOTE 2 There to extend thisUNICLASS through thepublication project specific  NOTE Referistono theprovision BIM TOOLKIT and the for dictionary. NOTE 1 The UK implementation of BS ISO 12006-2 is Uniclass so this latest coding practices.  recommendation can be expressed as follows:

11.3

Project specific for elements classification Use Uniclass Table Gcodes for Building and Table H for Civil

elements, with Table J for services work and Table L for identified NOTE Thereand is noMaterials. mandate Information for any project specific codes for thisbefield. Products relating to Spaces may classified using Table F.

Early stage design such as Scheme design and preliminary phases 12 Presentation may initially use Table D for Facilities, Table E for Construction

12.1

Elements, but these are deprecated.

Principles CPIC is the co-ordinating body responsible for maintaining and updating theshould Uniclass Reference should conventions. be made to Every container beclassifications. consistent in its presentational their website http://www.productioninformation.org/ for updates. For both drawings and documents, graphical and textual content should be distinguished containers within suchthe asproject layering or NOTE 2 There isby nousing provision to extend this files through specific dictionary. sections.

11.3 12.2

NOTE This ensures that the information can still be re-used for a variety Project specific codes classification of presentational purposes withoutfor conflicting with re-use of information. NOTE There is no mandate for any project specific codes for this field.

Standard codes for presentation

standard code for presentation should be exactly one character as 12 The Presentation follows.

12.1

Dimensioning

Principles H Hatching and shading M container Model related Every shouldelements be consistent in its presentational conventions. P Plot/paper related elements For both drawings and documents, graphical and textual content should T Text be distinguished by using containers within files such as layering or sections. NOTE There is no provision to extend this with project specific codes.

12.3

BS 1192:2007

12.2

NOTE This ensures that the information can still be re-used for a variety of presentational purposes withoutfor conflicting with re-use of information. Project specific codes presentation NOTE There is no mandate for any project specific codes for this field.

Standard codes for presentation

The standard code for presentation should be exactly one character as

13 follows. Number 13.1

D Dimensioning H Hatching and shading Principles © BSI 2007 • 21 M Model related elements A sequential number should be used when a container is one of a series P Plot/paper related elements not distinguished by any other of the fields defined in Clauses 6 to 12. T Text NOTE There most often files. this with project specific codes. This applies NOTE is no provision toto extend

13.2 12.3

Standard codingcodes for numbers Project specific for presentation The numbering standard for coding should specific be exactly four NOTE There is for no mandate any project codes forinteger this field. numeric digits, used sequentially. Leading zeros should be used. NOTE

13.3

There is no need to mandate any codes for this field.

Project specific coding There is no further restriction for project specific coding care• 21 © BSIbut 2007 should be taken not to embody information present in other fields.

13.2

Standard coding for numbers The numbering for standard coding should be exactly four integer numeric digits, used sequentially. LeadingBS zeros should be used. 1192:2007+A2:2016 1192:2007+A1:2015 NOTE

13.3

There is no need to mandate any codes for this field.

Project specific coding There is no further restriction for project specific coding but care should be taken not to embody information present in other fields.

14 Description 14.1

Principles Descriptive text should not be used to imply further distinctions of meaning. However, descriptive text derived from the other fields and used consistently can be used to aid recognition.

14.2

NOTE 1 fields.

This implies that this field is able to be deduced from the other

NOTE 2

Avoid long, unwieldy and poorly worded descriptions.

Standard coding for description NOTE

14.3

There are no standard codes mandated for the description field.

Project specific coding NOTE There is no further restriction for the project specific coding of the description field.

15 Status 15.1

Principles The identification and management of the “status” of containers should BS 1192:2007 follow the principles given in Clause 4.

15.2 15.2.1

Types of “status” General If repositories are not able to track the “status” of each container (for example a model or drawing) then its “status” should be tracked through using two fields together: a) suitability (see 15.2.2); and

b) revision (see 15.2.3). The “suitability” “suitability”and and “revision” a document changes during NOTE The “revision” of aofdocument changes during the the  production  process. design process.

15.2.2

Suitability Every container should have a field indicating the approved “suitability” for use of the contained information.

15.2.3

Revision Every container should carry a “revision” field, indicating the issue sequence of the contained information.

15.3 15.3.1

Standard status codes for “status”

15.2.3

1192:2007+A2:2016 BS 1192:2007+A1:2015 15.3 15.3.1

Revision Every container should carry a “revision” field, indicating the issue sequence of the contained information.

Standard coding Standard status codes for “status” Standard codes should be used for the “status” fields wherever possible. NOTE Some codes might not be appropriate depending on whether they are models or documents.

15.3.2

Standard codes for “suitability” The “suitability” code should be one or two characters. The “suitability” codes given in Table 5 should be used. NOTE Use of a particular management process might make some codes inapplicable to some types of document.

BS 1192:2007+A2:2016 Table 5 Status

Standard codes for suitability models and documents

Description

Work in Progress Initial status or WIP S0 Master document index of file identifiers uploaded into the extranet. Shared (Non-contractual) Suitable for Co-ordination The file is available to be ‘shared’ and S1 used by other disciplines as a background for their information.

Revision

Graphical Data

NonGraphical Data

Documents

P01.01 etc to P0n.0n etc

✓

P01 to P0n

✓

✗

Suitable for Information

P01 to P0n

✗

✓

Suitable for Review & Comment

P01 to P0n

As required

✓

Suitable for Stage Approval

P01 to P0n

✗

✓

P01 to Pnn

✗

✓

P01 to Pnn

✗

✓

Text deleted Suitable for PIM Authorization S6 (Information Exchanges 1-3) Suitable for AIM Authorization S7 (Information Exchange 6)

WIP to Published Unauthorized and (Non-contractual) use at risk. D1

Suitable for Costing

P01.01 etc to P0n.0n

✓

Suitable for Tender

P01.01 etc to P0n.0n

✗

✓

Suitable for Contractor Design

P01.01 etc to P0n.0n

✓

Suitable for Manufacture/Procurement

P01.01 etc to P0n.0n

✗

✓

C01 to C0n

✓

P01.01 etc to P0n.0n etc

✓

C01 to C0n

✓

Published Documentation (Contractual) A1, A2, A3, Approved and accepted as stage complete An etc (C= Contractual/Complete) Partially signed-off: with minor comments from the Client. All minor comments should be indicated by B1, B2, the insertion of a cloud and a statement B3, Bn etc of ‘in abeyance’ until the comment is resolved, then resubmitted for full authorization. Published for AIM Acceptance As Construction Record documentation, CR PDF, Models etc

of design documents for transfer to the contractor or subcontractor. This sign-off process is the same as that for manually produced drawings and is used again for CAD or electronic data/drawings. Refer to BS 7000-4. NOTE 2 There is provision to extend this with project specific codes. A) For construction with minor comments from the client. 1192:2007+A2:2016 BS 1192:2007+A1:2015 All minor comments should be indicated by the insertion of a statement of ‘‘in abeyance” until the comment is resolved or minor changes incorporated and resubmitted to achieve full sign-off.

15.3.3

Standard codes for “revisions” Versions area should be be Versionscreated createdwithin withinthe theWORK-IN-PROGRESS WORK-IN-PROGRESS area should numbered P01.1, P01.2, P01.3 numbered using usingdecimals, decimals,e.g. e.g. P1.1, P1.2, P1.3, etc., etc.  signed-off when signed-off the This should should be bechanged changedtotointeger integer P1P01 when by theby originator originator for sharing. Thereafter the version within the WIP area should for sharing. Thereafter the version within the WIP area should become become P02.01 as detailed in 4.2.4. P2.1 as detailed in 4.2.4.

Formal the revision Formal revisions revisionsshould shouldbe benumbered numberedsequentially, sequentially,marking marking the revision  preliminary (P0n) or contractual (C0n)  . as either either pre-contractual or post-contractual. Preliminary sequentially as as thethe Preliminary revisions revisionsshould shouldbebenumbered numbered sequentially BS 1192:2007  preliminary  design develops, e.g. P2, P01, P02, P03, etc. pre-contract design develops, e.g. P1, P3, etc. Contractual revision should be numbered sequentially for Post contractorrevision be numbered sequentially forC01, any C02, changes any changes update should to the signed-off containers, e.g.  or update to the signed-off containers, e.g. C1, C2, C3, etc. C03 , etc. NOTE 11 The The“C” “C”notation notation indicates container can befor used for indicates thatthat the the container can be used construction  or contractual purposes (e.g. Stage Completion). construction and contractual purposes.

to extend this this withwith project specific codes. codes. NOTE 22 There Thereisisprovision provision to extend project specific

15.4 15.4.1

Project specific coding Project specific codes for status The project specific codes should not conflict with the standard codes.

15.4.2

Project specific codes for suitability Extra suitability codes can be defined indicating other suitability for use, if required, with detailed descriptions, reflecting the contractual arrangements. These codes should not conflict with the standard codes.

15.4.3

Project specific codes for revisions Extra revision codes can be defined, if required, with detailed descriptions. These codes should not conflict with the standard codes.

1192:2007+A2:2016 BS 1192:2007+A1:2015

BS 1192:2007 Annex A (normative) A.1

Project space statement General All models, whether 2D or 3D, should be created using a common project origin and orientation using a conventional Cartesian axis and common unit of length. The statements given in A.2 to A.4 should be included with the project dictionary, and refined as necessary. Models should be created at 1:1. Units should be SI units of measure. NOTE 1

SI units are defined in BS ISO 31.

The basic unit of length within models should be agreed to be metres for infrastructure projects or millimetres for building. NOTE 2 The accuracy achievable using the chosen units and origins might need to be checked.

A.2

Space A statement or diagram of the project origin and orientation should be included with the project dictionary. The origin should be related to both the project grid and to the site context. The orientation should be related to a specific geospatial north. NOTE The project origin is best located within or close to the project or site extent.

A.3

Geospatial A statement or diagram should relate the project space to a named global geospatial system in three dimensions (decimal degrees latitude, longitude and elevation in metres) and a plan orientation (decimal degrees clockwise rotation from north) (see Figure A.1). NOTE 1 Alternatively reference can be made to a standard named projection such as the UK Ordnance Survey grid (see http:// www.ordnancesurvey.co.uk/oswebsite/gps/information/ coordinatesystemsinfo/guidecontents/guide1.html). NOTE 2 A decimal latitude in degrees requires eight decimal places to achieve positioning to within 1 mm.

Figure A.1

Geospatial referencing

1192:2007+A2:2016 BS 1192:2007+A1:2015

Annex B (normative) B.1

BS 1192:2007

Quality management Quality policy Quality policy should ensure that models are maintained over their lifetimes. At the outset of any project all facets of the organization of the project’s graphical database should be formulated by the authors of the data with a view to satisfying end users. NOTE 1 These constitute the in-house standards. Early strategic thinking helps to ensure that all demands made on the model over its lifetime can be met effectively and realistically.

Models, which need to be maintained over long periods of time, might be subject to both major and minor updates and the same in-house standards should be applied to these amendments in order to ensure model integrity is preserved. In-house standards should be published and regularly reviewed, for example, at the adoption of each new software release. When models are to be extended to cover new topics, consideration should be given to the strategy adopted for structuring the new information and the way it will be integrated. Sustained data quality requires methodical checking at the time of input and persistent discipline when changes are made. Data quality should be checked systematically. This should include: a) elimination of spurious data outside normal file extents or limits; b) checks on file set-up parameters; c)

testing of container allocations by switching on and off containers;

d) listing of containers; e)

elimination of information which is not to scale;

purging of all unnecessary data;

g) elimination of references to un-checkable (i.e. uncontrolled) files such as renditions; h) formats that do not maintain dimensional integrity should not be used; i)