Computer-Aided Civil and Infrastructure Engineering 17 (2002) 464472

SHORT CONTRIBUTION

Integrated AEC Information Services Using Object Methods and a Central Project Model
Rafael Sacks
Department of Construction Engineering and Management, Faculty of Civil Engineering, TechnionIsrael Institute of Technology, Haifa 32000, Israel

Abstract: A new paradigm is presented in which designers, contractors, and suppliers process project information, which is stored in a central project model, by using application routines provided on-line as object-oriented methods instead of stand-alone applications. Commercial project management Web site companies can provide the service through application methods tightly coupled with a project model. The development and use of such intelligent object sets is exemplied by the use of intelligent parametric templates (IPT) in three sample applications: for RC slab design, formwork design, and labor monitoring. The research requirements relating to the proposed paradigm are discussed, in light of the experience gained in development of the IPTs. The paradigm offers a technical and economic alternative to the development of industry-wide building project models. 1 INTRODUCTION The process of building construction has been aptly described as consisting of two highly integrated subprocessesan Information process and a material process (Bjork, 1999). A signicant proportion of the problems that occur in physical construction activities can be traced back to failings in the information process. For example, information-related problems have been found to cause signicant construction delays in 75% of projects (surveyed in a number of countries) (Ogunlana et al., 1995). One of the reasons most commonly cited for this state of affairs is the fragmentation of the building design and construction industry (Tolman, 1999; Alshawi, 2000). This problem is especially acute because almost

every project is prototypicalit must be designed from scratch, with the attendant production of a mass of new information (Mokhtar et al., 1997). Information technology (IT) is seen as holding the potential to radically improve the information process, by enabling collaboration and integration in both design and construction. Conceptually, what is desired are information repositories and networks that could simulate in-house colocation of all project participants. Much has been researched and written to show that colocation and concentrated large-scale investments in information technology are not possible in construction, and a plethora of ways have been developed in order to cope with the distribution problem (Bjork, 1999). The key thrust of research in pursuit of this goal has been the development of building project modeling (BPM) concepts. Galle (1995) dened ten desirable properties of computer-building modeling systems, grouped as issues of integration, intelligence, and compliance. While a wide range of technological approaches has been researched, no clear consensus has yet emerged on many basic issues. Among these are the following:

r How to resolve the need to provide versatility (the

ability to add new building technologies, sometimes ad hoc) with the need for industry-wide standardization of building project models (Galle, 1995; Tolman, 1999). The architecture of the databases. Centralized data models, distributed data models, hybrids of these, data transfer models (neutral le formats), and others have been investigated (Gielingh, 1988; Eastman, 1992; Teicholz and Fischer, 1994). Providing for concurrent design collaboration while at the same time ensuring semantic integrity of the data (Eastman and Kutay, 1991; Galle, 1995). Q2

E-mail: cvsacks@tx.technion.ac.il.

C 2002 Computer-Aided Civil and Infrastructure Engineering. Published by Blackwell Publishing, 350 Main Street, Malden, MA 02148, USA, and 108 Cowley Road, Oxford OX4 1JF, UK.

Integrated AEC Information Services Using Object Methods and a Central Project Model

465

r The degree of coupling between software packages r

and the project model database (Fenves et al., 1990). The possibility (and desirability) of incorporation of intelligent or creative systems with learning capabilities, both within application modules (Flemming, 1994; Sacks and Warszawski, 1997) and within the data model itself (for preserving integrity).

Two major efforts at standardization have been pursued: STEP (ISO 10303), starting with the AEC building systems model (Turner, 1988) and continuing with building construction core model (BCCM; Tolman and Wix, 1996); and more recently the industry foundation classes (IFC) development within the industry alliance for interoperability (IAI; Liebich and Wix, 1999). These assume no coupling with software applications and no intelligence, they provide limited integrity constraints, and they are likely to suffer from lack of versatility due to the need to update versions in incremental steps. Doubt has also been expressed as to the chances of success of standardization efforts such as STEP or IAI, or of any common model (Tolman, 1999), due to the innate complexity of a unied model, the multinational nature of the construction industry, and the required level of concentrated nancing. This paper suggests that many of the problems listed could be overcome if a new approach is taken to the provision of information services in construction, in line with the suggestion that the rst practical solution to the integration problem will be realized (through providing a service) rather than the unied development of standards (Tolman, 1999). This implies decentralization and commercializationhere, entrepreneurs provide a service, rather than any industry committee effort. Two trends in IT and construction project management are of relevance to the following discussion: the rst is the advent of commercial project management Web sites, and the second is the application service provider (ASP) model for providing software (ASP Island, 2000). The use of commercial project management Web sites (PMWS) has become common practice in AEC projects. Such sites provide a common data repository for the CAD drawings, text documents, and other data of the project (Hartung et al., 2000). The site is paid for by the project owner and managed directly by the project manager. While such sites create a virtual company for a construction project, and thus improve communication, they do not support any project data modeling capabilities at this time. In the ASP model, software is installed only on the providers server and used on-line by the client through a network (usually the Internet). Remuneration is for a service rather than for purchase of a package. This has the signicant benet of relieving the user from the need to maintain or upgrade software,

or nance its purchase; the user is assured access to the most recent version of the software. In light of these developments and the shortcomings of BPM standards, it is proposed that the concept of a central model be revised, particularly with regard to the ways in which it can be delivered and nanced. The following discussion starts by outlining a likely scenario of implementation of IFCs in the short term. Next, a new paradigm is proposed and described, in which application software methods are delivered together with building project model object instances, rather than as pre-sold packages. Three examples of the use of intelligent parametric templates are presented to demonstrate the concept. Finally, the obstacles and future research requirements are discussed in light of the experience gained through implementing the examples.

2 THE BASIC IFC APPROACH A likely scenario of the use of the IFC classes for integrating information processing in construction, using project management web sites (PMWS) as facilitators, is shown in Figure 1. In this view, software vendors incorporate IFCs in their products, that is, they are used as an application programming interface (API) rather than as a model exchange standard (Tolman, 1999). The users each build and use their own local project model subsets; data objects are downloaded to and uploaded from the central repository as and when needed. The straightforward drawbacks of this scenario are

r Ensuring the integrity of the project data is difcult

(multiple copies of each instance are stored) and data must be mapped or translated between each local building project model and the global BPM Adding new building products to the system, with attendant data objects, requires software upgrades, even if the new object classes inherit from the IFC classes Updates of vendor software require upgrading at each different location The cost of nancing the integration is borne largely by the AEC consultants

r r r

However, this scenario suffers from two more fundamental problems. First, adding any new building technology or product requires that new objects be dened and agreed upon. This is complex and laborious, since it requires that the model schema be evolved and then that each individual software vendor update their own packages and translators wherever necessary. Second, the vendor software packages, as intelligent as each may be, have limited scope (Tolman et al., 2000). Consider a simple question an owner may pose to a designer: What will be the cost and schedule implications of a

466

Sacks

Fig. 1. AEC integration using industry foundation classes and a project Web site.

design change (changing exterior nishing technology, for example)? To make this assessment, the designer would either have to run two additional software applications (estimating and scheduling) or request another consultant or the project manager to perform the check. Such multidisciplinary issues are common, and the limited scope of each application in the above scenario does nothing to aid the project participants resolve them. Two system architectures, which represent improvements to that described here, have been tested: the WISPER project (Alshawi, 2000) and an Internet-based CAD system (Han et al., 1999). In both of these, IFCs provide the basis for a common project model, and the Internet is used as the communication medium between users (through CORBA technology). However, only the integrity problem is ameliorated. The others remain, and in addition, the client software packages still require mapping or translation of the project data to their native data formats.

3 THE PROPOSED PARADIGM It is proposed that information generation in construction can be re-engineered: the new paradigm is presented in Figure 2. The key difference here is that application software is no longer delivered as user-based packages,

but as object-oriented methods, tightly coupled to the data objects, and delivered over the network at run time. The project participants all work through a common interface. The interface is both project and user specic, as is common today (Hartung et al., 2000). In addition to regular project communication functions, each user is given appropriate access to the building project model instances through a specic professional view interface (these are programmed by software houses and provided directly by the PMWS). All of the actions a user need perform (e.g., add and edit assemblies, produce drawings, bills of quantity, and other outputs, etc.) are done by launching object methods. Producing a project schedule, for example, could be initiated by a method of the IfcProject class, which would instantiate an IfcWorkSchedule and its IfcTasks (IAI, 2000). Producing a bill of quantities for a particular building system could be launched by an estimate method of the IfcSystem class, producing an IfcCostSchedule. Two sets of object class denitions and their methods are used, as distinguished by their source: basic classes and methods, and extension classes and methods. The basic methods provide simple functionality for the root classes, such as instance, read, write, etc. In many cases these will be place-holder methods, whose main purpose is to dene the object level interface (method declaration) for the base classes. All of the extension classes must inherit from root classes, and most signicantly,

Integrated AEC Information Services Using Object Methods and a Central Project Model

467

Fig. 2. Proposed paradigm for AEC integration.

they must also be subtypes of the base classesthis ensures that their instances will function with any methods that adhere to their base class method declarations. The extension methods are the majority of the methods required. They can be classied as belonging to one of two kinds: 1. Methods provided by AEC software companies, such as method groups for preliminary design, structural analysis, output of drawings, bills of quantities, etc. The vendors revenues will be accrued by selling the methods per use or by licensing the project management Web sites to sell them. 2. Classes and methods provided by building component suppliers. These will take the form of intelligent parametric templates (IPTs) (Sacks, 1998), which will enable a user to design, analyze, and detail complete work assemblies directly in the model. It is envisaged that product supply companies will provide these free of charge, with the aim of promoting sales (at present, CAD le libraries are supplied free of charge by a wide range of building component suppliers). In Figure 2 both the base classes and the extension classes are shown as residing on the project management server. It should be noted, however, that this is not the only (and not necessarily the optimal) possibility: distributed object technology on the Internet makes the physical location of software resources transparent

to the user (Faraj et al., 1999) These may therefore just as well reside on the vendors servers.

4 TWO-TIER INTELLIGENT BUILDING PROJECT MODEL IMPLEMENTATION The three examples outlined in this section demonstrate how intelligent object sets, rooted (but not necessarily contained a priori) in a building project data model (BPdM), may be provided to construction professionals, as envisaged in Figure 2. (Note that the term building project data modelBPdM is used to distinguish the object-oriented data model denition (of classes, inheritances, and links) from particular instances of building project data, which are termed building project modelsBPM.) All four make use of intelligent parametric templates (IPTs) based on the BPdM, and were implemented in AutoLISP++. IPTs are a technique for populating building project models with semantically rich sets of object instances (Sacks, 1998). They are dened as intelligent mechanisms for instantiation of sets of objects and the relations between them. They comprise a set of parametric objects, which are instantiated dynamically, and can adapt to represent complex real-world assemblies. The term intelligent refers to the collections of object methods and knowledge sets that are processed in order to instantiate the object instances and determine values for their parameters. As distinct from traditional expert systems,

468

Sacks

there is no central knowledge base; instead, packets of knowledge are coupled to the objects representing the building elements and assemblies to which they pertain. Rule sets are inherited in a similar fashion to methods. This top-down approach allows new technical solutions to be added incrementally to the library of IPTs without any change to the system itself or to previously dened solutions. The new classes dened to implement an IPT, which extend the base project model in which they are rooted, must inherit from base model classes, and must remain subtypes of base model classes. The base BPdM was developed for the automated building system (ABS; Sacks and Warszawski, 1997). It denes three levels of detail for each of three main aspects of building information: the building spaces (building, primary space, and secondary space), the assemblies (building assembly, work assembly, element), and the construction process (task, activity, and basic activity). AutoLISP++ is an object-oriented data base management system, based on the principles of the common lisp object system (CLOS) (Keene, 1989), and written in AutoLISP (AutoCAD R ) for the purpose of this series of building project model research. It includes an interpreter, a graphic schema editor (which automates writing of class denition les), a rule processor, and an instance browser. 4.1 Reinforced concrete column and slab design and analysis In the rst example, two complete IPTs were implemented for structural design of reinforced concrete columns and slabs in rectangular shaped buildings (Sacks et al., 2000)for at slabs spanning in two directions and for one directional ribbed (joist) slabs. The requirement was for technical solution templates that could adapt themselves to all of the possible geometric and topological congurations that might be required, such as different slab dimensions, openings in the slab of arbitrary size and location, variations in live load requirements over the oor areas, etc. In each case, new Work Assembly type classes were added to provide the anchor for the new IPT. Certain building element classes were also added: Figure 3 shows the base BPdM with the at slab extensions (shown shadowed to the right) and the ribbed slab extensions (shadowed to the left). Both inherit from and are subtypes of the base Concrete slab class. The new slab work assembly classes each include

r An instantiation method for the work assembly, r An algorithm and rule set for positioning and instanr r
tiating Columns, with respect to Building Axes and Structural Walls (building core elements), Algorithms for laying out the IPT-specic building Elements (e.g., One Way Slab Sections and Beams) with respect to arbitrary openings in the oor, Methods for performing preliminary sizing and structural analysis of the slab system,

Wherever possible, classes available in the base BPdM are used. These IPTs instantiate objects such as Column, Beam, RC Design Section, Structural Support, Rebar Use, Rebar, and basic activities such as Build Forms, Fix Steel, Pour Concrete. New classes, such as the OneWay Slab Section, and Column Strip and Middle Strip, all inherit from and are subtypes of the predened Slab Strip class. Two features should be noted:

r The two-tier nature of the object denitionsbasic

objects and interfaces are part of the common BPdM, while others are added to provide the specic functioning of a particular technical solution, The tight coupling of the objects form (attributes), function (dened by links within the model), and behavior (methods and rule sets) within the model denition. Specically, the behavior is independent of the user interface, or of any one application.

4.2 Formwork design with high shoring towers A prototype design aid for laying out and sizing temporary shoring towers for slab formwork has also been implemented using the IPT concept (Shapira, 1998). The knowledge (rules and objects) for laying out the towers, joists, and stringers and checking their spacings for economy, strength, stability, and safety requirements is implemented as an IPT for each proprietary formwork system. Five classes were dened for the IPT implemented in the experiment: Temporary Support WA, which inherits from the Work Assembly class of the BPdM, Temporary Support Element, which inherits from the Element class, and Tower, Joist, and Stringer Array classes (Figure 4, extensions shadowed). The formwork IPT objects are fully integrated with the overall project model and will exhibit all of the behaviors of their parent classes. It is common practice for suppliers of specialized formwork systems such as these to assist the contractor in detailed formwork design. The prototype system provides a clear example of how an IPT could be funded by an equipment supplier, programmed and maintained by a third party software house, provided as a service by a project management hosting Web site,

r A rule set for proposing preliminary feasible span r A rule set for evaluating the cost of each feasible alternative, lengths,

Integrated AEC Information Services Using Object Methods and a Central Project Model

469

Fig. 3. BPdM classes and ribbed slab extensions. Heavy lines denote inheritance relationships; light lines denote aggregation relationships.

and used by any project team member, as outlined in Figure 2.

4.3 Real-time monitoring of labor inputs The last example concerns real-time monitoring of labor inputs during construction. A model has been developed in which the amount of time a worker spends on any particular scheduled activity can be deduced by tracking the workers proximity to the building elements affected in that activity (Navon and Goldschmidt, 1999). Global positioning system (GPS) or radio frequency (RF) technologies have been proposed for use in tracking. The data model currently under development for this application is based on the BPdM, as is shown in Figure 5 (classes shown shadowed were added specically for this application; the others are part of the base model). Work envelopes represent the three-dimensional space occupied by a worker in order to perform a specic piece of work on a particular building elementeither above or below it (thickness), within a certain distance from it (offset), or in a temporary workspace on the building site. As in the proposed paradigm for providing IT in construction (Figure 2), all of the functionality of the labor control application can be provided entirely through the

Fig. 4. Extension classes added for the shoring tower IPT.

470

Sacks

r The behavior (methods) is embedded with the data r

objects, and not part of any particular software package. All new instances generated by IPT classes remain subtypes of existing base classes, and so the basic functionality of the user interface, editing, and drawing methods, etc. is ensured.

Fig. 5. Extension classes to support real-time labor monitoring.

project model classes. Most importantly, work envelopes can be instanced for any building element, without the requirement that its features be known to the labor monitoring application developer at the time of programming (by denition, any building element must inherit from the root Element class in the BPdM). This implies that any supplier can add new building elements to the overall system at any time. 5 DISCUSSION AND CONCLUSIONS The examples demonstrate the extension of the base BPdM by adding new objects and methods (to serve as IPTs or analysis modules), while retaining the functionality of the viewing interface, including the ability to produce outputs automatically. This is possible because

r The data model is two-tieredrst, the basic model,

and second, the supplier/application level. The second tier is entirely rooted in the rst through objectoriented inheritance.

These features are inherent in the paradigm proposed in Figure 2. They make it possible to incrementally add capabilities and new building technologies to the system, without having to redene and redistribute the basic project model as an incorporated part of diverse software packages. The new paradigm allows a standardized basic project model to be combined with growing domain models, thus providing versatility in terms of the range of building products it can support. It represents a practical approach to the accumulation of capabilities, through piecemeal development of modules suggested by Galle (1995). Furthermore, the centralized database architecture reduces the problems of maintaining integrity, which are difcult where local databases are used. In many cases design ofces represent the weak link in the economic chain of construction projects. Their resistance to integration is often associated with the additional costs of purchasing and upgrading software for use in specic projects. In this paradigm, little or no capital outlay is required on their part: the investment required for development and deployment are transferred from design practices to project management dotcoms and construction component suppliers, who are far better positioned to support capital investments. The operational costs are borne directly by the project owners, paid as fees to the PMWS. A window manufacturer, for example, will provide a set of extension object classes and methods, rooted in the base building project model, to enable an architect to insert/specify a specic window in a building design (i.e., in a growing project instance model). Using the IPT technique, the window will be able to insert itself in any wall object and detail its own parts. Through its methods, programmed using predened base model interfaces, it will also exhibit behavior compatible with the kinds of analyses, drawing production, or other information processing that might be required. A number of issues remain unresolved and require further investigation. The upper (base) tier must include not only classes and their attributes and links, but also basic methods (such as read(), write(), draw(), etc.) and their interfaces (i.e., method input and output denitions). These, and professional view interfaces, must be provided by PMWS companies, who will compete for market share (any attempt to provide these through

Integrated AEC Information Services Using Object Methods and a Central Project Model

471

industry-wide cooperative efforts seems unrealistic). The model presents no solution to the problem of maintaining integrity during concurrent editing of the BPM by more than one project participant. The traditional view of application software will no longer hold; it is not yet clear whether software vendors will impede or accelerate the adoption of the ASP strategy. To date, PMWS companies provide data repositories but no applications. It is likely that market forces will increasingly pressure them to offer enhanced integration services. Providing application functionality using IPTs and ASP technology, as in the proposed paradigm, represents a possible way forward.

REFERENCES
Alshawi, M. (2000), Integrated construction environments: technology and implementation, in INCITE 2000: Implementing IT to Obtain a Competitive Advantage in the 21st Century, HK Poly University Press, Hong Kong, pp. 36 53. ASP Island (2000), http://www.aspisland.com/services/model. asp. Bjork, B. C. (1999), Information technology in construction: domain denition and research issues, International Journal of Computer Integrated Design and Construction, 1(1), 316. Eastman, C. M. (1992), Modeling of buildings: evolution and concepts, Automation in Construction, 1, 99109. Eastman, C. M. & Kutay, A. (1991), Transaction management in design databases, in Concurrency in Engineering Data Management, D. Sriram, R. Logcher, and S. Fukada (eds.) Springer, New York. Faraj, I., Alshawi, M., Aouad, G., Child, T. & Underwood, J. (1999), Distributed object environment: using international standards for data exchange in the construction industry, Computer-Aided Civil and Infrastructure Engineering, 14, 395405. Fenves, S. J., Flemming, U., Hendrickson, C., Maher, M. L. & Schmitt, G. (1990), Integrated software environment for building design and construction, Computer-Aided Design, 22, 2736. Flemming, U. (1994), Case-based design in the SEED system, Automation in Construction, 3, 12334. Galle, P. (1995), Towards integrated, intelligent, and compliant computer modeling of buildings, Automation in Construction, 4, 189211. Gielingh, W. (1988), General AEC Reference Model (GARM), in Conceptual Modeling of Buildings, P. Christianson and H. Karlsson (eds.), CIB Proceedings, Publication 126 W74+W78 Seminar, Lund, Sweden. Han, C. S., Kunz, J. C. & Law, K. H. (1999), Building design

Q3

Q4

services in a distributed architecture, ASCE Journal of Computing in Civil Engineering, 13(1), 1222. Hartung, C. J., deLone, A. C., Kwas, R. M. & Austrian, B. (2000), e-commercial real estate industry overview, Bank of America Securities Equity Research Working Paper, March 2000, San Francisco, CA. IAI (2000), Industry Alliance for Interoperability, IFC 2x, http://cic.vtt./niai/technical/IFC 2x/index.htm. Keene, S. E. (1989), Object-Oriented Programming in Common Lisp: A Programmers Guide to CLOS, Addison-Wesley, Reading, MA. Liebich, T. & Wix, J. (1999), Highlights of the development process of industry foundation classes, in Durability of Building Materials and Components 8 (Vol. 4), M. A. Lacasse, and D. J. Vanier (eds.) NRC Research Press, Ottawa, Canada, pp. 275875. Mokhtar, A., Bedard, C. & Fazio, P. (1997), A methodology for dynamically assembling and modifying an active repository Q5 building database, Proceedings CIB W78, Cairns, Australia, CIB Publication 208. Navon, R. & Goldschmidt, E. (1999), Automated data acquisition for on-site control, Proceedings of the 16th IAARC/IFAC/IEEE International Symposium on Automation and Robotics in Construction (ISARC99), Madrid, Spain, 681 86. Ogunlana, S. O., Promkuntong, K. & Jearkjirm, V. (1995), Construction delays in a fast-growing economy: comparing Thailand with other economies, International Journal of Project Management, 14(1), 3745. Sacks, R. (1998), Issues in the development and implementation of a building project model for an automated building system, International Journal of Construction Information Technology, 5(2), 75101. Sacks, R. & Warszawski, A. (1997), A project model for an automated building system; design and planning phases, Automation in Construction, 7, 2134. Sacks, R., Warszawski, A. & Kirsch, U. (2000), Structural design in an automated building system, Automation in Construction, 10(1), 18197. Shapira, A. (1998), Formwork design for high shoring towers, Concrete International, American Concrete Institute. Q6 Teicholz, P. & Fischer, M. (1994), Strategy for Computer In- Q7 tegrated Construction Technology, ASCE Journal of Construction Engineering and Management, 120(1). Tolman, F. P. (1999), Product modeling standards for the building and construction industry: past, present and future, Automation in Construction, 8, 22735. Tolman, F. P. & Wix, J. (1996), Building construction core model (BCCM) version 1.0, ISO/TC/184/SC4/WG1. Tolman, F. P., Ozsariyildiz, S. & Schevers, H. (2000), Computer aided inception of large scale engineering projects: evaluating value versus cost, in INCITE 2000: Implementing IT to Obtain a Competitive Advantage in the 21st Century, Hong Kong, Poly University Press, Hong Kong, pp. 74455. Turner, J. (1988), AEC building systems model, working paper ISO/TC/184/SC4/WG1.

472

Sacks

Q1 Q2 Q3 Q4 Q5 Q6 Q7

Au: O.K. to change match reference Au: O.K. to change date to match reference? Au: Page # s? Au: Page # s? Au: Page # s? Au: city of publication? Au: Page # s?