IDM ; Makes IFC work!

Content

• Executive Summary
• IDM - Background
  • The components of IDM
• Methodology
  • Definitions
  • Making Process Map
  • Making ER
  • Making FP
  • Model View Definitions
    • Standardization of IDM
• Impact
  • The role of IAI
  • Road map for IFC IDM
  • Examples
• References

Executive Summary

IDM is for use in the AECFM business process. It specifies what the process is and its purpose, who are the creating and consuming actors and what is the information created and consumed. It is contracted data interchange.

IDM enables us to see information as an asset, regulate the information sharing between project participants and improve information quality. The IDM method allows projects to become information-centric. This will improve decision making and enable us to do a BIM project. IDM makes IFC work!

To give the users of BIM and the SW vendors a quality assured list of IDM to pick from, international and national standardization of IDM is suggested.

IDM - Background

The Building Information Modeling (BIM) is able to bring together the different threads of information used in the lifetime of a building.

To use BIM effectively however, and to enable realization of the benefits to be released, the quality of communication between the different participants in the construction process needs to be improved. If the information needed is available when it is needed, and the quality of that information is appropriate, then the construction process can be improved.

With requirements from the building and FM process, IDM is set out to define the key points or transactions, at which exchanges of information occur, identify the data in these transactions, specify how an application should share data in the transaction, and then allow applications to apply their user guidance as a response.

The IDM will grow progressively to provide a comprehensive reference to the processes that may be executed within building construction. From this reference list, end users will be able to specify those that are relevant to the needs of their specific project and, in so doing, will specify the information that needs to be communicated between the various participants.

In IDM, each process will be described individually and each description will be in three parts; the first part defines the process, the second part being non technical targeted towards the BIM user whilst the third part will be technical and focused on the BIM software developer.

The components of IDM are:

PM - Process Map
Gives an overview of the process, describing its objective and describes the stages in a project at which the business process is expected to be relevant. It also identifies all the sub processes.

ER - Exchange Requirement
A non technical description of the information required as input to the process and the expected source of that information together with a description of the expected results of the process; the output. Each requirement for information exchange is described individually.

FP - Functional Part
A description of the technical actions within the process mainly targeted towards the SW implementers. This again leads to the specific IFC capabilities supporting the actions and prescribed values of attributes where appropriate. The FP can be supported by an IFC schema view for the process (in EXPRESS, ifcXML and other formats). For solution providers, descriptions of IFC capabilities will also be developed for reusable 'functional parts' which are commonly occurring sets of data that may be used by any number of processes/ER's. FP gives the background for answering the questions of what data that is needed in a specific case for generating Model View Definition. On the basis of this, SW will certify to provide content that is captured using the model view definition format.

IDM offers substantial benefit to BIM users and solution providers including:

• regulates information flow between processes and between participants
• improve information quality within processes
• supports decision making through guaranteed information availability and quality
• supports more reliable and effective IFC support in software solutions
• allows more effective BIM use
• Makes IFC work!

Methodology

IDM is focusing on the business processes in the AEC/FM industry. Through the components Process Model (PM), Exchange Requirement (ER) and Functional Parts (FP) business processes are identified, described and specified in order to meet the needs from participants in the AEC/FM project lifecycle. Participants can be executive users, project managers, designers, facility managers, solution providers of software or others.

Making an IDM will typically start by defining a PM. Then specify the defined ER's and the belonging FP's.

The main goal for the PM is to

• Identify in which project stages (e.g outline design, full conceptual design, coordinated design etc) of the process there are exchange of information for this business process. E.g. a business process can be electrical engineering or energy analysis.
• Identify all the ER's for this business process. ER's can also be independent of ifc (e.g. local/national standards, building regulations etc), this will typically be input to the process.
• Identify the purpose of the business process and sub-processes
• Identify the result of execution of the processes - output

A PM can typically be "broken down" to a sufficient level of detail. E.g. 4-digit level where the overall PM covering all stages is 1-digit, stage is 2-digit, tasks in this stage is 3-digits and subtask underneath is 4-digits. The PM will contain a description of each stage/ER/activity/task.

The main goals for ER's are to:

• Identify what information a specific business process needs from which to start (input - can be the result from another business process/PM)
• Describes the information that must be passed from a business process to enable another to happen
• Identify the actors sending and receiving information within the process by role
• Identify when information exchange must happen
• Identify a table of information units needed to satisfy the requirement (other ER's and FP's)
• Defines whether use of the unit is mandatory or optional for the exchange requirement
• Specify the functional part that satisfies the information unit

An ER is typically unique within a project stage. However in many cases the business process has a cyclical sequence between project stages. Essentially, it is the degree of detail of information and the decomposition of elements from speculative into more specific types that changes from stage to stage. For each stage, the process follows the task sequence design ? model ? coordinate ? analyze.

ER's and PM's are not independent of each other. It is therefore essential that they are coordinated to serve the complete project.

The FP's:

• Describes the actions that are carried out within a business process to provide the resulting output information
• Are reusable and may be used by many exchange requirements
• Can be broken down into other functional parts
• Specifies other functional parts that are used
• Identifies IFC entities, attributes, property sets and properties required
• The value of attributes (either within the current or a used functional part) that may be set or constrained to meet particular needs

Definitions

Making Process Map

The Process Maps provides a description of an activity (or set of activities) related to a domain in the AEC/FM industry. Examples are Energy Analysis or Cost Modeling. Each of these activities is described from a process perspective using Business Process Modeling Notation BPMN as well as textual description of these processes. Discipline experts are defining the process maps.

Making ER

To set the exchange requirement you need to fix stages, describe overview and define actions. For each action you need to describe action, specify properties, assert mandatory or optional, set required values and at the end identify functional part. Actions are carried out to either set the value of an item of information (data) or change an existing value.

An ER captures the role of actors performing the action, providing the input and benefiting from the output. The target of an ER is the resulting output information. It is a set of information that can be exchanged and it is NOT the process. An exchange requirement has a name that describes its intent e.g. exchange_building_model and is defined by discipline experts.

The sections with an exchange requirement are:

• header that identifies the exchange requirement name, creator and the project stages for which the requirement is used
• overview that states the aims and content of the requirement in non technical text form. Overview is intended to be understood by an executive/end user
• technical description that identifies a table of information units needed to satisfy the requirement (e.g. project, wall, window etc.)

Each information unit provides a breakdown of the detailed data within the part and shows the value(s) of attributes that may be set or constrained. It defines whether use of the part is mandatory or optional for the exchange requirement and indicates the actor supplying the information (by role, not discipline). The information unit specifies the functional part that satisfies the information unit.

There may be several results from an exchange requirement. Results may be classified by type. e.g. model, document, exchange requirement, specification etc. The results identify:

• the information provided
• whether mandatory or optional
• intended receiving actor(s) by role
• identifier (e.g. specification reference)

Making FP

Model View Definitions

The Model View Definition is the IAI mechanism to certify SW to support the IDMs. Components of MVD are:

• Format: The type of data that needs to be captured and how that data is structured
• Content: The data that is needed in a specific case. For example the IFC Schema is content that is captured using the EXPRESS format and an IFC Model View Definition is content that is captured using the IFC Model View Definition format.
• Process: The roles and responsibilities of different involved parties, for example how a model view definition becomes official and how certification is organized.
• Tools: The tools used for creating content, e.g. Process Maps and Exchange Requirements, and managing the process of creating content. Tools are highly important, but the format itself must be independent from any specific tools.

In the content creation the goal has been set to "finding a useful balance between the wishes of users/customers and the possibilities of software developers, and documenting the outcome clearly." The model view definition format is used for documenting this outcome for the SW developers.

Model View Definitions and IDM

One of the ideas to the IDM is that software should be certified in order to meet the needs in business processes in the AEC/FM industry i.e. the IDM also got a certification aspect to it.
The MVD typically handles exchange of information from one type of application to another (e.g. from architectural- to structural design). In IDM this would be equal to one ER in the PM_Building_Modelling. This ER would be a sub result in this PM (output). The same ER will occur in the PM_Structural_Design as an "input ER".

This is one example of an ER/sub result from the PM_Building_Modelling. Others will be similar to architectural
- to electrical design, architectural- to HVAC design and architectural
- to energy analysis. In this way IDM handles different ER's for different purposes and different disciplines, and are therefore dependent of certification for several MVD. This might be a bit much to ask from implementers as of today, but it's not only important what SW CAN handle, it's also important what SW CAN NOT handle. Taking the holistic view where "all" business processes are handled in one BIM, it does not help the overall project much if the architect's application can fulfill only the "architectural to structural" view. Who is benefiting from that apart from the structural engineer? The software can still be IFC certified...

PMs are not independent of each other, similar to business processes in "real life", and must therefore be coordinated so the needed ERs are produced to serve also other ERs in other business processes.

As previously mentioned the business process often has a cyclical sequence between project stages, what separates them is the level of detail. This means that if an application can handle an ER in e.g. the coordinated design stage, the chances of the application supporting "the same" less detailed ERs in earlier stages are high.

This indicates that one ER can be defined as a view. Alternatively two or more ERs can be grouped (configured) into a view. This will increase the number of views, but it will make it easier to be certified for smaller business processes/activities. It will also communicate more exact what information exchanges the applications supports (e.g. application "shovel" support "ER_digging_soil" and "ER_digging_snow", but it doesn't support any other ERs).

The MVD is based on concepts in the lower technical level to identify entities, attributes, property sets and properties required to support a view. In IDM we have FP for the same purpose. To be able to define an ER as a view in this setting, it is necessary that FPs and concepts can express the exact same configuration.

Standardization of IDM

The IFC Model Specification is an international standard and construction activity is by nature local. Somewhere between these two levels a transition from international to local has to take place. Software is increasingly international and IDM and IFC Model View Definitions, are by this logic also international. Software is also localized to specific markets and country specific regulations and there is still a large number of purely local software. Exchange Requirements are much closer to local processes, including design contracts, but contain many universal elements. A standardization of IDMs is to give the users of BIM a set of quality assured IDMs to pick from when modeling the localized company or project specific building or FM process. The standardization needs therefore to be both at the international level, with a core of international acceptable contracts of data interchange, and at the national level, where national requirements will be built into the set of IDMs.

Impact

The IDM can be seen as an element in a move towards a more extensive use of IFC related technology. Most of the components of this exist as development ideas. The components are perceived as:

• The IFC information model
• The IFD dictionary model
• The IDM contracted data interchange
• The MVD model view definition for SW certification
• The Process Matrix (and similar efforts)
• Enterprise models

The role of IAI

This needs to be specified by IAI.

Additionally, the IDM will provide an improved methodology for development of future extensions to the IFC model that will include close descriptions of business requirements and IFC support so as to support accelerated implementation.

Road map for IFC IDM

IDM and deployment of IFC is not a new idea to the IAI, since the IAI in the beginning relied on the work of domain teams for defining the scope of the IFC Model Specification. The work of these domain teams is best captured in volume 1 of the IFC R2.0 documentation. Because IDM needs to reflect the "real projects" at an international level, there is need for a road map for the work.

The road map needs to answer the questions:

• Where are we today? Already developed IDMs or other contracts regarding data interchange should be documented using the official IDM methodology.
• How can we make the most out of the existing possibilities?
• What are the ultimate possibilities of IDM? This is a forward looking generation of IDM, which require changes to the building and FM processes, existing software and/or the current IFC model.

Examples

Examples are to be found at http://idm.buildingsmart.no

References

IAI Nordic Chapter, Norway, www.buildingsmart.no
AutoDesk, http://www.autodesk.com/apac_sapac_main/files/4525079_BIM_A_Key_to_Performance-Based_Design.pdf
OpenGroup, http://www.opengroup.org/oboe/Objectives.html
AEC3 Ltd. UK, www.aec3.com
"Vol. 1 AEC/FM Processes Supported by IFC", IFC R2.0 Member CD (See, 1999)