Product Data Server for Concurrent Engineering in ... - Semantic Scholar

Proc. 2nd European Conf. on Product and Process Modelling in the Building Industry, Amor R., Scherer R.J. (ed.), Building Research Establishment, Watford, Great Britain, 1998, pp. 277-289.

Product Data Server for Concurrent Engineering in A/E/C Peter Katranuschkov and Juha Hyvärinen Senior Research Assistant, Institute of Applied Informatics in Civil Eng., Dresden Univ. of Tech., Germany Senior Research Scientist, VTT Building Technology, Espoo, Finland

ABSTRACT: Product data technology (PDT) plays an important role in the development of concurrent engineering IT environments for A/E/C. This paper presents an overview of the developed product data management information server (PROMISE) in the EU ESPRIT project ToCEE, focusing on the basic requirements and concepts for PDT from the point of view of concurrent engineering, the conceptual features of the server, the interoperability issues in a multi-server/client environment and the specific product data services for concurrent engineering support. It reflects the experiences from the first running prototype implementation of PROMISE. 1.

INTRODUCTION

1.1 Concurrent Engineering from the Point of View of Building Construction Practice The main factors for competitiveness in building construction are quality, cost and time. In traditional construction the main goal has been minimising the costs in each phase of a basically sequential design and construction process. The intuitive method for reducing project time known as fast tracking, aiming, in essence, at the overlapping of design and construction activities, has in many cases helped to achieve shorter project duration as well as decreased costs. However, quite often it has also caused unexpected cost overruns and considerable time delays due to a low level of design completion prior to the start of construction. Concurrent engineering (CE) is, in contrast, a theoretically well founded production methodology aiming to reduce the duration of a project, to increase the value of the building product and at the same time to lower its cost. In CE all these, partially contradictory objectives, are pursued simultaneously and systematically. As understood today, CE implies collaborative, parallel product and process design, advanced project management, consideration of the whole product life cycle, effective communication

and information sharing across disciplines and phases of the product’s development and adequate consideration of responsibilities. Thus, CE means much more 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 are not yet fully understood. Hence, today’s software tools still provide only little support for a CE based way of work.

1.2 Building IT for Concurrent Engineering Different IT tools can be used for CE in a variety of forms - almost any piece of software or data format can be helpful for a certain specific need if appropriately configured and used. However, even dedicated decision making, simulation or controlling tools rarely reach the expected efficiency when used in isolation. The different information needs in construction projects, such as the management of the process, product, documentation and communication flows, are still handled in a fragmented manner as individual, or at best only partially interrelated systems. Because of this, many valuable features of existing tools and techniques still remain insufficiently exploited in practice.

2. THE TOCEE FRAMEWORK FOR CONCURIn building IT research, on the other hand, there RENT ENGINEERING have been considerable efforts invested in the conceptual specification and the development of To help tackle the above issues the EU project integration models and services. In the late 1980s a ToCEE was inaugurated in January 1996 (ESPRIT number of researchers (e.g. Eastman 1988; Gielingh IV-20587: Towards a Concurrent Engineering Envi1988; Turner 1988) have introduced product data ronment in the Building and Engineering Structures technology (PDT) in construction and have Industry). The main goal of the ToCEE project is the suggested it as a key approach for information development of a conceptual framework and a exchange and sharing in A/E/C projects. prototype environment for support of concurrent PDT based integration is now maturing into a set engineering to be used in the A/E/C domain. To of international standards known as STEP (ISO achieve this goal ToCEE builds upon the results 10303-1). Several European projects like ATLAS from the previous EU funded projects, but extends (Boehms & Storer 1994), CIMsteel (Watson & the scope considerably to include many important Crowley 1995), COMBI (Scherer & Sparacello concurrency enabling aspects with their mutual 1996), COMBINE (Augenbroe 1995) etc. have interrelationships. The focus of the project is developed prototype product modelling enviespecially on the holistic approach to design, on the ronments proving the validity of the approach and management of the information flows in the stimulating further research, standardisation and multidisciplinary collaborative work processes, and implementation activities. In the IRMA model on the legal aspects of electronic communication and (Luiten et al. 1993) a first attempt has been made to information sharing. join product and process models for building Product data technology plays an important role construction in a unified modelling framework on in ToCEE as an enabling technology for the whole the basis of PDT. Today, with the IFC project model modelling framework of the environment as well as developed within the industrial IAI initiative in the particular implementation of the ToCEE (Herold 1997) product data technology stands on the specific product data services for concurrent engithreshold of its practical implementation in inteneering support. grated building construction environments. In the following sections of this paper we present However, what is still missing is the treatment of the developed Product Data Management Informaall information - product as well as process tion Server in ToCEE (referred to as PROMISE), information, documents, users, software, hardware first focusing on the set up basic requirements and as a whole consistent system for concurrency in concepts and then going deeper into some details of which the interoperability and co-ordination issues its conceptual architecture and prototype implemenare efficiently resolved. tation. In this context, the problems related to PDT include (Turk et al. 1997): a) Unless software exists, which would implement a 3. PROMISE: THE TOCEE PRODUCT DATA product model, it is difficult to objectively evaMANAGEMENT SERVER FOR CONCURluate the usefulness and correctness of this model. RENT ENGINEERING b) For computer integrated construction product data is important, but it is not the only data set required. It may also not be the “centre of the 3.1 Requirement and Conceptual Design Issues universe“ in the sense that not all integration should happen around something as complicated and difficult to agree upon, as product models Great experience has already been gained worldappear to be. wide in product modelling for integration, for CAD c) Information exchange and sharing symbolised as or for data exchange between different CAD/CAE “data in once“ is an important, but not the only systems. requirement to be solved. In addition, concurrent However, as shown in table 1 below, concurrent engineering environments must support in a coengineering imposes several additional requirements ordinated and coherent manner parallel work, to product data management beyond integration and version handling, document management, conflict mere data exchange that must all be taken into management, information logistics etc. account. Table 1: Concurrent engineering features and their implications to product data management

Concurrent Engineering Features Collaborative work

Concurrency

Efficient inter-discipline communication and information sharing Life cycle management

Robust project management

Consideration of responsibilities and rights

Simulation, monitoring and forecasting

Product Data Management Related Issues Integrated data model Common product data repositories Distributed Client/Server environment Concurrent multi-user access to the product data repositories Availability of local data models allowing independent work in the individual engineering domains Change management and versioning Flexible Client/Server interfaces Comprehensive set of available server functions Consistent support of semantic and operational interoperability Comprehensive set of harmonised data models Modelling representation enabling model evolution and different levels of representation detail Capturing of key project management data in appropriate modelling object Linking to process and workflow management data Capturing of legal issues like contracts, order assignments, approvals, access rights etc. Appropriate linking to documents, the main holders of legally binding data Adequate interfaces and mapping facilities to the respective advanced software tools

In accordance with these requirements, the conceptual design of the ToCEE product data server PROMISE has been governed by the following principles: a) Commitment to a common project ontology based on an extended specification of the IFC project model, version 1.5 (IAI 1997). b) Layered model structure enabling partitioning of the product data repositories corresponding to engineering domain views and project phases and allowing both local (inconsistent) and global (consistent) changes to the product data done by individual users and client applications. c) Explicit modelling of systemic and project management information including relevant legal data. d) Explicit modelling of a comprehensive set of operations for all supported product data services. e) Knowledge-based representation of the data models enabling the necessary operational, semantic and functional interoperability of the server within the concurrent engineering environment. 3.2 Ontological Commitment

As a whole, the operational framework of the ToCEE environment is based on a multi-tier clientserver approach. It is comprised of a set of autonomously developed dedicated servers (for product, process, document, conflict, regulations management), a centralised information logistics system (including a common request broker for the whole environment) and a set of advanced client applications for selected specific design and construction tasks. In order to achieve the interoperability and the co-ordinated use of all components of the environment, it is essential that all they commit to a common project ontology which includes: − the use of a common modelling paradigm, − the use of a common meta model, − a set of explicitly defined, shareable, high-level modelling concepts. Figure 1 below shows the overall architecture of the operational framework. As it can be seen, the underlying modelling framework is in fact distributed among several component systems, glued together by the use of a common meta model.

Fig. 1: The operational framework of ToCEE Client Appl. Layer

Adapter Layer

GUI

Internet adapter (WWW, Email)

CAD

EXPRESS adapter (SPF, SDAI)

FEA ...

Appl. adapter (IL toolkit, ORB interface)

Central Infologistics Server

Server Plug-In Layer

Common Request Broker

Common Meta Model

3.3 Modelling Approach The modelling paradigm used to define the framework conforms to the STEP approach including data modelling using the EXPRESS language (ISO 10303-11), but with important extensions for the explicit definition of object identification and for the definition of operations to the modelling objects as introduced in EXPRESS-C (ISO/TC184/WG5/N202). The meta model captures the information about information, exposing explicitly and unambiguously the basic rules of the whole modelling paradigm, including the generic specification of concepts, operations and object identification. The entity definitions comprising the actual modelling framework of the environment are, as mentioned above, largely based on the IFC project model specification. However, the IFC schema is not implemented “in one place“, but as a distributed model with clearly defined interfaces. Not unexpectedly, the by far biggest portion of these entity definitions is allocated to and used by the product data management server, organised in hierarchically structured schemata as described in detail in (Hyvärinen et al. 1997; Hyvärinen & Katranuschkov 1997). To enable interoperability with other components of the environment like process, document, conflict management etc., the entity definitions used by the product data management server are subdivided in the following functional categories: a) Addressable public objects These are object definitions that are registered on the common request broker of the system and have explicitly published functional specifications that

Product Mgmt Server

Product Models

Process Mgmt Server

Process Model

Document Mgmt Server

Document Model

...

...

Common Modelling Framework

can be used to access their instances through remote procedure calls from a client or any other server. Such objects express the ontological commitment of the server to the overall concurrent engineering environment. However, not all details of the public objects need to be made explicit, but only their commonly available public interfaces. b) Accessible objects: These objects cannot be accessed directly through remote procedure calls. They possess methods that serve other objects, but are not explicitly identifiable. Their implementation is thus hidden from the other system components. Typically such objects are most of the integrated resources from STEP used in the IFC project model. c) Shared objects: These are a set of addressable public objects that need special consideration. Such objects define methods for more than one service. Depending on the specific use, their instances may be represented once and accessed remotely from the other components, or replicated in all relevant servers, with exactly one server bearing the responsibility for their appropriate updating. Shared objects are of vital importance for the server-to-server interoperability, whereas for a client there should be no visible difference between a “pure“ public product object, like e.g. IfcBuildingElement and shared objects like DocumentAssignment. This additional functional categorisation allows to: − keep the harmonisation effort manageable, − relieve the ontological commitment of applications to only those data of particular interest for the information exchange and sharing,

− develop the details of the product data services to a high extent independent from the development of the other components of the environment, hiding as much as possible representational and implementation aspects. Another important aspect to be considered in the product data management for concurrent engineering is the modelling not only of the information about the constructed facilities (product data), but also of the information about the concurrent engineering

system itself (system data), and the information needed for capturing project management aspects (project control data). This requires the explicit representation of several additional concepts that are missing or are only modelled as not directly identifiable entities in IFC. The below table 2 shows examples of several such concepts implemented within PROMISE.

Table 2: Capturing of systemic and management information in the ToCEE product data server (PROMISE) Concept Model

Purpose Allows each specific model to know about itself (its underlying schema, contained entity instances etc.), as well as to define model-level management operations like e.g. CheckIn, CheckOut, RetrieveModel etc. Session Similar to database systems, this concept serves for transaction management purpose, maintaining the state of a client-server interaction, allowing rollbacks etc. Information Process Used to maintain the status of each requested transaction. Note that state maintenance is especially important when an operation takes a long time to execute, or when ist execution is requested in asynchronous mode. Application Allows the unique identification of all software components in the environment, as well as to configure individual access rights for each API if necessary. Actor Used to captures the default assignment of access rights and responsibilities for the product data in different discipline-specific views. User Allows the explicit identification of all users in the system with their respective actor roles as well as to assign them specific access rights and responsibilities, broadening or narrowing the default actor rights as needed. Approval Allows robust treatment of responsibilities and facilitates change and conflict management by enabling the tracking of legal issues Contract Captures the contractual relationships within a project and thus allows to control the delegation of access rights and responsibilities to the users. Order Assignment Enables the delegation of access rights and responsibilities, if allowed by the respective contractual relationships. View Grouping mechanism serving as the main gateway to document and conflict management and facilitating the run-time model transformations to dedicated application-specific models. 3.4 Operations In consistence with the object-oriented modelling approach operations are defined for all objects that need to be accessed from the outside, i.e. by a client application or by another data management server of the environment. Through the specification of operations a structured access to the full server functionality is provided, at the same time hiding the particular object representation details. The formal description of the available server operations is done on the basis of the EXPRESS-C notation. This approach provides:

− high-level conceptual representation of the functional definitions which is not programming language specific − conformance with the underlying EXPRESS data models of the framework − capabilities for formal parsing and validation of the models including the operation specifications − sound basis for language bindings, e.g. for CORBA IDL, Java RMI etc. EXPRESS-C allows also inheritance, polymorphism and definition of pre- and post-conditions for the execution of the operations. Operations serve as a basis for accessing all product data services. The operations defined for objects in the product data server have the primary

goal to provide specific high-level product data management functionality, as opposed e.g. to CAD functionality which can be specified in the same way and for the same objects, but in a different system component. For instance, there is no move() operation defined for IfcWall entity, but instead there exists a set of operations allowing to create walls, modify their properties, group them with other objects, approve changes made by some other user etc. (in fact a wall can even be „moved“ by using setAttribute() to change its location). The concrete operations specified for PROMISE take into account: − the definitions of the modelling objects in the framework, − the functional object types as discussed in section 3.3 above, and − the necessary product data management services, including the specific features for concurrent engineering support. 3.5 Product Data Services The provided product data services in PROMISE can be grouped in 6 categories: (1) general database-like services based on SDAI (ISO 10303-22), (2) specific model management services, (3) specific services for views and filtering, (4) change management, (5) access control and (6) services for interoperability. Before execution of most of these services, the user's access rights are validated on the basis of the access rights and order assignments stored in the server data repository. Except for the first category, all other groups of product data services contribute to the support of different concurrent engineering aspects. Their detailed specification is given in (Hyvärinen et al. 1997). Here we focus only on the services for interoperability, which is one of the most important, yet very controversial and difficult to solve issue. 3.6 Interoperability Aspects The importance and complexity of the problem of interoperability in engineering data management has been recognised in many recent research studies and a number of methods for its solution have been proposed (EXPRESS-X, ACL/KIF etc). A survey of such methods is given in (Liebich et al. 1995). Why is interoperability a problem? One reason is the current lack of a complete set of harmonised and standardised product models for building const-

ruction. Another, yet deeper reason comes from the nature of collaborative work itself. Provided that a comprehensive set of conceptual product models exists, the huge amount of product data that have to be dealt with in a project could be most efficiently stored in STEP/SDAI-based repositories. This would in turn allow the use of standardised methods for information sharing by the applications using these data. Because of the multiple functional aspects to be considered, these product data repositories have to be meaningfully semantically partitioned, to allow coexistence of different independent representations of the modelling objects which can appropriately encapsulate the engineering knowledge relevant to different domain views, e.g. ‘wall’ in architectural design vs. ‘wall’ in structural design. In addition, for the purpose of collaborative work, the actual product data might need to be distributed and it should be possible to access and modify them in parallel, by different project actors. Thus, interoperability problems arise also because of this partitioning of the product data base, which can lead to inconsistent data states that must be adequately captured. Interoperability involves the consistent treatment of operational, semantic and functional aspects (Katranuschkov & Scherer 1997). Operational interoperability enables the communication, co-ordination and co-operation between the distributed components of the environment. This type of interoperability is automatically provided by the inherent features of the ToCEE framework (common modelling approach, ontology and interface specification, as well as centralised request broker services). Semantic interoperability means the ability of the underlying conceptual models to exchange and share common concepts. In ToCEE this is achieved through the layered modelling framework based on the IFC project model. Functional interoperability means the ability to support at run-time the model and data transformations needed in the information exchange and sharing between the components of the integrated environment. Such transformations are necessary when changes in one local aspect (source model) must be propagated and checked against the constraints of another local domain aspect (target model), e.g. architectural spatial model → structural model. In ToCEE environment this is achieved with the help of three developed knowledge-based methods - model mapping, consistency checking and

object matching, invoked automatically through Fig. 2 below shows the basic interrelationships appropriate product data operations. between these three methods. Fig. 2: Principal schema of the functional model and data transformations

Source model definition instantiation

Source model instantiation analysis of the source classes/instances/ relations and the source/target interschema equivalences

class level transformations

Mapping data level transformations

Target model definition instantiation

New target model instantiation

version comparison and dynamic identification of the new/modified objects

Matching

Exist. version of the target model data contents

Model mapping is the conversion of one modelling representation into another without awareness of the context, i.e. already existing data in the target model. It involves the specification of all necessary translations on class level, and full or partial transformation of the data instances according to these specifications. When applied on data level, a mapping operation will create a new target model context by parsing the mapping specifications, analysing the relations among the source model data, expanding the data in target model and reducing duplicate or redundant objects in accordance with the relationships defined in the target schema. Consistency checking aims at proving the validity of a new model version on the basis of ‘after-add’ rules applied to the new target model context. Such rules would normally not be included in the model specification itself, and can address issues like compliance to regulations, user requirements etc. Hence, the consistency checking operations are based on both the object-oriented definition of the target model classes and a complementary rule-based extension of the model, represented in a separate specification schema. The purpose of object matching is to update the context of the target model by taking into account both the changes introduced through mapping the source model onto the target and the already existing data in the target. It is concerned basically with the context-dependent comparison of the new and existing version of the target model. Similar to consistency checking, it makes use of rule-based reasoning, encompassing the dynamic identification of the changed objects, change propagation and, if necessary, restructuring of the target model context.

new instantiation (after mapping, reasoning & object matching compliance to regulations, consistence with userdefined constraints etc.

Consistency checking

4.

New version of the target model data contents

propagation of the changes, re-classification and merging into new version

PROTOTYPE IMPLEMENTATION

The prototype implementation of PROMISE is done in KEE/Lisp and Java and is currently running on a UNIX workstation. The server can be used locally in stand-alone mode (for administration/maintenance), or remotely in server mode, supporting TCP/IP, Java RMI and CORBA-based connectivity (the latter still in work).

4.1 Model Representation To enable coherent use of both the object-oriented approach based on the EXPRESS-C model specification and a set of advanced knowledge-based methods applied in product data services, the software representation of the product data models is done according to the frame-based modelling paradigm. This approach provides the following benefits: − capability to accommodate both descriptive and prescriptive computational features, − separation of data structures from the high-level rule-based data management knowledge, − encapsulation of knowledge-based methods within the procedural attachment of operations to the modelling objects, allowing the use of uniformly defined function calls from the outside, − full consistence with the conceptual objectoriented modelling approach, − flexibility for future modifications.

Consequently, the architecture of PROMISE very much resembles that of a typical knowledge-based

system as depicted in figure 3 below.

Fig. 3: The knowledge-based architecture of the ToCEE product data server (PROMISE) Input: operation parameters with embedded query/assert expressions User & Appl. Interface: OO-oper. / EXPRESS-C

Knowledge Acquisition Component

Explanation Component (N/A)

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

Reasoning Component (AI-Methods)

uses

Working Memory

uses Knowledge Base: Frame-based representation of the Meta and Product Model Schemata and the modelling object instances

The dashed-line components shown in figure 3 are only given for comparison, not actually implemented. The specific characteristics of the other components emphasise the resemblance, but also the difference to a classical knowledge-based system. An important feature of the architecture is also that input is always provided through one and the same gateway, in the form of uniformly used from client point of view remote procedure calls. 4.2 Application and User Interfaces The practical API implementation giving access to the provided product data services is based on TCP/IP, thus enabling fully distributed Internet operability. Client applications can use the server either directly (in which case the access rights to the data are automatically set as for „anonymous users“), or through server interoperability (SIOP) requests, using as a gateway the common request broker of the information logistics system (in which case the particular user role and access rights are always unambiguously resolved). For project management and system administration purposes a GUI is also provided which allows a super-user access to all available product data operations. Fig. 4 below gives an overview of the server interfaces and fig. 5 shows an example of a dedicated client, as implemented in the ToCEE environment. 4.3 Support to Client Software Implementation The interface between client and server applications is commonly thought to be at the level of network

connection. In the case of PROMISE this interface can be transferred inside the client application, which means that methods for accessing the model through the Internet are provided to client application developers and users as classes or programs, not as descriptions or specifications. This is easily achieved by distributing schema dependent ready-to-use class files as early-binding toolkits, but only if the applied schema is considered final. As the schemata are expected to evolve, higher flexibility may be desired and therefore the application should be able to „understand“ also the schema and generate the required class files. This would make the client application unnecessarily „heavy“ for most cases. The ToCEE solution to assist implementation has been to develop a separate intermediate application (referred to as PROMOTE) capable of generating the classes for any given schema. Using Java, the requirement of platform independence has been easily met and network features, like Remote Method Invocation are readily available. Client software developers can thus implement the connection to the server basically in 3 different ways: (1) Take the schema and do all the programming required to connect to the server and handle the data retrieved from model, (2) Use provided classes (toolkit) in their application, (3) Embed PROMOTE in their application to generate the class files. All these are likely to be used. Approaches (1) and (2) can be used when schemata are known and static. When final schemata are not available a priori, approach (3) would be more appropriate.

Fig. 4: General schema of the product data server interfaces Dedicated SIOP Requests from other servers or identified users of the system using Java RMI

public interface

Information Logistics Server

Product Data Server

operation operation operation operation operation

Client Application

Direct anonymous client quieries (only for investigation the product data) using TCP/IP, Java RMI or Corba

GUI of the product data server, showing the main and pop-up menus (top), a log window (bottom left), and a graphical representation of a data model (right)

Fig. 5: Example client embedded in a structural analysis application

As an alternative approach, PROMOTE can be used as an intermediate application between the server and client applications for data conversion among different versions of schemata. Providing a tool that can generate classes automatically from any schema, the amount of work related to schema updates is reduced dramatically. If there is no immediate reason to update the client interface, mapping from data conforming to one schema version to another can be provided. In simple cases, e.g. when a schema is updated, this mapping can be specified graphically and performed by PROMOTE. After downloading and mapping, a client application can read the produced STEP-file (ISO 10303-21), as if the original data were still com-

patible with the old schema. This solution gives software developers more flexibility when designing their products and eliminates the need of constant updating of schema dependent classes without losing the compatibility. This kind of mapping is going to be required for some time, because PDT is still quite a new and evolving technology. Providing a multi interfaced application capable of transferring data between different schemata, the life cycle of a software product can be extended and the whole PDT made more attractive to software developers. PROMOTE can also be used as a simple viewer and editor of actual data. For many users this might be sufficient to visualise product data (as Virtual Reality Model) or for changing values of attributes.

5.

CONCLUSION

Product data management for concurrent engineering requires a more sophisticated methodology than STEP or database technology currently provide. The lessons learned from the first prototype realisation of the product data management server for concurrent engineering in the ToCEE project have shown that in order to meet such requirements knowledge-based representation methods, as well as appropriate modelling extensions and interface specifications are needed in addition to the widely acknowledged object orientation in PDT. With the implementation of the IFC project model – not for CAD, but for project management and collaborative work, measurable steps towards establishing concurrent engineering IT environments for the A/E/C practice are expected to be achieved.

6. ACKNOWLEDGEMENTS The research related to this paper has been carried out with the help of the financial support of the European Union and the industrial partners in the ToCEE project. Their contribution to this work is gratefully acknowledged.

REFERENCES Augenbroe G. (ed) 1995. COMBINE 2 Final Report, EU/CEC Joule Programme, Project JOU2-CT920196, TU Delft, Netherlands. Böhms M. & Storer G. 1994. ATLAS - Architecture, methodology and Tools for computer-integrated Large Scale engineering, Proc. JSPE-IFIP WG 5.3 Workshop, DIISM'93, Tokyo, Japan. 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. (http://wwwcib.bau.tu-dresden.de/tocee) Gielingh W. 1988. General AEC Reference Model, TNO Report, B1-88-150, Delft, Netherlands. Herold K. 1997. Universal Building language, Journal of Computing in Civil Engineering, 2(1). Hyvärinen J., Katranuschkov P. & Scherer R.J. 1997. ToCEE Deliverable F2-1 - Concepts for the Product Modelling and Interoperability Management Tools, Technical Report, EU/CEC ESPRIT Project 20587, Brussels, Belgium.

Hyvärinen J. & Katranuschkov P. 1997. Product Data Management Methods in a Concurrent Engineering Environment for AEC, Proc. EG-SEA-AI-97, Lahti, Finland. IAI 1997. IFC Object Model for AEC Projects, IFC Release 1.5 Model Reference Documentation, Final Version, IAI Publ. Washington, DC. ISO 10303-1, -11, -21 IS 1994. Product Data Representation and Exchange - Parts 1, 11, 21, ISO TC 184/SC4, Geneva, Switzerland. ISO 10303-22 DIS 1996. Product Data Representation and Exchange - Part 22: Implementation Methods: Standard Data Access Interface Specification, ISO TC 184/SC4, Geneva, Switzerland. ISO/TC184/SC4/WG5/N202 1994. PISA Information Modelling Language (EXPRESS-C). Katranuschkov P. & Scherer R.J. 1997. Framework for Interoperability of Building Product Models in Collaborative Work Environments, in Choi C.-K., Yun C.-B. and Kwak H.-G. (eds) Proc of the 7th Int. Conf. on Computing in Civil and Building Engineering, August’97, Seoul, Korea, pp. 627-632. Liebich T., Amor R. & Verhoef M. 1995. A Survey of Mapping Methods Available Within the Product Modelling Arena, Proc. of the 5th Int. Conf. of the EXPRESS User Group, Grenoble, France. Luiten G., Froese T., Björk B-C., Cooper G., Junge R., Karstila K. & Oxman R. 1993. An information reference model for architecture, engineering and construction, in Mathur K.S., Betts M.P., Tham K.W. (eds) „Management of information technology for construction“, World Scientific Publishing, Singapore. Scherer R.J. & Sparacello H.-M. (eds) 1996. COMBI Final Report, EU/CEC ESPRIT III Project No. 6609, TU Dresden, Germany. Scherer R.J. 1998. A Framework for the Concurrent Engineering Environment, in Amor R., Scherer R.J. (eds) Proc. of the 2nd European Conf. on Product and Process Modelling in the Building Industry, Building Research Establishment, Watford, UK. Turk Z., Wasserfuhr R., Katranuschkov P., Scherer R.J., Amor R. & Hannus M. 1997. Conceptual Modelling of a Concurrent Engineering Environment, in: C. J. Anumba and N.F.O. Evbuomwan (eds) „Concurrent Engineering in Construction“, Institution of Structural Engineers, ISBN 1-874266-35-2, London, UK. Turner J. 1988. A systems approach to the conceptual modelling of buildings, in P.Christiansson, H. Karlsson (eds) "Conceptual Modelling of Buildings", CIB Publ. 126, Swedish Building Center, Solna, Sweden. Watson A. & Crowley A. 1995. CIMsteel Integration Standards, in R.J.Scherer (ed) "Product and Process Modelling in the Building Industry", Proc. of the 1st European Conf. on Product and Process Modelling in the Building Industry, Dresden, Germany, Balkema, pp 491-494.