Document A: The relationship between VISI, COINS and IDM

Size: px

Start display at page:

Download "Document A: The relationship between VISI, COINS and IDM"

Randall Bell
6 years ago
Views:

1 Document A: The relationship between VISI, COINS and IDM Contents 1. Introduction VISI concepts COINS IDM - Information Delivery Manual... 5 Process Map... 6 Exchange requirement... 6 Functional Part... 7 Business rules Suggestions for ensuring coherence Introduction In the Netherlands are two standards introduced with respect to process and information in building & construction projects. These standards are named VISI and COINS. VISI is an already implemented standard for management communication in building projects. VISI was created to allow agreements to be made on the process and information that are common ground to two or more partners in building projects. The COINS programme involves the development of a process and information model that will serve as the basis for the integration of the building process and the shared use of data.. There is an internationally active ISO working group that has the task of coming up with a standard that fulfils the above requirements. Its project title is Building Information Models Information Delivery Manual part -1: Methodology and Format (ISO/TC59/SC13/WG08). The working group was set up in November 2006 and aims to have its initial results ready by the end of A representative from COINS is participating in the international working group. Given the common aims, it is important to establish where VISI, COINS and IDM overlap and how they fit together. This document contains an inventory as well as proposals as to how the COINS programme can capitalise on IDM and VISI. 2. VISI concepts VISI is a standard for communication between partners in building projects. The agreements made have bearing on the communication needed to lay down the formalities between partners in a building project, which is termed 'management communication' for example, in order to finalise a request for change or to finalise a payment schedule. VISI is based on the Action Based Communication theory as described by Jan Dietz in his book Enterprise Ontology (Springer 2006). This theory assumes that co-ordination between people follows patterns of characteristic actions, such as: request, promise, state and accept. This pattern is called a transaction. 1

A transaction according to the theory of Action Based Communication The VISI organisation has developed a system using the following concepts: role transaction message message in transaction

2 A transaction according to the theory of Action Based Communication The VISI organisation has developed a system using the following concepts: role transaction message message in transaction information element The VISI system is a formally established one and is available as an Express file or an XSD file. Go to the VISI website for more information on this subject. The communication agreements that VISI has developed are grouped for particular fields of application and each group is called a VISI framework. The framework determines which roles, transactions, messages and information elements apply to the communication in a certain area of application. A VISI framework is laid down formally in an XML file and should follow the rules laid down in the system. 2

3 3-tier model: a VISI framework is based on the VISI system, project communication is based on a VISI framework. An information system that is VISI-compatible can assist communication in accordance with the rules laid down in a VISI framework. The process to which a VISI framework applies, can be depicted as an interaction diagram (see below). The roles are displayed in yellow rectangles (A01 to A06) and the transactions are in between these (T01 to T05). A transaction takes place between two roles. The roles that are connected to a transaction by a circle are the executive roles. A06 Spatial designer T05 3D-Modelling A01 Client delivery T01 A02 Projectdirector T02 railway A03 System Engineer Railway Interaction diagram T03 structures A04 System Engineer Structures More information on VISI can be found in document Document C and Document D. 3. COINS COINS is the acronym for Construction Objects and the INtegration of processes and Systems. The COINS program has the following objectives: To provide agreements on working methods and information needed to support the building process; To provide a common basis for the use of object information and integration of the building process. These agreements enable a better use of resources in information and communication technology (ICT). 3

Approach The COINS-program is carried out by the project group COINS with in this representatives of governments (clients), construction companies, engineering offices, network organisations and

The COINS-program is developing the following products: Agreements on working methods - COINS Engineering Method (CEM) Agreements on information COINS Building Information Model (CBIM) Implementation

4 Approach The COINS-program is carried out by the project group COINS with in this representatives of governments (clients), construction companies, engineering offices, network organisations and institutions (27 participants). Moreover IT-companies are participated (6 participants). The COINS-program is developing the following products: Agreements on working methods - COINS Engineering Method (CEM) Agreements on information COINS Building Information Model (CBIM) Implementation Strategy and methods CEM Working methods for the production of construction work. Do COINS consider then something whole news? No, we make use of recent developments which there are take over already in construction (for example systems engineering) and working methods of other industries. New is that we agreed sector-broad make concerning the application of those working methods, because that is an important first step to reach integration of the construction process. CBIM Building Information Model. For COINS it concerns in particular the terms which are relevant for integration of the construction process; hence that we speak of a Building Information Model. Also for this subject we use maximum of what already is available to standards. An example is the standard Ifc which is available for the engagements of 3Dmodel representation. The next figure gives an overview of CBIM (work in progress!). Object classes that have a central role in the support of the building process are: Function Space 4

5 Physical object 3D Representation Note that COINS has chosen for a explicit product structure that hooks to objects in 3D Representation (in Ifc-format or other standards). The agreement scheme CEM/CBIM for a typical application area is called a COINS framework. Main points for the development of CEM/CBIM are: CEM/CBIM is a framework for process and information CEM/CBIM is a means to make virtual construction possible CEM/CBIM is a means to make process integration possible We strive to keep CEM/CBIM as small as possible and lay the emphasis on that which necessary is for process integration CEM/CBIM will digitally be fixed; the language OWL is used for that aim CEM/CBIM is flexible in the use; it can become used as a stencil key set and are tailored to specific needs CEM/CBIM is developed for application in the primary process in construction as from the first design until demolition, according to a life cycle approach. The COINS-program is now in the developing and application phase. The development exists from theory shaping (CEM/CBIM) followed by reviews of the theory by practice tests. The following practice tests are carried out: RSS/Lunetten: functional specification/design of a railway station BAM: engineering, 3D-objects and quantity take-off IT-partners: engineering and interoperability IBU: functional specification/design of a waste water buffering facility Groningen: concurrent 3D-design of a small bridge More information is provided in Document E. 4. IDM - Information Delivery Manual The idea for IDM came from the IAI buildingsmart organisation and originated from the realisation that an integrated building process requires more than concurring on information models; the process also has to be included. We based this paper on the following document: Building Information Models - Information Delivery Manual - Part 1: Methodology and format, draft STD Version 2.1c2 (not available to the general public). The available documentation describes the goals of the IDM as follows: To provide the integrated reference for process and data required by BIM by identifying the discrete processes undertaken within building construction, the information required for their execution and the results of that activity. It will specify: o where a process fits and why it is relevant o which roles that create, consume and benefit from the information o what information is created and consumed o how the information should be supported with software solutions 5

The IDM came up with the following building blocks to work on the above goals: Process map Exchange requirement Functional part Business rule Process Map The documentation has the following to say

6 The IDM came up with the following building blocks to work on the above goals: Process map Exchange requirement Functional part Business rule Process Map The documentation has the following to say about the process map: A process map describes the flow of activities within the boundaries of a particular topic. The purpose is to help understand how work is undertaken in achieving a well-defined objective. A process map: o has a goal o has specific input o has specific output o uses resources o entails a number of activities that are performed in some order o may affect more than one organisational unit o creates value of some kind for the customer The following diagram depicts a process map. Exchange requirement The second building block is the exchange requirement or simply ER: ER is a set of information that is needed to support a particular business requirement at a particular stage of a project 6

7 For IDM as it is now, the set of information should be defined within the IFC model. However, the IDM approach will also work with sets of information defined within other industry standard models An ER should provide a description of the information in non-technical terms. ERs are read by the users (architect, engineer, constructor, etc.). An ER includes a set of preconditions for activities that must be completed before the execution of the ER in question. (NB: this raises several questions as to the nature of the ERis it an action or a set of information or a combination of both?). Functional Part The third building block is the functional part or FP. A functional part is a unit of information, or a single information idea, used by solution providers to support an exchange requirement. A functional part describes the information in terms of the capabilities required by the industry s standard information model on which it is based. The functional parts of IDM as it is now, are based on versions of the IFC model. A functional part is defined as an information model in its own right, as well as a subset of the information model on which it is based Functional parts describe an action in close detail. Whereas an exchange requirement describes information in non-technical detail, functional parts describe the use of every entity, every attribute, every property set and every property concerned. NB: Here too, the concepts of information and action overlap. Business rules The fourth building block is that of business rules, or just BR. BR describe operations, definitions and constraints that may be applied to a set of data used within a particular process or activity. They enable controls to be applied to: o the use of specific entities, o attributes and properties that must be asserted (or not asserted), o values, ranges of values or value limits that should be observed, o dependencies between entities or attributes or attribute values. The primary goal of business rules specification is to allow an exchange requirement to be modified and tailored to a specific business need. For instance, a generalised exchange requirement may be developed for a particular purpose (e.g. cost modelling at the detailed design stage of a project). Business rules can configure this requirement so that it is locationspecific without having to actually change the schema underlying the exchange requirement. For instance, two different sets of business rules might be applied to a single exchange requirement for e.g.: o cost modelling at the detailed design stage of a project in UK o cost modelling at the detailed design stage of a project in Norway 7

8 5. Suggestions for ensuring coherence VISI is an elegant and efficient concept. Everything that has to do with information technology and presentation has been left out of the standard. By using the concept of 'Role', a communication application can be defined completely separately from a particular organisation. The concepts are neatly defined and separated. The information side is not very structured: (simple and complex) information elements can be combined in messages. Process agreements are formed by defining the transactions between roles. Responsibilities are determined by means of roles linked to transactions. VISI s applicability is proven by many construction projects. While VISI focuses on the Management Process & Information, the scope of COINS is The Object Process & Information. COINS fits neatly to the VISI standard. The process side of the standard is covered by the COINS Engineering Method (CEM), while the information side of the standard is covered by the COINS Building Information Model (CBIM). The standard is currently in development and reviewed by means of practice tests. IDM is still at an early stage of development and its methodology is yet only a draft. The building blocks 'process map', 'exchange requirement' and 'business rule' are logical choices. The 'Functional part' is not clearly defined. The elaboration of the building blocks is unstable and is riddled with detailed document header definitions. IDM is strongly linked to IFC and, hence, dependent on implementation. IDM is based on fixed project stages. On the process side, IDM tends towards a broad scope that may jeopardise feasibility. To date, the following COINS products have been developed: the COINS Engineering Method CEM, en COINS Building Information Model CBIM. For more information, see Document E. How do VISI, IDM and COINS fit in with each other? In view of the above, we have arrived at the following proposals: Link VISI and COINS through a shared use of the 'Role' concept; this has already been implemented. Link VISI and COINS through a shared use of the 'Transaction' concept Make the 'Transaction' concept ready for use by COINS, see the explanation below. Fit the IDM building block 'Exchange requirement' into the ' Transaction' concept. Introduce the VISI concepts 'Role' and 'Transaction' for IDM application. Keep the scope of the application of the 'Process Map' building block as small as possible and limit it to that what is strictly necessary/relevant to attain process integration, which means limiting it to where the roles have interfaces (transaction). Find out to what extent the 'Functional part' building block is necessary. Ensure that the organisation, technology and implementation related aspects are left out of the standard. Explanation: An organisation, department or person involved in the execution of a virtual building process is assigned a certain role. In order to fulfil this role, they must be able to: See the part of the virtual building that is relevant to their role Build within the framework of the competences of their role (remove, change and create). 8

9 This captures the essence of the issue: it should be possible to establish the competences of the executive role by means of the transaction. These competences are related to the information objects that may come up. This is determined in CBIM. It must be possible to limit these competences, for example, only with regard to information objects in a certain state or only building components that are part of a certain assembly or subsystem. We see that the specification of the competences depends on the content applied. One possible solution is for a COINS transaction to contain a message with which the initiator: requests the executive role to build a part of the virtual building specifies the competences of the executive roles indicates what applies to which selections of objects. Those competences that have been given away in this manner must be retraced in the information system. The good thing about this solution is that you can define boundaries with respect to the information that is structured according to CBIM; within these boundaries there is still a great deal of freedom! The process map comes back because of the application of roles and transactions. The exchange requirement has taken a very simple shape. One of the questions that remains is what is to be done with the 'business rules'. The following diagram shows how the concepts fit together. A06 Spatial designer References to information objects Selections T05 3D-Modelling Authorisations Business rules A01 Client delivery T01 A02 Projectdirector T02 railway A03 System Engineer Railway T03 structures A04 System Engineer Structures Virtual Building According to CBIM End 9

BIM Standardization in ISO

Presentation by Tatsuo Terai at ACIT2008 in Beijing 19/20 Oct 2008 BIM Standardization in ISO Building Information Models Information Delivery Manual Part 1: Methodology and format ISO TC 59/SC 13 Date: