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

BRITISH STANDARD

Collaborative production of architectural, engineering and construction information – 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 A1 October 2015 See Foreword A2 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

© The British Standards Institution 2016 • i BS 1192:2007+A2:2016 BS 1192:2007+A1:2015BS 1192:2007 BS 1192:2007 BS 1192:2007+A1:2015BS 1192:2007 List of tables Foreword BS 1192:2007 Table 1 – Naming of directories and folder containers 15 Foreword Table 2 – Naming of file 15 ForewordPublishing information BS 1192:2007 Table 3 – Naming of containers within files including layers 16 ThisForewordPublishing BritishBritish StandardStandard information is is published publishe dby by BSI BSI Standards and came Limited, into effect under Table 4 – Examples of field usage 16 BS 1192:2007 onThisPublishinglicence 31 British December from StandardThe information British 2007. is It Standardspublishe was prepard Institution byed BSI by and Technical and came came intoCommittee into effect effect B/555,on Table 5 – Standard codes for suitability models and documents 25 ForewordConstructionThisonPublishing31 31December BritishBritish December StandardStandard 2007. informationdesign, 2007. It is wasis mode publishedIt publishe waspreparedlling prepar dby and byby BSIed BSITechnical data byStandards and Technical exchange came Committee Limited, intoCommittee. Aeffect list underB/555, of B/555, Table C.1 – Differences between international and British layer organizationsonConstructionThislicence 31 British December from StandardThe design, representeddesign, British 2007. modellingis mode It Standardspublishe was onlling this prepar andd co Institution andbymmitteeed dataBSI databy and Technicalexchange andcanexchange came became obtained into.Committee A into. list Aeffect list effectof on of request B/555,on naming fields 30 ForewordPublishingtoConstructionorganizationson31 its31December secretary. December 2007.represented representedinformationdesign, 2007. It was mode It onwas preparedon thislling this prepar committee co and bymmitteeed Technical databy Technical can canexchange beCommittee be obtained obtained Committee. A list B/555,on on ofrequest request B/555, organizationstoConstruction its secretary.secretary. design, representeddesign, modelling mode onlling this and co andmmittee data data exchange canexchange be obtained. A. list A list of on of request SupersessionThis British Standard is published by BSI and came into effect onPublishingtoorganizations its31 secretary. December representedrepresentedinformation 2007. It onwas on this this prepar committee committeeed by Technical can can be be obtained obtained Committee on on request request B/555, ThistoSupersession its British secretary.secretary. Standard supersedes BS 1192-5:1998, which is withdrawn. SupersessionConstructionThis British Standard design, is mode publishellingd andby BSI data and exchange came into. Aeffect list of onThisBS 311192:2007+A1:2015 British December Standard 2007. supersedes It supersedes was prepar BS BS ed1192-5:1998, 1192:2007,by Technical whichwhich Committee is is withdrawn. withdrawn. B/555, RelationshipSupersessionorganizations represented with other on this publications committee can be obtained on request toConstructionThis its British secretary. Standard design, supersedes modelling BSand 1192-5:1998, data exchange which. A islist withdrawn. of CopyrightThisRelationshipInformationBS 1192:2007+A1:2015 British is Standard claimed aboutwith insupersedes other Figuresthissupersedes document publications 1 BSto BS 9.1192-5:1998, 1192:2007,Reproduction whichwhich of these is is withdrawn. withdrawn. Relationshiporganizations represented with other on this publications committee can be obtained on request toSupersessionillustrationsCopyrightText its introduced secretary. is andclaimed or making altered in Figures products by Amendment 1 fromto 9. itReproduction No. might 1 is infringe indicated of thatthese in thecopyright. text by RelationshipInformation aboutwith other this document publications ThisDetailsCopyrightillustrationstags British of theis. StandardMinor andclaimed copyright making editorial insupersedes Figures ownerproducts changes (from 1 BSfromto are 9. 1192-5:1998,whom notitReproduction might tagged. any infringe permission which of thatthese is withdrawn.tocopyright. use this SupersessionillustrationillustrationsDetailsCopyrightText introduced of theis may andclaimed copyright or bemaking altered sought) in Figures ownerproducts by can Amendment (from be1 fromto obtained 9. whom itReproduction No. might byany1 is contactinginfringe permissionindicated of thatthese inthe tothecopyright. use text this by ThisRelationshipBSIDetailsillustrationillustrationstags Library, British of the .may StandardMinorandBritish copyright bemakingwith editorial sought) Standards supersedes other ownerproducts changescan House,publications(from be BSfrom obtainedare 1192-5:1998,whom 389 notit might tagged.Chiswick byany contactinginfringe permission which High that isRoad,the withdrawn.tocopyright. use this CopyrightLondonillustrationBSIDetails Library, of W4 theis may 4AL.Britishclaimed copyright be sought) Standards in Figuresowner can House,(from be1 to obtained 9. whom 389 Reproduction Chiswick byany contacting permission High of these Road,the to use this BSILondonillustration Library, W4 may 4AL.British be sought) Standards can House, be obtained 389 Chiswick by contacting High Road,the TheillustrationsRelationship changes and incorporated makingwith other products in th publicationsis revisedfrom it mightstandard infringe include: that copyright. BSI Library, British Standards House, 389 Chiswick High Road, TheDetailsCopyrightLondon changes of W4 theis 4AL. claimedincorporated copyright in Figuresowner in th (fromis 1 revisedto 9. whom Reproduction standard any permission include: of these to use this • Management processes to support collaborative working. illustrationillustrationsLondon W4 may 4AL.and bemaking sought) products can be from obtained it might by contactinginfringe that the copyright. The •changes Management incorporated processes in this to revised support standard collaborative include: working. BSITheDetails Library,•changes of Extending the Britishincorporated copyright controlledStandards owner in th naming House,(fromis revised whom 389to fistandard lesChiswick any and permission directories,include: High Road, to asuse well this • Management processes to support collaborative working. illustration•as Extending layersmay be and sought)controlled sub-models. can naming be obtained to files by and contacting directories, the as well London• W4 Management 4AL. processes to support collaborative working. •as Extending layers and controlled sub-models. naming to files and directories, as well BSI Library,• Compatibility British Standards with BS House,EN 82045-2 389 Chiswick and ISO High82045-5. Road, The •changes Extending incorporated controlled in th namingis revised to fistandardles and directories,include: as well London• W4 Compatibilityas layers 4AL. and sub-models.with BS EN 82045-2 and ISO 82045-5. • IncorporationasManagement layers and processessub-models. of BS ISO to 12006-2 support compliant collaborative classification working. • Compatibility with BS EN 82045-2 and ISO 82045-5. The •changes Incorporationtables, incorporated such as of Uniclass. BS in ISOthis 12006-2revised standard compliant include: classification • CompatibilityExtending controlled with BS naming EN 82045-2 to files and and ISO directories, 82045-5. as well • Incorporationtables,Management such as processes of Uniclass. BS ISO to 12006-2 support compliant collaborative classification working. • Recommendationsas layers and sub-models. for implementation of BS EN ISO 13567-2. • Incorporationtables, such as of Uniclass. BS ISO 12006-2 compliant classification • RecommendationsExtending controlled for naming implemen to fitationles and of directories,BS EN ISO 13567-2.as well • Compatibilitytables, such as with Uniclass. BS EN 82045-2 and ISO 82045-5. Use• of Recommendationsasthis layers document and sub-models. for implementation of BS EN ISO 13567-2. AsUse a • Codeof IncorporationRecommendationsthis of Practice, document thisof BS British for ISO implemen 12006-2 Standardtation compliant takes of theBS classificationformEN ISO of guidance13567-2. • Compatibility with BS EN 82045-2 and ISO 82045-5. andAsUse a recommendations. Codeof tables,this of Practice, document such as this ItUniclass. should British no Standardt be quoted takes as theif it form were of a guidance Use• of Incorporationthis document of BS ISO 12006-2 compliant classification specificationAsand a recommendations.•Code Recommendations of Practice,and particular this It should British forcare implemen noshou Standardt beld quotedbetation takentakes asof to theifBS ensureit form ENwere ISO of thata guidance13567-2. claims ofandspecificationAs compliancea recommendations.Codetables, of Practice,and ar suche particular not as misleading.this ItUniclass. should British care noshou Standardt beld quotedbe takentakes as to theif ensureit form were of thata guidance claims specificationofand compliance recommendations. and are particular not misleading. It should care noshout beld quotedbe taken as to if ensureit were thata claims AnyUse •user of Recommendationsthisclaiming document compliance for with implemen this Britishtation Standardof BS EN is ISO expected 13567-2. to ofspecification compliance and are particular not misleading. care should be taken to ensure that claims beAnyAs ablea userCode to claiming justifyof Practice, any compliance course this British of with action Standard this that British deviates takes Standard the from form isits expectedof guidance to of compliance are not misleading. recommendations.AnybeandUse able recommendations.user of to thisclaiming justify document any compliance course It should of with action no tthis be that Britishquoted deviates Standardas if from it were isits expected a to berecommendations.specificationAnyAs ablea userCode to claiming justifyof Practice,and anyparticular compliance course this British care of with action shou Standard this ldthat Britishbe deviates takentakes Standard tothe fromensure form isits expectedof that guidance claims to recommendations.ofbeandPresentational complianceable recommendations. to justify ar eany not conventions course misleading. It should of action not be that quoted deviates as if from it were its a specificationPresentational and particular conventions care should be taken to ensure that claims AnyTherecommendations. provisionsuser claiming in thiscompliance standard with are presentedthis British in Standard roman (i.e. is expected upright) to type.TheofPresentational compliance provisions Its recommendations ar ine thisnot conventions standardmisleading. are exprare presentedessed in sentences in roman in (i.e. which upright) the Presentationalbe able to justify any conventions course of action that deviates from its recommendations.AnyprincipalThetype. provisionsuser Its recommendationsclaimingauxiliary in this complianceverb standard is “should”. are with exprare presentedthisessed British in sentences in Standard roman in (i.e. is which expected upright) the to type.principalThe provisions Its recommendations auxiliary in this verb standard is “should”. are exprare presentedessed in sentences in roman in (i.e. which upright) the Commentary,be able to justify explanation any course ofand action gene thatral informativedeviates from material its is principaltype. Its recommendations auxiliary verb is “should”. are expressed in sentences in which the presentedCommentary,recommendations.Presentational in smaller explanation conventions italic andtype, gene andral does informative not constitute material a is principal auxiliary verb is “should”. normativeCommentary,presentedThe provisions in element. smaller explanationin this standarditalic andtype, are gene andpresentedral does informative not in roman constitute (i.e.material upright)a is presentednormativetype.Commentary,Presentational Its recommendations in element. smaller explanation conventions italic are andtype, expr gene andessedral does in informative sentences not constitute in material which a the is The word “should” is used to express recommendations of this standard. normativeprincipalpresentedThe provisions auxiliary in element. smaller in this verb standarditalic is “should”. type, are andpresented does not in roman constitute (i.e. upright)a The word “should”“may” is isused used in to the expres text sto recommendations express permissibility, of this e.g.standard. as an normativetype. Its recommendations element. are expressed in sentences in which the alternativeTheCommentary, word “should”“may” to the explanation is primary isused used in to recommethe expres and text gene stondation recommendations expressral informative of permissibility,the clause. of material thisThe e.g.standard. word as is an principal auxiliary verb is “should”. “can”Thealternativepresented word is used “should”“may” into tothesmaller expressis primary isused used italic inpossibility, to recommethe expres type, text sandto ndation e.g.recommendations express doesa conseq of not permissibility,the uenceconstitute clause. of of this Thean a e.g.standard.action word as anor Summary of pages analternative“can”normativeTheCommentary, event. word is used “may” toelement. tothe explanation expressis primary used inpossibility, recommethe and text gene to ndatione.g. expressral a conseqinformative of permissibility,theuence clause. ofmaterial Thean e.g.action word as is anor This document comprises a front cover, an inside front cover, pages i to iv, presented in smaller italic type, and does not constitute a The“can”analternative event. word is used “should” to tothe express primary is used possibility, torecomme express ndation e.g.recommendations a conseq of theuence clause. of of this Thean standard.action word or pages 1 to 32, an inside back cover and a back cover. normative element. Thean“can” event. word is used “may” to expressis used inpossibility, the text to e.g. express a conseq permissibility,uence of an e.g.action as anor alternativeThean event. word “should” to the primary is used torecomme expressndation recommendations of the clause. of thisThe standard. word ii • © The British Standards Institution 2016 “can”The word is used “may” to expressis used inpossibility, the© The text British to e.g. express Standardsa conseq permissibility, uenceInstitution© ofBSI an 2015 2007 e.g.action as• anoriiiiii analternative event. to the primary recommendation of the clause.© BSI The 2007 word • iii “can” is used to express possibility,© The British e.g. Standardsa conseq uenceInstitution© ofBSI an 2015 2007 action • oriiiiii an event. © BSI 2007 • iii

© BSI 2007 • iii

© BSI 2007 • iii BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007 BS 1192:2007 BS 1192:2007+A1:2015BS 1192:2007 Foreword BS 1192:2007 Foreword ForewordPublishing information BS 1192:2007 ForewordPublishing information This BritishBritish StandardStandard is is published publishe dby by BSI BSI Standards and came Limited, intoBS effect under1192:2007 onThisPublishinglicence 31 British December from StandardThe information British 2007. is It Standardspublishe was prepard Institution byed BSI by and Technical and came came intoCommittee into effect effect B/555,on ForewordConstructionThisonPublishing31 31December BritishBritish December StandardStandard 2007. informationdesign, 2007. It is wasis mode publishedIt publishe waspreparedlling prepar dby and byby BSIed BSITechnical data byStandards and Technical exchange came Committee Limited, intoCommittee. Aeffect list underB/555, of B/555, organizationsonConstructionThislicence 31 British December from StandardThe design, representeddesign, British 2007. modellingis mode It Standardspublishe was onlling this prepar andd co Institution andbymmitteeed dataBSI databy and Technicalexchange andcanexchange came became obtained into.Committee A into. list Aeffect list effectof on of request B/555,on ForewordPublishingtoConstructionorganizationson31 its31December secretary. December 2007.represented representedinformationdesign, 2007. It was mode It onwas preparedon thislling this prepar committee co and bymmitteeed Technical databy Technical can canexchange beCommittee be obtained obtained Committee. A list B/555,on on ofrequest request B/555, organizationstoConstruction its secretary.secretary. design, representeddesign, modelling mode onlling this and co andmmittee data data exchange canexchange be obtained. A. list A list of on of request SupersessionThis British Standard is published by BSI and came into effect onPublishingtoorganizations its31 secretary. December representedrepresentedinformation 2007. It onwas on this this prepar committee committeeed by Technical can can be be obtained obtained Committee on on request request B/555, ThistoSupersession its British secretary.secretary. Standard supersedes BS 1192-5:1998, which is withdrawn. SupersessionConstructionThis British Standard design, is mode publishellingd andby BSI data and exchange came into. Aeffect list of organizationsonThisBS 311192:2007+A1:20151192:2007+A2:2016 British December Standard represented 2007. supersedes It supersedes was on this prepar coBS BSmmittee ed1192-5:1998, 1192:2007,1192:2007+A1:2015,by Technical can be whichobtainedwhich Committee is is withdrawn. withdrawn.onwhich request B/555, RelationshipSupersessionis withdrawn. with other publications toConstructionThis its British secretary. Standard design, supersedes modelling BSand 1192-5:1998, data exchange which. A islist withdrawn. of RelationshipInformation aboutwith other this document publications organizationsCopyrightThisBS 1192:2007+A1:2015 British is Standard claimed represented insupersedes Figuressupersedes on this 1 co BSto BSmmittee 9.1192-5:1998, 1192:2007,Reproduction can be whichobtainedwhich of these is is withdrawn. withdrawn.on request RelationshipInformation aboutwith other this document publications toSupersessionillustrationsCopyrightText its introduced secretary. is andclaimed or making altered in Figures products by Amendment 1 fromto 9. itReproduction No. might 1 is infringe indicated of thatthese in thecopyright. text by RelationshipInformation aboutwith other this document publications ThisDetailsCopyrightillustrationstagsText introducedBritish of theis. StandardMinor andclaimed copyright or making alterededitorial insupersedes Figures ownerproducts by changes Amendments (from 1 BSfromto are 9. 1192-5:1998,whom notitReproduction mightNo. tagged. any 1 andinfringe permission whichNo. of 2, thatthese isrespectively withdrawn.tocopyright. use this SupersessionillustrationillustrationsDetailsCopyrightTextare indicated introduced of theis may andclaimedin copyright the or bemaking altered textsought) in by Figures ownerproducts by tags can Amendment (from be1 fromto obtained 9. whomand itReproduction No. might  byany1 is contactinginfringe permission.indicated Minor of thateditorialthese inthe tothecopyright. use text this by ThisRelationshipBSIDetailsillustrationillustrationstagschanges Library, British of are the .may not StandardMinorandBritish copyright tagged. bemakingwith editorial sought) Standards supersedes other ownerproducts changescan House,publications(from be BSfrom obtainedare 1192-5:1998,whom 389 notit might tagged.Chiswick byany contactinginfringe permission which High that isRoad,the withdrawn.tocopyright. use this CopyrightLondonillustrationBSIDetails Library, of W4 theis may 4AL.Britishclaimed copyright be sought) Standards in Figuresowner can House,(from be1 to obtained 9. whom 389 Reproduction Chiswick byany contacting permission High of these Road,the to use this BSILondonillustration Library, W4 may 4AL.British be sought) Standards can House, be obtained 389 Chiswick by contacting High Road,the TheillustrationsRelationship changes and incorporated makingwith other products in th publicationsis revisedfrom it mightstandard infringe include: that copyright. BSI Library, British Standards House, 389 Chiswick High Road, TheDetailsCopyrightLondon changes of W4 theis 4AL. claimedincorporated copyright in Figuresowner in th (fromis 1 revisedto 9. whom Reproduction standard any permission include: of these to use this • Management processes to support collaborative working. illustrationillustrationsLondon W4 may 4AL.and bemaking sought) products can be from obtained it might by contactinginfringe that the copyright. The •changes Management incorporated processes in this to revised support standard collaborative include: working. BSITheDetails Library,•changes of Extending the Britishincorporated copyright controlledStandards owner in th naming House,(fromis revised whom 389to fistandard lesChiswick any and permission directories,include: High Road, to asuse well this • Management processes to support collaborative working. illustration•as Extending layersmay be and sought)controlled sub-models. can naming be obtained to files by and contacting directories, the as well London• W4 Management 4AL. processes to support collaborative working. •as Extending layers and controlled sub-models. naming to files and directories, as well BSI Library,• Compatibility British Standards with BS House,EN 82045-2 389 Chiswick and ISO High82045-5. Road, The •changes Extending incorporated controlled in th namingis revised to fistandardles and directories,include: as well London• W4 Compatibilityas layers 4AL. and sub-models.with BS EN 82045-2 and ISO 82045-5. • IncorporationasManagement layers and processessub-models. of BS ISO to 12006-2 support compliant collaborative classification working. • Compatibility with BS EN 82045-2 and ISO 82045-5. The •changes Incorporationtables, incorporated such as of Uniclass. BS in ISOthis 12006-2revised standard compliant include: classification • CompatibilityExtending controlled with BS naming EN 82045-2 to files and and ISO directories, 82045-5. as well • Incorporationtables,Management such as processes of Uniclass. BS ISO to 12006-2 support compliant collaborative classification working. • Recommendationsas layers and sub-models. for implementation of BS EN ISO 13567-2. • Incorporationtables, such as of Uniclass. BS ISO 12006-2 compliant classification • RecommendationsExtending controlled for naming implemen to fitationles and of directories,BS EN ISO 13567-2.as well • Compatibilitytables, such as with Uniclass. BS EN 82045-2 and ISO 82045-5. Use• of Recommendationsasthis layers document and sub-models. for implementation of BS EN ISO 13567-2. AsUse a • Codeof IncorporationRecommendationsthis of Practice, document thisof BS British for ISO implemen 12006-2 Standardtation compliant takes of theBS classificationformEN ISO of guidance13567-2. • Compatibility with BS EN 82045-2 and ISO 82045-5. andAsUse a recommendations. Codeof tables,this of Practice, document such as this ItUniclass. should British no Standardt be quoted takes as theif it form were of a guidance Use• of Incorporationthis document of BS ISO 12006-2 compliant classification specificationAsand a recommendations.•Code Recommendations of Practice,and particular this It should British forcare implemen noshou Standardt beld quotedbetation takentakes asof to theifBS ensureit form ENwere ISO of thata guidance13567-2. claims ofandspecificationAs compliancea recommendations.Codetables, of Practice,and ar suche particular not as misleading.this ItUniclass. should British care noshou Standardt beld quotedbe takentakes as to theif ensureit form were of thata guidance claims specificationofand compliance recommendations. and are particular not misleading. It should care noshout beld quotedbe taken as to if ensureit were thata claims AnyUse •user of Recommendationsthisclaiming document compliance for with implemen this Britishtation Standardof BS EN is ISO expected 13567-2. to ofspecification compliance and are particular not misleading. care should be taken to ensure that claims beAnyAs ablea userCode to claiming justifyof Practice, any compliance course this British of with action Standard this that British deviates takes Standard the from form isits expectedof guidance to of compliance are not misleading. recommendations.AnybeandUse able recommendations.user of to thisclaiming justify document any compliance course It should of with action no tthis be that Britishquoted deviates Standardas if from it were isits expected a to berecommendations.specificationAnyAs ablea userCode to claiming justifyof Practice,and anyparticular compliance course this British care of with action shou Standard this ldthat Britishbe deviates takentakes Standard tothe fromensure form isits expectedof that guidance claims to recommendations.ofbeandPresentational complianceable recommendations. to justify ar eany not conventions course misleading. It should of action not be that quoted deviates as if from it were its a specificationPresentational and particular conventions care should be taken to ensure that claims AnyTherecommendations. provisionsuser claiming in thiscompliance standard with are presentedthis British in Standard roman (i.e. is expected upright) to type.TheofPresentational compliance provisions Its recommendations ar ine thisnot conventions standardmisleading. are exprare presentedessed in sentences in roman in (i.e. which upright) the Presentationalbe able to justify any conventions course of action that deviates from its recommendations.AnyprincipalThetype. provisionsuser Its recommendationsclaimingauxiliary in this complianceverb standard is “should”. are with exprare presentedthisessed British in sentences in Standard roman in (i.e. is which expected upright) the to type.principalThe provisions Its recommendations auxiliary in this verb standard is “should”. are exprare presentedessed in sentences in roman in (i.e. which upright) the Commentary,be able to justify explanation any course ofand action gene thatral informativedeviates from material its is principaltype. Its recommendations auxiliary verb is “should”. are expressed in sentences in which the presentedCommentary,recommendations.Presentational in smaller explanation conventions italic andtype, gene andral does informative not constitute material a is principal auxiliary verb is “should”. normativeCommentary,presentedThe provisions in element. smaller explanationin this standarditalic andtype, are gene andpresentedral does informative not in roman constitute (i.e.material upright)a is presentednormativetype.Commentary,Presentational Its recommendations in element. smaller explanation conventions italic are andtype, expr gene andessedral does in informative sentences not constitute in material which a the is The word “should” is used to express recommendations of this standard. normativeprincipalpresentedThe provisions auxiliary in element. smaller in this verb standarditalic is “should”. type, are andpresented does not in roman constitute (i.e. upright)a The word “should”“may” is isused used in to the expres text sto recommendations express permissibility, of this e.g.standard. as an normativetype. Its recommendations element. are expressed in sentences in which the alternativeTheCommentary, word “should”“may” to the explanation is primary isused used in to recommethe expres and text gene stondation recommendations expressral informative of permissibility,the clause. of material thisThe e.g.standard. word as is an principal auxiliary verb is “should”. “can”Thealternativepresented word is used “should”“may” into tothesmaller expressis primary isused used italic inpossibility, to recommethe expres type, text sandto ndation e.g.recommendations express doesa conseq of not permissibility,the uenceconstitute clause. of of this Thean a e.g.standard.action word as anor analternative“can”normativeTheCommentary, event. word is used “may” toelement. tothe explanation expressis primary used inpossibility, recommethe and text gene to ndatione.g. expressral a conseqinformative of permissibility,theuence clause. ofmaterial Thean e.g.action word as is anor presented in smaller italic type, and does not constitute a The“can”analternative event. word is used “should” to tothe express primary is used possibility, torecomme express ndation e.g.recommendations a conseq of theuence clause. of of this Thean standard.action word or normative element. Thean“can” event. word is used “may” to expressis used inpossibility, the text to e.g. express a conseq permissibility,uence of an e.g.action as anor alternativeThean event. word “should” to the primary is used torecomme expressndation recommendations of the clause. of thisThe standard. word “can”The word is used “may” to expressis used inpossibility, the© The text British to e.g. express Standardsa conseq permissibility, uenceInstitution© ofBSI an 20152016 2007 e.g.action as• anoriiiiii analternative event. to the primary recommendation of the clause.© BSI The 2007 word • iii “can” is used to express possibility,© The British e.g. Standardsa conseq uenceInstitution© ofBSI an 2015 2007 action • oriiiiii an event. © BSI 2007 • iii

© BSI 2007 • iii

© BSI 2007 • iii BS 1192:2007

Foreword Publishing information This British Standard is published by BSI and came into effect on 31 December 2007. It was prepared by Technical Committee B/555, Construction design, modelling and data exchange. A list of organizations represented on this committee can be obtained on request to its secretary. Supersession This British Standard supersedes BS 1192-5:1998, which is withdrawn. Relationship with other publications Copyright is claimed in Figures 1 to 9. Reproduction of these illustrations and making products from it might infringe that copyright. Details of the copyright owner (from whom any permission to use this illustration may be sought) can be obtained by contacting the BSI Library, British Standards House, 389 Chiswick High Road, London W4 4AL. The changes incorporated in this revised standard include: • Management processes to support collaborative working. • Extending controlled naming to files and directories, as well as layers and sub-models. • Compatibility with BS EN 82045-2 and ISO 82045-5. • Incorporation of BS ISO 12006-2 compliant classification tables, such as Uniclass. • Recommendations for implementation of BS EN ISO 13567-2. Use of this document As a Code of Practice, this British Standard takes the form of guidance and recommendations. It should not be quoted as if it were a specification and particular care should be taken to ensure that claims of compliance are not misleading. Any user claiming compliance with this British Standard is expected to be able to justify any course of action that deviates from its recommendations. Presentational conventions The provisions in this standard are presented in roman (i.e. upright) type. Its recommendations are expressed in sentences in which the principal auxiliary verb is “should”. BS 1192:2007+A1:20151192:2007+A2:2016 Commentary, explanation and general informative material is BS 1192:2007+A1:2015BS 1192:2007 presented in smaller italic type, and does not constitute a BS 1192:2007 normative element. The word “should” is used to express recommendations of this standard. Introduction The word “may” is used in the text to express permissibility, e.g. as an Introduction alternative to the primary recommendation of the clause. The word Collaboration between the participants in construction projects is BS 1192:2007 “can” is used to express possibility, e.g. a consequence of an action or pivotalCollaboration to the efficientbetween deliverythe participan of facilities.ts in construction Organizations projects are is an event. increasinglypivotal to the working efficient in delivery new collabo of facilities.rative environments Organizations in are order to achieveincreasingly higher working standards in new of qualitycollabo andrative greater environments re-use of inexisting order to Notes and commentaries are provided throughout the text of this knowledgeachieve higher and standardsexperience. of Aquality major and constituent greater re-useof these of collaborativeexisting standard. Notes give references and additional information that are environmentsknowledge and is experience. the ability to A comajormmunicate, constituent re-use of theseand share collaborative data important but do not form part of the recommendations. Commentaries © BSI 2007 • iii efficientlyenvironments without is the loss, ability contra to codictionmmunicate, or misinterpretation. re-use and share data give background information. efficiently without loss, contradiction or misinterpretation. Each year considerable resources are spent on making corrections to Contractual and legal considerations non-standardEach year considerable data, training resources new personnel are spent in on approved making correctionsdata creation to This publication does not purport to include all the necessary provisions techniques,non-standard co-ordinating data, training the new effo personnelrts of subcontractor in approved teams data creationand of a contract. Users are responsible for its correct application. solvingtechniques, problems co-ordinating related to the data effo reproduction.rts of subcontractor teams and solving problems related to data reproduction. Compliance with a British Standard cannot confer immunity The use of this standard is particularly applicable where technology from legal obligations. enabledThe use processesof this standard are used is particularly to support projects.applicable These where processes technology include:enabled processes are used to support projects. These processes include: • automation ofof  drawing3D model, and documentdata, drawing production and document processes; • automation of drawing and document production processes; •production indexing and processes; 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 areWhere significant the implementation benefits to both of standards the productivity is adequa of projecttely addressed, teams and there the profitabilityare significant of benefitsthe organization. to both the productivity of project teams and the profitability of the organization. This standard applies to all construction project documentation. The set ofThis project standard documents applies toand all each construc documtionent project within documentation. it are viewed as The a set hierarchyof project ofdocuments named contai and ners.each Itdocum gives entrecommend within it ationsare viewed for structured as a nameshierarchy to convey of named information containers. (meta-da It givesta) recommend about theations containers for structured required fornames effective to convey information information management (meta-da ta)and about exchange. the containers required for effective information management and exchange. It is clear that standards and this British Standard in particular, are one wayIt is clearto enable that standardsproject team and members this British to workStandard together in particular, more efficiently are one andway accuratelyto enable project on construction team members projects. to work This togetherstandard moreenables efficiently increasingand accurately confidence on construction in the use projects. of a common This st namingandard conventionenables and approachincreasing to confidence collaborativ ine the working use of for a common use in architecture, naming convention engineering, and constructionapproach to collaborativ and facilitatese working efficient for data use use in architecture, in facilities management. engineering, construction and facilitates efficient data use in facilities management. 1 Scope 1This Scope standard establishes the methodology for managing the production,This standard distribution establishes and the qualit methodologyy of construction for managing information, the includingproduction, that distribution generated andby CAD qualit systems,y of construction using a disciplined information, process forincluding collaboration that generated and a specified by CAD namingsystems, policy. using a disciplined process for collaboration and a specified naming policy. It is applicable to all parties involved in the preparation and use of informationIt is applicable throughout to all parties the design,involved construction, in the preparation operation and anduse of deconstructioninformation throughout throughout the thedesign, proj ectconstruction, lifecycle and operation the supply and chain. deconstruction throughout the project lifecycle and the supply chain. The principles for information sharing and common modelling are equallyThe principles applicable for informationto building and sharing civil andprojects. common modelling are equally applicable to building and civil projects. This standard is also a guide for developers of software applications to enableThis standard them to is support also a guide its implementation for developers through of software the provisionapplications of to configurationenable them to files support or application its implementation add-ons. through the provision of configuration files or application add-ons. iv • © The British Standards Institution 20152016 © The British Standards Institution© BSI 2015 2007 • • 1 © BSI 2007 • 1

iv • © BSI 2007 BS 1192:2007

Foreword Publishing information This British Standard is published by BSI and came into effect on 31 December 2007. It was prepared by Technical Committee B/555, Construction design, modelling and data exchange. A list of organizations represented on this committee can be obtained on request to its secretary. Supersession This British Standard supersedes BS 1192-5:1998, which is withdrawn. Relationship with other publications Copyright is claimed in Figures 1 to 9. Reproduction of these illustrations and making products from it might infringe that copyright. Details of the copyright owner (from whom any permission to use this illustration may be sought) can be obtained by contacting the BSI Library, British Standards House, 389 Chiswick High Road, London W4 4AL. The changes incorporated in this revised standard include: • Management processes to support collaborative working. • Extending controlled naming to files and directories, as well as layers and sub-models. • Compatibility with BS EN 82045-2 and ISO 82045-5. • Incorporation of BS ISO 12006-2 compliant classification tables, such as Uniclass. • Recommendations for implementation of BS EN ISO 13567-2. Use of this document As a Code of Practice, this British Standard takes the form of guidance and recommendations. It should not be quoted as if it were a specification and particular care should be taken to ensure that claims of compliance are not misleading. Any user claiming compliance with this British Standard is expected to be able to justify any course of action that deviates from its recommendations. Presentational conventions The provisions in this standard are presented in roman (i.e. upright) type. Its recommendations are expressed in sentences in which the principal auxiliary verb is “should”. BS 1192:2007+A1:2015 Commentary, explanation and general informative material is BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007 presented in smaller italic type, and does not constitute a BS 1192:2007 normative element. The word “should” is used to express recommendations of this standard. Introduction The word “may” is used in the text to express permissibility, e.g. as an Introduction alternative to the primary recommendation of the clause. The word Collaboration between the participants in construction projects is BS 1192:2007 “can” is used to express possibility, e.g. a consequence of an action or pivotalCollaboration to the efficientbetween deliverythe participan of facilities.ts in construction Organizations projects are is an event. increasinglypivotal to the working efficient in delivery new collabo of facilities.rative environments Organizations in are order to achieveincreasingly higher working standards in new of qualitycollabo andrative greater environments re-use of inexisting order to Notes and commentaries are provided throughout the text of this knowledgeachieve higher and standardsexperience. of Aquality major and constituent greater re-useof these of collaborativeexisting standard. Notes give references and additional information that are environmentsknowledge and is experience. the ability to A comajormmunicate, constituent re-use of theseand share collaborative data important but do not form part of the recommendations. Commentaries © BSI 2007 • iii efficientlyenvironments without is the loss, ability contra to codictionmmunicate, or misinterpretation. re-use and share data give background information. efficiently without loss, contradiction or misinterpretation. Each year considerable resources are spent on making corrections to Contractual and legal considerations non-standardEach year considerable data, training resources new personnel are spent in on approved making correctionsdata creation to This publication does not purport to include all the necessary provisions techniques,non-standard co-ordinating data, training the new effo personnelrts of subcontractor in approved teams data creationand of a contract. Users are responsible for its correct application. solvingtechniques, problems co-ordinating related to the data effo reproduction.rts of subcontractor teams and solving problems related to data reproduction. Compliance with a British Standard cannot confer immunity The use of this standard is particularly applicable where technology from legal obligations. enabledThe use processesof this standard are used is particularly to support projects.applicable These where processes technology include:enabled processes are used to support projects. These processes include: • automation ofof  drawing3D model, and documentdata, drawing production and document processes; • automation of drawing and document production processes; •production indexing and processes; 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 areWhere significant the implementation benefits to both of standards the productivity is adequa of projecttely addressed, teams and there the profitabilityare significant of benefitsthe organization. to both the productivity of project teams and the profitability of the organization. This standard applies to all construction project documentation. The set ofThis project standard documents applies toand all each construc documtionent project within documentation. it are viewed as The a set hierarchyof project ofdocuments named contai and ners.each Itdocum gives entrecommend within it ationsare viewed for structured as a nameshierarchy to convey of named information containers. (meta-da It givesta) recommend about theations containers for structured required fornames effective to convey information information management (meta-da ta)and about exchange. the containers required for effective information management and exchange. It is clear that standards and this British Standard in particular, are one wayIt is clearto enable that standardsproject team and members this British to workStandard together in particular, more efficiently are one andway accuratelyto enable project on construction team members projects. to work This togetherstandard moreenables efficiently increasingand accurately confidence on construction in the use projects. of a common This st namingandard conventionenables and approachincreasing to confidence collaborativ ine the working use of for a common use in architecture, naming convention engineering, and constructionapproach to collaborativ and facilitatese working efficient for data use use in architecture, in facilities management. engineering, construction and facilitates efficient data use in facilities management. 1 Scope 1This Scope standard establishes the methodology for managing the production,This standard distribution establishes and the qualit methodologyy of construction for managing information, the includingproduction, that distribution generated andby CAD qualit systems,y of construction using a disciplined information, process forincluding collaboration that generated and a specified by CAD namingsystems, policy. using a disciplined process for collaboration and a specified naming policy. It is applicable to all parties involved in the preparation and use of informationIt is applicable throughout to all parties the design,involved construction, in the preparation operation and anduse of deconstructioninformation throughout throughout the thedesign, proj ectconstruction, lifecycle and operation the supply and chain. deconstruction throughout the project lifecycle and the supply chain. The principles for information sharing and common modelling are equallyThe principles applicable for informationto building and sharing civil andprojects. common modelling are equally applicable to building and civil projects. This standard is also a guide for developers of software applications to enableThis standard them to is support also a guide its implementation for developers through of software the provisionapplications of to configurationenable them to files support or application its implementation add-ons. through the provision of configuration files or application add-ons. iv • © The British Standards Institution 2015 © The British Standards Institution© BSI 20152016 2007 • • 1 © BSI 2007 • 1

iv • © BSI 2007 BS 1192:20071192:2007+A1:2015 BS 1192:20071192:2007+A1:20151192:2007+A2:2016 BS 1192:2007+A1:2015BS 1192:2007

NOTE 1 The standard is an alternative where the formal meta-data NOTErecommendations 1 The standard as provided is an altern in BSative EN 82045-2 where the and fo ISOrmal 82045-5 meta-data cannot 3.4 document BS 1192:2007 recommendationsbe used because of asthe provided absence inof BSa compliant EN 82045-2 and and common ISO 82045-5 document cannot container for persistent information that can be managed and repository within an organization or project team. be used because of the absence of a compliant and common document interchanged as a unit NOTErepository 2 This within standard an organization does not give or guprojectidance team. on the use of different data 3.4[BS document EN 82045-1, ISO/IEC 8613-1, 3.2.3 modified] NOTEexchange 2 Thisfile formats, standard the does exchange not give of gu non-graphicidance on the data, use ofstructuring different data nor container for persistent information that can be managed and the exchange of data held as object classes and their instances nor the data exchange file formats, the exchange of non-graphic data, structuring nor 3.5interchanged drawing as a unit thestructuring exchange appropriate of data held to as speciali object classesst engineering and their analyses, instances nor nor the the data document used to present graphic information structuringdefinition and appropriate use of data to heldspeciali as instancest engineering parameters. analyses, nor the [BS EN 82045-1, ISO/IEC 8613-1, 3.2.3 modified] definition and use of data held as instance parameters. 3.53.6 fielddrawing 2 Normative references documentpart of a container used to pres nameent reserved graphic forinformation meta-data 2 Normative references NOTE The standard controls the usage of fields for naming containers The following referenced documents are indispensable for the 3.6 fieldand codes used in those fields. Theapplication following of referenced referencedthis document. document docume For nts datedis indispensableare references, indispensable for only the for the the edition part of a container name reserved for meta-data 3.7 instance applicationcited applies. ofof this Forthis document. undateddocument. refere For For datednces, dated references,the references, latest edition only only the of the edition the edition NOTE The standard controls the usage of fields for naming containers occurrence of an entity at a particular location and orientation within a citedreferenced applies.applies. document For For undated undated (inclu references, refereding nces,any theamendments) the latest latest edition edition applies. of theof the and codes used in those fields. referenced documentdocument (including (including any any amendments) amendments) applies. applies. model BS ISO 12006-2:2001, Building construction – Organization of 3.7 instance BSinformation ISO 12006-2,12006-2:2001, about Building construction Building construction construction works – –Organization Part – 2: Organization Framework of information offor 3.8occurrence layer of an entity at a particular location and orientation within a informationclassificationabout construction about of information worksconstruction – Part 2: works Framework – Part for2: Framework classification for modelcontainer comprising selected entities, typically used to group for NOTEclassification The implementation of information of BS ISO 12006-2 in the UK is published purposes of selective display, printing and management operations 3.8 layer NOTEunder the The name implementation “Uniclass". of BS ISO 12006-2 in the UK is published 3.9 meta-data under the name “Uniclass". container comprising selected entities, typically used to group for purposesdata used offor selective the description display, and printing management and management of documents operations and other 3 Terms and definitions containers of information 3 Terms and definitions 3.9NOTE meta-data Each item of meta-data resides in a field. Codes are the values For the purposes of this British Standard, the following terms and alloweddata used for for fields. the description and management of documents and other Fordefinitions the purposes apply. of this British Standard, the following terms and containers of information definitions apply. 3.10 model NOTE Each item of meta-data resides in a field. Codes are the values 3.1 code collection of containers organized to represent the physical parts of allowed for fields. 3.1 codesequence of characters, often a mnemonic, having defined meaning objects, for example a building or a mechanical device sequencewhen interpreted of characters, in the contextoften a mnemonic,of the field inhaving which defined it is entered, meaning used 3.10 modelNOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D), whento concisely interpreted convey in meta-datathe context of the field in which it is entered, used andcollection can include of containers graphical organized as well as to non-graphical represent the conten physicalt. This parts standard of to concisely convey meta-data 3.2 container isobjects, based foron generating,example a buildingsharing, oretc., a mechanicalmodel files, notdevice just drawings. Drawings are produced when the model is complete, correct and named persistent set of data within a file system or application data NOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D), 3.2 container consistent. namedstorage persistent hierarchy setincluding, of data butwithin not ali mitedfile system to, directory, or application sub-directory, data and can include graphical as well as non-graphical content. This standard storagedata file, hierarchy or distinct including, sub-set ofbut a notdata li mitedfile, such to, directory,as a chapter sub-directory, or section, NOTEis based 2 on Models generating, can include sharing, information etc., model by files, reference. not just drawings. Drawings are produced when the model is complete, correct and datalayers file, or orsymbol distinct sub-set of a data file, such as a chapter or section, NOTE 3 Information Models are a collective of 3D Models, 3.11 originatorconsistent. Information/Data, (non-graphical), documents, drawings and any other NOTElayers 1or symbol “Named containers” is the common pattern on structured agent responsible for production of a container NOTEinformation 2 Models needed can to deliver include the informationproject. by reference. information for design and management. The actual implementation of NOTE 1 “Named containers” is the common pattern on structured NOTE See Clause 7. information“named containers” for design might and be management. different in different The actual operating implementation systems and of 3.11 originator “namedproprietary containers” file formats. might The be differen“named tcontainer” in different pattern operating is, however, systems and 3.12 sub-modelagent responsible for production of a container proprietarydistinct in that file a formats. single name The “named is associated container” to a collection. pattern is, The however, principles model included as an instance in another model distinctof this standard in that a ca singlen be appliedname is independassociatedently to a of collection. the actual The principles NOTE See Clause 7. ofimplementation this standard caof nthe be “named applied container” independently pattern. of the actual 3.12 sub-model implementation of the “named container” pattern. NOTE 2 Directories include sub-directories and folders. model included as an instance in another model NOTE 32 Files FilesDirectories include include models,include models, sub-models, sub-directories sub-mode ls, sheets,data, and folders. docume sheets, nts,documents, tables and NOTEschedules.tables and 3 FilesFilesschedules. include include models, models, sub-models, sub-mode ls, sheets,data, docume sheets, nts,documents, tables and NOTEschedules.tables and 4 schedules. Containers within files include layers, sections and symbols. NOTE 4 Containers within files include layers, sections and symbols. 3.3 conventional Cartesian axis 3.3 conventionalgeometric convention Cartesian using positiveaxis co-ordinates (X, Y, Z) ordered as geometric(East, North, convention upwards), using so that positive conventional co-ordinates plans (X, use Y, X, Z) Y; ordered and Z isas (East,upwards North, upwards), so that conventional plans use X, Y; and Z is upwards

2 • ©© BSIThe 2007 British Standards Institution 2015 2 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution© BSI 2015 2007 • • 3

© BSI 2007 • 3 BS 1192:20071192:2007+A1:2015 BS 1192:20071192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007

NOTE 1 The standard is an alternative where the formal meta-data NOTErecommendations 1 The standard as provided is an altern in BSative EN 82045-2 where the and fo ISOrmal 82045-5 meta-data cannot 3.4 document BS 1192:2007 recommendationsbe used because of asthe provided absence inof BSa compliant EN 82045-2 and and common ISO 82045-5 document cannot container for persistent information that can be managed and repository within an organization or project team. be used because of the absence of a compliant and common document interchanged as a unit NOTErepository 2 This within standard an organization does not give or guprojectidance team. on the use of different data 3.4[BS document EN 82045-1, ISO/IEC 8613-1, 3.2.3 modified] NOTEexchange 2 Thisfile formats, standard the does exchange not give of gu non-graphicidance on the data, use ofstructuring different data nor container for persistent information that can be managed and the exchange of data held as object classes and their instances nor the data exchange file formats, the exchange of non-graphic data, structuring nor 3.5interchanged drawing as a unit thestructuring exchange appropriate of data held to as speciali object classesst engineering and their analyses, instances nor nor the the data document used to present graphic information structuringdefinition and appropriate use of data to heldspeciali as instancest engineering parameters. analyses, nor the [BS EN 82045-1, ISO/IEC 8613-1, 3.2.3 modified] definition and use of data held as instance parameters. 3.53.6 fielddrawing 2 Normative references documentpart of a container used to pres nameent reserved graphic forinformation meta-data 2 Normative references NOTE The standard controls the usage of fields for naming containers The following referenced documents are indispensable for the 3.6 fieldand codes used in those fields. Theapplication following of referencedthis document. docume For ntsdated are references, indispensable only for the the edition part of a container name reserved for meta-data 3.7 instance applicationcited applies. of Forthis undateddocument. refere Fornces, dated the references, latest edition only of the the edition NOTE The standard controls the usage of fields for naming containers occurrence of an entity at a particular location and orientation within a citedreferenced applies. document For undated (inclu refereding nces,any amendments) the latest edition applies. of the and codes used in those fields. referenced document (including any amendments) applies. model BS ISO 12006-2:2001, Building construction – Organization of 3.7 instance BSinformation ISO 12006-2:2001, about construction Building construction works – Part – 2: Organization Framework offor 3.8occurrence layer of an entity at a particular location and orientation within a informationclassification about of information construction works – Part 2: Framework for modelcontainer comprising selected entities, typically used to group for NOTEclassification The implementation of information of BS ISO 12006-2 in the UK is published purposes of selective display, printing and management operations 3.8 layer NOTEunder the The name implementation “Uniclass". of BS ISO 12006-2 in the UK is published 3.9 meta-data under the name “Uniclass". container comprising selected entities, typically used to group for purposesdata used offor selective the description display, and printing management and management of documents operations and other 3 Terms and definitions containers of information 3 Terms and definitions 3.9NOTE meta-data Each item of meta-data resides in a field. Codes are the values For the purposes of this British Standard, the following terms and alloweddata used for for fields. the description and management of documents and other Fordefinitions the purposes apply. of this British Standard, the following terms and containers of information definitions apply. 3.10 model NOTE Each item of meta-data resides in a field. Codes are the values 3.1 code collection of containers organized to represent the physical parts of allowed for fields. 3.1 codesequence of characters, often a mnemonic, having defined meaning objects, for example a building or a mechanical device sequencewhen interpreted of characters, in the contextoften a mnemonic,of the field inhaving which defined it is entered, meaning used 3.10 modelNOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D), whento concisely interpreted convey in meta-datathe context of the field in which it is entered, used andcollection can include of containers graphical organized as well as to non-graphical represent the conten physicalt. This parts standard of to concisely convey meta-data 3.2 container isobjects, based foron generating,example a buildingsharing, oretc., a mechanicalmodel files, notdevice just drawings. Drawings are produced when the model is complete, correct and named persistent set of data within a file system or application data NOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D), 3.2 container consistent. namedstorage persistent hierarchy setincluding, of data butwithin not ali mitedfile system to, directory, or application sub-directory, data and can include graphical as well as non-graphical content. This standard storagedata file, hierarchy or distinct including, sub-set ofbut a notdata li mitedfile, such to, directory,as a chapter sub-directory, or section, NOTEis based 2 on Models generating, can include sharing, information etc., model by files, reference. not just drawings. Drawings are produced when the model is complete, correct and datalayers file, or orsymbol distinct sub-set of a data file, such as a chapter or section, NOTE 3 Information Models are a collective of 3D Models, 3.11 originatorconsistent. Information/Data, (non-graphical), documents, drawings and any other NOTElayers 1or symbol “Named containers” is the common pattern on structured agent responsible for production of a container NOTEinformation 2 Models needed can to deliver include the informationproject. by reference. information for design and management. The actual implementation of NOTE 1 “Named containers” is the common pattern on structured NOTE See Clause 7. information“named containers” for design might and be management. different in different The actual operating implementation systems and of 3.11 originator “namedproprietary containers” file formats. might The be differen“named tcontainer” in different pattern operating is, however, systems and 3.12 sub-modelagent responsible for production of a container proprietarydistinct in that file a formats. single name The “named is associated container” to a collection. pattern is, The however, principles model included as an instance in another model distinctof this standard in that a ca singlen be appliedname is independassociatedently to a of collection. the actual The principles NOTE See Clause 7. ofimplementation this standard caof nthe be “named applied container” independently pattern. of the actual 3.12 sub-model implementation of the “named container” pattern. NOTE 2 Directories include sub-directories and folders. model included as an instance in another model NOTE 32 Files FilesDirectories include include models,include models, sub-models, sub-directories sub-mode ls, sheets,data, and folders. docume sheets, nts,documents, tables and NOTEschedules.tables and 3 FilesFilesschedules. include include models, models, sub-models, sub-mode ls, sheets,data, docume sheets, nts,documents, tables and NOTEschedules.tables and 4 schedules. Containers within files include layers, sections and symbols. NOTE 4 Containers within files include layers, sections and symbols. 3.3 conventional Cartesian axis 3.3 conventionalgeometric convention Cartesian using positiveaxis co-ordinates (X, Y, Z) ordered as geometric(East, North, convention upwards), using so that positive conventional co-ordinates plans (X, use Y, X, Z) Y; ordered and Z isas (East,upwards North, upwards), so that conventional plans use X, Y; and Z is upwards

2 • ©© BSIThe 2007 British Standards Institution 2015 2 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution© BSI 20152016 2007 • • 3

© BSI 2007 • 3 BS 1192:2007

4 Collaboration management processes

BS 1192:20071192:2007+A1:20151192:2007+A2:20164.1 Process considerations BS 1192:2007+A1:2015BS 1192:2007 BS 1192:2007 4.1.1 Standard method and procedure 4 CollaborationProjects should follow a common management set of generic processes processes at the highest 4.2 Process and the Common Data Environment level, which are fine-tuned on a project-by-project basis. The 4.2 (CDE)Process and the Common Data Environment procedures outlined apply to all approaches to project design 4.1 Process considerations (CDE) production, including: 4.2.1 Outline of a Common Data Environment • co-ordination of the project model files (2D and 3D) as they 4.2.1 Outline of a Common Data Environment 4.1.1 Standard method and procedure NOTE 1 There are four phases of the CDE as illustrated in Figure 1. develop; NOTE 1 There are four phases of the CDE as illustrated in Figure 1. Projects shouldshould followfollow a a common common set set of of generic generic processes processes at at the the highest highest Information, once prepared, should be placed into the level,• whichwhich production areare fine-tuned fine-tuned of 2D on drawingson a aproject-by-project project-by-project from 2D and basis. 3D basis. models; The The procedures and WORK-IN-PROGRESSInformation, once prepared, (WIP) sh(seeould 4.2.2 be placed) area andinto passedthe through the proceduresoutlined• apply production outlined to all approaches ofapply 2D drawingsto al lto approaches project using design 2D to CAD projectproduction, draughting design  and modelWORK-IN-PROGRESS in an anti-clockwise (WIP) directio (see 4.2.2n through) area the and phases passed of through its life. the  model in an anti-clockwise direction through the phases of its life. production,co-ordinationsoftware. including: of the information model. NOTE 2 The naming, numbering and identification of all data held in • co-ordination of the project model files (2D and 3D) as they NOTEthe CDE 2 are The defined naming, in numberingClause 5. and identification of all data held in 4.1.2 General project issues develop; Keythe CDE to the are processprocess defined isis in thethe Clause management management 5. of of moving moving the the data data between between each each The •project production “standard of method 2D drawings and procedure” from 2D and should 3D models; be agreed and and Keyof the to four the processphases (see is the 4.2.24.2.2 management,, 4.2.34.2.3, ,4.2.4 4.2.4 of movingand and 4.2.5 4.2.5 the),), itda it is tais here herebetween that that vital eachvital committed to by all the relevant parties involved in the project (e.g. the checking,of the four approving approvingphases (see  and 4.2.2, authorizing issu, 4.2.3ing processes, and4.2.4 accepting and are 4.2.5 executed.), processesit is here that are vital client,• design production consultants, of 2D drawingssupply chain using partners, 2D CAD etc.) draughting at the pre- checking,executed. approving and issuing processes are executed. constructionsoftware. contract stage in the project lifecycle. 4.2.2 WORK-IN-PROGRESS 4.2.2 WORK-IN-PROGRESS 4.1.2 ToGeneral implement project the “standard issues method and procedure” the following The WIP area of the CDE (see Figure 2) is where members of the project elements should be in place: teamThe WIP carry area out of their the CDE own (seework Figure using 2)their is where organization’s members softwareof the project The project “standard method and procedure” should be agreed and • Roles and responsibilities should be agreed, in particular the systems.team carry Whether out their the own common work repositousing theirry or organization’s an organization’s software in-house committed to by all the relevant parties involved in the project (e.g. the repositorysystems. Whether is used, the the common models andreposito documentsry or an should organization’s employ ain-house similar client, designresponsibility consultants, for designsupply co-ordchain partners,ination of etc.)the various at the pre- design disciplines. managementrepository is used,process the as models that used and fordocuments the total shouldproject. employ a similar construction contract stage in the project lifecycle. management process as that used for the total project. The organization is responsible for the quality of the WIP information To implement• Naming the conventions “standard method should andbe adopted procedure” according the following to Clauses 5 to 15. andThe shouldorganization ensure is that responsible appropriate for thechecking quality and of thereview WIP processes information are elements should be in place: inand place. should ensure that appropriate checking and review processes are • ArrangementsRoles and responsibilities should be in should place beto createagreed, and in particularmaintain the the in place. project specific codes as described in 6.3 to 15.4.3 and NOTE 1 Each model file only contains information for which each design responsibility for design co-ordination of the various design NOTEteam is 1 responsible.Each Each model model  fileText only deleted contains onlyinformation contains informationfor which each for which design disciplines.project spatial co-ordination as described in Annex A.   NOTEteameach is 2 responsible.task The organization team is responsible. also includes work package subcontractors “ • ANaming Common conventions Data Environment” should be adopted (CDE) approachaccording should to be NOTEwho develop 2 The design organization based on also consulta includesnts’ design,work package where contractssubcontractors require Clausesadopted 5to to allow 15. information to be shared between all whothis specificdevelop approach.design based on consultants’ design, where contracts require members of the project team (see 4.2). This is a repository, for Thethis specificdata continues approach. to be updated in the WIP area and should be indexed • Arrangementsexample a project should extranet be in orpla electronicce to create document and maintain the toThe indicate data continues minor version toto bebe updatedupdated changes, in in e.the theg. WIPP02.1,WIP area area etc., and and until  shouldoptions next be published indexed projectmanagement specific system. codes as described in 6.3 to 15.4.3 and project spatial co-ordination as described in Annex A. toshould indicatethe SHAREDbe indexed minor area versionto indicate (see changes,4.2.3 minor). e.versiong. P02.1, changes, etc., untile.g. nextP02.01 published, • A suitable information hierarchy should be agreed that toetc. the  SHAREDText deleted area (see 4.2.3). • Asupports “Common the Dataconcepts Environment” of the CDE (C andDE) the approach document should be repositoryadopted to asallow indicated information in 5.4.2 to. be shared between all members of the project team (see 4.2). This is a repository, for example a project extranet or electronic document management system. • A suitable information hierarchy should be agreed that supports the concepts of the CDE and the document repository as indicated in 5.4.2.

4 • © BSI 2007

4 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution© BSI 2015 2007 • • 5 © BSI 2007 • 5 BS 1192:2007

4 Collaboration management processes

BS 1192:20071192:2007+A1:20154.1 Process considerations BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007 BS 1192:2007 4.1.1 Standard method and procedure 4 CollaborationProjects should follow a common management set of generic processes processes at the highest 4.2 Process and the Common Data Environment level, which are fine-tuned on a project-by-project basis. The 4.2 (CDE)Process and the Common Data Environment procedures outlined apply to all approaches to project design 4.1 Process considerations (CDE) production, including: 4.2.1 Outline of a Common Data Environment • co-ordination of the project model files (2D and 3D) as they 4.2.1 Outline of a Common Data Environment 4.1.1 Standard method and procedure NOTE 1 There are four phases of the CDE as illustrated in Figure 1. develop; NOTE 1 There are four phases of the CDE as illustrated in Figure 1. Projects shouldshould followfollow a a common common set set of of generic generic processes processes at at the the highest highest Information, once prepared, should be placed into the level,• whichwhich production areare fine-tuned fine-tuned of 2D on drawingson a aproject-by-project project-by-project from 2D and basis. 3D basis. models; The The procedures and WORK-IN-PROGRESSInformation, once prepared, (WIP) sh(seeould 4.2.2 be placed) area andinto passedthe through the proceduresoutlined• apply production outlined to all approaches ofapply 2D drawingsto al lto approaches project using design 2D to CAD projectproduction, draughting design  and modelWORK-IN-PROGRESS in an anti-clockwise (WIP) directio (see 4.2.2n through) area the and phases passed of through its life. the  model in an anti-clockwise direction through the phases of its life. production,co-ordinationsoftware. including: of the information model. NOTE 2 The naming, numbering and identification of all data held in • co-ordination of the project model files (2D and 3D) as they NOTEthe CDE 2 are The defined naming, in numberingClause 5. and identification of all data held in 4.1.2 General project issues develop; Keythe CDE to the are processprocess defined isis in thethe Clause management management 5. of of moving moving the the data data between between each each The •project production “standard of method 2D drawings and procedure” from 2D and should 3D models; be agreed and and Keyof the to four the processphases (see is the 4.2.24.2.2 management,, 4.2.34.2.3, ,4.2.4 4.2.4 of movingand and 4.2.5 4.2.5 the),), itda it is tais here herebetween that that vital eachvital committed to by all the relevant parties involved in the project (e.g. the checking,of the four approving approvingphases (see  and 4.2.2, authorizing issu, 4.2.3ing processes, and4.2.4 accepting and are 4.2.5 executed.), processesit is here that are vital client,• design production consultants, of 2D drawingssupply chain using partners, 2D CAD etc.) draughting at the pre- checking,executed. approving and issuing processes are executed. constructionsoftware. contract stage in the project lifecycle. 4.2.2 WORK-IN-PROGRESS 4.2.2 WORK-IN-PROGRESS 4.1.2 GeneralTo implement project the “standard issues method and procedure” the following The WIP area of the CDE (see Figure 2) is where members of the project elements should be in place: teamThe WIP carry area out of their the CDE own (seework Figure using 2)their is where organization’s members softwareof the project The project “standard method and procedure” should be agreed and • Roles and responsibilities should be agreed, in particular the systems.team carry Whether out their the own common work repositousing theirry or organization’s an organization’s software in-house committed to by all the relevant parties involved in the project (e.g. the repositorysystems. Whether is used, the the common models andreposito documentsry or an should organization’s employ ain-house similar client, designresponsibility consultants, for designsupply co-ordchain partners,ination of etc.)the various at the pre- design disciplines. managementrepository is used,process the as models that used and fordocuments the total shouldproject. employ a similar construction contract stage in the project lifecycle. management process as that used for the total project. The organization is responsible for the quality of the WIP information To implement• Naming the conventions “standard method should andbe adopted procedure” according the following to Clauses 5 to 15. andThe shouldorganization ensure is that responsible appropriate for thechecking quality and of thereview WIP processes information are elements should be in place: inand place. should ensure that appropriate checking and review processes are • ArrangementsRoles and responsibilities should be in should place beto createagreed, and in particularmaintain the the in place. project specific codes as described in 6.3 to 15.4.3 and NOTE 1 Each model file only contains information for which each design responsibility for design co-ordination of the various design NOTEteam is 1 responsible.Each Each model model  fileTexttext only deleted deleted contains only onlyinformation contains contains information informationfor which each for for which which design disciplines.project spatial co-ordination as described in Annex A.   NOTEteameach is 2 responsible.task The organization team is responsible. also includes work package subcontractors “ • ANaming Common conventions Data Environment” should be adopted (CDE) approachaccording should to be NOTEwho develop 2 The design organization based on also consulta includesnts’ design,work package where contractssubcontractors require Clausesadopted 5to to allow 15. information to be shared between all whothis specificdevelop approach.design based on consultants’ design, where contracts require members of the project team (see 4.2). This is a repository, for Thethis specificdata continues approach. to be updated in the WIP area and should be indexed • Arrangementsexample a project should extranet be in orpla electronicce to create document and maintain the toThe indicate data continues minor version toto bebe updatedupdated changes, in in e.the theg. WIPP02.1,WIP area area etc., and and until  shouldoptions next be published indexed projectmanagement specific system. codes as described in 6.3 to 15.4.3 and project spatial co-ordination as described in Annex A. toshould indicatethe SHAREDbe indexed minor area versionto indicate (see changes,4.2.3 minor). e.versiong. P02.1, changes, etc., untile.g. nextP02.01 published, • A suitable information hierarchy should be agreed that toetc. the  SHAREDText deleted area (see 4.2.3). • Asupports “Common the Dataconcepts Environment” of the CDE (C andDE) the approach document should be repositoryadopted to asallow indicated information in 5.4.2 to. be shared between all members of the project team (see 4.2). This is a repository, for example a project extranet or electronic document management system. • A suitable information hierarchy should be agreed that supports the concepts of the CDE and the document repository as indicated in 5.4.2.

4 • © BSI 2007

4 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution© BSI 20152016 2007 • • 5 © BSI 2007 • 5 BS 1192:20071192:2007+A1:20151192:2007+A2:2016 BS 1192:2007+A1:2015BS 1192:2007 BS 1192:2007+A1:2015BS 1192:2007

Figure 1 Document and data management repository FigureFigure 2 WORK-IN-PROGRESS (WIP) (WIP) and and  issueshare process process for architectsfor modelarchitects model FigureFigure 2 WORK-IN-PROGRESS (WIP) (WIP) and and  issueshare process process for architectsfor  modelarchitects model CLIENT SHARED AREA  ARCHITECTURE WIP SHARED WORK IN PROGRESS  ARCHITECTURE WIP SUITABILITY VERSION Verified design data shared with the Non-verified design data used by SUITABILITY VERSION project team: in-house design team only: ARCH. Ongoing design development GRID S0 P01.1 ARCH. ARCH. GRID S0 P01.1 WALLS S0 P01.1 ARCH. ARCH. WALLS S0 P01.1 COLUMNS S0 P01.1

Check, Review, Approve ARCH. SUITABILITY VER Pnn.n COLUMNS S0 P01.1 Check, Review, Approve S0 SUITABILITY REVISION Check, Review, Approve S1 Pnn Task Team 1

CLIENT SHARED AREA Task Team 2  Task Team 3  Clients Authorization 4.2.3 SHARED 4.2.3 SHAREDWhen thethe datadata isis SHAREDSHARED with with the the other other members members of of the the project project team, team, the datadata isis checkedchecked and and  issuedText todeleted the CDE theand revision the revision code iscode updated is When thethe datadata isis SHAREDSHARED with with the the other other members members of of the the project project team, team, updatedto indicate to a indicate major revision, a major e.g. revision, P01. e.g. P01. the datadata isis checkedchecked and and  issuedText todeleted the CDE theand revision the revision code iscode updated is updatedWhento indicate aa model modelto a indicate major has has reached revision,reached a major a e.g. astatusrevision, status P01. that that e.g. is is“ P01. “fitsuitable for co-ordination” for it PUBLISHED shouldco-ordination” be uploaded it should to thebe SHAREDmade available area of thein CDE the asSHARED illustrated area in of ARCHIVE When aa modelmodel has has reached reached a astatus status that that is is“ “fitsuitable for co-ordination” for it DOCUMENTATION Figurethe CDE 3. as illustrated in Figure 3. shouldco-ordination” be uploaded it should to thebe SHAREDmade available area of thein CDE the asSHARED illustrated area in of Coordination and validated design Project history maintained for NOTEthe CDE 1 as The illustrated SHARED in area Figure ensures: 3. output for use by the total project Figure 3. knowledge and regulatory and • sharing of data in a well-defined context; team. legal requirements. NOTE 1 The SHARED area ensures: Production information sutable for Repository of the project • sharinga secure of safe data space in a to well-defined allow constructive context; sharing; Stage Completion information for non asset • non-adversarial working; Acceptance or Construction: • a secure safe space to allow constructive sharing; VERIFIED portfolio employers. • non-adversarialsupports the generation working; of spatially co-ordinated data as part of the development process. • supports the generation of spatially co-ordinated data as part of NOTE 2the The development model is now process. available to be shared by the whole project SUITABILITY REVISION team. An Cnn NOTE 2 The model is now available to be shared by the whole project team.Before uploadinguploading to to the the SHARED SHARED area, area a, amodel model should should be be reviewed reviewed and checkedand checked according according to compto complianceliance requirements requirements in in order order to to be be fit for a CLIENT SHARED AREA Before uploadinguploading to to the the SHARED SHARED area, area a, amodel model should should be be reviewed reviewed and specificsuitable purpose. for Thea specific informatio purpose.n should The information also be checked should for also be checkedand checked according according to compto complianceliance requirements requirements in in order order to to be be fit for a conformitychecked for toconformity Annex B. to Annex B. specificsuitable purpose. for Thea specific informatio purpose.n should The information also be checked should for also be NOTE The suffices for the A and B suitabilities refer to the stages. conformityThechecked “issue” for tostatusconformity Annex should B. to Annexbe used B. to identify the suitability of the information provided. The “suitability” code (see 15.2.2) gives The “issue” status should be used to identify the suitability of the ownership to the design teams and restricts access by others until information provided. The “suitability” code (see 15.2.2) gives information is sufficiently developed, co-ordinated, approved and ownership to the design teams and restricts access by others until authorized. information is sufficiently developed, co-ordinated, approved and authorized.NOTE 3 The suitability codes are distinct from the client/construction authorization status and from the contractors work packages purpose of issue.NOTE 3 The suitability codes are distinct from the client/construction authorization status and from the contractors work packages purpose of issue.The data sharedshared with with status status “ “FitSuitable for Co-ordination” for Co-ordination” should be should in the be changeablein the changeable formats. formats. All information All information having having a different a different status status should should be The data sharedshared with with status status “ “FitSuitable for Co-ordination” for Co-ordination” should be should in the be producedbe produced as asdocuments documents in in non-changeable non-changeable formats. formats. changeablein the changeable formats. formats. All information All information having having a different a different status status should should be producedbe produced as asdocuments documents in in non-changeable non-changeable formats. formats.

6 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution© BSI 2015 2007 • • 7

© The British Standards Institution© BSI 2015 2007 • • 7 BS 1192:20071192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007 BS 1192:2007+A1:2015BS 1192:2007

Figure 1 Document and data management repository FigureFigure 2 WORK-IN-PROGRESS (WIP) (WIP) and and  issueshare process process for architectsfor modelarchitects model FigureFigure 2 WORK-IN-PROGRESS (WIP) (WIP) and and  issueshare process process for architectsfor  modelarchitects model CLIENT SHARED AREA  ARCHITECTURE WIP SHARED WORK IN PROGRESS  ARCHITECTURE WIP SUITABILITY VERSION Verified design data shared with the Non-verified design data used by SUITABILITY VERSION project team: in-house design team only: ARCH. Ongoing design development GRID S0 P01.1 ARCH. ARCH. GRID S0 P01.1 WALLS S0 P01.1 ARCH. ARCH. WALLS S0 P01.1 COLUMNS S0 P01.1

Check, Review, Approve Check, Review, Approve ARCH. SUITABILITY VER Pnn.n COLUMNS S0 P01.1 Check, Review, Approve S0 SUITABILITY REVISION Check, Review, Approve S1 Pnn Task Team 1

CLIENT SHARED AREA Task Team 2  Task Team 3  Clients Authorization 4.2.3 SHARED 4.2.3 SHAREDWhen thethe datadata isis SHAREDSHARED with with the the other other members members of of the the project project team, team, the datadata isis checkedchecked and and  issuedTexttext deletedtodeleted the CDE the theand revisionrevision the revision codecode isiscode updatedupdated is When thethe datadata isis SHAREDSHARED with with the the other other members members of of the the project project team, team, updatedto indicate to a indicate major revision, a major e.g. revision, P01. e.g. P01. the datadata isis checkedchecked and and  issuedText todeleted the CDE theand revision the revision code iscode updated is updatedWhento indicate aa model modelto a indicate major has has reached revision,reached a major a e.g. astatusrevision, status P01. that that e.g. is is“ P01. “fitsuitable for co-ordination” for it PUBLISHED shouldco-ordination” be uploaded it should to thebe SHAREDmade available area of thein CDE the asSHARED illustrated area in of ARCHIVE When aa modelmodel has has reached reached a astatus status that that is is“ “fitsuitable for co-ordination” for it DOCUMENTATION Figurethe CDE 3. as illustrated in Figure 3. shouldco-ordination” be uploaded it should to thebe SHAREDmade available area of thein CDE the asSHARED illustrated area in of Coordination and validated design Project history maintained for NOTEthe CDE 1 as The illustrated SHARED in area Figure ensures: 3. output for use by the total project Figure 3. knowledge and regulatory and • sharing of data in a well-defined context; team. legal requirements. NOTE 1 The SHARED area ensures: Production information sutable for Repository of the project • sharinga secure of safe data space in a to well-defined allow constructive context; sharing; Stage Completion information for non asset • non-adversarial working; Acceptance or Construction: • a secure safe space to allow constructive sharing; VERIFIED portfolio employers. • non-adversarialsupports the generation working; of spatially co-ordinated data as part of the development process. • supports the generation of spatially co-ordinated data as part of NOTE 2 The model is now available to be shared by the whole project NOTE 2the The development model is now process. available to be shared by the whole project team. This may be further controlled through the use of a security SUITABILITY REVISION team. An Cnn NOTEaccess list2 as The defined model within is now the available Built Asset to Security be shared Management by the whole Plan project (see team.BeforePAS 1192-5:2015). uploadinguploading to to the the SHARED SHARED area, area a, amodel model should should be be reviewed reviewed and checkedand checked according according to compto complianceliance requirements requirements in in order order to to be be fit for a CLIENT SHARED AREA Before uploadinguploading to to the the SHARED SHARED area, area a, amodel model should should be be reviewed reviewed and specificsuitable purpose. for Thea specific informatio purpose.n should The information also be checked should for also be checkedand checked according according to compto complianceliance requirements requirements in in order order to to be be fit for a conformitychecked for toconformity Annex B. to Annex B. specificsuitable purpose. for Thea specific informatio purpose.n should The information also be checked should for also be NOTE The suffices for the A and B suitabilities refer to the stages. conformityThechecked “issue” for tostatusconformity Annex should B. to Annexbe used B. to identify the suitability of the information provided. The “suitability” code (see 15.2.2) gives The “issue” status should be used to identify the suitability of the ownership to the design teams and restricts access by others until information provided. The “suitability” code (see 15.2.2) gives information is sufficiently developed, co-ordinated, approved and ownership to the design teams and restricts access by others until authorized. information is sufficiently developed, co-ordinated, approved and authorized.NOTE 3 The suitability codes are distinct from the client/construction authorization status and from the contractors work packages purpose of issue.NOTE 3 The suitability codes are distinct from the client/construction authorization status and from the contractors work packages purpose of issue.The data sharedshared with with status status “ “FitSuitable for Co-ordination” for Co-ordination” should be should in the be changeablein the changeable formats. formats. All information All information having having a different a different status status should should be The data sharedshared with with status status “ “FitSuitable for Co-ordination” for Co-ordination” should be should in the be producedbe produced as asdocuments documents in in non-changeable non-changeable formats. formats. changeablein the changeable formats. formats. All information All information having having a different a different status status should should be producedbe produced as asdocuments documents in in non-changeable non-changeable formats. formats.

6 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution© BSI 20152016 2007 • • 7

© The British Standards Institution© BSI 2015 2007 • • 7 BS 1192:2007

Models that are downloaded by others (see Figure 4), should never be re-uploaded to the SHARED area. When a model is used as background information by others (see Figure 5), it is important to ensure that this does not result in information in models being duplicated. Therefore, a procedure should be agreed that ensures information occurs only once in the SHARED area (see Figure 6).

Figure 3 Architects model uploaded from WIP for sharing

Architecture models checked, reviewed and approved within an internal review process and uploaded to the SHARED area. The WIP model version is changed to a revision. The models suitability is moved to “fit for purpose”. In this example that is S1 “fit for co-ordination”. NOTE Any member of the project team can use the shared model files for reference or co-ordination. Other design team members can download the latest versions of models from the SHARED area of the CDE as shown in Figure 4. These download models can be used as background information onto which the recipient can BS 1192:20071192:2007+A1:20151192:2007+A2:2016 overlay their design information. BS 1192:2007+A1:2015

Models that are downloaded by others (see Figure 4), should never be FigureFigure 4 ArchitectsArchitect’s models SHARED uploaded models to referenced another disciplines to Structures WIP WIP area area re-uploaded to the SHARED area. When a model is used as background information by others (see Figure 5), it is important to ensure that this does not result in information in models being duplicated. Therefore, a procedure should be agreed that ensures information occurs only once in the SHARED area (see Figure 6).

Figure 3 Architects model uploaded from WIP for sharing

 SHARED ARCHITECTURE WIP

SUITABILITY REVISION SUITABILITY VERSION

ARCH. ARCH. GRID S1 P01 GRID S0 P01.1

ARCH. ARCH. WALLS S1 P01 WALLS S0 P01.1

ARCH. ARCH. COLUMNS S1 P01 WIP to SHARED COLUMNS S0 P01.1 BS 1192:2007 Check, Review, Approve

Figure 5 Structures co-ordinates its model files using the architecture 8 • © BSI 2007  files as a reference

Architecture models checked, reviewed and approved within an internal review process and uploaded to the ArchitectureSHARED area. models checked, reviewed and approved within an internal review process and uploaded to the SHARED area. The WIP model version is changed to a revision. The WIP model version is changed to a revision.   The models suitabilitysuitability is is moved moved to to “ “fitsuitable for purpose”. for purpose”. In this exampleexample that that is is S1 S1 “ “fit suitablefor co-ordination”. for co-ordination”. NOTE Any Any member member of of the the project project team team can canuse theuse shared the shar modeled model files for files reference for reference or co-ordination. or co-ordination. Other design Other designteam members team members can reference can download the latest the latest versions versions of models of models from the from SHARED the SHARED area of areathe CDE of the as CDEshown as in shown   inFigure Figure 4. These 4. These reference download modelsmodels cancan be be used used as as background background information information onto whichonto which the recipient the recipient can overlay can   overlaytheir design their information. design information. This produces a clash avoidance process.

Only graphical models approved, suitable for coordinationco-ordination (S1), (S1), Figure 4 Architectsshould be used models as a reference. uploaded to another disciplines WIP area

NOTE In In thethe example example shown shown in inFigure Figure 5, the 5, structuralthe structural engineer engineer has designed has desi thegned structural the structural member sizesmember and sizes takesand takesownership ownership of the structural of the structural column columnmodel layer.. When Wh enthe the structural structural engineer engineer uploads uploads this information this information into theinto SHARED the SHARED area thearea architect’s the architect’s file is revised file is and revised re-shared and tore-shared remove the to architecturalremove the architecturalownership of the ownership columns. of the Althoughcolumns. the finishes are still owned by the architect.

4.2.4 DOCUMENTATION Before information in in the the SHARED SHARED area area of of the the CDE CDE is is made made available available to theto the wider wider project project team, team, for for example example for for tender tender or or construction, construction, it it should beshould formally be formally checked, checked, approved approved and authorized and authorized (Figure (Figure 7). Suitable 7). Suitable checking andand approvalsapprovals processes processes should should be be defined defined and and applied. applied. These shouldNOTE apply See to PAS consultants 1192-2 for anda definition subcontractors’ of a plan of documents. work with stages. OnceThe sign the off document processes has should been allow approved for sign and off authorized, at the end of it eachpasses stage. to the contractor for “Action” and the revision changes from “Preliminary” to These should apply to all consultants and subcontractors’ documents. “Construction” (see 15.2.3).

8 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution 2015 • 9

© BSI 2007 • 9 BS 1192:2007

Models that are downloaded by others (see Figure 4), should never be re-uploaded to the SHARED area. When a model is used as background information by others (see Figure 5), it is important to ensure that this does not result in information in models being duplicated. Therefore, a procedure should be agreed that ensures information occurs only once in the SHARED area (see Figure 6).

Figure 3 Architects model uploaded from WIP for sharing

Architecture models checked, reviewed and approved within an internal review process and uploaded to the SHARED area. The WIP model version is changed to a revision. The models suitability is moved to “fit for purpose”. In this example that is S1 “fit for co-ordination”. NOTE Any member of the project team can use the shared model files for reference or co-ordination. Other design team members can download the latest versions of models from the SHARED area of the CDE as shown in Figure 4. These download models can be used as background information onto which the recipient can BS 1192:20071192:2007+A1:2015 overlay their design information. BS 1192:2007+A1:20151192:2007+A2:2016

Models that are downloaded by others (see Figure 4), should never be FigureFigure 4 ArchitectsArchitect’s models SHARED uploaded models to referenced another disciplines to Structures WIP WIP area area re-uploaded to the SHARED area. When a model is used as background information by others (see Figure 5), it is important to ensure that this does not result in information in models being duplicated. Therefore, a procedure should be agreed that ensures information occurs only once in the SHARED area (see Figure 6).

Figure 3 Architects model uploaded from WIP for sharing

 SHARED ARCHITECTURE WIP

SUITABILITY REVISION SUITABILITY VERSION

ARCH. ARCH. GRID S1 P01 GRID S0 P01.1

ARCH. ARCH. WALLS S1 P01 WALLS S0 P01.1

ARCH. ARCH. COLUMNS S1 P01 WIP to SHARED COLUMNS S0 P01.1 BS 1192:2007 Check, Review, Approve

Figure 5 Structures co-ordinates its model files using the architecture 8 • © BSI 2007  files as a reference

Architecture models checked, reviewed and approved within an internal review process and uploaded to the ArchitectureSHARED area. models checked, reviewed and approved within an internal review process and uploaded to the SHARED area. The WIP model version is changed to a revision. The WIP model version is changed to a revision.   The models suitabilitysuitability is is moved moved to to “ “fitsuitable for purpose”. for purpose”. In this exampleexample that that is is S1 S1 “ “fit suitablefor co-ordination”. for co-ordination”. NOTE Any Any member member of of the the project project team team can canuse theuse shared the shar modeled model files for files reference for reference or co-ordination. or co-ordination. Other design Other designteam members team members can reference can download the latest the latest versions versions of models of models from the from SHARED the SHARED area of areathe CDE of the as CDEshown as in shown   inFigure Figure 4. These 4. These reference download modelsmodels cancan be be used used as as background background information information onto whichonto which the recipient the recipient can overlay can   overlaytheir design their information. design information. This produces a clash avoidance process.

Only graphical models approved, suitable for coordination (S1), Figure 4 Architectsshould be used models as a reference. uploaded to another disciplines WIP area

NOTE In In thethe example example shown shown in inFigure Figure 5, the 5, structuralthe structural engineer engineer has designed has desi thegned structural the structural member sizesmember and sizes takesand takesownership ownership of the structural of the structural column columnmodel layer.. When Wh enthe the structural structural engineer engineer uploads uploads this information this information into theinto SHARED the SHARED area thearea architect’s the architect’s file is revised file is and revised re-shared and tore-shared remove the to architecturalremove the architecturalownership of the ownership columns. of the Althoughcolumns. the finishes are still owned by the architect.

4.2.4 DOCUMENTATION Before information in in the the SHARED SHARED area area of of the the CDE CDE is is made made available available to theto the wider wider project project team, team, for for example example for for tender tender or or construction, construction, it it should beshould formally be formally checked, checked, approved approved and authorized and authorized (Figure (Figure 7). Suitable 7). Suitable checking andand approvalsapprovals processes processes should should be be defined defined and and applied. applied. These shouldNOTE apply See to PAS consultants 1192-2 for anda definition subcontractors’ of a plan of documents. work with stages. OnceThe sign the off document processes has should been allow approved for sign and off authorized, at the end of it eachpasses stage. to the contractor for “Action” and the revision changes from “Preliminary” to These should apply to all consultants and subcontractors’ documents. “Construction” (see 15.2.3).

8 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution 20152016 • 9

© BSI 2007 • 9 BS 1192:2007+A2:20161192:2007+A1:2015 BS 1192:2007+A1:2015BS 1192:2007

Once the document has been approved and authorized, Texttext deleteddeleted BS 1192:2007 the revision changes from “Preliminary” (Pn) to “Contractual” (Cn) (see 15.2.3).

FigureFigure 6 Co-ordinated, reviewed reviewed and and uploaded uploaded models models  issuedshared to the to the SHARED areaarea and and duplicate duplicate  layersinformation removed removed

SHARED STRUCTURES WIP ARCHITECTURE WIP is established nvironment

SUITABILITY REVISION SUITABILITY REV/VER SUITABILITY VERSION ARCH. ARCH. GRID S1 P01 GRID S1 P01

ARCH. ked, reviewed and verified for GRID S0 P01.1 ARCH. ARCH. WALLS S1 P01 WALLS S1 P01 ARCH. WALLS S0 P01.1 ARCH. ARCH. WIP to SHARED COLUMNS S1 P01 ARCH. COLUMNS S1 P01 COLUMNS S0 P01.1 Check Review Approve STRUCT. STRUCT. COLUMNS S1 P01 COLUMNS S0 P01.1 through extractions from model files the SHARED through extractions    reference

a) Structures uploads co-ordinated models to SHARED e engineering data a concurrent design e 

 files from the SHARED area. This is chec SHARED area. files from the

SHARED ARCHITECTURE WIP STRUCTURES WIP

SUITABILITY REVISION SUITABILITY REV/VER SUITABILITY REV/VER .

ARCH. ARCH. ARCH. GRID S1 P02 GRID S0 P02.1 GRID S1 P01  drawings, data and documentation

ARCH. ARCH. ARCH. continual upload and download and upload continual WALLS S1 P02 WALLS S0 P02.1 WALLS S1 P01 

ARCH. tractions from model COLUMNS S1 P01 Text deleted Text Check, Review, Approve STRUCT. STRUCT. STRUCT.

COLUMNS S1 P01 COLUMNS S1 P01 COLUMNS S0 P01.1  blished and blished stored. of shared data, as illustrated in Figure 7. in Figure as illustrated of shared data, for approval in the client authorization area. ARCHITECTURAL of th development continue teams design the

COLUMNS , all disciplines produce REMOVED S0 P01.1    uce drawing through ex through drawing uce b) Change of ownership – Architect downloads, removes their duplicates and resubmits Concurrent activities with activities Concurrent Concurrent activities with continual upload and submitted e drawings to be pu of shared data, as illustrated in Figure 7. of shared data, as illustrated

  Figure 7 or stage completion Figure 7 reference  authorization area.  Once the process has been initiated and design teams continue development of data a concurrent engineering environment is established with At predetermined dates, all disciplines prod predetermined disciplines dates, all At approval in the client the On client allowsauthorization, th NOTE Once the process has been initiated and upload and download with a managed continuous area. This is checked, reviewed and area. This is checked, On authorization, the client allows drawings to be published NOTE managed continuous At predetermined dates At

10 • © The British Standards Institution 20162015 © The British Standards Institution© BSI 20152007 • 1111

10 • © BSI 2007 BS 1192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007

Once the document has been approved and authorized, Text deleted BS 1192:2007 the revision changes from “Preliminary” (Pn) to “Contractual” (Cn) (see 15.2.3).

FigureFigure 6 Co-ordinated, reviewed reviewed and and uploaded uploaded models models  issuedshared to the to the SHARED areaarea and and duplicate duplicate  layersinformation removed removed

SHARED STRUCTURES WIP ARCHITECTURE WIP is established nvironment

SUITABILITY REVISION SUITABILITY REV/VER SUITABILITY VERSION ARCH. ARCH. GRID S1 P01 GRID S1 P01

ARCH. ked, reviewed and verified for GRID S0 P01.1 ARCH. ARCH. WALLS S1 P01 WALLS S1 P01 ARCH. WALLS S0 P01.1 ARCH. ARCH. WIP to SHARED COLUMNS S1 P01 ARCH. COLUMNS S1 P01 COLUMNS S0 P01.1 Check Review Approve STRUCT. STRUCT. COLUMNS S1 P01 COLUMNS S0 P01.1 through extractions from model files the SHARED through extractions    reference

a) Structures uploads co-ordinated models to SHARED e engineering data a concurrent design e 

 files from the SHARED area. This is chec SHARED area. files from the

SHARED ARCHITECTURE WIP STRUCTURES WIP

SUITABILITY REVISION SUITABILITY REV/VER SUITABILITY REV/VER .

ARCH. ARCH. ARCH. GRID S1 P02 GRID S0 P02.1 GRID S1 P01  drawings, data and documentation

ARCH. ARCH. ARCH. continual upload and download and upload continual WALLS S1 P02 WALLS S0 P02.1 WALLS S1 P01 

ARCH. tractions from model COLUMNS S1 P01 Text deleted Text Check, Review, Approve STRUCT. STRUCT. STRUCT.

COLUMNS S1 P01 COLUMNS S1 P01 COLUMNS S0 P01.1  blished and blished stored. of shared data, as illustrated in Figure 7. in Figure as illustrated of shared data, for approval in the client authorization area. ARCHITECTURAL of th development continue teams design the

COLUMNS , all disciplines produce REMOVED S0 P01.1    uce drawing through ex through drawing uce b) Change of ownership – Architect downloads, removes their duplicates and resubmits Concurrent activities with activities Concurrent Concurrent activities with continual upload and submitted e drawings to be pu of shared data, as illustrated in Figure 7. of shared data, as illustrated

  Figure 7 or stage completion Figure 7 reference  authorization area.  Once the process has been initiated and design teams continue development of data a concurrent engineering environment is established with At predetermined dates, all disciplines prod predetermined disciplines dates, all At approval in the client the On client allowsauthorization, th NOTE Once the process has been initiated and upload and download with a managed continuous On authorization, the client allows drawings to be published NOTE managed continuous At predetermined dates At reviewed and area. This is checked,

10 • © The British Standards Institution 2015 © The British Standards Institution© BSI 201520162007 • 1111

10 • © BSI 2007 BS 1192:2007

4.2.5 ARCHIVE BS 1192:20071192:2007+A1:20151192:2007+A2:2016 BS 1192:2007+A1:2015BS 1192:2007 A process should be put in place to enable the continued availability of the ARCHIVE area information (see Figure 9), subsequentBS to1192:2007 the design and construction phases to support the following: Figure 8 Suitability “D” is data or documents not authorized by the client 4.2.5 ARCHIVE • history of the transfer of the project information; 4.2.5 AARCHIVE process should be put in place to enable the continued availability of • change audits; Athe process ARCHIVE should area be information put in place (see to enableFigure 9),the subsequentcontinued availability to the design of theand ARCHIVE construction• asset arearegister; phases information to support (see Figuthe following:re 9), subsequent to the design and construction• models;history of phases the transfer to support of the the project following: information; • changedocuments;history ofaudits; the transfer of the project information; • changelegalasset purposes,register; audits; e.g. Health and Safety file; • models;operationasset register; and maintenance information. NOTE• The documents;models; ARCHIVE area of the CDE is for inactive or superseded material• documents;legalin addition purposes, to the e.g. final Health signed-off and Safety “As Built” file; data and documentation. • operationlegal purposes, and maintenance e.g. Health andinformation. Safety file; Figure 9 Audit trail, data, documents, asset and facility management NOTE• 1 The operationThe ARCHIVE ARCHIVE and area areamaintenance ofof the CDE information. isis for for inactive inactive or orsuperseded superseded material materialinformationin addition in to addition the held final in signed-offto ARCHIVE the final  signed-off“Construction “As Record”.Built” data and NOTE The ARCHIVE area of the CDE is for inactive or superseded documentation. materialNOTE in2 additionFor a serial to clientthe final the ARCHIVEsigned-off may “As Built”be transferred data and into the client’s documentation.Asset Information Model (AIM) for continued maintenance and update. Figure 9 Audit trail, data, documents, asset and facility management Figure 9 Auditinformation trail, data, held documents,in ARCHIVE asset and facility management information held in ARCHIVE

NOTENOTE All All updatesupdates and and  reissuesreshares of any of anydocuments documents or ordrawings drawings are are archivedarchived for for future future auditing auditing and and historicalhistorical records. records.

NOTE Where Where documents documents are are required required by the by construction the construction team for team purposes for purposesother than otherconstruction than construction (e.g. tendering (e or.g. procurement), tendering or at procurement), a time prior to at a timetheir approvalprior to theirfor construction, approval forthe consstatustruction, “D” is used the and status transferred “D” is used to the and transferredPUBLISHED/ to the DOCUMENTATION DOCUMENTATION area area as as illustrated illustrated inin FigureFigure 8 8 (see 15.3.2 15.3.2). ).These These “D” “D” status status documents documents retain retain a preliminary a preliminary revision revision reference reference“ P01-P0 “P1-Pn”.n”.

© BSI 2007 • 13

12 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution© BSI 20152007 • 1313 © BSI 2007 • 13 BS 1192:2007

4.2.5 ARCHIVE BS 1192:20071192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007 A process should be put in place to enable the continued availability of the ARCHIVE area information (see Figure 9), subsequentBS to1192:2007 the design and construction phases to support the following: Figure 8 Suitability “D” is data or documents not authorized by the client 4.2.5 ARCHIVE • history of the transfer of the project information; 4.2.5 AARCHIVE process should be put in place to enable the continued availability of • change audits; Athe process ARCHIVE should area be information put in place (see to enableFigure 9),the subsequentcontinued availability to the design of theand ARCHIVE construction• asset arearegister; phases information to support (see Figuthe following:re 9), subsequent to the design and construction• models;history of phases the transfer to support of the the project following: information; • changedocuments;history ofaudits; the transfer of the project information; • changelegalasset purposes,register; audits; e.g. Health and Safety file; • models;operationasset register; and maintenance information. NOTE• The documents;models; ARCHIVE area of the CDE is for inactive or superseded material• documents;legalin addition purposes, to the e.g. final Health signed-off and Safety “As Built” file; data and documentation. • operationlegal purposes, and maintenance e.g. Health andinformation. Safety file; Figure 9 Audit trail, data, documents, asset and facility management NOTE• 1 The operationThe ARCHIVE ARCHIVE and area areamaintenance ofof the CDE information. isis for for inactive inactive or orsuperseded superseded material materialinformationin addition in to addition the held final in signed-offto ARCHIVE the final  signed-off“Construction “As Record”.Built” data and NOTE The ARCHIVE area of the CDE is for inactive or superseded documentation. materialNOTE in2 additionFor a serial to clientthe final the ARCHIVEsigned-off may “As Built”be transferred data and into the client’s documentation.Asset Information Model (AIM) for continued maintenance and update. Figure 9 Audit trail, data, documents, asset and facility management Figure 9 Auditinformation trail, data, held documents,in ARCHIVE asset and facility management information held in ARCHIVE

NOTENOTE All All updatesupdates and and  reissuesreshares of any of anydocuments documents or ordrawings drawings are are archivedarchived for for future future auditing auditing and and historicalhistorical records. records.

NOTE Where Where documents documents are are required required by the by construction the construction team for team purposes for purposesother than otherconstruction than construction (e.g. tendering (e or.g. procurement), tendering or at procurement), a time prior to at a timetheir approvalprior to theirfor construction, approval forthe consstatustruction, “D” is used the and status transferred “D” is used to the and transferredPUBLISHED/ to the DOCUMENTATION DOCUMENTATION area area as as illustrated illustrated inin FigureFigure 8 8 (see 15.3.2 15.3.2). ).These These “D” “D” status status documents documents retain retain a preliminary a preliminary revision revision reference reference“ P01-P0 “P1-Pn”.n”.

© BSI 2007 • 13

12 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution© BSI 201520162007 • 1313 © BSI 2007 • 13 BS 1192:20071192:2007+A1:20151192:2007+A2:2016 BS 1192:2007+A1:2015BS 1192:2007 BS 1192:2007 5 Naming of containers 5.4 Naming of containers 5.4 Naming of containers 5.4.1 Patterns for naming containers 5.1 Structure of names 5.4.1 NamesPatterns for containers for naming should containers be created according to three patterns: NOTE 1 Different containers have different fields joined together but Names for containers should be created according to three patterns: otherwise use the same conventions. a) directories and folders (see 5.4.2); or Names for containers should be created by joining together codes in the b)a) filesdirectories (see 5.4.3 and); folders or (see 5.4.2); or specified fields, in the specified order, using only the “-” hyphen c)b) filescontainers (see 5.4.3 within); or files including layers (see 5.4.4). character, which is therefore not allowed in any code. c) containers within files including layers (see 5.4.4). NOTE 2 Any “description” (see Clause 14) is appended following an 5.4.2 Directories and folders underscore “_”. 5.4.2 Directories should and be folderstransmitted and stored in repositories with names NOTE 3 The hyphen character may be used in a description field but this Directoriescomposed by should joining be thetransmitted one mandat andory stored and intwo repositories optional fields with namesgiven is deprecated. composedin Table 1. byAn joining example the is one given mandat in 5.5ory. and two optional fields given NOTEin TableImplementations 1. An example is might given introduce in 5.5. intermediate sub-directories 5.2 Assigning codes NOTEbased on Implementations fields present in mightthe file introduce naming specifiedintermediate in 5.4.3 sub-directories. Containers should have codes assigned for each of the specified fields. based on fields present in the file naming specified in 5.4.3. Table 1 Naming of directories and folder containers NOTE The codes for fields are defined in Clauses 6 to 15. Table 1 Naming of directories and folder containers Field Obligation Clause Any container having more than one dominant code for any single field Field Obligation Clause should be sub-divided. Project Required 6 SuitabilityProject A) RequiredOptional 615.3.2 5.3 Codes SuitabilityRevision A) A) Optional 15.3.315.3.2 A)RevisionIf information A) passes throughOptional an environment that cannot15.3.3 track meta-data 5.3.1 Sources of codes A) Ifthen information this field canpasses be includedthrough anto environmentidentify the “suitability” that cannot and track “revision”. meta-data Thethen two thisoptional field fielcands be should included be usedto id entifyor omitted the “suitability” together. and “revision”. Codes should be selected from one of two sources: The two optional fields should be used or omitted together. a) standard codes (see 5.3.2); or 5.4.3 Files 5.4.3 Files b) project specific codes (see 5.3.3). Files should be transmitted and stored in repositories in a context which Filesmakes should clear bethe transmitted fields defined and for stored the directory in repositories (see 5.4.2 in a ).context Files should which 5.3.2 Standard codes makesbe transmitted clear the and fields stored defined in repositories for the directory with names(see 5.4.2 composed). Files shouldby bejoining transmitted the seven and mandator stored iny repositoriesand three optional with names fields composedgiven in Table by 2 Containers should have standard codes assigned for the fields as listed joining(an example the seven is given mandator in 5.5y). and three optional fields given in Table 2 in 6.2 to 15.2. Standard codes should be used wherever possible. NOTE(an example The file is givenname inalso 5.5 contains). the extension suffix identifying the NOTEtype of application The file name applicable. also contains the extension suffix identifying the 5.3.3 Project specific codes type of application applicable. Project specific values for fields should be given codes that are unique Table 2 Naming of file Table 2 Naming of file and distinctive, with clear descriptions. Project specific codes should Field Obligation Clause not be overly long as some repository systems cannot handle long ProjectField RequiredObligation 6Clause file-identifiers. OriginatorProject Required 76 Containers should have codes assigned for the fields as specified ZonesOriginatorVolume and or systemassets Required 8.1.27 in 6.3 to 15.3. LevelsZones andand assetslocations Required 8.1.38.1.2 Each code should not imply meaning that is duplicated in other fields. TypeLevels and locations Required 98.1.3 NOTE This is necessary to ensure that complex rules are not required to RoleType Required 910 maintain consistency between the fields. For example, avoid putting meaning in a revision field that is related to the suitability field. RoleClassification OptionalRequired 1110 The codes should be published and maintained alongside the document NumberClassification OptionalRequired 1113 register. Codes should be mnemonics, where possible, to ensure users NumberSuitability A) RequiredOptionalmetadata 15.2.213 can clearly identify them and differentiate between them. RevisionSuitability A) A) Optionalmetadata 15.2.315.2.2 A)RevisionIf files A) pass through an environmentOptional where there is no15.2.3 directory context, A) Ifthis files field pass can through be included an environment to document wh theere suitability there is no and directory revision. context, Thethis optional fieldmetadata canfields be “suitability” included fields “suitability” to anddocu “revisment andion” the “revision” shouldsuitability be should usedand revision. orbe omittedused or together. Theomitted optional together. fields “suitability” and “revision” should be used or omitted together.

14 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution© BSI 20152007 • 1515 © BSI 2007 • 15 BS 1192:20071192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007 BS 1192:2007 5 Naming of containers 5.4 Naming of containers 5.4 Naming of containers 5.4.1 Patterns for naming containers 5.1 Structure of names 5.4.1 NamesPatterns for containers for naming should containers be created according to three patterns: NOTE 1 Different containers have different fields joined together but Names for containers should be created according to three patterns: otherwise use the same conventions. a) directories and folders (see 5.4.2); or Names for containers should be created by joining together codes in the b)a) filesdirectories (see 5.4.3 and); folders or (see 5.4.2); or specified fields, in the specified order, using only the “-” hyphen c)b) filescontainers (see 5.4.3 within); or files including layers (see 5.4.4). character, which is therefore not allowed in any code. c) containers within files including layers (see 5.4.4). NOTE 2 Any “description” (see Clause 14) is appended following an 5.4.2 Directories and folders underscore “_”. 5.4.2 Directories should and be folderstransmitted and stored in repositories with names NOTE 3 The hyphen character may be used in a description field but this Directoriescomposed by should joining be thetransmitted one mandat andory stored and intwo repositories optional fields with namesgiven is deprecated. composedin Table 1. byAn joining example the is one given mandat in 5.5ory. and two optional fields given NOTEin TableImplementations 1. An example is might given introduce in 5.5. intermediate sub-directories 5.2 Assigning codes NOTEbased on Implementations fields present in mightthe file introduce naming specifiedintermediate in 5.4.3 sub-directories. Containers should have codes assigned for each of the specified fields. based on fields present in the file naming specified in 5.4.3. Table 1 Naming of directories and folder containers NOTE The codes for fields are defined in Clauses 6 to 15. Table 1 Naming of directories and folder containers Field Obligation Clause Any container having more than one dominant code for any single field Field Obligation Clause should be sub-divided. Project Required 6 SuitabilityProject A) RequiredOptional 615.3.2 5.3 Codes SuitabilityRevision A) A) Optional 15.3.315.3.2 A)RevisionIf information A) passes throughOptional an environment that cannot15.3.3 track meta-data 5.3.1 Sources of codes A) Ifthen information this field canpasses be includedthrough anto environmentidentify the “suitability” that cannot and track “revision”. meta-data Thethen two thisoptional field fielcands be should included be usedto id entifyor omitted the “suitability” together. and “revision”. Codes should be selected from one of two sources: The two optional fields should be used or omitted together. a) standard codes (see 5.3.2); or 5.4.3 Files 5.4.3 Files b) project specific codes (see 5.3.3). Files should be transmitted and stored in repositories in a context which Filesmakes should clear bethe transmitted fields defined and for stored the directory in repositories (see 5.4.2 in a ).context Files should which 5.3.2 Standard codes makesbe transmitted clear the and fields stored defined in repositories for the directory with names(see 5.4.2 composed). Files shouldby bejoining transmitted the seven and mandator stored iny repositoriesand three optional with names fields composedgiven in Table by 2 Containers should have standard codes assigned for the fields as listed joining(an example the seven is given mandator in 5.5y). and three optional fields given in Table 2 in 6.2 to 15.2. Standard codes should be used wherever possible. NOTE(an example The file is givenname inalso 5.5 contains). the extension suffix identifying the NOTEtype of application The file name applicable. also contains the extension suffix identifying the 5.3.3 Project specific codes type of application applicable. Project specific values for fields should be given codes that are unique Table 2 Naming of file Table 2 Naming of file and distinctive, with clear descriptions. Project specific codes should Field Obligation Clause not be overly long as some repository systems cannot handle long ProjectField RequiredObligation 6Clause file-identifiers. OriginatorProject Required 76 Containers should have codes assigned for the fields as specified ZonesOriginatorVolume and or systemassets Required 8.1.27 in 6.3 to 15.3. LevelsZones andand assetslocations Required 8.1.38.1.2 Each code should not imply meaning that is duplicated in other fields. TypeLevels and locations Required 98.1.3 NOTE This is necessary to ensure that complex rules are not required to RoleType Required 910 maintain consistency between the fields. For example, avoid putting meaning in a revision field that is related to the suitability field. RoleClassification OptionalRequired 1110 The codes should be published and maintained alongside the document NumberClassification OptionalRequired 1113 register. Codes should be mnemonics, where possible, to ensure users NumberSuitability A) meta-dataRequiredOptionalmetadata 15.2.213 can clearly identify them and differentiate between them. RevisionSuitability A) A) meta-dataOptionalmetadata 15.2.315.2.2 A)RevisionIf files A) pass through an environmentOptional where there is no15.2.3 directory context, A) Ifthis files field pass can through be included an environment to document wh theere suitability there is no and directory revision. context, Thethis optional fieldmetadatameta-data canfields be “suitability” included fields fields “suitability” “suitability” to anddocu “revisment and andion” the “revision” “revision” shouldsuitability be should should usedand revision. orbe be omittedused used or or together. Theomitted optional together. fields “suitability” and “revision” should be used or omitted together.

14 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution© BSI 201520162007 • 1515 © BSI 2007 • 15 BS 1192:20071192:2007+A1:20151192:2007+A2:2016 BS 1192:2007+A1:2015BS 1192:2007

5.4.4 Containers within files 6 Project Containers within files should have names composed by joining the three mandatory fields and one optional field given in Table 3 (an 6.1 Principles example is given in 5.5). A single common project identifier should be defined at the initiation of NOTE The provisions applicable to containers within files do not apply the project; independent and recognizably distinct from any individual to unstructured documents such as un-scaled sketches, narrative and renderings. organization’s internal job number. Where possible it should match any existing contract code. Where a project involves several elements or one Table 3 Naming of containers within files including layers element with several phases, each should be assigned an identifier. NOTE A project can be divided into sub-projects. Field Obligation Clause Role Required 10 6.2 Standard codes for project Classification Required 11 NOTE There are no standard codes mandated for the project field. Presentation Required 12 Description Optional 14 6.3 Project specific codes for project 5.5 Examples of naming containers The code for the project and any sub-projects should be from two to six characters. 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 7 Originator examples that might be used for project specific codes.

Table 4 Examples of field usage 7.1 Principles

Fields Directories Files Containers Clause A unique identifier for each organization should be defined on joining (see 5.4.2) (see 5.4.3) within files the project. The unique identifier should identify the organization including layers responsible for creating the data. (see 5.4.4) Project PR1 PR1 6 7.2 Standard codes for originator Originator XYZ 7 NOTE There are no standard codes mandated for the originator field. ZonesVolume and or systemassets V1Z101 8.1.2 7.3 Project specific codes for originator Levels and locations 01 8.1.3 The code for each originating organization should be from three to six Type M3 9 characters. Role A A 10 Classification UniclassG31 (optional) (optional) UniclassG322  11 8 Divisions Presentation M 12 Number 0001 13 8.1 Principles Description (optional) Doors 14 Suitability (optional) S1 S1 15.2.2 8.1.1 Types of physical sub-division Revision (optional)P02 P2  P02P2  15.2.3 The project should be divided into manageable sub-divisions using two PR1-XYZ-01-01-M3-A-0001 A-Uniclass-M_Doors Name PR1-S1-P2 PR1-XYZ-Z1-01-M3-A-0001 A-G322-M_Doors criteria: a) zonesvolume and assetsor system (see 8.1.2 (see); 8.1.2); b) levels andand locationslocations (see (see 8.1.3 8.1.3) )(see (see also also Annex Annex C). C). NOTE Buildings Buildings are are vertically vertically displaced displaced named named using using levels levelsbut most but civil most civilstructures structures are horizontally are horizontally displaced displaced and named and using named location using or chainages. location or chainages.Civil projects Civil occupying projects large occupying areas such large as oil areas refinery such sites as and oil airportsrefinery would sites anduse the airports “location” would code use based the on “location” a grid basis co de basedor post on code a grid. Inbasis. each Incase each case“  volume“zone” then” then adds adds additional additional subdivision. subdivision.

16 • ©© BSIThe 2007 British Standards Institution 20152016 © The British Standards Institution© BSI 20152007 • 1717 BS 1192:20071192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016BS 1192:2007

5.4.4 Containers within files 6 Project Containers within files should have names composed by joining the three mandatory fields and one optional field given in Table 3 (an 6.1 Principles example is given in 5.5). A single common project identifier should be defined at the initiation of NOTE The provisions applicable to containers within files do not apply the project; independent and recognizably distinct from any individual to unstructured documents such as un-scaled sketches, narrative and renderings. organization’s internal job number. Where possible it should match any existing contract code. Where a project involves several elements or one Table 3 Naming of containers within files including layers element with several phases, each should be assigned an identifier. NOTE A project can be divided into sub-projects. Field Obligation Clause Role Required 10 6.2 Standard codes for project Classification Required 11 NOTE There are no standard codes mandated for the project field. Presentation Required 12 Description Optional 14 6.3 Project specific codes for project 5.5 Examples of naming containers The code for the project and any sub-projects should be from two to six characters. 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 7 Originator examples that might be used for project specific codes.

Table 4 Examples of field usage 7.1 Principles

Fields Directories Files Containers Clause A unique identifier for each organization should be defined on joining (see 5.4.2) (see 5.4.3) within files the project. The unique identifier should identify the organization including layers responsible for creating the data. (see 5.4.4) Project PR1 PR1 6 7.2 Standard codes for originator Originator XYZ 7 NOTE There are no standard codes mandated for the originator field. ZonesVolume and or systemassets V1Z1 8.1.2 7.3 Project specific codes for originator Levels and locations 01 8.1.3 The code for each originating organization should be from three to six Type M3 9 characters. Role A A 10 Classification UniclassG31 (optional) (optional) UniclassG322  11 8 Divisions Presentation M 12 Number 0001 13 8.1 Principles Description (optional) Doors 14 Suitability (optional) S1 S1 15.2.2 8.1.1 Types of physical sub-division Revision (optional)P02 P2  P02P2  15.2.3 The project should be divided into manageable sub-divisions using two A-Uniclass-M_Doors Name PR1-S1-P2 PR1-XYZ-Z1-01-M3-A-0001 A-G322-M_Doors criteria: a) zonesvolume and assetsor system (see 8.1.2 (see); 8.1.2); b) levels andand locationslocations (see (see 8.1.3 8.1.3) )(see (see also also Annex Annex C). C). NOTE Buildings Buildings are are vertically vertically displaced displaced named named using using levels levelsbut most but civil most civilstructures structures are horizontally are horizontally displaced displaced and named and using named location using or chainages. location or chainages.Civil projects Civil occupying projects large occupying areas such large as oil areas refinery such sites as and oil airportsrefinery would sites anduse the airports “location” would code use based the on “location” a grid basis co de basedor post on code a grid. Inbasis. each Incase each case“  volume“zone” then” then adds adds additional additional subdivision. subdivision.sub-division.

16 • ©© BSIThe 2007 British Standards Institution 2015 © The British Standards Institution© BSI 201520162007 • 1717 BS 1192:2007

8.1.2 Zones and assets BS 1192:2007 Every container should document a single building zone or asset (location), contained within a simple volume of space. There should be at least one set of zones explicitly designated to be 8.1.2 non-overlapping.Zones and assets EveryNOTE 1container The term should “asset” document might be amore single appropriate building zone for infrastructure or asset (location),projects. contained within a simple volume of space. ThereNOTE 2should Where be possibleat least one“zones” set shouldof zones be explicitly defined so designated as to identify to be a non-overlapping.logical portion of work intended to be delivered by a single team. 8.1.3 LevelsNOTE 1 and The term locations “asset” might be more appropriate for infrastructure projects. Where a container documents a single building level (floor) or location, NOTE 2 Where possible “zones” should be defined so as to identify a logicalthe code portion for that of worklevel intendedshould be to used. be delivered Where a by container a single team.documents multiple levels, a distinct code should be used. 8.1.3 NOTELevels The and term locations “location” might be more appropriate for infrastructure projects. Where a container documents a single building level (floor) or location, the code for that level should be used. Where a container documents 8.2 Standardmultiple levels, codes a distinct for code divisions should be used. NOTE The term “location” might be more appropriate for infrastructure 8.2.1 projects.General The standard codes for the spatial divisions of the project should be 8.2 Standardused wherever codes possible. for divisions NOTE Building projects are more likely to use standard codes. 8.2.1 General 8.2.2 Standard codes for “zone/asset” The standard codes for the spatial divisions of the project should be Theused “ zone/asset”wherever possible. code should be one or two characters. The following NOTEcode should Building be used projects for aare whole more level. likely to use standard codes. 00 All zones 8.2.2 Standard codes for “zone/asset” This list should be expanded in the project specific codes. The “zone/asset” code should be one or two characters. The following 8.2.3 Standardcode should becodes used for a “levels”whole level. and “location” The 00“level/locator” All zones code should be two characters as follows: This ZZlist should Multiple be levels expanded in the project specific codes. XX No level applicable BS 1192:2007+A1:2015 8.2.3 StandardGF Ground codes floor for “levels” and “location” The 00“level/locator” Base level codeof building should (where be two ground characters floor as is follows: not appropriate) For floorZZ Multiple levels above levels ground floor, the floor number should be used as BS 1192:2007 follows: BS 1192:2007+A1:20151192:2007+A2:2016 XX No level applicable BS 1192:2007+A1:2015 GF01 FloorGround 1 floor 0002 BaseFloor level2, etc. of building (where ground floor is not appropriate) BS 1192:2007 8.1.2 Zones and assets 8.1.2 Volumes and systems For floormezzanine levels theabove prefix ground “M” floor,should th bee floor used number as follows: should be used as Every container should document a single building zone or asset follows:  M1 Mezzanine above level 01 8.1.2 Zones(location),Every container and contained assets should within document a simple a single volume building of space. volume or system (location), contained within a simple volume of space. M201 FloorMezzanine 1 above level 02, etc. EveryThere containershould be shouldat least document one set of azones single explicitly building designatedzone or asset to be 02 Floor 2, etc. non-overlapping.There should be at least one set of volume per role explicitly For all levels below the ground floor the prefix “B” should be used: (location), contained within a simple volume of space. For mezzanine the prefix “M” should be used as follows: designated to be non-overlapping. B1 ThereNOTE 1should The beterm at “asset”least one might set beof morezones appropriate explicitly designated for infrastructure to be projects.Text deleted M1B2, etc. Mezzanine above level 01 non-overlapping. M2 Mezzanine above level 02, etc. BS 1192:2007 NOTE 2Where Where possible possible “  “zvolumesones” should” should be defined be defined so asso asto identifyto identify a a NOTE 2 ForFor floor floor notation,notation, seesee BS BS EN EN ISO ISO 4157-1 4157-1 and and BS BS EN EN ISO ISO 4157-2. 4157-2. NOTE 1 The term “asset” might be more appropriate for infrastructure logicalNOTE portion1 portion The ofterm of work work “asset” intended intended might to be tobe delivered be more delivered appropriate by a single by a singleteam. for infrastructure team. For all levels below the ground floor the prefix “B” should be used: projects. 18 • © BSI 2007 8.3 ProjectB1 specific codes for divisions 8.1.3 LevelsNOTE 2 and Where locations possible “zones” should be defined so as to identify a B2, etc. logical portion of work intended to be delivered by a single team. BS 1192:2007 Where a container documents a single building level (floor) or location, 8.3.1 PrinciplesNOTE 2 ForFor floor floor notation,notation, seesee BS BS EN EN ISO ISO 4157-1 4157-1 and and BS BS EN EN ISO ISO 4157-2. 4157-2. the code for that level should be used. Where a container documents BS 1192:2007 8.1.3 Levels and locations Project specific codes for divisions should be detailed in the project multiple levels, a distinct code should be used. Where a container documents a single building level (floor) or location, 18 • © BSI 2007 8.3 Projectspace statement specific (see Annex codes A). Thefor pr divisionsoject specific codes should not NOTEthe code The for term that “location”level should might be used.be mo reWhere appropriate a container for infrastructure documents 8.3 Projectconflict with specific the standard codes codes givenfor divisionsin 8.2. projects. multiple levels, a distinct code should be used. 8.3.1 NOTEPrinciples Infrastructure projects are more likely to require project specific BS 1192:2007 8.3.1 Principlescodes. 8.2 StandardNOTE The term codes “location” for might divisions be more appropriate for infrastructure Project specific codes for divisions should be detailed in the project projects. 8.3.28.3.2 Projectspace statement specific specificspecific codes (see codes codesAnnex for divisions forA). for The“ “zone” sh prvolumeouldoject be andspecific detailed “asset”” and codes in the should project not 8.2.1 General 8.3 Projectspaceconflict“system statement with specific the ”(seestan dardAnnex codes codes A). Thegivenfor pr divisionsinoject 8.2 specific. codes should not “Zone” and “asset” identifiers should be defined as required, with 8.2 Standard codes for divisions NOTEconflict Infrastructurewith the standard projects codes are given more in likely 8.2. to require project specific The standard codes for the spatial divisions of the project should be detailed“Volume demarcation” and “ in systemthree dimensions” identifiers and should descriptions. be defined as 8.3.1 NOTEPrinciplescodes. Infrastructure projects are more likely to require project specific used wherever possible. required, with detailed demarcation in three dimensions and descriptions. 8.2.1 General codes. Project specific codes for divisions should be detailed in the project NOTE Building projects are more likely to use standard codes. 8.3.28.3.38.3.2 Project specificspecific codes codes for for “ “zone”“level”volume and “asset”“location”” and The standard codes for the spatial divisions of the project should be 8.3.2 space“system statement ”(see Annex A). The project specific codes should not used wherever possible. “ProjectZone”Level” andand specific ““asset”location” identifiers codes codes should forshould “zone” be be defined defined and with as “asset” required, detailed with 8.2.28.2.2 Standard codescodes for for  “zone/asset”“volumes/system” conflict with the standard codes given in 8.2. detailed“demarcationZone”Volume and demarcation “asset” especially” and identifiers “ in insystemthree the shouldvedimensionsrtical” identifiers be dimension defined and should descriptions. as and required, be a detaileddefined with as NOTE Building projects are more likely to use standard codes. NOTE Infrastructure projects are more likely to require project specific “  description.required, with detailed demarcation in three dimensions and descriptions. The “zone/asset”volume/system code should” code be shouldone or be two one characters. or two characters. The following The detailedcodes. demarcation in three dimensions and descriptions. 8.2.2 Standardcodefollowing should code becodes should used forbe useda “zone/asset”whole for alevel. whole level. 8.3.3 Project specific codes for “level” and “location” 00ZZ AllAll zonesvolumes 8.3.28.3.3 Project specific codes for “zone”“level” and “asset”“location” The “zone/asset” code should be one or two characters. The following 9“ TypeLevel” and “location” codes should be defined with detailed Thiscode listshould should be usedbe expanded for a whole in the level. project specific codes. “demarcationZone”Level” andand ““asset” location”especially identifiers codes in the should shouldvertical be be dimension defined defined with as and required, detailed a detailed with demarcationdescription. especially in the vertical dimension and a detailed 00 All zones 9.1 detailedPrinciples demarcation in three dimensions and descriptions. 8.2.3 StandardWherever codespossible, for repetition “levels” of the and same “location” codes, per Role, should description. Thisbe avoided. list should be expanded in the project specific codes. 8.3.3 ProjectTo aid recognition, specific every codes container for “level” should contain and “location” a single type of The “level/locator” code should be two characters as follows: 9information, Type e.g. a drawing, location model, typical assembly or detail 8.2.3 StandardZZ Multiple codes levels for “levels” and “location” 9information.“ TypeLevel” and “ location” codes should be defined with detailed XX No level applicable demarcation especially in the vertical dimension and a detailed The “level“level/locator” Texttext deleteddeleted code should”” codecode be two shouldshould characters bebe twotwo characterscharacters as follows: asas follows:follows: 9.1 description.Principles GF Ground floor 9.29.1 StandardPrinciples codes for types of information ZZ00 BaseMultiple level levels of building (where ground floor is not appropriate) To aid recognition, every container should contain a single type of XX No level applicable TheToinformation, aid standard recognition, e.g.codes a drawing, everyfor file container containe location rssh model, holdingould contain typical models a assembly single and drawings type or ofdetail the For floor levels above ground floor, the floor number should be used as GF Ground floor 9codeinformation,information. Type should bee.g. exactly a drawing, two characters location model, as follows: typical assembly or detail follows: 00 Base level ofof buildingbuilding (where (where ground ground floor floor is isnot not appropriate) appropriate) information. DR Drawing 01 Flooror linear1 assets For floor levels above ground floor, the floor number should be used as 9.29.1 StandardPrinciplesM2 Two dimensionalcodes for model types of information 02 Floor 2, etc. follows:NOTE 1 The location codes for linear assets are likely to require project 9.2 TheToStandard aid standardM3 recognition, Three codescodes dimensional everyfor filefor container containe model types rssh ofholdingould information contain models a single and drawings type of the Forspecific mezzanine codes. the prefix “M” should be used as follows: MR Model rendering 01 Floor 1 codeTheinformation, standard should be e.g.codes exactly a drawing, for filetwo containe characters locationrs model, holding as follows: typical models assembly and drawings or detail the 02M1 FloorMezzanine 2, etc. above level 01 information.VS Visualization codeDR should Drawing be exactly two characters as follows: M2 Mezzanine above level 02, etc. SC Schedule or table For mezzanine the prefix “M” should be used as follows: SPDRM2 SpecificationDrawingTwo dimensional model For allM1 levels Mezzanine below abovethe ground level 01floor the prefix “B” should be used: 9.2 StandardBQM2M3 BillThreeTwo of dimensionalcodes dimensionalQuantity for model model types of information MR Model rendering M2B1 Mezzanine above level 02, etc. The standardSCM3 StructuralThree codes dimensional Calculation for file containe model rs holding models and drawings the MRVS VisualizationModel rendering For allB2, levels etc. below the ground floor the prefix “B” should be used: codeNOTE should 1 There be exactlyis no prov twisiono© characters The to British extend asStandards this follows: for project Institution specific 2015 codes. • 19 For all levels below the ground floor the prefix “B” should be used: VSSC VisualizationSchedule or table NOTEB1 For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2. NOTESCSPDR 2 SpecificationDrawingSchedule For file containers or table holding documents there are no standard B2, etc. codesSPBQM2 mandated. SpecificationBillTwo of dimensional Quantity model M3 Three dimensional model 18 • © BSI 2007 NOTE For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2. BQSC StructuralBill of Quantity Calculation NOTE For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2. MR Model rendering 18 • © The British Standards Institution 20152016 9.3 NOTEProjectSC 1 Structural There specific is no Calculation prov codesision© The to British forextend “ Standardstypes this for ”project Institution of information specific 2015 codes. • 19 VS Visualization ProjectNOTE 1 specific There is“type” no prov codesision should to extend be defined this for forproject documents. specific codes. 18 • © BSI 2007 NOTESC 2 Schedule For file containers or table holding documents there are no standard codes mandated. NOTESP 2 There Specification For fileis no containers mandate holdingfor any documentsproject specific there codes are no for standard drawings. codesBQ mandated. Bill of Quantity 9.3 ProjectSC Structural specific Calculation codes for “types” of information 9.3 Project specific codes for “types” of information ProjectNOTE 1 specific There is“type” no prov codesision should to extend be defined this for forproject documents. specific codes. NOTEProject 2 specific There For fileis “no type”containers mandate codes holdingfor should any documentsprbeoject defined specific therefor documents.codes are no for standard drawings. codes mandated. NOTE There is no mandate for any project specific codes for drawings. © BSI 2007 • 19 9.3 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. © BSI 2007 • 19 © BSI 2007 • 19

© BSI 2007 • 19 BS 1192:2007

8.1.2 Zones and assets BS 1192:2007 Every container should document a single building zone or asset (location), contained within a simple volume of space. There should be at least one set of zones explicitly designated to be 8.1.2 non-overlapping.Zones and assets EveryNOTE 1container The term should “asset” document might be amore single appropriate building zone for infrastructure or asset (location),projects. contained within a simple volume of space. ThereNOTE 2should Where be possibleat least one“zones” set shouldof zones be explicitly defined so designated as to identify to be a non-overlapping.logical portion of work intended to be delivered by a single team. 8.1.3 LevelsNOTE 1 and The term locations “asset” might be more appropriate for infrastructure projects. Where a container documents a single building level (floor) or location, NOTE 2 Where possible “zones” should be defined so as to identify a logicalthe code portion for that of worklevel intendedshould be to used. be delivered Where a by container a single team.documents multiple levels, a distinct code should be used. 8.1.3 NOTELevels The and term locations “location” might be more appropriate for infrastructure projects. Where a container documents a single building level (floor) or location, the code for that level should be used. Where a container documents 8.2 Standardmultiple levels, codes a distinct for code divisions should be used. NOTE The term “location” might be more appropriate for infrastructure 8.2.1 projects.General The standard codes for the spatial divisions of the project should be 8.2 Standardused wherever codes possible. for divisions NOTE Building projects are more likely to use standard codes. 8.2.1 General 8.2.2 Standard codes for “zone/asset” The standard codes for the spatial divisions of the project should be Theused “ zone/asset”wherever possible. code should be one or two characters. The following NOTEcode should Building be used projects for aare whole more level. likely to use standard codes. 00 All zones 8.2.2 Standard codes for “zone/asset” This list should be expanded in the project specific codes. The “zone/asset” code should be one or two characters. The following 8.2.3 Standardcode should becodes used for a “levels”whole level. and “location” The 00“level/locator” All zones code should be two characters as follows: This ZZlist should Multiple be levels expanded in the project specific codes. XX No level applicable BS 1192:2007+A1:2015 8.2.3 StandardGF Ground codes floor for “levels” and “location” The 00“level/locator” Base level codeof building should (where be two ground characters floor as is follows: not appropriate) For floorZZ Multiple levels above levels ground floor, the floor number should be used as BS 1192:2007 follows: BS 1192:2007+A1:2015 XX No level applicable BS 1192:2007+A1:20151192:2007+A2:2016 GF01 FloorGround 1 floor 0002 BaseFloor level2, etc. of building (where ground floor is not appropriate) BS 1192:2007 8.1.2 Zones and assets 8.1.2 Volumes and systems For floormezzanine levels theabove prefix ground “M” floor,should th bee floor used number as follows: should be used as Every container should document a single building zone or asset follows:  M1 Mezzanine above level 01 8.1.2 Zones(location),Every container and contained assets should within document a simple a single volume building of space. volume or system (location), contained within a simple volume of space. M201 FloorMezzanine 1 above level 02, etc. EveryThere containershould be shouldat least document one set of azones single explicitly building designatedzone or asset to be 02 Floor 2, etc. non-overlapping.There should be at least one set of volume per role explicitly For all levels below the ground floor the prefix “B” should be used: (location), contained within a simple volume of space. For mezzanine the prefix “M” should be used as follows: designated to be non-overlapping. B1 ThereNOTE 1should The beterm at “asset”least one might set beof morezones appropriate explicitly designated for infrastructure to be projects.Text deleted M1B2, etc. Mezzanine above level 01 non-overlapping. M2 Mezzanine above level 02, etc. BS 1192:2007 NOTE 2Where Where possible possible “  “zvolumesones” should” should be defined be defined so asso asto identifyto identify a a NOTE 2 ForFor floor floor notation,notation, seesee BS BS EN EN ISO ISO 4157-1 4157-1 and and BS BS EN EN ISO ISO 4157-2. 4157-2. NOTE 1 The term “asset” might be more appropriate for infrastructure logicalNOTE portion1 portion The ofterm of work work “asset” intended intended might to be tobe delivered be more delivered appropriate by a single by a singleteam. for infrastructure team. For all levels below the ground floor the prefix “B” should be used: projects. 18 • © BSI 2007 8.3 ProjectB1 specific codes for divisions 8.1.3 LevelsNOTE 2 and Where locations possible “zones” should be defined so as to identify a B2, etc. logical portion of work intended to be delivered by a single team. BS 1192:2007 Where a container documents a single building level (floor) or location, 8.3.1 PrinciplesNOTE 2 ForFor floor floor notation,notation, seesee BS BS EN EN ISO ISO 4157-1 4157-1 and and BS BS EN EN ISO ISO 4157-2. 4157-2. the code for that level should be used. Where a container documents BS 1192:2007 8.1.3 Levels and locations Project specific codes for divisions should be detailed in the project multiple levels, a distinct code should be used. Where a container documents a single building level (floor) or location, 18 • © BSI 2007 8.3 Projectspace statement specific (see Annex codes A). Thefor pr divisionsoject specific codes should not NOTEthe code The for term that “location”level should might be used.be mo reWhere appropriate a container for infrastructure documents 8.3 Projectconflict with specific the standard codes codes givenfor divisionsin 8.2. projects. multiple levels, a distinct code should be used. 8.3.1 NOTEPrinciples Infrastructure projects are more likely to require project specific BS 1192:2007 8.3.1 Principlescodes. 8.2 StandardNOTE The term codes “location” for might divisions be more appropriate for infrastructure Project specific codes for divisions should be detailed in the project projects. 8.3.28.3.2 Projectspace statement specific specificspecific codes (see codes codesAnnex for divisions forA). for The“ “zone” sh prvolumeouldoject be andspecific detailed “asset”” and codes in the should project not 8.2.1 General 8.3 Projectspaceconflict“system statement with specific the ”(seestan dardAnnex codes codes A). Thegivenfor pr divisionsinoject 8.2 specific. codes should not “Zone” and “asset” identifiers should be defined as required, with 8.2 Standard codes for divisions NOTEconflict Infrastructurewith the standard projects codes are given more in likely 8.2. to require project specific The standard codes for the spatial divisions of the project should be detailed“Volume demarcation” and “ in systemthree dimensions” identifiers and should descriptions. be defined as 8.3.1 NOTEPrinciplescodes. Infrastructure projects are more likely to require project specific used wherever possible. required, with detailed demarcation in three dimensions and descriptions. 8.2.1 General codes. Project specific codes for divisions should be detailed in the project NOTE Building projects are more likely to use standard codes. 8.3.28.3.38.3.2 Project specificspecific codes codes for for “ “zone”“level”volume and “asset”“location”” and The standard codes for the spatial divisions of the project should be 8.3.2 space“system statement ”(see Annex A). The project specific codes should not used wherever possible. “ProjectZone”Level” andand specific ““asset”location” identifiers codes codes should forshould “zone” be be defined defined and with as “asset” required, detailed with 8.2.28.2.2 Standard codescodes for for  “zone/asset”“volumes/system” conflict with the standard codes given in 8.2. detailed“demarcationZone”Volume and demarcation “asset” especially” and identifiers “ in insystemthree the shouldvedimensionsrtical” identifiers be dimension defined and should descriptions. as and required, be a detaileddefined with as NOTE Building projects are more likely to use standard codes. NOTE Infrastructure projects are more likely to require project specific “  description.required, with detailed demarcation in three dimensions and descriptions. The “zone/asset”volume/system code should” code be shouldone or be two one characters. or two characters. The following The detailedcodes. demarcation in three dimensions and descriptions. 8.2.2 Standardcodefollowing should code becodes should used forbe useda “zone/asset”whole for alevel. whole level. 8.3.3 Project specific codes for “level” and “location” 00 All zones 8.3.28.3.3 Project specific codes for “zone”“level” and “asset”“location” The “zone/asset” code should be one or two characters. The following 9“ TypeLevel” and “location” codes should be defined with detailed Thiscode listshould should be usedbe expanded for a whole in the level. project specific codes. “demarcationZone”Level” andand ““asset” location”especially identifiers codes in the should shouldvertical be be dimension defined defined with as and required, detailed a detailed with demarcationdescription. especially in the vertical dimension and a detailed 00 All zones 9.1 detailedPrinciples demarcation in three dimensions and descriptions. 8.2.3 StandardWherever codespossible, for repetition “levels” of the and same “location” codes, per Role, should description. Thisbe avoided. list should be expanded in the project specific codes. 8.3.3 ProjectTo aid recognition, specific every codes container for “level” should contain and “location” a single type of The “level/locator” code should be two characters as follows: 9information, Type e.g. a drawing, location model, typical assembly or detail 8.2.3 StandardZZ Multiple codes levels for “levels” and “location” 9information.“ TypeLevel” and “ location” codes should be defined with detailed XX No level applicable demarcation especially in the vertical dimension and a detailed The “level“level/locator” Text deleted code should” code be two should characters be two characters as follows: as follows: 9.1 description.Principles GF Ground floor 9.29.1 StandardPrinciples codes for types of information ZZ00 BaseMultiple level levels of building (where ground floor is not appropriate) To aid recognition, every container should contain a single type of XX No level applicable TheToinformation, aid standard recognition, e.g.codes a drawing, everyfor file container containe location rssh model, holdingould contain typical models a assembly single and drawings type or ofdetail the For floor levels above ground floor, the floor number should be used as GF Ground floor 9codeinformation,information. Type should bee.g. exactly a drawing, two characters location model, as follows: typical assembly or detail follows: 00 Base level ofof buildingbuilding (where (where ground ground floor floor is isnot not appropriate) appropriate) information. DR Drawing 01 Flooror linear1 assets For floor levels above ground floor, the floor number should be used as 9.29.1 StandardPrinciplesM2 Two dimensionalcodes for model types of information 02 Floor 2, etc. follows:NOTE 1 The location codes for linear assets are likely to require project 9.2 TheToStandard aid standardM3 recognition, Three codescodes dimensional everyfor filefor container containe model types rssh ofholdingould information contain models a single and drawings type of the Forspecific mezzanine codes. the prefix “M” should be used as follows: MR Model rendering 01 Floor 1 codeTheinformation, standard should be e.g.codes exactly a drawing, for filetwo containe characters locationrs model, holding as follows: typical models assembly and drawings or detail the 02M1 FloorMezzanine 2, etc. above level 01 information.VS Visualization codeDR should Drawing be exactly two characters as follows: M2 Mezzanine above level 02, etc. SC Schedule or table For mezzanine the prefix “M” should be used as follows: SPDRM2 SpecificationDrawingTwo dimensional model For allM1 levels Mezzanine below abovethe ground level 01floor the prefix “B” should be used: 9.2 StandardBQM2M3 BillThreeTwo of dimensionalcodes dimensionalQuantity for model model types of information MR Model rendering M2B1 Mezzanine above level 02, etc. The standardSCM3 StructuralThree codes dimensional Calculation for file containe model rs holding models and drawings the MRVS VisualizationModel rendering For allB2, levels etc. below the ground floor the prefix “B” should be used: codeNOTE should 1 There be exactlyis no prov twisiono© characters The to British extend asStandards this follows: for project Institution specific 2015 codes. • 19 For all levels below the ground floor the prefix “B” should be used: VSSC VisualizationSchedule or table NOTEB1 For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2. NOTESCSPDR 2 SpecificationDrawingSchedule For file containers or table holding documents there are no standard B2, etc. codesSPBQM2 mandated. SpecificationBillTwo of dimensional Quantity model M3 Three dimensional model 18 • © BSI 2007 NOTE For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2. BQSC StructuralBill of Quantity Calculation NOTE For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2. MR Model rendering 18 • © The British Standards Institution 2015 9.3 NOTEProjectSC 1 Structural There specific is no Calculation prov codesision© The to British forextend “ Standardstypes this for ”project Institution of information specific 20152016 codes. • 19 VS Visualization ProjectNOTE 1 specific There is“type” no prov codesision should to extend be defined this for forproject documents. specific codes. 18 • © BSI 2007 NOTESC 2 Schedule For file containers or table holding documents there are no standard codes mandated. NOTESP 2 There Specification For fileis no containers mandate holdingfor any documentsproject specific there codes are no for standard drawings. codesBQ mandated. Bill of Quantity 9.3 ProjectSC Structural specific Calculation codes for “types” of information 9.3 Project specific codes for “types” of information ProjectNOTE 1 specific There is“type” no prov codesision should to extend be defined this for forproject documents. specific codes. NOTEProject 2 specific There For fileis “no type”containers mandate codes holdingfor should any documentsprbeoject defined specific therefor documents.codes are no for standard drawings. codes mandated. NOTE There is no mandate for any project specific codes for drawings. © BSI 2007 • 19 9.3 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. © BSI 2007 • 19 © BSI 2007 • 19

© BSI 2007 • 19 BS 1192:2007

8.3 Project specific codes for divisions

8.3.1 Principles Project specific codes for divisions should be detailed in the project space statement (see Annex A). The project specific codes should not conflict with the standard codes given in 8.2. NOTE Infrastructure projects are more likely to require project specific codes.

8.3.2 Project specific codes for “zone” and “asset” “Zone” and “asset” identifiers should be defined as required, with detailed demarcation in three dimensions and descriptions.

8.3.3 Project specific codes for “level” and “location” “Level” and “location” codes should be defined with detailed demarcation especially in the vertical dimension and a detailed description. BS 1192:2007 9 Type 8.3 Project specific codes for divisions 9.1 Principles 8.3.1 Principles To aid recognition, every container should contain a single type of BS 1192:2007+A1:20151192:2007+A2:2016 Projectinformation, specific e.g. codes a drawing, for divisions location sh model,ould be typical detailed assembly in the project or detail BSBS 1192:2007 1192:2007 BS 1192:2007+A1:2015 spaceinformation. statement (see Annex A). The project specific codes should not conflict with the standard codes given in 8.2. 9.2 StandardNOTE Infrastructure codes projects for types are more of likely information to require project specific 1010 Role Role codes. The standard codes for file containers holding models and drawings the 8.3.2 codeProject should specific be exactly codes two characters for “zone” as follows: and “asset” 10.110.1PrinciplesPrinciples  DR Drawing “Zone”File and types “asset” for drawings identifiers and should models be defined as required, with EachEach organization organization should should be allocatebe allocated tod oneto one or moreor more roles roles within within the the M2 Two dimensional model detailed Code demarcation File Type in three dimensions and descriptions. project.project. M3 Three dimensional model NOTENOTE Further Further subdivision subdivision of ro ofles ro lescan can be impliedbe implied using using the the MRAF ModelAnimation rendering file (of a model) 8.3.3 Project specific codes for “level” and “location” classificationclassification field, field, see seeClause Clause 11 .11. VSCM VisualizationCombined model (combined multidiscipline model) “ Level”SCCR and Schedule “location”Specific or tablefor codes the clashshould process be defined with detailed demarcation SPDR Specification 2Despecially drawing in the vertical dimension and a detailed 10.210.2StandardStandard codes codes for for roles roles M2 2D model file description.BQ Bill of Quantity TheThe standard standard codes codes for forfile file role role should should be exactlybe exactly one one character character as as M3 3D model file SC Structural Calculation follows:follows: MR Model rendition file for other renditions, e.g thermal 9NOTE Type 1 Thereanalysis is no provetc. ision to extend this for project specific codes. AA Architect Architect NOTE VS 2 ForVisualization file containers file holding (of a model) documents there are no standard BB Building Building Surveyor Surveyor codes mandated. CC Civil Civil Engineer Engineer File types for documents 9.1 Principles DD Drainage, Drainage, Highways Highways Engineer Engineer

9.3 ToProject aidCode recognition, specificFile Type every codes container for sh “ouldtypes contain” of a singleinformation type of EE Electrical Electrical Engineer Engineer information, BQ Bille.g. ofa drawing,quantities location model, typical assembly or detail FF Facilities Facilities Manager Manager Project specific “type” codes should be defined for documents. information. COCA CorrespondenceCalculations GG Geographical Geographical and and Land Land Surveyor Surveyor NOTE CPCO ThereCostCorrespondence is no plan mandate for any project specific codes for drawings. HH Heating Heating and and Ventilation Ventilation Designer Designer DBCP DatabaseCost plan II Interior Interior Designer Designer 9.2 Standard FNDB FileDatabase codes note for types of information KK Client Client The standardHSFN HealthFilecodes note forand file safety containers holding models and drawings the LL Landscape Landscape Architect Architect code IEHS should beInformationHealth exactly and twsafety Exchangeo characters file as follows: MM Mechanical Mechanical Engineer Engineer MIIE MinutesInformation / action exchange notes file PP Public Public Health Health Engineer Engineer DR Drawing MSMI MethodMinutes statement/ action notes QQ Quantity Quantity Surveyor Surveyor M2 Two dimensional model PPMS PresentationMethod statement © BSI 2007 • 19 SS Structural Structural Engineer Engineer M3 Three dimensional model PRPP ProgrammePresentation TT Town Town and and Country Country Planner Planner MR Model rendering RDPR RoomProgramme data sheet WW Contractor Contractor VS Visualization RIRD RequestRoom data for sheet Information XX Subcontractor Subcontractor SC Schedule or table RPRI ReportRequest for information YY Specialist Specialist Designer Designer SP Specification SARP ScheduleReport of accommodation ZZ General General (non-disciplinary) (non-disciplinary) BQCASA Bill ofCalculationsSchedule Quantity of accommodation SCSH StructuralSchedule Calculation 10.310.3ProjectProject specific specific codes codes for for roles roles NOTE SN 1 ThereSnagging is no prov listision to extend this for project specific codes. NOTE SP 2 ForSpecification file containers holding documents there are no standard TheThe codes codes J, N, J,J, N,R,N, R, UR, Uor U or Vor Vor V or longeror longer longer codes codes codes should should should be be allocatedbeallocated allocated for for codes SU mandated. Survey non-standardnon-standard proj projectproject ectspecific specific specific roles. roles roles. listed and published.

9.3 Project specific codes for “types” of information 1111 Classification Classification Project specific “type” codes should be defined for documents. NOTE There is no mandate for any project specific codes for drawings. 11.111.1PrinciplesPrinciples EveryEvery container containercontainer should should should be be classifiedbe classified classified by by aby asingle a singleText code, deletedcode, taken taken from code, from the the chosentakenchosen reference from reference the chosendictionary, dictionary, reference to accuto dictionary,accuratelyrately describe todescribe accurately the the construction describeconstruction the assetsconstructionassets represented. represented. assets The represented. The code code should should  beText twobe two deletedcharacters characters or more. or more. A single A single codecode from from one one table table should should be used.be used.

© BSI 2007 • 19

20 • © The British Standards Institution 20152016 20 20•• © BSI © BSI2007 2007 © The British Standards Institution 2015 • 21 BS 1192:2007

8.3 Project specific codes for divisions

8.3.1 Principles Project specific codes for divisions should be detailed in the project space statement (see Annex A). The project specific codes should not conflict with the standard codes given in 8.2. NOTE Infrastructure projects are more likely to require project specific codes.

8.3.2 Project specific codes for “zone” and “asset” “Zone” and “asset” identifiers should be defined as required, with detailed demarcation in three dimensions and descriptions.

8.3.3 Project specific codes for “level” and “location” “Level” and “location” codes should be defined with detailed demarcation especially in the vertical dimension and a detailed description. BS 1192:2007 9 Type 8.3 Project specific codes for divisions 9.1 Principles 8.3.1 Principles To aid recognition, every container should contain a single type of BS 1192:2007+A1:2015 Projectinformation, specific e.g. codes a drawing, for divisions location sh model,ould be typical detailed assembly in the project or detail BSBS 1192:2007 1192:2007 BS 1192:2007+A1:20151192:2007+A2:2016 spaceinformation. statement (see Annex A). The project specific codes should not conflict with the standard codes given in 8.2. 9.2 StandardNOTE Infrastructure codes projects for types are more of likely information to require project specific 1010 Role Role codes. The standard codes for file containers holding models and drawings the 8.3.2 codeProject should specific be exactly codes two characters for “zone” as follows: and “asset” 10.110.1PrinciplesPrinciples  DR Drawing “Zone”File and types “asset” for drawings identifiers and should models be defined as required, with EachEach organization organization should should be allocatebe allocated tod oneto one or moreor more roles roles within within the the M2 Two dimensional model detailed Code demarcation File Type in three dimensions and descriptions. project.project. M3 Three dimensional model NOTENOTE Further Further subdivision subdivision of ro ofles ro lescan can be impliedbe implied using using the the MRAF ModelAnimation rendering file (of a model) 8.3.3 Project specific codes for “level” and “location” classificationclassification field, field, see seeClause Clause 11 .11. VSCM VisualizationCombined model (combined multidiscipline model) “ Level”SCCR and Schedule “location”Specific or tablefor codes the clashshould process be defined with detailed demarcation SPDR Specification 2Despecially drawing in the vertical dimension and a detailed 10.210.2StandardStandard codes codes for for roles roles M2 2D model file description.BQ Bill of Quantity TheThe standard standard codes codes for forfile file role role should should be exactlybe exactly one one character character as as M3 3D model file SC Structural Calculation follows:follows: MR Model rendition file for other renditions, e.g thermal 9NOTE Type 1 Thereanalysis is no provetc. ision to extend this for project specific codes. AA Architect Architect NOTE VS 2 ForVisualization file containers file holding (of a model) documents there are no standard BB Building Building Surveyor Surveyor codes mandated. CC Civil Civil Engineer Engineer File types for documents 9.1 Principles DD Drainage, Drainage, Highways Highways Engineer Engineer

9.3 ToProject aidCode recognition, specificFile Type every codes container for sh “ouldtypes contain” of a singleinformation type of EE Electrical Electrical Engineer Engineer information, BQ Bille.g. ofa drawing,quantities location model, typical assembly or detail FF Facilities Facilities Manager Manager Project specific “type” codes should be defined for documents. information. CO Correspondence GG Geographical Geographical and and Land Land Surveyor Surveyor NOTE CP ThereCost is no plan mandate for any project specific codes for drawings. HH Heating Heating and and Ventilation Ventilation Designer Designer DB Database II Interior Interior Designer Designer 9.2 Standard FN File codes note for types of information KK Client Client The standardHS Healthcodes forand file safety containers holding models and drawings the LL Landscape Landscape Architect Architect code IE should beInformation exactly tw Exchangeo characters file as follows: MM Mechanical Mechanical Engineer Engineer MI Minutes / action notes PP Public Public Health Health Engineer Engineer DR Drawing MS Method statement QQ Quantity Quantity Surveyor Surveyor M2 Two dimensional model PP Presentation © BSI 2007 • 19 SS Structural Structural Engineer Engineer M3 Three dimensional model PR Programme TT Town Town and and Country Country Planner Planner MR Model rendering RD Room data sheet WW Contractor Contractor VS Visualization RI Request for Information XX Subcontractor Subcontractor SC Schedule or table RP Report YY Specialist Specialist Designer Designer SP Specification SA Schedule of accommodation ZZ General General (non-disciplinary) (non-disciplinary) BQCA Bill ofCalculations Quantity SCSH StructuralSchedule Calculation 10.310.3ProjectProject specific specific codes codes for for roles roles NOTE SN 1 ThereSnagging is no prov listision to extend this for project specific codes. NOTE SP 2 ForSpecification file containers holding documents there are no standard TheThe codes codes J, N, J,J, N,R,N, R, UR, Uor U or Vor Vor V or longeror longer longer codes codes codes should should should be be allocatedbeallocated allocated for for codes SU mandated. Survey non-standardnon-standard proj projectproject ectspecific specific specific roles. roles roles. listed and published.

9.3 Project specific codes for “types” of information 1111 Classification Classification Project specific “type” codes should be defined for documents. NOTE There is no mandate for any project specific codes for drawings. 11.111.1PrinciplesPrinciples EveryEvery container containercontainer should should should be be classifiedbe classified classified by by aby asingle a singleTexttext code, deleted deletedcode, taken taken from code,code, from the the chosentakenchosen reference from reference the chosendictionary, dictionary, reference to accuto dictionary,accuratelyrately describe todescribe accurately the the construction describeconstruction the assetsconstructionassets represented. represented. assets The represented. The code code should should  beText twobe two deletedcharacters characters or more. or more. A single A single codecode from from one one table table should should be used.be used.

© BSI 2007 • 19

20 • © The British Standards Institution 2015 20 20•• © BSI © BSI2007 2007 © The British Standards Institution 20152016 • 21 BS 1192:2007 BS 1192:2007 13 Number 11.2 Standard codes for classification Classification codes should be selected from a system compliant 13.1 Principles to BS ISO 12006-2:2001, and in particular from tables equivalent A sequential number should be used when a container is one of a series to A.7 and A.8 for Elements, A.9 for Services work and A.13 for not distinguished by any other of the fields defined in Clauses 6 to 12. identified Products and Materials. NOTE This applies most often to files. NOTE 1 The UK implementation of BS ISO 12006-2 is Uniclass so this recommendation can be expressed as follows: 13.2 Standard coding for numbers Use Uniclass Table G for Building elements and Table H for Civil elements, with Table J for services work and Table L for identified The numbering for standard coding should be exactly four integer Products and Materials. Information relating to Spaces may be numeric digits, used sequentially. Leading zeros should be used. BS 1192:2007+A1:20151192:2007+A2:2016 classified using Table F. BS 1192:2007 BS 1192:2007+A1:2015 NOTE There is no need to mandate any codes for this field. Early stage design such as Scheme design and preliminary phases may initially use Table D for Facilities, Table E for Construction 11.2 Standard codes for classification Elements, but these are deprecated. 13.3 Project specific coding ClassificationCPIC is the codes codes co-ordinating should should be be bodyselected selected responsible from from a systema for system maintaining compliant compliant toand There is no further restriction for project specific coding but care toBS BS ISOupdating ISO 12006 12006-2:2001, the Uniclassand the Uniclass andclassification in part publication.iculars. Reference from tables should equivalent be made to should be taken not to embody information present in other fields. to A.7Texttheir and deleted website A.8 for http://www.productio Elements, A.9 for ninformation.org/Services work and for A.13 updates. for identified Products and Materials. NOTE NOTE 2 ThereRefer is to no the provision BIM TOOLKIT to exte andnd thethis UNICLASS through the publication project specific for dictionary.NOTElatest coding 1 The practices. UK implementation of BS ISO 12006-2 is Uniclass so this 14 Description recommendation can be expressed as follows: 11.3 ProjectUse Uniclass specific Table Gcodes for Building for elementsclassification and Table H for Civil 14.1 Principles elements, with Table J for services work and Table L for identified NOTEProducts There andis no Materials. mandate Informationfor any proj ectrelating specific to Spacescodes for may this be field. Descriptive text should not be used to imply further distinctions of classified using Table F. meaning. However, descriptive text derived from the other fields and used consistently can be used to aid recognition. 12 PresentationEarly stage design such as Scheme design and preliminary phases may initially use Table D for Facilities, Table E for Construction NOTE 1 This implies that this field is able to be deduced from the other Elements, but these are deprecated. fields. 12.1 Principles CPIC is the co-ordinating body responsible for maintaining and NOTE 2 Avoid long, unwieldy and poorly worded descriptions. Everyupdating container the should Uniclass be classificationconsistent ins. its Reference presentation shouldal conventions.be made to For boththeir drawingswebsite http://www.productio and documents, graphicalninformation.org/ and textual for content updates. should 14.2 Standard coding for description NOTEbe distinguished 2 There is by no using provision containers to exte ndwithin this filesthrough such the as project layering specific or NOTE There are no standard codes mandated for the description field. dictionary.sections. NOTE This ensures that the information can still be re-used for a variety 14.3 Project specific coding 11.3 Projectof presentational specific purposes codes without for conflicting classification with re-use of information. NOTE There is no further restriction for the project specific coding of the NOTE There is no mandate for any project specific codes for this field. 12.2 Standard codes for presentation description field. The standard code for presentation should be exactly one character as 12follows. Presentation 15 Status D Dimensioning 12.1 PrinciplesH Hatching and shading 15.1 Principles EveryM container Model related should elements be consistent in its presentational conventions. The identification and management of the “status” of containers should For bothP Plot/paperdrawings and related documents, elements graphical and textual content should BS 1192:2007 follow the principles given in Clause 4. be distinguishedT Text by using containers within files such as layering or sections. NOTE There is no provision to extend this with project specific codes. 15.2 Types of “status” NOTE This ensures that the information can still be re-used for a variety of presentational purposes without conflicting with re-use of information. 12.3 Project specific codes for presentation 15.2.1 General BS 1192:2007 NOTE There is no mandate for any project specific codes for this field. 12.2 Standard codes for presentation If repositories are not able to track the “status” of each container (for example a model or drawing) then its “status” should be tracked The standard code for presentation should be exactly one character as through using two fields together: 13follows. Number a) suitability (see 15.2.2); and D Dimensioning 22 • © BSI 2007 b) revision (see 15.2.3). 13.1 H Hatching and shading Principles © BSI 2007 • 21 M Model related elements NOTE The The “suitability”“suitability” and and “revision” “revision” of a of document a document changes changes during during the the A sequentialP Plot/paper number related should elements be used when a container is one of a series designproduction process. process. not distinguishedT Text by any other of the fields defined in Clauses 6 to 12. 15.2.2 Suitability NOTE ThereThis applies is no provision most often to to extend files. this with project specific codes. Every container should have a field indicating the approved “suitability” 12.313.2 ProjectStandard specific coding codes for numbers for presentation for use of the contained information. The numbering for standard coding should be exactly four integer NOTE There is no mandate for any project specific codes for this field. 15.2.3 numeric digits, used sequentially. Leading zeros should be used. Revision NOTE There is no need to mandate any codes for this field. Every container should carry a “revision” field, indicating the issue sequence of the contained information. 13.3 Project specific coding 15.3 Standard coding There is no further restriction for project specific coding but care 22 • © The British Standards Institution 20152016 © BSI 2007 • 21 © The British Standards Institution 2015 • 23 should be taken not to embody information present in other fields. 15.3.1 Standard status codes for “status” Standard codes should be used for the “status” fields wherever possible. 14 Description NOTE Some codes might not be appropriate depending on whether they are models or documents. 14.1 Principles 15.3.2 Standard codes for “suitability” Descriptive text should not be used to imply further distinctions of meaning. However, descriptive text derived from the other fields and The “suitability” code should be one or two characters. used consistently can be used to aid recognition. The “suitability” codes given in Table 5 should be used. NOTE 1 This implies that this field is able to be deduced from the other NOTE Use of a particular management process might make some codes fields. inapplicable to some types of document. NOTE 2 Avoid long, unwieldy and poorly worded descriptions.

14.2 Standard coding for description NOTE There are no standard codes mandated for the description field.

14.3 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 follow the principles given in Clause 4.

© BSI 2007 • 23

22 • © BSI 2007 BS 1192:2007 BS 1192:2007 13 Number 11.2 Standard codes for classification Classification codes should be selected from a system compliant 13.1 Principles to BS ISO 12006-2:2001, and in particular from tables equivalent A sequential number should be used when a container is one of a series to A.7 and A.8 for Elements, A.9 for Services work and A.13 for not distinguished by any other of the fields defined in Clauses 6 to 12. identified Products and Materials. NOTE This applies most often to files. NOTE 1 The UK implementation of BS ISO 12006-2 is Uniclass so this recommendation can be expressed as follows: 13.2 Standard coding for numbers Use Uniclass Table G for Building elements and Table H for Civil elements, with Table J for services work and Table L for identified The numbering for standard coding should be exactly four integer Products and Materials. Information relating to Spaces may be numeric digits, used sequentially. Leading zeros should be used. BS 1192:2007+A1:2015 classified using Table F. BS 1192:2007 BS 1192:2007+A1:20151192:2007+A2:2016 NOTE There is no need to mandate any codes for this field. Early stage design such as Scheme design and preliminary phases may initially use Table D for Facilities, Table E for Construction 11.2 Standard codes for classification Elements, but these are deprecated. 13.3 Project specific coding ClassificationCPIC is the codes codes co-ordinating should should be be bodyselected selected responsible from from a systema for system maintaining compliant compliant toand There is no further restriction for project specific coding but care toBS BS ISOupdating ISO 12006 12006-2:2001, the Uniclassand the Uniclass andclassification in part publication.iculars. Reference from tables should equivalent be made to should be taken not to embody information present in other fields. to A.7Texttheir and deleted website A.8 for http://www.productio Elements, A.9 for ninformation.org/Services work and for A.13 updates. for identified Products and Materials. NOTE NOTE 2 ThereRefer is to no the provision BIM TOOLKIT to exte andnd thethis UNICLASS through the publication project specific for dictionary.NOTElatest coding 1 The practices. UK implementation of BS ISO 12006-2 is Uniclass so this 14 Description recommendation can be expressed as follows: 11.3 ProjectUse Uniclass specific Table Gcodes for Building for elementsclassification and Table H for Civil 14.1 Principles elements, with Table J for services work and Table L for identified NOTEProducts There andis no Materials. mandate Informationfor any proj ectrelating specific to Spacescodes for may this be field. Descriptive text should not be used to imply further distinctions of classified using Table F. meaning. However, descriptive text derived from the other fields and used consistently can be used to aid recognition. 12 PresentationEarly stage design such as Scheme design and preliminary phases may initially use Table D for Facilities, Table E for Construction NOTE 1 This implies that this field is able to be deduced from the other Elements, but these are deprecated. fields. 12.1 Principles CPIC is the co-ordinating body responsible for maintaining and NOTE 2 Avoid long, unwieldy and poorly worded descriptions. Everyupdating container the should Uniclass be classificationconsistent ins. its Reference presentation shouldal conventions.be made to For boththeir drawingswebsite http://www.productio and documents, graphicalninformation.org/ and textual for content updates. should 14.2 Standard coding for description NOTEbe distinguished 2 There is by no using provision containers to exte ndwithin this filesthrough such the as project layering specific or NOTE There are no standard codes mandated for the description field. dictionary.sections. NOTE This ensures that the information can still be re-used for a variety 14.3 Project specific coding 11.3 Projectof presentational specific purposes codes without for conflicting classification with re-use of information. NOTE There is no further restriction for the project specific coding of the NOTE There is no mandate for any project specific codes for this field. 12.2 Standard codes for presentation description field. The standard code for presentation should be exactly one character as 12follows. Presentation 15 Status D Dimensioning 12.1 PrinciplesH Hatching and shading 15.1 Principles EveryM container Model related should elements be consistent in its presentational conventions. The identification and management of the “status” of containers should For bothP Plot/paperdrawings and related documents, elements graphical and textual content should BS 1192:2007 follow the principles given in Clause 4. be distinguishedT Text by using containers within files such as layering or sections. NOTE There is no provision to extend this with project specific codes. 15.2 Types of “status” NOTE This ensures that the information can still be re-used for a variety of presentational purposes without conflicting with re-use of information. 12.3 Project specific codes for presentation 15.2.1 General BS 1192:2007 NOTE There is no mandate for any project specific codes for this field. 12.2 Standard codes for presentation If repositories are not able to track the “status” of each container (for example a model or drawing) then its “status” should be tracked The standard code for presentation should be exactly one character as through using two fields together: 13follows. Number a) suitability (see 15.2.2); and D Dimensioning 22 • © BSI 2007 b) revision (see 15.2.3). 13.1 H Hatching and shading Principles © BSI 2007 • 21 M Model related elements NOTE The The “suitability”“suitability” and and “revision” “revision” of a of document a document changes changes during during the the A sequentialP Plot/paper number related should elements be used when a container is one of a series designproduction process. process. not distinguishedT Text by any other of the fields defined in Clauses 6 to 12. 15.2.2 Suitability NOTE ThereThis applies is no provision most often to to extend files. this with project specific codes. Every container should have a field indicating the approved “suitability” 12.313.2 ProjectStandard specific coding codes for numbers for presentation for use of the contained information. The numbering for standard coding should be exactly four integer NOTE There is no mandate for any project specific codes for this field. 15.2.3 numeric digits, used sequentially. Leading zeros should be used. Revision NOTE There is no need to mandate any codes for this field. Every container should carry a “revision” field, indicating the issue sequence of the contained information. 13.3 Project specific coding 15.3 Standard coding There is no further restriction for project specific coding but care 22 • © The British Standards Institution 2015 © BSI 2007 • 21 © The British Standards Institution 20152016 • 23 should be taken not to embody information present in other fields. 15.3.1 Standard status codes for “status” Standard codes should be used for the “status” fields wherever possible. 14 Description NOTE Some codes might not be appropriate depending on whether they are models or documents. 14.1 Principles 15.3.2 Standard codes for “suitability” Descriptive text should not be used to imply further distinctions of meaning. However, descriptive text derived from the other fields and The “suitability” code should be one or two characters. used consistently can be used to aid recognition. The “suitability” codes given in Table 5 should be used. NOTE 1 This implies that this field is able to be deduced from the other NOTE Use of a particular management process might make some codes fields. inapplicable to some types of document. NOTE 2 Avoid long, unwieldy and poorly worded descriptions.

14.2 Standard coding for description NOTE There are no standard codes mandated for the description field.

14.3 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 follow the principles given in Clause 4.

© BSI 2007 • 23

22 • © BSI 2007 BS 1192:2007

15.2 Types of “status”

15.2.1 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). NOTE The “suitability” and “revision” of a document changes during the 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 BS 1192:2007+A1:20151192:2007+A2:2016 Every container should carry a “revision” field, indicating the issue sequence of the contained information.

15.3 Standard coding

15.3.1 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.

© BSI 2007 • 23

24 • © The British Standards Institution 20152016 BS 1192:2007

15.2 Types of “status”

15.2.1 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). NOTE The “suitability” and “revision” of a document changes during the 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 BS 1192:2007+A1:2015 Every container should carry a “revision” field, indicating the issue BS 1192:2007+A2:2016 sequence of the contained information.

15.3 Standard coding Table 5 Standard codes for suitability models and documents

Graphical Non- 15.3.1 Standard status codes for “status” Status Description Revision Graphical Documents Data Data Standard codes should be used for the “status” fields wherever possible. Work in Progress NOTE Some codes might not be appropriate depending on whether they Initial status or WIP P01.01 etc are models or documents. S0 Master document index of file identifiers to P0n.0n ✓ ✓ ✓ uploaded into the extranet. etc 15.3.2 Standard codes for “suitability” Shared (Non-contractual) The “suitability” code should be one or two characters. Suitable for Co-ordination The file is available to be ‘shared’ and P01 to The “suitability” codes given in Table 5 should be used. S1 ✓ ✗ ✗ used by other disciplines as a background P0n NOTE Use of a particular management process might make some codes for their information. inapplicable to some types of document. P01 to S2 Suitable for Information ✗ ✓ ✓ P0n P01 to S3 Suitable for Review & Comment As required ✓ ✓ P0n P01 to S4 Suitable for Stage Approval ✗ ✗ ✓ P0n Text deleted Suitable for PIM Authorization S6 P01 to Pnn ✗ ✗ ✓ (Information Exchanges 1-3) Suitable for AIM Authorization S7 P01 to Pnn ✗ ✗ ✓ (Information Exchange 6) WIP to Published Unauthorized and (Non-contractual) use at risk. P01.01 etc D1 Suitable for Costing ✓ ✓ ✓ to P0n.0n P01.01 etc D2 Suitable for Tender ✗ ✓ ✓ to P0n.0n P01.01 etc D3 Suitable for Contractor Design ✓ ✓ ✓ to P0n.0n P01.01 etc © BSI 2007 • 23 D4 Suitable for Manufacture/Procurement ✗ ✓ ✓ to P0n.0n Published Documentation (Contractual) A1, A2, A3, Approved and accepted as stage complete C01 to C0n ✓ ✓ ✓ An etc (C= Contractual/Complete) Partially signed-off: with minor comments from the Client. All minor comments should be indicated by B1, B2, P01.01 etc to the insertion of a cloud and a statement ✓ ✓ ✓ B3, Bn etc P0n.0n etc of ‘in abeyance’ until the comment is resolved, then resubmitted for full authorization. Published for AIM Acceptance As Construction Record documentation, CR C01 to C0n ✓ ✓ ✓ PDF, Models etc

24 • © The British Standards Institution 2015 © The British Standards Institution 2016 • 25 BS 1192:2007

Table 5 Standard codes for suitability models and documents

Code Suitability Models Drawings and documents WORK-IN-PROGRESS (see 4.2.2) S0 Initial non-contractual code. YY Master document index of file names should be uploaded into the extranet. SHARED (see 4.2.3) Pre-construction sign-off. Non contractual. S1 Fit for co-ordination. YN The file is available to be “shared” and used by other disciplines as a background for information. S2 Fit for information N Y S3 Fit for internal review and comment Y Y S4 Fit for construction approval N Y DOCUMENTATION (see 4.2.4) Pre construction sign-off codes with temporary ownership by the contractor for a specified purpose. Non contractual. D1 Fit for costing Y Y D2 Fit for tender N Y D3 Fit for contractor design Y Y D4 Fit for manufacture/procurement N Y DOCUMENTATION (see 4.2.4) These are sign-off codes used to state the completeness of the document for contractual purposes. A Fit for construction N Y B Fit for construction but with NY comments A) C Comprehensive revisions needed N Y ARCHIVE (see 4.2.5) AB As built Y Y NOTE 1 Codes A, B, C are referenced JCT 2005 – Major Project Sub-Contract (MPSub/G) [1] describing the sign-off 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)BSFor 1192:2007+A1:20151192:2007+A2:2016 construction with minor comments from the client. 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 BS 1192:2007 minor changes incorporated and resubmitted to achieve full sign-off.

15.3.3 Standard codes for “revisions” Annex A (normative) Project space statement Versions created created within within the the WORK-IN-PROGRESS WORK-IN-PROGRESS area area should should be be numbered usingusing decimals, decimals, e.g. e.g.  P1.1,P01.1, P1.2, P01.2, P1.3, P01.3 etc., etc. A.1 General This should bebe changedchanged to to integer integer  P1P01 when signed-offwhen signed-off by the by originator the All models, whether 2D or 3D, should be created using a common originatorfor sharing. for Thereafter sharing. Thereafter the version the within version the within WIP thearea WIP should area becomeshould project origin and orientation using a conventional Cartesian axis and becomeP2.1 as detailedP02.01 in 4.2.4 as .detailed in 4.2.4. 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 Formal revisionsrevisions should should be be numbered numbered sequentially, sequentially, marking marking the the revision revision should be created at 1:1. as either pre-contractuapreliminary (P0l orn post-contractual.) or contractual (C0n). Units should be SI units of measure. Preliminary revisionsrevisions should should be be numbered numbered sequentially sequentially asBS asthe the1192:2007 NOTE 1 SI units are defined in BS ISO 31. pre-contractpreliminary design design develops, develops, e.g. P1,e.g. P2, P01,P3, etc.P02, P03, etc. The basic unit of length within models should be agreed to be metres for Contractual revision should be numbered sequentially for infrastructure projects or millimetres for building. Postany changes contract or revision update shouldto the signed-off be numbered containers, sequentially e.g.  forC01, any C02,changes NOTE 2 The accuracy achievable using the chosen units and origins orC03 update, etc. to the signed-off containers, e.g. C1, C2, C3, etc. might need to be checked. NOTE 1 The The “C” “C” notation notation indicates indicates that th theat thecontainer container can be can used be for used for construction  andor contractual contractual purposes. purposes (e.g. Stage Completion). A.2 Space 24 • © BSI 2007 NOTE 2 There There is is provision provision to extendto extend this thiswith with project project specific specific codes. codes. 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 15.4 Project specific coding related to a specific geospatial north. NOTE The project origin is best located within or close to the project or 15.4.1 Project specific codes for status site extent. The project specific codes should not conflict with the standard codes. A.3 Geospatial 15.4.2 Project specific codes for suitability A statement or diagram should relate the project space to a named Extra suitability codes can be defined indicating other suitability for global geospatial system in three dimensions (decimal degrees latitude, use, if required, with detailed descriptions, reflecting the contractual longitude and elevation in metres) and a plan orientation (decimal arrangements. These codes should not conflict with the standard codes. degrees clockwise rotation from north) (see Figure A.1). NOTE 1 Alternatively reference can be made to a standard named 15.4.3 Project specific codes for revisions projection such as the UK Ordnance Survey grid (see http:// www.ordnancesurvey.co.uk/oswebsite/gps/information/ Extra revision codes can be defined, if required, with detailed coordinatesystemsinfo/guidecontents/guide1.). descriptions. These codes should not conflict with the standard codes. NOTE 2 A decimal latitude in degrees requires eight decimal places to achieve positioning to within 1 mm.

Figure A.1 Geospatial referencing

26 • © The British Standards Institution 20152016 26 • © BSI 2007 © The British Standards Institution 2015 • 27

© BSI 2007 • 25 BS 1192:2007

Table 5 Standard codes for suitability models and documents

Code Suitability Models Drawings and documents WORK-IN-PROGRESS (see 4.2.2) S0 Initial non-contractual code. YY Master document index of file names should be uploaded into the extranet. SHARED (see 4.2.3) Pre-construction sign-off. Non contractual. S1 Fit for co-ordination. YN The file is available to be “shared” and used by other disciplines as a background for information. S2 Fit for information N Y S3 Fit for internal review and comment Y Y S4 Fit for construction approval N Y DOCUMENTATION (see 4.2.4) Pre construction sign-off codes with temporary ownership by the contractor for a specified purpose. Non contractual. D1 Fit for costing Y Y D2 Fit for tender N Y D3 Fit for contractor design Y Y D4 Fit for manufacture/procurement N Y DOCUMENTATION (see 4.2.4) These are sign-off codes used to state the completeness of the document for contractual purposes. A Fit for construction N Y B Fit for construction but with NY comments A) C Comprehensive revisions needed N Y ARCHIVE (see 4.2.5) AB As built Y Y NOTE 1 Codes A, B, C are referenced JCT 2005 – Major Project Sub-Contract (MPSub/G) [1] describing the sign-off 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)BSFor 1192:2007+A1:2015 construction with minor comments from the client. BS 1192:2007+A1:20151192:2007+A2:2016 All minor comments should be indicated by the insertion of a statement of ‘‘in abeyance” until the comment is resolved or BS 1192:2007 minor changes incorporated and resubmitted to achieve full sign-off.

15.3.3 Standard codes for “revisions” Annex A (normative) Project space statement Versions created created within within the the WORK-IN-PROGRESS WORK-IN-PROGRESS area area should should be be numbered usingusing decimals, decimals, e.g. e.g.  P1.1,P01.1, P1.2, P01.2, P1.3, P01.3 etc., etc. A.1 General This should bebe changedchanged to to integer integer  P1P01 when signed-offwhen signed-off by the by originator the All models, whether 2D or 3D, should be created using a common originatorfor sharing. for Thereafter sharing. Thereafter the version the within version the within WIP thearea WIP should area becomeshould project origin and orientation using a conventional Cartesian axis and becomeP2.1 as detailedP02.01 in 4.2.4 as .detailed in 4.2.4. 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 Formal revisionsrevisions should should be be numbered numbered sequentially, sequentially, marking marking the the revision revision should be created at 1:1. as either pre-contractuapreliminary (P0l orn post-contractual.) or contractual (C0n). Units should be SI units of measure. Preliminary revisionsrevisions should should be be numbered numbered sequentially sequentially asBS asthe the1192:2007 NOTE 1 SI units are defined in BS ISO 31. pre-contractpreliminary design design develops, develops, e.g. P1,e.g. P2, P01,P3, etc.P02, P03, etc. The basic unit of length within models should be agreed to be metres for Contractual revision should be numbered sequentially for infrastructure projects or millimetres for building. Postany changes contract or revision update shouldto the signed-off be numbered containers, sequentially e.g.  forC01, any C02,changes NOTE 2 The accuracy achievable using the chosen units and origins orC03 update, etc. to the signed-off containers, e.g. C1, C2, C3, etc. might need to be checked. NOTE 1 The The “C” “C” notation notation indicates indicates that th theat thecontainer container can be can used be for used for construction  andor contractual contractual purposes. purposes (e.g. Stage Completion). A.2 Space 24 • © BSI 2007 NOTE 2 There There is is provision provision to extendto extend this thiswith with project project specific specific codes. codes. 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 15.4 Project specific coding related to a specific geospatial north. NOTE The project origin is best located within or close to the project or 15.4.1 Project specific codes for status site extent. The project specific codes should not conflict with the standard codes. A.3 Geospatial 15.4.2 Project specific codes for suitability A statement or diagram should relate the project space to a named Extra suitability codes can be defined indicating other suitability for global geospatial system in three dimensions (decimal degrees latitude, use, if required, with detailed descriptions, reflecting the contractual longitude and elevation in metres) and a plan orientation (decimal arrangements. These codes should not conflict with the standard codes. degrees clockwise rotation from north) (see Figure A.1). NOTE 1 Alternatively reference can be made to a standard named 15.4.3 Project specific codes for revisions projection such as the UK Ordnance Survey grid (see http:// www.ordnancesurvey.co.uk/oswebsite/gps/information/ Extra revision codes can be defined, if required, with detailed coordinatesystemsinfo/guidecontents/guide1.html). descriptions. These codes should not conflict with the standard codes. NOTE 2 A decimal latitude in degrees requires eight decimal places to achieve positioning to within 1 mm.

Figure A.1 Geospatial referencing

26 • © The British Standards Institution 2015 26 • © BSI 2007 © The British Standards Institution 20152016 • 27

© BSI 2007 • 25 BS 1192:2007+A1:20151192:2007+A2:2016 BS 1192:2007 BS 1192:2007 BS 1192:2007+A1:2015 BS 1192:2007

Annex B (normative) Quality management B.2 Data exchange B.2 ToData avoid exchange problems associated with data exchange, participants in the B.1 Quality policy Toexchange avoid problems process should: associated with data exchange, participants in the exchange process should: Quality policy should ensure that models are maintained over their a) follow the recommendations given in this standard; lifetimes. At the outset of any project all facets of the organization of the b)a) followagree asthe early recommendations as possible which given data in shouldthis standard; be exchanged, when, project’s graphical database should be formulated by the authors of the b)and agree in as what early format; as possible which data should be exchanged, when, data with a view to satisfying end users. c) agreeand in the what version format; of format to be used for data exchange; NOTE 1 These constitute the in-house standards. Early strategic thinking c) agree the version of format to be used for data exchange; helps to ensure that all demands made on the model over its lifetime can d) establish procedures to test, monitor and report the accuracy of be met effectively and realistically. d) establishdata transfer, proced andures conduct to test, initial monitor data antransferd report trials; the accuracy of Models, which need to be maintained over long periods of time, might e) agreedata transfer, a method and of conductrecording initial each data issue transfer and receipt trials; of digital data, be subject to both major and minor updates and the same in-house e) agreeand what a method constitutes of recording an acceptable each issue transfer. and receipt of digital data, standards should be applied to these amendments in order to ensure NOTENOTEand Aspectswhat 1 See constitutes thatBS 1192:4 have beenCOBiean acceptable found for information to cause transfer. problems exchange methods.include: model integrity is preserved. NOTEa) mismatch 2 AspectsAspects betweenthat that havehave the been entities found found tosupported to cause cause problems problems by the include: sending include: system, In-house standards should be published and regularly reviewed, for a) mismatchneutral format, between and the receiving entities system;supported by the sending system, example, at the adoption of each new software release. When models b)neutral line styles format, and text, and in receiving particular, system; text justification, the manner in are to be extended to cover new topics, consideration should be given b)which line styles text andsize text,is defined, in particul and ar,special text justification,fonts; the manner in to the strategy adopted for structuring the new information and the way c)which treatment text ofsize non-graphical is defined, and data special assignment; fonts; it will be integrated. Sustained data quality requires methodical c)d) differencestreatment of in non-graphical the handling andatad specification assignment; of co-ordinate checking at the time of input and persistent discipline when changes are geometry. In particular, different software systems might have made. d) differences in the handling and specification of co-ordinate geometry.adopted different In particular, approaches different to the software specification systems of mightco-ordinate have Data quality should be checked systematically. This should include: adoptedgeometry. different The three approaches most commonly to the specificationused methods of are: co-ordinate geometry.1) real world The three dimensions; most commonly used methods are: a) elimination of spurious data outside normal file extents or limits; 1)2) realarbitrary world model dimensions; units which are scaled uniformly for all entities b) checks on file set-up parameters; 2) arbitraryin a model; model or units which are scaled uniformly for all entities c) testing of container allocations by switching on and off containers; 3) ain combination a model; or of real world dimensions and scale factors as part of an instance. d) listing of containers; 3) a combination of real world dimensions and scale factors as part of an instance. e) elimination of information which is not to scale; Annex C (informative) f) purging of all unnecessary data; Conventions for layer naming in Annex C (informative) Conventions for layer naming in g) elimination of references to un-checkable (i.e. uncontrolled) files international projects such as renditions; international projects C.1 h) formats that do not maintain dimensional integrity should not be Differences between British and international used; C.1 standardsDifferences between British and international i) other content checks. BSstandards EN ISO 13567-2 recommends the use of additional characters in each of the required fields, and a more elaborate layering structure, in NOTE 2 If an organization is registered under a formal quality BS EN ISO 13567-2 recommends the use of additional characters in management (QM) system to BS EN ISO 9001 its quality policy is clearly eachorder of to the accommodate required fields, diverse and nation a moreal elaboraterequirements layering and constructionstructure, in identified in a quality manual. Further guidance on the management of orderclassification to accommodate systems. Thisdiverse Code nation of Practiceal requirements recommends and construction the use of a the construction design process is given in BS 7000-4. classificationsimpler, ISO compatible, systems. This layer Code naming of Practice and coding recommends strategy, theto minimize use of a simpler,the number ISO of compatible, different layers layer namingused and and reduces coding complexity strategy, to when minimize data theare numberexchanged of differentbetween layersthe diff usederent and parties reduces to a complexityproject. when data are exchanged between the different parties to a project.

28 • © The British Standards Institution 20152016 © BSI 2007 • 27 28 • © BSI 2007 © The British Standards Institution 2015 • 29 28 • © BSI 2007 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007 BS 1192:2007+A1:20151192:2007+A2:2016 BS 1192:2007

Annex B (normative) Quality management B.2 Data exchange B.2 ToData avoid exchange problems associated with data exchange, participants in the B.1 Quality policy Toexchange avoid problems process should: associated with data exchange, participants in the exchange process should: Quality policy should ensure that models are maintained over their a) follow the recommendations given in this standard; lifetimes. At the outset of any project all facets of the organization of the b)a) followagree asthe early recommendations as possible which given data in shouldthis standard; be exchanged, when, project’s graphical database should be formulated by the authors of the b)and agree in as what early format; as possible which data should be exchanged, when, data with a view to satisfying end users. c) agreeand in the what version format; of format to be used for data exchange; NOTE 1 These constitute the in-house standards. Early strategic thinking c) agree the version of format to be used for data exchange; helps to ensure that all demands made on the model over its lifetime can d) establish procedures to test, monitor and report the accuracy of be met effectively and realistically. d) establishdata transfer, proced andures conduct to test, initial monitor data antransferd report trials; the accuracy of Models, which need to be maintained over long periods of time, might e) agreedata transfer, a method and of conductrecording initial each data issue transfer and receipt trials; of digital data, be subject to both major and minor updates and the same in-house e) agreeand what a method constitutes of recording an acceptable each issue transfer. and receipt of digital data, standards should be applied to these amendments in order to ensure NOTENOTEand Aspectswhat 1 See constitutes thatBS 1192:41192-4 have beenCOBiean acceptable found for information to cause transfer. problems exchange methods.include: model integrity is preserved. NOTEa) mismatch 2 AspectsAspects betweenthat that havehave the been entities found found tosupported to cause cause problems problems by the include: sending include: system, In-house standards should be published and regularly reviewed, for a) mismatchneutral format, between and the receiving entities system;supported by the sending system, example, at the adoption of each new software release. When models b)neutral line styles format, and text, and in receiving particular, system; text justification, the manner in are to be extended to cover new topics, consideration should be given b)which line styles text andsize text,is defined, in particul and ar,special text justification,fonts; the manner in to the strategy adopted for structuring the new information and the way c)which treatment text ofsize non-graphical is defined, and data special assignment; fonts; it will be integrated. Sustained data quality requires methodical c)d) differencestreatment of in non-graphical the handling andatad specification assignment; of co-ordinate checking at the time of input and persistent discipline when changes are geometry. In particular, different software systems might have made. d) differences in the handling and specification of co-ordinate geometry.adopted different In particular, approaches different to the software specification systems of mightco-ordinate have Data quality should be checked systematically. This should include: adoptedgeometry. different The three approaches most commonly to the specificationused methods of are: co-ordinate geometry.1) real world The three dimensions; most commonly used methods are: a) elimination of spurious data outside normal file extents or limits; 1)2) realarbitrary world model dimensions; units which are scaled uniformly for all entities b) checks on file set-up parameters; 2) arbitraryin a model; model or units which are scaled uniformly for all entities c) testing of container allocations by switching on and off containers; 3) ain combination a model; or of real world dimensions and scale factors as part of an instance. d) listing of containers; 3) a combination of real world dimensions and scale factors as part of an instance. e) elimination of information which is not to scale; Annex C (informative) f) purging of all unnecessary data; Conventions for layer naming in Annex C (informative) Conventions for layer naming in g) elimination of references to un-checkable (i.e. uncontrolled) files international projects such as renditions; international projects C.1 h) formats that do not maintain dimensional integrity should not be Differences between British and international used; C.1 standardsDifferences between British and international i) other content checks. BSstandards EN ISO 13567-2 recommends the use of additional characters in each of the required fields, and a more elaborate layering structure, in NOTE 2 If an organization is registered under a formal quality BS EN ISO 13567-2 recommends the use of additional characters in management (QM) system to BS EN ISO 9001 its quality policy is clearly eachorder of to the accommodate required fields, diverse and nation a moreal elaboraterequirements layering and constructionstructure, in identified in a quality manual. Further guidance on the management of orderclassification to accommodate systems. Thisdiverse Code nation of Practiceal requirements recommends and construction the use of a the construction design process is given in BS 7000-4. classificationsimpler, ISO compatible, systems. This layer Code naming of Practice and coding recommends strategy, theto minimize use of a simpler,the number ISO of compatible, different layers layer namingused and and reduces coding complexity strategy, to when minimize data theare numberexchanged of differentbetween layersthe diff usederent and parties reduces to a complexityproject. when data are exchanged between the different parties to a project.

28 • © The British Standards Institution 2015 © BSI 2007 • 27 28 • © BSI 2007 © The British Standards Institution 20152016 • 29 28 • © BSI 2007 BS 1192:2007 BS 1192:2007+A1:2015

BS 1192:2007 BS 1192:2007+A1:2015 BS 1192:2007+A1:20151192:2007+A2:2016 BS 1192:2007 BS 1192:2007 Bibliography BS 1192:2007+A1:2015 BibliographyFor dated references, only the edition cited applies. For undated Table C.1 compares the layer naming required in 5.4.4 with those references, the latest edition of the referenced document (including any recommended in BS EN ISO 13567-2. amendments)ForBibliography dated references, applies. only the edition cited applies. For undated references, the latest edition of the referencedBS 1192:2007+A1:2015 document (including any BS 1192:2007 ForBSreferences, EN dated ISO references, 4157-1,the latest Construction edition only the of edtheition drawings referenced cited applies. – document Designation For (includingundated systems any – amendments) applies. Table C.1 Differences between international and British layer naming Partreferences,amendments) 1: Buildings the applies. latest and edition parts of of the buildings referenced document (including any BS 1192:2007 BS 1192:2007+A1:2015 fields amendments)BS EN ISO 4157-1, applies. Construction drawings – Designation systems – BSamendments) EN ISO 4157-1,4157-2, applies. Construction drawings – Designation systems – Part 1: Buildings and parts of buildings Mandatory/optional Field name and Number of Field name and Number of BSBibliographyPart EN 1:2: ISO BuildingsRoom 4157-1, names and Construction and parts numbers of buildings drawings – Designation systems – field order in characters order in BS 1192 characters PartBS EN 1: ISO Buildings 4157-2, and Construction parts of buildings drawings – Designation systems – ForPartBS EN7000-4, dated 1: ISO Buildings references, 4157-2,Design and Constructionmanagement only parts the ofed buildingsition drawingssystems cited –applies. –Part Designation 4: For Guide undated tosystems – BS EN ISO 13567-2 BibliographyPart 2: Room names and numbers BS 1192:2007+A1:2015 BS 1192:2007 BSreferences,managingPart EN 2: ISO Room 4157-2,thedesign names latest inConstruction edition constructionand numbers of the drawings referenced – document Designation (including systems any – M 1. Agent responsible 2 1. Role 1 then hyphen amendments)ForPartBS 7000-4, dated 2: Room references, Design applies.names management onlyand thenumbers edition systems cited –applies. Part 4: For Guide undated to BSPart EN7000-4, 2: 82045-1, Room Design names Document management and numbers management systems –– PartPart 1:4: PrinciplesGuide to and M 2. Element 6 2. Classification 2–5 then hyphen references,managing thedesign latest in edition construction of the referenced document (including any BSmethodsmanaging EN7000-4, ISO 4157-1,designDesign inConstructionmanagement construction drawingssystems – –Part Designation 4: Guide tosystems – M 3. Presentation 2 3. Presentation 1 amendments) applies. PartBibliographymanagingBS EN 1: 82045-1, Buildings design Document andin construction parts management of buildings – Part 1: Principles and BSmanaging EN 82045-2,82045-1, design Document in construction management – Part 2:1: MetadataPrinciples and O 10. User defined Unlimited 4. Description Underscore then BSmethods EN ISO 4157-1, Construction drawings – Designation systems – ForBSelements EN dated ISO82045-1, andreferences, 4157-2, informat Document Construction onlyion the managementreference edition drawings cited model – applies. Part– Designation 1: ForPrinciples undated systems and – unlimited Part 1: Buildings and parts of buildings methodsBSPart EN 2: 82045-2, Room names Document and numbers management – Part 2: Metadata references,BSmethods EN ISO82045-2, 13567-1,the latest Document editionTechnical managementof the product referenced documentation – Part document 2: Metadata (including – any BSelements EN ISO and 4157-2, informat Constructionion reference drawings model – Designation systems – amendments)BSOrganizationelements EN7000-4, 82045-2, and Design applies.informatand Document managementnamingion management referenceof laye systemsrs formodel CAD –– PartPart – Part 2:4: MetadataGuide 1: Overview to C.2 Managing the relationship between British and Part 2: Room names and numbers international structures BSandelementsmanaging EN principles ISO and 4157-1,13567-1,design informat inConstruction Technical constructionion reference product drawings model documentation – Designation – systems – OrganizationBS 7000-4, Design and managementnaming of laye systemsrs for CAD – Part – Part 4: Guide 1: Overview to PartBSOrganization EN 1: ISO82045-1, Buildings 13567-2,13567-1, and Document and naming Technical parts managementof of laye productbuildingsrs for documentation CAD– Part – Part1: Principles 1: Overview– and A UK organization working on an international project, to which andmanaging principles design in construction Organizationmethodsand principles and naming of layers for CAD – Part 1:2: OverviewConcepts, BS EN ISO 13567-2 code conventions for layering are to be applied, can BS EN ISO 4157-2, Construction drawings – Designation systems – andformatBS EN principles ISO82045-1, and 13567-2, codes Document used Technical in constructionmanagement product documentationdocumentation – Part 1: Principles – and convert layers for export in a straightforward manner because the layer BSPart EN 2: 82045-2, Room names Document and numbers management – Part 2: Metadata Organizationmethods and naming of layers for CAD – Part 2: Concepts, structure in 5.4.4 is a subset of the ISO structure. Data received from BSelements EN7000-4, ISO and 13567-2,9001,Design informat Quality management Technicalion manage reference product systemsment model documentationsystems – Part 4: Guide – to OrganizationBSformat EN 82045-2, and codes and Document used naming in constructionmanagement of layers for documentation CAD– Part – Part2: Metadata 2: Concepts, overseas organizations can be converted to this structure, but some loss BSmanagingOrganization ENISO ISO12006-2, 13567-1,design and Building innaming Technical construction construction of laye productrs for documentation– CAD Organization – Part 2: Concepts,–of formatBSelements EN ISO and and 9001, codes informat Quality used ionin manage construction referencement model systemsdocumentation of layer structuring information is likely to occur. UK organizations BSinformationOrganization EN 82045-1, about and Document namingconstruction managementof laye worksrs for – CADPart– Part –2: Part1: Framework Principles 1: Overview forand might therefore be obliged to use a more complex and unfamiliar methodsclassificationBSand ENISO principles ISO12006-2, 13567-1,9001, of BuildinginformationQuality Technical manage construction productment documentationsystems– Organization –of structure. In such circumstances, it is useful for the project teams to informationOrganization about and namingconstruction of laye worksrs for – CADPart –2: Part Framework 1: Overview for BS ISOEN ISO82045-2,31,12006-2, 13567-2,Quantities DocumentBuilding Technical and construction managementunits product documentation– –Organization Part 2: Metadata –of agree at an early stage how they will allocate named containers for and principles informationOrganizationclassification about ofand information namingconstruction of laye worksrs for – CADPart –2: Part Framework 2: Concepts, for specific projects and document these. It is likely that software will be ISOelementsinformation 82045-5, and aboutDocument informat constructionion management reference works model – – Part Part 5: 2: Application Framework of for classificationBSformat ISOEN ISO 31,and 13567-2,Quantities codes of information used Technical and in constructionunits product documentationdocumentation – used for converting between the standards. BSmetadata EN ISO for13567-1, the construction Technical productand facility documentation management – sector Organization and naming of layers for CAD – Part 2: Concepts, OrganizationBSISO ISOEN 82045-5, ISO31, 9001,Quantities Document and Quality naming and management manage unitsof layementrs for – systems PartCAD 5:– PartApplication 1: Overview of NOTE BS EN ISO 13567 parts 1 and 2 contain many detailed format[1] GREAT and BRITAIN: codes used JCT in 2005 construction – Major Project documentation Sub-Contract metadata for the construction and facility management sector recommendations on how to exchange data internationally. ISOBSandmetadata ISO (MPSub/G). 82045-5,principles 12006-2, for Documentthe London: Building construction RICSmanagement construction Books. and facility – –Part Organization management 5: Application of sector of BS EN ISO 9001, Quality management systems Layer management software software provides provides options options for for converting converting ISO ISO layers layers BSmetadata[1]information EN GREAT ISO for 13567-2,BRITAIN: about the construction construction Technical JCT 2005 product–an Majorworksd facility Project–documentation Part management 2:Sub-Contract Framework – sector for   classificationBS ISO(MPSub/G). 12006-2, of London: Buildinginformation RICS construction Books. – Organization of to BSto layers1192:2007 as in thislayers. British Standard . Further[1]Organization(MPSub/G). GREAT reading BRITAIN: and London: naming JCT RICS 2005 of Books. laye – Majorrs for Project CAD –Sub-Contract Part 2: Concepts, information about construction works – Part 2: Framework for CONSTRUCTIONBSformat ISO(MPSub/G). 31,and Quantities codes London: PROJECT used and inRICS construction unitsINFORMATION Books. documentation COMMITTEE. Uniclass: Furtherclassification reading of information UnifiedISOBS EN 82045-5, ISO classification 9001, Document Quality for management managethe constructionment – systemsPart industry, 5: Application 1998. London. of CONSTRUCTIONFurtherBS ISO 31, reading Quantities PROJECT and unitsINFORMATION COMMITTEE. Uniclass: AvailableCONSTRUCTIONBSmetadata ISO 12006-2, from: for the The Building PROJECTconstruction Association construction INFORMATION ofan Consultingd facility – Organization COMMITTEE. management Engineers. of Uniclass: sector UnifiedISO 82045-5, classification Document for management the construction – Part industry, 5: Application 1998. London. of CONSTRUCTION[1]information GREAT BRITAIN: about PROJECT construction JCT 2005 INFORMATION – Majorworks Project– Part COMMITTEE. 2:Sub-Contract Framework Uniclass:A Code for of Availablemetadata from: for the The construction Association ofan Consultingd facility management Engineers. sector ProcedureUnifiedclassification(MPSub/G). classification for ofthe London: information Construction for RICS the Books.construction Industry. London. industry, RIBA 1998 Bookshops. London. AvailableCONSTRUCTION from: The PROJECT Association INFORMATION of Consulting COMMITTEE. Engineers. A Code of Availablewww.ribabookshops.comCONSTRUCTIONBS[1] ISO GREAT 31, from: QuantitiesBRITAIN: The PROJECT Association JCT and 2005 unitsINFORMATION of– Major Consulting Project COMMITTEE. Engineers. Sub-Contract A Code of Procedure for the Construction Industry. London. RIBA Bookshops CONSTRUCTIONFurtherProcedure(MPSub/G). reading for the London: PROJECT Construction RICS INFORMATION Books. Industry. London. COMMITTEE. RIBA Bookshops A Code of www.ribabookshops.comISO 82045-5, Document management – Part 5: Application of Procedurewww.ribabookshops.com for the Construction Industry. London. RIBA Bookshops FurtherCONSTRUCTIONmetadata reading for the PROJECTconstruction INFORMATION and facility COMMITTEE. management Uniclass: sector Unifiedwww.ribabookshops.com classification for the construction industry, 1998. London. [1] GREAT BRITAIN: JCT 2005 – Major Project Sub-Contract AvailableCONSTRUCTION from: The PROJECT Association INFORMATION of Consulting COMMITTEE. Engineers. Uniclass: (MPSub/G). London: RICS Books. Unified classification for the construction industry, 1998. London. CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of Available from: The Association of Consulting Engineers. FurtherProcedure reading for the Construction Industry. London. RIBA Bookshops www.ribabookshops.comCONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of CONSTRUCTION PROJECT INFORMATION COMMITTEE. Uniclass: Procedure for the Construction Industry. London. RIBA Bookshops Unified classification for the construction industry, 1998. London. www.ribabookshops.com Available from: The Association of Consulting Engineers. CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of Procedure for the Construction Industry. London. RIBA Bookshops 30 • © BSI 2007 www.ribabookshops.com © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31 30 • © The British Standards Institution 20152016 © BSI 2007 • 29 30 • © BSI 2007 © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31 BS 1192:2007 BS 1192:2007+A1:2015

BS 1192:2007 BS 1192:2007+A1:2015 BS 1192:2007+A1:2015 BS 1192:2007 BS 1192:2007 Bibliography BS 1192:2007+A1:20151192:2007+A2:2016 BibliographyFor dated references, only the edition cited applies. For undated Table C.1 compares the layer naming required in 5.4.4 with those references, the latest edition of the referenced document (including any recommended in BS EN ISO 13567-2. amendments)ForBibliography dated references, applies. only the edition cited applies. For undated references, the latest edition of the referencedBS 1192:2007+A1:2015 document (including any BS 1192:2007 ForBSreferences, EN dated ISO references, 4157-1,the latestConstruction edition only the of editionthe drawings referenced cited applies. – document Designation For (includingundated systems any – amendments) applies. Table C.1 Differences between international and British layer naming Partreferences,amendments) 1: Buildings the applies. latest and edition parts of of the buildings referenced document (including any BS 1192:2007 BS 1192:2007+A1:2015 fields amendments)BS EN ISO 4157-1, applies.Construction drawings – Designation systems – BSamendments) EN ISO 4157-1,4157-2, applies. Construction drawings – Designation systems – Part 1: Buildings and parts of buildings Mandatory/optional Field name and Number of Field name and Number of BSBibliographyPart 1192-4,EN 2: ISO Room Collaborative4157-1, names Construction and production numbers drawings of information – Designation - Part 4: systems – field order in characters order in BS 1192 characters FulfillingPartBS EN 1: ISO Buildings employer’s 4157-2, and Construction information parts of buildings drawings exchange –requirements Designation using systems – BS EN ISO 13567-2 ForBS 7000-4, dated references,Design management only the edition systems cited –applies. Part 4: For Guide undated to COBibliographyPartBie 2: RoomCode ofnames practice and numbers BS 1192:2007+A1:2015 BS 1192:2007 BSreferences,managingPart EN 2: ISO– Room 4157-2,thedesign names latest inConstruction edition constructionand numbers of the drawings referenced – document Designation (including systems any – M 1. Agent responsible 2 1. Role 1 then hyphen amendments)ForPartBS 7000-4, dated 2: Room references, Design applies.names management onlyand thenumbers edition systems cited –applies. Part 4: For Guide undated to BSPart EN7000-4, 2: 82045-1,RoomDesign namesDocument management and numbers management systems –– PartPart 1:4: PrinciplesGuide to and M 2. Element 6 2. Classification 2–5 then hyphen references,managing thedesign latest in edition construction of the referenced document (including any BSmethodsmanaging EN7000-4, ISO 4157-1,designDesign inConstructionmanagement construction drawingssystems – –Part Designation 4: Guide tosystems – M 3. Presentation 2 3. Presentation 1 amendments) applies. PartBibliographymanagingBS EN 1: 82045-1, Buildings design Document andin construction parts management of buildings – Part 1: Principles and BSmanaging EN 82045-2,82045-1, design Document in construction management – Part 2:1: MetadataPrinciples and O 10. User defined Unlimited 4. Description Underscore then BSmethods EN ISO 4157-1, Construction drawings – Designation systems – ForBSelements EN dated ISO 82045-1, andreferences, 4157-2, informatDocument Construction onlyion the managementreference edition drawings cited model – applies. Part– Designation 1: ForPrinciples undated systems and – unlimited Part 1: Buildings and parts of buildings methodsBSPart EN 2: 82045-2,Room namesDocument and numbers management – Part 2: Metadata references,BSmethods EN ISO82045-2, 13567-1,the latest Document editionTechnical managementof the product referenced documentation – Part document 2: Metadata (including – any BSelements EN ISO and 4157-2, informat Constructionion reference drawings model – Designation systems – amendments)BSOrganizationelements EN7000-4, 82045-2, andDesign applies.informat andDocument managementnamingion managementreference of laye systemsrs formodel CAD –– PartPart – Part 2:4: MetadataGuide 1: Overview to C.2 Managing the relationship between British and Part 2: Room names and numbers international structures BSandelementsmanaging EN principles ISO and 4157-1,13567-1,design informat inConstruction Technical constructionion reference product drawings model documentation – Designation – systems – OrganizationBS 7000-4, Design and managementnaming of laye systemsrs for CAD – Part – Part 4: Guide 1: Overview to PartBSOrganization EN 1: ISO 82045-1,Buildings 13567-2,13567-1, andDocument and naming Technical parts management of of laye productbuildingsrs for documentation CAD– Part – Part1: Principles 1: Overview – and A UK organization working on an international project, to which andmanaging principles design in construction Organizationmethodsand principles and naming of layers for CAD – Part 1:2: OverviewConcepts, BS EN ISO 13567-2 code conventions for layering are to be applied, can BS EN ISO 4157-2, Construction drawings – Designation systems – andformatBS EN principles ISO 82045-1, and 13567-2, codesDocument used Technical in constructionmanagement product documentationdocumentation – Part 1: Principles – and convert layers for export in a straightforward manner because the layer BSPart EN 2: 82045-2,Room namesDocument and numbers management – Part 2: Metadata Organizationmethods and naming of layers for CAD – Part 2: Concepts, structure in 5.4.4 is a subset of the ISO structure. Data received from BSelements EN7000-4, ISO and 13567-2,9001,Design informat Quality management Technicalion manage reference product systemsment model documentationsystems – Part 4: Guide – to OrganizationBSformat EN 82045-2, and codes andDocument used naming in construction management of layers for documentation CAD– Part – Part2: Metadata 2: Concepts, overseas organizations can be converted to this structure, but some loss BSmanagingOrganization ENISO ISO12006-2, 13567-1,design and Building innaming Technical construction construction of laye productrs for documentation– CAD Organization – Part 2: Concepts,–of formatBSelements EN ISO and and 9001, codes informat Quality used ionin manage construction referencement model systemsdocumentation of layer structuring information is likely to occur. UK organizations BSinformationOrganization EN 82045-1, about andDocument namingconstruction managementof laye worksrs for – CADPart– Part –2: Part1: Framework Principles 1: Overview forand might therefore be obliged to use a more complex and unfamiliar methodsclassificationBSand ENISO principles ISO12006-2, 13567-1,9001, of BuildinginformationQuality Technical manage construction productment documentationsystems– Organization –of structure. In such circumstances, it is useful for the project teams to informationOrganization about and namingconstruction of laye worksrs for – CADPart –2: Part Framework 1: Overview for BS ISOEN ISO82045-2,31,12006-2, 13567-2,Quantities DocumentBuilding Technical and construction managementunits product documentation– –Organization Part 2: Metadata –of agree at an early stage how they will allocate named containers for and principles informationOrganizationclassification about ofand information namingconstruction of laye worksrs for – CADPart –2: Part Framework 2: Concepts, for specific projects and document these. It is likely that software will be ISOelementsinformation 82045-5, and aboutDocument informat constructionion management reference works model – – Part Part 5: 2: Application Framework of for classificationBSformat ISOEN ISO 31,and 13567-2,Quantities codes of information used Technical and in constructionunits product documentationdocumentation – used for converting between the standards. BSmetadata EN ISO for13567-1, the construction Technical productand facility documentation management – sector Organization and naming of layers for CAD – Part 2: Concepts, OrganizationBSISO ISOEN 82045-5, ISO31, 9001,Quantities Document and Quality naming and management manage units of layementrs for – systems PartCAD 5:– PartApplication 1: Overview of NOTE BS EN ISO 13567 parts 1 and 2 contain many detailed format[1] GREAT and BRITAIN: codes used JCT in 2005 construction – Major Project documentation Sub-Contract metadata for the construction and facility management sector recommendations on how to exchange data internationally. ISOBSandmetadata ISO (MPSub/G). 82045-5,principles 12006-2, for Documentthe London: Building construction RICSmanagement construction Books. and facility – –Part Organization management 5: Application of sector of BS EN ISO 9001, Quality management systems Layer management software provides options for converting ISO layers BSmetadata[1]information EN GREAT ISO for 13567-2,BRITAIN: about the construction construction Technical JCT 2005 product–an Majorworksd facility Project–documentation Part management 2:Sub-Contract Framework – sector for classificationBS ISO(MPSub/G). 12006-2, of London: Buildinginformation RICS construction Books. – Organization of to BS 1192:2007 layers. PASFurther[1]Organization (MPSub/G).GREAT1192-2, reading BRITAIN:Specification and London: naming JCT RICS for2005 of information Books. laye – Majorrs for Project CADmanagement –Sub-Contract Part 2: for Concepts, the information about construction works – Part 2: Framework for capital/deliveryCONSTRUCTIONBSformat ISO(MPSub/G). 31, and Quantities codes London: phasePROJECT used andof inRICS construction construction unitsINFORMATION Books. projects documentation COMMITTEE. using building Uniclass: informationFurtherclassification reading modelling of information UnifiedISOBS EN 82045-5, ISO classification 9001, Document Quality for management managethe constructionment – systemsPart industry, 5: Application 1998. London. of CONSTRUCTIONFurtherBS ISO 31, reading Quantities PROJECT and unitsINFORMATION COMMITTEE. Uniclass: AvailableCONSTRUCTIONBSmetadata PASISO 1192-5:2015,12006-2, from: for the The Building PROJECTconstruction Association Specification construction INFORMATION ofan Consultingford facility security-minded – Organization COMMITTEE. management Engineers. building of Uniclass: sector informationUnifiedISO 82045-5, classification modelling, Document for digital management the construction built environments – Part industry, 5: Application and 1998 smart. London. ofasset CONSTRUCTION[1]information GREAT BRITAIN: about PROJECT construction JCT 2005 INFORMATION – Majorworks Project– Part COMMITTEE. 2:Sub-Contract Framework Uniclass:A Code for of managementAvailablemetadata from: for the The construction Association ofan Consultingd facility management Engineers. sector ProcedureUnifiedclassification(MPSub/G). classification for ofthe London: information Construction for RICS the Books.construction Industry. London. industry, RIBA 1998 Bookshops. London. AvailableCONSTRUCTION from: The PROJECT Association INFORMATION of Consulting COMMITTEE. Engineers. A Code of Availablewww.ribabookshops.comCONSTRUCTIONBS[1] ISO GREAT 31, from: QuantitiesBRITAIN: The PROJECT Association JCT and 2005 unitsINFORMATION of– Major Consulting Project COMMITTEE. Engineers. Sub-Contract A Code of Procedure for the Construction Industry. London. RIBA Bookshops CONSTRUCTIONFurtherProcedure(MPSub/G). reading for the London: PROJECT Construction RICS INFORMATION Books. Industry. London. COMMITTEE. RIBA Bookshops A Code of www.ribabookshops.comISO 82045-5, Document management – Part 5: Application of Procedurewww.ribabookshops.com for the Construction Industry. London. RIBA Bookshops FurtherCONSTRUCTIONmetadata reading for the PROJECTconstruction INFORMATION and facility COMMITTEE. management Uniclass: sector Unifiedwww.ribabookshops.com classification for the construction industry, 1998. London. [1] GREAT BRITAIN: JCT 2005 – Major Project Sub-Contract AvailableCONSTRUCTION from: The PROJECT Association INFORMATION of Consulting COMMITTEE. Engineers. Uniclass: (MPSub/G). London: RICS Books. Unified classification for the construction industry, 1998. London. CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of Available from: The Association of Consulting Engineers. FurtherProcedure reading for the Construction Industry. London. RIBA Bookshops www.ribabookshops.comCONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of CONSTRUCTION PROJECT INFORMATION COMMITTEE. Uniclass: Procedure for the Construction Industry. London. RIBA Bookshops Unified classification for the construction industry, 1998. London. www.ribabookshops.com Available from: The Association of Consulting Engineers. CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of Procedure for the Construction Industry. London. RIBA Bookshops 30 • © BSI 2007 www.ribabookshops.com © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31 30 • © The British Standards Institution 2015 © BSI 2007 • 29 30 • © BSI 2007 © The British Standards Institution 20152016 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31

30 • © BSI 2007 © The British Standards Institution 2015 • 31 BS 1192:2007+A2:2016

32 • © The British Standards Institution 2016 This page deliberately left blank BS 1192:2007+A2:2016

This page deliberately left blank NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

British Standards Institution (BSI) BSI is the national body responsible for preparing British Standards and other standards-related publications, information and services. BSI is incorporated by Royal Charter. British Standards and other standardization products are published by BSI Standards Limited.

About us Revisions We bring together business, industry, government, consumers, innovators Our British Standards and other publications are updated by amendment or revision. and others to shape their combined experience and expertise into standards We continually improve the quality of our products and services to benefit your -based solutions. business. If you find an inaccuracy or ambiguity within a British Standard or other The knowledge embodied in our standards has been carefully assembled in BSI publication please inform the Knowledge Centre. a dependable format and refined through our open consultation process. Organizations of all sizes and across all sectors choose standards to help Copyright them achieve their goals. All the data, software and documentation set out in all British Standards and other BSI publications are the property of and copyrighted by BSI, or some person Information on standards or entity that owns copyright in the information used (such as the international We can provide you with the knowledge that your organization needs standardization bodies) and has formally licensed such information to BSI for to succeed. Find out more about British Standards by visiting our website at commercial publication and use. Except as permitted under the Copyright, Designs bsigroup.com/standards or contacting our Customer Services team or and Patents Act 1988 no extract may be reproduced, stored in a retrieval system Knowledge Centre. or transmitted in any form or by any means – electronic, photocopying, recording or otherwise – without prior written permission from BSI. Details and advice can Buying standards be obtained from the Copyright & Licensing Department. You can buy and download PDF versions of BSI publications, including British and adopted European and international standards, through our website at Useful Contacts: bsigroup.com/shop, where hard copies can also be purchased. Customer Services If you need international and foreign standards from other Standards Development Tel: +44 845 086 9001 Organizations, hard copies can be ordered from our Customer Services team. Email (orders): [email protected] Email (enquiries): [email protected] Subscriptions Subscriptions Our range of subscription services are designed to make using standards Tel: +44 845 086 9001 easier for you. For further information on our subscription products go to Email: [email protected] bsigroup.com/subscriptions. With British Standards Online (BSOL) you’ll have instant access to over 55,000 Knowledge Centre British and adopted European and international standards from your desktop. Tel: +44 20 8996 7004 It’s available 24/7 and is refreshed daily so you’ll always be up to date. Email: [email protected] You can keep in touch with standards developments and receive substantial Copyright & Licensing discounts on the purchase price of standards, both in single copy and subscription format, by becoming a BSI Subscribing Member. Tel: +44 20 8996 7070 Email: [email protected] PLUS is an updating service exclusive to BSI Subscribing Members. You will automatically receive the latest hard copy of your standards when they’re revised or replaced. To find out more about becoming a BSI Subscribing Member and the benefits of membership, please visit bsigroup.com/shop. With a Multi-User Network Licence (MUNL) you are able to host standards publications on your intranet. Licences can cover as few or as many users as you wish. With updates supplied as soon as they’re available, you can be sure your documentation is current. For further information, email [email protected].

BSI Group Headquarters 389 Chiswick High Road London W4 4AL UK