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

29 Statistically almost 80% of the infra sectors current projects are maintenance. It is normally necessary to complete insufficient basic information (advanced surface and ground survey techniques etc.) and collect information about intersecting other networks (such as tele, cabling). The quality of end result of design is a consequence of adequate initial information. The backbone of product modelling is the definition of needed initial information and automating delivery and production process. Norwegian practice proves that current network information and geographic information (from Norwerian Mapping Authority) can be used as project initial data. In Finland the importance of sufficient initial data is also recognized, FINNRA is defining the content for road projects required electrical initial data Design Presently various design solutions are lacking interoperability throughout the process from network planning to engineering planning. Certain format development efforts are directed to reducing conversions, such as LandXML exploitation in Finland (for more information in Finnish see Appendix B). Information flow in design consists from various plans; in roadway development there are e.g. network plan, location study, general plan, road plan, engineering plans. In railways content in rail plan is closer to engineering. New construction and renewal projects have separated design software that are basing on different data model structuring. Qualitative data rather often includes also geometrical 3D information in product modelling. In the future interplay between distributed participants, owners, consults, specialists and contractors, is managed through model servers. Each participant has access to needed phase models during various design steps. Centralized and standardized platform opens new doors for gaining more reliable cost estimates on alternative comparisons, calculating environmental profiles, analyzing durability life values and imposing new owner defined performance based requirements to solutions. Fields competitiveness is also depending on how well the infra sectors object type catalogues are transferred from paper to electrical. However this don t mean that solutions get more and more limited; object type catalogues enable also differing from known solutions and making of innovations Construction Interaction between designing and construction has been increasing. Main outcome from construction back to design are as build measurements that designer delivers automatically or semi automatically to public registers and databases. Site automation has become common technology under the last ten year, other Nordic countries are further in implementation than in Finland [Oulu 2006]. The recognised benefits of site automation are: increased capacity of machines, improved sork environment and methods, better quality (decreased variation in structure), less interruptions of traffic and use, decreased quantities and savings in site measurements, site management and control and improved safety. As built documentation benefits for maintenance or following design phases. 23

30 Machine automation needs accurate, machine type specific, 2D or 3D information for each working task/process. At the moment processes are still partly manual; requiring conversions and modifications. Integrated product data model enables wider exploitation of on line design and working process. Machines can provide as build and measurement information back to designer, who has more capabilities to update engineering plans. Interaction to machines operates in application level; data is presented in simple enough format (such as XML based formats, e.g. LandXML) that machine automation and steering systems can make the most of. At the moment common standard is missing. Practically for this means two things: all applications should have an interface enabling data transfer and defined data is accurate and precise also in product model. Mobile data transfer also establishes new possibilities for quality monitoring and inspection Use and maintenance Use and maintenance is the most the relevant life cycle phase that should be taken account also in implementing integrated product model. We should realize that maintenance is actually part of the design. Development of functional maintenance requires lots of data produced during design. Design data is sort of frame where dynamic route condition data, traffic data and other relevant maintenance data is associated. This data can be automatically (or semi automatically) sent to public registers. Public registers are used for storing the real time information. Maintenance has also lots of potential to make most out of efficient measuring techniques (such as 3D laser scanning and ground penetration radar). Measuring information is also important initial data to renewal projects. Integrated product model can also exploit automated data collection services like road weather stations, road condition cameras, maintenance equipment and mobile measurement devices. It gives a possibility to share and distribute information efficiently, both landline and mobile (internet) for road users, road administration and other relevant parties. Can we learn from other industries? Is it possible that infra sector could develop maintenance manuals like in housing industry? It is evident that maintenance needs updating. Industry needs standards and pre defined action catalogues for managing relevant data (e.g. topology, measurements, actions, condition and historical data) Archiving Currently the role of archiving is prescribed by laws, and dot performed as a voluntary value adding task. Unfortunately the result has been that information is archived mostly in papers and in unorganized order. Especially in heavy maintenance or new construction projects (such as E18 in Finland, see it is very important to have access to design content of past projects. At the moment government offices are obliged to ensure the usability and conservation for certain storage time on official information (such as design documents, plans, tendering and purchasing documents). If infra sector in Finland sets future targets on transition towards product modelling it is obvious that the role of archiving should advance and support this. 24

31 3.2.6 Environmental impacts of infrastructures Environmental values are considered highly important also in infra sector. The Environmental values and eco indicators in infra construction study delivered a method for the estimation of environmental impacts in infra construction (road, railway, street and water way). Environmental impacts are estimated during many life cycle phases design, building, maintenance and management of infrastructure [Korkiala Tanttu et al. 2006]. Developed EIMI system (Environmental Impacts of Infrastructure) contains eleven environmental impact categories including environmental stressors that are mostly quantifiable indicators (see Figure 13). In the assessment of the environmental impact different impact categories are arranged according their relevance (weighting values). Figure 13. The EIMI assessment method, tree hierarchy [Korkiala Tanttu et al. 2006]. 25

32 EIMI system shows an example about developing comparison systems for infrastructure solution basing other values than costs. Environmental values should be recognized also in structural alternative comparisons while deciding route s main directions, designing various alternatives and considering tenders. Proposed assessment method isn't finished but the ideology suits well to product model based technology platform. It can offer a feasible development platform for new and innovative solutions perceiving environmental values and support sustainable development. 3.3 Public registers interoperability and service possibilities The Finnish Road Administration The Finnish Road Administration (Finnra) has about 130 different production systems and databases which utilize road network and structure data. Due to the long development history of different data systems there are many kind of methods used to organise data into integrated road data systems. Several data banks are serving well the purpose they are designed, structural design usable and data gathering is consistent and secured. They are mainly Oracle databases but there are also data storages which only save the measured or monitored data in textual files. In the following chapters is described the basic data registers used in road network management of Road Administration Digiroad Digiroad is a national database which contains precise and for certain purposes also accurate data on the location of all roads and streets in Finland as well as their most important physical features. The Finnish Road Administration has a responsibility to develop and to maintain the Digiroad system as well as to make all contracts around the Digiroad. [ To support the Digiroad system there enacted a special law (991/2003) and a decree (997/2003) by Parliament. The legislation was to clarify some issues concerning responsibility of system maintenance, the contents of the register or the data transfer from different data producers. The Digiroad is young product developing project started in 2001 and the system was completed in December The Finnish Road Administration provides Digiroad data services for all users (companies, public and private instances) interested in its data. The Road Administration also maintains and updates the data in the Digiroad system in co ordination with other data producers. The main data producers are Road Administration (public roads), National Land Survey (geometry and private roads) and municipalities (streets). The main data contents is planned to be updated with the delay of some months. [Storsjö 2005] Data import to system is based on automated batch procedures. Unfortunately there are quite a lot of manual editing required to ensure data quality and to implement the updates also to the rather complicated data structure of the reference chains. 26

33 Figure 14: Digiroad data interfaces between producers and users. Digiroad describes the geometry and physical features of roads and streets in Finland. It is almost total comprehensive database on Finnish roads and streets (covering a total of km). It provides e.g. the following data: The official name and number of road The location of road The width and type of pavement of road The number of traffic lanes Speed limits Bridges and tunnels Parking facilities and lots Restricted turns and access Restrictions as to the width, height or weight of vehicle Bus stops Freight and passenger terminals Street names Building numbers Detailed listing of subjects is available on Digiroad website. Digiroad is doesn t produce new data. It is only a data platform gathering data from several data bases. Earlier specific data has been saved with a varying quality in several data bases which have been maintained by different organizations. The very Road Administration has all together over 100 data register systems and most of them include some kind of geographical information. The Digiroad is planned to promote development of transport telematics in Finland. According to project team Digiroad makes the following activities possible at national and local level: Pre trip route planning (optimization, length, cost, alternatives, fixed points) On route navigation (fastest, quickest, least motorways, most motorways, detours, ad hoc route changes, POIs) Guidance to services (parking, fuel, accommodation, culture, sports) 27

34 Public transport services (routes, timetables, costs, arrival times, trip chains) Logistics aids (raw materials, delivery, timing, predictability, mode changes, costs) Route guidance for fire and rescue services (routes, route alternatives, obstacles, trip times, addresses) Traffic control (information services, daily traffic control, preparation for special events, emergency control) Intelligent Speed Adaptation (ISA) (comprehensive, up to date national coverage of speed limits) The system also offers possibilities for traffic management, driver information and road maintenance tasks to a limited extend. The Digiroad data will be homogenous in content, detail and accuracy throughout the country with respect to road class. Data content has been designed to primarily serve route planning and navigation purposes. The GDF standard and ISO TC204 has been used as a guideline for data content and classifications. The database will have a unique road element indexing system that will be the basis and standard for interfacing with other data bases. Most Digiroad features are stored without their own geometry, as road attribute data that refers to certain locations in the road network. (certain reference chains). GIS software dynamically places the (point or line) features along the referred reference chains and thus displays the attribute data as points or lines. The data in Digiroad is tied on road center line. The center line geometry is composed of traffic elements. The Digiroad traffic network is based on these traffic elements. The length of the traffic element is mainly the part of the road between two intersections, but they can be also shorter. The road characteristics are described with the attributes of traffic element. The reference chains are linear referencing of Digiroad. The reference chain is formed by combining the geometry of several traffic elements. Typically the formation of reference chain is based on same road number or street name. In large measure Digiroad data is attached to reference chains by using the dynamic segmentation. The dynamic segmentation has not own geometry but it is located dynamically in the network with reference chains. In this way every traffic element does not need attribute information. With this definition the segment can also be point (like bus stop) or area (like car park). So the Digiroad data model is designed in accordance with the following rules: Traffic elements are defined from intersection to intersection Attribute data will be saved using dynamic segmentation Attributes are defined separately for each direction Attribute data is referenced on road elements using relative distance segmentation Geometry and attribute data are carriageway specific and not lane specific [Digiroad, Tietolajien kuvaus] 28

35 Figure 15: Digiroad data content and structure basics. Every road or street in Digiroad is rated in a functional class. These functional classes are utilized in the planning and operation of the road network for instance, in route planning, navigation, and optimization of traffic when the goal is to direct traffic primarily to preferred routes. The functional class of a route is based on the importance of the road or street in the flow of traffic. Its purpose is to describe the level of service of the route for the flow of traffic and, on the other hand, make it possible to direct traffic to the preferred route. The following quality specifications have been set for Digiroad [Digiroad description]: The database will not contain real time data Maximum updating cycle will be approximately 1 3 months Anticipated changes may be pre coded to take effect at a specified time Accuracy of geometry, 1 3 meters Accuracy of attribute data, 5 10 meters Road Data Bank Road Data Bank (RDB) is designed for Finnish Road Administration operative road maintenance use. Register contains all public roads and pedestrian and bicycle ways in Finland. Data in the RDB is arranged with road numbers and road part numbers between the intersections or some other discontinuations points (nodes). RDB contains information on road history, geometry, classifications, circumstances, materials, traffic volumes, and traffic accidents. All data is presented mainly in 100 m sections using dynamic position system from the beginning of the road. Only the nodes have global horizontal coordinates (according to KKJ system). Data is maintained by Finnish Road Administration. 29

36 Road Data Bank is the main source for many other Finnish Road Administration data systems. It is used as a background tool for Condition Database, Pavement Management Systems (PMS), Investment Programming Systems (HIPS, HIBRIS), traffic and accident data systems Condition Database Condition Database contains information about paved roads maintained by Finnish Road Administration (about km). Rut depth, damage and bearing capacity information have bee saved into register since 1989 in the sections of 100 m. Later more measured condition parameters have been added to the register. Nowadays Condition Database contains more than 200 different parameters/records. The total size of the database is now over 6 GB. The data can be listed into the following groups: service ability (ruts, evenness (IRI), roughness, slopes) damages (several kind of damages) bearing capacity (Falling Weight Deflectometer measurement) ground penetrating radar. Figure 16: Data flows around the Road Administration s Condition register. The Condition Database is totally composed data base. A lot of road data (general information and addresses) is transferred from Road Database to Condition register. The measured and monitored data is updated directly by measuring organisations. The rut and evenness measurements have been done km per year, damage investigations km and FWD measurements about km. The condition data is used mainly for road network management analysis with Pavement Management Systems (PMS) to follow road network condition trends for the design of rehabilitation actions for the quality control of contracts. 30

37 The condition Database is based on Oracle 9i format. The database can be used with special software by persons having the user rights for the data base. The data can be searched with different criteria and the selected data can be saved to Excel files. Also one road rehabilitation analyses and planning software (Road Doctor) has direct access to the Condition Database Bridge Register Bridge Register is the basic information source for all Finnish Road Administration bridges. The Bridge Register contains information on: Bridges on public roads Finnra s pedestrian bridges Finnra s culverts (span width 2.00 metres) Bridges on other roads and streets maintained by Finnra Bridges on transit roads, owned by communities National heritage bridges Bridges on private roads, subsidized by the state Abolished and adopted bridges. Bridge Register contains administrative, structural and traffic data for bridges. Register has information of damages and deterioration detected during the inspections, their exact location and extent are also recorded. Information on the effect of the damages on bridge bearing capacity and on repair urgency is evaluated and saved. Also historical data and information on previous repairs and their realised costs are gathered for further research and bridge age behaviour modelling. There is also saved photos which have been taken during bridge inspections. [E. Vesikari, 2000] Figure 17: Bridge Register, damage information screen. 31

38 The regions of Road Administration are responsible for the basic data of Bridge Register and for updating the data of repair works. The most part of the register data is public but there is also some confidential not published data Other Road Administration data systems and data registers In addition to above basic data registers there are several other registers, systems and information sources which are dealing with the road management. Especially in road planning the following sources are used: maps and other geographical information measured and monitored information (climate and weather, road condition, structures and materials) videos and still photos soil and ground survey information road network maintanance plans prior road (construction) plans equipment and device information materials of several interest groups (National Land Survey, municipalities, energy companies, Finnish Environment Institute, Population Register Centre, Statistics Centre). Figure 18: Measured and monitored information in road rehabilitation design system. All kind of geographical information has a very important function in road planning. The geographical information is the entirety which describes object s position, characteristics and contact information in reality. Geographical information can contain data e.g. about land forms, natural resources, land use, land ownership, settlements, traffic and community networks, environmental conditions. The common feature is that data can be presented at coordination system and thus illustrated on maps. 32

39 A geographical information system (GIS) is a system for creating, storing, analysing, managing and displaying geographically referenced information and associated attributes. The geographical information system of Finnra is composed of several data sources. These sources are not collected into one system. The GIS of Finnra is concentrated to control the four most important entireties [Väyläomaisuuden hallinnan käsitteistö]: Register of Buildings and Dwellings (Population Register Centre) Genimap s AT and GT maps, Finnish Road network, nomenclature National Land Survey s material (base maps, street addresses etc.) Finnish Environment Institute s material (natural conservation areas, groundwater areas Current situation in Road Administration registers The data processing systems of Finnish Road Administration are evaluated as high level in the international audition year So Road Administration has at least good basis for road management to do defined quality for customers. Road Administration actively carries out plans to develop common data resources, integrated services and consistence of working methods in data processing. [Ratahallintokeskuksen ja Tiehallinnon evaluointi, 2006] In the development plan of data processing [Tiedon hallinnan visio ja strategia, 2002] is described a vision, which will reach for that data is common resource for citizens, customers and partners that service level of data processing systems is so good that it will increase the co operation and interaction between Road Administration and its interest groups that services are independent of time and place. There is some functions in road management sector which are weakly supported by common data processing systems or where data transfer is inadequately organised. The material of previous road plans creates main gab in data transfer. After the planning process (after the building) the plan data is today saved only manually and the filing is not systematically organised. Even the instructions are not common. 33

40 Figure 19: Main data processing registers and systems in road management, VTT/ InfraPDM project.. The information of prior road plans is a real trouble with the design and planning of the road rehabilitation. Also the condition data measured on pavements (e.g. FWD measurements, GPR data, PTM measurements) is not saved systematically and is many cases difficult to get as an initial data for design purposes. Some new data sources will every now and then appear on the markets. Some times it takes a lot of time until the data gathering, transferring, saving and utilization is arranged with effective manners. In this sense the data processing with road still photos is current topic in Road Administration. Data transfer between organisations may induce problems. The data systems of civil service departments, cities and other municipalities, energy and telecommunication companies hardly ever are able to communicate with each other. Due to non compatible data formats the data has to be handled manually, when it can not be transferred digitally in any way Finnish Rail Administration At the moment the Finnish Rail Administration has over 30 different databases and systems that include data about the railway network. The registers include real data bases (mainly Oracle), spreadsheet files (mostly Excel) and manual text files and drawings. Although the most of registers are kept up by Rail Administration there are furthermore several other instances collecting and maintaining the data (VR Track Ltd, VR Group Ltd, maintenance companies, design firms, contractors). The large number of registers and systems has problems with updating and securing the correctness of the data. The main registers are listed in the Table 3. 34

41 Table 3: Finnish rail registers [RHK 2006]. Register name Registers maintained by VR Track Ltd Track area information Railway statistics and maps Main tracks (superstructure) Sidings (superstructure) Obstacles for transports with extended vehicle gauge Railway level crossings Rail faults and breakages Weak soil Sections in rock cuttings Tunnels Bridges Culverts Database for inspection of track geometry Railway Photo Service Track geometry database Track enbankment soil frost areas Schematic charts of stations Turnouts (switches) Braking capacity monitoring system/signal & track info Other data documentation Level crossings Weak soil & ground data Crossings of power supply lines, water pipes etc. Real estates and buildings Catenary Electric point machines Marshalling yard lighting Contact wire measuring reports Data of hot box detectors Remote control of catenary Private sidings Pile framings and concrete slabs Format Oracle table Excel spread & Autocad pic & Oracle table Oracle table, Excel spreadsheet Oracle table "Erik" database, technics unknown Oracle table Oracle table Excel spreadsheet Oracle table Oracle table Oracle table Oracle table Oracle table IT application & jpg pic Oracle table Excel spreadsheet Pdf document Oracle table Oracle table & text file Two different systems Several documents / registers Excel spreadsheet KHJ system, ESRI application Cad pics / Excel spreadsheet Excel Text reports, partly CAD pics Paper reports Unknown Unknown Excel spreadsheet Excel spreadsheet The Finnish Rail Administration has an ongoing task to build an information system for network data, which consists of operational databases and a data warehouse. The most essential task for the information system is the integration of rail data and development of positioning systems. The goal is that in the future system would have a real time and interactive electronic tool which could be used for managing the infrastructure and other information of the railway network. The present day registers will be linked together by common interfaces. One of the main tasks is the definition of interface specifications and harmonization of dispersed data. The functional requirements specification on the data model will be done during the beginning of year The adoption of the new system will probable occur during the years [Rail data system, M. Tuominen 2006] The rail data base under development will have the following features and possibilities [Mäkitalo et al. 2005]: follow up/control development of rail network condition to schedule and optimize the future needs for maintenance and replacement investments to set traffic restrictions, speed limits, load limitations traffic and transport planning and logistics needs for new railway companies (real time railway capacity, limitations, construction sites) needs for passengers (network geography, speed rates, travel times and schedules) needs of other authority systems commitment for maintenance contractor work tasks. 35

42 Other data users Reports, quaries Map interface GIS server Track condition analyses Data Warehouse Measurement Data Other Information Basic Network Data Other database Other database Environ Mental Data Maintanance Data Operative databases Other database Data Validation Data Sources Origin: M. Tuominen / RHK Figure 20: Goal for future register system of Finnish Rail Administration. The system of the Rail Administration databases will have some similar features to the Finnish Road Administration s databases. The future rail database system will have more capabilities to serve railway mantanance and planning tasks than does today s road network registers. [Mäkitalo et al. 2005] Services based on interoprable registries and databases Road Administration einfra concept The development of the procurement methods has a central role in research and development program of Finnish Road Administration. Road Administration is generating more innovative delivery methods by developing new product and service models, new offer evaluation arguments and principles to select a service producer. An important part of these is to develop the data processing of procurements. Road Administration has named development projects of data processing as eprojects (eprojektit). There are several co projects belonging to eprojects. The section is dealing with the goals of road network management and the role of data processing as part of it. The objectives for the data management processes and the actions to be taken to achieve them are defined in several etienpito projects. erakenteet section offers the support for road management processes as a form of data processing services. 36

43 Figure 21: eprojects of Finnish Road Administration. einfra co project will develop the ICT based solutions where the main task is to define basic ICT architecture. According to planned schedule in 2010 databanks and information should be in joint use, in accordance with the information model of an open infra domain. Information service is supplied by service providers. Consultants are used in procurements, and they carry out various types of tasks linked with procurements, as required by the customer Other registries and databases Other existing Finnish registers and databases have to be taken into account while developing the road and rail databases. Solutions must be integrated also with these to ensure better data quality and information management. First example considered here is National Land Survey of Finland. NLS Finland carried out a remarkable real estate and property register update that was completed in 2005 [KTJ]. The new system, in Finnish KTJ (Kiinteistötietojärjestelmä), was specified and implemented internally. Data updates to register, e.g. properties and locations, are executed by municipalities. Realized system benefits are improved information services for users and decreased formats in data exchange. XMLbased data transfer (GML) is applied in KTJ system. Similar direction was also exposed by Norwegian Mapping Authority [NMA 2006]. The Association of Finnish Local and Regional Authorities [Kuntaliitto] has done unification effort in classification and feature coding of topographic data and geographic data in a municipality. National Land Survey of Finland has published description and metadata of their topographic data base [maastotietokanta] to help stakeholders adapt to it. The KTJ [KTJ], Kiinteistötietojärjestelmä in Finnish, system of National Land Survey of Finland offers unified access to land property data. 37

44 4. Conclusions Finnish infra sector has big expectations of product model technology in the future. We should remember, though, that experiences from other industries have shown that transition towards more productive work processes with wide exploitation of product model technology requires a lot of time and a lot of effort. The industry needs strong leaders to ensure that standards are developed and agreed upon, and also implemented in software tools and finally used by practitioners. 4.1 Expected benefits and potential problems of common product data model Benefits Based on the experiences from forest and building industry (Appendix A) general benefits can be summarized as: 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. Similarly, as seen in IFC benchmark study, some new potential business opportunities can emerge with product models (Chapter 2.3): 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. Also, the Norwegian road and rail administrations reportedly [Infra2010/Apilo 2006] have seen the model based information managent benefial for themselves, their supply chains and the users of their networks. Furthermore, Norwegian estimates from product modelling technology exploitation [NPRA 2006]: Data with better quality From NPRA point of view NRDB helps in standardizing tender documents Web services for digital map data and orthophoto Use of common data model in NRDB and Road design system makes dataflow easy Better routines for data access and distribution to end users Web services with relevant data from different public authorities available A lot of new users both within NRPA and outside our organization Easier access to data and better data quality for users both within NPRA and the community means better decisions 38

45 NRDB savings It is no easy matter to make any system realistic estimation on annual savings and reliability of estimations tend to improve when experiences from operation are available. As Pöyry has also presented in Appendix A, the savings are coming on the long run. Annual savings estimations have also varied greatly in NRDB case. First optimistic expectations were represented by Finn Zetterström from Vianova Norway in Infra2010 s workshop in Oslo [ ; Oslo ]. These figures are calculated by constant percentage share and therefore include very rough generalization. Other notable issue is involvement of third party savings that in many cases sets the reliability to unsteady basis. On total Finn Zetterstöm s optimistic annual savings expectations are 155 M (200 MUS$), containing following: Design 3 M (4 MUS$) Maintenance 50 M (65 MUS$) Construction 50 M (65 MUS$) Improved safety (less accidents) 31 M (40 MUS$) Utilization of road network 16 M (20 MUS$) Other savings 5 M (6 MUS$). Norwegian Public Roads Administration has according to Vianova Finlands InfraPDM report 2.1 adjusted annual savings magnitudes. Figures are closer to reality, although the system has been operational for short time since and verifiable evidence is lacking. NPRA s conclusion on estimated total annual savings is 8.2 M, with subset of: Road data collection and distribution: Annual costs 12 M, 1,2 M annual savings (10%) Road planning and design: Annual costs 30 M, estimated 1 M annual savings Road maintenance: Annual costs 430 M, estimated 2 M annual savings (0,5 %) Development and operating costs: Annual costs 18 M, estimated 4 M annual savings Unfortunately we can not base realistic estimations on first hand experience due to short operation period of NRDB. Before making any conclusion on potential savings couple of serious matters have to be acknowledged. Firstly, figures have to be reviewed in sensitivity analysis. In Infra2010 programme Apilo [Infra2010/Apilo] stated that if the workload on design in Finland decreases 5% there is potential for annual 9 M savings. In case workload decreases 10% the potential for savings becomes significant 18 M annually. On the other hand, the experiences in both building and infra sector suggest currently rather high, up to 30 %, extra effort in design due to inefficient data exchange. FINNRA and RHK share opinion that design phase has potential for savings. BaneData savings According to NRA [NRA 2006] BaneData system has same functions now than earlier Ease server based databases. In this context benefits are understood as improved quality of information and possibility to have more users. System is also expandable to maintenance, although certain adjustments are required for the data model. It is also expected that maintenance is actually the lifecycle phase that bring most probably savings. 39

46 In conclusion As a conclusion it is justified to say that realistic annual savings are in the magnitude of five million Euros, when both road and rail administration are perceived. Non monetary savings are also realizing, such as improved data quality. The immediate benefits would be enabling process and quality improvement as well as new types of services utilizing geographic information, cost savings in the long run. Seek also improved competitiveness in large scale projects (though interoperable systems and collaboration practices), also in exporting consulting services as well as software products and services (IFC experiences support the software aspect). For various stakeholders, there different kinds in incentives for product modelling: software vendors: no need to support numerous exchange formats, international marketplace (data models and interfaces in several countries based on same standards) consultants: information sharing less laborious and less error prone, new service opportunities, different applications used in different tasks can access the same information sources. owners/authorities: maintenance of information (registries, data banks) manageable (common data models and interfaces supporting interoperability, no need to maintain redundant information in multiple sources). clients: life cycle processes better supported (seamlessly), choice of consultants and contractors not based on software products they use. users: up to date, on demand information services, potential for services improving quality and safety of infrastructure. contractors: Figure 22: Benefits and possibilities for product modelling exploitation in Infra sector, VTT/ InfraPDM project.. 40

47 4.1.2 Potential problems Several potential risks can be recognised, and should be taken into consideration in any development plan. Technical risks: System does not satisfy the needs of Finnish infra sector (if adopted from elsewhere) Software (other than major design applications) may not yet be on the level that benefits from model based information. Fair business practices not maintained, if Solution creates a favoured status for one or few parties System is not based on open standards (such as ISO standards) Interface specifications of its components are not fully defined and/or publicly available implementations of the components are not (fully) conforming to interface specifications; possibility that wild card solutions enter the market System is not dynamic and updatable System is dynamic and updatable, but without stringent procedures for these ISO TC211 standards may need updating when life cycle coverage is expanded (e.g. design information) Organisational and economical risks: Underestimation of time and resources required from over enthusiasm to exhaustion o It is common rule that development work almost every time requires longer time and more money than expected o Realized savings are not coherent to investment. It is obvious that savings are not realized in short term costs are higher in the beginning. Availability of training o Lack of quality and common practices o Purchasing costs are determined too high Insufficient cooperation while development and uptake lack of compatibility of solutions Support for various formats must still exist and causes additional costs Insuffiecient training intelligent network is required and training may not produce enough skilful practitioners fast enough Deficient or incorrect communications o Practitioners in infra sector may resist to adopt new way of action SWOT High level SWOT analysis covers general product model based system and Norwegian system. 41

48 Product Model based system in General Table 4: SWOT interoperable product models in general, VTT/ InfraPDM project Norwegian System Table 5: SWOT Norwegian specification and Quadri concept, VTT/ InfraPDM project. 42

49 4.2 Projected system implementation schedule and costs Implementation schedule estimation National Road Data Bank NRDB System has been in production use since and NPRA has not made analysis of the project results yet. Development process included schedule delays, although NPRA was not very surprised. First delay (indicated in September 2002) resulted from underestimating the data model complexity. NRDB is a rather complex system also including historical data about the road network itself and also all the features. The second delay, that was actually big surprise, was almost two years spent for the FAT (Factory Acceptance Test, to test system functionality) and the SAT (Site Acceptance Test, to test workflow when system in full production). Actually both phases were supposed to last for three months. There were also high risks in data model specification tasks requiring special expertise. Unfortunately these risks realized and necessary changes had to be done to the data model. Figure 23 represents planned project schedule and the realized one. [NPRA 2006] Figure 23: Planned and realized implementation schedules of NRDB in NPRA [NPRA 2006]. BaneData The project work started in 2000 and the system was released in July Project plan was set to having BaneData approved on September However it finished close to 2 years later. Realized development schedule for the BaneData is presented in Figure 24. Delays were caused partly because of upgrading to newer Maximo version and unrealistic estimation on time required for specification and technical issues. Work on maintenance development was started on July 2004 and continues. [NRA 2006]. 43

50 Figure 24: Realized implementation schedule of BaneData in NRA [NRA 2006]. Implementation schedule estimation In the first place, the basic decision whether infra sector is going to advance product model based system development has to be done. Following duration estimations on tasks mean effective work time and decision waiting times shift schedule instantly forward. Decisions and directions: 8 12 months Open specification definition, exploitation and delivery of system servers months Essential road and rail registers data conversion and tests: months Total 3 5 years National Road Data Bank NRDB Estimated implementation costs NRDB development costs have been received from NPRA s NRDB project leader. Overall, NPRA has invested more than 15 M in the development of NRDB. This includes also several clients migrated from our old system (more than 15 different clients). This justifies us state a question: Are all required conversion costs included? E.g. NRDB is in connection to asset management. VTT s research team estimates that extra conversion costs are somewhere close to 10 M. System is also under expansion towards design in SYMPRO project (see InfraPDM Report 2.1 from Vianova Systems Finland). Cost estimates from SYMPRO were not at the disposal of authors. Therefore our estimate for incorporating design to system is 25 M. System has been in production use since , so far analysis of results have not been made. BaneData According to NRA the system development costs were 5 million Euros. Original budget was exceeded, due to increased consultant costs and internal work in NRA. Estimation for the investment costs when broadening BaneData into maintenance are 15 M. Work on maintenance development was started on July Annual system administration costs are at the moment over 0.1 M. This is rather small due to no need for making corrections. 44

51 Estimated implementation costs One notable feature is different development status of NRDB and BaneData; NRDB covers the maintenance phase and the expansion from design to construction phase is now on going. BaneData covers existing registers and maintenance is under consideration. In Finland the priorities are opposite; FINNRA s and RHK s priorities on potential savings are design and construction phases. Discussions in RHK s have revealed that there is current need to update register system and make expansion to maintenance [RHK 2006]. The cost information was available at very late stage of the study and contains significant differences, even contradictions. Based on the available information reliable cost estimation is very difficult. In addition, the Norwegian system is still under construction and there is no data of the final costs. In general, VTT s estimation is that the total costs are significantly higher and immediate benefits significantly lower that the image given at the beginning of this study. Thus VTT s estimation tries to include sufficient margin, so that the Finnish budget would be realistic. VTT s research team comes to a conclusion that total investment costs, NRDB and BaneData, in Norway will be 70 M. This includes in the NRDB NRDB existing registers, maintenance, extra conversions (estimate from VTT) and expansion to design (SYMPRO, estimate from VTT). In BaneData existing registers and expansion on maintenance that is currently on going are included. At the moement there are no indications to expand BaneData to design and construction phases [NRA 2006]. Before everything else Finnish infra sector has to make statement on whether Road and Rail Administations (FINNRA and RHK) are basing the development on same technical system. Norwegian Public Roads and Rail Administrations have developed separate systems. There is potential synergy between Finland and Norway; Finland would expand the use in the areas which are currently missing from the Norwegian model. However, earlier sentence also is a threat or at least an uncertainty for the Finnish project. Overall benefits from the Norwegian system development exploitation here depend on how well our priorities match to current Norwegian model status. Unfortunately earlier phases (initial data, design and construction) are not finalized. As a conclusion to this chapter estimated implementation costs are represented existing registers update. The system development to the Finnish priority areas, elaborating open specification by exploiting existing Norwegian specifications and delivery of system servers are probably be M. We assume that the data conversion costs in Finland and Norway would be on the same level, probably M.. VTT s estimation is that the total cost of the development and data conversion would are be in M including the development of specifications, implementation of the system, and data conversion and import to the system. In addition, the project would need active participation from established finnish consortium, FINNRA and RHK in the development and significant resources in education of the end users. Depending on the amount of internal resources the total costs of this are probably in the range of 5 10 million. Altogether the total investment is from M. 45

52 4.3 Proposal for Finnish product data model system implementation plan National Finnish infra sector is facing new challenges, whether the systems and registers in infra sector are elaborated or not. Generally there has aroused the suspicion of undergoing consolidation activities in road and rail administrations. It is obvious that when working environment changes information systems are presumed to elaborate simultaneously. Machine automation has taken more footsteps especially site automation has advanced. National projects on site automation are exploring e.g. application programming interfaces (APIs) and possibilities to manage surface model in database. It is necessary to improve software interoperability to be able to get the most out from possibilities of machine automation. Presently there is too many wild cards used in data exchange in infra sector; practitioners concentrate merely to individual projects instead of long term commitment to data exchange problem solving through standards. Lately Inframodel projects showed progress by obtaining competing design software vendors to Inframodel projects to specifying localised documentation to LandXML standard on exchanging design information ( and ). Many of the existing problems in data exchange are related to lacking of commonly used standards. If the environment in infra sector is developed according to current practices there is a possibility that we shut the doors from new whole life cycle services. Data exchange between sequential phases can be managed but when advanced service is linked to phases at life cycles both ends its probable that the foundation is shaking. We still need to make investments on system development but significant process development has also less potential. It is recommended that the work is based on wide cooperation, including All public authorities; e.g. National Land Survey Finland NLS, Finnish Roads Administration FINNRA, Finnish Rail Administration RHK; municipal actors Contractors, consultants Service providers, software vendors and other participants. Firstly open and commercial business activities must be recognized (see Figure 25). International standards from well established bodies should be the basis for the national Finnish specification that should be described by open Finnish consortium. Specification defines the product data model used in software and applications supporting common product data model based data exchange. Collaboration with other national bodies and efforts, e.g. Norwegian public roads and rail administrations, is feasible starting point that should be further consider in case the infra industry in Finland is making transition towards product model based system development. It is important to fulfil the needs of the Finnish infra sector and to recognize also to what extent it is feasible to cover infrastructure information management. 46

53 Figure 25: Relations of open and commercial business activities, VTT/ InfraPDM project. It is important that all the players work together and enable by actions also the successful end result. Product data model based system administration in Finnish Infra sector is described in Figure 26. The maintenance of open specification must be governed by consortium securing that reasonable and required content is attached. Specification updating process must be transparent in order to support the software, tool and service developers of various routes having equal possibility to deliver commercial products. Figure 26: Administration of product data model based system in Finnish Infra sector, VTT/ InfraPDM project. 47

54 It s essential that road and rail administrations (FINNRA and RHK) have active role in the development efforts. The potential for savings in infra sector is greater when individual development projects and pilots support the goal; e.g. product models should be required in projects in some extent. ICT system and process development pilots for Finnish infra sector are expressed in Figure 27. Figure 27: ICT system and process development pilots for Finnish infra sector, VTT/ InfraPDM project. Proposal for Finnish product model based system implementation is illustrated in Figure 28 and Figure 29. National Infra2010 RTD programme is first of all making framework decision whether infra sector is going to apply product model technology. There is an option to develop solution based on FIN NOR cooperation or other alternative. This decision should be made on the grounds of negotiations with Norwegian bodies and other software houses testing on Quadri concept. There is also clear indication that the openness of specification development and equal possibility for software development are the fundamentals of any workable solution. Finnish development environment should base specification development to open consortium in any development case, FIN NOR cooperation or other solution. In conclusion the model based system development is predicted to take 3 5 years period. VTT s research team emphasizes that task duration estimates are effective work time and decision waiting time instantly shifts schedule forward. 48

55 Figure 28:Implementation plan for Finnish infra sector phase 1. VTT/ InfraPDM project. Figure 29: Implementation plan for Finnish infra sector phase 1. VTT/ InfraPDM project. 49

56 Digiroad description, Finnish Road Administration Digiroad summary, Finnish Road Administration References Digiroad, Tietolajien kuvaus, Tiehallinto, Versio 1.1 FINNRA listing. Verified on August technical instructions in Finnish "Tiehallinto tekniset ohjeet. Infra2010 / Apilo, L Elinkaarenaikaisen tiedonhallinnan hyödyntäminen infra alalla. Ramboll. Infra 2010 Presentation, Kam, C. and Fischer, M. 2002: "Product Model & 4D CAD Final Report", CIFE Technical Report 143, Stanford University Kiviniemi, A Product modelling roadmap to infra sector. Tuotemalli Roadmap infra alalle. Delivered under infra 2010 research programme. Korkiala Tanttu, L. ;Tenhunen, J.;, Eskola P.; Häkkinen, T.; Hiltunen M R. and Tuominen A. (2006). Väylärakentamisen ympäristövaikutukset ja ekoindikaattorit; ehdotus arviointijärjestelmäksi. Tiehallinnon selvityksiä 22/2006. ISBN vaylarakentamisen_ymparistovaik_ekoindikaattorit.pdf LVM Väylät 2030 Väestön ja elinkeinoelämän haasteet liikenneväylien pidolle. Published by Liikenne ja viestintäministeriö. ISBN Mäkitalo, M.; Tuominen, M.; Väänänen H.(2005): Ratatietojen kuvaaminen ratatietokanta ja verkkoselostus. Ratahallintokeskus. Liikennejärjestelmäosasto. Helsinki Ratahallintokeskuksen julkaisuja A 3/ pages in Finnish. ISBN NRA Jernbanestatistikk Norwegian railway statistics. Jernbaneverket, available at: Porkka, J. & Hyvärinen, J ICT infra based lice cycle process model for roadway and railway projects. Composed during InfraPDM project, 13 th July Rail data system, M. Tuominen Rail data system, Marko Tuominen, Finnish Rail Administration. Lecture sheets Ratahallintokeskuksen ja Tiehallinnon evaluointi 2006, Eera Finland Oy, Liikenne ja viestintäministeriö. Ratahallintokeskus, Rataverkko osasto / Ratatietoyksikkö. Ratatietojen nykytilakuvaus (briefing in Finnish); Muistio

57 RHK Finnish railway statistics Ratahallintokeskus, August Available at: Storsjö, M Nationella vägdatabaser i Norden. Masters thesis from Land Survey department in Helsinki University of Technology. Espoo igiroad%20storsj%c3%b6%22 Taylor, J. and Levitt, R. 2005: "Modeling Systemic Innovation in Design and Construction Network", CIFE Technical Report 163, Stanford University Tiedon hallinnan visio ja strategia 2002, Tieto projekti, Tiehallinto, Helsinki. Tiedonhallinnan kehittämisssuunnitelma. Tiefakta Published by FINNRA. Vesikari, E.; Söderqvist, M K Experience and Challenges of BMS Implementation in Finland, Bridge Seminar in Vilnius, Lithuania October 2000, BRC & NVF Committee 32. Web sources InfraRYL web. Verified on August InfraRYL web site: KTJ, Kiinteistötietojärjestelmä. Kuntaliitto, Association of Finnish Local and Regional Authorities. Kunnan paikkatiedon luokittelu 2.3 (Classification of municipal geographic data). Maastotietokanta, Description of the topographic database of National Land Survey of Finland. NGIS web. Verified on August Open Geospatial Consortium: Safe Software. Siltarekisteri. SOSI web. Verified on August railways e.g. Tierekisteri. 51

58 Vocabulary of positioning, Paikannussanasto, Tekniikan sanastokeskus: TSK 30, 2002, Väyläomaisuuden hallinnan käsitteistö. Wikipedia web, open standard. Verified on August Discussions FINNRA Finnish Public Roads Administration (Tiehallinto). Participants: Markku Tervo, Matti Raekallio, Matti Ryynänen, Jarmo Purkunen, Harri Spoof. NMA Norwegian Mapping Authority (Statens Kartverk), discussions with Kent Jonsrud. NPRA Norwegian National Public Road Administration (Statens Vegvesen) Meetings in Oslo on 29th November 2005, 7th February 2006 and 11th May Participants: Trond Hovland, Jan Arve Bingen, Liv Nordbye, Harald Wethal, Erik Norstöm. NRA Norwegian Rail Administration (Jernbaneverket) Workshop in Oslo on 25th August Participants: Knut Bjarne Green, Geir Ingvaldsen, Inge Engelberg. Oulu Discussions with Mika Jaakkola (University of Oulu) and Kalervo Nevala (VTT Oulu) RHK Finnish Rail Administration (Ratahallintokeskus). Participants: Harri Yli Villamo, Marko Tuominen, Marko Nyby, Mika Heliranta, Tommi Röntynen, Mikko Himmi, Jussi Lindberg. Vianova Norway Information on Norwegian development projects in Vianova IT AS Participants: Finn Zetterström and Eivind Stalheim. 52

59 Appendix A: Experiences, benefits and problems of integrated product data models Preface This report is written in Pöyry Oy by Ari Kähkönen and Vesa Männistö (Pöyry Infra), Timo Syrjänen (Pöyry Application Services), Mikko Höynälänmaa (Pöyry Forest Industry), and Topi Tissari and Timo Huvinen (Pöyry Building Services). Contact Ari Kähkönen P.O.Box 500 (Jaakonkatu 3) FI Vantaa Finland Domicile Vantaa, Finland Business ID Tel Fax Pöyry Infra Oy 1

60 Contents 1 Preface 1 BACKGROUD AND OBJECTIVES OF THE STUDY 3 2 PRODUCT MODELS IN FOREST INDUSTRY Usage of Plant models current situation Plant engineering tools Plant maintenance and operation Standardization Integration platform e commerce Experiences of using plant models Plant models in engineering Plant models in plant maintenance and operation Plant models data exchange Benefits Risks 7 3 PRODUCT MODELS IN BUILDING INDUSTRY Usage of product models in building industry current situation Experiences of using product models Product models in design Product models in design pilots Product models data exchange Product models in construction Product models in FM Benefits Risks 10 4 CONCLUSIONS 11 Copyright Pöyry Infra Oy

61 Copyright Pöyry Infra Oy 2

62 3 1 BACKGROUD AND OBJECTIVES OF THE STUDY Infra 2010 is a research and development program coordinated by Rakennusteollisuus ry and participated by both public (e.g. Ministry of Transport and communications, road administration, rail administration, municipalities) and private sector (e.g. building contractors, designers, consultants, building material industry). Objective of the program is to raise the productivity in infra sector by renewing acquisition and working methods. The core of the program is development and implementation of common product data model for infra sector. Product data model is a formal and systematic description of a structure (e.g 3 dimensional computer model). It defines what information product model includes and what attributes and relations that data has. Product data model can be used to manage the life cycle of a structure from project planning to maintenance (see Figure 1). A common standard enables data transfer to the model from different companies software. Model measurement Model maintenance 3D model Development of operations Design programs Updates of documents Maintenance systems Simulation Operational accounting Operation Building Equipment installations Quality control Visualization Training Etc. Figure 1. Utilisation of product model in managing the life cycle of a structure. The objective of this feasibility study is to describe experiences of using product data model in other business areas. Forest industry and Building industry are used as reference cases. 2 PRODUCT MODELS IN FOREST INDUSTRY Product models in forest industry are called as plant models. The plant model is a collection of plant objects which describe plant or part of it. Plant objects have relations to other or external plant objects. The model can be presented in different hierarchies based on the relations between plant objects. Plant objects are divided into functional and physical parts. Requirements are clearly separated from implementation parts. Plant models are standardized although many standards exis describing the same context. Copyright Pöyry Infra Oy

63 2.1 Usage of Plant models current situation In forest industry design and engineering companies first started to use plant models in their work, when the first CAD systems were introduced in major plant engineering companies in early 1980 s. For example Jaakko Pöyry acquired a plant design system in 1982 (Calma), which already then enabled product models based design. First plant model based design was concentrated inside one company (mostly big engineering companies) and even in one discipline with no integration between disciplines. In recent years all life cycle phases of a plant are using product models in a way or other. Same time exchange of product models between different vendors is a common practice. One of the biggest challenges right now is interoperability between different systems. Currently plant models can be used as a base for developing applications, work processes or exchanging plant information Plant engineering tools Most plant design systems are built around the product model. The product model includes technical information (database) and/or visual representation of plant objects (3D model). These kind of systems are used in process, layout, piping, electrical and instrumentation engineering disciplines. The product models based tools can be used: to produce equipment lists. One of the main reasons to use product models is to be able to calculate correct equipment lists from the model fast and to do it repeatedly. This feature is used in all disciplines. to produce automatically drawings from the model. In typical pulp and paper project deliverables include thousands of piping isometric, electrical circuit and loop diagrams. Using the right tool these drawings can be generated automatically from product models. to automate design. With a product models it is possible to use tools, which automate design. Rule and template based systems are used in dimensioning and component selections. to visualize design. Product models can be visualized in different ways. For example 4D visualization (time based visualizations) Plant maintenance and operation In plant maintenance and operation part of the product model can be stored in maintenance and production systems. At the end of the investment project it is common process to transfer engineering information to maintenance system. Copyright Pöyry Infra Oy

64 2.1.3 Standardization Plant data transfer between different parties and in different life cycle phases is important. NIST (1) has calculated that cost of inadequate interoperability in the U.S. capital facilities industry is 15.8 billion dollars per year. There are no exact calculations on what is the corresponding figure in Finland, but clearly the same interoperability problem exists in Finland. Standardization of product model structures and semantics in plant design is one key to solve interoperability problem. There exist many standards in plant design area starting ISO standards like ISO (STEP) and ISO (Posc/Caesar). U.S. based organization Fiatech (Fully Integrated and Automated Technology for Capital Project Industry) has listed most important standards in plant design field (2). There are also local standards in Finland, which are created by PSK (PSK Standardointiyhdistys ry). (3) Finnish standards are in close relation to international standards Integration platform Standardized product model based systems enable integration between different stake holders over the whole plant life cycle. Engineering companies are using plant models based design data to transfers information between different disciplines, for example data from process definitions (requirements and initial data) are passed to instrumentation and electrification disciplines. This way design time will be made shorter and design quality is better than when exchanging s and Excel files. This integration can also be automated e commerce Product models can also be used to automate procurement. Group of Nordic paper companies have created standard for material and services used in pulp and paper procurement. These kinds of standards connected with product models can integrate and automate procurement process. Also product portals can be created for different industry sectors. 2.2 Experiences of using plant models Plant models in engineering The plant models are in key role in successful project implementation. It is almost impossible to execute investment projects without product models. Clients are setting shorter time schedules and with using product model based design efficient design with better quality can be achieved. For example without automatic drawing generation it is impossible to execute profitable projects. The work sharing between own companies and other vendors are possible. The problems arise, when tools from different vendors are used, because most of them are not using same product model templates and standards. Copyright Pöyry Infra Oy

65 Best result with product models can be achieved in new investment projects. Existing plant product data (if it is not in product model format) gathering is expensive. It must be really beneficial to make decision to re model existing data, although re modelling of the plant data could be done in steps and in different life cycle phases. Hybrid models where some part is modelled and some part exists in document, are also used. When documentation part modifications are done, it is then modelled. This could take years but also costs are divided over several years. This kind of examples exist in forest industry where paper mills instrument and electrical part was modelled within 10 years time Plant models in plant maintenance and operation The product models are used typically within maintenance systems and for example connections to 3D models are used only in some cases. The 3D models are used as interface to other mill information or are stored as starting point for further engineering projects. Process, instrumentation and electrical product models were earlier stored partly in maintenance system but in recent years plants have started to use new plant models based systems to store data. This data can be used for small maintenance engineering tasks, tuning and/or simulating the plant operations. These new product model databases are also good starting points to new investment projects. Common standard is one of the crucial requirements for successful data integration in plant maintenance and operation Plant models data exchange Document hotel based information sharing is currently used almost in every investment project. Product information exchange is still mostly in excel format. Every project has different format and every vendor has its own format. At the end of the project, most mill information plant owners requirements can be delivered, but data is often in wrong format. There are projects trying to solve that problem. In Finland PaperIXI ( ) and PRINDEX (2006) are concentrating to solve this problem. In both projects all major players in pulp and paper industry are participating. The data exchange standards exist, but work processes how to use them in shared context require new skills and policies from all parties. All the involving parties must commit to use agreed methods and standards. An international project with big players like Shell, Dupont, and Bechtel has also been started to solve this problem (4). Project ADI is using ISO standards as a base standard. Plant engineering system and tool vendors are not using and pushing standards so much as they should, because they are afraid of losing their market share. They try to make their own standards. 2.3 Benefits Technical information of a plant can be stored in a centralized way and only once. All the parties participating to activities during the plant life cycle have the same data. Copyright Pöyry Infra Oy

66 Design and engineering will become more effective. Automated features can be utilized. For example, rule based design requires a plant model. Data integration is possible and it can be done independently if standardized product models are used. E commerce solution can be utilized. New business services can be created when using product models. Using of product models enables development of new work methods and processes. Most of the benefits accrued from the utilisation of product models are gained by the client, although the industry is mainly responsible for the development Risks Required common standards are not reached or standards are not taken into use. Integration of different systems requires huge amount of resources. The selected standard will not come as a main stream standard and work done based on that standard is lost. System vendors will not follow standards and island of automation still exists. Product model based development will use most of the development resources and other important development areas are neglected. 3 PRODUCT MODELS IN BUILDING INDUSTRY In building industry product models are also called Product data model and Building information model (BIM). Product model consists of objects, whose properties are described with attributes and which have relationships to other objects. In large Finnish research project, ProIT, product model has been defined as follow: Building product model is the totality of building information, digital product data, throughout the life cycle of building. Product model represents unique product data in a form that is defined by a product data model. Product model may be stored either as application in database or data transfer file. 3.1 Usage of product models in building industry current situation In building industry designers have longest taken advantage of product model technology. Product model based design started at the end of 1980 s when architects began using 3D design applications. Models were used also for indoor climate simulations and in small scale for dimensioning networks (piping, HVAC, electrical) and steel structures. In design of building services usage of commercial product s libraries in design applications started in 1990 s. In larger scale modelling started at the end of 1990 s when first commercial applications came to market in Finland. Nowadays all building design bases using product models in a way or other. However there are Copyright Pöyry Infra Oy

67 differences in extent and accuracy but model exists. Commonly exchanging product models between designers is established way of co operation. There are still lot of challenges in co operation between systems of disciplines. In the beginning of 2000 s there have been started to merge models of separate disciplines in pilot projects of building design. IFC standard (Industrial Foundation Classes) has been established for merging models in Finland. In practise even globally there are still very few IFC projects but volume is clearly growing. Finland s proportion of IFC based projects is very significant and in addition of this IFC technology and research is in top level even internationally. This means that Finnish building industry is moving from product model piloting to large scale exploitation. Many building design applications of separate disciplines support IFC standard, e.g. ArchiCAD, AutoDesk ADT and Revit in architectural structural design; Allplan Engineering, Bentley Structura and Tekla Structures in structural design; and MagiCAD in building system design. In addition to that there are other applications in building industry which have IFC compatibility: Solibri Model Checker for analysing and consolidation models; Graphisoft 5D solutions, Tocoman ilink and Eterprixe for bills of quantities, scheduling and production control; and IDA Indoor Climate and Energy for indoor climate and energy simulations Experiences of using product models Product models in design Product modelling is used in building design e.g for creating drawings, lists and visualisations, LCC and LCA analyses, and indoor climate and energy simulations. Product models are also used to creating basic data for facility management and storing data during whole life cycle of building. Product model based design is more efficient way to produce design documents than traditional CAD drawings. Efficiency is a consequence of exploitation of building part models and product libraries which contain 3D geometry of building components and also hierarchical data of them. Product model design environment enables producing various drawings from different views of 3D model. In addition to this it is possible to take advantage of building part data when creating texts to lists and drawings. Often drawings and lists are able to create automatically or at least semi automatically from model. Furthermore with help of various rules many design tasks and quality control is able to automate. In conventional design product modelling is made only to the extent that company s document producing requires. Most design companies use product model technology only for improving internal processes. Instead target of leading companies is to give added value to clients and besides that many of them have developed own applications for quality control and cumulative design data handling based on models Product models in design pilots Most of pilot projects of product modelling are made to Senaattikiinteistöt, which have been in a remarkable role developing product model technology in building industry. Pilot projects have focused on product model based design, data exchanging, utilizing Copyright Pöyry Infra Oy

68 product models when making decision between alternative proposals and improving construction. Data exchange by IFC works yet in a quite limited amount of applications. Working cases are e.g. transfer of geometry, bills of quantities, cost accounting, energy and environment analyses, 4D modelling and logistic control. The main problem on data exchange is insufficient implementation of IFC. There are lot of practical challenges in IFC exchange. However in many researches data exchange cases between various parties have been documented so better implementations will solve those problems in near future. Consolidating models of various disciplines have already been routine in pilot projects. Remarkable part of design coordination is able to make with help of product models. When using product models in coordination it is possible to use automatic checking based on rules. E.g. these types of checks are: coordination of architectural and structural design, collision control of building service systems and adjust systems to structures. In an important role in coordination is visual study of 3D model. Based on experiences got from pilot projects stricter modelling of 3D geometry and part properties add workload and costs. To adopt new working methods takes time and as well design applications need improving. So design will become more effective in future but probably stricter modelling will not lower workload or cost of design. On the other hand through modelling it is able to improve considerably total efficiency of building process. Modelling costs are not significant part of total economy in building process or building s life cycle especially when taking into consideration added value of product models in decision processes, efficiency of building processes and maintenance of buildings. Data content of product model in IFC format is often notably more limited than in native design environment from which IFC models have been generated. This restrict utilizing model e.g. in facility management. Product model pilot projects have been, excluding few exceptions, new buildings. In renovation projects current constructions have been modelled only partially. One reason is that benefits in facility management have not grown enough. In pilot projects it has been noted that use of product models needs common rules and procedures to whole building industry. For instance in agreements responsibility issues and rights of product models must be taken into account. Moreover in project level it is very important to decide already in the beginning of project what will be modelled and how exactly. Also it has to be arranged, which data will be exchanged by model and which data otherwise Product models data exchange Excluding pilot projects product model based data exchange has not become common way to share data between designers. Not even in pilot projects product models have not been replaced traditional 2D drawings and document based information distribution because model based data exchange doesn t work well enough in all disciplines. However product model based data exchange has very high potential, because in product models there is lot of data stored in one place. Probably in near future model servers will be introduced. They will offer public product model database, control Copyright Pöyry Infra Oy

69 services for product models and data interface for several simultaneous client applications Product models in construction Product model technology has been used in most advanced construction companies during last ten years. It has been used e.g. in bills of quantities, cost and offer calculations, 4D modelling of building process and purchasing Product models in FM Most of facility management software is still separate databases into which design and construction data are inputted manually. There is definite need for easy to use applications which could take advantage of product models and maintenance data would be able to update to model. As well in applications which were made for buildings users would be able to utilize product models. 3.3 Benefits When building information is stored in a product model, all participants have the same data. Product models will replace a remarkable part of traditional document and drawing based data exchange. Product models will speed up and intensify design and construction process. For example automatic design features and 4D modeling can be used and more parallel work can be done. In addition, product models improve the quality of design and construction. Product models can be easily utilized in LCC and LCA analyses when decision making is based on accurate facts. Product models can be used to meet the requirements of customers when using comparison between alternative solutions, visualizations and indoor climate simulations. Product models enable a new business development for example in facility management. 3.4 Risks In Finland a remarkable part of research and software development in product models is based on the IFC standard. If some other international standard will become common, part of efforts on IFC will be lost. In construction industry there is a great number of small and medium sized companies. Their resources to invest in new business methods, personnel training and software are restricted. This is a challenge for whole building industry in product model based development and large scale utilization of product models. In addition, product model based development can decrease other business development Copyright Pöyry Infra Oy

70 4 CONCLUSIONS 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. For example, some engineering branches and/or companies have been more willing to adopt product model based working methods, while some branches are yet in the world of excel and e mails. The following main conclusions can be drawn from experiences gained in forest industry and building services. 1. The selected product model has to be based on an international, well established standard, which will be developed and supported in the future. The standard has to be interoperable with main applications used by the industry, and all main application providers should support it. It is also advisable to follow the main stream of the development, other decisions are to be well justified. Standardisation of product model structures, terminology and dictionary is also essential. 2. The role of the main client is very important in implementation of a product model. The main client has to show with her own performance that the product model will be used in most of the activities. The main client has also to indicate, how policylevel questions (e.g. which standard to be used) should be solved. The main client has also to ensure, that the implementation process is managed by the industry itself, not by the application providers. 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. It is recommended that this missing data is collected during maintenance planning and maintenance activities, but this data can then not be fully utilised in maintenance planning. 4. A product model should be flexible enough to handle data of different accuracy levels. For example, if there are some usable data of existing structures (drawings, photos, etc.), the use of that in the product model should be possible (hybrid model). Furthermore, data acquisition methods are developing fast, and today s data collection needs might be easily fulfilled with tomorrow s technologies. It is also very important, that data quality requirement are defined and obeyed while storing the data into the product model. 5. Openness. The product model has to be open to all parties developing applications based on the model. If the model is too closed, smaller application providers might disappear from the market. 6. Costs. It is evident, that implementation of a product model will incur expenses for the industry during the first years. The parties have to invest in technology, software, and training, as well as conversion of existing data and working methods to the new product model environment. It should also be understood, that design work will be slower during the implementation phase. No short term benefits should be expected. 7. Skills. Introduction of a product model to daily work routines is a long process. Although much can be learnt from experiences of other industries, time is needed for training and practising of new methods, as well as for adaptation of product model ideology, and tackling of prejudice against new technologies, etc.. Acquisition of Copyright Pöyry Infra Oy 11

71 new skill might become unfeasible for small service providers, and there will be a need for networking of companies (e.g. between information service providers and small maintenance contractors). 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. What would be the situation in forest and building industries, if no product models were used? Firstly, these industries have always find ways to design, build and manage plants and building, also without product models. Because development of IT technology is fast, the industries have always to choose current technologies, and also to acknowledge, that technologies (software, hardware) have to be changed 2 3 times during the lifetime of a building or a plant. The essential requirement is smooth and reliable exchange of information not the technology behind it. 12 Copyright Pöyry Infra Oy

72 Appendix B: LandXML data transfer standard (In Finnish) LandXML standardin kehitystyön ovat laittaneet alulle suuret kansainväliset maarakennusalan ohjelmistotalot tavoitteena infra alan avoin XML pohjainen tiedonsiirtostandardi. Nykyisin LandXML standardin kehitystyötä hallinnoi LandXML organisaatio (Land Development industry organization, johon voi liittyä ilman kustannuksia ja velvoitteita jäsenyys on ilmainen. Nykyisin aktiivista kehitystyötä tehdään maailmanlaajuisesti ja jäseniä on yli 500. Kehitystyötä tehdään Yhdysvalloissa, Uudessa Seelannissa, Filippiineillä, Sloveniassa, Australiassa, Suomessa, Thaimaassa, Japanissa ja Kanadassa. Standardia tukevia ohjelmistoja on lähes 50. Siirtotiedoston rakenne on märitelty skeemassa (XML Schema), jonka vastuullinen kehitysarkkitehti on Nathan Crews (Autodesk). Standardin versio 1.0 ratifioitiin (LandXML v1.0) Nykyisin ratifioitu standardin versio 1.1 julkaistiin kesäkuussa Suurien ohjelmistotalojen tuki on ajanut formaatin käyttöä voimakkaasti eteenpäin. Kotimaassa LandXML tiedonsiirtoa on hyödynnetty muutamissa kehityshankkeissa. Tekes Infra ohjelman Älykäs tietyömaa projektikokonaisuudessa toteutettiin tierakennuskoneen modulaarinen ohjaus (MODU hanke), jossa sitä hyödynnettiin tiegeometrioiden siirrossa. Laajemmassa mittakaavassa LandXML tiedonsiirtoa ajetaan alalle InfraModel hankkeilla. InfraModel1 ( ) tutustui LandXML tiedonsiirtoon sekä tiedonsiirron ongelmiin nykyisten infrasuunnittelujärjestelmien välillä. InfraModel2 ( ) aloitettiin ensimmäisen vaiheen pohjalta ja dokumentoi LandXML tiedonsiirtotavan käytön sekä aloitti implementoinnin kolmen merkittävän ohjelmistotoimittajan tuotteisiin (Tekla Oyj, Sito Oy ja Vianova Systems Finland Oy). InfraModel hankkeiden myötä Tiehallinto on ilmaissut siirtyvänsä LandXML tiedonsiirtoon suunnittelutiedoissa , mikäli tiedonsiirron pilotointi onnistuu. Inframodel dokumentoitu LandXML: InfraModel2 hankkeen aikana tehtiin yhteistyötä LandXML organisaation ja lähinnä Nathan Crewssin kanssa. Kehitystyön tuloksista osa päätyi myös LandXML v1.1 standardiin. Hyvin alkanutta kansainvälistä yhteistyötä tullaan jatkamaan myös tulevaisuudessa. InfraModel2 päätösseminaari ( ) pidettiin tiistaina Espoossa, aiheena LandXML tiedonsiirto suunnittelussa ja työmaa automaatiossa. Tilaisuudessa mielenkiintoisia näkökulmia tiedonsiirron mahdollisuuksista esitti Nathan Crews (Autodesk) ja sen yhteydessä keskusteltiin myös tulevaisuuden 1

73 tarpeista. Kotimaassa yksi merkittävä formaatin kehityskohta on työmaaautomaation tarpeiden huomiointi. Sisältö LandXML standardin kuvaa kohteet elementteinä hierarkkisessa jäsentelyssä. Oheisessa kuvassa esitellään LandXML v. 1.1 päätason elementit. Rakenteeseen on mahdollista tehdä esimerkiksi parametrimuotoisia sisällöllisiä laajennuksia. Kuva 30. LandXML v1.1 standardin päätason elementit. 2

74 tarpeista. Kotimaassa yksi merkittävä formaatin kehityskohta on työmaaautomaation tarpeiden huomiointi. Sisältö LandXML standardin kuvaa kohteet elementteinä hierarkkisessa jäsentelyssä. Oheisessa kuvassa esitellään LandXML v. 1.1 päätason elementit. Rakenteeseen on mahdollista tehdä esimerkiksi parametrimuotoisia sisällöllisiä laajennuksia. Kuva 30. LandXML v1.1 standardin päätason elementit. 2

75 Lyhyt yhteenveto LandXML standardin sisällöstä <Units> Mittayksiköt tiedostossa käytetyt lukuarvojen yksiköt <CoordinateSystem> Korkeus ja koordinaattijärjestelmät suunnitelmatiedon koordinaatti ja korkeusjärjestelmät, <Project> Projekti hankkeen yleiskuvaus. <Application> Sovellus tiedoston tallennussovellus ja käyttäjä <Alignments> Linjauksen geometria Viivoina vaakageometrian suorat, kaaret, siirtymäkaaret ja viivaketjut sekä tasauksen suorat ja kaaret. Mahdollista kuvata poikkileikkaukset (esitystapaa päivitetty LandXML v. 1.1). Kotimaassa käytetään usein viivaketjumuotoista ratkaisua, toteutustapa kuvattu InfraModel tiedonsiirron dokumentaatiossa. <CgPoints> Koordinaattipisteet Amerikkalaisessa suunnittelukäytännössä keskeiset koordinaattipisteet (joihin mahdollista viitata) <GradeModel> Väylämalli (ei käytössä) Rakennekokeilu väylän parametriseen aluekuvaukseen (Zone). Mallin toimimattomuuden vuoksi ei ole otettu käyttöön. <Monuments> Kiintopisteet iintopisteet joilla laadullisia ominaisuuksia <Parcels> Tonttijakotiedot tonttigeometriat sekä perustiedot. <PlanFeatures> Varusteet ja laitteet suunnitelman sisältämät varusteet ja laitteet, esim. suojakaiteet, valaisinpylväät. <PipeNetworks> Vesihuoltoverkostot Erityyppisten vesihuoltoverkostojen määrittely solmupisteverkkona rakenteet,(esim. kaivot) ja putket. <Roadways> Väylän mitoitustiedot Väylämallin mitoitustiedot (luokitus, kaistatiedot, nopeusrajoitukset, liikennevirtatiedot ja onnettomuudet, sillat ja risteykset.) <Surfaces> Maasto ja rakennepintakuvaukset Lähtöaineisto (pisteet, taiteviivat, korkeuskäyrät). Pinnat on mahdollista kuvata kolmioverkkona tai rasteroimalla. <Survey> Mittaustiedot mittaustiedot kiintopisteistä ja koordinaattipisteistä sekä käytetyt mittausmenetelmät. 3

76 Appendix C: ICT infra based lice cycle process models for road and railway project 1

77 Figure 31: ICT infra based lice cycle process model for roadway project. VTT/ InfraPDM project. 2

78 Figure 32: ICT infra based lice cycle process model for railway project. VTT/ InfraPDM project. 3