Common InfraBIM requirements YIV2015 - Etusivu · PDF file2.1 Software and formats ... Common InfraBIM requirements YIV2015 4 (17) ... and sustainable development in the project and

Common InfraBIM requirements YIV2015

Vol 2.0

General modelling requirements

Juha Liukas, Liisa Kemppainen Sito Oy

14.9.2015

Infra modeling

Quality control

Supervision and

coordination

Gathering of initial data

Planning, construction,

asset management

Coordination of disciplines

Interaction and

collaboration


2 (17)


Version

Version Date Author Description

1.0 4.5.2015 Liisa Kemppainen Finishing

1.0 7.9.2015 Patrick Jensen Translation edits


3 (17)


CONTENT

1 PREFACE ..................................................................................................................................................... 4

2 Definitions .................................................................................................................................................. 6

2 General model technical requirements ..................................................................................................... 8

2.1 Software and formats ........................................................................................................................ 8

2.2 Units and coordinate systems ............................................................................................................ 9

2.3 Related standards and instructions ................................................................................................. 11

2.4 Linking infra classification system to modelling ............................................................................... 13

2.5 Planning of modelling ...................................................................................................................... 13

2.6 Model description document ........................................................................................................... 14

2.7 Naming of models ............................................................................................................................ 15

2.8 Publication of models....................................................................................................................... 16

2.9 Accuracy of models .......................................................................................................................... 16

2.10 Quality control of models ................................................................................................................ 16

2.11 Delivered material ............................................................................................................................ 17


4 (17)


1 PREFACE

The goal of modelling infra objects is to support the quality of design and construction, efficiency, safety and sustainable development in the project and life cycle process. Models are used throughout the whole life cycle of project, from the start of design and collecting of initial data, continuing after construction with use and maintenance. Modelling enables e.g.:

• Investment decision support by comparing the functionality, extent and costs of solutions • Comparisons of energy, environment and life cycle analyses for target monitoring of the design and

maintenance • Reconciliation of different technical areas • Visualization and analysis of constructability of designs • Quality assurance, improvement of data exchange and enhancement of design process • Utilization of construction project data in functions during use and maintenance such as machine

control These general infra modelling requirements cover requirements for initial data, different phases of design, construction, as-built-documentation as well as use and maintenance. The goal of the modelling instruc-tions is to guide, coordinate and develop the whole infra modelling practise. Current best practises form the base for these instructions and the instructions will be updated as practice and tools develop.

This document describes the basics and concepts as well as the process and use case requirements of mod-elling in different project phases on a general level – more accurate requirements and instructions can be found in YIV instructions parts 3-11.

The infrastructure discipline occasionally uses the terms inframodelling for data modelling and inframodel for a particular infra object data model. Geospatial information (plan, environment etc.) is intrinsically re-lated to modelling and can readily be presented in 3D models. The definition of modelling in infra area can thus generally be extended to control of infra data.

In house construction projects, a model customarily refers to a designer-produced 3D design, or a part of it. This definition has, however, been extended to encompass all of the various information linked to a model-based design.

The modelling instructions present minimum requirements for modelling and data content of models. In addition to minimum requirements, case-specific additional requirements may be specified. Modelling re-quirements and contents of the infra model must be described in all contracts in a binding and uniform manner.


5 (17)


InfraBIM modelling instructions consist of following documents:

1: Data model-based project

2:General modelling requirements

3: Initial data

4: Model and modelling in different design phases in project

5: Construction models

5.1: Earth, foundation and rock constructions, pavement and surface constructions

5.2: Preparation instruction for as-planned model for earth works (machine control model)

5.3: Preparation instruction for as-built model for earth works


6.1: Systems


7.1: Construction technical components

8: Quality assurance of model

9: Quantity survey, cost management

10: Visualization

11: Utilization of model in different design phases, construction of infra as well as use and maintenance of infra

Every party in a model-based project must familiarise themselves with the general requirements part (parts 1-2) and the principles of quality assurance (part 8) in addition to the parts referring to their own discipline. The person managing project or project data control must master the modelling requirements as a whole.


6 (17)


2 DEFINITIONS

This section describes the definitions of central terms. Broader definitions are described in InfraBIM-vocabulary.

Presentation model (previously Virtual model)

A presentation model (also known as visualization model) consists of a detailed, textured, lighted and shaded model, which makes the model visually highly realistic. A presentation model can also be used for simulations of different use situations.

Industry Foundation Classes (IFC)

International data exchange standard for exchange and shared use of product data of construction and real estate management. IFC defines the reconciliation base of software in data exchange. Also used in data exchange for bridges and structures.

Infra model

A product model of the infrastructure, i.e. a manifestation of a particular feature in the model, expressed through a commonly agreed data definition. For example, a particular data of road project saved in LandXML-exchange file in accordance with Inframodel. Note: lately the construction sector has started to use the term model as a synonym for product model.

Inframodel (IM)

Open LandXML-based data definition for model-based data exchange. The Inframodel documentation de-scribes the data content and practices of LandXML used in Finland. Inframodel contains only part of LandXML data. On the other hand, LandXML standard has been extended within the allowed framework by linking the Infra classification systems to it.

LandXML

Internationally used XML-based standard for presentation of infra and survey data in earth works.

Initial data model

A Digital representation of the initial data collected or surveyed from various sources for the design of op-erations and services. These include the terrain model, plan model, geotechnical model, the model of exist-ing constructions and other reference material, such as official permits and decisions. The initial data model is continuously updated with complementary information as the project proceeds.


7 (17)


Model-based

A paradigm or application method for data treatment, where e.g. a product is described as a model that software applications can interpret. The software can also automatically interpret the product information of the constitutive components of the model.

Native format

The native save format of computer software. Data content in a native format more extensive than in a data exchange format, but utilizing a native format or converting to an open format usually requires the same software or program library of same software the file was created in.

Design model

A component of the data content of a model infra construction or system, which covers design solutions by the designers. Can, when needed, be phased more specifically, e.g. into pre, general, route (road/street/railway) and construction and final engineering models. Each design phase can be divided further, e.g. according to each technical discipline.

Data exchange format

Data format for saving, collection, exchange and archiving data with computer software.

As-built model

A data subset (phasing) of a product model, which describes the final implementation of designs.

As-planned model

A data subset of a product model of an infra construction or system, which covers the execution phase, i.e. tasks, resources, timing etc. Can also refer to machine control models or setting out-models produced for surveys from design models.

Combination model

Model assembled from several different models. Usually a combination model is composed of an initial data model and design models from different technical disciplines. A combination model is a technical model, whose purpose is to ensure reconciliation of different technical disciplines and designs of different project parts. A presentation model can be produced based on the combination model.

Maintenance model

A data subset of a product model (phasing), which covers the maintenance phase. It covers tasks and changes etc. during use and maintenance.


8 (17)


2 GENERAL MODEL TECHNICAL REQUIREMENTS

2.1 Software and formats Electronically stored data must be stored in a usable format. It is an absolute requirement to primarily use open standards and formats supporting modelling. Uniform formats enable versatile uses of data, rational-izes design work and provides more detailed data of content. The internal models used in software in the infra field often differ from each other in basic principle. The differences are specific to each technical area. E.g. modelling of water supply networks is very similar across different software, while the modelling logic of earth constructions differ significantly from each other. Because of this it is easy to resume designing a water supply network after a data exchange between dif-ferent software. On the other hand, a transferred model of earth constructions for transportation routes may correspond to the final results, but doesn’t contain all the data needed to prepare a model. Requirement The invitation to tender shall clearly state the requirements for the final product. Basic requirements for modelling are:

• The software can use and produce a model in an open, model-based, format. For infra construc-tions the open format is an Inframodel-compliant content and definition LandXML and for struc-tures IFC.

• The model and its final products and prints are based on the Infra classification system. Inframodel and its content is described in online documentation as well as in the instructions (see www.infrabim.fi) Open formats are not always completely comprehensive, and in transition phases other common formats or software native formats shall be used. For example, the format for soil investigations is the Infra soil investigation format. Because open data model formats don’t yet contain all infra constructions, the dwg format may be used to present them. In such a case, naming conventions must comply with the Infra nam-ing classification. It should also be noted, that dwg-format limits the intelligent exchange of characteristics data of objects.

The native data format must be taken into consideration in data management. A model has to be delivered in such a manner that all essential design data is preserved and can be passed forward with the model. This means that all used material and profile libraries must be delivered alongside the model, including the model description document. The exchange of data must employ an open format, but the data must also be archived in the native format, so that data can be preserved, even for a limited time. When software versions change, parts or all of the data stored in native formats may be lost or rendered unreadable with new software. Picture 1 describes how formats are tightly connected to the data management triangle.


9 (17)


Formats, naming and modelling requirements must be complete and uniform, for data management to function.

Picture 1. triangle of data management.

2.2 Units and coordinate systems The unit used is the meter. The primary coordinate system to be used is a locally uniform EUREF-FIN coor-dinate system and N2000 datum level, in accordance with national recommendations. On a national level the ETRS-TM35FIN coordinate system (one projection band, central meridian is 27º) shall be used. It can be used in preliminary and general design, but more detailed design should use an appropriate ETRS-GKn co-ordinate system. A locally suitable projection band width and the most suitable medium meridian at a full-degree longitude 19º, 20º, 21º, …, 31º. For example, in the Helsinki region, the municipalities (Helsinki, Espoo, Kauniainen and Vantaa) use the ETRS-GK25 plane coordinate system. Initial data or earlier designs are often in obsolete coordinate systems, datum levels or different bands. If that is the case, the material has to be re-projected to a desired coordinate system and datum level. The function and reliability of the used re-projection formulae used have to be assured.


10 (17)


The design of buildings, bridges and structures often uses a local coordinate system, which is anchored to a certain reference point. Re-projection to the project coordinate system requires a satisfactory amount of reference points (3-8 pts.). If the local model cannot be realized in national coordinate system, following principles shall be followed:

- Choose a suitably close “whole number coordinate” in the global coordinate system as a starting point for the local origin.

- Rotate the model so that the Y-axis (mathematical) of the local coordinate system points north in the global coordinate system (P(x) I(y), N(x) E(y)).

- Choose 3-5 adjustment points, where a control cube is inserted. These cubes shall be included in the produced partial models of combination model. At least three of the locations the control cu-bes are placed in must be possible to survey on-site.

Waterways have also their own coordinate system regulations, which are also adhered to in modelling ma-terial. Maps and other drawings, which are appendix material for the design decision, are mainly visualized in the KKJ-coordinate system. The Finland Uniform Coordinate System- based EUREF-FIN coordinate system is used for overview maps based on nautical charts. EUREF is generally used, but in all projects the client’s instructions are followed. For sea waterway projects is generally defined in the theoretical mean water level (MW level) for a certain year, to which all investigations, design, construction and documents are bound. If project does not have a separately defined MW level, the waterway documents are in principle bound to the MW –level of the par-ticular year. For inland waters the corresponding reference level for particular sea part is the defined low reference level for sailing season. Instruction Re-projection the coordinate system for design material is agreed from project to project and ensured, the projection is made in accordance with instructions.


11 (17)


2.3 Related standards and instructions Standardisation related to data control of infra is roughly divided into GIS-based initial data, related struc-tures such as bridges, retaining walls, buildings as well as actual infra objects. Furthermore there is a na-tional Infra soil investigation format for exchange of soil investigations. The data contents of different standards are described in Picture 2.

Picture 2. Rough data content map of standards (InfraTM 2010-2013)

The most significant standardisation parties and standards for initial data are:

• Open GIS Consortium (OGC) and ISO/TC211 committee - ISO 19100 series standard: basic imple-mentation methods, metadata, service interfaces, GML format.

• INSPIRE-directive: EU-regulation, which regulates public distribution and availability of GIS of public administration. Directive also takes a position on technical implementation principles based on ISO 19100 series standards.

• CEN/TC 287-committee: is responsible for European standardisation of GIS. In practise the commit-tee approves ISO 19100 series standards for European use and delivers technical reports of best practise (CEN TR 15449-serie).

• KuntaGML- and KRYSP projects: data content and format of initial material are local definition is based on OGC and ISO GML-formats. Covers among others base map, town plan, environment data and network material.


12 (17)


• JHS-recommendations of public administration: gives recommendations for ICT-practises. • For exchange of soil investigation material is a national Infra-format

The most significant standardizing parties and standards for data content of infra constructions are: • LandXML; XML-based data content definition for infra constructions covering constructions, routes

and networks. Last version of LandXML is 1.2. • Inframodel (IM): national application of LandXML-specification. Last version is 3 based on LandXML

v.1.2. Infra model definition contains application instruction as well as defines standardized value ranges for some characteristics data.

The most significant standardizing parties and standards related to structures and production management are:

• Building: IFC-specification developed by the international buildingSMART-consortium (Industry

Foundation Classes). The last version, IFC4, also links to GIS. The version mostly used in implemen-tations is anyway the previous IFC2x3-version. The standard is also applied to bridges and other structures.

• Bridges: buildingSMART-extension project for bridges is ongoing. Base for the definition work have for some time already been, mainly the proposition made by buildingSMART France.

• Scheduling, quantity survey and cost management: buildingSMART/IFC-definition contains rather comprehensive control data for production. Rather few applications anyway support these defini-tions.

• Definitions of shared use in processes and practises: within buildingSMART-consortium is devel-oped an Information Delivery Manual (IDM)-definition, which is published as ISO-standard ISO/DIS 29481-1 Building information models. Information delivery manual Part 1: Methodology and for-mat.

• Classification system: within buildingSMART-consortium is defined classification system /classification structure Data Dictionary, which is published as ISO-standard ISO 12006-3 Building construction – Organization of information about construction works – Part 3: Framework for ob-ject-oriented information.


13 (17)


2.4 Linking infra classification system to modelling Use of InfraBIM-classification system Infra BIM-classification system covers infra constructions and - numbering and naming practises of models. Classification system relies on and extends the Infra-construction component classification system. Uniform naming practises helps Infra constructions and models throughout the whole life cycle. The goal of a uniform vocabulary is a uniform understanding of terminology and avoiding misunderstand-ings. Uniform terminology and its use ease modelling projects considerably. The objects in an infra model must be described in accordance with the system instructions and regulations of the chosen classification, such that the quantity surveys can be conducted based on the model according to the quantity survey instructions.

2.5 Planning of modelling The organization of a data model-based project is considerably affected by the content, extent and design phase of the project. Control and coordination are emphasized in large projects, which have many parties and technical areas. In small projects roles are combined and embedded in other design tasks. As common functionality of tools and models develop, the organization of projects can in become simpler even in large, multidisciplinary projects. The tasks and roles of data modelling is described in YIV part 1. Requirement The execution of the modelling is planned in the project start-up phase. The plan can be included in the planning program or data management plan. A dedicated modelling plan is prepared in large projects (part 1). Model plan document shall contain at least following things:

• Instructions to be followed • Goals of modelling • Purpose of use of modelling • Extent and accuracy level of modelling • Persons in charge • Documentation of model • Description of process: organization, cooperation and data exchange as well as timetable • Quality assurance


14 (17)


2.6 Model description document The model description document is the most important document attached to model, which shall always be delivered with the model. The description document describes the situation of model and its partial models at time for delivery. The description shall contain all facts regarding model use and reliability. Possi-ble deviations from agreed model content in different project phases and other important observations on e.g. limitations on model content and data exchange imposed by software shall be documented in the de-scription document. The document shall list the software and their versions used for modelling different technical disciplines. The documentation of combination models (view models) has to describe software, assembly manner, formats as well as possible deviations or deficiencies in comparison with the original constituent models. Picture 3 shows an example of a description document presentation. A description of the initial data model is included in the model description document. Requirements Contents of the description document include:

• Target and end use of model • Contained models per technical discipline and their content • Used software and its version and files forms (partial model, combination model) • Coordinate system and datum level • Naming and numbering practices of components • Possible deficiencies and incompleteness in model in comparison with requirement of particular

phase • Accuracy of constructions in model in comparison with required phase • Produced files • Quality assurance measures • Checking and approval of model • Other relevant aspects


15 (17)


Picture 3. Example of presentation of model description document

2.7 Naming of models Requirement The objects in initial data model shall be named in accordance with the existing Infra-classification system and its extension, the InfraBIM-classification system. The corresponding infra-classification code shall be attached to each object. The level names of CAD-files shall be applied correspondingly. Model files and folders are named descriptively, so that it is immediately obvious what material they con-tain. File and folder names cannot contain Scandinavian letters (å, ä, ö) or special characters. Allowed char-acters are AZ, a-z, numbers 0-9, underscores and hyphens. Use of empty spaces is prohibited. Names of files and folders shall be as short as possible, but also descriptive. The maximum length of a folder path with file name shall be 256 characters. Naming practices shall always be agreed upon at the start of project.


16 (17)


2.8 Publication of models Publication of models means publishing a web model or other corresponding model online on a web page or cloud service, where different parties can investigate and comment the model. In model-based design process design and models cannot be differentiated, so they shall be publishable at the same time.

Publishing a model encompasses the following phases:

• Timetable of project defines publishing decision. • The model, the model description document and other material are updated and finished to publisha-

ble condition. • The model is checked for accordance with (YIV instructions, part 8). Uniformity of documents and mod-

els are checked. • The material is published.

2.9 Accuracy of models In model-based design process, modelling can be used in different phases. The level of detail and accuracy of modelling can vary from project to project. Further, the level of modelling detail can vary within a pro-ject, e.g. between different design disciplines. The accuracy level of modelling is defined by design phase, technical discipline and utilization needs of the model. The accuracy level is mainly defined by the requirements in the design phase and design instruc-tions. The accuracy level of initial data shall correspond to design requirements. Model accuracy in different phases is described in YIV instructions part 4.

2.10 Quality control of models Requirements An internal quality verification review must be performed for discipline-specific partial models. A compre-hensive coordination review must be performed for all partial models at each level of design or construc-tion. Instruction The content and properties of construction models are described in YIV instructions parts 5-7 for each technical discipline. Part 4 defines the content of models in different design phases. Quality assurance of models is ensures, that models are delivered in accordance with these instructions and therefore suitable for their intended use. Models and their content can be examined from three angles.

• Technical model content: is the model prepared in accordance with required standards and classifi-cation system (syntax and semantics).


17 (17)


• Data content of model: do the models contain all required data included in design, construction and maintenance phases

• Quality evaluation: are all solutions as a whole functional, e.g. are there conflicts between model objects.

Quality assurance is described more in YIV instructions part 8.

2.11 Delivered material The delivery method and of the project and potential publication is agreed upon at the start of the project. Model material is delivered in entities that serve the following design or construction phase. A model de-scription document is always attached to models. A presentation model is just one part of the model mate-rial and helps visualization at public events and other presentations.

Once a project is finished, the material is delivered an open format previously agreed upon (for example Inframodel 3, IFC) as well as in native format of the modelling software. All models and digital documents are delivered in accordance with contract to the client, who has the right to use models with corresponding conditions as traditional project documents. Before delivery and sharing to third parties, empty and non-essential levels and modelling components have to be removed in accordance with YIV instructions part 8. Models can only contain modelling components by the designer. They may not include other designers’ models, even if they have been used as reference models.

It is essential, that the parties of the purchase process know what they intend to achieve with modelling and the how model can be utilized in the future.

The conditions for further use and exchange of delivered models are documented in a project contract or a separate delivery contract of models.

Documents

Common InfraBIM requirements YIV2015 - Etusivu · PDF file2.1 Software and formats ... Common InfraBIM requirements YIV2015 4 (17) ... and sustainable development in the project and