The Evolution of CAD
Chapter Four:
the International Alliance for Interoperability
Written By Martyn Day
Data transfer will be a key issue for the early object adopters. Transfering models has always been a problematic issue for the industry and it doesn't look to be getting any better. Martyn Day continues his voyage in the object world and talks to the Technical Director of the International Alliance for Interoperability, Richard A. See.
In writing this series of articles on the much hyped object developments in CAD, it has become obvious that the capabilities of the systems on offer, the level of data transfer between those systems, the cost and long-term direction of the technology are either embryonic or shrouded in mystery. While it's hard enough to grasp the basic concepts of the new technology, the long-term complications and implications can not be over looked.
In the future, object-based CAD modellers will allow us to create intelligent buildings, which will understand construction conventions and provide the designer with better feedback systems. One key issue here, is that there will be a number of these systems out there creating intelligent models. As each vendor will have its own way of creating intelligent objects (walls, doors and windows) transferring this data to a competitor's system will be extremely challenging. In the same way that it's difficult for a French person to understand Chinese!
To aid this translation it would help if there were a common set of standards or an agreed vocabulary. Autodesk realised this as it was developing its object technology and helped form a guiding body, The International Alliance for Interoperability (IAI). In short this team, made up from developers and users from the construction industry, were tasked with deciding what exactly made up a wall, a door, a window etc, these were more commonly called Industry Foundation Classes (IFCs). As the object momentum grew, more CAD developers and architects joined and IAI chapters were set-up all around the globe, working to define all the objects used in the construction world - not a small task. Unfortunately as the IAI grew so did the "designed by committee" stigma. To find out more about what the IAI is attempting to do and has already achieved, I talked with Richard A. See, IAI International Technical Director.
Martyn Day: The CAD industry is on the cusp of moving towards Object modelling. This year companies like Autodesk and Bentley will have solutions that allow architects to create models using doors, windows walls, etc. As this happens the models will become highly complex and "intelligent". How will users transfer this data from one CAD system to another while maintaining the Intelligence?
Richard See: I would like to answer this on both technical and business levels. On the technical level, as models of projects become more "complex and intelligent", information sharing will be increasingly dependent on application "views". Such "views" of the shared model are essentially model subsets that include only the information of interest to that application. The resulting 'filtering' of information significantly increases the success in sharing intelligent object models. IFC has been designed to support such model views. These will be shared between applications, initially through file exchange, then through software interfaces on model servers, through standard software interfaces at the object level.
However, the degree to which this will be successful is largely dependent on end users. Effectively, this will not happen unless end users demand it. To do this, they must understand and appreciate the importance of establishing industry standard definitions for the information to be shared (so that applications will 'plug and play'. They must also become active, both in definition of object types (classes) and in requiring support of such standardised objects in the software they use.
MD: IFCs require specification. Considering how many architectural components are out there, this sounds like a tough job. Where is the IAI and IFC classification on the roadmap?
RS Yes, specifications for the object types to be supported must be published in order for implementations by different vendors to successfully share these object. Yes, this is a very large job! The current release of IFC (Release 1.5) includes 185 classes and over 100 'Type Definitions'. This means that our 'vocabulary' of object types is close to 300. A large percentage of these provide the fundamentals (geometry, units of measure, common properties, model structure, etc.). This infrastructure has taken some time, but was essential and will give us a solid foundation on which to build Releases 2.0 and 3.0. The remaining classes in Release 1.5 support a limited set of design processes in architectural design, HVAC systems design, construction management and facilities management. In IFC Release 2.0 (scheduled for Spring 1999), we will include extensions for all of these domains plus building code checking, cost estimating, simulation and document management. In Release 3.0 (scheduled for Summer 2000) we will add support for power and lighting systems, building structure, temporary facilities (cranes, scaffolding, lifting devices, etc.), construction scheduling, external libraries and document references into the model.
MD:While I hear the sales pitch quote IFCs and IAI as being the best way to transfer data from one CAD system to another, off the record, the CAD vendors appear to be not so confident about a) the IAI's ability to produce the goods quick enough, or are b) reticent about standards that are designed by a committee. What do you think of this?
RS With regard to the time it is taking to develop IFC releases: We are now completing our third release in three years. While the current release of IFC is not as complete as some would like it to be, it does include a number of concepts that are key to AEC/FM project models, yet not supported in many shipping CAD systems. Furthermore, IFC has been designed to support information sharing with non-CAD applications Our membership is nearing 650 leading AEC/FM organizations in 19 countries, including significant representation of software vendors serving this industry (Autodesk and Bentley among them). This industry cross section is working together to insure a smooth transition from a document centric approach to a model centric approach for designing, constructing and managing building projects. This will take time, but we are making great progress.
A central belief in the IAI is that the IFC project model should be defined by industry - that is, the AEC/FM professionals who design, build and maintain built facilities + the software companies that serve them. Another central belief is that the IFC Project Model must be 'open' and vendor/application neutral (not proprietary to a single vendor). If intelligent objects are to be shared across application boundaries, it seems to me that the alternative is for all applications to be forced to use the 'application model' that is optimized for one (or a couple) leading software companies. Obviously, such an application model would be proprietary and closed by comparison, even if it was made widely available through licensing. While the IAI's consensus-based approach does mean some compromise by all participants, the result is an open, vendor neutral, sharable project model.
There is no doubt that software vendors will create 'application models' that are optimised for their application. There is no single object model that is optimal for all applications. Therefore, all applications supporting IFC are supporting an application's 'view' of the shared project model. This means that, while many objects in their application will be internalized IFC objects, other objects may have to be 'mapped' to the closest equivalent in IFC (e.g. a generalisation or an object with extensions by other apps). This is okay, and should be expected. IFC cannot be 'all things to all applications.'
MD: What happens to undefined objects when translated into an IFC file?
RS: We have included the IfcProxy object to address this very issue. You can think of IfcProxy as an 'all others' type of object. It is very general purpose, allowing applications to share all of the 'data' for such an object, but obviously not defining any standard behaviors. The reason for including IfcProxy is that any release of IFC (or any other object model for that matter) will be incomplete. It is simply not possible to pre-define all possible types of objects for all types of AEC/FM projects. Additionally, the IAI has consciously focused on incremental delivery of IFC. That means that we did part of the job in Release 1.0, more in Release 1.5 and so on.
MD: Is it true that the IAI only defines Object properties and graphic representation? Would that mean that symbols would change from one CAD package to another?
RS It is NOT true that IFC excludes these. Actually, IFC allows multiple 'shape representations' (2D and 3D, geometric or symbolic) and these are handled 'as' properties (just as with cost, material, etc.). This is because IFC is not CAD or geometry centric. However, applications are not required to define and share multiple shape representations in IFC. The only requirement for objects that have 'shape' is to include a 3D bounding box representation (to show placement, orientation and extent). Creation and sharing of all other shape representations is optional and the decision of the end user.
MD: Aren't Proxy Objects damaging to the integrity of Object models?
RS: I will assume that you are asking about IfcProxy objects here (as distinct from AutoCAD 'Proxy objects').
I wish that there was a simple answer to this, but in reality, it depends on the context and on what a 'reader' attempts to do with IfcProxy objects. In general, since IfcProxy objects are object surrogates for object types not yet defined as native to IFC, we want to limit what applications attempt to do with them.
Case 1 An application supports an object type that is not yet defined in IFC. Is it better to include it in the IFC model and share it with another application (even though it will be a limited representation), or to leave it out of the model? Our collective opinion was that it was better to include it as an IfcProxy. The best example of this in IFC R1.5 is stairs. Stairs will not be added into IFC until R2.0. In the mean time, users can exchange stairs as IfcProxy objects. This will allow the sharing of the stair geometry and any special properties for stairs. Receiving applications should display the geometry and make the properties available through a general query interface, but should most likely NOT edit these objects.
Case 2 Application 'A' supports an IFC object type that is not supported by application 'B'. When application 'B' reads a model file with these object types, one option is to agree a method by which this application creates IfcProxy objects in their place Ñ only within the context of that application. This can be dangerous if there are special relationships between known objects (fully understood by app 'B') and the objects now represented by IfcProxy objects. If edits are completed on the known objects that 'should' trigger a change in proxies, but don't, this could damage model integrity. Our core technical team is studying this problem now in order to develop a set of 'rules for interoperability'. The goal of these rules is to prevent such model damage.
MD: What's a wipeout Object? And what happens to them once exported to IFC?
RS: I believe you are referring to a 'wipeout' in AutoCAD R14. You will need to speak to Autodesk for a definitive answer. My understanding is that these are used in obscuration - used to selectively obscure entities in drawings. This is a concept that is appropriate and useful in drawings (as views of models), but are not appropriate to the underlying model. Therefore, we do not need to save such objects in an IFC model.
It is important to note that IFC will not supplant DWG or other drawing/document formats. These things are complimentary. Documents present specific views (presentations of representations) of object in an underlying model. An example is a plan view drawing (representation) of floor 1 at 1:100 scale (presentation). The application that creates and manages such a drawing will query or extract a selected subset of model objects (e.g. floor 1), generate representations appropriate to that document type (e.g. plan view) and then generate the presentation (e.g. detail and scaling appropriate to 1:100 scale). Manipulation of these object representations within the document will result in modifications to the underlying model objects through the application interface to the model repository. Additionally, some objects will be specific to the documents and will not be stored in the model repository. 'Wipeout objects' are an example of such document specific objects. They will not be stored in an IFC project model. They will be created to modify the representations in drawings and will be managed by the drawing application.
MD: Would you say that software companies selling OO software are jumping the gun a little by including undefined architectural Objects?
RS: No, I would not say they are jumping the gun. Users will always have the option of sharing such objects through the proprietary format. This will limit the number of other users with which they can share, but it will certainly be viable. Over time, as we are able to provide more comprehensive coverage of object types in AEC/FM projects, we can learn from vendors who have pioneered some of these object types.
MD: How is the IAI funded?
RS: Most of the work done in the IAI is done by member-company 'sponsored' resources. That is, expert time made available by member companies. Additionally, we have a core technical team that does most of the object modeling and specifications. Some of these are also member-company sponsored. Others are independent consultants with special expertise that we have decided is essential to the development of IFC. Currently, funding for these resources (and other overhead expenses) comes primarily from membership fees and project specific sponsorship by member organisations. However, we have submitted proposals into a number of government sponsored research programs. We expect to attract additional research and development funding during the coming year.
MD: How will you handle class definition revisions? Will it always be backward compatible.
RS: Within the current release of IFC, the Object ID includes the IFC release number. We set a goal to maintain as much backward compatibility in IFC as is practical, but we do not guarantee it. This is because we know we will learn valuable lessons from early IFC releases. We must have the freedom to evolve IFC, continuously improving its design and coverage of object types and concepts in AEC/FM projects. In general, we can expect that vendors will create model migration tools. Such tools will allow users to convert project models from say IFC R2.0 to IFC R3.0.
MD: What advice would you give to any company looking at an object oriented Architectural solution?
RS: My advice would include the following:
Ensure that it supports IFC. This will give you long term security that the resulting models will be supported by a wide range of applications and application types in the future.
Establish a pilot project and pilot user team.
Provide early feedback to the software vendor for that solution. Feedback about improvements and next steps to supporting the way your firm works.
Conclusion
From talking to Richard one does build some confidence in the capability and possibility of IFCs, perhaps not now but in the coming years, once a whole lot of work has been done. The problem with believing that all this is possible is hearing the relatively negative CAD vendor's views of the IAI. One common feeling that I keep coming across is that the IAI has spent 3 years reinventing another standard, STEP AP225, which is now an ISO interchange standard. Also many observers feel that the fundamental IFC architectural model is insufficient to represent the complexities of contemporary buildings.
To me it seems while the CAD vendors help fund the IAI, a number resent not being able to 'control the outcome' and then there's the more fundamental issue that good data transfer between systems isn't something developers of proprietary CAD systems particularly want. Only time will tell the outcome of this debate. Will users invest in object CAD systems? The market will decide.
All rights reserved to Electronic Design Automation LTD 1999
Any queries to webmonkey: al@edaltd.co.uk
