Collaborative Production of Architectural, Engineering and Construction Information - Code of Practice

BS 1192:2007
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+A1:2015
Publishing and copyright information

The BSI copyright notice displayed in this document indicates when the
document was last issued.
© The British Standards Institution 2015
Published by BSI Standards Limited 2015
ISBN 978 0 580 90816 3
The follow BSI references relate to the work on this standard:
Committee reference B/555
Draft for comment 07/30163397 DC, 15/30326416 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
BS 1192:2007+A1:2015
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 2015 • i

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

BS 1192:2007+A1:2015
BS 1192:2007
BS 1192:2007
Foreword
Foreword
Publishing information BS 1192:2007
Publishing
This British information
British Standard
Standard isispublished
publishedbybyBSI
BSI and came
Standards into effect
Limited, under
This
on 31British
licence from Standard
December 2007.isIt
The British published by BSI
was prepared
Standards byand came
Technical
Institution and cameinto effect
Committee
into effect B/555,
on
Foreword
on 31 December
31 December 2007.
Construction 2007. It
It was
design, was prepared
preparedand
modelling by Technical
by Technical Committee
Committee
data exchange. B/555,
A list of B/555,
Construction design,modelling
Construction design,
organizations modelling
represented and
on thisand data
data
committee exchange.
exchange.
can A list
A list
be obtained ofonofrequest
organizations
Publishing
organizations
to represented
information
represented
its secretary. onthis
on thiscommittee
committeecancanbebeobtained
obtainedononrequest
request
to its
its secretary.
secretary.
This British Standard is published by BSI and came into effect
Supersession
on 31 December 2007. It was prepared by Technical Committee B/555,
Supersession
This British Standard supersedes BS 1192-5:1998, which is withdrawn.
Construction design, modelling and data exchange. A list of
BS 1192:2007+A1:2015
This British Standard supersedes
supersedes BSBS 1192:2007, which
1192-5:1998, whichisiswithdrawn.
withdrawn.
organizations represented on this committee can be obtained on request
Relationship with other publications
to its secretary.
Relationship
Information
Copyright withinother
about
is claimed publications
this document
Figures 1 to 9. Reproduction of these
Copyright
Supersession
illustrationsisand
Text introduced claimed
making
or in Figures
alteredproducts 1 from
to 9. it
by Amendment Reproduction
might
No. of that
1 isinfringe
indicatedthesecopyright.
in the text by
illustrations
Details
tags  of the
. and
Minormaking
copyright products
owner
editorial changes from
(from it
whom
are notmight
any
tagged.infringe that
permission
This British Standard supersedes BS 1192-5:1998, which is withdrawn. copyright.
to use this
Details of the
illustration maycopyright owner
be sought) can(from whom by
be obtained anycontacting
permissionthe to use this
illustration
BSI Library,may
Relationship be sought)
with
British other
Standards canHouse,
be obtained
publications by contacting
389 Chiswick the
High Road,
BSI Library,
London
Copyright British
claimedStandards
W4is4AL. in FiguresHouse,
1 to 9.389 Chiswick High
Reproduction Road,
of these
London W4
illustrations 4AL.
The changesand making products
incorporated from it might
in this revised standard infringe that copyright.
include:
Details of theincorporated
The changes copyright owner (from
in this whom
revised any permission
standard include: to use this
• Management processes to support collaborative working.
illustration may be sought) can be obtained by contacting the
• Management processes to support collaborative working.
• Extending
BSI Library, British controlled
Standards naming
House, 389to files and directories,
Chiswick High Road, as well
•
London W4 Extending
as layers controlled
4AL. and sub-models. naming to files and directories, as well
as layers and sub-models.
The • Compatibility
changes incorporatedwithinBS ENrevised
this 82045-2 and ISO
standard 82045-5.
include:
• Compatibility with BS EN 82045-2 and ISO 82045-5.
• Incorporation of BS ISOto12006-2
Management processes supportcompliant classification
collaborative working.
• Incorporation
tables, such asof BS ISO 12006-2 compliant classification
Uniclass.
• Extending controlled naming to files and directories, as well
tables, such as Uniclass.
• Recommendations
as layers and sub-models.for implementation of BS EN ISO 13567-2.
• Recommendations for implementation of BS EN ISO 13567-2.
Use•of Compatibility
this document with BS EN 82045-2 and ISO 82045-5.
Use of Incorporation
this
As a •Code document
of Practice, of BS
this ISO 12006-2
British Standardcompliant
takes the classification
form of guidance
As tables,
anda recommendations.
Code such asthis
of Practice, ItUniclass.
Britishnot
should Standard takes
be quoted as the
if itform
wereofa guidance
and recommendations.
specification It
and particular for
• Recommendations should not be quoted
careimplementation
should be taken as
oftoif it were
BSensure
EN ISOa 13567-2.
that claims
specification
of complianceand areparticular care should be taken to ensure that claims
not misleading.
of compliance
Use of this are not misleading.
document
Any user claiming compliance with this British Standard is expected to
As
Anya Code
user of Practice,
claiming
be able to justify any this British
compliance
course ofwithStandard
thisthat
action takes
British the
Standard
deviates form
from is of guidance
itsexpected to
and
be recommendations.
able to justify any course
recommendations. It should not bethat
of action quoted as iffrom
deviates it wereits a
specification
recommendations. and particular care should be taken to ensure that claims
Presentational
of compliance are not conventions
misleading.
Presentational
The conventions
Any provisions
user claiming in this standardwith
compliance are presented
this BritishinStandard
roman (i.e. upright) to
is expected
The
be able to justify any course of action that deviates from its upright)
type.provisions
Its in this
recommendations standard are are presented
expressed in in roman
sentences (i.e.
in which the
type. Its
principal recommendations
auxiliary
recommendations. verb is are expressed
“should”. in sentences in which the
principal auxiliary verb is “should”.
Commentary, explanation and general informative material is
Presentational
Commentary,
presented in smaller conventions
explanationitalic andtype,general
and does informative
not constitute material
a is
The provisions
presented
normative in in this standard
smaller
element. italic type, are and
presented
does notin roman
constitute(i.e. upright)
a
type. Its recommendations
normative element. are expressed in sentences in which the
The word “should” is used to express recommendations of this standard.
The word “should”
“may” is is usedintothe
used express
text torecommendations
express permissibility,of thise.g.
standard.
as an
Commentary,
The word “may”
alternative explanation
to the isprimary theand
textgeneral
used inrecommendation informative
to express the clause.material
of permissibility, Thee.g. isan
as
word
presented
alternative
“can” is used in smaller
to to
the italic
primary
express type, and
e.g. does
recommendation
possibility, ofnot
theconstitute
a consequence clause. anaaction
of The word or
normative
“can” is usedelement.
an event. to express possibility, e.g. a consequence of an action or
an
Theevent.
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. Standards
© The British a consequence © of
BSIan
Institution action
2007
2015 iii
• or
• iii
an event. © BSI 2007 • iii
type. Its recommendations are expressed in sentences in which the
BS 1192:2007+A1:2015 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
BS 1192:2007 “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 • © The British Standards Institution 2015

BS 1192:2007+A1:2015
BS 1192:2007
BS 1192:2007
Introduction
Introduction
Collaboration between the participants in construction projects is
Collaboration
pivotal between delivery
to the efficient the participants in construction
of facilities. Organizations projects
are is
pivotal to theworking
increasingly efficientindelivery of facilities.environments
new collaborative Organizationsinare order to
increasingly
achieve higherworking in new
standards collaborative
of quality environments
and greater re-use ofin order to
existing
achieve higher
knowledge and standards
experience. of Aquality
majorand greater re-use
constituent of theseof collaborative
existing
knowledge andisexperience.
environments the ability to A communicate,
major constituent of these
re-use collaborative
and share data
environments
efficiently is theloss,
without ability to communicate,
contradiction re-use and share data
or misinterpretation.
efficiently without loss, contradiction or misinterpretation.
Each year considerable resources are spent on making corrections to
Each year considerable
non-standard resources
data, training are spentinonapproved
new personnel making corrections
data creation to
non-standardco-ordinating
techniques, data, trainingthe new personnel
efforts in approvedteams
of subcontractor data creation
and
techniques,
solving co-ordinating
problems related to the efforts
data of subcontractor teams and
reproduction.
solving problems related to data reproduction.
The use of this standard is particularly applicable where technology
The use processes
enabled of this standard
are usedis particularly applicableThese
to support projects. where technology
processes
enabled processes are used to support projects. These processes
include:
include:
•
• automation
automationof of drawing
3D model,and document
data, drawing production processes;
and document
• 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
are the implementation
significant benefits to bothof standards is adequately
the productivity addressed,
of project teams and there
the
are significant
profitability of benefits to both the productivity of project teams and the
the organization.
profitability of the organization.
This standard applies to all construction project documentation. The set
This
of standard
project applies to
documents andalleach
construction
document project
withindocumentation.
it are viewed asThe a set
of project of
hierarchy documents and each Itdocument
named containers. within it are viewed
gives recommendations as a
for structured
hierarchy
names of named
to convey containers.
information It gives recommendations
(meta-data) about the containers for structured
required
names
for to convey
effective information
information (meta-data)
management andabout the containers required
exchange.
for effective information management and exchange.
It is clear that standards and this British Standard in particular, are one
It is clear
way that standards
to enable project team andmembers
this British Standard
to work in particular,
together are one
more efficiently
way accurately
and to enable project team members
on construction to work
projects. This together
standard more efficiently
enables
and accurately
increasing on construction
confidence in the useprojects.
of a commonThis standard enables
naming convention and
increasingtoconfidence
approach collaborative in the use offor
working a common naming convention
use in architecture, and
engineering,
approach to collaborative
construction and facilitatesworking
efficient fordata
useusein architecture, engineering,
in facilities management.
construction and facilitates efficient data use in facilities management.
1 Scope
1 This
Scopestandard establishes the methodology for managing the
This standard
production, establishesand
distribution thequality
methodology for managing
of construction the
information,
production,
including distribution
that generated and quality
by CAD of construction
systems, information,
using a disciplined process
including
for that generated
collaboration by CAD naming
and a specified systems,policy.
using a disciplined process
for collaboration and a specified naming policy.
It is applicable to all parties involved in the preparation and use of
It is applicable
information to all parties
throughout involvedconstruction,
the design, in the preparation and and
operation use of
information throughout
deconstruction thethe
throughout design, construction,
project operation
lifecycle and andchain.
the supply
deconstruction throughout the project lifecycle and the supply chain.
The principles for information sharing and common modelling are
The principles
equally for information
applicable to building andsharing
civil and common modelling are
projects.
equally applicable to building and civil projects.
This standard is also a guide for developers of software applications to
This standard
enable them toissupport
also a guide for developersthrough
its implementation of software applications
the provision of to
enable them tofiles
configuration support its implementation
or application add-ons. through the provision of
configuration files or application add-ons.
© BSI2015
© The British Standards Institution • 1
2007 • 1
© BSI 2007 • 1
BS 1192:2007
BS 1192:2007+A1:2015
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
be used because of the absence of a 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, the exchange of non-graphic data, structuring nor
the exchange of data held as object classes and their instances nor the data
structuring appropriate to specialist engineering analyses, nor the
definition and use of data held as instance parameters.
2 Normative references
The following referenced documents are indispensable for the
application of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
BS ISO 12006-2:2001, Building construction – Organization of
information about construction works – Part 2: Framework for
classification of information
NOTE The implementation of BS ISO 12006-2 in the UK is published
under the name “Uniclass".
3 Terms and definitions

For the purposes of this British Standard, the following terms and
definitions apply.
3.1 code
sequence of characters, often a mnemonic, having defined meaning
when interpreted in the context of the field in which it is entered, used
to concisely convey meta-data
3.2 container
named persistent set of data within a file system or application data
storage hierarchy including, but not limited to, directory, sub-directory,
data file, or 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. The actual implementation of
“named containers” might be different in different operating systems and
proprietary file formats. The “named container” pattern is, however,
distinct in that a single name is associated to a collection. The principles
of this standard can be applied independently of the actual
implementation of the “named container” pattern.
NOTE 2 Directories include sub-directories and folders.
NOTE 3 3 Files
Filesinclude
includemodels,
models, sub-models,
sub-models, sheets,
data, documents, tables and
sheets, documents,
schedules.
tables and schedules.
NOTE 4 Containers within files include layers, sections and symbols.
3.3 conventional Cartesian axis

geometric convention using positive co-ordinates (X, Y, Z) ordered as
(East, North, upwards), so that conventional plans use X, Y; and Z is
upwards
2 • ©
2 • © BSI
The2007
British Standards Institution 2015
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 document
[BS EN 82045-1, ISO/IEC 8613-1, 3.2.3 modified]
container for persistent information that can be managed and
3.5 drawing
interchanged as a unit
document used toISO/IEC
[BS EN 82045-1, present 8613-1,
graphic information
3.2.3 modified]
3.6
3.5 field
drawing
part of a container
document name reserved
used to present graphic for meta-data
information
NOTE The standard controls the usage of fields for naming containers
3.6 field
and codes used in those fields.
part of a container name reserved for meta-data
3.7 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 instance
3.8 layer
occurrence of an entity at a particular location and orientation within a
container
model comprising selected entities, typically used to group for
purposes of selective display, printing and management operations
3.8 layer
3.9 meta-data
container comprising selected entities, typically used to group for
data used of
purposes forselective
the description
display,and management
printing of documents
and management and other
operations
containers of information
3.9 meta-data
NOTE Each item of meta-data resides in a field. Codes are the values
data used
allowed forfor the description and management of documents and other
fields.
containers of information
3.10 model
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
3.10 model
NOTE 1 Models can be two-dimensional (2D) or three-dimensional (3D),
collection of containers
and can include graphicalorganized
as well asto represent the
non-graphical physical
content. parts
This of
standard
objects,
is based for example a building
on generating, sharing, or a mechanical
etc., device
model files, not just drawings.
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
NOTE 2 on generating,
Models sharing,
can include etc., model
information byfiles, not just drawings.
reference.
Drawings are produced when the model is complete, correct and
3.11 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
NOTE 2 Models
information neededcan include
to deliver theinformation
project. by reference.
NOTE See Clause 7.
3.11 originator
3.12 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
4 Collaboration management processes
1192:2007+A1:2015 4.1
BS 1192:2007
BS
Process considerations
4.1.1 Standard method and procedure

4 Collaboration management
Projects should follow a common processes
set of generic processes at the highest
level, which are fine-tuned on a project-by-project basis. The
procedures outlined apply to all approaches to project design
4.1 Process considerations
production, including:
4.1.1 • co-ordination
Standard methodofand
the procedure
project model files (2D and 3D) as they
develop;
Projects shouldfollow
Projects should followaacommon
commonset setofofgeneric
genericprocesses
processesatatthe
thehighest
highest
level,•which
level, production
which of 2Don
arefine-tuned
are fine-tuned drawings from 2D andbasis.
ona aproject-by-project
project-by-project 3D models;
basis.
TheThe and
procedures
procedures
outlined
• apply outlined apply to alltoapproaches
to all approaches
production of 2D drawings project 2DtoCAD
usingdesign project design
production,
draughtingand
co‑ordination
production, of the
including:
software. information model. 
• co-ordination of the project model files (2D and 3D) as they
4.1.2 General project issues
develop;
The •project “standard
production ofmethod and procedure”
2D drawings from 2D andshould be agreed
3D models; andand
committed to by all the relevant parties involved in the project (e.g. the
• design
client, production of 2D drawings
consultants, using
supply chain 2D CADetc.)
partners, draughting
at the pre-
software.
construction contract stage in the project lifecycle.
4.1.2 To implement
General the “standard
project issuesmethod and procedure” the following
elements should be in place:
The project “standard method and procedure” should be agreed and
• Roles
committed and
to by allresponsibilities should
the relevant parties be agreed,
involved in theinproject
particular
(e.g.the
the
responsibility for design co-ordination of the various
client, design consultants, supply chain partners, etc.) at the pre- design
disciplines.
construction contract stage in the project lifecycle.
To implement theconventions
• Naming should and
“standard method be adopted according
procedure” to
the following
Clauses 5 to 15.
elements should be in place:
•
• Arrangements should be inshould
Roles and responsibilities place be
to create
agreed,and maintain the
in particular the
project
responsibility for design co-ordination of the variousand
specific codes as described in 6.3 to 15.4.3 design
project spatial co-ordination as described in Annex A.
disciplines.
•
• A “Common
Naming Data Environment”
conventions (CDE) approach
should be adopted accordingshould
to be
adopted to allow
Clauses 5 to 15. information to be shared between all
members of the project team (see 4.2). This is a repository, for
• Arrangements should
example a project be in or
extranet place to create
electronic and maintain the
document
project specific codes
management system. as described in 6.3 to 15.4.3 and
project spatial co-ordination as described in Annex A.
• A suitable information hierarchy should be agreed that
• A “Common
supports theData Environment”
concepts of the CDE (CDE) approach
and the should be
document
adopted to allow information to
repository as indicated in 5.4.2. be shared between all
members of the project team (see 4.2). This is a repository, for
example a project extranet or electronic document
management system.
• A suitable information hierarchy should be agreed that
supports the concepts of the CDE and the document
repository as indicated in 5.4.2.
4 • © BSI 2007
4 • ©
4 • © BSI
The2007
BS 1192:2007+A1:2015
BS 1192:2007
BS 1192:2007
4.2 Process and the Common Data Environment

4.2 Process
(CDE) and the Common Data Environment
(CDE)
4.2.1 Outline of a Common Data Environment
4.2.1 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,
WORK-IN-PROGRESS (WIP)should be placed
(see 4.2.2) into passed
area and the through the
WORK-IN-PROGRESS (WIP)
model in an anti-clockwise (see 4.2.2)
direction areathe
through andphases
passedofthrough
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
NOTECDE
2 are
Thedefined
naming, Clause 5. and identification of all data held in
in numbering
the CDE are defined in Clause 5.
Key to
to the
the process
processisisthe
themanagement
managementofofmoving
movingthethedata
databetween
between each
each
Key tofour
of the the process
phases is the
phases (see
(see management
4.2.2,
4.2.2, of moving
4.2.3,4.2.4
4.2.3, 4.2.4 the it
and4.2.5),
and 4.2.5),data between
itisishere
here each
thatvital
that vital
of the fourapproving
checking,
checking, phases (see
approving  4.2.2,
and 4.2.3,
issuing 4.2.4
processes
, authorizing and and
are4.2.5),
accepting it is here that
executed.
 processes are vital
checking,
executed. approving and issuing processes are executed.
4.2.2 WORK-IN-PROGRESS
4.2.2 WORK-IN-PROGRESS
The WIP area of the CDE (see Figure 2) is where members of the project
The
teamWIP area
carry outoftheir
the CDE
own (see
workFigure
using2) is where
their members software
organization’s of the project
team carry
systems. out their
Whether theown work repository
common using theirororganization’s software
an organization’s in-house
systems.
repositoryWhether
is used,the
thecommon repository
models and or anshould
documents organization’s
employ ain-house
similar
repository is used, the models and documents should
management process as that used for the total project. employ a similar
management process as that used for the total project.
The organization is responsible for the quality of the WIP information
The organization
and should ensureisthat
responsible for the
appropriate qualityand
checking of the WIPprocesses
review information
are
and should
in place. ensure that appropriate checking and review processes are
in place.
NOTE 1 Each model file only contains information for which each design
team is1
NOTE 1 responsible.
Eachmodel
Each model fileText
only contains
deleted information
 only for which each
contains information design
for which
team
each is
 responsible.
task  team is responsible.
NOTE 2 The organization also includes work package subcontractors
who develop
NOTE 2 Thedesign based onalso
organization consultants’
includes design, where contracts
work package require
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
to indicate
data continues to be
be updated
minor version
to updated
changes,ine.g.
in theWIP
the WIParea
area
P02.1, and
etc.,
and should
until
 nextbe indexed
published
options 
to indicate
the minor
SHARED version
area (see changes,
4.2.3). e.g. P02.1, etc., until next
should be indexed to indicate minor version changes, e.g. P02.01, published
to
etc.the
SHARED area
Text deleted (see 4.2.3).
© BSI2015
2007 • 5
© BSI 2007 • 5
BS 1192:2007
BS 1192:2007+A1:2015
Figure 1 Document and data management repository

CLIENT SHARED AREA
SHARED WORK IN PROGRESS
Verified design data shared with the Non-verified design data used by
project team: in-house design team only:
Check, Review, Approve

Ongoing design development
SUITABILITY VER Pnn.n

S0
SUITABILITY REVISION
S1 Pnn Task Team 1
CLIENT SHARED AREA Task Team 2
Task Team 3
Clients Authorization
PUBLISHED
ARCHIVE
DOCUMENTATION
Coordination and validated design Project history maintained for
output for use by the total project knowledge and regulatory and
team. legal requirements.
VERIFIED
Production information sutable for Repository of the project

Stage Completion information for non asset
Acceptance or Construction: portfolio employers.
SUITABILITY REVISION
An Cnn
CLIENT SHARED AREA
NOTE The suffices for the A and B suitabilities refer to the stages.
6 • ©
6 • © BSI
The2007
BS 1192:2007+A1:2015
BS 1192:2007
Figure
Figure 2
2 WORK-IN-PROGRESS (WIP)and
WORK-IN-PROGRESS (WIP) andissue
shareprocess for architects
 process for
model
architects model

ARCHITECTURE WIP
SUITABILITY VERSION

ARCH.
GRID S0 P01.1
ARCH.
WALLS S0 P01.1
ARCH.
COLUMNS S0 P01.1
4.2.3 SHARED
When the data
When the dataisisSHARED
SHAREDwith withthe
theother
othermembers
membersofof
thethe project
project team,
team,
the data
data is
is checked
checkedand
and issued
Text to the CDE
deleted andrevision
 the the revision code
code is is
updated
updated
to indicatetoaindicate a majore.g.
major revision, revision,
P01. e.g. P01.
When
When aa model
modelhas hasreached
reacheda astatus
statusthat
that
is is
“ “fitsuitable
for co-ordination”
 for it
should be uploaded
co‑ordination” to the
it should be SHARED area of the
made available in CDE
the as illustrated
SHARED areain
of
the CDE3.as illustrated in Figure 3.
Figure
NOTE 1 The SHARED area ensures:
• sharing of data in a well-defined context;
• a secure safe space to allow constructive sharing;
• non-adversarial working;
• supports the generation of spatially co-ordinated data as part of
the development process.
NOTE 2 The model is now available to be shared by the whole project
team.
Before uploadingto
Before uploading tothe
theSHARED
SHAREDarea,
area,a amodel
modelshould
shouldbebe reviewed and
reviewed
and checked
checked according
according to compliance
to compliance requirements
requirements ininorder
ordertotobe
befit for a
suitable
specific  for The
purpose. a specific purpose.
information The information
should shouldfor
also be checked also be
checked for to
conformity conformity
Annex B.to Annex B.
The “issue” status should be used to identify the suitability of the
information provided. The “suitability” code (see 15.2.2) gives
ownership to the design teams and restricts access by others until
information is sufficiently developed, co-ordinated, approved and
authorized.
NOTE 3 The suitability codes are distinct from the client/construction
authorization status and from the contractors work packages purpose of
issue.
The data
data shared
sharedwith
withstatus
status“ “FitSuitable
for Co-ordination” should beshould
 for Co-ordination” in thebe
changeable formats.
in the changeable All information
formats. having
All information a different
having status
a different should
status be
should
produced
be producedas as
documents
documents ininnon-changeable
non-changeableformats.
formats.
© BSI2015
2007 • 7
BS 1192:2007
BS 1192:2007+A1:2015
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

SHARED ARCHITECTURE WIP
SUITABILITY REVISION SUITABILITY VERSION

ARCH. ARCH.
WIP to SHARED
GRID S1 P01 GRID S0 P01.1
ARCH. ARCH.
WALLS S1 P01 WALLS S0 P01.1
ARCH. ARCH.
COLUMNS S1 P01 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 this
In this example
examplethat
thatisisS1
S1““fitsuitable  for co-ordination”.
for co-ordination”.
NOTE Any
NOTE Anymember
memberofof the project
the team
project can can
team use the
useshared modelmodel
the shared files forfiles
reference or co-ordination.
for reference Other design
or co-ordination. Other
team members can  reference  the latest versions of models from the SHARED
design team members can download the latest versions of models from the SHARED area of the CDEarea of the CDE as shownasinshown
Figure 4.
in FigureThese reference
4. These download models can
models canbe beused
usedasas
background
background information
informationonto which the recipient
onto which can overlay
the recipient can
their design information. This produces a clash avoidance process.
overlay their design information.
Only graphical models approved, suitable for coordination (S1),

Figure 4 Architects models
should be used uploaded
as a reference.to another disciplines WIP area
8 • ©
8 • © BSI
The2007
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
overlay their design information. BS 1192:2007+A1:2015
Figure
Figure 4
4 Architects models
Architect’s uploaded
SHARED modelstoreferenced
another disciplines WIP
to Structures area
WIP area
BS 1192:2007
Figure 5 Structures co-ordinates its model files using the architecture

8 • © BSI 2007
files as a reference
NOTE In
NOTE Inthe
theexample
example shown
shown in in Figure
Figure 5, structural
5, the the structural engineer
engineer has designed
has designed the structural
the structural member
member sizes and sizes
and takes
takes ownership
ownership of the structural
of the structural column  column
modellayer.
. When Whenthethe structural
structural engineer
engineer uploads
uploads this information
this information into
the
intoSHARED area the
the SHARED areaarchitect’s file is revised
the architect’s file isand re-shared
revised and to remove the
re-shared toarchitectural ownership of the
remove the architectural columns. of
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
the wider
wider project
project team,
team, forfor example
example forfor tenderororconstruction,
tender construction,ititshould
should
be be formally
formally checked,
checked, approved
approved and authorized
and authorized (Figure
(Figure 7). Suitable
7). Suitable
checking and approvals processes should be defined and applied.
checking and approvals processes should be defined and applied. These
should
NOTE applySeeto consultants
PAS 1192-2 for and subcontractors’
a definition of a plan ofdocuments.
work with stages.
Once theoff
The sign document
processeshas beenallow
should approved and
for sign offauthorized, it each
at the end of passes to the
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).
© The British Standards Institution 2015 • 9

BS 1192:2007+A1:2015
Once the document has been approved and authorized, Text deleted
BS 1192:2007 the revision changes from “Preliminary” (Pn) to “Contractual”
(Cn) (see 15.2.3).
Figure
Figure 6
6 Co-ordinated, reviewedand
Co-ordinated, reviewed anduploaded
uploaded models
models issued
sharedto
the
to the
SHARED areaand
SHARED area andduplicate
duplicate
layers removed
information removed
SHARED ARCHITECTURE WIP STRUCTURES WIP
SUITABILITY REVISION SUITABILITY REV/VER

SUITABILITY VERSION
Check Review Approve

WIP to SHARED
ARCH. ARCH.
GRID S1 P01 ARCH.
GRID S1 P01
GRID S0 P01.1
ARCH. ARCH.
WALLS S1 P01 ARCH.
WALLS S1 P01
WALLS S0 P01.1
ARCH. ARCH.
COLUMNS S1 P01 ARCH. COLUMNS S1 P01
COLUMNS S0 P01.1
STRUCT. STRUCT.
COLUMNS S1 P01 COLUMNS S0 P01.1
a) Structures uploads co-ordinated models to SHARED
SHARED ARCHITECTURE WIP STRUCTURES WIP
SUITABILITY REVISION SUITABILITY REV/VER SUITABILITY REV/VER

ARCH. ARCH. ARCH.

GRID S1 P02 GRID S0 P02.1 GRID S1 P01
ARCH. ARCH. ARCH.
WALLS S1 P02 WALLS S0 P02.1 WALLS S1 P01
ARCH.
COLUMNS S1 P01
STRUCT. STRUCT. STRUCT.
COLUMNS S1 P01 COLUMNS S1 P01 COLUMNS S0 P01.1
ARCHITECTURAL
COLUMNS
REMOVED S0 P01.1

b) Change of ownership – Architect downloads, removes their duplicates and resubmits
10 • © The British Standards Institution 2015

Figure 7
Figure 7 Concurrent
Concurrentactivities
activitieswith
withcontinual
continualupload
uploadand
and reference
download
At
At predetermined
predetermineddates dates, stage completion
allordisciplines produce , all disciplines
drawing throughproduce drawings,
extractions from model
datafiles documentation
and from  through
the SHARED extractions
area. This from
is checked, model files
reviewed andfrom the SHARED
verified for
© The British Standards Institution

area.
approval
This in checked,
is the clientreviewed and 
authorization submitted for approval in the client authorization area.
area.
On authorization,
authorization,the theclient
clientallows
allowsthe
thedrawings to be
drawings published
to be published
and deleted.
Textstored.
© BSI 2015
NOTE
NOTE OnceOncethe theprocess
process hashasbeen initiated
been initiated the design
andand teams
the design continue
teams development
continue of the design
development of thedata a concurrent
design engineering
data a concurrent engineering
environmentenvironment
is establishediswith a
established
managed continuous
with a managed reference
continuous  of shared
download and data,
upload illustrated
as of in Figure
shared data, 7.
as illustrated in Figure 7.
• 11
2007 • 11
BS 1192:2007+A1:2015
BS 1192:2007
BS 1192:2007
BS 1192:2007+A1:2015
Figure 8 Suitability “D” is data or documents not authorized by the client
NOTE
NOTE All Allupdates
updatesand
and resharesof
reissues  of any
any documents
documents or or drawingsare
drawings are archived
archived for
forfuture
futureauditing andand
auditing
historical records.
historical records.
NOTE Where
NOTE Wheredocuments
documents areare
required by the
required byconstruction
the constructionteam for purposes
team for
other than construction (e.g. tendering or procurement), at
purposes other than construction (e.g. tendering or procurement), a time prior to at a
their approval
time for construction,
prior to their approval forthe construction,
status “D” is used
theand transferred
status to the
“D” is used and
PUBLISHED/
transferred to the DOCUMENTATION
DOCUMENTATION area
area asasillustrated
illustrated in in Figure
Figure 88
(see 15.3.2).
(see 15.3.2).These
These “D”“D”
status documents
status retain
documents a preliminary
retain revisionrevision
a preliminary reference
“
 P01-P0n 
reference “P1-Pn”. ”.
12 • ©
12 • © BSI
The2007
4.2.5 ARCHIVE
BS 1192:2007+A1:2015
BS 1192:2007
A process should be put in place to enable the continued availability of
BS to
the ARCHIVE area information (see Figure 9), subsequent 1192:2007
the design
and construction phases to support the following:
4.2.5 ARCHIVE
4.2.5 • history of the transfer of the project information;
ARCHIVE
A process should be put in place to enable the continued availability of
the • change
ARCHIVE audits;
area information (see Figure 9),
A process should be put in place to enable the subsequent to the design
continued availability of
and construction
• asset phases
register; to support the following:
the ARCHIVE area information (see Figure 9), subsequent to the design
and construction
• models;ofphases
• history to support
the transfer of thethe following:
project information;
•
• history
change of the transfer of the project information;
audits;
documents;
•
• change
asset audits; e.g. Health and Safety file;
register;
legal purposes,
•
• asset register;
models;
operation and maintenance information.
NOTE• Themodels;
documents;
ARCHIVE area of the CDE is for inactive or superseded
material in addition
• documents; to the
legal purposes, final
e.g. signed-off
Health “As Built”
and Safety file; data and
documentation.
legal purposes,
• operation e.g. Health and
and maintenance Safety file;
information.
Figure 9 Audit trail,
• 1 The data,
operation documents,
andarea
maintenance asset and facility management
NOTE TheARCHIVE
ARCHIVE area of CDEinformation.
of the CDE isfor
is forinactive
inactiveor or superseded
superseded material
information
material held
in additionintoaddition in ARCHIVE
the final signed-off
to the final “Construction
signed-off “As Record”.  and
Built” data
NOTE The ARCHIVE area of the CDE is for inactive or superseded
documentation.
NOTE in 2 addition
For a serial
material to client the ARCHIVE
the final signed-offmay be transferred
“As Built” data andinto the client’s
Asset Information Model (AIM) for continued maintenance and update.
documentation.
Figure 9 Audit trail, data, documents, asset and facility management
Figure 9 information held documents,
Audit trail, data, in ARCHIVEasset and facility management
information held in ARCHIVE
© BSI 2007 • 13
© BSI2015
2007 • 13
© BSI 2007 • 13
BS 1192:2007
BS 1192:2007+A1:2015
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 Codes
5.3.1 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 • © BSI
The2007
BS 1192:2007+A1:2015
BS 1192:2007
BS 1192:2007
5.4 Naming of containers

5.4 Naming of containers
5.4.1 Patterns for naming containers
5.4.1 Patterns for naming
Names for containers containers
should be created according to three patterns:
Names for containers
a) directories should
and folders be 5.4.2);
(see created or
according to three patterns:
a) directories
b) files and folders
(see 5.4.3); or (see 5.4.2); or
b)
c) files (see 5.4.3);
containers withinor
files including layers (see 5.4.4).
c) containers within files including layers (see 5.4.4).
5.4.2 Directories and folders
5.4.2 Directories and
Directories should be folders
transmitted and stored in repositories with names
composed
Directoriesby joining
should be the one mandatory
transmitted andin
and stored two optional fields
repositories given
with names
in Table 1. by
composed Anjoining
exampletheisone
given in 5.5. and two optional fields given
mandatory
in Table 1. An example is given in 5.5. intermediate sub-directories
NOTE Implementations might introduce
based
NOTE onImplementations
fields present inmight
the fileintroduce
naming specified in 5.4.3.
intermediate sub-directories
based on fields present in the file naming specified in 5.4.3.
Table 1 Naming of directories and folder containers
Table 1 Naming of directories and folder containers
Field Obligation Clause
Field
Project Obligation
Required Clause
6
Project
Suitability A) Required
Optional 6
15.3.2
Suitability
Revision A)
A) Optional 15.3.2
15.3.3
Revision
A) A)
If information Optional
passes through 15.3.3track meta-data
an environment that cannot
A) then this field can
If information be included
passes to environment
through an identify the “suitability”
that cannotand “revision”.
track meta-data
Thethen
two this
optional
field fields
can beshould be used
included or omitted
to identify together. and “revision”.
the “suitability”
The two optional fields should be used or omitted together.
5.4.3 Files
5.4.3 Files
Files should be transmitted and stored in repositories in a context which
makes clear be
Files should thetransmitted
fields defined
andfor the directory
stored (see 5.4.2).
in repositories Files should
in a context which
be transmitted
makes clear theand stored
fields in repositories
defined with names
for the directory composed
(see 5.4.2). by
Files should
joining the seven
be transmitted andmandatory and three optional
stored in repositories fields composed
with names given in Table
by 2
(an example
joining is given
the seven in 5.5). and three optional fields given in Table 2
mandatory
(an example
NOTE is given
The file name in 5.5).
also contains the extension suffix identifying the
type
NOTE of application applicable.
The file name also contains the extension suffix identifying the
type of application applicable.
Table 2 Naming of file
Table 2 Naming of file
Field
Project Obligation
Required Clause
6
Project
Originator Required 6
7
Originator
Zones
Volumeand assets
or system Required 7
8.1.2
Zones and
Levels and assets
locations Required 8.1.2
8.1.3
Levels and locations
Type Required 8.1.3
9
Type
Role Required 9
10
Role
Classification Required
Optional 10
11
Classification
Number Optional
Required 11
13
Number
Suitability A) Required
Optional
metadata 13
15.2.2
SuitabilityA)A)
Revision Optional
metadata 15.2.2
15.2.3
Revision
A) A) Optional where there is no
If files pass through an environment 15.2.3
directory context,
A) this field
If files canthrough
pass be included to document
an environment the suitability
where there is noand revision.
directory context,
Thethis
optional
 field fields
metadata
can 
be“suitability”
to and “revision”
fields “suitability”
included document and should
“revision”
the beshould
suitability used or
be omitted
used or together.
and revision.
The optional fields “suitability” and “revision” should be used or omitted together.
omitted together.
© BSI2015
2007 • 15
© BSI 2007 • 15
BS 1192:2007
BS 1192:2007+A1:2015
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 Naming of containers within files including layers

Role Required 10
Classification Required 11
Presentation Required 12
Description Optional 14
5.5 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 Files Containers Clause
(see 5.4.2) (see 5.4.3) within files
including layers
(see 5.4.4)
Project PR1 PR1 6
Originator XYZ 7
Zones
Volumeand assets
or system Z1
V1 8.1.2
Levels and locations 01 8.1.3

Type M3 9
Role A A 10
Classification Uniclass (optional)
G31 (optional) G322 
Uniclass 11
Presentation M 12
Number 0001 13
Description (optional) Doors 14
Suitability (optional) S1 S1 15.2.2
Revision (optional) P02
P2  P02
P2  15.2.3
Name PR1-S1-P2 PR1-XYZ-Z1-01-M3-A-0001 A-Uniclass-M_Doors
A-G322-M_Doors
16 • ©
16 • © BSI
The2007
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 Principles
8.1.1 Types of physical sub-division

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

8.1.2 Volumes and systems
Every container should document a single building zone or asset
Every container
(location), shouldwithin
contained document a single
a simple building
volume volume or
of space.
8.1.2 Zones and assets
system (location), contained within a simple volume of space.
There should be should
Every container at leastdocument
one set ofazones
singleexplicitly
building designated to be
zone or asset
There should be
non-overlapping. at least one set of  volume per role explicitly
(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
NOTE 2WhereWhere possible
possible “ “zones”
volumesshould be defined
” should so as
be defined to identify
so as to identifyaa
NOTE
logical 1portion
The of
logical portion term
of “asset”
work
work might
intended
intended be
to beto more
be appropriate
delivered
delivered for infrastructure
by a single
by a single team. team.
projects.
8.1.3 NOTE 2 and
Levels Where locations
possible “zones” should be defined so as to identify a
logical portion of work intended to be delivered by a single team.
Where a container documents a single building level (floor) or location,
8.1.3 the code and
Levels for that level should be used. Where a container documents
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
8.2 Standard
projects.
codes for divisions
8.2.1 General
8.2 Standard codes for divisions
The standard codes for the spatial divisions of the project should be
8.2.1 used wherever possible.
General
NOTE Building projects are more likely to use standard codes.
The standard codes for the spatial divisions of the project should be
used wherever possible.
8.2.2 Standard
8.2.2 codesfor
Standard codes for
“zone/asset”
“volumes/system”
NOTE Building projects are more likely to use standard codes.
The “
zone/asset” code 
volume/system should be should
” code one orbe
two characters.
one The following
or two characters. The
8.2.2 code should
following
Standard be
code used for
should
codes for a“zone/asset”
whole
be used for alevel.
whole level.
The 00 All zonescode should be one or two characters. The following

“zone/asset”
code list
This should be used
should for a whole
be expanded level.
in the project specific codes.
00 All zones
Wherever codes
possible,for
repetition of theand
same“location”
codes, per Role, should
8.2.3 Standard “levels”
be avoided.
This list should
 be expanded in the project specific codes.
The “level/locator” code should be two characters as follows:
8.2.3 Standard codes
ZZ Multiple for “levels” and “location”
levels
XX
The “levelNo level
Textapplicable
“level/locator” code should
deleted be two
” code characters
should as follows:as follows:
be two characters
GF Ground floor
ZZ Multiple
00 Base levellevels
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:
00
00 Base level
level of
of building
building(where
(whereground
groundfloor
floor
is is
notnot appropriate)
appropriate)
or linear
01 Floor assets
For floor levels1above ground floor, the floor number should be used as
02
follows: Floor 2, etc.
NOTE 1 The location codes for linear assets are likely to require project
specific
For codes.
mezzanine
01 Floor 1the prefix “M” should be used as follows:
02
M1 Floor 2, etc.
Mezzanine above level 01
M2 Mezzanine above“level
For mezzanine the prefix 02, etc.
M” should be used as follows:
For all
M1levels below above
Mezzanine the ground floor the prefix “B” should be used:
level 01
M2
B1 Mezzanine above level 02, etc.
B2,levels
For all etc. below the ground floor the prefix “B” should be used:
NOTE
B1 For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2.
B1
B2, etc.
18 • © BSI 2007 NOTE For floor notation, see BS EN ISO 4157-1 and BS EN ISO 4157-2.
18 • © BSI 2007
The “level/locator” code should be two characters as follows:
ZZ Multiple levels
XX No level applicable BS 1192:2007+A1:2015
GF Ground floor
00 Base level of building (where ground floor is not appropriate)
For floor levels above ground floor, the floor number should be used as
follows:
01 Floor 1
02 Floor 2, etc.
For mezzanine the prefix “M” should be used as follows:
M1 Mezzanine above level 01
M2 Mezzanine above level 02, etc.
For all levels below the ground floor the prefix “B” should be used:
B1
B2, etc.
BS 1192:2007
NOTE 2 For
Forfloor
floornotation, seeBS
notation, see BSEN
ENISO
ISO4157-1
4157-1 and
and BSBS
ENEN ISO
ISO 4157-2.
4157-2.
18 • © BSI 2007 8.3 Project specific codes for divisions
8.3.1 Principles
BS 1192:2007
Project specific codes for divisions should be detailed in the project
space statement (see Annex A). The project specific codes should not
8.3 conflict withspecific
Project codes
the standard for divisions
codes given in 8.2.
NOTE Infrastructure projects are more likely to require project specific
8.3.1 Principles
codes.
8.3.2 Project
8.3.2 Project
Project specific codes
specific
specific for divisions
codes
codes for should
for““zone”
 be
volume detailed
and ” and
“asset”in the project
space statement
“system” (see Annex A). The project specific codes should not
Zone” and
“conflict with“asset” identifiers
the standard should
codes beindefined
given 8.2. as required, with
detailed
“Volume demarcation
” and “ in system
three dimensions andshould
” identifiers descriptions.
be defined as
NOTE Infrastructure projects are more likely to require project specific
required, with detailed demarcation in three dimensions and descriptions.
codes.
8.3.3 Project specific codes for “level” and “location”
8.3.2 Project
“Level” andspecific
“location”codes for “zone”
codes should and
be defined “asset”
with detailed
demarcation especially
“Zone” and “asset” in the should
identifiers verticalbe
dimension and
defined as a detailed
required, with
description.
detailed demarcation in three dimensions and descriptions.
9 Project
8.3.3
Type specific codes for “level” and “location”
“Level” and “location” codes should be defined with detailed
demarcation especially in the vertical dimension and a detailed
9.1 Principles
description.
To aid recognition, every container should contain a single type of
information, e.g. a drawing, location model, typical assembly or detail
9 Typeinformation.
9.1
9.2 Principles
Standard codes for types of information
To
Theaid recognition,
standard codes every
for filecontainer should
containers contain
holding a single
models type of the
and drawings
information,
code e.g.exactly
should be a drawing, location model,
two characters typical assembly or detail
as follows:
information.
DR Drawing
M2 Two dimensional model
9.2 Standard
M3 Threecodes formodel
dimensional types of information
MR Model rendering
The standard codes for file containers holding models and drawings the
VS Visualization
code should be exactly two characters as follows:
SC Schedule or table
DR Drawing
SP Specification
M2 Twoofdimensional
BQ Bill Quantity model
M3 Three dimensional
SC Structural Calculationmodel
MR Model rendering © The British Standards Institution 2015 • 19
NOTE 1 There is no provision to extend this for project specific codes.
VS Visualization
NOTESC2 Schedule
For file containers
or table holding documents there are no standard
9.1 Principles
8.3.1 Principles
BS 1192:2007+A1:2015 information, e.g.codes
Project specific a drawing, locationshould
for divisions model,
betypical assembly
detailed or detail
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
NOTE Infrastructure for types oflikely
are more information
to require project specific
codes.
The standard codes for file containers holding models and drawings the
8.3.2 code should
Project be exactly
specific two characters
codes for “zone”as follows:
and “asset”
DR Drawing
Fileand
types for drawings
“
Zone” “asset” identifiersand models
should be defined as required, with
M2 Two dimensional model
detailed
demarcation
Code File Type in three dimensions and descriptions.
M3 Three dimensional model
AF Model
MR Animation
rendering file (of a model)
8.3.3 Project
CM specific
Combined codes
model for “level”
(combined and “location”
multidiscipline model)
VS Visualization
“Level”
CR
SC and Specific
“location”
Schedule for the clash process
codes should be defined with detailed
or table
DR Specification
demarcation
SP 2D drawingin the vertical dimension and a detailed
especially
M2 Bill of
description.
BQ 2DQuantity
model file
M3 3D
SC Structural model file
Calculation
MR Model rendition file for other renditions, e.g thermal
9 TypeNOTE 1 There is no provision
analysis etc. to extend this for project specific codes.

NOTE VS
2 ForVisualization
file containers fileholding
(of a model)
documents there are no standard
codes mandated.
9.1 File types for documents
Principles
9.3 Code specific
Project File Type codes for “types” of information
BQ
information, Bill
e.g. of quantitieslocation model, typical assembly or detail
a drawing,
Project specific “
CO Correspondence type” codes should be defined for documents.
information.

NOTE CP ThereCost
is noplan
mandate for any project specific codes for drawings.
DB Database
9.2 Standard
FN
codes for types of information
File note

The HS
standard Health
codes forandfile
safety
containers holding models and drawings the

code IE Information
should be exactly two Exchange file as follows:
characters
MI Minutes / action notes
DR Drawing
MS Method statement
M2 Two dimensional model © BSI 2007 • 19
PP Presentation
M3 Three dimensional model
PR Programme

MR
RD
Model rendering
Room data sheet
VS
RI Visualization
Request for Information
RP SC Schedule
Report or table
SP
SA Specification
Schedule of accommodation
CA BQ Bill of Quantity
Calculations
SH SC Structural
Schedule Calculation

NOTE SN
1 ThereSnagging list
is no provision to extend this for project specific codes.
SP Specification
NOTE 2 For file containers holding documents there are no standard
SU
codes Survey
mandated.
9.3 Project specific codes for “types” of information

Project specific “type” codes should be defined for documents.
NOTE There is no mandate for any project specific codes for drawings.
© BSI 2007 • 19

BSBS
1192:2007
1192:2007 BS 1192:2007+A1:2015
1010Role
Role
10.1Principles
10.1 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 11.11.
Clause
10.2Standard
10.2 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 AArchitect
Architect
B BBuilding
Building
Surveyor
Surveyor
C CCivil
Civil
Engineer
Engineer
D DDrainage,
Drainage,
Highways
HighwaysEngineer
Engineer
E EElectrical
Electrical
Engineer
Engineer
F FFacilities
Facilities
Manager
Manager
G GGeographical
Geographical andand
Land
Land
Surveyor
Surveyor
H HHeating
Heating
andandVentilation
Ventilation
Designer
Designer
I I Interior
Interior
Designer
Designer
K KClient
Client
L LLandscape
LandscapeArchitect
Architect
M MMechanical
MechanicalEngineer
Engineer
P PPublic
Public
Health
Health
Engineer
Engineer
Q QQuantity
Quantity
Surveyor
Surveyor
S SStructural
Structural
Engineer
Engineer
T TTownTownandand
Country
Country
Planner
Planner
W WContractor
Contractor
X XSubcontractor
Subcontractor
Y YSpecialist
Specialist
Designer
Designer
Z ZGeneral
General
(non-disciplinary)
(non-disciplinary)
10.3Project
10.3 Project
specific
specific
codes
codes
forfor
roles
roles
TheThe
codes
codes
J, N,
codes J,J,N,
R,
N,R,
U
R,U
or
Uor
VorV
or
Vorlonger
orlonger
longer
codes
codes
codes should
should
shouldbe
beallocated
be allocated
allocated for for
non-standard
non-standard
project
non‑standard project
specific
project specific
specificroles.
roles.
roles listed and published.
1111Classification
Classification
11.1Principles
11.1 Principles
Every container
Every container
should
container should
bebe
should classified
beclassified
classified
bybyaby
asingle
a single
code,
Text code,
taken
deletedtaken
 from
from
thethe
code,
chosen
chosen
takenreference
reference
from dictionary,
dictionary,
the chosen to accurately
to dictionary,
reference accurately describe
describe
to thethe
construction
accurately construction
describe the
assets
assets
represented.
represented.
construction The
assets The
codecode
should
represented.should
 beText
two
be twocharacters
characters
deleted  or more.
or more.
A single
A single
code
code
fromfrom
oneone
table
table
should
should
be used.
be used.
20 20• •© BSI
© BSI
2007
2007 © The British Standards Institution 2015 • 21
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+A1:2015 classified using Table F. BS 1192:2007
Early stage design such as Scheme design and preliminary phases
may initially use Table D for Facilities, Table E for Construction
11.2 Standard codes for classification
Elements, but these are deprecated.
Classification
Classification
CPIC is thecodes
codes shouldbebebody
should
co-ordinating selected
selected from
from afor
system
a system
responsible compliant
compliant
maintaining to
and
to BSupdating
ISO 12006-2:2001,
BS ISO 12006 the and in particular
and the Uniclass
Uniclass from
publication.
classifications.  tables
Reference equivalent
should be made to
to A.7
Text
and
their A.8 for
website
deleted 
Elements, A.9 for Services work and
http://www.productioninformation.org/ forA.13 for
updates.
identified
NOTE Products
2 There and Materials.
 NOTE Referistono
theprovision to extend
BIM TOOLKIT thisUNICLASS
and the through thepublication
project specific
for
dictionary.
NOTE 1 The
latest coding UK implementation
practices.  of BS ISO 12006-2 is Uniclass so this
recommendation can be expressed as follows:
11.3 Project specific
Use Uniclass Table Gcodes for elements
for Building classification
and Table H for Civil
elements, with Table J for services work and Table L for identified
NOTE Thereand
Products is noMaterials.
mandate Information
for any project specific
relating codes for
to Spaces thisbefield.
may
classified using Table F.
12 Presentation
Early stage design such as Scheme design and preliminary phases
may initially use Table D for Facilities, Table E for Construction
Elements, but these are deprecated.
12.1 Principles
CPIC is the co-ordinating body responsible for maintaining and
Everyupdating theshould
container Uniclassbeclassifications. Reference
consistent in its should conventions.
presentational be made to
their website http://www.productioninformation.org/ for updates.
For both drawings and documents, graphical and textual content should
be distinguished
NOTE 2 There isby nousing containers
provision within
to extend this files suchthe
through asproject
layering or
specific
dictionary.
sections.
NOTE This ensures that the information can still be re-used for a variety
11.3 Project specific
of presentational codes
purposes withoutfor classification
conflicting with re-use of information.
NOTE There is no mandate for any project specific codes for this field.
12.2 Standard codes for presentation
12 The standard code for presentation should be exactly one character as
Presentation
follows.
D Dimensioning
12.1 Principles
H Hatching and shading
EveryM container
Model related
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.
NOTE This ensures that the information can still be re-used for a variety
12.3 Project
of specific
presentational codes
purposes withoutfor presentation
conflicting with re-use of information.
BS 1192:2007 NOTE There is no mandate for any project specific codes for this field.
12.2 Standard codes for presentation
The standard code for presentation should be exactly one character as
13 follows.
Number
D Dimensioning
13.1 Principles
H Hatching and shading
© BSI 2007 • 21
M Model related elements
A sequential number should be used
P Plot/paper related elements when a container is one of a series
not distinguished
T Text by any other of the fields defined in Clauses 6 to 12.
NOTE There
NOTE This applies most often
is no provision toto files. this with project specific codes.
extend
13.2
12.3 Standard
Project codingcodes
specific for numbers
for presentation
The numbering
NOTE There is for standard for
no mandate coding should specific
any project be exactly four
codes forinteger
this field.
numeric digits, used sequentially. Leading zeros should be used.
NOTE There is no need to mandate any codes for this field.
13.3 Project specific coding

There is no further restriction for project specific coding
© BSIbut care• 21
2007
should be taken not to embody information present in other fields.
13.2 Standard coding for numbers
The numbering for standard coding should be exactly four integer
numeric digits, used sequentially. LeadingBS
zeros should be used.
1192:2007+A1:2015
NOTE There is no need to mandate any codes for this field.

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.
NOTE 1 This implies that this field is able to be deduced from the other
fields.
NOTE 2 Avoid long, unwieldy and poorly worded descriptions.
14.2 Standard coding for description

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

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 Types of “status”
15.2.1 General
If repositories are not able to track the “status” of each container (for
example a model or drawing) then its “status” should be tracked
through using two fields together:
a) suitability (see 15.2.2); and
22 • © BSI 2007 b) revision (see 15.2.3).
NOTE The
NOTE The “suitability”
“suitability”and
and “revision”
“revision” of aofdocument
a document changes
changes during
during the the
design
 process.
production  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 Standard coding

15.3.1 Standard status codes for “status”
15.2.3 Revision
BS 1192:2007+A1:2015 Every container should carry a “revision” field, indicating the issue
sequence of the contained information.
15.3 Standard coding
15.3.1 Standard status codes for “status”

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

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

BS 1192:2007+A1:2015
Table 5 Standard codes for suitability models and documents
Graphical Non-
Status Description Revision Data Graphical Documents
Data
Work in Progress
Initial status or WIP P01.01 etc
S0 Master document index of file identifiers to P0n.01 ✓ ✓ ✓
uploaded into the extranet. etc
Shared (Non-Contractual)
Suitable for Co-ordination
The file is available to be ‘shared’ and used
S1 P01.01 to ✓ ✗ ✗
by other disciplines as a background for
their information. P0n.01
S2 Suitable for Information P01 to Pnn ✗ ✓ ✓
S3 Suitable for Review & Comment P01 to Pnn As required ✓ ✓
S4 Suitable for Stage Approval P01 to Pnn ✗ ✗ ✓
S5 Suitable for Manufacture P01 to Pnn ✓ ✓ ✓
Suitable for PIM Authorization
S6 P01 to Pnn ✗ ✗ ✓
(Information Exchanges 1-3)
Suitable for AIM Authorization
S7 P01 to Pnn ✗ ✗ ✓
(Information Exchange 6)
WIP to Published
Unauthorized and (Non-contractual) use at risk.
P01.1 etc to
D1 Suitable for Costing ✓ ✓ ✓
Pn.1 etc
P01.1 etc to
D2 Suitable for Tender ✗ ✓ ✓
Pn.1 etc
P01.1 etc to
D3 Suitable for Contractor Design ✓ ✓ ✓
Pn.1 etc
P01.1 etc to
D4 Suitable for Manufacture/Procurement ✗ ✓ ✓
Pn.1 etc
Published Documentation (Contractual)
A1, A2, A3, Approved and accepted as stage complete
C01 to C0n ✓ ✓ ✓
An etc (C= Contractual/Complete)
Partially signed-off:
with minor comments from the Client. All
minor comments should be indicated by P01.01 etc
B1, B2,
the insertion of a cloud and a statement to P0n.0n ✓ ✓ ✓
B3, Bn etc
of ‘in abeyance’ until the comment etc
is resolved, then resubmitted for full
authorization.
Published for AIM Acceptance
As Construction Record documentation,
CR C01 to C0n ✓ ✓ ✓
PDF, Models etc

of design documents for transfer to the contractor or subcontractor. This sign-off process is the same as that for
manually produced drawings and is used again for CAD or electronic data/drawings. Refer to BS 7000-4.
NOTE 2 There is provision to extend this with project specific codes.
A) For construction with minor comments from the client.
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”

Versionscreated
Versions createdwithin
withinthe
theWORK-IN-PROGRESS
WORK-IN-PROGRESS area
area should
should be be
numbered using
numbered usingdecimals,
decimals,e.g.
e.g.
P1.1, P1.2,
P01.1, P1.3,
P01.2, etc., etc.
P01.3
should be
This should bechanged
changedtotointeger
integer P1P01
when
 signed-off by theby
when signed-off originator
the
originator for sharing. Thereafter the version within the WIP area
for sharing. Thereafter the version within the WIP area should become should
become P02.01
P2.1 as detailed in as detailed in 4.2.4.
4.2.4.
Formal revisions
Formal revisionsshould
shouldbe
benumbered
numberedsequentially,
sequentially,marking
marking the
the revision
revision
as either preliminary (P0n) or contractual
either pre-contractual or post-contractual.
 (C0n)  .
Preliminary
Preliminary revisions
revisionsshould
shouldbebenumbered
numbered sequentially as as
sequentially thethe
BS 1192:2007
preliminary
pre-contract
  design
design develops,
develops, e.g. P2,
e.g. P1, P01, P02, P03, etc.
P3, etc.
Contractual revision should be numbered sequentially for
Post contractorrevision
any changes update should be numbered
to the signed-off sequentially
containers, forC01,
e.g.  any C02,
changes
or
C03update to the signed-off containers, e.g. C1, C2, C3, etc.
, etc.
NOTE 1 1 The
The“C”
“C”notation
notation indicates
indicates thatthat
the the container
container can
can be befor
used used for
construction
construction and contractual
or purposes.
contractual purposes (e.g. Stage Completion).
24 • © BSI 2007 NOTE 2
2 There
Thereisisprovision
provisionto extend this this
to extend withwith
project specific
project codes. codes.
specific
15.4.1 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.

BS 1192:2007 BS 1192:2007+A1:2015
Annex A (normative) Project space statement

A.1 General
All models, whether 2D or 3D, should be created using a common
project origin and orientation using a conventional Cartesian axis and
common unit of length. The statements given in A.2 to A.4 should be
included with the project dictionary, and refined as necessary. Models
should be created at 1:1.
Units should be SI units of measure.
NOTE 1 SI units are defined in BS ISO 31.
The basic unit of length within models should be agreed to be metres for
infrastructure projects or millimetres for building.
NOTE 2 The accuracy achievable using the chosen units and origins
might need to be checked.
A.2 Space
A statement or diagram of the project origin and orientation should be
included with the project dictionary. The origin should be related to
both the project grid and to the site context. The orientation should be
related to a specific geospatial north.
NOTE The project origin is best located within or close to the project or
site extent.
A.3 Geospatial
A statement or diagram should relate the project space to a named
global geospatial system in three dimensions (decimal degrees latitude,
longitude and elevation in metres) and a plan orientation (decimal
degrees clockwise rotation from north) (see Figure A.1).
NOTE 1 Alternatively reference can be made to a standard named
projection such as the UK Ordnance Survey grid (see http://
www.ordnancesurvey.co.uk/oswebsite/gps/information/
coordinatesystemsinfo/guidecontents/guide1.html).
NOTE 2 A decimal latitude in degrees requires eight decimal places to
achieve positioning to within 1 mm.
Figure A.1 Geospatial referencing
26 • © BSI 2007 © The British Standards Institution 2015 • 27

BS 1192:2007+A1:2015 BS 1192:2007
Annex B (normative) Quality management

B.1 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 • © The British Standards Institution 2015 © BSI 2007 • 27

BS 1192:2007 BS 1192:2007+A1:2015
BS 1192:2007
B.2 Data exchange

B.2 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) follow
agree astheearly
recommendations given
as possible which in should
data this standard;
be exchanged, when,
b) and in what format;
agree as early as possible which data should be exchanged, when,
c) and
agreeinthe
what format;
version of format to be used for data exchange;
c)
d) agree the procedures
establish version of format
to test,tomonitor
be usedand forreport
data exchange;
the accuracy of
data transfer,
d) establish and conduct
procedures initial
to test, data and
monitor transfer trials;
report the accuracy of
data transfer,
e) agree a methodand
ofconduct
recordinginitial
eachdata
issuetransfer trials;of digital data,
and receipt
and what constitutes an acceptable transfer.
e) agree a method of recording each issue and receipt of digital data,
NOTE
 andAspects
NOTE what constitutes
1 See that
BS 1192:4 an acceptable
have been
COBiefound transfer.
to cause
for information problems include:
exchange methods.
NOTE 2 Aspects
a) mismatch that
that have
Aspectsbetween been
havethe foundto
entities
been found tocause
cause
supported problems
by the
problems include:system,
sending
include:
a) neutral
mismatch format,
betweenandthe
receiving
entities system;
supported by the sending system,
b) neutral format,
line styles andinreceiving
and text, system;
particular, text justification, the manner in
b) which text size is defined, and special fonts;
line styles and text, in particular, text justification, the manner in
c) treatment
which text of non-graphical
size data
is defined, and assignment;
special fonts;
d)
c) differences
treatment ofinnon-graphical
the handling and
dataspecification
assignment; of co-ordinate
d) geometry. In particular, different software systems
differences in the handling and specification might have
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
geometry. dimensions;
The three most commonly used methods are:
2)
1) arbitrary
real worldmodel units which are scaled uniformly for all entities
dimensions;
2) in a model; or
arbitrary model units which are scaled uniformly for all entities
3) a
incombination
a model; or of real world dimensions and scale factors as
3) part of an instance.
a combination of real world dimensions and scale factors as
part of an instance.
Annex C (informative) Conventions for layer naming in

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

28 • © BSI 2007
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 name and Number of Field name and Number of
field order in characters order in BS 1192 characters
BS EN ISO 13567-2
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 software provides options for converting ISO layers
to BS 1192:2007 layers.
30 • © The British Standards Institution 2015 © BSI 2007 • 29

BS 1192:2007 BS 1192:2007+A1:2015
Bibliography
For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any
amendments) applies.
BS EN ISO 4157-1, Construction drawings – Designation systems –
Part 1: Buildings and parts of buildings
BS EN ISO 4157-2, Construction drawings – Designation systems –
Part 2: Room names and numbers
BS 7000-4, Design management systems – Part 4: Guide to
managing design in construction
BS EN 82045-1, Document management – Part 1: Principles and
methods
BS EN 82045-2, Document management – Part 2: Metadata
elements and information reference model
BS EN ISO 13567-1, Technical product documentation –
Organization and naming of layers for CAD – Part 1: Overview
and principles
BS EN ISO 13567-2, Technical product documentation –
Organization and naming of layers for CAD – Part 2: Concepts,
format and codes used in construction documentation
BS EN ISO 9001, Quality management systems
BS ISO 12006-2, Building construction – Organization of
information about construction works – Part 2: Framework for
classification of information
BS ISO 31, Quantities and units
ISO 82045-5, Document management – Part 5: Application of
metadata for the construction and facility management sector
[1] GREAT BRITAIN: JCT 2005 – Major Project Sub-Contract
(MPSub/G). London: RICS Books.
Further reading
CONSTRUCTION PROJECT INFORMATION COMMITTEE. Uniclass:
Unified classification for the construction industry, 1998. London.
Available from: The Association of Consulting Engineers.
CONSTRUCTION PROJECT INFORMATION COMMITTEE. A Code of
Procedure for the Construction Industry. London. RIBA Bookshops
www.ribabookshops.com

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

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW
British Standards Institution (BSI)

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

Collaborative Production of Architectural, Engineering and Construction Information - Code of Practice

Uploaded by

Copyright:

Available Formats

You might also like

Collaborative Production of Architectural, Engineering and Construction Information - Code of Practice

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Collaborative Production of Architectural, Engineering and Construction Information - Code of Practice

Uploaded by

Copyright:

Available Formats

BS 1192:2007

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

Publishing and copyright information

Amendments issued since publication

© The British Standards Institution 2015 • i

ii • © The British Standards Institution 2015

Notes and commentaries are provided throughout the text of this

Contractual and legal considerations

iv • © The British Standards Institution 2015

NOTE 1 The standard is an alternative where the formal meta-data

3 Terms and definitions

3.3 conventional Cartesian axis

3.4 document BS 1192:2007

4.1.1 Standard method and procedure

4.2 Process and the Common Data Environment

Figure 1 Document and data management repository

SHARED WORK IN PROGRESS

Check, Review, Approve

SUITABILITY VER Pnn.n

CLIENT SHARED AREA Task Team 2

Production information sutable for Repository of the project

CLIENT SHARED AREA

Check, Review, Approve

Figure 3 Architects model uploaded from WIP for sharing

SUITABILITY REVISION SUITABILITY VERSION

Check, Review, Approve

Only graphical models approved, suitable for coordination (S1),

Figure 5 Structures co-ordinates its model files using the architecture

© The British Standards Institution 2015 • 9

SHARED ARCHITECTURE WIP STRUCTURES WIP

SUITABILITY REVISION SUITABILITY REV/VER

Check Review Approve

a) Structures uploads co-ordinated models to SHARED

SHARED ARCHITECTURE WIP STRUCTURES WIP

SUITABILITY REVISION SUITABILITY REV/VER SUITABILITY REV/VER

ARCH. ARCH. ARCH.

10 • © The British Standards Institution 2015

© The British Standards Institution

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

5.2 Assigning codes

5.3.2 Standard codes

5.3.3 Project specific codes

5.4 Naming of containers

5.4.4 Containers within files

Table 3 Naming of containers within files including layers

5.5 Examples of naming containers

Table 4 Examples of field usage

Levels and locations 01 8.1.3

6.2 Standard codes for project

6.3 Project specific codes for project

7.2 Standard codes for originator

7.3 Project specific codes for originator

8.1.1 Types of physical sub-division

BS 1192:2007 8.1.2 Zones and assets

The 00 All zonescode should be one or two characters. The following

18 • © BSI 2007 8.3 Project specific codes for divisions

9.3 Project specific codes for “types” of information

20 • © The British Standards Institution 2015