1

for Roads Deliverable 3.1. Inventory of available information exchange standards Editors Sander van Nederveen, Esra Bektas (TNO) Contributors Michel Böhms, Bart Luiten, Léon van Berlo (TNO) Olof Bergmann, Mikael Malmkvist (Trafikverket) Benno Koehorst (RWS) Eric Lebègue, Bruno Fies (CSTB) Final Draft Version 26 April 2013 This version is free for dissemination. It will be used as a basis for further activities in the V-Con project. Comments are welcome. Please send your comments to Benno Koehorst at benno.koehorst@rws.nl.

-Con.

-Con.

2

Table of Contents 1 Introduction ............................................................................................................ 3

1.1 Overall Goal of V-Con .................................................................................... 3 1.2 Task 3.1 ........................................................................................................... 3 1.3 Document Structure......................................................................................... 4 1.4 Reading Guide ................................................................................................. 5

2 V-Con Framework ................................................................................................. 6 2.1 Business Framework ....................................................................................... 6 2.2 ICT Framework ............................................................................................... 8 2.3 Total V-Con Framework ............................................................................... 12 2.4 V-Con Scope ................................................................................................. 13

3 The List of Standards ........................................................................................... 15 3.1 ISO ................................................................................................................ 15 3.2 IEC 81346-2 .................................................................................................. 27

3.3 W3C .............................................................................................................. 28 3.4 Object Management Group (OMG) .............................................................. 30 3.5 OGC .............................................................................................................. 32 3.6 INSPIRE ........................................................................................................ 34 3.7 LandXML.org ............................................................................................... 37 3.8 Standards in the Netherlands ......................................................................... 38 3.9 Standards in Sweden ..................................................................................... 43 3.10 Standards in Germany ............................................................................... 53 3.11 Standards in Norway ................................................................................. 54 3.12 Other Standards ......................................................................................... 54

4 Currently Used Configurations of Standards ....................................................... 58 4.1 International Configurations ......................................................................... 58 4.2 National Configurations ................................................................................ 60

4.3 Company-specific Configurations................................................................. 62 4.4 Project-specific Configurations ..................................................................... 65

5 Assessment of Standards and Configurations ...................................................... 67 5.1 Assessment Table .......................................................................................... 67 5.2 Conclusion ..................................................................................................... 68

6 Follow-up ............................................................................................................. 70 References .................................................................................................................... 71 Appendix A Abbreviations ..................................................................................... 73 Appendix B General about information ................................................................. 74

3

1 Introduction

1.1 Overall Goal of V-Con The Virtual Construction for Roads (V-Con) project aims at improving the efficiency and effectiveness of the National Road Authorities by improving data exchange in the civil infrastructure sector using the Building Information Modelling (BIM) approach. BIM has already been successfully implemented in other sectors, and now is a worldwide development. However, the civil infrastructural sector still lags behind to benefit BIM. On one hand, this sector feels no need to invest in standardisation of data exchange formats and contribution to the use of BIM in infrastructure projects. On the other hand, the software industry hesitates to develop software for their infrastructure clients when there is too much uncertainty about the market potential of their products. Without getting a software support, authorities such as Rijkswaterstaat (RWS) and Trafikverket (TRV) will not use information standards in their own projects and processes and therefore they will not demand the use of the standards from the contractors. This represents a cyclic relation between road authorities and software companies that hinders to benefit BIM in infrastructure projects. V-Con attempts to break out of this circle of an ICT-standstill within road constructions. It will define a (sets of) standard for road constructions, procure necessary software and launch a PCP (Pre-Commercial Procurement) for a RIM-server (Road Information Model Server) and software tooling. V-Con has two primary objectives; 1) establishing a draft version of a standardised information exchange structure, and 2) procuring and testing software systems in a PCP that comply with this structure. The results will be embedded in two ‘use-cases’

that will be the procurement of two large infra projects, one in the Netherlands and one in Sweden. Coordination activities are foreseen: first between the two leading research institutes in this field, TNO from the Netherlands and CSTB from France. Secondly, with the National Road Authorities in the Netherlands (RWS) and Sweden (TRV). Thirdly, with the software vendors in the sector. And fourthly with the rest of the civil infrastructural sector. The result will be a draft version of a standard that will be used in the software that will be procured in the PCP part of the project. Dissemination of V-cons results will take place in the appropriate networks of these types of organizations. The project takes four years and started in October 2012 with selecting the approach for the standardised information exchange structure in work package 3. This document is the result of these first steps.

1.2 Task 3.1 This document is called Deliverable 3.1, the main deliverable of Task 3.1 in the V-Con project. The Description of Work describes the objective of Task 3.1 as follows:

Identify and analyse usability of existing information exchange standards for the following areas: Management information

4

System engineering Description of highways and their parts Geographical information Object libraries This inventory can make use of the inventory made by RWS and TNO early 2011 and similar work done by CSTB.

This document describes the results of Task 3.1. Please note that an inventory of this kind is by definition never complete, nor up-to-date. Therefore the authors have tried to focus on standards that are relevant for the V-Con project. The different elements of Task 3.1 and the relationship with Task 3.2 are visualized in Figure 1.1 below.

Figure 1-1 In V-Con WP3 develops the Road Information Structure to be used by RWS and TRV.

T3.1 provides an inventory of available information exchange standards, that can be used in the alternative scenarios in T3.2. In Task 3.2 these alternative scenarios are worked out and one scenario is selected for use in T3.3, T.3.4 and WP 2.

1.3 Document Structure This document is structured as follows: Chapter 1 provides an introduction. Chapter 2 presents a framework for standards in order to position current information exchange standards and define the scope of V-Con project. This framework has a Business part and an ICT part. The framework is used for different purposes:

Definition of the scope of V-Con, in 2.4 Positioning of standards, in Chapter 3 Positioning of configurations (see below), in Chapter 4

Chapter 3 lists a number of standards are listed. This comprises both international and national standards. The international standards description is structured along the organization that develops the standard, for example ISO. The national standards are

5

of course organized by country. For each standard, the key characteristics are described. Chapter 4, presents “configurations of standards”. These configurations are different

sets of standards that are being used in current projects and that fit well together. In this chapter, configurations are described on different levels:

International National Company-specific Project-specific

Chapter 5 presents a table with an overview of the most relevant standards and configurations and assesses them along selection criteria for standards as identified in V-Con Deliverable D3.2 Finally Chapter 6 gives an outlook of the follow-up of this deliverable as will be carried out in Task 3.2 Definition of Road Infrastructure. In Task 3.2, an evaluation and selection of the standards presented in this document will be carried out.

1.4 Reading Guide Not all parts of this document are intended for all audiences. Many readers will not need to read all the technical details of information exchange and sharing technologies. For example:

Domain Experts, such as infrastructure project managers, Experts in related areas, such as experts in GIS, CAD, document management,

building classification, building codes, etc.

Interested readers who belong to these groups, or to groups with another background, are recommended to read the following parts of this deliverable:

Chapter 1 Introduction Introductions of all chapters Paragraph 2.4 V-Con Scope Chapter 5 Assessment (table) Chapter 6 Follow-up

Also the Reference section and the Appendices can be very helpful. The Reference section provides useful links for further reading, including original sources of some of the standards discussed. Appendix A clarifies abbreviations. Appendix B clarifies a number of common terms on information modeling and information exchange. In addition, readers could zoom in on subjects/areas they are familiar with. For example, a GIS expert might take a closer look at paragraph 3.5 on OGC and 3.6 on INSPIRE. Finally, BIM/Modeling Experts who are familiar with developments such as IFC should read the whole document.

6

2 V-Con Framework In this chapter the V-Con Framework is presented. The V-Con Framework can be used for the following purposes:

Positioning of information exchange standards Definition of the scope of the V-Con-project, as well as other developments.

The V-Con Framework will be presented step by step. First, the Business Framework is presented. This part of the V-Con Framework is intended for the positioning of standards in the business domain of road authorities Next, the ICT Framework is presented. This part of the Framework is intended for the positioning of standards with respect to their ICT-characteristics.

2.1 Business Framework

2.1.1 Impact Dimension The Impact dimension provides a distinction between three kinds of impacts: impact on People, Prosperity, or Planet.

Figure 2-1 The Impact Dimension

2.1.2 Life-Cycle Dimension The Life-Cycle Dimension provides a distinction in life-cycle stages, from idea to demolition and re-use. Typical life-cycle phases for roads are Program, Design, Plan, Build, Operate and Exploit. During the life cycle of roads from program to exploitation, validation takes place on different levels: technical, functional and business level.

PeopleSafer, less traffic jams

ProsperityFailure cost down, transaction cost down, profits up

PlanetEnergy/CO2 reduction

7

Figure 2-2The Life-cycle Dimension

2.1.3 The Supply-Chain Level Dimension The next dimension for road information is the Supply-chain Level dimension (or decomposition/aggregation level, etc.). Typical levels for roads are geospatial area, structure, system, part and component.

Figure 2-3 The Supply Chain Level Dimension

There are many ways to define decomposition levels in construction. For example ISO 12006-2 has other decomposition levels. For the V-Con Framework we have chosen levels that have been agreed upon by TNO and CSTB in a mutual agreement for information modeling in the Building and Construction Industry.

Program

Design

Plan

Build

Operate

Exploit

PREP

ARE

(“T

HIN

K”)

REA

LIZE

(“D

O”)

valid

atio

nGeospatial Area**

Product > here: Structure

System > here: Building System

Part > here: Building Element/Building Space

Component

Material

* Client<>Contractor nested** Not building spaces …

8

It should be noted that it does not really matter what levels are chosen, as long as it is possible to position standards or standardization developments along a supply chain/decomposition level dimension.

2.1.4 The V-Con Business Framework Combination of the three business dimensions leads to the following matrix.

Figure 2-4 The V-Con Business Framework

The first dimension is the Impact dimension. It is represented at the top of the matrix. The second dimension is the Life-cycle Phase dimension; this dimension forms the horizontal axis of the matrix. The third dimension is the Supply-chain Level dimension; it forms the vertical axis of the matrix. The idea is that standards or developments can be positioned along these three dimensions. In principle any combination of values along the dimensions is possible; the dimensions are independent of each other. Figure 2.4 also shows two typical application areas in infrastructure: BIM and GIS. It is expected that these areas will become important in V-Con. In GIS models and systems, infrastructure systems and their environment are typically described on the two highest supply chain levels: geospatial area level and product level. In BIM models and systems, infrastructure systems are typically described on all levels ranging from geospatial area to material. It is obvious that BIM and GIS “meet” on

the two highest levels.

2.2 ICT Framework

2.2.1 Primary ICT Characteristics For the ICT-Framework, three primary ICT characteristics are taken into account. The first characteristic is the distinction between functionality (software) and data. This distinction slices the ICT world into (1) functionalities offered to end-users and (2) the data in a general sense that is handled by/related to those functionalities.

Life-cycle Phase

Supply-chain Level

Program Design Plan Build Operate Exploit

Spatial Area

Construction

System

Equipment

Component

Material

Life-cycle Phase

Supply-chain Level

Program Design Plan Build Operate Exploit

Geospatial Area

Product

System

Part

Component

Material

“GIS”

“BIM”

Impact People Prosperity Planet

9

The second characteristic is the distinction between specification and implementation. This distinction indicates that both functionalities and data, can be (1) specified and (2) (often partially) implemented in software. The V-Con project focusses in work package 3 on the (agreed) “Data Specification” part of this total ICT picture. In the

tendering phase of V-Con the focus will shift towards the actual implementation of the data-specification and existing end-user functionalities supporting those data aspects via compliant interfaces like import/export- mechanisms, API’s and/or plug-ins. The third characteristic is the semantic level. Here, first a distinction is made between (1) the actual Semantics & Information and (2) the Technologies or languages used to express this semantics/information. Furthermore we state that we have different layers: (1) the information directly reflecting reality (‘content’), (2) the information structures

governing this information and sometimes (3) a third layer in the form of an explicit meta-model governing the information structures below. The latter can typically be left blank because the semantics of the language used to express the information structures below can fulfil this role. Finally we split the kind of semantics we are interested in into (1) object information like classes, properties, and relationships, (2) representation information like explicit shape or ‘geometry’ and (3) information about information or meta-information like authorship, version info, etc. where the V-Con focus is clearly on the ‘Object

Semantics’ (in the form of object libraries/ontologies). Based on these three primary characteristics, the following matrix can be defined, see Fig 2.5. In this matrix, the characteristics are used to define three dimensions.

Figure 2-5 The three primary dimensions of the ICT Framework

Functionality (software) DataSpecification • Meta-Semantics

• Semantics for• Meta (PLM/VISI/…)

• Object• Geometry

• Information• Meta (PLM/VISI/…)

• Object• Geometry

• Technologies• Languages for all

above

• Access Mechanisms*

Implementation

* Import/Export (I/E), Application Programming Interfaces (APIs), Web Service (WS) interfaces, Query Language (QL) interfaces

10

2.2.2 Coverage and Applicability Dimensions The coverage dimension distinguishes between international, continental, national, organizational and project specific developments as illustrated in Fig 2.6.

Figure 2-6 Coverage Dimension

The applicability dimension distinguishes between general developments for all kinds of products or applications, and product/application-specific developments, see Fig 2.7.

Figure 2-7 Applicability Dimension

International (=”global”, “worldwide”)

Continental (European, US, Asian, …)

National (NL, SE, FR, …)

Organisation (RWS, Trafikverket, RGD, BAM, VolkerWessel, …)

Project (RWS SAA, TRV Stockholm Bypass, …)

GenericAny market/product type

MarketConstruction, Mechanical, Electronics, …

SegmentCivil Infra, Buildings, Automotive, Consumer Electronics, …

ProductResidential Building, Office, Road, Bridge, Car, Laptop, …

11

2.2.3 The V-Con ICT Framework Combination of the five ICT dimensions leads to the following framework, see Fig 2.8.

Figure 2-8 The V-Con ICT Framework

As you may have noted, the primary dimensions have been slightly restructured in comparison to Fig 2.5.

Underlying Technologies for

Meta-Semantics

Information (Meta, Object, Geometry)

Semantics(for Meta, for Object, for Geometry)

Language for SemanticsLanguage for Information

SPECIFICATION

IMPLEMENTATION(“Software”)ClientClient

Server

FUNCTIONALITY DATA

Access M

echanisms

(AP

I’s, We S

ervices, Q

uery

Lan

gu

ages)

International Continental National Organisation Project

Language for Meta-Semantics

Generic Market Segment Product

12

2.3 Total V-Con Framework Integration of the Business Framework and the ICT Framework results in the total framework shown in Fig. 2.9.

Figure 2-9 Total V-Con Framework

13

2.4 V-Con Scope

2.4.1 Business View The framework presented in sections 2.1-2.3 can be used to position all kinds of standards and developments. But first the framework will be applied to the project V-Con itself, in order to define the project scope of V-Con. Through a questionnaire and discussions at project meetings the following statements about the scope of V-Con have been made:

The two end-user organizations in V-Con, Rijkswaterstaat en Trafikverket, have similar interests, therefore the same scope will be used for both partners;

On the Life-Cycle dimension, the most important life-cycle phases are programming & design and operation & exploitation; planning and building is the domain of construction companies and are less important for road authorities.

The most important interactions are (1) between the client project office and the construction company and (2) between the client project team and the clients’

operation and management department. On the impact dimension, People, Planet and Prosperity are all important. On the Supply-Chain Level dimension, all levels are important, from geospatial area level to the detailed component level. These statements can be visualized as follows, see Fig 2.10

Figure 2-10 V-Con scope, business view

Life-cycle Phase

Supply-chain Level

Program Design Plan Build Operate Exploit

Geospatial Area

Product

System

Part

Component

Material

Asset Management

Traffic Management

Impact People Prosperity Planet

Network Management :

validations

14

2.4.2 ICT View With respect to ICT, the following statements have been made:

Applicability: focus on roads, and on interfaces with e.g. bridges, flyovers, tunnels, installations and electronic systems.

Coverage: emphasis on European development, with possibility to have national/local or company-specific solutions;

Semantic level: focus on semantics, rather than geometry or meta-semantics; (choices of) languages are considered important, but we do not plan to develop new languages;

Focus on specification, later on implementation, especially on software interfaces, (BIM-GIS, BIM-asset management, etc. etc.).

These statements can be visualized as follows, see Fig 2.11:

Figure 2-11 V-Con scope, ICT View

IMPLEMENTATION(“Software

Interfaces”)

Underlying Technologies for

Meta-Semantics

Information (Meta, Object, Geometry)

Language for SemanticsLanguage for Information

SPECIFICATION

ClientClient

Server

FUNCTIONALITY DATA

Access M

echanisms

(AP

I’s, We S

ervices, Q

uery

Lan

gu

ages)

International Continental National Organisation Project

Language for Meta-Semantics

Generic Market Segment Product

Semanticsfor Meta for Object for Geometry

Focus: Roads

European

Civil Infrastructures

‘localised’ ‘made company-specific’

15

3 The List of Standards In this chapter an overview is given of standards that are (or may be) relevant for the V-Con project. For each standard, some key characteristics are described. These characteristics are such as semantics (object, geometry, meta-semantics), languages, access mechanisms etc, as visualized earlier in Fig 2.5. The listing is done based on the organization that develops standards (ISO, W3C, OGL etc.). In Chapter 4, a number of so-called configurations of standards will be discussed. Configurations are sets of standards that are being used in current projects and that fit well together. Of course the configurations in Chapter 4 are typically composed of standards in Chapter 3. In Chapter 5 both a number of relevant standards from this chapter and relevant configurations of Chapter 4 are assessed. The result is an assessment table that gives a good quick overview of the standards and configurations most relevant for V-Con. For the selection of standards to be included in Chapter 3, it was decided to focus on open standards that provide standardization on a semantic level. Typically, semantic standards are model-/object-based and well structured. This focus follows from the choices made in the V-Con framework in the previous Chapter. It should help to make an effective start of the later tasks in V-Con, such as T32, T33, T34 and WP 2. Still. the list presented here is more or less arbitrary: the number of standards that could be included is almost infinite. Therefore some standards of this list are obvious, while others could have been left out and yet others that are left out, could have been included.

3.1 ISO ISO (International Organization for Standardization) is an international standard-setting body composed of representatives from various national standards organizations. Founded on February 23, 1947, the organization promulgates worldwide proprietary, industrial, and commercial standards. Below, we provide the standards that are relevant for the V-Con framework.

3.1.1 ISO STEP (Wikipedia 2012a) ISO STEP, formally called ISO 10303, is an ISO standard for the computer-interpretable representation and exchange of product manufacturing information. Its official title is: Automation systems and integration — Product data representation and exchange. It is known informally as "STEP", which stands for "Standard for the Exchange of Product model data". ISO 10303 can represent 3D objects in Computer-Aided Design (CAD) and related information. The STEP standard can be roughly divided in two parts: a domain-specific model part and a supporting technology part. The domain-specific model part consists for example of a number of so-called Application Protocols (APs), conceptual models that provide a basis for information exchange in specific industrial areas. For example: AP 214 focuses on the automotive industry, while other APs focus on process and offshore industries, manufacturing, aerospace etc.

16

The technology part of STEP provides a number of generic languages, formats and tools that can be used for the domain-specific STEP Parts. Some examples of supporting technology are: the EXPRESS data modeling language and EXPRESS-based tools, the STEP Physical File and STEP-XML-formats, and the database interface SDAI (Standard Data Access Interface). More or less inbetween the “models” and the “technologies” is the STEP Part on

Geometry and Topology. This Part has indeed a conceptual model (for shape description), but has a supporting role in many domains. For BIM the biggest relevance of STEP is that many BIM standards use STEP technology. Especially BuildingSMART standards make use of STEP technology. In the past there have been attempts to develop a STEP AP for building and construction, such as the STEP Building Construction Core Model (BCCM). But during nineties, the the Industrial Alliance for Interoperability (which became later buildingSmart) took over the development and launched the IFCs.

Figure 3-1 ISO/STEP positioned in the framework

EXPRESSBIMserverSolibri…SPFF

SDAI

(Example: AP-214)

17

STEP Part 28 (P28) The standard is a data format for STEP/EXPRESS information in XML. The format is a part of the STEP standard and designated ISO 10303-28, and is published by ISO1.

SDAI and API (http://en.wikipedia.org/wiki/ISO_10303-22) SDAI is a part of the implementation methods of STEP formally called ISO 10303-22. SDAI itself is defined independent of a particular programming language. Language bindings exist for

Part 23 - C++ language binding of the standard data access interface Part 24 - C binding of the standard data access interface Part 27 - Java binding to the standard data access interface with

Internet/Intranet extensions

The development of language bindings for FORTRAN and the interface definition language (IDL) of CORBA were canceled. SDAI defines an abstract Application Programming Interface (API) to work on application data according to a given data models defined in EXPRESS. API is a protocol intended to be used as an interface by software components to communicate with each other (http://en.wikipedia.org/wiki/Application_Programming_Interface). The original intent of SDAI and its bindings to programming languages was to achieve portability of software applications from one implementation to another. This was soon abandoned because there were only a few commercial implementations and they differed significantly in their detailed APIs. Today the term SDAI is sometimes used for all kinds of APIs supporting STEP, even if they only partially follow the strict functionality as defined in ISO 10303-22 and its implementation methods, or not at all. Part 35 of STEP (Abstract test methods for SDAI implementations) provides a formal way how to prove the conformance of an implementation with SDAI.

STEP APs

STEP APs can be roughly grouped into the three main areas design, manufacturing and life cycle support.

Design APs includes mechanical, connectivity oriented electric, electronic and piping/ventilation, ship and others (i.e. Building elements, technical data packaging core information and exchange, systems engineering data representation, fluid dynamics etc.).

Manufacturing APs are for information exchange of dimensional inspection, design and manufacturing product, mechanical product definition for process plans using machining features, application interpreted model for computer numeric controllers and process plans for machined products.

Life cycle support APs contains functional data and schematic representation of process plants and generic model for life cycle support of AEC Facilities.

PLCS (Product LifeCycle Support) The Product LifeCycle Support (PLCS) standard (ISO 10303-239) is a STEP Application Protocol. It is an international standard that specifies an information 1 www.iso.org

18

model that defines what information can be exchanged and represented to support a product through life. This definition is provided by using the EXPRESS information modelling language. The basic data structures that are exchanged are defined by EXPRESS Entities. It is particularly used for the life cycle related structuring and definitions:

Change Management Versioning Consolidation Requirement Product as realized Maintenance

The business objects in PLCS cover the whole life cycle for products, with the goal to support the maintenance, influence the design, development and production for maintainability and finally influence the requirement improvements. It would be impractical to contract for data compliant with ISO 10303-239 PLCS without a means of specifying the scope required. "Data EXchange specifications" ("DEXs") are defined in order to constrain the full information model to the scope required.

Fig 3.2 Overview of the Data Exchange Specification (DEX) of ISO 10303-239 PLCS

The Data Exchange Specification is a subset of the PLCS information model, designed to support data exchange for specific activities, providing guidance and rules for how to use and combine the selected entities and external Reference Data in that exchange. Each DEX includes a complete EXPRESS schema. This is a subset of the PLCS schema with a derived XML Schema. Both can be used to define and validate a data exchange file.

19

3.1.2 ISO TC211/CEN TC287 (Source: http://www.isotc211.org/) ISO TC211is a standardization in the field of digital geographic information. This work aims to establish a structured set of standards for information concerning objects or phenomena that are directly or indirectly associated with a location relative to the Earth. These standards may specify, for geographic information, methods, tools and services for data management (including definition and description), acquiring, processing, analyzing, accessing, presenting and transferring such data in digital/electronic form between different users, systems and locations.

Fig 3.3 Digital geographic information standards, such as ISO 19147, positioned in the V-Con Framework.

UML

XML,GML

SFA

(Example: ISO - 19147)

20

The work shall link to appropriate standards for information technology and data where possible, and provide a framework for the development of sector-specific applications using geographic data. Examples of relevant standards for building information are ISO 19103, 19107, 19109, 19111, 19115, 19128, 19136, 19142, 19147, 19148, 19157 etc.

3.1.3 ISO 19100 ISO 19100 is an international series of standards for geographic information that forms the basis for the exchange of spatial data between different information systems. It is also the basis of the INSPIRE Directive. 2 The standard is being developed within the International Technical Committee ISO / TC 211 Geographic Information / Geomatics. Sweden participates through Stanli. The standard defines a generic data model for geographic information and specializations of this for different uses.

The generic data model is called the framework and reference model (Framework and Reference Model).

It is specified additionally for geographic information in the part data-models and relationships (Data Models & Operators).

The information system's incoming and outgoing data are specified divided on information services (Geographic Information Services) and data management (Data Management).

Specializations for different uses are specified in the Profiles and Functional Standards. Each such specialization has each their geometrical specification (Data Models & Operators) and specification of incoming and outgoing data. The standard illustrates this with the figure below.

Figure 3.4: Illustration of the ISO 19100-series standards

2 (2012)

21

3.1.4 IFC (Source: http://en.wikipedia.org/wiki/Industry_Foundation_Classes) The Industry Foundation Classes (IFC) data model is intended to describe building and construction industry data. It is a neutral and open specification that is not controlled by a single vendor or group of vendors. It is an object-based file format with a data model developed by buildingSMART (International Alliance for Interoperability, IAI) to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used format for BIM. The IFC model specification is open and available. It is registered by ISO as ISO/PAS 16739 and is currently in the process of becoming the official International Standard ISO 16739 (Wikipedia 2012b). The IFC constitutes a framework for sharing information between different disciplines within the AEC/FM industry throughout the project lifecycle (IAI 2000:2). The main purpose of the IFC is to enable effective information exchange between information systems, so called interoperability (Ekholm 2005). This concerns both semantic definitions and object exchange formats. The semantic definitions of the IFC concern, just as ISO 12006-2, objects of interest in construction and facilities management but especially not all infrastructure objects are covered in IFC. However, IFC does not adhere to the ISO-standard and has different definitions and general structure. The documentation of IFC does not present a theoretical background for its structure or choice of model classes. It was built following the general EXPRESS modeling conceptual frame-work (Ekholm 2005). The primary technology underlying IFC is ISO STEP technology: the information structure is recorded in the modelling language EXPRESS and the associated data is expressed in accordance with the STEP Physical File Format (SPFF) (Ekholm 2005). A secondary variant of IFC, IfcXML, uses W3C XML technology: here the information structure is recorded in eXtensible Schema Definition (XSD) and the associated data is expressed using eXtensible Markup Language (XML). As many experience IFC as a complex model, a ‘simplified IfcXML' concept has recently been developed, for which a viewer is available from software supplier DDS (Ekholm 2005). A part of IFC relates to semantic objects such as IfcBuilding, IfcColumn, IfcSpace, etc. while another part relates to the associated geometry (the ‘explicit form

representation’) (Ekholm 2005). These objects have a limited number of hard-modelled properties. Moreover, in addition to these predefined property types, additional property types (with any status) can be added using so-called ‘property sets’

that are defined with Property Set Definition (PSD) and, like IfcXML, are expressed in XML technology. Various property sets have already been defined by BuildingSmart, particularly as a supplement to the last IFC version, “2x4”, which is soon to be released (Source: (Ekholm 2005)). The IFC standards suitably provide an information sharing and exchange platform, which can couple with the network technology to form a central database server to facilitate information exchange between different parties from various geographic locations (Chen et al. 2005). IFC offers primarily models for objects in the building domain; for the infrastructure domain there is a lot less available. Of course it is possible to use columns, beams and

22

floors to model a bridge. But typical road elements (especially elements with typical road-specific geometry such as clothoids) are not offered. There have been several initiatives that aimed at the extension of IFC for infrastructure. Currently, a number of international specialists who are interested in this issue, have formed a group called OpenInfra. OpenInfra is exploring and co-ordinating on-going activities in the field of open information standards for infrastructure. OpenInfra is linked to the buildingSMART-organization. Developments that OpenInfra is currently looking at include LandXML and IFC-Bridge. LandXML are further explained in 3.5. IFC-Bridge is a proposal for an extension of IFC and provides entities particularly tailored for the geometric and semantic description of bridges. This includes entities for the definition of roadway tracks, such as IFCClothoid. IFC-Bridge has not been published as an official standard, but is still under development. The current draft has been developed by the French researchers G. Arthaud and E. Lebegue (CSTB). This draft dates from 2005 but there are plans to continue the work. Finally three more advanced technical concepts related to IFC need to be mentioned: IDM, bSDD and MVD. bSDD (buildingSMART Data Dictionary) is used to uniquely identify properties independent of which format the property resides is. It is used for language translation of property descriptions, enumerators and values and for mapping between various classification systems (source: buildingSmart). More information on bSDD can be found in 3.1.6. MVD – (buildingSmart 2012) An IFC View Definition, or Model View Definition, MVD, defines a subset of the IFC schema, that is needed to satisfy one or many Exchange Requirements of the AEC industry. This definition is created using the MVDxml standard. The method used and propagated by buildingSMART to define such Exchange Requirements is the Information Delivery Manual, IDM (also ISO/DIS 29481). Model View Definition, specifies a view-specific subset of IFC to be agreed upon by project participants or by actors of the same discipline. IDM, Information Delivery Manual (ISO 29481-1:2010), is a methodology and format for the development of an information delivery manual. It is a standard specifying a methodology that unites the flow of construction processes with the specification of the information required by this flow, a form in which the information should be specified, and an appropriate way to map and describe the information processes within a construction life cycle. In a simple manner, IDM specifies the delivery process to be followed; how the model developer must deliver IFC data to model users. IDM is intended to facilitate interoperability between software applications used in the construction process, to promote digital collaboration between actors in the construction process and to provide a basis for accurate, reliable, repeatable and high-quality information exchange. (Source: http://www.iso.org/iso/catalogue_detail.htm?csnumber=45501). IDM is adapted from international practices, to facilitate identification and documentation of information exchange processes and requirements Nawari (2012). It

23

is the international standard for defining the information that should be exchanged between project participants in the AEC project lifecycle (Park et al. 2011). The IDM process consists of three parts: the process map (PM), exchange requirement (ER), and functional part (FP). IDM recommends using business process modeling notation (BPMN) for defining a PM (ISO/TC59/SC13, 2008) (Park et al. 2011). For an overview of IFC positioned in the V-Con Framework, please see Figure 4.1 in Chapter 4.

IFC-Bridge IFC-Bridge is a first tentative of introduction of infrastructure meta-Information, and bridges, in particular, within IFC. IFC-Bridge, which is an official BuildingSmart International (BSI) project, was originally, developed, in 2006, by SETRA (Service d’Etudes Techniques des Routes

et Autoroutes of France), as Project Leader (Jean Gual) and CSTB as Technical Leader (Eric Lebègue). IFC-Bridge project has been officially internationally re-launched in 2012 with Bouygues as Project Leader (Pierre Benning) and still CSTB as Technical Leader (Eric Lebègue). IFC-Bridge was and is also developed with a set of international participants from Germany (Thomas Liebich, IAI German Chapter and BSI Modeling Support Group leader), Jeffrey Wix (BSI UK Chapter), Robin Drogemuller (BSI Australian Chapter), Kari Karstila (BSI Finnish Chapter) and Nabuyoshi Yabuki (BSI Japan Chapter) and some representative of other French companies like VINCI, EGIS (Christophe Castaing, leader of openINFRA project). Scope of IFC-Bridge is to carry out full development of the IFC model extensions from other IFC development projects to capture design information for providing a standard exchange and archiving model data related to the whole bridge life cycle.

Fig 3.5 Different actors create, process and use bridge project data during the bridge life cycle Scope of IFC-Bridge model data is the following:

General structure of bridges; Complete geometry definition;

24

Technological definitions ; Materials associations (Concrete, steel, wood…); Pre-stressing information; Process control.

IFC-Bridge introduces new EXPRESS entities as extension of the IFC4 data model:

Figure 3-6 IFC-Bridge, extension of IFC data model

Figure 3-7 : illustration of some IFC-Bridge entities.

25

3.1.5 gbXML The standard gbXML (Green Building XML) is a data format in XML for communication of information between BIM (building) and a large number of analysis programs, for example, automatic energy analyzes. The standard is published here.3 The standard was originally developed in 1999 by the Green Building Studio, USA.

3.1.6 ISO 12006 ISO 12006 consists of part 2 (ISO 12006-2) and Part 3 (ISO 12006-3). Part 1 should have been defined as the common basis for the standard 12006 but is yet missing.

ISO 12006-2 ISO 12006-2 is the international framework standard for construction classification with the aim of international harmonization and interoperability for building classification systems. The standard is being revised. A CD version (Committee Draft) is expected in early 2013 and the final standard around the end of 2013-2014. Working version in October 2012 contains recommendations for 18 different Classification tables that may be appropriate to develop (17 of these are objects and one concerns properties). At this writing, the development points to that the current tables will be used together in a clearer way. The idea is that at the same time it should be possible to classify complex objects like a building as construction parts and production results. ISO 12006-2 consists of four parts:

Definitions of terms Concepts Model Table of which classifications-tables that are recommended Examples of classes in classifications-tables

ISO 12006-3, IFD (Source: http://www.ifd-library.org/index.php?title=Main_Page) IFD, the International Framework for Dictionaries, is a standard for terminology libraries, or ontologies. Initially, IFD was set up for “pure” dictionaries, i.e. lists of words with

explanations. But later on IFD became a high-level conceptual model for construction information. The concept for the IFD Library is derived from internationally-accepted open standards that have been developed by ISO (most importantly ISO 12006-3:2007 “Building construction -- Organization of information about construction works –Part 3: Framework for object-oriented information”). IFD Library is one of the core components of the buildingSMART technology, the others being IFC and IDM/MVD. IFD Library provides flexibility for an IFC-based building information model (BIM) allowing for the link between the model and various databases with project and product specific data. IFD Library:

Opens up for a model enrichment that will allow for advanced analysis, simulation and design checks at a very early phase.

3 www.gbxml.org

26

Provides a real opportunity to generate an IFC-BIM for operational and maintenance purposes with storage of product specific data, although IFD itself has a generic data.

Provides a feasible method of linking existing knowledge systems to an IFC-BIM.

Provides multilingual and translation capabilities to the information in an IFC-BIM.

The IFD standard has many similarities with the EPISTLE4 standard for the Oil and Gas industry (Bell and Bjørkhaug, 2007a in Hjelseth 2009).

3.1.7 PLIB PLIB is acronym of Industrial automation systems and integration - Parts library. It is also ISO 13584 is PLIB is developed and maintained by the ISO technical committee TC 184, Technical Industrial automation systems and integration, sub-committee SC4 Industrial data (source: http://en.wikipedia.org/wiki/ISO_13584) Sardet et al (1998) defines PLib Standard (officially the ISO 13584 Standard series "Parts Library") as a model and an exchange format for digital libraries of technical components. The major benefits of this approach include: productivity increase (the components are not modeled several times), quality increase (the data models are guaranteed by the supplier of the library) and product data storage / exchange efficiency (in product data a component is only represented by a reference). Developed in the same ISO committee as STEP, PLib is fully inter-operable with STEP. In PLib libraries, component representations may be defined as STEP data. In STEP product data, PLib components may be represented by simple references. (Sardet et a. 1998) Leukel et al. (2006) emphasizes the research on the ontological aspect of ISO 13584 and its contribution to semantic integration. In this context, all data exchange is assigned to PLIB’s own exchange format that is specified in the EXPRESS language

of STEP and results in non-XML data files; e.g. [7] [8].

3.1.8 ISO 15926 ISO 15926 is a standard for data integration, sharing, exchange and hand-over between computer systems, with origins in a number of projects and organizations from the process and offshore industries (EPISTLE, POSC-Caesar, USPI, etc). The full title is “Industrial automation systems and integration – Integration of life-cycle data for process plants including oil and gas production facilities” (Fiatech 2011). Similar to IFC, the history of ISO 15926 starts with development activities in ISO-STEP, most notably the development of AP 221 “Functional data and schematic representation of process plants”. In terms of the Applicability Dimension (see 2.2.2), ISO 15926 is in the “Process and

Offshore” market segment. This is different from the V-Con domain. But the domain is similar: infrastructure projects and process industry projects are both large scale engineering projects, in which coping with complexity, multiple disciplinary collaboration and life cycle orientation etc. are important issues.

27

From a V-Con point of view, ISO 15926 has some very interesting and relevant elements.

Part 1 ”Overview and Fundamental Principles” is relevant for defining modelling guidelines.

Part 2 ”Data Model” defines the entities/objects of ISO 15926 in conceptual models, including functional requirements, physical solutions, object types and instances, activities, etc.

Part 4 ”Initial Reference Data” provides a list of terms used in the process industry, including many standard objects (instances, or catalogue items). This list of standard objects is typical for ISO 15926, BuildingSMART does not have something like this.

Part 8 provides a mapping of Part 2 (which is originally defined in EXPRESS) to OWL

Part 11 includes a description of the Gellish language, a language developed by Van Renssen aiming at a semantically richer and more natural alternative for mainstream modelling languages such as UML of EXPRESS (Renssen 2005).

3.2 IEC 81346-2 An important standard that needs to be developed more for Swedish use is ISO / IEC 81346. (Industrial systems, installations and equipment and industrial products – Structuring principles and reference designations – Part 2: Classification of objects and codes for classes). A reference system according to ISO / IEC 81346 has both a classifying and an identifying function. The identifying function uses the classifying function and creates identities for objects. The identification is done so that a classification code is complemented with a number that unambiguously identifies the object. With unambiguous means that the same identity (code + number) is not connected to more than one (1) object (occurence). The indication with the identifying part differ some between objects from different aspects, even if they refer to the same item (such as a pump as a product and a pump as a function). This allows the identifications to be unique within a project. The usefulness of the identifying function is to create a reference between the object and other information. Within the reference structure system aspect is a key concept. An aspect is a specific way to consider a system, and is applied in the reference standard to distinguish parts of the system. The parts can be different depending on the aspect, but the same parts can sometimes be found in various aspects. Attitudes differ on the usefulness of a combination of reference systems and classification systems. In Denmark, it is discussed and tested if the reference scheme system should be included in the further development of the new classification system CCS (CCS Cuneco Classification System). The work is led by Cuneco, see here.4 ISO / IEC 81346 or equivalent shall according to EU-Directive be applied in Sweden in the electrical and mechanical field. The construction industry in Sweden generally

4 http://cuneco.dk.

28

does not apply the reference scheme in connection with the construction classification, nor in any uses known to the writers except in Trafikverket facility registers (see description below). Requirements for digital information delivery for building construction with associated facilities and land is usually made through the use of industry recommendation Construction documents 90 Part 8 Digital deliveries. (Bygghandlingar 901 Del 8 Digitala leveranser) The recommendation is based in part on the ISO 12006-2 and IEC / ISO 82045 Document management, but not at the reference ISO / IEC 81346th. In the BH90 Part 8 it is defined, in contrast to the ISO / IEC 81346 that:

Identification involves the separation of a certain amount of information from each other in the current environment. Examples are the drawing number or Object-ID such as a specific door. Identifying indications should not be bearers of information to sort, group or filter the information. For this, other methods should be used. To satisfy different requirements, multiple identifying names need to be used, for example the planners used in building construction and property owner in management.

3.3 W3C (Source: http://en.wikipedia.org/wiki/W3C) The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web (abbreviated WWW or W3). W3C also engages in education and outreach, develops software and serves as an open forum for discussion about the Web.

29

W3C/IETF (Internet Engineering Task Force) Standards (over Internet protocol suite):

CGI CSS DOM GRDDL HTML MathML OWL P3P RDF SISR SKOS

SMIL SOAP SPARQL SRGS SSML SVG VoiceXML XHTML XHTML+Voice XML XML Events

XML Information Set XML Schema XPath XQuery XSL-FO XSLT WCAG WSDL XForms

Figure 3-8 W3C Standards positioned in the framework

DTD/XSD or RDF,RDFS,OWLXML or RDF-XML/Turtle/N3

Any schema or ontologyHTTP/URL

XPATH,XQUERYorSPARQL OSS RDF Server:

JENA-Fusekion TDB

“In principle:

any business scope”

30

3.4 Object Management Group (OMG) (Source http://en.wikipedia.org/wiki/Object_Management_Group) Object Management Group (OMG) is an international, open membership, not-for-profit computer industry standards consortium. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries. Originally aimed at standardizing distributed object-oriented systems, the consortium now focuses on modeling (programs, systems and business processes) and model-based standards. Products of the Object Management Group include:

Model Driven Architecture (MDA), a software design approach with a number of design principles;

Meta Object Facility (MOF), a modelling construct for defining meta-models for modelling languages, for mappings between these languages, and for transformation of their associated information structures and instances;

MOF Query/View/Transform (QVT) facility XML Metadata Interchange (XMI), metamodel for XML created with MOF

and QVT, and intended to transfer UML models between different modeling/software tools.

Unified Modelling Language (UML), a general purpose modelling language for object-oriented software development. UML includes a set of graphic notation techniques for different types of models (class diagram, sequence diagram, use case diagram etc.).

Object Constraint Language (OCL), a language for describing rules or constraints on UML-models or other MOF-based models.

Systems Modelling Languages (SysML), a modeling language based on UML for use in Systems Engineering, developed in collaboration with INCOSE (the International Council for Systems Engineering).

31

Figure 3-9 OMG Standards positioned in the framework

3.4.1 CAD-format

3.4.1.1 DWG The file format DWG (Drawing) is one of the CAD industry leaders, and is the default file format for AutoCAD software. The DWG format was developed in the late 1970s and has since 1982 been licensed by Autodesk, which also is the owner of Autocad. The DWG file format is supported by most software that can handle CAD files. Autocad can convert DWG Files into DXF files without losing graphical information. The format is constantly evolving, and since 2000 has several different versions been published - currently every three years.

MOF

XMI

UML OCL SysML

32

The different versions have similar format but different file structure, which means that third-party applications may have problems opening all versions. Within Trafikverket, it is mainly road projects that are planned with the DWG format. Special applications for AutoCAD - for example, Civil 3D and Architecture - contains objects that gets to be a new format at each annual upgrade. Such industry-specific objects can contain large amounts of information in addition to the graphical properties. They can be made readable in other AutoCAD versions through so-called Object Enablers. Attributes can also be linked to individual objects in DWG files by linking to XML files. In this manner, any set of properties can be stored.

3.4.1.2 DXF DXF (Data eXchange Format, also known as Drawing Interchange Format) is a format for transferring vector data, developed by Autodesk. It was created to transfer the geometric information to CAD software that does not support DWG format. The format handles most types of spatial objects, such as ellipse, line, point, text, and closed polygons. DXF has support for storing geometry in both plan and elevation. The format stores and transmits only vector data, which means that all other data, is lost. It should also be mentioned that any program that purports to support DXF does not do so completely, since there is no attributes standard. This means that the import of attribute data from DXF to other programs can be interpreted in different ways and even lose some information.

3.4.1.3 DGN DGN (Design) is the internal format of MicroStation and is developed by Bentley Systems. By the year 2000, the DGN files were based on ISFF file format, Intergraph's standard file format. That version was called V7 DGN, the current version is called V8 DGN. The format can be used as transfer format since it is well documented. The use of the DGN is not as widespread as the DWG. Within Trafikverket, the main rail projects are projected with the DGN format.

3.5 OGC The Open Geospatial Consortium (OGC) is an international industry consortium of 481 companies, government agencies and universities participating in a consensus process to develop publicly available interface standards. OGC® Standards support interoperable solutions that "geo-enable" the Web, wireless and location-based services and mainstream IT. The standards empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications. OGC® and OpenGIS® are registered trademarks of the Open Geospatial Consortium (OGC). OGC is the brand name associated with the standards and documents produced by the OGC. OGC standards are developed in a unique consensus process supported by the OGC's industry, government and academic members to enable geoprocessing technologies to interoperate, or "plug and play".

3.5.1 CSW The OpenGIS® Catalogue Services Interface Standard (CAT) supports the ability to publish and search collections of descriptive information (metadata) about geospatial

33

data, services and related resources. Providers of resources use catalogues to register metadata that conform to the provider's choice of an information model; such models include descriptions of spatial references and thematic information. Client applications can then search for geospatial data and services in very efficient ways.

3.5.2 WFS The OpenGIS Web Feature Service Interface Standard (WFS) defines an interface[http://www.opengeospatial.org/ogc/glossary/i] for specifying requests for retrieving geographic features [http://www.opengeospatial.org/ogc/glossary/g] across the Web using platform-independent calls. The WFS standard defines interfaces and operations for data access and manipulation on a set of geographic features, including:

Get or Query features based on spatial and non-spatial constraints Create a new feature instance Get a description of the properties of features Traverse XLinks

The specified feature encoding for input and output is the Geography Markup Language (GML) (Source: http://www.opengeospatial.org/standards/gml) although other encodings may be used. also an ISO standard (ISO 19136:2007)

3.5.3 WMS The OpenGIS® Web Map Service Interface Standard (WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent so that layers from multiple servers can be combined or not. It is also an ISO standard (ISO 19136:2007)

3.5.4 GML The OpenGIS® Geography Markup Language Encoding Standard (GML) The Geography Markup Language (GML) is an XML grammar for expressing geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. As with most XML based grammars, there are two parts to the grammar – the schema that describes the document and the instance document that contains the actual data. A GML document is described using a GML Schema. This allows users and developers to describe generic geographic data sets that contain points, lines and polygons. However, the developers of GML envision communities working to define community-specific application schemas [en.wikipedia.org/wiki/GML_Application_Schemas] that are specialized extensions of GML. Using application schemas, users can refer to roads, highways, and bridges instead of points, lines and polygons. If everyone in a community agrees to use the same schemas they can exchange data easily and be sure that a road is still a road when they view it. Clients and servers with interfaces that implement the OpenGIS® Web Feature Service Interface Standard[http://www.opengeospatial.org/standards/wfs] read and write GML data. GML is also an ISO standard (ISO 19136:2007) [www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32554].

34

See also the GML pages on OGC Network: http://www.ogcnetwork.net/gml GML (Geography Markup Language) is an XML-based protocol according to ISO 19118 for the transport and storage of geographic information in accordance with the ISO 19100 series. A basic idea of GML is to make geographic information vendor independent. The format can store both geographical and non-geographical attributes for objects. The GML scheme describes how a GML file must be structured and which objects can be described in it. For further information about GML, please see here.5

3.5.5 CityGML The German North Rhine Westphalia Sig3D organization originally developed CityGML, now a globally important OGC standard for sharing urban models and integrating design drawings with spatial data. Though CityGML is focused on 3D modeling, it also provides a practical standard way to integrate indoor/outdoor location, that is, a standard way to integrate building location in Earth coordinates with building details in the Euclidean geometry of Computer Aided Design (CAD) systems. CityGML is now being widely implemented in software products and online services. It is the standard for 3D geo-information in the Netherlands and CityGML 3D models are being built or considered by many countries. Bridge ADE is the Bridge Model of the SIG 3D and represents the spatial and thematic properties of bridges. Bridge ADE is a new module in CityGML 2.0. (Source: http://www.citygmlwiki.org/index.php/CityGML_Bridge_ADE)

3.6 INSPIRE INSPIRE is a European platform (set up with EU-funding) that serves as a co-ordinator for GIS-related standards. INSPIRE does not develop a lot of standards itself, but it primarily provides guidelines for standardization and references to standards to be used. INSPIRE was launched in May 2007 with the INSPIRE Directive, establishing an infrastructure for spatial information in Europe to support Community environmental policies, and policies or activities which may have an impact on the environment. INSPIRE is based on the infrastructures for spatial information established and operated by the 27 Member States of the European Union. The Directive addresses 34 spatial data themes needed for environmental applications, with key components specified through technical implementing rules. This makes INSPIRE a unique example of a legislative “regional” approach.

3.6.1 Legislation Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) was published in the official Journal on the 25th April 2007. The INSPIRE Directive entered into force on the 15th May 2007

5 http://www.opengeospatial.org/standards/gml

35

To ensure that the spatial data infrastructures of the Member States are compatible and usable in a Community and trans-boundary context, the Directive requires that common Implementing Rules (IR) are adopted in a number of specific areas (Metadata, Data Specifications, Network Services, Data and Service Sharing and Monitoring and Reporting). These IRs are adopted as Commission Decisions or Regulations, and are binding in their entirety. The Commission is assisted in the process of adopting such rules by a regulatory committee composed of representatives of the Member States and chaired by a representative of the Commission (this is known as the Comitology procedure).

INSPIRE Data Specifications/Application schemas - Spatial Themes

Annex I 1. Coordinate reference systems 2. Geographical grid systems 3. Geographical names 4. Administrative units 5. Addresses 6. Cadastral parcels 7. Transport networks 8. Hydrography 9. Protected sites

Annex II 1. Elevation 2. Land cover 3. Orthoimagery 4. Geology

Annex III 1. Statistical units 2. Buildings 3. Soil 4. Land use 5. Human health and safety 6. Utility and Government services 7. Environmental monitoring facilities 8. Production and industrial facilities 9. Agricultural and aquaculture facilities 10. Population distribution – demography 11. Area management / restriction / regulation zones & reporting units 12. Natural risk zones 13. Atmospheric conditions 14. Meteorological geographical features 15. Oceanographic geographical features 16. Sea regions 17. Bio-geographical regions 18. Habitats and biotopes 19. Species distribution 20. Energy resources 21. Mineral resources

36

Fig 3.10 INSPIRE Network Services - Service types

Fig 3.11 INSPIRE technical architecture overview

Relation to other standards INSPIRE is based on and/or reuses concepts from in first hand ISO 19100 series of standards but also other theme specific standards/regulations/concepts.

37

Figure 3-12 OGC standards positioned in the framework

One of the supporting technologies that is used by INSPIRE is GDF, the Geospatial Data File format. This format is also used by CityGML, see 3.5.

3.7 LandXML.org (Source: RWS’s appendix G) LandXML is an open standard that appears to overlap considerably with CityGML with respect to GIS geometry and more semantic objects. However, LandXML seems to be much less in the spotlight than CityGML and is especially pushed/controlled by Autodesk. The most recent update was in July 2008 (version 1.2). The most recent news messages also date from that period, which suggests that it is not a very dynamic standard. One strong point in favour of it is the support by Autodesk Civil 3D 2011 (import/export). Detailed road designs can be saved/exchanged/shared neutrally in LandXML (including the road axes or ‘alignments’).

XSDXML

GML/CityGML and ADEs, IMgeowfs

XSD

EU:Inspire NL:Geonovum

BGT

“In principle:

any business scope dealing with global info”

38

Due to lack of interest and funding, LandXML.org ceased operations in November 31, 2012 (http://www.landxml.org/). But it is tried to rescue by IFCforInfra.

Figure 3-13 LandXML positioned in the framework

3.8 Standards in the Netherlands

3.8.1 COINS (Source: http://www.coinsweb.nl/wiki/index.php/Hoofdpagina) COINS is a Dutch system/open standard for applying BIM in infrastructure. It is complementary to standards issued by buildingSMART such as IFC, IFD Library and IDM. The system is used by partners in construction projects for the purpose of exchanging building information and managing building project data. The system comprises:

Agreements for setting up a BIM: COINS BIM (CBIM) The COINS Container data exchange format

XSDXML

LandXML

Civil Infrastructures

39

A set of basic information management principles Specifications for a Building Information System.

CBIM comprises two main components: 1) a compact generic model for the instantiation of project information (functions with requirements and construction units/rooms with performances) and 2) a meta model for defining limited object libraries, referred to here as ‘catalogue parts’. The catalogue parts can be consulted by

the bodies in the project model (RWS, Appendix G). COINS currently have several issues that need further attention such as incomplete reuse of open standard modelling constructs for specialization, instantiation and the missing functionalities at class level. In spite of these issues, COINS CBIM presents a good first step to the projects in which BIM will be experienced. COINS requirements always depend on features, whereas the performance always depends on function fulfillers [functievervullers] (spaces or physical objects). In the general interpretation of a function as ‘the effect of something’, this allocation is not immediately evident. It must be tested whether this COINS interpretation gives restrictions in the modelling of BIM information structures.

3.8.2 NEN (Source: http://nl.wikipedia.org/wiki/NEN) NEN is an abbreviation for ‘Dutch

Standard’ (NEderlandse Norm) and since May 8, 2000 it is the name of the close collaboration of the Dutch Standardisation Institute and the Foundation NEC (specialized in the standardization of electrical engineering and ICT). Both organizations work closely together. NEN accompanies and encourages the development of standards. As a neutral party, NEN made an inventory about which standards are needed and brought the organizational stakeholders together in order to finance and develop these standards. What NEN does is at national, European and global levels. There are over 1500 specific Dutch standards and there are many more valid in the Netherlands, for example because they come from Europe (EN) or globally valid (ISO). Among all the standards, NEN-2767-4 is for a methodology to assess the condition of infrastructure in an objective and unambiguous determination. The standard covers the following sectors:

Civil engineering works, both “dry” (road and rail infrastructure) and “wet”

(waterways) Hydraulic engineering Road construction Electrical and mechanical engineering Landscaping

The standard consists of two parts, 1) the methodology for measuring the conditioning of infrastructure, and 2) defect list for conditioning of infrastructure. (Source: http://www.nen2767-4.nl/pagina/methodiek.html)

40

NEN also hosts working groups and expert networks that do not directly develop standards. One such expert network that is relevant for V-Con is the NC 381184 “Automation Systems and Integration” Expert Network. This network has been

working on (among other things) a collection of modeling agreements for object libraries.

3.8.3 VISI (Source: http://www.bakkerspees.com/visi/brochure) VISI is the Dutch acronym for ‘Terms & Conditions for the Implementation of Standardization in ICT in Civil Engineering’. The VISI standard is based on the DEMO theory/method of Prof. Dietz (Delft University of Technology) in combination with a technically complex multi-layered structure in XML/XSD, such as that which can currently be found in the Semantic Web (RWS, Appendix G). The underlying idea is the standardization of communication between persons. The way in which people are able to communicate on subjects is recorded, with the people involved always viewed as working from specific roles. The full communication on a subject is referred to as a transaction, and the collection of agreements (i.e. transactions, roles, etc.) is recorded in a framework. VISI-compatible software is able to read in a framework and then permit communication according to the agreements in the framework. The principle is based on the allocation of roles and a collection of messages that may be sent in transactions between two roles. Each person, playing a specific predefined role, can participate in a project. It is also certainly conceivable that one person has multiple roles or, conversely, that a specific role is shared by multiple persons. In a role, it is possible to communicate about a certain subject with another role. What may be communicated about a subject and the messages that may be exchanged about the subject are defined and registered in a VISI framework. A subject is thus recorded in a transaction (probably better described as a ‘workflow’) which registers the communication options for this subject between two roles. The messages in a transaction can best be compared with an e-mail with pre-entered content; however, while free text fields may be present, the computer is much more able to understand the meaning of the text fields than would be the case in a regular e-mail. The architecture of VISI has a technically complex multi-layered structure in XML/XSD. This structure makes it possible that a specific framework can be developed that is not dependent on the software used. For the user, this means that agreements on communication (frameworks) can be recorded and modified per project without the need to modify VISI-compatible software so that it will support the new agreements. The layers of the VISI architecture are called VISI Systematiek and VISI Framework.

VISI Systematiek The VISI Systematiek (“VISI Methodology”) is a technical basis for VISI communication. In order to implement the system in a clear-cut way, the software vendors have to settle additional requirements and guidelines. The VISI Systematiek, requirements and guidelines are established in the VISI Guidelines. CROW manages this guideline. The VISI Technical Commission plays an important role in establishing the Guidelines. (source: http://www.crow.nl/nl/VISI/VISI-Systematiek.html)

41

The current version of the VISI System is version 1.3. The core of VISI is tested and stable. But like many other standards VISI Systematiek is never finished, its development continues. The needs of users and proposals of software vendors for the improvements form the basis for this. CROW holds at least a biannual release cycle for new versions of VISI (source: http://www.crow.nl/nl/VISI/VISI-Systematiek.html)

VISI Framework (Source: http://www.bouwinformatieraad.nl/blog.asp?c=4In 2010) CROW had established a workgroup in order to develop a concept version of a generic VISI framework of Digital Collaboration. The intended aim of CROW is a national expansion of the VISI application for the support of the collaboration of the client and the contractors with their collaboration partners. The VISI agreement for Digital Collaboration is valid as preconditions for capturing and exchanging information of the following issues:

Coordination activities Capturing errors (anomalities) and costs Changes of design and implementations Availability of data Archive development

(Document A, 2011) The VISI system is a formally established one and is available as an Express file or an XSD file. The communication agreements that VISI has developed are grouped for particular fields of application. Each group is called a VISI framework. The framework determines which roles, transactions, messages and information elements apply to the communication in a certain area of application. A VISI framework is laid down formally in an XML file and should follow the rules laid down in the system. A VISI framework is based on the VISI system, project communication is based on a VISI framework. An information system that is VISI-compatible can assist communication in accordance with the rules laid down in a VISI framework. The starting point for the generic VISI framework Digital Collaboration was the existing UAV focusing on the contract management of a UAV89 contract. The framework is prepared after a necessary inventory by a trio of parties: engineering design bureaus, construction companies (‘uitvoerend bouw bedrijven’) and building project management bureaus.

(CROW VISI Documentation 1.0, 2011) The agreements that VISI has developed are grouped for particular areas of application, with each group being known as a VISI framework. VISI frameworks are available in two areas of application. The first is the communication between employer and contractor in a UAV agreement; this framework is simply called a VISI- UAV framework. The second area of application is the communication between employer and contractor in a UAVgc agreement; this is designated as a VISI-UAVgc framework.

3.8.4 CB-NL CB-NL (De Nederlandse conceptenbibliotheek voor de gebouwde omgeving), aims to define a standardized language for solving the data exchange problem which hinders chain integration and the further implementation of BIM.

42

The CB-NL is in line with national and international standards such as IFD, IFC and COINS. For public clients, the use of this language is also possible (and required) in the enforcing of chain integration. This leverage reckons to accelerate the implementation of the CB-EN. The CB-NL is surrounded by a landscape of existing and applied knowledge libraries and standards. These knowledge libraries and standards are an important part of the total language arrangements. The CB-NL is a binding element with which all knowledge is established in a uniformed language. The CB-NL does not present a competition for the existing knowledge institutes but an essential addition. Besides, the CB-NL forms a basis for the connection to the product libraries, by which the whole chain can be connected. CB-NL includes 1) concepts, characteristics and value fields arising from legally binding standards, 2) concepts used by the industry collectively for communication, 3) defining relations, functions, activities and properties and 4) concepts and properties required to connect to standards of knowledge institutes.

3.8.5 BouwConnect (http://www.bouwconnect.nl/) BouwConnect is a database consisting of several product configurators, which act as a 'factory' of components that can be infinitely varied. This is in contrast to other libraries or databases. These have only fixed products and thus have a limited variety. By entering the desired variables (height, width, fire resistance, energy) in the Product Configurator, components can be composed, entirely tailored to the needs of the client and can be connected directly to the delivery range of the selected manufacturer. The Product Configurator generates a composite product in real-time, consisting of several components, each with their unique WUID. Of this total solution, a complete product definition with all types of information is generated. The composite product can be used in a digital drawing by different parties. In the BouwConnect library hundreds of manufacturers’ specified components can be found. These components are directly applicable in various types of software, such as AutoCAD, Revit and ASD-Arkey. Integration is also possible with a wide range of building applications for tender, calculation, calculations, testing and procurement. BouwConnect is a commercial product developed and marketed by the Dutch telecom company KPN and a software company for architects called De Twee Snoeken.

3.8.6 SfB CI/SfB Construction Industry Classification System (Construction indexing manual 1976) is the classification system most widely used by architectural specifiers. The system has been in operation for more than 30 years and is the industry standard (RIBA Books, 2008). CI/SfB is derived from Swedish SfB (Samarbetskomittén för Byggnadsfrågor), 1950, and UDC (Universal Decimal Classification). It was first implemented in UK in 1961 as SfB/UDC Building filing manual (Gelder 2012). CI/SfB contains five tables:

Table 0 Physical environments, e.g. 413 Hospitals – mental, psychiatric Table 1 Elements, e.g. (21.1) Walls, external walls – loadbearing

43

Table 2 Constructions, forms, e.g. F Brickwork, bricks Table 3 Materials, e.g. g2 Fired clay, vitrified clay, ceramics Table 4 Activities, requirements, e.g. (P3) Sound, quiet – transfer Defunct but still in use, e.g. product literature (to BS 4940-1-3:1994), NL/SfB

CI/SfB is a library system used by the building industry and is suitable for the smallest or largest office. The current CI/SfB edition was issued in 1976 and, according to RIBA Information Services, is still widely used although the scheme is long overdue for revision. Gelder (2012) stresses Uniclass replacing CI/SfB. He notes that the SfB Agency in the UK decided (sometime before 1997) that CI/SfB should be replaced by a ‘unified

classification’ (i.e. Uniclass) rather than revised. Widespread take-up of CAWS by NBS, SMM7 and NES indicated that CI/SfB

was not the preferred approach to classification of work sections in the UK. CI/SfB did not reflect changes in the industry, e.g. new building types, new

performance issues. CI/SfB notation (brackets, upper case and lower case, etc) is difficult to

understand and computerise. Limitations of SfB in terms of computerisation led several countries to

develop new approaches to classification, so SfB was no longer being used internationally. (Gelder 2012)

3.8.7 Geonovum Many countries have a local organization for co-ordination and sometimes development of GIS standards. In the Netherlands, Geonovum is such an organisation. Geonovum has developed software for GIS in the Netherlands called IMGeo. IMGeo 2.0 provides the full information model and the resulting generated IMGeo 2.0 xsd to download in order to support the implementation of BGT (Basiskaart Grootschalige Topografie, the Dutch geographic basic map for large scale topography) / IMGeo by software vendors. The information model is available for download in EAP (Enterprise Architect) format and XML 2.1 format. The IMGeo 2.0 XSD is a GML Application Schema and CityGML Application Domain Extension (ADE). Software developers can IMGeo 2.0 XSD as the basis for the implementation of (storage) IMGeo in their products. Also the IMGeo 2.0 XSD is relevant for those who want to work with 3D IMGeo. Please note that this is NOT the message XSD standard for exchanging data IMGeo and is NOT intended for data exchange.

3.9 Standards in Sweden Not included but it should be noted that there also is an increasing need for standardization of interchange with manufacturers as they are more and more involved in the early phases.

44

3.9.1 AB

AB - General requirements for building, construction and installation contracts. ABT - General requirements for turnkey projects for building, construction and

installation. ABK - General requirements for consulting assignments. ABS - General requirements for single-family contracts, where the individual

consumer is the client. AB-U - General Conditions of subcontracts in the performance contracts. ABT-U - General provisions on subcontracting for turnkey contracts. ABM - General requirements for purchase of goods for commercial construction

3.9.2 Bygghandlingar 90 (Construction Documents 90) The purpose of the Construction Documents 90 (Bygghandlingar 90, BH 90) "Part 8 Digital supplies for construction and management" is to supplement part 1-7 90 with recommendations for the exchange of information in all stages of the construction process, from planning to management. The target group of the recommendations is actors who act as producers and purchasers of information.6 This is one of many steps in the adaptation of the industry against the introduction of BIM. Bygghandlingar 90 is the building sector’s recommendations for an integrated and efficient presentation of construction projects. Bygghandlingar 90 is divided into eight sections:

Section 1 – Forms of presentation Section 2 – Presentation techniques Section 3 – Presentation of dimensions and measurements Section 4 – Presentation of house construction Section 5 – Presentation of installation work Section 6 – Presentation of reconstructions Section 7 – Presentation of Civil Engineering Works

This section deals with digital building modeling, coding of objects, symbols and presentation of the construction information for the building, including the information that form the basis for the design. Bygghandlingar 90 describes how AMA and SB11 can be used in a building information model. Section 8, Digital deliveries for construction and asset management (Digitala leveranser för bygg och förvaltning). Section 8 supplements the description of the presentation forms as discussed in section 1-7. It describes the data management needed to facilitate a continuous information flow between phases and between different actors, from designer to end user. This section can be used for information exchange across all stages of the process. Bygghandlingar 90, section 8, can be used as a reference document in the same way as AMA. The content is not described in the same structured way as AMA, but the instruction texts provide guidance. In the example below, AMA and SB 11 codes are used together with other structured information as described in Bygghandlingar 90. 6 (Löwnertz, 2008)

45

Practical Example of BIM oriented CAD design Project specific attributes

Figure 3.14 Object attributes in a CAD/BIM system, specified according to Bygghandlingar 90.

For the classification of landscape information, ie, existing conditions, the SRA Code list (Vägverkets kodlista) was previously used, published in Drawing manual measuring and mapping (Rithandbok mät och kartering) (publ 2000:5 B). In conjunction with the 2nd edition of the Construction Documents 90 Part 7 (Bygghandlingar 90 del 7) SIS took over responsibility for the list under the name Code list BH90 for Geographic Information (Kodlista BH90 för landskapsinformation). The list includes both built and natural given object. It is based on codes with six positions, of which the first three are a group designation. Example: ADM (Administration), BYG (Buildings)[byggnader], ANL (Facilities) [anläggningar]. For each code there is also a "field code" that can be used for measuring. Examples of codes: ANLASF “Line at the asphalt edge” [ Linje vid asfaltkant]; VEGLTA “Hardwood” [Lövträd]. Updated versions of the list are published here.7

3.9.3 BSAB 96 BSAB is a construction classification system, whose structure is founded on the ISO 12006. The tables in BSAB are for instance used in the AMA, which is a series of

7 www.bygghandlingar90.se

46

handbooks for establishing the technical descriptions. Different systems related to technical descriptions also use BSAB. The system is owned and managed by Swedish Building Centre. BSAB consists of a number classification tables, more or less filled with contents. The tables describe the built world in a number of "views", such as construction works (byggnadsverk), spaces (utrymmen), building elements (byggdelar, “functional

parts”) and production results (produktionsresultat, “production parts”). The purpose of the Swedish classification system BSAB is to divide and organize information within the sector in a logical way, regardless of where the data is located or who is responsible for it. The classification system can be used throughout the life cycle by all parties in the construction and asset management process and in all types of systems that manage information about the structure.

Figure 3-15 BSAB views on building objects (Resources tables are not in BSAB)

BSAB 96 consists of a set of interacting tables. These tables are based on different views on building and construction objects that are distinguished in the BSAB approach. The tables are used to organize technical and economic information in documents and databases. The classification system consists of tables for:

Line of business (VE verksamhet), from SCB (Statistics Sweden) Infrastructural units (IE infrastrukturella enheter) Building entities (BV byggnadsverk), preliminary table Spaces (UT utrymmen), preliminary table Building Elements (BD byggdelar) and building Designed Elements for

building systems and installation systems (BDT byggdelstyper och installationssystem)

47

Production Result (PR produktionsresultat), type of the ISO 12006-2 concept Work Result

No tables have been set up for resources and asset management results etc. Some resource tables are published from other parties. Examples of buildings are roads, bridges and houses. Building parts are defined as a part of the building that fulfills one of the main functions. For example column frames or ground pipes. Building parts are systematically divided into building part types. A building part type is a technical solution to a building part, for example a column frame made from in-situ cast concrete. Example of a general class is F BRICKWORK which e.g. includes the more specific class FC BRICKWORK OF BRICK IN BUILDING, which in turn is subdivided into e.g. FCD BRICKWORK OF CONCRETE STONE, CONCRETE BLOCK OR SUCH IN SYSTEM. The codes for building parts are built up by two numbers followed by a point and then letters. Codes for building part types are separated from the building part code with a slash (/). For example: 31 Superstructures 31.B Superstructures for roads and planes Example of code for building part type: 31.B/1 Superstructure of gravel bitumen Production result is the result of an activity at the construction site.

Building entities (BV byggnadsverk) The construction works are classified according to the activity they serve: their purpose. Example:

Example:

D = Roads and Plans

DC = Roads on ground

DCB = Roads for road traffic

DCB/B = Roads for car traffic

Figure 3.16: Construction works.

Spaces (UT utrymmen) Spaces are also classified by type of activity they serve. Example:

48

Figure 1.17: Spaces.

Example:

1 = Spaces for outdoor activities

11 = Spaces for traffic

111 = Spaces for road traffic

111.D = Roadways (undetermined)

111.DB = Lane (undetermined)

Building Element (BD byggdelar) Building Elements (functional parts) describes the main features in the construction works, without regard to technical solutions, material content or production. Example:

Figure 3.18: Building Parts.

Example:

3 = Superstructures and facility additions

31. = Superstructures

31.B = Superstructures for Roads and Plans

31.BB = Mid Road Shoulders

Production Results (PR produktionsresultat) Production results are the result of an activity on the construction site for the production of part or whole construction works. A production results, is decided with the regard to materials and construction method, but not regarding function. Example:

49

Figure 3.19: Production Results.

Example:

D = Land Superstructures and facility additions etc. DC = Land Superstructures etc. DCC = Bitumen-bound superstructure layers for roads, surfaces etc. DCC1 = Bitumen-bound superstructure layers category A, for roads, surfaces etc. DCC14 = Bitumen-bound wearing course category A DCC141 = wearing course category A of asphalt mass DCC1412 = wearing course category A rich in stone bituminous concrete (ABS) DCC14122 = wearing course category A rich in stone bituminous concrete for maintenance

Designed Elements and Recipes A Designed Element (building-part-type of) is a building Element (functional part) whose technical solution has been decided, that is, a detailed production results has been stated. Building part types is thus a kind of hybrid, a building part that "knows" both its function and its structure. Example: pillar framework of situ concrete, the inner wall of discs on a stud framework. Tables are available for houses. Building part types are used for coding objects in Stockholm Bypass (Förbifart Stockholm). As defined types are not available for facility use, preliminary codes, which are developed in collaboration with the Swedish Building Centre (Svensk Byggtjänst) are used. Example: 31B-01, Superstructure for roads and surfaces, type E20 light rock bank. Building part types can be used as a "recipe" that contains all the resources needed to construct the building part - both goods and works. The recipes can then be linked to rates and thus provide the basis for cost estimates. Swedish Building Centre (Svensk Byggtjänst) is currently running a development project called FokusI, using building part types precisely in this way. The construction elements are also linked to functional and aesthetic requirements, which can be set at different levels of detail: for the building part and its detailed production results.

3.9.4 AMA AMA stands for Allmän material- och arbetsbeskrivning (General materials and job description) and is a reference work for the production of administrative requirements and technical specifications for construction, infrastructure and installation projects. AMA texts need to be invoked in administrative regulations or technical descriptions to become valid. This is done by adding a statement that AMA is used in the document. The texts are invoked by a code with an associated header. When a code is invoked all the underlying codes are invoked, as well as overlying codes according to a pyramid rule. Draft description texts can be downloaded from the AMA description tool, a paid service with the AB Svensk Byggtjänst (Swedish Building Centre). AMA texts are

50

only to be referred to; texts should never be copied into the technical descriptions or administrative regulations. The only description texts to be printed are additions to, or changes to, AMA texts. In AMA there are thousands of descriptions of proven technical solutions for various constructions. The descriptions are used for documentation and communication throughout the entire construction process, from tender documents to complete construction documents. Since the description along with the AMA texts becomes contract documents after the procurement, the invoked AMA texts are legally binding.

AMA Structure AMA and RA (Recommendations and directions) include over 15,000 codes and headers with associated regulations and recommendations. In addition, all changes are documented in AMA News, which comes out twice a year. In RA there are comments to texts in AMA and information on how the description should be designed to become sufficiently complete and calculable. AMA is divided into a number of different sections or disciplines: Administrative Regulations, Infrastructure, House, Plumbing, Electrical Installations and Refrigeration. The administrative regulations cover all disciplines and are based on the Swedish Allmänna bestämmelser (standard agreements within the sector). The encoded headers in AMA are taken from the BSAB system. In other words, AMA applies the BSAB system. Only the BSAB tables for buildings, building parts, building part types and production results are used in AMA and technical descriptions. The current version is BSAB 96 and it is in accordance with ISO 12006-2.

3.9.5 Reference systematics in Trafikverket Reference systematics is used by the Transport Administration for data coordination of road facilities. The usage is described in the documents 2003:54 Principles of digital information (Principer för digital informationshantering, Vägverket 2005) and 2007:54 of system code and component designations (Principer för digital informationshantering, Vägverket 2009). The aim of 2007:54 is stated to be "to meet the primary operational and maintenance needs." 2003:54 covers requirements for data coordination in processes from early design to management, but excluding management processes. The publication is the requirement document in which both general and stage-specific guidelines describe how digital information is to be reported to Trafikverket during the project. An important part of 2003:54 is the IT tutorial, where the conditions for the project is described (geographic divisions, naming, metadata, CAD methodology, component handling, etc.). 2003:54 is extensive and provides operational rules for data representation, metadata, supplies and more. It is basically complete and also includes tables of classified objects. Examples of tables, are facility parts (eg: roads, ramps, bridges, water and sewer systems); Technology areas (example: architecture, rock art); Technical systems (see System 2007:54).

51

In 2003:54 there is an example that follows ISO / IEC 81346. 8 For a detailed description of the system numbers and component designations refers to the publication 2000:5 A, which was replaced by 2007:54. It is not explicitly stated in 2007:54 that it follows the ISO / IEC 81346, but it is clear from the content. Hereby it is possible to argue that Trafikverket in the form of 2003:54 and 2007:54 follows ISO / IEC 81346.

3.9.6 The reference systematics of Trafikverket and BSAB A closer analysis of 2007:54 shows the following. The code structure follows the principle + AABCC = DDDEEFFF-HHH III: XXX.

+ AABCC denotes the geographical location, called Facility-part [Anläggningsdel]. AA = Facility [Anläggning], B =Subarea [Delområde] and CC = Facility-part within the subarea [Anläggningsdel inom delområde].

DDD designates System (example: land, facility building parts, house building elements , road systems, and piping and ventilation systems, Electrical systems) [Mark, Anläggningsbyggdelar, Husbyggdelar, Väganordningar, Rör- och ventilationssystem, Elsystem]. The systems can in turn be subdivided (for example, house building elements [Husbyggdelar] is subdivided into 320 House Substructure [Husunderbyggnad], 330 House Frame [Husstomme], 340 Roof [Yttertak], 350 Outer walls [Ytterväggar] and so on).

EE denotes Component. Examples for System 320-399 house building elements: 3xx FG Window. 360 LD Cylinder locks. 390 LB Building. Examples of using the coding: 470RV001 means "470RV001" refers to road-railing and the code is interpreted as: System 470 "OTHER TRAFFIC DEVICES AND ROAD EQUIPMENT". Component 470 RV "road railing". Sequential number 001.

FFF means sequential number. HHH means subassemblies. III also means subassemblies. XXX means withdrawal (terminals)

When comparing the structures of concepts and classes in BSAB 96 it is possible to find both similarities and differences. In much the structures are used in the corresponding areas in Trafikverket concepts in the same way as BSAB 96, but with a different structure and changing groupings and denominations. That for example, "390 LB Building" [390 LB Byggnad] belongs to the system "House Building Elements" [Husbyggdelar] is inversely to the system of BSAB 96, where "House" is classified as a type of "Construction Works" [Byggnadsverk (BV)]. The Construction Works "House" in BSAB in turn consists of "House Building Elements" [Husbyggdelar].

8 The example is the designation 26201 # H03, where 26201 is the identity of a facility part and the H03 is the identity of a further sub-division which is called the main part. An example of a main part is the stretch of road where a road goes from the road in the tunnel to the road in the open. In ISO / IEC 81346 represents the aspect location with "+", function with "=", the product with (-) and other aspects with "#". In 2003:54 and 2007:54 facility parts is used as mode sometimes without designation and sometimes with the "+", system + component is used as a function and is denoted by "=", and the dimension or material and more are used as a product and is denoted by "-". There are also a number of other aspects that are designated by "#".

52

3.9.7 SB 11 CAD layers SB 11 has recommendations for the use of ISO 13567 combined with BSAB 96 and the code list of landscape information from Bygghandlingar 90. ISO 13567 provides a framework in the form of principles and naming for structured layer division. SB 11 contains tables with layer names and descriptions, as well as detailed instructions for use. BSAB 96 is used for classification, which provides consistency with other construction documentation. The naming of CAD layers are based on three mandatory fields. These fields are called responsible party, elements and presentation. In addition to the mandatory fields there are voluntary fields. Each field represents different and distinct concepts. Each field consists of a predetermined number of characters that contains codes for classification. For short codes, the unused positions are marked with a hyphen (-). When CAD graphics represents a building part it can be classified using BSAB tables. Layer division according to BSAB's production results table can be used, but the main principle in SB 11 is to use BSAB's building part tables.

3.9.8 TEiP TEiP is a combined classification and specification system for turnkey projects that are developed and maintained by Trafikverket. It consists of a single table, and reads as follows:

operations traffic (such as road or rail traffic) existing land, environment and constructions and temporary facilities (such as

existing road construction) road facility (see example below) train facility

As for facilities, TEiP sees these as entities (eg road facility) with elements (eg road construction in road facility). TEiP breaks down the superior parts into smaller parts to the desired level, such as road-body and subgrade, superstructure, wearing course, bonded wearing course.

Figure 3.20: TEiP.

Example:

D = Road facility (the whole figure)

DB = Road construction (part 1 in the figure)

DB1 = Road body and subgrade (part 1.1 in the

figure)

DB11 = Superstructure (part of 1.1 in the figure

(not shown))

DB11b = Wearing course (not shown)

DB11bb = Bonded wearing course (not shown)

53

Besides wholes and parts TEiP also handles types and locations for each part. Examples of the types are DF2 Handrail /Bridge railing and thus DF22 Central barrier / railing and so on. TEiP has a handling of objects and their properties that may affect the ongoing revision of ISO 12006-2. Additionally TEiP handles properties according ABT 06. TEiP thus has a structure that can be used directly in BIM for all kinds of information about facility objects. The structure of the road facility systems are well proven in many turnkey projects and are now also developed for railway facilities and more. The structure of TEiP permits the specifying requirements in OTB (Object Specific Specification) can be made as per ABT per property of the object with all the properties and objects identified and is thus suited for the application of BIM. TEiP is thus based on a systematic approach that differs from the more established BSAB system, although the names (codes) have similar looks. Even BSAB can be used to describe characteristics and also for making requirements definition. A strong performance in this area can be expected, at least in terms of BIM for houses. Parallel experiments need to be done also for facilities.

3.9.9 fi2XML The Association fi2 "Society for Information Management" (Föreningen för Förvaltningsinformation) has developed the format fi2, which is supposed to be used for information transfer from production to management stage. The format specifies what information should be available for a given application. Format of data models - such as the IFC and fi2 - must be compatible with each other so that information is not distorted between different processes in the transmission. fi2 is continuously developed for the management of houses, but not for the facility industry. fi2XML is a data format in XML for management related (house) information. The format is one of several from the Association fi2. These are not compatible with IFC. They use classification systems in commercial processes (UNSPSC).

3.9.10 sbXML sbXML (Swedish Construction Industry XML) [Svenska Byggbranschens XML] is a Swedish data format for information on quantities (amount lists) and spreadsheet data (priced quantities). The format also has the capacity to transmit any type of information, such as technical descriptions. It is not published on the Web. According to an IVL report9 it is used by Swedish programs.

3.10 Standards in Germany

3.10.1 OKSTRA OKSTRA (Objektkatalog für das Strassen- und Verkehrswesen) is a feature catalogue and application schema for road and traffic related data covering the whole life-cycle of a road and with the goal of a lossless exchange of road-related data. Many software vendors have integrated OKSTRA interfaces into their software products (Inspire 2012).

9 Shared data communication format for lifecycle information (December 2011).

54

The structure and content of the catalogue is defined in NIAM, EXPRESS and XSD (visualized in HTML using a EXPRESS to HTML mapping). OKSTRA is a German development, completely described and modeled in the German language.

3.11 Standards in Norway

3.11.1 SN/TS 3489:2010 Implementation of support for IFD Library in an IFC model

Standards Norge (Standards Norway) has released a technical specification on the implementation of support for IFD library in an IFC model. This specification provides guidelines on how to apply IFD concepts when an object library is developed for use in conjunction with an IFC model. In particular, it standardizes the way IFC references shall be tagged in IFC 2x3 and 2x4, including concepts and examples for both classification and properties (Source: Standards Norge 2010).

3.11.2 SN/TS 3489 Technical specification SN/TS 3489 Implementation of support for IFD Library in an IFC model. This is a Norwegian standard that is intended to be an ISO standard. IFC 2x3 and 2x4 are designed for the standard to be applied directly. The standard specifies how the terms in the IFD database must be specified in the IFC. It shall be made for objects by either connecting (tag) the IFD term to IfcRoot-entity directly or via the type reference-entity. It should be done for attributes (properties) by either connecting (tag) the IFD term to IfcProperty-entity by name or type or by name or type and value.

3.12 Other Standards

3.12.1 Information exchange standards Information exchange standards define vendor-neutral, open-standards for the exchange of some specific type of project information. These exchanges are started and driven by subject matter experts like you who form project teams to solve specific information exchange problems. The critical task facing a team is to define clearly the information needed, at specific points in the project, for the team's problem to be solved. These standards can be characterized as pragmatic, practical, user driven standards. They are focused on divers aspects of the building process and products. Officially these standards are coordinated by the BuildingSMART Alliance USA (bSa), which is a part of the US National Institute for Building Sciences (NIBS), but in practice several organizations lead individual projects. For example Stattsbyg, BuildingSmart Norway, US army corps of engineers, TNO, NASA, RICS and may companies from the AEC industry are involved. All the information exchange standards end with ‘ie’ in the name. The current list (March 2013) of ie-standards is:

BIM Server information exchange (BIMSie) Building Automation Modeling information exchange (BAMie) Building Programming information exchange (BPie) Construction Operations Building Information Exchange (COBIE) Electrical System information exchange (Sparkie)

55

Equipment Layout information exchange (ELie) HVAC information exchange (HVACie) Life Cycle information exchange (LCie) Quantity Takeoff information exchange (QTie) Specifiers' Properties Information Exchange (SPIE) Wall information exchange (WALLie) Water System information exchange (WSie)

3.21 Information exchange standards positioned in the V-Con framework. The picture does not represent the full scale of the information exchange-standards.

3.12.2 COBie COBie stands for “Construction Operations Building Information Exchange”. It is

developed by the US Army Corps of Engineers (USACE). It is a data format for the publication of a subset of building model information focused on delivering building information for maintenance and facility management. COBie does not hold

56

geometric information. It is the official BuildingSMART Model View Definition (MVD) of IFC for Facility Management. There are several open tools that can generate a COBie model from an IFC model. In December 2011, COBie was approved by the US-based National Institute of Building Sciences as part of its National Building Information Model (NBIMS-US) standard. The NBIMS-US standard focuses on the improvement of how information is captured during design and construction phase, and then provided for operations, maintenance, and facility/asset management purposes. COBie is mandatory for specific projects in the USA and in the UK. COBie helps capture and record important project data at the point of origin, including equipment lists, product data sheets, warranties, spare parts lists, and preventive maintenance schedules. This information is essential to support operations, maintenance and asset management once the built asset is in service. COBie has been incorporated into software for planning, design, construction, commissioning, operations, maintenance, and asset management. COBie may take several approved formats include (COBie) spreadsheets, and IFC files in both SPFF and XML format. COBie then specifies on agreements among stakeholder representatives to define what exact information is to be provided by whom, to whom, and when. COBie is usually stored as a (spreadsheet)XML file. A lightweight XML format for COBie, COBieLite, was demonstrated in January 2013. For that goal COBie describes in a sense how IFC should be used and say extended (property sets) taking manu existing, often US sources into account (OmniClass, NIBS, UFGS, MIMOSA, OMSI, DPW, USAF, NASA, and many other facility management related standards). Example worksheet:

57

The FM Handover Model View Definition (MVD) is only the second official MVD published through the buildingSMART international. COBie is now mandated for public building projects in the United Kingdom too. More information on COBie can be found in [East 2007]

Relevance for V-Con The COBie standard is very well defined and maintained and has strong link to BuildingSmart. It can be seen as a more end-user-oriented standard on how to use standards like IFC for in this case Facility Management. The use for V-Con is limited by the fact that it mainly addressed Buildings like apartments, offices and clinics, not civil infrastructures like roads and bridges.

58

4 Currently Used Configurations of Standards The standards described in Chapter 3 can all be used in projects. However, certain combinations of standards are likely to be found together. For example the standards of buildingSMART are more or less complementary and based on the same technologies. When standards are used in projects, then normally such a set of standards is chosen that fit well together. In Chapter 5 both a number of relevant standards from Chapter 3 and relevant configurations of Chapter 4 are assessed. The result is an assessment table that gives a good quick overview of the standards and configurations that are most relevant for V-Con. In this chapter some sets of standards are presented that fit well together and that are (likely to be) found in practice. We will call these sets of standards “configurations of

standards”. This chapter is structured according to the “Coverage Dimension” (see 2.2.2):

One international configuration “BuildingSmart” is presented. National configurations are presented for the Netherlands, Sweden and

France. Company-specific configurations are presented for Rijkswaterstaat and

Trafikverket. Project-specific configurations are presented for the Dutch project SAA and

the Swedish project Stockholm By-Pass.

4.1 International Configurations

4.1.1 BuildingSMART (Wikipedia 2012a) BuildingSMART, formerly the International Alliance for Interoperability (IAI), is an international organization which aims to improve the exchange of information between software applications used in the construction industry. It has developed Industry Foundation Classes (IFCs) as a neutral and open specification for Building Information Models (BIM). BuildingSMART says it develops and maintains international standards for openBIM, combining:

buildingSMART Processes - Information Delivery Manuals (IDM) buildingSMART Data Dictionary - it maintains the International Framework

for Dictionaries (IFD) Library buildingSMART Data model - the organization manages the software-neutral

Industry Foundation Classes (IFC) data model

Fig 4.1 shows the standards that constitute the buildingSMART configuration. As Figure 4.1 shows, buildingSMART uses ISO STEP technologies such as EXPRESS, SPFF and SDAI as base technologies, but also XML and XSD. IFC can be found on the semantic level; IFD on the meta-semantic level (providing rules for object definitions). IDM and MVD provide supporting methods for IFC.

59

Figure 4-1BuildingSmart in V-Con Framework

Figure 4.2 zooms in on the relationships between languages and semantics. SPFF is a language for “flat” information to be exchanged. EXPRESS can be used for the

definition of the object semantics, or meta-semantics.

60

Figure 4-2 BuildingSmart in V-Con Framework (straight line means: language for, dotted line means: instance of)

4.2 National Configurations

4.2.1 The Netherlands For BIM standardisation in the Netherlands the BIR (Bouw Informatie Raad), the Dutch acronym for Building Information Council plays an important co-ordinating role. The BIR is committed to building a successful transition to BIM. The members are employed by large construction companies and clients. They sit in a personal capacity in this council. The members themselves are not IT people. The program office of the BIR consists of people who have an IT background. They focus on determining the general arrangements for the open systems standards to achieve required for BIM. The BIR has a coordinating role in a number of Dutch standardization developments, such as COINS, VISI and CB-NL. Figure 4.3 shows a “Dutch” configuration of with

different parts of the aforementioned standards.

EXPRESSSPFF

IFC / IfcForInfra and bSDD Library

IFD

EXPRESS

61

Figure 4-3 Configuration NL in V-Con Framework

Standards that can be recognized in the configuration are: COINS-elements, such as the CBIS server and CBIM Part 1 and 2, VISI-elements (maybe out of scope for V-Con) CB-NL International basic standards and languages from ISO STEP and W3C.

4.2.2 Sweden A relevant Swedish standard for geographic information is the “SS 63 70 06:2006”

Approved 2006-03-08 (Edition 1): Geographic information – Generic representation of geographic phenomena. It is not clear how this standard relates to CityGML. Another relevant standard in Sweden is ISO Methodology for feature cataloguing.

62

Figure 4-4 Configuration Sweden positioned in framework

4.2.3 France In France, co-operation on standards takes place both in the public sector and in the private sector. Especially in the private area initiatives can be observed that make use of the buildingSMART/IFC approach. CSTB is usually actively involved in such initiatives and also in further development of buildingSMART-standards. For example, CSTB is one of the leaders of the IFC-Bridge development (see Section 3.1.5)

4.3 Company-specific Configurations

4.3.1 Rijkswaterstaat While RWS uses many elements of the “Dutch” configuration for current projects such as SAA, they are also have their own specific strategy on information standards. The most important RWS-specific development at the moment is the Object Type Library (OTL). See Fig 4.4.

63

Figure 4-5 RWS Configuration

In the future, additions are expected that should provide better support for Systems Engineering and better integration with the (next generation of) Beheer & Management Systemen (Control and Management Systems, BMS). See Fig 4.5

4.3.2 Trafikverket The standards that are relevant for Trafikverket are already mentioned in 4.2.2. In addition to that two currently running projects at Trafikverket are worth mentioning. The first one is the BIM-implementation project by Trafikverket. In this project an extensive analysis of open BIM standards is carried out (Malmkvist et al 2013). The second project is the Information Model Transport Network project (Trafikverket 2013). In this project an information model is defined for transport networks. In this

DTDXML

Civil Infra

OTL-DTD

OTL

RWS SAA

64

model, transport networks are used as a reference system for properties (e.g. geometry), states, events, etc. With events all the information is meant that can be tied to the reference network. The requirements of this information model for data that is tied to the reference network is expressed specifically that the model for this should be "generic so you can easily add, delete, change the types of events without any system development" and that "the model should be able to handle objects, events and divisions/attributes in the same way." In a type independent event model, events of a specific type are not explicitly modeled; instead the same model is used regardless of what kind of event is concerned. Structurally, it is, according to this model, no difference between a "speed limit" and a "railroad switch". The advantage of this is that no systems or databases, that implements the generic event model, needs refinement when new types of events are being added. The type independent model in itself is not sufficient to be able to interpret the data. For the interpretation of the data it requires a data catalog that describes the various types of events that exist and what is distinctive and descriptive for each event type.

Fig 4.6 Trafikverket configuration

65

4.4 Project-specific Configurations

4.4.1 SAA In the Dutch RWS SAA-project (phase 1) that is currently running, a subset of the standards of the “Dutch” configuration (see 4.2.1) is applied, consisting mainly of COINS-elements. CB-NL is not yet used because it is still under development. Instead, the SAA-project has developed their own object type library (OTL). Also the Systems Engineering part of COINS is not yet fully used in SAA. The SAA project initially focuses on the “solutions” and “forgets about requirements”.

4.4.2 Stockholm By-Pass

Fig 4.7 Stockholm By-Pass configuration The project-specific configuration for Stockholm By-pass is at present not fully investigated. The figures above will be completed by TRV later on.

Usage of BSAB BSAB is used in modified or expanded form in different systems, sometimes with elements of the older version BSAB 83. Examples are in the CAD layer in the Construction Documents 90 (Bygghandlingar 90) and the Trafikverket's project Stockholm Bypass (Förbifart Stockholm).

66

Figure 4. 8: Example on structure for Stockholm Bypass (Förbifart Stockholm)

67

5 Assessment of Standards and Configurations In this chapter a table is presented in which a number of standards and configurations that are relevant for V-Con are assessed. The standards and configurations all have been described in Chapter 3 and Chapter 4. Of course the table can be extended in a later stage, for example with national standards. The assessment is done using three general selection criteria that have been identified in V-Con Deliverable D32:

Product quality Process quality Quality in practice

For explanation of these criteria, please refer to V-Con Deliverable D3.2.

5.1 Assessment Table Standard Product Quality Process Quality Quality in Practice ISO STEP + well defined

+ well documented - not web-based - low-level API - no AP for roads

+ ISO SC4: well organized, good procedures

+ good support from software vendors - not compliant with modern web-based interfaces - not much used in construction (only combined with IFC)

IFC + well defined + well documented - no support for roads (only buildings) - “old” STEP technology - limited static semantics

+ buildingSmart, well organized - small group of developers

+ lot of commitment from practice + good support from software vendors - problems with compliancy and validation

ISO 12006/ bsDD

- poorly defined and documented

- within buildingSmart organization, not very active

- hardly used

W3C + well defined + sound foundation + enables pure semantic modeling - more technology than models, limited scope + generic

+ well organized: clear, transparent, professional, open

+ common web technologies widely used (XML etc, “the

internet”) - semantic web technologies not much used yet

OGC + well defined, + scope: GIS + modern XML technology

- limited number of active persons/ organizations

- limited tool support (depends on “layer”:

probably GML more than CityGML)

68

Standard Product Quality Process Quality Quality in Practice OMG + well defined and

documented + UML widely used for graphic models + sysML probably relevant for Systems engineering + strong in transformations

+ well organized: clear, transparent, professional, open

+ UML widely used - Use of other methods limited to software develop-ment (e.g. XMI)

LandXML + scope: infra (between BIM and GIS) - semantically weak (use of layers)

- formally dismantled + tried to rescue by IFCforInfra

- only supported in some Autodesk products such as Civil3D

COINS + well defined (some parts in Dutch?) + support for roads incl systems engineering - issues related to modeling approach

+ well organized - not fully open (membership fees)

- only known and used in NL

5.2 Conclusion From the table above, with the quick assessment of the configurations relevant for V-Con, we can conclude that there are many initiatives standardizing (parts of) the information structures needed for communication with road information models (RIM) in the civil infrastructural sector. These initiatives have their strengths and weaknesses in terms of acceptance in the market, quality of the process and organization behind it, and quality of the standards itself. These initiatives each have their right of existence. They will evolve, each with their own dynamics in the sector. For V-Con, the challenge is not to replace these existing initiatives with a new super-standard (also called “the-mother-of-all-standards”), but to make use of the strengths of the

individual initiatives and to make links between them. Another observation is the growing perceived need for a distributed modeling (as opposed to a centrally orchestrated) approach. The traditional approach towards information standardization is to develop one central, static information model everybody can agree upon, preferably with international coverage and supported by standardization bodies, such as ISO. Countries, organizations or even projects feel the need to model information structures with a more specific, often limited coverage. For example, to support the information needs based on national regulations, on a typical common way of practice of group of companies, or on an end-user application used by the national road authorities. Typically, the 5 levels of the Coverage dimension of the ICT framework—International, European, National, Company, Project—should be supported: it should be possible to develop information structures on each of the layers by the proper organizations. The structures on the more specific levels could build upon the more generic levels. The other way round, more specific structures could get promoted to a broader coverage where useful.

69

This way the one and only, top down static structure could be replaced by a cloud of flexible structures with multiple authorities behind them that are reused, interrelated, mapped or aligned to each other etc. This situation could be tagged as more ‘dynamic’

because the participating structures could typically change more quickly in time too.

70

6 Follow-up In this Deliverable D3.1, an overview of information standards relevant for road infrastructure is given. First, a list of standards is presented. Next, a selection of so-called configurations of standards is described: sets of standards that fit well together and that can be found in projects. The next step for V-Con is to prepare for a “scenario”: an attractive configuration of standards (both existing standards and standards to be developed), plus a strategy on how to achieve this. This next step of the V-Con project will be carried out in Task 3.2, and will be reported in Deliverable 3.2.

71

References BuildingSmart 2012, http://buildingsmart.com/standards/mvd, accessed November

2012. CROW VISI Documentation, Versie 1.0, 31 May 2011

(http://www.crow.nl/nl/VISI/VISI-Systematiek.html) Document A: The relationship between VISI, COINS and IDM East, E. William, “Construction Operations Building Information Exchange (COBIE),

Requirements Definition and Pilot Implementation Standard”, June 2007. http://buildingsmartalliance.org/index.php/projects/commonbimfiles/

Eastman. C.M.; Y.-S. Jeong; R. Sacks; and I. Kaner, Exchange Model and Exchange Object Concepts for Implementation of National BIM Standards, Journal of Computing in Civil Engineering, Vol. 24, No. 1, January 1, 2010.

Encyclopedia, http://www.encyclopedia.com/doc/1O11-dynamicdatastructure.html Fiatech. “An introduction to ISO 15926”, November 2011. Hjelseth E, Nick Nisbet, 2010, OVERVIEW OF CONCEPTS FOR MODEL

CHECKING, Proceedings of the CIB W78 2010: 27th International Conference –Cairo, Egypt, 16-18 November, Norwegian University of Life Sciences (UMB), Dept. of Mathematical Sciences and Technology, Norway

Håvard Bell & Lars Bjørkhaug, A buildingSMART ontology, SINTEF Building & Infrastructure, Oslo, Norway, accessed 31st January 2013

Hjelseth E., 2009, Foundation for development of computable rules, Norwegian University of Life Sciences (UMB), Dept. of Mathematical Sciences and Technology, Norway

http://www.geonovum.nl/dossiers/inspire Inspire 2012, http://inspire.jrc.ec.europa.eu/index.cfm/pageid/42/list/7/id/12421,

accessed November 2012. Joerg LEUKEL, Volker SCHMITZ and Martin HEPP, 2006, A Critical Assessment of

ISO 13584 Adoption by B2B Data Exchange Specifications, Proceedings of the 13th ISPE International Conference on Concurrent Engineering (CE 2006), Antibes, France, September 18-22, 2006, IOS Press.

Malmkvist, M, E. Ljungwe, L. Häggström, K. Eckerberg, “Open BIM-standard – Terms, processes and data”, Trafikverket 2013.

Nawari O. Nawari, 2012, BIM Standard in the Structural Domain, JCES Volume 1, Issue 2 June 2012 PP. 42-51, School of Architecture, College of Design, Construction & Planning, University of Florida

Renssen, van, “Gellish, a generic extensible ontological language - Design and application of a universal data structure”, Delft University Press 2005, ISBN 90-407-2597-7.

RIBA Books, 2008, Architects’ Pocket Books .Sardet Standards Norge 2010, SN/TS 3489 Implementation of IFD Library Support in IFC. Trafikverket 2013, Project New Information Models (Projekt Nya informations-

modeller), “Information Model Transport Network – road and railroad”. Wikipedia 2012a, http://en.wikipedia.org/wiki/ISO_10303, accessed November 2012. Wikipedia 2012b, http://en.wikipedia.org/wiki/BuildingSMART, accessed November

2012. Wikipedia 2012c, http://en.wikipedia.org/wiki/Industry_Foundation_Classes,

accessed November 2012. Young Hyun Park, Chi Yon Cho, Ghang Lee, 2011, IDENTIFYING A SUBSET OF

BPMN FOR IDM DEVELOPMENT, Proceedings of the CIB W78-W102 2011:

72

International Conference –Sophia Antipolis, France, 26-28 October, Building Informatics Group, Department of Architectural Engineering, Yonsei University, South Korea

73

Appendix A Abbreviations The typical context of the term is annotated between [square brackets] AEC – Architecture, Engineering & Construction BIM – Building Information Model BIR – Bouw Informatie Raad (Eng.: Building Information Counsel) [NL] BSI – BuildingSmart Initiative (former IAI) CBIM – COINS BIM [COINS] CBNL – Concept Bibliotheek for NL GIS – Geographical Information System (“BIM for areas”) GUID – Globally Unique IDs IFD – International Framework for Dictionaries [BS] LC – Life-cCycle LoD – Level of Detail [GIS] LT – Long-Term MOF – Meta Object Facility [OMG] MT – Mid-Term OMG – Object Management Group OTL – Object Type Library [RWS] OWL – Web Ontology Language (on top of RDF/RDFS) [W3C] QVT – Query View and Transform facility [OMG] RDF(S) – Resource Description Framework (for Schemas) [W3C] RWS – Rijkswaterstaat [NL] SC – Supply-Chain (client <> contractor nested) SE – Systems Engineering (esp. Functional requirements) SPFF – STEP Physical File Format ST – Short-Term SW – Semantic Web technologie [W3C] SysML – Systems Modelling Language [OMG] TRV – Trafikverket UML – Unified Modelling Langauge [OMG] XML – XML Metadata Initiative [OMG]

74

Appendix B General about information To get a more complete picture of the basic theory, please see Malmkvist et al (2013). The handling of information is all about human interpretation of data. Information management in the context that is described in this report is done via computerized systems. It requires that the computer system is provided a structure so that they can manage the data properly, both in themselves and also during exchange where the risk of corruption increases. In order to accomplish this it is required a definition of:

o Comprehensible data and data models o Conclusive data transfers o Thorough basic concepts

Object Identifiable tangible or abstract entity. Any part of the perceivable or

conceivable world, a construction object is of interest in the context of a construction process

Property Demonstrable ratio of an object. Properties are characteristic of objects, such as a road surface is black.

Attribute Information of characteristics of the object. In information systems characteristics are expressed as attributes. Examples of attributes are color, building component, fire class. Attributes are primarily related to things. They may also be related to each other, for example, black may be a type of color, namely black is related to (that type of) the color.

Property Set A group of attributes which together define an object. Concept A mental image of an object or group of objects with similar characteristics.

Concepts are mental constructs (perceived notions) that can represent phenomena in reality. Concepts cannot be communicated directly. Concepts can be communicated through symbols whose significance is determined in a social context. Examples of symbols are characters, terms, and images. For the agreement on their meaning, written definitions can be needed.

Term A name for a concept in a particular area of expertise. The term is thus "the word" used for a concept.

Meaning The meaning of a term is its referent, that is, the object in question, and its context, i.e. other concepts that form a context, such as a story or a theory.

Symbol A generally accepted, or for a particular purpose acceptable representation

of information such as a story or a theory. Symbol of a language stands for and can be interpreted as a concept. Terms and speech are symbols consisting of characters (letters and numbers). Characters are stored using the coding system memory media whose smallest unit is 0 (off) or 1 (on). Examples of code systems are Unicode characters and examples for graphics are Tif, Jpeg, Gif and others.

Model Simplified representation of real or imaginary events. A model is an image representing the characteristics of an object. The image can be physical (and then be part of reality) or mental (perceived). The mapping can be static or dynamic, i.e. stationary or moving. A physical representation is made by a mental conception and is dependent on the medium used. Natural images usually represent characteristics of the real reality and are on a small scale or a full-scale model. Physical representations may include folded paper, drawings

75

on paper, wood, foam, or be digital. Digital images are stored on media which can be interpreted by computers or the like. The images are usually in several scales and can be represented differently in different scales.

Information The meaning of data. During communication, data is transmitted in the form of symbols that must be interpreted by the receiver in an agreed manner to be understood. The agreement may involve the interpretation to be made, for example, under the defined general language or explanatory text or under any other defined terms, such as a theory. Data may be individual, such as "The roadway has an incline of 2 per mille", or be systems of data. An example of a way to group these systems of data, are with sentences, paragraphs, chapters and sections. The computerized information data are expressed on the basis of a conceptual model.

Conceptual model

A systematic description, a model of the relationships between concepts

within a field of knowledge. A conceptual model (Conceptual Schedule) consists of general classes, properties and relationships, and is used in an information system to create statements about the phenomena of interest, such as construction.

Information system

Systems that collects, processes, stores or distributes and presents

information. An information system consists of a conceptual model, an information database and an information processor with functions for incoming and outgoing data. The information database consists of data, i.e. statements about objects of interest.

Information model

A systematic description of a business concept, relationships between

concepts, as well as a specification of the descriptive information that can or

should be available. An information model, for example BIM, can be created in an information system. An information model is a representation of an imagined or actual object, such as a building. The information model is created in the information system and consists of statements about the object of interest. The term data model refers to the fact that the model consists of statements (data).

Data Representation of facts, ideas or the like in a form suitable for transmission,

interpretation, or processing by humans or by automatic means. Data in information are statements about properties of objects. The usage of the terms data and information are overlapping at times. As defined here, information is the data which is transferred during a communication and interpreted by a human.

Data format Data formats are symbols and rules for combining symbols to express the

data. Data format consists of signs, terms, and numerical numbers and the rules for how they can be combined. A data format is a formal language. Examples of data formats are datafiles and XML-files, such as the IFC part 21, ifcXML, fi2XML, sbXML, gbXML. A data format has a specific syntax, i.e. the rules for how characters are combined to be read correctly. Examples of data formats (XML) for the data "Street address is Sveavägen 1": <street address> Sveavägen 1 </ street address>. The structure with the characters <> /, "tags" [markup] and the way these combined constitute the syntax, while the semantic content consists of classes, properties and values of properties, such as "street address" and "Sveavägen 1". XML standard itself covers only the syntax although some semantic concepts are covered. Another example of the data format is the declaration forms from "Skatteverket" (the Inland Revenue) stating what should be entered where and how it should be done.

File format A specification of how data is stored in a file. File format is a data format in the form of a file (computer file). A file format has a determined syntax, i.e. rules for how characters are combined to be read correctly. The technology

76

and the standardization and the types of file formats are too complex to be described here, but it goes a long way being able to distinguish between file formats using the ending of the data file. Example: txt, xml, dxf, dwg, pdf, doc, docx.

Standard Documents that are prepared in consensus and adopted by recognized

agencies and for general and repeated use gives rules or guidelines for

activities or their results, in order to reach the widest possible consensus in a

particular context.