Key Tasks of Process Modeling

21 

3.3 Key Tasks of Process Modeling

With the Blue-Green requirements prepared, a workflow manual is needed to describe the collaboration interface and process. This research uses two concepts describing below to support the workflow manual.

In the building design process proposed in the Figure 3-2-2, it requires Common Data Environment (CDE) as a working environment to support design collaboration.

There are four phases of CDE [65]. In the CDE, a lead designer of the project will coordinate the collaboration process [66]. The first task team is usually architect team.

The architect team will form an initial BIM project model in the “Work in progress”

folder. After the initial BIM project model is checked by the lead designer, it can be uploaded to “Shared” folder to be shared among the project teams. The rest task teams such as landscape architect team, structural engineer team, mechanical engineer team, electrical engineer team, and plumbing engineer team can reference the initial BIM project model as a foundation to develop the content of the model. The lead designer will also check, review and approve the coordinated models before it is uploaded to

“Shared” folder. When it comes to the end of design stage or the project milestone, employer will authorize the BIM project model and the corresponding design documents to be published in “Published documentation” folder. Besides, the “Archive”

folder is used to record the history data of the project information at each project milestone. The CDE is an iterative process repeating above steps.

For supporting the business requirement, there is an open data format of BIM model called Industry Foundation Class (IFC) [67] designed to support all the business requirement for all project stages. In general, it is feasible to exchange information under particular business requirement during design stage [68].

Therefore, Information Delivery Manual (IDM) is a document to support the BIM

use, and the project stakeholders can use to clarify the collaboration interface and process [69]. There are international standards [70][71] to define the methodology in formulating an IDM, and there are four components of IDM listed in Table 3-3-1. For the use of IDM is not only for supporting the business requirement but also developing the software solution, there exists barriers in mapping the relationship between Process Maps, Exchange Requirements, Functional Parts and Model View Definition (MVD) which is a is a subset of IFC for particular BIM use [72][73].

In order to apply the concept of CDE and IDM to formulate a workflow manual for the Blue-Green design, there are two modeling key tasks shown below.

(1) Clarify the expected workflow and information exchange for the design and analysis process

In modeling the design process, it requires experienced consultants or designers to outline the work items for the specific design stage. The requirement identification of the Blue-Green design, the use of the BIM element models of the Blue-Green design and the customized design tool should be considered as the work items. The corresponding workflow is composed by arranging the work items and relationship between each character in the project. The structure of the workflow is developed under CDE collaboration concept. Therefore, the information exchange is clarified according to the work items in the workflow.

doi:10.6342/NTU201803891

23 

(2) Document the information using Process Maps and Exchange Requirements

For taking the advantage of IDM methodology, Process Maps and Exchange Requirements are used to describe expected workflow and information exchange in formal document. In creating the Process Maps, the expected workflow is illustrated in Business Process Model and Notation (BPMN) [74] format. The Exchange Requirements is formulated according to the Process Maps. It is suggested to reference existing Process Maps and Exchange Requirements in published IDM to shorten this process of documentation. Because the process modeling only focuses on satisfying the business requirement, developing IFC compatible software solution is not considered. The outcome of the workflow manual is composed of Process Maps and Exchange Requirements.

Table 3-3-1. The primary components of IDM [68]

IDM elements Descriptions

Process Maps A process map describes the flow of activities within the boundary of a particular topic.

The purpose of a process map is to gain an understanding of the configuration of activities that make it work, the actors involved, the information required, consumed and produced.

Exchange Requirements

An exchange requirement is a set of information that needs to be exchanged to support a particular business requirement at a particular stage of a project.

Typically, for IDM as presently established, 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 such as the Geographic Markup Language (GML) as defined by the Open Geospatial Consortium (OGC).

An exchange requirement is intended to provide a description of the information in non-technical terms. The principal audience for an exchange requirement is the user (architect, engineer, constructor etc.). It should however also be used by the solution provider since it provides the key to the technical detail that enables the solution to be provided.

Functional Parts

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 required capabilities of the industry standard information model upon which it is based. For IDM as presently established, the functional parts are based on versions of the IFC model.

A functional part is fully described as an information model in its own right as well as being a subset of the information model on which it is based.

Concepts A concept is a fragment of information that can be used in a functional part (where it is bound to a release of the IFC model) or to an exchange requirement (where it is expressed in generic terms). It can be used to capture the basic functionalities within a model such as naming, identification etc. A concept does not need to be simply related to a single entity or even to a whole entity. For instance, the concept of a software identifier simply describes how a globally unique identifier attribute is asserted for an entity.

doi:10.6342/NTU201803891

25