Volgende: Evaluation regarding improved information Omhoog: Analysis of current information Vorige: Specification and Classification Inhoudsopgave
This section analyses PDT initiatives, starting with ISO-STEP, followed by the STEP split-off IFC. Next are future ISO-standard 12006-3, with two example projects, and lastly reference models.
Within BC, the ISO's STEP has not met much success [34]. This in contrast with other industries like automotive and the oil/gas industry. Two BC ISO-STEP initiatives are discussed below, but some general comments can already be made.
ISO-STEP is a big standardisation-by-committee effort. A lot of effort is put into coordination between the various parts of STEP, making sure that the same definition of `person' or `address' is used. The same is true for shape related models, like 2D drawing models and topology and geometry models. Besides generally applicable models, STEP also contains sector specific models, but not for BC. Why not?
An ISO-STEP standardisation process needs strong participants and enough funding. BC is conspicuous for lack of companies with a large market share, being mostly dominated by SMEs. Also, the profit margins do not allow for much research and standardisation subsidies when there is no reasonably direct return on investment.
There is a difference in variety of objects in the various industries. Cars in the automotive industry are largely one product family with a typical set of components. BC by contrast makes houses, stadiums, power plants, bridges: all distinct product families, but of course realised with a limited but common set of materials and basic components. Still it seems that the uniqueness of the products forms a strong negative influence on the information standardisation process. Also the fact that houses, components and materials are different in each country (due to local circumstances like regulations, weather and such) makes it hard to develop standards for international usage.
An early example of a successful STEP development is the AP221/ EPISTLE/POSC-CAESAR project developed for the process industry in the late nineties using ISO-STEP technology. The ERDL is a managed collection of process plant life-cycle data that represents information about classes or individuals which are common to many process plants or of interest to many users. The ERDL as published contains about 10500 classes [35] representing core class specialisations for physical objects and properties which could provide a significant reference source to doing projects.
The ERDL data library was made using Excel and Access tables, which was a practical choice at the time (when Internet was still obscure), but now has resulted in a data collection with little or no appeal. The reason for mentioning ERDL in the first place is to give credit to the developers that were advanced in their time, but could not do the job right because a suitable technology was lacking.
The BCCM was probably the most important part of the STEP effort in BC. A core model is a model that describes common objects like beam, column and floor in such a way that more detailed objects can be described by specialisation, i.e. a hollow concrete floor can be modelled as a subtype of floor [15].
The first version of the BCCM was a result of the European ATLAS project [36] and subsequent development of ISO-STEP Part 106. Development of a large model full of BC Semantics did not fit in well with the heavyweight ISO standardisation process and progress was slow. This lead to the start of the IFC project discussed in the next section. Following IFC's start, development of BCCM has ceased. [11]
An observation that can be made is that heavyweight standardisation processes are not suited for the development of a standard library for BC. Perhaps a standardisation process is not the right fit in principle for a development effort. A standard development efforts should standardise what is available and what has been proven in practice (de facto), it should not be created as a de jure standard, hoping for acceptance-because-it-is-a-standard.
The IAI [37] started the development of the IFC [38] on the results of the aforementioned BCCM. Since then IFC is developed in rapid cycles.
IFC is a modeling effort of the ISO-STEP type. They do not operate within the ISO standardisation effort, though, as that was deemed too slow. It was started by CAD vendors, intending a much more rapid progress. Progress has indeed occurred and work on STEP standards like BCCM has ceased.
As it was started by software vendors, software support for the standard is available. It is mostly restricted, however, to the big CAD packages and a handful of model checkers etc. Result is that only a very small part of BC uses IFC in real practice, it is mostly restricted to the top 1% biggest companies [22]. This makes it uninteresting for the majority of software vendors and thus restricts IFC in its adoption by the market.
The information ordering allowed by IFC is restricted by the amount of BC Semantics (`door', `windowsill', `fire resistance') contained inside the IFC model. Currently a workgroup (XM7) is researching the possibility to split IFC into a core IFC and a separate library containing the Semantics: construction objects and properties currently built into the IFC model itself. The 12006-3 standard, discussed in the next section, is one of the candidates for storing the Semantics. Since halfway 2006 this work is underway using the name `IFD library for buildingSMART' [39].
Something that speaks for the attractiveness of IFC is the fact that researchers doing roadworks engineering have used IFC for their (essentially unsupported) data: for roads [40] and for concrete bridges [41]. The road- and waterworks industry is badly under-provided by information standards, worse than the building industry. IFC proved to be useful and extendable.
The IAI at last did understand the need for exploitable results. That has been the reason for the funded, controlled development environment outside the standardisation arena where no financing is involved. Despite this understanding and despite efforts of several CAD/CAE vendors, IFC adoption and commercialisation is still on a very low level (<1%). The reasons are mainly the lack of added value that follows from IFC conformance. Individual CAD-systems like ArchiCad, ADT and others internally have more power than IFC, so why should users or user groups settle for less?
IFC will receive a boost, as recently a big USA governmental building organisation made IFC usage mandatory for their future construction projects (from 2006 onwards) [42].
 |
Since mid 1990s, work is underway to create an 12006-3 ISO standard for object libraries [43]. This concerns the data standard, the actual contents of the object library are outside of the ISO process. The standard is developed using STEP technologies, most notably the Express data format specification and the ExpressG diagram format. Currently (halfway 2006) the standard is in the DIS stage. Figure 3.4 provides a simplified overview.
The object library format allows for objects, properties, units and so on. All items--including properties and units--are uniquely and rigorously identified with an ID, which is a real improvement over the Classification and Specification systems described earlier in this chapter. Every item can have names in multiple languages, likewise multilingual textual descriptions [44]. This provides a basis for international object library development, when desired.
Two mechanisms are available for structuring information: inheritance (is-a) and composition (has-a). With the inheritance mechanism, an inheritance tree can be made with more abstract items on top, branching out to more specific items further down. For instance, a `door' is-a `access construction' or a `highway' is-a `road'. With composition, typical components can be attached to an object. For instance, a `house' has-a `roof', a `foundation'.
12006-3 is a very focused effort, providing only a way to build object libraries for BC. This is contrary to, for instance, the IFC project, where Semantics (the object library's content) are mixed in with the rest of the standard. It is good to keep BC Semantics separate [45] from, in this case, shape modeling. This is evidenced by IFC's start of the XM7 project which aims at separating Semantics out of the IFC model, possibly by using 12006-3. XM7 has recently been superseded by IFD [46]).
Though a focus purely on the object library level is a good thing, the accompanying data level (where the library objects are used) has received virtually no attention. Only the eConstruct project--discussed in the next chapter--really used objects in catalog items, objects taken from an 12006-3 object library (STABU's LexiCon) [47]. This lack of data-level usage is a two-fold risk. First there is little feedback from actual data on the object library; if there is a continuous effort to create, for instance, catalogs based on the object library, then this gives insight into weak and strong points of the current objects contained in the library. Second, it is harder to show the effectiveness of such an object library, since it cannot be demonstrated. To safeguard against this weakness, it is advisable to do at least a prototypical walk-through all the way from the object library to actual catalogs or Specifications [48].
Though being much more specific and providing much more computer-usable information than common Classification and Specification efforts, there are a few weaknesses relating to an improved information and knowledge handing in BC. First, the reference mechanism by which external information sources (like regulations) can be referenced is text-only. It is to be acknowledged that there is not a lot of rich information with which to link in a more semantic way, so there was probably not really an alternative for this textual solution. Second, there is no built-in way to connect two 12006-3-based object libraries, apart from using aforementioned textual reference mechanism. This means a built-in assumption that one single 12006-3 object library will be used for BC, or at least for a large part of it. Third, properties can only have normal values, they cannot have another object as their value. This restricts the richness of the object-to-object relations to the build-in inheritance and composition relation.
Next, two 12006-3 examples from the Netherlands will be analysed.
CROW publishes the Dutch Specification system for civil engineering works [49]. CROW is participating in the development of structures and guidelines for object libraries and is working closely together with STABU in these matters.
CROW is developing its own object library for works of civil engineering constructions (the CROW object library, `CROWOB' in Dutch). Lately CROW changed its top-down, manual approach in filling the object library for works of civil engineering constructions, supported by the LexiCon Explorer, into a--on the one hand--more bottom-up, semi-automated and--on the other hand--more practice driven approach. The top-down approach has shown too little progress in the past few years. It did not result in a usable hierarchy and each discussion provided a new kind of hierarchy without a clear advantage over the previous one and without providing clarity on the lower levels containing the actual data. Also the manual approach resulted in re-thinking lots of definitions that were already available, albeit possibly less consistent and in a less structured way. Overall, this stood in the way of getting any substantial content at all.
In the first step along this new approach CROW has transformed their Dutch `nomenclature for roads and traffic' into the first initial version of the CROW object library (version 0.1, beginning of 2005). This resulted so far in approximately 2500 object definitions and many more relations, with the capability of an XML export according to the 12006-3 format.
The next step, started in 2005, is the evolution to version 0.2. One element is to work from projects from construction practice. Another element is that the next version(s) will also contain the relations, amongst others, with CROW's Specification system.
Conclusion: acceptability of a top-down hierarchy is apparently low when its advantages cannot be clearly demonstrated. The bottom-up approach tries to build on existing data, making it more semantically rich. The speed with which this bottom-up approach could be executed has much to commend it, though the results have not proven themselves in practice yet.
STABU's LexiCon has always been directly linked with the core 12006-3 development through its main developer: Kees Woestenenk. It has therefore all 12006-3's advantages like multilingual possibilities and strict modeling. The LexiCon is consequently bi-lingual (English and Dutch), in the sense that those two languages are kept updated and synchronised. Lexicon's content during the eConstruct project was translated in no less than six languages [50], see figure 3.5 for a Greek example.
In the most recent version only the inheritance mechanism is used [51]; the other object structuring possibility, composition, is reserved for future commercial enhancements. LexiCon therefore has as its backbone a huge single-inheritance hierarchy, part of which is shown in figure 3.6. As everything has to fit in that one hierarchy, a sizable number of objects are by necessity abstract. A stated goal of the single inheritance hierarchy is improved consistency.
 |
For the LexiCon, 12006-3's lack of data format was addressed in the eConstruct project (2000-2002, discussed in the next chapter). Delft University of Technology and TNO developed the bcXML data format, which was subsequently used for a convincing demonstration. Catalogs and IFC drawings were linked together, with the LexiCon Taxonomy as the Semantics used by the bcXML data.
There was no follow-up on the bcXML possibility and attention was shifted to updating the hierarchy, which resulted in multiple revisions. These revisions have not yet obtained market acceptance, one of the reasons being that there are no demonstratable results [22] [52].
The recent LexiCon versions do not offer the possibility to attach properties like `fire resistance' and `door leaf height' to the objects, neither do they indicate parts. The LexiCon is seen as a basis upon which you can build libraries [22]. The creation of commercial object libraries, which include attached properties and parts, can then be done on top of the base LexiCon.
Improved information handling in BC means a more streamlined exchange of objects and properties. Keeping the (linked) properties out of the core and entrusting that to multiple commercial object libraries does seem problematic, especially since 12006-3 does not include a mechanism to connect multiple object libraries.
Other research in the past looked into a method that could produce product models for certain domains that required multiple sub models. An example has been the EPISTLE development of the international process plant industry. Basically the idea is to create a common meta model for a number of overlapping detailed models.
A well known reference model is the GARM [53] [54]. The purpose of the GARM was to develop dedicated type models for specific product classes (office buildings, highways, bridges) that all have a similar structure.
The approach advocated in the GARM is particularly suited to the problems of BC. The GARM supports: the distinction between a functional perspective and a technical perspective; top down and bottom up problem solving; and a layered approach.
Many researchers have applied GARM principles to create a reference model with properties that were required. Luiten [55] for example created the Building Product Model (BPM) that could support design for construction.
Until recently, the influence of the reference modelling approach has been very limited. It seems that the technology of the past and the traditional standardisation process lacked sufficient power for successful implementation of this approach.
In a decennium the BC PDT researchers have not advanced much. Only the IAI has something tangible. The development of ISO-STEP standards for BC is abandoned. The promise of semantic integration could not be realised. The Classification system people infiltrated in the PDT arena but synergy did not follow.
Tolman analysed [34] why the PDT approach of ISO-STEP did not (yet) deliver BC what it promised. Basically (1) the expressiveness of the standard has been too small, (2) the time to market of the standard and its related tools has been too long and (3) the standard lacks openness (cannot be developed without heavy involvement of ISO-people and ISO ownership). While developing and implementing the standard, the technology changes and changes.
The IAI with its IFC scores somewhat better; a fraction of the current BC projects uses some IFC technology. What has been missing in ISO-STEP and what still is lacking in the IFC is Semantics, i.e. definitions of the 300k+ objects of interest playing a role in BC, including properties, units, relations, constraints. As to openness: the IFC and its submodels are controlled by the IAI, which is not really much different from ISO. It is possible to develop your own extensions, though.
Reinout van Rees 2006-12-13
