<< Previous | Next >>

2.3 Making best use of CAD

2.3.1 Generally

Effective use of CAD depends on following a number of basic production disciplines, and appropriate use of the functionality afforded by such systems, as described in the remainder of this section. It also depends on good strategic management, the main aspects of which are covered in Section 2.4. Most of the concepts referred to are set out in BS 1192 Part 5: 1998: Construction drawing practice (and the sister document ISO 13567: Parts 1 and 2) and are appropriate to most of the CAD systems used by construction industry professionals. A glossary is included at Appendix G1.

Essentially, CAD systems enable the extensive re-use of data. Libraries of standard items can be created, the use of which speeds up drawings production. Drawn information can be structured using 'layers' to enable its re-use, to facilitate spatial coordination, and to enable it to be linked to subsequent activities.

To date, the construction industry has, in the main, used computer hardware and software to improve the presentation of drawn information, but the potential to improve the underlying quality of the information has been under exploited. CAD systems enable the user to create and store highly structured graphic and non-graphic information, but much of the value of this is lost when drawn information is printed for issue to other members of the team on paper rather than exchanged electronically.

Until recently, the basic functionality of CAD has changed little. Much third party software has been written for specific tasks, e.g. ground modelling, highway design, and architectural, structural and services detailing. Current development of CAD software is now directed almost exclusively towards 3D 'object technology' (objects are conceived as having identity, form, properties and behaviour, rather than being just lines on paper). These advanced CAD developments are outside the scope of this Code that, pragmatically, focuses on improving the quality of drawn information by using more basic hardware and software more effectively.

2.3.2 Coordinates

In CAD systems the graphic information needed to generate production drawings is assembled in data files, which are based on Cartesian co-ordinates of all relevant points needed to define the project.

In Figure 2.2 the points 1, 2, 3 and 4 can each be precisely located in space by three co-ordinates, which are given in relation to three planes (normally two vertical and one horizontal) at right angles. The point of intersection of the three reference planes is called the origin of the co-ordinate system O. It is convenient to select the location of the origin outside the space required by the project so that all co-ordinates have positive values. The co-ordinates are sometimes referred to as 'real world' co-ordinates and the space defined by their positive values is known as 'model' space.

Figure 2.2 Cartesian co-ordinate basis of CAD systems

Given the co-ordinates of points 1, 2, 3 and 4 it is possible to calculate lengths 1-2, 2-3, 3-4 and 4-1. The area of the quadrilateral 1,2,3,4 can also be calculated. Volumes can be calculated by similar means. In a real project there are thousands of lengths, areas and volumes to be defined in the graphic files needed to generate drawings. Modern CAD systems have the power to generate and manipulate these files with great speed and accuracy.

2.3.3 Spatial coordination

Building grids

Spatial co-ordination is an essential requirement of good quality production information. To achieve a fully co-ordinated set of production drawings across all design disciplines a common building grid should be established by the lead designer and used by all members of the design team. This will ensure that the different design discipline files achieve the same registration when co-ordinating, reviewing or plotting the drawings.

Normally the bottom left hand corner of the building, in plan view, is set to x0, y0 (the 'origin' – see Figure 2.3). This ensures that all dimensional or area calculations are based on positive co-ordinates.

Figure 2.3 Building grid definition

Site surveys

Site surveys are generally based on Northings and Eastings related to the OS grid. In some instances the survey origin may be based on an arbitrary grid chosen by the surveyor (see Figure 2.4). Levels will be given in relation to a local OS bench mark or to a local temporary bench mark (TBM) established for the project.

Figure 2.4 Site survey grid definition

Coordination of building and survey grids

To enable the building to be correctly located within the site it is necessary to relate the origin and orientation of the building grid to the origin and orientation of the survey grid (see Figure 2.5). Final setting out information can then be generated as coordinates from the underlying survey file. Earthwork calculations can also be made.

Figure 2.5 Coordination of survey and building grids

Dimensional consistency

Many of the problems that arise on construction sites can be traced to errors and ambiguities in the dimensions. The errors occur when information is entered incorrectly, or dimensions are added as text that is unrelated to the underlying coordinate system. The concept of 'not to scale' should not be entertained and drawings should be based on model information held 'full size' in 'real world' coordinates. Incorrect dimensional information will prevent effective spatial coordination.

Dimensions should be derived automatically from the underlying CAD co-ordinates by using the 'associative dimensioning' function of CAD systems. Dimensions should not be entered as 'text' as they are purely graphic characters having no relationship with the underlying CAD coordinates. Otherwise interrogation of the positions of different project elements is compromised.

The project team should agree a common dimensional unit, metres or millimetres. Millimetres are the generally accepted unit for production drawings.

2.3.4 Coordinating and reusing the graphic data

In traditional practice, by carefully planning the points at which copy negatives were taken from base drawings, considerable re-use of information could be achieved and errors resulting from repetitive drafting could be minimized. Similar principles apply in the use of CAD; in essence reference files and layers replace copy negatives.

Figure 2.6 illustrates the way in which CAD drawings can be built up. To fully exploit the potential of CAD thorough planning by the design team is needed, anticipating the iterative nature of the design process and the various 'cycles' that are involved.

Section 2.3.6 will explain the way in which drawings can be produced using views of multiple model files. This fine structuring of the data increases the potential for its re-use and provides much better control of revisions. CAD also enables electronic comparison between drawings, which is both swifter (since the comparison is automatic) and more accurate (since it avoids errors in interpretation arising from manual comparison).

A key objective is to ensure that there are no disagreements of content or clashes of position in the set of drawings. There are two routes to meet this objective using CAD; the first is by 'Drawings Overlay' the second by 'Model Exchange'.

Figure 2.6 Discipline layers combined for drawing production

The Drawings Overlay method involves using the CAD system to produce drawing definitions and is analogous to the manual process of overlay co-ordination checking. An example of this method would be:

• The architect's general arrangement drawing definition is transferred electronically to the structural engineer.
• The engineer inserts the architect's drawing definition into a new drawing file.
• The engineer traces the required information and then detaches the architect's file.
• The engineer adds to the copied information the structural elements and in this way produces a new drawing definition.

This process has re-used some of the architectural information but has introduced ambiguity into the project data set: the architect's column layer still remains in the architect's general arrangement drawing definition but the column layer is different in the structural engineer's drawing definition. It is therefore necessary for the architect to change his drawing definition. This drawing production process thus has an inbuilt drafting, checking, revision and re-issue cycle with consequent resource and time implications.

Main disadvantages:

• Each discipline has to update its drawing definitions at each revision.
• Drawing information tends to become 'out of scale' because of the temptation to change dimensions only rather than using the associative dimensioning function.
• There is little saving on draughting time compared with manual draughting.

The Model Exchange method aims to eliminate the checking, revision and re-issue cycle. It relies on the establishment of a single, closely controlled, multi-disciplinary shared graphic database. Rather than transferring drawing definition files, it is the CAD model files themselves that are transferred.

Model graphic files are transferred and shared between the different design disciplines and specialist constructors, such that data is never duplicated - see Figure 2.7. The model files are layered in accordance with the agreed Standard Methods and Protocols (see Section 2.4.2) and contain all information related to the project or the allocated zones. The recipient of a model file may extract layers of information as the basis of his own model files. New layers can be introduced into the received model files.

Figure 2.7 Model Exchange method

In the Model Exchange process the 'ownership' of individual layers is transferred from one discipline to another as required, e.g. the architect initially positions the elements of the building, including structural components such as columns. Once the structural engineer has designed the columns the ownership moves from the architect to the structural engineer. To ensure that only one set of data for each component exists within the project data set, it will be necessary for the architect to delete the 'architectural' column layer e.g. A282_G, giving precedence to the engineer's layer S282_G. Data is thus shared rather than duplicated, and ambiguity is prevented.

In the Model Exchange method data is circulated, enhanced and replaced until an agreed state of completion is reached. Drawing definitions are then extracted from the data set as required. Planning of the data sets and the sequence of their production should be agreed before the detailed design is commenced. Each file should be issued with a model file number and revision identifiers in a similar way to a drawing. Model graphic files should be referenced into drawing definitions.

The Model Exchange method enables multi-disciplinary design to proceed in a managed environment where the build-up of information follows the design sequence. There should be no need for co-ordination 'checks' because coordination is a product of the detailed design process. Other advantages are:

• Ownership of data remains with the originator even though it is used by other disciplines.
• Data is shared to reduce draughting time and cost.
• Any number of drawing definitions can be generated from model files.
• Spatial co-ordination is assured, to give 'fit first time' information.
• Information is finely structured to allow subsequent use for construction planning, estimating, cost planning, facilities management, etc.

Selection of the Drawings Overlay method or Model Exchange method should be made according to project need and designers' experience. In general, the Model Exchange method will require greater IT skills, and stricter discipline by all members of the design team. Its benefits and advantages will tend to be greater on more complex projects, where coordination will be a greater challenge.

2.3.5 Zoning

When planning complex projects and determining the number of model files required, it is commonplace and good practice for the project to be divided into zones (volumes defined by coordinates within an overall project model) that will be held as separate model files. Zoning a project in this way enables multiple users to work on the project efficiently. Zones should be allocated using cut lines to indicate their limits. Zone boundaries could be structural joints or grid lines; for road projects they could be chainage distances; or they could be defined by use e.g. a vertical distribution shaft.

The same information should not appear on two or more CAD model files - if one is updated, but the other is not, the wrong information may be used. However, it may be necessary to show portions of adjacent zones on drawings, in which case:

• The surrounding zones should be referenced into the CAD model file using the 'reference' command.
• The surrounding zones should be displayed in a subdued manner to increase the awareness of the reader.
• A note should be added to the drawing stating that the information within the adjacent zones is for illustrative purposes only, and is not necessarily correct.
• The usual note 'For continuation refer to...' still applies.

Figure 2.8 Project zoning

2.3.6 File structuring

CAD systems have extensive capabilities to manage information but these are largely negated if the information is not structured into model files and sub-files in a meaningful way. If the file structure is deficient, information can be lost, its potential for re-use may be reduced, and changes become harder to track.

Layers

The basic unit of structure in a CAD system is the 'layer'. A user needs to be confident of finding, for example, all the windows on the windows layer, all the dimensions on the dimensions layer, etc. BS 1192 Part 5 (1998) describes a common approach to the structure of CAD data. It defines layer fields as the convention of naming each layer with the information in it - see Figure 2.9.

Figure 2.9 Example of layer coding

The three mandatory field descriptors in the BS are significant:

• Field 1 Single alphabetical character describing the originator. In the design development stages the 'Agent' or 'ownership' of model files may need to change hands - see Section 2.3.4 above.
• Field 2 The element field.
• Field 3 Single alphabetical character describing the type of presentation e.g. dimensions, graphics, hatching, text, etc.

The element field 'name' can come from Uniclass or CI/SfB tables (see Appendix D2); whichever of these is selected should be used consistently by the whole team. The same element table should be used for layer naming and 'parts of the building' grouping and numbering of drawings (see Sections 2.2.4 and 2.2.6).

The layers required should be chosen carefully; there is no need to use every layer simply because it is listed in the elemental table. An example of layer naming applied to a typical project is given in Appendix D3 and illustrated in Figure 2.6.

Sub-models

The model files for a project should be supplemented by the use of sub-models (blocks/cells/instances), created for the project or drawn from an office library of sub-models. The whole point of such sub-models is that they can be used many times, thereby saving much time. The sub-models are created by using CAD primitives (lines, rectangles, arcs, circles, etc.) to define shapes representing door sets, windows, eaves details, manholes, etc. Several manufacturers provide sub-models representing the use of their products, but the relevance of these to the needs of the project should be assessed before they are used. Sub-models can also replicate standard graphic symbols such as north points and section markers.

Sub-models are brought into a drawing and positioned by means of a local 'insertion point' to relate the sub-model to the project coordinate system - see Figure 2.10.

Figure 2.10 Sub model placement of window by insertion point

References

The same principle is used to transfer by 'reference' all or part of another file into the current file, using the agreed origin as the insertion point (see Section 2.3.3 above). This procedure significantly speeds up the preparation and updating of drawings. For example by referencing core plans (showing the arrangement of grids, columns, ducts, etc.) into the general arrangement floor plans the need to maintain separate drawings is avoided. Any subsequent changes to the core plans will be replicated into the general arrangement drawings, because any change to a file will automatically be represented within the 'reference' of that file.

Figure 2.11 shows how data can be held in separate model files, incorporated by reference into a combined model file, and form part of a drawing definition.

Figure 2.11 Drawing definition incorporating views of model files

2.3.7 File names and numbers

Document/file management software packages give users freedom in the length and content of names they give to model files. However, files should be allocated simple, meaningful names, which can be maintained consistently across projects of varying size and complexity. Names given to model files should identify their author, subject content, location and other relevant attributes.

Model file names should, wherever possible, be both human and machine readable, with a fixed number of characters to allow selection by wild carding.

Model file names should be divided into fields, with each field holding one concept. Where relevant, model file name fields should be based on the mandatory fields recommended in BS 1192 Part 5 (see Section 2.3.6 above). The design team should agree from the outset the fields that are to be mandatory and those that are to be optional.

All coding conventions should be left justified. The use of spaces as an alphanumeric character should be avoided. Alphanumeric characters A-Z and numbers 1-9 are allowed, plus two further characters:

• A hyphen '-', which should be used to indicate that a character position in a field relates to all possible values of that position. Hyphens used to fill out trailing character positions in a field indicate no further sub-division of information;
• An underscore '_', which should be used as a character placeholder where a decision is taken not to use a field, or to indicate that certain trailing character positions will never be used under the layer naming conventions adopted.

The recommended order of usage of model files is given in Figure 2.12.

Figure 2.12 Order of usage of model files (nesting)

The number of files that a single file is permitted to refer to and the depth of nested file references supported should be limited to three levels. The number of references to other files by a single file should be the minimum consistent with the objectives of the composite model.

The project team should agree a folder structure that facilitates the exchange and use of reference models - see Figure 2.13. The references between model files should not be dependent on the local directory structure of the computer system or the information provider. When a file containing references is exchanged, the files to which it refers should be exchanged with it.

Figure 2.13 Example folder structure

<< Previous | Next >>