Publisher’s version / Version de l'éditeur:
Vous avez des questions? Nous pouvons vous aider. Pour communiquer directement avec un auteur, consultez la
première page de la revue dans laquelle son article a été publié afin de trouver ses coordonnées. Si vous n’arrivez
Questions? Contact the NRC Publications Archive team at
[email protected]. If you wish to email the authors directly, please see the first page of the publication for their contact information.
https://publications-cnrc.canada.ca/fra/droits
L’accès à ce site Web et l’utilisation de son contenu sont assujettis aux conditions présentées dans le site LISEZ CES CONDITIONS ATTENTIVEMENT AVANT D’UTILISER CE SITE WEB.
CIB 2004 Triennial Congress [Proceedings], pp. 1-11, 2004-05-01
READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS WEBSITE.
https://nrc-publications.canada.ca/eng/copyright
NRC Publications Archive Record / Notice des Archives des publications du CNRC : https://nrc-publications.canada.ca/eng/view/object/?id=052d80ac-0116-4696-8d32-4f344ec3ba9f https://publications-cnrc.canada.ca/fra/voir/objet/?id=052d80ac-0116-4696-8d32-4f344ec3ba9f
NRC Publications Archive
Archives des publications du CNRC
This publication could be one of several versions: author’s original, accepted manuscript or the publisher’s version. / La version de cette publication peut être l’une des suivantes : la version prépublication de l’auteur, la version acceptée du manuscrit ou la version de l’éditeur.
Access and use of this website and the material on it are subject to the Terms and Conditions set forth at
An Integration approach for developing AEC/FM total project systems
An Integration approach for developing AEC/FM total project
systems
Halfawy, M.M.R.; Froese, T.M.; Vanier, D.; Kyle,
B.
NRCC-47041
A version of this document is published in / Une version de ce document se trouve dans :
CIB 2004 Triennial Congress, Toronto, Ontario, May 2-9, 2004, pp. 1-11
Title: An Integration Approach for Developing AEC/FM Total Project Systems. Authors: Mahmoud M.R. Halfawy1, Thomas M. Froese2, Dana Vanier3, and Brian Kyle4 Abstract
In an effort to bridge the gaps in the facility design, construction, and management processes, as well as to improve the quality of such processes, a three-year research effort has been launched with the goal to develop methods and technologies that could potentially achieve close integration of various design, construction, and facility management processes. This paper reports on some results of the first two years of the ITAC (“Information Technology for AEC/FM in Canada”) research project. ITAC is a collaborative effort that aims to leverage the current use of IT in the AEC/FM industry through the development of a computational infrastructure that addresses the specific characteristics and requirements of AEC/FM projects and enables the integration of AEC/FM projects information.
The paper presents integration approaches to support the development of AEC/FM integrated project systems. The paper also discusses the implementation of software prototypes that demonstrate the application of these approaches. A product-centric multi-tier component-based framework that provides a set of reusable tools and domain-specific services is presented. The framework aims to facilitate the implementation of modular and distributed large scale integrated project systems that would support multi-disciplinary project processes throughout the project lifecycle. The framework functionality, architecture, components, and implementation techniques are discussed. Implementation of a software prototype that demonstrates the utility of the framework will also be presented.
INTRODUCTION
Fragmentation of the Architecture, Engineering, Construction, and Facilities Management (AEC/FM) industry has caused many problems that could be primarily attributed to the “gaps” between the design, construction, and facility management phases of a project. Project information typically flows sequentially from the design phase to the construction phase to the facility management phase, with very costly and time consuming feedback loops in the form of change orders during the construction phase, or excessive maintenance work during the facility management phase. Kyle et al. (2000) demonstrated that it is difficult to exchange data amongst applications in large organizations in the FM phase (this can be equally true in smaller organizations) and this situation exists in many organizations.
Information gaps and lack of efficient information management throughout the facility lifecycle have often resulted in increased cost and time, reduced quality and maintainability, and the inability to efficiently access and communicate information. The schematic in Figure 1 illustrates data storage and retrieval requirements during the eight phases of a facility’s life cycle: planning (1), definition (2), implementation (3), commissioning (4), testing (5), evaluation (6), in service (7), and deconstruction (8). As can be seen, the data retrieval requirements increase over time and data are stored and lost constantly in the facility’s life.
Experience with project gaps and information gaps, along with factors related to competition and economic pressures, have created an increasing demand for adopting approaches that would achieve the integration of different project processes. The AEC/FM industry has been steadily moving towards adopting methods that can potentially integrate different project processes throughout the project lifecycle. This trend has created an increasing demand for software systems that would support this integration. As a result, software tools have been moving to become more open through providing access
1
Post-Doctoral Research Fellow, Department of Civil Engineering, University of British Columbia, Vancouver, BC, Canada, V6T 1Z4, [email protected]
2
Associate Professor, Department of Civil Engineering, University of British Columbia, Vancouver, BC, Canada, V6T 1Z4, [email protected], http://www.civil.ubc.ca/~tfroese/
3 Senior Research Officer, Institute for Research in Construction, National Research Council, Ottawa, Canada.K1A 0R6, [email protected]
4
Senior Research Engineer, Public Works and Government Services Canada, Ottawa, Canada. K1A 0S5,[email protected]
to their internal data models, adopting model-based techniques, or by supporting industry-wide standard data models. Adopting integrated project delivery approaches supported by integrated software systems will undoubtedly lead to reduced design-construction cycle time, due to reduction in changes and rework, and to improved overall lifecycle efficiency, performance, and maintainability of facilities.
Integrated project systems are fairly complicated software systems and, despite many years of research and development, The AEC/FM industry has yet to develop a complete understanding of their architecture, features, and implementation requirements for integration. A fundamental requirement of integrated project systems is to support the management of the project information and to allow the exchange of such information among different project disciplines in an efficient manner. Also, implementation of the integrated system should take into consideration a number of factors pertaining to the project organization and size, available technologies, suitable modes of data sharing, and a wide range of other technical issues. The suitability of an approach for a particular class of projects would depend on the characteristics and data management requirements of the projects. Obviously, no single approach or architecture would be appropriate throughout the industry and any solution should be developed to provide a flexible and customizable environment that could be adapted to accommodate possible project scenarios.
In an effort to bridge the gaps in the facility design, construction, and management processes, a three-year research effort was launched with the goal to develop methods and technologies that could potentially achieve close integration of these processes. This paper reports on some results of the first two years of the ITAC (“Information Technology for AEC/FM in Canada”) research project. ITAC is a collaborative effort that aims to leverage the current use of IT in the AEC/FM industry through the development of a computational infrastructure that addresses the specific characteristics and requirements of AEC/FM projects and to enable the integration of AEC/FM project information.
Within the general context of the ITAC project (Kyle et al. 2002), researchers attempted to integrate data from a wide variety of applications, including design and construction management (Halfawy and Froese 2002), facilities maintenance management (Hassanain et al. 2001), life cycle costs (Vanier and Nesje 1998), and condition assessment data (Vanier 1998). As the FM research activities in the ITAC project related more to service life prediction and maintenance optimization than to IT, expeditious software tools and processes were selected in place of more rigorous testing of different software applications. Data interoperability was the result of very low-level data exchange (e.g. comma delimited files), and probably very similar to the ways that FM organizations intercommunicate.
This paper presents an approach to implement integrated project systems. The approach aims to support efficient sharing and management of project information, and to enable the integration and interoperation of domain-specific software applications through developing and maintaining an integrated project model. A multi-tier component-based framework that provides a set of reusable domain-specific services is presented. The framework aims to facilitate the implementation of modular and distributed project systems, which is particularly suitable for the integration of large-scale multi-disciplinary processes throughout the project lifecycle. The paper discusses the architecture and the main components of the framework and highlights techniques to implement these components.
DESIGN CONSIDERATIONS OF AEC/FM INTEGRATED PROJECT SYSTEMS
An integrated project system must support a wide range of requirements, Primarily, (1) management of project data and documents across all project disciplines and throughout the project lifecycle; (2) the integration of various project processes and the enabling of efficient information flow between these processes; (3) the ability to support the integration and interoperation of an array of function-specific software applications that support various project activities; (4) management and coordination of project activities and workflow; (5) collaboration of project teams; and (6) the ability to customize the system to specific work practices or project organizations. Satisfying each of these requirements represents a major challenge that needs to be addressed.
AEC/FM projects involve the generation and manipulation of dynamic and large data sets with complex interrelated objects. An integrated project system is required to maintain the consistency and integrity of project data, especially when users could access the data concurrently, by implementing procedures to propagate and manage changes to project data. Also, the system should support industry-wide data modeling standards if they exist. The system should support different modes of data access and exchange such as file exchange, centralized database, application-to-application data exchange, and online web access. Also, due to the evolutionary and iterative nature of project processes, the system should enable users to define objects at multiple levels of details and enable the management of changes and versioning of these objects.
AEC/FM data are multi-faceted and could be represented and exchanged in several forms and formats. Traditionally, this information is stored and exchanged using unstructured documents (Kyle et al. 2000). With the recent proliferation of model-based software tools and standard data models, a large part of this information can now be represented in a neutral object-based format (e.g. IFC P21 or XML files). Another form of project data exchange that is becoming more commonplace in the industry is the use of online transactions. Transaction examples include: requesting product or schedule data, submitting a change order, electronic tendering and procurement, materials management, resource scheduling, and site information. An integrated project system is required to support the modeling, integration, and management of these three forms of project data.
Given the fragmented nature of the industry, an integrated system needs to support an open, modular architecture and non-proprietary, possibly standard, data models that allow various applications to plug into the system and to interoperate and exchange data with other applications. Developing and adopting industry-wide standard data models is a critical factor in supporting interoperability and efficient data exchange. Also, given the availability of a large number of commercial applications, these systems are also required to enable replacing, upgrading, or extending the tool set, without impacting their overall operation.
AEC/FM projects typically involve many inter-dependent activities that need to be managed and coordinated. An integrated system should assist in modeling and implementing workflows to enable the efficient flow of information among various project processes. The system should also support collaboration and coordination of project teams by supporting the communication of different forms of information (textual, graphical, video) and different interaction modes (synchronous, asynchronous).
Given the wide range of project systems requirements, a component-based architecture seems particularly suitable. Systems would also need to be flexible to accommodate future modification, extension, and technology improvement. Another consideration is the necessity to separate the functionality between the function-specific tool set and the common services components. While applications provide users with the functionality to perform specific project activities, components provide the functionality to integrate and manage project information and processes. Applications access the components’ functionality through published interfaces, and therefore should make no assumptions about the implementation of these components.
DEVELOPING INTEGRATED PROJECT SYSTEMS USING OBJECT-BASED DATA MODELS
Developing standard object models has been a major area of research during the past decade (Eastman 1999). Several efforts have been underway to develop standard data models to support interoperability and data exchange among software applications, which constitute a fundamental requirement to implement integrated project systems. Object-based data models define schemas that represent the structure and organization of project data in the form of a class hierarchy of objects. The use of an object model will significantly improve the consistency of project information, and serve to
integrate different project aspects and facilitate the exchange of project information between different software applications. Over the years, several data models have reached a high level of maturity in supporting a wide range of project aspects. Most notable of these models is the Industry Foundation Classes (IFC), developed by the Industry Alliance for Interoperability (IAI 2003). Examples of other models include: CIMSteel CIS/2 for steel construction projects, PCSC precast concrete model, AP225, and aecXML. Many commercial software tools already support several of these standard data models. IFC represents the largest scale standard AEC data model. The latest IFC release (version 2x Edition 2) has significantly extended the model to support areas such as structural steel, reinforced concrete, precast concrete, structural analysis, among others. Efforts are ongoing to link and interface IFC with other data models in order to extend the scope and utility of the model. Like many other standardization efforts, IFC is based on ISO STEP data modeling standards. The IFC schema defines the main objects and relationships that cover core project information such as building elements, the geometry and material properties of building products, project costs, schedules, and organizations. Instances of the IFC entities are initialized, linked, and assembled by applications to create an object model of the project.
In the simplest form of interoperability, the project model is communicated from one application to another in a data file (e.g. using ISO 10303 Part 21 format). Upon receipt of the data file, the receiving software re-creates the project model for further processing. As an example of the current capabilities of IFC-based interoperability, the following scenario has been implemented using tools developed by the Building Lifecycle Interoperable Software group (BLIS 2003).
• One tool is used to define the basic rooms and spaces of a building, including the names, areas, and other basic requirements. The resulting preliminary space plan is exported to an IFC data file.
• The IFC file is read into a two-dimensional technical drawing tool. In this tool, previously identified rooms are arranged into an overall floor plan, and various design details such as windows, doors, plumbing and mechanical systems, are added. The resulting design is then exported as an IFC file. • The IFC file is opened by an energy analysis tool. Although the information had previously been
constructed in a 2D drawing package, all of the elements have height and elevation properties, and can form full 3-D models in the CAD system. This tool performs energy simulations, and allows design revisions to the HVAC components, with the results again exported to an IFC file.
• The IFC file is opened in a tool that generates a 3-D virtual reality view of the project, allowing the user to rotate, zoom in and out, and walk-through the building. This tool then runs a series of design checks; rules which look for specific code conformance issues. Items that fail to pass the design checks, such as a room with insufficient fire egress provisions, are highlighted in the 3-D model. • The IFC file is opened in a tool that itemizes all of the physical components in the building, and maps
their properties to an estimating database, to build up a complete cost estimate for the project.
This scenario describes the current state-of-the-art in IFC-based information integration. With the basic product modeling capabilities of IFC now reaching a high level of maturity and stability, efforts are underway to define and develop ways to extend the model semantics, data exchange mechanisms, project areas, and application domains.
A COMPONENT-BASED FRAMEWORK FOR INTEGRATED PROJECT SYSTEMS
Integrated AEC/FM project systems share many common characteristics, which makes the development of a generic reference model of these systems both feasible and desirable. Although software systems used to support different types of facilities will most likely implement different domain functionality, much of the functionality related to data and process management is generic and could be simply reused in these systems. The generic reference model, or framework, would enable and promote the reuse of domain-specific software components, which would, in turn, enhance the consistency and interoperability among different systems. It will also facilitate the development of new systems and make the development process more feasible and affordable.
The framework is intended to support the integration of large-scale projects where processes are carried out by a collaborative multi-disciplinary effort of many organizations. The proposed framework presents a high level description. The framework could be viewed as a reference model of integrated project systems that deal primarily with the organization, overall functionality, and interfaces of the components. Further refinement and extension of that framework would yield a detailed specification and
a blueprint for integrated project systems in a particular AEC/FM domain (e.g. buildings, bridges, etc.). The framework could also be viewed as a software platform, or a kernel, that can be used to support the implementation of integrated project systems. The kernel would provide a number of common services, which are implemented as a set of components, to offer a set of generic domain-specific functionality.
The framework has defined a number of components and organized them in a multi-tier architecture (Halfawy and Froese 2002). The multi-tier component-based architecture has been chosen because of its ability to support the development of extensible and modular large-scale integrated project systems. The component-based architecture has several advantages over other approaches. Specifically, systems will be highly maintainable and can be easily upgraded or extended; replacing or upgrading function-specific tools would have little impact on the framework; the components could be reused to support the development of specialized integrated project systems that address a particular class of facilities or projects; the components and applications could be transparently run in a distributed environment. The framework defines three tiers: the AEC/FM applications tier, the common domain services tier, and the project data repository tier (Figure 2).
Figure 2: Architecture of the Component-Based Framework for Integrated AEC/FM Project Systems The framework does not impose any restrictions on the implementation details of components, and a number of methods and technologies could be employed. Examples of alternative component technologies include CORBA, JavaBeans, COM/DCOM, or .NET. Most existing component technologies provide mechanisms to enable components and applications to transparently run in a distributed environment, by shielding the details of data marshaling and accessing remote components. The framework components span four main areas of functionality: data management, workflow management, document management, and transactions management. The framework also integrates a number of domain-specific software applications. The following sections will discuss different parts of the framework. The Model-Based Project Repository
The project repository contains the specific project objects instances produced and shared by different applications. The repository could be implemented in two main forms, depending on the required
data management functionality: using simple neutral files or a centralized Database Management System (DBMS). Current implementations of integrated project systems rely almost exclusively on the application-to-application exchange of neutral files (e.g. STEP Part21 or XML files). However, file-based data exchange is very limited in its scalability and ability to support the data management functionality required by large AEC/FM projects. Also, sharing project data using files makes it difficult to control or track changes and versions of the data, and, despite the fact that an application or project participant would typically require access to a limited view of the integrated project model, file exchange typically involves the exchange of the entire project model, which is clearly inefficient, especially for large scale projects.
Limitations of file-based project repositories could be addressed by using a centralized database. Using a centralized database would help to eliminate errors resulting from file-based data transfers between applications, eliminate data inconsistency across different applications, enable the exchange of partial project views, provide an integrated view of project data, and support transactional forms of data exchange (Froese et al. 2000). The database would also enable the implementation of a variety of data management services to maintain the integrity and consistency of the project data. It could implement version control functionality to track data evolution and changes, and could support the use of distributed data sources by adopting distributed or federated database architectures. Users and different applications could concurrently access the same project data.
Applications and Adapters
The applications tier integrates a set of possibly distributed, function-specific software tools that perform various project activities (e.g. CAD, HVAC design, structural analysis and design, specifications, construction scheduling, cost estimating, etc.). Applications could be specifically developed to support a standard data model (e.g. IFC). Applications that do not support the data model would require the use of an adapter to perform bi-directional data mapping to and from the framework data model adopted. As more standard-compliant applications become readily available in the industry, the need to develop such adapters will gradually diminish. Depending on the application characteristics, adapters could be developed in several different ways. The framework does not impose restrictions on the implementation details of adapters (e.g. language, technique). An adapter could be implemented as standalone software or as an add-on to the host application. Adaptors use the data management services provided by the framework middle-tier components to access and exchange data stored at the project repository.
Data Management Components
The data management components are used by other components and applications in the framework to enable local or remote access to the project repository. Therefore, the implementation of the data management components will depend on the structure of the project repository. Data management components that only support file-based project repositories will be easier to implement. However, the data management functionality offered will be minimal. To support centralized or distributed project repositories, the data management components will implement more advanced data management functionality using the services offered by the underlying DBMS.
Delivering the data management services through standardized interfaces would render additional benefits to implementers of other components and applications. There are many different types of potential data sources in a typical project. Examples include XML files, relational or object-oriented databases, applications that are able to respond to data requests, or components that access remote data sources. Given the large number of APIs available to access data sources, the standard interface will help to isolate implementers of data consumers from the details of the underlying project repository. One option would be to adopt an existing and stable standard API such as the ISO Standard Data Access Interface (SDAI). Another option would be to employ a general-purpose interface (e.g. the XML DOM). Document Management Component
A large portion of all project information, such as drawings, analysis calculations, bill of materials, and specifications, is represented and exchanged as documents that need to be managed and integrated with the project object model. Document management uses a set of document attributes, or metadata, to classify, organize, search, and retrieve documents. The document management component defines metadata attributes that effectively describe a project document, and establish a bi-directional link
between these attributes and the objects in the project model, and thus enables context-based access to documents directly from the object model.
Transaction Management Component
A significant amount of project information is communicated in the form of transactions. Examples include requesting or querying information from various data sources, exchanging design or construction documents related to a specific project, exchanging data related to a specific business transaction (e.g. purchase orders), or distributing updated information to project teams. Furthermore, accessing online data repositories or data exchange between applications over the Internet would require exchanging data at a fine level of granularity where small chunks of the model data are communicated. The transactions management component enables the framework to interoperate with online data clients or providers, especially across different organizations, via the use of message-based protocols. Despite a lack of a transactions standard in the AEC/FM industry, work is ongoing to define such standards in a way that is consistent with existing standard data models (e.g. IFC) and emerging Web interoperability standards such as XML SOAP and web services (Halfawy et al. 2002).
Workflow Management Component
Interdependencies between project processes necessitate the definition of rules and procedures to manage and coordinate the information flow and the workflow within the project. The workflow management component would define methods to support modeling and implementation of these rules and procedures in the framework. Workflow models would help to provide an encompassing view of different project roles, software tools, information requirement and flow, and project processes, and to identify the interface between these processes. The component could implement functions to enable automatic routing and tracking of project documents. The component could also implement services to support real-time collaboration of geographically distributed project participants.
IMPLEMENTATION OF A PROTOTYPE INTEGRATED PROJECT SYSTEM
Transforming the framework into an actual software implementation involves further refinement of the design and the consideration of a number of factors pertaining to the project organization, available technologies, and suitable modes of data sharing, etc. Obviously, no single implementation would satisfy the requirements of every project and any solution should be developed to provide a flexible and customizable environment that could be adapted to accommodate different scenarios. In general, to implement the framework in a particular AEC/FM domain, two main prerequisites must be met: the availability of a (preferably standard) project data model that can support modeling and integration of various project aspects; and the availability of a set of software applications to support project activities in various disciplines. Developing standard data models in AEC/FM domains should become a priority in the coming years in order to support the implementation of integrated project systems. Successful development and implementation of IFCs should be a catalyst for other domains to develop similar models, probably following the same methodology.
An ideal implementation of an integrated project system would support the exchange and management of different forms of project data (i.e. object models, documents, and transactions). However, project organizations or the technology available to an organization might dictate or limit the possible forms and modes of data exchange. For example, organizations may not be able to share and maintain a centralized DBMS-based project repository, and therefore should share data through files.
The prototype software was developed to support building design and construction projects. The prototype employed the IFC 2x schema. A set of middle-tier components were implemented using Microsoft COM/DCOM technology. The components are programmed using Visual C++ and Visual Basic languages. The following scenario illustrates a typical use of the prototype system. First, a preliminary architectural design is developed and a number of IFC design objects are defined. The CAD software generates an IFC model and exports the design data into a standard IFC STEP part 21 file which is added to the project repository to be maintained and managed by the framework. Cost estimating, scheduling, and specification software would import the design data, generate more IFC-based project information, and link this information back with the project model that was initially used. The project model will integrate the different project aspects and maintain the relationships among IFC entities (e.g. linking cost and schedule data to building elements). Project participants from different disciplines could access
the project model and view data in their respective domains, along with any other related information in other domains. Participants could use this integrated project view to assess interactions and dependencies between various project activities, and resolve conflicts and inconsistencies at early stages of the project. Figure 3 shows an example project modeled using the prototype system.
The prototype enables users to manage and navigate through project information through a tree-like “project explorer” interface. This interface represents project views in a hierarchical tree structure and employs the services provided by the data management component to access various pieces of project information such as the facility product model, resources, schedule, cost estimate, specifications, and documents. Making various project aspects accessible from a single model would significantly improve the flow of information across various project disciplines. Users could also link project information among various project views to indicate relationships between different elements of project data. The project explorer enables users to link related objects by a simple drag-and-drop operation. This feature is used extensively to link products, tasks, cost items, and specifications documents. The explorer also enables associating documents with model objects. Dragging a document node and dropping it onto an IFC object would automatically create an IfcDocumentReference entity that associates the document with the object.
Figure 3: Integrated Project Views inside the IFC Project Explorer
Implementing Project Repository and Framework Components.
The data management component is used by other components and applications to interface with the project data repository that contains persistent IFC objects. The prototype project repository and the data management component were implemented to support file-based data exchange. Applications can import/export project data using the standard IFC data model schema. In addition to supporting the exchange of STEP Part 21 or XML files using BLIS XML schema (BLIS, 2003), the data management component also supports accessing a wide range of generic data sources such as relational database management systems, through the use of the standard ODBC interface, and XML files, through the use of the XML DOM interface.
In the implementation of the workflow management components, a number of common workflow models have been identified, analyzed, formalized, and modeled. (Pouria et al. 2002) presented these models for two scenarios: a document review process and a material delivery processes. The models are represented using UML activity, swimlane, and sequences diagrams. The models demonstrated the interaction sequences of information flow between project roles, software applications, conditional logic, and start/end states. More workflow models are being developed to address change management, request for quote, procurement, and request and update of design and schedule IFC-based information.
The transactions management component implemented the functionality to receive and send messages to access and query the IFC project repository via a SOAP-based web service. Other components and applications could use the services of this component to communicate with other online systems either within or across organizational boundaries. The component is intended to support a set of pre-defined transactions that could be used to exchange information or to retrieve information from online data sources in the form of messages. A number of efforts to define, formalize, and standardize the transactions in AEC/FM projects are underway (e.g. Halfawy et al. 2002).
Implementing Applications and Adapters.
The applications integrated into the prototype were selected to support architectural design (Architectural Desktop, ADT), construction scheduling (Microsoft Project), and cost estimating (Timberline Precision Estimating). Although some of these applications support a model-based approach, the models are proprietary and do not support the standard IFC 2x data model. Therefore, adapters were developed to perform the mapping of the internal representation of the project data in these applications to and from the IFC 2x schema. Two applications were also developed to support specifications writing and 4D project simulation. Unlike the aforementioned three legacy applications, these applications directly supported IFC and therefore, no adapters were needed.
• ADT Adapter. The ADT adapter was developed using the ObjectARX class library (Autodesk 1999), and accesses the data management component services through COM interfaces. The adapter added a menu control where different mapping functions could be accessed. The adapter maps the IFC objects to the corresponding ADT objects. Almost all IFC architectural design entities have corresponding ADT objects. For example, an IfcWall object is mapped to an ADT wall entity where the wall dimensions are extracted from the IfcWall geometric representation attributes. A reverse operation is performed to exporting IFC files.
• Microsoft Project Adapter. An adapter for Microsoft Project was implemented as a COM add-in that adds a menu interface to MS Project where data mapping functions can be accessed. A standalone and web-based versions of the adapter were also developed.
• Timberline Cost Estimating Adapter. A standalone adapter was developed to access Timberline’s cost estimates and databases using Timberline’s ODBC driver and Microsoft ADO classes. Cost items and assemblies (IfcCost entities) could be linked to products (IfcBuildingElement entities) by defining IfcRelCostsObjects entities where the RelatingControl attribute references an instance of IfcCost and the RelatedObjects attribute references the related instance of IfcBuildingElement. Cost items could also be linked to tasks using instances of IfcRelCostsObjects.
• Project and Product Specifications Application. The specifications application supports the development of project and products specifications. Specifications are typically prepared as a separate set of documents with no direct or explicit links with the project object model. The application used ARCAT (ARCAT 2003) MasterFormat-based specifications where different sections are stored as separate files. Using a tree-based interface that resembles the MasterFormat hierarchy, users select and edit relevant sections and then link the resulting sections specifications to the IFC objects as external document references.
• 4D Application. The 4D application enables users to link tasks (IfcTask entities) from the schedule with related objects in the product model (IfcBuildingElement entities). Linking tasks with facility products is achieved by defining instances of the IfcRelAssignsToProcess where the RelatedObjects attribute references the instance(s) of IfcBuildingElement and the RelatingProcess attribute references the related IfcTask entity. The application then uses the time information in the schedule to generate a visual simulation of the progress of the construction process, which would help to identify potential conflicts and evaluate the interaction between various activities.
CONCLUSIONS
Current practices and integration trends in the industry are increasing the demands for the implementation and deployment of integrated project systems will become increasingly crucial for efficient project management and control, and for efficient management of facility lifecycle information. In this paper, we described a framework to facilitate the implementation of large-scale integrated project systems, and presented a prototype implementation of this framework. In essence, the framework supported AEC/FM projects by: (1) providing the infrastructure and common domain services that is required by various project activities; (2) supporting the interoperation of software tools and defining techniques to integrate legacy software tools into the framework; (3) integrating the information models of various disciplines to support information sharing and exchange through adopting a standard integrated project model; and (4) providing tools to coordinate project activities and to enable the collaboration of project teams. The framework would potentially improve the availability, reliability, and consistency of project information, resulting in better decisions and less changes and rework.
In addition to the need to more thoroughly address the many research issues highlighted by the framework, we can identify some industry-oriented research activities. Field studies are needed to assess the impact of implementing integrated project systems and how they could impact the organization structure, team interaction, communication, and productivity of project teams. We also need to conduct studies to evaluate the costs and benefits of fully implementing and deploying such systems.
ACKNOWLEDGMENTS
We gratefully acknowledge support for this work from the Natural Sciences and Engineering Research Council of Canada, Collaborative Research Opportunities Program.
REFERENCES
ARCAT 2003. Home Page at http://www.arcat.com, Last Accessed October 20, 2003. AutoDesk Inc. 1999. ObjectARX Developer’s Guide.
BLIS 2003. Building Lifecycle Interoperable Software, Home Page at http://www.blis-project.org, Accessed October 20, 2003.
Eastman, C.M. 1999. Building Product Models: Computer Environments Supporting Design and Construction. CRC Press, Boca Raton FL.
Froese, T., Yu, K., Liston, K., and Fischer, M., 2000. System Architectures for AEC Interoperability, Proceedings of Construction Information Technology (CIT), Reykjavik, Iceland, 28-30 June, 2000, G.Gudnason (Ed.), Icelandic Building Research Institute, Vol.1, pp.362-373.
Halfawy, M. and Froese, T. 2002. A Component-Based Framework for Integrated AEC/FM Project Systems. Proceedings of the CSCE Conference of the Canadian Society for Civil Engineers, Montreal, Canada, June 5-8.
Halfawy, M., Pouria, A. and Froese, T. 2002. Developing Message-Based Interoperability Protocols for Distributed AEC/FM Systems. CIB W78 Conference, Aarhus, Denmark, June 12-14.
Hassanain, M.A.; Froese, T.M.; Vanier, D.J. "Development of a maintenance management model based on IAI standards," Artificial Intelligence in Engineering, 15, (2), April, pp. 177-193.
IAI 2003. International Alliance for Interoperability, Industry Foundation Classes – IFC 2x. On-line documentation.http://www.iai-international.org (Last Accessed October 20, 2003).
Kyle, B. R.; Vanier, D. J.; Kosovac, B.; Froese, T. M. 2000. Information needs towards service life asset management, 17th International CODATA Conference on Data and Information for the Coming Knowledge Millennium, (Baveno, Italy), pp. 1-18, http://irc.nrc-cnrc.gc.ca/fulltext/nrcc44508/
Kyle, B.R.; Vanier, D.J.; and Lounis, Z. 2002. The BELCAM Project: a summary of three years of research in service life prediction and information technology. 9th International Conference on the Durability of Building Materials and Components, Brisbane, Australia, p. 1-10, http://irc.nrc-cnrc.gc.ca/fulltext/nrcc45189/
Pouria, A., Halfawy, M. and Froese, T., 2002. Developing AEC/FM Transaction Standards. 3rd International Conference on Concurrent Engineering in Construction, University of California at Berkeley, California, USA, July 1-3.
Vanier, D.J. 1998. "Product modeling: helping life cycle analysis of roofing systems," The Life Cycle of Construction IT Innovations, Stockholm, Sweden, pp. 423-435, http://irc.nrc-cnrc.gc.ca/fulltext/nrcc43682.pdf
Vanier, D.J. and Nesje, A. 1998. "Roofing system product model: life cycle economic implications," Second European Conference on Product and Process Modeling in the Building Industry, Watford, United Kingdom, pp. 533-541, http://irc.nrc-cnrc.gc.ca/fulltext/nrcc42662.pdf
