Background

The IAI’s approach

“IAI (International Alliance for Interoperability) is an alliance of organizations within the construction and facilities management industries dedicated to improving processes within the industry through defining the use and sharing of information.”

This organization founded in 1995 has specified, over the years, a product model (IFC Industry Foundation Classes) that reached its first maturity level in 1999 with its 2.0 release. Nowadays, with the release 2x edition 2, it should become a de-facto standard in the AEC/FM industry.

The IFC model scope is large: it contains enough concepts to exchange any information over the building industry chain of processes and this in the fields of architecture design, engineering, scheduling, cost estimation, manufacturing, construction management, facility management, HVAC, etc …

The IAI’s goal is that these specifications would support software implementation by multiple vendors, such that the software of these vendors could exchange and interoperate on a commonly understood data model of a building project.

But as the time went by, the IFC model scope has increased and increased without being really used or at least experimented in real project exchanges. Only implementation – endorsed by IAI – of CAD vendors have been so far experimented and certified.

This is the paradox that IAI is now facing: how to make this huge model implemented and used in real projects?

The BLIS project, a pragmatic step forward

In 1999, after the IFC R2.0 release, a small group of IAI members has realized that modeling was not the only answer to the problem of interoperability and decided to not wait for the ‘perfect’ model to start adopting it in real AEC/FM projects.

The BLIS project (Building Lifecycle Interoperable Software) was formed on the voluntary initiative of a group constituted by software vendors, end users and research institute.

BLIS members, nowadays in the range of 80, have agreed to concentrate on the definition, the implementation and the use of pragmatic subsets of the IFC model. The aim is to support, as far as possible, software vendors in implementation and shipping tasks and end-users in their daily process using the software.

For that, the BLIS project has introduced the notions of concepts and views designed to support the following use cases:

• Design <-> Design (geometry view)
• Client briefing/space planning ->Architectural design
• Architectural design <-> HVAC design
• Arch/HVAC Design -> Quantities take off / cost estimating
• Arch/HVAC Design -> Thermal load calculations / HVAC system design
• Arch/HVAC Design -> Construction management/scheduling

Quickly in 2000, the success of the BLIS demonstrations around the world has proven and confirmed this pragmatic approach and leads in 2001 to the recognition of the BLIS group as a crucial entity for the interoperability in the AEC/FM domains.

In 2001, the BLIS project has certified 13 software products from 13 different organizations for 3 different views and should in October 2002 certify 5 more organizations.

Thanks to the BLIS project, the AEC/FM world has set up is mind on the interoperability idea and while IAI is still modeling a new IFC release it can rely on the fact that some people at least are taking care of the real uses cases and problems in this industry through different pilot projects.

The IMSVR project

Starting from the different experiences of IAI and BLIS, VTT (Finland) and SECOM, Inc (Japan) have endorsed the elaboration of a model server framework IMSVR (IFC Model Server) for storing IFC object model within a database system and running on the internet.

Without this kind of model server functionality, sharing of IFC data by IFC compatible applications would be limited to file base exchanges.

Thanks to this model server functionality provided on the internet, IFC compatible applications can communicate with each other via the internet and utilize functions implemented in the model server such as partial model import / export.

The future plan development of this project is to provide a wide variety of Web Service functions, i.e. scheduling doors windows, external library data merger into IFC model with property set system, VRML converter, and so on.

Using today standard Internet technology (SOAP, XML, Database) this project is de facto extensible and scalable.

But what is a server without any client?

This is exactly to this question that the present project is trying to facilitate.

Project Objectives

This project proposal deals with the definition, the development and the implementation of a simple AEC-domain specific language to communicate with IFC model servers.

This language, called interface, aims to:

• Be AEC-domain specific,
• Be defined using standard technology
• Be free to use
• Facilitate the access to IFC model servers from a client application whatever the technology used by this application

The realizations of this project will be:

• Domain Specific Web services
  • Architecture Design Web Service (ADWS)
  • Space Planning Web Service (SPWS)
  • HVAC Design Web Service (HDWS)
  • Construction Management Web Service (CMWS)
  • Thermal Load Calculation Web Service (TLCWS)
  • Quantity take-off Web Service (QTOWS)
  • Cost Estimation Web Service (CEWS)
  • Facility Management Web Service (FMWS)
    
• Domain Specific Libraries for facilitating the implementation for client side applications (Optional)
  • Architecture Design Java API (ADJAPI)
  • Architecture Design C++ API (ADCAPI)
  • Architecture Design .NET API (ADVBAPI)
  • Space Planning Java API (SPJAPI)
  • Space Planning C++ API (SPJAPI)
  • Space Planning .NET API (SPJAPI)
  • …

The priority with which the development of these interfaces and web services will be made, is strongly dependent on the priority of the industrial partners commitments in the first place.

The SABLE Framework proposed Architecture

Copyright © 2002-2004, BLIS-Project [BLIS Registered Organization].