Classification: Restricted

Classification: Restricted

Brite-EuRam BE 96-3016

CONCURrent Engineering in Building
and Civil Engineering

Information modelling

BE96-3016 CONCURDeliverable R13011

Document Control Sheet

Amendment Record

Table of Contents

1Executive Summary______

2Introduction, background and scope______

2.1What is tendering______

2.2Objectives in tendering stage______

2.3Integrated modelling______

3Information Modelling______

3.1Introduction______

3.2Object of interest and ontology______

3.2.1CONCUR information ontology______

3.2.2CONCUR Meta Model______

3.2.3Functional unit - technical solution decomposition______

3.2.4Global model______

3.3Characteristics and functions______

3.3.1Information aspects______

3.3.2Characteristics______

3.3.3Quantities______

3.3.4Functions______

3.3.5User actions and processes______

3.3.6Examples______

4Mapping to IFC 1.5______

4.1Spatial model______

4.2Element model______

Appendix A Objects of interest______

Appendix B Characteristics______

Appendix C Functions of interest______

Rev. 3

BE96-3016 CONCURDeliverable R13011

1Executive Summary

“The end goal of the CONCUR project is the integration of industrial processes within the day-to-day operations of the industrial partners.”

2Introduction, background and scope

Workpackage 1 of CONCUR is addressing the way the industrial partners work and use necessary information. Work to that intent is carried out by doing process and information analyses in the industry partner companies. The results of the analyses were reported in a number of process models, one for each partner and a CONCUR Common Process Model describing the common processes found in the investigated organisations.

The aim of CONCUR is the use and implementation of existing and emerging models required to provide meaningful two-way information exchange in technical building projects. To realise two-way information exchange, which is needed for communication between the various disciplines present in the tendering process of a project, CONCUR needs common semantics and definitions. To enable deriving common semantics an integrated modelling approach was adopted.

In addition the workpackage composed/assembled a common information model from the explicit knowledge of the processes. The model describes the information needs in the tendering process.

2.1What is tendering

The result of CONCUR for the industrial partners is the implementation and use of integrated systems, spanning the early stages of the project life cycle: from inception to tender. This period of a project discusses business needs, tries different solutions and designs a selected one. Using integrated systems provides a consistent means of handling data and information, accelerates the process and acts as a basis for further work in construction, operation and decommissioning.

Our analysis in CONCUR revealed that the tendering process changes, based on differing business trends such as increased globalisation and most importantly changes in collaboration and types of contract. In conventional tendering for building projects an organisation received a detailed set of requirements and specifications for a facility, sometimes even containing detailed drawings. In CONCUR we leave the conventional notion of tendering based on a detailed description of the facility but we focus on the process ignoring a number of issues, like information ownership and authorship, differing or additional contractual obligations and changing responsibilities and liabilities.

A definite end of the tendering process cannot be given, it is all up to the client, and depends on the subsequent process. For the purpose of CONCUR we let the tendering process end with the formal approval or dismissal of the client based on an accurate costing and global planning. A typical tendering process therefor ideally involves all disciplines that have any relationship to the facility and also elaborates on the complete life cycle of the facility. The consortium talking to the client is much more than a construction preparations group. It will act as a trusted partner to the client.

2.2Objectives in tendering stage

The main objective of the tendering stage is the specification of a facility in such a way that the client has a reasonable accurate price and has a sufficiently accurate description of the facility to be constructed and the delivery time of the facility, in accordance to set requirements.

There are a number of bases to which people arrange the tendering process. As long as there is no contract to carry out work, a balance will exist between depth and detail, and effort. Despite the fact that decisions made early on might lead to large consequences in the remainder of the project.

A tender team needs to take care that a minimal amount of waste is produced. As waste we might think of the effort made and results produced in case a project does not lead to an order. On the other hand the team needs to ascertain that effort and results produced are sufficient to win the order. That this leads to tension may come as no surprise. A hit rate of 25% means that 75% of the time and effort spend on tendering is waste and must be recovered in some other way. Reducing the effort in the 75% which is lost will directly result in better margins.

The first test of the tender team will be to assess the viability of the project and judge it on its merits for client and other participants. It may well come out that a proposal for a facility might look promising, but lacks viability because of huge ground prices. During the assessment of viability and feasibility work is done in close co-operation with the client and other (potential) partners in the consortium to enable sound value engineering.

The priority of the information gathering process is driven by the need to acquire more certainty and confidence. The first items to be refined, i.e. detailed, will be items that constitute risk or have high uncertainty. Building houses one would very much like to know whether the ground is heavily polluted which results in expensive cleansing operations, building a process plant one might care less. The team and the client together need to obtain confidence that a particular facility fulfils the business requirements of both parties and solves a problem to the client. Confidence will also be obtained or strengthened by producing a realistic construction programme with possible issues and bottlenecks clearly defined.

The tendering process is one of many decisions: shall we build a high rise or shall we remain shallow, shall we use glass cladding or wood planes, ... . What happens is that each action is aimed at providing information for the next decision. The tendering process therefore is in essence an information production process. An information production process that takes some bits of information and refines and refines until enough is gathered for a sound decision. In fact each decision is aimed at determining the viability, assessing and reducing risk, and eventually in calculating the cost. As tendering is a refinement process this also holds for the requirements. In each refinement cycle more will be known and more detail will be presented about the
performance requirements of the building or product under design.

Today an electronic model of the product that is collaboratively arrived at will facilitate the communication between disciplines and with the client. It also enables keeping consistent information about the facility.

2.3Integrated modelling

Integrated modelling addresses the various models not independently but includes the individual relations. It also looks at existing models and tries to position them in the CONCUR environment. Integrated models including processes, information semantics and information content are necessary to enable an integrated work practice sharing and using the same data. The most challenging issue has been to devise a way to capture, define, develop and maintain a consistent view of the business scope, business processes, information aspects, information objects and information flows.

CONCUR needs two-way semantic information exchange about building projects. To do so CONCUR will use and implement existing models and concepts, based on a common terminology, common semantics and definitions. In CONCUR modelling has been done to identify activities, which are carried out during tendering by the industrial partners to capture work practice and information. We identify the (physical) objects of interest (ooi) which practitioners use in tendering. Objects of interest denote the way practitioners look at a facility during the tendering process. Different views can be introduced when a proper product tree is available.

Although use is made of existing standard models, developed in STEP and IAI, composing a common information model is not possible without doing an amount of modelling. Purpose of the modelling activities is to identify and bridge the gap between practitioners models and how information is described with existing and proposed standards. Therefore one of the activities being done is to match the practitioners view of the world with existing and emerging standard models and derive a relation between how practitioners describe their world and existing models describe the world of building and construction.

As stated in the Technical Annex information modelling will address various conventional project stages. Based on process analyses results and observations and conclusions there formulated, it was felt that the individual modelling task results would not benefit to CONCUR. In stead an integrated modelling approach was proposed and adopted. This does not exclude the need to describe informational requirements for the processes defined along the traditional inception/client brief, feasibility study, concept design and tender stages approach. So information granularity gradually increases and ranges from the technical building to the information items needed to enable an accurate tender to be presented. This means that major cost items and major decisions are included, but no detail drawings (the conventional way of describing/defining a product) are included.

3Information Modelling

Information structures are used to enable capturing the right information at the right time to provide proper back-up of decisions being made and to register what bases decisions have been arrived at.

3.1Introduction

The inception model focuses on the information, which is acquired in the early phase of a project. Information is related to the business needs of the prospect, the business needs of the tendering consortium aimed at arriving at a feasibility of a project. The information then needed comprise the performance requirements a prospects wants the product to fulfil. Specifying performance requirements is a move from conventional projects where specifications might be based on very detailed drawings leaving out any design contribution from the tenderer. Online the outline of a product, building or other solution is now given.

The design model extends the outline which has been described in the inception part of the information model. Since the design is aiming at resolving additional challenges and deciding on more detailed issues of the product and project development, it reflects the approach and work practice taken by practitioners. The traditional design model may be reshuffled to support modern and new ways of working and co-operation thereby providing the necessary information structures.

The design model builds upon existing and emerging data standards. The approach adapted closely relates the informatin model to the IAI IFC 1.5 development, but also similar standards such as STEP AP221, AP225, AP227 are taken into account. For those areas which are not supported we have modelled closely related to the IAI IFC 1.5 thereby taking into account the way the concepts of the complete information model have been outlined.

The following sections describe the concept which has been adopted by CONCUR to arrive at additional model elements which closed the gap between CONCUR and standards, hence between what is needed and what exists.

3.2Object of interest and ontology

Information is used to communicate. To enable electronic communication one needs to identify the information used and needs to be communicated. During the process modelling activities some information modelling has already been done: globally identifying what information is needed and what is produced by activities.

Practitioners have their own way of communication. They certainly don't exchange information in terms of information models but they speak about their own objects: their objects of interest (OOIs). During discussions with practitioners a set of OOIs has been identified (See appendix A). They denote the terms with which they communicate in the early stages of a project. Built Objects are similar to the Objects of Interest.

Looking at the OOIs a structuring has been applied. The structuring follows the thinking process and information expansion and detailing which takes place in the tendering process.

Views associated with the disciplines involved in building and construction lead to different information entities. Information is associated with a functional system or unit, e.g., structural system, electrical system, spatial system. Each system has certain requirements to be derived from the use of the total product and the client perception. The functional units noted can be matched and implemented by technical solutions.

3.2.1CONCUR information ontology

CONCUR set the top level of a product tree, based on discussions with practitioners. A few levels of detail are added. The product tree will need to evolve into a complete product model. Modelling however is not the focus of CONCUR. But with insufficient existing material and standards for the tendering process, additional modelling work is done. CONCUR uses as many existing information models as possible. Therefore the information modelling activities are aimed at identifying the entities involved, i.e. what determines the product tree, and selecting from what existing model they might be taken. In a way that CONCUR will be able to compose its information model and use tools available for and associated with the models, e.g. IAA IFC 1.5, AP221, AP225.

Appendix A lists the top levels of the objects of interest which have been specified by the practitioners. The objects of interest obtained from parctitioners have been structured in a crude way to enable relating the elements to existing models on the one hand, and to enable relating with practitioners on the other hand. Further structuring and mapping onto the IAI IFC 1.5 has been done in chapter 5. The complete EXPRESS-G diagrams show the relations to IAI IFC 1.5 elements.

3.2.2CONCUR Meta Model

Adding more structure to the CONCUR OOI-s several steps forward have been tried. All steps were aimed to restrict information modelling to the bare minimum and rely on existing and emerging standard models. A limited number of relevant relations between OOI-s can be identified. Besides "part-of" for decomposition, "is-a" for subtypes, "connects" for connectivity is added and "role" to denote specific views and functions of objects. From these considerations the following meta-model could be derived which can be mapped onto the IFC 1.5 model.

3.2.3Functional unit - technical solution decomposition

The General Architectural Reference Model states that functional units specify facilities or functions that can be provided by a technical solution. Each occurrence of FU-TS therefore denotes a design decision: selecting a specific technical solution.

With the decomposition rule that states that: TSes decompose in lower order FU’s, the Hamburger model of the Turbine building looks like the one shown in the figure below.

Note that each individual Hamburger constitutes: (1) a decision about the choice of a particular type of Technical Solution, and (2) the derivation of the parameter values that are required for the aspects. Decisions are influenced by choices made in related Hamburgers.

From the Hamburger model you can see how important it is to retain the high level OOI’s in the Ontology. Normally you would probably not include an object like BuildingEnclosureType, but including it provides the possibility to store information about different combinations of the lower level entities Roof, Wall, etc. (for instance as used in earlier projects).

3.2.4Global model

Based on discussions and examples above the information can be divided into a restricted number of different areas of interest. The areas combine the view and discipline of various specific topics that are investigated in the tender stage.

First of all the approach is to derive performance specifications based on the spatial needs of a prospect. Second there is the translation of spaces into more substantial building elements. Third the types of finishes of building elements and spaces are collected.

3.3Characteristics and functions

3.3.1Information aspects

We use aspects to identify information needs in our discussions with practitioners. An aspect of an object describes (a collection of) distinct properties of an object. An aspect of an object may be represented in various ways by a collection of attributes. In other words, an aspect of an object is a grouping of object's attributes belonging somehow together and which are interesting enough to record information about. The role of aspects is to enable the capturing of relevant information grouped together which addresses a specific topic in relation to the object of interest. Aspects are (following the GARM) subjects like: strength and stiffness, fire safety, energy, cost, etc.

Definition of the relevant aspects of interest of the objects is one step in the overall modelling process, and it serves the scoping of the modelling by providing some hints on what type of properties of the objects should be included in the product data model. Which aspects are relevant for CONCUR depend on what is important for tendering. The following addresses several aspects we are interested in. A definitive list cannot be given now but will evolve along the lines of the implementation part of the project.