Preservation of meaning in mapped IFCs

The development of high-level standard representations of buildings has been welcomed by the majority within the industry. Such standards allow for semantic interoperability between the large number of design tools which are available to practitioners in the A/E/C and FM industries. However, with such standards comes greater reliance on the information contained within the models which are transmitted, and interpreted, automatically between design tools. Unlike geometry-based standards (e.g., DXF, IGES, DWG, etc) where there was always an expectation of human interpretation, this semantic data must be correct to fit within the interoperable world we have developed. Testing of the semantic interoperability of a small number of commercial design tools has shown that this level of trust is not yet able to be assumed and that further work needs to be done to ensure that we can preserve meaning when moving semantic information between design tools. Figure 1. Summary of changes to an IFC data file after a round-trip through a CAD package. Transformations identified when performing a round-trip of IFC data into and straight back out of major CAD tools include the addition, or removal, of objects representing physical constructs from the original description of the building (e.g., beams, see Figure 1) as well as changes to attribute values in the models. Given that these objects have very clear semantics, and identity, within the IFC data model this is obviously of concern to those who must rely on the accurate transfer of information between design tools. This leads us to examine why in certified design tools the meaning of models is not always preserved as expected. 2 IFC CONFORMANCE TESTING Certification of design tools is a process undertaken by a software vendor according to the rules laid down by the IAI (1996). There are two basic parts to this process. The first is a self testing process where a company utilizes the formal test cases for the exchange view they propose to support. When their design tool is able to conform to the requirements around the formal test cases then they put their deign tool forward for testing at a public interoperability workshop where: “The purpose of the workshop is to demonstrate to an appointed representative of the IAI that interoperability is achieved under live data exchange conditions with other IFC applications. ” (IAI 1996). A design tool which successful completes both of these processes is deemed to be IFC compliant as is authorized to carry the IAI Certification logo for the particular version of IFC that their design tool was tested against. This approach fits with the standard view of conformance testing as described by Kindrick et al. (1996). Testing takes two forms (see Figure 2). In one form a particular design task is executed in the design tool and the resultant model exported as an IFC file. This IFC data file is then analysed to ensure that the design tool created structures of the correct type. The second form imports the IFC data file into the design tool to analyse whether the correct structures were instantiated within the design tool. Figure 2. Two types of conformance testing (adapted from Kindrick et al. 1996) Such conformance testing can provide reassurance that the design tool complies with the transfer standard in terms of the structures created and the semantics of individual test cases. It is also relatively cheap to perform as each design tool is tested individually. However, this approach doesn’t address larger issues of whether the tool is interoperable with other design tools. The IAI’s interoperability workshop is an approach to providing this reassurance (see Figure 3). Though it is structured to concentrate on particular design tasks and only requires interactions with a small number of design tools. To guarantee full interoperability this testing would have to be performed with every design tool which utilizes the particular exchange view. Figure 3. Interoperability testing (adapted from Kindrick et al. 1996) Design