towards a concurrent engineering environmentitc.fgg.uni-lj.si/toceecd/reports/final-f.pdf ·...

ESPRIT Project No. 20587

Towards a Concurrent Engineering Environment

WORKPACKAGE F

PRODUCT MODELLING AND

INTEROPERABILITY

FINAL REPORT

DELIVERABLE: F4

AVAILABILITY: PUBLIC

PARTNERS OWNING: VTT, CIB, SOF

DATE: APRIL 10, 1999

Authors: Juha Hyvärinen, Peter Katranuschkov, Tero Hemiö

ESPRIT Project No. 20587 ToCEE Deliverable F.4 ii

CONTENTS

SYNOPSIS.............................................................................................................................................................1

1. INTRODUCTION .......................................................................................................................................3

2. CONCEPTS.................................................................................................................................................7

CONCEPTUAL DESIGN OF THE PRODUCT MODELLING FRAMEWORK..................................................................7

OPERATIONAL INTEROPERABILITY ................................................................................................................11

SEMANTIC INTEROPERABILITY ......................................................................................................................12

FUNCTIONAL INTEROPERABILITY ..................................................................................................................13

PRINCIPAL INTERRELATIONSHIPS OF THE INTEROPERABILITY SERVICES IN THE TOCEE ENVIRONMENT...........17

3. IMPLEMENTATION ...............................................................................................................................19

OVERVIEW...................................................................................................................................................19

THE PRODUCT DATA MANAGEMENT SERVER PROMISE...............................................................................19

THE PRODUCT MODEL BROWSER PROMOTE .................................................................................................29

APPLICATION INTERFACES TO THE PRODUCT DATA MANAGEMENT ENVIRONMENT ........................................36

4. CONCLUSION..........................................................................................................................................38

APPENDICES ....................................................................................................................................................39

APPENDIX I. REFERENCES...........................................................................................................................39

APPENDIX II. RELATED WORK......................................................................................................................42

APPENDIX III. FORMAL SPECIFICATIONS USED IN THE TOCEE PDM ENVIRONMENT.......................................44

ESPRIT Project No. 20587 ToCEE Deliverable F.4 iii

List of figures

FIG. 1: INFORMATION EXCHANGE SCENARIOS IN AEC/FM SUPPORTED IN THE TOCEE ENVIRONMENT.......................4

FIG. 2: OVERVIEW OF THE TOCEE MODELLING FRAMEWORK...................................................................................9

FIG. 3: PRINCIPAL SCHEMA OF THE OPERATIONAL FRAMEWORK..............................................................................11

FIG. 4: DESIGN INTERACTION EXAMPLE FOR THE USE OF MODEL MAPPING AND MODEL MATCHING ..........................14

FIG. 5: INTERRELATIONSHIPS OF THE FUNCTIONAL MODEL AND DATA TRANSFORMATIONS ......................................16

FIG. 6: USE OF THE PRODUCT DATA MANAGEMENT FUNCTIONS FOR PROJECT CO-ORDINATION .................................17

FIG. 7: THE PDM ENVIRONMENT ARCHITECTURE IN TOCEE..................................................................................20

FIG. 8: EXAMPLE FOR TRIGGERING A RULE-BASED METHOD FROM A CLIENT APPLICATION .......................................22

FIG. 9: FUNCTIONAL COMPONENTS OF PROMISE/M .............................................................................................22

FIG. 10: THE GRAPHICAL USER INTERFACE OF PROMISE .......................................................................................26

FIG. 11: SCREENSHOT OF THE MAIN MENU OF PROMISE ........................................................................................27

FIG. 12: CASCADING NAVIGATION THROUGH A PRODUCT MODEL WITH THE GUI OF PROMISE................................27

FIG. 13: COMBINED GEOMETRIC VIEW OF THE ARCHITECTURAL AND THE FOUNDATION MODEL OF A BUILDING

RETRIEVED FROM PROMISE .................................................................................................................28

FIG. 14: EXAMPLE GENERIC CLIENT IMPLEMENTING THE PROMISE API.................................................................29

FIG. 15: CLASS HIERARCHY USED IN SCHEMA PARSING WITH PROMOTE ..................................................................29

FIG. 16: STRUCTURE OF THE 'SCHEMA' OBJECT .......................................................................................................29

FIG. 17: EXPRESS SCHEMA BROWSING .................................................................................................................30

FIG. 18: ADDITIONAL DEFINITIONS FOR JAVA CLASSES IN PROMOTE.......................................................................31

FIG. 19: DATA BROWSING WITH PROMOTE ............................................................................................................32

FIG. 20: CONTENT HIERARCHY VIEW TO THE DATA IN PROMOTE.............................................................................33

FIG. 21: VIRTUAL REALITY BROWSER AS AN INTERFACE TO PROMOTE PRODUCT DATA BROWSER ............................34

FIG. 22: PROMOTE CLIENT/SERVER FUNCTIONALITY .............................................................................................35

FIG. A.III-1: SCREENSHOTS OF THE INHERITANCE GRAPH OF SCHEMA TC_PRODUCT_MODEL ....................................72

List of tables

TABLE 1: CONCURRENT ENGINEERING FEATURES AND THEIR IMPLICATIONS TO PRODUCT DATA MANAGEMENT..........6

TABLE 2: CATEGORIES OF PDM SERVICES ENABLED BY PROMISE AND RESPECTIVE FUNCTIONS DEFINED IN THE

SERVER API ..........................................................................................................................................25

TABLE A.II-1: SUMMARY OF RELATED R&D PROJECTS AND STANDARDISATION WORK ...........................................42

TABLE A.III-1: UNITS OF MEASURE FOR THE TOCEE DEMO ENVIRONMENT .............................................................46

TABLE A.III-2: PROPERTY SET DEFINITIONS FOR THE TOCEE DEMO ENVIRONMENT.................................................48

TABLE A.III-3: FUNCTION SPECIFICATION FOR THE PROMISE API, V.1.0.4............................................................67

ESPRIT Project No. 20587 ToCEE Deliverable F.4 iv

List of abbreviations

Abbrev. Description

AEC − Architecture, Engineering and Construction

AI − Artificial Intelligence

AP − Application Protocol

API − Application Programming Interface

BCCM − Building Construction Core Model (STEP Part 106)

CAE/CIC − Computer Aided Engineering / Computer Integrated Construction

CE − Concurrent Engineering

CEE − Concurrent Engineering Environment

CMS − Conflict Management Services

CRB − Common Request Broker(this term used in the Information Logistics in ToCEE is borrowed from CORBA –the common object request broker architecture developed by the OMG)

DMS − Document Management System

FM − Facility Management

HVAC − Heating, Ventilation and Air Conditioning

IAI − International Alliance for Interoperability(over 600 organisations in the AEC/FM industry including architects, engineers,contractors, building owners and managers, building product manufacturers, softwarevendors, information providers, government agencies, research labs and universities)

IFC − Industry Foundation Classes(Core Project Model for building construction being developed by the IAI)

IL − Information Logistics

ILS − ToCEE’s Information Logistics Services

IT − Information technology

NDM − Neutral Document Model

NPsM − Neutral Process Model

NPtM − Neutral Product Model

PsMS − Process Management System

PtDMS − Product Data Management System

PDM − Product Data Management

PDT − Product Data Technology

RPC − Remote Procedure Call

STEP − The international Standard for the Exchange of Product Data (ISO 10303)

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

WP − Work package

ESPRIT Project No. 20587 ToCEE Deliverable F.4 v

The ToCEE Partners

Acronym Full Name FunctionalRole

Role in ToCEE

Address

OPB − Obermeyer Planen + Beraten design consultant,in-house softwaredevelopment

coordinator Hansastr. 4080686 MünchenGermany

BRE − Building Research Establishment research agency partner Bucknalls LaneGarston, WatfordHERTS, WD27JRUK

CIB − Computeranwendung imBauwesen,Technical University Dresden

academic partner Mommsenstr. 13Inst. für Baumech.und BauinformatikTU Dresden01062 DresdenGermany

DAP − D’Appolonia design consultant,in-house softwaredevelopment

partner Via San Nazaro 19GenovaItaly

GCC − General Construction Company contractor partner Kapodistriou St. 3015123 Maroussi -AthensGreece

ISE − Institute of Structural andEarthquake Engineering,University Ljubljana

academic partnerthroughCOPERNICUS

Jamova 2FGG,Univ. LjubljanaSI-61000 LjubljanaSlovenia

KU − KUPARI Oy design & FMconsultant,in-house softwaredevelopment

partner Myyrmäenraitti 2PO Box 3101601 VantaaFinland

OTT − Dr. OttLawyer, civil and industr. eng.

lawyer office(constr. &computer law)

partner Vorhölzerstr. 2181477 MünchenGermany

SOF − SOFISTIK Hellas software vendor partner 3rd Septembriou 5610433 AthensGreece

VTT − VTT Building Technology research institute partner Kemistintie 3PO Box 1800FIN-02044 EspooFinland

ESPRIT Project No. 20587 ToCEE Deliverable F.4 1

SYNOPSIS

The overall goal of WP F Product Modelling and Interoperability has been to develop amodelling infrastructure and generic facilities to enable collaborative work in a concurrentengineering environment (CEE).

The operational framework of the ToCEE environment is based on a multi-tier client-serverapproach. It is comprised of a set of dedicated servers for product, process, document, conflictand regulations management with a centralised information logistics system (including acommon request broker for the whole environment, and a set of client applications for selecteddesign and construction tasks). In order to achieve interoperability and co-ordinated use, allcomponents commit to a common project ontology which includes:

• the use of a common modelling paradigm based on STEP/EXPRESS,• the use of a common meta model,• a set of explicitly defined, shareable, high-level modelling concepts,• a set of explicitly defined common interface specifications, including the ToCEE

InfoContainer API for client-server communication.

The overall modelling framework is based on the IFC project model specification (Release 1.5final), but with considerable enhancements to account for the recognised concurrent engineeringfeatures:

• Collaborative work,• Concurrency,• Inter-discipline communication and information sharing,• Life cycle management,• Consideration of responsibilities.

For the benefit of a consistent modelling approach, an explicit meta model is used for setting upthe basic principles for development of the individual Product, Process and Document models,and the supporting Conflict and Contract models. The domain views represented in the productdata model include Architectural, HVAC, Structural and Foundation design as well as Facilitymanagement.

Methods have been developed for generic access/modification of the product data both formodel-based STEP physical file data exchange and for direct SDAI-like manipulation ofmodelling objects. Model interoperability and consistency is supported through knowledge-based methods including mapping, matching, merging of partial models. All developed methodsare explicitly specified on the basis of EXPRESS-C and can be invoked remotely in platform andlanguage independent way by using the ToCEE InfoContainer API.

The software tools prototyped in the workpackage include:• a general purpose server for product data management (PROMISE),• a general purpose product model browser (ProMoTe),• a set of dedicated client adapters servicing the architectural, structural analysis,

foundation design and facility management applications integrated in the ToCEEenvironment.

PROMISE supports TCP/IP, Java RMI and CORBA IDL based communication. It allowsproduct data processing both on full model and individual modelling object level and enablesapplication integration and collaborative work through a set of generic operations bundled in theserver API which has been specified and implemented on top of the common ToCEEInfoContainer API. The server incorporates also several specific operations dedicated to theToCEE implementation of the IFC project model.


ProMoTe supports TCP/IP and Java RMI based communication. It makes full use of the serverAPI to access the product data repository, but can as well be used in stand-alone mode throughits comprehensive GUI offering schema and model import/export functionality. The schemabrowsing features of ProMoTe provide tools for schema development and maintenance. Databrowsing and visualisation features (including VRML, spreadsheet and HTML support) can beused both directly by end-users to examine the product data and in more sophisticated client-sideoperations such as the recognition of changes done to a product model. ProMoTe incorporatesalso lightweight client-server functionality allowing distributed work over the Internet.

Product data management clients for the selected ToCEE applications have been implementedusing different strategies in order to test, verify and evaluate the developed integration platformfor CEE. The architectural and structural analysis applications use the ToCEE Step Toolbox forSTEP data exchange together with a general Information Logistics Client with embeddedproduct data management functionality based on the InfoContainer API. The foundation designapplication implements directly and exclusively the ToCEE InfoContainer API includingadvanced functions for model mapping, rule-based search etc. The facility managementapplication uses ProMoTe as a dedicated front-end server for the application, i.e. the access toPROMISE is realised exclusively with the help of ProMoTe, whereas the application itselfsupports local STEP physical file data exchange based on the ToCEE FM aspect model.

In addition, there has been developed a light-weight generic client which allows to test theavailable server operations explicitly, and a general purpose applet developed in workpackage Efor accessing the Information Logistics Server can be used to access the PDM server as well.


1. INTRODUCTION

As understood today, concurrent engineering implies collaborative, parallel product and processdesign, advanced project management, consideration of the whole product life cycle, effectivecommunication and information sharing across disciplines and phases of the product’sdevelopment and adequate consideration of responsibilities. Thus, concurrent engineering meansmore than merely achieving high parallelisation of individual project activities (Scherer 1998).

To a certain extent concurrent engineering is the way the building industry operates today.However, its implications to design and construction practice and especially to building IT arenot yet fully understood. Hence, today’s software tools still provide only little support for aconcurrent engineering based way of work.

Building construction projects are characterised by one-of-a-kind products (buildings andfacilities) and one-of-a-kind project set-ups. Communication and information sharing needs aretypically between different disciplines, between different organisations and between differentkinds of applications. Because of varying organisational modes of AEC projects and varyingresponsibilities of disciplines data exchange needs may also vary from project to project.However, the current use of IT in building construction is limited primarily to computer-aidedproduction of documents and presentations, with some support for information managementusing databases related to structured CAD-models. In some narrow areas, like structural designof steel and reinforced concrete structures, product model applications are used to developstructural models from which working documents (drawings, bill-of-materials, etc.) aregenerated, but there is not much integration to other applications (e.g. architectural design orstructural analysis). CAD data exchange between disciplines is primarily done on the level ofexchanging drawings using de facto standard formats DWF or DXF and using native toolformats for other type of documents, like specifications, schedules etc. Thus, the differentinformation 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, on the other hand, there have been considerable efforts invested in theconceptual specification and the development of integration models and services. In the late1980s a number of researchers (e.g. Eastman 1988; Gielingh 1988) have introduced product datatechnology (PDT) in construction and have suggested it as a key approach for informationexchange and sharing in A/E/C projects. Several European projects like ATLAS (Boehms &Storer 1994), CIMsteel (Watson & Crowley 1995), COMBI (Scherer & Sparacello 1996),COMBINE (Augenbroe 1995) etc. have developed prototype product modelling environmentsproving the validity of the approach and stimulating further research, standardisation andimplementation activities. In the IRMA model (Luiten et al. 1993) a first attempt has been madeto join product and process models for building construction in a unified modelling frameworkon the basis of PDT. Today, with the IFC project model developed within the industrial IAIinitiative (Herold 1997) product data technology stands on the threshold of its practicalimplementation in integrated building construction environments.

However, what is still missing is the treatment of all information - product as well as processinformation, documents, users, software, hardware - as a whole consistent system forconcurrency in which interoperability and co-ordination issues are efficiently resolved.

To help tackle such issues this workpackage of ToCEE has been focusing on the basicrequirements and concepts for PDT from the point of view of concurrent engineering, themodelling and interoperability issues in a multi-server/client environment and the specificproduct data services for concurrent engineering support.


In this context, the overall goal of WP F Product Modelling and Interoperability has been todevelop the enabling modelling infrastructure and generic facilities for collaborative work in aconcurrent engineering environment.

The basic objectives of the workpackage have been to develop concepts and tools that providesupport for:• Information sharing across disciplines and life-cycle phases like design, construction and

facility management within the scope of selected prototype concurrent engineering scenarios• Interoperability in heterogeneous product / process / document based environments.

A further objective in a more narrow practical scope has been to provide support for theinformation requirements of each of the Application Workpackages (A-C) and the other Tooldevelopment Workpackages (E-G) in the ToCEE project through adequate aspect modelscapturing the specific information requirements into product data model representations of therespective domain.

The modelling infrastructure developed to support these objectives consists of:• An integration framework containing a set of layered product data models• Methods for intraoperability between the separate product models• Methods for interoperability between product models and other models presentations of

information (process and document models and HTML, VRML, DXF etc.) as well as withthe ToCEE information logistics services.

On a generic level, the product modelling framework aims to cover the whole life-cycle ofbuilding complexes developed in large scale engineering projects, i.e. buildings, buildingsections and building site, including all basic aspects of information sharing in a concurrentengineering environment. On a more detailed level, the focus has been on the domains of theApplication Workpackages A, B and C, i.e. the design process for reinforced concrete buildings,the construction activities for geotechnical works on the construction site and facilitymanagement including e.g. space management, planning of maintenance, cost management asshown in Fig. 1.

Documents Drawings

Structured CAD data Product data

BUILDING DESIGN

CONSTRUCTION

FACILITY MANAGEMENT

ARCH STRUC

Archive

Usage 2

Structures Loads ...

Usage 3

Spaces Service systems ...

HVAC

Usage 1

Structures Spaces Fittings ...

Fig. 1: Information exchange scenarios in AEC/FM supported in the ToCEE environment


Based on the achievements in ISO/STEP “Building & Construction” and in European andnational building information technology projects and most recently within the IAI, it wasforeseen that an underlying concept of WP F would be the deployment of a kernel model forconcurrent engineering, which should be domain-independent and should serve as a bridgebetween the separate discipline oriented aspect models. This kernel model is the common basisfor information exchange and IT support for concurrent engineering, whereas the aspect modelsrepresent domain-specific views of product data and provide local support for the applications inthe respective domain.

According to this principal approach, a primary goal has been to examine vertical and horizontalinteroperability issues. The first refers to harmonisation and mapping between the kernel and theaspect models, the second includes handling of different semantics and information content indifferent aspect models.

Another focus of the R&D work has been the investigation of appropriate methods fortransformation of the information contained in the set of product models (representing thedynamically changing product data in the course of the design, construction and facilitymanagement processes) to a set of documents which represent - usually graphically - technicallyand eventually also legally determined “frozen“ states of the product characteristics that aremeant to be read and understood by humans.

Finally, because of the anticipated heterogeneity of both software tools and information contentin the Concurrent Engineering Environment, an important goal has been to define the layeredproduct model structure which would support information processing at different levels of detail.This enables capturing and querying both global features representing overall characteristics ofthe product from a certain perspective, as well as locally stored detailed attributes of the buildingobjects. This flexibility of the representations would allow to support the information logisticsservices at a high level as well as to capture detailed individual properties of modelling objectswhenever necessary.

The scope of the product modelling framework includes:

1. An IFC based kernel model for CEE (at first aimed to be aligned with theSTEP/AEC/Building Construction Core Model (BCCM, STEP Part 106); later it becameobvious, that instead of STEP BCCM, the momentum lies at the IAI IFC).

2. Model support for high level product, process and agent model components for communi-cation purposes to support the Information Logistics Services developed in WP E, as well asfor components required by the conflict management methods developed in WP H.

3. Application models for the separate application Workpackages (WP A, B, C). These aspectmodels are developed to an extent that allows sufficient support for the informationrequirements of each application with respect to co-ordination and co-operation with theother applications. WP F does not claim to develop complete models of the targetedapplication domains, but contains specifications capturing generic characteristics for eachapplication and goes in detail for selected representative aspects.

When setting up the requirements it was realised that IT support for product data managementin 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 in the largely distributed information

management process of building construction which would allow repeated data exchangecycles and exchange of partial product models and will compensate the lack of a fullyintegrated product model with concurrent access of all different disciplines, which is notbelieved to be realistic in building construction environments


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

The examined end-user requirements to product data management include:• data re-use, no redundancy of the information (a frequent cause of errors)• data integrity and consistency• fast, convenient and efficient access to local data, which implies application specific

modelling• information sharing of common resources and information hiding of all irrelevant

information• “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 ofrecognised conflicts for crucial solution parameters)

• automated assistance for conflict recognition and interactive support for conflict resolution• possibilities for creating variant solutions.

Requirements for supporting overall project management functionality include:• Fast access to global summarised data like total cost (for building, building section,

subsystem, construction phase etc.), total erection time, built area, site area etc., whichimplies with respect to product modelling the ability to quickly retrieve such data from theavailable product information.

• Methods for monitoring status and progress of design / planning work, which requiresnavigation through the common product model, examination of the separate modellingperspectives, inspecting on a high level the status of the data etc.

Specific concurrent engineering requirements imposed to product data management beyondintegration are summarised in table 1 below.

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

Concurrent Engineering Features Product Data Management Related IssuesCollaborative work of physicallydistributed teams

• Distributed C/S environment• Common product data repositories

Co-operative problem solving • Comprehensive data access and retrieval functionsproviding 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 methodsfor effective model transformations

• Change managementEfficient inter-discipline commu-nication and information sharing

• Well-defined and flexible C/S interfaces• Comprehensive set of available server functions• Consistent support of semantic and operational

interoperabilityLife cycle management • Comprehensive set of harmonised data models

• Modelling representation enabling model evolution anddifferent levels of representation detail

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

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


2. CONCEPTS

The proposed product modelling and interoperability framework for ToCEE takes into accountdifferent interoperability aspects relevant to CEE. These are:

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

On the basis of a common layered model architecture and a set of interoperability methods andtools these aspects are considered in their mutual interrelationship, as one consistent whole. Theyare described in greater detail in the following sections.

Conceptual Design of the Product Modelling Framework

ToCEE’s modelling framework is developed on the basis of the requirements explained in theprevious chapter. The principles for ToCEE’s modelling framework have been:

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

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

3. Partitioning of the product models according to different systemic aspects in order tofacilitate parallel and to greatest possible extent independent work in the different disciplinesinvolved in a construction project.

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

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

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

7. Use of IFC as basis for the modelling framework in order to achieve faster practical results,as well as to contribute to the IFC development and at the same time not intervene withalready established solutions.

The ToCEE system architecture is comprised of selected client applications for various tasks inAEC/FM and a set of information management servers. In such a complex environment, it ismost beneficial for information sharing that all system components follow the same object-oriented paradigm. In practice, this has lead us to formulate common concepts for product,process and document information on a generic conceptual level.

Concerning the product data management, it must also be anticipated that architects and engi-neers will continue to use local data and applications because of the highly distributed nature oftheir work. Therefore, the data exchange between applications (and the ToCEE system) isexpected to happen using aspect models specified for each discipline separately, but inaccordance to the common paradigm.


Because of these reasons, the following assumptions have been made w.r.t. the functionality ofthe product data management environment in ToCEE:

• there shall be a centralised project management,• there should exist a logically consistent overall project model maintained by a dedicated

product data management server,• users (and applications) shall work with local models suitable for their needs, whereas the

common product data shall be accessed exclusively through the API provided by theInformation Logistics Services, using the specific functions for product data management.

Architecture of the Modelling Framework

The ToCEE modelling framework has five layers (from top to bottom):1. The Meta model layer sets the basic principles of the whole modelling paradigm. It server

for the formal definition of all allowable basic and user-defined data types as well as for thegeneric definition of object classes (called “concepts” on the Meta model level). Followingthe definitions in the Meta model each object class in the other model layers has a parentconcept and contains a set of attributes describing its state and a set of operations defining itsbehaviour. Each attribute has in turn a tag indicating if it is part of the EXPRESS entityspecification and should thus participate in the data exchange between applications. Eachoperation is defined through its name and parameters which can be either of predefined datatypes or references to concepts. In addition, each class description contains also anidentification attribute which can be linked to one of the attributes defined in the EXPRESSschema as is the case with the ‘ProjectID’ attribute of TC_IfcRoot and all its subclasses inthe Kernel model.

2. The Kernel model layer defines in three schemas the high-level generic concepts, which arecommon to all lower level models representing Product, Document and Process relatedinformation. The main features of TC_IfcKernel, the ToCEE adaptation of the IFC Kernelschema, are:• The definition of a generic root entity (TC_IfcRoot), from which all other entities are specialised,

and from which they inherit the attributes 'ProjectID' and 'versionStatus' that can be used tosupport unique identification and versioning

• Division of the object classes into actual modelling objects (TC_IfcObject), relationships betweenthose objects (TC_IfcRelationship) and objects for predefined types and attributes(TC_IfcPropertyTypeDef , TC_IfcOccurrencePropertySet and TC_IfcPropertySet).

• Division of the object classes into project, product, process and group objects, with the ToCEEspecific addition of „document“ (TC_IfcProject , TC_IfcProduct , TC_IfcProcess , TC_IfcGroupand TC_Document).

• The two other schemas in the Kernel are: (1) TC_Communication_Model, which contains infor-mation on the system itself and the information processes in it, and (2) TC_Model_Populationwhich has a similar purpose as the SDAI dictionary model (ISO 10303-22), but is extended toinclude important for CEE meta model information.

3. The Neutral model layer presents the concepts for each modelling perspective, i.e. NeutralProduct Model, Neutral Document Model, Neutral Process Model, Neutral Contract Modeland a common high-level Conflict Model. These neutral models are implementedrespectively in each data management server of the ToCEE environment.

4. The Aspect model layer further specialises the Neutral Product Model (NPtM) for theselected 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 applicationsused in CEE. In the scope of ToCEE this layer includes as practical examples a structural anda geotechnical application model for the WPs A and B.


In addition to these five model layers, a set of independent resources are available to all othermodels for referencing - except for the application models, which however can copy constructsthat are found useful.The architecture of the whole framework is illustrated in Fig. 2.

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

REFERENCES B/NRESOURCES NOT VISIBLE,ALSO POSSIBLE COPYINGTO APPL. MODELS NOTSHOWN.

TC_Population

TC_Contract

TC_Conflict

TC_Communication

TC_ShapeRepresentationRes

Notes: In the ToCEE scope only a Structural and Geotech. 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. 2: Overview of the ToCEE modelling framework


Use of the IFC Project Model for ToCEE

The international standardisation work w.r.t. building product modelling has been taken intoaccount 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 thanin 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. However, in order to supportadequately the requirements to product data management in ToCEE, it has been necessary todefine several specific extensions to the IFC project model.

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 arethe basis for the implementation of advanced interoperability functions used in modeltransformations, model matching and change management.In the ToCEE framework each object or relationship is given a unique identifier in each model,and each model also has a unique identifier. Object identification includes not only naming, butalso versioning information. Thus, each object has an identity not only in the scope of aparticular model, but also globally, across models and life-cycle stages, so that it can beaddressed with the help of an accessor function from any location and at any time and state.In the run-time environment object identification is maintained centrally by the PDM server andthe access rights of actors to create new objects through respective server functions are strictlydefined. The syntax for addressing of objects through their IDs is formally specified and con-sistently used in the ToCEE InfoContainer API and all offered PDM services (see Appendix IIIfor details of these specifications).

Groupings

The grouping mechanism plays an essential role in the ToCEE framework. Each group is a typeof TC_IfcObject, alike product, process or document. All these have unique identifiers includingversion information, as does the objectified relationship IfcRelGroups, which assigns membersto groups. The possibility to assign a group instance to itself has been prohibited - otherwisegroups can be assigned recursively to other groups just like any other objects. In each groupassignment there is a possibility to specify access rights to the members of that group, orapprovals of them. Grouping can be especially useful for linking product model instances todocuments or assigning them to conflicts.

Views

The grouping mechanism described above is used also as a basis for relating product model datato documents. For this purpose, the TC_RelViews entity is defined in the Kernel, providing afiltered version of the whole model (grouping as 'entity-level' filter and optionally specifiedTC_Filtering as 'attribute-level' filter). A view may itself be comprised of other views which thenmay be related to documents. In this way, a high-level inter-relationship between products anddocuments can be achieved, whereas for the direct relation of a document content to product dataa mapping e.g. between SGML and EXPRESS should be applied. Such content and form depen-dent interoperability between products and documents is however beyond the scope of ToCEE.In principle, the view objects defined in such way are groups of product objects that can be usedto create a document with an appropriate application tool, whilst the documents themselves canbe considered as time-stamped „frozen“ representations of the product data. Thus, a view can beused to update a document’s content with the actual state of the product data (by creating e.g. a


new document version). On the other hand, documents can have a legal status which cannot beassigned directly to views, at least because responsibility cannot be properly traced.

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 tocorrespond best to work practice. However, since the entity TC_Approval is related to a group ofobjects via assignment in the Kernel model, and since a group may be a TC_View, which has afiltering capability, there exists also a possibility to apply approvals on 'attribute-level' (forcontrolling certain important or sensitive data).In principle, the model for TC_Approval allows each group of objects to be assigned any numberof approvals. Furthermore, each TC_Approval object includes information about which actor'sapproval is questioned, in which role the approval is given and when. The attribute statusspecifies, if the object is representing an approval that is:

1. Required (according to contractual arrangements etc.),2. Requested (notice has been sent to the party whose approval is needed),3. Given/rejected or given provisionally,4. Not needed.

Approvals can also be related to each other, e.g. there can exist one object for required, andone for requested approval, and the fact that they are related can be stated by aTC_ApprovalRelationship object instance. This concept is borrowed from ISO 10303-41 and hasbeen used in a slightly simplified form in the implementation of the change and conflictmanagement facilities of the ToCEE environment.

Access Rights

In similar manner as approvals, access rights may be assigned collectively to a group of objectswhich is assumed to be most convenient for practice. The access rights may be granted to aparticular actor (person or organisation), or to certain roles in a project, and they may authoriseto one or more of the following actions:

1. Read (allows to retrieve, but not to manipulate the data),2. Write (allows to add data into the model)3. Modify (allows to change existing model data, incl. deletion)4. Change rights (allows to grant/deny access rights)

Collectively, groupings, access rights and approvals will play a substantial role for the run-timeauthorisation for using the project information and thus can contribute greatly to the robustnessof complex CE environments.

Meta Model Information

This is the information about a product model stored in the product data repository of the system.It is needed in order to enable individual processing of local models for each actor together witha shared product data space for co-operative work, as well as for supporting the needed modelinteroperability features.The use of meta model information in the PDM server of the ToCEE environment is based onimplementation of the SDAI dictionary model (ISO 10303-22) with specific extensions added toenable the operability of CEE. It contains constructs for the concept entities Model, ModelSchema, Mapping and Mapping Schema. Through the meta data a model “knows” not only theentities 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-dateversion, what mapping specifications are associated to it and for which other models, what is thebase reference model to be used for consistency checking etc.


Operational Interoperability

From operational point of view interoperability means the ability of the system components towork together in a coherent way for the solution of complex tasks that cannot be solved by onlyone single system component.

The concept of the operational framework of ToCEE is based on the client-server paradigm. Ithas a clearly distinguished layered structure as shown in fig. 3.

The Client Application Layer is the basic user interface to the system. It is the layer at whichthe actual project activities, like working with CAD, FEA, FM programs etc. will normally takeplace. The Adapter Layer provides both the users and the client applications with a set ofgeneric Internet-based access methods to all common project management services which, inturn, are organised as separate subsystems (product, process, document, conflict management)implemented as a Server Plug-In Layer. This approach allows to develop each application orserver independently, and to integrate them in a flexible and fully distributed manner, hidingfrom the end-user low-level communication details.

Process Mgmt Server

Appl. adapter (IL toolkit, ORB interface)

Internet adapter (WWW, Email)

EXPRESS adapter (SPF, SDAI)

FM

. . .

FEA

CAD

CommonRequestBroker

. . .

Product Models

Document Model

Server Plug-In LayerCommunication

LayerMiddleware

Adapter LayerClient Appl.Layer

Process Models

Common Modelling Framework

Common Meta Model

Product Data Mgmt Server

Document Mgmt Server

Conflict Mgmt Server

. . .

Conflict Model

Fig. 3: Principal schema of the operational framework

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 specialise the meta model objects of the system to the common requestbroker (CRB), which is part of the centralised Information Logistics Services (ILS) in ToCEE.These objects contain public methods that can be accessed through remote calls by any otherclient 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 mainrole is to identify the correct target subsystem, and then parse, resolve and forward to it therequest. Additionally, the ILS provides consistent access control and concurrent request handlingfor all project communication.

This approach enables the PDM Server to provide services to the client applications and theother servers of the ToCEE system through the ILS. The product data maintained by the PDMserver itself are accessed by calling its public functions, which are registered on the ORB asoperations for product concepts known to the middleware. In this way a structured run-timeenvironment with layered levels of data abstraction is achieved.


Semantic Interoperability

Semantic (or schema) interoperability can be defined as the ability of the conceptual modelschemata to share common concepts which can be used for the actual exchange and sharing ofthe information stored in the data models according to these conceptual schemata. Semanticinteroperability plays a very important role in an open integration environment, as envisioned byToCEE, since in such environment it cannot be assumed that all information can be viewed as asingle logical system described by one single global schema.

In principle, in order to achieve the semantic interoperability of the model schemata used in theenvironment, two complementary approaches can be applied: (1) Model harmonisation, i.e. useof the inherent features of the modelling paradigm like generalisation/specialisation, referencingetc., and (2) Model mapping, i.e. use of special specifications and methods for the transfor-mation of the modelling objects of one schema to another where model harmonisation is notalone sufficient.

Model Harmonisation

As already mentioned the ToCEE modelling framework consists of a set of pre-harmonisedmodels for diverse kinds of information. This pre-harmonisation is not only needed for the modeldevelopment, but even more for the realisation of the principal requirements of concurrentengineering: co-operative work and information sharing across the disciplines and phases of abuilding product life cycle.

The actual data exchange between applications takes place on the basis of the respective aspectmodels, specified for each discipline separately, but in accordance to the common paradigm. Theaspect models are designed in such way that they provide, for the first, for easy transformationfrom one representation to another, and for the second, allow for gradual, stepwise enhancementof the models themselves *).

The support of the data transformations (mappings) between the different models is achieved by:• specifying on high level those common concepts which can be shared, and• general resources which can be re-used in the domain specific models

(following closely the ISO STEP methodology).

Model Mapping

Because of the envisioned use of numerous model schemata and respective data models in CEE(at least one model for each discipline-specific view), data transformations are needed on manyoccasions:• for exporting the data of one aspect model to other aspect models for the purpose of inter-

discipline collaboration;• for the data exchange with applications that use their own dedicated models

• for the generation of views.

All such data transformations must be based on an underlying specification of the equivalencesof the data representations used in the different models. In the case of fully harmonised modelschemata these equivalences are provided by the modelling paradigm itself. However, since the

*) Note, however, that the modular layered structure will enable gradual development and expansion of the models

only as long as the generic concepts and their declarations on the meta and kernel levels are stable. For thisreason, it is of utmost importance that the models on these layers are lean, representing only high-levelconcepts, and not trying to merge all concepts on the layers below into one huge logical schema. This is anapproach which has already been verified successfully in the COMBI project and is fully supported in thedevelopment of the IFC project model.


objective is to have lean models on the higher levels of the framework, this is not always thecase. For such cases special mapping methods are needed.

Model mapping involves the conversion of one modelling representation (source) into one ormore other modelling representations (target) without awareness of the context, i.e. alreadyexisting local data in the target. Due to the different semantic richness of the separate models inthe framework, the mapping methods must be able to deal with the following problems:differences in the terminology, i.e. representation of the same (or similar) concepts usingdifferent names (synonyms), or representation of different concepts using the same names(homonyms), differences in the structure, i.e. representation of the same concepts using differentconstructs, which leads to the necessity to consider all possible transformations of EXPRESSdata types, and differences in the modelling abstraction, i.e. representation of the same conceptswith focus on different aspects of their properties and behaviour.

In the ToCEE environment, model mapping is realised in the following way:1. The mapping specifications defining the equivalences between the different data models are

maintained explicitly in the PDM server.2. 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 objectinstances belonging to one model into object instances of another model 1). Each mappingoperation must be able to deal with the cardinality cases 1:1, 1:N and M:N, i.e. given a sourcemodel context C’, a target model context C” and a set of mapping specifications m ∈ M, it mustbe able to produce as appropriate any of the following relationships between the source andtarget objects:

(1) { }m c c c m c c c Cj k i k j i k k/ ( , ) | ( , )′′ = ′ ′′ ′ ′′ ′′ ∈ ′′∧ – 1:1 mapping

(2) { }m c c m c c c Cj i j i/ ( , ) | ( , )′′ = ′ ′′ ′ ′′ ′′ ∈ ′′∧C – 1:N mapping

(3) m m with C and Cj jc Ci

/ / ,′ × ′′ = ′′ ′ ⊆ ′ ′′ ⊆ ′′′∈ ′

C C C C CU – M:N mapping

In practice, the third and most difficult case has not been considered in the implementation, as inthe ToCEE models M:N relations are substituted by sets of „objectified relationships“, resultingin only 1:1 and 1:N cardinalities.

Functional interoperability

From functional point of view interoperability means the ability to support at run-time the modeland data transformations needed in the information exchange and sharing between thecomponents of the integrated environment 2) . Such transformations are necessary for examplewhen changes in one local aspect (source model) have to be propagated and checked against theconstraints of another local, discipline-specific aspect (target model), e.g. architectural spatialmodel to structural model. In the ToCEE environment this is achieved with the help of themethods model mapping (applied on instance level, as described in the previous section),model matching, consistency checking and model merging.

1) 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.

2) „Functional interoperability“ is often understood in a more tight scope, as a standard declarative query languageand a standard transaction mechanism, including mapping e.g. from SDAI to SQL. To avoid ambiguity, themethods described in this section can be named alternatively „dynamic model management“ methods.


Model Matching

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

To focus the discussion, let us consider a simplified practical example taken from an envisionedscenario, as shown in Fig. 4.

Design interaction

modelversionmatching

spring objectelastic support

Fig. 4: Design interaction example for the use of model mapping and model matching

At the first iteration step of the presented design cycle, i.e. after the structural designer hascompleted the initial configuration of the structural system of the building and the relevant dataare passed to the foundation designer to determine the appropriate foundation system, noconsistency problems will arise, since the foundation design objects will be created for the firsttime and added as new items to the product data base of the project. However, when returning toanalyse the bearing structure - this time taking into account its interaction with the foundation -the situation will be different because the newly created foundation objects can affect thestructural system in various ways. First, the actually computed stiffnesses of the designedfoundations will as a rule cause changes to the presumed support conditions of the pre-designedframes and shear walls and hence will lead also to changes in their overall stiffness. Thus, it maybecome necessary to re-dimension beams and columns which would result, in turn, in new loadsto the foundations and can also influence architectural or HVAC design. It is also possible thatsome structural assemblies must be entirely reconfigured, in which case they might no longermatch the determined foundation layout. At last, because of changes in their properties, certainelements might even need to be re-classified, e.g. spread footings may „migrate“ to stripfootings, or the whole shallow foundation system may need to be substituted by pile foundations.

This simple interaction example shows that even small, at first glance „harmless“ changes in onepartial aspect model can cause cascading changes in one or more other models leading,potentially, to serious consistency problems. Such problems can be tackled by the modelmatching operations of the PDM server. The 'match' operation should be invoked whenever anapplication or user tries to update the corresponding information context (using 'checkIn'operation), i.e. create a new version of its instantiated model, or when the results of a mappingoperation have to be verified against the constraints defined in all other relevant models. Eventhough matching is applied to a whole data model, version comparison is performed on object-by-object basis because the product data can also be updated individually.


Model Matching is an important tool for supporting a general least commitment strategy for thewhole environment with the aim to defer decisions until greater certainty is achieved. It makesuse of the frame-based representation paradigm implemented on the PDM server and is stronglyrelated to the hierarchical architecture of the modelling framework. The key idea is to use thepersistent kernel model of the framework as a reference structure for all other modellingrepresentations by means of associating each object instance in a given context to instances ofobject classes defined in the kernel. Besides attributes and methods determining their behaviour,the kernel object classes on the PDM server contain also specific rules which facilitate thematching procedure.

As a concrete example of the technique outlined above, let us examine again the designinteraction case given in Fig. 4, now focusing on the process of updating the existing structuralsystem after mapping the objects contained in the foundation model onto the structural model. Ina first step, the mapping operation will create temporary objects which represent only thatportion of the structural system which ensures the contact to the foundation. The task of thematching procedure will then be to verify the correctness of these objects in respect to the overallstructural model and to “merge” them into the instantiated structural model context. In order todo this all temporary objects are first identified w.r.t. the objects of the kernel model on the basisof predefined „sufficiency values“. After this is done, the corresponding objects in the existingdata structures of the structural model can be easily identified and checked, and their state can beupdated - eventually creating new instances or re-classifying existing ones when appropriate. Forexample, if a spring element has not been defined previously because the support nodes of thecolumns have been assumed „fixed“, it will be created and will replace the correspondingconnector elements in the data model.

Here it must be noted that the matching operation will in fact only mark the changed objects, butwill not perform the change commitment itself, leaving the decision for that to the user or theclient application having the appropriate background knowledge. If it is desired that differentaspect models reflect simultaneously the made modifications, before committing the changesconsistency checking must also be involved.

Consistency Checking

Whilst the PDM server ensures that one individual product model is formally consistent bydefault, in the ToCEE environment consistency checking must ensure also that the changes madein one model are consistent with the data objects and the formal constraints in one or more otheraspect models. This inter-model consistency checking is a much more complicated and time-consuming procedure which is invoked internally when the PDM server 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 of„conflict object groups“ of the found inconsistent objects which can then be passed to theconflict management server for further processing. All such operations are performed ontemporary data sets which will either replace the previous model versions - when all conflicts aresuccessfully resolved, or will automatically be deleted - if the proposed changes are rejected.

As a whole, consistency checking can involve quite complex operations requiring an adequaterule base to be established for each respective model. Full development of such rule bases hasbeen beyond the scope of the ToCEE project.

Much like model matching, which is in most cases closely associated with model mapping, theconsistency checking operation must obviously be correlated with both other model managementoperations - model mapping and model matching. Their interrelationships for the scope of onedata model are illustrated on the below Fig. 5.


Source modeldefinition

data level

transformations

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: 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 theadopted approach to allow the use of local models in order to facilitate independent, concurrentwork. Model merging involves:• the synchronisation 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 pairwise matching of each aspect modelwith the base reference model maintained at the PDM server. In order to do this, it is necessarythat the modelling framework is specified in such way that a base reference model exists and themappings to/from the aspect models are clearly defined and available at run-time.

This additional requirement is however readily met in the ToCEE environment through the useof the Neutral Product Model adapted from IFC. Note, however, that as an automated operationmodel merging requires caution because it relies upon appropriate preceding consistency checksand resolution of all data conflicts. Therefore in the ToCEE environment it is an operationdesignated for exclusive use by the project manager. Whilst it is possible, at least theoretically,to incorporate all other necessary interoperability operations into the 'merge' function, this hasnot been the approach taken in the implementation because:• it would result in a very complex procedure which might take unpredictably long time to run,

• it would contradict to the basic approach taken in designing the server functions as minimalbuilding blocks which can be glued together in client applications, but not at the server, and

• it will introduce more “automation” than desirable and would thus either enforce decisionsthat cannot be controlled by the end-user and can be potentially dangerous, or it will benecessary to take a very restrictive approach towards all discovered problems in the datamodels which in turn might result in a lot of wasted time if the 'merge' operation fails.


Principal Interrelationships of the Interoperability Services in the ToCEE Environment

In a complex construction project taking place in a virtual enterprise including many participantsworking in parallel, project co-ordination will usually not require co-ordinated and consistentversions 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 theindividual freedom, and thus the creativity of each project actor. Co-ordination of all models isnormally required only at certain points, whilst partial process threads develop individually andonly partially co-ordinated with each other.

For these reasons, all interoperability services have to be used in a correlated way, withunderstanding of their inter-relationship and specific functionality. Fig. 6 shows schematicallythese principal inter-relationships and the envisioned intent for the use of the advanced serverfunctions for project co-ordination from the viewpoint of product data management. With thehelp of such advanced functions, the co-ordination of design decisions can move in future fromthe currently often practised „political“ solution of conflicts towards the achievement of reallysynchronised, technically consistent information.

Fig. 6: Use of the product data management functions for project co-ordination


3. IMPLEMENTATION

Overview

In the multi-tier client-server environment of ToCEE several types of client applications have tobe supported both w.r.t. their functionality and the models they use, as well as w.r.t. to theirinformation sharing needs and available communication features.Product data management support in the ToCEE environment is realised by the following set ofsoftware tools:1. The ToCEE product data management server PROMISE developed by CIB;2. The ToCEE generic product model browser ProMoTe developed by VTT;3. Client adapters for product data support for the applications in WPs A, B and C developed by

SOF, DAP and KU.The main emphasis of the implemented prototypes has been to prove as much as possible of thedeveloped concepts in a realistic environment. Commercial realisation of the tools has not been amain target because: (1) all tools are developed almost from scratch, (2) despite the advances ofIFC, the interest and the uptake of PDT in building construction is at present still very moderate,and (3) marketable product model based systems even by big software vendors are not yetmatured to full functionality and therefore the existing software infrastructure and user expertisewith respect to PDT is still at comparatively low level.Nevertheless, all developed tools are fully functional and show how the broad range of PDMissues addressed in ToCEE can be tackled in practice. Therefore, migration to marketable tools isbasically not a conceptual, but a strategic and resource problem.

The Product Data Management Server PROMISE

The prototype realisation of the product data management server PROMISE (v. 1.0) followsclosely the developed concepts outlined in the previous chapter. Most of the functionality of theserver is generic and can be used also for other data models defined on the basis ofSTEP/EXPRESS. However, in order to support product data management in the ToCEEenvironment, a set of functions have been prototyped as well which are specific for the ToCEEmodelling framework based on the IFC 1.5 final model. PROMISE can be easily configured towork with different data models, but in each specific project it has to commit to the models set upfor the whole environment. In the ToCEE environment these include TC_PRODUCT_MODELand the respective architectural, structural, HVAC and FM extensions as well as the application-specific models for structural analysis and geotechnical design.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 mapping,matching, consistency checking and merging.

Architecture and components of PROMISE

With focus on PROMISE the ToCEE environment architecture can be presented schematicallyas shown on Fig. 7 below.

Client Applications PROMISE (CiB)

Legacy application:ToCEE WPC

product data repository

Stand-aloneApplication:

ToCEE WPAFront-endapplication

interface server

PROMISE/F

Applications with embeddedInternet capability: ToCEE WPB

ClientAdapter Actual PDM

Server

PROMISE/M PPrrooMMooTTee

STEP

Java Internet

VR

EXPRESS

WWW Browser(with generic ILS Applet)

InfologisticServer

(ObjectRequestBroker)

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

Fig. 7: The PDM environment architecture in ToCEE

The actual product data management server PROMISE/M is responsible for the execution of allproduct data operations requested by client applications through remote procedure calls (RPCs).PROMISE/M is implemented in KEE/LISP/CLOS and is running on a UNIX workstation. Itperforms all the major functions of the system and can be used both locally, in stand-alone mode,and remotely, in server mode.

The front-end interface server PROMISE/F is implemented in Java and can be installed on anyplatform supporting the Java Virtual Machine v. 1.1 or higher. It is responsible for tackling thecommunication with the Information Logistics Server (ILS) and with the remote clients. Thisincludes parsing of requests, downloading/uploading BLOBs, such as STEP physical files,resolving user authorisation and task priority. PROMISE/F supports TCP/IP, Java RMI andCORBA IDL based communication (the latter, however, not sufficiently tested as it is not usedby the clients implemented in the ToCEE environment.

PROMISE/M and PROMISE/F are fully integrated, but can reside on different platforms, andtheir configuration is fully transparent to the clients. PROMISE/M provides in addition a GUIwhich is dedicated to the system administrator and a project information manager withadministrator privilege. For security reasons there is no way to access PROMISE/M remotelyexcept through the front-end server PROMISE/F by using the registered public server operationson the common request broker of the ILS. The communication between PROMISE/M andPROMISE/F is realised 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 ispossible only through the ILS, since the user access rights are set and maintained by the latter.

The configuration of both server components is fully parameterised and can be performed veryeasily by modifying the desired parameters in the respective configuration files. This includessetting 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, texteditor, general-purpose CAD system supporting DXF import, spreadsheet tool supporting SDFand CDF file import).

Product data representation

In order to enable coherent use of both the implemented object-oriented methods for thesupported data models as well as knowledge-based methods applied in more sophisticatedservices, such as model transformations, model matching, complex queries etc., the repre-sentation of the product data models in PROMISE/M is realised according to the frame-basedmodelling paradigm.

The implemented frame-based representation parallels the conceptual model schemata specifiedon the basis of EXPRESS-C. Frames incorporate all object-oriented features of EXPRESS-Centities, such as inheritance, state and behaviour, but allow also to vary dynamically the numberand type of their attributes, to define different properties of the attributes themselves, as well asto associate rules to different frame structures. The 3-layer representation used in frames (object-attribute-facet) allows to include easily meta information about the modelling objects, as well asto enhance them with additional attributes which are needed for several management functionsbut have to be shadowed for the client applications using the “pure EXPRESS” specification ofthe data models. Rules are defined separate from the data and methods captured within frames,and can be used for run-time binding of variables to modelling object instances. This enablestheir use for information retrieval purposes in applications that do have knowledge of the modelschema, but not necessarily of the particular model instantiations. Rules are triggered e.g.through the execution of query functions from the body of the object-oriented server methods.Thus, rule-based reasoning can be seamlessly integrated in the “normal” object-oriented requestsof a client application to the PDM server, as shown on the example in Fig. 8 *).

In this example, exec.operation is used to invoke the object-oriented method “match”, thusallowing to combine rule-based and object-oriented techniques.

match (oid: ?m inParams:(refModel:?n)) is the method that will be applied consecu-tively to model M1 and any other model Ni satisfying the above rule. It may in turn triggerforward and/or backward chaining rules during its execution, switching seamlesly betweenobject-oriented and rule-based processing techniques.

*) This feature of PROMISE is not used by the client applications in the prototype ToCEE environment.


With the given TC_Model entity specification in EXPRESS-C (excerpt):ENTITY TC_MODEL SUBTYPE OF (IfcRoot);

... –- attribute specification

(* versionStatus: StatusEnum; -- inherited from IfcRoot *)Operations -- EXPRESS-C method specification match (refModel: TC_MODEL);...END_ENTITY;

When a modified version of an instantiated product model M1 is checked in at the PDM server and itsstatus is set to “proposed”, e.g. by executing a remote method call from a client application like:

M1.setAttribute (Name:“Status”, Value:PROPOSED) *)

the following rule will be triggered automatically, allowing a separate agent process to determine allchanges done to the model and to notify subsequently the affected actors:

IF (the versionStatus of ?m is PROPOSED) ; ?m is automatically bound to (the projectID of ?m is ?id) ; the model instance M1.

(?n is in TC_MODEL) ; Gets all ‘active’ instantiated ((the projectID of ?n) = ?id) ; model versions with the same (the versionStatus of ?n is ACTIVE) ; projectID on the server.THEN (the versionStatus of ?n is FROZEN) (exec.operation match(oid:?m inParams:(refModel:?n)))

*) Note: The syntax of client requests is simplified here for convenience.

Fig. 8: Example for triggering a rule-based method from a client application

The outlined representation paradigm allowed the development of a component architecture thatvery much resembles that of a typical knowledge-based system as shown in Fig. 9 below.However, in contrast to expert systems, designed to assist engineers in the solution of specificproblem solving tasks, the goals of the knowledge-based methods in the PDM server are to reactto general-purpose, yet complex queries and assertions, and to adapt to a variety of changes inthe product models resulting from the concurrent, simultaneous work of the separate actors in aproject team.

InterfaceComponent

OO-oper. / EXPRESS-C

WorkingMemory

ReasoningComponent

(AI Methods)

Server Knowledge Base:Frame-based representation (state and behaviour) of the product model schemata

and a set of instntiated product models, containing the modelling object instances

uses

invokes

uses

Input: operation parameters withembedded query/assert expressions

ExplanationComponent (N/A)

KnowledgeAcquisitionComponent

create/modify objects(through SPF, SDAI-oper.)

sends msg

sends msg invokes

Fig. 9: Functional components of PROMISE/M


The main component of PROMISE/M is its knowledge base containing a set of predefined datamodel schemata, as well as one or more product models associated with each model schema andrepresenting the separate work spaces and views of each actor on the designed building product.Each data model schema in the knowledge base is organised in a frame structure, as described inthe previous section, and contains exclusively class frames, roughly corresponding to the entitystructuring given in the EXPRESS-C schema of the model. The instantiated product models, onthe other hand, contain only instance frames with inherited attributes and behaviour from therespective underlying data model schema. All frames can act both as “normal” objects,responding to messages from the outside and/or from other objects, as well as to participate inrule-based queries and assertions. The knowledge base can accommodate also overall rulessimilar to the global rules in EXPRESS.

The interface component has the task to resolve properly the requested operations and to activatethe appropriate server object methods responsible for the execution of the client requests. Allincoming requests and result responses are also based on the formal EXPRESS-C specificationsin the data models, regardless of the particular internal server method used (pure object-orientedor knowledge-based implementation). In this way, the interface module allows to hide from theusers and clients the implementation details of the server, which simplifies greatly clientimplementation.

Typically the reasoning component will retrieve the required data from the knowledge-basetogether with the appropriate reasoning rules and will place them in the working memory of theserver. After that the inference process on the retrieved data and rules is started, and, on itscompletion, the result is returned to the calling method. Currently, the server implementationfeatures an inference engine including forward and backward chaining as well as different searchalgorithms. These methods can be further enhanced using the same component architecture.

The remaining (dashed-box) components shown in Fig. 9 are given only for comparison withtypical expert system architectures. An explanation component is difficult to envision for aserver software, and a comprehensive knowledge acquisition component has been beyond thescope of the server implementation, although new “knowledge” can (and is) continuouslyintroduced in the knowledge base through respective create/modify or similar requests.

Application Interface

The use of PROMISE by client applications is based entirely on a formally defined API whichprovides for uniform platform-independent access to the supported product models on the server.

The PROMISE API is designed according to the following principles:

1. The data exchange with client applications is based on the ToCEE InfoContainer API whichcontains generalised constructs available to all components of the ToCEE environment (seeAppendix III, pg. 51). All functions of the PROMISE API are defined in terms of theseconstructs, as methods of the modelling objects specified in the product model schemataimplemented on the server.

2. Communication with the clients and the ILS is realised on the basis of requests and responsesaccording to the TC_Communication_Model schema and the ToCEE Server InteroperabilityProtocol (SIOP) as described in ToCEE Deliverable E2.

3. The data models in the product data repository and the objects contained in them areaddressed according to a formally defined syntax for the object identification (see AppendixIII, pg. 45). Object identification is maintained centrally by the server which ensures that theobject IDs remain the same (and unique) within and between sessions and across all inter-related aspect models. It serves also as basis for matching objects in different model versions,for recognition of changes and for consistency checking purposes.


4. Searching for objects which satisfy certain criteria, but whose IDs are not known in advanceto an application is supported through an extension of the InfoContainer API providing a setof formally defined search templates (see Appendix III, pg. 63).

With respect to their addressability through the functions of the PROMISE API the objectsdefined in the product model schemata are additionally classified as:• Registered public objects

These are objects that are registered on the common request broker of the ILS. They containpublished function specifications that can be used directly by applications through remotecalls.

• Addressable public objectsThese are objects that are not known to the ILS. They can be accessed through remote calls iftheir IDs are previously retrieved and used for creating a temporary instance on the ILS forreferencing within the particular session. The session control itself is performed by the ILSwhich is responsible also for creating the appropriate lexical closure for the object ID of eachsuch object during the session.

• Private objectsThese are objects defined in generic resource schemata that cannot be accessed directlythrough remote calls. Such objects may still possess methods that serve other objects, butthey cannot be referenced directly in an operation.

This additional classification of the product model objects serves the following purposes:− it relieves the ILS of the task to maintain replicated definitions of all entities defined in

EXPRESS models (usually several thousand),− provides structured access to the product data “by importance”,− allows to define a comprehensive set of generic operations independent of the particular data

models used, and− inhibits direct access to resources which are normally only meaningful in connection with

some high-level object (a good example here is TC_IfcPoint as it is certainly unwise to movepoints around individually, and not through the respective building element(s), such asTC_IfcWall to which they are associated).

All functions are defined as methods of respective object classes in the product model schemata(EXPRESS-C operations) which enables their object-oriented use. They are kept as small aspossible, allowing minimum side effects. The purpose of this approach is to provide “functionalbuilding blocks” to the applications that can be used for the implementation of their own specificneeds, instead of trying to “guess” the possible requirements and provide sophisticated, but fixedcompound operations. Most of the functions are defined on generic level, i.e. as methods of theMeta model classes, in order to enable their use in a uniform way for any specific data model*).

In order to allow not only SDAI-like access, but also operations on whole product models, whichis the more common use of PDT by existing application system today, a comprehensive set offunctions is developed also for ‘Model’ and ‘ModelSchema’ objects, including the advancedinteroperability services featured by PROMISE. This enables applications to access whole datamodels in the same way as for individual object instances.

*) The exception to this is a set of functions prototyped specifically for the IFC model in order to explore better its

features and contribute to its development.


Product data services

In Chapter 2 the principal services and methods developed for product data management supportin CEE have been discussed.

Table 2 presents the product data services prototyped in PROMISE, grouped w.r.t. theirfunctionality. A formal description of the available functions in the PROMISE API is given inAppendix III of this document (see pg. 65). More detailed information on these functions isavailable in HTML format.

Table 2: Categories of PDM services enabled by PROMISE and respective functions defined inthe server API

Category Generic functions IFC-specific functionsGeneral product data services • createInstance

• retrieve• checkIn• checkOut• find• get/set/unset/testAttribute• getInstances• getMethods• getRelationshipTree• inspect• view *

• getRelatingObject• getRelatedObjects• getRelations• addToGroup• removeFromGroup• status

Model management services • create• delete• retrieve• checkIn• checkOut• find• getObjects• view *

• getProductObjects• getGroups• getViews

Services for access control • get/set/unsetAccessRightsInteroperability services • map / mapTry

• getMappingSchemas• match• getDocAssignments

Services for change management • match• checkConsistency

Session management • open/closeTransaction• commit• rollback

*) The ‘view’ function is specified generically, but implemented different for each model for the case ofviewing the object or model geometry as this is dependent on the particular geometry representationused in the model.


User interface

Besides server functionality PROMISE enables also password protected local use for privilegedproject data management or for system administration and maintenance. In local mode rootaccess rights are granted giving full permission to use all available system functions. For thispurpose PROMISE offers a menu-driven GUI as shown on Fig. 10.

1 = global menu bar, 2 = output window showing browsing an object instance in text format,3 = output window showing browsing of product data in table format, 4 = browsing a model as graph,5 = log window for the server activities, 6 = prompt window

Fig. 10: The graphical user interface of PROMISE

The main menu of the GUI contains options to start/stop the server, to examine and to stoprunning remotely invoked processes and also to use all functions of the “official” server API inmuch the same way as available to client applications. Fig. 11 shows a screenshot of the pull-down menu allowing to select a server operation from the GUI of PROMISE. This menu isstructured hierarchically, following the hierarchical definition of the operations.


Fig. 11: Screenshot of the main menu of PROMISE

The GUI offers also additional features accessible through the other submenus of the globalmenu bar:• The “Step” submenu allows to import/export EXPRESS schemas and STEP data files stored

in a local directory of the computer.• The “Tools” submenu provides facilities for manual (interactive) model mapping, as well as

for creating / editing / deleting object classes or instances directly with the user interface(editing of functions is also possible if the associated text editor is additionally configured). Itallows also to examine the model geometry with a CAD-tool (if configured with the system)as well as to set / check communication options.

• The “View” submenu enables browsing of product model data in different ways, e.g.navigating cascading down the object hierarchy as shown on Fig. 12, as a full object graphshowing both the object classes and the related object instances, in tabular form etc.

Fig. 12: Cascading navigation through a product model with the GUI of PROMISE

In addition to these menu functions, each model, class, instance or attribute shown on the screenhas an associated context menu which is accessible by clicking on it with the left mouse button,whereas the right button is used for window control functions.

Visual examination of the geometry of a model with a CAD system which does not “understand”the object definitions is realised via DXF. However, PROMISE allows to view also more thanone model together as shown on Fig. 13 presenting an AutoCAD screenshot of the architecturaland the foundation model of a building, the latter being defined in the application specific


schema of WPB. This provides for quick checking of the product model e.g. by the projectmanager even if not all data are represented as IFC objects.

Fig. 13: Combined geometric view of the architectural and the foundation model of a buildingretrieved from PROMISE

The implementation of PROMISE includes also an example generic client written in Java. It canbe used for light-weight data browsing, but its main purpose is to serve as example for theimplementation of the InfoContainer and the PROMISE API to other applications.

Fig. 14: Example generic client implementing the PROMISE API


The Product Model Browser ProMoTe

Schema independent product model browser has been the main target in development work. Thislate-binding approach enables the use of one software tool for accessing a variety of product databased on different schemata. A secondary objective has been to develop a 'laptop' client/serversolution for lightweight product model management.

Schema browsing

The ability to parse EXPRESS (ISO 10303-11) schema files and create Java classes to be used inpopulation of product data is the most important feature of this software.

Parsing EXPRESS schema file

The class hierarchy used in EXPRESS schema parsing is shown in Fig. 15.

Fig. 16 describes the structure of the schema object. The three main types of definitions from anEXPRESS source file are saved in tree vectors: Types, Entities and Functions. Currently,ProMoTe does not generate any code for EXPRESS functions, so they will not be discussed inthis report.

Schema EXPRESS_Generic_Entity

EXPRESS_Simple_Datatype

java.lang.Object

EXPRESS_Named_Datatype

java.lang.Cloneable java.io.Serializable

EXPRESS_Entity

EXPRESS_Type

EXPRESS_Attribute

EXPRESS_Enumeration

EXPRESS_Rule

java.util.Vector

EXPRESS_Entity_Vector

EXPRESS_Type_Vector

EXPRESS_Attribute_Vector

EXPRESS_Enumeration _Vector

EXPRESS_Rule_Vector

Fig. 15: Class hierarchy used in schema parsing with ProMoTe


Schema

EXPRESS_Entity

EXPRESS_Type

EXPRESS_Attribute

EXPRESS_Enumeration

EXPRESS_Rule

EXPRESS_Entity_Vector

EXPRESS_Type_Vector

EXPRESS_Attribute_Vector

EXPRESS_ Enumeration _Vector

EXPRESS_Rule_Vector

EXPRESS_Rule

EXPRESS_Rule_Vector

Subtypes/Supertypes

EXPRESS_Function_Vector

*

*

*

*

*

*

Fig. 16: Structure of the 'schema' object

One Java class is created for each type and entity defined in an EXPRESS source file. In additiona Java class is also created for each type or entity which is used in aggregation in the schema.These aggregation classes are inherited from the java.util.Vector class so all the limitationsdefined in the schema for different types of aggregations have to be added. This usually meanslimiting the number of items in a list or checking that each item appears just once in the list.Actually even this number of classes is not enough, because type casting requires that also thecorresponding super classes of aggregation classes have to be defined. For example for theTC_PRODUCT_MODEL schema 253 Java source files are created.

Actual parsing is done by first creating an instance for each type and entity and then defining theattributes for each item. This approach enables referencing to items that have not yet been fullydefined. References to super- and subtypes are the most obvious reasons for this kind ofapproach. Values of attributes are separated from the original definition string using standardtools provided by Java. The class java.util.StringTokenizer is used to separate definitions fromeach other and the class java.util.Enumeration is used to go through and define each attribute.

Functionality of the schema browser

Generic EXPRESS schema browser is provided for studying entity definitions in detail. A treelike hierarchy is used as an interface to access the definition of each entity. The user can checkthe inheritance path, specifications of attributes and rules of an entity by selecting it from the tree(Fig. 17). The schema can also be reproduced to represent the definitions stored in the schemainstance. This serves as a quality check for instantiations of the schema and also providesdifferent views of the schema. All inherited definitions are shown in comments inside thedefinition of each entity. This string can also be written out in HTML format.


Fig. 17: EXPRESS schema browsing

Creation of Java classes

When creating the Java classes from the schema for the first time, one file is created for eachentity, type and aggregation defined in the EXPRESS file as described above. When creatingthese files also a number of other files are created to enable the user to make some additionaldefinitions. These definitions are used in the classes next time they are generated. If somechanges have been made into the files those definitions are used in the generation of source code.

Methods provided by default

Methods for setting and getting values of all attributes are provided as well as methods forsetting and getting the value of each attribute separately. For each class at least two constructorsare defined: a default constructor with an empty parameter list and another one with parameter oftype java.util.Vector. The latter enables construction of a new instance and setting the values ofall attributes as defined in the parameter with one command. For classes of ‘types’ also aconstructor with parameter of type java.lang.String is defined. This constructor creates theinstance and sets the values of attributes according to the parameter string. Actually each classshould have a constructor with java.lang.String type of parameter, which could be used when aSTEP data file (ISO 10303-21) is read. In the current implementation the default constructor isused to create instances of entities and values of attributes are set using ‘setAllAttributes’method.

For each derive-attribute a new definition file is created. A ‘get’ method for the attribute iswritten into this file with the derive rule in comments. If the definition for this ‘get’ method isnot specified, null is always returned. Additional specification is used when creating the Javaclasses again. This approach is selected because of the complexity of the derive definitions.Manual work that has to be done is still quite small, and usually the same definitions can be usedwhen creating Java classes for the next revision of the schema. Just to make sure that outdateddefinitions are not used a check is performed each time when Java classes are created to ensurethat the specification of the derive-rule is still the same as when the specification was done.


Additional definitions

Fully schema independent browsing of product data with a Virtual Reality Interface (VRI) is notpossible, so some additional methods need to be provided. Entities containing geometricalinformation must have a pre-named method that is used when the VRML file is created. Lettingthe user to define additional methods for each entity solves this problem. In a similar way as thedefinitions for ‘get’ methods of derive-attributes are read from a file, also additional methods canbe specified in a file. Additional attributes and constructors can also be defined, but the usersshould be very careful what to add into the classes, because the idea is to define the datastructure in the schema, not in these files. The adopted approach is illustrated in Fig. 18.

Specification files Specification files

Schema

SchemaDependencies

*

Entity*

DeriveAttributes

Methods

AddAttributes.txt

Constructors.txt

DeriveAttribute.txt*

Method.txt*

ProMoTe ProMoTe

STEP

Java Internet

VR

EXPRESS

EXPRESSSchema

Fig. 18: Additional definitions for Java classes in ProMoTe

Another usage of additional methods is to enable arrangement of instances according to thecontent hierarchy specified in the data model. This kind of hierarchy is used for example in theIFC 1.5 final model, where instances can be arranged in a hierarchical structure, defined in themodel using instances of class IfcRelContains.

Data browsing

Reading a STEP file

STEP file parsing is done in two stages: first all instances of entities are created using the defaultconstructor and then the values of attributes are set for each instance. Instances of types areconstructed using the definition string from the STEP file as an argument. After all instances oftypes referred in the instance of an entity have been created, the setAllAttributes method is usedto set the values of attributes.

All created instances of entities are saved in an instance of java.util.Hashtable, which links theinstance with a unique id. If the schema supports unique id, then this id can be used or else a newid is generated. This enables easy and fast access to each instance of entity if the id is known.


Browsing data

A generic STEP data browser, i.e. a tool for studying the values of attributes of instances, istechnically a quite straightforward task to be implemented. Names of attributes can be requestedfrom the entity instance of a schema or from the selected instance itself. If the instance of thecorresponding schema is not available, then java.lang.reflect-package provides methods to accessnames of attributes of the specified class. In the selected approach names of attributes arerequested from the instance of the schema. Values of attributes can be asked with the‘getAllAttributes’ method generated automatically for each entity class.

Fig. 19: Data browsing with ProMoTe

A tree structure presentation is selected for viewing the data content of the model. Instances ofeach class are shown below the name of a class or entity (see Fig. 19). Class name serves as atitle and when the tree is structured according to the inheritance hierarchy of the entities, itprovides an easy access to each individual instance as well as groups of instances. Selection ofinstances is made easy by defining that selecting a name of an entity causes all instances of theselected entity and all instances of the subclasses of that entity to be selected.

If some kind of hierarchical structure is specified in the data model, like the ifcRelContains-structure in the IFC 1.5 final schema, methods for showing this hierarchy can be specified asadditional methods as described in the previous section (Fig. 20).


Fig. 20: Content hierarchy view to the data in ProMoTe

Other features

Creating lists from selected instances is also a schema dependent feature. When creating the list,predefined method names are used. These methods are implemented in a schema dependencies-folder. A similar approach is applied for creating VRML models as described below.

By selecting groups of instances the user can create a partial STEP-file containing only theinstances, which are referred by the selected instances. If no items are selected the whole modelis saved. A STEP-file can also be written in HTML format, enabling easy viewing.

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

ProMoTe browser can create a VRML-file, which can be viewed with a virtual reality browser(VRB). This feature is schema dependent and pre named methods are used to create the VRMLfile. These methods have to be implemented for each schema.


VR browser as interface to Product Model

A VRB can be used as an interface to product data, enabling selection of instances and triggeringspecified methods (Fig. 21). In our case the public domain VRB Cosmo player was chosen as thegraphical user interface (GUI). VRB is embedded in a HTML file with the help of a ProMoTeVRML applet, which enables connection from VRB back to ProMoTe via a socket. Values ofattributes can be viewed as well as documents linked to instances as if the instance was selectedfrom the ProMoTe program itself.

Fig. 21: 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 VRmodel can be changed. This enables turning on and off a specified instance or changing thecolour of it. For example in visualisation of construction schedule hiding of instances can beused to simulate construction of the building day by day. Changing the colour can be used tohighlight instances, which are in a conflict, or to visualise changes in the model by showingdifferent versions of instances in different colours.


Client/Server functionality

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 theserver instance of ProMoTe. In the client instance the remote model can be browsed andmanipulated in the same way as a local model. When the VRML-model is generated from aremote model, the conversion is done in the server instance of ProMoTe. Only the VRML file issent through the net, so the amount of transferred data is kept as small as possible. This modelcan be browsed in the VRB as if it was local.

ProMoTe Client ProMoTe Client

STEP

Java Internet

VR

EXPRESS

ProMoTe Server ProMoTe Server

STEP

Java InternetVR

EXPRESS

ProMoTe Client/Server ProMoTe Client/Server

STEP

Java Internet

VR

EXPRESS


STEP

Java InternetVR

EXPRESS


STEP

Java InternetVR

EXPRESS


STEP

Java InternetVR

EXPRESS

Fig. 22: ProMoTe Client/Server functionality


Application Interfaces to the Product Data Management Environment

The application workpackages A, B and C have each implemented in their respectivecommercial AEC/FM software packages interfaces for import/export of STEP physical filesconforming to the ToCEE product data model specification. For their integration in theenvironment and the communication with the ToCEE servers different approaches have beenused. This has been done partially on purpose, in order to examine different possible alternatives,as shown on the general schema of the environment architecture given in Fig. 7 (pg. 20).

Workpackage A: Connection to the PDM environment from SOFiCAD by SOFiSTiK

The connection of the tools for architectural and structural design in WPA to the PROMISEserver is realised with the help of a generic Information Logistics Client prototyped on the basisof the communication methods of the ToCEE Information Logistics Server. Within theapplication system product data support is achieved with the help of the ToCEE Step Toolbox.

The ToCEE Step Toolbox has been specially developed with the purpose to support file-baseddata exchange between the applications for building design in WP A and the PDM server. Itenables C++ based client applications to create, send and retrieve STEP physical files to/fromthe PDM server. The Toolbox itself uses the EXPRESS specifications of theTC_PRODUCT_MODEL. For each entity and type in the TC_PRODUCT_MODEL schemathere is a corresponding C++ class that contains the same information as the respectiveEXPRESS entity. Thus, the Toolbox is effectively a unified C++ early binding interface for easyaccess to STEP physical files, based on the TC_PRODUCT_MODEL and conforming to ISO10303-21, implementation level 2;2. The advantage of the chosen early binding method for anapplication (as opposed to late binding) is in its more effective performance. The greaterflexibility of the late binding method used in PROMISE (especially concerning the uniformprocessing of any data model) is not needed from an application point of view, since anapplication always commits to a specific data model.

The functionality of the Toolbox is fully encapsulated in the application system whereas theInformation Logistics Client serves as a client adapter to the ILS and consequently also toPROMISE.

Workpackage B: Connection to the PDM Environment from Geotechnical Works System PAULAdeveloped by D’Appolonia

The geotechnical works system developed in WPB is connected to the PDM server in a slightlydifferent way. Instead of implementing a comprehensive Information Logistics client as in WPAa dedicated light-weight tool has been prototyped on the basis of the InfoContainer API. Thistool is fully integrated in the application system. It is invoked directly from the application menuand supports exactly the specific features needed in the application. This is achieved by using theserver functions as building blocks for the implemented specific client functions. When a clientfunction is triggered from within the application several server requests are executed insequence, the results of which are collected and transformed to the needed internal format.

A specific feature of the client realisation is the use of the mapping features of the PDM server inorder to filter and transform the data available in a product model based on theTC_PRODUCT_MODEL schema into the application-specific model used in WPB. Forimporting / exporting product data in STEP physical file format an own dedicated module hasbeen prototyped.


Workpackage C: Connection to the PDM environment from Cu-FIMS by Kupari Engineering Oy

The commercial FM application CU-FIMS implements an entirely different integration approachcompared to the other applications. It shows how the generic ProMoTe browser can becustomised for use as a client adapter for existing legacy applications.

The ProMoTe browser provides the facility management a schema independent tool forbrowsing and using the available models in the ToCEE environment. All available servers in theproject environment can be connected through the Information Logistics System. ProMoTebrowser can be used to download separate instances of a selected model or the whole model ifrequired. The model can also be visualised as a virtual reality model, which can be used as aninterface to product data. User specified queries can be used to select instances that fulfil definedrequirements.

The connection to the PROMISE-server is implemented using the InfoContainer API. Receiveddescriptions of requested instances are populated as ProMoTe objects, containing the sameinformation as the original object that was downloaded. References to other objects aremaintained using a hashtable connecting the object reference provided by the server and thecorresponding ProMoTe object populated to represent it. If the whole model is downloaded, it istransferred as a STEP file and ProMoTe populates it as any other STEP file.

Data transfer between ProMoTe-browser and facility management software (Cu-FIMS) is basedon STEP exchange files. In addition to transferring of the whole model also just requiredinstances (and all instances that are referred to) can be transferred.


4. CONCLUSION

The objectives for product modelling have been achieved by developing the ToCEE modellingframework, where the layered approach has been realised for the specified domain: the modelsspecifically cover the building design (from architectural to structural and HVAC), geotechnicalconstruction and finally facility management - where construction and facility management gettheir initial information from design. The scope has been on a high level (on meta and kernellevels, and on neutral level when there have been no models for the needed information, e.g.contract and conflict models). The ToCEE layered modelling architecture has been based on theIAI project model IFC version 1.5 (pre-beta release), in hope for more rapid industry deploymentthan by a strictly STEP-based approach, but in good faith that the IFC core model will eventuallybecome the basis for STEP BCCM. Furthermore, the adopted architecture has been modified todefine clearly 5 levels of modelling abstraction: meta, kernel, neutral, aspect and application.

Also, the objectives for intra- and interoperability methods have been defined by specification ofthe functionality of the Product Data Management Server in the ToCEE client-server systemarchitecture, including data conversions between different aspect models and model managementtaking consistency after updates into account.

The requirements to support multidisciplinary, distributed aspects of building informationmanagement are satisfied in a larger scope conceptually, and proven by prototypeimplementation in a smaller one.

On the basis of the experience gathered from the implementation, as overall conclusion it shouldbe noted that an IFC-based framework can work in principle for CEE, but needs enhancements.Enhancements are required not only in domain models (flesh on the bones) but also in handlingconcurrent engineering requirements like change management and parallel versions, legal issues,transaction management.


APPENDICES

Appendix I. References

Bibliography

Ammermann E., Junge R., Katranuschkov P., Liebich T., Scherer R.J. (1994): COMBI Deliverable A2:Concept of the Object-Oriented Model for Building Design, Parts 1 & 2, EU ESPRIT Project 6609,Res. Report 1-2/94, CIB, TU Dresden, Germany.

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

Bailey I., Hardwick M., Laud A., Spooner D.L. (1996): Overview of the EXPRESS-X Language. Proc. 6thAnnual Conf. of the EXPRESS User's Group, Toronto, Canada.

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

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

ESPRIT IV-20587 (1995): EU ESPRIT IV Project 20587 ToCEE - Project Programme, EU/CEC,Directorate Generale III, Brussels, Belgium.

Gielingh W. (1988): General AEC Reference Model, TNO Report, B1-88-150, Delft, Netherlands.

Heller P., Roberts S., Seymor P., McGinn T. (1997): Java 1.1, Developer's Handbook, SYBEX Inc. US.

Hemiö T., Katranuschkov P. (1999): Virtual Reality: Human Interface to Product Data, to appear in:Proc. of the int. conf. on Concurrent Engineering in Construction, CEC’99, Helsinki, Finland.

Herold K. (1997): Universal Building language, Journal of Computing in Civil Engineering, 2(1).

Hyvärinen J., Katranuschkov P., Scherer R.J. (1996): ToCEE: Product Modelling and Interoperability -Concepts for the Product Model and Interoperability Management Tools, Deliverable F2-1, EUESPRIT Project No. 20587 ToCEE, 55 p., Brussels.

Hyvärinen J., Katranuschkov P., Scherer R.J. (1996): ToCEE: Product Modelling and Interoperability -Formal Specification of the Modelling Framework Schemata, Deliverable F2-2, EU ESPRIT ProjectNo. 20587 ToCEE, 165 p., Brussels.

Hyvärinen J., Katranuschkov P. (1997): Product Data Management Methods in a Concurrent Engi-neering Environment for AEC, in: Heinisuo M. (ed.) Applications of Artificial Intelligence inStructural Engineering - IV, Proc. 4th Workshop of the European Group for Structural EngineeringApplications of Artificial Intelligence (EG-SEA-AI), Lahti, 1-2 Sept. 1997, Report 22, Dept. CivilEngineering Structural Mechanics, Tampere University of Technology, Tampere, Finland, p. 195-202.

Intellicorp (1994): The KEE Software Development System, Version 4.1, User’s Manual, Intellicorp Inc.,Mountain View, CA.

International Alliance for Interoperability (1997): Industry Foundation Classes – End-User Guide andSpecifications, IAI Publ., Washington, DC.

International Alliance for Interoperability (1997): IFC Object Model for AEC Projects, IFC Release 1.5Model Reference Documentation, Final Version, IAI Publ., Washington, DC.

ISO 10303-1 IS (1994): Product Data Representation and Exchange - Part 1: Overview andFundamental Principles. International Organisation for Standardisation, ISO TC 184/SC4, Geneva.

ISO 10303-11 IS (1994): Product Data Representation and Exchange - Part 11: Description Methods:The EXPRESS Language Reference Manual, International Organisation for Standardisation, ISO TC184/SC4, Geneva.

ISO 10303-21 IS (1994): Product Data Representation and Exchange - Part 21: ImplementationMethods: Clear text encoding of the exchange structure, International Organisation forStandardisation, ISO TC 184/SC4, Geneva.


ISO 10303-22 DIS (1996): Product Data Representation and Exchange - Part 22: ImplementationMethods: Standard data access interface specification, International Organisation for Standardisation,ISO TC 184/SC4, Geneva.

ISO 10303-41 IS (1994): Product Data Representation and Exchange - Part 41: Integrated resources:Fundamentals of product description and support, International Organisation for Standardisation, ISOTC 184/SC4, Geneva.

ISO 10303-42 IS (1994): Product Data Representation and Exchange - Part 42: Integrated resources:Geometric and topological representation, International Organisation for Standardisation, ISO TC184/SC4, Geneva.

ISO/TC184/SC4/WG11/N002 (1996): EXPRESS-X Reference Manual WD.

ISO/TC184/SC4/WG3/N599 (1997): ISO 10303-106 WD: Product Data Representation and Exchange -Part 106: Building construction core model.

ISO/TC184/WG5/N202 (1994): PISA Information Modelling Language.

Karstila K., Katranuschkov P., Mangini M. (1996): ToCEE : Product Modelling and Interoperability -Requirements, Deliverable F1, EU ESPRIT Project No. 20587 ToCEE, 30 p. Brussels.

Katranuschkov P., Scherer R. J. (1995): COMBI Deliverable A4: User Manual of the Product ModellingIntegration Environment, PROMINENT v. 1.1, EU /CEC ESPRIT III Project No. 6609, TU Dresden,Germany.

Katranuschkov P., Scherer R. J. (1996): Schema Mapping and Object Matching: A STEP-BasedApproach to Engineering Data Management in Open Integration Environments, Proc. CIB-W78Workshop „Construction on the Information Highway“, Bled, Slovenia.

Katranuschkov P., Hyvärinen J. (1998): Product Data Server for Concurrent Engineering in AEC. Proc.of the 2nd European Conference on Product and Process Modelling in the Building Industry, Amor R.,Scherer R.J. (ed.), Building Research Establishment, Watford, UK, pp. 277-289.

Katranuschkov P., Scherer R.J. (1997): Framework for Interoperability of Building Product Models inCollaborative Work Environments, in: Choi C.-K., Yun C.-B., Kwak H.-G. (eds), Proc. 7th int. conf.“Computing in Civil and Building Engineering” (ICCCBE-VII), Seoul, Korea, pp. 627-632.

Luiten G., Froese T., Björk B-C., Cooper G., Junge R., Karstila K. & Oxman R. (1993): An informationreference model for architecture, engineering and construction, in Mathur K.S., Betts M.P., ThamK.W. (eds) „Management of information technology for construction“, World Scientific Publishing,Singapore.

Scherer R.J. (1998): A Framework for the Concurrent Engineering Environment, in: Amor R., SchererR.J. (eds) Proc. of the 2nd European Conf. on Product and Process Modelling in the Building Industry,Building Research Establishment, Watford, UK.

Scherer R. J., Sparacello H.-M. /eds./ (1996): COMBI Final Report. EU /CEC ESPRIT III Project No.6609, TU Dresden, Germany.

Scherer R. J., Katranuschkov P. (1999): Knowledge-Based Enhancements to Product Data Server Tech-nology for Concurrent Engineering, in: Proc. 5th int. conf. on Concurrent Enterprising, ICE’99, TheHague, Netherlands.

Scherer R.J., Wasserfuhr R., Katranuschkov P., Hamann D., Amor R., Hannus M., Turk Z. (1997):A Concurrent Engineering IT Environment for the Building Construction Industry, in: Fichtner D. andMacKay R. (eds.) Facilitating Deployment of Information and Communication Technologies forCompetitive Manufacturing, Proc. European Conf. on Integration in Manufacturing, IiM’97, ISBN 3-86005-192-X, publ. Selbstverlag TU Dresden, Dresden, Germany, pp.31-40.

Wasserfuhr R., Reinecke W., Scherer R.J. (1996): ToCEE: Information Logistics - Concepts, DeliverableE2, EU ESPRIT Project No. 20587 ToCEE, Brussels, 55 p.

Wasserfuhr R., Scherer R.J. (1999): ToCEE: Information Logistics – Final Report, Deliverable E4,EU ESPRIT Project No. 20587 ToCEE, Brussels.

Watson A. & Crowley A. (1995): CIMsteel Integration Standards, in Scherer R.J. (ed) "Product andProcess Modelling in the Building Industry", Proc. of the 1st European Conf. on Product and ProcessModelling in the Building Industry, Dresden, Germany, Balkema, pp 491-494.


WWW Resources:

Projects:

• ToCEEhttp://wwwcib.bau.tu-dresden.de/tocee/

• ATLAS / ESPRIThttp://www-uk.research.ec.org/esp-syn/text/7280.htmlhttp://cic.sop.cstb.fr/ILC/ECPROJEC/ATLAS/atlas.htm

• COMBI / ESPRIThttp://wwwcib.bau.tu-dresden.de/combi/

• COMBINE, COMBINE II / JOULEhttp://erg.ucd.ie/combine.html

• CIMSTEEL / EUREKAhttp://www.leeds.ac.uk/civil/research/cae/cimsteel/cimsteel.htm

• daVINCI / CAIROhttp://ganesh.mit.edu/

• GEMhttp://www.tno.nl/instit/bouw/project/gem/home.html

• IAIhttp://iaiweb.lbl.gov/member-ftp at iai.lbl.gov

• VEGA / ESPRIT http://www.tno.nl/instit/bouw/project/Vega/vegahome.html

• VTT / STARhttp://www.vtt.fi/cic/projects/star/star.html

Standards and specifications:

• CORBAhttp://www.omg.org/

• EXPRESS-Chttp://www-rpk.mach.uni-karlsruhe.de/~ecco/EXPRESS-C/index.html

• EXPRESS-Xhttp://www.mel.nist.gov/step/parts/expressx/

• Javahttp://www.javasoft.com/

• STEP/SOLIS (SC4 On-Line Information Service)http://www.nist.gov/sc4/

• STEP/Part 106: Building Construction Core Model (BCCM)http://www.bre.co.uk/~itra/ceic.htm

• STEP AP 230: Building Structural Frame: Steelworkhttp://www.leeds.ac.uk/civil/research/cae/step/ap230/ap230.htm


Appendix II. Related work

For various reasons, product model technology is nowadays not very widely used in the buildingindustry, the preferred way of modelling still being based on traditional CAD technology.However, this situation is gradually changing, which is evidenced by the rigorous interest andthe participation in different development consortia on the side of big CAD vendors (like e.g.Autodesk, Bentley, Nemetschek, PAFEC etc.) The impetus for this positive trend has been givenon the one hand by big construction companies, that have realised the benefits from product datatechnology application, and on the other hand by the achievements and the experience gained inseveral international and national building IT projects.

The basic characteristics of related efforts that have been the background of the work in theToCEE workpackage F are summarised in short in the table below.

Table A.II-1: Summary of related R&D projects and standardisation work

Project / Effort Domain Approach Use of STEPmethodology

Relevance to ToCEE

European IT projects in building & construction

ATLAS Large Scale Engineering,multidiscipl. environment,life-cycle modelling

Layered model speciali-sations (Aspect models,View type models)

YES product model frame-work, issues in inter-operability

CIMSTEEL Structural steel frames Harmonised logical productmodel(used as basis for thedevelopment of AP 230)

YES(CIMsteel 2)

product model frame-work, structuralsystem modelling,tools integration

COMBI Structural design Hierarchical architecture:Kernel (minimal) - Aspectmodel structure

YES Product model frame-work, interoperability,communicationmethods

COMBINE 2 Energy design(architecture and HVAC)

Harmonised integratedproduct data model

YES Product model frame-work, arch. models,HVAC models,communicationmanagement (ExEx)

GEM General engineeringmodel for product life-cycle with focus on eng.analysis issues

Generic specification andmodelling of eng. analysis

YES Integration methods

Selected other IT Projects in building & construction

EDM-2 General engineering datamodel, focus on arch. andstructural design

Generic model, classescontaining methods fordynamic model evolution

NO Interoperability,flexible interfaces,dynamic change mgmt

SEED Standard-independentdesign

Model of design standardsand interoperability to acontext-oriented productmodel with the help of anagent communicationlanguage and a sharedneutral model schema

NO Interoperability tosemantically verydifferent models,concurrent access tostandards andregulation knowledge

STAR Product modelling ingeneral

Generic product data model YES generic objectspecifications


Basic research

ACL/KIF Environment fordistributed knowledge-based systems

general formalisedinterfaces to knowledge-based agents

NO interoperability anddata exchange aspects,mapping specifications

VEGA Distributed systems Supporting methodologyand tools for distributedsystems and concurrency,adapted to the needs of theB&C domain

YES(aims to

extend basicmethods)

Concurrent access todistributed STEP databases; extension ofSDAI to supportdistributed data accessby means of anadapted object brokertechnology

Standardisation efforts

ISO/STEP/AEC/B&C

Building & Construction,HVAC, Steel structures &3D-CAD models

STEP AP Approach;Core - Aspect models(Part 106)

YES guideline for productmodel development,as an integrationvehicle;at present work isstopped because ofIFC developmentwhich is seen of higherpriority

IAI/IFC Architectural, HVAC &Facilities management

Core - Aspect models,Implementation of buildingobjects in CAD

Not directly(but in closerelation, uses

SPF dataexchange, the

IntegratedResources)

Possibilities forinteroperability ofproduct model basedenvironment withCAD


Appendix III. Formal Specifications used in the ToCEE PDM Environment

Overview

The specifications given herein are the common basis for the operational interoperability of the PDMenvironment in ToCEE, as well as for the communication to other ToCEE components through theInformation Logistics Server. Not covered are standards, such as STEP, which are used in accordance tothe specifications given in the relevant documents.

The PDM environment builds upon the following set of formally defined concepts and data formatsenabling the interoperability of the various components of the environment (the PDM server PROMISE,the Schema and Model Browser ProMoTe, product data related client adapters and the integratedengineering applications from workpackages A, B and C):

Issue Sources

• Object identification this document, pg. 45ToCEE Deliverable E2

• Units of measure this document, pg. 46

• Property sets, defined in accordance with the propositionsof the IFC project model, version 1.5 final

this document, pg. 47

• The InfoContainer API, version 1.0.8 this document, pg. 51ToCEE Deliverable E4

• Search templates for the InfoContainer API, version 1.0.1 this document, pg. 63

• The product data management server functions, version 1.0.4based on the InfoContainer API

this document, pg. 65

• The ToCEE data models this document, pg. 71(includes only screenshots from thePDM server for the main ToCEE schemaTC_PRODUCT_MODEL)

• The ToCEE Server Interoperability Protocol (SIOP) ToCEE Deliverables E2, E4

• The Schema Mapping Language CSMLdeveloped in the ESPRIT III project 6609 COMBI

COMBI Deliverable A4(Katranuschkov & Scherer, 1995)

• The EXPRESS language for the specification of all datamodels used in server and client implementation

ISO 10303-11 IS (1994)

• The EXPRESS-C language for the formal specificationof all supported modelling object server operations

ISO/TC184/SC4/WG5/N202 (1994)

• The STEP physical file data exchange specification foruploading/downloading whole product model contentsto/from the PDM server

ISO 10303-21 IS (1994)

• The Java 1.1 language specification for the InfoContainerJava language toolkit and the software implementation ofPROMISE/F (the front-end PDM server in the ToCEEenvironment), ProMoTe (the ToCEE Schema and ProductData Browser) and all PDM clients and client adaptersimplemented in the Java language

www.javasoft.com


Object Identification

All concepts - model schemata, data models, object classes and object instances - are uniquely identifiedand remain persistent throughout the duration of a project in the ToCEE environment. Uniqueidentification of concepts is maintained centrally by the Information Logistics Server. Concepts that areused within the PDM environment are registered on the Information Logistics Server at the beginning of aproject and are available to all PDM clients. Product models and their contained data instances can becreated during a project by any registered project actor, but are assigned unique IDs exclusively by thePDM server. This is the basic mechanism for maintaining the consistency of the data across disciplines,domain models and time.

The following syntax given in EBNF is used consistently throughout the PDM environment for theidentification of product data related concepts:

<conceptID> ::= <schemaID> | <modelID> | <classID> | <objectInstanceID>

<schemaID> ::= <symbol><modelID> ::= <symbol> '.' <longint><classID> ::= <simpleClassID> | <qualifiedClassID><simpleClassID> ::= <symbol>

<qualifiedClassID> ::= [ <schemaID> ':' ] <symbol><objectInstanceID> ::= [ <modelID> ':' ] <classID> '.' <longint><symbol> ::= <letter> { <alphanum> }*<longint> ::= <digit> { <digit> }*

<alphanum> ::= <letter> | <digit><letter> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h'.| 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' |

'y' | 'z' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H'.| 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W' | 'X' |

'Y' | 'Z' | '_'<digit> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' |

'8' | '9'

Notes:

• The above syntax is consistent with the overall specification of concepts on the Information LogisticsServer and thus enables access to all data types defined in the ToCEE modelling framework in auniform way.

• The schemaID prefix in <classID> may be omitted when unambiguous. This is the case for allclasses defined in the ToCEE modelling framework.

• The modelID prefix in <objectInstanceID> may be omitted if the referenced object isunambiguous. This happens for example in many server responses where the modelID is given once,as a separate output parameter.

• <longint> may contain as many digits as allowable in the internal representation of long integernumbers, i.e. it should represent a valid integer < 264 –1.

Examples:

SchemaID: TC_PRODUCT_MODEL

ModelID: TC_MODEL.Arch_Model_1

ObjectInstanceID: TC_MODEL.Arch_Model_1:TC_IfcWall.134012


Units of Measure

In the ToCEE prototype environment all units of measure used in STEP physical file based data exchangein accordance with ISO 10303-21 and in the functions based on the InfoContainer API are fixed as givenin the table below.

Table A.III-1: Units of measure for the ToCEE demo environment

Dimensional Unit Required Measure

ACCELERATION metres_per_second_per_second

ANGLE radian

AREA square_metre

AREA_DENSITY kilograms_per_square_metre

ELASTICITY kiloNewtons_per_square_metre

FORCE kiloNewton

FORCE_PER_LENGTH kiloNewtons_per_metre

FREQUENCY Hertz

INERTIA metre_to_power_four

INERTIA_PER_LENGTH metre_to_power_four_per_metre

LENGTH metre

LIN_THERM_EXP metres_per_degree_Celsius

LINEAR_STIFFNESS kiloNewtons_per_metre

MASS kilogram

MASS_DENSITY kilograms_per_cubic_metre

MASS_PER_LENGTH kilograms_per_metre

MODULUS cubic_metre

MODULUS_PER_LENGTH cubic_metres_per_metre

MOMENT kiloNewton_metre

MOMENT_PER_LENGTH kiloNewton_metres_per_metre

PRESSURE kiloNewtons_per_square_metre

RATIO percent

ROTATIONAL_STIFFNESS kiloNewton_metres_per_radian

STRESS kiloNewtons_per_square_metre

SURFACE_AREA_PER_LENGTH square_metres_per_metre

TEMP_GRADIENT_MEASURE degree_Celsius_per_metre

TEMPERATURE degree_Celsius

TIME second

VELOCITY metres_per_second

VOLUME cubic_metre

Note:All measure values are defined in accordance with IFC Version 1.5 final and ISO 10303-41.


Property Sets

The table below presents the property sets defined according to the IFC 1.5 final model specification,adapted respectively for the ToCEE prototype environment. These property sets are used in ToCEEprimarily to support the information needs of the engineering applications developed in WPs A, B and C.They don’t pretend to be exhaustive.

The columns in the table are defined as follows:

• PropertySet name is unique in ToCEE – this is the value for TC_IfcPropertySet.Descriptor

• ToEntity specifies legal entity type(s) for the set [Value for TC_IfcPropertyTypeDef.TypedClass]

• ToType specifies legal generic type(s) for the set [Value for TC_IfcPropertyTypeDef.GenericType]• Properties specifies a list for TC_IfcPropertySet.HasProperties of the correct TC_IfcProperty

subtypes:− simple property

(names unique in the PropertySet context - appearing in TC_IfcSimpleProperty.Descriptor)− reference to another PropertySet: pSetRef− ref. to ToCEE entity instance (by its uniqueID): oRef

• PropertyType specifies the basic data type for simple properties• Cardinality specifies the multiplicity of the related PropertyType.• Unit Dimension specifies the required dimensional units (see table "Units of Measure“ – pg.46).

In addition the following global rule applies:• Nloads must have the same value in TC_Loads and TC_AnalysisTypes.

Table A.III-2: Property set definitions for the ToCEE demo environment

PropertySet name ToEntity ToType Properties Cardinality PropertyType Unit DimensionTC_Crane TC_IfcEquipment LoadCapacity 1 REAL kiloNewton

Span 1 REAL metre

TC_CeilingType TC_IfcCeiling FireRating 1 INTEGERAcousticRating 1 INTEGER

TC_DoorType TC_IfcDoor FireRating 1 INTEGERAcousticRating 1 INTEGERLockType 1 STRINGExterior 1 BOOLEAN

TC_SpaceStandard TC_IfcSpaceProgram SpaceStandard FireSeparation 1 REALProgOccupants 1 INTEGEREnvironmentalRequirements 1 STRINGStandardLength 1 REAL metreStandardWidth 1 REAL metre

TC_WallType TC_IfcWall FireRating 1 INTEGER

AcousticRating 1 INTEGERThermalRating 1 INTEGER

TC_WindowType TC_IfcWindow FireRating 1 INTEGERAcousticRating 1 INTEGERFrameType 1 STRINGGlazingType 1 STRING

TC_Equipment TC_IfcEquipment UserInstructions 1 STRINGTC_ConnectionSizes LIST [1:N] pSetRefTC_ConnectionTypes LIST [1:N] pSetRef

TC_ConnectionSizes TC_IfcBuildingElement ConnectionSize LIST [1:N] STRINGTC_ConnectionTypes TC_IfcBuildingElement ConnectionType LIST [1:N] STRINGTC_Maintenance TC_IfcBuildingElement MaintenanceInstructions 1 STRING

Property set definitions for the ToCEE demo environment (continued - sheet 2/3)

PropertySet name ToEntity ToType Properties Cardinality PropertyType Unit DimensionTC_FM_Site TC_IfcSite LegalDescription 1 STRING

TaxID 1 STRING

Zoning 1 STRINGTC_BuildingSite TC_IfcSite BuildingSite GroundLevel 1 REAL metre

WaterTable 1 REAL metreTC_DumpSite TC_IfcSite DumpSite TotalCapacity 1 REAL cubic_metre

Remains 1 REAL cubic_metreDistance 1 REAL metre

TC_FoundationProperties TC_FoundationSystem StructuralSystem FoundType 1 INTEGERFoundDepth 1 REAL metreTC_Loads 1 pSetRef

TC_FootingProperties TC_SpreadFooting MaxSettlement 1 REAL metreSettlement 1 REAL metreArea 1 REAL square_metre

Weight 1 REAL kilogramBCSF 1 REAL

TC_PileGroupProperties TC_PileGroup Npiles 1 INTEGERTC_PileProperties L [1:Npiles] pSetRefTypology 1 INTEGEROrder 1 INTEGER

MaxSettlement 1 REAL metreSettlement 1 REAL metreArea 1 REAL square_metreWeight 1 REAL kilogramBCSF 1 REALHeadDeflection 1 REAL metre

Property set definitions for the ToCEE demo environment (continued - sheet 3/3)

PropertySet name ToEntity ToType Properties Cardinality PropertyType Unit DimensionTC_PileProperties TC_Pile Xoff 1 REAL metre

Yof 1 REAL metre

Diam 1 REAL metreTC_StructuralProperties TC_IfcSystem StructuralSystem TC_Loads 1 pSetRef

TC_AnalysisTypes 1 pSetRefTC_Structural_Interaction TC_IfcBuildingElement TC_LoadRes L [1:Nloads] pSetRef

TC_SupportConditions 1 pSetRefTC_SupportConditions TC_IfcBuildingElement Dx 1 REAL metre_per_kiloNewton

Dy 1 REAL metre_per_kiloNewtonDz 1 REAL metre_per_kiloNewtonRx 1 REAL radian_per_kiloNewton_metreRy 1 REAL radian_per_kiloNewton_metreRz 1 REAL radian_per_kiloNewton_metre

TC_LoadRes TC_IfcBuildingElement LoadType 1 INTEGER

Fx 1 REAL kiloNewtonFy 1 REAL kiloNewtonFz 1 REAL kiloNewtonMx 1 REAL kiloNewton_metreMy 1 REAL kiloNewton_metreMz 1 REAL kiloNewton_metre

TC_Loads TC_IfcSystem StructuralSystem Nloads 1 INTEGERTC_FoundationSystem LoadType L [1:Nloads] INTEGER


The InfoContainer API

The InfoContainer API provides the basis for accessing the various servers in the ToCEE environment,for the Server Interoperability Protocol (SIOP) and for the PDM services build upon it. It is used topackage and represent all types of data that can be exchanged in client-server communication based onthe ToCEE Information Logistics services.

This section presents:• the InfoContainer Externalisation, i.e. the language independent definition of an InfoContainer object,

that is recognised and can be used in any server request, and• the available public methods in the InfoContainer Java 1.1 language binding that can be used directly

in client applications written in the Java language.

More comprehensive documentation of the InfoContainer API is available in HTML format athttp://wwwcib.bau.tu-dresden.de/tocee. Detailed description of the communication concepts and the useof the InfoContainer API in the ToCEE environment is given in WP E (ToCEE Deliverables E2, E4).

InfoContainer Externalisation (in EBNF)

<InfoContainer> ::= <label> '(' { <par> }* ')'<label> ::= <symbol><par> ::= <symbol> ':' <value><symbol> ::= <letter> { <alphanum> }*<value> ::= <longint> | <real> | <boolean> | <logical> | <string> | <symbol> | <Aggregation> | <BLOB> | <ObjRef> | <InfoContainer><longint> ::= <digit> { <digit> }*<real> ::= [ <sign> ] <digit> { <digit> }* '.' { <digit> }* [ 'E' [ <sign> ] <digit> { <digit> }* ]<boolean> ::= 'true' | 'false'<logical> ::= 'true' | 'false' | 'unknown'<string> ::= '"' { <char> }* '"'<Aggregation> ::= '[' {value}* ']'<BLOB> ::= 'BLOB' '(' <OID> ')'<ObjRef> ::= 'oRef' '(' <OID> ')'<OID> ::= '"' <symbol> { '.' <ID> }+ '"'<ID> ::= <symbol> | <longint><alphanum> ::= <letter> | <digit><letter> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h'.| 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H'.| 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' | '_'<digit> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

Notes:

• <char> can be any valid ASCII or Unicode character• <longint> may contain as many digits as allowable in the internal representation of long integer

numbers, i.e. it should represent a valid integer < 264 –1.• Separators between syntactical elements are one or more white spaces.


Java Language Bindings for the Objects and Methods in the InfoContainer API

♦ Class Hierarchy

class java.lang.Objectclass tocee.ic.InfoContainer (implements java.io.Serializable)class tocee.ic.Aggregation (implements java.io.Serializable)class tocee.ic.ObjectRef (implements java.io.Serializable)class tocee.ic.BLOB (implements java.io.Serializable)class tocee.ic.ICSymbolclass tocee.ic.ICParserclass tocee.CEEsessionclass tocee.ilServer.OzObject (implements tocee.ilServer.InfoContainerLanguageBinding)class tocee.ilServer.OzAggreg (implements tocee.ilServer.InfoContainerLanguageBinding)class tocee.ilServer.OzOREF (implements tocee.ilServer.InfoContainerLanguageBinding)class tocee.ilServer.OzBLOB (implements tocee.ilServer.InfoContainerLanguageBinding)class tocee.ilServer.OzString (implements tocee.ilServer.InfoContainerLanguageBinding)class tocee.ilServer.OzValue (implements tocee.ilServer.InfoContainerLanguageBinding)class java.rmi.server.RemoteObject (implements java.rmi.Remote, java.io.Serializable)class java.rmi.server.RemoteServer

class java.rmi.server.UnicastRemoteObjectclass tocee.adapters.RmiImpl (implements tocee.adapters.RmiInter)

interface tocee.adapters.RmiInter (extends java.rmi.Remote)class java.lang.Throwable (implements java.io.Serializable)

class java.lang.Exceptionclass tocee.ic.FeatureTypeExceptionclass tocee.ic.MalformedICstringExceptionclass tocee.ic.MalformedICsyntaxException

♦ Class tocee.ic.InfoContainer

java.lang.Object|+----tocee.ic.InfoContainer

Synopsis:

The main class of the ToCEE InfoContainer API. Used to package and represent all types of data that canbe exchanged in client-server communication based on the ToCEE Info Logistics specification.

Class Declaration:

public class InfoContainer extends Object implements Serializable

Constructors:

InfoContainer() Default (empty) constructor.InfoContainer(CEEsession) Creates an empty InfoContainer and assigns it a session.InfoContainer(CEEsession, String) Same as InfoContainer(String s), but assigns also a session.InfoContainer(String) Creates an InfoContainer from a String, representing a valid

InfoContainer 'externalisation'.InfoContainer(String, String[], Object[]) Creates an InfoContainer instance containing the

components (features) given in the parameter list of theconstructor call.


Public Methods:

Aggregation getAggregAt(String f) Retrieves the 'Aggregation' object stored at feature f.BLOB getBLOBAt(String f) Retrieves the 'BLOB' object stored at feature f.boolean getBooleanAt(String f) Retrieves the boolean value stored at Feature f.Class getClassAt(String f) Retrieves the class of the object stored at Feature f.Object[][] getFeatureArray() Returns all component features of an InfoContainer in a

new 2-dimensional array with two sub-arrays:the featureNames and the featureValues (as Objects)

String[] getFeatureNames() Returns all feature names contained in an InfoContainer in aString array.

Hashtable getFeatureTable() Returns all features contained in an InfoContainer as areference to a Hashtable with keys - the featureNames, andvalues - the featureValues (as Objects).

Class[] getFeatureTypes() Returns an array of class objects for all features containedin an InfoContainer.

Object[] getFeatureValues() Returns an array of objects for all feature values containedin an InfoContainer.

InfoContainer getICAt(String f) Retrieves the InfoContainer object stored at feature f.String getLabel() Returns the InfoContainer label.long getLongAt(String f) Retrieves the long value stored at Feature f.ObjectRef getObjectRefAt(String f) Retrieves the 'ObjectRef' object stored at feature f.double getRealAt(String f) Retrieves the double value stored at Feature f.String getStringAt(String f) Retrieves the String stored at Feature f.ICSymbol getSymbolAt(String f) Retrieves the symbol object (ICSymbol) stored at Feature f.Object getValueAt(String f) Generic access method to retrieve the object at Feature f.void info() Prints on stdout general information about this particular

InfoContainer instance.boolean isAggregAt(String f) Tests if the value of feature f is an aggregation.boolean isBLOBAt(String f) Tests if the value of feature f is a BLOB, i.e.boolean isBooleanAt(String f) Tests if the value of feature f is a boolean value.boolean isFeature(String f) Tests if feature f exists.boolean isICAt(String f) Tests if the value of feature f is an InfoContainer instance.boolean isLongAt(String f) Tests if the value of feature f is a long value.boolean isObjectRefAt(String f) Tests if the value of feature f is an object reference, i.e.

instance of the ObjectRef class.boolean isRealAt(String f) Tests if the value of feature f is a real value (mapped to Java

double).boolean isStringAt(String f) Tests if the value of feature f is a String object.boolean isSymbolAt(String f) Tests if the value of feature f is a symbol, i.e.int numberOfFeatures() Returns the number of features stored in the InfoContainer.String setLabel(String) Sets the InfoContainer labelObject setValueAt(String f, Object obj) Sets a new value for feature f, or adds the feature with the

given value to the InfoContainer if it is a new feature.String toString() Overrides Object.toString().


♦ Class tocee.ic.Aggregation

java.lang.Object|+----tocee.ic.Aggregation

Synopsis:

Represents aggregations like lists, sets and bags in the InfoContainer API The EBNF syntax of a legalexternalisation of Aggregation objects is:<Aggregation> ::= '[' {value}* ']'

where:<value> ::= <longint> | <real> | <boolean> | <logical> | <string> | <symbol> | <BLOB> | <ObjRef> | <Aggregation> | <InfoContainer>

Class Declaration:

public class Aggregation extends Object implements Serializable

Constructors:

Aggregation() The default empty constructor.Aggregation(CEEsession) Constructs an Aggregation instance for the specified server-

client session.Aggregation(CEEsession, Vector) Constructs a Aggregation instance for the specified server-

client session and fills it with the specified elements.Aggregation(Vector) Constructs a Aggregation instance and fills it with the

specified elements.

Public Methods:

void addElement(Object) Appends a new element at the end of an Aggregationinstance.

Aggregation getAggregAt(int index) Retrieves the Aggregation instance found at position 'index'.BLOB getBLOBAt(int index) Retrieves the BLOB instance found at position 'index'.boolean getBooleanAt(int index) Retrieves the Boolean instance found at position 'index' and

converts it to the basic boolean type.Object getElementAt(int index) Retrieves the element at position 'index' in a Aggregation

instance.InfoContainer getICAt(int index) Retrieves the InfoContainer instance found at position

'index'.long getLongAt(int index) Retrieves the Long instance found at position 'index' and

converts it to the basic long type.ObjectRef getObjectRefAt(int index) Retrieves the object reference (ObjectRef instance) found at

position 'index'.double getRealAt(int index) Retrieves the Double instance found at position 'index' and

converts it to the basic double type, i.e. the 64 bitrepresentation of a real number according to IEEE 754.

int getSize() Returns the number of elements in a Aggregation instanceString getStringAt(int index) Retrieves the String instance found at position 'index'ICSymbol getSymbolAt(int index) Retrieves the ICSymbol instance found at position 'index'Vector getVector() Returns the content of a Aggregation instance as a Java

Vectorvoid insertElementAt(Object obj, Inserts a new element at position 'index' in a Aggregation

instance.


boolean isAggregAt(int index) Returns whether or not the element at ‘index’ is aAggregation instance.

boolean isBLOBAt(int index) Returns whether or not the element at ‘index’ is a BLOBinstance.

boolean isBooleanAt(int index) Returns whether or not the element at ‘index’ is a booleanvalue

boolean isICAt(int index) Returns whether or not the element at ‘index’ is anInfoContainer

boolean isLongAt(int index) Returns whether or not the element at ‘index’ is an int orlong value

boolean isObjectRefAt(int index) Returns whether or not the element at index is an objectreference (represented as an instance of the ObjectRefclass).

boolean isRealAt(int index) Returns whether or not the element at index is a real(represented as a Double instance in the InfoContainerAPI).

boolean isStringAt(int index) Returns whether or not the element at index is a Stringboolean isSymbolAt(int index) Returns whether or not the element at index is a symbol

(represented as an instance of the ICSymbol class).void removeElementAt(int index) Removes the element at position 'index' in a Aggregation

instance.void setElementAt(Object obj, int index) Sets (replaces) the element at position 'index' in an

Aggregation instance.String toString() Overrides Object.toString().

Provides a syntactically correct Aggregation externalisationfor the InfoContainer API.

♦ Class tocee.ic.ObjectRef

java.lang.Object|+----tocee.ic.ObjectRef

Synopsis:

Represents object references in the InfoContainer API. ObjectRef allows a client application to addressand/or execute methods on any remote object registered at the Object Request Broker. The EBNF syntaxof the externalisation of ObjectRef is:<ObjectRef> ::= 'oRef' '(' <OID> ')'

where:<OID> ::= '"' <symbol> { '.' <ID> }+ '"'<symbol> ::= <letter> { <alphanum> }*<ID> ::= <symbol> | <longint>

Class Declaration:

public class ObjectRef extends Object implements Serializable

Constructors:

ObjectRef() The default (empty) constructor.ObjectRef(CEEsession) Creates an empty ObjectRef instance and assigns it a

session.ObjectRef(CEEsession, String) Creates a ObjectRef instance with a given address and

session.


Public Methods:

InfoContainer execMeth (String,

InfoContainer)

Executes a method for the referenced object on the serverfor which the object has been registered. Depending on thekind of connection for the session establishes automaticallythe appropriate connection with the server or throws anexception if a communication or an i/o error occurs.

ObjectRef getConcept() Retrieves the concept of the object reference as anaddressable object reference itself.

String getConceptName() Returns the name of the concept of the object reference.String getObjectAddress() Retrieves the object address, i.e. the unique ID of this object

in the current project.String setObjectAddress(String) Sets the Object address. This method is legal only for the

respective server maintaining the unique IDs of therespectively registered server classes on the ILS.

String toString() Overrides Object.toString().Provides a syntactically correct ObjectRef externalisationfor the InfoContainer API.

♦ Class tocee.ic.BLOB

java.lang.Object|+----tocee.ic.BLOB

Synopsis:

Represents binary large objects (BLOBs) in the InfoContainer API. BLOB allows a client application toupload or download BLOBs, i.e. local files on the client machine, to/from the Object Request Broker oran associated server.

Normally, BLOB will be used in conjunction with remote method invocation for ObjectRef instances,where the input or output parameters are specified as BLOBs, e.g. for uploading/downloading text ordrawing documents, for checking in/out STEP physical files etc.

The EBNF syntax of the externalisation of BLOB is:<BLOB> ::= 'BLOB' '(' <OID> ')'

where:<OID> ::= '"' <symbol> { '.' <ID> }+ '"'<ID> ::= <symbol> | <longint><symbol> ::= <letter> { <alphanum> }*

Class Declaration:

public class BLOB extends Object implements Serializable

Constructors:

BLOB() The default (empty) constructor.BLOB(CEEsession) Creates an empty BLOB instance and assigns it a session.


Public Methods:

String getBlobID() Retrieves the BLOB ID.InputStream getInStream() Creates an input stream and associates it with the BLOB for

subsequent upload.Void lazyLoadFromFile(String) Lazy loading of a file.void loadFromFile(String) Uploads a local file to the document server and associates it

with the BLOB object.void saveAsFile(String) Downloads the file associated with the BLOB from the

document server and saves it locally in the specified file.void setBlobID(String) Sets the BLOB ID. The execution of this method depends

on the actual access rights of the application on this object.void setInStream(InputStream) Sets the input stream associated with the BLOB object and

prepares the upload of the data.String toString() Overrides Object.toString().

Provides a syntactically correct BLOB externalisation forthe InfoContainer API.

♦ Class tocee.ic.ICSymbol

java.lang.Object|+----tocee.ic.ICSymbol

Synopsis:

Represents 'symbol' values in the InfoContainer API. The EBNF syntax of a legal InfoContainer symbolis:<symbol> ::= <letter> { <alphanum> }*

The ICSymbol class is used in the InfoContainer API for representing certain top-level feature values andfor representing the enumeration values defined for entity attributes in EXPRESS schemas.

Class Declaration:

public class ICSymbol extends Object implements Serializable

Constructors:

ICSymbol() The default empty ICSymbol constructor. Note thatICSymbol instances are implicitly constructed when aconstructor of InfoContainer is called.

ICSymbol(String) The primary ICSymbol constructor. It creates an ICSymbolinstance from a specified string. The given string mustconform to the InfoContainer syntax, otherwise anIllegalArgumentException is thrown

Public Methods:

boolean equals(Object) Overrides Object.equals()String toString() Overrides Object.toString().

Provides a syntactic correct externalisation of an ICSymbolfor the InfoContainer API.

String valueOf() Returns the externalisation, i.e. the string representation ofan ICSymbol.


♦ Class tocee.ic.ICParser

java.lang.Object|+----tocee.ic.ICParser

Synopsis:

Used to parse the external representation of an InfoContainer as String. Contains a set of class (static)methods useful for tokenizing an InfoContainer string and for querying the type or content of a token.ICParser cannot be instantiated.

Class Declaration:

public final class ICParser extends Object

Public Methods:

boolean testToken(Object testObj, char c) Tests if an InfoContainer token (testObj) is equal to thespecified char value ‘c’

boolean testToken(Object testObj, Tests if an InfoContainer token (testObj) is an instance of agiven class

boolean testToken(Object testObj, Tests if an InfoContainer token (testObj) is equal to thespecified pattern object

Vector tokenizeICstring(String) Tokenizes an InfoContainer string.

♦ Class tocee.CEEsession

java.lang.Object|+----tocee.CEEsession

Synopsis:

This class is used to obtain a session for the Information Logistics Server in the ToCEE environment.Details of its usage are given in Workpackage E.

Class Declaration:

public class CEEsession extends Object

♦ Class tocee.ilServer.OzObject

java.lang.Object|+----tocee.ilServer.OzObject

Synopsis:

This class is used by the Information Logistics Server for its specific language binding for generic objectdata types in the InfoContainer API.

Class Declaration:

public class OzObject extends Object implements tocee.ilServer.InfoContainerLanguageBinding


♦ Class tocee.ilServer.OzAggreg

java.lang.Object|+----tocee.ilServer.OzAggreg

Synopsis:

This class is used by the Information Logistics Server for its specific language binding for theAggregation data type in the InfoContainer API.

Class Declaration:

public class OzAggreg extends Object implements tocee.ilServer.InfoContainerLanguageBinding

♦ Class tocee.ilServer.OzOREF

java.lang.Object|+----tocee.ilServer.OzOREF

Synopsis:

This class is used by the Information Logistics Server for its specific language binding for the ObjectRefdata type in the InfoContainer API.

Class Declaration:

public class OzOREF extends Object implements tocee.ilServer.InfoContainerLanguageBinding

♦ Class tocee.ilServer.OzBLOB

java.lang.Object|+----tocee.ilServer.OzBLOB

Synopsis:

This class is used by the Information Logistics Server for its specific language binding for the BLOB datatype in the InfoContainer API.

Class Declaration:

public class OzBLOB extends Object implements tocee.ilServer.InfoContainerLanguageBinding


♦ Class tocee.ilServer.OzString

java.lang.Object|+----tocee.ilServer.OzString

Synopsis:

This class is used by the Information Logistics Server for its specific language binding for the String datatype in the InfoContainer API.

Class Declaration:

public class OzString extends Object implements tocee.ilServer.InfoContainerLanguageBinding

♦ Class tocee.ilServer.OzValue

java.lang.Object|+----tocee.ilServer.OzValue

Synopsis:

This class is used by the Information Logistics Server for its specific language binding for all simple datatypes used in the InfoContainer API.

Class Declaration:

public class OzValues extends Object implements tocee.ilServer.InfoContainerLanguageBinding


♦ Exception Class tocee.ic.MalformedICstringException

java.lang.Object|+----java.lang.Throwable | +----java.lang.Exception | +----tocee.ic.MalformedICstringException

Synopsis:

This exception class of the InfoContainer API is thrown when an incorrect token is found in theInfoContainer externalisation as String.

Class Declaration:

public class MalformedICstringException extends Exception

♦ Exception Class tocee.ic.MalformedICsyntaxException

java.lang.Object|+----java.lang.Throwable | +----java.lang.Exception | +----tocee.ic.MalformedICsyntaxException

Synopsis:

This exception class of the InfoContainer API is thrown when the InfoContainer externalisation as Stringdoes not match the defined EBNF syntax.

Class Declaration:

public class MalformedICsyntaxException extends Exception

♦ Exception Class tocee.ic.FeatureTypeException

java.lang.Object|+----java.lang.Throwable | +----java.lang.Exception | +----tocee.ic.FeatureTypeException

Synopsis:

This exception class of the InfoContainer API is thrown when trying to retrieve a feature with animproper type from an InfoContainer instance.

Class Declaration:

public class FeatureTypeException extends Exception


Search Templates for the InfoContainer API

Some of the available product data server functions involve rule-based queries allowing to search forspecific objects in the product data repositories on the basis of specified ad hoc filtering or otherconditions. For this purpose a special syntax for search expressions is introduced for the PDMimplementation of the InfoContainer API as follows:

(1) A search expression is represented in an InfoContainer as a <string> value of the input parametersearchExpr.

(2) The general form of a search expression is:

SearchExpr ::= '(' 'FOR' <variable> { <variable> }* 'DO' '('<searchTemplate>

{ { 'AND' | 'OR' } <searchTemplate> }* ')' ')'where:<variable> ::= '?'<symbol>

Separators between syntactical elements are one or more white spaces.

(3) Each variable must appear at least once in one or more search templates and is bound at execution ofthe template where it is first referenced to the value(s) of the search result.

(4) Search templates are executed in sequence linked by logical ANDs or ORs. Therefore, variables thatare bound in a preceding search template can be re-used in subsequent ones.

(5) The results for all given variables matching a search expression are returned as values of the outputparameter resultSet which is an aggregation of one or more aggregations, depending on the numberof specified variables for the search expression.

(6) Search templates are defined as follows:

Membership:• Subclass: '(' 'ALL' <subclassID> 'ARE' <classID> ')'

• Instance: '(' <instanceID> 'IS' 'IN' [ 'CLASS' ] <classID> ')'

Attribute values:• '(' 'THE' <attributeName> 'OF' <instanceID> 'IS' <value> ')'

Cardinality:• '(' <instanceID> 'HAS' 'AT' 'MOST' <maxnum> <attributeName> ')'

• '(' <instanceID> 'HAS' 'AT' 'LEAST' <minnum> <attributeName> ')'

Equality:• '(' <term1> '=' <term2> ')'

(7) <subclassID>, <classID>, <instanceID>, <attributeName> have the obviousmeaning. They are all represented as symbols as defined in the InfoContainer API specification andcan be variables, such as ?LENGTH or valid references to existing data objects, such asTC_MODEL.Struct_Model_2:TC_IfcColumn.9966. However, within a search expressionsuch references should not be enclosed in quotations.

(8) <maxnum> and <minnum> are integers with the obvious meaning.

(9) Terms can be any of the following:

− Atomic values, such as ABC, 1 etc.

− Variables, such as ?XYZ

− Templates− Expressions

(10) Expressions can be given as:'(' 'LISP' <any-lisp-expression> ')' e.g.: (LISP (> ?X 35.0)) or'(' 'SET.OF' <value> { <value> }* ')' e.g.: (SET.OF IfcBeam IfcColumn)


Examples:

Example 1:

In order to retrieve the object references of all simple beams in a structural aspect model, i.e. all instancesof TC_IfcBeam which are defined with the GenericType SIMPLEBEAM, the following searchexpression can be used:

(FOR ?X DO ((?X IS IN CLASS TC_IfcBeam) AND (THE GenericType OF ?X IS SIMPLEBEAM)))

Use of the above search expression in the ‘find’ operation:

request (OID:”TC_MODEL.Struct_Model_1” meth: ”find” inParams:

in(searchExpr:”(FOR ?X DO ((?X IS IN CLASS TC_IfcBeam) AND (THE GenericType OF ?X IS SIMPLEBEAM)))” ) )


Product Data Management Functions based on the InfoContainer API

In the following table the function specifications for all prototyped operations of the PDM server aregiven, grouped by object classes and sorted alphabetically by name within each object class.

The columns in the table have the following meaning:

• Function name = the name of the function to be used in a request (parameter ‘meth’)

• Method of class = the top-level class in TC_PRODUCT_MODEL schema to which thefunction can be applied, i.e. the function can be used for all subclasses ofthis class and their instances(TC_PRODUCT_MODEL, the ToCEE adaptation of IFC 1.5 final, is the“main“ model schema in the ToCEE PDM environment, used as ref. basisin all ToCEE applications)

• Applies to = the function can be applied to a class ( C ) or an instance ( I )

• Users = the users that are allowed to execute the function;f(ACL) means that execution depends on the actual Access Control List,obtained from the specified accessRights;admin means that execution is allowed only for users with administratorrights (no restrictions) – this will normally be a person authorised by theProject Manager

• inParams = the input parameters to be provided in a request (parameter ‘inParams’)

• outParams = the output parameters returned in response (parameter ‘content’)

For the “externalisation” of all functions, e.g. for use in TCP/IP based communication, the followingformatting rules apply:

• Both inParams and outParams must be represented as InfoContainer.The types of their elements for each specific function are given according to the InfoContainer APIspecification.

• Object references (oRef) have to be specified as valid conceptID’s, according to the EBNF syntax forobject identification on the product server, e.g. object instances should be referenced as:[ <modelID> ':' ] <classID> '.' <longint>

• Class objects have to be prefixed by the schemaID, and instances by the modelID. As all object classes are unambiguously defined across all model schemata in the ToCEE demoenvironment, the schemaID may as well be omitted.

Examples (top-level arguments for the Information Logistics Server omitted):

Request (OID:”TC_IfcWall” meth:”inspect”)Request (OID:”TC_MODEL.Arch_Model_1:TC_IfcWall.12345” meth:”getAttribute” inParams:ic(attName:”occurrenceProperites”))

Request (OID:”TC_MODEL.Struct_Model_1” meth:”checkOut” inParams:ic(infoType:SPF))


Notes:

• All functions for TC_IfcRoot are generic and are actually also valid for the meta model classConcept and thus for any defined entity in any data model, i.e. not only for the entities in schemaTC_PRODUCT_MODEL. However, the functions given for TC_IfcRoot are not always meaningfulalso for TC_MODEL. Use the section for TC_MODEL for the applicable functions for whole models.

• Functions for TC_MODEL marked with asterisk (‘*’) are valid for any product model, not only forTC_PRODUCT_MODEL.

• Functions marked with ‘**’ require heavy computational resources. They can be executed only inrequests with syncMode = async(syncMode is top-level parameter defined in the ILS communication schema)

• optional parameters are denoted with OPT.

Table A.III-3: Function specification for the PROMISE API, v.1.0.4

Function name Method of object Applies to Users inParams outParams

createInstance TC_IfcRoot C f(ACL) content: InfoContainer objRef: oRef

find C/I f(ACL) searchExpr: String resultSet: Aggregation (value)(type of ‘value’ depends on the query)

getAccessRights I f(ACL) OPT forRole: ICSymbol (s. TC_RoleTypeEnum)OPT forUser: oRef

accessRights: Aggregation(ICSymbol) (s. TC_AccessRightsEnum)

getAttribute I f(ACL) attName: String attName: StringattContent: value

getInstances C f(ACL) OPT forModel: oRef modelRef: oRefobjRefs: Aggregation(oRef)

getMethod C/I f(ACL) methName: String methParams: InfoContainer(each element: name:type (as ICSymbol))

getMethods C/I f(ACL) N/A methNames: Aggregation(String)

getRelationshipsTree I f(ACL) N/A relating: Aggregation(oRef)related: Aggregation(Aggregation(oRef))(nested level depth depends on context)

inspect C/I f(ACL) N/A for Classes: parentRef: oRef childRefs: Aggregation(oRef) attributes: Aggregation(ICSymbol)for Instances: parentRef: oRef attributes: InfoContainer (each attribute: name:value pair)

retrieve I f(ACL) N/A attributes : InfoContainer (each attribute: name:value pair)

setAttribute I f(ACL) attName: StringattContent: value

N/A

Function specification for the PROMISE API, v.1.0.4 (continued - sheet 2 / 4)


testAttribute TC_IfcRoot I f(ACL) attName: String isSet: Boolean

unsetAttribute I f(ACL) attName: String N/A

getRelatedObject TC_IfcRelationship1to1 I f(ACL) N/A modelRef: oRefobjRef: oRef

getRelatingObject I f(ACL) N/A modelRef: oRefobjRef: oRef

getRelatedObjects TC_IfcRelationship1toN I f(ACL) N/A modelRef: oRefobjRefs: Aggregation(oRef)

getRelatingObject I f(ACL) N/A modelRef: oRefobjRef: oRef

addToGroup TC_IfcRelGroups I f(ACL) objRefs: Aggregation(oRef) N/A

removeFromGroup I f(ACL) objRefs: Aggregation(oRef) N/A

getRelations TC_IfcObject I f(ACL) N/A relating: Aggregation(oRef)related: Aggregation(Aggregation(oRef))

merge ** TC_IfcProject C admin baseModel: oReftargetModelRefs: Aggregation(oRef)

modelRef: oRef

view TC_IfcProduct I f(ACL) viewType: DXF | VRML | TEXT | HTML resultBLOB: BLOB

setAccessRights TC_AccessGroup I owner forRole: ICSymbol (s. TC_RoleTypeEnum)OPT forUser : oRefaccessRights: Aggregation(ICSymbol) (s. TC_AccessRightsEnum)

N/A

unsetAccessRights I owner forRole: ICSymbol (s. TC_RoleTypeEnum)OPT forUser: oRef

N/A



checkIn * TC_MODEL I f(ACL) spf: BLOBOPT retBrief: boolean(when retBrief is false no output parametersare returned, otherwise all the output para-meters given in next column are returned)

OPT objNums: Aggregation(int)OPT objRefs: Aggregation(oRef)OPT objStatus: String(objStatus can be one of “Same”, “New”,“Changed”, “NewOrChanged”)

checkOut * I f(ACL) OPT retrieve: boolean spf : BLOB

checkConsistency ** I f(ACL) targetModelRefs: Aggregation(oRef) OPT failedFor: Aggregation(oRef)

closeTransaction * I f(ACL) N/A N/A

commit * I f(ACL) N/A N/A

create * C f(ACL) spf: BLOBmodelName: StringOPT refModel: oRefOPT retBrief: boolean; (see checkIn)

modelRef: oRefOPT objNums: Aggregation(int)OPT objRefs: Aggregation(oRef)OPT objStatus: String; (see checkIn)

delete * I admin N/A N/A

find * C/I f(ACL) searchExpr: String resultSet: Aggregation(value)(type of ‘value’ depends on query)

getAllModels * C f(ACL) N/A modelRefs: Aggregation(oRef)modelSchemas: Aggregation(oRef)

getDocAssignments I f(ACL) N/A modelRef: oRefobjRefs: Aggregation(oRef)

getGroups I f(ACL) N/A modelRef: oRefobjRefs: Aggregation(oRef)

getObjects * I f(ACL) N/A modelRef: oRefobjRefs: Aggregation(oRef)

getProductObjects I f(ACL) N/A modelRef: oRefobjRefs: Aggregation(oRef)



getViews I f(ACL) N/A modelRef: oRefobjRefs: Aggregation(oRef)

map * TC_MODEL I f(ACL) OPT mappingRef: oRef modelRef: oRef

mapTry * I f(ACL) OPT mappingRef: oRef N/A

match * I f(ACL) refModel: oRef changedObjects: Aggregation(oRef)

merge ** I admin targetModelRefs: Aggregation(oRef) modelRef: oRef

openTransaction * I f(ACL) N/A N/A

retrieve * I f(ACL) N/A spf: BLOB

rollback * I f(ACL) N/A N/A

setAccessRights * I owner forRole: ICSymbolOPT forUser: oRefaccessRights: Aggregation(ICSymbol)

N/A

unsetAccessRights * I owner forRole: ICSymbolOPT forUser: oRef

N/A

view I f(ACL) viewType: DXF | VRML | TEXT | HTML resultBLOB: BLOB

getMappingSchemas TC_ModelSchema I f(ACL) N/A mappingSchemas: Aggregation(oRef)

getModels I f(ACL) N/A modelRefs: Aggregation(oRef)

retrieve I owner N/A resultBLOB: BLOB

retrieve TC_MappingSchema I owner N/A resultBLOB: BLOB


Overview of the TC_PRODUCT_MODEL Schema

TC_PRODUCT_MODEL is the extended, ToCEE specific version for CEE of the IFC project model(release 1.5 final). This schema is the basis of the ToCEE modelling environment. It is the referenceschema for all aspect models used in applications. Besides this, the ToCEE environment implements alsoapplication specific models for structural and foundation analysis which are not of general interest.

The following 7 pages present snapshots of TC_PRODUCT_MODEL taken from the PDM server. As themodel is quite big it does not fit into one screen. The first three diagrams present consecutively scrolleddown snapshots of the subclasses of TC_IfcRoot, the other four diagrams represent the resourceobjects included in the model. Defined types are shown as instances of the meta model entity TYPE.

Note:

In the ToCEE implementation environment not all entities specified in TC_PRODUCT_MODEL are used.However, they are not pruned from the schema as they are fully supported by the product datamanagement server PROMISE and the product model browser ProMoTe, although not sufficiently testedfor lack of practical application in the scope of the prototype environment.

Fig. A.III-1: Screenshots of the inheritance graph of schema TC_PRODUCT_MODEL

Screenshots of the inheritance graph of schema TC_PRODUCT_MODEL (continued - sheet 2 / 7)