Cib 2004: wednesday afternoon¶

The afternoon session. Ghang Lee (georgia tech): implementing 3D parametric modelling in technical areas of construction

The work was done in the PCSC, precast concrete software consortium.

The steel industry had a couple of good implementations and standards, which were the envy of the concrete industry. They were still using 2D instead of the nice 3D from the steel boys.

So they started developing a parametric 3D model plus supporting application. They did it in a 6-month development period, mainly via the internet. The project should be finished by october 2004.

More info

Seok-Joon You (georgia tech): relational database implementation of STEP-based product model

There are basically two choices when dealing with a STEP-based product model: using a STEP database or rolling out your own solution. Strengths of STEP dabases include:

• support of workflow
• incremental update of data
• concurrency control
• change management

STEP is good as long as you have only one (big, central) model.

Choice of database

Many STEP applications use an STEP objectdatabase like ObjectStore. It is easier to translate from STEP data and there is a claim of better performance. A downside is that there is no sophisticated query language.

As an alternative (chosen here) you can use a normal relational database (here: microsoft SQL server). It is compatible to most existing systems and you can use the powerful SQL language for queries. A drawback is that it is harder to translate to/from STEP. Possibly there is also less performance.

The choice they made was to implement their STEP model (the steel industry's CIS/2) in MSSQL. Rest of the info is in the paper.

Thomas Froese: integration approach for developing AEC/FM total project systems

(Just a note: AEC is "architecture, engineering, construction" and FM is "facilities management", just for those that don't know)

The work was done in the ITAC project (Information Technology for Aec in Canada). They focused on project gaps: inefficiencies in the communication within a project.

At least conceptually, they take a central datastore as the beginning. In practice, there is nothing really wrong with it being distributed in one way or another. (I liked it that he said so. I'm a bit allergic to a cental datastore. Of course there is nothing wrong to just use it as a conceptual idea while leaving the technical implementation open).

Challenges:

• There is lack of data standards.
• There is a lot of unstructured information (plain documents, binary image files, drawings in closed formats, etc.)
• Etcetera.

This paper's focus is on the "systems" level, so: frameworks.

• Shared project information repository
• Open, modular
• Supports various kinds of integration, data, processes, etc.

In the project they made a few programs to access a generalised data store. With a generalised data store they meant that they had defined a generic API to access project data. It looked OK, there was even a specification prototype implemented using Autocad

(Only: why? A generalised data store access method. Eeek. Isn't that what they invented http and the internet for? http://someprojectserver.com/project_one/specification/front_section? Can't get much more generic than that!)

Conclusions

• Industry is now facing a paradigm shift towards integration.
• Proposed framework is generic and flexible (and it was succesfully applied).
• Project information reuse and tool integration will help.
• A strategy to transfer the framework to the industry should address the non-technical issues (like acceptance).

Kwok K. Yum (csiro, Australia)): partial model exchange between data owners

His talk was interesting, but mostly graphical, so I won't write too much about it here. His talk was about exchanging parts of an IFC file. For instance, an architect that communicates the walls etcetera to an intallation technician.

From the conclusions: the digital quality requirements increase after adoption of a Building Information Model (BIM, as they nowadays seem to call IFC-like model-based systems). Also, practicioners must practice demarcating responsibility and liability.

Thomas Ng (university of Hong Kong): a fuzzy procurement selection decision support tool for construction

Note: he meant the procurement of a project as a whole, not the procurement of individual projects. So he meant a selection support tool for the selection of contract types.

The selection of a proper contract type can be hard. you need to keep in mind the newness of certain types to the client. Also there might be lack of clear criteria.

The selection criteria are often fuzzy ("a bit complex"). So, he implemented a neural-network-like solution that results in a recommendation for a specific contract type.

Alan Russell (university of british columbia, canada): using multiple views to model construction

The motivation was finding out how to design a decision support system of sufficient width and depth to be useful. For this to work, there was a need for a new way of thinking: the management of a project by using abstracted multi-view views of a project. Examples of views include:

• Physical view: what is to be build, site content.
• Cost view: what costs how much.
• Change view: what changed, why and how.

On representatioon of the views: what is the minimal data set for maximal functionality.

A contractor hates to start with a blank piece of paper. The last project's basic info will be quite alright as a basis for the new one, thank you! (There was a contractor in the room who started to nod violently in support of this :-)

One of the three conclusions: A multi-view representation of a construction project has the potential to support a much broader range of management functions than currently supported by state-of-the-art tools.