Issue dated - 19th May 2003

-


Previous Issues

CURRENT ISSUE
INDIA NEWS
NEWS ANALYSIS
STOCK FILE
INDIA TRENDS
E-BUSINESS
OPINION
FOCUS
COMPANY WATCH
TECHSPACE
TECHNOLOGY
PRODUCTS
EVENTS
COLUMNS
TECH FORUM

THE C# COLUMN

BETWEEN THE BYTES
TECHNOLOGY
SPECIALS <NEW>
HMA BANKBIZ
EC SERVICES
ARCHIVES/SEARCH
IT APPOINTMENTS
WRITE TO US
SUBSCRIBE/RENEW
CUSTOMER SERVICE
ADVERTISE
ABOUT US

 Network Sites
  IT People
  Network Magazine
  Business Traveller
  Exp. Hotelier & Caterer
  Exp. Travel & Tourism
  Exp. Backwaters
  Exp. Pharma Pulse
  Exp. Healthcare Mgmt.
  Express Textile
 Group Sites
  ExpressIndia
  Indian Express
  Financial Express

 
Front Page > Technology > Story Print this Page|  Email this page

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.

<Back to top>


© Copyright 2003: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in
Mumbai by The Business Publications Division of the Indian Express Group of Newspapers.
Please contact our Webmaster for any queries on this site.