Data exchange from BIM to building-use simulation

Transcription

1 icccbe 2010 Nottingham University Press Proceedings of the International Conference on Computing in Civil and Building Engineering W Tizani (Editor) Data exchange from BIM to building-use simulation M. Laasonen Tampere University of Technology, Finland Abstract The starting point of this study is the practical problem of generating a research environment where different kinds of software can be made to mesh seamlessly with the design process. The main problem is that data receiving programs need information which is not included in the traditional design process. There are two ways to solve the problem: the data content of models must be increased, or the data must be complemented from other sources of information. Literature shows that a lot of resources have been used to standardize data exchange between CAD software of different design areas. For complete exchange, data content, data format and the meaning of the data of the sending and receiving programs should be exactly the same. Such demands for data are difficult to establish when it is exchanged between programs planned for different application areas. A problem is also that even when standards are broad, any single one does not cover all the special tasks of building design. Yet, many papers suggest that all data exchange should take place through a single model of a domain or a single database server. This paper, for its part, proposes that standard data exchange should be used only with limited data content. Instead of broadening standards and making them more complicated, we should accept the fact that a single standard cannot be applied to all data exchange instances. In the presented method, information is added in the standard data which can be used to complement it. Two example cases where the new method is used are presented. One concerns a BIM-based fire simulation and the other one exchange of data on a ventilation machine from design to building-use simulation. Keywords: data exchange, BIM, design, maintenance, simulation 1 Background There are several publications dealing with product models and BIMs as they are nowadays called. References to data exchange between models can also be found. For example, the report by Han et al. (2000) examined product modelling and the related data exchange formats. In their introduction they quote Eastman s (1999) words: The purpose of developing product modelling is to develop an electronic representation of a building, in a form capable of supporting all major activities throughout the building lifecycle. Their conclusion is that The goal of constructing a product model is to exchange building information. They studied in more detail two of the standard data exchange formats : ISO Standard for the Exchange of Product Model Data (STEP) and Industry Foundation Classes (IFC).

2 The idea of standard-based data exchange is that instead of connecting all applications separately to each other, there is only one file or server to which all applications are connected. Such a solution is presented, for example, by Yeh and You (2000) using the STEP standard and by Plume and Mitchell (2007) using the IFC standard. In the last few years many papers on IFC-based data exchange have been published. For example, one of the first live pilot projects, HUT-600, was used as an example by Fisher and Kam (2002). The published cases are mainly built around architectural models. The selected data exchange solution varies by publications. Three examples of cases where an own data exchange format or different standards have been used are given below. Hartman et al. (2003) developed the IRoom environment into an interactive workspace in order to enable data exchange and control between applications. For testing and validation of their environment they decided to use their own XML format instead of any standard. Rundle and Fay (2008) investigated different possibilities to standardize data exchange in building automation. These four standards proved suitable: Initial Graphics Exchange Specification (IGES), STEP, IFC and Computer Aided Engineering exchange (CAEX). According to the authors, the last one was the most suitable for the purpose in question. Jeong and Eastman (2009) looked at data exchange concerning precast concrete between different participants in design. They noticed that a single standard was not enough but that both general IFC and commercial SAT ( were needed. If the programs between which the data is exchanged represent totally different application areas, the sending program may not have all the data the receiving program needs. Then, the problem of the missing data must be solved. Two examples of that are given in the following. Mitchell et al. (2007) tested data exchange between architectural and thermal analysis programs by a standard file. The geometry of structures and spaces was transformed successfully. However, material properties were not transferred but they were entered through the interface of the thermal analysis program. They mentioned that, for example, due to the many national variations the materials cannot be readily identified. Some other data like a shading element and geographic orientation were also added to the analysis separately. Dimyadi et al. (2007) exchanged data from an architectural model to a CFD (Computational Fluid Dynamics) based FDS (Fire Dynamics Simulator) program. They developed an extra program called Parser for an interface to add the fire simulation data missing from the architectural model. 2 Data exchange methods 2.1 Problems of centralized data exchange Many publications consider only two possibilities of organizing data exchange: 1) A decentralized method where everyone discusses directly with everyone else and 2) A centralized method where a common database is generated based on a general data format. The building design process involves many different areas of expertise like structural design and building automation. A single standard that covers all data exchange tasks does not exist. If such a standard were to be developed, it would be so broad that its administration would be very difficult even if the database were split into several parts. A common database would require determining which building parts are updated by which program. Otherwise a common identification system would be needed for all building parts in every application. A further problem is that all building parts cannot be connected to each other only based on coordinates. For example, space is an important concept to which many functions are connected. Presently, the problem is solved by collecting the data in the architectural model from which the final standard data exchange database is output.

3 It must also be remembered that part of the knowledge is programmed into the intelligence of software which may be difficult to transform to database form. For example, the behaviour of the connections of building parts is difficult to exchange from one program to another. Then the model cannot be exchanged in editable form, but only the end result of design is available. Almost any data exchange can be realized by the decentralized method. Then the intelligence of original applications may be utilised by their programming interface. The main disadvantage of the decentralized method is the updating and versioning of the data transformation program. A certain program may not be able to communicate with the different versions of some application. In cases where several standards are used, the centralized method has been abandoned, and the decentralized method has been largely reintroduced. This paper does not deal in any detail with the adjoining areas of buildings but just notes that data exchange cases that are difficult to standardize can also occur, for example, when modelling land or navigation and other geographical information systems. Should someone still prefer a single standard, the commercial and scientific competition and amount of data involved would make it difficult to decide which one to select. An object-oriented database can naturally be more easily used for different purposes than a traditional relational database. Yet, no one can be sure about how data processing will be developed in the future. It is possible that even a totally new standard will be taken into use if it is proven to be effective. 2.2 Combined data exchange method In this paper the centralized method is developed into a more general form. In the new combined method the original data includes information by which the exchanged data can be complemented from other sources of information. In deviation from other data exchange, the reading of additional data is unidirectional. The basic organization of different methods is shown in Figure 1. Decentralized Centralized Figure 1. Different ways of organizing data exchange Combined The combined method could involve, for example, the following steps: 1) Add to the original model a unique identifier or unique keyword recognizable by a program. 2) Determine the specific place where complementary data should be found. It can be, for example, a certain path in the same computer, an IP address of a shared server or a web page address. That data place can also be saved to the attributes of the original model. 3) Document the data content of complementary data and save the information. For example, XML files make the programming easy. 4) Join the complementary data during some phase of data exchange. If it is done in the beginning, the sending program writes all the information to the file that the receiving program

4 understands. After transformation the data content is usually lower than in the sending program. If more intelligent data is not needed, the receiving program may first read the standard data and then complement the data content. In that case, the place where the complementary data can be found should be included in the standard. Based on this definition of data exchange methods, data transformation cases can be divided into two categories based on data content: 1) Ones where basic graphics and commonly used attributes are transformed by a standard and 2) Ones where exchange of professional data of certain area is implemented by a special program. In practice many cases are a combination of these two. As told before the combination method can be realized merged to a standard by agreeing on the saving of the identifier. The logical place to complement the data content of an object is the database of a manufacturer. They could keep the format very steady when all the information is initially stored. Every manufacturer has its own identification system for production. The problem is in ensuring that different manufacturers do not have the same kinds of codes. This can be avoided by incorporating the manufacturer s information in the identification. The manufacturer portion could be a distinct web address where the manufacturer data is available. The wholesale trade, for instance, is already using different coding systems which could be adapted to wider use. 3 Applications of combined data exchange 3.1 Case 1: BIM-based fire simulation of steel structures In Case 1, it was desired to add the calculation temperatures of steel structures in fire to the design process. In normal design, the product model is transformed into an analysis program and the dimensions of parts are determined. With the inclusion of calculation temperatures, the process should allow transforming the product model to both the analysis and the fire simulation program. After fire simulation, the temperature of every rod should be added to the analysis program in the form of a temperature/time curve because otherwise the real temperatures of steel parts cannot be calculated. The problem was how to co-operate with several programs whose data contents differed considerably from each other. The modelling program is used to plan the geometry of steel parts for production, and nowadays the models can be highly accurate. Every connection detail and machining of parts is included in the model. In the analysis program, parts are depicted by one dimensional finite elements. In CFD-based fire simulation, all objects should be transformed into cubes following exactly the nodes of the calculation grid. In fire simulation, walls and other non-bearing building parts are also needed contrary to the modelling of bearing steel structures. Fire simulation also needs data that no modelling program includes. Most of the data consists of values like density which could be saved to the model s defined attributes. There is also material data in the form of functions like conductivity as a function of temperature. Such data is not suitable for transforming by a standard file planned for a geometric model. The combined method is applied here by identifying the complementary data from material names. The material information is saved to separate pre-written files. Used material can be read from the model, and the necessary files can be transferred to the input file of the fire simulation program. The same method is used to model fires. The geometry is modelled by the basic elements of a modelling program. The fire is distinguished from actual building parts simply by adding the material name keyword fire to the beginning. The data transformation program reads the model, finds the right fire file, and adds it to the input file of the fire simulation program. Finally, the calculated temperature curves were transformed to the input file of the analysis program including the identifier of steel parts. The developed test environment has been described more precisely by Heinisuo et al. (2008).

5 3.2 Case 2: Data exchange from planning to maintenance The other example of data exchange has so far been realized only on the theoretical level. Yet, it shows how the combination method can be utilized in a larger environment. The presented case involves the simplified data content of a ventilation machine. Nowadays the collection of data for maintenance from the design process is such a large undertaking that it is not done just for simulation purposes. If the process could be automated, the situation would be different. In the example the data is exchanged primarily through the architectural BIM. That is in line with the design processes used today. The figure below indicates the participants of the design process and using of ventilation machine. The maintenance box represents actually the entire real estate business including also facility management and the building owner. In practice, their interrelationships vary a lot and are not dealt with in this paper. All cost-related data has also been omitted. Figure 2. Data exchanges concerning planned ventilation machine The data exchange instances of Figure 2 are numbered. The space information planned by an architect will be exchanged (1) to the ventilation designer. He or she calculates the required ventilation and selects (2) the machine that can provide it. The placing and geometry of the machine is transmitted (3) to the architect. The same data is further transformed (4) to the structural designer who also needs to know, for example, the weight (5) of the machine. The type information (6), again, allows the electrical designer to determine the power (7) requirement of the machine. A lot of design data is needed for maintenance. The architect s data on the spaces and their use (8) is most important for rental property owners. Detailed type and model numbers, manuals and a service program (9) of all existing machines are needed to keep the technical system running. Here it is assumed that the realized system is updated to all plans before data exchange. The combination method also has limitations. For maintenance it would be valuable, for example, to know the difference between the rated and planned operation capacity of the machine. Such data is stored in the design program but is not available without a special agreement. Similarly protected data is also how different parts of the ventilation system are connected to each other or to the power supply. In the case of a centralized data exchange method, there is the question of how the maintenance information will be stored to a common database initially. The design process does not produce maintenance information. The information is not known even to ventilation designers, not to mention the architect. Technically most of the information could be saved to a common database by adding new attributes to the building parts of the model. In any case, data exchange is uncertain when there are attributes whose meaning is not controlled by the program that saves them. In this connection it should be mentioned that Finland has a national coding system for HVAC products. It was established in 1992 and contains presently over items. Practically all participants to the building process use its codes. A commercial company LVI-numero Oy (2010) owned by the association of producers and importers manages the coding. A similar coding system could be taken immediately into use in the data exchange within national projects. A different approach may be needed on the international level.

6 4 Discussion and conclusions The main conclusion of this paper is that standardization of data transformation may not have to be expanded to the most general cases. There is no question that standards are needed. Standard files are most effective when only basic data like geometry and material information is transformed. In more special cases, the combined method presented here could be an effective alternative. Too broad standards are difficult to use and may hinder the development of applications. All the data exchange needs of future application cannot be forecast. A standard that must be changed all the time is of little use. By limiting the data content a standard can be made more stable. When a limited standard is used, the data must often be complemented. Then, the biggest problem is how to ensure the identification of objects, especially internationally. A practical solution could be to include a standardized attribute for identification to objects describing, for example, building parts use. The attribute could be taken from the web address and the identifier is unique at least on the page in question. The natural administrator of the page would be the manufacturer of a building part. Any new program may be easily developed when all information can be easily reached from such a page. When all significant data can be saved directly on the page, there should be no need to update it very often. There is also no need to determine beforehand the purposes for which the data will be used. The main problem of the combination method is changing data formats of applications as in the case of the decentralized method. A standard basic data exchange format and stable data stores might improve the situation. The method cannot solve all data exchange cases. For example, the numerous connections between building parts should be transformed by a different method. The next thing to do is to perform and document as many different kinds of data exchanges as possible using the combination method. The accrued experiences will allow developing the method further. For example the fire simulation process may also be applied to the calculation of indoor climate in normal use. If maintenance programs could be used for simulation purposes, automatic data exchange by the combination method would provide them the needed initial data cost-effectively. References DIMYADI J. A., W., SPEARPOINT M., AMOR R., Generating fire dynamics simulator geometrical input using an IFC-based building information model, ITcon Vol. 12, 2007, pp EASTMAN, C., Building product models. CRC Press, USA. ISBN FISHER, M, KAM, C., PM4D final report. CIFE Technical Report #143, Stanford University, USA HAN, S., LAW, K., KUNZ, J., Computer models and methods for a disabled access analysis design environment. CIFE Technical Report #123, Stanford University, USA HARTMAN, T., FISHER, M, RANK, E., SCHREYER, M., NEUBERG, F., Integration of a three dimensional CAD environment into an interactive workspace. CIFE Technical Report #146, Stanford University, USA HEINISUO M., LAASONEN M., HYVÄRINEN T., Product modeling in fire safety concept, calculation of steel temperatures. EG ICE08 Conference, Intelligent Computing in Engineering, edited by Rafiq, Y., de Wilde, P., Borthwick, M., University of Plymouth, Plymouth, pp ISBN JEONG, Y., EASTMAN, C., Benchmark tests for BIM data exchanges of precast concrete. Automation in construction, 18 (4), pp MITCHELL, J., WONG, J., PLUME, J., Design Collaboration Using IFC. A case study of thermal analysis. Computer-Aided Architectural Design Futures, Springer Netherlands, pp ISBN LVI-NUMERO OY, (In Finnish) PLUME, J., MITCHELL, J., Collaborative design using a shared IFC building model - Learning from experience. Automation in Construction,16(1),pp RUNDE, S., FAY, A., A data exchange format for the engineering of building automation systems. Proceedings of the 13th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA, pp YEH, S-C., YOU, C-F Implementation of STEP-based product data exchange and sharing. Concurrent Engineering Research and Applications, No:1, Vol:8, pp