BS-1192!5!1998 - Drafting Code

BRITISH STANDARD

Construction drawing practice Ð Guide for the structuring and exchange of CAD data

CIC 01.100.30; 35.240.10

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

BS 1192-5:1998

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

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

Date

Text affected

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

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

 BSI 1998

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 1

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 2

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

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

 BSI 1998

3

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.

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

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). 4

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

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  BSI 1998

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

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

Agent responsible Element Presentation Sector Status Scale

Alternative data structuring methods Files and file referencing (described in 5.2)

1 1 1 1 2 3

Sub-models of components and their instancing (described in 5.3)

Layering by layer attribute assignment (described in 5.4)

1 1 3 3 5 4

1 1 1 2 2 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. 6

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

BS 1192-5:1998

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.

Subject or agent

View

SP

P

Small power Plan view layout

User defined suffix

Sector

0 5 BF

C

Level5, block Revision C B, zone F

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.

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 4 (alphanumeric); viewed; or project ---- (four hyphens) = specific file identification whole project number

01AB = level 1, block A, zone B 1234 = file number

User defined suffix

Denoting file status or revision

B = revision B

 BSI 1998

1 (alphanumeric)

7

BS 1192-5:1998

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 ª-º.

Figure 5 Ð Example of node and insertion point placement

8

 BSI 1998

BS 1192-5:1998

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.

Table 3 Ð Mandatory fields and recommended character codes Concept class

Agent responsible

Characters

1 (alphabetic)

Recommended character codes

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

 BSI 1998

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 9

BS 1192-5:1998

Table 4 Ð Optional fields Concept class

Characters

Sector

Recommended character codes

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 1 (alphabetic) N = new work E = existing (to remain) R = remove T = temporary work - (hyphen) = whole project 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 Unlimited string Project specific. No reserved codes. Any number of characters (alphanumeric)

Status

Scale

User defined

Mandatory Field Name

Agent

A

Element

240

Presentation

D

-

Description Architect Stairs Dimensions (using Cl/SfB)

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.

Mandatory Field Name

Agent

Element

A

244-

Optional

Presentation

D

Description Architect Spiral stairs Dimensions (using Cl/SfB)

Sector

0 2 BD

Status Scale

-

Level 2, block Not used B, zone D

E 1:50

User defined

STAIRS Stairs

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

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) 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; 12

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

BS 1192-5:1998

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

Table B.1 Ð Differences between international and British layer naming fields International fields (ISO 13567-2)

Number of characters National fields (BS 1192 : Number of characters Part 5)

1. Agent responsible 2. Element 3. Presentation

2

1. Agent responsible

1

6 2

2. Element 3. Presentation

4 1

4. Status 5. Sector 6. Phase 7. Projection 8. Scale 9. Work package 10. User defined

1 ç è 4 1 1 1 2 Unlimited string

4. Sector 5. Status Ð Ð 6. Scale Ð 7. User defined

4 1 Ð Ð 1 Ð Unlimited string

Mandatory fields

Order/name:

Optional fields

Order/name:

 BSI 1998

13

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.