CONSTRUCTION DESIGN DOCUMENT MANAGEMENT SCHEMA AND PROTOTYPE

CONSTRUCTION DESIGN DOCUMENT MANAGEMENT SCHEMA AND PROTOTYPE Ziga Turk Asst.Prof., Faculty of Civil Engineering and Geodesy, University of Ljubljana, Slovenia. CDDM Schema and Prototype dr. Ziga Turk FGG Jamova 2 Ljubljana Slovenia. fax: +386-61-268-572 email: ziga.turk@fagg.uni-lj.si

CONSTRUCTION DESIGN DOCUMENT MANAGEMENT SCHEMA AND PROTOTYPE ABSTRACT: Product and process models are often regarded as a panacea to most problems of computer integrated construction (CIC). But the paradigm shift they are about to achieve is not imminent. Software supporting CIC relies on the definition of the conceptual building product and building process models which are, at least in a standardised form, delivered quite slowly. Alternatively, working solutions to CIC may also be achieved by reducing the level of detail at which the information are modelled. This paper suggests a document to be used as a larger data chunk instead of records, attributes and primitive objects. Resulting construction document management (CDM) systems are a shorter term solution for CIC; the documents are not as numerous as objects or attributes and they hide complexity of the information they carry. During the life cycle of a building the information creation, demand and use are greatest in the pre-construction phases, particularly the design phase. The paper presents a prototype of a construction design documentation management system (CDDMS), particularly the conceptual model behind it (the "CDDMS" model) and the extensions it needs to span into other dimensions of the product model definition space. It has been found out that the existing database and networking technology is sufficient to create efficient collaborative engineering environments. The presented schema is compatible with the proposed "HCDMS" model for hybrid environments where some documents are results of queries into a product model database and some are the original containers of information. KEYWORDS: document management, design process modelling, integrated CAD, groupware, collaborative design

1. INTRODUCTION This section introduces the role of CDDM systems in the CIC effort and the motives for the presented research. 1.1 On collaborated and integrated CAD The complexity of civil engineering products like buildings, bridges, roads, factories etc. requires the employment of the most typical tool for fighting complexity - decomposition. On one hand, the product itself is decomposed into components or assemblies which are designed separately; on the other, the design process of a complex component is broken into many discrete design steps. Each is then accomplished separately in a design sub-process. When the complexity of the design increases, the number of sub-designs or sub-processes grows. Since they are not independent, the communication between the sub-processes, the re-composition of the components and the management of the whole building process are very important. To be feasible, the re-composition must include only compatible components. The current approach to ensure that is to standardise the information and data formats which are passed into various subprocesses. Product models which should model and capture all information needed during the life time of a civil engineering product are being designed and standardised. A growing number of design-sub-processes already is supported by computer programs. Their result are the information that are stored digitally. Although most of these programs per se do not support collaborative work, they still enable the use of information technology (IT) for the communication between the participants in the building process, the integration of the building sub-process information into a building product database and the management of the building process as a whole. 1.2 Product, process and documentation models IT can be applied to different scales of decomposition of the designed product. The difference is in the size of the unit of information that is handled by software which supports integrated or collaborated CAD. On the small scale, a unit may be as small as one single attribute (like the thickness of a wall).

On a larger scale, the unit may be a document or a set of documents that are a result of a design subprocess (like the dimensions of all concrete elements in a building). As depicted in Fig 1., integrated CAD can be decomposed to five distinct modelling spaces. The static product model contains the facts about the product. The Process and dynamic product models contain information about the design process that lead to such a product (who, when, how, explored alternatives) and the design rationale (why). The client-server relations reveal the principal means of the interaction between them. Fig 2 shows how are these relations manifested on a small fraction of a product model. It also demonstrates one of the main obstacles in attaching the process related information. It seems impractical to attach process related information - like the one suggested in IRMA (Luiten et al 1993) model - to just about every attribute in the product model. To find larger units for the attachment of process related information is one of the most exciting tasks of the present CIC research. It may take quite some time before the product and process models are defined and combined into a unified model. In the meantime, we propose a document as a unit onto which the process related information should be attached. We propose a document management system as a replacement for a full product model management system. 1.3 The paradigm shift The diagram in Fig 3 shows the growth of impact that the use of IT has on the AEC (architecture, engineering, construction) industries. The "islands of automation" paradigm will be, in the future, replaced by integrated software using product data exchange based on a standardised product model. This model, however, needs time to mature. During that time the "state-of-the-art" curve flattens what is also reflected in the state-of-practice (curve A), obviously below the state-of-the-art. By introducing document data exchange sometime during that period (dotted area), a smoother transition into a hybrid data exchange paradigm is possible (state of practice curve B).

Because the document is as old as the skill of writing, we expect that there will always be some document based information and that hybrid (not pure product model) data exchange is what we can expect in the future. 1.4 Related work The importance of document management for engineering disciplines is well recognised. Commercial efforts did provide some answers to the immediate needs. Numerous electronic or engineering document management (EDM) systems have been appearing on the market (Billing 1993, Reinhardt 1994). They are either general business applications or associated to a single drafting package managing the created drawings. Perhaps the largest single customer for CDM systems is the US Department of Defence (UoD), which reportedly maintains some 60 million pages of technical manuals and documentation. Since 1985 the UoD has established a program called CALS (Computer Aided Logistics Support) to this problem (Henderson, 1991) and identified four document types and related standards describing their content. For textual documents it refers to SGML - standard generalised mark-up language (ISO 8879). For the scope office automation systems the same problem is addressed in the international standard ODA - Office Document Architecture (ISO 8613). All cited solutions do not address perhaps the most important issue - the relation of the document to the design process. The need for CDM systems for architecture and engineering is well recognised. Berger (1989) and Ladino (1987) emphasise the legal aspects and legal implications of construction documents. König (1981) addresses the importance of documents in future land information systems. Long (1988) stresses the importance of managing and maintaining technical documents. 1.4.1 Envelope vs. mark-up approach The majority of the most recent work goes beyond the identification of the problem and deals with the details of document management and the underlying information structures. Debras and Rezgui (1994) use the SGML document type definitions (DTD) and a set of document templates to link documents to the product model. Mokhtar and Bedard (1994) propose that construction technical documents should

be an output of a central database and suggest using an object oriented data base. Armstrong and Lockley (1994) modelled the generic document structures present in the process of product certification and created an OODB based system which manages the referential integrity of the document sources. Basically, there seems to exist two different views of documents and CDM systems. Some of the authors are more concerned with the content of the document - with the internal structure and meaning of the document parts. Descriptive mark-up of the documents (for example using the SGML) is seen as a general solution for that. The approach pursued in this paper and also by others (Björk et al 1993, Björk 1994) is to split the managed document information into the document itself and its envelope. The first contains the original contents of the document and may, but in general does not, deal with it in greater details. The envelope contains document's meta data, which are needed to manage the document. The two approaches are reflected in the relation the CDM system has to product models. The first approach attempts to parse the existing documents and convert the information they carry into the product model databases. A product model is inherently semantically richer than a written document. It is possible to automate the creation of documents based on the product model. Going the other way - adding structure and computer parseable semantics to documents - is a tedious, manual task, at least until natural language recognition systems become available. On the other hand, marking of the documents that are not results of the design process (like building codes), is well justified. One of the most important research issues related to CDM systems is the information content of the meta data and their relation to building product and process models. Conceptual modelling techniques may be applied to this problem as well. 1.5 Functions of document management systems and motivation Documents are still the prevailing abstraction used in day to day business to represent containers of information. Until recently, computer systems have only weakly supported this in forms of files and

databases. Recent developments of system software is showing great interest in document based operating systems and applications (as opposed to file based). The functions of construction document management systems include (1) pure document management, (2) building process management through documents, (3) management of building product (which is documented in the documents) and (4) aid and integration with CAx applications providing a comfortable working environment. General EDM is expected to provide partial answers to functions 1 and 4. The rest was our first motive for this research. The second motive for separate research of CDM systems (Turk et al 1994) is the need to prepare for the smooth transition from the islands of automation state into hybrid document and product model based data exchange and answer the question how can CDM systems assist in the transition. And finally, building products and the associate documents have a scope that is much broader than can be covered by an EDM system within a company or department. We are talking about industrybranch-wide documents which are created, used and referenced for decades - by state authorities, contractors, banks, construction companies and building product users and maintainers. 2. THE PROTOTYPE 2.1 Previous work The author's earlier work related to document management included the creation of two prototype system each exploring a certain aspect of the problem and the selected technology. 2.1.1 Frame based prototype The frame based prototype was built in 1991/92 and modelled the design environment using the model-view-controller paradigm as views, controllers, processes and managers. The prototype uses expert system (ES) shell Kappa (Intellicorp) and its frame based technology to model these entities. The views are hierarchically classified according to the information they contain. There are two subtypes - the "true" views and the files. The firsts are interfaces to databases describing a product

(usually a collection of files and related manipulation tools). The controllers are abstractions of the existing programs and are not hierarchically ordered. A process is an abstraction of a part of the design process and connects a view to a controller. Managers are humans or special programs. The design process is understood as a goal satisfaction problem: the goal of a design process is to create a certain document and, at all times, ensure that it is up to date with regard to other documents on which this document is based. Expert system's chaining mechanism and goal oriented reasoning is used to do that. If a document became obsolete, an expert system would start a process, that is, run a controller on a particular document, so that it would be up to date again. The environment has attributes of a blackboard system, where various controllers assert changes of the information they control to the goal stack so that other controllers can respond to it. The reasoning mechanism has the function of the process dispatcher. A typical form showing information about a process is depicted in Fig 4 (left). The prototype tackled some interesting issues to design process management like the automatic supervision of the design process and explored the usefulness of ES shells for CDDM systems. It was well suited for the management of information that resulted from non-interactive computer programs. It was less efficient on problems and software where human interaction was required - and such is the majority of design related software. 2.2 Hypermedia based prototype Hypermedia based prototype takes the opposite approach and attempts to support the design process by creating a user friendly environment where the human designer could be making the decisions while the software would be keeping track of the data. It has no ambition to control the design process in any way, but to provide easy access to information needed for that. It was built upon a hypercard like product Toolbook (Asymetrix) and uses cards as an abstraction for a collection of construction information. A card represents a file or a set of files. Since Toolbook and other cardware software enable typing of page backgrounds, these are typed according to the tools that may be used to manage the information they contain. The backgrounds are hierarchically ordered.

The information model behind this prototype is simpler than the one used in the frame based prototype. The user is not manipulating the processes but the documents. Each document has an associated meta-information which is manipulated through a form such as the one shown in Fig 4- right. It has a type and associated methods, version control information, part-of and has parts associations and a free form history list. The form's methods may be run directly from the form and would manipulate the contents of the document. 2.3 Goals Based on the experience from two earlier prototypes, the primary role of IT was decided to be that of a medium - a medium which is (1) integrating the design sub-processes, the computer based design tools with the designers - and (2) connecting the designers themselves - creating the communication environment for a true collaborative design. Concrete goals for developing the process based version were to: (a) Closely bind the meta data and the document on a higher than file-system level; (b) Support collaborative design by ensuring central and transparent storage that may be accessed through local and wide area networks; (c) Support features of a quality controlled system; The solution should provide information onto which the systems for quality assurance as suggested in the ISO 9000 series of standards could be attached; (d) Provide a base for design scheduling and management using IT; and (e) Support document versioning and help assure design consistency. 2.4 The CDDMS model This section provides plain English description of the design environment which integrates product (hidden in documents) and design process models. The key entities of the CDDMS model are: a) design task or sub-task which results in a b) document which is created or supervised by a c) designer using a d) tool.

This definition shows that a CDDM system model can only be defined, if a simple design process model is available. The envelope's meta data implicitly define a more precise process model, which will become apparent from the following sections. 2.4.1 Design task A design task a is a part of a design process. It belongs to a design process; may be a part of another design task so that infinite structuring of the design process is possible; it cannot be (at present) a part of many design tasks; has progression state which may be one of: planned, started, suspended and finished; has a progression value which is a percentage showing how much of a task has been estimated to be accomplished; has planned and actual start and finish; has a supervisor, who manages this task; has free form description and comments of arbitrary length. 2.4.2 Design document A design document is a result of a design task. It has its contents and an envelope. The contents of a document may be a computer file or some not computerised media and it is entirely independent of its envelope. The envelope knows about the type of the content, but is not concerned with any of its details. Other features of a document are that it belongs to a document type; it is a result of one design task; has an author and a supervisor; has a progression status which is one of: empty (nothing done yet), draft (being worked on), proposal (author is done with it), checked (document is cleared by the supervisor). It has as a physical location where this document is stored; may be discussed or commented; has configuration information. A configuration is a set of documents that together define a design alternative. The configuration "main" means that the document is a part of the main version of the design. Any other value suggests that the document is a part of an alternative solution. The design document may have base documents; these are documents which contain information that was used to create this document; may have previous versions which are replaced by this document or to which this document is an alternative to. In the latest case, the document also has configuration information other than "main". 2.4.3 Types of documents by storage

Documents are typed according to the location of their physical storage: a) documents not stored digitally; b) documents that are physically stored in the envelope (within Windows environment documents made with applications that support OLE); c) document stored in files of the network file system; d) document stored on remote file system and need to be copied to the local file system, before their content can be examined. The documents of the type c and d are further sub-typed according to the file type. 2.4.4 File types and file tools File types and the associated tools are used to create an object oriented interface to a particular file. A file type contains information about file type name; the name of mostly one the super file type; a file type from which files of this type inherit tools; and finally, a list of tools that may be applied to instances of this file type. File tools are pieces of code (typically programs) that may be executed with files of an associated type as a parameter. A file tool contains information which is needed to run the program which includes the name of the tool; the associated type; command that runs the tool; parameters of the command; implementation details of the command. 2.4.5 People and organisations People involved in the design project are managers of tasks, supervisors and authors of documents. Information associated with them is: personal information like name, surname, date of birth, picture...; professional information (title, education); organisational information (position within the company); employment information - company they work for; mailing and electronic address. Organisations employ people. The associated information are name, address and the main contact person.

2.5 Collaboration support With respect to the project, designers communicate with each other in two ways; one to one - the communication is private; one to many - designers comment documents, configurations and tasks or other comments. 2.6 Implementation The section describes the implementation of the above schema in a relational database (RDB), the environment and the user interface. 2.6.1 Database schema The schema is depicted in Fig 5. 2.6.2 Implementation environment The prototype is running under Microsoft Windows 3.1 and the relational database system Microsoft Access. It supports any network operation system (NOS) that has the functionality of a network file system (NFS). This is a system where remote disks are logically presented to the applications as if they were local. The examples of such systems are Novell Netware, Windows for Workgroups, Lantastic and PC/NFS. These systems usually operate on a local area network (LAN) limited to a local building or buildings (Fig 6). Using the IP tunnelling, however, some of the NOS make it possible to access information on media anywhere on the wide area network (WAN) as if it were on the local hard disk, usually at a much lower speed. The implementation also provides alternative means to access information residing on machines attached to a WAN. The program builds on the hypertext transfer protocol (HTTP) and the World Wide Web (WWW). The environment uses a free client program which can display information on remote machines or make a copy of the information on the local machine (Fig 8). It is only possible to view but not change the remote information. The information accessed through the WWW is expected to be of reference nature and not a part of one project only.

Communication is supported with an interface to an external program for sending and reading electronic mail. Sending e-mail to authors and supervisors of documents is particularly easy - both the address and the subject field are filled in by the system with designer's and document's ID. One-to-many communication is supported through a simple, but effective conferencing subsystem that functions as a part of the environment. It is thread based. A thread is a set of articles that were created as direct or indirect replies to one single "root" article. In this case every task, document or configuration has the role of a "root" article and may be commented and discussed by other designers. A more formal approach to discussions and decision making like IBIS (Kunz and Rittel 1970) is being considered. 2.6.3 User interface The program is form oriented. User interface employs some of the gadgets of the Windows operating system like fields, menus, buttons, drop down menus, and scroll bars. It is point-and-click rather than drag and drop. Some sample forms are in Figs 7 and 9. 3. EVALUATION OF THE PROTOTYPE A prototype of a construction project documentation management system was developed and steps towards the modelling of a hybrid CDM systems have been made. Most goals listed in Section 2.3 were achieved. 3.1 Prototype deficiencies The program competes with some functions of advanced file systems (attaching additional information to files, handling remote files...), of operating systems shells (running programs), scheduling and group-ware programs. The present version cannot compete with any of those but it can, however, compete as a combination of the four, which is specially adapted to engineering needs. OLE servers solve, in part, the main technical problem of such environments - the relation between the document's envelope and the actual document. The OLE documents are stored in the actual database virtually

within their envelope. On the other hand, files may still be handled not only through the environment but directly through the operating system. A possible solution to this problem would be a use of a virtual OLE server that would create an OLE interface to non OLE applications. The alternative would be the use of an object oriented operating system like NextStep or OS/2. 3.2 Mature technology The process based prototype also showed that by using Windows based relational database management tools, OLE, industry standard local- and wide-area network tools, the development of core functions of such environments is quite fast. Current prototype's support for document versioning and dependencies between documents is limited. It keeps track of the relations between documents, but leaves the management responsibilities to the users. Further development work will be focused towards evolving the prototype into an end-user version to be distributed. Further research work is focused on improving version and dependencies management. 4. TOWARD HYBRID SYSTEMS In sections 2 and 3 a construction design document management system was described. The system is limited to a single life-cycle stage of the product and to only one organisation that takes part in its development. The extension of the scope to other life cycle stages and other organisations requires a more complete model which would also establish a clear relation to the product and process models. Such a hybrid CDM system model was attempted in a pre-study (Turk et al 1994). This section will show that the CDDM system model, presented in Section 2, is compatible with and can evolve into the more sophisticated hybrid model. 4.1 Hybrid CDM system model A generalised view of the HCDMS model is depicted in Fig 10. Every document has presentation and organisation information (or aspect). The presentation information defines the type of document according to format, content, storage etc. (digital vs. not digital documents, texts, books, drawings,

videos, results of programs etc.). The organisation information ties a document or set of documents to the organisational structure of an organisation that is involved in the life-cycle of a building product (project specific, company wide, industry wide). A generic document may be either a source or a query document. A source document is the original container of information and not just an output of some data that are originally stored in some other place. As such it has some document life cycle information, which includes data on document state and activities which are performed by actors and are modifying the state by using resources. A source document also relates to product life cycle information because the activity is a part of a task, which is a part of a life cycle stage, which is a part of the building product life. Query documents are special views of the building product database. The source of the information is thus the product database. The documents include information about the building product model entities which are described in the document. The entities have product life cycle information of their own. 4.2 Relation to the CDDMS model CDDMS model includes the parts of Fig 10 on the shaded background. Since it is not product model oriented, it is concentrated around the source document and those of its features that are not related either to the product model or organisational aspects that go beyond the walls of a design studio. The presentation and document life cycle information are thus quite complete, while the support for the product life cycle and the associated dynamic product model information is limited, as well as the support of organisational information. 5. CONCLUSIONS Process and product models are not the goals but the means to computer integrated construction and integrated CAD. The two models are the servers - the infrastructure - to client models which are application specific. Product models are being standardised in the framework of the STEP standards. Process models are still a research topic. We have shown that it is possible to practically apply a process model to a document management system.

This resulted in a practical integration of the design process. By using documents as the entities with the attached process related information we have avoided the explosion of the size of the product database which would have happened if the process related information had been related to smaller data items. In addition modelling CDDM systems is an excellent polygon for the study, design and implementation of process models, because documents are general and informationaly rich enough to enable the observation of construction processes on a larger scale. The presented prototype has a clear perspective to be expanded into the hybrid construction document management system which we expect will be the next step we shall see in the development of solutions for computer integrated construction. Further research in this area is needed in the following areas: versioning and dependencies management, tighter integration with product models into hybrid systems, hyperspace and virtual reality browsing as opposed to current techniques or database queries and hypertext. 6. REFERENCES Armstrong, S., Lockley, S., 1994, Modelling of generic Document Sructures and the Development of an Integrated Document Data Environment, To appear in Proceedings of the 1st European Conference on Product and Process Modelling, Dresden, Germany, Oct. 5-7., 1994. Berger, C.J., 1989, Law: Project Documentation, Progressive Architecture 5:89. Billing, K., 1993, Engineering Document Management Systems, Cadence, August 1993. Björk, B-C., 1994, Conceptual Models of Product, Project and Document Data; Essential Ingredients of CIC, Proceedings of the ASCE First Congress on Computing in Civil Engineering, Washington D. C., June 1994. Björk B-C., Huovila P., Hult, S. 1993, Integrated Construction Project Document Management, Paper submitted to the EuropIA 93 conference. Debras P., Rezgui, Y., 1994, Software Systems for the Integration of Documentary Engineering within a Construction Project, Preproceedings of the CIB W78 Workshop on Computer Integrated Construction, Helsinki, Finland, August 22-24, 1994. Henderson, L.R., 1991, CALS as a Solution for Digital Delivery of Technical Documents, Computer-Aided Design, Vol.23, No.4, May 1991. ISO 8613, Information Processing systems - Text and Office Systems - Office Document Architecture and Interchange Format ODA/ODIF), International Standards Organization. ISO 8879, Information Processing systems - Text and Office Systems - Standard Generalized Markup Language SGML), International Standards Organization.

König, A., 1981, Leitungsdokumentation in einem kuenftigen Landinformationssystem, Schweizer Ingenieur and Architekt, Vol.99, No.10, Pg. 198-200. Kunz W. and Rittel H., 1970, Issues as Elements of Information Systems, Report S-78-2, Institut für Grundlagen der Planung, Universität Stuttgart, Stuttgart, Germany. Ladino, M.J., 1987, Making documents into Evidence. Consulting-Specifying Engineer, No.11, Year 1987. Long, R.J., 1988, Maintaining Control of Your Technical Documentation, Construction Specifier, No. 4, Year 1988. 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. Mokhtar A. and Bedard C., 1994, Towards Integrated Construction Tecnical Documents - a New Approach Through Product Modelling, To appear in Proceedings of the 1st European Conference on Product and Process Modelling, Dresden, Germany, Oct. 5-7., 1994. Reinhardt, A., 1994, Managing the New Document, Byte, Vol 19, No 8. Turk @., Björk B-C, Johansson K., Svensson K., 1994, Document management systems as an essential step towards CIC, in preproceedings - CIB W78 Workshop on Computer Integrated Construction, VTT, Helsinki, Finland, August 22-24, 1994.

Building Codes and Standards uses Static Product Model all described in Design Documentation uses uses Requirements Process Model may use uses Dynamic Product Model some described in Fig 1: ICAD modelling spaces.

static PM dynamic PM and process model fi fi fi Mark (CE): based on static calculation ID9882, unify! John (Arch): function of storey height. H Lucy (Arch): same as columns ID2145-2287, should not interfere with the opening on 2nd floor! w T Mark (CE): How about a T-profile? Fig 2: Static product model and (in clouds) dynamic product model and process model related data about a column.

use of IT in AEC document data exchange hybrid data exchange state of the art state of practice (B) state of practice (A) islands of automation development of standard conceptual models time product data exchange Fig 3: The paradigm shift.

Fig 4: Forms of the frame based (left) and the hypermedia based prototypes. Construction design document management schema and prototype. International journal of construction information technology, 1994, vol.

Figure 5: Database schema. Tables are shown as boxes, fields as words in those boxes and relations between tables as lines. documents network file system lan tcp/ip tunnel CDDM system WWW protocol Fig 6: Networking environment and the three means to access documents.

Figure 7: Document form shows multiple documents at once since it is expected, that it will be the most used form. The content field either shows the icon of the program which is used to manipulate the document or is empty when the document is not a result of an OLE supporting application. In the first case double clicking on the icon opens the application, in the second it opens up a list which lists the programs that may be used to manipulate the document.

document on LAN users CDDM system tools viewers document on WAN Fig 8: Accessing documents - user's perspective. Figure 9: Windows screen when using the program.

document lifecycle information presentation information SOURCE DOCUMENT has has has GENERIC DOCUMENT is a is a may refer to organization information QUERY DOCUMENT is a view of building product model has has product lifecycle information Fig 10:The relations between the types of documents, the building product model and various document related information.