BS1192:2007

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

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 List of tables Table 1 – Naming of directories and folder containers 15 Table 2 – Naming of file 15 Table 3 – Naming of containers within files including layers 16 Table 4 – Examples of field usage 16 Table 5 – Standard codes for suitability models and documents 25 Table C.1 – Differences between international and British layer naming fields 30

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

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

Foreword Foreword BS 1192:2007 Foreword Publishing information Foreword Publishing information isispublished Standards Limited, under This British British Standard Standard publishedbybyBSI BSI and came into effect BSeffect 1192:2007 Publishing information This published

by BSI came into licence from Standard The British Standards Institution and came into effect B/555, on on 31British December 2007.isIt was prepared byand Technical Committee Publishing information on 31 December 2007.

It was prepared by Technical Committee B/555, British published byand BSI Standards Limited, under 31 December 2007.

Itiswas prepared by Technical Committee B/555, This British Standard Standard ismodelling published by BSI andexchange. came into Aeffect Construction design, data list of Foreword This ismodelling published by data BSI came into Construction design, and data exchange.

Aeffect list ofrequest licence from Standard The British Standards Institution and came effect on Construction design, modelling and exchange.

Ainto list ofon on 31British December 2007.

It was prepared byand Technical Committee B/555, organizations represented on this committee can be obtained on 31 December 2007.

It on was prepared

by Technical Committee B/555, 31 its December 2007.

It was prepared

by Technical Committee B/555, organizations represented committee can be onon request organizations represented onthis this committee can beobtained obtained request Construction design, modelling and data exchange.

A list of to secretary.

Foreword Publishing information

Construction design,modelling and data exchange.

Aeffect list ofrequest Construction design, exchange.

A list ofon its secretary. to itsBritish secretary. organizations represented on thisand committee can be obtained This Standard ismodelling published by data BSI and came into Supersession organizations represented on this committee can be obtained on request organizations represented on this committee can be obtained on to Publishing information on its 31secretary.

December 2007. It was prepared by Technical Committeerequest B/555, Supersession its secretary. to itsBritish secretary.

This Standard is This British Standard ismodelling publishedBS by1192-5:1998, BSI andexchange. camewhich into Aeffect Construction design,supersedes and data listwithdrawn. of Supersession 1192:2007+A2:2016 1192:2007+A1:2015, which BS 31 1192:2007+A1:2015 1192:2007, isiswithdrawn.

This British Standard supersedes BSBS 1192-5:1998, which withdrawn. on December 2007.

Itsupersedes was prepared

by Technical Committee B/555, organizations represented on this committee can bewhich obtained on request Supersession Relationship withsupersedes other publications is withdrawn.

This British Standard BS 1192-5:1998, which is withdrawn.

Construction to its secretary.design, modelling and data exchange. A list of Relationship within other publications Information about this document BS 1192:2007+A1:2015 supersedes 1192:2007, isiswithdrawn.

This BritishisStandard supersedes BS 1192-5:1998, which withdrawn.

Copyright claimed Figures toBS 9.

Reproduction of these organizations represented on this1committee can bewhich obtained on request Relationship with other publications Information about this document Copyright isand claimed in Figures 1 from to 9. it Reproduction of that these Text or altered

by Amendment No. 1 isinfringe indicated in the text by illustrations making products might copyright.

Supersession to itsintroduced secretary.

Relationship with other publications Information about this document illustrations and making products from it might infringe that copyright.

Copyright is claimed in Figures 1 to 9.

Reproduction of these Text introduced or altered by Amendments No. 1 and No. 2, respectively tags  .

Minor editorial changes are not tagged.

Details of the copyright owner (from whom any permission to use this This British Standard supersedes BS 1192-5:1998, which is withdrawn.

Copyright is claimed in Figures 1 to 9.

Reproduction of these Details of the copyright owner (from whom any permission to use this Text introduced or altered by Amendment No. 1 is indicated in the text by are indicated in the text by tags  and  .

Minor editorial illustrations and making products from it might infringe that copyright. illustration may be sought) can be obtained by contacting the Supersession illustrations and making products from it might infringe that copyright. illustration may be sought) can be obtained by contacting the tags  . not Minor editorial changes not tagged. changes are tagged.

Details of the copyright owner (from whom any permission to use this BSI Library, British Standards House, 389 Chiswick High is Road, Relationship with other publications This British Standard supersedes BSare 1192-5:1998, which withdrawn.

Details of the copyright owner (from whom any permission to use this BSI Library, British Standards House, 389 Chiswick High Road, illustration may be sought) can be obtained by contacting the London W4 4AL. Copyright is claimed in Figures 1 to 9. Reproduction of these illustration may be sought) can be obtained by contacting the London W4 4AL. BSI Library, British Standards House, 389 Chiswick High Road, Relationship with other publications illustrations making products from it might infringe that copyright.

The changesand incorporated in this revised standard include: BSI Library, British Standards House, 389 Chiswick High Road, London W4 Copyright is4AL. claimed in Figures 1 revised to 9.whom Reproduction of these Details of the copyright owner (from any permission to use this The changes incorporated in this standard include: • W4 Management processes to support collaborative working.

London 4AL. illustrations and making products from it might infringe that copyright. illustration may be sought) berevised obtained by contacting the The • changes incorporated incan this standard include: Management processes to support collaborative working.

• controlled naming to files and directories, Details ofExtending theBritish copyright owner (from whom any permission to as usewell this The Library, changes incorporated in this revised standard include: BSI Standards House, 389 Chiswick High Road, • Management processes to support collaborative working.

• Extending controlled naming to files and directories, as well as layers sub-models. illustration may beand sought) can be obtained by contacting the London W4 4AL. • Management processes to support collaborative working. layers and sub-models.

• as Extending controlled naming to files and directories, as well BSI Library, British Standards House, 389 Chiswick High Road, • Compatibility withinBS ENrevised 82045-2 and ISO 82045-5.

The • changes incorporated this standard include: Extending controlled naming to files and directories, as well as layers and sub-models.

London 4AL. • W4 Compatibility with BS EN 82045-2 and ISO 82045-5.

• Incorporation of BS ISOto12006-2 classification as layers and processes sub-models.

Management supportcompliant collaborative working.

Compatibility with EN12006-2 82045-2 and ISO 82045-5.

The • changes incorporated inBS this revised standard include: • Incorporation BS ISO compliant classification tables, such asof Uniclass.

• Compatibility with BSnaming EN 82045-2 and ISO 82045-5. as well Extending controlled to files and directories, tables, such as Uniclass.

• Incorporation of BS ISO 12006-2 compliant classification Management processes to support collaborative • Recommendations for implementation of BS EN working.

ISO 13567-2. as layers and sub-models.

• Incorporation of BS ISO 12006-2 compliant classification tables, such as Uniclass.

• Recommendations for implementation of BS EN ISO 13567-2.

• Extending controlled naming to files and directories, as well tables, such aswith Uniclass.

Compatibility BS EN 82045-2 and ISO 82045-5.

Use• of this document • Recommendations for implementation of BS EN ISO 13567-2. as layers and sub-models.

Use of Incorporation this document Recommendations for implementation ofthe BS classification EN ISO 13567-2. of BS ISO 12006-2 As a •Code of Practice, this British Standardcompliant takes form of guidance • Compatibility with BS EN 82045-2 and ISO 82045-5.

Use of tables, this document such asthis As Code of Practice, Britishnot Standard takes anda recommendations.

ItUniclass. should be quoted as the if itform wereofa guidance Use of Incorporation this document •Code of BS ISOnot 12006-2 and It should be quoted as if itclassification were a guidance As a recommendations. of Practice, this British Standard takes the form of specification and particular care should becompliant taken that claims • Recommendations for implementation ofto BSensure EN ISO 13567-2. tables, such As a recommendations.

Code of Practice, this British Standard takes the specification and particular care not should be taken that claims andcompliance ItUniclass. should be quoted asto if ensure itform wereof a guidance of are notasmisleading. and recommendations.

It should not be quoted as if it were a of compliance are not misleading. specification and particular care should be taken to ensure that claims Use of this document forwith implementation of BS ENisISO 13567-2.

Any • userRecommendations claiming compliance this British Standard expected to specification and particular care should be taken to ensure that claims of compliance are not misleading.

As a Code of Practice, this British Standard takes the form of guidance Any user claiming compliance with this British Standard is expected to be able to justify any course of action that deviates from its of compliance are not misleading.

Use of this document andable recommendations.

It should notthis bethat quoted as iffrom it were a be justify any course ofwith action deviates itsexpected Any usertoclaiming compliance British Standard is to recommendations.

As a user Code of Practice, this British Standard takes the form of guidance Any compliance thisthat British Standard is to specification and any particular care should bedeviates taken to ensure that claims recommendations. be able toclaiming justify course ofwith action from itsexpected Presentational conventions and recommendations.

It should not bethat quoted as iffrom it were be able to justify course of action deviates its a of compliance areany not misleading. recommendations.

Presentational conventions specification and careare should be taken to ensure that claims recommendations.

The in particular this standard roman (i.e. upright) Any provisions user claiming compliance with presented this BritishinStandard is expected to Presentational conventions of compliance are not standard misleading.

The provisions inany this are presented in roman (i.e. upright) type.

Itstorecommendations are expressed indeviates sentences in which the be able justify course of action that from its Presentational conventions type.

Its recommendations are with expressed in sentences the to The in this standard are presented inStandard romanin (i.e. upright) principal auxiliary verb is “should”.

Any provisions user claiming compliance this British iswhich expected recommendations.

The provisions in this standard are presented in roman (i.e. upright) principal auxiliary verb is “should”. type.

Its recommendations are expressed in sentences in which the be able to justify any course of action that informative deviates frommaterial its Commentary, explanation and general is type.

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

Presentational conventions recommendations.

Commentary, explanation informative material is presented in smaller italic and type,general and does not constitute a principal auxiliary verbstandard is “should”.

The provisions in this aregeneral presented in roman (i.e. upright) presented in smaller italic and type, and does not constitute a Commentary, explanation informative material is normative element.

Presentational conventions Commentary, explanation and general type.

Its recommendations expressed ininformative sentences inmaterial which normative element. presented in smaller italicare type, and does not constitute a theis The word “should” is used to express recommendations of this standard.

The provisions in this are and presented in roman (i.e. upright) presented in smaller italic type, does not constitute a principal auxiliary verbstandard is “should”. normative element. usedintothe express of thise.g. standard.

The word “should” “may” is is used text torecommendations express permissibility, as an type.

Its recommendations are expressed in sentences in which the normative element.

Commentary, explanation and informative isan The “may” isprimary used the textgeneral torecommendations express as word “should” is usedinto express ofmaterial this standard. alternative to the recommendation of permissibility, the clause.

Thee.g. word principal auxiliary verb is “should”.

The word “should” is used to express recommendations ofofthis standard. presented in smaller italic type, does alternative to to the recommendation ofnot theconstitute clause.

The word “may” isprimary used in the text and toe.g. express permissibility, as an “can” is used express possibility, a consequence anae.g. action or Commentary, explanation and general informative material is The word “may” is used in the text to express permissibility, e.g. as an normative element. “can” is used to express possibility, e.g. a consequence of an action alternative an event. to the primary recommendation of the clause. The word or presented in smaller italic type, and does alternative to to the primary recommendation ofnot theconstitute clause.

The word or an “can” is used express a consequence anastandard. action Theevent. word “should” is usedpossibility, to expresse.g. recommendations ofofthis normative element. “can” is used to express possibility, e.g. a consequence of an action or an event.

The word “may” is used in the text to express permissibility, e.g. as an an event.

The word “should” is used to express recommendations of this alternative to the primary recommendation of the clause.

Thestandard. word

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

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

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

BS 1192:2007

Commentary, explanation and general informative material is presented in smaller italic type, and does not constitute a normative element.

The word “should” is used to express recommendations of this standard.

The word “may” is used in the text to express permissibility, e.g. as an alternative to the primary recommendation of the clause. The word “can” is used to express possibility, e.g. a consequence of an action or an event.

Notes and commentaries are provided throughout the text of this standard. Notes give references and additional information that are important but do not form part of the recommendations. Commentaries © BSI 2007 • iii give background information.

Contractual and legal considerations This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.

Compliance with a British Standard cannot confer immunity from legal obligations.

iv • 2016 iv • © The British Standards Institution 2015

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

Introduction Introduction Collaboration between the participants in construction projects is

Collaboration between delivery the participants in construction projects pivotal to the efficient of facilities.

Organizations are is pivotal to theworking efficientindelivery of facilities.environments Organizationsinare increasingly new collaborative order to increasingly working in new collaborative environments order to achieve higher standards of quality and greater re-use ofin existing achieve higher of Aquality greater re-use of collaborative existing knowledge and standards experience. majorand constituent of these knowledge andisexperience.

A communicate, major constituent of these collaborative environments the ability to re-use and share data environments is theloss, ability to communicate, re-use and share data efficiently without contradiction or misinterpretation. efficiently without loss, contradiction or misinterpretation.

Each year considerable resources are spent on making corrections to Each year considerable resources are spentinonapproved making corrections to non-standard data, training new personnel data creation non-standardco-ordinating data, trainingthe new personnel in approvedteams data creation techniques, efforts of subcontractor and techniques, co-ordinating the efforts of subcontractor teams and solving problems related to data reproduction. solving problems related to data reproduction.

The use of this standard is particularly applicable where technology The use processes of this standard is particularly applicableThese where technology enabled are used to support projects. processes enabled processes are used to support projects. These processes include: include: • automation 3D model, data, drawing and document automationof of drawing and document production processes; • production automationprocesses; of drawing and document production processes; • indexing and searching project material; • indexing and searching project material; • filtering and sorting; • filtering and sorting; • quality checking and document comparisons.

• quality checking and document comparisons.

Where the implementation of standards is adequately addressed, there Where the implementation of standards is adequately addressed, there are significant benefits to both the productivity of project teams and the are significant to both the productivity of project teams and the profitability of benefits the organization. profitability of the organization.

This standard applies to all construction project documentation. The set This standard applies to alleach construction project of project documents and document withindocumentation. it are viewed asThe a set of project of documents and each Itdocument within it are viewed as a hierarchy named containers. gives recommendations for structured hierarchy of named containers.

It gives recommendations for structured names to convey information (meta-data) about the containers required names to convey information (meta-data) the containers required for effective information management andabout exchange. for effective information management and exchange.

It is clear that standards and this British Standard in particular, are one It is clear that standards andmembers this British Standard in particular, are one way to enable project team to work together more efficiently way accurately to enable project team members to work efficiently and on construction projects.

This together standard more enables and accurately on construction This standard enables increasing confidence in the useprojects. of a common naming convention and increasingtoconfidence in the use offor a common naming convention and approach collaborative working use in architecture, engineering, approach to collaborative fordata useuse in architecture, engineering, construction and facilitatesworking efficient in facilities management. construction and facilitates efficient data use in facilities management.

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

This standard establishesand thequality methodology for managing the production, distribution of construction information, production, distribution quality of construction information, including that generated and

by CAD systems, using a disciplined process including that generated

by CAD naming systems,policy. using a disciplined process for collaboration and a specified for collaboration and a specified naming policy.

It is applicable to all parties involved in the preparation and use of It is applicable to all parties involvedconstruction, in the preparation and and use of information throughout the design, operation information throughout thethe design, construction, operation andchain. deconstruction throughout project lifecycle and the supply deconstruction throughout the project lifecycle and the supply chain.

The principles for information sharing and common modelling are The principles for information sharing common modelling are equally applicable to building and civil and projects. equally applicable to building and civil projects.

This standard is also a guide for developers of software applications to This standard also a guide for developersthrough of software applications enable them toissupport its implementation the provision of to enable them tofiles support its implementation configuration or application add-ons. through the provision of configuration files or application add-ons. © BSI2015 2007 • 1 2016 © The British Standards Institution •• 1 1 © BSI 2007 • 1

BS 1192:2007 1192:2007+A1:2015 BS 1192:2007+A2:2016 BS 1192:2007+A1:2015 BS 1192:2007 NOTE 1 The standard is an alternative where the formal meta-data recommendations as provided in BS EN 82045-2 and ISO 82045-5 cannot NOTE 1 The standard is an alternative where the formal meta-data be used because of the absence of a compliant and common document recommendations as provided in BS EN 82045-2 and ISO 82045-5 cannot repository withinofan project team. be used because theorganization absence of aor compliant and common document repository within an organization or project team.

NOTE 2 This standard does not give guidance on the use of different data exchange file formats, exchange non-graphic data, structuring nor NOTE 2 This standardthe does not giveofguidance on the use of different data the exchange data held object classes and their instances nor the data exchange file of formats, theas exchange of non-graphic data, structuring nor structuring engineering the exchangeappropriate of data heldto asspecialist object classes and theiranalyses, instancesnor northe the data definition and use of data as instance parameters. structuring appropriate toheld specialist engineering analyses, nor the definition and use of data held as instance parameters.

2 Normative references 2 The Normative references following referenced documents are indispensable for the application ofreferenced this document.

For dated the edition The following referenced documents arereferences, indispensable for the following document is indispensable foronly the cited applies.

For undated references, the latest edition ofthe theedition application ofthis thisdocument. document.

Fordated dated references, only application of For references, only the edition cited applies.

For references, latest edition of the referenced document (including any the amendments) applies. cited applies.

Forundated undated references, the latest edition of the referenced document any amendments) applies. referenced document(including (including amendments) applies.

BS ISO 12006-2:2001, Buildingany construction – Organization of information about construction works– –Organization Part–2: Framework for ISO Building construction of information BS ISO 12006-2, 12006-2:2001, Building construction Organization of about construction works – Part 2:works Framework classification classification of information information about construction – Part for 2: Framework for classification of information NOTE The implementation of BS ISO 12006-2 in the UK is published under the name “Uniclass". of BS ISO 12006-2 in the UK is published NOTE The implementation under the name “Uniclass".

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

3.1 3.1

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

3.2 3.2

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

when interpreted in the context of the field in whichdefined it is entered, used sequence of characters, often a mnemonic, having meaning to concisely convey when interpreted in meta-data the context of the field in which it is entered, used to concisely convey meta-data storagepersistent hierarchy set including, not alimited to, directory, sub-directory, named of databut within file system or application data data file,hierarchy or distinct sub-set of datalimited file, such as a chapter or section, storage including, buta not to, directory, sub-directory, layersfile, or or symbol data distinct sub-set of a data file, such as a chapter or section, layers or symbol NOTE 1 “Named containers” is the common pattern on structured information for design and management.

Thepattern actual implementation NOTE 1 “Named containers” is the common on structured of “named containers” might be different in different operating systems and information for design and management. The actual implementation of proprietary file formats. “named container” is, however, “named containers” mightThe be different in differentpattern operating systems and distinct in that single name is associated to a collection. principles proprietary fileaformats.

The “named container” pattern is,The however, of this standard be applied the actualThe principles distinct in that acan single name is independently associated to aofcollection. implementation of the pattern. of this standard can be“named appliedcontainer” independently of the actual implementation of the “named container” pattern.

NOTE 2 Directories include sub-directories and folders.

NOTE 2 Files Directories include sub-directories and folders.

NOTE 33 Files includemodels, models, sub-models, documents, tables and include sub-models, sheets, data, sheets, documents, tables and schedules. schedules.

NOTE 3 Files Files includemodels, models, sub-models, documents, tables and 3 include sub-models, sheets, data, sheets, documents, tables and schedules. schedules.

NOTE 4 Containers within files include layers, sections and symbols.

3.3 3.3

NOTE 4

Containers within files include layers, sections and symbols.

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

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

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

document

BS 1192:2007

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

3.4 3.5

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

3.6 3.5

field drawing

3.6

field and codes used in those fields.

3.7

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

part of a container name reserved for meta-data

instance

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

model

3.7 3.8 3.8 3.9 3.9

instance

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

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

3.10

model

3.10

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

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

objects, for example a building or a mechanical device

collection of containers organized represent the physical parts of and can include graphical as well asto non-graphical content.

This standard objects, example a building a mechanical device is based for on generating, sharing, or etc., model files, not just drawings.

3.11

Drawings are produced when the model is complete, correct and NOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D), consistent. and can include graphical as well as non-graphical content. This standard is based generating, sharing, etc., model not just drawings.

NOTE 2 on Models can include information byfiles, reference.

Drawings are produced when the model is complete, correct and NOTE 3 Information Models are a collective of 3D Models, originator consistent.

Information/Data, (non-graphical), documents, drawings and any other

agent responsible for production of a container

3.11 3.12

information neededcan to deliver theinformation project. by reference.

NOTE 2 Models include NOTE See Clause 7.

originator sub-model agent responsible for production of a container

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

3.12

sub-model model included as an instance in another model

© BSI2015 2007 • 3 2016 © The British Standards Institution •• 3 3

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

Process considerations Standard method and procedure

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

4.1

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

4.1.1

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

4.1.2

General project issues develop;

develop; Projects shouldfollow followaacommon commonset setofofgeneric genericprocesses processesatatthe thehighest highest Projects should production of 2Don drawings from 2D andbasis.

3D models; and level,•which are TheThe procedures level, which arefine-tuned fine-tuned ona aproject-by-project project-by-project basis. outlined to all approaches project production, and procedures outlined apply to alltoapproaches project design • apply production of 2D drawings usingdesign 2DtoCAD draughting co-ordination of the information model.  production, including: software.

•

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

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

4.1.2

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

• Naming should and be adopted according to To implement theconventions “standard method procedure” the following Clauses 5 to 15. elements should be in place: • •

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

• •

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

• • •

•

4 • © BSI 2007

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

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

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

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

NOTE 1 There are four phases of the CDE as illustrated in Figure 1.

Information, once prepared, should be placed into the Information, once prepared, be placed into passed the WORK-IN-PROGRESS (WIP)should (see 4.2.2) area and through the WORK-IN-PROGRESS (WIP) (see 4.2.2) areathe andphases passedofthrough model in an anti-clockwise direction through its life. the model in an anti-clockwise direction through the phases of its life.

NOTE 2 The naming, numbering and identification of all data held in the CDE in numbering Clause 5. and identification of all data held in NOTE 2 are Thedefined naming, the CDE are defined in Clause 5.

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

4.2.2 4.2.2

WORK-IN-PROGRESS WORK-IN-PROGRESS

The WIP area of the CDE (see Figure 2) is where members of the project The area the CDE is where members software of the project teamWIP carry outoftheir own (see workFigure using2) their organization’s team carry out their work repository using theiror organization’s software systems.

Whether theown common an organization’s in-house systems.

Whether repository or anshould organization’s repository is used,the thecommon models and documents employ ain-house similar repository is used, the models and documents should employ a similar management process as that used for the total project. management process as that used for the total project.

The organization is responsible for the quality of the WIP information The organization responsible for the qualityand of the WIPprocesses information and should ensureisthat appropriate checking review are and should ensure that appropriate checking and review processes are in place. in place.

NOTE 1 Each model file only contains information for which each design team is1 NOTE Eachmodel model fileText only contains information for which each design 1 responsible. text deleted  contains for Each deleted only only containsinformation information forwhich which each  task  team is responsible. team is responsible.

NOTE 2 The organization also includes work package subcontractors who develop based onalso consultants’ where contracts require NOTE 2 Thedesign organization includes design, work package subcontractors this specific who develop approach. design based on consultants’ design, where contracts require this specific approach.

The data continues to be updated in the WIP area and should be indexed The data continues continues to be be updated updated ine.g. theWIP WIParea area and should indexed to indicate minor version changes, P02.1, etc., until nextbe published data to in the and  options  to indicate minor version changes, e.g.

P02.1, etc., until next published the SHARED area (see 4.2.3). should be indexed to indicate minor version changes, e.g. P02.01, to area (see 4.2.3). etc.the SHARED Text deleted

© BSI2015 2007 • 5 2016 •• 5 5 © The British Standards Institution © BSI 2007 • 5

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

Figure 1

Document and data management repository

 CLIENT SHARED AREA SHARED

WORK IN PROGRESS

SUITABILITY S1

Check, Review, Approve

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

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

SUITABILITY S0

REVISION Pnn

VER Pnn.n

Task Team 1 Task Team 2

CLIENT SHARED AREA

Task Team 3 Clients Authorization

PUBLISHED DOCUMENTATION

SUITABILITY An

VERIFIED

Coordination and validated design output for use by the total project team.

Production information sutable for Stage Completion Acceptance or Construction:

ARCHIVE

Project history maintained for knowledge and regulatory and legal requirements.

Repository of the project information for non asset portfolio employers.

REVISION Cnn

CLIENT SHARED AREA

NOTE The suffices for the A and B suitabilities refer to the stages.

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

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

WORK-IN-PROGRESS (WIP)and and issue for architects WORK-IN-PROGRESS (WIP) shareprocess  process for model architects model WORK-IN-PROGRESS (WIP)and and issue for architects WORK-IN-PROGRESS (WIP) shareprocess  process for model architects model 

ARCHITECTURE WIP

 Check,Check, Review, Review, Approve Approve

ARCHITECTURE WIP SUITABILITY VERSION ARCH. GRID

SUITABILITY S0

VERSION P01.1

ARCH. ARCH. GRID WALLS

S0 S0

P01.1 P01.1

ARCH. ARCH. WALLS COLUMNS

S0 S0

P01.1 P01.1

ARCH. COLUMNS

S0

P01.1

 

4.2.3

SHARED

4.2.3

When the data dataisisSHARED SHAREDwith withthe theother othermembers members the project team, team, When the ofof the project SHARED text deleted  code updated Text deleted  the the revision code isis updated the data data is is checked checkedand and issued to the CDE andrevision the revision code is When the data dataisisSHARED SHAREDwith withthe theother othermembers members the project team, When the ofof the project team, to indicate major revision, P01. e.g. P01. updated toaindicate a majore.g. revision, the data is checked and  Text deleted  the revision code is updated data is checked and issued to the CDE and the revision code is  for When aa model has ae.g. that is is “ When model hasreached reached astatus status that “fitsuitable for co-ordination” it to indicate major revision, P01. updated toaindicate a major revision, e.g.

P01. areain of co-ordination” it should be  made available in the as SHARED should be uploaded to the SHARED area of the CDE illustrated  for When aa model has reached a astatus that is is “ When model has reached status that “fitsuitable for co-ordination” it the CDE3.as illustrated in Figure 3.

Figure co-ordination” it should be  made available in the as SHARED areain of should be uploaded to the SHARED area of the CDE illustrated NOTE 1 The SHARED area ensures: the CDE3.as illustrated in Figure 3.

Figure • 1 NOTE • • • • • •

sharing of dataarea in aensures: well-defined context; The SHARED a secureof safe space allow constructive sharing data in atowell-defined context;sharing;

non-adversarial working; a secure safe space to allow constructive sharing; supports the generation of spatially co-ordinated data as part of non-adversarial working; the development process.

• supports the generation of spatially co-ordinated data as part of NOTE 2 The model available to be by thebywhole projectproject NOTE 2 the Thedevelopment modelisisnow now available toshared be shared the whole process. team. This may be further controlled through the use of a security team.

NOTE 2 as The modelwithin is now toSecurity be shared by the whole access list defined theavailable Built Asset Management Planproject (see Before uploading to reviewed Before uploading tothe theSHARED SHAREDarea, area,a amodel modelshould shouldbebe reviewed and PAS 1192-5:2015). team.

and checked according to compliance requirements ordertotobe befit for a checked according to compliance requirements ininorder Before uploading to the area, a amodel should bebe reviewed Before uploading theSHARED SHARED area, model should reviewed suitable  for to a specific purpose.

The information should also be and specific purpose.

The information should also be checked for and checked according to compliance requirements ordertotobe befit for a checked according to compliance requirements ininorder checked for conformity conformity to Annex B.to Annex B. suitable  for The a specific purpose.

The information shouldfor also be specific purpose. information should also be checked The “issue” status should be used checked for to conformity B.to identify the suitability of the conformity Annex B.to Annex 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 NOTE 3 The suitability codes are distinct from the client/construction authorized. authorization status and from the contractors work packages purpose of NOTE issue. 3 The suitability codes are distinct from the client/construction authorization status and from the contractors work packages purpose of The data shared sharedwith withstatus status“ “FitSuitable for Co-ordination” should beshould in thebe data  for Co-ordination” issue.

changeable formats.

All information having a different status should be should in the changeable formats.

All information having a different status The data data shared sharedwith withstatus status“ “FitSuitable for Co-ordination” should beshould in thebe  for Co-ordination” produced as as documents ininnon-changeable be produced documents non-changeableformats. formats. changeable formats.

All information having a different status should be in the changeable formats.

All information having a different status should produced as as documents ininnon-changeable be produced documents non-changeableformats. formats. © BSI2015 2007 • 7 2016 •• 7 7 © The British Standards Institution © BSI2015 2007 • • © The British Standards Institution

7 7

1192:2007+A2:2016 BS 1192:2007 1192:2007+A1:2015 BS 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 WIP

SHARED

SUITABILITY

REVISION

ARCH. GRID

S1

P01

ARCH. WALLS

S1

P01

ARCH. COLUMNS

S1

P01

Check, Review, Approve WIP to SHARED

SUITABILITY

VERSION

ARCH. GRID

S0

P01.1

ARCH. WALLS

S0

P01.1

ARCH. COLUMNS

S0

P01.1

 Architecture models checked, reviewed and approved within an internal review process and uploaded to the

Architecture SHARED 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 suitability is moved to “suitable for purpose”.

The models suitability is moved to “fit for purpose”.

In  for co-ordination”.

In this this example examplethat thatisisS1 S1“ “fitsuitable for co-ordination”.

NOTE Any the project team can can use the modelmodel files forfiles reference or co-ordination.

Other design NOTE Anymember memberofof the project team useshared the shared for reference or co-ordination.

Other team members can  reference  the latest versions of models from the SHARED area of the CDE as shownasinshown design team members can download the latest versions of models from the SHARED area of the CDE Figure 4. These reference models models can background information onto which the recipient can overlay in Figure 4. These download canbe beused usedasas background information onto which the recipient can their design information. This produces a clash avoidance process. overlay their design information.

Figure 4

co-ordination(S1), (S1), Only graphical models approved, suitable for coordination Architects models uploaded to another disciplines WIP area should be used as a reference.

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

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 1192:2007+A2:2016 BS 1192:2007+A1:2015 overlay their design information.

Figure Figure 4

Architects models uploaded another disciplines WIP area Architect’s SHARED modelstoreferenced to Structures WIP area

BS 1192:2007

8 • © BSI 2007

Figure 5

Structures co-ordinates its model files using the architecture files as a reference

NOTE In Inthe theexample example shown Figure 5, structural the structural engineer has designed the structural member NOTE shown in in Figure 5, the engineer has designed the structural member sizes and sizes takes ownership of the structural column  modellayer. . When thethe structural engineer uploads this information into and takes ownership of the structural column When structural engineer uploads this information the area the architect’s file is revised re-shared remove the ownership of the columns. of intoSHARED the SHARED area the architect’s file isand revised and to re-shared toarchitectural remove the architectural ownership  the Although columns.the finishes are still owned by the architect.

4.2.4

DOCUMENTATION Before information Before informationin inthe theSHARED SHAREDarea areaofofthe theCDE CDEisismade madeavailable available to to the wider project team, example tenderororconstruction, construction,ititshould the wider project team, forfor example forfor tender should be formally checked, approved and authorized (Figure 7). Suitable be formally checked, approved and authorized (Figure 7). Suitable checking and approvals processes should be defined and applied. checking and approvals processes should be defined and applied. These should apply consultants subcontractors’ NOTE Seeto PAS 1192-2 for and a definition of a plan ofdocuments. work with stages.

Once theoff document beenallow approved and it each passes to the The sign processeshas should for sign offauthorized, at the end of stage.  contractor for “Action” and the revision changes from “Preliminary” to These should apply to all consultants and subcontractors’ documents.

“Construction” (see 15.2.3).

2016 • 9 © The British Standards Institution 2015 • 9

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

BS 1192:2007

Figure Figure 6

Co-ordinated, reviewedand anduploaded uploaded models Co-ordinated, reviewed models issued sharedto the to the SHARED areaand andduplicate duplicate layers removed SHARED area information  removed

 SHARED

ARCH. GRID

REVISION

S1

ARCH. WALLS

S1

ARCH. COLUMNS

S1

STRUCT. COLUMNS

S1

SUITABILITY

P01 P01 P01 P01

VERSION

ARCH. GRID

S0

P01.1

ARCH. WALLS

S0

P01.1

ARCH. COLUMNS

S0

P01.1

SUITABILITY

Check Review Approve WIP to SHARED

SUITABILITY

STRUCTURES WIP

ARCHITECTURE WIP

REV/VER

ARCH. GRID

S1

P01

ARCH. WALLS

S1

P01

ARCH. COLUMNS

S1

P01

STRUCT. COLUMNS

S0

P01.1 

a) Structures uploads co-ordinated models to SHARED

 ARCHITECTURE WIP

SUITABILITY

REVISION

ARCH. GRID

S1

P02

ARCH. WALLS

S1

P02

STRUCT. COLUMNS

S1

P01

Check, Review, Approve

SHARED

SUITABILITY

STRUCTURES WIP

REV/VER

SUITABILITY

REV/VER

ARCH. GRID

S0

P02.1

ARCH. GRID

S1

P01

ARCH. WALLS

S0

P02.1

ARCH. WALLS

S1

P01

ARCH. COLUMNS

S1

P01

STRUCT. COLUMNS

S0

P01.1

STRUCT. COLUMNS

S1

P01

ARCHITECTURAL COLUMNS REMOVED

b) Change of ownership – Architect downloads, removes their duplicates and resubmits

10 • 2016 10 • © The British Standards Institution 2015

S0

P01.1



Concurrent upload and download reference Concurrentactivities activitieswith withcontinual continual upload and

At  stage completion drawing , all disciplines drawings, datafiles and from documentation  through extractions from model files the SHARED At predetermined predetermineddates dates, allordisciplines produce throughproduce extractions from model the SHARED area. This is checked, reviewed andfrom verified for area.

This in is the checked, and  submitted for approval in the client authorization area. approval clientreviewed authorization area.

On authorization, the drawings to be published and Textstored. deleted. authorization,the theclient clientallows allows the drawings to be published NOTE Once has been initiated andand the design teams continue development of the design a concurrent engineering environmentenvironment is establishediswith a Oncethe theprocess process has been initiated the design teams continue development of thedata design data a concurrent engineering established managed continuous reference  of shared as of illustrated in Figure 7. with a managed continuous download and data, upload shared data, as illustrated in Figure 7.

Figure 7 Figure

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

© BSI 2015 2007 • 11 • 11 © The British Standards Institution 2016 • 11

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

Figure 8

Suitability “D” is data or documents not authorized by the client

NOTE  resharesof  of any documents drawingsare are archived archived for auditing andand NOTE All Allupdates updatesand and reissues any documents or or drawings forfuture future auditing historical historicalrecords. records.

NOTE Where areare required by the team for purposes Wheredocuments documents required byconstruction the construction team for other than construction (e.g. tendering or procurement), at a time prior to at a purposes other than construction (e.g. tendering or procurement), their approval for construction, the construction, status “D” is used transferred to the time prior to their approval for theand status “D” is used and PUBLISHED/ DOCUMENTATION area illustrated in in Figure Figure 88 transferred to the DOCUMENTATION area asasillustrated (see 15.3.2).

These “D”“D” status documents retain a preliminary revisionrevision reference (see 15.3.2).

These status documents retain a preliminary “reference P01-P0n  ”.

“P1-Pn”.

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

4.2.5

4.2.5 4.2.5

ARCHIVE

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

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

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

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

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

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

Health and Safety file; data and documentation.

Figure 9

Figure 9 Figure 9

legal purposes, e.g. Health and Safety file; • operation and maintenance information.

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

Built” data

NOTE The ARCHIVE area of the CDE is for inactive or superseded documentation.

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

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

© BSI 2007 •

13

© BSI2015 2007 • 13 • 13 2016 © The British Standards Institution • 13 © BSI 2007 •

13

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

5 Naming of containers 5.1

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

Names for containers should be created by joining together codes in the specified fields, in the specified order, using only the “-” hyphen character, which is therefore not allowed in any code.

NOTE 2 Any “description” (see Clause 14) is appended following an underscore “_”.

NOTE 3 The hyphen character may be used in a description field but this is deprecated.

5.2

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

NOTE

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

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

5.3 5.3.1

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

5.3.2

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

5.3.3

Project specific codes Project specific values for fields should be given codes that are unique and distinctive, with clear descriptions. Project specific codes should not be overly long as some repository systems cannot handle long file-identifiers.

Containers should have codes assigned for the fields as specified in 6.3 to 15.3.

Each code should not imply meaning that is duplicated in other fields.

NOTE This is necessary to ensure that complex rules are not required to maintain consistency between the fields. For example, avoid putting meaning in a revision field that is related to the suitability field.

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

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

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

Naming of containers Naming of containers

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

5.4.2 5.4.2

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

Directories and folders Directories and Directories should be folders transmitted and stored in repositories with names composed joining one mandatory andin two optional fields given Directoriesby should be the transmitted and stored repositories with names in Table 1. by Anjoining example given in 5.5. and two optional fields given composed theisone mandatory in Table 1.

An example is given in 5.5. intermediate sub-directories NOTE Implementations might introduce

Table 1 Table 1

based fields present inmight the fileintroduce naming specified in 5.4.3.

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

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

Field Field Project

Obligation Obligation Required

Clause Clause 6

A) Project Suitability A) Suitability Revision A)

Required Optional Optional

6 15.3.2 15.3.2 15.3.3

A) A) Revision If information

Optional 15.3.3track meta-data passes through an environment that cannot then this field can be included to environment identify the “suitability” “revision”.

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

5.4.3 5.4.3

The two optional fields should be used or omitted together.

Files Files Files should be transmitted and stored in repositories in a context which makes clear be thetransmitted fields defined the directory (see 5.4.2).

Files should Files should andfor stored in repositories in a context which be transmitted stored in repositories with names composed by makes clear theand fields defined for the directory (see 5.4.2).

Files should joining the seven mandatory and three optional fields composed given in Table be transmitted and stored in repositories with names by 2 (an example is given in 5.5). and three optional fields given in Table 2 joining the seven mandatory (an example is given 5.5).

NOTE The file name in also contains the extension suffix identifying the

Table 2 Table 2

type of application applicable.

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

Naming of file Naming of file

Field Field Project

Obligation Obligation Required

Clause Clause 6

Project Originator Originator assets Zones Volumeand or system

Required Required

6 7 7 8.1.2

Zones and Levels and assets locations Levels and locations Type

Required Required

8.1.2 8.1.3 8.1.3 9

Type Role Role Classification

Required Required Optional

9 10 10 11

Classification Number Number Suitability A)

Optional Required Required meta-data  metadata Optional

11 13 13 15.2.2

SuitabilityA)A) 15.2.2 meta-data  metadata Optional 15.2.3 Revision A) A) Optional where there is no 15.2.3 Revision If files pass through an environment directory context, field canthrough be included to document the suitability revision.

A) this If files pass an environment where there is noand directory context, Thethis optional fields “suitability” “revision” should beshould used or meta-data  fields“suitability” “suitability” and “revision” should beomitted usedor ortogether.  metadata  fields and “revision” be used field can be included to and document the suitability and revision.

The optional fields “suitability” and “revision” should be used or omitted together. omitted together. omitted together. © BSI2015 2007 • 15 • 15 2016 • 15 © The British Standards Institution © BSI 2007 • 15

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

Containers within files Containers within files should have names composed by joining the three mandatory fields and one optional field given in Table 3 (an example is given in 5.5).

NOTE The provisions applicable to containers within files do not apply to unstructured documents such as un-scaled sketches, narrative and renderings.

Table 3

5.5

Naming of containers within files including layers Field

Obligation

Clause

Role

Required

10

Classification

Required

11

Presentation

Required

12

Description

Optional

14

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

Table 4

Examples of field usage

Fields

Directories (see 5.4.2)

Files (see 5.4.3)

Project

PR1

PR1

6

XYZ

7

Originator

Zones Volumeand or system assets

Containers within files including layers (see 5.4.4)

Clause

V1 01   Z1

8.1.2

Levels and locations

01

8.1.3

Type

M3

9

Role

A G31 (optional) Uniclass  (optional)

Classification

A G322  Uniclass

Presentation

M

Number

0001

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

S1 PR1-S1-P2

S1

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

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

11 12 13

Doors

P02 P2 

10

14 15.2.2 15.2.3

AUniclass-M_Doors A-G322-M_Doors

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

6 Project 6.1

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

NOTE A project can be divided into sub-projects.

6.2

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

6.3

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

7 Originator 7.1

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

7.2

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

7.3

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

8 Divisions 8.1 8.1.1

Principles Types of physical sub-division The project should be divided into manageable sub-divisions using two criteria: a) and assets (see 8.1.2); a) zones volume or system  (see 8.1.2); b) and locations locations(see (see8.1.3) 8.1.3)(see (seealso also Annex b) levels and Annex C).C).

NOTE Buildings displaced named usingusing levels levels but most NOTE Buildingsare arevertically vertically displaced named butcivil most structures are horizontally displaceddisplaced and named using location or chainages. civil structures are horizontally and named using location or Civil projectsCivil occupying large areas suchlarge as oilareas refinery sitesasand chainages. projects occupying such oilairports refinerywould sites use the “location” codeuse based a grid basis based or poston code each In case and airports would theon“location” code a grid. In basis. each ““ volume sub-division. ” then adds additional subdivision. case “zone” then adds additional subdivision.

© BSI2015 2007 • 17 • 17 2016 © The British Standards Institution • 17

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

8.1.2 8.1.2 8.1.2

Zones and assets Volumes and systems

Every container should document a single building zone or asset Every container shouldwithin document a single building volume or (location), contained a simple volume of space.

Zones and assets system (location), contained within a simple volume of space.

There should be should at leastdocument one set ofazones to be Every container singleexplicitly building designated zone or asset  volume per role  explicitly There should be at least one set of non-overlapping. (location), contained within a simple volume of space. designated to be non-overlapping.

NOTE 1 The term “asset” might be more appropriate for infrastructure There should be at least one set of zones explicitly designated to be projects. Text deleted non-overlapping.

NOTE 2Where Where possible be defined so as to identify possible “ “zones” volumesshould ” should be defined so as to identifyaa NOTE 1portion The of term “asset” might be more appropriate for infrastructure logical of work intended be delivered by a single team. logical portion work intended to beto delivered by a single team. projects.

8.1.3 8.1.3

8.2 8.2.1 8.2 8.2.1

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

Where a container documents a single building level (floor) or location, the code and for that level should be used. Where a container documents Levels locations multiple levels, a distinct code should be used.

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

NOTE The term “location” might be more appropriate for infrastructure Standard codes for divisions projects.

General

Standard codes for divisions

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

General NOTE

8.2.2 8.2.2

8.2.2

Building projects are more likely to use standard codes.

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

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

NOTE Building projects are more likely to use standard codes.

The “ zone/asset” code  should be should one orbe two characters.

The following volume/system ” code one or two characters.

The

code should be used for for a“zone/asset” whole following code should be used for alevel. whole level.

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

This should be expanded in the project specific codes.

00 All zones

8.2.3

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

8.2.3

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

be avoided.  be expanded in the project specific codes.

This list should The “level/locator” code should be two characters as follows:

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

02 2, etc.

M1 Floor Mezzanine above level 01 M2 Mezzanine above“level 02, etc.

For mezzanine the prefix M” should be used as follows: For all below above the ground floor the prefix “B” should be used: M1levels Mezzanine level 01 M2 B1 Mezzanine above level 02, etc.

B2,levels etc. below the ground floor the prefix “B” should be used: For all NOTE B1 For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2.

B1 B2, etc.

18 • © BSI 2007

NOTE

18 • 2016 18 • © The British Standards Institution 2015

18 • © BSI 2007

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

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

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

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

For floor levels the above ground should be used as mezzanine prefix “M” floor, shouldthe befloor usednumber as follows: follows: M1 Mezzanine above level 01 01 Floor 1 M2 Mezzanine above level 02, etc.

02 Floor 2, etc.

For all levels below the ground floor the prefix “B” should be used: For mezzanine the prefix “M” should be used as follows: B1 M1 Mezzanine above level 01 B2, etc.

BS 1192:2007 M2 Mezzanine above see level NOTE 2 For Forfloor floornotation, notation, see BS EN ISO and BSBS ENEN ISO 4157-2.

BS02, ENetc.

ISO4157-1 4157-1 and ISO 4157-2.

For all levels below the ground floor the prefix “B” should be used:

18 • © BSI 2007

8.3 8.3.1

18 • © BSI 2007

8.3 8.3 8.3.1 8.3.1 8.3.2 8.3.2 8.3

8.3.1 8.3.3 8.3.2 8.3.2 8.3.2

8.3.3 8.3.3 8.3.2 9 9.1 8.3.3

Project specific codes for divisions B1 B2, etc.

BS 1192:2007 Principles NOTE 2 For Forfloor floornotation, notation, see and BSBS EN ISO 4157-2. seeBS BSEN ENISO ISO4157-1 4157-1 and EN ISO 4157-2.

BS 1192:2007 Project specific codes for divisions should be detailed in the project space statement (see Annex A). The specific codes should not Project specific codes forproject divisions conflict with the standard codes given in 8.2.

Project specific codes for divisions

Principles NOTE Infrastructure projects are more likely to require project specific BS 1192:2007 codes.

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

Project specific codes for divisions should be detailed in the project Project specific codes for “level” and “location” Project specific volume “asset” ” and Project specificcodes codesfor for““zone” and space statement (see Annex A).

The project specific codes should not system ” codes Project specific for “zone” and “asset” “““Level” and “asset” location” codes should be defined with detailed Zone” and “ identifiers should be defined as required, with conflict with the standard codes given in 8.2. demarcation especially in the vertical dimension and a detailed detailed demarcation in three dimensions and descriptions.

“Zone” Volume  ” and “  system  ” identifiers should be defined as and “asset” identifiers should be defined as required, with NOTE Infrastructure projects are more likely to require project specific description. required, with detailed demarcation in three dimensions and descriptions. detailed codes. demarcation in three dimensions and descriptions.

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

especially in theshould vertical dimension and a detailed “demarcation and ““asset” location” codes be defined detailed “Level” Zone” and identifiers should be definedwith as required, with description. demarcation especially in the vertical dimension and a detailed detailed demarcation in three dimensions and descriptions.

Principles description.

To aid recognition, container should contain a single type of Project specificevery codes for “level” and “location” information, e.g. a drawing, location model, typical assembly or detail “Level” and “location” codes should be defined with detailed information. demarcation especially in the vertical dimension and a detailed Principles description.

Principles Standard codes for types of information To aid recognition, every container should contain a single type of information, e.g. a drawing, locationshould model, typical or of detail To recognition, every contain aassembly single type Theaid standard codes for filecontainer containers holding models and drawings the information. information, e.g. a drawing, location model, typical assembly or detail code should be exactly two characters as follows: information.

DR Drawing Principles Standard codes for types of information M2 Two dimensional model Standard codes for typesshould of information M3recognition, Threecodes dimensional model To every contain a single type of the Theaid standard for filecontainer containers holding models and drawings MR Model rendering information, e.g. a drawing, location model, typical assembly or detail code should be exactly twocontainers characters as follows: The standard codes for file holding models and drawings the VS Visualization information. code should be exactly two characters as follows: DR SC Drawing Schedule or table M2 Two dimensional model DR Drawing SP Specification Standard codes types of information M3 Three dimensional model M2 Twoofdimensional model BQ Bill Quantityfor MR Model rendering M3 Three dimensional model SC Structural The standard codesCalculation for file containers holding models and drawings the VS Visualization MR Model The Standards Institution 2015codes.

• 19 code be rendering exactly two©characters follows: NOTEshould 1 There is no provision toBritish extendas this for project specific SC Schedule or table VS Visualization DR Drawing NOTE For file containers SP SC2 Specification Schedule or table holding documents there are no standard codesM2 mandated.

Twoofdimensional BQ Bill Quantity model SP Specification M3 Three dimensional model SC Structural Calculation BQ Bill of Quantity MR Model rendering Project specific codes for “Standards types of information SC1 Structural Calculation 2016codes.

• 19 © The Institution 2015 • 19 NOTE There is no provision toBritish extend this for ” project specific VS Visualization NOTE 1 There no provision to extend this forthere project codes.

Project “type” codesholding should be defined for documents.

NOTE For fileis containers documents arespecific no standard SC2 specific Schedule or table

9 Type 9 Type

9.1 9.1 9.2

9 Type 9.1 9.2 9.2

9.2

9.3

9.1 8.3.1

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

Principles

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

9.2

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

8.3.2

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

codes.

DR Drawing M2 Two dimensional model detailed demarcation in three dimensions and descriptions.

Code Code File Type M3 Three dimensional model AF Animation file (of a model)

AF Model MR rendering Project specific codes for “level” and “location” CM Combined model (combined multidiscipline model)

CM VS Visualization CR Specific for the clash process “Level” CR “location” codes should be defined with detailed SC and Schedule or table DR 2D drawingin the vertical dimension and a detailed

DR Specification demarcation especially SP M2 2DQuantity model file

M2 Bill of description.

BQ M3 3D model file

M3 SC Structural Calculation MR

MR Model rendition file for other renditions, e.g thermal NOTE 1 There is no provision to extend this for project specific codes. analysis etc.

NOTE 2 ForVisualization file containers documents there are no standard VS fileholding (of a model)

VS Fileand types for drawings models “ Zone” “asset” identifiersand should be defined as required, with

8.3.3

9 Type 9.1 9.3

9.2

9.3

codes mandated.

File types for documents Principles

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

BQ BQ Bill quantitieslocation model, typical assembly or detail information, e.g. of a drawing, Project specific “ type” codes should be defined for documents.

CA Calculations CO Correspondence information.

NOTE is noplan mandate for any project specific codes for drawings.

CO Correspondence CP ThereCost

CP Cost plan DB Database Standard codes for types of information DB Database FN File note

FN File note HS Health andfile safety The standard codes for containers holding models and drawings the

HS Health and two safety IE Information Exchange file as follows: code should be exactly characters

IE Information exchange MI Minutes / action notes file DR Drawing

MI Minutes statement / action notes MS Method M2 Two dimensional model © BSI 2007 • 19

MS Method statement PP Presentation M3 Three dimensional model PP Presentation PR Programme MR Model rendering PR Programme RD Room data sheet VS

RD Visualization Room data RI Request forsheet Information SC or table

RI Schedule Request for information RP Report SP RP Report of accommodation SA Specification Schedule BQ Quantity

SA Bill of Schedule of accommodation CA Calculations SC Structural Calculation SH SH Schedule

SN SN Snagging list NOTE 1 There is no provision to extend this for project specific codes.

SP SP Specification NOTE 2 For file containers holding documents there are no standard SU SU Survey codes mandated.

Project specific codes for “types” of information Project specific “type” codes should be defined for documents.

NOTE There is no mandate for any project specific codes for drawings.

© BSI 2007 •

20 • 2016 20 • © The British Standards Institution 2015

19

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

BSBS 1192:2007 1192:2007

1010Role Role 10.1 10.1Principles Principles Each Each organization organization should should be allocated be allocated to one to one or more or more roles roles within within thethe project. project.

NOTE NOTEFurther Further subdivision subdivision of roles of roles cancan be implied be implied using using the the classification classification field, field, see see Clause Clause 11.11.

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

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

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

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

The The code code should should beText two be two characters characters or more.

A single A single code code from from oneone table table should should be used. be used.

20 20• •© BSI © BSI 2007 2007

2016 • 21 © The British Standards Institution 2015 • 21

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

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

Early stage design such as Scheme design and preliminary phases may initially use Table D for Facilities, Table E for Construction Standard codes for classification Elements, but these are deprecated.

Classification codes shouldbebebody selected from afor system compliant Classification codes should selected from a system compliant to CPIC is the co-ordinating responsible maintaining and BSBS ISO 12006 Uniclass and the Uniclass publication.  tables to ISO 12006-2:2001, and in particular from equivalent updating the classifications.

Reference should be made to to A.7 and A.8 for Elements, A.9 for Services work and for their website http://www.productioninformation.org/ forA.13 updates. deleted  Text

identified Products and Materials.

NOTE 2 There to extend thisUNICLASS through thepublication project specific  NOTE Referistono theprovision BIM TOOLKIT and the for dictionary.

NOTE 1 The UK implementation of BS ISO 12006-2 is Uniclass so this latest coding practices.  recommendation can be expressed as follows:

11.3

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

elements, with Table J for services work and Table L for identified NOTE Thereand is noMaterials. mandate Information for any project specific codes for thisbefield.

Products relating to Spaces may classified using Table F.

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

12.1

Elements, but these are deprecated.

Principles CPIC is the co-ordinating body responsible for maintaining and updating theshould Uniclass Reference should conventions. be made to Every container beclassifications. consistent in its presentational their website http://www.productioninformation.org/ for updates.

For both drawings and documents, graphical and textual content should be distinguished containers within suchthe asproject layering or NOTE 2 There isby nousing provision to extend this files through specific dictionary. sections.

11.3 12.2

NOTE This ensures that the information can still be re-used for a variety Project specific codes classification of presentational purposes withoutfor conflicting with re-use of information.

NOTE There is no mandate for any project specific codes for this field.

Standard codes for presentation

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

12.1

D

Dimensioning

Principles H Hatching and shading M container Model related Every shouldelements be consistent in its presentational conventions.

P Plot/paper related elements For both drawings and documents, graphical and textual content should T Text be distinguished by using containers within files such as layering or sections.

NOTE There is no provision to extend this with project specific codes.

12.3

BS 1192:2007

12.2

NOTE This ensures that the information can still be re-used for a variety of presentational purposes withoutfor conflicting with re-use of information.

Project specific codes presentation NOTE There is no mandate for any project specific codes for this field.

Standard codes for presentation

The standard code for presentation should be exactly one character as

13 follows.

Number 13.1

D Dimensioning H Hatching and shading Principles © BSI 2007 • 21 M Model related elements A sequential number should be used when a container is one of a series P Plot/paper related elements not distinguished by any other of the fields defined in Clauses 6 to 12.

T Text NOTE There most often files. this with project specific codes.

This applies NOTE is no provision toto extend

13.2 12.3

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

NOTE

13.3

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

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

22 • 2016 22 • © The British Standards Institution 2015

13.2

Standard coding for numbers The numbering for standard coding should be exactly four integer numeric digits, used sequentially. LeadingBS zeros should be used.

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

13.3

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

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

14 Description 14.1

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

14.2

NOTE 1 fields.

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

NOTE 2

Avoid long, unwieldy and poorly worded descriptions.

Standard coding for description NOTE

14.3

There are no standard codes mandated for the description field.

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

15 Status 15.1

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

15.2 15.2.1

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

22 • © BSI 2007

b) revision (see 15.2.3).

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

15.2.2

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

15.2.3

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

15.3 15.3.1

Standard coding 2016 • 23 © The British Standards Institution 2015 • 23

Standard status codes for “status”

15.2.3

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

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

Standard coding Standard status codes for “status” Standard codes should be used for the “status” fields wherever possible.

NOTE Some codes might not be appropriate depending on whether they are models or documents.

15.3.2

Standard codes for “suitability” The “suitability” code should be one or two characters.

The “suitability” codes given in Table 5 should be used.

NOTE Use of a particular management process might make some codes inapplicable to some types of document.

© BSI 2007 •

24 • 2016 24 • © The British Standards Institution 2015

23

BS 1192:2007+A2:2016 Table 5 Status

Standard codes for suitability models and documents

Description

Work in Progress Initial status or WIP S0 Master document index of file identifiers uploaded into the extranet.

Shared (Non-contractual) Suitable for Co-ordination The file is available to be ‘shared’ and S1 used by other disciplines as a background for their information.

Revision

Graphical Data

NonGraphical Data

Documents

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

✓

✓

✓

P01 to P0n

✓

✗

✗

S2

Suitable for Information

P01 to P0n

✗

✓

✓

S3

Suitable for Review & Comment

P01 to P0n

As required

✓

✓

S4

Suitable for Stage Approval

P01 to P0n

✗

✗

✓

P01 to Pnn

✗

✗

✓

P01 to Pnn

✗

✗

✓

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

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

D1

Suitable for Costing

P01.01 etc to P0n.0n

✓

✓

✓

D2

Suitable for Tender

P01.01 etc to P0n.0n

✗

✓

✓

D3

Suitable for Contractor Design

P01.01 etc to P0n.0n

✓

✓

✓

D4

Suitable for Manufacture/Procurement

P01.01 etc to P0n.0n

✗

✓

✓

C01 to C0n

✓

✓

✓

P01.01 etc to P0n.0n etc

✓

✓

✓

C01 to C0n

✓

✓

✓

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

Published for AIM Acceptance As Construction Record documentation, CR PDF, Models etc

© The British Standards Institution 2016 • 25

of design documents for transfer to the contractor or subcontractor. This sign-off process is the same as that for manually produced drawings and is used again for CAD or electronic data/drawings. Refer to BS 7000-4.

NOTE 2 There is provision to extend this with project specific codes.

A) For construction with minor comments from the client.

1192:2007+A2:2016 BS 1192:2007+A1:2015 All minor comments should be indicated by the insertion of a statement of ‘‘in abeyance” until the comment is resolved or minor changes incorporated and resubmitted to achieve full sign-off.

15.3.3

Standard codes for “revisions” Versions area should be be Versionscreated createdwithin withinthe theWORK-IN-PROGRESS WORK-IN-PROGRESS area should numbered P01.1, P01.2, P01.3 numbered using usingdecimals, decimals,e.g. e.g. P1.1, P1.2, P1.3, etc., etc.  signed-off when signed-off the This should should be bechanged changedtotointeger integer P1P01 when by theby originator originator for sharing.

Thereafter the version within the WIP area should for sharing. Thereafter the version within the WIP area should become become P02.01 as detailed in 4.2.4.

P2.1 as detailed in 4.2.4.

Formal the revision Formal revisions revisionsshould shouldbe benumbered numberedsequentially, sequentially,marking marking the revision  preliminary (P0n) or contractual (C0n)  . as either either pre-contractual or post-contractual.

Preliminary sequentially as as thethe Preliminary revisions revisionsshould shouldbebenumbered numbered sequentially BS 1192:2007  preliminary  design develops, e.g. P2, P01, P02, P03, etc. pre-contract design develops, e.g. P1, P3, etc. Contractual revision should be numbered sequentially for Post contractorrevision be numbered sequentially forC01, any C02, changes any changes update should to the signed-off containers, e.g.  or update to the signed-off containers, e.g. C1, C2, C3, etc.

C03 , etc.

NOTE 11 The The“C” “C”notation notation indicates container can befor used for indicates thatthat the the container can be used construction  or contractual purposes (e.g. Stage Completion). construction and contractual purposes.

24 • © BSI 2007

to extend this this withwith project specific codes. codes.

NOTE 22 There Thereisisprovision provision to extend project specific

15.4 15.4.1

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

15.4.2

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

15.4.3

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

26 • 2016 26 • © The British Standards Institution 2015

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

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

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

Units should be SI units of measure.

NOTE 1

SI units are defined in BS ISO 31.

The basic unit of length within models should be agreed to be metres for infrastructure projects or millimetres for building.

NOTE 2 The accuracy achievable using the chosen units and origins might need to be checked.

A.2

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

NOTE The project origin is best located within or close to the project or site extent.

A.3

Geospatial A statement or diagram should relate the project space to a named global geospatial system in three dimensions (decimal degrees latitude, longitude and elevation in metres) and a plan orientation (decimal degrees clockwise rotation from north) (see Figure A.1).

NOTE 1 Alternatively reference can be made to a standard named projection such as the UK Ordnance Survey grid (see http:// www.ordnancesurvey.co.uk/oswebsite/gps/information/ coordinatesystemsinfo/guidecontents/guide1.html).

NOTE 2 A decimal latitude in degrees requires eight decimal places to achieve positioning to within 1 mm.

Figure A.1

26 • © BSI 2007

Geospatial referencing

2016 • 27 © The British Standards Institution 2015 • 27

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

Annex B (normative) B.1

BS 1192:2007

Quality management Quality policy Quality policy should ensure that models are maintained over their lifetimes. At the outset of any project all facets of the organization of the project’s graphical database should be formulated by the authors of the data with a view to satisfying end users.

NOTE 1 These constitute the in-house standards. Early strategic thinking helps to ensure that all demands made on the model over its lifetime can be met effectively and realistically.

Models, which need to be maintained over long periods of time, might be subject to both major and minor updates and the same in-house standards should be applied to these amendments in order to ensure model integrity is preserved.

In-house standards should be published and regularly reviewed, for example, at the adoption of each new software release. When models are to be extended to cover new topics, consideration should be given to the strategy adopted for structuring the new information and the way it will be integrated. Sustained data quality requires methodical checking at the time of input and persistent discipline when changes are made.

Data quality should be checked systematically. This should include: a) elimination of spurious data outside normal file extents or limits; b) checks on file set-up parameters; c)

testing of container allocations by switching on and off containers;

d) listing of containers; e)

elimination of information which is not to scale;

f)

purging of all unnecessary data;

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

other content checks.

NOTE 2 If an organization is registered under a formal quality management (QM) system to BS EN ISO 9001 its quality policy is clearly identified in a quality manual. Further guidance on the management of the construction design process is given in BS 7000-4.

28 • 2016 28 • © The British Standards Institution 2015

© BSI 2007 •

27

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

BS 1192:2007 BS 1192:2007 B.2 B.2

Data exchange Data To avoidexchange problems associated with data exchange, participants in the exchange process should: To avoid problems associated with data exchange, participants in the exchange process should: a) follow the recommendations given in this standard; a) b) b) c) c) d)

follow theearly recommendations given in should this standard; agree as as possible which data be exchanged, when, and in what format; agree as early as possible which data should be exchanged, when, and inthe what format; agree version of format to be used for data exchange;

agree the procedures version of format be usedand forreport data exchange; establish to test,tomonitor the accuracy of data transfer, and conduct initial data and transfer trials; d) establish procedures to test, monitor report the accuracy of data transfer, and initial transfer trials;of digital data, e) agree a method ofconduct recording eachdata issue and receipt and what constitutes an acceptable transfer. e) agree a method of recording each issue and receipt of digital data, andAspects what constitutes an acceptable transfer.

NOTE that have been found to cause problems include: 1 See 1192-4  NOTE 1 BS 1192:4 COBie for information exchange methods. that been foundto tocause cause problems include:system, NOTE 2 Aspects Aspectsbetween that have havethe been found problems include: a) mismatch entities supported by the sending a) b) b) c) d) c) d)

neutral format, andthe receiving mismatch between entities system; supported by the sending system, line styles and text, particular, text justification, the manner in neutral format, andinreceiving system; which text size is defined, and special fonts; line styles and text, in particular, text justification, the manner in treatment non-graphical data assignment; which text of size is defined, and special fonts; differences the handling and treatment ofinnon-graphical dataspecification assignment; of co-ordinate geometry.

In particular, different software systems might have differences in the handling and specification of co-ordinate adopted different approaches to the specification of co-ordinate geometry. In particular, different software systems might have geometry.

The three most commonly used methods are: adopted different approaches to the specification of co-ordinate 1) real world dimensions; geometry.

The three most commonly used methods are: 2) 1) 2) 3) 3)

arbitrary units which are scaled uniformly for all entities real worldmodel dimensions; in a model; or arbitrary model units which are scaled uniformly for all entities a incombination a model; or of real world dimensions and scale factors as part of an instance. a combination of real world dimensions and scale factors as part of an instance.

Annex C (informative) Annex C (informative) C.1 C.1

Conventions for layer naming in Conventions layer naming in internationalfor projects international projects

Differences between British and international Differences between British and international standards standards BS EN ISO 13567-2 recommends the use of additional characters in each ofISO the 13567-2 required recommends fields, and a more elaborate layering structure, BS EN the use of additional characters in in order to accommodate diverse national requirements and construction each of the required fields, and a more elaborate layering structure, in classification systems. This Code of Practice recommends the use of a order to accommodate diverse national requirements and construction simpler, ISO compatible, layer naming and coding strategy, to minimize classification systems. This Code of Practice recommends the use of a the number different layers used andand reduces data simpler, ISOof compatible, layer naming codingcomplexity strategy, towhen minimize are exchanged between layers the different parties to acomplexity project. when data the number of different used and reduces are exchanged between the different parties to a project.

28 • © BSI 2007 28 • © BSI 2007

2016 • 29 • 29 © The British Standards Institution 2015

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

BS 1192:2007 Table C.1 compares the layer naming required in 5.4.4 with those recommended in BS EN ISO 13567-2.

Table C.1

Differences between international and British layer naming fields

Mandatory/optional field

Field name and order in BS EN ISO 13567-2

Number of characters

Field name and order in BS 1192

Number of characters

M

1. Agent responsible

2

1. Role

1 then hyphen

M

2. Element

6

2. Classification

2–5 then hyphen

M

3. Presentation

2

3. Presentation

1

O

10. User defined

Unlimited

4. Description

Underscore then unlimited

C.2

Managing the relationship between British and international structures A UK organization working on an international project, to which BS EN ISO 13567-2 code conventions for layering are to be applied, can convert layers for export in a straightforward manner because the layer structure in 5.4.4 is a subset of the ISO structure. Data received from overseas organizations can be converted to this structure, but some loss of layer structuring information is likely to occur. UK organizations might therefore be obliged to use a more complex and unfamiliar structure. In such circumstances, it is useful for the project teams to agree at an early stage how they will allocate named containers for specific projects and document these. It is likely that software will be used for converting between the standards.

NOTE BS EN ISO 13567 parts 1 and 2 contain many detailed recommendations on how to exchange data internationally.

Layer management managementsoftware softwareprovides providesoptions optionsfor forconverting converting ISO layers ISO layers BS to layers as in this British Standard. to 1192:2007 layers.

30 • 2016 30 • © The British Standards Institution 2015

© BSI 2007 •

29

BS 1192:2007 BS 1192:2007

BS 1192:2007 BS 1192:2007

BS 1192:2007

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

Bibliography For dated references, only the edition cited applies. For undated Bibliography references, the latest edition of the referenced document (including any Bibliography For dated references, amendments) applies. only the edition cited applies. For undated

BS 1192:2007+A1:2015 references, the latest edition of edition the referenced document any For dated only the cited applies.

For (including undated BS EN ISOreferences, 4157-1, Construction drawings – Designation systems – amendments) applies. references, the latest edition referenced document (including any Part 1: Buildings and partsofofthe buildings BS 1192:2007+A1:2015

Construction drawings – Designation systems – applies.

BS amendments) BS EN EN ISO ISO 4157-1, 4157-2, Construction drawings – Designation systems – Part 1: Buildings and parts of buildings EN2:ISO 4157-1, Construction drawings – Designation BS 1192-4, Collaborative of information - Part 4:systems – Part Room names andproduction numbers

Bibliography BS EN 4157-2,and Construction drawings –requirements Designation systems – Part 1:ISO Buildings parts buildings Fulfilling employer’s information exchange using For dated references, only theof edition cited –applies. undated BS 7000-4, Design management systems Part 4:For Guide to Bibliography BS 1192:2007+A1:2015 Part names and numbers COBie –Room Code practice references, theof latest edition of thedrawings referenced–document (including any BS EN2:ISO 4157-2, Construction Designation systems – managing design in construction BS EN ISO 4157-2, Construction drawings – Designation systems – For dated references, only edition cited –applies. undated amendments) applies.

BS 7000-4, Design management systems Part 4:For Guide to Part 2: Room names and the numbers BS EN 82045-1, Document management – Part 1: Principles and references, the latest edition of the referenced document (including any managing design in construction BS EN ISO 4157-1, Designation systems – 7000-4, Design Construction management drawings systems – –Part 4: Guide to methods amendments) applies.

Part 1:82045-1, Buildings and parts of buildings – Part 1: Principles and BS EN Document management managing design in construction BS EN 82045-2, Document management – Part 2: Metadata BS EN ISO 4157-1, Construction drawings – Designation systems – methods BS EN ISO 4157-2, Construction drawings – Designation systems 82045-1, Document management –applies.

Part 1:For Principles and – elements and information reference model For dated references, only the edition cited undated Part 1: Buildings and parts of buildings Part 2:82045-2, Room and numbers BS EN Document management – Part 2: Metadata methods references, thenames latest edition of the referenced document (including any BS EN ISO 13567-1, Technical product documentation – BS EN ISOand 4157-2, Construction drawings – Designation systems – elements information reference model amendments) applies.

7000-4, Design management systems Part 4: Metadata Guide to BS EN 82045-2, Document –– Part 2: Organization and namingmanagement of layers for CAD – Part 1: Overview Part 2: Room names and numbers managing design in construction BS EN ISOand 13567-1, Technical product documentation elements information reference model – and principles 4157-1, Construction drawings – Designation systems – BS 7000-4, Design management systems – Part 4: Guide to Organization and naming ofoflayers fordocumentation CAD – Part 1: Overview Part 1: Buildings and parts buildings 82045-1, Document management – Part 1: Principles and BS EN ISO 13567-1, Technical product – 13567-2, managing design in construction and principlesand naming of layers for CAD – Part 1: Overview methods Organization 2: Concepts, BS EN ISO 4157-2, Construction drawings – Designation systems – 82045-1, Document management – Part 1: Principles and BS 13567-2, Technical product documentation – and principles format and codes used innumbers construction documentation Part 2:ISO Room names and BS EN EN 82045-2, Document management – Part 2: Metadata methods Organization and naming of layers for CAD – Part 2: Concepts, elements information reference model EN ISOand 13567-2, Technical product documentation – to 9001, Quality management systems BS 7000-4, Design management systems – Part 4: Guide format and codes used in construction documentation BS EN 82045-2, Document management – Part 2: Metadata Organization and naming of layers for CAD – Part 2: Concepts, managing design in construction 13567-1, Technical product documentation BS EN ISO ISO 12006-2, Building construction – Organization –of elements and information reference model BS EN ISO 9001, Quality management systems format and codes used in construction Organization and naming of layers for–documentation CAD –2:Part 1: Overview information about construction works Part Framework for BS EN 82045-1, Document management – Part 1: Principles and BS EN ISO 13567-1, Technical product documentation and principles ISO 12006-2, construction – Organization –of 9001, Quality management systems classification of Building information methods Organizationabout and naming of layers for– CAD –2:Part 1: Overview information construction works Framework for EN ISO 13567-2, Technical product documentation –of BS ISO 12006-2, Building – Part 31, Quantities andconstruction units 82045-2, Document management –Organization Part 2: Metadata and principlesof information classification Organization and naming of layers for 2: Concepts, information construction works – CAD Part –2:Part Framework for elements andabout information reference model ISO 82045-5, Document management – Part 5: Application of BS EN Technical product documentation format and13567-2, codes used in construction documentation – ISO ISO 31, Quantities and units classification of information metadata the construction and facility management BS EN ISO for 13567-1, Technical product documentation – sector Organization and naming of layers for CAD – Part 2: Concepts, EN ISO 9001, Quality management systems ISO 82045-5, Document management – Part 5: Application of BS ISO 31, Quantities and units Organization and naming of layers CAD –Sub-Contract Part 1: Overview [1] GREAT JCTin2005 – Majorfor Project format andBRITAIN: codes used construction documentation metadata forDocument theBuilding construction and facility management and principles BS ISO 12006-2, construction Organization ofsector ISO 82045-5, management 5: Application of (MPSub/G).

London: RICS Books. – –Part BS EN ISO 9001, Quality management systems information about construction works –documentation Part 2: Framework for [1] GREAT BRITAIN: JCT 2005 product –and Major Project Sub-Contract metadata the construction facility management BS EN ISO for 13567-2, Technical – sector BS ISO 12006-2, Building construction – Organization of classification of information (MPSub/G).

London: RICS Books.

Further reading Organization and naming ofinformation layers CAD –Sub-Contract Part 2:for Concepts, PAS 1192-2,BRITAIN: Specification management the [1] GREAT JCT for 2005 – Majorfor Project information about construction worksprojects –documentation Part 2: Framework for format and codes used in construction capital/delivery phase of construction using building BS ISO 31, Quantities and units (MPSub/G).

London: RICS Books.

CONSTRUCTION PROJECT INFORMATION COMMITTEE. Uniclass: classification of information Further reading information modelling Unified classification formanagement the construction industry, 1998. London.

BS ISO 9001, Quality management ISOEN 82045-5, Document –systems Part 5: Application of BS ISO 31, Quantities and units Further reading CONSTRUCTION PROJECT INFORMATION COMMITTEE. Uniclass: Available from: The Association of Consulting Engineers.  PAS 1192-5:2015, Specification for security-minded building metadata for theBuilding construction and facility management BS ISO 12006-2, construction – Organization ofsector Unified classification for the construction industry, London. information modelling, digital built environments and1998. smart asset ISO 82045-5, Document management ––Part 5:2:Application of CONSTRUCTION PROJECT INFORMATION COMMITTEE. Uniclass: A Code information about construction works Part Framework for of [1] GREAT BRITAIN: JCT 2005 of – Major Project Sub-Contract Available from: The Association Consulting Engineers. management  metadata for the construction and facilityLondon. management sector Unified classification for the construction industry, 1998.

London.

Procedure for the Construction Industry.

RIBA Bookshops classification of information (MPSub/G). London: RICS Books.

CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of Available from: The Association of Consulting Engineers. www.ribabookshops.com [1] GREAT BRITAIN: JCT – Major Project Sub-Contract BS ISO 31, Quantities and2005 units Procedure for the Construction Industry. London.

RIBA Bookshops (MPSub/G).

London: RICS Books.

Further reading CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of ISO 82045-5, Document management – Part 5: Application of www.ribabookshops.com Procedure for the Construction Industry.

London.

RIBA Bookshops CONSTRUCTION INFORMATION metadatareading for the PROJECT construction and facilityCOMMITTEE. managementUniclass: sector Further www.ribabookshops.com Unified classification for the construction industry, 1998. London.

[1] GREAT BRITAIN: JCT 2005 – Major Project Sub-Contract CONSTRUCTION PROJECT INFORMATION Available from: The Association of ConsultingCOMMITTEE. 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.

Procedurereading for the Construction Industry. London. RIBA Bookshops Further CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of www.ribabookshops.com 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.

Bibliography

30 • © BSI 2007

CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of Procedure for the Construction Industry. London. RIBA Bookshops www.ribabookshops.com © The British Standards Institution 2015 • 31

30 • © BSI 2007

© The British Standards Institution 2015

30 • © BSI 2007

© The British Standards Institution 2015 • 31 2016 • 31

•

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 and others to shape their combined experience and expertise into standards -based solutions.

Our British Standards and other publications are updated by amendment or revision.

The knowledge embodied in our standards has been carefully assembled in a dependable format and refined through our open consultation process.

Organizations of all sizes and across all sectors choose standards to help them achieve their goals.

Information on standards We can provide you with the knowledge that your organization needs to succeed. Find out more about British Standards by visiting our website at bsigroup.com/standards or contacting our Customer Services team or Knowledge Centre.

Buying standards You can buy and download PDF versions of BSI publications, including British and adopted European and international standards, through our website at bsigroup.com/shop, where hard copies can also be purchased.

If you need international and foreign standards from other Standards Development Organizations, hard copies can be ordered from our Customer Services team.

Subscriptions Our range of subscription services are designed to make using standards easier for you. For further information on our subscription products go to bsigroup.com/subscriptions.

With British Standards Online (BSOL) you’ll have instant access to over 55,000 British and adopted European and international standards from your desktop.

It’s available 24/7 and is refreshed daily so you’ll always be up to date.

You can keep in touch with standards developments and receive substantial discounts on the purchase price of standards, both in single copy and subscription format, by becoming a BSI Subscribing Member.

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 bsmusales@bsigroup.com.

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

We continually improve the quality of our products and services to benefit your business. If you find an inaccuracy or ambiguity within a British Standard or other BSI publication please inform the Knowledge Centre.

Copyright 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 or entity that owns copyright in the information used (such as the international standardization bodies) and has formally licensed such information to BSI for commercial publication and use. Except as permitted under the Copyright, Designs and Patents Act 1988 no extract may be reproduced, stored in a retrieval system or transmitted in any form or by any means – electronic, photocopying, recording or otherwise – without prior written permission from BSI. Details and advice can be obtained from the Copyright & Licensing Department.

Useful Contacts: Customer Services Tel: +44 845 086 9001 Email (orders): orders@bsigroup.com Email (enquiries): cservices@bsigroup.com Subscriptions Tel: +44 845 086 9001 Email: subscriptions@bsigroup.com Knowledge Centre Tel: +44 20 8996 7004 Email: knowledgecentre@bsigroup.com Copyright & Licensing Tel: +44 20 8996 7070 Email: copyright@bsigroup.com