Collected End User Scenarios

Transcription

1 IST Classification: Public IST ICCI Innovation co-ordination, transfer and deployment through networked Co-operation in the Construction Industry Collected End User Scenarios Authors: Katranuschkov, P. (TU Dresden) Wix, J. (AEC3) Liebich, T. (AEC3) Gehre, A. (TU Dresden) Issue Date 25 March 2002 Version 1.0 Deliverable Number D11 Task Number WP1 / T11 Status Issued

2 Abstract The overall aim of the ICCI project is to enhance the co-ordination of research and developments in IST projects targeting the construction sector, the promotion of the selected projects results, and a concerted support for the future implementation and deployment of new technologies in industrial context. The specifically addressed project objectives are: (1) to synthesise industrial requirements, (2) to publish ICT state-of-the-art in the fields of technical advances and commercial offerings, (3) to synthesise information for the integration of human, organisational and technical elements, and to provide best practice guides, (4) to assess the latest developments in the area of legal and contractual support for the use of ICT in construction, (5) to deliver dissemination, and (6) to provide future requirements, strategy and implementation plans for IT in construction. In this context, Work Package 1 of the project focuses in particular on aspects related to the industry needs in the global ebusiness. It deals with the synthesis of end users scenarios and the synthesis of industrial end users requirements. This Deliverable D11 reports the first phase of the work performed in WP1 - collecting of end user scenarios from all member projects of ICCI, including identification of actors, roles, tools / systems deployed and used, information and communication streams. It is structured as follows: Chapter 0 Executive Summary presents the overall roadmap of the work package, including the planned follow-up deliverables, outlines the adopted approach, and provides a concise review of the work undertaken in the period. Chapter 1 Introduction presents the goals of the report and the specific nature of the research effort, and identifies the scope of the performed study. Chapter 2 Background provides a walk-through of the studied projects and other resources, including a short summary for each of the projects, with its most essential objectives and achievements. At the end, a concise discussion of the findings and impressions obtained during the study are also presented. Chapter 3 Methodology deals with the developed approach for harmonised representation of user scenarios. The achievement of a harmonised view has been deemed very important both for the subsequent synthesis of user scenarios and requirements, as well as for the overall objectives of the project. The suggested approach is intended to serve as a more general recommendation for future ICT projects, including national and international RTD projects and IAI-related industry-driven projects. Chapter 4 Results details the collected 24 user scenarios, comprising 77 subtasks. This chapter, spanning over more than 70 pages builds the main part of the report. In accordance with the developed approach, all scenarios are provided in a uniform manner, on the basis of a pre-defined template. In this way, initial classification of the gathered data (w.r.t. the involved actors, applications, communication methods and techniques, data content, type and formats) has been achieved. The chapter ends with a summary of the obtained results from the study and a discussion related to the process and the adopted methodology. Chapter 5 Mapping of the user scenarios to AEC industry processes lists the results of the performed pre-classification of the collected scenarios in terms of the addressed design and construction processes. Furthermore, the provided data are extended beyond the gathered scenarios from the ICCI member projects to include also a high-level view on all recently finished or ongoing IAI projects. Finally, Chapter 6 Conclusion synthetically summarises the overall results of the work done. Katranuschkov, P. et al., March 2002 Page 2 of 133

3 Document Revision Sheet Revision No. Status Page Nos. Amendment Date By 1 Draft 86 Draft 06/03/2002 TUD 2 Pre-final Draft 130 Detailed results added, revised all chapters 3 Issued 133 Final text editing, incl. additional comments and references Issued to EC 22/03/2002 TUD AEC3 CSTB USAL TNO VTT Lough 25/03/2002 CSTB TUD Katranuschkov, P. et al., March 2002 Page 3 of 133

4 Contents ABSTRACT...2 ABBREVIATIONS EXECUTIVE SUMMARY INTRODUCTION OVERVIEW SCOPE OF STUDY BACKGROUND OVERVIEW ANALYSED MATERIAL DISCUSSION METHODOLOGY OVERVIEW BASIC CONCEPTS AND ASSUMPTIONS CANDIDATE FORMAL MODELLING METHODS THE ICCI APPROACH USER SCENARIO TEMPLATE RESULTS OF THE USER SCENARIOS CAPTURE OVERVIEW OSMOS USER SCENARIOS ECONSTRUCT USER SCENARIOS ISTFORCE USER SCENARIOS DIVERCITY USER SCENARIOS ELEGAL USER SCENARIOS GLOBEMEN USER SCENARIOS DISCUSSION MAPPING OF THE USER SCENARIOS TO AEC INDUSTRY PROCESSES CONCLUSIONS ACKNOWLEDGEMENTS REFERENCES Katranuschkov, P. et al., March 2002 Page 4 of 133

5 Figures FIG. 1: EXAMPLE IDEF0 MODEL...32 FIG. 2: EXAMPLE USE CASE DIAGRAM...33 FIG. 3: EXAMPLE OF A GPP PROCESS MODEL DIAGRAM...39 Tables TABLE 1: OVERVIEW OF IAI PROJECTS...16 TABLE 2: GPP PHASES...36 TABLE 3: GPP DELIVERABLES DEVELOPMENT...38 TABLE 4: USER SCENARIO TEMPLATE...42 TABLE 5: SUMMARY OF THE COLLECTED USER SCENARIOS...44 TABLE 6: MAPPING OF COLLECTED SCENARIOS TO AEC/FM INDUSTRY PROCESSES TABLE 7: SUMMARY OF ADDRESSED GPP PHASES Katranuschkov, P. et al., March 2002 Page 5 of 133

6 Abbreviations AEC Architecture, Engineering and Construction CAD Computer-Aided Design CAE Computer-Aided Engineering CAS Computer-Aided Selling CIC Computer-Integrated Construction CORBA OMG s Common Object Request Broker Architecture CSCW Computer-Supported Cooperative Work FM Facilities Management GPP Generic Building Process Protocol (The EPSRC IMI Generic Design & Construction Process Protocol) GPP II Generic Process Protocol Level II HTML Hypertext Mark-up Language IAI International Alliance for Interoperability ICT Information and Communication Technology IE Microsoft s Internet Explorer IFC Industry Foundation Classes (collective description for the IAI project data model framework) IIOP OMG s CORBA Internet Inter-ORB Protocol KMS Knowledge Management System OMG Object Management Group PDM Product Data Management PDT Product Data Technology QMD Quality Management Process Diagram RMI Remote Method Invocation RPC Remote Procedure Call RTD Research and Technologic Development SPF STEP physical file (data exchange format according to ISO ) STEP STandard for the Exchange of Product Data (ISO 10303) UML Unified Modelling Language VE Virtual Enterprise VO Virtual Organisation VR Virtual Reality W3C The World Wide Web Consortium WfM Workflow Management WfMC The Workflow Management Coalition WP Work package XML extensible Mark-up Language Katranuschkov, P. et al., March 2002 Page 6 of 133

7 ICCI Partner Abbreviations CSTB USAL VTT TNO TUD Lough LJU AEC3 TUDelft Centre Scientifique et Technique de Bâtiment, France (coordinator) University of Salford, UK VTT Technical Research Center of Finland TNO Building and Construction Research, The Netherlands Technische Universität Dresden, Germany University of Loughborough, UK University of Ljubljana, Slovenia AEC3 Ltd., UK Delft University of Technology, The Netherlands ICCI Member Projects OSMOS econstruct ISTforCE DIVERCITY elegal GLOBEMEN An Open Specification and Framework for the Construction Dynamic Virtual Organisations EU project IST ecommerce & ebusiness in the European Building and Construction Industry: Preparing for the Next Generation Internet EU project IST Intelligent Services and Tools for Concurrent Engineering EU project IST Distributed Virtual Workspace for Enhancing Communication within the Construction Industry EU project IST Specifying Legal Terms of Contract in ICT Environment EU project IST Global Engineering and Manufacturing in Enterprise Networks IMS Project No , Katranuschkov, P. et al., March 2002 Page 7 of 133

8 0. Executive Summary The general aim of the ICCI cluster is to improve harmonisation and coherency of research and development, and thereby to benefit efficiency in IST projects, assist knowledge transfer to industry, and reduce time to market of exploitation. ICCI acknowledges that deploying and using IT in construction is nowadays less a matter of cutting edge technology, than a combination of technology, organisation, marketing, legal frameworks and social impacts. Therefore, it is the intention of ICCI to start paving the way to such combination for the construction sector. In this context, the objectives of WP1 are set up as follows: to collect and synthesise, but more importantly consolidate and validate at a true European level, the end user requirements and use cases/scenarios from projects, in order to lead to industrial requirements and a set of reference models for ICT in construction (ICCI-DoW, 2001). These objectives are allocated to two subtasks, T11 and T12. Their achievement will be reported in a series of deliverables starting with this Deliverable D11 and proceeding with D12-1 (scheduled for project month 8), D12-2 (month 10), D13-1 (month 10), D13-2 (month 16) and D13-3 (month 22) *). However, in the Description of Work from the ICCI contract, the two tasks T11 and T12 are not explicitly associated with these deliverables. Therefore, at the outset, a road map for the whole work package that clearly identifies the targeted content of each deliverable had to be developed. This road map is set up as follows: 1. Deliverable D11 targets the AS IS situation. Objectives and respective activities involved include: survey of adequate formal methods for the identification/specification of business cases, user scenarios and requirements, to be applied in this phase and later on; outline of an overall methodology; capturing the available input from the ICCI member projects; studying available material from related RTD efforts; bottom-up synthesis of business cases; initial classification of the collected information. The results of these activities provide the content of this report. Due to the nature of the task, it is quite voluminous and will most probably remain the thickest report produced by WP1. 2. Deliverable D12 targets the provision of a GAP ANALYSIS. This Deliverable is divided into two parts the first (D12-1) dealing with the collection of requirements, and the second (D12-2) with the synthesis of the findings and the actual gap analysis. *) Requested to shift to month 24. Katranuschkov, P. et al., March 2002 Page 8 of 133

9 In particular, the objectives for Deliverable D12-1 include: Further refinement of the formal methodology suggested in D11; Collecting the relevant information; Draft classification of the identified user requirements. The objectives for Deliverable D12-2 are: Final specification of formal methods and models for the synthesis of business cases, user needs and requirements and its respective application w.r.t. the findings from D11 and D12-1; Identification of gaps and future needs. 3. Deliverable D13 aims to present the targeted TO BE situation. Its specific objectives are: SWOT analysis of the achieved results in the ICCI member projects w.r.t. user requirements and needs; Synthesis of all findings; Provision of a detailed process matrix capturing the collected data; Detailed elaboration of selected cases as best practice examples; Assessment of the synthetic results and recommendations for future RTD efforts; Refinement of the above in three consecutive steps (D13-1/2/3); Final recommendations to the industry and the research community in Deliverable D13-3. To achieve this, reference models will be suggested and used for three basic ICT aspects to be examined. These are: Process (using/adapting the Process Matrix from the Generic Process Protocol, as proposed in this Deliverable D11); Product data (tentatively, by using the IFC model as basis, but other possibilities will also be investigated as far as such possibilities emerge during the project); Communication (tentatively, by using the Internet-enabled client/server paradigm and Web Services concept, but other approaches will be investigated here as well). The activities related to the achievement of the objectives for Deliverable D11 constituted the major part of the work done in this phase of WP1. These activities included: Literature survey (performed by TUD and AEC3) Suggestion of common methodology (TUD, AEC3) and outlined overall approach Internal workshops (TUD, AEC3, partners) discussions (All partners) Preparing a unified form for the user scenarios capture (TUD, AEC3) Collecting scenarios in accordance with the developed approach (All partners) Editing / digesting / pre-classification of the collected scenarios (TUD) Mapping the captured scenarios to AEC/FM industry processes (TUD, AEC3) Draft report (TUD) Editing the draft and issuing the final report (CSTB, AEC3, TUD). Katranuschkov, P. et al., March 2002 Page 9 of 133

10 The structure of the Deliverable Report comprises six chapters: 1) Introduction 2) Background 3) Methodology 4) Results of the User Scenarios Capture 5) Mapping of the User Scenarios to AEC Industry Processes, and 6) Conclusion followed by an Acknowledgements and a References section. The core part of the report is Chapter 4. It presents the collected 24 user scenarios, comprising 77 subtasks. In accordance with the developed process-centric approach outlined in Chapter 3, all scenarios are provided in a uniform manner on the basis of a pre-defined template (also an output of this Deliverable). In this way, initial classification of the gathered data w.r.t. the involved actors, applications, communication methods, data content, type and format has been achieved. The obtained results are critically discussed and a high-level mapping to AEC/FM project phases is performed in Chapter 5. The study covers not only the member projects of the ICCI cluster, but is extended with analysis of all recently finished or ongoing industrydriven IAI projects. Katranuschkov, P. et al., March 2002 Page 10 of 133

11 1. Introduction 1.1 Overview When looking at previous work done on user requirements and user scenarios capture, a large variety of practical approaches can be observed. This is partially dependent on the differences in the specific objectives of the undertaken efforts and the context of the projects in which this has been done, but also on the lack of a coherent methodology. Therefore, major goals of this Deliverable, along with the presentation of the gathered raw material, are: (1) to propose a coherent methodology that can enable provision of the collected scenarios in a harmonised manner, (2) to report the derived harmonised views as a means for presenting the individual projects achievements w.r.t. the supported specific scenarios in a readily readable form, and (3) to prepare the basis for synthesising of the findings so that a well-founded gap analysis, followed by synthesised general recommendations for future RTD work can later be achieved. The reported study is based on (but not limited to) work done in the ICCI member projects. However, there are several specific features that distinguish it from similar efforts undertaken in the individual member projects, and in fact in most other RTD projects analysed. First, in the studied RTD projects user scenarios are typically identified after some basic requirements have been specified already in the proposal for the project, at its very outset or, at most, in the first 3-4 months of the work. After that, the different known projects have proceeded differently, at some point coming up with more specific scenarios. In certain cases this has been done in a straight-forward fashion, e.g. by following/adapting the UML model development approach (as e.g. in ISTforCE), or by applying a merger of IDEF0, on the high level, and UML for more detailed analysis (as in OSMOS and DIVERCITY). In contrast, in this work due to the fact that the member projects are already in their final phases - the user scenarios are extracted from what really has been achieved and demonstrated. Second, in the studied projects the methods used are most of the time applied in a generic way, focussing basically on the overall envisaged functionality and the respective processes aimed to be supported, whereas scenarios have emerged more as an intermediate product than as a specifically scheduled deliverable of the development process. Here, we have first looked at scenarios in a dispassionate way, trying to find a harmonised and coherent method for their uniform representation on the basis of a set of classification concepts, and only afterwards will deal with the synthesis of results, sorting/classifying scenarios into processes, identifying gaps, etc. - to finally derive open needs and development issues that have been or still are of high importance for the global ebusiness in the AEC industry domain. Third, the developed scenarios have been mainly elicited from an analysis of the target requirements w.r.t. the envisaged final products, with some consultancy on the side of endusers, but not on the basis of more general industry needs, taken into account at the offset. In fact, these needs are typically preset, depending on the targeted project objectives. Katranuschkov, P. et al., March 2002 Page 11 of 133

12 Here, again, no specific needs are defined in advance, but first an objectified picture is attempted to be presented. Another difference in that respect is that the reported work only implicitly refers to end-user views from interviews, questionnaires etc., as such efforts have been undertaken in the member projects themselves. Instead, the scenarios are captured basically with the help of major developers from the member projects, relying on the gained knowledge through user views collected earlier, as well as the experience from and the achievements of the research and development work during the projects. In this way, more synthetic and more consolidated views could be derived. 1.2 Scope of study As stated in the preceding section, this report is mainly based on the findings of the ICCI member projects. Whilst this is aligned with the objectives of the work package specified in the contractual documents to the project, it has been considered necessary to extend the study with additional reviewing of a number of recent or ongoing national and international projects undertaken in similar areas. In this way, a broader picture of the area of interest has been obtained. However, even with these extensions, the performed study has not had the ambition to provide a comprehensive state-of-the-art analysis of the target area. There are three reasons for that: (1) Time/resource constraints, as by contract. (2) Existing similar studies performed in the near past. Whilst it was not felt necessary to repeat such general efforts, it was acknowledged that there are no known trials for synthesising the research results of a specific set of selected major European ICT projects, undertaken in the last years. Therefore, the work was especially concentrated on the comprehensive coverage of the latter. (3) Lack of a suitable methodology that can help harmonise the very different (at the first glance) results of the analysed projects. As a consequence, special emphasis has been put on the development of such a methodology and its application to the projects in scope, instead of attempting a overview, followed by more vague analysis/synthesis of the findings (inevitably, in view of the available labour resources compared to the large amount of material to study). Having these aspects in mind is essential for the proper reading of the results of the work reported in the following chapters. Katranuschkov, P. et al., March 2002 Page 12 of 133

13 2. Background 2.1 Overview To enable the development of a coherent overall approach for collecting, analysing and synthesising ebusiness user scenarios and user requirements, a broad study of available material was initially performed. It included careful examination of the deliverables of the ICCI member projects related to the specification of user requirements and use cases, together with peer reviewing of 23 ongoing or recently finished IAI projects, 8 past and current European and national projects, and a considerable number of literature sources. This chapter presents a walk through the examined projects, with short summaries of their most essential objectives and achievements. At the end of the chapter, critical issues found are also discussed. 2.2 Analysed material ICCI member projects Common to all ICCI member projects is that they aim specifically at the solution of various complex ICT problems, providing comprehensive and sophisticated environments that cover conceptually - a large range of building construction activities. However, solutions are typically sought on generic level, whereas practical design/construction tasks are mostly included only as test-bed or best-practice (pilot) examples. Developed new engineering applications are also rare. The focus is primarily on infrastructure, logistics and data management services, together with utilisation / adaptation / demonstration of available advanced engineering and CAD software. Detailed overviews of these projects are provided in the contractual ICCI document Description of Work, as well as in several ICCI-related publications. An especially good source of information is the ITcon special issue (2001), dedicated to the ICCI projects. A short synopsis of each project is provided below for completeness and to enable reading of this report as a stand-alone document. OSMOS (IST ) The general aim of the OSMOS project is to enhance the capabilities of construction enterprises and SMEs to act and collaborate effectively on projects by setting up and promoting value-added Internetbased flexible services that support team work in the dynamic networks of the European construction industry. The specific emphasis is on providing a conceptual framework and a set of infrastructure services to support the effective operability of Virtual Enterprises, from their set up and through their full life cycle up to their final dismantling. OSMOS is strongly concerned with defining the working practices, processes, techniques, tools and technical infrastructure to enable the European construction industry to progress from its current position towards a large scale, computer-integrated approach. As such, it is an industry-led project, involving construction end-users, construction IT providers, and academic and research organisations. Katranuschkov, P. et al., March 2002 Page 13 of 133

14 Each of these organisations has a very important, complementary role in the exploitation of the OSMOS results. It is therefore strongly expected that some of them will be interested in adopting in practice the developed Internet-based teamwork services on completion of the project. econstruct (IST ) A major industry challenges is communication across national and organisational barriers, made even more complex due to the problems of transferring and sharing knowledge across different ICT systems. The econstruct consortium, a pan-european group of construction-related organisations, is rising to the challenge of narrowing this communication gap so that even small and medium construction companies and suppliers can reap the benefits of using ecommerce and ebusiness effectively. In contrast to earlier projects like ATLAS, COMBI, CONCUR and others that have mainly focused on the meaningful communication of design information, econstruct addresses ecommerce / ebusiness issues in order to provide a powerful yet low cost infrastructure that: (1) can support ebusiness between users and suppliers of building materials, components, systems and services, (2) is integrated with ecommerce and design/engineering applications, and (3) can help to establish virtual market places across regional and national boundaries. ISTforCE (IST ) The main product of the ISTforCE project is an Internet-based Concurrent Engineering Services Platform (CESP) providing intelligent services and tools for engineers, participating in parallel in multiple projects. The developed approach enables plug-in of different IT tools on the platform, both directly (as core services), or as extended (rented) engineering services. The substantial innovation of ISTforCE is that: (1) it offers a personalised human-centred approach, enhancing current, less flexible project-centred web-based collaboration approaches, (2) it sets up an open environment where new services and tools can be easily integrated and where providers of engineering information, services and tools meet project managers, engineers and architects, (3) it enables flexible and customisable object-level data exchange based on IFC, and (4) it provides an infrastructure for on-line ebusiness by combining legal and financial transactions, at all system levels. An important part of the work is concentrated on multi-project workflow management. Another important aspect is support and management of the knowledge needed by end-users in easily understandable form. The flexibility of the ISTforCE platform is demonstrated by several novel engineering applications exploiting different patterns of remote (rental) software for selected practical design/construction tasks. DIVERCITY (IST ) DIVERCITY is a research and demonstration project that is investigating the use of virtual reality in the construction industry. The project contributes to the improvement of the design and construction processes by addressing three key areas of specific AEC project activities: (1) Client Briefing, which requires detailed interaction between the client and the architect, (2) Design Review, which requires detailed input from multidisciplinary teams, and (3) Construction Planning, involving the layout of the site and the construction schedule for the building(s) to be erected on that site. DIVERCITY aims to integrate established Virtual Reality technologies with construction design activities in order to produce a design led Distributed Virtual Workspace. The system development and integration is being undertaken by five developer partners, and includes the realisation of a comprehensive product database, as well as advanced simulation packages for examination of the visual, thermal and acoustic properties of the designed buildings. Katranuschkov, P. et al., March 2002 Page 14 of 133

15 elegal (IST ) ICT based information exchange in project-based business, such as construction and large scale engineering, has become common but is not properly covered by contractual practice. The full use of inter-enterprise ICT is hampered by poorly defined responsibilities, overlapping communication techniques, mistrust. Therefore, the major goal of elegal has been to define a framework for legal conditions and contracts regarding the use of ICT in project business, with particular emphasis on construction. Based on a comprehensive study of user requirements, the project is developing legal support tools for the use of ICT in construction in order to promote an enhanced business practice in which the use of ICT in inter-enterprise information exchange is contractually stipulated. The envisaged key results of elegal include: (1) library of re-usable clauses and model contracts, (2) contract configuration and negotiation tools, (3) simulated contract negotiation game, and (4) recommendations to standardisation. GLOBEMEN (IMS Project No , ) The goal of GLOBEMEN is to define and harmonise ICT support requirements in various one-of-akind industries operating in various cultural environments (building construction, power plant, shipbuilding, telecommunications). The project aims to demonstrate functionalities which offer attractive market opportunities to IT vendors for product development, to satisfy the needs of various industries world-wide. To achieve that, GLOBEMEN develops a reference architecture for virtual enterprises, implements proof of concept industrial prototypes, demonstrates core features of the architecture, and promotes deployment by IT vendors, industry, academia and standardisation. The approach of GLOBEMEN is to address three main aspects of manufacturing: (1) sales and services, (2) inter-enterprise management and (3) engineering design, and examine these in a number of critical scenarios with high relevance to business practices Ongoing IAI projects for the next IFC platform releases Within the IFC development process, as laid out by the IAI, each portion of the IFC model is defined in terms of its usage scenario(s), business and exchange needs, and technical feasibility. Specifically, for the purposes of this study, the analysed IAI projects are a valuable source for several reasons. In almost all studied projects a common document template has been used, with special emphasis on the AEC industry processes and project phases to be supported. As all IAI projects deal with the analysis of data requirements for these processes from the viewpoint of PDT, envisaging specific domain extensions to the IFC project model, industry needs w.r.t. project information are reflected in a comprehensive and harmonised way. Because of the upcoming implementation of the IFCs in commercial AEC software, these projects are highly relevant w.r.t. short to mid-term development trends. Therefore, some general results of their analysis are also included in this deliverable, complementing the more detailed results provided for the ICCI projects. Katranuschkov, P. et al., March 2002 Page 15 of 133

16 The IAI projects led to the definition of the IFC release 2.0, subsequently to the definition of IFC release 2x the current release and they will drive the enhancements of the second edition of IFC2x, the next platform release 3 and beyond. Within this deliverable D11 all IAI projects have been reviewed and mapped to a high-level process matrix in order to (1) provide for a wider and more strongly industry-relevant scope, and (2) start providing a roadmap of IFC development, as a major spin-off effect of the work, Further work and recommendations will be done in the subsequent deliverables D12 and D13. Table 1 below summarises the IAI projects, their status and targeted IFC release. Table 1: Overview of IAI Projects Code Title Status Target release CB-1 Client information requirements *) finished N/A AR-3 Site Planning, Capture of Design Intent on hold R3 (or beyond) AR-4 Means of Escape repl. by CS-4 N/A ST-1 Steel Frame Structures active R2x 2 nd Ed. ST-2 Reinforced Concrete Structures and Foundations active R2x 2 nd Ed. ST-3 Precast Concrete Construction active R2x 2 nd Ed. ST-4 Structural Analysis and Steel Construction active R2x 2 nd Ed. BS-2 Power and Lighting System on hold R3 (or beyond) BS-5 HVAC system extensions finished R2/R2x BS-6 Performance Metrics finished R2/R2x BS-7 HVAC Performance Validation active R2x 2 nd Ed. BS-8 HVAC Modelling and Simulation active R2x 2 nd Ed. BS-9 Network IFC: IFC for Cable Networks in Buildings active R3 CS-3 Performance Based Code Compliance Checking on hold R3 (or beyond) CS-4 Code Compliance Support prescriptive code active R2x 2 nd Ed. CM-2 Temporary Facility Planning on hold R3 (or beyond) ES-2 Cost Planning finished R2/R2x FM-1 Engineering Maintenance active R2/R2x FM-6 Building Systems and Property Management on hold R3 (or beyond) FM-7 Visualization and Control within FM Systems on hold R3 (or beyond) FM-8 Costs, Accounts and Financial Elements in FM active R2x 2 nd Ed. PM-3 Material Selection, Specification and Procurement active R3 XM-4 IFC drafting extension **) active R2x 2 nd Ed. *) The CB-1 project had been a special project not defining IFC model requirements, but business processes. **) The XM-4 project is not included in the analysis presented in this Deliverable, as its context has less relevance to the performed study. In the next paragraphs, each IAI project is briefly described. More information is available at Katranuschkov, P. et al., March 2002 Page 16 of 133

17 Client Briefing Client Information Requirements (IAI Project CB-1) Clients need information both to make decisions concerning the project, but also w.r.t. the needs of their core business. Therefore, clients must be able to articulate what their needs for information are. To achieve this, a generic reference model is required to enable a common understanding of the requirements, and to allow to position the client s needs in a coherent way. Underlying this model will be a comprehensive set of information requirements to support the client processes. This information can then be used by all domains as a brief for client requirements which the domain process model(s) must deliver Architecture Site Planning, Capture of Design Intent (IAI Project AR-3) The site planning process used by architects, urban planners and landscape designers defines the location and orientation of a building or buildings on a site. Along with its orientation, the accesses to the building(s) and other major landscape features are conceptually developed. The balance between open area on the site and the building requirements may effect both the shape and size of the building(s). Therefore, the site layout process is typically one of the very first stages of the building design process. It may run in parallel with defining the building program and building massing, or occur shortly after. The capture of design intent is also the first process to be defined that is not part of commercial software solutions at the time. Currently design professionals (architects, urban planners) cannot adequately capture the reasoning, analysis, design alternatives and decisions that occur during the AEC process. By capturing these aspects in a formalised fashion, the ability for building owners and facility managers to make informed decisions based on the results of previous design and construction processes will be increased. Hence, this process can become a core capability in the object model that all disciplines should use during a facilities lifecycle. Means of Escape (IAI Project AR-4) As mentioned in Table 1 above, this project has been superseded by project CS-4. Initially, it has targeted 2 stages. Stage 1 deals with the compartmentation of a building for the purpose of means of escape in case of fire (by Use Class, by Ownership and/or Tenancy and by Area and/or Volume). Stage 2 deals with establishing of escape routes from all parts of the building to the final exits, including identification of all room exits, compartment exits, storey exits and final exits, connecting all compartment exits to storey exits to establish linear common escape routes, connecting all storey exits to form vertical common escape routes and, finally, extending common escape routes to final exits. In-order to check compliance of escape routes with regulatory requirements, the following steps have been undertaken: (1) allocating occupancy to each space within each compartment in the building, (2) checking travel distance and adequacy of widths of all exits in order to escape safely all occupants. Some of the project s achievements are further re-used within the CS-4 project. Katranuschkov, P. et al., March 2002 Page 17 of 133

18 Structural Engineering Steel Frame Structures (IAI Project ST-1) The ST-1 project deals with the exchange of steel frame information between constructional steelwork designers and other disciplines in AEC projects. Its main focus is in the exchange of spatial configuration data about steel frames (3D shape of the members of the structural steel system, their locations, orientation, relative position, and connectivity), which is based on the co-operative use of the IFC model, the CIMsteel Integration Standards specifications (CIS), and a mapping between them by a so-called Interoperability Adapter. CIS, developed in the CIMsteel Eureka project, is a comprehensive specification enabling data exchange and sharing of detailed product model data for the design, fabrication and erection of construction steelworks. The CIS Release 2 forms are also the basis of Application Protocol 230: Building structural frame: Steelwork of the ISO standard Product data representation and exchange (STEP). Both IFCs and CIS utilize in their specifications and implementations the same PDT methods and techniques: the EXPRESS modelling language, the ISO data exchange format, and available EXPRESS toolkits from ISO Also, emerging from the STEP effort is a mapping specification language (EXPRESS-X), which allows for formal specification of mappings between two distinct data specifications (i.e. EXPRESS schemas). The targeted AEC industry processes in ST-1 include: (1) Steel frame baseline information provision as input for steel frame design, (2) Steel frame design, (3) Steel frame spatial configuration for design coordination, collision detection and visualization, and (4) Early planning of steel frame fabrication, transport, assembly and erection. Reinforced Concrete Structures and Foundation Structures (IAI Project ST-2) In all kinds of business processes related to building production, the structural safety of the building is obtained through the overall domain process of structural design. This domain covers the processes of "Structural scheme design " and "Structural execution design", which come after "Architectural programming" and "Structural scheme", through the processes of structural design of architectural production to construction works. The information of this domain - after "Production design" which is the next process, is reported to the "Construction" section. "Supervision", which is attended by a structural engineer, is performed similar to "Construction". However, this does not include a link "Production design" to "Supervision". The objective of the ST-2 project is to represent the reinforced concrete structure and foundation structure of a building in one coherent model, but allowing for their individual use as well. There is only a weak relation to the IFC Core model, with only one part of it strictly considered. Further work towards full IFC integration is planned for a later stage or follow-up project. Within the targeted processes, the following activities are considered: (1) Structural scheme design including member scheme, material scheme, foundation scheme, schematic structural calculation, rough estimation; (2) Structural execution design including allowable stress design, decision of member shape and layout, ultimate strength design, allowable stress design, making of structural drawings. Out of scope is the sub-process of external force calculation. Precast Concrete Construction (IAI Project ST-3) Precast concrete construction is an important type of building systems, which is heavily used in Nordic countries, but also in other European countries. Additionally, precast concrete elements are used also Katranuschkov, P. et al., March 2002 Page 18 of 133

19 as floor and facade elements together with steel frame systems in many countries around the world. The benefits from the precast concrete construction IFC extension are: (1) Enabler for streamlined product data exchange between building designers, element designers, element manufacturers, and contractors; (2) More efficient process without much of the manual re-input of data into different IT systems, and better possibilities for exploiting the data in downstream applications; (3) Better basis for further development of precast concrete production automation. As an expression of the real business need for the work, about ten years ago in Finland a data exchange specification and system called BEC-system (Precast Concrete CAD) has been developed. The system was perhaps ahead of its time, but it is still to some extent used by the industry. Since precast concrete structures are a special form of reinforced concrete structures, the project relies on the outcome of ST-2, dealing mainly with in situ concrete, and also on ST-4 for the material independent structural analysis. In terms of the business processes, the focus lies on the specifics of manufacturing the precast structures and therefore on the design phase for data provision, as well as on the production phase. Structural Analysis Model and Steel Construction (IAI Project ST-4) ST-4 is one of the more recent IAI projects, inaugurated in Its primary goal is to tightly integrate the structural engineering domain into the information management process provided by the IFCs. It is intended that all already captured building data are re-used, extended as necessary, and associated with structural assumptions. In this respect, ST-4 is substantially different from ST-1 and ST-2. The project develops two domain extension models: (1) structural analysis, and (2) steel construction. The structural analysis model shall enable structural engineers to set their assumptions in the context of the whole virtually defined building, by specifying the load-bearing structure of the building as a whole, as a set of substructures, or both. The provided inter-connections with the basic IFC building elements are a major benefit of the integration into the IFC project model. They can help structural engineers as well as other designers to manage more efficiently the highly iterative analysis and design processes. However, it is not the purpose of this extension to cover the whole domain in full detail, but to capture the 'main decisions' of the structural engineer and provide them to the other designers. Changes in the virtual building can be traced easily to the related parts of other domains. As a result, the time needed to respond to changes will be considerably reduced. The steel construction model is more voluminous. It is based on the available comprehensive German industry standard for data exchange in the steel construction domain (Produktschnittstelle Stahlbau). However, in accordance to the principles outlined above, compared to ST-1 the steel construction extensions are broader in scope, but also not so detailed as in ST-1. The link to basic IFC elements is stronger because the whole original model is re-worked and not mapped Building Services Power and Lighting System (IAI Project BS-2) The BS-2 project deals with the definition of information requirements for some of the electrical services aspect of building services. Within the IFC 2x development cycle, four electrical processes are planned to be covered: (1) Lighting Design and Layout, (2) Protective Devices, (3) Conductors, (4) Cabinets, Panels and Enclosures. The design of power and lighting systems is undertaken by building services engineers or by electrical engineers. The addressed processes are part of the detailed design stage of work. Lighting design is important in that it determines the illumination available for working or for safety in the event of a Katranuschkov, P. et al., March 2002 Page 19 of 133

20 need to evacuate the building. Lighting is often a subject of particular interest to the architect, not only because of the illumination and its quality but also because of the positioning and the type of light fittings. Positioning of light fittings also has a bearing on the installation of other engineering services and on the design and erection of ceilings. HVAC Systems Extensions (IAI Project BS-5) The BS-5 project includes the following processes: (1) Plumbing System Design, and (2) Control System extensions. It builds upon or extends work done in the IAI BS-1 Project HVAC System Design. Engineers responsible for the design of building plumbing systems are typically consulted during the building conceptual stage. However, major design efforts occur after the architect has substantially completed his part of the building design. Thus, the design process here encompasses assigning plumbing fixtures to the architect s designated locations, and the schematic and detailed description of associated plumbing piping components. These components include sections of pipes, fittings and accessories, such as cleanouts, valves and regulators. The design process also includes the connection of these components to plumbing fixtures (such as water closets, lavatories, urinals etc.) and equipment, (such as air compressors, booster pumps, sewage ejectors etc.), as well as construction cost estimates. However, the latter are typically performed by contractors using the construction documents (drawings and specifications) prepared by the Building Services engineers. Performance Metrics (IAI Project BS-6) This project is planned as an international collaborative effort led by the North American Building Services Committee. It aims at capturing performance objectives and their corresponding performance metrics along with any corresponding relationships to building elements or components, to achieve more efficient operation of the building and provide feedback for more effective building design. Engineers, contractors, and building owners all are concerned that the building design, construction, and operation meets specific functional requirements. These requirements, or Performance Objectives, typically are qualitative in nature and exist in many abstract forms. For example, a Performance Objective might be that the occupied spaces in a building must be comfortable and have an adequate lighting level to support the tasks planned for the space. To satisfy these Performance Objectives, a set of measurable, quantitative target values must be established as discrete Performance Metrics. Performance Objectives come into existence from many sources (the building owner, site conditions, local utility incentives etc.), and many decisions are made during the design, construction and operation of a building to meet these objectives. In many cases, specific building elements or components are designed, specified or installed so that the Performance Objectives can be realized. Therefore, it is essential that a relationship between the Performance Objectives and specific building elements and components are identified and maintained so that their design rationale becomes and remains available to downstream participants. HVAC Performance Validation (IAI Project BS-7) The BS-7 project deals with the performance of HVAC systems during the life cycle of the building, including the design, build, commissioning and operation/maintenance period. The project was initiated recognizing that emerging technologies for performance validation, like simulation and other model-based methods, require detailed information from systems and their components. These methods utilize physical descriptions of HVAC systems to construct reference models of correct operation. The complexity of the models determines the detail of the information captured. The challenge is to identify those physical attributes of the HVAC components and subsystems that describe the core features that can enable performance validation using simulation based methods. Katranuschkov, P. et al., March 2002 Page 20 of 133

21 The project involves identifying the static information required to construct "correct operation" models of selected HVAC subsystems/products. Currently it concentrates on selected HVAC subsystems and products, i.e. radiator heating system and its defined components, air-handling unit, and cooled beam. Specifications extend the scope of IFC models to include this performance-related data. Particular consideration has been paid to the evolution of performance data through the building life cycle. The focus is on simulation based performance validation methods, which facilitate better understanding of the dynamic behaviour of a building and its HVAC systems. HVAC Modelling and Simulation (IAI Project BS-8) Similar to the BS-7 project, BS-8 is concentrating on the design and operation of HVAC systems in buildings. Compared with BS-7 it is broader in scope for the HVAC systems concerned, but more narrow in focussing on the thermal simulation part. Specifically, the project focuses on the support of the exchange of HVAC information between software currently used by the AEC/FM community (e.g. CAD) and various building services simulation tools, such as EnergyPlus (the successor of DOE, one of the broadly used simulation tools in industry and research). Supporting the exchange of HVAC information will make the use of such tools more efficient and cost-effective, and will therefore remove the primary barriers for their more widely spread use. The project recognises that currently the business case of simulating the thermal performance of buildings is supported in terms of the building geometry and materials by IFC, and not yet in terms of the building system design. Extending the IFC model to support the modelling and simulation of HVAC components and systems will allow this information to be more easily archived and exchanged between participants across the life cycle of a building project. In order to ensure that the HVAC systems within a building are properly designed and operated, HVAC data must be documented along with all other building information (e.g. geometry and construction material characteristics). This will provide access to this data not only during design, but also during the operation of the constructed building. Due to the overlap with BS-7, both projects have recently joined efforts and will propose a single and harmonised IFC extension. IFC for Cable Networks in Buildings (IAI Project BS-9) This is a very recent IAI project proposing to extend the IFC definitions for cabling and cable management. It acknowledges that an electrical domain extension, based on the IFC building model, is still missing but needed for the management of modern buildings, where cable networks become more and more important. The co-ordination and integration activities between the disciplines of architecture, network design, facility management and others are therefore in the focus of the project. The co-operation will be supported by an extended IFC object model, that allows to: (1) transfer the description of various network facilities and to identify them for a usage in different CAFM- and CAD-systems, (2) use relevant data of building models for network design / facilities management, (3) use both network and building data in third application fields as HVAC, security, especially fire prevention and admission control. Expected benefits include the increase of design quality both on the architectural and the network side. Furthermore facility management processes and re-engineering of communication networks will be improved. The scope of the project is the support of the communication between the architect, the network designer and the facility manager using different software systems, and the data exchange among different CAD and CAFM systems, especially network facilities management systems. Katranuschkov, P. et al., March 2002 Page 21 of 133