-return to main page - previous page - next page -
What is an IFC
The intention of the IAI is to specify how the 'things' that could occur in a constructed facility (including real things such as doors, walls, fans, etc. and abstract concepts such as space, organization, process etc.) should be represented electronically. These specifications represent a data structure supporting an electronic project model useful in sharing data across applications.
Each specification is called a 'class'. The word 'class' is used to describe a range of things that have common characteristics. For instance, every door has the characteristics of opening to allow entry to a space; every window has the characteristic of transparency so that it can be seen through. Door and window are names of classes.
The classes defined by the IAI are termed 'Industry Foundation Classes' or IFCs. The reasons for this are:
- IFCs are defined by the AEC/FM industry
- They provide a foundation for the shared project model
- They specify classes of things in an agreed manner that enables the development of a common language for construction
An IFC specifying a fan is more than a simple collection of lines and geometric primitives recognized as a fan. It knows that it is a fan and knows about the characteristics that make it a fan.
There may be many fans used on a project. Each fan used conforms to the class specification but may have different values assigned to its characteristics. One fan may have an inlet connection radius of 900mm whilst another may have an inlet connection radius of 1200mm. Both are fans and have the characteristics of a fan defined in the IFC specification. When a class is used may times, each instance of its use is called an object.
IFC-based objects allow AEC/FM professionals to share a project model, yet allow each profession to define its own view of the objects contained in that model. Other professionals can later use a fan object designed by an engineer. This leads to improved efficiency in cost estimating, building services design, construction, and facility management.
IFCs enable interoperability among AEC/FM software applications. Software developers can use IFCs to create applications that use universal AEC/FM objects based on the IFC specification. A centrifugal fan object created in one application can be exchanged with and used in another IFC compliant application. This second application recognizes the centrifugal fan object, which reveals:
"I am a fan and I know that I am a centrifugal fan. I also know how much air I must deliver against what resistance offered by the ducted system I am connected to, the radius of my inlet connection and the length and width of my outlet connection. Additionally, I know what my operation is, what my geometry is, and so forth."
The second application is able to understand these characteristics and add information to the object because it also uses the IFC specifications defined by the IAI. Applications that support IFCs will allow members of a project team to share project data in an electronic format. This will ensure that the data is consistent and co-ordinated. Furthermore, this shared data can continue to evolve after design, through construction, and occupation of the building. Information generated by the project design team will be available in intelligent, electronic format to the building construction team through their IFC compliant software and to building facilities managers through their IFC compliant software.
Member companies in the IAI, frustrated with the current fractured information systems of the AEC/FM industry, are working together to make this happen. The IAI includes industry leaders from all aspects of the international AEC/FM community. This group is uniquely qualified to develop the specifications for the IFC. However, the IAI is not, and will never be, a software company. It works with software companies that serve the AEC/FM industry to promote the IFC specifications and to enable them to create a new generation of software applications that apply the potential of the computer in the AEC/FM industry.
The entire AEC/FM industry and all of its customers benefit from the work of the IAI!
How Are IFCs Implemented
The IAI does not write software.
The IAI develops the IFC Object Model and supporting specifications. This common project model serves as the foundation upon which the software authors can develop applications that read and write to the physical file format used to communicate with IFCs.
Application software is developed independently by software authors.
There are three possible ways to share data using IFCs.
- By creating a physical file of information that may be shared across a network, by email or on a physical medium such a floppy disk. The EXPRESS language specification view of the IFC Object Model determines the structure of the file and the syntax of the file is determined by ISO 10303 part 21.
Presently, most software applications share information using physical files.
- By placing information in a database which has an interface defined according to the ISO 10303 part 22 (Standard Data Access Interface) for putting in and getting out data. The EXPRESS language specification view of the IFC Object Model determines the structure of the information sent to or received from the database.
Presently, a number of software applications can work using shared databases (also known as project model servers).
- By using software interfaces that can expose the information content of defined groups of attributes within an object. Software interfaces allow for direct communication between applications without the need for an intermediate file or database.
The use of software interfaces is experimental at present. There are no implementations in the AEC/FM industry that rely on the use of software interfaces.
Together the IAI and the AEC software community are defining this model, but it remains the task of the software vendors to implement the IFC specification and to bring applications to market.
The IFC Release Cycle
The objective of the IAI is to issue a major release of the IFC Object Model annually. In addition, interim releases of the model may be issued to satisfy a particularly urgent application need or to make corrections to the model as a result of implementers/user feedback.
IFC releases are numbered according to the extent of updating that has occurred. Release numbering is:
- Integer (e.g. 2,3 etc.)a major release at which the range of supported industry processes is extended and at which ALL IFC model documentation, including informative and guideline publications, is updated and reissued. Updated documentation is provided to all members;
- Dot (e.g. 2.5, 3.1 etc.)a major release at which enhancements to the IFC Object Model Core and/or Resources are issued. The range of supported industry processes is not normally extended. Documentation concerning the formal specification of the model is updated and reissued. Updated documentation is provided to all members;
- Dot-Dot (e.g. 2.5.1, 3.1.2)an interim release that includes model corrections. Addendum notices are issued to software implementers and are available to all members via the IAI international FTP site. Documentation is not reissued.
How are IFCs Developed
To develop the IFC specification it is essential to have a common view of AEC/FM data that can be shared by AEC/FM and software development professionals. This common view is known as the IFC Object Model, defined using a top-down approach. By starting with a very general view of the AEC/FM industry, an overall model of a building can be defined and successively worked into a detailed model suitable for creating software applications. The described processes and the accompanying figures which follow are representative of the information found in the Guidelines for the Development of Industry Foundation Classes.
- Usage Scenarios are written descriptions of the processes that users perform, such as how a facilities manager maintains the various assets within a building (such as an air handling unit). These usage scenarios capture the decisions and information that are used during each step of the process.
Process Diagrams give a visual representation of the process that is being defined. A process diagram is a diagrammatic representation of a usage scenario. For instance, the process of scheduling maintenance can be visually identified.
Classes are object-oriented programming components used to define objects. Classes are designed to support the needs of the process and include concise definitions of the AEC/FM data objects. Classes can clearly represent physical objects such as a centrifugal fan or more abstract objects such as the cost of the fan and the process by which it is installed.
A defined Idea or Class
Instances of a Class or Object
Attributes are information about the class or its interface and are added to fully define an AEC/FM object. For example, a centrifugal fan has a supply air volume and a resistance against which it can supply this volume of air, etc. These attributes are stored within the appropriate centrifugal fan class.
Relationships occur between classes. For example, a fan has a relationship to a starter. A starter in fact starts a fan, and reciprocally a fan is started by a starter. Relationships are important in defining object behavior in ways that mimic the behavior of the real world artefacts.
- Interfaces are used to provide access to the object. IFC interfaces are designed to support the AEC/FM processes, and enable software vendors to implement IFC based objects. For example, a fan object must support a variety of AEC/FM disciplines and include interfaces for costing, structural consideration, acoustic performance, among others.
Views of an Object
Interfaces of an Object
The object model is used to represent the classes, their interfaces, attributes and relationships in a composite representation. The IAI uses Express-G for its model notation, which allows a graphical representation of the object model to be created.
- Test cases are created to exercise the model using data from a predefined building and a specific usage matched to an industry practice. These test cases are based on the usage scenarios developed along with the IFC information model and allow a software developer to test their application’s ability to conform to the IFC Specification. The test cases provide live data for use with objects, interfaces, attributes and relationships. Figure 18 contains sample test case data.
IFC Release Deliverables
IFCs are documented for two readers: the AEC/FM professional and the technical specialist (a category that includes both specialist object modelers and software developers). IFC Release documents include:
An Introduction to the IAI and its IFCs
This document, the Introduction to the IAI and its IFCs, provides AEC/FM industry professionals with an introduction to the IFC Specifications including the IFC based shared project model concept. It outlines the benefits of IFC compliant applications to end-users, provides an overview of IFC, the IAI, and summarizes the processes that have been modeled in this release of the IFC Specifications.
IFC Model Guide
The IFC Model Guide provides a reference for the technical requirements, content and arrangement of the IFC Object Model. It includes the following major elements
- The IFC Model Architecture which describes the principles of how the IFC Object Model is organized
- The IFC Object Naming and Development Convention which describes how all of the elements of the model should be named and the guidance rules for the creation of classes and property sets.
- Samples of parts of the IFC Object Model for information.
The Guide is intended for specialist object modelers who are interested in IFC development and for software developers who need to understand how the IFC Object Model has been created.
IFC Specification Development Guide
The IFC Specification Development Guide provides an extended reference on how to develop IFC specifications in a consistent way. It describes how to develop a project proposal, documentation of processes and classes and development of domain object models that can then be synthesized into the overall IFC Object Model. It includes appendices that describe in simple terms some of the technologies used in IFC development. These appendices are useful in learning and understanding why and how IFCs are specified in a manner that is independent of software implementation.
AEC Processes Supported by IFC
The AEC Processes Supported by IFC documents the AEC/FM domain processes that the IFC Object Model supports in this release. Therefore, this document effectively defines the scope of AEC project information included in the current IFC Release
IFC Model Reference
The IFC Model Reference defines the IFC Object Model. This includes all of the information required by the AEC processes structured in an IFC model detailing object classes, standard interfaces and data types. It also presents several key concepts used in the design of the IFC model including: model structure, capturing design intent, sharing semantic relationships, model extension by application developers, and model exchange versus runtime interface views of the IFC Object Model.
It also documents the Information Model Exchange file used to represent the IFC Object Model. This Information Model is defined using the EXPRESS language defined in ISO 10303 part 11:1994 and can be used directly by software developers. This document provides an overview of the physical file format.
Also documented is the runtime interfaces view of the IFC Object Model that complements the Exchange Model view. This view is presented using Object Management Group's Interface Definition Language (IDL), which may also be used directly in software CASE tools to automate parts of the software development process.
This is the principal document in the IFC Release Document Suite and contains a large quantity of information. It is of value both to end-users and to software implementers. To assist navigation, it is made available primarily in HTML format and can be browsed using Web browsers such as Netscape and Microsoft Internet Explorer.
IFC Software Implementation Guide
The IFC Software Implementation Guide provides information and guidance to software programmers on how best to go about developing IFC compliant software. It draws on the experience of those organizations who have already developed such software and contains vital information which can reduce the time (and cost) of development. It discusses potential implementation strategies and includes list of software toolkits and platforms that are available to speed up the development of IFC compliance.
IFC Implementation Certification Guide
The IFC Implementation Certification Guide describes the process that has been adopted for certification of IFC compliant software applications and how such compliance must be demonstrated. It also describes the use of the compliance testing toolkit software and how this should be obtained.
