InfraPDM. Report 1: Objectives and Ramifications of Product Modelbased System in Finnish Infrasector

Transcription

1 InfraPDM Report 1: Objectives and Ramifications of Product Modelbased System in Finnish Infrasector Targets and forecasts based on Norwegian experiences Juha Hyvärinen Janne Porkka Markku Pienimäki Leena Korkiala Tanttu Tarja Mäkeläinen Arto Kiviniemi VTT, Technical Research Centre of Finland 2006

2

3 Preface This report is the first report in four report series delivered in Infra Product Data Model Analysis (InfraPDM, project. The objective of InfraPDM project is analysis of Norwegian product data model and its technology components, the Quadri concept, as well as feasibility study on Quadri concept localisation and uptake in Finnish conditions. Work has been financed by Confederation of Finnish Construction Industries, and carried out under national Infra 2010 research programme ( year Members in the steering group were Paavo Syrjö SML, Heikki Jämsä RT, Jussi Kauppi KUNTALIITTO, Timo Kohtamäki LEMCON OY, Heikki Koivisto TIELIIKELAITOS, Juhani Kuusisto YIT RAKENNUS OY, Martti Kärkkäinen LOHJA RUDUS OY, Jukka Pekkanen RT, Pauli Pernaa SKANSKA TEKRA OY, Kari Ruohonen RHK, Markus Rönty ESPOON KAUPUNKI, Markku Teppo TIEHALLINTO, Pekka Vaara RAKLI, Tapani Karonen SML, Jaakko Heikkilä RAMBOLL, Mikko Ojajärvi LVM, Matti Pekka Rasilainen HELSINGIN KAUPUNKI and Osmo Rasimus TEKES. The project has been led by VTT Technical Research Centre of Finland, where two teams contributed to work: i) Building Informatics (Research Professor Arto Kiviniemi, Senior Research Scientist Juha Hyvärinen, Research Scientist Janne Porkka and Research Scientist Tarja Mäkeläinen) and ii) Road Structures (Senior Research Scientist Leena Korkiala Tanttu and Senior Research Scientist Markku Pienimäki). The foundation of this work has been cooperation; between expert organizations and companies in Finland (Finnish Road Administration FINNRA, Finnish Rail Administration RHK, Vianova Systems Finland, Tekla Corporation, Centroid Sito and Bentley Systems Finland). We are also thankful for Norwegian National Public Roads Administration NPRA for the willingness to share information, and Norwegian Rail Administration and Vianova Systems AS for participation to project implementation.

4 InfraPDM delivered four reports: 1. Objectives and Ramifications of Product Model Based System in Finnish Infra sector Introduces the principles of product modelling and experiences from other industries. Outlines technical, economical and organisational ramifications of application of product modelling in infra sector. Report gives a high level estimation on possible implementation schedule and required budget. Finnish national needs are taken into account in proposal for product modelling implementation plan. 2. Technical documentation of Quadri Concept (Vianova Systems Finland) Describes the following: i) Documentation of product data model and technology components, ii) Norwegian and Finnish road and rail register differences and consequences to system implementation, and iii) Quadri concept, methods of technical implementation and extent of system usage in Norway. Besides the results from Quadri demo project are described. 3. Technical Evaluation of Quadri Concept for Finnish Conditions Technical evaluation focuses on structure, technology and embedded data content in Quadri concept collecting together Norwegian experiences and implementation information. Last chapter aims to giving conclusion on current status of Norwegian Quadri concept.. 4. Infra alan tuotemalliselvitys Yhteenvetoraportti Executive report (in Finnish). The authors express their thanks to each member of the steering group, executive group and technical teams; contributing research and development work parties; and interest and commentary groups. During the past months we have shared much valuable opinions, and let s hope that cooperation still strengthens in upcoming years. Especially we are grateful to NPRA (National road Database NRDB) and NRA (Banedata). We wish that decision makers use InfraPDM results wisely in forthcoming policy definitions. Product modelling has major influence for the whole sector. Espoo, September 2006 VTT research team

5 Contents Preface... 3 Glossary of terms and abbreviations Introduction Background and purpose Finnish and Norwegian infra sectors compared Product modelling baseline Product modelling principles and concepts Experiences on product models in other industries IFC benchmarking Technical properties IFC standard in practice Software implementations Extent of project usage Overview on utilization among participants Experiences and lessons learned Case example Product model based information management in infra sector Baseline for product data model definition Life cycle information management Project definition Design Construction Use and maintenance Archiving Environmental impacts of infrastructures Public registers interoperability and service possibilities The Finnish Road Administration Digiroad Road Data Bank Condition Database Bridge Register Other Road Administration data systems and data registers Current situation in Road Administration registers Finnish Rail Administration Services based on interoprable registries and databases Road Administration einfra concept Other registries and databases... 37

6 4. Conclusions Expected benefits and potential problems of common product data model Benefits Potential problems SWOT Product Model based system in General Norwegian System Projected system implementation schedule and costs Implementation schedule estimation Estimated implementation costs Proposal for Finnish product data model system implementation plan46 References Appendices Appendix A: Experiences, benefits and problems of integrated product data models Appendix B: LandXML data transfer standard (In Finnish) Appendix C: ICT infra based lice cycle process models for road and railway project

7 Glossary of terms and abbreviations Term Definition Source BaneData FINNRA Maintenance model NMA NPRA NRA NRDB NVDB Product data model Product model RHK TEKES Railway data management system, managed by NNRA Finnish Public Roads Administration (Tiehallinto) Data related to use period such as maintenance, corrective maintenance, preventive maintenance and renewal Norwegian Mapping Authority (Statens Kartverk) Norwegian National Public Road Administration (Statens Vegvesen) Norwegian Rail Administration (Jernbaneverket) National Road Database, managed by NPRA see NRDB An information model for product data. A formal specification of product data. (description) An instantiation of a product data model. A product model of a specific infrastructure represents product data about the infrastructure in a form that is defined by a product data model. Finnish Rail Administration (Ratahallintokeskus) Finnish Funding Agency for Technology and Innovation ProIT ProIT 1

8 1. Introduction This report introduces the principles of product modelling in general, as well as experiences from other industries. Technical, economical and organisational ramifications of application of product modelling in infra sector are outlined. Finally, the report gives also high level estimations on possible implementation schedule and financial investments. Figure 1: Outline for Report 1, section marked by green colour is subcontracted to Pöyry Oy and delivered as Appendix A of this report. 1.1 Background and purpose The infra sector in Finland is at the moment exploring the ways of increasing productivity. One of the primary means on the path towards this goal is wide application of product model technology for information and process management, as assumed in the R&D programme Infra The roadmap [Kiviniemi, 2006] defines the role of a product data model and the essential steps for its exploitation. In the roadmap the product data model is the foundation for software interoperability and process integration. It defines the logistics of shared information. Product data model is closely connected to existing public register systems in road and rail administrations. At the moment there is a strong expectation that decision on rail data register updating will be made in near future. Therefore it is feasible to evaluate cooperation possibilities with road data register development.. The roadmap also indicates the importance of common and open standards in information sharing, which is also reflected in software development (to support these standards). 2

9 Figure 2: Roadmap of steps towards better life cycle information management in Finnish infra sector [Kiviniemi 2006]. Similar initiatives have been identified also in other countries, in Norway in particular, where model based solutions for the infra sector have been developed under the name Quadri concept. Norwegian development has taken place without collaboration between the road and rail administrations. The general objective of InfraPDM project is to make study on possibilities and effects that product modelbased technology has and make analysis of Norwegian product data model and its technology components the Quadri concept. The expectation is that based on this study, the necessary decisions for starting development and implementation of product data model for Finnish infra sector can be made. 1.2 Finnish and Norwegian infra sectors compared Finnish the road and rail network administrations are separated from construction and maintenance. Both administrations were influenced by outsourcing to gain cost savings on last decade. Market situation is more competitive in roads, where tendering also covers design phases. There are four railway contractors, VR Track with close to 80% market share, doing construction and maintenance according to pre defined plans. Outsourcing has partly taken place in Norwegian infra sector. Norwegian Rail Administration has outsourced heavy maintenance [NPRA and NRA 2006]. Norwegian Mapping Authority also has carried out unification process in the collection map related data from cities and municipalities. Similar efforts have taken place also in Finland. There are many similarities and differences between Finnish and Norwegian road and railway networks, which are rather identical in size. Air traffic has more passengers in Norway (compared to railways), also freight traffic takes place merely by waterborne traffic. Finnish freight traffic uses more railways. Due to geographical differences routes in Norway also contain greater amount of tunnels and level crossing. Statistics about networks are described in Table 1. The annual budgets in network administrations in both countries are on same level, according to infra2010 / Laura Apilo (see Table 2). 3

10 Table 1: Traffic statistics from Finland and Norway [Tiefakta 2005; LVM 2002; RHK 2004; NRA 2005]. Table 2: Annual budgets in Finnish and Norwegian road and rail administrations [Infra2010 / Apilo]. Another potentially significant difference between the two countries is the nature of the software market in infra sector: in Norway there is one rather dominant design system concentrated, whereas in Finland there are several vendors with considerable market share. 4

11 2. Product modelling baseline 2.1 Product modelling principles and concepts A product model is a representation of real world things in software world. It may exist physically in various forms, e.g. it may be stored in a file or in a database. The key characteristic of a product model is that the things are described and defined as concepts, with attributes, relationships to other things and with behaviour. The things may be physical tangible or not (e.g. bridge or clearance space ) or they may be abstract, e.g. process, environmental impact or quality. A formal definition of concepts (usually as objects in software world) is the basis of any product model; this definition is called product data model. The relationship between product data model and product model is analogous to database schema and the actual data (or template and document). A product model typically employs several types of representation for concepts, e.g. when representing physical things, geometric and topological as well as non geometric properties (such as material, colour, age, ); also, it should be noted that the several geometric representations may exist at the same time (e.g. 2D or 3D). Also, it should be noted, that all 3D models are not product models (if only comprised of geometric primitives, such as lines or surfaces, without any semantics of the concepts they are representing) and product models do not always require 3D geometry (even though it is usually provided). The food chain of model based information management is presented in Figure 3: A real world thing is identified a corresponding concept is defined in data model the concept is implemented in software (as a class) data on an actual thing is stored as an object (of the class) software presents the data to end user. 5

12 Figure 3: Product modelling steps (from conceptualisation to use), VTT/ InfraPDM project. Product modelling is not exactly a science ( a scientific theory may be proven right or wrong, a product model is merely relevant or not ). The first step in assuring that a model will be relevant is finding the boundaries of the Universe of Discourse (UoD) defining the domain of interest in the real world (the things and phenomena) i.e. what needs to be modelled and to what purpose? E.g. from road administration or rail administration point of view, this may include either road network or railway network, respectively (and separately); alternatively, from general infra sector point of view both of these, with a number of other things, could be in the UoD. Another dimension in UoD is defined by the type of information that is relevant for the model; this typically relates to the processes that are expected to be supported by the model. The UoD may be defined to be quite narrow (e.g. early railway design information ) or rather large ( whole life cycle information management for infra sector ). In any case, the UoD must be carefully defined and clearly described, since it is not possible to create the model of everything, and it is always a balancing act: very limited UoD leads to rapid modelling (and use) but may also leave interoperability issues between disjoint models (unless harmonized); larger UoD with longer (stepwise) development phase towards more comprehensive solution may exhaust resources (and patience). Formalism is the definition of modelling methodology and language. It shall be able to capture and define all aspects of the UoD, and it should be both computer interpretable any data model is useful only when be implemented in software as well as human readable since the completeness and correctness of any data model should be assessed before implementation by domain experts, e.g. civil 6

13 engineers. Modelling languages like EXPRESS (used by ISO TC184/SC4 standards and by the IAI) and UML (used by ISO TC211 standards) meet these requirements. Product data model is an information model for product data, a formal specification of product data (ProIT description). Product data model should be complete (100% of the UoD) and exclusive (0% of outside of the UoD). Product model is an instantiation of a product data model, a product model of a specific infrastructure represents product data about the infrastructure in a form that is defined by a product data model (ProIT description modified for infrastructures). For already a couple of decades, product modelling has been applied in many industries, first for internal organisation of data in advanced design systems, and lately also for information sharing between various applications. Typically, these solutions have been built on proprietary technology of strong software vendors. However, as the need for plugging in new types of applications or software form various vendors has increased and so has the demand for openness in interfaces and data definitions. There can be found numerous definitions for openness. Essentially, an open system builds on a modular design and uses open standards for its interfaces. These standards are based on industry consensus, and they are publicly available (free or for a fee), and they are published and maintained by recognised standards organisations. European Union has adopted in "European Interoperability Framework for pan European egovernment Services" (Version 1.0, 2004) definition for open standard [Wikipedia web, open standard]. Following rules should be applied in Finnish infra sector: The standard is adopted and will be maintained by a not for profit organisation, and its ongoing development occurs on the basis of an open decision making procedure available to all interested parties (consensus or majority decision etc.). The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee. The intellectual property i.e. patents possibly present of (parts of) the standard is made irrevocably available on a royalty free basis. There are no constraints on the re use of the standard. Product model standards that are generally considered open are e.g.: ISO (STEP for engineering industries, including aerospace, automotive, shipbuilding, electronics), ISO (POSC/CAESAR for process plants), Industry Foundation Classes (IFC foraec/fm by the IAI International Alliance for Interoperability) and Cimsteel Integration Standards (CIS/2 for steel construction by SCI The Steel Construction Institute in the UK, and promoted by the AISC American Institute of Steel Construction). In the area of geographic information, open standards are being more and more based on the framework of ISO TC 211 (published as the ISO series, which by itself cannot yet be 7

14 considered as a product model standard); these standards are published by national standardisation bodies (e.g. SIS in Sweden) and internationally by the Open Geospatial Consortium (OGC). 2.2 Experiences on product models in other industries A report was written by Pöyry Infra Oy about experiences on product models in both forest and building industry, respectively (Appendix A). The main conclusions can be summarised as: Although product models have already been used for several years by forest and building industries, the use of models is not yet fully implement over the whole industry. 1. The product model has to be based on an international, well established standard and all the main applications used by the industry should support it. 2. The role of the major clients is very important in implementation of a product model. 3. Product models are very effective in design and building phase, but benefits of collecting data of already existing structures is highly doubtful in the short term. 4. A product model should be flexible enough to handle data of different accuracy levels and from various sources. 5. The product model has to be open to all parties developing applications based on the model. 6. It is evident, that implementation of a product model will incur expenses for the industry during the first years; no short term cost benefits should be expected. 7. Introduction of a product model to daily work routines is a long process, time is needed for training and practising of new methods. 8. The main benefit of the product model is interoperability of data (not only visualisation, drawings, etc.). The data needs to be stored only once, it can be used several times by all parties and in all phases (design, build, operate and maintenance), and design work can be decentralised, if needed. Furthermore, the quality of data becomes better by time. Finally, the authors conclude that the IT technology is not (and should not be seen) essential as such ( these industries have always find ways to design, build and manage plants and building, also without product models ), rather a mean to an end which is smooth and reliable exchange of information (for the benefit of the industry processes). 2.3 IFC benchmarking IFC (Industry Foundation Classes) is an open product model standard for buildings developed by IAI (International Alliance for Interoperability). The IFC development started by 12 major AEC 8

15 (Architectural/Engineering/ Construction) organizations AT&T, Archibus, Autodesk, Carrier, HOK, Honeywell, Jaros Baum & Bolles, LBNL, Primavera, Softdesk, Timberline, and Tishman in USA as the Industry Allliance for Interoperability in 1994 and expanded to an open international effort in At the beginning the IAI consisted of 7 International Chapters French Speaking, German Speaking, Japan, Nordic, North America, Singapore, UK and has later expanded with 6 new Chapters Australasia, Benelux, China, Iberia, Italia, Korea. The original vision of IAI was to enable software interoperability in the AEC/FM industry by providing a universal basis for process improvement and information sharing in the construction and facilities management industries. The current vision has expanded into improving communication, productivity, delivery time, cost, and quality throughout the whole building life cycle, but the mission and goal, defining the IFC specification, have remained the same over 10 years. The main reason for the expanded vision was the need to emphasize the business potential of interoperability instead of the technical aspects of the specification. This has also lead to a new brand for IAI; buildingsmart ( IFC specification is based on the same principles and uses the same description language as ISO (Standard for Product Data Representation and Exchange STEP) by ISO TC184/SC4. IFC is compliant to STEP Standard Part 11 (EXPRESS data definition language), Part 21 (Physical File format SPF) and Part 22 (Standard Data Access Interface SDAI). In October 2005 IFC 2x Platform also achieved an official standard status as ISO PAS ( sc4.org/sc4_open) Technical properties The full documentation of all versions of IFC specifications is available on the IAI web site ( international.org/model/ifc(ifcxml)specs.html ). In addition, the web site includes IFC Technical Guide, which describes the model architecture and technical details. This section describes briefly the main architecture principles and content of the specification. IFC data model consists of a four main layers where any class may reference a class from the lower layer but may not reference a class from a higher layer. References within same layer are only allowed within the Resource layer. [Figure 4 and Figure 5]: Domain Model Layer contains Building/Construction domain specific models, which are integrated into IFCs, and mapping of externally developed models to the Core constructs. Interoperability Layer contains the commonly used AEC concepts (building construction specific shared elements). Core Layer contains the Kernel (non AEC specific, most abstract part) and the Core Extensions (AEC specific, abstract part). Resource Layer contains Resources for concepts, described independently from specific usage for AEC objects. 9

16 domain layer HVAC Domain Electrical Domain Architecture Domain Construction Management Domain FM Domain interop layer Shared Bldg Services Elements Shared Spatial Elements Shared Building Elements Shared Management Elements Shared Facilities Elements core layer Control Extension Product Extension Process Extension 2x platform IFC 2x 2x non platform part next candidates out of platform Kernel Architecture short form distribution resource layer Material Property Resource Actor Resource DateTime Resource External Reference Resource Geometric Constraint Resource Geometric Model Resource Geometry Resource Material Resource Measure Resource Cost Resource Constraint Resource Approval Resource Profile Resource Property Resource Quantity Resource Representation Resource Topology Resource Utility Resource Presentation Resource Reference Geometry Resource Figure 4: IFC architecture, IAI Use Domain Models External Domain Models Map Interop Adapter Domain Models Layer The architecture operates on a 'ladder principle'. Use Use Use Use Map Use Use Interop Modules Use Use Core Extensions Kernel Use TypeOf Independent Resources TypeOf TypeOf TypeOf TypeOf Interop Layer Core Layer Resources Layer Any class may reference a class from the lower layer but may not reference a class from a higher layer. References within same layer are only allowed within the Resource layer. Figure 5: IFC architecture principle, IAI The IFC data model consists of several hundreds entities. These entities describe physical building objects, abstract concepts, elements related to AEC processes or actors, etc. (Figure 6). Some entities are AEC or even domain specific, some are generic and could be used in any application area. In IFC 2x3G the model contains also GIS (Geographic Information System) entities. All individual entities are based in IfcRoot and there are three fundamental categories object, property and relationship. Relationships are defined between objects and between objects and properties. IFC specification also includes two entities which enable flexible additions on national or even project level. These are ProxyObjects and PropertySets: The IfcProxy is a container for wrapping objects which are defined by associated properties, which may or may not have a geometric representation and placement in space. A proxy may have a semantic meaning, defined by the Name attribute, and property definitions, attached 10

17 through the property assignment relationship, which definition may be outside of the definitions given by the existing releases of IFC. The IfcPropertySet defines all dynamically extensible properties. The property set is a container class that holds properties within a property tree. These properties are interpreted according to their name attribute. Figure 6: Units of Functionality in IFC2x 11

18 2.3.2 IFC standard in practice Software implementations The implementations of IFC specification are traditionally built for file based exchange i.e. each application participating in an exchange scenario will have a translator for file export and/or import. The file format is following the ISO (an ascii encoding, the so called STEP File Format SPF) or, more recently, also XML encoding (ISO The specifications would enable each software developer writing their own translators from scratch, but in practice, the commercial implementations almost exclusively are utilizing software libraries, toolboxes, provided by thirdparty vendors for import export functions on specific programming platforms (COM, C/C+,.NET and Java most commonly) see international.org/software/tools for IFC developers.html for available products. In recent years, there have been attempts to provide open access to IFC model servers; an example of this concept is the SABLE project ( project.org/~sable/): on top of IFC specification, and web service interface is specified for access. In addition to server side specifications and implementations (as Web Services), libraries are provided for facilitating the implementation for client side applications (C++,.NET, Java APIs) Extent of project usage Despite the general acceptance of the IFC standard in the AEC industry the use of IFC data exchange in real projects has been very limited. The IAI web site documents only 6 construction projects and 5 other examples of the use or support for the specification ( Naturally this documentation does not cover all projects which have used IFC data exchange; for example, Senate Properties has used IFC in 15 pilot projects in Finland and only one of these is mentioned on the IAI web site. VTT s rough estimation is that by summer 2006 the specification has been used in projects globally. However, currently the use of IFC is growing rapidly, especially in Finland, USA, Australia and Norway. In USA General Service Administration (GSA, the owner of all governmental buildings in USA) announced in December 2003 that they will start demanding IFC compliant models by the end of To make this possible GSA has developed detailed modelling guidelines for designers and also a mandatory certification process for the software products which can be used in their projects when the requirement will be effective. There are several reasons for the slow adoption of the standard; for example, lack of development funding of the specification and real market drivers for implementation, AEC industry s fragmentation and resistance in moving from 2D drafting into 3D modelling, and difficulty in measuring and proving the benefits. One reason has also been the constant development of the specification, which has made software vendors uncertain of which version to implement. The latest IFC specification, IFC 2x3G, has developed through 10 earlier versions, and 8 of these versions have been supported by commercial software implementations since The largest publicly documented implementation base is still for version IFC 2.0 (published in 1999, supported in total by 31 released products, project.org/blis_product_public.html). Other versions 12

19 have been less successful in implementation support although currently the focus is in IFC 2x3 and 2x3G implementations Overview on utilization among participants As documented also in the report Experiences, benefits and problems of integrated product data models several commercial software products support IFC data exchange at least on some level. Also the IFC specification and its data exchange use cases cover a wide range of practical needs in the AEC process, for example: Architectural design and spatial management (for example ArchiCAD,, Bentley Triforma, AutoDesk ADT and Revit) Structural design (for example Allplan Engineering, Bentley Structura and Tekla Structures) HVAC and electrical design (for example MagiCAD and DDS) Design integration, model and design checking (for example Solibri Model Checker, NavisWorks and CSIRO Design Check) Energy, comfort and lighting simulation (for example Granlund s product family and IDA Indoor Climate) LCA and LCC analysis (for example Granlund s product family and CSIRO LCAdesign) Quantity take off and cost estimation (for example Tocoman ilink, Enterprixe and Graphisoft Constructor, CSIRO Estimator) However, in many applications the implementation quality of the IFC support is not on a sufficient level. The main reasons for this are that 1) the certification process has not been robust enough and 2) the use of IFC exchange in real projects has not yet been active enough to reveal all major problems. As a consequence of the insufficient implementation quality the projects using IFC exchange still need significant technical expertise in solving the practical problems. Thus wide adoption is not yet possible, the current adoption is on the innovator and early adaptors levels; early majority is still waiting [Figure 7]. 13

20 Figure 7: Geoffrey Moore s Chasm Experiences and lessons learned The main lesson learned from the slow deployment of the IFC specification is that the original schedule expectations in the IAI were totally unrealistic; The IFC object based technology, which the Industry Alliance members are demonstrating in Autodesk's booth, will be implemented in real applications by both our industry and third party application developer partners worldwide during the next 12 months. This could make the ideal of global interoperability with shared information throughout the building life cycle a reality by next year's A/E/C SYSTEMS show. (Ian Howell, director of AEC industry marketing for Autodesk, June 5 th 1995). In reality, first products with limited IFC support were published four years later, in The development of the specification started when modelling was extremely rare in the AEC industry. This meant that there was no real market demand for a data exchange standard. However, the development created basis for the adoption of modelling and also for advanced technical development, such as the IFC Model Servers. In addition, IFC specification has gained recognition now when the industry is moving towards modelling and thus it is less likely that there will be several competing standards in the area. From that viewpoint the early development was probably the right decision, only the public message following from the expectations was too optimistic and thus frustrating to the industry. Obstacles and negative actions in the IFC development and deployment One result from the significant underestimation of the complexity of the development has been a constantly insufficient budget and difficulty to find the funding from the continuity of the work from the industry. In addition, the emphasis on complex technology issues in marketing has been a wrong message; a data exchange specification is not an end user product, industry needs robust software tools which work without detailed knowledge of the standard. As often happens, the early demonstrations are successful and make people believe that the problems are basically solved. However, delivering full scale industrial applications is very different compared 14

21 to the toy problems solved in the demonstrations. The history of ICT development includes many examples of this phenomenon, such as artificial intelligence and expert systems. It took many years before the IAI started to focus enough into the implementation of the IFC specification. This problem includes many aspects. A crucial factor for the software vendors to even consider the implementation is the market demand; will the IFC support real affect to the sales. If not, there is no incentive to invest in the implementation, but to develop something else which has real effect in the market position. Since the market demand has been minimal, the constant change of the IFC specification and promises of the next improved version immediately after the previous version was published has been detrimental by making software vendors uncertain of which version to implement [Figure 8]. Also the technical support for implementation and documentation of the implementation agreements has been insufficient. Last, but not least, the quality control of the IFC implementation has not been robust enough. This has lead to a situation where end users can be disappointed in the results if they try to use a certified product and face serious problems in data exchange. The end users cannot differentiate between the quality of the specification and quality of the implementation. Thus, the problems affect strongly in the reputation of the specification. Figure 8: History of the different IFC releases Despite the problems mentioned above, technology is the easy part. The speed of adoption is very dependent on human factors, such as industry processes, legal agreements between companies, people s working habits, priorities and skills. These are much more difficult to change than the technical environment, especially in a fragmented business environment, such as, AEC industry. Bringing a systemic innovation innovation affecting many players in a value network, such as moving from traditional documents into integrated models is very difficult and faces many obstacles [Taylor and Levitt 2005]. This means that changing processes in an industry branch and creating a standard for the new at the same time is a very difficult task. There are no real market drivers, on the contrary, many companies will actively opposite and challenge the change. It is difficult, if not impossible, to prove the real 15

22 implications in the processes and business before the change has happened in large scale. This creates uncertainty in the companies. Is the change a zero sum game where someone will lose if someone wins or is a win win situation possible? Investing in a new technology and the learning processes will inevitably cost something; who should pay for it and how long will the payback time be? Most companies will wait until someone can show at least some evidence of success. Benefits and positive actions in the IFC development and deployment As a consequence of the original Industry Alliance the IFC specification was in the early phases seen as an effort dominated by Autodesk, but the wide industry participation and neutral workgroup has gained an impartial status for the specification in the industry. Visionary work in IAI has created an extensive specification which is sufficient to support many of the real business processes in the AEC industry. It also created basis to develop new products, such as, model servers and model checkers, which are not domain specific as the traditional AEC applications. Expandability of the IFC specification property sets and proxy objects gives flexibility on the national, and even on a project, level. This is important in the AEC industry which is still strongly based on local actors and regulations. Getting the IFC specification into the core of national or industry programs or as a demand of a key actor has been crucial for the adoption of the standard. For example, Tekes, Senate Properties, Singapore Government, GSA and Norwegian buildingsmart program have by their actions affected globally in the acceptance and implementation of the IFC specification. Some key actions in development and deployment of an industry standard based on the experiences of the IFC specification Strong drivers, preferably major clients or industry leaders are necessary for the successful adoption of a standard Chasing a perfect solution is detrimental, instead a standard should be developed step by step and starting to use what is already there by starting data sharing with useful minimum Concentrating on use and implementation quality and ensuring sufficient certification process is a necessity Moving into modelling can provide internal benefits without interoperability, but for the industry as a whole interoperability is crucial It is important to identify and communicate the benefits even if they cannot be measured exactly Involving as wide group of actors as possible is crucial; integration requires wide acceptance Publishing the success stories speed up the adoption significantly; envy and fear are powerful drivers for a change 16

23 Separating the development and maintenance of the specification from the software implementation is crucial to achieve an impartial environment and acceptance in the software market Case example The best publicly available documentation of the use of IFC data exchange is still the first real use case; HUT 600. The project consisted of an expansion including the new main lecture hall for the main building of Helsinki University of Technology, a landmark building designed by Alvar Aalto in 1960s. The testing of new software tools and methods in this project was funded by Tekes as a part of the Vera technology program in The following description of the project is mainly from the CIFE report [Kam and Fischer 2002]. The HUT 600 project team constructed and maintained product models with explicit knowledge of building components, spatial definitions, material composition, and other parametric properties. During the early schematic phase, product model based software and IFC data exchange allowed the project team to shorten the time for design iteration, develop a reliable budget for effective cost control, and eliminate the need to re enter geometric data, thermal values, and material properties as different disciplines contributed to the design progress. In addition, visualization tools such as photorealistic rendering software, Virtual Reality Experimental Virtual Environment (VR EVE) fostered early communication among the end users, owners and the project team, who then captured valuable inputs and effectively translated the client s intent into long term values. Building on the resulting efficiency and time savings, the project team was able to conduct a variety of in depth life cycle studies and alternative comparisons. The HUT 600 project team constructed and maintained product models with explicit knowledge of building components, spatial definitions, material composition, and other parametric properties. During the early schematic phase, productmodel based software and IFC data exchange allowed the project team to shorten the time for design iteration, develop a reliable budget for effective cost control, and eliminate the need to re enter geometric data, thermal values, and material properties as different disciplines contributed to the design progress (Figure 9). In addition, visualization tools such as photo realistic rendering software, Virtual Reality Experimental Virtual Environment (VR EVE) fostered early communication among the end users, owners and the project team, who then captured valuable inputs and effectively translated the client s intent into long term values. 17

24 Figure 9: Examples of simulations in the HUT 600 project, Granlund Building on the resulting efficiency and time savings, the project team was able to conduct a variety of in depth life cycle studies and alternative comparisons on thermal performance, operation costs, energy consumption, and environmental impacts. Compared to a conventional approach, these relatively seamless data exchange and technology tools substantially expedited design and improved the quality of interdisciplinary collaboration. The improved design, visualization and communication methods empowered the building owners to better align the long term facility values with their strategic plans. As desired, most benefits occurred during the early design phase. Even though the integrated modelling improved upon conventional practices in terms of design quality, project risks, and lifecycle values, the project encountered technological, cultural, and business barriers to extending the benefits. Project participants in the HUT 600 project could have enjoyed further benefits if product modelling tools supported revision handling, two way exchanges, simpler mapping of data formats from exporting to importing applications (Figure 10), and if IFC compliant software tools were extensible and robust. 18

25 Figure 10: Data exchange process in the HUT 600 project, CIFE/Stanford University Despite of the technical problems in the HUT 600 project the positive results convinced the owner, Senate Properties, to continue the use and testing of interoperable product models in 10+ new projects The focus of the tests has been different in different projects varying the use of product models in different phases by different actors. Currently Senate Properties is planning to start demanding IFC compliant models in 2007 and preparing a public announcement about this requirement. 19

26 3. Product model based information management in infra sector 3.1 Baseline for product data model definition National infra sector has witnessed many attempts to raise its productivity during last years. Latest message was announced on 23 rd of August 2006, when FINNRA and RHK informed about new practices: clients are requiring the use of Infra classification system and IK cost management system in their projects, starting January 1 st Data exchange has also new breeze blowing: after May 1 st 2007 Inframodel documented LandXML format, if approved in piloting project, is scheduled to enter the practice as required exchange format (more information on LandXML in Finnish see Appendix B). Earlier experiences show short term solutions by improving file based data exchange between various design applications. There are two basically different approaches on improving file based exchange: first is to unify currently used various formats and the second one is to provide tools to ease transformation between formats. First approach has been used in Finnish Inframodel projects ( and ). Design data exchange requires conversions and causes additional costs for participants. It is also not unrealistic to say that applications and solutions are currently interoperable by nature in life cycle level only when delivered by same vendor for internal use in one office. However, file based data transfer can be successful between certain project phases and/or vendors products. Inframodel projects generated a documented LandXML format for this purpose (see Appendix B, in Finnish). Second approach to data exchange is by means of providing format conversion tools or interoperability software. One example on this is provided by Safe Software [Safe Software]. Their technology includes stand alone FME (Feature Manipulation Engine) software package for about 150 data formats on conversions and licensing possibility to embed technology in other vendor products.. National Infra2010 research and development programme ( is guiding infra sector towards utilization of product model technology, encouraging adopting an ICT platform enabling life cycle information management. Transition is expected to follow fair business models and be based on open standards. Two major stakeholders in Finnish infra sector, FINNRA and RHK, have expressed slightly contradicting priorities, as illustrated in Figure 11 [FINNRA and RHK discussions, 2006]. 20

27 Figure 11: Priorities for life cycle phase support in Finnish road and rail administrations [FINNRA and RHK discussions, 2006]. Finnish Road and rail Administrations (FINNRA and RHK) have shared vision of striving for whole life cycle development where design and other earlier phases are seen as potential savings foundation. Especially FINNRA states that road projects are enhanced in project level supporting 3D modelling where data is stored to databases throughout the project life cycle [FINNRA interviews, 2006]. Therefore priorities are targeted to advance early phases of projects project definition, design and construction. RHK is in a position where they need to make decisions about updating existing register systems. [RHK interviews, 2006]. Present railway databank is distributed to many individual databases and strong development needs exist especially towards centrally managed system. Besides operation environment in railways changes, year 2007 opens rail transportation markets for competition in Finland and European Union is also improving practices. Changes validate update need of existing railway databank. It is essential to develop system that is flexible and updatable for new reporting needs of network information. For example network statement has to be updated annually. System also has to enable interaction between new participants; It is probable that when markets open more territorial borders have less importance. 3.2 Life cycle information management Efficient use of product modelling technology leads most probably also to process changes. During InfraPDM a tentative ICT based lice cycle reference process model for road/railway projects was made (see Appendix C). Projects include many kinds of data having various status and purposes. Is one product data model specification enough for the infra sector? Norwegian practice implies two, or even more, to support product databanks (or model servers) for managing the data throughout the life cycle in different 21

28 application areas (road and rail). Tighter competition between vendors in Finland also promotes the assumption that there may emerge several implementations, using different vendors technologies. It is possible that these model servers are based on same open specifications, and potentially using same technology components. However it is important that phase models are recognized in specification work. Figure 12 demonstrates the integration between management of various databanks. Integration requires predefined content in each server, and storing data subsets once (accepted phase models such as various plans; general plan, engineering plan etc.). Archiving can be linked to information deliveries. Figure 12 also introduces the various four databanks: 1) Register databank, 2) Project information databank, 3) Maintenance information databank and 4) Archives. The status of various archives most probably changes. Figure 12: Life cycle information management administration of infrastructures, VTT/ InfraPDM project. In the long run, the objective is interoperability of all ICT systems used throughout the life cycle; including public registers and databanks, project data banks (or model servers), applications (initial data, design, site measurements and automation, operation, maintenance, quality control etc.) Project definition Initial data for design is received from numerous sources (such as National Land Survey of Finland, cities, municipalities, Geological Survey of Finland, maintenance, land use planning, various experts etc.). Roughly the data is divided to 1) general information, 2) project information and 3) maintenance information. Problems in receiving initial data in right format for following phases are traditionally caused by deficient interoperability of used software and tools although the situation has been improving. 22