Towards a Concurrent Engineering Environmentitc.fgg.uni-lj.si/toceecd/reports/final.pdf · Towards a Concurrent Engineering Environment ToCEE ... Acknowledgement ... sos Filos (CEC

ESPRIT Project No. 20587 ToCEE Deliverable K 7 / J 2

1

Towards a Concurrent Engineering Environment

ToCEE

A MULTI-TIER CLIENT-SERVER SYSTEM

FOR CONCURRENT ENGINEERING

Raimar J. Scherer (Ed.)

January 2000

7. Version 2000/08/28

Final Report and Migration Guidelines

DELIVERABLE: K 7 / J 2

AVAILABILITY: PUBLIC

PROJECT DURATION: 01/96 – 04/99

REPORTING PERIOD: 01/96 – 04/99

PARTNERS OWNING: TUD, VTT, BRE, OPB, DAP AND IBS

DATE: JANUARY 31, 2000

Acknowledgement The partners of the ToCEE consortium deeply acknowledge the financial and the advisory support of the Commission of the European Community (CEC) given in particual by Dr. Era-sos Filos (CEC project officer) , Dr. Fikry Garras and Prof. Rainer Anderl (reviewers) during the runtime from 1996 through 1999, which allowed the consortium to develop a concurrent engineering environment and to investigate in particular such important issues like e-signature, legally binding e-documents and e-data, modelling of the responsibility structure in virtual enterprises, dynamic integrated workflow and project management, conflict manage-ment and virtual round table decision processes.


3

Foreword From 1996 through 1999, during a period of 40 months an industrial and academic consor-tium of 10 partners investigated new ways of working for the building construction industry and developed a prototype client-server system for concurrent engineering in a 420 person months effort supported by the Commission of the European Community under the ESPRIT Framework 4 Programme.

For a quick understanding of the developed Concurrent Engineering Environment (CEE) from the practical point of view it is recommended to first read the final overview report “the To-CEE Concurrent Engineering Environment” by R. J. Scherer, January 2000. This 27-page report is focused on the main principles of the CEE and provides a compressed pictorial road show of the system as a whole with explaining text. There the emphasis is put on information logistics and conflict management. The report can be downloaded from http://cib.bau.tu-dresden.de/.

A more detailed road show of the whole system is provided by a Power Point show, which complements both reports. There, the explanation of the system as well the individual compo-nents is done in more detail by transparencies and screenshots but with very short accompany-ing text parts. The explanation is arranged around a fictive design sequence of a real structure, showing how the system supports collaborative, co-operative and simultaneous engineering and conflict management. The whole story is structured into five acts and complemented by several outsourced excursions for the explanation of components and methods in more detail. The PPT show can be downloaded from http://cib.bau.tu-dresden.de/.

This final report summarizes the requirement studies and describes the developed prototype of the multi-tier client-server system ToCEE as a whole and component-wise and provides addi-tional background information. The objective of the report is to keep the overall concept and context and is addressed to the technical and scientific interested reader.

For those who would like to have additional information focused on individual components, the public final reports of the single workpackages are recommended, which can be ordered from [email protected]. Contributions to this report has been made by the follow-ing persons on behalf of their organizations and on behalf of their co-workers involved in the project but not explicitly mentioned here:

Robert Amor BRE: chapter 5.5 Robert Balder OPB: chapter 5.5 Mike Clift BRE: chapter 5.5 Janez Duhovnik ISE chapter 5.6 Lauri Heikkinen KUP: chapter 7.4 Juha Hyvärinen VTT: chapter 5.2 Peter Katranuschkov TUD: chapter 5.2, chapter 5.3, chapter 6, chapter 7.2 Mauro Mangini DAP: chapter 7.3 Eduard Ott OTT: chapter 4 Byron Protopsaltis SOF: chapter 7.1 Raimar Scherer TUD: chapter 2, chapter 3, chapter 4.6, chapter 5.3, chapter 5.4,

chapter 7.1, chapter 7.2, chapter 8 Marc Sparacello GCC: chapter 7.3 Ziga Turk ISE: chapter 5.6 Rainer Wasserfuhr TUD: chapter 5.1


4

The original contributions have been edited appropriately in order to come up with one ho-mogeneous document, i.e. gaps have been filled and overlaps have been cleared by the editor, which sometimes demands stronger changes in the original text submitted. The editor counts on the generosity of the authors for the benefit of the readers. Dresden, January 2000 Raimar J. Scherer


5

CONTENTS

1 THE TOCEE CONSORTIUM.............................................................................................................................7 2 OBJECTIVES ........................................................................................................................................................ 10 2.1 CONCURRENT ENGINEERING...................................................................................................................................10 2.2 REQUIREMENTS ON THE FRAMEWORK...................................................................................................................12 3 CONCURRENT ENGINEERING ENVIRONMENT ............................................................................... 15 3.1 THE MANAGEMENT PROCESS .................................................................................................................................15

3.1.1 Activity View of the Management Process .................................................................................................... 15 3.1.2 Data View of the Management Process......................................................................................................... 16

3.2 THE DATA MODEL ARCHITECTURE .......................................................................................................................17 3.3 SYSTEM ARCHITECTURE ..........................................................................................................................................18 3.4 THE CEE SYSTEM COMPONENTS MANAGEMENT................................................................................................19 3.5 THE BUSINESS PROCESS ..........................................................................................................................................20 3.6 THE TECHNICAL PROCESS .......................................................................................................................................21 3.7 PROTOTYPE IMPLEMENTATION OF THE ENVIRONMENT ......................................................................................22 3.8 FUTURE EXTENSIONS...............................................................................................................................................24

3.8.1 Extensions to Electronic Commerce............................................................................................................... 24 3.8.2 Extension to a Client-Server-Agent Architecture......................................................................................... 24

4 LEGAL ISSUES .................................................................................................................................................... 26 4.1 OBJECTIVES ...............................................................................................................................................................26 4.2 ESTABLISHING LEGAL ACTS BY ELECTRONIC MEDIA – THE DIGITAL SIGNATURE .......................................26 4.3 LEGAL EVIDENCE OUT OF ELECTRONIC MEDIA...................................................................................................29 4.4 AUTHORITY TO GIVE ORDERS AND CREATE OR MODIFY DATA........................................................................30 4.5 LEGAL REQUIREMENTS ON AEC OBJECTS...........................................................................................................31 4.6 IMPLEMENTATION OF THE LEGAL ISSUES..............................................................................................................33 5 COMPONENTS OF THE CONCURRENT ENGINEERING ENVIRONMENT............................. 34 5.1 THE INFORMATION LOGISTICS AND WORKFLOW MANAGEMENT SYSTEM......................................................34

5.1.1 Components of the Information Logistics Layer .......................................................................................... 34 5.1.2 The ToCEE Advanced Process Workflow Management System................................................................ 35 5.1.3 Advanced Project Management Services....................................................................................................... 37 5.1.4 The ToCEE System Component Management System................................................................................. 38 5.1.5 The ToCEE System Communication Method................................................................................................ 39 Step 1) Browse the template repository......................................................................................................................... 41 Step 4) Get the worktasks created after the application of the template.................................................................. 42 5.1.6 The ToCEE Client Adapter Layer................................................................................................................... 42 5.1.7 Extending the ToCEE Environment................................................................................................................ 43

5.2 PRODUCT MODEL SERVER AND DATA MODELLING FRAMEWORK FOR CEE ..................................................43 5.2.1 Objectives and Requirements........................................................................................................................... 43 5.2.2 Operational Interoperabiliy – ToCEE Operational Framework............................................................... 45 5.2.3 ToCEE Modelling Framework ........................................................................................................................ 46 5.2.4 Specific Issues of the Modelling Framework for CEE ................................................................................ 49 5.2.5 Functional interoperability.............................................................................................................................. 50 5.2.6 The Product Data Management Server Prototype PROMISE ................................................................... 52 5.2.7 The Product Model Browser Prototype ProMoTe....................................................................................... 54

5.3 CONTRACTUAL MODEL FOR A CE VIRTUAL ENTERPRISE..................................................................................56


6

5.3.1 Problem Specification....................................................................................................................................... 56 5.3.2 Current Practice................................................................................................................................................ 57 5.3.3 Envisaged Improvements through an IT-Based Virtual Enterprise.......................................................... 57 5.3.4 The Data Model for Authorization.................................................................................................................. 59 5.3.5 Instantiation of Access Rights.......................................................................................................................... 63

5.4 CONFLICT MANAGEMENT SYSTEM ........................................................................................................................63 5.4.1 Objectives and Requirements........................................................................................................................... 63 5.4.2 Conflict Management Framework and Architecture................................................................................... 65 5.4.3 Implementation................................................................................................................................................... 68

5.5 DOCUMENT SERVER.................................................................................................................................................69 5.5.1 Requirements...................................................................................................................................................... 69 5.5.2 Document Server System.................................................................................................................................. 70 5.5.3 DMS Client.......................................................................................................................................................... 73 5.5.4 Overview on the basic functionality of the DMS.......................................................................................... 74

5.6 REGULATION SERVER ..............................................................................................................................................76 5.6.1 Requirements and Objectives........................................................................................................................... 76 5.6.2 Regulation processing framework .................................................................................................................. 77 5.6.3 Prototype development...................................................................................................................................... 81

6 CASE EXAMPLE – THE NEW MUNICH FAIR ....................................................................................... 85 7 CEE APPLICATIONS AND APPLICATION TOOLS ............................................................................. 92 7.1 APPLICATION TOOLS FOR THE DESIGN PROCESS.................................................................................................92

7.1.1 Objectives and Requirements........................................................................................................................... 92 7.1.2 Design Phase Client and IFC Interfaces with the ToCEE STEP Toolbox............................................... 93 7.1.3 CE Extensions for the Design Tools............................................................................................................... 94

7.2 CONFLICT MANAGEMENT IN THE DESIGN PROCESS............................................................................................95 7.3 CONSTRUCTION SIMULATION TOOLS...................................................................................................................106

7.3.1 Site Preparation Module................................................................................................................................107 7.3.2 The Construction Simulation Module...........................................................................................................109 7.3.3 Data Exchange and Information Sharing through Client Interfaces......................................................113

7.4 FACILITY MANAGEMENT APPLICATION TOOL...................................................................................................116 7.4.1 Objectives..........................................................................................................................................................116 7.4.2 Objectives of FM Software in ToCEE ..........................................................................................................117 7.4.3 Implementation Alternatives for FM System...............................................................................................117 7.4.4 Functionality of FM System...........................................................................................................................118 7.4.5 Integration of the FM Application Tool in ToCEE....................................................................................119

8 MIGRATION STRATEGY .............................................................................................................................122 8.1 MARKET TRENDS AND DEVELOPMENT................................................................................................................122 8.2 MIGRATION RECOMMENDATION FOR THE INDUSTRY.......................................................................................127 9 GLOSSARY..........................................................................................................................................................129 10 REFERENCES ....................................................................................................................................................132 10.1 PAPER REFERENCES................................................................................................................................................132 10.2 INTERNET REFERENCES.........................................................................................................................................137 10.3 PUBLIC TOCEE REPORTS......................................................................................................................................138


7

1 The ToCEE Consortium Obermeyer Planen + Beraten (Design and Consulting Company) regular mail Hansastraße 40, D-80686 München contact person Rudolf Juli, Dr., Dept. R + Z type of contact business, technical, user phone +49 (89) 5799-470 fax +49 (89) 5799-495 e-mail [email protected] www http://www.opb.de/

OPB DE

C

Building Research Establishment Ltd. (Research and Expertise Centre) regular mail (Bucknalls Lane) Garston, Watford, WD2 7JR, UK contact person David Bloomfield, Director type of contact technical phone +44 (1923) 664-549 fax +44 (1923) 664-689 e-mail [email protected] www http://www.bre.co.uk/ (http://helios.bre.co.uk/ccit/people/trebor1.html)

BRE UK

P

Computeranwendung im Bauwesen (University of Technology Dresden) regular mail (Mommsenstr. 13), 01062 Dresden contact person Raimar J. Scherer, Univ.-Prof. Dr.-Ing. type of contact technical, business phone +49 (351) 463- 3527 fax +49 (351) 463-3975 e-mail [email protected] www http://cib.bau.tu-dresden.de/ (http://cib.bau.tu-dresden.de/mitarbeiter/cjs)

TUD DE

P

D'Appolonia S.p.A (Design Consulting and Software Development) regular mail Via San Nazaro 19, I-16145 Genova contact person Mauro Mangini, Ing., MSc (Carnegie MellonUniversity) type of contact business, technical, user phone +39 (10) 362-8148 fax +39 (10) 362-1078 e-mail [email protected] www http://www.dappolonia.it/

DAP IT P

General Construction Company S.A. (Building Construction Company) regular mail 30 Kapodistriou Ave., GR-151 23 Maroussi / Athens contact person Henry-Marc Sparacello, Civ.eng. (E.S.T.P.-Paris) type of contact user phone +30 (1) 68-33-401 fax +30 (1) 68-43-253 e-mail [email protected] www

GCC GR

P


8

KUPARI Engineering Oy (Engineering and Consulting Company) regular mail PO Box 31 (Liesikuja 4 A) FIN-01600 Vantaa contact person Lauri Heikkinen, Dr.ing., Senior Consultant type of contact business, technical, user phone +358 (9) 53054-221 fax +358-(9) 53064-201 e-mail [email protected] www http://www.kupari.fi/gb_index.html

KUP FI P

Dr. Ott Lawyer, civil and industr. eng. (Lawyer and Engineer) regular mail Tillmann & Ott, Vorhoelzstr. 21, D-81477 München contact person Eduard Ott, Dr. jur., Dipl.-Ing., Dipl.Wirtsch.Ing. type of contact business, technical phone +49 (89) 749161-0 fax +49 (89) 749161-31 e-mail [email protected]

OTT DE

P

SOFiSTiK Hellas SA Athens Development (Software Vendor) regular mail 3rd Septembriou 56, GR-10433 Athens contact person Byron Protopsaltis, Dr. type of contact business phone +30 (1) 822-0607 fax +30 (1) 825-1632 e-mail [email protected] www http://www.sofistik.de/

SOF GR

P

VTT Building Technology (Research and Expertise Centre) regular mail PO Box 1801, FIN-02044 VTT contact person Matti Hannus, Chief Research Scientist type of contact technical phone +358 (9) 456-6948 fax +358 (9) 456-6251 e-mail [email protected] www http://www.vtt.fi/ (http://cic.vtt.fi/hannus/)

VTT FI P

Institute of Structural & Earthquake Engineering (University Ljubljana) regular mail PO Box 579 (Jamova 2) SI-1000 Ljubljana contact person Ziga Turk, Ass. Prof., Faculty. of CivEng and Geodesy type of contact technical phone +386 (61) 1768-622 fax +386 (61) 1250-693 e-mail [email protected] www http://www.fgg.uni-lj.si/ (http://itc.fgg.uni-lj.si/~zturk/)

ISE SL

P


9

Ingenieurbüro Scherer (Project Management Consultancy) regular mail Schevenstraße 19c, D-01326 Dresden contact person Raimar J. Scherer, Univ.-Prof. Dr.-Ing. type of contact business phone +49 (351) 268-4516 fax +49 (351) 268-4517 e-mail [email protected]

IBS DE

S

________________ C = Co-ordinator, P = Partner, S = Sub-contractor


10

2 Objectives

2.1 Concurrent Engineering Concurrent engineering is the way of developing and manufacturing complex products in a fast, efficient, faultless and therefore competitive way. This has led to the development of team work being one of the advantages of modern industrial societies on the one hand and on the other hand to big companies due to the fact that the availability of the right expert at the right time at one and the same location seems to be manageable only if this expert is em-ployed in one and the same company. All in all, it is just a knowledge logistics problem. However this way of coping with the knowledge logistics problem leads to bigger and bigger companies. A trend that was most consequently followed in the socialist countries, whereas in industry countries self-organizing systems, self-controlling systems, flexible teams and lean construction have been the answer to the overkill accompanied with such big organizations.

Modern communication techniques, such as telephone and later on fax, easy, cheap and fast in transmitting knowledge over any distance, modern printing techniques, such as photocopy machines, easy, cheap and fast in duplication of represented ideas and knowledge in written and graphical form and modern transportation techniques, as well easy, cheap and fast, which have highly increased human mobility, have been the three driving forces to overcome the need of big companies to cope with knowledge logistics and promoted the development of new enterprise strategies, such as joint ventures, outsourcing, strategic alliances and sub-contracting. Small, lean, efficient and sharing work across enterprise borders are the modern trends.

All large construction companies in the western world has dramatically changed their profile concerning for instance engineering design resources. There was a dramatic cut-down throughout the late seventies, eighties and early nineties in the size of the design and construc-tion departments. Sub-contracting and hiring on demand have been the fascinating word. Eventually, this was one of the starting phase of the new ways of business engineering and enterprising in the construction industry, like extended enterprises and virtual enterprises. However, at least the vision of these new ways of doing business and engineering work was born. However, the efficient way of doing this kind of working has become and ongoing be-comes reality due to the use of Information Technology, the Inter- and intra-nets and the World Wide Web.

Concurrent engineering and virtual enterprising are closely related, because both are closely connected with Information Technology via the corresponding kernel problem supported by this technology, namely information logistics, which at the end will due to the involvement of human experts result in the management of the already above mentioned problem of knowl-edge logistics. Therefore the main and most innovative and important part of ToCEE was the information logistics component but at the same time it is the most invisible part of the devel-oped client-server system. Its presence is only imaginable if the one who is working with the system has experience in usual client-server systems and workflow systems used in standard office work, for instance. The visible parts are product data management, electronic document management and process management. At a first glance, these visible parts of ToCEE may lead a superficial observer to the impression that ToCEE might be only one of the currently emerging client-server systems for engineering applications. However, ToCEE is more. It is an information and a knowledge communication and logisitics system for the virtual enter-prise and for concurrent engineering.


11

Concurrent engineering does have different aspects, which are often fuzzily specified and often not made cognizant. Concurrency occurs in four different basic ways: in time, in space, in do-main and in enterprise (Fig. 2.1). Each corresponds to already defined and well understood ways of engineering. These are simultaneous engineering, collaborative engineering, co-operative engineering and – as an upcoming new branch – electronic engineering commerce.

COOPERATIVEENGINEERING

Product - ViewVirtual Expert

SIMULTANEOUSENGINEERING

Product - TimeVirtual Time

COLLABORATIVEENGINEERING

Human - SpaceVirtual Enterprise

Electronic Commerce

Product - SpaceVirtual Market

ConcurrentEngineering

Fig. 2.1: Aspects of Concurrent Engineering [Table 3.1]

Co-operative engineering is the synchronized work of different domain experts working on one and the same part of the product. This kind of concurrency, which represents the human-knowledge dimension, requires a virtual product model, that allows different data views of one and the same part of the product and moreover needs functionalities for data management, such as transformation, consistency checking, monitoring, control and notifications of the different engineers, so that a conflict-free synchronized design and manufacture of the product is guaranteed.

Collaborative engineering is understood to be the work of physically distributed teams work-ing on one and the same product as if working at a round table regardless of the location of the team members. This requires an extended or virtual enterprise organization in order to appropriately co-ordinate the work and streamline all participants towards one common objec-tive, regardless of the different enterprises they belong to.

Simultaneous engineering means that at any time of the design process each product life state is appropriately taken into consideration, for instance by applying the related expert knowl-edge by means of forecasting, prognosis and simulation either by tools or by involving the human expert directly.

The overall goal is concurrent access to the same data and concurrent synchronized objec-tives; just to form a team and provide team work, even if there is physically no team due to separation in time and space. Therefore concurrent engineering is strongly connected with virtual enterprising, with simultaneous access to and simultaneous modification of the same product items, and with the co-ordination of parallel streams of data, information and knowl-edge flow in the virtual enterprise.

Further goals connected with concurrent engineering are flexibility and availability of human expert resources, faster access to expert knowledge and an improved collaborative work, in


12

order to increase the quality of the designed and manufactured product and to reduce the lead time. In order to achieve this, all the economic and technical aspects, that might and can affect the product during its life cycle, must be concurrently taken into consideration.

2.2 Requirements on the Framework In order to achieve the concurrent engineering objectives in an efficient way an IT-based framework is necessary which constitutes the virtual enterprise for the collaborative engineer-ing, the simultaneous engineering and the virtual product model for co-operative engineering. One of the important aspects of the framework is the modelling, co-ordination and integration of all underlying enterprise processes as for instance basically explained in . There are four principle processes identifiable: the technical process, the business process, the commerce process and the co-ordinating management process (Fig. 2.2). Each of these processes is con-cerned with different kinds of data, namely the product data, the activity data, the cost and delivery data and the control data. Each of them have to be modelled by discipline-specific data models.

Fig. 2.2: Processes to be co-ordinated for concurrent engineering and the resulting data (taken form [Scherer, 1998a])

However, due to the different disciplines the data and processes belonging to and the accord-ing different cultures the involved humans show, quite different models result, which have to be integrated and harmonized. This is an advanced interoperability problem and an essential ontology problem, too [Katranuschkov 2000]. The modelling of processes and data is a data structure and activity control problem. However, the framework should not only provide ar-chives for the data but support the flow, the retrieval, and the distribution of information, too. This means that there is a strong requirement for logistic support concerning the value infor-mation. This is the important new demand on IT, which goes beyond the traditional objectives of software tool developments for engineering applications. At a first glance this seems to be a business process modelling problem. However, this nowadays turns into an essential engi-neering requirement, because concurrent engineering is based on the virtual enterprise para-digm. Strongly connected with this aspect is the responsibility problem, i.e. the appropriate

Co-ordination Board

Technical Process

Business Process

Commerce Process

Management

Product Data

Activity Data

Cost and Delivery Data


13

modelling of the responsibility for the fulfilment of tasks, activities and events, the authoriza-tion of access and modification of data and the responsibility for the information flow, i.e. the proper supply of the finally valid and binding data. These aspects are dealt with in our frame-work by legal modelling, approval modelling and electronic signatures [Scherer 1997], [Ott 1998].

In a more abstract way these requirements can be fulfilled through the combined IT-based modelling of the process model, the product model and the document model [Scherer, 1998a] integrated by an information logistics model. Therefore the information logistics model has not only to manage the information flow in the CEE but it has also to know about and manage all the components, i.e. the services and tools of the CEE. It owns the information about the information [Turk et al 1997]. It is the important hidden background model of the concurrent engineering environment, as it is visualized through the exploded view of the ToCEE logo (Fig. 2.3).

Fig. 2.3: ToCEE Logo – Exploded View [Scherer 1998b]

The second important part of the framework is the co-ordination board (Fig. 2.2). This com-ponent has to link together data, information and human intention. The project manager must be able to control and manage the processes via the board and all participants must receive an individual view of their own contributions as well as an informative overview of the whole project in order to be able to deduce the appropriate priorities for their contributions on their own. Therefore the status of the activities has to be transparent not only to the project man-ager but to all project participants in a presentation corresponding to their dedicated views and responsibilities in the project.

As a result, two major objectives can be identified:

• First, a communication architecture is needed that carries out the transformation and the compression and presentation of information for all participants across the technical de-sign, business and commerce domains. This defines the data-oriented view.

• Second, the data manipulation and communication must be coupled with the manage-ment process in order to monitor the execution of the planned project workflow and adapt it to the current alternatives. This defines the activity process-oriented view.

Both objectives demand interoperability of different kinds and degrees and a high level of semantics in order to identify the necessary activities. Besides the sharing of data and objects


14

also a common understanding and interpretation must be supplied in order to allow co-operative work [Katranuschkov 2000]. From the viewpoint of ontologies [Gruber 1993], a theory for common object representations for the co-ordination board has to be derived. We call this co-ordinational interoperability because it should provide the co-ordinated access and interpretation of semantic objects. The key point here is that integration can not be reduced to common data structures and transportation of data across networks. High level interoperabil-ity is the sharing of interpretable and useable information between multiple partners, compo-nents and tools. This implies that, in general, information should be receiver-oriented filtered and represented when moving from the specific context of one actor to differing contexts of other actors. This is an important basic problem of IT systems for virtual enterprises that could only be touched in this project but still need substantial basic research, field studies, practical requirements and evaluation and several industrial research and development efforts.

Below co-ordinational interoperability, there is the need of platform interoperability and nota-tional interoperability. Platform interoperability (or operational interoperability) aims at inte-grating heterogeneous computer hard- and software and notational interoperability to harmo-nize the syntax notation. The later is further subdivided in semantic and in functional interop-erability. These interoperability problems are focused by the ToCEE project and solutions are developed, prototyped and tested. They are discussed in chapter 5.1 and 5.2.


15

3 Concurrent Engineering Environment

3.1 The Management Process

3.1.1 Activity View of the Management Process

For the realization of the co-ordination interoperability we have introduced the concept of a co-ordination board (Fig. 2.2), on which the activities of the project process are co-ordinated. The board has a graphic-interactive component (Fig. 3.1) for planning, refinement and modi-fication of project activities, where activities are additionally sub-structured into worktasks. Activities are often called workflow in the literature and at a first glance the process manage-ment tool looks like an ordinary workflow tool.

Fig. 3.1: Roles for Worktasks of the Demonstration Scenario

However, in our approach activities combine the business process with the technical and commerce process via worktasks (Fig. 3.2) in a dynamic way on the level of project planning and management. Business process data are incorporated via process templates into activities. Activities are instantiated process templates. Business data are mainly data needed by the in-formation logistics services to maintain the system. Product data, cost and delivery data, etc. are incorporated into worktasks via product data and via documents and they contain the nec-essary information logistics data in form of technical and commerce process meta data ob-jects. The integration of activity, technical product and commerce data are achieved by the ToCEE system with the information logistics system. This leads to the multi-layered data model (Fig. 3.4) described in more detail later.

The co-ordination board is the management tool, which provides project transparency to all participants. It is owned by the project manager and in general project participants are only allowed to make suggestions for activity planning to the project manager. However, in order to promote self-responsibility and fast reaction by everybody every participant should be in-

Facilit.Mgr.

Proj.Mgr.

Architect

Struct.-Eng.

HVAC-Eng.

Found-Eng.

Owner

Constr.Co.

Roles:


16

volved in the activity planning process appropriately according to his responsibility in the project. Therefore activity planning on the project manager level should remain on a very general level following the objective of information compression, whereas on lower levels of enterprise processes a more detailed activity planning may be necessary depending on the particular tasks and the participants involved. For this purpose the project manager can and should delegate the right to create new sub-activities to appropriate participants or he should even give the order to selected participants to refine activities appropriately. This needs an appropriate modelling of the authorization structure which has to be done by hand up to now but it is imaginable that in the future it will be semi-automatically deduced from contracts [Scherer 1997].

instantiate

Process template repository

Worktask Worktask

Role Role

Actor Agent

Business Process

Process template

Objects/ Documents

Activity

Objects/ Documents

Technical Process + Commerce Process

Activity Flow

Data Flow

Fig. 3.2: Activity-based Integration Model

3.1.2 Data View of the Management Process

From the data view we have introduced an information container (Fig. 3.3), which is based on a wrapper concept. There the original data, which can be either product data in object representa-tion, i.e. the computer-internal representation of information or they can be document data, i.e. the human-like representation of information, are wrapped by process or management data, i.e. business process data like data concerning activities, worktasks, orders and the worktask status. Often this business process data are nothing else than information logistics meta data but we clearly distinguish between business process data and pure information logistics data.

These business process data are additionally wrapped by header data, which serve for the management of the information carried out by the information logistics system [Wasserfuhr 1998] on the level of platform interoperability.

Header Data: ID

Management Data: PsD

LeD

Product Data: internal: Obj’s external: Doc’s

Layer 1: Info-Syst. Header UPRL Address

Layer 2:

Process Data Legal Data

Layer 3: Product Data direct or attached

Fig. 3.3: Structure of the Information Container


17

For platform interoperability we have developed in the ToCEE project a mechanism called Uniform Project Resource Locator (UPRL) [Wasserfuhr & Scherer 1997], which is an exten-sion of the URL mechanism. The main extension items developed are summarized in Table 3.1.

Resource Identification URL UPRL

Server www server UPRL object server

Client browser, robot browser, robot, helper application

Response content HTML, multi media HTML, multi media, objects

Access methods browsing, full text search

browsing, full text search, object queries

Spec. of request semantics - EXPRESS-C language

Semantic reflection - Concept registry

Semantic multi-server integra-tion

- Concept registry + Server Inter-operability Protocol (SIOP)

Table 3.1: Comparison of URL and UPRL

Interoperability of helper applications and servers is achieved by mapping object addresses to URLs. The basic URL mechanism is extended for addressing project relevant objects. This includes modelling of inheritable object behaviour, access authentication (role dependent visibility of objects and object behaviour), parallel execution of object behaviour and trans-parent access to all meta data. UPRLs allow project-wide object addressing and extends the standard WWW addressing technique towards co-ordinated concurrent access to shared ob-ject-oriented models, client applications to manipulate server-side documents and objects, based on a formal interface definition.

All objects of the environment can be addressed by UPRLs via the Information Logistics server although they may be physically located and managed by other servers. The informa-tion logistics server logically interconnects all servers to one logical but virtual project unit (Fig. 3.4). Systems can retrieve and manipulate data of a server by sending requests to the server across the network and specifying an object address and name at run-time. Models can be physically distributed across several servers, based on a Server Interoperability Protocol specification (SIOP). All requests to UPRL objects are co-ordinated by the information logis-tics server, which behaves like a common request broker corresponding to the concepts of the CORBA technology.

For UPRL servers, additional client applications, such as CAD systems, can be included on the client side, and which can actively manipulate server side documents and objects. These client applications can be extended with a respective middleware interface. It can be imple-mented either on the basis of a Java class library developed in the ToCEE project, or, for other target implementation languages, by using HTTP libraries.

3.2 The Data Model Architecture We have chosen a distributed client-server architecture. The servers are physically organized according to the criteria of combining human-like data representation and computer-internal data representation, i.e. a document server versus the other server (Fig. 3.4 – bottom). This is one criterion of structuring the virtual data space. The other criterion takes attention of the different disciplines, which are linked to the virtual enterprise, i.e. the ontology problem and


18

the process integration problem on one hand and the data view problem on the other hand. This criterion leads us to a five-layer data model architecture [Katranuschkov & Scherer 1997] shown on the top part of Fig. 3.4.

DocumentModel Server

physicaldistribution

logicalintegration

Information Logistics Request Broker

meta level

instance level

ProductModel Server

ProcessModel Server

Meta Layer

Kernel Layer

Neutral Layer

Aspect Layer

Application Layer Document Product Others

Fig. 3.4: Distributed Structured Data Model Servers

There, the three lower layers of the data model directly coincide with the physical server structure, i.e. each server is organized according to these three layers and can be used as a stand-alone system. This three-layer architecture was originally developed in the ESPRIT project COMBI [Katranuschkov 1995], [Katranuschkov & Scherer 1996] and becomes more and more widely applicable through its use by the IAI (IAI 1997) for the IFC product model. These three layers are necessary to logically integrate the data structures from application-tool specific data which are represented in the 5th layer and transform them first to the engineer-ing-discipline specific data, like architectural, structural or HVAC discipline (4th layer) and afterwards to technical kernel data, i.e. the technical ontology level (3rd layer) through the application of the paradigm of data condensation.

The two upper layers are the two interoperability layers for the process integration from the project point and from the virtual enterprise point of view [Katranuschkov & Scherer 1997], [Katranuschkov & Hyvärinen 1998]. They logically integrate the different servers and the according server-specific data structures to a project-wide data model and a virtual enterprise data model, resp. The top but one layer, the kernel layer is the enterprise ontology layer whereas on the top layer, the elements and the structure of the model themselves are defined. This can be seen as the model ontology level.

3.3 System Architecture The ToCEE CEE system is structured in a 5tier multi-client multi-server system [Katranuschkov & Hyvärinen 1998], [Wasserfuhr 1998]. The five layers shown in Fig. 3.5 are

• Client adapter layer, which serves as the basic user interface to CEE, where the clients and application tools are located.

• Adapter layer, which provides most preferably used interface technologies as generic access methods to the ILS.


19

• Information logistics layer, which manages and controls the information processes as well as all the CEE components.

• Server layer, where the management components of the servers are conceptually located. • Project data layer, where the data storage systems are located, such as object-oriented and

relational data base systems or even simple file systems for data mass storage. • Ex-project data layer, which is the same as the project data layer but with data not exclu-

sively belonging to the project, such as regulation data or Internet catalogue data (e-commerce).

Fig. 3.5: CEE System Architecture of ToCEE

3.4 The CEE System Components Management As part of the platform interoperability a plug-in technology is developed [Wasserfuhr, Scherer 1999], which allows to extend the CEE by any new server and client.

Fig. 3.6: Architecture of the CEE System Management

adapter

Application adapter (IL toolk it, ORB,

concad)

Internet adapter (WWW, Email)

EXPRESS adapter (SPF, SDAI)

Ex - project data

Regu - lations

project data

Product Models

Process Models

Documents

Regulation broker

Document mgmt. server

Process mgmt. server

Product mgmt. server

Conflict mgmt. server

information logistic

layer

Common

Request

Broker

Plug-in register

Plug-ins

process wizzard

PtM Browser

SofiCAD

PAULA

CuFIMS

SoFiPLUS

SoFiSTiK

E - mail

document browser

GWM

web

C l i e n t a p p l i c a t i o n la yer

server

layer

CEE component:

client or

server or

kernel application

CEE system manager: EXPRESS - C engine

UPRL interface

system knowledge base: functionality of the CEE components in EXPRESS - C

request

response

CEE - registry


20

The technology is based on a formal description of each CEE component and an additional system management component. As formal language EXPRESS-C [ISO 1994b] is chosen.

Each new component has to show two properties. First it has to have a UPRL system commu-nication interface and second its functionality provided by the UPRL interface has to be de-scribed in EXPRESS-C. Integrating a new CEE component, the component has to be regis-tered in the CEE registry and its interface functionality described in EXPRESS-C has to be uploaded on the CEE system knowledge base.

At runtime the system manager EXPRESS-C engine checks every request from a server and every response to a client by looking-up in the CEE registry first if the component is a valid CEE component, second if the content of the UPRL request/response is in compliance with the functionality of the component as described in the CEE system knowledge base, and third it carries out data transformations if necessary.

In the current state of the prototype, the CEE system management system is not a self-standing component but is integrated in the ILS.

3.5 The Business Process The part of the business process we are interested in is the co-ordination of the teamwork for concurrent engineering and electronic commerce. The work of the members of the virtual enterprise is organized in terms of worktasks (Fig. 3.2), which are globally identifiable and linked to roles, required input, expected or delivered results (documents, product model views, product data objects) and project time schedules [Wasserfuhr 1998].

Nowadays this part of the business process is also known as engineering workflow. However, engineering workflow is usually document-based and there the activity data have to be set up by hand. We extend the scope to product data and included enterprise and contract data as well, which allows us to reduce the manual work for the activity data considerably, and re-duce run-time and errors, too.

Models are needed which support the users for the selection of the correct activity input ver-sions and the notification about which activities have to be performed when, by whom and for which reason. The data are needed in different forms according to the preferences of the users of working either design, production, or process-oriented.

The developed collaborative work environment supports the activities with background knowledge about the roles, obligations and contractual relationships of the different players. The object-oriented role model is used to enrich communication with a semantic model of senders and receivers. The roles may have multiple aspects, because they are embedded in different environments (Fig. 3.7). These environments determine the working culture and the kind of data represented. The role model includes devolution of responsibility, authentication, user preferences, tools to be used and notification services. The generic role model has to be adaptive to the project-specific configuration of the roles. The instantiation of a consistent role model is a non-trivial data transformation [Scherer 1997] even if it is based on an object-oriented contract model of the specific project. The system supports both multiple actors per role and multiple roles per actor. For the latter, we have introduced a technique which we call "organizational role abstraction" in order to address different functions of an organization not only by actors, but also by roles, e.g. HVAC expert of company C. Organizational abstraction permits to encapsulate the details of the execution of an activity from other participants.


21

...

Accountant

Director

Enterprise Roles

Marketplace Roles

Supplier

Project Roles...

Project Mgr.

Cost Designer

Arch.

Fig. 3.7: Role Model

It should be possible for a project manager to define and monitor project communication on the basis of responsibilities. His model is therefore role-process-centred. In our approach a project manager describes the principle activities of the roles in terms of main activities and an worktask model is built up from those main activities by appropriate refinements down to the worktasks carried out in a co-ordinated way by all responsible participants of the virtual enterprise (Fig. 3.1). Such an activity driven architecture extends the different communication activities of actors with an explicit semantic level, which keeps track of the causality of com-munication, by grouping atomic worktasks to activities and checking their relationships to predefined process templates, which are defined by a project manager and based on overall enterprise strategies.

3.6 The Technical Process We envisage the technical process as driven by the requirements of the investor, the availabil-ity of technical products on the electronic market, the know-how of the design team and the sophistication of the tools. In general, the technical process will be integrated in the co-ordination board via the worktasks of the business process (Fig. 3.2).

Each individual technical worktask will thus represent one distinct part of the consecutive changes of the state of the evolving product data. The goal of each task is to provide a feasible technical solution whereby the required functionality and behaviour of the designed building are achieved in a measurable way. The actor responsible for a certain specific task will typi-cally work with the product data representing his specific view made available through the layered product model and corresponding interoperability methods [Katranuschkov & Hy-värinen 1998], [Katranuschkov 2000]. The actors need tools and services that support them to reliably access to a common product data repository, including view transformation methods, version management and recognition of conflicts with other designers. Since the technical solutions most often include a great variety of externally supplied products, it is important to ensure a close interaction with the electronic commerce activities, i.e. search on the electronic market, negotiating, purchasing and supplying the right products and product data.

We supported the technical process by a hierarchically structured product data model of the building (Fig. 3.4), based on the STEP technology [ISO 1994a] and on the IFC model [IAI 1997]. The product data will be stored in a shared distributed database and accessed through a high-level interface based on the SDAI technology [ISO 1994a]. The anticipated overall ar-chitecture of the technical process system and its relation to the overall workflow is shown in Fig. 3.8. The Product Data Server is described in chapter 5.2, and the detailed model is given in [Katranuschkov & Hyvärinen 1998], [Hyvärinen et al 1997].


22

T-PINS

Designproduct data

repository

TechnicalDesign Tool(CAD , AID)

Set-topinteroperability tools

ProductData Server

(ToCEE)

DesignCase Base

El. Commerceproduct data

repository

TechnicalWork Task

WorkTask

WorkTask

Business processworkflow

Fig. 3.8: Architecture of the IT Components for the Technical Process

(upper right part not prototyped)

Interoperability Methods are needed that enable the transformation of the data from one de-signer’s view to another, at the same time ensuring proper management of all locally made changes and of the resulting product data versions. Accordingly mapping and matching tools based on the STEP technology have already started to be developed in the ESPRIT project COMBI [Katranuschkov 1995] and continued here. In order to achieve flexibility, operational interoperability, semantic interoperability and functional interoperability must be taken into account. It is carried out partially by pre-standardization of a kernel skeleton and comple-mented by descriptive mapping procedures and additional functional mapping procedures [Katranuschkov 2000]. In comparison, STEP [ISO 1994a] is strongly based on pre-standardization and partially on descriptive mapping procedures only.

3.7 Prototype Implementation of the Environment Nine different partners from the European Union and one from Slovenia have developed a first prototype of the above described concurrent engineering environment in a three-year joint effort. Special attention was drawn to the development of machine – machine interfaces (e.g. client adapters) as well as human – machine interfaces (e.g. browsers) and application tools. The CEE is complemented by application tools, which serve for test and for demonstra-tion purposes of the CEE, because the server system of the CEE is hidden to the user by the information logistics server, which is hidden, too, as already mentioned above, by browsers and application tools. It has to be mentioned that this is also novel compared to current client-server systems and follows the paradigm of human-centred new ways of working, i.e. the ob-jectives of the IST Programme of the CEC for 1999 through 2003. There, the user should in-teract with the system solely via application tools and browsers which allow him to remain staying mentally in his world of working. This means that he is not bothered by system ad-ministration issues, server-oriented data structures, document management and other data management work, which is often structured differently from his personal view on the project.


23

Fig. 3.9 provides an overview of the implemented components according to the distribution ofther responsibility and development efforts of the partners involved in ToCEE. Be aware that Fig. 3.9 is not an architectural representation of the system, which is given in Fig. 3.5.

Conflict

Contract

Regulation

Process

Product

o-o API

SQL

Document Rel. DB

Client

Product Browser

FM

Constr. Geotech.

Simulator

Client Found. Exp.

Client (Template)

ToCEE Tool

CAD IFC

SOF

CIB / DAP

SOF

DAP

DAP

KUP

CIB

OPB

Infolog. Server

ConCad

VTT

OPB

OPB

CIB

CIB

ISE

CIB

CIB

Fig. 3.9: Implemented Components (SOF, DAP, etc. means ToCEE Partners.)

The following components of the developed CEE are implemented as prototypes:

• Information logistics server developed by CIB [Wasserfuhr 1998], which glues the sys-tem together and frees the user from system administration issues and system language;

• Document server developed by OPB based on an existing relational document server, which is used for current projects. It is extended by several functionalities and by a two-layer interface, a SQL interface and an object-oriented application programming inter-face.

• Product data server developed by CIB [Katranuschkov & Hyvärinen 1998], based on the IFC V1.5 and extended by CE functionalities;

• Process server by CIB [Wasserfuhr 1998], which combines workflow technology with project management technology;

• Regulation server developed by ISE [Turk 1998a]), which is realized as a kernel applica-tion. This means that it behaves like an application tool and can be directly attached by any application. The link between kernel application and the application tool is estab-lished via the information logistics server, such as each server as well. Therefore, from the system point of view it is a server The regulation server is a generic tool, which pro-vides construction codes and regulations taking benefits from hypertext techniques.

• Contract server developed by CIB [Scherer 1997], which represents, based on contracts, the virtual enterprise structure, i.e. roles, persons, responsibilities and authorizations;

• Conflict management server developed by CIB [Katranuschkov 2000], on which the con-flicts detected are stored and provided to the team members in virtual round table conflict resolution sessions in an organized and decision-supporting way;

Applications Clients Servers


24

• Existing CAD application, which is extended with a product model IFC interface by SOF applying the ToCEE toolkit from ConCAD. It is connected with the CEE by a client, which is developed by SOF as a template client, serving as a template for other clients.

• Foundation design expert system and a construction simulator application for geo-technical work by DAP, which is linked to the CEE by a client developed in co-operation of CIB and DAP.

• Facility management application by KUP based on an existing FM system, extended with an object-oriented interface.

• Virtual reality product model browser developed by VTT [Hemiö & Hannus 1999] which serves also as the client for the FM system.

The conceptual development of the components was also supported by BRE concerning the document server, by OTT concerning the contract server and legal issues [Ott 1998] and by GCC concerning the construction simulator.

3.8 Future Extensions

3.8.1 Extensions to Electronic Commerce

In our opinion it is the natural future step that CE will be linked to and integrated in (or vice versa) the business processes, as already mentioned above and the electronic commerce proc-esses, resulting in a global engineering network [Rethfeld 1996]. E-commerce is strongly ac-tor-oriented and less project-oriented, because the decision made to buy a certain product or to rent a certain service is a human act. Therefore e-commerce needs a paradigm shift from pro-ject-centred to actor-centred engineering IT systems. The ISTforCE project [Scherer 2000] for instance is addressing this issue. Straightforward technical solutions for instance are a kind of a technical product information system for the support of the design and the set-up of the bill of materials, as it is indicated in Fig. 3.8 by the T-PINS component. However, such a tool should not only be focused on data format issues such as XML to EXPRESS conversions [ISO 10303-28 WD 1999]) but has to include the human behaviour as a customer and there-fore should act as an intelligent advisory system supporting the designer’s cognitive work on several levels [Scherer 1997].

Several further tools for procurement, purchase, tendering, bidding and negotiations are imag-inable for the client side and corresponding tools for the supplier side [Scherer, 1998a].

For data integration, the STEP- or IFC-based building object model has to be extended with specific high-level "electronic commerce" objects in order to treat the electronic commerce process on the same semantic level as the technical and the business processes. For instance, objects around an object family budget, like project total budget, budget corridor, or engi-neer’s individual budget, are immediately imaginable .

3.8.2 Extension to a Client-Server-Agent Architecture

Several activities and services necessary for the integration and co-ordination of the different processes may be carried out by agents. As a case example for such an agent, a knowledge-based server access component was developed on an academic level [Katranuschkov & Sche-rer 1999, Den Haag] and demonstrated by a simplified test case. The goal of this agent was to provide to the user an engineering based man – machine interface with the product server and to conceal the technical object-oriented data structure based communication language from the user. In other words the knowledge-based server access agent is an intelligent agent trans-lating the engineering language into the system language and for the system response vice versa, of course. A lot of such very useful agents are feasible as well as low-level service and


25

controlling agents, which act like demons, for instance for controlling activity deadlines and reminding people. Most probably such agents will decide upon the competitiveness of CE client-server systems in the near future, because they are very visual services for the user.

For an efficient application of such agents, the co-ordination board, as suggested in Fig. 2.2, should be separated into its two basic functionalities. First, in an activity modelling and con-trolling tool for the project management and second, in a data integration component. This can be for instance an electronic co-ordination board, on which several functions can be car-ried out by agents or other artificial intelligence based tools as described in [Scherer, 1998a].

Fig. 3.10: Interaction Cycle of Activities (A) Controlled by the Project Manager and Co-

ordination Board (B) for Concurrent Engineering

As a result a clearer distinction between the activity- (or process-) oriented view and the tech-nical data view will become viewable. This is an important issue because both views are not identical as if it is implicitly assumed when applying straightforward workflow systems but they are orthogonal (Fig. 3.10). This should be considered in the modelling of the virtual en-terprise, as for instance it is suggested by [Scheer, 1998]. The straightforward application of standard workflow systems – as it is often the case in practice when EDMS are extended with workflow functionalities – implicitly assumes that both processes can be treated with in com-mon. The first ToCEE approach followed exactly this line, whereas the final prototype takes attention of this fact and to some extent already distinguishes between technical engineering data and activity related data.


26

4 Legal Issues

4.1 Objectives The demand for a paper-free design office and construction site gets presently stronger and stronger. No one is willing any more to send written letters on sheets of paper by registered mail if it needs only a click on the screen to send an e-mail via the internet. Thus already many of electronic paper-free messages are being transferred between design and construction participants, especially within large construction projects. But what happens when a slab has crashed down and only bits and bytes exist for the orders which led to the failure and not sheets of paper which have been personally signed? In such a case the problems of a paper-free construction site get obvious.

Legal issues are a key topic for practically applicable IT based CE systems, because every user must have the confidence that he can not only technically but also legally trust in the CE system. This means that all actions and all decisions he makes are formally legally valid, i.e. that they are legally binding and legally verifiable and accepted in court for any kind of dis-pute, which may arise. In all IT-projects the consideration of legal aspects is far behind the level of the achieved technical progress. Before ToCEE in most cases only technical aspects have been considered when doing IT-based work. Especially avoiding the use of written paper and instead using electronically stored files and objects is one of the key points in this area. Before it was getting into the public discussions, it had already been addressed within ToCEE. But many other legal aspects arise because of using files and electronically stored data instead of paper. This leads for instance to the following problems:

• How is it possible to extract and present evidence from the mass of electronically stored data?

• How can defects and relative responsibilities of the parties involved later be recon-structed?

• How must AEC-objects be expanded with legal elements in order to get a greater protec-tion against disputes and trials?

In the following chapters these main points of the legal workpackage in ToCEE are figured out. They are structured in the following topics:

• Legal declaration by e-documents, i.e. electronic signature for any kind of e-documents, which are e-mails, text documents, drawings and product data files.

• Legal evidence of the contents of e-documents. • Legal basis for virtual enterprises, i.e. the contractual model. • Legal requirements on AEC objects.

4.2 Establishing Legal Acts by Electronic Media – The Digital Signature

To get a paper-free software system to work concerning legal aspects, one of the essentials is to give declarations containing legal intent from one person to another. There are one-way declarations like orders from the client to the contractor. And there are also two-way declara-tions, for example, when the contractor and his sub-contractor set up their contract. Such a contract consists of the one declaration of the sub-contractor that he is willing to work, and the other declaration of the contractor that he accepts. All these are declarations of legal in-tent.


27

Until recently, say about 1997, the electronic form of declarations of legal intent seemed to pose a problem. This was because up to that time only paper-based declarations seemed to be legally accepted. But already at that time there was a strong demand for the acceptance of declarations in electronic form. The banking sector especially realized the advantages of elec-tronic declarations to and from their customers, for example for transferring money from one account to another. Banking companies have made electronically transmitted declarations of legal intent a reality already. And there have been strong efforts by some governments to make electronic declarations of legal intent legally admissible. Several laws have been passed (http://cwis.kub.nl/frw/people/koops/digsig.htm#g, Digital signature legislation). The first one in the world was in Utah (USA) in 1995. Some EU-countries have released already some laws, others will follow. The European Commission is preparing a directive on digital signa-tures which will be valid in every EU-country (www.ispo.cec.be/eif/policy). With these laws – combined with suitable contract clauses – the electronically transmitted declarations will get the same legal authority as paper-based declarations.

The basic requirement in transferring reliable electronic declarations is the "digital signature". With the type of the digital signature, the creation of a “Trusted Third Party” and some special clauses in the contracts between the building participants it is possible to create a paper-free electronic communication on building sites.

The purpose of the digital signature is to have an electronic document with protection against alteration or manipulation, and to know for sure who was the sender of the electronic docu-ment. The content of the document (like a text or the bitmap in the file) gets, with the use of a key (a particular sequence of digits) and an algorithm, encoded. It is impossible to read this new file without the encryption algorithm and the appropriately fitting key.

Single Private Key

When decoding the file in order to read the original content, the knowledge of both the key and the algorithm is necessary. The algorithm is public, but the key is secret. The key is a password or a longer sequence of digits. If the receiver knows the key, and knows that the key belongs to the individual sender, then we have – together with the public algorithm – a digital signature. Thus encryption (encoding) and decryption (decoding) is the method for a digital signature. This kind of digital signature is already practised in many cases.

To work with one secret key is only possible between clearly separated parties like banks and their customers. On a construction site for each message between the different parties one key would be necessary. The following Fig. 4.1 shows the project participants on a sample con-struction site with 5 parties.

Client

Contractor Architect Project Manager

Subcontractor

Fig. 4.1: Construction Participants Relations


28

For a reliable communication between the 5 parties many secret keys would be necessary:

• for each of the four communication lines shown in Fig. 4.1 (e.g. from client to project manager, to architect, to contractor, from contractor to subcontractor)

• and several more for all the other paths (like from project manager to architect, from cli-ent to subcontractor, etc.)

This method is called a “secret-key signature method“ http://www.digicash.com /publish/digsig,/digbig.htm. In this case the sender needs an additional key for every recipient. When using the digital signatures of more than a few people the administrative efforts for handling the keys get higher and higher, and then other encryption methods are necessary.

Single Private - Public Key

One of these other methods is the "public-keys". The encryption programme creates two keys: one is private and is stored only on the hard-disk of the sender. The other one is public, and can be looked up by anyone, e.g. by looking up in public databases. After the sender encodes his message with his private key and sends it, for example by e-mail to the receiver the latter is able to decode it with the public key of the sender which he selected from – for example – the PGP-database in the internet www.pca.dfn.de/dfnpca/pgpkserv. Thus the receiver knows that the message has been sent off by the person who owns the secret key, that is the sender. Having been encoded by the sender, the message has been digitally signed. Thus a digital sig-nature is not a handmade signature, done by a human for example with his PC-mouse. It is a calculation of a computer using a sequence of digits (the keys), created by the computer.

Double Private - Public Keys

Using only the digital signature, other people than the receiver would be able to read the mes-sage because they can easily access the public key of the sender. If the message should be kept secret, to provide that only the receiver is able to read it and nobody else, the sender has to execute an additional step. After having encoded his message with his private key he en-codes the message once more, but this time with the public key of the intended receiver. Also this public key is easily accessible by looking up in the public database. Then the sender transfers the double-encrypted message to the receiver. The receiver decodes the message twice: firstly with his private key and secondly with the public key of the sender. This proce-dure has some advantages:

• only the receiver is able to read the message, • the message has been surely sent off by the sender and not another person and • the receiver knows that the contents of the electronic message have not been altered on

the way to him. He knows that the message he received is valid from the beginning of the file to its end.

All this is an advantage of the electronically transmitted form of documents compared to pa-per-based "written" signatures and declarations. Therefore, receivers and senders who do not know each other and have not exchanged any keys are able to send encrypted messages to each other. The sender is not able to calculate the receiver’s private key by using the public key or the delivered message. He is only able to use the public key for decoding the message, but for nothing else.

This system of pairs, like the “public-key signature method” is called an asymmetric method. One key is used for encoding, the other one for decoding. This is different to symmetric methods, like secret key methods, with single keys, as described above. Symmetric methods use the same key for encoding and decoding.


29

The best known method in this field of the “public-key signature method“ is RSA, created by Rivest-Shamir-Adleman, published in 1978 (http://www.rsa.com/about/). One of the best known types of software in the area of “public-key signature method” is the programme "PGP – pretty good privacy", created by Phil Zimmermann (http://www.ifi.uio.no/pgp/). It is freeware and can be downloaded on the internet.

One problem for the sender and receiver is that both have to be sure that the public keys are really the ones that the original person has used in the original database. The solution to this problem is the trusted third party.

The main task of a trusted third party (or: trust centre) is – concerning the digital signature – to check and keep track of whether the public key is in fact the one from the sender, and not from another person. That is the problem of the „authenticity“ of the sender. To ensure that the key is authentic a party in whom both sender and receiver trust gives a certificate for the public key, and this third party also administrates the public key on its server.

Instead of "private" trusted third parties in whom individuals trust, "public" trusted third par-ties can be established by national laws, like done in Germany (http://www.iid.de/rahmen/iukdgk.html). The trusted third party needs the permission, or a licence from the government. When the trusted third party declares that a certain public key belongs to the person A one is legally „allowed“ to trust in that.

The use of digital signatures and established trusted third parties forms what is known as a "security infrastructure". This is essential for reliable electronic transfer of declarations of legal intent.

4.3 Legal Evidence out of Electronic Media Another problem when using electronic declarations and not sheets of paper for legally bind-ing instructions is the matter of legally valid evidence. When a building failure or damage to a building occurs, it is often necessary to prove who caused the damage. With a paper-written instruction this is no problem. But when only bits and bytes exist on the hard-disk of the re-ceiver the evidence is unsure. There are two problems:

• Has the e-message received the receiver? • Was the sent e-message represented in a way that the receiving person was able to read

it?

Evidence to Receive the Electronic Message

Thus a system has to be developed which allows strong evidence to be found in the case of disputes. The problem for the accusing party is how he can prove that a declaration has found his way to the receiver. This is a matter of receipt of the declaration.

At least two ways are possible:

• Either the sender gets an automatic confirmation that the message has been opened and read by the receiver or

• All electronic messages are passed via a central server where they are stored and the de-livery is monitored. This special server has to be under control of one person who is trusted by all parties, who takes care that no manipulations occur. This is another type of the before mentioned „Trusted Third Party“.

Within ToCEE the second alternative has been implemented. All electronic information passes the ILS-server, where all transactions are protocolled by date, sender and receiver.


30

Common Format for Read and Write

When talking about the transmission of electronic declarations of legal intent one important point is missing most times in the discussions: that is, the necessary common programme which sender and receiver both have to use. If for example the sender transmits a WordPer-fect.7-file and the receiver tries to read this file with Microsoft Word 7 the receiver will not succeed. Each of the files has its own different format and a conversion is not possible be-cause Microsoft Word 7 is not able to read WordPerfect 7. This has nothing to do with the digital signature but it is essential in a construction project to be able to communicate between the parties. So when transferring data it is necessary to define a common format or even a common programme in which sender and receiver write and read their messages.

For a multi-participant project, all the participating parties have to work with the same soft-ware and the same version of it or are responsible that sent messages are in a commonly ac-cepted format. This has to be set down in the contract between the parties.

4.4 Authority to Give Orders and Create or Modify Data In a IT-environment it is necessary to control the access of the project participants to the data which are stored or to be transferred. A contractor is not authorized to access the database and modify the architect’s design. This can only be done by the architect himself or by the author-ity which is above the architect, this is the client. The same problem occurs when giving or-ders: the contractor is not allowed to give orders to the architect. Only the architect or the au-thority above the architect is allowed to give those orders. This system can vary: other people may have the authority to give orders, e.g. the project manager. The CEE should free the user from any system administration work and exclude wrong use of system facilities. Therefore a methodology is necessary, which handles these accesses on data and orders. This is the ‘con-tractual model’.

The contractual structure in a construction project is generally the same. The client makes contracts with different parties like designers, contractors and vendors. The contractor himself makes further contracts with sub-contractors. This leads to a contractual structure as graphi-cally represented in Fig. 4.2:

Client


Subcontractor

Fig. 4.2: Contractual Relations

The authority to give orders to other participating parties follows the contractual relations. This means that for example, the client is allowed to give his orders to the project manager (they have a contract with each other) and to the Architect, but the client is not permitted to give orders to the sub-contractor of the contractor because these two have no contract with each other. Additional matters can easily be derived from this structure, namely the authority to give legally binding orders on a construction site to other parties.

The only way that this hierarchy of authority can change is by giving power of attorney to another party. This is done in most cases by the client, who gives his authority partially to the


31

project manager or/and the architect. With this power of attorney the project manager and the architect is able to act on behalf of the client, that means as the client is able to act. This can be described as directed relations and graphically as represented in Fig. 4.3. With the author-ity transferred by the client, the project manager is then able to give his orders for construc-tion details or for the time schedule for example, to the contractor. Without the transferred power only the client would have the power to give these orders. This scheme of authorities has to be set up once for every construction project. It can be called a “Contractual Model”. Several legal tools, i.e. tools that support legally correct actions are imaginable, such as a tool for checking the power of attorney when sending declarations from one building-participant to another.

Client


Subcontractor

Fig. 4.3: Authority Relations

The most important benefit of the contract model is that access rights to information can eas-ily be defined. The project manager in the above example is allowed to access the database and to input and read data there. He is allowed to create new AEC-objects, to change existing AEC-objects and to permanently remove older objects. But this can only be done in respect to the contractor (see Fig. 4.3), not to the sub-contractor. This authority to read and write data, and those who are permitted to access has to be defined newly for every building project. This system is able to work, even if there have to be taken into account some limitations as the project manager for example, does normally receive only partial and not complete authority from the client.

4.5 Legal Requirements on AEC Objects Today the work on construction sites is still done on the basis of line drawings on paper, which are the results of manual work or CAD programs. In future AEC-objects (STEP- or IFC-objects) instead of simple line drawings will be the working drawings for the site. The change from line drawings to objects has several consequences concerning legal issues. The most remarkable one is the „track of approval“, which should be considered in more detail in the following.

In order to control the final design of the building according to good practice every item of each building element needs the permission of one or several participants (HVAC-engineer, local authorities, architect, structural engineer, etc.) before the building element can be con-structed. Thus it is necessary to keep track of every part, or item of the building whether it was permitted, by whom, how and when. The person who has final responsibility that all di-mensions and all materials of a building are correct and approved is usually the architect or the project manager. This is the system like it is nowadays and this will be the procedure in the future, too. But this procedure can be easier handled when using AEC objects extended appropriately.


32

Approval by

Rec

ord

No.

Typ

e

leng

th [m

]

thic

knes

s [m

]

heig

ht [m

]

mat

eria

l

posi

tion

lo

wer

le

ft

corn

er [m

]

thic

knes

s of

the

rmal

in

sula

tion

[m

]

34 wall 4 25 3 concrete x=10 y=2 z=9 0.1

Loc. Authority Y Y Y Y NPN Y NPN

Architect Y Y Y Y Y Y Y

Structural Engineer Y Y Y Y Y Y Y

HVAC-Engineer Y N Y N Y Y Y

78 hole 1 empty 2 empty x=11.5 y=2 z=9.5

empty

Loc. Authority Y Y Y Y

Architect Y Y Y Y

115 window 1 0.1 2 PVC x=11.5 y=2.1 z=9.5

empty

Loc. Authority Y Y Y Y Y

Architect Y Y Y Y Y Y

HVAC-Engineer Y Y Y Y Y Y

Legend: Y = Yes, approved; No = Not approved; NPN = No Permission necessary

Table 4.1: AEC-Objects Extended for Track of Approval

It would be beneficial for all project participants to set up a system in the AEC-objects that shows which parts of the elements have been approved by whom and whether or not those persons are allowed to control the building elements. Setting up such a track of approvals leads to AEC-objects, for example, as shown in Table 4.1. In this example four different par-ties have approved the drawings which contained these elements. The architect has created the drawings initially which means that for every attribute on the line "architect" in the AEC-object where there is a Y for yes, the architect has approved. When the local authority had to approve something, their attribute fields on the AEC-object contain a Y, too. Those items which do not need an approval by the particular party are marked with a NPN (No Permission Needed). The structural engineer and the HVAC-engineer also had a look at the drawings. Those AEC-objects which had been affected by those persons when looking at the drawings are marked in the above matrix either with a Y or N, showing whether they approved or dis-approved. In the given example, the only rejection came from the HVAC-engineer and con-cerns the length and height of the wall. The reason is that he cannot accept the full dimensions of the wall because he wants a cut-out for his pipelines.

These Y’s, N’s and NPN’s are the newly created legal “track of approval” values. This system is legally essential for working in an IT-environment. Every “N”, or every field which has not been filled out by the appropriate person, should be shown up by the software to the responsi-ble person, usually the project manager or the architect, in order to support him in his moni-toring work.

The above system of approvals in AEC-objects was invented as the solution to the problem of how to control every item’s permission of the building before construction. But the use of


33

approvals in AEC-objects does more than this: it is essential for enabling a simultaneous (in this sense a concurrent) working system on a construction site and during design, too.

The future scenario may be as follows: the architect will send his "drawing" not only to the next party in the ordinary sequence but also to all other appropriate parties simultaneously. When the “drawings” with the approvals in the AEC-objects come back to the architect, every part of the AEC objects is visible, showing whether it was approved and by whom. Thus it can be automatically checked which parts of the building have not been approved yet. With this advanced technology the tasks during design and on the construction site can be over-lapped much more than it already is nowadays.

4.6 Implementation of the Legal Issues The consequences of the legal requirements on the modelling of the CEE and the implication on the various tools are described in chapters 5.2.4, 5.3 and 7.

It has to be mentioned that the legal requirements as postulated in the preceding chapters are made from an idealized view, i.e. they are maximized requirements. Opposed are constraints like scalability of the models, runtime performance, standardization trends in project data modelling and even acceptance problems from the end users. All this has to be taken into ac-count in order to end up with a pragmatic, i.e. technically realizable and marketable CEE. Especially for the extensions of the AEC object by approval attributes, additional considera-tion has been necessary before implementation, which are given in chapter 5.3.4/2.


34

5 Components of the Concurrent Engineering Environment

5.1 The Information Logistics and Workflow Management System

5.1.1 Components of the Information Logistics Layer

The Information Logistics layer of the ToCEE CEE combines

• an information flow management system which manages and and keeps track of all in-formation flow in the CEE,

• a generic STEP oriented middleware communication layer with • an advanced workflow control for distributed CAD and CAE applications and • offers a system manager for the control and project management system of the CEE

components and for the definition of additional environment functionality, based on • APIs for client and server side extensions.

Fig. 5.1: The ToCEE System Architecture

The ToCEE CEE has a multi-layered distributed system architecture. For the end-user per-spective, the user basically interacts with workflow clients to perform his tasks in the envi-ronment. Any tool or client application needed for the execution of tasks shall be invoked through the ILS layer (Fig. 5.1). The data can be distributed on several servers which offer different services. The co-ordination of concurrent access of client applications to server-side data and services is achieved by an ILS layer, which is implemented as

• a common request broker, which is a uniform gateway to access data and services for process and workflow management

• a system component management system and server plug-ins • middleware adapters for client applications, which support different existing middleware

standards like HTTP, Java RMI or CORBA, and which are located in the adapter layer.

adapter layer

Application adapter (IL toolkit, ORB,

concad)



Ex-project data

Regu- lations

project data

Product Models

Process Models

Documents

server plug-in layer

Regulation broker





information logistic layer

Common

Request

Broker

Plug-in register

Plug-ins

process wizzard

PtM Browser

SofiCAD

PAULA

CuFIMS

SoFiPLUS

SoFiSTiK

E-mail

document browser

GWM

web

Client application layer


35

Strongly connected with the ILS is the process and workflow management component, which is described in the following chapter.

5.1.2 The ToCEE Advanced Process Workflow Management System

The CEE intends to serve as a workflow framework for all participants of a construction pro-ject. Every user has one or more roles, like "Project Manager", "Architect", or "Structural En-gineer". Fig. 5.2 shows the GUI, where the roles can be instantiated for the projects by the authorized person, i.e. the client or his consultant and can be looked-up by all project partici-pants. Roles can also be added at runtime.

Fig. 5.2: Actors and Roles in the CEE

In ToCEE, the work of the members of a distributed virtual enterprise is organized in terms of worktasks, which are globally identifiable (like other objects of the environment), linked to actor roles (e.g. architect, structural engineer, etc.), required input (documents, product data), expected or delivered output (documents/views of the product model/single objects of the product model) and the time schedule of a project as shown in Fig. 3.2.

Worktasks can be grouped and defined by means of two additional levels, namely activities and workflows (Fig. 5.3):

• Workflows are one or more activities. A project consists of one or more workflows. Sev-eral workflows of the same type may be performed in one project. The workflows them-selves can be derived from generic workflow or process templates, declared by a project manager, or from predefined templates. Predefined workflow templates can be: - Messages, for internal ad-hoc communication.

- E-mails, which allow external persons to notify the actors inside the environment by standard email gateways. In this way we can embed traditional emails as special "one-step" workflows. This allows a smooth migration from existing organizational proc-esses to more advanced workflow driven ways of working.

- Conflicts, which are registered as instantiated conflicts on the Conflict Management Server.


36

• Worktasks, which consist of one or more tasks and are to be carried out by one or more persons owning one and the same role.

• Activities, which are one or more worktasks and are to be carried out by one or more persons owning different roles.

ProcessTemplate

PredefinedProcessTemplate DeclaredProcessTemplate

Workflow 1

WorkTask 11 WorkTask 1n

Conflict Message EMail

Activity 11

Workflow m ...

WorkTask m1 WorkTask mn

Activity m1

Workflow Templates

Workflows

Worktasks

Types

Hierarchy

Super-class

Sub-class

Project

Sub-class Activity Activity 1n Activity mn

Fig. 5.3: Entities of the Advanced Workflow System

During the overall work process, the process management tool continuously updates the worklists (Fig. 5.4) for the different users, which contain exactly those worktasks which are relevant for one user. The user indicates that he wants to start the execution of a task by acti-vating the according worktask on his worklist and then the system provides him with a list of all relevant documents and the corresponding tools from which he can select an appropriate tool, e.g. a CAD, a structural analysis tool or an office application or a document. When a user finishes a worktask, he assigns his results to the process management tool and the tool updates the status of all possible follow-up worktasks for other users.

Fig. 5.4: The Worklist for a User provided by the ILS client

Each worktask can take on different status during its life cycle. The status and their depend-encies are summarized in Fig. 5.5. They are in particular as follows.


37

Initially, a task is suspended or – for some exceptional cases – also ready for execution. A task is suspended, if it requires additional data to be executable (e.g. the task for calculation of loads may suspended, because data about the building geometry and the location of building elements is missing). As soon as all required input data is available, a task is as ready-ForExecution. If the actor actually starts, the internal operation fetchForUnify is performed, ensuring exclusive access to this task and changing the state to inExecution. Afterwards the actor may switch the state between inExecution and interrupted, as often as he wants. The workflow system can be configured to check, if the actor performs tasks simultaneously, and present a notice. If the task is finished, the results are linked to the task (performed by the internal operation unify) and the state becomes finished. All tasks which are not finished, can be aborted. Abortion can be performed for the workflow which includes the task.

suspended

readyFor Execution

finished

interrupted

aborted

inExecution

fetchForUnify

unify

abort

abort

abort

abort

interrupt

continue

<automatically>

Fig. 5.5: State Diagram of Worktasks

From the user’s point of view the clients which are plugged in the ILS are the gateway through which all information is trafficked. So it is obvious that it is a trivial though crucial part of the whole system where the man-machine interface just begins. In order to get a first quick view of how the system works, the following scenario may be imagined.

A usual session with the system would entail the following : Upon start of the client the user must log in and get authenticated through a user ID/password combination. The ILS client automatically retrieves the worklist for the authenticated user. The user then can choose the task he is interested in and get any associated documents. Alternatively he can upload any document relevant to his task or modify those documents, where he has the right to write, by his contributions. He can submit his finished contribution to the project, signalling termina-tion of a worktask. He can acknowledge his worktasks and define the status of his results in the legal model – binding or still not, i.e. approved or not. Worktasks display is visually en-hanced by colours to show at first glance, due, delayed or terminated worktasks as well as their time limits.

5.1.3 Advanced Project Management Services

For a dynamic set-up of workflows, activities and worktasks and their refinement on demand during runtime a tool named ProcessWizard was designed which supports project managers in the co-ordination of the actors. A process definition methodology was developed to achieve a parametric description of worktask pattern, based on workflows templates as described be-fore. Fig. 5.6 shows a screen shot of an example session with the ProcessWizard. Each task of


38

a user role is modelled as a worktask (a node in the process network) and the dependencies are represented as arrows. The main window (1) of the Process Wizard shows the worktasks. By selecting a worktask, the properties of the worktask can be modified in a separate window (2). For each worktask, the actors and roles can be specified (3) by selecting them from over-view lists which are interrelated according to the actor matrix (Fig. 5.1).

1

2

3

Fig. 5.6: Process Management Tool in the ToCEE Environment

With the ProcessWizard, work templates may be created, edited, stored and applied. Work templates can be applied. If a work template is applied, a new workflow is created. The work-tasks of this workflow are immediately available on the worklist of all involved actors. The list of all workflows can be browsed with the ProcessWizard.

A shared project calendar allows access to all time related information in a unified form of presentation. The status of tasks is displayed as a barchart, which evolves dynamically in time.

5.1.4 The ToCEE System Component Management System

The integration of the CEE as a distributed client server architecture is ensured by a formal specification of the functionality and semantic integration of the servers. This specification is called the ToCEE modelling framework. The ToCEE modelling framework formally de-scribes data structures of the data which can be stored and manipulated in the CEE. The speci-fication consists of a set of EXPRESS-C specifications. The EXPRESS-C language is an ob-ject oriented formal language for the definitions of concepts and data structures. It is an exten-sion of the EXPRESS language, which is part of the ISO Standard 10303, STEP (STandard for the Exchange of Product Data). Initially it was intended for use for the description of product data, but it is flexible enough to be applied in many other domains.

Each server-plug-in implements a disjoint subset of the global concept registry. Concepts are classes in the sense of object oriented programming, but additionally they know about their instances and they are available as objects at runtime. All components which offer permanent


39

server services for the environment are registered in the server registry. Fig. 5.7 shows an example of a server registry, visualized by the respective Information Logistics administration tool ‘server viewer’.

Fig. 5.7: Information Logistics Administration Tool ‘Server Viewer’ for the Server Registry

Currently, the adapters are based on a late binding approach, so that schema definitions can be changed at runtime, but strong type checking for the source code of the client application is not possible. First steps have been made to create an early binding, by directly compiling an EXPRESS-C specification into implementation skeletons of the target implementation lan-guage or an intermediate language independent specification layer (e.g. CORBA IDL). Fur-ther investigations will be made in accordance to ongoing standardization activities like the Java language binding in CORBA 2.2, the Java to IDL Revision Task Force of the OMG or the IDL to SDAI binding proposal of STEP, ISO 10303-Part 26.

5.1.5 The ToCEE System Communication Method

Within the ToCEE security framework, the right to execute a request is restricted to authenti-cated users, based e.g. on password analysis. Sessions are used to group a set of requests which are sent by one client subsequently. The security authentication can be controlled on session level either than on request level. A session encapsulates a sequence of communica-tion events which are performed, between the same client and server, with the same middle-ware adapter and with the same authentication scheme. The authentication of requests is based on either a login and a password or by access restriction to trusted IP -Address domains.

Each request is uniquely related to an object of a server and defines a method which shall be performed with this object. Therefore, it is named an object request. The request may include input parameters which depend on the interface definition of the method in the EXPRESS-C model. The response contains the status of the response generated by the server (ok or fail) and the output parameters.

The interoperability of the different ToCEE system components is achieved by a mechanism called UPRL (Uniform Project Resource Locator), which extends the standard WWW ad-dressing technique (Uniform Resource Locator, URL) towards co-ordinated concurrent access to shared object-oriented models (Fig. 5.8). It allows client applications to manipulate server-side documents or objects, based on a formal interface definition. They are described in STEP oriented EXPRESS-C models, which are a conservative extension of data models of the To-CEE modelling framework. Each EXPRESS-C specification has a uniquely defined subset which is an EXPRESS compliant data model. The data models can be physically distributed across several servers, based on a Server InterOperability Protocol, SIOP specification.


40

Distributed Information Space through:Uniform Project Resource Location

UPRL = URL +project semantics:

person, worktask,document, IfcObject,view, ...

==> Unique identification of objects in the environmentand description of their possible behaviour

Company 1

ToCEEEnvironment

Company 3

Company 2

UPRL

Fig. 5.8: Uniform Project Resource Locator

An UPRL is defined as:

http://<tocee-server>/<user>?<request>

The pattern <tocee-server> stands for a valid IP address of a ToCEE environment.

The pattern <user> is the login name for a user who is registered in the CEE, e.g. "miller".

The pattern <request> has a structure which is adopted to pass parameters to the CEE in a CGI like style. http://wwwcib.bau.tu-dresden.de /sphinx/miller? OID=IfcPerson.31& meth=notify& message=“hello!“

parameter valuemethod parameter.

method nameinstance IDobject class

userCEE gateway of the web server

Fig. 5.9: Example of a UPRL Request

In the existing WWW architecture, each URL request produces – as server responses – an HTML output which can be used by a WWW browser client. In the ToCEE object centred architecture, each object request produces an Information Container IC output which can be used by a client application to work with the data in an object oriented programming language like C++, Java or Oz. We first describe the structure of responses, called IC format, and then introduce a library for accessing these structures within a programming language. The objects addressable by UPRL are derived from the ToCEE modelling framework. They are decom-posed into partial models which are managed by different servers.

ICs (Fig. 3.3) consist of possibly recursively nested records, i.e. values of ICs themselves can be ICs. Records have a named label and set of features with values. The possible value types can be: Long, Real, String, Boolean and Logical are the basic types well known. Additionally, the IC syntax distinguishes between symbols and strings. Strings are alphanumeric values on the instance level and symbols are terms on class level. Strings are enclosed with double quotation marks, whereas symbols are denoted without any quotation marks. Also the labels and features


41

of records are symbols. Symbols are case-sensitive. In contrast to strings, symbols are expected to appear frequently in a data model. In a distributed environment, this allows to define hash codes for symbols on each local site. If ICs are transferred across a network, only the hash code of the IC symbols and the hash table updates have be transferred.

ICs can be used to represent the state of objects of an object oriented data model. The features are the names of the object attributes and the values are the object attribute values. The label is the name of the object class. However, ICs do not have to comply to a type schema. They can have additional ad-hoc defined attributes, which is a very flexible mechanism and allows to extend a schema at runtime. A Java library was developed which defines an API to ICs for pars-ing and printing, access to the internal structure of ICs and composition and modification of ICs. The ICs API allows to work with ICs without caring about their syntactical structure.

Further on the construct of binary large objects (BLOBs) are introduced. They can keep any type of data (e.g. complete files), for instance SPFs.

Object References are represented as records with label ‘oref’ and can be compared to the „href“ references of HTML, but instead of pointing to URLs, they represent object addresses according to the addressing schema for objects.

Aggregations can be used to express lists and sets. The elements of the aggregation are em-braced with „[„ and „]“ and accordingly the empty list is „[ ]“. Aggregations are both used to represent lists and sets. If sets are represented, the ordering is insignificant.

The SIOP is based on a generic method invocation interface, by executing a method "execMeth" on the server plug-in. A server plug-in has to implement a specified Java RMI server with the RMI interface "ServerPlugIn".The SIOP request addresses a unique object and performs a method for this object.

Example of an ToCEE system communication sequence for the "Execute Order" template. No user interactions are shown.

Step 1) Browse the template repository

Request: OID=ProcessTemplateRepository.1 & meth=getAllTemplates Response: response( responseTo:oRef("request.12") oid:“ProcessTemplateRepository.1“ status:ok templates:[ oRef(“ProcessTemplate.2“) Ref(“ProcessTemplate.3“)

oRef(“ProcessTemplate.5“) oRef(“ProcessTemplate.7“)] ) Step 2) Select a template

Request: OID= ProcessTemplate.2 & meth=view Response: response( responseTo:oRef("request.13") oid:“ProcessTemplate.2“ status:ok content:ProcessTemplate(

name:“Give order“ params:[oRef(“variable.13“) oRef(“variable.14“)] )

)

Method name is defined as operation in the EX-PRESS-C model

References to templates contained in repository #1

Parameter name is defined as operation parameter in the EXPRESS-C model

Object attributes are defined as attributes in the EXPRESS-C model


42

Step 3) Apply the selected template

Request: OID=ProcessTemplate.2 & meth=apply & activityContext=oRef(“transaction.2“)

Response: response( responseTo:oRef("request.14") oid:“ProcessTemplate.2“ status:ok transaction:oRef(“transaction.423“)) ) Step 4) Get the worktasks created after the application of the template

Request: OID= transaction.423 & meth=getOutput Response: response( responseTo:oRef("request.15") oid:“transaction.423“ status:ok output:[ oRef(“worktask.131“) oRef(“worktask.132“) ] ) Step 5) Finish the worktask

Request: OID=worktask.131 & meth=unify & value=oRef(“document.16“) Response: response( responseTo:oRef("request.16") oid:“worktask.131“ status:ok transaction:oRef(“transaction.424“))

5.1.6 The ToCEE Client Adapter Layer

The ToCEE ILS is a kind of middleware layer which enables programs to access and modify data of the environment independently of the physical distribution of the data.

The basic mechanism for communication between different distributed components of the CEE environment are requests and their responses. A component which sends the request is called the client. Each component which can accept requests is called a server. It is responsi-ble for creating the response. The terms of clients and servers are only defined for a single communication event. So the server of a communication event can be client in another com-munication event.

Communication events can be executed by adopting different existing middleware standards. Therefore, clients and servers have to use common so called middleware adapters to access the ILS (Fig. 3.4). The different technologies provided are:

• the WWW centred middleware, based on the HTTP protocol extensions [W3C99], • the Java RMI middleware [Sun98], • CORBA ORB [OMG98] and • The MOZART/Oz distributed computing environment [Moz99].

In principle, additional adapters for proprietary middleware solutions like DCOM can be in-cluded with little efforts if followed our specifications.

Activity contexts allow transaction oriented undo (rollbacks) of worktasks


43

5.1.7 Extending the ToCEE Environment

Software developers who want to extend the ToCEE platform can do extent on the client side, by accessing and processing server side objects like actors, documents or tasks. or on the server side: by developing a new Server PlugIn which extends the existing ToCEE models.

We think that the ToCEE architecture offers many exciting ways for extensions. We have initiated the ToCEE Interest Group (http://cib.bau.tu-dresden.de/tocee/TIG) to invite third party developers to participate in software development with the ToCEE platform.

5.2 Product Model Server and Data Modelling Framework for CEE

5.2.1 Objectives and Requirements

The objectives of WP Product Modelling and Interoperability has been to develop a modelling infrastructure and generic facilities to enable collaborative work in a CEE. As understood today, concurrent engineering implies collaborative, parallel product design, advanced project management, consideration of the whole product life cycle, effective communication and in-formation sharing across disciplines and phases of the product’s development and adequate consideration of responsibilities.

Building construction projects are characterized by one-of-a-kind products and one-of-a-kind project set-ups. Communication and information sharing needs are typically between different disciplines, between different organizations and between different kinds of applications. Be-cause of varying organizational modes of AEC projects and varying responsibilities of disci-plines data exchange needs may also vary from project to project. However, the current use of IT in building construction is limited primarily to computer-aided production of documents and presentations, with some support for information management using databases related to struc-tured CAD-models. In some narrow areas, like structural design of steel structures, product model applications are used to develop structural models from which working documents (drawings, bill-of-materials, etc.) are generated, but there is not much integration to other appli-cations (e.g. architectural design or structural analysis). CAD data exchange between disciplines is primarily done on the level of exchanging drawings using de facto standard formats DWG or DXF and using native tool formats for other type of documents, like specifications, schedules, bill of quantities etc. Thus, the different information needs in construction projects, such as the management of the process, product, documentation and communication flows, are still handled in a fragmented manner as individual, or at best only partially interrelated systems.

In building IT research there have been considerable efforts invested in the conceptual speci-fication and the development of integration models and services. In the late 1980s a number of researchers, e.g. [Eastman 1988], [Gielingh 1988], have introduced product data technology (PDT) in construction and have suggested it as a key approach for information exchange and sharing in A/E/C projects. Several European projects like ATLAS [Böhms & Storer 1994], CIMsteel [Watson & Crowley 1995], COMBI [Scherer & Sparacello 1996], COMBINE [Augenbroe 1995] etc. have developed prototype product modelling environments proving the validity of the approach and stimulating further research, standardization and implementation activities. In the IRMA model [Luiten et al 1993] a first attempt has been made to join prod-uct and process models for building construction in a unified modelling framework on the basis of PDT.


44

Today, with the IFC project model developed within the IAI PDT stands on the threshold of its practical implementation in integrated building construction environments.

However, what is still missing is the treatment of all information – product as well as process information, documents, users, software, hardware – as a whole consistent system for concur-rency in which interoperability and co-ordination issues are efficiently resolved. The focus was on the basic requirements and concepts for PDT from the point of view of concurrent engineering, the modelling and interoperability issues in a multi-server/client environment and the specific product data services for concurrent engineering support.

When setting up the requirements it was realized that IT support for product data management in CEE should be decomposed into a number of aspects:

• Information sharing needs, viewed from various axes: inside and between disciplines, over the life-cycle and between various representations (levels of semantics).

• Enabling methods for concurrency and communication, which would allow repeated data exchange cycles and exchange of partial product models and will compensate the lack of a fully integrated product model with concurrent access of all different disciplines.

• Responsibility and ownership of information, when in the information base there can be a number of copies of objects of different versions or objects dependent from other objects owned by other disciplines, and as it is not always possible to define a single owner re-sponsible for the information, addressing also of ownership related legal issues.

The examined end-user requirements to product data management include:

• data re-use, i.e. no redundancy of the information, • data integrity and consistency, • fast and efficient access to local data, which implies application specific modelling, • “just-in-time“ information access (by explicit querying of the common global data and/or

other agents, in order to be able to take proper actions, as well as automated notification of recognized conflicts for crucial solution parameters),

• automated assistance for conflict recognition and interactive support for conflict resolu-tion,

• possibilities for creating variant solutions.

Requirements for supporting overall project management functionality include:

• Fast access to global summarized data, like total cost (for building, building section, sub-system, construction phase etc.), which implies with respect to product modelling the ability to quickly retrieve such data from the available product information.

• Methods for monitoring status and progress of design/planning work.

Specific concurrent engineering requirements imposed to product data management beyond integration are summarized in Table 5.1.

The proposed product modelling and interoperability framework for ToCEE takes into ac-count different interoperability aspects relevant to CEE. These are:

• operational interoperability, • semantic interoperability and • functional interoperability (dynamic model management).


45

Concurrent Engineering Features Product Data Management Related Issues Collaborative work of physically distributed teams

• Distributed client-server environment

• Common product data repositories

Co-operative problem solving • Comprehensive data access and retrieval functions providing just-in-time information

Concurrency • Concurrent multi-user access to the product data repositories

• Availability of local view models allowing independent work in the individual discipline domains together with methods for ef-fective model transformations

• Change management

Efficient inter-discipline commu-nication and information sharing

• Well-defined and flexible client-server interfaces

• Comprehensive set of available server functions

• Consistent support of semantic and operational interoperability Life cycle management • Comprehensive set of harmonized data models

• Modelling representation enabling model evolution and different levels of representation detail

Consideration of responsibilities • Capturing of legal issues like contracts, order assignments, ap-provals, access rights etc.

• Appropriate linking to documents, the main holders of the legal data

Table 5.1: Concurrent engineering features and their implications to product data management

On the basis of a common layered model architecture and a set of interoperability methods and tools these aspects are considered in their mutual interrelationship, as one consistent whole.

5.2.2 Operational Interoperabiliy – ToCEE Operational Framework

From operational point of view interoperability means the ability of the system components to work together in a coherent way for the solution of complex tasks that cannot be solved by only one single system component. The concept of the operational framework of ToCEE is based on the client-server paradigm. It has a clearly distinguished layered structure as shown in Fig. 5.10.

The Client Application Layer is the basic user interface to the system. It is the layer at which the actual project activities, like working with CAD, FEA, FM programs etc. will normally take place. The Adapter Layer provides both the users and the client applications with a set of generic Internet-based access methods to all common project management services which, in turn, are organized as separate subsystems (product, process, document, conflict management) implemented as a Server Layer. Servers as well as clients are connected with the central ILS with a specially developed flexible plug-in technology described in chapter 5.1. This approach allows to develop each application or server independently, and to integrate them in a flexible and fully distributed manner, hiding from the end-user low-level communication details.


46

Fig. 5.10: CEE System Architecture of ToCEE

In this aspect of the environment, interoperability is achieved on the basis of the following principles:

1. Each application or server uses its own locally stored data which allows parallel and to high extent independent data access in accordance to each discipline-specific knowledge context.

2. In order to be integrated in the environment, each server must only register a set of global interface objects that specialize the meta model objects of the system to the common request broker (CRB), which is part of the centralized Information Logistics Services (ILS) in To-CEE. These objects contain public methods that can be accessed through remote calls by any other client or server and thus provide the basis for the inter-component communication.

3. The actual project information exchange is performed by client requests to the CRB, whose main role is to identify the correct target subsystem, and then parse, resolve and forward to it the request. Additionally, the ILS provides consistent access control and concurrent re-quest handling for all project communication.

This approach enables the PtDMS to provide services to the client applications and the other servers of the ToCEE system through the ILS. The product data maintained by the PtDMS itself are accessed by calling its public functions, which are registered on the CRB as opera-tions for product concepts known to the middleware. In this way a structured run-time envi-ronment with layered levels of data abstraction is achieved.

5.2.3 ToCEE Modelling Framework

The main goal of the model development efforts was to develop a kernel model for CE, which should be domain-independent and should serve as a bridge between the separate discipline oriented aspect models. This kernel model, which finally was split up into three hierarchical models, the meta, the kernel and the neutral model layer (see layers 1 to 3 in Fig. 3.4 and Fig. 5.11) is the common basis for information exchange and IT support for concurrent engineering, whereas the aspect models taken from IFC/IAI or STEP/ISO 10303 represent domain-specific views of product data and provide local support for the applications in the respective domain.

According to this principal approach, an important goal has been to define the layered product model structure which would support information processing at different levels of detail. This enables capturing and querying both global features representing overall characteristics of the

adapter layer

Application adapter (IL toolkit, ORB,

concad)



Ex-project data

Regu- lations

project data

Product Models

Process Models

Documents

server plug-in layer

Regulation broker





information logistic layer

Common

Request

Broker

Plug-in register

Plug-ins

process wizzard

PtM Browser

SofiCAD

PAULA

CuFIMS

SoFiPLUS

SoFiSTiK

E-mail

document browser

GWM

web

Client application layer


47

product from a certain perspective, as well as locally stored detailed attributes of the building objects. This flexibility of the representations would allow to support the information logistics services at a high level as well as to capture detailed individual properties of modelling ob-jects whenever necessary.

The principles for ToCEE’s modelling framework have been:

1. Development of a common layered object-oriented conceptual model for all relevant infor-mation in the CE environment.

2. Partitioning of the project model domains in a set of models for dealing separately with products, documents and processes, so that different types of information can be served by separate servers and the individual models do not become too complicated to be developed and maintained.

3. Partitioning of the product models according to different systemic aspects in order to facili-tate parallel and to greatest possible extent independent work in the different disciplines in-volved in a construction project.

4. Use of EXPRESS as a common modelling language, in order for the models to be aligned both with STEP and IFC, extended with specification of operations on the basis of EX-PRESS-C for all implemented schemata.

5. Use of concepts from SDAI and IFC to achieve maximum pre-harmonization of the frame-work and yet retain the layered structure and the independent domain-specific use of the models.

6. Use of advanced methods for model transformations (both on schema and data level) to tackle the interoperability problems relevant to the distributed CEE.

The scope of the product modelling framework includes:

1. An IFC based kernel model for the CEE. 2. Model support for high level product, process and agent model components for communi-

cation purposes to support the ILS, as well as for components required by the conflict man-agement methods.

3. Aspect and Application models for the separate disciplines and applications.

The architecture of the resulting ToCEE modelling framework as illustrated in Fig. 5.11 has five layers (from top to bottom):

1. The Meta model layer sets the basic principles of the whole modelling paradigm. It serves for the formal definition of all allowable basic and user-defined data types as well as for the generic definition of object classes (called “concepts” on the Meta model level), con-taining a set of attributes describing its state and a set of operations defining its behaviour.

2. The Kernel model layer defines in three schemas the high-level generic concepts, which are common to all lower level models representing Product, Document and Process related information: (1) TC_IfcKernel, the ToCEE adaptation of the IFC Kernel schema, (2) TC_Communication_Model, which contains information on the system itself and the in-formation processes in it, and (3) TC_Model_Population which has a similar purpose as the SDAI dictionary model (ISO 10303-22), but is extended to include important features for CEE meta model information.


48

TC_NPtM + Shared Elements

TC_NDM

TC_NPsM

TC_GEO

TC_IfcFM

TC_IfcARC

TC_IfcHVAC

TC_STRUCT

ARC HVAC STR GEO FM

TC_META

TC_ActorResource

TC_ApprovalResource

TC_CostResource

TC_IfcPropertyTypeRes

TC_DateTimeResource

TC_MaterialResource

TC_IfcMeasureResource

TC_IfcUtilityResource

TC_IfcGeometryResource

META MODEL

KERNEL MODEL

NEUTRAL MODELS

ASPECT MODELS

APPLICATION MODELS

RESOURCE MODELS

REFERENCE

USE

TRANSLATE

TC_IfcKernel

IMPLEMENT

TC_Population

TC_Contract

TC_Conflict

TC_Communication

TC_ShapeRepresentationRes

3

2

4

5

1

REFERENCES B/N RESOURCES NOT VISIBLE, ALSO POSSIBLE COPYING TO APPLICATION MODELS NOT SHOWN

Notes: In the ToCEE scope, only a structural and geotechnical application model are implemented. The architectural, HVAC and FM tools use directly the respective aspect models. Ifc in the model name indicates that the model is very close or identical to the resp. IFC schema.

Fig. 5.11: Overview of the ToCEE Modelling Framework

3. The neutral model layer presents the concepts for each modelling perspective, i.e. Neutral Product Model (NPtM), Neutral Document Model (NDM), Neutral Process Model (NPsM), Neutral Contract Model (Contract) and a common high-level Conflict Model (Conflict). These neutral models are implemented respectively in each data management server of the ToCEE environment.

4. The aspect model layer further specializes the Neutral Product Model (NPtM) for the se-lected domains in building construction by defining aspect models for architectural, struc-tural, HVAC and geotechnical design, as well as for facility management.

5. At last, the application model layer should contain the native models of diverse appli-cations used in CEE. In the scope of ToCEE this layer includes as practical examples a structural and a geotechnical application model.


49

In addition to these five model layers, a set of independent resources are available to all mod-els for referencing – except for the application models, which however can copy constructs that are found useful.

The international standardization work w.r.t. building product modelling has been taken into account when constructing the ToCEE modelling framework and defining the individual models. As in 1997 it became obvious that the development in this area is more rapid within the IAI than in STEP, a decision was taken to adopt the latest available IFC model version (Release 1.5 final) when defining the kernel, neutral and aspect models in ToCEE and extend this model appropriately to cope with the above given objectives and requirements.

5.2.4 Specific Issues of the Modelling Framework for CEE

Identification

Identification in CEE means much more than simply assigning unique IDs to modelling objects. The identification and addressing mechanisms play a primary role in information sharing and are the basis for the implementation of advanced interoperability functions used in model trans-formations, model matching and change management. Object identification includes not only naming, but also versioning information. Thus, each object has an identity not only in the scope of a particular model, but also globally, across models and life-cycle stages, so that it can be addressed with the help of an accessor function from any location and at any time and state.

Groupings

Each group is a type of TC_IfcObject, alike product, process or document. All these have unique identifiers including version information, as does the objectified relationship IfcRel-Groups, which assigns members to groups. In each group assignment there is a possibility to specify access rights to the members of that group, or approvals of them. Grouping can be espe-cially useful for linking product model instances to documents or assigning them to conflicts.

Views

The grouping mechanism described above is used also as a basis for relating product model data to documents. For this purpose, the TC_RelViews entity is defined in the Kernel, provid-ing a filtered version of the whole model (grouping as 'entity-level' filter and optionally speci-fied TC_Filtering as 'attribute-level' filter).

Approvals

Basically, approvals are expected to be assigned to groups of objects or whole aspect models, automatically applying to all members in a group or all entities in a model. This is assumed to be a compromise between best to work practice and data management concerning run-time performance. Attaching a complete approval list to each item, i.e. to each attribute of each AEC object, as stated from a legal point of view (chapter 4) would lead to an overkill of cur-rent hardware systems. However, since the entity TC_Approval is related to a group of ob-jects via assignment in the Kernel model, and since a group may be a TC_View, which has a filtering capability, there exists also a possibility to apply approvals on 'attribute-level' for controlling certain important or sensitive data if necessary. Approvals can also be related to each other by a TC_ApprovalRelationship object instance, e.g. there can exist one object for required, and one for requested approval. This concept is borrowed from [ISO 10303-41] and has been used in a slightly simplified form in the implementation of the change and conflict management facilities of the ToCEE environment.


50

Access Rights

In similar manner as approvals, access rights may be assigned collectively to a group of ob-jects which is assumed to be most convenient for practice. The access rights may be granted to a particular actor (person or organization), or to certain roles in a project.

Meta Model Information

This is the information about a product model stored in the product data repository of the sys-tem. It is needed in order to enable individual processing of local models for each actor to-gether with a shared product data space for co-operative work, as well as for supporting the needed model interoperability features. The use of meta model information in the PTDM server of the ToCEE environment is based on implementation of the SDAI dictionary model (ISO 10303-22) with specific extensions added to enable the operability of CEE. It contains constructs for the concept entities Model, Model Schema, Mapping and Mapping Schema. Through the meta data a model “knows” not only the entities it contains, but also who is the user who created it, which users are allowed to read/write/modify the data, is the model checked out (i.e. locked for changes), which is its up-to-date version, what mapping specifica-tions are associated to it and for which other models, what is the base reference model to be used for consistency checking etc.

5.2.5 Functional interoperability

From functional point of view interoperability means the ability to support at run-time the model and data transformations needed in the information exchange and sharing between the components of the integrated environment. Such transformations are necessary for example when changes in one local aspect (source model) have to be propagated and checked against the constraints of another local, discipline-specific aspect (target model), e.g. architectural spatial model to structural model. In the ToCEE environment this is achieved with the help of the methods model mapping, model matching, consistency checking and model merging.

Model Mapping

In principle, to achieve the semantic interoperability of the model schemata used in the envi-ronment, two complementary approaches can be applied:

(1) Model harmonization, as explained in previous section, and

(2) Model mapping, i.e. use of special specifications and methods for the transformation of the modelling objects of one schema to another.

Because of the envisioned use of numerous model schemata and respective data models in CE, data transformations are needed. All such data transformations must be based on an un-derlying specification of the equivalences of the data representations used in the different models. In the case of fully harmonized model schemata these equivalences are provided by the modelling paradigm itself leading to a blown up data model. However, since the objective is to have lean models on the higher levels of the framework, harmonization is not always possible. For such non-harmonized cases special mapping methods are needed.

Model mapping involves the conversion of one modelling representation (source) into one or more other modelling representations (target) without awareness of the context, i.e. already existing local data in the target. In the ToCEE environment, model mapping is realized in the following way:

• The mapping specifications defining the equivalences between the different data models are maintained explicitly in the PtDMS.


51

• The mapping operations are performed by using these mapping specifications, invoked through calling the server functions 'map' or 'mapTry' for the appropriate data models.

A mapping operation always creates new data. In principle, these can be a new model schema, new object classes in an existing schema and complete or partial transformations of object instances belonging to one model into object instances of another model. In ToCEE, in order to ensure the robustness of the environment, the first case will not be considered because of the serious consistency problems it might potentially cause. Each mapping operation must be able to deal with the cardinality cases 1:1, 1:N and M:N, i.e. given a source model context C’, a target model context C” and a set of mapping specifications m ∈ M, it must be able to pro-duce as appropriate any of the following relationships between the source and target objects:

1. { }Ccccmcccm kkijkikj ′′∈′′′′′′′′=′′ ∧),(|),(/ – 1:1 mapping

2. { }Ccccmccm ijij ′′∈′′′′′′′′=′′ ∧),(|),(/l – 1:N mapping

3. CandCwithmmCc

jji

′′⊆′′′⊆′′′=′′×′′∈′

lllll U ,// – M:N mapping

The third case has been considered in the implementation, through the substitution of M:N relations by sets of „objectified relationships“, resulting in only 1:1 and 1:N cardinalities.

Model Matching

The purpose of model matching is to update the context of a target model by taking into ac-count both the changes introduced through mapping a source model onto the target and the already existing data in the target. Thus, model matching is concerned basically with the con-text-dependent comparison of a new and existing versions of the target model.

Model Matching is an important technique for supporting concurrent work. It makes use of the frame-based representation paradigm implemented on the PtDMS and is strongly related to the hierarchical architecture of the modelling framework. The key idea is to use the persis-tent kernel model of the framework as a reference structure for all other modelling representa-tions by means of associating each object instance in a given context to instances of object classes defined in the kernel. Besides attributes and methods determining their behaviour, the kernel object classes on the PtDMS contain also specific rules which facilitate the matching procedure.

Here it must be noted that the matching operation will in fact only mark the changed objects, but will not perform the change commitment itself, leaving the decision for that to the user or the client application having the appropriate background knowledge. If it is desired that dif-ferent aspect models reflect simultaneously the made modifications, before committing the changes consistency checking must also be involved.

Consistency Checking

Whilst the PtDMS ensures that one individual product model is formally consistent by de-fault, in the ToCEE environment consistency checking must ensure also that the changes made in one model are consistent with the data objects and the formal constraints in one or more other aspect models. This inter-model consistency checking is a much more complicated and time-consuming procedure which is invoked internally when the PtDMS operation 'checkConsistency' is called. It can involve implicitly the consecutive execution of mapping, matching and local consistency checking for each model to be examined, as well as creating


52

of „conflict object groups“ of the found inconsistent objects which can then be passed to the CMS for further processing. All such operations are performed on temporary data sets which will either replace the previous model versions – when all conflicts are successfully resolved, or will automatically be deleted – if the proposed changes are rejected.

Much like model matching, which is in most cases closely associated with model mapping, the consistency checking operation must obviously be correlated with both other model man-agement operations – model mapping and model matching. Their interrelationships for the scope of one data model are illustrated in Fig. 5.12.

Source modeldefinition

data leveltransformations

class level

Mapping Consistencychecking

Matching

transformations

instantiation

Source modelinstantiation

New version ofthe target model

data contents

instantiation

Target modeldefinition

Exist. version ofthe target model

data contents

New target modelinstantiation

new instantiation(after mapping,matching and

consist. checking

instantiation

Other modeldefinitions

Other existingmodels in the CEE

Fig. 5.12: Interrelationships of the Functional Model and Data Transformations

Model Merging

The necessity for model merging at certain stages of the work process arises because of the adopted approach to allow the use of local models in order to facilitate independent, concur-rent work. Model merging involves: • the synchronization of all existing aspect models with and into one consistent reference

model that can be used as basis for a next project development phase, and • checking and properly updating the modelling object instances in all affected aspect

models, i.e. their version status and identification attributes. Merging is a compound operation which encompasses matching of each aspect model in pairs with the base reference model maintained at the PtDMS. To do this, it is necessary that the modelling framework is specified in such way that a base reference model exists and the mappings are clearly defined and available at run-time. This additional requirement is met in the ToCEE environment through the use of the Neutral Product Model adapted from IFC.

5.2.6 The Product Data Management Server Prototype PROMISE

The prototype realization of the PtDMS PROMISE (V. 1.0) follows closely the developed con-cepts outlined in the previous chapter. Most of the functionality of the server is generic and can be used also for other data models defined on the basis of EXPRESS. However, in order to sup-port product data management in the ToCEE environment, a set of functions have been proto-typed as well which are specific for the ToCEE modelling framework based on the IFC 1.5 final model. PROMISE can be easily configured to work with different data models, but in each spe-cific project it has to commit to the models set up for the whole environment. In the ToCEE environment these include TC_PRODUCT_MODEL and the respective architectural, struc-tural, HVAC and FM extensions as well as the application-specific models for structural analy-sis and geotechnical design.


53

The features of the server include:

• modelling support - generic access / modification functions for EXPRESS-based data models through the

server GUI - implementation of EXPRESS-C operations - schema evolution and schema mapping

• product data management support - basic functions for querying / updating product models - specific functions for the ToCEE extension of the IFC model - specific functions for access rights - STEP physical file based data exchange according to ISO 10303-21 (impl. level 2;1) - advanced knowledge-based queries and assertions - viewing the product data in different presentation forms including DXF, HTML and

tabular format • support for concurrent use of multiple models and multiple schemata • advanced interoperability functions for co-operative work in CEE, such as model map-

ping, matching, consistency checking and merging.

With focus on PROMISE the ToCEE environment architecture can be presented schemati-cally as shown on Fig. 5.13.

Client Applications PROMISE (CiB)

Legacy application: ToCEE FM

product data repository

Stand-alone Application:

ToCEE Design Front-end application

interface server PROMISE/F

Applications with embedded Internet capability: ToCEE

Construction Site

Client Adapter Actual PDM

Server

PROMISE/M PPrroo MMooTT ee

STEP

Java Internet

VR

EXPRESS

WWW Browser (with generic ILS Applet)

Infologistic

Server ILS

(Common Object Request Broker)

CRB

The link b/n PROMISE and any other component is on the basis of TCP/IP

Fig. 5.13: The PTDM Environment Architecture in ToCEE

The actual PtDMS PROMISE/M is responsible for the execution of all product data opera-tions requested by client applications through Remote Procedure Calls (RPCs). PROMISE/M is implemented in KEE/LISP/CLOS and is running on a UNIX workstation. It performs all the major functions of the system and can be used both locally, in stand-alone mode, and re-motely, in server mode.

The front-end interface server PROMISE/F is implemented in Java and can be installed on any platform supporting the JVM V.1.1 or higher. It is responsible for tackling the communi-cation with the ILS and with the remote clients. This includes parsing of requests, download-


54

ing/uploading BLOBs, such as SPFs, resolving user authorization and task priority. PROM-ISE/F supports TCP/IP, Java RMI and CORBA IDL based communication.

PROMISE/M and PROMISE/F are fully integrated, but can reside on different platforms, and their configuration is fully transparent to the clients. PROMISE/M provides in addition a GUI which is dedicated to the system administrator and a project information manager with admin-istrator privilege. For security reasons there is no way to access PROMISE/M remotely except through the front-end server PROMISE/F by using the registered public server operations on the CRB of the ILS. The communication between PROMISE/M and PROMISE/F is realized on the basis of TCP/IP sockets.

As a whole PROMISE can be accessed in two modes:

• anonymously – only for querying / retrieving product data, but with no modification rights

• by registered project actors – giving full access to read/write/modify the data according to the particular user access rights

Anonymous access is available both directly and through the ILS. Registered user access is possible only through the ILS, since the user access rights are set and maintained by the latter.

The configuration of both server components is fully parameterized and can be performed very easily by modifying the desired parameters in the respective configuration files. This includes setting up the active model and mapping schemata, the folders for storing different BLOB types, the TCP/IP ports to be used and, optionally, helper applications (currently WWW browser, text editor, general-purpose CAD system supporting DXF import, spread-sheet tool supporting SDF and CDF file import).

5.2.7 The Product Model Browser Prototype ProMoTe

The schema independent Java-based product model browser, using late-binding approach en-ables accessing variety of product data (based on different schemata) – also over the Internet. A secondary objective has been to develop a 'laptop' client/server solution for lightweight product model management.

Generic EXPRESS schema browser is provided for studying entity definitions in detail. A tree like hierarchy is used as an interface to access the definition of each entity. The user can check the inheritance path, specifications of attributes and local rules of an entity. Each schema can also be reproduced to represent the definitions stored in the schema instance (Fig. 5.14). This serves as a quality check for instantiations of the schema and also provides different views of the schema. This string can also be written out in HTML format. Moreover, Java classes corre-sponding to the EXPRESS schema elements can be generated and used for actual data browsing application.

A tree structure presentation is selected for viewing the data content of the model in the ge-neric data browser, i.e. a tool for studying the values of attributes of instances. Class names serve as titles, and the tree is structured according to the inheritance hierarchy of the entities. This provides an easy access to each individual instance as well as groups of instances. By selecting groups of items, the user can create a partial SPF containing only the given in-stances. If no items are selected the whole model is saved. A SPF can also be written in HTML format, enabling easy viewing.

If some hierarchical structure is specified in the data model, like the ifcRelContains structure for decomposition in the IFC 1.5 final schema, additional methods for showing this hierarchy can be specified. Creating lists from selected instances is also a schema dependent feature, as


55

well as creating VRML models, which ProMoTe browser can generate and which can be viewed with a virtual reality browser (VRB). As shown in Fig. 5.14.

Documents (files) can be linked to selected instances by selecting a document file and speci-fying the application, which should be launched to view it. In the current implementation the connection is stored only in a hash table. In future versions a document server will be used to keep track of the documents and their links with different objects.

The VRB can be used as an interface to product data, enabling selection of instances and trig-gering specified methods. In our case the public domain VRB Cosmo player was chosen as the GUI. VRB is embedded in a HTML file with the help of a ProMoTe VRML applet, which enables connection from VRB back to ProMoTe via a socket. Values of attributes can be viewed as well as documents linked to instances as if the instance was selected from the Pro-MoTe program itself.

Fig. 5.14: Virtual Reality Browser as an Interface to ProMoTe Product Data Browser

The ProMoTe VRML applet takes over the control of VRB, so properties of instances in the VR model can be changed. This enables turning on and off a specified instance or changing the colour of it. For example in visualization of construction schedule hiding of instances can be used to simulate construction of the building day by day. Changing the colour can be used to highlight instances, which are in a conflict, or to visualize changes in the model by showing different versions of instances in different colours.

ProMoTe can also be opened as a server to other instances of ProMoTe through the Internet. Java Remote Method Invocation (RMI) is used to provide access to the models running in the server instance of ProMoTe. In the client instance the remote model can be browsed and ma-nipulated in the same way as a local model. When the VRML model is generated from a re-mote model, the conversion is done in the server instance of ProMoTe. Only the VRML file is sent through the net, so the amount of transferred data is kept as small as possible. This model can be browsed in the VRB as if it was local.


56

5.3 Contractual Model for a CE Virtual Enterprise The legal framework of a virtual enterprise in building construction based on public laws, regulations, state of best practice and specialized by contracts to the specific project and vir-tual enterprise structure constitutes the structure of authorization, the interdependencies of the different partners, their rights, obligations and responsibilities. The legal interoperability of an IT-based environment for the virtual enterprise depends on a high degree on the extent to which these issues are incorporated in the underlying data structure and on how the instantia-tion of the legal model is supported, because it is evolutionary and dynamic in its nature. The following chapter (based on[Scherer 1997]) is focused on the legal aspects concerning access rights on product data to show the basic principle, suggest a data structure for the legal model and motivate the application of knowledge based methods for the necessary mapping from contract model to authorization space as part of an authorization information system.

5.3.1 Problem Specification

In building construction, a one-of-a-kind product is designed and manufactured by several partners forming a one-of-a-kind virtual enterprise. Therefore, for each new building a new virtual enterprise is established with new and different players and with a new business struc-ture based on new and individual contractual rules. Each partner has his specific role, which he has to fulfil. His role gives him authority and therefore different expectations of how to fulfil his role and demands from him authority, e.g. decision making in time, and gives him obligations, such as responsibility, delivery of reliable and quality-assured results in time. The roles have to be disjunctive and the union of all roles has to cover the role of the virtual enter-prise in a complete way.

This sounds self-evident but one has to keep in mind the one-of-a-kind product and the one-of-a-kind virtual enterprise, which means that every participant enters with different past ex-perience. For the main domain-specific tasks there is no misunderstanding in the expectations and willingness of the players. However, for inter-domain tasks the responsibility is often fuzzy due to the players’ individual expectations concerning their roles. Usually they have learned the most about their roles in practice, especially those parts concerning the co-operation with others. The understanding about the border lines of their roles are thus always fuzzy, because based on historical experience (Fig. 5.15).

Fig. 5.15: Responsibility Space of a Virtual Enterprise Showing the Fuzzy Boundaries of the

Individual Roles (left) and an Instantiated Structure before Adjustment (right), with Overlap-ping (Black) or Missing (White) Areas, e.g. for the Ownership of the Product Objects

Each new virtual enterprise for a new one-of-a-kind product usually result in a slightly new arrangement of the roles of the participants of the players. The legal generic model is proba-bly unchanged but the instantiated legal model, the role structure of the virtual enterprise is not. The border lines separating and adjusting the mutual roles are different and – what is most dangerous – they are often different in details, in unexpected and therefore overseen


57

details causing a lot of problems and waste of money in practice. Thus, it is vital to provide information of which rights and obligations have to be attached to everybody’s role by a kind of information system.

5.3.2 Current Practice

The roles of the players of a virtual enterprise are defined by contracts. The contractual struc-ture represents the legal framework. However, contracts are only precise in a limited way, because in contracts the role, the end result, some important intermediate results and a rough time schedule are structured by some milestones. The exact meaning is implicit in the seman-tics. From a legal point of view they may be exactly defined, but in the understanding of the acting people, they are often not. Our primary interest is on supporting the operability of the virtual enterprise as much as possible, and only secondary on the litigation afterwards. Our interest is to avoid failures beforehand.

The daily practice shows that there is no construction project without competence problems and errors. The way they are solved depends strongly on the individual human willingness of co-operation and finding a compromise instead of maximising one’s own interest. It is a well-known fact that on the construction site, and also in the virtual design office, persons give orders for which they are not authorized. Often they do it by evidence and good will. This is good practice and our laws do already consider such behaviour and legalizes it under certain circumstances. For instance, German law considers two cases of getting power of attorney without receiving it in a formal way. First, one receives power of attorney by law if one has already acted on behalf of a third person several times and if the responsible person is aware of this and has accepted it silently. It is power of attorney by tacit permission. Second, one receives also power of attorney if the responsible person is not personally aware of such an activity but should be aware according to good-business practice. It is power of attorney by apparent permission.

Authority, and also obligations usually concerning quality of the product, deadlines for finish-ing or intermediate steps due to co-ordination are often refined upon during the production process in an ad hoc manner. Decisions are sometimes made without the authorized persons involved and their agreement is asked for afterwards. Such good practice is a must to handle the incompleteness of the design and the construction preparation resulting from the short design and preparation time for a one-of-a-kind product to be produced for an acceptable price and the limited capability of human beings to overlook complex structures in every de-tail in advance. All in all, a contractual framework has to be a compromise of legal require-ments, human capability and physiology, because at the end all participants first of all has to show their highest modification in order to come up with the best end product possible.

5.3.3 Envisaged Improvements through an IT-Based Virtual Enterprise

Several of the drawbacks of current practice may be overcome by methods, which get oper-able due to IT techniques or by novel methods from IT. One problem which can be tackled is due to the non-evident common understanding of the partition of the authorization space due to the role structure of the particular virtual enterprise. It is a problem of availability of the right information at the right time in the demanded level of detail.

In fact, human actors have an understanding of their responsibility and authorization space and of course of their obligations concerning the border lines mainly from experience, i.e. past cases, which are different for different persons, of course. Ideally, every partner would learn in advance, for each new set up of a one-of-a-kind virtual enterprise, what is his authorization space and those parts from the other partners’ authorization spaces, which he should know in


58

order to know who is responsible or can be impacted by his contribution to the product and modifications during design and re-design phases. Such a global learning in advance is not human like. Humans prefer and are willing to learn when they need to, i.e. to learn selectively focused only on necessary topics. Simply to act in an economic way. This can and should be supported by an authorization information system, because such an information system would allow to focus on the new, different parts of the authorization structure.

The authorization information system is to be based on the contractual framework of the virtual enterprise from which the role structure and the interdependencies of the roles, i.e. the role net-work, can be determined (see Fig. 5.16). The authorization structure concerning the players can be set up at the start of the project, but it will then lack the information about the authorized individual persons, the product entities and the activities on which authorization is given. Such a system would be only a contract archiving system which may be implemented with a browser to view the contractual structure, i.e. it would be merely an advanced document management sys-tem for contract documents.

Fig. 5.16: From the Contractual Network to the Space of Responsibilities

What would be an important add-on is the mapping from the contractual structure to the au-thorization space concerning product entities in design and manufacturing, concerning activi-ties, concerning orders and concerning approvals. Such mapping means the application of enterprise knowledge, which is related to the kind of product and the kind of the contractual structure. In the next chapter, an according data model is suggested which can enable these mapping procedures.

CONTRACTS

define

Know- ledge about roles

R O L E S

with

1. Hierarchy of authority of contractors to give orders

2. Network of role dependencies

3. Space of responsibility

C4 C5 C3

. . . . . .

C1

C7 C6

C2

R4 R3

R2 R1


59

5.3.4 The Data Model for Authorization

Authorization concerning product data is known as access rights from the point of view of a data base management system. In TOCEE we suggest, as a basic modelling principle, to at-tach such access information to groups of objects and not to attributes directly. However, a group can consist of a single attribute only when applying the filtering capability at TC_View.

The aspects of legal relevance incorporated in the suggested environment include the explicit formal representation of:

- the actors in a construction project

- the roles of these actors in the project processes

- their access rights to the project information maintained by the system

- the contractual agreements

- the rights to give orders to other actors

- the approval rights and obligations for the developed technical solutions

- the collection of product and process data into groups to which legally relevant information can be attached.

These concepts are strictly related to the technical project information. They are incorporated in the overall modelling framework as follows:

Actors, roles, access rights etc. are defined as generic resources. Each such resource object is defined within a self-contained resource schema, which can be referenced by any of the mod-els in the framework, but can itself only reference other resource schemata. Resource objects can be instantiated only by attaching them to instances of the “primary“ modelling objects defined in the kernel, neutral, aspect or application model layers. They do not exist independ-ently and can be referenced only through the modelling objects to which they are linked. Thus, they are used to provide additional information to the “primary“ modelling object in-stances generated in a project.

In contrast, contracts and groups are concepts that play an essential role for the proper support of the legal requirement and are therefore specified and included in the kernel model layer, which defines the high-level generic concepts, common to all lower level models representing product, process and document related information.

Specifically, in ToCEE actors and roles are defined in the TC_IfcActorRes schema adopted from the IFC project model, approvals are defined in the TC_ApprovalRes schema, access rights are defined in the modified IFC-schema TC_modIfcIdentRes, groups are defined in the TC_KERNEL schema based on the IFC kernel specification, and contracts and orders are defined in the newly developed TC_Neutral_Contract_Model schema. The characteristics and inter-relationships of these concepts are explained from three different perspectives, repre-sented in three different views on the data model.

1. ‘High Level Grouping’ object structure view In the grouping concept (Fig. 5.17) each object class is a specialization of the abstract entity TC_IfcRoot and thus has always a unique identification, including the object’s ID and ver-sion. TC_IfcRoot is sub-structured into TC_IfcObject, TC_IfcAttribution, and TC_IfcTypeDefinition and TC_IfcRelationship, which are used to define and relate to each other the principal object categories that can be treated in the system (tangible objects, objec-tified relationships, attribution sets and generic, library-like object type definitions). Up to here, this general kernel model structure follows quite closely the IFC project model (IFC,


60

1997). TC_IfcObject is then further specialized into project, contract, process, product, docu-ment and group entities. TC_IfcRelationship is specialized further into TC_Relationship1toN and that into TC_IfcRelGroups.

Fig. 5.17: View of the ‘High level-Grouping’ Object Structure

The abstract object class TC_IfcGroup allows the dynamic collection and identification of object groups at run-time (independent of their position in the classification hierarchy). TC_IfcRelGroups is used to uniquely link a TC_IfcGroup object to the objects that are the members of the group. The objectified relationship TC_IfcRelGroups captures several addi-tional properties of the grouping concept, including the important aspects of access rights, which are directly related to the legal authorization of the information usage. The TC_AccessAssignment object allows to attach to each group individual rights for each actor to read, write, modify the entities included in the group. Such rights can be given both to indi-vidual actors, to organizations, or, generically, to their roles in the project (architectural, struc-tural, HVAC etc.). With the ‘Access Assignment’ object we model both the time variance of the access rights due to different project phases and the ad hoc changes and adjustments to a new situation, for instance due to an accidental impact or inability of a partner to fulfil his tasks. Thus, the required co-operation and the allowed sharing of information can be con-trolled at each stage of a project.

TC_ObjectID (ABS)

TC_IfcRoot

1

1

1

1

TC_IfcTypeDefinition (ABS) TC_IfcObject

(ABS) TC_IfcAttribution

(ABS) TC_Document

(ABS) TC_IfcProduct

TC_Contract

TC_IfcProject

TC_IfcRelGroups

TC_IfcGroup

(ABS) TC_IfcProcess

(ABS) TC_IfcRelationship

(ABS) TC_IfcRelationship1toN

TC_IfcAccessRight

Note: The meaning of the used entity prefices in all schemata is as follows: TC_ = new, ToCEE specific entities TC_Ifc = entities that are adapted from the IFC draft spec. v.1.5 (IFC,1997)

accessRights L[1:?]

AccessInProcesses L[1:?]

accesses S[1:?]

(INV) GroupedBy S[0:1]

(RT) RelatingObject

RelatedObjects L [1:?]

RelatingObject

*ObjectID

TC_AccessAssignment


61

In principle, there exist situations in which access right information has to be assigned to indi-vidual objects or even to individual attributes. However, in a real construction project such in-formation will be typically assigned to a high-level “composite” object, such as “a building”, “a building section”, “a building storey” etc., presuming implicitly that it applies also to all ele-ments contained in it. By collecting such elements in groups, this information is made explicit and allows to define and maintain formally the required approval rights. If in some special case it is desired that access rights and approvals are assigned to an individual object, this can be done by creating a group containing only that single object and then assigning the required rights to this group. Thus, with this general grouping mechanism, a flexible attachment of ac-cess rights and approvals on technical level can be achieved in the desired granularity.

2. ‘Contract-Actor-Role-Access’ object structure view Contract is a concept which does not appear in the IFC project model and is only outlined as a generic resource in STEP [ISO 10303-41]

1

(ABS) TC_IfcObject

(ABS) TC_Document

TC_Contract

TC_IfcAccessRight

Subcontracts S[0:?]

Orderer

Subject S[1:?]

OrderSpec S[1:?]

RelatedActors L[1:?]

Clients L[1:?]

TC_IfcProject

Contractors L [1:?]

TC_IfcActorSelect

TC_OrderAssignment

PartOfProject

TC_IfcSubjectSelect

Subject S[1:?]

(ABS) TC_IfcProduct

(ABS) TC_IfcProcess

TC_IfcGroup

accessRights L[1:?]

Fig. 5.18: View of the ‘Contract-Actor-Access’ Object Structure

In order to be able to capture the contractual data and relate them consistently to the respec-tive evolving technical solutions, we have included contract related concepts at the neutral model level. This allows to treat contracts as independent modelling objects, to reference con-tract related information directly and to capture the dependencies between contractual agree-ments and the actual developed technical solutions.


62

Fig.5.18 shows the high-level objects of the neutral model level with focus on the TC_Contract and the TC_Access_Rights entities. With the help of TC_Contract important information aspects which are directly relevant for the technical solutions and which are con-tained only verbally in a written contract can be defined formally and maintained explicitly in the system.

The object TC_Contract has the following properties:

- is part of a construction project

- relates the contract parties (link to TC_IfcActorSelect)

- gives the contract a subject, which can be a single process, product or group entity or a set of such objects

- relates a contract to a set of allowable order assignments and access rights.

‘Order Assignment’ provides the capability to represent the rights of one actor to delegate tasks to other actors and give him/her authority to resolve conflict situations. ‘Access Right’ allows to define strictly the possible accesses to the shareable project information.

TC_IfcOrganisation

TC_IfcActorRole

TC_IfcAccessRight

TC_IfcActorSelect

TC_AccessRightEnum

ThePerson

TheOrganisation

Roles L[1:?]

grantedTo S[1:?]

RightsAssigned S[1:?]

TC_AccessSelect

TC_IfcPersonAndOrganisation TC_IfcPerson

Roles L[1:?]

TC_IfcRoleEnum

STRING

Name

Description

Fig. 5.19:View of the ‘Role-Actor-Access’ Object Structure

In the suggested data structure the object ‘Role’ is not directly related to the object ‘Contract’, as it can be seen in Fig. 5.19, because ‘Roles’ are not explicitly stated in the contract.

The intention here has been to model first the foreground information as it appears in the con-tractual documents of current practice, and second, the underlying background information for the known roles in a construction project (architect, structural engineer, HVAC etc.) on the


63

basis of engineering knowledge and the prescriptions in the building codes and regulations. For the latter, however, a specialized authorization management tool is needed.

5.3.5 Instantiation of Access Rights

Without a procedure as outline in Fig. 5.16, there are in principle two possibilities to instanti-ate the access rights – first according to the ‘first come – first served’ principle, and second, according to pre-given cases.

The ‘first come – first served’ principle means that this partner owns the object and has writ-ing access who first instantiates the object, whereas the others have only reading access. This can only be applied to some extent to the design phase.

The pre-given case method means that the access rights are instantiated by default values, which are taken from a case base, where the contract – role – access rights structure is stored for characteristic case projects. The selection criterion is the measure of similarity between the actual contract structure and the stored case.

Both are however only start-up instantiations. Refinement and modifications are necessary which have to be carried out by an authorized person, the investor (contractor C1 in Fig. 5.16) or to whom he has delegated his rights in the authorization hierarchy. For instance, when set-ting up the contracts for the design, technical data can only be specified in a very general way, since at that stage most technical details are yet unknown. A contract can, e.g. be linked to a high-level product object, such as the whole building, the site, a building storey etc., or a high-level process object, such as foundation design, geotechnical site preparation work, ma-sonry work etc., before the detailed elements contained in such objects are known. These set up contractual rights can be used at run-time to determine what additional order assignments are legally possible to be defined. Such an evolution of access rights should only be done semi-automatically. It has to be monitored and controlled by an authorized person. This means that an assistant-like expert system would be necessary which a) uses the knowledge about roles to generate the role network of dependencies and the space of responsibility in a time-dependent way and b) provides a powerful user interface in order to allow the explicit control by an authorized person.

Therefore, the authorization information system should serve two purposes. First, it has to assist the project manager to set up, monitor, control, refine and modify the authorization structure, and second, it must provide fast and transparent information about the current state of the authorization space to each of the partners of the virtual enterprise. Such formalized information is also of utmost importance for the conflict management.

5.4 Conflict Management System


In construction, project co-ordination will usually not require co-ordinated and consistent ver-sions of all data models at all times. In fact, such co-ordination may even be counter-productive because it can slow down the overall process and would considerably restrict the individual freedom, and thus the creativity of each project actor. Co-ordination of all models is normally required only at certain points, whilst partial process threads develop individually and only partially co-ordinated with each other. Fig. 5.20 shows schematically the principle of this kind of working and the related required product data management services. The co-ordination points are called round table meeting.


64

Fig. 5.20: Use of the Product Data Management Functions for Project Co-ordination

This kind of temporarily independent, parallel working for a virtual team requires the follow-ing services:

• Support from the system to automatically detect conflicts, • Support from the system for the user to detect conflicts, • Protocolling of detected conflicts, • Detection of related sub-conflicts, • Priority of conflicts, • Responsible actors, • Notification of actors about conflicts, • Inspection of registered conflicts, • Overview of open conflicts, • Communication about conflicts, • Co-ordination of conflict resolution process, • Status of conflicts solution process.

These services can be classified to two phases of conflict management concerning the virtual team:

• Passive conflict management, i.e. detection protocolling and notification to which the first seven services belong.

• Active conflict management, i.e. co-ordination of the conflict resolution process to which the latter five services belong.

The conflict which arises in a CEE with temporarily independent, parallel working can be classified as follows:


65

1. Parallel access conflicts This problem is well-known from data base, when one actors reads the data and meanwhile the data is changed by another actor. This implies the read data is no longer up-to-date.

2. Distributed data conflicts Because of the structured product model with different aspect model one object may be rep-resented in more than one aspect model. The change of an object in one aspect model has to be incorporated in the other aspect models, where this object is also represented, as well.

3. Legal conflicts Access rights are defined for every object allowing changes only by the appropriate actor. Therefore it may be possible that an actor tries to change some data where he has no rights to do so by contract.

4. Equal partner conflicts There may be situations where two or more partners can not agree on a common resolution of a conflict, because they do not have a contract which each other. By using a contract model it will be possible to reason about the actor who has the power to make a final deci-sion.

5.4.2 Conflict Management Framework and Architecture

Several of the services are already partially or fully supported by the inherent functionality of the ILS and PtDMS. There are for instance:

• Automatic detection of conflicts • Detection of sub-conflicts from the mapping, matching and consistency checking functions of the PtDMS.

• Notification • Communication • Co-ordination from the ILS.

• Inspection from the ProMoTe browser.

Therefore, in ToCEE only some complementary components, methods and data structures need to realize a conflict management framework. These are: • Conflict management server to protocol und manage the status of conflicts • Conflict object schema • Grouping of conflict objects • Approval object to control the conflict resolution process.

The system architecture for the conflict management framework is given in Fig. 5.21.There, the central component is again the ILS, which has to organize the interaction and information flow between the actors (via the clients), the CMS, the PtDMS and the PsDMS. The conflict data base contains

• The conflict objects, which are grouped together in conflict object groups, either organ-ized by topology, functionality or actor-dependency.

• The approvals, i.e. the approval status for each conflict object group per involved actor. • Actor information concerning role and responsibility.

A conflict object groups together all the information which is important for the resolution of a conflict. Besides an identification it contains a verbal description of the conflict, references to


66

the old and new (requested for changed to) version of the same Product Object group and the current status of the conflict.

Fig. 5.21: Architecture of the Conflict Management System

A conflict is a logical data structure stating that something is wrong in the system. It contains the following attributes:

• raisedBy the actor raising the conflict and adding it to the data base • createdAt the date when the conflict is added to the data base • relatedDocument the document where the conflict detected • relatedObjects the objects related with the conflict description

the verbal description of the conflict • priority importance of the conflict; it can be:

low, medium, or high • responsible the actor responsible for the solution of the conflict;

determined by the contract model • executingActor the actor solving the conflict; this can be:

the responsible actor, the raising actor, or an actor determined by the responsible actor

• approvals the actors which have to approve the solution of the conflict. • parent the superordinated conflict • status the status of the conflict; possible values are:

open, ignored, suspended, inExecution, or solved • solvedBy worktasks for the solution of the conflict

Conflict Database

Conflict Control

Conflict Management Server

Process Management Server

Information Logistics Server

Product Management Server

Client 1

Client 2

Client 3


67

A conflict can be done in one of the five states (Fig. 5.22).

open

suspended

solved

inExecution

ignored Fig. 5.23: State Transition of the Conflict

The states have the following meanings:

- open The conflict is created and can be edited.

- suspended The conflict is actually not operated in a worktask.

- inExecution The conflict is actually operated by at least one worktask.

- solved The conflict is solved, that means all approvals have stated their consent or that they are not competent. All subordinated conflicts are also solved or ignored.

- ignored The conflict and its subordinated conflicts are also solved or ignored

During the conflict resolution the dependencies between the conflict groups will be stored in a conflict tree. The conflict tree is used to monitor the sub-conflicts, which need to be resolved before the primary conflict can be resolved. The conflict tree may actually represent a graph of conflicting product data objects, because there will be interrelations and interdependencies between the sub-conflicts. Fig. 5.24 shows an example of a conflict tree.

For the approval information a self-standing object is chosen and not an attribute to each AEC object as suggested in chapter 4. The benefits are a more powerful information structure and less amount of data needed. An approval object contains as attributes: actors, conflicts, priori-ties, status.

The conflict management is an interaction between the information inherent in the concepts:

• Approval, • Conflict, • Contract, • Worktask.

The conflict resolution process has to be triggered by one of the actors, usually the actor who is indicated to be responsible for the solution of the conflict. The triggering can be done at any time but should be done preferably at the agreed co-ordination points in order to minimize communication time in the virtual team. The conflict resolution process is nothing else than a newly set-up workflow as described in chapter 5.1.


68

Conflict C3 Raised by HVAC

ARCH

Conflict C1 Raised by ARCH

SE HVAC FEXP

Conflict C4 Raised by FEXP

SE

Conflict C2 Raised by SE

FEXP

Conflict C5 Raised by ARCH

SE

Fig. 5.24: Conflict Tree

5.4.3 Implementation

The conflict data base is implemented in the object-oriented data base management system ObjectStore PSE for JAVA. The conflict control component is realized as a JAVA applet. For the user, the following methods are provided:

1. for the manipulation: add instance, delete all instances, update, update feature, delete, delete feature, and methods for the state change,

2. for the request: view, get instances, get number of instances.

Fig. 5.25: Conflict User Interface: Applet Conflict Edit


69

The user interface is one applet, named ConflictEdit to create and edit conflicts. It can be ac-tivated under the control of a web browser (see Fig. 5.25).

Conflicts can be inspected with the ProMoTe browser (see chapter 5.2.7). When creating the VR-model, product model is downloaded from the PtDMS and conflict instances are requested from the CMS. Among other attributes conflict instance contains a description of the conflict and a list of instance IDs related to it. ProMoTe compares the IDs of each visualised instance to the IDs in this list. If an ID of the visualised instance is found from the list, the ID is saved in a list containing the IDs defined in this conflict that are visualised in generated VRML-file. Con-tent of this list is transferred to ProMoTe-applet as a parameter in generated HTML-file. For each instance of conflict there is a parameter for the description of the conflict and one parame-ter for each ID of the instance related to this conflict. When creating the VRML-file multiple models can be selected. Created VR-model contains selected instances of specified models. In the ProMoTe-applet the user can switch between the models and also show them at the same time. By selecting an instance from the model, it is also possible to switch between the versions of that specific instance. ProMoTe-applet contains a choice list that can be used to select the conflict to be visualised. Instances in the VR-model that are defined in the selected conflict change their colour to user specified conflict-colour.

5.5 Document Server

5.5.1 Requirements

The Document Management System (DMS) is based on the requirements summarised in Fig. 5.26.

Fig. 5.26: Requirements for the DMS

The networking requirements are:

• accessibility to an Intranet by PPTP • the Internet linking should be kept to a minimum to save costs

Requirements

• registration and administration of all project documents during processing

• access to all common data format by browser

• integration of required software for viewing and processing

• specify links to dependent projects and documents

• control protocol of data flow and existing versions

• variable and expandable data structure

• user friendly tools to generate lists and documents

• Control of legal status and access rights

• common data system (SQL)

• data communication

• Handle interlocking XREFs and plot paperwork

• Interpret documents in lists and files

• manage archives of old documents


70

• storage of common documents will be checked at regular intervals • identify transfer events • have automatic document retrieval with read only capability • transfer urgently needed documents via the Internet or direct ISDN connections. The DMS shall operate as a client-server system and on the assumption of one server per or-ganisation. The servers are to be connected by Internet or ISDN with one server handling data and E-mail transactions.

A high administration functionality will be achieved by:

• being independent of document type • flexibility i.e. variable and expandable structure • being adaptable to all common data structures • able to accept differentiated and hierarchical user logging on.

5.5.2 Document Server System

The DMS developed at OPB for the ToCEE project exists fundamentally of 3 components:

• the network which provides for the connection, • the Server which provides the data and • the Client who connects to the Server.

DMS is based on the Inter- and Intranet standards as it uses the TCP/IP protocol and HTTP. Thus it is possible to use both an Internet or Intranet system, or a combination of the two.

• The DMS comprises four Server components which interact with each other through the CGI (Common Gateway Interface)-Interface of the WWW-Server (Fig. 5.27).

Fig. 5.27: DMS Components

The components are: • WWW

dms.opb.de

CGI

WWW DB

File Java


71

• Database • Java Interface

File-system The Web-Server has the following tasks:

• To take in all the requests (UPRL's) of the Client • Transmit these to the CGI • Manage the correct transmission to the corresponding instances (in Java) • To take in the results of the instances • Return these results to the Client to process

The documents are structured according to the classification schema given in Fig. 5.28. All information about a document is stored in the DMS. Each attribute of a document is registered in indices. Since each project can own different attributes of a document the data is stored in a project specific manner. The database performs the following tasks:

• [Takes the UPRL from the Client via the Web-Server] • [Takes it to the CGI-Interface] • Take in the SQL statements from the CGI interface • Evaluate them • Pass the results back to the CGI-Interface • [CGI provides a standardised response] • [Web-Server delivers the results to the Client]

title block B

sheet note

memo- randum

common used

attributes

specific document. attributes

(attribute set)

document file

additional files

document

Structure elements

document- category

letter AutoCAD-

drawing

document- type DWG DOC DOC TXT PPT

kind of document

special standard

PPT TXT MEMO2

MEMO1 attribute-

set title block A

Fig. 5.28: Classification Structure for Documents


72

Fundamentally the Java component is used to evaluate the UPRL from the Client to generate the queries to the database, to evaluate the data returned by the database, and to send a re-sponse EXPRESS-C format to the Client. This interface also manages the transfer of the files to and from the Server. The Java-Interface performs the following tasks:

• [Takes the UPRL from the Client via the Web-Server] • [Takes it to the CGI-Interface] • Evaluate the UPRL • Prepare the SQL-Statements • Connect to the data base • Convert the results from the data base to Express-C • Connecting to the local Filesystem • Take in or check out data from the local Filesystem • Forward the data to the CGI • [CGI provides a standardised response] • [Web-Server delivers the results to the Client]

The Fileserver stores the documents in a separate structure as given in Fig. 5.29. In the data-base information about the path of the documents are stored, so that access to the correct document can be guaranteed any time. The Java interface is directly connected with the File-system of the Fileserver. This interface also up- and downloads the documents from the File-system. If a Internet Browser (JVM) is used as a Client then the security features must be sus-pended so that access to the local Filesystem is guaranteed. The fileserver has the following tasks:

• [Takes the UPRL from the Client via the Web-Server] • [Takes it to the CGI-Interface] • [The Java-Interface connects to the Fileserver] • The Operating-System submits the document to the Java-Interface • The Operating-System takes the document from the Java-Interface • [The Java-Interface transmits the success or an error to the CGI] • [CGI provides a standardised response] • [Web-Server delivers the results to the Client]

Fig. 5.29: Organisation of Document Storage

kind of docs document type document type directory-knots

type 3 type 2

type 1

type 1 type 1

type 1

type 2 type 2

type 2 document

types- contained

files stored

other assigned files document-

file


73

5.5.3 DMS Client

It is possible that any kind of application which has an HTTP connection can work as a client. In principle the communication between client and a server are requests and a responses fol-lowing the ToCEE specification given in chapter 5.1.

Fig. 5.30: DMS Client as JVM browser or HTTP application

The request from the Browser to the Server is composed of an UPRL and the response is composed in EXPRESS-C. The client application must ensure that its requests are created as correct UPRL for the server and also the client application must ensure that the response from the server is evaluated correctly. The exact descriptions of requests (UPRL) and responses (EXPRESS-C) are described under http://dms.opb.de/dmsdoc.

Fig. 5.31: GUI of the DMS client

Client

Browser

JVM File

To the WWW

Client

Application with HTTP-

Interface (Java)

File

To the WWW


74

The client is based on a Java-capable browser. It is available both on the Internet as well as on the Intranet and guarantees a transparent data exchange between the inhouse staff members and ex-ternal partners connected on the Internet. As part of this client a securely configured firewall pro-tects the LAN from non-authorized access. The GUI makes it simple to navigate in the DMS-Tree.

The client supports:

• Download Documents • Upload Documents • Search for Documents • Look at the Attributes of Documents • View Documents directly in the Browser

Fig. 5.32: Search window of the DMS client

Various search specifications allows to look up for particular documents in the DMS. The search menu opens an additional window in which one can enter the specifications for the search. In the “Project” panel one can select one or several projects on the DMS to look for documents. One can choose only projects, which has been selected at “Login”. In the “Keys” panel all attributes allowed for the selection are indicated for the projects indicated in the DMS at “Login”. By activating the buttons one defines the search terms. In the “Document” panel are additional fields about the document. By activating the buttons one defines the search term. After pressing the [Search] button a query is passed to the DSM. The result is shown in the DMS tree. This shows only the documents which corresponds to the search re-quest. After the search the [Unsel. Tree] becomes active. By pressing this button the selection is cleared and the signal in the “Menu”-Panel indicates unselected and all the documents in the DMS tree are presented on the tree.

5.5.4 Overview on the basic functionality of the DMS

During a project the documents are permanently changed. A new version is indicated by the actual date, which stores the index. This procedure can be used to define a criterion for ar-chiving documents in order to remove old version from the actual status. This way the docu-


75

ments are separated in actual and archived documents, no documents are deleted. Archiving is done automatically. A property of an archive is that normally no document can be fetched back into the actual process. Only the administrator is allowed to get documents back from archive to actual. In order to record the workflow all meta data are copied in history tables. From there one can get information like which users work on the document, which reasons have caused the changes, time and duration of modifications, which of the attributes have been changed.

The system is developed to process all document types. All documents means that there are documents both with known and with unknown attribute sets. Documents with assigned at-tribute sets can be immediately handled properly in the DMS. Unknown attribute sets can be defined later in order to obtain full system functionality. The DMS can manage also different kind of documents, which are related to other documents with specific assignments.

• Sets of documents are marked by name to compound documents in order to organize documents in a special way. Documents can be members of several sets as well. Docu-ment sets are defined, frozen, deleted, etc.

• Views of documents are documents with the same content but prepared differently, e.g. documents written in different languages.

• Referenced documents are a set of documents which are referenced by a specified docu-ment to cooperate with it, e.g. Xrefs in drawings.

• Referring documents are a set of documents which refer to a specified document • Accumulation, the document file and some assigned files together create a document

consisting of several files.

To manage the data in the system there are some functions to

• install the structure, • initialise definitions, • handle archiving and versions, • organize modifying and history, • administer storing.

The definition values serve as a description and controlling of the system behavior, depending on the requirements requested by the projects. There are definitions to

• control inserts, updates, ... of documents, • define archive methods, • define modify methods, • define document relations, • define checking methods, • define document types, • define procedures, etc.

As soon as documents are put in the DMS some activities are started, e.g.

• input checking, • value checking, • insert specific attributes, • define a time stamp, • managing access rights, • define document relations, • manage modifying, archiving and storing.


76

Using the GUI or the special interface the user is able to get information about documents and the document itself. Information and documents are available by using functions managing

• general document handling, • revisions, • status, • validation.

5.6 Regulation Server

5.6.1 Requirements and Objectives

The approach taken for regulation handling is novel in two ways: (1) In the numerous comput-erization efforts to date, the regulations were considered to be sources of knowledge and infor-mation. The researchers have been trying to encode this knowledge into computer programs. We claim that knowledge can only be achieved with the correct interpretation of the regulations that cannot be achieved by a computer. We are therefore focusing on a joint-cognitive environ-ment that assists in human interpretation of the codes. (2) We do not believe in a single best representation of the regulations but suggest a framework where different representation can be abstracted as components and accessed through a central regulation broker. The regulation-processing framework is based on multiple regulation agents, brokers and servers that provide various regulation related services which include the delivery of passive hypertext and of active components that contain some of the logic embedded in the regulations.

Similar to client's requirements, building regulations (i.e. building code, standard or bylaw) provide constraints on the designs developed during a construction product. In an engineering environment, the regulations represent reference information that is not project- or company-specific, but is in a sense global (see Fig. 3.5). In a networked environment, such as the Inter-net or the World Wide Web, several publishers make the regulations available. These include authorities, professional associations and standardization bodies. They use different represen-tation approaches. Some may provide passive and some active representations. The regula-tions are used by engineers whose workstations are connected to the Web. They use design software and either the engineers manually or the design software would occasionally require information from the regulations, e.g. to check the design against the codes or to interactively restrict the options offered by the design software. To do so, they should be able to find regu-lation services, learn about the services that they offer, establish communication and finally use the services provided.

The research of the computerization of regulation processing has a long history and has been quite extensive. Commercially successful were two kinds of solutions. (1) The text or hyper-text solutions, where information technology was used to find, extract and deliver the text of the regulation and assist in the navigation of the regulations, and (2) the embedded systems, where some provisions of the regulations were embedded into CAD programs, from standard line types and dimensioning symbols, to automatic generation of loading or proportioning of certain structural elements. Systems that were attempting to provide stand-alone computable representations of the building codes that would be used by different CAD systems were less successful. According to [Kiliccote et al 1996] the reasons for a limited success of active rep-resentation of the codes were that (a) regulations are not self sufficient, (b) regulations are ambiguous, (c) regulations have exceptions and (d) regulations include higher order logic. We claim that the reasons are deeper and are related to the overall role of computers.


77

We challenge two deeply rooted assumptions of regulation processing:

1. Regulations contain knowledge and information that should be computerized. 2. Regulations will be made available in one best representation from a single source.

It is very appealing to think that the regulations contain objective knowledge that can be matched against some data in the product model and evaluate if this product model conforms to the regulations or not. Critics of artificial intelligence that have applied the speech-act the-ory and Heidegger's philosophy to the design of computer programs would stress the impor-tance of the interpretation and context and claim that the main deficiency of machine intelli-gence lies in the lack of access to the full context, to the blindness of any model based ap-proach and to the unspoken meaning of the speech acts. [Turk 1998b] summarized the conse-quences that this understanding of software has on some trends in construction information technologies.

During the human interpretation of the regulations, the human places them in context and makes sure they are interpreted within that context. This context includes not only deep engi-neering knowledge, but also common sense and understanding of the context in which the regulations were written (accounting for current technology, industrial policies, social order, etc). We can use these arguments to explain the success of representations that leave the in-terpretation entirely to the humans. Automatic mapping of the non-trivial provisions to prod-uct models is therefore difficult. But for simpler provisions this mapping can be done. In the embedded systems, the author of the CAD program has interpreted the provisions of the regu-lations in the very limited context of design cases that his program supports and could there-fore come up with useful solutions. Generalized representations of the regulations, however, attempt to provide a neutral good-for-all representation that can be applied in any context. We claim, again, that this is not possible for non-trivial provisions.

The regulation server developed focuses on the issues of the publishing, searching and deliv-ery of the building regulations and on the interfaces between the regulation processors and CAD software. The representation attempts to support a joint-cognitive approach and delegate the interpretation to an engineer who should be best aware of the context. The requirements that we are aiming at fulfilling are:

• Engineering environment contains several providers of electronic regulations that use different representations. However, access to all should be possible in a uniform way.

• Users of the regulations are both humans and computer programs (CAD software). The problem of the context in which a computable regulation is applied should be shifted to-wards an end user or software author.

• Engineering environment contains several CAD programs that could use the knowledge embedded in the regulations. The system should make it easy for the CAD software au-thors and systems integrators to plug-in the functionality of the computerized regulations.

• Engineering environments are networked. Regulations have a wide scope and should be delivered over the network.

To accommodate for several different approaches to the representation of the regulations, the regulations should be modelled as component objects.

5.6.2 Regulation processing framework

We propose that decomposition into components, agents and robots are the essential informa-tion technologies that can be applied to address the requirements identified above.


78

A web robot is [Koster 1995] a "program that traverses the Web's hypertext structure by re-trieving a document, and recursively retrieving all documents that are referenced". In the net-worked regulation-processing context, the robots are used to discover and catalogue available regulation servers and their functionality.

An agent is "one that acts for or as the representative of another" (http://gs213.sp.cs.cmu.edu/prog/webster, 1999). A software agent is a piece of software that acts to accomplish tasks on behalf of its user. We do not follow AI's definition of an agent where attributes like initiative, responsiveness and intelligence are associated with the term. Both robots and agents replace humans in doing their work. Agents pretend either to have some human qualities or present themselves to software as humans, while robots make no such attempts. In the networked regulation-processing context, the agents are expected to ini-tiate regulation checking on behalf of the designer. The checking can take place after or dur-ing design.

Component architecture is notion in object-oriented programming where "components" of a program are advertised to the environment in a standard way and the programs in this envi-ronment can make use of the components using standard request methods, usually through a request broker, such as CORBA or DCOM. This enables completely dynamic loading of ob-jects. Components need not reside on the same machine, they can be distributed on the net-work. Component-oriented approaches favour object-interoperability to data-exchange and enable true distributed computing. In the context of networked regulation processing we use the notion of a component to represent the functionality of a computerized representation. Regulation is a component with some data (hypertext) and a number of methods that can be asked to perform compliance checking or provide information in the regulation in a computer readable format. It is vital that the methods are defined in a uniform, computer readable, stan-dard format, allow accesses from different applications, provide application interface for sev-eral language bindings etc.

aaP Before any calculation is carried out, the designer shall choose the forces and imposed displacements which will be treated as actions in that calculation. Some forces and imposed displacements shall be treated as actions in certain calculations and not in others Downdrag (negative skin friction) and earth pressures are examples of such forces. (3) For loads applied to foundations by structures, an analysis of the interaction between the structure and the ground may be needed in order to determine the actions to be adopted in the design of foundations.

application

Web

request hypertext

call method

reply

explanation

calculation

“active”, component layer

“passive”, hypertext layer

method

code

public interface

method method method method method

Fig. 5.33: Informal Use-case Diagram for Regulation Processing.

Building regulations are documents that contain text requiring interpretation. They can be viewed as illustrated text, as an inter- or intra-related hypertext, but also as a software compo-nent or object (Fig. 5.33). The knowledge embedded in the regulations can be abstracted as set of methods, queries or functions that can be invoked by the users of the regulation. The regulation can therefore be modelled as a component (or several components) which exposes


79

its methods in a standard way. Some of the methods could be rather primitive, e.g. “display clause N”, some more sophisticated e.g. “check beam” or “assert constraints”. The methods are invoked by message passing. The actual implementation of the method is hidden from the user and the environment. The regulation is an object encapsulated in a “wall of code”. Only some public methods are available to the outside world. On another layer below the compo-nents is the hypertext representation of the regulation.

The overall architecture builds on the four actors that are involved in regulation processing – clients, brokers, servers and agents:

• client: host which is running applications for a user and is requesting information from the regulation processing servers, brokers and agents;

• broker: host application that manages meta information about the servers and the agents; it knows how to find a server and establishes communication between client and server; Regulation brokers store lists of regulation servers and the uniform descriptions of their functionality. In addition to simply finding a server, passing that information to the client and letting that the client arrange a session with the server, brokers are more helpful in storing server details so that the dialogue between server and the client could be shorter. Brokers also include other information such as certification data on some regulation serv-ers, performance, and reliability evaluation etc.

• server: host application that serves regulation-related information on request to the client or meta-information to the broker; Regulation specific part includes rule sets, procedures, objects or other components specific to a single regulation. Representation specific parts are components, which are unique to a representation type, but may be reused with all regulations using this regulation type. E.g. hypertext server, rule evaluation engines, etc. Client specific parts are components, which are special for each client using the regula-tion server. An important feature of a server is that it presents itself to the outside world in a uniform way. This means that servers should not have client or agent specific parts, but be compatible with a standardized application interface.

• agent: host application that monitors the actions between other components; autono-mously invokes server and client actions when a need is identified or such a request is made.

There are several main events that take place in the environment (Fig. 5.34).

• Server registration and update. A server is registered with the broker. It tells what it does and defines its interface.

• Registration verification. A broker periodically scans the server if it is still active and if it conforms to its specification.

• Server search. A client issues a request to the broker, specifying what kinds of regulation processing services are required. Broker searches its database and returns a list of servers who offer the service.

• Server use. A client passes information via the broker to the server and receives results from the server via the broker or directly. Results may be in several different formats.

• Agent request. A client requests an agent to monitor product model for compliance with the regulations.


80

• Agent action. An agent discovers that the state of the product data has changed in such a way that its action is needed. The agent performs the action, usually by sending a mes-sage to the responsible actor or raising a conflict.

conformanceMonitoring

regulationReading

regulationServer

searchingForServer

regulationBroker

regulationAgent

registrationServices

client

regulationProcessing

Fig. 5.34: Main Use Case Diagram.

Fig. 5.34 depicts the overview of the usage scenarios between the main object classes. Regu-lation servers and agents register with the regulation broker. Clients consult the regulation broker to find the servers. They use regulation servers to get the textual representation of the regulations or ask regulation agent to monitor or impose constraints on their designs.

Main services offered by the regulation broker to the clients include searching of servers on various criteria and returning information about these servers, including access restrictions, payment methods, facilities offered, etc. Main services offered by the regulation server are compliance verification of an “informationChunk”, retrieval of regulation (hyper)text, search for regulation parts, search embedded methods, retrieval of computable application interface of a method and regulation methods execution. Main services that can be required from the regulation agent are submission or removal of an information chunk for automatic monitoring by the regulation processing server, retrieval of log files and results. In turn, regulation agent requests regulation-processing functionality from the regulation server.

The classes used to represent the environment are grouped into four packages. The Servers package contains the classes needed to represent the regulation servers, brokers, and agents. The Internet package models the Internet communication backbone and protocols. The Regu-lations package contains the classes for the modelling of building regulations. And finally, the Product Data package includes the classes required to interface the regulation processing


81

component with the product data managed by the environment’s information logistics ser-vices. Fig. 5.35 shows the detailed class diagram of the Servers package.

registeredWith1..1

knowsAbout

*

regulationBroker

findServer( )getServerInfo( )registerServer( )modifyRegistration( )

isDescribedIn

*regulationServer

isDescribedIn*

request reply

supportsRegulation1..*

regulationServerInformationhost : hostInfoorganisation : textaddress : textaccess : text

1..1

*

*

includes 0..*

regulationMetaInformationtitle : textkeywords : textissuedBy : textissuedAt : texttimeScope : textspaceScope : textrepresentations : text

execMethod( )showMethods( )

1..*

client server

has

1..*

belongsTo

1event

isServerIn

isClientIn

hostaddress : IP

sessionclient : hostserver : hoststartAt : timeendAt : time

1..*1

regulationAgent

*

*hasTask0..*

agentTaskproductDatumschedulingInfoorderedBy

0..*

regulationMethodname : textdocs : textparameterTemplate : text

0..*

1relatedMethod 1

*

Fig. 5.35: Detailed Class Diagram for the Servers Package

5.6.3 Prototype development

Servers, brokers, and agents are implemented as Web services using HTTP communication protocol. Clients are programmable applications running on Windows 95, Windows NT or UNIX systems. Internet or intranet is used for the communication backbone. Server side pro-gramming is done using CGI interface and the portable programming language Perl.


82

Passively, the regulations are represented as hypertext. Software has been developed that automatically creates hypertext from plain text, inserts cross references etc. Additional func-tionality includes complex full text searches, minicode generation, public and private annota-tions and commentaries (Fig. 5.36). Active aspects of the regulations are modelled using the EXPRESS-C language and implemented as JavaScript, CGI and ActiveX components. Draft Eurocodes were used as a test case.

The software we developed can be broken into the following groups:

• author's environment;

• end users' environment;

• integration tools;

• maintenance tools.

title toolbar

previousclause

nextclause

computablecomponent

codesupport

annotationof clause

discussionof clause

link to sections above

table ofcontents

window withfull-text of code

maintoolbar

implicitlinks

explicitlinks

outline styleor simple

link tofull-text

regulation utilities

regulation tools

list ofcodes

search facility

about help

Fig. 5.36: Regulation Represented as Hypertext

Author's environment assists in the rapid and semi-automatic creation of hypertext from the scanned building codes. The environment integrates some free software for the creation of HTML from RTF documents as well as proprietary software that automatically converts the text into hypertext. Human editing is minimized, therefore we are able to quickly convert big volumes of code into hypertext format. The software automatically creates the co-called pas-sive representation of the regulations, as shown in the central part of Fig. 5.36, it creates cross-references, full text index, A – Z index and infrastructure for annotations, discussions, explanations etc.

The end user environment is the interactive environment that is used to access the codes. The access is through two types of servers – the regulation server that serves the code prepared with tools of the author’s environment and the regulation broker that is used to discover and


83

register the server and its abilities. The top grey row in Fig. 5.36 is provided by the regulation broker. The central white part is delivered by the regulation server on user's request through the broker. The environment also includes access to the computable sections of the code through the calculator icon. Implemented as ActiveX and CGI components (Fig. 5.38), these computable sections are not generated automatically, however, the created tools allow the programmer to define only the logic of the component. Based on the specification, the user interface (Fig. 5.38) is generated automatically just like the documentation for programmers. This is available as readable text (Fig. 5.40) or in EXPRESS language.

Fig. 5.37: Regulation Broker Displaying

Servers that Match the Term "Eurocode"

Fig. 5.38: Example User Interface to a CGI

Component

Fig. 5.39: Results from another Component's

Processing

Fig. 5.40: Information about the Component's

Application Interface, given as Plain Text

ESPRIT Project No. 20587 ToCEE Deliverable K 7 / J Page 84

Integration tools are provided for system integrators who would like to use the functionality of the building codes in their CAD programs. To them, the regulation brokers present the building codes as components with publicly defined interfaces. The interface is documented both in human readable text (Fig. 5.40) or in EXPRESS language. Based on these definitions, the users of the regulations will be able to make hooks from their programs into the function-ality of the regulation servers. Physically, the information exchange uses feature vectors. CGI components are accessed using Web browser. Information with CAD packages is exchanged using the cookie mechanism. Geotechnical design software, PAULA as part of the GWM en-vironment (Fig. 7.30) has integrated some of our regulation processing functionality into its latest version.


6 Case Example – The New Munich Fair In the requirements phase of ToCEE the New Munich Fair Project (NMM) was chosen as a case project (Fig. 6.1 – Fig. 6.2). For the demonstration of the ToCEE software tools for con-current engineering Hall 21 of the NMM is selected as case building. The demonstration sce-nario presents a typical example problem for the beginning of the construction phase: new requirements of the owner initiated through the early involvement of the facility management in the project and leading to the necessity to perform a fast partial re-design of the building and re-planning of the construction activities. The scenario foresees to start with the sugges-tion to install a crane in Hall 21 for the transportation of heavy items – a requirement of a new tenant, not provided in the original design.

Fig. 6.1: Entrance area of the New Munich Fair

For the purpose of the demonstration, the real design of Hall 21 is simplified in such a way that it is understandable, manageable to be run in a demonstration environment and empha-sises the concurrent engineering and co-operative work issues addressed by ToCEE.

The following pages (Fig. 6.3 – Fig. 6.7) present several schematic diagrams of Hall 21 – front view of the building, floor plan of the basic structure, the suggested placement of the proposed semi-portal crane, a 3D view of the whole structure and a plan of the whole site in the detail needed for the site preparation activities simulation.

Hall 21 is a large one-storey building enclosed on both front sides by two auxiliary 2-storey office buildings. The latter will be included in the demonstration only as a whole, so that their impact on the main hall building can be properly considered. From architectural point of view Hall 21 consists of one large space (approx. 10,800 m2) and several additional spaces in the 10 entrance areas. Its primary bearing structure is comprised of 10 shear wall cores enclosing


the entrance areas, a lateral system supporting the roof which consists of pairs of braced trusses spanning the hall space and a supporting longitudinal system of simple beams span-ning between the cores. Loadings include self-weight, live loads, equipment load, wind and snow.

Fig. 6.2: Bird's Eye View of the New Munich Fair

The foundations of the shear wall cores are initially designed as spread footings but may change in the re-design phase due to the heavy asymmetric loading introduced by the new crane. The HVAC system contains pipes and conduits both at floor and roof level. Manholes and inspection chambers are located in the entrance areas, in the spaces between the paired shear walls.

For all these systems, the proposed semi-portal crane will be a "conflict object" requiring re-spective re-design considerations. It causes additional heavy loads on the structure that have to be considered and its support must be integrated into the structural system. Besides, the HVAC system at the side of the crane support has to be re-designed and the positions of the pipes have to be relocated. The entrance areas have to be re-designed by the architect, and possibly new virtual spaces for the whole hall will also have to be established. The details of the foreseen project activities for this case example are presented in the next section.


Fig. 6.3: Front View of the Case Building (NMM - Hall 21)


Fig. 6.4: Floor Plan, Showing Main Structural and Architectural Elements


Fig. 6.5: Floor Plan, Showing Approximate Position of Proposed new Crane


Fig. 6.6: Isometric View of the Building Structure (Worm's Eye Perspective, no Ground Plate Shown)


Fig. 6.7: Plan of whole Site Showing First Excavation and Waste Dump Activities from Ex-ample Construction Simulation done with WP B


7 CEE Applications and Application Tools Application tools, such as CAD, cost calculation or FM, are usually designed for stand-alone purposes. In their current state, they are often only of little use to serve for and support CE issues. In most cases they even do not provide standardized data interfaces. In ToCEE we focused on key issues to upgrade application tools for CE, i.e. to gain the benefits of up to 30 % increase of cost effectiveness from IT support CE or to develop new tools from scratch, like the geotechnical work module (GWM) tool, where the paradigm of CE determines the tool as a whole. In the following of this chapter, the CEE developments for the application tools are presented for the design, for the construction and for the facility management proc-esses and, of course, the way how they can be incorporated in the other processes as simula-tion tools shown by the example of the GWM.

7.1 Application Tools for the Design Process


For the design process, various tools are available, which support single tasks, like architec-tural and engineering design representations (CAD) or mathematically based verifications of design, such as structural analysis tools, which are sometimes extended to simulation tools by appropriate graphical presentation of the results as animations and by interactive user input during runtime.

For CE these tools need extensions and add-ons, which sometimes demand valuable re-engineering of these tools. These are addressing the following issues:

• High-level semantics, namely object-oriented product data and their I/O • General semantics, namely preferably standardized objects • Common semantics, namely global identification of objects • Business process information, like worktask, time, version, authenticated user • Legal information, like authorization of the user, responsibility, approval status. • Support conflict management. One of the most advanced commercially available CAD system in 1997 concerning these is-sues has been selected. It possesses a powerful programming interface. Therefore some of the high-level semantics and some of the general semantics were already available to the ToCEE project. The drawback was that some of the issues, which were essential, have been still de-veloped by the commercial software provider in parallel. Some of them were available so late in time, even the ß version, that an own development was made for standardized product data I/O based on IFC version 1.5. The ToCEE tool [Ingenbleek 1998] developed by Concad GmbH, Germany, was used in order to map Autodesk Foundation Classes (AFC) objects to IFC objects.

At the time being the interest of software vendors are focused on application tool integration. Therefore specific issues for CE, i.e. common semantics, business process and legal informa-tion, have been developed on our own by extending the commercial CAD system through the public programming interface and through a dedicated client, which can be started in the CAD environment. The tools developed are technically described to some extend in the following and their functionality for practical purposes will be shown in the next chapter together with the conflict management tools.


At the time being only some of the commercial AEC software vendors has implemented ISO 10303-225, which covers AEC objects primarily focused on the geometrical properties and some test implementations for IFC V1.5.1, which covers simple basic geometry but also pro-ject, process and document related information. However, the latter was not available on the market in 1998 but was only provided for testing under special conditions (Remark: Mean-while IFC V 1.5.1 is commercially provided by the main AEC CAD vendors). All in all, some AEC software supported object-oriented product models but for a limited scope in standard-ized format and in an broader scope in proprietary formats. Therefore it was decided upon to develop a general design phase client, which as a prototype covers the above given issues which are not fulfilled by the software commercially available. As commercially software, AUTOCAD and ADT from AutoDesk as CAD tools and SOFiPLUS from SOFiSTiK as structural analysis tools were chosen.

7.1.2 Design Phase Client and IFC Interfaces with the ToCEE STEP Toolbox

The design phase client (Fig. 7.1) named SOFiSTiK ToCEE Client serves for different pur-poses.

Fig. 7.1: The Design Phase Client, SOFiSTiK ToCEE Client with the PtDMS Client opened for downloading GLOBAL-1 Product Model, started under AutoCAD

First, it is a kind of platform which can be started under different environments, such as WINDOWS-NT, AUTOCAD, ADT and SOFiPLUS, which provides to the design a user-friendly, easy accessibility under these different environments.

Second, in the SOFiSTiK ToCEE Client, several clients of the ToCEE CEE are incorporated, which allows to start from the client’s platform

• The ILS client which provides to the user its individual worklist, • The PtDMS client which allows up- and download of product data providing full func-

tionality of the PtDMS to the user access. • The DMS client which provides full access to the DMS and up- and download of all kind

of documents.


The design phase client is generic and allows to incorporate other clients easily on its platform interface.

Third, the design phase client is automatically communicating with IFC interfaces imple-mented with the ToCEE STEP toolbox for AUTOCAD, ADT and SOFiPLUS (Fig. 7.2).

Fig. 7.2: The ToCEE STEP Toolbox

The ToCEE STEP toolbox from ConCAD GmbH, Germany [Ingenbleek 1998] is an object-oriented tookit for the mapping of IFC V1.5.1 objects expressed in EXPRESS to C++ classes using the early-binding technology. With the ToCEE STEP toolbox, an IFC V 1.5.1 I/O inter-face for ADT and AUTOCAD was developed which can be started via the SOFiSTiK ToCEE client or directly in ADT or AUTOCAD, because SOFiPLUS uses AUTOCAD as platform. IFC I/O to SOFiPLUS is realized via AUTOCAD using AUTOCAD Foundation Classes (AFC).

7.1.3 CE Extensions for the Design Tools

In ADT, some CE functionality is implemented using the object-oriented programming inter-face Object ARX for AEC, which offers also direct access to MFC (Microsoft Foundation Classes). This direct access was used for instance for running the SOFiSTiK ToCEE Client under WINDOWS-NT as well as under ADT. Two important CE extensions can be catego-rized.

First, newly generated AEC objects in ADT as well as in other application tools obtain only a local ID. For product model based file transfer, where each SPF contains a complete product model, this would be sufficient. However for CE, where only aspect product models are proc-essed by the users and several versions of the same aspect product model may exist, which must be properly managed by the PtDMS, global IDs are a must. Global IDs can only be managed error-free by the CE system and there the PtDMS is the right component. Therefore, for each SPF uploaded to the PtDMS, the PtDMS generates for all local IDs the correspond-ing global IDs based on the most recent global product model from the last co-ordination point (see Fig. 5.20). The PtDMS automatically sends a list of tuples containing the local and the global IDs back to the application tools to update there immediately the local SPF in order to avoid old corrupted local data there. In a very first test implementation, the complete SPF with the global IDs has been sent back and the tuple list was generated in the ADT. The gen-eral and specific solution opportunity are implemented.

Second, in order to support conflict detection and product model inspection, the comparison of two aspect models is a necessity for CE. It can be provided for either on client or on server side. Basically this functionality is implemented in the PtDMS. However, there exists no spe-cific knowledge about AEC objects like existing in specific application tools, of course, which leads to weaker conclusions about changes. Therefore it is considered beneficial to have such

ADT

Sofistik ToCEE Client

To C EE STEP Toolbox

SPF

IFC

AFC


a functionality in the according application tool. Finally, in order to gain most experience on this important CE subject we choose both ways, even though this is somehow redundant.

The implementation done on the PtDMS is described in chapter 5.2. The comparison proce-dure realized in ADT with the ARX API is based on the object IDs and geometrical informa-tion applied with ADT internal functionality. As a result of a comparison the ADT provides a visualization of the master model and in pre-selected colours all differences between the mas-ter model and the second model. In Fig. 7.13, the changes of the design section of the HVAC engineer are shown.

7.2 Conflict Management in the Design Process The tools developed for design and for the computer-supported management of conflicts in the ToCEE CEE are demonstrated with the help of a small demonstration scenario which is a cut-out from the large demonstration scenario provided in the PPT show. As case example a simplified version of Hall 21 of the New Munich Fair (chapter 6) recently designed and con-structed is used.

As starting point let us assume that the owner requests a change at a certain stage in the de-sign of the building. The task is to provide light crane equipment with working area of the crane extending over the whole length of the hall.

Although the order of the owner is given to the architect, this task cannot be fulfilled by the architect alone. Specialist knowledge of the whole design team (HVAC, electrical, structural, foundation engineer etc.) is needed in order to consider properly the possible consequences of the design change. Therefore, in parallel to determining the crane type and location, the archi-tect sets up new workflow with several worktasks for the members of the design team with the help of ToCEE’s Process Wizzard as shown on Fig. 7.3. Collaboration can hence start.

Fig. 7.3: Initial Workflow for the Example Conflict Demonstration Scenario


To focus on the description of the design and the conflict management tools the cut-out sce-nario is limited to the tasks of the architect and of the HVAC engineer in the following.

According to the set up workflow, the task of the HVAC designer is to re-design the duct sys-tem for ventilation and air conditioning so that it fits to the proposed change by the architect. However, this single worktask (from the point of view of the architect) involves a complex sequence of actions (from the point of view of the HVAC designer) requiring the use of a va-riety of tools, system services and types of data. This expanded view of the worktask of the HVAC designer is shown on Fig. 7.4 below.

Process Data

Workflow ClientProMoTe

VR-BrowserConflict Detection

Tool CAD Product Data

Management Client Conflict Applet

Process MgmtServer

Get new work task

H1

Modify HVACdesign solution

H4

Register conflict,create new task(s)

H6

Conflict MgmtServer

Process Data Product Data (HVAC Aspect Model)

Conflict Data

Product Data MgmtServer

Download data,visualise changes

H2

Product Data (Architectural Aspect Model)

Examine data,detect conflict

H3

Uploadmodified model

H5

Product Data (HVAC Aspect Model)

Product Data

ClientTools

Servers

Work task: Re-design ducts

Fig. 7.4: Sequence of Actions in the Worktask “Re-design ducts” of the HVAC Engineer; top:

Tools, middle: Worktasks H1-AH, bottom: Servers and Dataflow

At first the HVAC designer gets informed of the new task through his workflow client (step H1), sometimes also called ILS client, which continuously updates his individual worklist. After he started the worktask ‘Re-design duct’ he receives a list from the ILS via the work-flow client of all currently available documents and aspect product models, which contain the architectural re-designed element.

As next action (H2) he downloads the current, up-to-date product data from the architectural aspect model, and then uses the virtual reality browser ProMoTe in order to obtain a fast im-pression of the changes made by the architect. With ProMoTe all new or changed objects w.r.t. some previous design state can be automatically highlighted and viewed in a VR-model, and at the same time their non geometric properties can be examined as shown on Fig. 7.5. From this quick examination with the ProMoTe tool it becomes obvious that the crane presents a potential problem, because, when moving, it may collide against the ventilation ducts in the hall.


Potential problem

VR-model

Control

ToCEE : ProMoTeToCEE : ProMoTe

Fig. 7.5: Visualisation of the Design Product Data with ProMoTe (new or changed Data

w.r.t. Previous Model Versions are highlighted and can be easily recognized)

A detailed analysis with ToCEE’s specialised conflict detection tool confirms the suspected problem (step H3). The conflict detection tool has been designed to detect geometric conflicts for objects moving along pre-defined working paths, and is implemented on top of Auto-desk’s Architectural Desktop. Fig. 7.6 gives an example of its use, showing selected frames from the animation produced after the analysis of the crane path. Due to this, now obvious conflict, the HVAC engineer is not able to fulfil the requirements of the architect as sug-gested. Instead, he proposes an alternative solution, modifying respectively the product data as step H4 with the help of his CAD system (Fig. 7.7).

Fig. 7.6: Detection of Geometric Conflicts with Moving Objects


Design change

Fig. 7.7: Change of the Design Data due to the Geometric Conflict between Crane and Ventilation Ducts

In a conventional approach this would now complete the task of the HVAC designer. He would then notify the architect about the conflict with an informative message (by phone, fax, e-mail) and will either attach his alternative proposal as a drawing file to his message or, by more advanced organisational and IT infrastructure, he will store this file on the document management system used in the project. It might also be possible to exchange the product data with the architect, but the co-ordination of the process of conflict resolution will still happen only in the heads of the designers, without notable IT support.

Fig. 7.8: Uploading the HVAC Aspect Model Data to the Product Data Server with ToCEE’s

General Purpose Product Data Management Client PROMISE / Susi

With ToCEE, however, a much more rigorous approach to change and conflict management becomes possible. Co-ordination of conflict solving and reaching agreement, status of con-flicts project wide, status of approval, status of development versions and alternatives of the design solution, all this is maintained and managed by the ToCEE CEE. All these boring and error-sensitive information logistics tasks are taken over by the CEE and keeps the users in-formed and up-to-date.

Therefore, the next step in the CEE after the product data are modified to represent the proposed new design alternative, the HVAC designer uploads the new version of the HVAC aspect model to PROMISE, the product data server of the ToCEE environment (step H5). This can be done


either by the specialised client tool developed by SOFiSTiK, or with ToCEE’s general purpose product data management client PROMISE/Susi shown on Fig. 7.8. However he has now to indicate that this aspect model is not a new, valid version, binding for all but that it is solely his suggestion for solving the design conflict concerning the newly added crane and the ventilation ducts. This notice will be provided by him in the next action (step H6).

Fig. 7.9: Applet for Reporting a Conflict

In the next and final step (H6) the HVAC engineer registers the detected conflict via the con-flict management client, a JAVA applet of the conflict management server on the conflict management server (Fig. 7.9). The main objective there is to permanently store the informa-tion about the conflict in the CEE and made it available whenever and for whomever it is of interest. When a conflict is registered without a proposed solution, only the person (or role) who is responsible to manage the solution has to be indicated. As default, the person who reg-isters the conflict is taken.

In the present scenario, the HVAC engineer already made a suggestion to solve the conflict and therefore already started the first step for the conflict resolution and therefore has to indi-cate that he uploaded his proposed solution to the PtDMS and who has to approve his pro-posal. This are in the present case the architect, the structural engineer and the foundation (i.e. geotechnical) engineer.

The Conflict Management Server stores the conflict data including all related references to processes, documents and product model objects in a central conflict database which enables the monitoring of the conflict status, the maintenance of the data consistency and integrity and the notification of all actors involved in the conflict solution. Together with that, the system automatically creates a new worktask for the architect who has been selected as responsible actor for solving the conflict, which immediately appears on the workflow status window (Fig. 7.10) and on the individual worklist of the architect, too. In this way robust co-ordination of data and processes with explicit consideration and control of responsibilities by the IT-system is achieved.


Fig. 7.10: Workflow after the Spatial Conflict between Crane and Ventilation Ducts are Reg-

istered on the CMS

It has to be mentioned that this does not mean that the conflict has to be solved immediately before any other design step can be continued or started newly. It is solely on the responsible person’s decision (here the architecture) when he is calling for the conflict resolutions proc-ess. Nevertheless any of the involved persons can work on the solution of the conflict when-ever they consider it convenient for them. They have been informed personally about the con-flict via the CEE due to their indication by the HVAV engineer as an approval person.

Workflow Client CAD-based Conflict Mgmt Tool Process Wizzard CAD

(Arch. Desktop)Product Data

Management Client Conflict Applet

Process MgmtServer

Get new work task

A1

Modify arch.design solution

A4

Uploadmodified model

A5

Register changesapprove conflictfrom HVAC

Conflict MgmtServer

Process Data Product Data (Arch. Aspect Model)

Conflict Data

Process Data


Download data,examine changes

A2

Product Data (HVAC + Arch. Aspect Model)

A6

Process Data

Product Data (Arch. Aspect Model)

ClientTools

Servers

Product Data

Abort tasks,create new workflow A3

Work task: Spatial collisions

Fig. 7.11: Sequence of Actions in the New Worktask of the Architect, due to the Detected Con-

flict; top: Tools, middle: Worktasks A1-A6, bottom: Servers and Dataflow

Today, conflicts are usually solved in round-table meetings. The procedure of a “round table” consists in principle of two components, a co-ordinator and a controller. With the ToCEE CEE the co-ordinator is the responsible person, whereas the controlling work is taken over by


the CEE. It is the controlling of the approvals. The start of a conflict resolution cycle has to be triggered by the responsible person by setting up the conflict resolution workflow. This work-task for the architect is named “spatial collision” in the present scenario. It consists of several actions, which are depicted on the expanded view of the worktask given on Fig. 7.11. Imme-diately after the conflict is registered, it appears on the architect’s worklist due to the auto-matic messaging system of the ILS. The architect starts his worktask “spatial collision” by selecting this worktask on his worklist (Fig. 7.12), which is maintained by the ILS client (step A1). The ILS client provides the architect with all available information for this worktask as it was already explained for the step H1, before.

Fig. 7.12: Task for Conflict Resolution on the Worklist of the Architect

Usually, the next step (A2) of the architect is that he informs about the conflict by download-ing the architectural aspect model and the related HVAC aspect model as well as the proposed solution HVAC aspect model. He examines and compares them with the help of ProMoTe in a similar way as already described for step H2.

Alternatively, the architect can use directly with his CAD system the ToCEE change man-agement tool developed on top of Autodesk’s Architectural Desktop which allows him to view and compare the data of two aspect models right away as shown in Fig. 7.13.

With the change management tool two models in STEP physical file format can be loaded on the Architectural Desktop in the same work session. The analysis of the differences between the two models relies on the centrally maintained object IDs for all product objects in all aspect models by the product data server. The tool supports also direct queries to the product data server through the ToCEE IC API [Wasserfuhr, Scherer 1999], [Hyvärinen et al 1999]. In that case only the architectural model will have to be loaded completely, whereas the new and changed objects in the HVAC model can be obtained directly through a remote call to the knowledge-based server function match. From application point of view this second procedure is much more efficient w.r.t. data storage and time as it delegates most of the sophisticated model comparison work to the product data server. However, it is not interactive and therefore the first, more explicit procedure might be preferred whenever more detailed control of the model matching process is felt necessary.

After examining the proposed changes the architect must coordinate the solution of the con-flict. From the workflow chart of the Process Wizzard he can easily allocate all tasks affected by the proposed design changes.


Assuming that he himself can agree with the modifications proposed by the HVAC designer, he must nevertheless take care that all other designers also agree with these modifications and re-work their design solutions accordingly.

Initial instances

Changed instances

Fig. 7.13: The ToCEE Change Management Tool embedded in Autodesk’s Architectural

Desktop

For this purpose the architect stops the running workflow with the Process Wizzard as shown on Fig. 7.14 and Fig. 7.15 and consequently sets up the workflow for the needed re-design work, i.e. the virtual round table workflow (step A3) as shown in Fig. 7.16.

Fig. 7.14: Aborting a Workflow


Fig. 7.15: Workflow after Abortion (black boxes show aborted tasks, white boxes show already finished ones)

After this coordination work the architect can adjust his own solution with the help of his CAD system (step A4) and then upload the changed model back to the product data server (step A5) in a similar way as already described for the HVAC designer.

Fig. 7.16: Revised Workflow with the Newly Added Conflict Resolution Workflow

Finally, he approves the changes proposed by the HVAC designer as shown on Fig. 7.17.


The updated architectural model can now be used as basis for modifying all other discipline-specific models by the other designers. Their work will typically follow a similar to the pre-sented procedure, using the appropriate services of the CEE.

Fig. 7.17: Conflict Approval

A unique feature of the ToCEE CEE is that it explicitly allows the existence of temporarily inconsistent data in order to restrict as little as possible individual and simultaneous work, which demands several versions and alternatives of one and the same design part and tempo-rary conflicting data. Many of the developed services and tools contribute to the solution of such conflicting situations. Their usage, briefly outlined in the presented scenario, is summa-rised in the following:

Conflict management issues Tools Implementation • Parallel work (time) conflicts,

process coordination • Process Management Server

TUD

• Process Wizzard TUD • Workflow clients SOF, TUD

• Distributed data consistency • Distributed data access • Visualisation of changes

• Product Data Server (PROMISE) • General purpose product data client • VR-enabled product data browser

(ProMoTe)

TUD TUD

VTT

• Conflict management, con-

flict propagation, data coordi-nation

• Conflict notification and ap-proval

• Conflict detection

• Conflict Management Server • WWW-enabled conflict manage-

ment clients • Conflict detection tool • Change management tool embedded

in Autodesk’s Arch. Desktop

TUD

TUD OPB

SOF


ProductData

Conflicts

Global 1

STRUC_ 1

FOUND_1

A F S, H

S F F

F F S

ARCH_1

HVAC_1

H F A

ARCH_1;2

A F S

Re-designducts

React to detected conflict

Worktask of Architect:„Spatial collisions“

Match modelsCheck in changed model

Fig. 7.18: Product and Conflict Data State before and after the Worktask of the Architect. (Abbreviations: A = Architect, H = HVAC, S = Structural, F = Foundation engineer).

Whilst all these tools provide a functional user interface and many useful stand-alone features, their full power is manifested only through their coherent use in the ToCEE environment. For example, in order to enable the functionality of the conflict clients and the individual work on the separate aspect models, a sophisticated coordination of the different aspect product models and their version, i.e. proposal for solving the conflict, at each stage of the design process must be maintained by the product data server. Fig. 7.18 gives an impression of the problem, show-ing the product and conflict data state before and after the worktask of the architect:

(1) product model data shown in light grey exist on the server, but are not used during this worktask;

(2) Aspect model HVAC_1 is only retrieved for comparison of changes w.r.t. the arch. model

(3) Aspect model ARCH_1 is checked out, compared with HVAC_1, modified and then checked in again as new model version at the end of the worktask

(4) conflicts shown in black are relevant to this worktask, other conflicts that might exist but are not handled here are shown in light grey.

However, even though conflict management requires the coherent use of a variety of tools, data and models, to the end-user and to client applications the whole CEE appears as one con-sistent set of information logistics services. Fig. 7.19 emphasises this unique ToCEE ap-proach. It presents once more the worktask of the architect dedicated to the solution of the arisen conflict, but this time from the user/application point of view.


Workflow Client CAD-based Conflict Mgmt Tool Process Wizzard CAD

(Arch. Desktop)Product Data

Management Client

Process MgmtServer

Process Data


Product Data (HVAC + Arch. Aspect Model)

Product Data (Arch. Aspect Model)

User Tools for work task „Spatial Collisions“

Process Data

Information Logistics Server

Document MgmtServer

Server „black box“

Conflict Mgmt Server

Conflict Control

Conflict Database

Conflict Data

Conflict Applet

Fig. 7.19: User View on the System for the Worktask “Spatial Collisions”

7.3 Construction Simulation Tools For the construction simulation two different tools have been developed and implemented via clients in the ToCEE framework, a site preparation module and construction simulation mod-ule. They are summarized as the ground work module and named GWM environment.

In geotechnical structures, the design solution is strongly influenced by the actual site condi-tions, concurrent construction activities and external constraints on the work and must take them into account in order to avoid – what is later claimed as – unforeseen site effects. This is accomplished using the site preparation module. This module compares the current design to the existing site conditions/construction plans and identifies conflicts. During design the site preparation module is invoked after layout of each major item. Likewise, during construction simulation the corresponding module is used to identify physical interference and resource conflicts in the proposed schedule.

Two main classes of construction conflicts exist, physical interference and resource utiliza-tion. Physical interference occurs when two activities or structures are planned for the same location at the same time. Resource conflicts are when different construction activities de-mand the same piece of equipment or crew at the same time.

From the point of view of the site preparation module, which is realized as an expert system, the site is represented as a physical space in x,y,z and time. This space is populated by objects and events, each of which has a particular position in both space (x,y,z) and duration in time (represented by start and finish times). All aspects of the site can be expressed in these terms, for example an existing gas main has a known position (x,y,z) and exists in time from the beginning of the project until some action is taken to reroute or demolish it. Similarly, a planned foundation has position, the proposed location of the structure, and will exist in time from the point at which it is constructed until the end of the project. In this framework detection of physical interference is straightforward. Conflicts are defined as the overlap in space-time of two objects or activities. An example would be if the proposed foundation


two objects or activities. An example would be if the proposed foundation intersected the ex-isting gas main. A solution to this conflict is to reroute the gas main before construction of the foundation. In this case, the gas main no longer overlaps the foundation in time, and the con-flict is resolved. This formulation offers a great deal of flexibility to specify relationships be-tween construction and external events. Potential interference can be expressed as an obstruc-tion of a portion of the site for a given period.

Resource conflicts are evaluated in a similar manner. The construction database contains a list of all equipment and personnel available for the work. The simulation module draws re-sources from this database. When a task requires equipment/crew, which are currently, occu-pied in another activity a conflict is registered.

The foundation design of large facilities frequently requires soil improvement to reduce the compressibility of soils, i.e. the foundation settlements. Usually these methods include pre-loading, tamping, compaction with vibratory rollers, and the use of compaction columns driven in the soil. All these methods require specific field works that interfere with other con-struction activities. A detailed design and construction schedule must therefore be prepared to the purpose.

7.3.1 Site Preparation Module

Preloading of foundation soils may be an interesting solution particularly for large construc-tion areas, when sufficient volumes of material are available, and can be transported to the site with an acceptable environmental impact, and when the required time can be reduced by the use of vertical drains. In the design and construction module described in the following, an automated approach to field preloading activities is developed.

The objective of the Site Preparation Module is to define the site preparation activities pre-liminary to the construction. The Module verifies the Design results against existing site con-ditions and detects eventual conflicts. This can lead to a modification of the foundation de-sign. Subsequently, the system considers the problems related to the excavation under the current design, taking into account also the results of the site improvement. Finally, it analy-ses the aspects of the construction of the foundation members. At this point, the Design Phase can be considered concluded and the Construction Phase can start.

Fig. 7.20: Preloading Solution


Information is acquired from the site database enabling the system to define the site prepara-tion necessary to detect possible arising conflicts. If, at the end of this phase, all detected con-flicts have been successfully solved, the system will proceed to the definition of the activities necessary for the implementation of the works so far defined. Otherwise the solution of "un-solvable" conflicts will be asked to the user or sent back to the foundation design phase. The activity modules for site improvement, excavation and construction define the list of activities necessary to perform the construction, along with their mutual interactions in terms of logical constraints and resources, ready to be processed by the construction simulator.

The Site Improvement Module determines if preloading is needed (Fig. 7.20). In such a case, the preload volume and duration are evaluated, and the results of the assumptions given after analysis. This module also produces results to be utilised by the Activity Module (e.g. time and thickness of the preloading area).

Fig. 7.21: Earth Moving Design

The Earthwork Module develops the earth moving design (Fig. 7.21) considering potential conflicts with other activities (e.g. groundwater table), and identifies additional work required to resolve these conflicts (e.g. dewatering to be analysed by the next module). The output produced gives excavation layout and corresponding quantities. The module performs at first a grading design for the areas where the building will be constructed and subsequently analy-ses the excavations due to the single foundations of the building. The user can fix the slope of the grading areas. Output for the Activity Module is the list of tasks required for earthworks with location and quantities of work.

The Design Construction Module takes into account all other aspects of the site preparation such as retaining walls and dewatering systems. The need for retaining walls is established by the system where grading areas of different levels are required. The presence of existing struc-tures to be demolished is also underlined. If ground water level is above foundation level (conflict detection) and the condition of soil is appropriate, the system launches a dewatering analysis. As result, it produces a layout of wells (Fig. 7.22) (number and position) and pump-ing rate for lowering the water table below foundation level.


Fig. 7.22: Dewatering Analysis Results

7.3.2 The Construction Simulation Module

An activity simulator is used for construction planning. The package consists of two parts, • a series of activity modules and • a simulation engine. Each activity modules captures one construction task and split it into component activities, allocate personnel and equipment for each activity and define unit production rates. The simu-lation engine is then used to model construction. During simulation each activity draws re-quired manpower and equipment from the resources available at the job site. Work progresses for each activity is evaluated according to the unit production rates. The results of simulation show the percent completion of work at any time and evaluate degree of resource utilization. The simulation is used to detect conflict between activities, and to refine the job schedule.

Activity Modules

The activity modules develop detailed work plans and resource requirements for the individ-ual construction tasks and work quantity, physical dimensions and site conditions when de-termining crew requirements and production rates. The activity modules consider work quan-tity, physical dimensions and site conditions when determining crew requirements and pro-duction rates. Cost and time are also presented per operation (which can be considered as equivalent to sub-contractor). This facilitates the control and the attribution of expenses for financial and contract management purposes. Full expert systems are developed for some of the more influential activities, including preloading, several aspects of earthwork and pile installation. Other activities are represented schematically. The system is flexible, however, to allow user definition of tasks and activities.

The input to the construction simulation activity modules is the list of construction tasks and required work quantities developed in design. The output is a list of activities/operations with their interrelationships, crew/equipment needs.


Fig. 7.23: Activity Module User Interface

Two levels of work definition can been considered. They are: • activity: is a part of work that requires a certain number of simple operations. For in-

stance the activity of earth movement from one part of the site to another will be part of the task of the site preloading;

• operation: represents the lowest level work like for instance loading a truck for the trans-port of the material to or from the quarry.

A special user interface has been developed together with GCC in order to allow the end user to properly define the activities.

Fig. 7.24: Activity Module User Interface


They are necessary to perform the construction works (Fig. 7.23, Fig. 7.24). By means of the graphical user interface an activity can be defined by graphically connecting the operation objects in order to define the proper logical constraints such as the order in which the opera-tions have to be performed, whether they can be performed in series or in parallel and so on. By means of interactive input forms the user will also be able to enter all the information con-cerning the characteristics of the operation composing the activity. Moreover the system will contain a list of standard activities to be edited by the user who can change the connections (links) along with their actual characteristics such as duration, status etc.

From one construction project to another one, activities’ definition does not vary essentially (for similar domain, e.g. building, roads, etc.). So, if the activity modules are defined for one construction project (e.g. building), they can be used as a template for a new building project. Only refinements, new tasks or updating (e.g. for cost or resource availability) are usually necessary.

Table 7.1: Input Data for the Construction Simulator for the NMM Project

In Table 7.1 the input data for the construction simulator for the NMM project are summa-rized These data are transferred to the corresponding windows (‘Activities’, ‘Operations’, ‘Material’ and ‘Equipment’) after defining the ‘Parameters’ that characterise the work (diame-ter, length, etc.) (see Fig. 7.24 for example). Note: in the table, the quantities for e.g. concrete or excavation are evaluated by and directly transferred from the Design Module. The system contains also standard links between activities and between operations. These links can be modified by the user in the window ‘Links’.

Simulator Engine

The simulator engine module performs a simulation of the activities defined in the site im-provement, excavation and construction modules. Simulation embodies the principle of "learning by doing". In order to investigate the possible evolution of a complex system, like a construction process, we must first build a model of the process and then, by means of a simu-lator engine, operate it. The results of the simulation allow forecasting the progress of the work at every time interval with indication of the work done, resources allocated as well as the variation of other significant parameters. It will be also possible to stop the simulation, change the values of some parameters and then resume it, in order to verify the influence of changes during the construction process.

The activity simulator is a tool by means of which the construction manager is able to verify the possible evolution of the present situation at the construction site. He could test, for in-

ACTIVITY OPERATION EQUIPMENT & MATERIAL QTY PRODUCTIVITY TIME UNIT COSTGENERAL EXCAVATION GENERAL EXCAVATION EARTH if we say that Hall is approx. 3800M2 (1day=8hours)

and excav.depth 0,5m => 1250m3BULLDOZER 1 pce 2500m2/day 12 hours 500$/dayTRUCKS (16M3) 5 pces (80 travels for 1250m3 => 7 travels by hour)

if we say that 2 travels by truck by hour => 4 trucks 12 hours 200$/day

PILE EXECUTION BORING WORKS ROTATING AUGER 1 pce 45m/day 8 hours 680$/dayREINFORCEMENT CRANE 1 pce 150m/day 3 hours 400$/day

REINFORCEMENT 6 tons (35m3x170kg/m3) 150m/day 270$/tonsCONCRETING CRANE 1 pce 1 hour 400$/day

CONCRETE-MIXER 2 pces 1 hour 360$/dayCONCRETE-PUMP 1 pce 1 hour 400$/dayCONCRETE 35m3 (for diam 1m and length 45m) 50$/m3

PILE CAP EXECUTION EXCAVATION EARTH 16m3 (4mx4mx1m)EXCAVATOR 1 pce 70m3/day 2 hours 260$/dayTRUCKS (16M3) 1 pce 2 hours 200$/day

1ST-METER DEMOLITION HAND-HAMMER 2 pces 2 pces/day 8 hours 150$/dayBLINDING CONCRETE-MIXER 1 pce 1 hour

CONCRETE-PUMP 1 pce 1 hourCONCRETE 2m3 50$/m3

REINFORCEMENT REINFORCEMENT 3 tons (16m3x170kg/m3) 2 hours 270$/tonsFORMWORK FORMWORK 16m2 1 hour 13$/m2CONCRETING CONCRETE-MIXER 1 pce 1 hour 360$/day

CONCRETE-PUMP 1 pce 1 hour 400$/dayCONCRETE 16m3 (4mx4mx1m) 50$/m3


stance, how the system could react to a different resource allocation or to a change in the planned construction schedule due to unforeseen events.

Fig. 7.25: Simulation Process

Various libraries containing a list of standard operations and activities are available for the creation and the modification, by means of graphical tools, of the simulation model in order to allow the user to continuously interact with a “living” model of the activities at the construction site.

The main features of the activity simulator are:

• logical propagation; • recursive levels representation; • time-sharing; • database interaction; • resource management;

The basic elements that compose the simulation model on which the simulator can operate are described in the following. They are:

• functional blocks: representing operations and composed by activation functions, links, attributes and logical relations;

• queues: containing the resources to be used and computing their idle time; • links (connectivity relations among the blocks): allowing to set the direction and se-

quence of propagation; • activation functions: allocating and de-allocating resources from the databases and the

queues; • propagation process: determining the status of the functional blocks through logical

and/or relations among the entering links; • work definition: with two level of tasks: “activity” and “operation”; • task planning: allocating tasks in time.


As soon as the resources are available, i.e. released from preceding activities, the next opera-tion using these resources will automatically start. So at the end, the system gives the opti-mum construction time related to the resources availability.

Fig. 7.25 shows an example activity module in action. A typical worktask would be construct-ing a driven pile foundation. This task is broken down into component activities, from procure-ment and delivery of piling to site through pile driving to final backfilling around the pile cap. Fig. 7.26 shows the results (quantities, costs, time and resources) after the simulation process in a protocol report form.

ACTIVITY: [HALLE311-EXC]EXCAV

HOURS: 6 COST: 1950$

ACTIVITY'S OPERATIONS NAME hours COST ($)

EXCAVATION 6 1950 ACTIVITY'S MATERIALS AND EQUIPMENTS

NAME QUANTITY COST ($) EARTH 1250m3 -

SCAVATRICE (BULLD.) 1 item 750 TRUCK 4 items 1200

ACTIVITY: [4-PILESQQQ-I]PILE_EXECUTION

HOURS: 12 COST: 4390

ACTIVITY'S OPERATIONS NAME Hours COST ($)

BORING WORKS 8 680 CAGE ELEMENT 3 1770 PILE CONCRETE 1 1940

ACTIVITY'S MATERIALS AND EQUIPMENTS NAME QUANTITY COST ($)

CEMENTO (CONC) 35m3 1750 REINFORCEMENT 6T 1620

CRANE 1 item 200 TRIVELLA (ROT.AUGER) 1 item 680

CONCRETE-MIXER 2 item 90 CONCRETE-PUMP 1 item 50

Fig. 7.26: Shortcut of the Protocol of a Simulation Run for hall 21 of the NMM

7.3.3 Data Exchange and Information Sharing through Client Interfaces

The product data models based on the IAI development work, which has been enhanced with capabilities to support CE, represent the basis for exchange and sharing of product model data as well as the information for process and document management.

The GWM developed by DAP communicates with the other module of the ToCEE environ-ment by means of the information logistics services provided by the ILS. STEP files contain-ing product model data are communicated between the GWM and the product model server PROMISE as BLOBs via the ILS applying the SOFISTIK ILS client as the GWM interface. The interface uses SPF ( Fig. 7.27).


ISO - 10303 - 21; HEADER; FILE_DESCRIPTION (( 'FOUNDATION DESIGN EXCHANGE FILE'),'l'); FILE_NAME ('TOCEE.STP','Mon Mar 01 17:27:56 1999 ', ('M.MANGINI'), ('DAP','D''APPOLONIA','16146 GENOVA','ITALY'), 'STEP PROCESSOR DAP','Geotechnical Works Module V. 1.0', 'APPROVED BY M.MANGINI'); FILE_SCHEMA (('FD_APM')); ENDSEC; DATA; #10=CONCRETE('C25'); #11=STEEL('BSt550'); #14=POINT(849.034300, - 147.084500,0.000000); .

. #19=POINT(848.134300, - 99.414500,0.000000);

#74=BUILDING('HALLE21',13.300000,. PILES., 921.701000,848.000000, - 81.307900, - 263.507900); #1000=PROJECT('TC_PROJECT.1','NMM',(#74)); #75=LOADCASE('LOAD COMB. 1',10); #76=LOAD('CL708',#74,#75, (0.000000,0.000000,2604.720000, - 53.930000, - 132.150000,0.000000),

.STRUCT.,#14 , '2 - PILESCL708', - 1,.PILES.,0.025000,'PROCESSED', (0.0,0.0,1.66644E6, - 3.19907E5, - 1.72362E6,0.0)); #77=LOAD('CL682',#74,#75, . . #96=PILE_GROUP('2 - PILESCL708',#74,(#76),#14,2.700000,1.200000,0.900000,.DESIGNATED.,.RECTANGULAR.,.PILES.,0.001563,2.500000,#10, (#11), 9.000000,72.900000,0.600000,2,1,0.001500,1279.019400, 0.000000,17.000000,0.000000,1,2, - 1,.X.,( 2.500000 ), (#15,#16), (1.500000, - 1.500000), (0.000000,0.000000), 523.671667,248.138333,.DRILLED.,#10,$); #97=PILE_GROUP('2 - PILESCL682',#7 4,(#77),#17,2.700000,1.200000,0.900000, .

. 523.671667,248.138333,.DRILLED.,#10,$);

Fig. 7.27: Shortcut of STEP Output File from GWM

The SOFISTIK ILS client provides each TOCEE user with his individual worklist to be per-formed within the CEE. In the GWM environment the worklist can directly be popped up through the command Retrieve-ISL in the Communication menu available in the Simulation Environment.

Fig. 7.28: Individual Worklist provided by the ILS Client

Furthermore it is possible to retrieve a model from the product model server consisting in a complete description of a building along with its loads position and values. The objects con-tained in the product model database are mapped to the foundation design module PAULA by selecting the Button Map to Foundation Design in the PtDMS window (Fig. 7.29). Such win-dow can be obtained though the command Retrieve-PM in the Communication menu avail-able in the Simulation Environment. The command Store-PM in the Communication menu can be used to perform the opposite operation and store the results of the Foundation Analysis in thePtDMS.The ILS also gives access to the DMS, which currently serves as the comple-


mentary source of project information in the ToCEE environment. The DMS provides the latest version of CAD files (e.g. the earth moving design in Fig. 7.21) and project documenta-tion which can be accessed by team members at any stage of their work. This repository is also updated with results of analyses as for instance the simulation protocol report (Fig. 7.26) to make them quickly available to other parties on the project.

Fig. 7.29: PtDMS Console Opened through ILS toMap Product Data to the Partial Product

Model Foundation Engineering

A menu in the Design Environment provides the interface for the foundation design system PAULA with the regulation server.

Fig. 7.30: Regulation Server Interface from the GWM Environment, particularly the Founda-

tion Design System PAULA


A connection through Internet Explorer is then automatically established as shown in Fig. 7.30. By means of the interface it is possible to query the regulation server about the values of parameters contained in the regulation concerning some aspects of the design, so that the de-sign module will be able to use such parameters during the course of the foundation analysis.

7.4 Facility Management Application Tool

7.4.1 Objectives

This work package aims were at the development of a Facility Management (FM) application system and building information database supporting typical FM tasks. One of the main em-phasis of the research and development work was standardising data exchange interfaces so that the developed application system would be capable for exchanging and filtering building information between building design and construction applications in order to transfer infor-mation from earlier life cycle phases to the FM phase. FM system services end-user informa-tion needs and improves the designer’s possibility to reuse the end-user’s information.

The development is based on the current Facility management software package of KUPARI Solutions Oy. The software package is modular enabling the user to choose those modules which are needed. The modules are: CuFIMS for space management, CuESTATE for storing information of the building, CuMAINT for maintenance management, CuENERGY for managing energy consumption, CuVALUE for calculating the cash flow and estimating the value of the real estate.

Facility management software may serve different aspects of facility management. The main aspects of facility management are

• property management, • facility management of users, • technical facility management.

The use of different modules of facility management software varies depending on the desired scope.

If the emphasis is on the property management, the emphasis are to maintain the basic infor-mation of real estates, to have tools for evaluation the value of the building and bench mark-ing the profits and costs of the building, and have features that supports renting of spaces.

When the facility management system serves the users of the real estate, most important fea-tures are the parts that provides the user information of the services of the spaces, reservation of negotiation rooms etc. and information of consumption if user is responsible for them.

Technical facility management serves mainly maintenance personnel and information needs are thus service system documentation, equipment documentation such as technical performance contact data of suppliers and replacement part data, maintenance and reparation instructions.

Commercial FM systems provides different tools of which some cover only one aspect of FM and others can be used in different ways enabling them to serve several aspects of FM. The typical FM application system will provide access and various views for FM database of a building and will support typical FM processes, which are

• Space management, • Administrative purposes,


• Maintenance management, • Management of building service systems.

FM systems also include interfaces for standardised two-way data exchange with other appli-cations, e.g. for getting data from the design phase and providing data for other applications like accounting.

7.4.2 Objectives of FM Software in ToCEE

In ToCEE the FM represent an important aspect of concurrency. While other applications in ToCEE mainly handles the part of the concurrency that deals with the aspect of simultaneous work flow, the FM deals with the life cycle aspect of concurrency. FM integrated into CEE means data exchange between product model generated in design and construction phases and FM software. Based on the two-direction information transmission, the FM can also serve the designer with output data, e.g. for simulation the life cycle of the building to figure out the most effective design or when the building is renovated, for re-design purposes

The goals for the development work are divided into:

1. Short term goal: Document based FM with standardised data exchange interfaces. Aiming at short term progress constrained by current CAD design practise, an application system with standardised exchange of information in the form of e.g. technical documents and at-tached attribute information concerning spaces, equipment etc. was developed. The IFC model is used in the extent, which is found to be useful to be implemented.

2. Long term goal: The aim is to develop product data models, specifications and guidelines for migration from current practise towards future product model applications and informa-tion sharing in the form of product model data. Product modelling and product data tech-nology is an enabling technology that offers solution for information sharing between vari-ous application over the life cycle of buildings. Thus it is also a means for transfer of in-formation from design and construction to FM.

The IFC standardisation work evolved during the ToCEE project in a way that actually both short term and long term goals were met. The FM system used can handle documents and read CAD drawings in DXF format and it has separate database for real estate information. FM software can however also read IFC files and show graphics based on IFC data.

7.4.3 Implementation Alternatives for FM System

Implementation alternatives for FM System are:

1. Database System The most common way of handling real estate information is database environment. Infor-mation is collected in various databases and logical connections tie them together.

2. CAD FM implementation using existing CAD systems is usually designed in such a way that the drawing database is used as the primary database to which additional engineering informa-tion is attached. The drawing database contains mainly simple graphical objects. The engi-neering information is in the external databases and each drawing has simple link to that. The CAD-file consists of two- or three-dimensional geometrical objects and may have some non-geometrical property data attached as additional attributes to the objects.

3. Geographical Information System (GIS) GIS is specialised computer system for the storage, retrieval, analysis and display of large volume of spatial or map type data. In GIS the processing of graphical and spreadsheet data is integrated. All data in GIS needed are related to the geographic location.


4. Product Model In a product model, a building element is described by its technical (engineering) informa-tion and its three-dimensional geometry. All elements are interrelated by a topological model. This a) provides all necessary information in an integrated form and b) allows to generate any desired view of the data in tabular graphical form, in two- or three-dimensional representation.

5. Combined Product Model and Document Model System The combined product model and document model approach combines the product model and documents in a way that user interface enables end user to have access to database in-formation and documents connected to database items from the same user interface. This combination is practically necessary, because product models are still under development and therefore their scope is limited.

7.4.4 Functionality of FM System

The general purpose was to develop a FM software, which is a part of the CEE of ToCEE. The existing CuSOFTWARE FMS software of KUPARI Solutions Oy was be used as a start-ing point. The corresponding requirements described below are serving for the short term goal.

The possibility to have the whole facility management system (FMS) in one application and its capability to control different aspects of facility management through an easy and standard interface is a major advance. This offers to users tools to administrate FMS data from a single facility to a group of facilities just in a one workstation. Network support will expand those advantages for all connected workstations. This means that an user can use the FMS e.g. from a laptop workstation connected via mobile or telephone line. The system structure will be modular, so that different users may select and use only the modules they need with a possi-bility to upgrade the system if necessary. It is also possible to adjust this FMS to suit different countries including the language.

The user target group consists of end-users, which are facility managers, property managers, site managers, asset managers, maintenance managers and maintenance workers in buildings.

Themes Themes are used to control information shown in floor plans of FM system. For FM purposes there are huge amount of different objects connected to one floor plan. Usually those objects are building data, walls, areas, information of tenants and different kind of equipment. If all those objects are visible at the same time, it’s very difficult to have a clear view of the screen in a one look. To avoid that, users can create different themes (layers) for the different pur-poses. Depended of the activated theme the user sees only those objects which are defined to the current theme. Some typical themes:

• floor plans • rental areas • rate maps • electrical devices • air conditioning devices • heating devices.

Databases Beside of graphical information from the asset there are also other indispensable information in documents and databases (usually agreements, rates, maintenance directions, etc.). Capabil-ity to handle all the necessary FM information through one user interface is one of the main advantage of the FMS. The most practical manner is store the data in databases and build


links from objects in FMS document to database fields. For FM purposes there are different types of databases:

• equipment database • maintenance database • basic information of the site and the facility • space database • tenant database.

Because databases are typically quite large, the most sensible available technology that is ef-fective enough to use commercial relational databases.

Views The FMS is made to manage large maps as well as floor plans or even just rooms at a same time. It is thus important that an user can change zooming scale for the document any time. In order to do scale zooming, it is supposed that all graphics used in floor plans shall be in vector form. The selection of required facility and floor has to be quick and easy.

User Interface The FM applications will be developed into the Windows environment. Therefore the guide-lines for the user interface in Windows environment, published by Microsoft, will indicate the main guidelines for the user interface. It seems, that in the future user interfaces

like Internet web browser (e.g. Netscape Navigator and Microsoft Explorer) will become a general way to use client-server applications. They also offer a standard way to deliver docu-ments in the network.

Maintenance Management The maintenance management application takes care of the maintenance of the building ser-vice systems. To be able to fulfil this task the application has to have database containing data of the systems and equipment, maintenance instruction, maintenance timetable and track re-cord of the maintenance work done to certain equipment.

Evaluation of the Value and Profits of the Real Estate One of the main issue for the facility owners is the evaluation of the value and profit of the real estates (Life cycle calculation). The software does this by calculating the cash flow of the real estate for desired time interval and discounts them in order to have the estimation of the value. Software can also be used for budgeting the costs and incomes. The basis for the cash flow is taken from the present agreements. The future is estimated by the price-list of the pro-gressed rents and their development in the area, where the real estate is located. The energy costs and costs of the maintenance can be evaluate from the history or in case of the new building the costs can be estimated using the energy calculations made by designers. Of course possible energy saving measures will decrease these costs. The possible renovation projects can also be taken account by giving investment to certain year and modifying costs of the use after that.

7.4.5 Integration of the FM Application Tool in ToCEE

The development is based on the current CuSOFTWARE facility management software pack-age of KUPARI Solutions Oy, described in chapter 7.4.1. The CuSOFTWARE provides a FM systems that combines the management of the database and documents. In ToCEE the system is actually developed in such a way that it combines the document management to the product model using shared database.


The computer environment selected for the FM system is PC based Windows which is cur-rently used by most existing FM software modules. It brings a user-friendly, well-known in-terface associated with powerful processors and low cost platforms. The FM-software has a graphical user interface, which provides interaction and visualisation techniques including scrollable text and graphic windows, menus and dialogue boxes.

The database functions are managed by SQL (Structured Query Language), which is a lan-guage for accessing information from relational databases. SQL allows rapid access to multi-ple database files from a single command line. Relational databases is particularly functional for networked environments of the client/server variety. The nature of SQL allows for dy-namic queries, in which the resulting database can be accessed by other queries.

The FM application tool is a client-server system. The basic structure of the FM system archi-tecture is shown in Fig. 7.31. The good relationship and on-line data transfer between the dif-ferent FM software modules is implemented in OLE (Object Linking and Embedding) meth-ods, i.e. the application is based on Microsoft OLE/ActiveX technology.

Information Management level

Server level

Control level

DB interface level

SQL database

Communication to database

ActiveX control which acts as interface to FMS database

OLE serves e.g. server showing floor plan or site plan

Management level of user interface

Fig. 7.31: System Architecture and GUI Examples of the FM Application Tool


The integration of the FM application tool, in particular the communication to PtDMS and DMS is managed by tools which were developed by CIB and VTT. An overview of the im-plementation architecture is shown in Fig. 7.32. The access of the FM application tools is via the ILS (indicated by CBR in Fig. 7.32). The further connection to the Product Model is done by the Product Model Browser PROMOTE. This browser provides the browsing of the prod-uct model and extracting and importing IFC files from/to the model. The browser is imple-mented in Java. The PROMOTE browser enables to read the whole IFC file or to choose the needed part of the IFC file to the FM system. This enables for example a combination of CAD drawing and IFC objects to be read in FM system.

The access to the DMS is managed by the DMS browser. This application took care of the upload and download of the documents from/to the DMS and provided thus the link between local document management of FM system and global ToCEE document model management.

CommonRequestBroker

CommonRequestBroker

ToCEE : PM BrowserToCEE : PM Browser

Navigate

ToCEE : CuFIMSToCEE : CuFIMS

ToCEE : DM BrowserToCEE : DM Browser

KUPARI Engineering Oy- Windows NT- Java- EDM

- Windows NT- Visual C++ 4.2- MFC 5.0- MS SQL Server

IFC in/out ToCEE logon

Select objects

ToCEE : CBRToCEE : CBR

Product model adapterProduct model adapter

Document adapter

Document adapter

IFC adapterIFC adapter

ToCEE logon

L. Heikkinen & M.Hannus 12.2.1999

Facilityinformation

management... FMdatabase

Document management ...HTTP

IFC in/out

ToCEEprotocol

ToCEEPM

schema

ToCEEFM

schema

Navigate

Doc in/out

Select itemsOPB

ToCEEdocument

schema

IFCfile

View Edit

ToCEEprotocol

CIB

Documfile

Fig. 7.32: The Implementation of the FM-Software in ToCEE

The FM application tool uses the same model as other aspects models. It is an enlarged FM model, which is based on IFC version 1.5. The development of FM system for ToCEE envi-ronment gave valuable knowledge how to combine FM system to the product model gener-ated in design and construction phases of the building. A definition of the information needed in the FM phase of the building was generated and delivered in the requirements report [Heikkinen et al 1996].

In the ToCEE environment the connection of FM software to the product and document model showed that information generated in design and construction phases can directly be utilised in the FM-software, which means that sustainable amount of work can be saved and one of the greatest obstacles for using FM software can thus be reduced.


8 Migration Strategy

8.1 Market Trends and Development Concurrent engineering working based on a CEE with the features of the ToCEE system will reduce design costs up to 30 %, which sums up from • reduction of design errors due to old design information, • reduction of travel costs and time due to virtual round table meetings, • reduction of search time for design information and documents, • reduction of delays and reduction of delay times due to an optimal sequence for carrying

out activities, • reduction of wrong design decisions due to the possibilities to involve easily the right

experts and right tools at any time. Further on, the CEE allows to set up virtual design teams with members from all around the world, which means • to incorporate the best engineering knowledge, • to access the engineering knowledge at the lowest price. Based on these numbers, CE should have already penetrated the construction industry sector like a hurricane. However this was not the case at all and still is far away from being reality. What are the drawbacks? • First, we can identify that the mass of civil engineers and architects is organized in SMEs,

where the very small enterprises with one to five employees dominate the market. Thus the decision makers have multiple functionalities and therefore very little time to watch new trends and even more to estimate the impact on their daily business. As a result, they behave conservatively, which is a widely known characteristic for the construction industry.

• Second, services on the net were still crucial and net costs were too expensive. However, this has changed strongly during the last few years, strongly driven by e-commerce initia-tives and competition among the net and on-line providers. As a result, meanwhile engi-neers and architects expect a lot from this technology but cannot imagine what this might be except of e-mail and fast file transfer, i.e. fast transfer of CAD files and bill of quanti-ties, etc. via net.

• Third, most engineers and architects are not aware of these CE new ways of working and therefore no demand exists from the market for triggering according software develop-ments.

• Fourth, most engineers and architects are working independently and on their own indi-vidual scale due to the SME fact. However, CE demands strong co-operative team work-ing with a strong discipline in order to be a reliable team member.

• Fifth, investment resources are very low in the mean due to the SME fact again and the low earning rates in the construction industry.

Not technology but mentality and expectations of the buyers are the driving forces for the de-velopment of a complex new product for the market, i.e. to free the numerous necessary in-vestment costs and convince software vendors to invest in the development of the product.

The summary studies undertaken by [Katranuschkov et al 1997], which is based on studies of [CIRIA 1995], [Cragg P. B. & Zinatelli N. 1995], [Gardner P. J. 1995a] [Gardner P. J. 1995b], [Healy J. & Orr T. L. L. 1996], [Howard R. /ed./1996], [Schulz R. C. 1996], [Sørensen L. S. & Andersen T. 1996], show that the construction industry is mainly interested in the application of CAD systems (Table 8.1) and secondarily in databases and net working technologies,


Number of firms whose input has been considered in this study

US contractors

14

EU contractors

37

EU design firms 169

US design firms 134

10 - 50 57%

< 10 31%

> 50 12%

Size of design firms by number of employees

whereas other technologies for CE are of much less or even of negligible interest. The amount of firms interviewed and the distribution of their size are given in Fig. 8.1. Issue

Average percentage of use

Prevailing areas of use

Relevance to con-current engineering

Expected ten-dency

CAD systems

total

3D CAD

86% ±7%

25% *)

design

FM

collaborative work

increasing use

increasing use

Database systems 69% design construction FM

collaborative work information sharing data integrity

increasing use

Knowledge-based systems < 5% *) design collaborative work simulation, forecasting, interoperability, conflict management

increasing, but difficult to esti-mate

Groupware & WfM systems 13% ±3% design information flow controlling

increasing use

Document management systems 27% ±4% design construction FM

collaborative work information sharing responsibilities

strongly increas-ing

Product data management systems < 5% *) design collaborative work information sharing data integrity responsibilities

increasing use

Project management tools 48% ±4% construction time management resource mgmt controlling

increasing use

Networking & communication tools

LAN

Internet / WWW

60% ±8%

50% ±5%

design construction FM

information flow communication & process management

strongly increas-ing strongly increas-ing

*) the amount of analysed data was too small to allow calculation of deviations

Table 8.1: Building IT usage by category

Fig. 8.1: General data of the Building IT study


Another result to be mentioned is that the construction industry more or less exclusively uses the standard hardware and operation system technology, which is PC with Windows and NT systems (Fig. 8.2), which draws some light on the investments done in IT concerning money, know how and the project size.

UNIX5%

Others5%

Windows & NT

90%

Fig. 8.2: Operating environments

More interesting are the expectations about the benefits of IT for the user (Fig. 8.3), which is not the reduction of costs but immaterial goods like clients’ satisfaction and the improvement of image. Also the results about the expected barriers (Fig. 8.4) show that the construction industry considers mainly IT as a cost problem (hard- and software costs) and not as a human resource problem. It means that they are not aware of the new ways of working and the corre-sponding business process re-engineering efforts, which they have to undergo. This will result in a lot of training and education efforts (i.e. to close existing lacks of skills) and means a lot of motivation work to the staff for using the computer not as a computation and office work tool but as a communication, co-ordination and management tool in order to change – some-times quite extensively – their way of working.

0 1 2 3 4 5 6 7

Ranking

Increased revenue

Improved communication

Control and monitoring

Reduced overheads

Competitive advantage

Improved image

Client satisfaction

Fig. 8.3: Estimated benefits to design and construction companies from the use of IT

(0 = lowest, 10 = highest ranking)

It follows that the effective application of IT solutions supporting concurrent engineering methodology demands valuable Business Process Re-Engineering (BPR) efforts.


0 1 2 3 4 5 6 7

Ranking

Staff resistance to IT

Lack of skills

Lack of standards

Lack of gov. incentive

Acquis. of quality software

Company infrastructure

Financial limitations

Fig. 8.4: Estimated barriers to the use of IT (0 = lowest, 10 = highest ranking)

Edward Deming, who was a key figure in the establishment of a highly productive contempo-rary industrial base in Japan after the Second World War, has regularly stated over his life-time that in excess of 80% of the problems encountered in an organisation are due to failures in the management of that organisation. This view implies a complete re-think of the way in which an industry co-ordinates and integrates itself. In construction, a shift away from con-centrating on the task driven, functional control of a project towards a highly focused and integrated project process is required. BPR in construction means [Fowler & Gray 1996] „the analysis and the design of work flows and processes within organisations, between organisa-tions in the same industry sector and between related industry sectors to fulfil the require-ments of the client“. IT has a crucial role as an enabling technology in this respect. Fig. 8.5 exposes the close rela-tionships between IT and BPR in construction projects, which therefore allow the migration to a modern and effective working by introducing a CEE.

Project strategic planning Project IT planning

BPR planning

Performance modification

IT infrastructure

guide

influence align

develop

align

enable

adapt

influence

adopt

Fig. 8.5: Principal Relationship between IT and BPR on a Construction Project

/ adapted from [Grover et al 1993] /


From the technology point of view the different components, which a CEE comprises, are currently developed up to different levels. Some of them, like • data integration based on CAD data exchanging (2D) drawing information, • project management tools for presentation of the process activity network, • electronic document management for CAD drawings and standard office applications, • workflow systems based on standard documents, are highly developed and broadly applied in industry (first two items) or considerably devel-oped and increasingly applied (last two items). However, these components without the others mentioned below would only allow fast document but not engineering contents exchange (all mentioned data are representation data) because the workflow systems demand a pre-defined, detailed activity sequence, which is not appropriate for construction industry needs. CE in the sense we are speaking about needs in addition product models, information logistics and vir-tual enterprise modelling. These other components like

• product models and information based on product models, • information logistics, • virtual enterprise modelling, • responsibility modelling, • dynamic workflow and project management, • conflict management,

are still very poorly developed, not at all used in the industry and still do need considerable research efforts to solve critical problems and come up with pragmatic solutions. Nevertheless ToCEE comes up with feasible solutions and is ready for use, when standardization of the product model is sufficiently completed and agreed upon in industry. ToCEE contributed to the standardization process but had to respect the slow decision-making process, which al-ways happens when a lot of actors are involved. STEP and IFC are global standardization efforts.

Fig. 8.6: Penetration of CE Components in the Construction Market - Trends in Building

Construction taken from [Scherer 1998b]


Getting CE into operation is strongly influenced by the perspective of how these methods and methodologies will develop in the near future and what the driving forces are. This depends strongly on what the market means to need and not so much however on what would be needed for an optimal CE system. The market trends estimated from a personal market survey of the German market carried out during 1997 and 1998 by IBS are summarized in Fig. 8.6, which is due to globalization of this market – valid for other countries, too.

There the most important topics influencing a CEE are given, namely electronic document management systems (EDMS), product models (STEP or IFC), engineering workflow sys-tems, and electronic commerce components. On the abscissa the number of expected installa-tions is drawn. In Fig. 8.6 the estimated first beneficial installation identifies the starting year. This trend has been worked out in the middle of 1998 [Scherer 1998b] and Fig. 8.6 is taken from there without any change, because it is still valid. From this trend, CE systems are ex-pected to be installed in practice not before 2002. This gives on the other hand the interested firms still sufficient time to prepare themselves mentally to BPR that they will have to un-dergo.

8.2 Migration Recommendation for the Industry As a final result, some migration guidelines are proposed, based on the market perspectives given in the chapter before, the lesson learned during the development of the ToCEE system concerning technical issues as well as responses from industry and standardization bodies.

As a first step, it is recommended to introduce EDMS. They are already offered by several software vendors for the construction industry for managing standard documents, like CAD drawings and standard office software documents. It has to be carefully distinguished between systems for solely archiving purposes and those for multiple access on actual documents and archiving old versions. Some of these EDMS do already show workflow components, which may give some insight into this new technology, but these workflow systems being far away from the flexibility needed as described in this report. Therefore it is recommended to test them for gaining first experience but one should not expect to apply them beneficially, except if work sequences and related (document) information flows are repeatedly occurring in the same manner, such as it may be the case in line-oriented construction sites, like street or rail-way constructions.

As the second step, it is recommended to test product model interfaces, which are provided by the main CAD software vendors for STEP (ISO 10303-AP 225) and for IFC V1.5.1. The scope of the considered objects in IFC V1.5.1 is not too much designing a complete building but gaining experience and being prepared for this new way of working, which means 3D CAD modelling instead of the familiar 2D drafting, for which the V1.5.1 is quite suffi-cient. In spite of the announcement of the IAI that V2.xx will be published in summer 2000 and the commitment of the main software vendors to deliver product model interfaces for V2.xx until end of 2001 with full functional support of the product model capability by their CAD systems, gaining experience with V1.5.1 is of upmost importance. V2.xx will allow to model a complete building. Alternatively, the product model interfaces for a full geometric 3D modelling is already available as STEP (ISO 10303-AP225) and interfaces are provided by several software vendors. Therefore data integration and working across the Internet with different CAD systems without loss of high level information covering more than geometric information will happen in about 1.5 years from now on. Other tools will most probably fol-low very quickly in due time.

As the next step, most probably powerful workflow systems will follow. Therefore, it is rec-ommended to carefully watch the market development and gain experience with the “old-


fashioned” workflow systems, which are developed originally for banking and administration processes and have been straightforwardly transferred to construction and engineering. They are offered together with or as extensions of EDMS. This was already mentioned under the first recommended step. Further on it is recommended to take part in training courses for the new arising engineering workflow systems. They are already offered for the mechanical in-dustry with a continuous increase in quality and quantity. An adaptation of these systems to the construction industry needs will most probably happen and may value the effort. How-ever, due to different culture and the many specifics of the construction industry, as ToCEE taught us, these engineering workflow systems will not sufficiently fulfil the needs of the con-struction industry and new system will probably have to be developed. Finally, the newly de-veloped system may dominate the market but in the transition time, engineering workflow systems adapted from the mechanical engineering industry are a good choice, because this transition time will last between 3 and 7 years from now on, depending on the different appli-cation areas within the construction industry until new systems will be provided.


9 Glossary Abbreviation Description AEC Architecture, Engineering and Construction AFC AUTOCAD Foundation Classes AP Application Protocol API Application Programming Interface BLOB Binary Large OBject BPR Business Project Re-engineering CAD Computer Aided Design / Drafting CAAD Computer Aided Architectural Design CAE Computer Aided Engineering CDF Comma Delimited Format (used by file import/export in database technology) CE Concurrent Engineering CEE Concurrent Engineering Environment CGI Common Gateway Interface CLOS Common LISP Object System CORBA Common Object Request Broker Architecture CMS Conflict Management Server CRB Common Request Broker DMS Document Management System DB Data Base DCOM Distributed Common Object Model (developed by Microsoft) DWG Drawing (AutoCAD drawing file) DXF Drawing eXchange Format (owned by AutoCAD) EDM Electronic Document Management EDMS Electronic Document Management System FEA Finite Element Analysis FM Facility Management FMS Facility Management System GIS Geographic Information System GLENET Global Engineering Network GUI Graphical User Interface GWM Ground Work Module href Hypertext reference flag in an HTML document HTML Hypertext Mark-up Language HTTP Hypertext Transfer Protocol HVAC Heating, Ventilation and Air Conditioning IAI International Alliance for Interoperability, a construction industry association with

over 600 members worldwide IC Info Container ID Identification Number/object identifier IDL Interface Definition language for CORBA IFC Industry Foundation Classes (Project Model for building construction developed by IAI)


IL Information Logistics ILS ToCEE’s Information Logistics Services IP Internet Protocol IT Information Technology JVM JAVA Virtual Machine KEE Knowledge Engineering Environment MFC Microsoft Foundation Classes NDM Neutral Document Model NPsM Neutral Process Model NPtM Neutral Product Model OLE Object Linking and Embedding OMG Object Management Group ORB Object Request Broker (term introduced in CORBA) oref object reference PTDM Product Data Management PDT Product Data Technology

PGP "Pretty good privacy", a software tool for e-signature with the asymmetric public -key signature method

PM Project Management PtDMS Product Data Management Server PsDMS Process Data Management Server RMI Remote Method Invocation RPC Remote Procedure Call RSA public-key signature method created by Rivest-Shamir-Adleman

RTF Rich Text Format

SDAI Standard Data Access Interface (ISO 10303-22)

SDF Space Delimited Format (used by file import/export in database technology)

SIOP Server InterOperability Protocol SPF Step Physical File (ISO 10303-21)

SQL Structured Query Language

STEP The international Standard for the Exchange of Product Data (ISO 10303) TC Transmission Control

TCP/IP Transmission Control Protocol / Internet Protocol (the basic communication protocol used in the Internet)

T-PINS Technical Product INformation System UML Unified Modelling Language UPRL Universal Project Resource Locator URL Uniform Resource Locator VR Virtual Reality VRB Virtual Reality Browser VRML Virtual Reality Modelling Language WP Work Package WWW World Wide Web


IST Information Society Technology, the R&D Framework Programme of the CEC for 1999 – 2003

CEC Commission of the European Communities

Definition of some items: Activity One or more tasks carried out by on or more different experts from one or

more different disciplines. It is comparable to a workflow. Workflow One or more activities

Worktask One or more tasks for which one person or one institute (one role) is respon-sible. They may be carried out by one or more different experts instantiated for that role.

Process template Generic workflow. Same as workflow template provided through a workflow library.


10 References

10.1 Paper References Augenbroe 1995

Augenbroe G. (ed.) 1995): COMBINE 2 Final Report. EU / CEC Joule Programme, Project JOU2-CT92-0196, TU Delft, Netherlands.

Böhms & Storer 1994

Böhms M. & Storer G. 1994: ATLAS – Architecture, methodology and Tools for computer-integrated Large Scale engineering, Proc. JSPE-IFIP WG 5.3 Workshop, DIISM'93, Tokyo, Japan.

CIRIA 1995

CIRIA 1995, IT in Construction: Quantifying the Benefits, CIRIA/CICA Report.

Cragg P. B. & Zinatelli N. 1995

Cragg P. B. and Zinatelli N., The Evolution of Information Systems in Small Firms, Informa-tion and Management 29/1995, pp. 1-8.

Eastman 1988

Eastman C. 1988: Conceptual Modeling of Buildings. Review, in: P. Christiansson, H. Karls-son (eds) „Conceptual Modelling of Buildings“, CIB Publ. 126, Swedish Building Center, Solna, Sweden.

Fowler & Gray 1996

Fowler C.E.A., Gray C. 1996, The Effective Application of Information Technology in Busi-ness Process Re-Engineering, in: Kumar B. and Retik A. (eds) „Information Representation and Delivery in Civil and Structural Engineering Design“, Civi-Comp Press, Edinburgh.

Gardner P. J. 1995a

Gardner P. J. 1995, IT in Structural Engineering (Results of the Members’ Survey on IT and Computers), The Structural Engineer 73(21), 7/95.

Gardner P. J. 1995b

Gardner P. J. 1995, The Infiltration of Information Systems in Engineering Consultancies, in: Pahl P. J. & Werner H. (eds.) “Computing in Civil and Building Engineering”, Proc. 6th Int. Conf. on Computing in Civil and Building Engineering VI-ICCCBE, Berlin 12-15 July, Balkema, Rotterdam, The Netherlands, pp. 911-916.

Gielingh 1988

Gielingh W. 1988: General AEC Reference Model, TNO Report, B1-88-150, Delft, Nether-lands.

Grover et al 1993

Grover V., Teng J.T.C., Fiedler K.D. 1993, Information Technology Enabled Business Proc-ess Redesign: An Integrated Planning Framework, Int. J. of Management Science, 21(4)


Gruber 1993

Gruber T.R. 1993. Towards principles for the design of ontologies used for knowledge-sharing, in Guarino N. and Poli R. (eds.), Formal Ontology in Conceptual Analysis and Knowledge Representation, Kluwer Academic Publ., Deventer, The Netherlands.

Healy J. & Orr T. L. L. 1996

Healy J and Orr T. L. L. 1996, Information Technology Use in Consulting Engineering Firms in the Republic of Ireland, in: Kumar B. & Retik A. (eds.) “Information Representation and Delivery in Civil and Structural Engineering Design”, Civil-Comp Press, Edinburgh, UK, pp. 163-170.

Heikkinen et al 1996

Heikkinen L., Niukkala J., KarstilaK., Sparacello H.-M., Chassapakis I. 1996, Facility Man-agement – Requirements, Report C 1 (restricted), Uni. of Technology Dresden, Inst. of Ap-plied Computer Science in Civil Engineering, Dresden, Germany.

Hemiö & Hannus 1999

Hemiö T. & Hannus M., Implementing Browsing Tool for EXPRESS Schemata and STEP Data, “Product Data Technology Europe 1999, 8th Symposium”, Proc. of the PDT Days 15th & 16th April 1999, Stavanger, published by Quality Marketing Services, Sandhurst, UK.

Howard R. /ed./1996

Howard R. 1996, Building IT 2005, Construction IT Forum Res. Report, ICE, Thomas Tel-ford Electronic Publ., London, UK.

Hyvärinen et al 1997

Hyvärinen J., P. Katranuschkov and R.J. Scherer 1997. Product model and interoperability management tools,Report F 2.1, (confidential), University of Technology, Inst. of Applied Computer Science in Civil Engineering, Dresden, Germany.

Hyvärinen et al 1999

Hyvärinen J., Katranuschkov P., Heimiö T., Scherer R. J. 1999, Product Modelling and Inter-operability – Documentation of the Server and Tools, Report F 4 (public) Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering,, April 1999.

IAI 1997

IFC Object Model for AEC Projects, 1997. IFC Release 1.5 Model Reference Documentation, Final Version, IAI Publ. Washington, DC, USA.

Ingenbleek 1998

Ingenbleek B. 1998, Product Modelling and Interoperability – The ToCEE STEP Toolbox, Report F 3 (confidential), Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, March 1998.

ISO 10303-28 WD 1999

Industrial Automation Systems and Integration – Product Data Representation and Exchange – Part 28: Implementation Methods: XML Representation for EXPRESS-driven Data, ISO TC 184/SC4, NIST, Gaithersburg, MD, USA.


ISO 10303-41

ISO 10303-41, 1998 Product Data Representation and Exchange – Part 41: Integrated Re-cources: Fundamentals of Product Description and Support, International Organisation for Standardization, ISO_TC 184/SC4, NIST, Gaitherburg, MD, USA.

ISO 1994a

ISO 10303-1 IS 1994. Product Data Representation and Exchange - Part 1: Overview and fundamental principles, ISO TC 184/SC4, Geneva, Italy.

ISO 1994b

ISO/TC184/SC4/WG5/N202 1994, PISA Information Modelling Language.

Katranuschkov 1995

Katranuschkov P. 1995. COMBI: Integrated Product Model, In: Scherer R.J. (ed.) Proc. 1st European Conference on Product and Process Modelling in the Building Industry, Balkema Publ., Rotterdam, Netherlands.

Katranuschkov 2000

Katranuschkov P 2000. Modelling the Concurrent Engineering Environment, PhD thesis, Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, Dresden, Germany.

Katranuschkov et al 1997

Katranuschkov P., Scherer R. J., Clift M. 1996, Migration Perspectives towards Concurrent Engineering, Report J1, Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, Dresden, Germany.

Katranuschkov & Hyvärinen 1998

Katranuschkov P. and Hyvärinen J. 1998. Product Data Server for concurrent engineering in AEC, in Amor R. (ed), Proc. of the 2nd European Conference on Product and Process Model-ling in the Building IndustryBuilding Research Establishment, Watford, Great Britain.

Katranuschkov & Scherer 1996

Katranuschkov P., Scherer R.J. 1996, Schema Mapping and Object Matching: A STEP-Based Approach to Engineering Data Management in Open Integration Environments, In: Turk Z. (ed), Construction on the Information Highway, Proc. of the CIB W78-96 Workshop Con-struction on the Information Highway, Uni. Of Ljublana Dept. of Structural and Earthquake Engineering, Slovenia.

Katranuschkov & Scherer 1997

Scherer R.J., Katranuschkov P. 1997, Framework for Interoperability of Building Product Models in Collaborative Work Environments, Proc. of the 8th International Conference on Civil and Building Engineering, pp. 627 - 632, C.-K. Choi, C.-B. Yun, H.-G. Kwak (eds.), Seoul, Korea, 1997

Katranuschkov & Scherer 1999, Den Haag

Scherer R.J., Katranuschkov P. 1999, Knowledge-Based Enhancements to Product Data Server Technology for Concurrent Engineering, ICE 99, Den Haag.


Kiliccote et al 1996

Kiliccote H., Garrett, J.H. and Fenves, S.J. 1996. A Standards Processing Framework, In B. Kumar (ed), Information Processing in Civil and Structural Engineering Design, Civil-Comp Press, 127-132.

Koster 1995

Koster, M. 1995, Robots in the Web: threat or treat? ConneXions, Volume 9, No. 4.

Luiten et al 1993

Luiten G., Froese T., Björk B-C., Cooper G., Junge R., Karstila K. & Oxman R. 1993: An information reference model for architecture, engineering and construction, in Mathur K.S., Betts M.P., Tham K.W. (eds) „Management of information technology for construction“, World Scientific Publishing, Singapore.

Rethfeld 1996

Rethfeld U. 1996. GEN vision and major concepts, In: Proc. 1st European Workshop on Global Engineering Networking, Paderborn, Germany.

Ott 1998

Ott, E. 1998. The building site without paper – legal aspects in an IT-environment, in Björk Bo-Christer and Jägbeck Adina (eds.), the life-cycle of construction IT Innovations, , Pro-ceedings of the CIB Working Commission W78, Information Technology in Construction Conference, June 1998, Royal Institute of Technology, Stockholm, Sweden.

Scheer, 1998

Scheer A.-W. 1998. Business process engineering, Springer-Verlag, Germany.

Scherer 1997

Scherer R.J. 1997 Legal Framework for a Virtual Enterprise in Building Industry, Proc. of the 4th International Conference on Concurrent Enterprising, pp. 373 - 384, K.S. Pawar (ed.), Not-tingham.

Scherer, 1998a

Scherer R.J., AI methods in concurrent engineering, in: Ian Smith (ed.) Artificial intelligence in structural engineering, Lecture note in AI, Vol. 1454, Springer 1998, Germany, 1998.

Scherer 1998b

Scherer R.J. 1998, A Framework for the Concurrent Engineering Environment. In Amor R. (ed), Proc. of the 2nd European Conference on Product and Process Modelling in the Building Industry, Building Research Establishment, Watford, Great Britain.

Scherer 1998c

Scherer R., 1998, Concurrent Engineering – Scope and Demands, Workshop on Concurrent Collaborative Working Erastos Filos, European Community, DG III/F/7, Integration in Manu-facturing.

Scherer 2000

Scherer R. J., Towards a Personalized Concurrent Engineering Internet Service Platform, In: Goncalves R., Steiger-Garcao A., Scherer R. J. (eds), Product and Process Modelling in Building and Construction, Balkerna Publ., Rotterdam, Netherlands.


Scherer & Sparacello 1996

Scherer R. J., Sparacello H.-M. (eds). 1996: COMBI Final Report., Uni. of Technology Dres-den, Inst. of Applied Computer Science in Civil Engineering, Dresden, Germany.

Schulz R. C. 1996

Schulz R. C. 1996, Computer Mediated Communications in Architecture, Engineering and Construction, Res. Report, Dept. Civil Eng., Cal. State. Univ., CA.

Sørensen L. S. & Andersen T. 1996

Sørensen L. S. and Andersen T. 1996, The Current State of Computing in Building Design and Construction: A Detailed Survey, in: Kumar B. & Retik A. (eds.) “Information Represen-tation and Delivery in Civil and Structural Engineering Design”, Civil-Comp Press, Edin-burgh, UK, pp. 171-176.

Turk 1998a

Turk Z. 1998. Regulation Server for Building Construction, in Amor R. (ed), Proc. of the 2nd European Conference on Product and Process Modelling in the Building Industry, Building Research Establishment, Watford, Great Britain.

Turk 1998b

Turk, Z. 1998, On theoretical foundations of CAD, in I. Smith (ed), Artificial Intelligence in Structural Engineering, Lecture note in AI, Vol. 1454Springer Verlag, Berlin, Germany.

Turk et al 1997

Turk Z., Wasserfuhr R., Katranuschkov P., Amor R., Hannus M., Scherer R.J. 1997, Concep-tual Modelling of a Concurrent Engineering Environment, in: Anumba C.J. & Evbuomwan N.F.O. (eds.) Concurrent Engineering in Construction, ISBN 1 874266 35 2, Institution of Structural Engineers, London, June 1997

Wasserfuhr 1998

Wasserfuhr R. 1998. Shared process models for distributed co-operative engineering, in Amor R. (ed), Proc. of the 2nd European Conference on Product and Process Modelling in the Build-ing Industry, Building Research Establishment, Watford, Great Britain.

Wasserfuhr & Scherer 1997

Wasserfuhr R. and Scherer R.J. 1997. Process models for information logistics in the concur-rent building life cycle, in Pawar K.S. (ed.), Proc. 4th Int. Conf. on Concurrent Enterprising, Nottingham, Great Britain.

Wasserfuhr, Scherer 1999

Wasserfuhr R. & Scherer R.J. 1999 Process and Information Logistic Services – Documenta-tion of the Server and Tools, Report on Task E 4 (public), University of Technology Dresden, Inst. Of Applied Computer Science in Civil Engineering, Dresden, Germany.

Watson & Crowley 1995

Watson A. & Crowley A. 1995: CIMsteel Integration Standards, in Scherer R.J. (ed) "Product and Process Modelling in the Building Industry", Proc. of the 1st European Conf. on Product and Process Modelling in the Building Industry, Dresden, Germany, Balkema, pp 491-494.


10.2 Internet References IAI 1999

International Alliance for Interoperability. http://www.interoperability.com

ISO 1998

International Organisation for Standardisation, TC184/SC4. STEP – Standard for the Ex-change of Product Data. http://www.nist.gov/sc4.

Moz99

Mozart Consortium. The Mozart Programming System. http://www.mozart-oz.org .

OMG98

Object Management Group. CORBA- http://www.omg.org/corba/corbaiiop.html .

Sun98

Sun Technologies. RMI - Remote Method Invocation. http://java.sun.com/products/jdk/1.1/docs/guide/rmi/.

W3C99

The W3 Consortium. HTTP– Hypertext Transfer Protocol. http://www.w3.org/Protocols/.

http://cwis.kub.nl/frw/people/koops/digsig.htm#g, Digital signature legislation

Towards A European Framework for Digital Signatures And Encryption, http://www.ispo.cec.be/eif/policy, status: 12th January 1998

http://www.digicash.com/publish/digsig,/digbig.htm, DigiCash, Digital Signatures and Smart Cards

http://www.pca.dfn.de/dfnpca/pgpkserv

http://www.rsa.com/about/

http://www.ifi.uio.no/pgp/

http://www.iid.de/rahmen/iukdgk.html

http://gs213.sp.cs.cmu.edu/prog/webster

The ToCEE homepage with additional infos, links and technical specifications can be found at http://wwwcib.bau.tu-dresden.de/tocee


10.3 Public ToCEE Reports Clift M., Amor R., Teichmann H., Document Modelling - Documentation of the Server and Tools, Report G 4 (public), Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, April 1999.

Heikkinen L., Niukkala J., Hyvärinen J., Heimiö T., Facility Management - Documentation of the Client and Tools, Report C 6 (public), Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, March 1999.

Hyvärinen J., Katranuschkov P., Heimiö T., Scherer R. J., Product Modelling and Interopera-bility - Documentation of the Server and Tools, Report F 4 (public) Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, April 1999.

Katranuschkov P., Scherer R. J., Clift M., Migration Perspectives towards Concurrent Engi-neering, Report J1, Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, December 1996.

Ott E., Legal Model - Documentation, Report D 6 (public), Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, March 1999.

Rekounotis T., Balder R., Design Process - Documentation of the Client and Tools, Report A 6 (public), Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineer-ing, March 1999.

Scherer R. J. Ed., A Concurrent Engineering IT Environment for the Building Construction Industry – Concepts - Annual Report 1997, Report K 4.1, Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, March 1998.

Scherer R. J. Ed., A Multi-tier Client-Server System for Concurrent Engineering – Migration and Final Report J2, Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, February 2000.

Scherer R. J. Ed., Overview of Requirements and Vision of ToCEE - Annual Report 1996, Report K 1.2, Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engi-neering, February 1997.

Scherer R. J., Katranuschkov P., Oertel J., Salonen M., Hemiö T., Conflict Management - Documentation of the Server and Tools, Report H 4 (public), Uni. of Technology Dresden, Inst. of Applied Computer Science in Civil Engineering, April 1999.

Scherer R. J., The ToCEE Client-Server System for Concurrent Engineering, Uni. of Tech-nology Dresden, Inst. of Applied Computer Science in Civil Engineering, January 2000.

Turk Z., Modelling of Design Standards and Building Codes - Documentation of the Server and Tools, Report on Task I 4 (public), Uni. of Technology Dresden, Inst. of Applied Com-puter Science in Civil Engineering, April 1999.

Wasserfuhr R., Scherer R. J., Process and Information Logistic Services –Documentation of the Server and Tools, Report on Task E 4 (public), Uni. of Technology Dresden, Inst. of Ap-plied Computer Science in Civil Engineering, April 1999.