|

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BRITISH STANDARD
BS 1192-5:1998
CIC 01.100.30; 35.240.10
NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW
Construction drawing
practice
Guide for the structuring and exchange
of CAD data
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
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
Amendments issued since publication
Amd. No. Date Text affected
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
Society of Chief Architects of Local Authorities
BS 1192-5:1998
BSI 1998 i
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
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
ii BSI 1998
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.
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.
BSI 1998 1
BS 1192-5:1998
Introduction
This guide to the structuring and exchange of CAD
data has been compiled at a time of unprecedented
change in the development and use of 2D and 3D
CAD systems. These will soon be supplemented by
the introduction of object oriented technology with
the capability of representing all the information
associated with a construction project and its
constituent parts; defining relationships between
parts and relationships between each part/activity
and the project as a whole. At the same time, and in
some cases in advance of the development of
commercially available systems, the BS EN ISO 10303
series of standards for the exchange of product
(STEP) modelling data are being developed to
provide a neutral means of describing construction
product data throughout its life-cycle, independent
from any particular CAD software system.
When fully available, object-orientated programming,
distributed databases and product modelling will not
only enable the transfer of data to take place
between all participants in the design and
construction process, using different software
systems, but will also form the basis for structuring
and sharing component libraries, databases and
archives.
This guide was written to accommodate a 4 digit
element code which may not be compatible beyond
level 2 with some of the newer classification
systems, e.g. Uniclass [1]. Although the
recommendations in this standard are primarily
intended for users and managers of CAD systems, it
is expected that developers of such systems will
support the implementation of this standard.
Guidance is given in annex A, on project
organization and neutral format data exchange.
Guidance on layer name fields and coding
conventions for international projects is given in
annex B.
1 Scope
This British Standard gives guidance and information
on the structuring and exchange of data between
CAD systems, widely used by the construction
industry, to create 2D or 3D geometric models of
construction projects in conjunction with the
preparation of drawings.
This guide covers conceptual classes of information
important to construction industry users, methods of
structuring CAD data and recommends coding rules
and conventions for naming model files, sub- models
and layers. Guidance is also given on drawing
annotation, presentation and the management and
exchange of data between CAD users. An important
use is also to structure data in component libraries
produced by third parties.
This standard does not include guidance on the use
of different data exchange file formats, the exchange
of non-graphic data, structuring and exchange of
data held as object classes and their instances, data
structuring appropriate to specialist engineering
analyses, or the definition and use of data entity
parameters (parametrics).
2 Normative references
The following normative documents contain
provisions which, through reference in this text,
constitute provisions of this part of this British
Standard. For dated references, subsequent
amendments to, or revisions of, any of these
publications do not apply. For undated references,
the latest edition of the publication referred to
applies.
BS 1192-1:1984, Construction drawing practice
Recommendations for general principles.
BS 1192-3:1987, Construction drawing practice
Recommendations for symbols and other graphic
conventions.
BS 1192-4:1984, Construction drawing practice
Recommendations for landscape drawings.
BS 6100-1-1.5.7, Glossary of building and civil
engineering terms General and miscellaneous
Operations; associated plant and equipment
Drawings.
3 Terms and definitions
For the purposes of this British Standard, the
following terms and definitions apply.
NOTE The following terms defined in this standard are
reproduced, the first time they appear in clauses 4 to 11, in bold
type.
3.1
annotation
part of a drawing consisting of letters or numbers
and, where relevant, associated graphic entities
3.2
attribute
trait, quality or characteristic of an entity
3.3
class
collective identity for entities which exhibit common
behaviours and which have common attributes
3.4
clip
portion of a model file that has been copied and
stored as a separate model file
3.5
database
organized collection of data that can be interpreted
and operated on by computer
3.6
data structure
description of the way in which information is
organized within a database
2 BSI 1998
BS 1192-5:1998
3.7
drawing definition
specification of the content and composition of a
particular drawing
3.8
entity
information unit having uniform meaning and use
3.9
instance
occurrence of an entity at a particular location and
orientation within a model or sub-model
3.10
layer
attribute of an entity used for identification
commonly used to control visibility, and for the
classification of entities within a model
3.11
model
collection of model files and associated non-graphic
information
3.12
model file
computer file containing 2D or 3D graphic entities
and any non- graphic data stored with them
3.13
nest
hierarchical arrangement of entities or model files
3.14
object
instance of a class of entities which has individual
state and behaviour and unique identity
3.15
parameter
attribute of an entity which affects its geometry, size
or appearance when drawn
3.16
primitive
entity which is a basic, indivisible, geometrical
element used within computer modelling systems
(e.g. a point, line or arc) which is not defined in
terms of subordinate entities
3.17
reference
instance of a model file
3.18
reference file
model file associated with an active model file and
containing information which can be viewed and
interrogated but not immediately altered
3.19
schema
structure within which information is organized in a
database
3.20
style
parameter affecting the appearance of a primitive
3.21
sub-model
model included as an instance in another model
3.22
wildcarding
text searching based on a template composed of
characters which either appear in a specific position
in the character sequence being sought, or are
wildcard characters such as * or ?, reserved as place
holders or selection delimiters
4 Relationship between drawings and
CAD models
4.1 General
Most proprietary CAD systems used by architects,
contractors, engineers and surveyors create, display,
manipulate and alter graphic entities, store them in
computer files as 2D or 3D graphical models, and
output model data in formats appropriate to their
intended use, typically as construction drawings.
Together, these model files form a graphical
database of project information.
CAD systems may also store, manipulate and output
non-graphic data relating to graphic entities.
However, at present, the data structures of most
systems are not designed to record explicit
information about the relationships and
interdependencies that exist between parts of a
project, or the parts and the whole.
Organizations tend to adopt one of two main
approaches to project modelling for the production
of drawings. They may:
a) build up project data as a series of planar 2D
models, typically relating to plans, sections, and
elevations, by discipline and from these construct
separate 3D models from which to produce
perspective visualizations (see Figure 1); or
b) adopt an approach more akin to product
modelling, build a 3D model or models as
assemblies of entities representing construction
components, and assemble drawings
incorporating 2D or 3D views of 3D model data
(see Figure 2).
The choice of which approach or mix of approaches
to adopt is likely to depend on individual project
requirements and the capabilities of the CAD system
or systems being used. Each organization should
understand why they are adopting a particular
approach in a project. Where CAD data is to be
exchanged with other organizations, the approach
adopted for the production of drawings may need to
be altered to accommodate other members of the
project team.
BSI 1998 3
BS 1192-5:1998
Figure 1 Project data structured as a series of planar 2D models
Figure 2 Drawing definition incorporating views of multiple model files
4 BSI 1998
BS 1192-5:1998
4.2 Drawing definition
A drawing definition is the closest approximation
to a paper drawing that a CAD system will store. It
records the information necessary to create a
specific drawing. Typically, it will store annotation
(drawing number, name, revision notes, dimension
strings, etc.) specific to the drawing, but will present
construction information as interactively defined
views of graphical data stored in one or more model
files (see Figure 2). As a minimum, a drawing
definition will specify the position and scale at
which such views are to be displayed and plotted.
The content of views of 2D model files are specified
in terms of their extent/boundaries, the categories of
graphical data that should be displayed and how
data should be shown. A 3D specification also
includes the view point, the depth of view, and the
type of perspective employed.
The graphic entities held in model files are usually
assigned line styles and other parameters affecting
their appearance when they are created, but when
defining a view users may be permitted to specify
that graphic entities be displayed in a different way.
Most important, and most variable between systems,
are the methods offered to structure, and then
control, what categories of graphic information are
displayed.
Figure 2 shows a drawing definition that
incorporates a 2D view of information assembled in
a model file, which in turn refers to information
stored in other model files.
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
interrogate, read-only data in other files.
Each file is referred to by a reference inserted into
the active file which records the name of the
referenced file and its position, size and orientation
in relation to the active file. It may also include a
specification of which layers within the reference
file should be displayed (see 5.4).
Model file references can be used to:
a) layer model information in the same fashion as
overlay drafting;
b) assemble a composite model from a set of
component models, with little data redundancy;
c) create drawing definitions and make templates
of information which are common to models and
drawings e.g. grids, drawing frames, fixed
annotation etc.;
d) maintain geometric and data consistency, since
changes made to the data in a model file will be
reflected in every other file that refer to it; and
e) view raster images of scanned drawings and
photographs in conjunction with other model data.
CAD systems which support reference files usually
also support instances of sub-models (see 5.3) and
layering of data within individual files (see 5.4).
Some systems also permit nested file references
(see 8.2).
5.3 Sub-models of components and their
instancing
Sub-models are collections of model data that are
either stored or included by reference in the data
structures of model files. Sometimes sub-models are
stored as separate files and are referred to in much
the same way as other model files but often the
information associated with a sub-model is stored
within the substructure of a model file and is only
referred to within the file (see Figure 3).
NOTE The lift, with any associated attributes, would
typically be held as a sub-model, referred to by the instances
in the stair/lift core model file.
Figure 3 Instances of a sub-model of a
component within a model file and model
file references
BSI 1998 5
BS 1192-5:1998
Unlike model file references, sub-model references,
usually called instances, often have non-graphic
attribute data associated with them. Sub-models
are also generally distinguished by the special
treatment they receive. For example, libraries are
designated to hold them, special provisions are made
to view them for selection purposes, to count them,
and to assign, schedule and report on the
non-graphic attribute data associated with them. By
design, they are ideally suited to represent individual
construction components or discrete assemblies of
such components. Sub-models and the entities they
contain are often assigned separate layer attributes
(see 5.4).
Object oriented CAD systems use objects to fulfil
the role played by sub-models of components.
5.4 Layering by layer attribute assignment
Model data can be layered by assigning a layer
attribute to each entity in a model file. This usually
occurs when an entity is created. Entities with the
same assigned layer attribute then form a layer.
Layers are generally named or numbered and an
entity can be transferred between layers by changing
its layer attribute assignment.
Layers of 2D graphical data are similar in concept to
the transparent sheets used in overlay draughting,
with all the entities relating to the same co-ordinate
system. Unlike reference files, all information is held
in a single file and layers formed in this way cannot
be clipped or included by reference in other files.
The visual display of a layer can , however, be
turned on and off. Layering can also sometimes be
used to designate which entities should be ignored
during editing operations, although in practice, the
selective manipulation and editing that can be
performed on layers is usually quite limited.
If faceted names (such as: architect, level 2,
plan, etc.) can be used to identify layers, then each
facet can be associated with a different category of
construction data. Some CAD systems also allow
wildcarding techniques to be used to specify which
categories of model data should be displayed or
manipulated. Model files, sub-models, and objects
can often be handled in a similar fashion by systems
that support their faceted naming, or selection based
on attribute assignment.
6 Classification of information
6.1 Conceptual classes of information
Graphic entities should be structured and classified
so that entities belonging to one or more classes of
information can be selectively displayed, separated,
combined, and exchanged. They can be classified
into the following categories.
a) Agent responsible: the professional discipline of
the author. Each discipline usually maintains its
own models which contain data covering its
particular area of responsibility. Usually one
discipline takes the responsibility for a base or
framework model upon which the others rely.
Almost inevitably there is some duplication of
information so that co-ordination between
disciplines can take place.
Increasingly models of building stock are being
used by strategic divisional planners and managers
within organizations. Although perhaps not the
original authors of the data, their job function and
the fact that they might be the most enduring
users of the graphic database may mean that their
requirements should take precedence.
b) Element: functional parts of construction works
to be designated by a classification system.
Generally, it is recommended that nationally
recognized classifications such as Uniclass [1],
CI/SfB [2], or Common arrangement [3] should be
used for this purpose.
c) Presentation: information stored in model files
or drawing definitions which may need to be
switched on or off for presentation purposes. This
can be information associated with plotted output,
such as drawing borders and drawing annotation,
or to produce views for drawing composition
purposes which contain only a subset of the
information contained in one or more model files.
It may also be information which users working on
models wish to display or suppress for their own
convenience.
d) Sector: a subdivision of a project into physical
locations, such as building, storey or zone.
Because plan levels commonly form the nucleus of
a graphical database, it may often be necessary to
subdivide a plan model containing all information
concerned with a particular level of the building to
satisfy multi-user access requirements and system
response times. Section and elevation planes
which hold quite different data and which are
updated on a different basis are often kept as
separate models.
e) Status: whether parts of a construction project
are new, for retention or demolition, etc.
f) Scale: additional or alternative information
which is used to produce drawings at different
scales with different levels of detail.
Other concepts may also be important, particularly
the subdivision of data by construction phase or
contract work package. Creating new building stock,
or adding to and refurbishing existing property, can
stretch over long periods of time, and may well
progress through various development and approval
stages. Phases blend one into the other. Predictions
on future phases, operations on current phases and
audit trails on past phases, all have their influences
on model structure. Project management
arrangements, particularly on projects with short
programmes, may sometimes require graphical
models to be organized to enable work packages to
be issued to subcontractors. It is therefore important
to take these aspects into consideration from the
outset.
6 BSI 1998
BS 1192-5:1998
6.2 Application of data structuring techniques
Table 1 gives the applicability of different data
structuring techniques described in clause 5 to the
conceptual classes of information described in 6.1.
Table 1 The applicability of alternative
data structuring methods
Conceptual
category
Alternative data structuring methods
Files and
file
referencing
(described
in 5.2)
Sub-models
of
components
and their
instancing
(described
in 5.3)
Layering by
layer
attribute
assignment
(described
in 5.4)
Agent
responsible 1 1 1
Element 1 1 1
Presentation 1 3 1
Sector 1 3 2
Status 2 5 2
Scale 3 4 2
Key:
1 = very applicable
2 = applicable
3 = possible
4 = possible by swapping
5 = unusual
7 Non-graphic data
7.1 General
Many CAD systems incorporate or refer to
non-graphic data which can be associated with
graphic entities. For example, a ventilation diffuser
may have associated data specifying its size and
manufacturer and instances of the diffuser may
associate data specifying the diffuser number and
flow rate, which may vary from instance to instance.
Some systems can identify graphic entities for
purposes of display, manipulation and editing, based
on the attributes associated with them.
Support for the assignment and manipulation of
non-graphic data varies greatly between systems, and
the provision of detailed guidance on this is beyond
the scope of this standard. However, some of the
more commonplace means of structuring
non-graphic data are given in 7.2.
7.2 Types of non-graphic data
7.2.1 Bound attributes
Bound attributes are usually stored within graphic
files as part of an instance. They are bound in the
sense that the schema for the attributes is fixed at
the time of its assignment and cannot be changed.
Generally, each attribute has a name and a format
which may be numeric (either integer or real) or
textual (string). Bound attribute data can be useful
where there is a limited number of non-graphic
attributes and it is certain that the schema will not
undergo change.
7.2.2 Extension attributes
Extension attributes, like bound attributes, are
stored within graphic files as part of an instance;
however, the schema for extension attributes can be
determined instance by instance. It is also often
possible to attach the attributes as values, without an
accompanying name. Where extension attributes are
to be used, care should be taken to ensure that the
schema is specified in conjunction with the values
and their format. It can be confusing when extra
extension attributes are added to some entity
instances, but not included with other instances of
the same nature.
7.2.3 Separate databases
Data may be associated with graphic entities through
references to records stored in an external database
management system. This can be effected by
associating a unique identifying attribute with the
entity and storing the value of this unique attribute,
in the field of a record within a database table.
Because the CAD system and the database are
usually separate, a change in one may not be
reflected immediately in the other. It is therefore
essential when a change is made that a reconciliation
process is undertaken to synchronize both sets of
records.
7.2.4 Objects
Increasingly, CAD systems are making use of objects.
An object is an instance of a class and consequently
has the data and behaviour specified by the class but
its own identity. Objects can also inherit data from
parent objects, thus doing away with the need to
hold data against an object, when it can be held
more efficiently by a parent object.
8 Model files
8.1 Naming
8.1.1 Organization
Document/file management software packages have
given users much more freedom in terms of the
length and content of the names they associate with
files. Model files, however, should be allocated
simple, meaningful names which can be maintained
consistently across projects of varying size and
complexity. Names given to model files should
support their use as reference files so that their
author, subject content, location and other attributes
can be immediately identified.
Model file names should, wherever possible, be both
human and machine readable, with a format based
on a fixed number of characters to allow selection
by wild-carding. Names should be divided into fields,
with each field holding one concept. It is important
that all participants in a project should agree from
the outset which fields are to be mandatory and
which are to be optional.
BSI 1998 7
BS 1192-5:1998
Table 2 Recommended order or usage of model file field names
Field Description Characters Examples
Subject or agent
responsible
The subject content of
the file or the author
code
2 (alphanumeric) SP = small power layout
C- = civil engineer
A- = architect
A1 = architect 1
View Denoting viewing
direction
1 (alphabetical) P = plan view
Z = section Z-Z
N = view from north
Sector or file ID number Portion of project being
viewed; or project
specific file identification
number
4 (alphanumeric);
---- (four hyphens) =
whole project
01AB = level 1, block A,
zone B
1234 = file number
User defined suffix Denoting file status or
revision
1 (alphanumeric) B = revision B
If model files are to be treated as layers for data
exchange purposes, model file name fields should be
based on the mandatory concept fields
recommended for layer naming in 10.3.
8.1.2 Model files representing different 2D views
8.1.2.1 File name coding conventions
All coding conventions should be left justified.
Alphanumeric characters allowed are the letters A-Z,
the numbers 1-9 and two further characters which
should be used in the following way:
a) a hyphen -, which should be used to indicate
that a character position in a field relates to all
possible values of that position. Consequently,
hyphens used to fill out trailing character positions
in a field indicate no further sub-division of
information;
b) an underscore _, which should be used as
character placeholders, where a decision is taken
not to use a field, or that certain trailing character
positions will never be used under the project
layer naming conventions adopted.
8.1.2.2 Coding of 2D model file field names
The recommended order of usage of model files is
given in Table 2.
An example of coding of 2D model file field names is
given in Figure 4.
S P P 0 B 5 F C
Subject
or agent
View Sector
Small power
layout
User
defined
suffix
Plan
view
Level5, block
B, zone F
Revision
C
Figure 4 Example of coding of 2D
model file field names
8.2 Nested model file references
CAD systems vary in terms of the number of files
that a single file is permitted to refer to and the
depth of nested file references supported. The
following principles should be adopted.
a) The number of references to files by a single
file should be limited to the minimum number
consistent with the objectives of the composite
model.
b) Nesting of file references should be avoided
wherever possible.
c) Where it is not possible to avoid nesting, the
maximum depth of nesting should be no greater
than three levels.
8.3 Data exchange with referenced model files
The exchange of a file which incorporates references
to other files should be undertaken with care and
should take into account the following.
a) When a file containing references is exchanged,
the files to which it refers should be exchanged
with it.
b) The references between model files should not
be dependent on the local directory structure of
the computer system of the information provider.
c) The project team should agree a directory
structure which facilitates the exchange and use of
reference models.
9 Sub-models and instances of
sub-models
9.1 General
Sub-models should be used to represent real world
components that can be counted or measured.
Sub-models may have multiple representation
associated with them. Where applicable, 2D
sub-models relating to building assemblies should
conform to BS 1192-1, symbolic representation to
BS 1192-3 and landscaping to BS 1192-4.
8 BSI 1998
BS 1192-5:1998
Figure 5 Example of node and insertion point placement
9.2 Sub-model naming
Sub-model names are usually prefixed with a short
code identifying the purpose of the sub-model or the
author (see 10.3). For example:
A =architect;
T = temporary sub-model for information transfer
between files;
P = project specific sub model which will be
instanced into multiple drawings; or
G =generic component that may be stored in a
library for use on other projects.
Such prefixes are commonly followed by an element
code taken from a recognized construction industry
classification system, e.g. Table 1 of the Cl/SfB
Construction indexing manual, or a project specific
mnemonic describing the sub model. Whichever
naming convention is agreed by project team
members, sub-models should be allocated names
which enable their identification and location,
according to a predictable format which can be
maintained consistently across projects of varying
size and complexity.
9.3 Annotation with component sub-models
It is important to avoid storing annotation and
hatching as part of a sub-model unless it adds
significantly to clarity or is necessary to control the
appearance or content of sub-model instances
(see 11.2 and 11.5.3).
9.4 Alternative component sub-model
representations
Alternative component sub-model representation
should be dimensionally equivalent to the primary
representation for the context in which it is to be
used, and co-ordinate origins and insertion points
should be co-ordinated (see 9.5). Where alternative
representations of a sub-model are created and
stored as separate sub-models, for example as 2D
or 3D sub-models which represent the same
component, the name of the alternative
representation should be associated with that of the
primary sub-model. Where layers are to be used to
control the display of different representations of a
sub-model, users should define an additional layer
name field for this purpose.
9.5 Insertion points and nodes
Insertion points for sub-models should be logically
determined, to enable their correct placement within
model files. The insertion point of an alternative
representation should conform to that of the primary
representation, to ensure correct positioning and to
enable substitutions to be made (see Figure 5).
Independent point entities or nodes should be
included within sub models which are to connect
with other entities in a systematic way, for example,
to form linear runs.
10 Layers and layer naming
10.1 Layer name formats and codes
The following concepts, categories, formats and
codes should be used for allocating layers on
construction projects for the purposes of
communication and management. Those involved in
a project should agree the layers and codes used and
how the data will be transferred between their CAD
systems. The number of different layers used when
information is exchanged between the different
parties to the project should be kept to the minimum
necessary.
Codes used in the layer names should be both
human and machine readable. A format with a fixed
number of characters should be used to allow
selection of layers by wildcarding. Where reserved
codes are given, they should be used only for the
purpose specified. Other codes may be used for
project specific purposes.
Layer names should be divided into fields, with each
field holding one concept. Fields should be specified
as either mandatory or optional. Mandatory fields
should always be included in the layer names.
Optional fields should only be used, as required for
each project.
10.2 Coding rules and conventions
Coding conventions should be as follows.
a) All fields should be left justified.
b) Alphanumeric characters should be chosen
from the letters A-Z and digits 0-9 in addition to
the hyphen -.
BSI 1998 9
BS 1192-5:1998
Table 3 Mandatory fields and recommended character codes
Concept class Characters Recommended character codes
Agent
responsible
1 (alphabetic) A = architects
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
(alphanumeric)
Taken from the element code of a recognized classification system, such as
(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
(alphanumeric)
Model related or page related character representing a hierarchical
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
c) The underscore character _ should be used as
a placeholder for each field character, where all
the character positions in a field or any trailing
character positions at the end of a field, will never
be used, e.g. when a coding system requiring fewer
characters is adopted. The first three fields should
always be used and their characters should not be
replaced by underscore characters, except:
1) where the coding system used has fewer
characters than the field length; or
2) where a manufacturer is creating a catalogue
of components which will by used on various
projects. In this case, the agent responsible
field is unknown and the underscore character
may be used to occupy the character position in
this field.
d) Unused trailing fields in the optional part of the
layer name can be omitted.
e) Where a layer is to be interpreted as relating to
all possible values of a specific character position,
the hyphen character - should be used.
10.3 Mandatory fields
Mandatory fields are given in recommended order of
usage in Table 3.
10.4 Optional fields
Optional fields, in recommended order of usage are
given in Table 4.
10.5 Application of layer codes
Examples of layer naming codes are given in
Figures 6 and 7. Figure 6 gives mandatory codes only.
Figure 7 gives mandatory and optional fields.
10 BSI 1998
BS 1192-5:1998
Table 4 Optional fields
Concept class Characters Recommended character codes
Sector 4
(alphanumeric)
Values used should be decided for each project. The first character may
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
G = 1 : 200
H = 1 : 500
User defined Unlimited string
(alphanumeric)
Project specific. No reserved codes. Any number of characters
A 2 2 0 B E S T A I R S 4 4
- -
D D
Agent Field
Name
Description
Element Presentation
Architect Dimensions Level 2, block
B, zone D
Not
used
Spiral stairs
(using Cl/SfB)
Mandatory Optional
Sector Status Scale User defined
1:50 Stairs
Figure 7 Example of layer coding using both mandatory and optional fields
A 2 4 0
-
D
Agent Field
Name
Description
Element Presentation
Architect Dimensions
Stairs
(using Cl/SfB)
Mandatory
Figure 6 Example of sub-set layer coding
using only mandatory fields
11 Recommendations relating to
drawing annotation and linework
11.1 General
Annotation provides information which cannot be
readily conveyed graphically. Typically, it consists of
the following forms either individually or in
combination:
a) text notes or labels;
b) references, including enclosing circle, rectangle,
polygon etc.;
c) leader line and arrow; and/or
d) dimension line.
11.2 Principles governing graphic appearance
of annotation
The graphical appearance of annotation on drawings
produced by CAD systems should conform to
BS 1192-1. Any strategy adopted should not
contravene the following general principles.
a) The visibility of annotation should be
controllable and therefore arranged on layers
separate from other model or drawing definition
data.
b) Annotations built up from text and graphic
elements should be layered so that they can be
edited as a unit.
c) An annotation that refers to a single graphic
element should be attached to it: those which refer
to many should be independent.
d) Where possible, annotations should be
associated with drawing definitions rather than
model files.
BSI 1998 11
BS 1192-5:1998
11.3 Coupled and strongly-coupled annotations
A coupled annotation, such as a component
dimension or label associated with an element i.e. a
symbol, a component, a contour or an instance label
(e.g. a door number), should be attached to or
grouped with the element to which it refers, such
that it will not become separated, but should be
placed on a separate layer.
A strongly-coupled annotation, such as a reinforced
concrete detail bar tag, weld mark or stair arrow,
should be attached to, or grouped with, the entities
to which it refers and be placed on the same layer.
11.4 Text heights and fonts
Character heights should conform to BS 1192-1. Data
exchange will be facilitated by the use of
conventional fonts. Care should be taken to avoid
the use of system specific fonts or special effects
that distort characters.
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.
11.5.2 Line styles
Line styles should conform to BS 1192-1.
Complicated line styles, particularly those based on
linear patterning where symbols are placed at regular
intervals, should be avoided.
11.5.3 Hatching and fills
Although hatching and fills may be used to good
effect on output drawings, their use in CAD generally
slows down file display rates. Consequently, their
use should be avoided unless it adds significantly to
the clarity of interpretation or information content of
the model. In circumstances where hatching and fills
are considered to be essential, they should always be
placed on separate layers to the graphical
information being annotated. This not only enables
hatching layers to be switched off to speed up
normal working but also helps to isolate any data
exchange problems that may be associated with
hatching or fills.
BS 1192-5:1998
12 BSI 1998
Annex A (normative)
Guidance to CAD system managers
A.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.
These constitute the in-house standards. Early strategic
thinking will help to ensure that all demands made on
the model over its lifetime can be met effectively and
realistically.
Models, which may need to be maintained over long
periods of time, may 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 should be checked
periodically by sampling. This should include:
a) checking for spurious data outside normal file
extents or limits;
b) checks on file set-up parameters;
c) checks on layer listings, and testing of layer
allocations by switching on and off layered
information by individual name facets;
d) listing of model references and sub-model
instances; and
e) dimensional checks (for information which is not
to scale) and checks on the setting-out geometry and
locations of project structures.
If an organization is registered under a formal quality
assurance (QA) system to BS EN ISO 9001, its quality
policy will be clearly identified in a quality manual.
Further guidance on the management of the
construction design process is given in BS 7000-4.
A.2 Neutral format data exchange
A.2.1 Methodology
To avoid problems associated with neutral format data
exchange, participants in the exchange process should:
a) compare the manner in which data can be
structured in the sending and receiving systems, and
the neutral formats supported by available
translators. If regular data exchange is planned it is
common for participants to adjust the way they
structure data to make data transfer as
straightforward as possible, but this should be
balanced against any adverse affects on the
efficiency of individual system usage;
b) agree as early as possible which data should be
exchanged, when, and in what format;
c) establish procedures to test, monitor and report
the accuracy of data transfer, and conduct initial
data transfer trials;
d) agree a method of recording each issue and
receipt of digital data, and what constitutes an
acceptable transfer.
A.2.2 Key aspects
The following information should be agreed:
a) origins to be used for model files and sub models,
together with any necessary rotation, scaling, etc.;
b) file naming, layering, line and text style
conventions;
c) the manner in which model data will be zoned;
d) the version of neutral format that will be used for
data exchange.
A.2.3 Sender's responsibilities
The sender should take care to:
a) check that layer allocations and other agreed
conventions are adhered to prior to transfer;
b) purge files of all unnecessary data;
c) ensure that data sets are complete within
themselves and that no references exist to files
excluded from the transfer set.
A.2.4 Potential pitfalls
Aspects that have been found to cause problems
include:
a) mismatch between the entities supported by the
sending system, neutral format, and receiving
system;
b) line styles and text, in particular, text justification,
the manner in which text size is defined, and special
fonts;
c) the number of layers available in each system;
d) lack of support for instances, or differences in the
way instances are supported;
e) deep nesting of sub-model instances or file
references;
f) treatment of non-graphical data assignment;
g) differences in the handling and specification of
co-ordinate geometry. In particular, CAD system
managers should be aware that different software
systems may have adopted different approaches to
the specification of co-ordinate geometry. The three
most commonly used methods are:
1) real world dimensions;
2) arbitrary model units which are scaled
uniformly for all entities in a model; or
3) a combination of real world dimensions and
scale factors as part of an instance.
BSI 1998 13
BS 1192-5:1998
Table B.1 Differences between international and British layer naming fields
International fields
(ISO 13567-2)
Number of characters National fields (BS 1192 :
Part 5)
Number of characters
Mandatory fields
Order/name: 1. Agent
responsible
2 1. Agent responsible 1
2. Element 6 2. Element 4
3. Presentation 2 3. Presentation 1
Optional fields
Order/name: 4. Status 1

4
4. Sector 4
5. Sector 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
Annex B (informative)
Layer name fields and coding
conventions for international projects
B.1 Differences between British and
international standards
ISO 13567-2 recommends the use of additional
characters in each of the mandatory fields, and a more
elaborate layering structure, in order to accommodate
diverse national requirements and construction
classification systems. This guide recommends the use
of a simpler, ISO compatible, layer naming and coding
strategy, to minimize the number of different layers
used and reduce complexity when data are exchanged
between the different parties to a project.
Table B.1 compares the layer name fields
recommended in 10.3 and 10.4 with those
recommended in ISO 13567-2.
B.2 Managing the relationship between British
and international layer structures
A UK organization working on an international project,
to which ISO 13567-2 code conventions for layering are
to be applied, should be able to convert layers for
export in a straightforward manner, because the layer
structure in this British Standard is a subset of the ISO
structure.
Data received from overseas organizations can be
converted to the British layering structure, but some
loss of layer structuring information is likely to occur.
UK firms may therefore be obliged to use a more
complex and unfamiliar layer structure. In such
circumstances, project teams should agree at an early
stage how they will allocate layers for specific projects
and document these. It is likely that software will be
used for converting layers.
Users wishing to exchange data internationally should
consult ISO 13567-1 and -2, as they contain many
detailed recommendations. Layer management
software should provide options for converting ISO
layers to BS 1192-5 layers.
Bibliography
Standards publications
BS 7000-4:1996, Design management systems Guide
to managing design in construction.
BS EN ISO 9001:1994, Quality systems Model for
quality assurance in design, development, production,
installation and servicing.
BS EN ISO 10303, Industrial automation systems and
integration Product data integration and exchange.
BS EN ISO 10303-1:1994, Overview and fundamental
principles.
ISO 13567-1:1998, Technical product documentation
Organization and naming of layers for CAD
Overview and principles.
ISO 13567-2:1998, Technical product documentation
Organization and naming of layers for CAD
Concepts, format and codes used in construction
documentation.
Other documents
[1] Uniclass Unified classification for the
construction industry: 1998, Building Project
Information Committee. Available from: The
Association of Consulting Engineers, 12 Caxton Street,
London SW1; The Construction Confederation, 82 New
Cavendish Street, London W1; The Royal Institute of
British Architects, 66 Portland Place, London W1; The
Royal Institution of Chartered Surveyors, 12 Great
George Street, London SW1.
[2] Cl/SfB Construction indexing manual (latest
edition), RIBA Publications, Royal Institute of British
Architects, 66 Portland Place, London W1.
[3] Common arrangement of work sections for
building works (latest edition) published by Building
Project Information Committee. Available from the
organizations listed in [1].
BSI
389 Chiswick High Road
London
W4 4AL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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.