Classification: Restricted
CON
CUR
Brite-EuRam BE 96-3016
CONCURrent Engineering in Building
and Civil Engineering
T1200 Inception Stage Information
Requirements and Modelling
Authors:
Pekka Valikangas, Fortum
Maria Nikolaenko, VTT
Matti Hannus, VTT
Theo van Rijn, TNO
Jeff Stephens, Taylor Woodrow
Distribution
Date
Draft 1
Issued
24/12/2000
26/01/2001
Report Reference
TW
FORTUM
*
*
*
SKA
*
TNO
*
DUT
*
VTT
*
R1201
Status Draft/Issued/Revised
Issued
*
KTH
*
STABU
*
WWW
*
CEC
No.
Date
Rev.
1
Release
CEC
24/01/2001
--
to
ii
CONCUR R1201
This page is intentionally left blank
CONCUR R1201
TABLE OF CONTENTS
iii
page
1.
EXECUTIVE SUMMARY
1
2.
INTRODUCTION, BACKGROUND AND SCOPE
1
3.
4.
5.
2.1
What is tendering
1
2.2
Objectives in tendering stage
2
2.3
Integrated modelling
3
INFORMATION MODELLING
5
3.1
Inception model
5
3.2
Design model
6
OBJECT OF INTEREST AND ONTOLOGY
7
4.1
CONCUR information ontology
7
4.2
CONCUR Meta Model
8
4.3
Functional unit - technical solution decomposition
9
4.4
Global model
9
ASPECTS AND ATTRIBUTES
9
5.1
Information aspects
5.2
Functions
10
5.3
Characteristics
11
5.4
Quantities
12
5.5
User actions and processes
12
5.6 Examples
5.6.1
Standby power installation
9
12
13
6.
EXISTING MODELS
14
7.
CONCLUSIONS AND RECOMMENDATIONS
14
8.
REFERENCES
14
APPENDIX A, Inception Stage Information by Fortum Engineering Ltd
1
CONCUR R1201
1.
Executive Summary
“The end goal of the CONCUR project is the integration of industrial processes within the dayto-day operations of the industrial partners.
incept
incept
design
design
realise
realise
downstream
upstream
Information store
Figure 1.1 Two-way information exchange (left) implemented with an information store
accessible by all throughout the project. [Frits Tolman et. al.]
2.
Introduction, background and scope
Work package 1 of CONCUR is addressing the way the industrial partners work and use
necessary information. Doing process carries out work to that intent 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 results were published in deliverables
[R1101FI], [R1101SE], [R1101UK] and [R1102]. Task 1200 is giving direct results to T2200,
which is reported in deliverable [R2201].
CONCUR is aiming to use and implement existing and emerging models [Frits Tolman et. al.],
which are 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 work package composed/assembled common information model from the explicit
knowledge of the processes. The model describes the information needs in the tendering process.
This report was written at the beginning stage of the CONCUR project (September 1998) and
then reviewed at the end of it (January 2001).
2.1
What 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.
CONCUR R1201
2
Our analyses in CONCUR revealed that the tendering process also changes, similar to the way
business changes. 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, differential 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 the contract,
and depends on the succeeding 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
detailed planning. A typical tendering process therefore 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.2
Objectives 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 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 assure 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% that is lost will directly result in better margins. The first test of
the 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
CONCUR R1201
3
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 refine and refine until enough is gathered for a sound decision. In fact
each decision is aimed at determining viability, assessing and reducing risk, and eventually in
calculating 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.
The CONCUR industrial Partners studied their tendering processes and a number of variations
too. These were presented in the form of IDEF0 (ICOM) activity diagrams (figure 2.1, taken
from [R1102].) that decompose (i.e. sub-divide) through about four levels of detail. As well as
allowing the processes to be analysed and potentially better organised, the diagrams show the
main sets of information that flow between the activities.
It is this information facilitates communication between projects, disciplines and companies, and
that characterise the integration of systems (manual and IT) needed to support communication.
The exercise also first raised the issue of words, meaning and communication of concepts
between partners. It was evident that partners easily misunderstood each another, particularly
when discussing detail. Discussion was necessary to reduce “fuzziness” and increase precision
person to person. Computer-to-Computer transfer of information must be unambiguous (i.e.
precise) which requires careful definition of terms (see LexiCon later) and relationships (see data
models later).
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.3
Integrated 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.
4
CONCUR R1201
AUTHOR: Frits Tolman and Theo van Rijn
DATE: 13/03/98
PROJECT: Common CONCUR Process Model REV: 3
USED AT:
NOTES: 1 2 3 4 5 6 7 8 9 10
external C2
process
constraints
C3
Develop
and Refine
Concept of
Technical
Building
technical
building
concept
x
site works
Design and
Refine
Technical
Building
I1
READER
DATE
Compile, Submit and Decide on Tender
is not decomposed.
For CONCUR only the input for the
Tendering process is relevant.
If the tender is succesful the
process continues, otherwise it stops.
technical
building
as_designed
Cost and
Refine
Technical
Building
global design
technical
building
as_costed
Compile,
Submit and
Decide on
Tender
A2
business process needs
P. 5
(as relevant for
the technical building)
Design and
Refine
Tender
Construction technical
building
Programme
A3
as_planned
A5
Detail, Erect technical
and Operate building
and Maintain
O1
Technical
Building
comment
NODE:
A-02
TITLE:
I2
raw materials
construction products
Conceive, Design, Plan and Erect Technical Building
tender
result
A4
construction programme
The main processes each transform the
technical building into a subsequent States.
"and Refine" implies required feed back loops
including, e.g., from Plan back to Develop Concept.
Note that the model focuses on the primary design
process. Other important views for tendering,
like planning, or cost are derived and not detailed.
CONTEXT:
comment
process equipment
building regulations,
planning regulations,
safety regulations,
environmental regulations.
A1
P. 4
C1
WORKING
DRAFT
RECOMMENDED
PUBLICATION
A6
comment
The dotted process is outside
the scope of CONCUR
NUMBER:
technical building
as_realized in operation
P. 3
Figure 2.1 Conceive, design, plan and erect technical building
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 practitioner’s models and how
information is described with existing and proposed standards. Therefore one of the activities
being done is to match the practitioner’s 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 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.
5
CONCUR R1201
Identification
Identificationofofactivities,
activities,
information
informationflows
flowstotobe
be
supported and
supported and
supporting
tools
supporting tools
Do
inception
Identification
Identificationofofkey
key
objects
objectsofofinterest,
interest,
their
decomposition
their decomposition
and
andsubtyping.
subtyping.
Identification
Identificationofofrelevant
relevant
aspects
aspectsofofthe
theobjects
objects
Do
design
Do
tender
Identification
Identificationofofthe
the
properties
propertiesofofthe
theobjects
objects
Do
prj mgnt
Object
Objectontology
ontology
Object
Asp1
Asp2
Information
Informationplanning
planning
model
modelas
asaaroadmap
roadmap
totokey
objects
key objects
Formal
Formalproduct
productdata
data
model(s)
model(s)describing
describingthe
the
detailed
information
detailed information
requirements
requirements
Asp3
Object
Property Description
Candidate
model
Candidate
model
Candidate
model
xxx
Figure 2.2 Overall scooping and capturing steps of information requirements into a formal
product data model
3.
Information 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.1
Inception model
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 prospect 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 tendered. An
outline of a product, building or other solution is now given. Performance specifications might
be as simple as “we need a hospital with 200 beds, 2 operating theatres and recovery rooms”, or
“we need an office for 150 people with 2 management layers requiring 10 meeting rooms”.
Figure 3.1 shows the story of the design process in the tendering phase (in FORTUM
classification the Inception phase). Solid arrows represent data flows between different tasks
(rounded boxes). Other arrows (dashed) represent data flow, in which the data is mainly
generated during the design process and the inception data is not anymore noticeable. Fully
coloured boxes are tasks, where the inception data is having considerable effect. Other boxes
(coloured cross-hatched) represent tasks where the design work is mainly based on the design
process itself.
The main purpose of the CONCUR project is to specify the data flow (arrows) between different
tasks. However tasks must be supported by development and/or configuration work in tasks
T2200: “Configure Inception Software”, T2300: “Configure Project Management Software”,
CONCUR R1201
6
T2400: “Configure Specification Software” so that the applications can take benefit from
subsequent advanced data exchange (WP3: “Process and Application Integration”).
Figure 3.1 Inception data flow in design process at tendering phase (Software under
consideration during mid term review)
3.2
Design model
The design model extends the outline, which has been described in the inception part of the
process 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.
Spatial requirements are based on the primary processes, which take place in the building.
Processes and business functions are needed to enable spatial requirements to be derived.
Building elements denote the physical constituent elements of a building. Two types of relations
may exits between building elements: (1) composition or “has-a” relation and (2) specialisation
or “is-a-type-of” relation. The former relation denotes the real breakdown of the building into
elements. The second relation denotes each decision to be taken in the design process. Selecting
a type-of foundation is an explicit design decision based on existing and present information,
CONCUR R1201
7
such as soil condition, height of building, function of the building. Information to this purpose
must therefore be present in the design model.
The design model builds upon existing and emerging data standards. The approach adapted
closely relates to the IAI IFC 1.5 development and similar standards such as STEP AP221
(“Functional data and their schematic representation for process plant“), AP225 (“Building
elements using explicit shape representation), AP227 (“Plant Spatial Configuration“). For those
areas which are not supported we have modeled additions to the IAI IFC 1.5 thereby taking into
account the way the concepts of the complete 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.
4.
Object of interest and ontology
Information is used to communicate. To enable electronic communication one need to identify
the information used and needed to be communicated. During the process modelling activities
some information modelling has already been done: globally identifying what information is
needed and what information 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.
4.1
CONCUR 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 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 CONCURS will be able to compose its
information model and use tools available for and associated with the models, e.g. AP221, IAA
IFC 1.5, and AP225.
Figure 4.1 shows the top level of the objects of interest, which have been agreed by the
practitioners. The complete EXPRESS-G diagram also shows relations to IAI IFC 1.5 elements.
8
CONCUR R1201
Superstructure
containsSystems S[1:?]
ExternalEnvelope
System
StructuralSystem
RoofSystem
(ABS)
System
InternalSpace
System
InternalSpace
DividingSystem
ExternalSpace
System
ExternalSpace
DividingSystem
9,1
BuildingServicesSystem
containsFacadeAssembliesS[1:?]
containsSegments S[1:?]
containsDividers S[1:?]containsGroups S[1:?]containsDividers S[1:?]
containsStructuralAssembliesS[1:?]
4,1
StructuralSubAssembly
7,1
FacadeSubAssembly
2,1
RoofSegment
8,1
InternalDivider
3,1
ExternalSpaceGroup
6,1
ExternalDivider
containsInterconnections S[1:?]
containsGroups S[1:?]
5,1
InternalSpaceGroup
5,2
Interconnection
Figure 4.1: CONCUR High level objects of interests
4.2
CONCUR Meta Model
Adding more structure to the CONCUR OOIs 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 OOIs can be
identified. Besides "part-of" for decomposition, "is-a" for subtypes, "connects" for connectivity is
added and "role" to denote specific views and uses of objects. From these considerations the
following core of meta-model was derived.
Subtype
unique
Identification
Part-of
CONCUR_
Data_Item
Connects
CONCUR_
Object
relates S[2:?]
CONCUR_
Relation
Figure 4.2: Core of a CONCUR meta model [Frits Tolman et. al.]
Role-of
9
CONCUR R1201
4.3
Functional unit - technical solution decomposition
The General Architectural Reference Model described in [Frits Tolman et. al.] 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.
4.4
Global model
Because of practical reasons of the CONCUR project the information was 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. The principle is shown in Fig. 4.3.
First of all the approach was to derive performance specifications based on the spatial needs of a
prospect. Second there was the translation of spaces into more substantial building elements.
Third the building services were determined and their capacities noted. Fourth the types of
finishes of building elements and spaces were collected. Each collection step includes resources
required, work methods needed and cost derived.
STABU
CI/SfB
UNICLASS
KKS
A Project
standard
Classification
System
Project Specific
Reference System
Office
Ward
Turbine Hall
Services void
Floor 6
Zone A
Room 9
East Wing
Function
Location
Conceptual
Space
X,Y,Z
IFC/STEP
Position
contains
Geometry
Volume
Area
Capacity
Figure 4.3: Global model of project information
5.
Aspects and attributes
5.1
Information 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 objects 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.
CONCUR R1201
10
Definition of the relevant aspects of interest of the objects is one step in the overall modelling
process, and it serves the scooping of the modelling by providing some hints on what type of
properties of the objects should be included in the product data model.
The following addresses several aspects we may be interested in. The definitive list is under
construction and will be reviewed shortly.
The main aspects of information are derived from the business process, which specifies that the
product cost and value to the client are the main outputs of the process. These are critical aspects
for a project developer.
The value is derived from the product’s specification and availability e.g. delivery time. The
costs are derived from the size and terms of investment involved and the maintenance and
operating costs. Both value and cost are thus dependent on the product specifications, on the
production costs and the production time. Thus, the product description, the production cost and
production time, are the basic information outputs needed.
Looking at cost one is only interested in quantities and unit cost to be able to calculate a price for
the facility. This is true at any point in time in a project, irrespective of the level of detail of
available information. The level of detail leads to a change in type of quantities and unit cost.
Finishes are not priced individually at first but are part of the square meter price for office space.
The actual cost estimates associated with the product and its realisation will be determined
during the process. Deriving more accurate cost figures does not follow from increased
knowledge. The set cost boundaries work as a balance. They imply that an increase in e.g. design
complexity, which in turn will lead to a change in price, is followed by a balancing act: choosing
a lesser price of material or supplier to decrease the total cost.
Several aspects, besides time and cost, can be derived from looking at a building from the
associated viewpoints and in accordance to set requirements, e.g.: legislation, aesthetics,
strength, safety, comfort, buildability, and environmental impact. In the end the attributes contain
the actual information values. Combining and grouping attributes provides the reader with the
actual information he or she seeks.
Aspects are topics like strength and stiffness, safety, economics, etc. They can be viewed as
denoting categories of attributes, i.e. the actual measurable information. What aspects are
relevant to CONCUR depends on the importance of the aspect in the tendering process.
Important aspects relate to the interaction between various disciplines involved in specifying,
designing and constructing a technical building. Each partners have their own main interest
focused in their role in the CONCUR demonstration. Appendix A Shows aspects of inception
information from Fortum Engineering.
The attributes are limited for the moment to the following categories: functions, characteristics
and quantities; these are briefly discussed below. Another category, which remains to be done, is
about functions.
5.2
Functions
Functions describe the (possible) involvement of an object in its environment. A function
specifies what contribution will be expected from the object, which role it has to play, what kind
CONCUR R1201
11
of task it has to fulfil. A function in itself cannot be quantified, and is therefore always
descriptive.
Functions are organised in three levels: function categories, functions and detailed functions.
This hierarchy is only meant to provide some structure. The detailed functions, on the lowest
level, may actually occur in specifications.
Functions are identified by name only; the function content has to be added. In project
specifications functions will be placed in a context: the environment in which they operate. The
function content is on the one hand related to the performing object, and on the other to the user
action or process in which it is involved. For example, one of the functions is Electricity supply.
This function could be related to a building (the building needs electricity), as well as to a single
room in that building (the room has electricity outlets), or to a whole complex or plant (e.g. by
means of a power station). Also, the function could be specified for the main energy supply, as
well as for a standby supply. Thus, the function Electricity supply has to be related to the object
building, or room, or plant, as well as to the process of either main or secondary energy supply.
Another example, which shows the dependency of a user activity more clearly, is the space
providing functions. If the space has to accommodate a user action, then the user action actually
provides the space requirements, i.e. the consumption of space. A power plant as a whole has
space requirements, and so has the user activity of sitting. A space could also be required to
accommodate other objects, e.g. the opening in a wall object would be a space (from the wall's
point of view) to accommodate a window. Also this wall could embody pipelines, outlets and
other stuff, which (again from the wall's point of view) would be reserved space.
The specification of a function may imply other functions, e.g. an accommodation for sports
includes spaces to accommodate sitting.
5.3
Characteristics
Characteristics describe the object itself and its behaviour. Basically a characteristic can be
quantified, which means that a characteristic should be related to a quantity (see below).
The list of characteristics is organized in categories. So far, there are four categories:
Composition, Load/Input/Output, Performance and Property. A characteristic may occur in
several categories, so categories should not be interpreted as a hierarchy, but more as aspects.
Composition not only comprises the physical structure, but also logical ones, like 'Signal-to-noise
ratio' and 'Relative humidity'. In general, composition is a set of references to other objects.
Load/Input/Output are characteristics that may come from, or sent to the environment. This
context should be made explicit in the specification. For example a Floor has a Load to carry,
this Load will then be transferred to other objects in turn. As another example, a luminary needs
electricity as input, which it will transfer into light as an output. In this case both input and output
are distinct, relevant characteristics.
Performance is interpreted here as a (required) capability, which would be needed for the
fulfilment of a function (see above). A performance is triggered by its function: a luminary is
capable of providing light, but it only does so when switched on.
A Property is a characteristic 'proper' to the object. The set of properties is responsible for the
performance (and thus for the functionality) of the object. A number of properties could be
interpreted as performance as well; in this case they are listed both as a property and a
CONCUR R1201
12
performance. For example an object could be 'damp proof', which would be a property, but a
certain level of 'dampproofness' may also be regarded as a required performance.
Characteristics are for a large part extracted from the Glossary of building and civil engineering
terms (BSI). Other characteristics come from the STABU system, (hopefully correctly) translated
into English.
5.4
Quantities
Quantities are basically based on the SI units. They are maintained in STABU system currently in
Dutch and to be replaced by the international version in due time. A number of quantity types are
needed in addition to SI; most of these are basically the same as the SI quantity, but more
specific.
Quantity types are used to give values to characteristics.
5.5
User actions and processes
For Built Objects, user actions and processes are their 'reason of existence'. Generally, user
actions and processes require Space (for which the accommodation function is introduced
above), which space requirement is then translated into Built Objects.
User actions and processes are anticipated to quantify the related space requirements. The list is
not yet ready however. It is end users interest after CONCUR project to continue to list basic
(human) activities, like active or passive sitting, standing, lying down, etc., as well as complex
actions and processes like conferencing, sports, and producing electrical power in a power plant.
5.6
Example
First of all, it should be clear that a specification could be given for Built Objects at any level of
decomposition. So, a specification could specify a Power Plant as a whole, or a Turbine Building
as a part of that plant, or a Wall as part of that building, or a Window embodied in that wall, or a
Lintel as part of the wall. However, on whatever level the object may be, it will always be
specified on that level only, with references to an environment (as the higher level) and possibly,
in the other direction, to the first level of decomposition. So, in order to find the specification of
the Lintel, starting at the level of Power Plant, you have to traverse the tree from level to level:
Power Plant -> Building -> Wall -> Lintel.
A specification has two parts: the first part describing the 'abstract' object in its environment (the
Functional Concept, or FC) and an optional second part (the Solution Concept, or SC) describing
the object's composition and properties. For one FC there are normally a number of possible SCs,
but ultimately in a project only one of these options will be chosen, so at the end a single FC
relates to a single SC. For example specifying its performance, and some shape outlines could
specify a Floor as an FC. A number of SCs could fit that specification: In site cast concrete
floors, prefabricated concrete slab floors, timber floors, etc. Each SC will have its own
specification, with a set of references to the components and a set of characteristics. Ultimately,
one of these solutions will be chosen, in which case the specifications of both types will be
joined.
CONCUR R1201
13
It should be noted, however, that there does not always exist a one-to-many mapping between
FCs and SCs. Frequently a number of SCs may provide the required functionalities of several
FCs ( many-to-many relationship).
Starting at the level of Power Plant, the FC specification of it would generally specify the
required output with regard to its environment. The function of the Power Plant would be:
Electricity supply. This function would then be quantified into a required output of, say, ´100
MWe + 30 MWt´. The output is in the overview of characteristics listed as 'Electrical power +
district heat power'. The SI quantity would be 'watt', so the MWe and MWt -unit has to be added
as an alternative quantity. In the case of the Power Plant 'Electrical and district heat power' have
to be generated, so 'Electricity and district heat generation' would be an implied function of the
Power Plant.
There are a number of SCs for the Power Plant FC, amongst which are: a hydroelectric power
plant, a nuclear power plant and power plants using fossil fuel. Depending of the choice we
would then be able to design and specify the major parts of such a power plant. These parts
would then stand for a new series of FCs.
At some level of decomposition a Turbine building will be specified as an FC. Also we may
encounter at a certain level a 'Standby power installation'. This installation might be necessary to
keep parts of the Power Plant running when the main internal power supply would fail. The FC
specification of this installation could be something like this (note that not all characteristics are
yet in the list):
5.6.1 Standby power installation
Primary power (input)
– Nominal voltage (V): 400/230
– Maximum voltage tolerance (%): +6, -10
– Frequency (Hz): 50
– Maximum frequency tolerance (%): +1, -1
– Supply system: TN-C
Load conditions (output)
– Nominal voltage (V): 400/230
– Maximum voltage tolerance (%): +6, -10
– Frequency (Hz): 50
– Maximum frequency tolerance (%): +1, -1
– Supply system: TN-C-S
– Capacity load (kVA): 100
– Asymmetrical load (%): < 2
– Power factor (cos.fi): 0,8
– Short-circuit capacity (MVA): 100
Operation
– Automatic switch-over to emergency operation after a decrease of voltage (%): > 10
– Change-over time (s): < 15
– Switch back to normal operation: automatic
– Maximum switch-over time (h): > 100
Parallel operation
– Automatic synchronisation
– Lag time (min): > 15
Modes
– Standby
– Emergency
– Bypass
CONCUR R1201
14
Control
– Operation
– Failure
Control interface
– RS 232
Reliability
– MTBF (h): > 150.000
6.
Existing models
CONCUR project has selected IAI´s IFC 1.5 model as a common tool for data repository of
project. The IFC 1.5 schema and Fortum Engineering´s KKS classification system is a basis for
inception data structure – see Appendix A.
7.
Conclusions and Recommendations
These conclusions are made in accordance with [R2201], Configure Inception Software. The
work on this task: “Inception Stage Information Requirements and Modelling” proved, that
international standards are ready enough for the goals presented in CONCUR project. It was
possible to use directly IFC specifications as a basis of product models and as a data exchange
protocol between different applications, which CONCUR partners have.
Work in task 2200 proved that common CAE tools are still not ready to be implemented directly
to support IFC syntax of product models. It was also found to be useful, if software could adapt
better to different IFC versions by reading schemas.
8.
References
[Frits Tolman et. al.], TOLMAN, F., OZSARIYILDIZ, S., VAN RIJN, T. & WOESTENENK, K. 1998. Concur:
integrated processes, software, models and data. CONCURrent Engineering in Building and Civil
Engineering, Brite-EuRam BE96-3016, 02/98
[R1101FI], SERÉN, K.-J. & VÄLIKANGAS, P. 1997. Process model for industrial partner IVO Power
Engineering Ltd. CONCURrent Engineering in Building and Civil Engineering, Brite-EuRam BE96-3016,
R1101FI, 30/06/97
[R1101SE], HOGÅRD, P., BALATON, E. & JÄGBECK, A. 2000. Process models for industrial partners Inception
to Tender Process – AS IS (Skanska). CONCURrent Engineering in Building and Civil Engineering,
Brite-EuRam BE96-3016, R1101SE, 01/03/00
[R1101UK] VAN RIJN, T. & STORER, G. 1997. Process model for industrial partner Taylor Woodrow Inc.
CONCURrent Engineering in Building and Civil Engineering, Brite-EuRam BE96-3016, R1101UK, 25/08/97
[R1102] TOLMAN, F., VAN RIJN, T. & BÖHMS M. 1998. Common process model. CONCURrent Engineering in
Building and Civil Engineering, Brite-EuRam BE96-3016, R1102, 23/11/99
[R2201] VÄLIKANGAS, P. 1999-2001. Configure inception software. CONCURrent Engineering in Building and
Civil Engineering, Brite-EuRam BE96-3016, R2201, 24/01/01