|
Evolution of design technology
Soon
all buildings sketches will be represented as databases and not
drawings. The shift is good news for facility managers, but it has
been a long time coming, says Adrian Schep
In the early 1980s architects
first began using Computer Assisted Drawing (CAD). The traditional
layer drafting technique was easily adapted to the layer-based CAD
systems of the day, and within a few years most construction documents
and shop drawings were plotted on computers.
Slowly, technology began
to affect the process. CAD files were exchanged with consultants
instead of physical underlay drawings. Beyond simple graphics these
files communicated information about a building through their layer
structure; a rectangle on one layer represented a concrete column,
but on another layer a tile pattern on the floor.
Digital file formats, originally
designed to store only graphics and drive plotters, now directly
conveyed information about the building, which did not appear in
the plotted version of the file.
The use of CAD files was
evolving toward communicating information about a building in ways
that a plotted drawing could not.
This evolution continued
with the introduction of object-oriented CAD in the early 1990s.
Data ‘objects’ in these systems—doors, walls, windows, and roofs—stored
non-graphical data about a building in a logical structure, together
with the building graphics. These systems often supported geometrical
modelling of the building in three dimensions, thereby automating
the laborious drafting task of laying out building section drawings
and generating schedules.
Forward-thinking design
firms adopted these tools, realising that the data in the object-oriented
CAD files, if carefully structured and managed, could be used to
automate certain documentation tasks like schedules and room numbering.
A parallel development in
the 1990s was the increasing use of the Internet for sharing data
digitally. Suddenly, all information needed to be represented digitally
for it to be effectively communicated.
CAD files that had been
exchanged on floppy disks within the design team appeared instead
on File Transfer Page (FTP) sites, on Web pages, and attached to
e-mail. The same forward-thinking design firms who were adopting
object-oriented CAD into their practices began sharing and delivering
their documents to clients digitally and began investigating Web-based
project management and collaboration services.
But object-oriented CAD
systems remain rooted to building graphics, built on graphics-based
CAD foundations, and as a result are not fully optimised for creating
and managing information about a building. Other industries, such
as manufacturing, were already realising great benefits from non-graphical,
parametric information technology tools.
Another generation of purpose-built
software solutions was required. Software that is information-centric
and provides building information modelling in place of building
graphic modelling.
By storing and managing
building information as databases it can capture, manage, and present
data in ways that are appropriate for the building team member using
that data.
Architects, for example,
work on the information using the conventional graphic language
of building design (such as plan, section, and elevation); entering
and reviewing information in a format that looks just like the architectural
drawings they have worked with for years. The defining factor is
that they are actually working on the building information through
a drawing rather than working directly on a drawing in the computer.
Similarly, structural engineers
work with the data presented graphically in familiar framing and
bracing diagrams, quite different from the architects’ interface
to the data. Builders work with some of the same presentations,
as well as, isometric views of the building geometry to study phasing
and co-ordination issues, and spreadsheets of quantity data provided
from the building information model.
Because the information
is stored as a database, changes in the data that so frequently
occur during design can be logically propagated and managed by the
software throughout the project lifecycle.
The effort that would otherwise
be spent in manual document checking and co-ordination can be invested
instead in the real work of constructing and operating the building.
The building information
model contains not only a list of building components and locations,
but also the relationships that are intended between those objects.
For example, that a door should be three feet from a window or the
eaves of the roof should overhang the exterior wall by 550 mm.
The information and relationships
embedded within building components themselves, as well as those
embedded in the overall model, makes reuse of the data in other
applications even more powerful and the design process significantly
more efficient.
The first occupancy of a
building—at the end of the conventional design and construction
cycle—is just the beginning of the life and use of the structure.
The evolving occupancy of the building, together with the maintenance
requirements of the building materials, assemblies and systems,
result in changes throughout the life of the building.
The building information
model is then used for the design and documentation of the continuing
maintenance, renovation and renewal of the building itself. Information
about all the successive renovations to a building can be maintained
in the building information model, forming a record of all changes
that have been made to the building in its history.
An example of this is the
use of schedule data in a building information model for inventory
management in a retail operation. As the display unit layout is
planned for a store in a building information model, the possible
configurations and capacity for each unit are captured and reported
back in a schedule for inventory calculations. The inventory schedule
information can then be linked to a procurement system to co-ordinate
the management of stock with the capacity of the store. Thus, the
building information model data extends to the support of the store
operations.
The building information
model is also used to access and manage physical information about
the building, such as finishes, tenant or department assignments,
furniture and equipment inventories, and also financial data regarding
areas for lease and rental income, or departmental cost allocations.
Both revenue and cost management in the operation of the building
are therefore improved.
This capture and preservation
of building information throughout its life may not guarantee better
buildings, but it will mean better building processes. For facility
managers this means that every aspect of the building is manifested
in a way that saves time and effort, thus freeing up more time to
focus on priority management tasks.
The author is product marketing
manager, Building Industry Division for South Asia-Pacific at Autodesk.
He can be contacted on adrian.schep@autodesk.com.
|