in: Fichtner D. and MacKay R. (eds.) Facilitating Deployment of Information and Communication Technologies for Competitive Manufacturing, Proc. Of the European Conf. On Integration in Manufacturing, IiM’97, pp.31-40, ISBN 386005-192-X, publ. Selbstverlag der TU Dresden, Dresden, 24-26 Sept. 1997.
A CONCURRENT ENGINEERING IT ENVIRONMENT FOR THE BUILDING CONSTRUCTION INDUSTRY R.J.Scherer1, R. Wasserfuhr2, P. Katranuschkov3, D. Hamann4, R. Amor5, M. Hannus6 & Z. Turk7 Abstract: Since the late 1980s it has been suggested that product modelling is the key to computer
integrated engineering, which is also a prerequisite for computer assisted concurrent engineering. Later experience has shown that product modelling alone is not sufficient, and that other aspects, such as processes, documents etc. have to be modelled as well. In this paper we describe an environment modelling approach which can integrate all kinds of construction information, such as the information about products, processes and documents. As a basis for a fully distributed interoperable IT system for concurrent engineering in building construction we propose a conceptual framework which decomposes an abstract concurrent engineering model into a set of hierarchically structured interrelated modelling spaces. The paper presents the main requirements and the key concepts of the developed approach. Reported is the work in progress performed as part of the EU Esprit project 20587 ToCEE.
1
Introduction
Concurrent Engineering is the way the building industry works today. However, in practice the degree of success achieved through the application of concurrent engineering varies considerably from case to case. Organisational factors, especially with respect to information management methods and techniques, coupled with different levels of training and experience of personnel, place considerable limitations on the level of concurrency and collaborative work being achieved. Furthermore, since every building is a one-of-a-kind product and almost every project is performed by a new virtual enterprise, within a distributed and heterogeneous information infrastructure, the difference in the potential for concurrent engineering work in the various participating enterprises is another factor that lowers the achievable level of concurrency. Information technology has an enormous potential to improve both the organisational and the technological infrastructure of construction projects and thus to facilitate the effective application of concurrent engineering methodology. In the application of IT for concurrent engineering in the building industry valuable steps have already been achieved: in product model based integration - by
1) 2) 3) 4) 5) 6) 7)
Chair of Applied Computer Science in Civil Eng., TU Dresden, Germany,
[email protected] see 1,
[email protected] see 1,
[email protected] see 1,
[email protected] IT Research and Application, Building Research Establishment, UK,
[email protected] VTT, Technical Research Centre of Finland,
[email protected] Faculty of Civil and Geodetic Engineering, University of Ljubljana, Slovenia,
[email protected]
STEP [ISO-94], Parts 41 - 45, 106, APs 225, 230, 231 (to mention just the most applicable parts for building construction) and by several EU projects like ATLAS [BOE-94], COMBI [SCH-95] and COMBINE [AUG-95]; in process modelling - by the CALS [HEN-91] and the IRMA [LUI-93] initiatives; in workflow developments and electronic document management - by the WfMC [WFM-94] as well as in several commercial and academic electronic document management systems [AMO-96]. In spite of all these achievements, concurrent engineering issues, such as the management of the process, product, documentation and communication flows, are still being handled in a fragmented manner, as individual, mutually independent, or at best only partially interrelated systems. Interoperable environments have yet to be developed which can fully integrate into practice and increase the uptake of concurrent engineering. To help tackle these issues the EU ESPRIT project ToCEE was started in 1996 [TOC-95; AMO-97]. The primary goal of the ToCEE project is to establish and validate in a software prototype a general methodology and an overall architecture of a concurrent engineering IT environment for the technical work to be done in the areas of the design of buildings, construction process planning, facility management, project management. As a basis of such environment we propose a conceptual framework which decomposes an abstract concurrent engineering model into a set of hierarchically structured interrelated and interoperable modelling spaces. The following sections present the main requirements, the key concepts and the envisioned demonstration of the ToCEE approach.
2
Principal Requirements for Concurrent Engineering
The activities and information flows to be supported in the targeted Concurrent Engineering Environment (CEE) should cover almost the whole life cycle of a building as shown on a high-level on fig. 1. Project goals Process External model constraints
Regulation requirements User requirements Management documentation
Manage Management construction info. process 1
CE requirements
Design building 2
Building design documentation
Building design info Construction documentation
Plan and do construction 3
Construction info Facility management documentation
Plan facility management 4
Facility management info Maintain information base 5
Process management tools
Conflict management tools
Building design applications
Construction planning applications
Facility management applications
Browsers
Project information base Action info
Information base management tools
Fig. 1 - CEE Activity Reference Model
In this broad scope various types of information have to be considered and dealt with in their interrelationship: (1) the information about the constructed facilities, including construction products, processes, documents, regulations, contractual requirements etc., (2) the information about the CEE system itself, including the information representation (files, databases), the information processes and the components of the environment as such - servers, clients, users, applications etc., and (3) the information about the information, including concepts like ownership, access control, versioning etc. Therefore the integration of the interrelated information aspects of a building project into
Product Model
a consistent conceptual framework is of primary importance. These aspects are: the product, the document, the information flow and the process
Process
models as shown schematically on fig. 2. In this context a basic requirement for the CEE system is the development of an interopera-
Information Flow
Document Model
bility methodology, including formal methods and constructs capable to deal with: (1) a hierarchically structured product model world based
Fig. 2 - Interrelated aspects of a building project
on STEP technology (aspect models described in Application Protocols, Core Model and Integrated Resources), (2) the existing non-homogeneous real-world product specification, i.e. STEP [ISO-10303] together with the IFCs (Industry Foundation Classes) of the IAI initiative [IAI-97], and (3) any arbitrary data structures describing product relevant data, e.g. in the various numerical software tools available in the building construction domain. Basic principles need to be developed to enable the integration of such arbitrary product data structures. In this direction valuable steps have already been achieved in the ESPRIT project COMBI [SCH-95]. The results obtained there provide the possibility to use a highly flexible interoperability methodology, instead of static, pre-described and pre-harmonised product models. This interoperability objective actually has an impact on the whole modelling framework content and its data abstraction hierarchy, which - as a principal requirement - must be divided in various levels of abstraction that may in turn be defined as separate, orthogonal models. The product model dimension of the project information targets a logically consistent and technically complete representation of the product where the product data are easily available in parts or views, appropriate to the individual users’ perspectives. This is already developed to a high extent. What is missing is the legal validity. The current legal understanding in inter-enterprise information sharing is based on the following: • The receiver has to become the information in a reliable form and way (including the legal security, authorisation and validation of the data), and he has to be informed that he has to put this information at a specific place by applying a specific procedure. • It is up to the sender to ensure that the receiver interprets the information exactly in the way the sender intends. This is fulfilled in current legal practice when the same, commonly accepted
visual representation is used, e.g. text in an agreed language and graphical representations (technical drawings, scheme diagrams etc.) according to valid standards or best practice. In an automation system this can only be achieved if the representation tools and the representation procedures (for the application of these tools) are connected in an - again legal - sense to the electronic data. As a further principal requirement, the product model infrastructure must be complemented by a document modelling system which fulfils the legal requirements. Documents are in some sense views on the product model data, but are also more than that, because approved documents are legally valid whereas product data are not, at least in the present understanding of inter-enterprise communication. Therefore product data has to be represented inside documents in order to obtain legal status. A product and a document model have to coexist and, because of the requirements for their interrelationships, are in fact highly influenced by each other. They need clearly defined interfaces, which should be built on the basis of formal interoperability methods and recognised language specifications. For achieving concurrency in the design, construction and maintenance of buildings the CEE system has to support the existence of several versions of the information at one and the same time due to the parallel work on one and the same product by different actors. Maintaining the consistency of the data is not the sole requirement here because - taken alone - it places too strong constraints on collaborative working, resulting in: (1) too early decision making and detailing instead of a preferable least commitment strategy, and (2) too intensive, and thus counter-productive information flows and conferencing. Therefore an additional, but opposite requirement is: parallel independent working with a minimum on coordination and notification efforts. As a result conflicts can arise, which need appropriate methods to be dealt with. A compromise between these two important requirements for concurrent engineering leads to a project progress structured by coordination points as shown on the below fig. 3.
Fig. 3 - Structured concurrent processes in the building product development
Between these coordination points, parallel independent work has to be allowed, where the individual actors together with the project management decide upon the needs and frequency of notification among the participants. Thus, Information logistics becomes of utmost importance. Additionally, due to the growing inconsistency of the data in the progress of parallel work, conflict management becomes also an important management task. This task can be supported by applying artificial intelligence methods for conflict recognition and conflict propagation, i.e. propagation of the constraints due to conflicts and/or proposed alternative solutions. Finally, a system for control of the information flows for process supervision and guidance (in design, construction, facility management) must also be integrated as an inherent part of the concurrent engineering environment. Without this, concurrency will remain on a low level. However, since project information exists mainly in the form of product model data and as documents, the workflow methods and tools have to interact extensively with the product model and the document model management systems. This form of information logistics demands the consideration of requirements on the availability and presentation of the information in both models. Such interaction, which can also be seen as an interoperability issue in a broad sense, is one further focus of ToCEE.
3
Proposed Concept for a Concurrent Engineering Environment
The overall objective - to combine the independently used nowadays systems for product, document and process management into a consistent IT environment with special emphasis on increasing the operability of concurrent engineering, the specific requirements of the building industry and the highly distributed nature of building construction work, dominated by many scattered small and
medium-size enterprises, have been the main motivation for setting up the basic principles of the conceptual architecture for CEE as follows: • centralised project management supported by comprehensive information logistics and process management services; • modular and distributed operational framework based on the client-server paradigm and utilising the possibilities offered by the Internet; • logically consistent overall modelling framework based on a common object-oriented representation paradigm; • use of local models for the needs of all discipline-specific work, coupled with centralised product data management services accessible through clearly defined functional interfaces; • flexible information exchange and sharing enabled by knowledge-based methods for achieving the interoperability of the CEE system, including the aspects: operational interoperability (client-server, server-server), semantic interoperability (intra- and inter-model-operability) and functional interoperability (runtime model matching, consistency checking and conflict management). Client-Server Architecture The principal idea of the operational framework of ToCEE is to apply a multiple server concept, in which distributed services can be accessed through a common communication layer, which organises the communication between client and server hosts in terms of communication events. Any project communication can be decomposed into atomic communication events which are either requests to a server implementing services, or responses of a server. The communication layer, implemented as a common request broker, ensures the transfer of „information containers“ across a network. All information transferred between the system components is either input or output to/from a service in the form of such information containers. The services themselves are organised in an object-oriented way and include a semantic decomposition of all concepts of the environment into orthogonal models, and thus into addressable objects and object operations. In addition, the communication services provide a centralised logging, access control and serialisation of concurrent requests. This type of system design enables the clients to operate in an integrated space of services, independent of the physical location of each server-side service (see fig. 4). The meta information of the services is structured as a „lean“ conceptual model, ensuring that each addressable object in the environment is subsumed by a concept of the underlying hierarchically organised modelling framework. Each server specialises in the implementation a well defined set of these concepts. A new server can be integrated into the environment by defining new concepts, their attributes and behaviour. By treating concepts themselves as objects, the formal relationships between concepts can be made available (and partially extensible) at system runtime.
FEA
System Call or Java Interface
Information Logistics Toolkit
CAD
...
ILTP request
WWW Browser
HTTP response
WWW Server
WWW Browser
...
Document Mgmt. Server
ILTP response
URL request
Persistence Mechanisms
TCP/IP Ingoing Email
E-Mail Client
EMail Server
E-Mail Client
Outgoing Email
Information Logistics Services Product Mgmt. Server
Fig. 4 - Operational framework of the concurrent engineering environment
Internet Gateway Internet technologies are especially relevant for inter-organisational cooperation and the virtual design office of the future. Internet technologies and standards, particularly related to email and the WWW (SMTP, HTTP, HTML, CGI, Java) have also brought new dynamics into the development of intra-organisational networks, bridging the problem of heterogeneous platforms and operating systems. In the CEE system, the Internet gateway should make the services of the environment easily available for different system platforms and across the boundaries of organisations. Therefore, it is especially designed to manage project member data, their work-lists, bi-directional document transfer, and product model browsing. Only if specialised user interfaces are needed, the user has to change from his WWW browser to specific helper applications or browser plug-ins. Similarly, the email gateway will be directly integrated with the environment and can be used e.g. for transferring automatically the file attachments of emails to the document management server. Modelling Framework The conceptual modelling framework of ToCEE enhances the ideas of the STEP methodology and the findings of the EU projects ATLAS, COMBI and COMBINE to provide a common intra- and interoperable information infrastructure for all relevant data in the concurrent engineering environment. It consists of five hierarchically organised modelling layers supporting not only the semantic interoperability between different, domain-specific product data representations, but also to documents, processes and other project related information (see fig. 5).
META Model Layer Inter-model operability
KERNEL Model Layer NEUTRAL Model Layer
Neutral Product Model
Intra-model operability (product data)
ASPECT Model Layer
Aspect Product Models Appl.1
...
Vertical pre-harmonisation
Appl.N
Application Model Layer
Fig. 5 - Modelling framework (principal decomposition of the concurrent engineering environment model)
The Meta Model Layer on the top of the framework defines explicitly the basic rules of the whole modelling paradigm, including a generic specification of concepts and operations for all services to be implemented in the environment. The Kernel Model Layer defines the high-level concepts needed to link the data of the different subsystems. It is comprised of 3 schemata: (1) TC_Kernel, containing the most general definitions of the construction-related information objects which are further specialised in the lower level models, (2) TC_Communication_Model, specifying the information about the system itself and the information processes in it, and (3) TC_Model_Population, defining explicit concepts for ‘model schema’ and ‘actual populated model’ as a whole, as well as for the representation of ‘mapping specifications‘ between different schemata and ‘mappings‘ between the different data models. The Neutral Model Layer represents the main concepts for each modelling perspective to be implemented as a separate service in ToCEE, i.e. Neutral Product Model, Neutral Document Model, Neutral Process Model, Contract Model and Conflict Model. These three layers (Meta-Kernel-Neutral) build the shared Project Model of the CEE, binding the orthogonal domain-specific modelling representations in the different system components into one consistent whole. Below them are the layers related to the various system aspects that must be considered in a building project. For instance, the Product Model is substructured into architectural, structural, geotechnical, HVAC and facility management Aspect Models and further specialised Application Models (for structural analysis and design, foundation design, construction site simulation etc.). Currently, the Process and the Document Models are not further specialised, but it is likely that a similar substructuring will be necessary here too, e.g. to distinguish between project documents, regulatory documents, supplier documents etc. The lowest level, i.e. the application model layer, is often neglected in product modelling as being self-evident. In our opinion it must also be seriously considered in real-world modelling because it is the necessary prerequisite to connect also the non-harmonised, non-STEP conforming data models of existing legacy applications. The state of best practice in the building industry on data modelling is at present non-STEP-oriented, and the IAI initiative of the world-wide leading CAD providers gives evidence that STEP is only seen as a general recommendation for an independently developed industry standard. We respect this tendency in order to allow faster transition of the achieved
research results into practice. Thus, despite of some difficulties, the ToCEE models follow as close as possible the newest IFC project model (draft version 1.5), adjusting and extending it wherever necessary with specific constructs for CEE, such as Approval, Access Rights and Order Assignment supporting the legal requirements to electronic data management, as well as different kinds of groupings, such as Conflict Group Assignment, Document Assignment and View - supporting the semantic and functional interoperability in the framework. These extensions to the IFC model, as well as the knowledge-based methods for achieving the interoperability in the environment (model mapping, matching, consistency checking) are discussed in detail in [HYV-97]. Activities and Process Modelling From activities point of view, i.e. the process and information flow point of view, there are the three application domains - design, construction, facility management - on the top level of the activity reference model. As shown on fig. 1 they are accompanied by two additional activities: the management of the project information and the maintenance of the CEE information. The first is more closely related to the product and document models, whereas the latter is related to the Information Logistics system. At runtime, this process model can be: (1) further refined to more specific activities, and (2) complemented with the definition of ad-hoc activities. In order to keep track of the semantics of such ad-hoc activities, a generic activity classification schema is developed, which allows the definition of nested activity contexts [WAS-97]. Conflict Management The management of conflict is not very well supported by existing IT systems today. Most of the conflict management is done manually by the project actors and by the project manager, who use their knowledge about the product to be built and the information supplied by drawings to form a model of the building in their mind in order to detect possible conflicts. The main issues for conflict management in the CEE are to enable the parallel and simultaneously working of various actors and at the same time ensure the correctness of the data by controlling and managing already detected conflicts and by making the actors aware of these conflicts. To help tackle these issues a conflict database will be used to group all the information regarding specific conflicts. This database can be queried by the project manager as well as by the other users to inform about related conflicts. By tracing the activities on the product model data it will be possible to determine the actors who have to be informed of unsolved conflicts. The conflict resolution itself will be supported by knowledge-based negotiation methods which will be triggered at the project coordination points at which temporary inconsistencies of the project data have to be removed (see fig. 3 above).
4
Envisioned Demonstration Scenarios
The methodology and techniques developed by ToCEE shall be validated and demonstrated by software prototypes in real world scenarios. Three different demonstration scenarios are envisioned to show the operability and benefits of the proposed IT environment for concurrent engineering work. As case project the New Munich Fair (Neue Messe München) is selected. At present this large site, including over 20 buildings, is under construction and will be finished by the end of 1998.
Scenario 1 will demonstrate cooperative design with the relevant iteration cycles that are necessary to obtain conflict free, overall agreed design solutions. As a case example, one of the buildings of the New Munich Fair will be taken and specific design coordination parameters such as cut-outs in floors and walls, where architect, structural engineer and HVAC engineer are involved, will be chosen. The life cycle will be included in this scenario by simulating construction process parts for checking constructability, and by simulating the building behaviour for checking the functionality of the building and the maintenance efforts and costs that will be necessary. Scenario 2 will demonstrate the cooperative work between the two life cycle phases: design - construction. This scenario, with a loop back from construction site preparation to design, usually happens when an unexpected situation on the construction site, which demands re-design of parts of the building, occurs. The re-design is strongly constrained by the actual situation on the site and the already erected parts of the building. Scenario 1 is included here as well as part of the re-design process. As a case example, an unexpected situation in the geotechnical domain will be considered. Scenario 3 will demonstrate concurrent engineering potential from facility management point of view. A strong interaction between design and facility management is always present (though not always sufficiently considered), concerning the data structures and information content transferred from design to facility management, and between construction and facility management, concerning the as-built data. The demonstration of concurrency in the facility management life cycle phases will be concentrated on space management, which requires product data concerning the base floor plans, definition of spaces (in closed areas) and information connected to the spaces themselves, and on technical facility management, which requires data related to the building service systems (HVAC, electrical etc.) and the equipment. The cooperative work between facility managers and designers which is needed in the case of refurbishment or modifications of a building includes similar interaction cycles as in scenario 2.
5
Conclusions
The goal of ToCEE is the development of an overall conceptual framework, a software system prototype and discrete tools to support concurrent engineering. The system should handle various information types, including product and process information, document management, legal aspects, contract and regulation processing. In coordinating the efforts related to the management of this information, we have learned that an overall conceptual structure of the CEE system is required. This paper documents the main views on such a structure, based on the clear separation of the construction and the information system aspects. It includes very abstract concepts of information handling, consistently specialised down to concrete application-specific data items. To applications such system will provide a high level abstraction of a distributed, multi-server, platform-independent environment.
6
Acknowledgements
Research related to this paper has been carried out within the ESPRIT Project 20587 ToCEE financially supported by the European Union and the industrial partners. Their support is very appreciated.
References AMO-96
Amor R. and Clift M.: Document Models and Concurrent Engineering. In: Turk Z. (ed.) „Construction on the Information Highway“, Proc. CIB-W78 Workshop, Bled, June, 1996.
AMO-97
Amor R., Katranuschkov P., Clift M., Scherer R.J., Turk Z. and Hannus M.: A Framework for Concurrent Engineering - ToCEE. In: Proc. PDTAG’97 Conference, Nice, April, 1997.
AUG-95
Augenbroe G. (ed.): COMBINE 2 Final Report. EU/CEC Joule Programme, Project JOU2-CT920196, TU Delft, 1995.
BOE-94
Böhms M. and Storer G.: ATLAS - Architecture, methodology and Tools for computer-integrated LArge Scale engineering. In: Proc. JSPE-IFIP WG 5.3 Workshop, DIISM’93, Tokyo, 1994.
HEN-91
Henderson L. R.: CALS as a solution for digital delivery of technical documents. Computer-Aided Design, 23(4), 1991.
HYV-97
Hyvärinen J., Katranuschkov P. and Scherer R. J.: ToCEE Deliverable F2-1 - Concepts for the Product Model and Interoperability Management Tools. Technical Report, July, 1997.
IAI-97
International Alliance for Interoperability: Industry Foundation Classes, Release 1.0 - End-User Guide and Specifications, IAI Publ., 1997.
ISO-94
ISO 10303: Product Data Representation and Exchange. Parts 11, 22, 41-45, 106, 225, 230, 231. International Organisation for Standardisation, ISO TC184/SC4, Geneva, 1994-96.
LUI-93
Luiten G., Froese T., Björk B-C., Cooper G., Junge R., Karstila K. and Oxman R.: An Information Reference Model for Architecture, Engineering and Construction. In: Mathur K.S., Betts M.P. and Tham K.W. (eds.) „Management of Information Technology for Construction“, World Scientific Publishing, Singapore, 1993.
SCH-95
Scherer, R. J.: EU-Project COMBI - Objectives and Overview. In: Scherer R.J. (ed.) „Product and Process Modelling in the Building Industry“, Proc. ECPPM’94, Dresden, Oct., 1994.
TOC-95
ToCEE: Project Programme. EU ESPRIT Project 20587 ToCEE „Towards a Concurrent Engineering Environment in the Building and Engineering Structures Industry“, EU/CEC Directorate Generale III, Brussels, Nov., 1995.
WAS-97
Wasserfuhr R. and Scherer R. J.: Information Management in the Concurrent Design Process. In: Proc. Int. Colloquium IKM’97, Weimar, February, 1997.
WFM-94
Workflow Management Coalition: Glossary - A Workflow Management Coalition Specification. WfMC Technical Document, 1994. (http://aiai.ed.ac.uk(WfMC/DOCS/glossary.html)
