BRITISH STANDARD |

| BS 1192-5:1998
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Construction drawing |
|
|
|
|
|
practice Ð |
|
|
|
|
|
|
|
|
Guide for the structuring and exchange |
|
|
of CAD data |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CIC 01.100.30; 35.240.10 |
|
|
|
|
|
|
|
|
NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW
|
|
|
|
 BS 1192-5:1998

Committees responsible for this

British Standard
The preparation of this British Standard was entrusted to Technical Committee
B/212, Tolerances, drawing practice, modular co-ordination, joints, project
information, computer modelling, upon which the following bodies were
represented:

Architects' and Surveyors' Institute

Association of County Councils
British Institute of Architectural Technologists
Chartered Institute of Building
Chartered Institution of Building Services Engineers
Construction Confederation
Department of the Environment (Building Research Establishment)
Institution of Civil Engineers
Institution of Structural Engineers
Royal Institute of British Architects
Royal Institution of Chartered Surveyors
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

Society of Chief Architects of Local Authorities

This British Standard, having

been prepared under the
direction of the Sector Board for
Building and Civil Engineering,
was published under the
authority of the Standards Board
and comes into effect on
15 August 1998

 BSI 1998
Amendments issued since publication
Amd. No. Date Text affected

The following BSI references

relate to the work on this
standard:
Committee reference B/212
Draft for comment 96/109490 DC

ISBN 0 580 29514 1

 BS 1192-5:1998

Contents

Page
Committees responsible Inside front cover
Foreword ii
Introduction 1
1 Scope 1
2 Normative references 1
3 Terms and definitions 1
4 Relationship between drawings and CAD models 2
5 Common methods of structuring graphic data 4
6 Classification of information 5
7 Non-graphic data 6
8 Model files 6
9 Sub-models and instances of sub-models 7
10 Layers and layer naming 8
11 Recommendations relating to drawing annotation and linework 10
Annex A (normative) Guidance to CAD system managers 12
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

Annex B (informative) Layer name fields and coding conventions for

international projects 13
Bibliography 13
Figure 1 Ð Project data structured as a series of planar 2D models 3
Figure 2 Ð Drawing definition incorporating views of multiple model files 3
Figure 3 Ð Instances of a sub-model of a component within a model file and
model file references 3
Figure 4 Ð Example of coding of 2D model file field names 7
Figure 5 Ð Example of node and insertion point placement 8
Figure 6 Ð Example of sub-set layer coding using only mandatory fields 10
Figure 7 Ð Example of layer coding using both mandatory and optional fields 10
Table 1 Ð The applicability of alternative data structuring methods 6
Table 2 Ð Recommended order or usage of model file field names 7
Table 3 Ð Mandatory fields and recommended character codes 9
Table 4 Ð Optional fields 10
Table B.1 Ð Differences between international and British layer naming fields 13

 BSI 1998 i
 BS 1192-5:1998

Foreword

This British standard has been prepared by Technical Committee B/212. It supersedes
BS 1192-5:1990 which is withdrawn.
The changes incorporated in this new edition reflect the increased use of reference
files and greater experience of CAD data management and exchange. It was prepared
in parallel with ISO 13567 and recommends the use of a simpler, ISO compatible, layer
naming and coding strategy. This minimizes the number of different layers used and
reduces complexity when data are exchanged between different parties to a project.
A British Standard does not purport to include all necessary provisions of a contract.
Users of British Standards are responsible for their correct application.
Compliance with a British Standard does not of itself confer immunity
from legal obligations.
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

Summary of pages
This document comprises a front cover, an inside front cover, pages i and ii, pages 1
to 13 and a back cover.

ii  BSI 1998
 BS 1192-5:1998

Introduction This standard does not include guidance on the use

of different data exchange file formats, the exchange
This guide to the structuring and exchange of CAD of non-graphic data, structuring and exchange of
data has been compiled at a time of unprecedented data held as object classes and their instances, data
change in the development and use of 2D and 3D structuring appropriate to specialist engineering
CAD systems. These will soon be supplemented by analyses, or the definition and use of data entity
the introduction of object oriented technology with parameters (parametrics).
the capability of representing all the information
associated with a construction project and its
constituent parts; defining relationships between 2 Normative references
parts and relationships between each part/activity The following normative documents contain
and the project as a whole. At the same time, and in provisions which, through reference in this text,
some cases in advance of the development of constitute provisions of this part of this British
commercially available systems, the BS EN ISO 10303 Standard. For dated references, subsequent
series of standards for the exchange of product amendments to, or revisions of, any of these
(STEP) modelling data are being developed to publications do not apply. For undated references,
provide a neutral means of describing construction the latest edition of the publication referred to
applies.
product data throughout its life-cycle, independent
from any particular CAD software system. BS 1192-1:1984, Construction drawing practice Ð
Recommendations for general principles.
When fully available, object-orientated programming,
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

BS 1192-3:1987, Construction drawing practice Ð

distributed databases and product modelling will not Recommendations for symbols and other graphic
only enable the transfer of data to take place conventions.
between all participants in the design and
BS 1192-4:1984, Construction drawing practice Ð
construction process, using different software
Recommendations for landscape drawings.
systems, but will also form the basis for structuring
and sharing component libraries, databases and BS 6100-1-1.5.7, Glossary of building and civil
archives. engineering terms Ð General and miscellaneous Ð
Operations; associated plant and equipment Ð
This guide was written to accommodate a 4 digit Drawings.
element code which may not be compatible beyond
level 2 with some of the newer classification
systems, e.g. Uniclass [1]. Although the
3 Terms and definitions
recommendations in this standard are primarily For the purposes of this British Standard, the
intended for users and managers of CAD systems, it following terms and definitions apply.
NOTE The following terms defined in this standard are
is expected that developers of such systems will reproduced, the first time they appear in clauses 4 to 11, in bold
support the implementation of this standard. type.
Guidance is given in annex A, on project 3.1
organization and neutral format data exchange. annotation
Guidance on layer name fields and coding
part of a drawing consisting of letters or numbers
conventions for international projects is given in
and, where relevant, associated graphic entities
annex B.
3.2
attribute
1 Scope trait, quality or characteristic of an entity
This British Standard gives guidance and information 3.3
on the structuring and exchange of data between class
CAD systems, widely used by the construction collective identity for entities which exhibit common
industry, to create 2D or 3D geometric models of behaviours and which have common attributes
construction projects in conjunction with the
preparation of drawings. 3.4
clip
This guide covers conceptual classes of information
important to construction industry users, methods of portion of a model file that has been copied and
structuring CAD data and recommends coding rules stored as a separate model file
and conventions for naming model files, sub- models 3.5
and layers. Guidance is also given on drawing database
annotation, presentation and the management and organized collection of data that can be interpreted
exchange of data between CAD users. An important and operated on by computer
use is also to structure data in component libraries 3.6
produced by third parties. data structure
description of the way in which information is
organized within a database

 BSI 1998 1
 BS 1192-5:1998

3.7 3.20
drawing definition style
specification of the content and composition of a parameter affecting the appearance of a primitive
particular drawing
3.21
3.8
sub-model
entity
model included as an instance in another model
information unit having uniform meaning and use
3.9 3.22
instance wildcarding
occurrence of an entity at a particular location and text searching based on a template composed of
orientation within a model or sub-model characters which either appear in a specific position
in the character sequence being sought, or are
3.10
wildcard characters such as * or ?, reserved as place
layer holders or selection delimiters
attribute of an entity used for identification
commonly used to control visibility, and for the
classification of entities within a model 4 Relationship between drawings and
3.11 CAD models
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

model 4.1 General

collection of model files and associated non-graphic Most proprietary CAD systems used by architects,
information contractors, engineers and surveyors create, display,
3.12 manipulate and alter graphic entities, store them in
model file computer files as 2D or 3D graphical models, and
output model data in formats appropriate to their
computer file containing 2D or 3D graphic entities intended use, typically as construction drawings.
and any non- graphic data stored with them Together, these model files form a graphical
3.13 database of project information.
nest CAD systems may also store, manipulate and output
hierarchical arrangement of entities or model files non-graphic data relating to graphic entities.
3.14 However, at present, the data structures of most
systems are not designed to record explicit
object
information about the relationships and
instance of a class of entities which has individual interdependencies that exist between parts of a
state and behaviour and unique identity project, or the parts and the whole.
3.15 Organizations tend to adopt one of two main
parameter approaches to project modelling for the production
attribute of an entity which affects its geometry, size of drawings. They may:
or appearance when drawn a) build up project data as a series of planar 2D
3.16 models, typically relating to plans, sections, and
primitive elevations, by discipline and from these construct
entity which is a basic, indivisible, geometrical separate 3D models from which to produce
element used within computer modelling systems perspective visualizations (see Figure 1); or
(e.g. a point, line or arc) which is not defined in b) adopt an approach more akin to product
terms of subordinate entities modelling, build a 3D model or models as
assemblies of entities representing construction
3.17 components, and assemble drawings
reference incorporating 2D or 3D views of 3D model data
instance of a model file (see Figure 2).
3.18 The choice of which approach or mix of approaches
reference file to adopt is likely to depend on individual project
model file associated with an active model file and requirements and the capabilities of the CAD system
containing information which can be viewed and or systems being used. Each organization should
interrogated but not immediately altered understand why they are adopting a particular
approach in a project. Where CAD data is to be
3.19 exchanged with other organizations, the approach
schema adopted for the production of drawings may need to
structure within which information is organized in a be altered to accommodate other members of the
database project team.

2  BSI 1998
 BS 1192-5:1998
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

Figure 1 Ð Project data structured as a series of planar 2D models

Figure 2 Ð Drawing definition incorporating views of multiple model files

 BSI 1998 3
 BS 1192-5:1998

4.2 Drawing definition Model file references can be used to:

A drawing definition is the closest approximation a) layer model information in the same fashion as
to a paper drawing that a CAD system will store. It overlay drafting;
records the information necessary to create a b) assemble a composite model from a set of
specific drawing. Typically, it will store annotation component models, with little data redundancy;
(drawing number, name, revision notes, dimension
strings, etc.) specific to the drawing, but will present c) create drawing definitions and make templates
construction information as interactively defined of information which are common to models and
views of graphical data stored in one or more model drawings e.g. grids, drawing frames, fixed
files (see Figure 2). As a minimum, a drawing annotation etc.;
definition will specify the position and scale at d) maintain geometric and data consistency, since
which such views are to be displayed and plotted. changes made to the data in a model file will be
The content of views of 2D model files are specified reflected in every other file that refer to it; and
in terms of their extent/boundaries, the categories of e) view raster images of scanned drawings and
graphical data that should be displayed and how photographs in conjunction with other model data.
data should be shown. A 3D specification also CAD systems which support reference files usually
includes the view point, the depth of view, and the also support instances of sub-models (see 5.3) and
type of perspective employed. layering of data within individual files (see 5.4).
The graphic entities held in model files are usually Some systems also permit nested file references
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

assigned line styles and other parameters affecting (see 8.2).

their appearance when they are created, but when
defining a view users may be permitted to specify 5.3 Sub-models of components and their
that graphic entities be displayed in a different way. instancing
Most important, and most variable between systems, Sub-models are collections of model data that are
are the methods offered to structure, and then either stored or included by reference in the data
control, what categories of graphic information are structures of model files. Sometimes sub-models are
displayed. stored as separate files and are referred to in much
Figure 2 shows a drawing definition that the same way as other model files but often the
incorporates a 2D view of information assembled in information associated with a sub-model is stored
a model file, which in turn refers to information within the substructure of a model file and is only
stored in other model files. referred to within the file (see Figure 3).

5 Common methods of structuring

graphic data
5.1 General
In addition to facilitating the selective display and
manipulation of different categories of information,
CAD project data should be divided into files of
manageable size, to facilitate access by different
users, to maximize the re-use of data and minimize
duplication. Nearly all CAD systems use some
combination of the data structuring methods
described below.
5.2 Model files and file referencing
It is still common to store different categories of
graphic data in separate files, with user access to
data controlled at file level and ªwriteº access
restricted to one file at a time. Although it is not
uncommon to store all the graphic data relating to
an individual drawing in a single file, many CAD
systems also allow a user to open one file as an
active file and then simultaneously display and
NOTE The lift, with any associated attributes, would
interrogate, read-only data in other files. typically be held as a sub-model, referred to by the instances
Each file is referred to by a reference inserted into in the stair/lift core model file.
the active file which records the name of the
Figure 3 Ð Instances of a sub-model of a
referenced file and its position, size and orientation
in relation to the active file. It may also include a component within a model file and model
specification of which layers within the reference file references
file should be displayed (see 5.4).

4  BSI 1998
 BS 1192-5:1998

Unlike model file references, sub-model references, framework model upon which the others rely.
usually called instances, often have non-graphic Almost inevitably there is some duplication of
attribute data associated with them. Sub-models information so that co-ordination between
are also generally distinguished by the special disciplines can take place.
treatment they receive. For example, libraries are Increasingly models of building stock are being
designated to hold them, special provisions are made used by strategic divisional planners and managers
to view them for selection purposes, to count them, within organizations. Although perhaps not the
and to assign, schedule and report on the original authors of the data, their job function and
non-graphic attribute data associated with them. By the fact that they might be the most enduring
design, they are ideally suited to represent individual users of the graphic database may mean that their
construction components or discrete assemblies of requirements should take precedence.
such components. Sub-models and the entities they b) Element: functional parts of construction works
contain are often assigned separate layer attributes to be designated by a classification system.
(see 5.4). Generally, it is recommended that nationally
Object oriented CAD systems use objects to fulfil recognized classifications such as Uniclass [1],
the role played by sub-models of components. CI/SfB [2], or Common arrangement [3] should be
5.4 Layering by layer attribute assignment used for this purpose.
Model data can be layered by assigning a layer c) Presentation: information stored in model files
attribute to each entity in a model file. This usually or drawing definitions which may need to be
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

occurs when an entity is created. Entities with the switched on or off for presentation purposes. This
same assigned layer attribute then form a layer. can be information associated with plotted output,
Layers are generally named or numbered and an such as drawing borders and drawing annotation,
entity can be transferred between layers by changing or to produce views for drawing composition
its layer attribute assignment. purposes which contain only a subset of the
Layers of 2D graphical data are similar in concept to information contained in one or more model files.
the transparent sheets used in overlay draughting, It may also be information which users working on
with all the entities relating to the same co-ordinate models wish to display or suppress for their own
system. Unlike reference files, all information is held convenience.
in a single file and layers formed in this way cannot d) Sector: a subdivision of a project into physical
be clipped or included by reference in other files. locations, such as building, storey or zone.
The visual display of a layer can , however, be Because plan levels commonly form the nucleus of
turned on and off. Layering can also sometimes be a graphical database, it may often be necessary to
used to designate which entities should be ignored subdivide a plan model containing all information
during editing operations, although in practice, the concerned with a particular level of the building to
selective manipulation and editing that can be satisfy multi-user access requirements and system
performed on layers is usually quite limited. response times. Section and elevation planes
If faceted names (such as: architect, level 2, which hold quite different data and which are
plan, etc.) can be used to identify layers, then each updated on a different basis are often kept as
facet can be associated with a different category of separate models.
construction data. Some CAD systems also allow e) Status: whether parts of a construction project
wildcarding techniques to be used to specify which are new, for retention or demolition, etc.
categories of model data should be displayed or f) Scale: additional or alternative information
manipulated. Model files, sub-models, and objects which is used to produce drawings at different
can often be handled in a similar fashion by systems scales with different levels of detail.
that support their faceted naming, or selection based Other concepts may also be important, particularly
on attribute assignment. the subdivision of data by construction phase or
contract work package. Creating new building stock,
6 Classification of information or adding to and refurbishing existing property, can
stretch over long periods of time, and may well
6.1 Conceptual classes of information progress through various development and approval
Graphic entities should be structured and classified stages. Phases blend one into the other. Predictions
so that entities belonging to one or more classes of on future phases, operations on current phases and
information can be selectively displayed, separated, audit trails on past phases, all have their influences
combined, and exchanged. They can be classified on model structure. Project management
into the following categories. arrangements, particularly on projects with short
a) Agent responsible: the professional discipline of programmes, may sometimes require graphical
the author. Each discipline usually maintains its models to be organized to enable work packages to
own models which contain data covering its be issued to subcontractors. It is therefore important
particular area of responsibility. Usually one to take these aspects into consideration from the
discipline takes the responsibility for a base or outset.

 BSI 1998 5
 BS 1192-5:1998

6.2 Application of data structuring techniques 7.2.2 Extension attributes

Table 1 gives the applicability of different data Extension attributes, like bound attributes, are
structuring techniques described in clause 5 to the stored within graphic files as part of an instance;
conceptual classes of information described in 6.1. however, the schema for extension attributes can be
determined instance by instance. It is also often
Table 1 Ð The applicability of alternative possible to attach the attributes as values, without an
data structuring methods accompanying name. Where extension attributes are
Conceptual Alternative data structuring methods to be used, care should be taken to ensure that the
category Files and Sub-models Layering by schema is specified in conjunction with the values
file of layer and their format. It can be confusing when extra
referencing components attribute extension attributes are added to some entity
(described and their assignment
in 5.2) instancing (described
instances, but not included with other instances of
(described in 5.4) the same nature.
in 5.3)
7.2.3 Separate databases
Agent
Data may be associated with graphic entities through
responsible 1 1 1
references to records stored in an external database
Element 1 1 1 management system. This can be effected by
Presentation 1 3 1 associating a unique identifying attribute with the
entity and storing the value of this unique attribute,
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

Sector 1 3 2
in the field of a record within a database table.
Status 2 5 2 Because the CAD system and the database are
Scale 3 4 2 usually separate, a change in one may not be
Key: reflected immediately in the other. It is therefore
1 = very applicable essential when a change is made that a reconciliation
2 = applicable process is undertaken to synchronize both sets of
3 = possible
4 = possible by swapping records.
5 = unusual
7.2.4 Objects
Increasingly, CAD systems are making use of objects.
7 Non-graphic data An object is an instance of a class and consequently
7.1 General has the data and behaviour specified by the class but
Many CAD systems incorporate or refer to its own identity. Objects can also inherit data from
non-graphic data which can be associated with parent objects, thus doing away with the need to
graphic entities. For example, a ventilation diffuser hold data against an object, when it can be held
may have associated data specifying its size and more efficiently by a parent object.
manufacturer and instances of the diffuser may
associate data specifying the diffuser number and 8 Model files
flow rate, which may vary from instance to instance.
Some systems can identify graphic entities for 8.1 Naming
purposes of display, manipulation and editing, based
8.1.1 Organization
on the attributes associated with them.
Support for the assignment and manipulation of Document/file management software packages have
non-graphic data varies greatly between systems, and given users much more freedom in terms of the
the provision of detailed guidance on this is beyond length and content of the names they associate with
the scope of this standard. However, some of the files. Model files, however, should be allocated
more commonplace means of structuring simple, meaningful names which can be maintained
non-graphic data are given in 7.2. consistently across projects of varying size and
complexity. Names given to model files should
7.2 Types of non-graphic data support their use as reference files so that their
7.2.1 Bound attributes author, subject content, location and other attributes
Bound attributes are usually stored within graphic can be immediately identified.
files as part of an instance. They are bound in the Model file names should, wherever possible, be both
sense that the schema for the attributes is fixed at human and machine readable, with a format based
the time of its assignment and cannot be changed. on a fixed number of characters to allow selection
Generally, each attribute has a name and a format by wild-carding. Names should be divided into fields,
which may be numeric (either integer or real) or with each field holding one concept. It is important
textual (string). Bound attribute data can be useful that all participants in a project should agree from
where there is a limited number of non-graphic the outset which fields are to be mandatory and
attributes and it is certain that the schema will not which are to be optional.
undergo change.

6  BSI 1998
 BS 1192-5:1998

If model files are to be treated as layers for data 8.2 Nested model file references
exchange purposes, model file name fields should be CAD systems vary in terms of the number of files
based on the mandatory concept fields that a single file is permitted to refer to and the
recommended for layer naming in 10.3. depth of nested file references supported. The
8.1.2 Model files representing different 2D views following principles should be adopted.
a) The number of references to files by a single
8.1.2.1 File name coding conventions file should be limited to the minimum number
All coding conventions should be left justified. consistent with the objectives of the composite
Alphanumeric characters allowed are the letters A-Z, model.
the numbers 1-9 and two further characters which b) Nesting of file references should be avoided
should be used in the following way: wherever possible.
a) a hyphen ª-º, which should be used to indicate c) Where it is not possible to avoid nesting, the
that a character position in a field relates to all maximum depth of nesting should be no greater
possible values of that position. Consequently, than three levels.
hyphens used to fill out trailing character positions
in a field indicate no further sub-division of 8.3 Data exchange with referenced model files
information; The exchange of a file which incorporates references
b) an underscore ª_º, which should be used as to other files should be undertaken with care and
character placeholders, where a decision is taken should take into account the following.
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

not to use a field, or that certain trailing character a) When a file containing references is exchanged,
positions will never be used under the project the files to which it refers should be exchanged
layer naming conventions adopted. with it.
8.1.2.2 Coding of 2D model file field names b) The references between model files should not
The recommended order of usage of model files is be dependent on the local directory structure of
given in Table 2. the computer system of the information provider.
An example of coding of 2D model file field names is c) The project team should agree a directory
given in Figure 4. structure which facilitates the exchange and use of
reference models.
User
Subject defined 9 Sub-models and instances of
or agent View Sector suffix sub-models
SP P 0 5 BF C 9.1 General
Small power Plan Level5, block Revision Sub-models should be used to represent real world
layout view B, zone F C components that can be counted or measured.
Sub-models may have multiple representation
Figure 4 Ð Example of coding of 2D associated with them. Where applicable, 2D
model file field names sub-models relating to building assemblies should
conform to BS 1192-1, symbolic representation to
BS 1192-3 and landscaping to BS 1192-4.

Table 2 Ð Recommended order or usage of model file field names

Field Description Characters Examples
Subject or agent The subject content of 2 (alphanumeric) SP = small power layout
responsible the file or the author C- = civil engineer
code A- = architect
A1 = architect 1
View Denoting viewing 1 (alphabetical) P = plan view
direction Z = section Z-Z
N = view from north
Sector or file ID number Portion of project being 4 (alphanumeric); 01AB = level 1, block A,
viewed; or project ---- (four hyphens) = zone B
specific file identification whole project 1234 = file number
number
User defined suffix Denoting file status or 1 (alphanumeric) B = revision B
revision

 BSI 1998 7
 BS 1192-5:1998

9.2 Sub-model naming 9.5 Insertion points and nodes

Sub-model names are usually prefixed with a short Insertion points for sub-models should be logically
code identifying the purpose of the sub-model or the determined, to enable their correct placement within
author (see 10.3). For example: model files. The insertion point of an alternative
representation should conform to that of the primary
A = architect;
representation, to ensure correct positioning and to
T = temporary sub-model for information transfer enable substitutions to be made (see Figure 5).
between files;
P = project specific sub model which will be Independent point entities or ªnodesº should be
instanced into multiple drawings; or included within sub models which are to connect
with other entities in a systematic way, for example,
G = generic component that may be stored in a
to form linear runs.
library for use on other projects.
Such prefixes are commonly followed by an element 10 Layers and layer naming
code taken from a recognized construction industry
classification system, e.g. Table 1 of the Cl/SfB 10.1 Layer name formats and codes
Construction indexing manual, or a project specific The following concepts, categories, formats and
mnemonic describing the sub model. Whichever codes should be used for allocating layers on
naming convention is agreed by project team construction projects for the purposes of
members, sub-models should be allocated names communication and management. Those involved in
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

which enable their identification and location, a project should agree the layers and codes used and
according to a predictable format which can be how the data will be transferred between their CAD
maintained consistently across projects of varying systems. The number of different layers used when
size and complexity. information is exchanged between the different
9.3 Annotation with component sub-models parties to the project should be kept to the minimum
It is important to avoid storing annotation and necessary.
hatching as part of a sub-model unless it adds Codes used in the layer names should be both
significantly to clarity or is necessary to control the human and machine readable. A format with a fixed
appearance or content of sub-model instances number of characters should be used to allow
(see 11.2 and 11.5.3). selection of layers by wildcarding. Where reserved
9.4 Alternative component sub-model codes are given, they should be used only for the
representations purpose specified. Other codes may be used for
Alternative component sub-model representation project specific purposes.
should be dimensionally equivalent to the primary Layer names should be divided into fields, with each
representation for the context in which it is to be field holding one concept. Fields should be specified
used, and co-ordinate origins and insertion points as either mandatory or optional. Mandatory fields
should be co-ordinated (see 9.5). Where alternative should always be included in the layer names.
representations of a sub-model are created and Optional fields should only be used, as required for
stored as separate sub-models, for example as 2D each project.
or 3D sub-models which represent the same 10.2 Coding rules and conventions
component, the name of the alternative
representation should be associated with that of the Coding conventions should be as follows.
primary sub-model. Where layers are to be used to a) All fields should be left justified.
control the display of different representations of a b) Alphanumeric characters should be chosen
sub-model, users should define an additional layer from the letters A-Z and digits 0-9 in addition to
name field for this purpose. the hyphen ª-º.

Figure 5 Ð Example of node and insertion point placement

8  BSI 1998
 BS 1192-5:1998

c) The underscore character ª_º should be used as d) Unused trailing fields in the optional part of the
a placeholder for each field character, where all layer name can be omitted.
the character positions in a field or any trailing e) Where a layer is to be interpreted as relating to
character positions at the end of a field, will never all possible values of a specific character position,
be used, e.g. when a coding system requiring fewer the hyphen character ª-º should be used.
characters is adopted. The first three fields should
always be used and their characters should not be 10.3 Mandatory fields
replaced by underscore characters, except: Mandatory fields are given in recommended order of
1) where the coding system used has fewer usage in Table 3.
characters than the field length; or 10.4 Optional fields
2) where a manufacturer is creating a catalogue Optional fields, in recommended order of usage are
of components which will by used on various given in Table 4.
projects. In this case, the ªagent responsibleº
field is unknown and the underscore character 10.5 Application of layer codes
may be used to occupy the character position in Examples of layer naming codes are given in
this field. Figures 6 and 7. Figure 6 gives mandatory codes only.
Figure 7 gives mandatory and optional fields.

Table 3 Ð Mandatory fields and recommended character codes

Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

Concept class Characters Recommended character codes

Agent 1 (alphabetic) A = architects
responsible B = building surveyors
C = civil engineers
D = drainage, sewage and road engineers
E = electrical engineers
F = facilities managers
G = geographical information system engineers and land surveyors
H = heating and ventilating engineers
I = interior designers
K = client
L = landscape architects
M = mechanical engineers
P = public health engineers
Q = quantity surveyors
S = structural engineers
T = town and country planners
W = contractors
X = subcontractors
Y = specialist designers
Z = general (non-disciplinary)
NOTE J, R, U or V may be allocated to other agents on particular projects.
Element 4 Taken from the element code of a recognized classification system, such as
(alphanumeric) (alphanumeric)Cl/SfB Table 1, CAWS (common arrangement), or Uniclass.
For example:
K36_ = external walls (using Uniclass)
244_ = spiral stairs (using Cl/SfB)
K31_ = plasterboard fixed partitions (using CAWS)
621_ = electrical services (using Cl/SfB)
NOTE Underscore characters should be added when less than four characters are used.
Non specific characters should be coded as hyphens. Hyphens followed by underscores in
this field indicate that the layer relates to the whole model or drawing.
Presentation 1 Model related or page related character representing a hierarchical
(alphanumeric) sub-division
D = dimensioning
G = grid
H = hatching
M = model related graphics
P = page/plot related graphics
T = text
- (hyphen) = whole model or drawing definition

 BSI 1998 9
 BS 1192-5:1998

Table 4 Ð Optional fields

Concept class Characters Recommended character codes
Sector 4 Values used should be decided for each project. The first character may
(alphanumeric) be a hyphen to indicate a negative value. The following are examples of
possible use:
-1A3 = basement, block A, zone 3
---- (four hyphens) = whole extent of project
Status 1 (alphabetic) N = new work
E = existing (to remain)
R = remove
T = temporary work
- (hyphen) = whole project
Scale 1 (alphabetic) A=1:1
B=1:5
C = 1 : 10
D = 1 : 20
E = 1 : 50
F = 1 : 100
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

G = 1 : 200
H = 1 : 500
User defined Unlimited string Project specific. No reserved codes. Any number of characters
(alphanumeric)

11.2 Principles governing graphic appearance

Mandatory of annotation
Field Agent Element Presentation The graphical appearance of annotation on drawings
produced by CAD systems should conform to
Name A 240 - D BS 1192-1. Any strategy adopted should not
Description Architect Stairs Dimensions contravene the following general principles.
(using Cl/SfB) a) The visibility of annotation should be
controllable and therefore arranged on layers
Figure 6 Ð Example of sub-set layer coding separate from other model or drawing definition
using only mandatory fields data.
b) Annotations built up from text and graphic
elements should be layered so that they can be
11 Recommendations relating to edited as a unit.
drawing annotation and linework c) An annotation that refers to a single graphic
11.1 General element should be attached to it: those which refer
Annotation provides information which cannot be to many should be independent.
readily conveyed graphically. Typically, it consists of d) Where possible, annotations should be
the following forms either individually or in associated with drawing definitions rather than
combination: model files.
a) text notes or labels;
b) references, including enclosing circle, rectangle,
polygon etc.;
c) leader line and arrow; and/or
d) dimension line.

Mandatory Optional
Field Agent Element Presentation Sector Status Scale User defined
Name A 244- D 0 2 BD - E STAIRS
Description Architect Spiral stairs Dimensions Level 2, block Not 1:50 Stairs
(using Cl/SfB) B, zone D used

Figure 7 Ð Example of layer coding using both mandatory and optional fields

10  BSI 1998
 BS 1192-5:1998

11.3 Coupled and strongly-coupled annotations 11.5.2 Line styles

A coupled annotation, such as a component Line styles should conform to BS 1192-1.
dimension or label associated with an element i.e. a Complicated line styles, particularly those based on
symbol, a component, a contour or an instance label linear patterning where symbols are placed at regular
(e.g. a door number), should be attached to or intervals, should be avoided.
grouped with the element to which it refers, such
that it will not become separated, but should be 11.5.3 Hatching and fills
placed on a separate layer. Although hatching and fills may be used to good
A strongly-coupled annotation, such as a reinforced effect on output drawings, their use in CAD generally
concrete detail bar tag, weld mark or stair arrow, slows down file display rates. Consequently, their
should be attached to, or grouped with, the entities use should be avoided unless it adds significantly to
to which it refers and be placed on the same layer. the clarity of interpretation or information content of
the model. In circumstances where hatching and fills
11.4 Text heights and fonts are considered to be essential, they should always be
Character heights should conform to BS 1192-1. Data placed on separate layers to the graphical
exchange will be facilitated by the use of information being annotated. This not only enables
conventional fonts. Care should be taken to avoid hatching layers to be switched off to speed up
the use of system specific fonts or special effects normal working but also helps to isolate any data
that distort characters. exchange problems that may be associated with
hatching or fills.
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

11.5 Linework
11.5.1 Line thickness
CAD systems offer a wide choice of line thickness.
To ensure good appearance and legibility, line
thickness should be in accordance with BS 1192-1,
which recommends a line thickness range of 0.18 mm
to 2 mm and a thickness ratio between any two lines
of not less than 2:1.

 BSI 1998 11
 BS 1192-5:1998

Annex A (normative) b) agree as early as possible which data should be

exchanged, when, and in what format;
Guidance to CAD system managers c) establish procedures to test, monitor and report
A.1 Quality policy the accuracy of data transfer, and conduct initial
Quality policy should ensure that models are data transfer trials;
maintained over their lifetimes. At the outset of any d) agree a method of recording each issue and
project all facets of the organization of the project's receipt of digital data, and what constitutes an
graphical database should be formulated by the acceptable transfer.
authors of the data with a view to satisfying end users.
A.2.2 Key aspects
These constitute the in-house standards. Early strategic
thinking will help to ensure that all demands made on The following information should be agreed:
the model over its lifetime can be met effectively and a) origins to be used for model files and sub models,
realistically. together with any necessary rotation, scaling, etc.;
Models, which may need to be maintained over long b) file naming, layering, line and text style
periods of time, may be subject to both major and conventions;
minor updates and the same in-house standards should c) the manner in which model data will be zoned;
be applied to these amendments in order to ensure
model integrity is preserved. In-house standards should d) the version of neutral format that will be used for
be published and regularly reviewed, for example, at data exchange.
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

the adoption of each new software release. A.2.3 Sender's responsibilities

When models are to be extended to cover new topics, The sender should take care to:
consideration should be given to the strategy adopted a) check that layer allocations and other agreed
for structuring the new information and the way it will conventions are adhered to prior to transfer;
be integrated.
b) purge files of all unnecessary data;
Sustained data quality requires methodical checking at
the time of input and persistent discipline when c) ensure that data sets are complete within
changes are made. Data should be checked themselves and that no references exist to files
periodically by sampling. This should include: excluded from the transfer set.
a) checking for spurious data outside normal file A.2.4 Potential pitfalls
extents or limits; Aspects that have been found to cause problems
b) checks on file set-up parameters; include:
c) checks on layer listings, and testing of layer a) mismatch between the entities supported by the
allocations by switching on and off layered sending system, neutral format, and receiving
information by individual name facets; system;
d) listing of model references and sub-model
b) line styles and text, in particular, text justification,
instances; and
the manner in which text size is defined, and special
e) dimensional checks (for information which is not fonts;
to scale) and checks on the setting-out geometry and
locations of project structures. c) the number of layers available in each system;
If an organization is registered under a formal quality d) lack of support for instances, or differences in the
assurance (QA) system to BS EN ISO 9001, its quality way instances are supported;
policy will be clearly identified in a quality manual. e) deep nesting of sub-model instances or file
Further guidance on the management of the references;
construction design process is given in BS 7000-4. f) treatment of non-graphical data assignment;
A.2 Neutral format data exchange g) differences in the handling and specification of
A.2.1 Methodology co-ordinate geometry. In particular, CAD system
managers should be aware that different software
To avoid problems associated with neutral format data systems may have adopted different approaches to
exchange, participants in the exchange process should: the specification of co-ordinate geometry. The three
a) compare the manner in which data can be most commonly used methods are:
structured in the sending and receiving systems, and
1) real world dimensions;
the neutral formats supported by available
translators. If regular data exchange is planned it is 2) arbitrary model units which are scaled
common for participants to adjust the way they uniformly for all entities in a model; or
structure data to make data transfer as 3) a combination of real world dimensions and
straightforward as possible, but this should be scale factors as part of an instance.
balanced against any adverse affects on the
efficiency of individual system usage;

12  BSI 1998
 BS 1192-5:1998

Annex B (informative) layers to BS 1192-5 layers.

Layer name fields and coding
conventions for international projects Bibliography
Standards publications
B.1 Differences between British and
international standards BS 7000-4:1996, Design management systems Ð Guide
to managing design in construction.
ISO 13567-2 recommends the use of additional
characters in each of the mandatory fields, and a more BS EN ISO 9001:1994, Quality systems Ð Model for
elaborate layering structure, in order to accommodate quality assurance in design, development, production,
diverse national requirements and construction installation and servicing.
classification systems. This guide recommends the use BS EN ISO 10303, Industrial automation systems and
of a simpler, ISO compatible, layer naming and coding integration Ð Product data integration and exchange.
strategy, to minimize the number of different layers BS EN ISO 10303-1:1994, Overview and fundamental
used and reduce complexity when data are exchanged principles.
between the different parties to a project. ISO 13567-1:1998, Technical product documentation Ð
Table B.1 compares the layer name fields Organization and naming of layers for CAD Ð
recommended in 10.3 and 10.4 with those Overview and principles.
recommended in ISO 13567-2.
ISO 13567-2:1998, Technical product documentation Ð
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

B.2 Managing the relationship between British Organization and naming of layers for CAD Ð
and international layer structures Concepts, format and codes used in construction
A UK organization working on an international project, documentation.
to which ISO 13567-2 code conventions for layering are Other documents
to be applied, should be able to convert layers for [1] Uniclass Ð Unified classification for the
export in a straightforward manner, because the layer construction industry: 1998, Building Project
structure in this British Standard is a subset of the ISO Information Committee. Available from: The
structure. Association of Consulting Engineers, 12 Caxton Street,
Data received from overseas organizations can be London SW1; The Construction Confederation, 82 New
converted to the British layering structure, but some Cavendish Street, London W1; The Royal Institute of
loss of layer structuring information is likely to occur. British Architects, 66 Portland Place, London W1; The
UK firms may therefore be obliged to use a more Royal Institution of Chartered Surveyors, 12 Great
complex and unfamiliar layer structure. In such George Street, London SW1.
circumstances, project teams should agree at an early [2] Cl/SfB Construction indexing manual (latest
stage how they will allocate layers for specific projects edition), RIBA Publications, Royal Institute of British
and document these. It is likely that software will be Architects, 66 Portland Place, London W1.
used for converting layers.
[3] Common arrangement of work sections for
Users wishing to exchange data internationally should building works (latest edition) published by Building
consult ISO 13567-1 and -2, as they contain many Project Information Committee. Available from the
detailed recommendations. Layer management organizations listed in [1].
software should provide options for converting ISO

Table B.1 Ð Differences between international and British layer naming fields
International fields Number of characters National fields (BS 1192 : Number of characters
(ISO 13567-2) Part 5)
Mandatory fields
Order/name: 1. Agent 2 1. Agent responsible 1
responsible
2. Element 6 2. Element 4
3. Presentation 2 3. Presentation 1
Optional fields
Order/name: 4. Status 1 4. Sector 4
ç
è
5. Sector 4 5. Status 1
6. Phase 1 Ð Ð
7. Projection 1 Ð Ð
8. Scale 1 6. Scale 1
9. Work package 2 Ð Ð
10. User defined Unlimited string 7. User defined Unlimited string

 BSI 1998 13
 |
|
|
|
|
|
|
|
|
BSI Ð British Standards Institution
|
|
|
|
|
|
| BSI is the independent national body responsible for preparing British Standards. It
|
| presents the UK view on standards in Europe and at the international level. It is
| incorporated by Royal Charter.
|
|
| Revisions
|
|
| British Standards are updated by amendment or revision. Users of British Standards
|
| should make sure that they possess the latest amendments or editions.
|
|
| It is the constant aim of BSI to improve the quality of our products and services. We
|
| would be grateful if anyone finding an inaccuracy or ambiguity while using this
| British Standard would inform the Secretary of the technical committee responsible,
|
| the identity of which can be found on the inside front cover. Tel: 020 8996 9000.
|
| Fax: 020 8996 7400.
|
|
| BSI offers members an individual updating service called PLUS which ensures that
|
| subscribers automatically receive the latest editions of standards.
|
|
| Buying standards
|
| Orders for all BSI, international and foreign standards publications should be
|
| addressed to Customer Services. Tel: 020 8996 9001. Fax: 020 8996 7001.
|
|
Licensed copy:Bisons Concrete, 07/06/2005, Uncontrolled Copy, © BSI

| In response to orders for international standards, it is BSI policy to supply the BSI
|
| implementation of those that have been published as British Standards, unless
|
| otherwise requested.
|
|
| Information on standards
|
| BSI provides a wide range of information on national, European and international
|
| standards through its Library and its Technical Help to Exporters Service. Various
|
| BSI electronic information services are also available which give details on all its
|
| products and services. Contact the Information Centre. Tel: 020 8996 7111.
|
| Fax: 020 8996 7048.
|
|
| Subscribing members of BSI are kept up to date with standards developments and
| receive substantial discounts on the purchase price of standards. For details of
|
| these and other benefits contact Membership Administration. Tel: 020 8996 7002.
|
| Fax: 020 8996 7001.
|
|
| Copyright
|
|
| Copyright subsists in all BSI publications. BSI also holds the copyright, in the UK, of
|
| the publications of the international standardization bodies. Except as permitted
| under the Copyright, Designs and Patents Act 1988 no extract may be reproduced,
|
| stored in a retrieval system or transmitted in any form or by any means ± electronic,
|
| photocopying, recording or otherwise ± without prior written permission from BSI.
|
|
| This does not preclude the free use, in the course of implementing the standard, of
|
| necessary details such as symbols, and size, type or grade designations. If these
|
| details are to be used for any other purpose than implementation then the prior
| written permission of BSI must be obtained.
|
|
| If permission is granted, the terms may include royalty payments or a licensing
|
| agreement. Details and advice can be obtained from the Copyright Manager.
|
| Tel: 020 8996 7070.
|
|
|
|
|
|
|
|
|
BSI |
|
389 Chiswick High Road |
|
London |
|
W4 4AL |
|
|
|
|
|
|