v-con business specification phase 1 - modelservers.org€¦ · coordinate reference system crs a...

Business Specification

Reference code 31104294

V-Con


Phase 1


1

Content

1 Introduction .............................................................................. 3

1.1 Overview of PCP documents ............................................................................................ 3 1.2 Structure of the Business Specification ............................................................................. 3

2 Terms and abbreviations ........................................................... 4

3 Business Scope .......................................................................... 7

3.1 Business objective, business process and business objects ................................................ 7 3.2 V-Con’s business challenges ............................................................................................. 9 3.3 Business risks .................................................................................................................. 9 3.4 Scope and boundaries ................................................................................................... 10

4 Vision on the V-Con Solution ................................................... 11

4.1 Vision statement ........................................................................................................... 11 4.2 Vision for the usage ....................................................................................................... 11 4.3 Major features .............................................................................................................. 11 4.4 Limitations and exclusions ............................................................................................. 12 4.5 Assumptions and dependencies ..................................................................................... 12

5 V-Con Business Model ............................................................. 13

5.1 Introduction .................................................................................................................. 13 5.2 General roles ................................................................................................................. 14 5.3 Introduction to business use cases ................................................................................. 15

Annex A: ‘System engineering’ use case........................................ 17

Introduction ........................................................................................................................... 17 General description of the use case ......................................................................................... 18 The main scenario of the use case ............................................................................................ 19

Alternative scenarios for the use case .......................................................................................... 21 Summary of transactions ........................................................................................................ 22

Annex B: ‘Repavement’ use case .................................................. 24

Introduction ........................................................................................................................... 24 The main scenario of the use case ........................................................................................... 25 Summary of transactions ........................................................................................................ 27

T2 - exchange requirement ........................................................................................................... 27 T4 - exchange requirement ........................................................................................................... 27 T5 - exchange requirement ........................................................................................................... 27 T6 - exchange requirement ........................................................................................................... 28

Annex C: ‘Alignment’ use case ...................................................... 30

Introduction ........................................................................................................................... 30 General description of the use case ......................................................................................... 31 The scenario of the use case 'alignment' .................................................................................. 32 Summary of transactions ........................................................................................................ 34


2


3

1 Introduction This document includes the business scope (Chapter 3) and a vision on the solution (Chapter 4). After that, we describe the business process and requirements for a limited number of use cases (Chapter 5 and the annexes). For the introduction and background to the V-Con PCP, please see the document Invitation to Tender, ITT. 1.1 Overview of PCP documents

The Business Specification is part of the V-Con procurement documents and adds more detail from a business perspective to the overall challenge described in the Challenge Brief. The more technical details (on IT level) are described in the Technical Specification.

V-Con procurement documents

Invitation to Tender, ITT

PCP Process

Q&A

V-Con Agreement

Challenge Brief


Technical Specification Figure 1: Document structure for the V-Con Pre-Commercial Procurement (PCP) process

1.2 Structure of the Business Specification The Business Specification is structured as follows:

Chapter Fout! Verwijzingsbron niet gevonden. introduces this document.

Chapter 3 describes the business scope of V-Con.

Chapter 4 describes the vision and major features for the V-Con Solution. Important limitations, exclusions, assumptions and dependencies for the project and the V-Con Solution is also described in this chapter.

Chapter 5 describes the generic business model, stakeholders, general roles and the structure of the business use cases.

Annex A-C describes the business use cases.


4

2 Terms and abbreviations For the purposes of this Business Specification, the following terms, abbreviations and definitions apply.

Terms Abbreviations Definitions

ANDA A development program within Trafikverket with the goal of modernizing the asset management systems.

Building Information Model Building Information Modeling

BIM A digital representation of physical and functional characteristics of a facility. A building information model is a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to demolition.

Long-Term Asset Management System

BMS LT A development program within Rijkswaterstaat with the goal of modernizing the asset management systems.

BuildingSMART A neutral, international and unique not-for-profit organisation supporting open BIM.

BuildingSMART International

bSI The same as above.

CB-NL The Nederlandse Conceptenbibliotheek (CB-NL) is a library or collection of concepts for the building knowledge domain. This library is in fact an ontology, which defines concepts and semantic relations between these concepts.

Coordinate Reference System

CRS A coordinate system that is related to the real world by a datum.

COINS An open Dutch standard for information exchange based on Systems Engineering.

Customer Requirement Specification

CRS The documented result of eliciting, consolidating, and resolving conflicts among the needs, expectations, constraints, and interfaces of the product's relevant stakeholders in a way that is acceptable to the customer.

Design and Build D&B A contract where the construction company is responsible for the design and build activities.

Design Build Finance and Maintain

DBFM A contract where the construction company is responsible for the financing of the project, the design and build activities and maintaining the project result.


5

EXPRESS A standardized language for specifying product data models. EXPRESS is formalized in the ISO Standard for the Exchange of Product model STEP.

Geographic Information GI Information concerning phenomena implicitly or explicitly associated with a location relative to the Earth.

Geographic Information System

GIS Information system dealing with information concerning phenomena associated with location relative to the Earth.

Information Delivery Specification

IDS The IDS describes requirements regarding the delivery of Asset Management information and is part of the contract between client and construction company.

Industry Foundation Classes

IFC An open standardized specification for BIM data that is exchanged and shared among software applications.

InfraGML A proposed new OGC standard that will encompass a subset of LandXML and is based on GML.

Infrastructure for Spatial Information in the European Community

INSPIRE The INSPIRE directive aims to create a European Union (EU) spatial data infrastructure. This will enable the sharing of environmental spatial information among public sector organisations and better facilitate public access to spatial information across Europe

Interface Requirements Specification

IRS Documentation that specifies requirements for interfaces between or among systems and components

LandXML A standard data format for civil engineering design, geographic information and survey measurement data.

Linked Data A W3C defined method of publishing structured data on the Web so that it can be interlinked and become more useful. It builds upon standard Web technologies such as HTTP, RDF and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers.

Linear Referencing System

LRS A method of spatial referencing, in which the locations of features are described relative a one-dimensional object in terms of measurements along (and optionally offset from) that object.

National Road Authority NRA


6

Object Type Library OTL Library of standardized object definitions, often (to be) implemented as an ontology

Open Geospatial Consortium

OGC An international industry consortium of companies, government agencies and universities participating in a consensus process to develop publicly available interface standards.

Ontology Library of standardized object definitions, often (to be) implemented as an ontology

Product Life Cycle Support

PLCS Product Life Cycle Support (PLCS) specifies an information model that defines what information can be represented and exchanged to support a product through life. The information model is specified in the ISO 10303-239 standard using the EXPRESS information modelling language.

Product Lifecycle Management

PLM An integrated, information driven approach to all aspects of a product's life from its design inception, through its manufacture, deployment and maintenance and culminating in its removal from service and final disposal.

Pre-Commercial Procurement

PCP Research and technical development phase before commercialisation.

Rijkswaterstaat RWS Dutch national road, waterways and water systems authority

System Requirements Specification

SRS A structured collection of information that embodies the requirements of the system.

System Design Description

SDD Documentation that describes design goals, trade-offs and the actual design of the system.

Systems Engineering SE An interdisciplinary approach and means to enable the realization of successful (engineered) systems.

System of Interest The system whose life cycle is under consideration.

System Specification SYS The whole set of SRSs, IRSs and SDDs.

Trafikverket TRV Swedish Transport Administration

V-Con Solution VCS A solution that supports information management in a realization or maintenance project for an infrastructure asset at a road authority as a result of the V-Con project.


7

3 Business Scope 3.1 Business objective, business process and business objects The objectives of a National Road Authority (NRA) relate to the main road network and are summarised as:

To enable smooth, safe and sustainable traffic on roads;

To deliver reliable and useful information about the traffic and the infrastructure. To realise the usage process objectives, an NRA provides the following services (functions) to users: 1) Safe and sufficient road space; 2) Monitoring of the current state of traffic and infrastructure and execution of static and

dynamic traffic and infrastructural measures. These measures ensure that the current state of traffic and infrastructure better match the desired situation (control loop).

The aforementioned services are realised through a combination of business objects and business processes. Within the physical living environment, the following (types of) business objects are important to an NRA:

infrastructural systems:

for the movement of persons and goods

structures:

buildings (traffic control centre, service buildings)

structures other than buildings (junction structures, other engineering structures)

areas:

functional areas

administrative areas In systems engineering, an infrastructural system is a function performer, composed of three types of objects:

The user and his vehicle moves from his origin to his destination via the collection of interconnected traffic spaces. This collection is called a network. In this road network we distinguish between hubs (nodes) and connections (links). Examples are road sections, access and exit slip roads, etc.

The current state of the traffic process is observed by sensors, and the suitable traffic or infrastructural measures are imposed on the traffic process and its participants by means of actuators. The control loop is completed by a control system, which compares the observed situation with the desired situation (reference value, set point), and generates a control signal. The entire system of sensors, actuators and control systems can be controlled and monitored by means of an operating system. Sensors, actuators and control systems are logical objects, objects primarily defined by their function. Examples of sensors are cameras and detection loops. Examples of actuators are traffic signs and lights, matrix signal generators and barriers.

Nodes, links, sensors, actuators, control and operating systems are realised with physical objects or assets in the real world. This collection of physical objects is referred to as the infrastructure or the site. Examples are paving, crash barrier structures, etc. If the


8

physical state of an asset is degraded, this will ultimately lead to reduced availability or unavailability of traffic spaces.

The key business processes performed by the NRA are:

asset management

management of network usage The assets within the infrastructure are the subject of the asset management business process. This process covers the entire life cycle of the infrastructure (from concept to demolition) and consists of:

Construction (new development):

exploration

plan specification

preparation of realisation

realisation (including major variable maintenance)

demolition

Management:

inspections

programming

Maintenance:

regular maintenance

minor variable maintenance

Major variable maintenance For asset management, the NRA follows the following steps:

In the operational asset management process, the current status (condition) of the assets is systematically monitored (e.g. by performing inspections).

The current status is compared with the required status as specified in asset frameworks, standards and guidelines.

Measures are formulated based on this comparison (regular, variable or major maintenance). If the functionality of the infrastructure must be changed, it can also be decided to carry out a new development (construction).

In view of the large number of measures and the limited resources available to an NRA, prioritisation (order of importance) and programming (time schedule order) are performed.

The measures are implemented through programming in the form of projects and result in new (or renewed) assets and/or a new current status for the existing assets.

The Systems Engineering (SE) and Product Life Cycle Support (PLCS) methods are used during the entire life cycle of an asset to make a clear distinction between the required functionality of a system (functions, aspects and interfaces with their requirements and preconditions) and the solution provided. Data availability and multiple use of data are essential to support the methods employed during the entire life cycle. Managing the data becomes ever more important. The traditional method no longer fulfils

requirements. Hence the NRA’s use object-oriented data management in order to make it

possible to use data multiple times and to exchange it digitally with the use of open

standards. To exchange the data from one system to another using open standards, a V-Con

Solution is needed.


9

3.2 V-Con’s business challenges The Challenge Brief identifies the three main business challenges for the V-Con Solution:

support the project organisations (active in different phases of the life cycle depending on type of contract)

make use of open information-exchange standards

make use of Linked Data supported by Ontologies Based on these challenges and general NRA objectives as described above, the following business challenges for the V-Con solution have been identified:

Establish an arena for the use and development of cooperating open standards for BIM, GIS, SE and PLCS.

Enable the NRA’s project organisations to be interoperable with their external stakeholders (construction companies, consultants and others, all using their own software).

Enable the NRA’s project organisations to be interoperable with their internal stakeholders (the asset management organisation and, possibly, the traffic management organisation, all using their own software).

Enable the road information management to make use of ontologies which are capable of working with information through the whole life cycle.

Ensure that the use of open standards can be made a requirement in the infrastructure contracts tendered by an NRA.

Facilitate the exchange/sharing of information across several disciplines: physical assets, spatial network, functions, requirements, object types, documents, and GIS representations.

3.3 Business risks

Identified business risks of implementing the V-Con Solution in NRA are:

Low awareness and level of SE, PLCS and BIM implementation in businesses and organisations might affect the acceptance of the V-Con Solution.

No on-time availability of open standards (such as IFC alignment, IFC for roads, ontologies on organisational level, etc.).

No implementation of open standards and interfaces in software products from IT vendors.

Low market acceptance of the V-Con Solution.

No on-time availability of requirements for RWS’s and TRV’s modernised asset-management systems.

Lack of projects/activities to finalise the standards, etc. for road infrastructure after the end of the Project.

Vendor lock-in into one monolithic solution continues, instead of a solution based on multiple modules from potentially different vendors supporting open standards.


10

A Contractor must address these risks in his risk mitigation when designing and developing the V-Con Solution. 3.4 Scope and boundaries The scope of the V-Con Solution is the support of adequate information exchange/sharing, both semantically and syntactically. The information exchange/sharing is related to the components that make up the infrastructure, spread over several disciplines. It refers, for example, to physical objects, the spatial network, functions, requirements, object types, documents, GIS representations and 3D representations, including the applicable relations. The focus will be on road-related information. The V-Con Solution primarily supports the project organisation that is responsible for preparing, acquiring and executing different kinds of contracts (e.g. construction, maintenance and operations contracts, or a combination of these in a single contract). The V-Con Solution supports the ‘asset management’ organisational unit, which is responsible for the provision and management of the road infrastructure, by delivering and receiving information from the project organisation. The V-Con Solution will support information management for the road infrastructure through

the whole life cycle.


11

4 Vision on the V-Con Solution 4.1 Vision statement For a National Road Authority who procures road infrastructure design, construction, operation and/or maintenance from different construction companies, the V-Con Solution is a modularised solution that supports the Linked Data approach and open information exchange/sharing between different stakeholders using various software solutions, tools and standards during the various life-cycle stages. Unlike the solutions currently available, the V-Con Solution enables the integration of the various tools and standards that are used throughout the whole life cycle of the road infrastructure in a vendor-neutral fashion. These tools and standards must concern areas such as Building Information Modelling (BIM) data, GIS data and Systems Engineering Data. 4.2 Vision for the usage Considering the management’s objective, i.e., provision and use of reliable and useful information on the road infrastructure, the Principal has the following vision for the usage of the V-Con Solution:

Recording (collecting) site-related data once and making this data available multiple times in accordance with open standards.

Exchanging site-related data within the NRA and between the NRA and its partners in accordance with open standards.

Uniquely identifying and defining objects within the road infrastructure.

Recording information (knowledge) about different object types once and making it available multiple times. Examples are building and component specifications, design rules, laws, standards, frameworks and guidelines. This concerns information at type level.

Recording information in a specific context (e.g., as built and then mapped to common data) and other contexts (e.g., the information model for the asset management system(s)).

Exchanging an NRA’s information with European and national legacy systems. 4.3 Major features

The V-Con Solution shall address the following major features:

Integration of different tools and standards in the area of Building Information Modelling (BIM), Geographical Information Systems (GIS), Systems Engineering (SE) and Product Life-Cycle Support (PLCS).

Support for open standard-based information management and data exchange for different types of infrastructure projects during the entire life cycle for road infrastructure.

Support for open standard-based data exchange with external stakeholders, such as construction companies, and internal stakeholders, such as the asset management department.

o Use exchange standards wherever possible. o The standards to be used are defined by V-Con.

Flexibility with regards to future development of NRA asset management system and relevant open standards for data exchange within this business area.


12

o As these asset management systems and open standards are under development, the V-Con Solution should be flexible with regards to future developments.

Support for integrating and mapping between standards and semantics defined on an international, country, company or project level.

Support for the linked-data approach according to www.w3.org, http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook and V-Con Technical Specification.

Support for the generic business model described in Chapter 5.

Support for the business use cases described in the annexes. 4.4 Limitations and exclusions

The main focus and purpose of the V-Con Solution is an IT solution (component) that can constitute a part of the IT system that supports an NRA’s project organisation.

The Principal is responsible for the development and adjustments of RWS and TRV IT solutions.

The Contractors are not responsible for adjustment of existing RWS and TRV applications to the standards.

The Principal is responsible for developing semantics (Ontologies) to be used in the solution and making them available.

4.5 Assumptions and dependencies Major assumptions for the project and the V-Con Solution are:

The Contractors follow and will support the results from the ongoing efforts and activities within RWS, TRV and standardisation organisations.

The Contractors actively follow standardisation efforts within this area and provide proposals and comments when appropriate.

Major dependencies for the project and the V-Con Solution are:

The ongoing efforts within ISO TC211 to specify a framework of standards for semantic interoperability of Geographic Information.

The ongoing activities for international standardisation, such as IFC Alignment in bSI/OGC and IFC for Roads in bSI and InfraGML in OGC.

The ongoing activities for national standardisation such as CB-NL, COINS in Netherlands, Object Type Library (OTL) at RWS and the updated BSAB system in Sweden.

The ongoing BIM programs at RWS and TRV will in the future influence the conditions and requirements for the infrastructure projects and the Contractors.

The ongoing projects, BMS LT at RWS and ANDA at TRV, with the goal of developing a new asset management system, might in the future influence the conditions and requirements for the projects and the Contractors.

http://www.w3.org/

http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook


13

5 V-Con Business Model 5.1 Introduction The generic business model of the Project is based on and described by three business use cases and its roles are mainly performed by three stakeholders: project organisation, asset management organisation and Contractor.

Stakeholder Description

Asset management organisation

An organisation unit within a National Road Authority responsible for the management of the road infrastructure.

Project organisation An organisation unit within a National Road Authority that uses people and other resources to achieve a specific objective or other outcome. The project, which is normally divided into one or more specified work packages (or contracts), is procured and executed by different types of construction companies.

Construction company An organisation responsible for the execution of a contract. The execution normally includes performing agreed actions, self-monitoring activities and the delivery of documentation/data to the client’s project organisation according to the specifications in the contract. To avoid confusion with the more generic term “Contractor” already used in the "V-Con Framework Agreement" we use the term "Construction company" in this context to represent both construction and engineering companies.

The V-Con Solution must enable road authorities to share and exchange road information with various construction companies on an infrastructure project through the use of open standards. The V-Con Solution must also support the standards-based sharing and exchange of road information between the project organisation and asset management organisation. The three use cases cover four main types of contracts:

a) DBFM (Design Build Finance and Maintain) contracts. The builder/construction company undertakes to arrange the financing of the project, to design and build the project, and maintain the project result.

b) D&B (Design and Build) contracts. The builder/construction company undertakes to design and build the project.

c) Design contract. The designer/construction company undertakes to design the project.

d) Build contract. The builder/construction company undertakes to build the project.

The use cases described in this document are used as a starting point for the tests to be carried out in Phase 3 of the V-Con project. The final version of the test case specifications will be provided during Phase 2 of the Project (see also the PCP Process document).


14

5.2 General roles In line with the general structure of the use cases, the Principal distinguishes the following key roles. This list of key roles is divided and specialised into more specific roles in the descriptions of each specific use case provided in Annexes A to C. Role Description

Asset manager The role within the asset management organisation who maintains an up-to-date inventory of the actual road network infrastructure by using an asset management repository.

Client’s contract manager

The role within the project organisation responsible for the execution of the project with regards to cost, time and content/result. The role is responsible for partitioning the work into one or more contracts, performing the procurement, monitoring contract execution and approving the results.

Project configuration manager

The role within the project organisation responsible for maintaining the project repository containing different types of configuration items such as requirements, specifications, documentation, network information and asset information.

Technical manager The role within project organisation responsible for preparing and documenting the technical part of the contract.

Construction company’s contract manager

The role within the organisation of the Construction company that is the formal point of contact for the client’s contract manager.

Systems architect The role responsible for the overall policies and architecture rules of the road network and infrastructure, assuring that individual projects within the project organisation deliver products that are compatible and consistent with each other, and adhere to the same policies, rules and design principles.


15

5.3 Introduction to business use cases

Assetmanager

Construction company

Project organisation

Asset management organisation

T2

T4

T5

T6

Asset mgmt.repository

Projectrepository

Construction company’s

contract manager

Client’s contractmanager

Projectconfig.

manager

Technicalmanager

SystemsArchitectT8

Figure 2: General and simplified view of stakeholders, roles and the information flow The diagram above contains:

one green rectangle representing one instance of a stakeholder’s asset management organisation;

three green rectangles representing one or more instances of a stakeholder’s project organisation;

three green rectangles representing one or more instances of a stakeholder’s Construction company;

orange lines labelled Tx representing information flow;

six blue rectangles representing roles. Below is a general and simplified description of the steps and the information flow in the use cases. 1) Based on the need to maintain or change the current state of the road network the asset

manager creates a project specification (or project brief or scope) specifying project goals, requirements and constraints.

2) An extract from the asset management database that describes the current state (as-is) of the road network and its physical assets is provided to the project organisation (T2).

3) The project configuration manager creates a project repository and stores the received

information in the project repository

4) The client’s contract manager and the asset manager agree on the project specification and the Information Delivery Specification (IDS) for the transaction (T6). Examples of documentation/data requirements included in this specification are: a) upgraded current network and physical assets configuration (incl. topological data,

properties); b) maintenance information (guarantees, strategy, plan, instructions).


16

5) The technical manager prepares the technical part of the contract according to the overall

design policies and standards provided by the systems architect (T8).

6) The project organisation complements and refines the specifications for the project and groups different tasks into a suitable number of contracts.

7) The client’s contract manager performs the procurement(s) with support from public procurement experts. One step in the procurement process is to provide specifications including required state (as-required) information and current state (as-is) information for the road network to the candidates from the project repository (T4).

8) The construction company’s contract manager and the client’s contract manager agree

on the requirements for the contract(s). The contract includes specifications, required state (as-required) information, current state (as-is) information and an Information Delivery Specification (IDS) for the transaction (T5). Examples of documentation/data needs included in this specification for T5 are: a) design information (decisions, deviations from requirements, trade-offs, risk analyses,

safety analyses, etc.); b) current and future network and physical assets configuration; c) verification reports; d) maintenance information (guarantees, strategy, plan, instructions); e) traffic management measures.

9) The selected construction company(s) execute(s) the contract. This includes performing

different types of tasks, self-monitoring activities and delivering of agreed documentation/data (T5) to the project organisation according to requirements.

10) During execution of the contract, the project organisation responsibility includes performing and documenting inspections and approving or rejecting deliveries of documentation/data. The project configuration manager is responsible for updating and maintaining the project repository.

The description above is an introduction to the more specific and detailed description of the use cases provided in Annexes A to C:

Annex A: ‘System engineering’ use case

Annex B: ‘Repavement’ use case

Annex C: ‘Alignment’ use case In addition to the general roles in the use cases, specific use-case roles are also introduced. The significance and a further specification of the transaction prioritisation will be included in the Phase 2 and Phase 3 of the PCP.


17

Annex A: ‘System engineering’ use case Introduction This business use case is set in the part of an NRA organisation responsible for the provision, construction and maintenance of the road infrastructure. In the context of the Project, this use case provides a brief overview of the life-cycle process for the road network and the stakeholders involved. The use case highlights a number of common concepts for other more specialised use cases. The roles (actors) and a number of named artefacts, e.g. CRS, IRS and IDS, should be considered as abstractions that have different instantiations in different organisations. It will not be possible to test this use case on its own within the Project as that would require the entire road model (semantically and syntactically) to be in place as well as the full functional specification and implementation of the V-Con Server. The more specialised Alignment and Repavement use cases are intended to constitute a base for testing the V-Con server. However, a number of general requirements can be identified in this use case. These requirements should be considered in every transaction in the specialised use cases. In this use case description, we assume that the work will be contracted under a DBFM contract. Such a contract also includes a financial component which is not included in this use case description or in the scope for the V-Con Solution.

Use case specific roles Role Description

Asset owner The role representing the owner of the road infrastructure (the responsible minister). The political decision to construct a new road section is taken by the asset owner.

Portfolio manager The role within asset management organisation responsible for a portfolio of projects and the long-term planning, assessment and prioritisation of projects.

Stakeholder The role representing a person, group or organisation with an interest in or affected by a project.

Stakeholder manager The role within the project organisation responsible for managing the stakeholders of the project. This role inventories the stakeholder needs, and documents them in a Customer Requirement Specification (CRS).

Asset user The role representing the users of the infrastructure or the services or information related to the infrastructure and the traffic. Besides these direct users, we also include proxies for the users, e.g., service and map providers and all legal or other entities requiring information, e.g., INSPIRE.


18

General description of the use case

Construction company


Asset managementorganisation

T2

T4

T5

T6

Projectportfolio

Projectrepository

T8Clients’s contractmanager

Projectconfig.

manager

Technicalmanager

Systems architect

Stakeholder manager

StakeholderT3

Portfoliomanager

Assetmanager


Asset owner

Asset user T9

T1


contract manager

Figure 3: Overview of the roles and transactions of the ‘systems engineering’ use case

The road infrastructure consists of a large collection of components distributed across different disciplines. In this use case description, we focus in particular on the specification phase. The description covers the specification phase for the design, construction (build) and maintenance of a new road section. The road infrastructure is managed by an organisation called asset management. In this organisational unit we encounter the role of asset manager. The asset manager maintains an up-to-date inventory of the actual road infrastructure by using an asset management repository. In this repository we find information about the actual, historical and sometimes also future configuration of the traffic network and its capabilities, as well as the physical assets that make up the actual network, and their state. The role portfolio manager maintains a portfolio of projects, and assesses and prioritises the projects. This assessment is based on a large number of parameters, from political decisions through to cost-benefit analyses. The political decision to construct a new road section is taken by the asset owner, the owner of the road infrastructure (the responsible minister). The asset owner determines the scope of the work, decides on the contract model (e.g., DBFM), and makes available the financial means to execute the project. In the Netherlands and Sweden, this would imply that the concept and pre-study phases have already been executed successfully. The asset manager acts as the principal for this project on behalf of the asset owner. The contract is prepared and procured by the organisational unit project organisation, which performs this task on behalf of the asset manager. Within this organisation, the stakeholder manager is responsible for managing the stakeholders of the project. This role inventories the stakeholder needs, and documents them in a structured data set known as a Customer Requirement Specification (CRS). The stakeholder manager also resolves conflicts between conflicting and overlapping stakeholder needs, and negotiates with the stakeholders to strike a balance between needs and applicable solution limitations (technical, planning, financial, and political).


19

The technical manager is responsible for preparing the technical part of the contract. This includes a high-level system design of the new traffic network, based on systems engineering and life-cycle costing principles. The technical manager identifies the universe of discourse, the System(s) of Interest and the external actors. The stakeholder needs are transformed into a System Requirement Specification (SRS). Several Interface Requirement Specifications (IRS), describing the interfaces of the System of Interest for the external actors, are created. In the next step, a high-level system design is created. The design itself, the design decisions and trade-offs are documented in a System Design Description (SDD) as a means to determine the feasibility of the system requirements. The level of detail required in the system design is determined by a combination of specific project risks and the overall design policies and standards of the project management organisation. The system design is an iterative and incremental process. At each required level of detail, new versions of SRS and IRS are created, and the design decisions recorded in new versions of the SDD. The whole set of SRSs, IRSs and SDDs constitutes the System Specification (SYS). The client’s contract manager is responsible for partitioning the System of Interest and statement of work into one or more contracts, performing procurement, executing contracts and approving the results. The contract includes the whole set of SRSs, IRSs and SDDs pertaining to the System of Interest included in the scope of the contract. The project configuration manager is responsible for managing the configuration for the System of Interest. To this end, this role uses a project repository that contains the actual configuration of the road network and physical assets that are in the scope of the contract. This configuration consists of the actual current state, the required future state (defined by CRS, SRS, IRS and SDD) and the actual future state (including verification and validation). The actual detailed design, construction and maintenance of the contract is performed by a construction company. Within the construction company’s organisation, we encounter the role construction company’s contract manager. This is the formal point of contact for the client’s contract manager. The systems architect is responsible for the overall architecture of the road network and infrastructure, and assures that individual projects within the project organisation deliver products that are compatible and consistent with each other and adhere to the same policies, rules and design principles. The systems architect provides the technical manager with a (centrally managed) set of technical standards that contains generic requirements and design decisions for a selected set of object types. The selection of the object types is based on the frequency of occurrence in the organisation, as well as the project workload, cost and risks associated with the object type. The main scenario of the use case The main scenario of the systems engineering use case consists of the following steps: 1) Following a legal decision, the asset owner orders the asset manager to initiate a project

to construct a new road section (T1), and imposes financial and planning constraints on the project.

2) The asset manager provides (T2) the project configuration manager with the requirements for the project and the new road section (primarily based on the legal decision), and an extract from the asset management repository that describes the actual


20

(as is) configuration of the network and its physical assets. The project organisation and the asset manager also agrees on the Information Delivery Specification (IDS) for the transaction (T6).

3) Based on the top-level requirements for the new road section, the technical manager identifies the universe of discourse, the system(s) of interest and the external actors, and translates the legal requirements into a set of top-level system requirements.

4) The stakeholder manager identifies the relevant stakeholders for the System of Interest, elicits the stakeholder needs and constraints (T3), and documents them in a Customer Requirement Specification (CRS). The CRS content is stored in the project repository. The stakeholder manager resolves conflicts between conflicting and overlapping stakeholder needs.

5) The technical manager transforms the stakeholder needs into additional system

requirements, and collects them in a System Requirement Specification (SRS), as well as several Interface Requirement Specifications (IRS), describing the interfaces of the System of Interest with the external actors. The SRS and IRS are stored in the project repository.

6) In the next step, the technical manager creates a high-level system design, in which the

system is decomposed into system elements. The system decomposition, design decisions and trade-offs (based on system capabilities) are recorded in a System Design Description (SDD) as a means of determining the feasibility of the system requirements. The SDD is stored in the project repository. The system components and their associated capabilities are instantiated from the company-wide set of technical standards.

7) The systems architect makes available the set of company-wide technical standards (T8). He co-decides on any project-specific deviation from the company-wide technical standards, and incorporates the issues and recommendations into the technical standards. The technical manager is allowed to deviate from policies set by the technical standards after explicit acknowledgement by the asset manager and systems architect. The technical manager reports issues and recommendations to the systems architect for improving the quality of the set of technical standards.

8) The stakeholder manager negotiates with the stakeholders (T3) to strike a balance

between needs and applicable solution limitations arising from the system design (technical, planning, financial, and political). The resulting updates in the CRS are stored in the project repository.

9) The client’s contract manager prepares one or more contracts for the construction of the

new road section. The technical part of each contract contains the whole set of SRSs, IRSs and SDDs pertaining to the System of Interest included in the scope of the contract. He initiates a procurement process, in which the contract is provided to the candidate suppliers in the form of a dataset generated from the project repository. After completion of the procurement process, the contract is granted to a construction company.

10) The construction company executes the contract, creates a detailed system design, and

constructs the new road section. After completion of the new road section, the construction company hands over the new road section to the client.


21

11) At agreed times, the construction company provides the project organisation with an overview of the actual configuration of the current and future (including possible alternatives) networks and physical assets (T5), as well as verification and validation reports showing that he is in compliance with the requirements of the contract. These data are stored in the project repository.

12) The project configuration manager applies the agreed Information Delivery Specification

(IDS) to the project repository, generates a dataset and offers this dataset to the asset manager (T6).

13) The asset manager integrates the received datasets into the asset management

repository and informs the asset owner of the status and completion of the project.

14) The asset manager publishes the information from the updated asset management repository through the agreed channels (e.g., INSPIRE view and download services) (T9).

Alternative scenarios for the use case In principle, other kinds of contracts imply the subdivision of a DBFM contract into a number of phases, each with a separate contract. Among other things, this emphasises the ability to handle baseline aspects. The general implication for this business use case is that the transactions with phase-specific content (subset of DBFM) are rediscovered in each individual phase.


22

Summary of transactions Transaction Prio Role 1 Role 2 Content

T1 Low Asset owner Asset manager

Overall plan and planning.

T2 Medium Asset manager


Process requirements and constraints System requirements and constraints Current and global future network (incl. topological data, properties) Current environment of the network Current physical assets (incl. geographic and geometric data, properties) IDS for T6

T3 Low Stakeholder Stakeholder manager

Stakeholder needs and requirements

T4 Medium Client’s contract manager

Designer’s contract manager

Content of T2 + Elaboration of requirements (SRS, IRS and SDD) arising from stakeholder manager and technical manager IDS for T5

T5 High Designer’s contract manager


Design information (decisions, functional requirements, baseline information, deviations from requirements, trade-offs, risk analyses, safety analyses, etc.) Current and future network and physical assets configuration Verification reports Maintenance information (guarantees, strategy, plan, instructions) Traffic management measures

T9 Low Asset manager

External users Available public data

T8 Low Systems architect

Technical manager

Policies and standards

T6 Very High


Asset manager

Upgraded current network and physical assets configuration (incl. topological data, properties) Maintenance information (guarantees, strategy, plan, instructions), functional requirements, baseline information

The transactions identified in this use case will have to conform to the ISO 29481-2 Building Information Models – Information Delivery Manual – Part 2: Interaction Framework and/or PLCS (ISO 10303-239 Product Life Cycle Support) standards, as well as the other standards, formats and ontologies for roads, specified in the V-Con project. Since work typically is performed in an iterative and incremental manner, it is required that all transactions be handled according to systems engineering principles concerning version,


23

configuration, baseline, authentication and authorisation management with traceability for updates of data, metadata data and documents.


24

Annex B: ‘Repavement’ use case Introduction The business use case is set in the part of an NRA organisation that is responsible for the provision, construction and maintenance of road infrastructure. In this use case, we focus in particular on the renewal of the road pavement. In the context of the V-Con project, this use case covers the monitoring and management of the pavement condition in the road network. It also includes the planning, execution and monitoring of ‘repavement’ operations. In this use case description, we assume that the work is contracted under D&B-contract.


Pavement manager The role within the asset management organisation responsible for the overall pavement management, including analysing and planning.

Pavement monitor The role within the asset management organisation who regularly monitors and analyses the condition of the road pavement in the current road network.

Pavement inspector The role within the project organisation responsible for monitoring the construction company execution of the contract. This monitoring includes spot inspections of repavement work, self-monitoring and documentation/data deliveries.


Pavementmanager

Constructioncompany



T2

T4

T5

T6


Projectrepository

T8

Pavementmonitor


Projectconfig.

manager

Technicalmanager

Systems architect

Pavementinspector


contract manager

Figure 4: Overview of the roles and transactions in the ‘repavement’ use case


25

The road infrastructure is managed by an organisation called asset management. In this organisational unit, we encounter the role of the pavement manager who is responsible for overall pavement management, including analysing and planning. Another role is that of pavement monitor, a person who regularly monitors and analyses the condition of the road pavement in the current road network. Data about the current and historic condition of and work carried out on the road pavement is stored in the asset management repository. The output from various analysis activities is road segments of which the condition, either currently or in the near future, is or will be below the acceptable (or desired) quality level. The identified road segments are then grouped together into repavement objects (or maintenance objects). The repavement objects within a geographic area, where the pavement has to be improved, plus the current condition and the requirements, are grouped together and submitted to a project organisation. The technical manager refines the requirements and for each repavement object specifies the technical requirements for the actions to be performed. The preparation and specification is created according to the technical standards that for repavement provided by the systems architect. Another role is project configuration manager who is responsible for the management of the project repository with configuration items like the requirements, documentation/data for the repavement actions, the conditions and the monitoring. The client’s contract manager is responsible for partitioning the work into one or more contracts, performing the procurement, monitoring the contract execution, and finally approving the results. The construction company executes the contract. This includes designing and performing agreed repavement work, self-monitoring and delivering the agreed documentation/data about performed pavement work and new conditions. The execution of the contracts is monitored and approved by the project organisation. The role pavement inspector is responsible for monitoring the construction company’s execution of the assigned contract. This monitoring includes spot inspections of repavement work, self-monitoring and documentation/data deliveries. The pavement inspector advises the client’s contract manager on verification of requirements. After execution and approval, the project organisation delivers documentation/data about performed repavement work and new conditions back to the asset management organisation. The main scenario of the use case The main scenario of the repavement use case consists of the following steps: 1) The pavement monitor regularly monitors the condition of the road surface and its

pavement in the road network. The state is measured by standardised measurement procedures and characteristics like surface texture, roadway friction, noise and profile. Measured and calculated condition data is stored in the asset management repository.

2) The pavement manager combines measured and calculated condition data with road data (from the asset management repository), such as historical pavement records, traffic volumes, speed limits and road classifications. An analysis of factors such as conditions,


26

performance/quality requirements, benefits, costs and budget levels is performed. The result of this analysis is a selected set of road segments where the pavement has to be improved. For the selected road segments, the as-is and as-required conditions as well as the performance/quality level are specified.

3) The selected road segments are then grouped together into repavement objects that are

specified and planned.

4) Repavement objects within a geographic area are grouped together and assigned to a project organisation (T2).

5) The project organisation and the pavement manager agree on the requirements for the

delivery of documentation/data (T6) for new conditions and performed repavement work. 6) The project configuration manager creates a new project repository and then stores the

received project specifications in the project repository. 7) The technical manager complements and refines the technical specifications for the

repavement objects in accordance with organisation standards and project-specific performance, quality and process requirements. More detailed data about as-is conditions, plus requirements for repavement work and construction company monitoring, reporting and documentation/data delivery, (T5) is added. Updates are stored in the project repository.

8) The client’s contract manager groups the assigned repavement objects into a suitable

number of contracts. The grouping in different contracts is done based on criteria such as geography and type of work.

9) The client’s contract manager complements the technical specifications with legal

conditions and creates procurement documents with support from public procurement experts.

10) The client’s contract manager performs the procurement with support from public

procurement experts. One step in the procurement process is to provide (or make available) the technical specifications containing the as-is and as-required baselines to the participating construction companies (T4).

11) Contract is signed with the selected construction company(s). 12) The selected construction company executes the contract. This includes designing and

performing repavement actions, self-monitoring activities and delivery of as-designed and as-built documentation/data (T5) to the project organisation according to requirements.

13) During execution of the contract, we note the following responsibilities within the project

organisation with respect to the delivery of documentation/data (T5) from the construction company. a) The project configuration manager is responsible for updating the project repository

with as-designed and as-built documentation/data. b) The pavement inspector is responsible for performing and documenting inspections. c) The client’s contract manager is responsible for approving or rejecting.


27

14) The project configuration manager delivers documentation/data (T6) for new conditions and performed repavement work to the pavement manager according to the requirements agreed in step 4 above.

Summary of transactions Trans. Prio Role 1 Role 2 Content

T2 Medium Pavement manager

Project config. manager

Listed below


Construction company’s contract manager

Listed below

T5 High Construction company’s contract manager


Listed below

T6 Very High

Project config. manager

Pavement manager

Listed below

T8 Low Systems Architect

Technical Manager

Listed below

T2 - exchange requirement For the planning and execution of a repavement project, the following technical specifications are required:

Road segments grouped together into repavement objects

For each repavement object:

Road segment locations with as-is and as-required surface conditions plus road data such as historical pavement records, traffic volumes, speed limits and road classifications

Performance and quality requirements

T4 - exchange requirement For the procurement and execution of a repavement contract, the following technical specifications are required:

Road segments grouped together into repavement objects

For each repavement object:

Road segment locations with as-is and as-required surface conditions plus road data such as historical pavement records, traffic volumes, speed limits and road classifications

Bill of quantities with detailed requirements for work plus surface conditions, performance and quality

Contractual requirements for the execution such as monitoring, reporting and deliveries of data and documentation

T5 - exchange requirement For the fulfilment of a repavement contract a delivery of the following is required:


28

Statement of completed work with quantities, unit price and costs

Copy of contract, inception and construction meeting minutes

Certificates for aggregate and asphalt plus test results for ballast, binder and granules

Working recipes

For each action reported:

Sampling and drilling plan

Delivery test documentation for asphalt, both summary and individual results, including results from the b and c tests

Delivery test results for pavement, both summary and individual results, cavity percentage, water sensitivity, deformation resistance and abrasion resistance, including results from the b and c tests

Results from measurement of roughness, slope and friction

Results from measurements with infrared camera

Delivery of test documentation for unbounded layers, including support strip

Quality documents for isolations, culverts, etc.

Deviation reports

Results from measurement of clear height under bridge after repavement work During the fulfilment of the repavement contract, agreed and regular deliveries of as-designed and as-built data for work performed is required:

Work reports with general construction company and object reference data

For each layer in the report: pavement type, stone sizes, binder type and variety, ball mill value, micro-deval, additive percentage, thickness, adjustment weight, coverage, area, price, work date, managed lanes, and coordinates defining start and end of road section

T6 - exchange requirement After fulfilment and approval of the repavement contract and deliveries, the project organisation delivers:

Statement of completed work with quantities, unit price and costs

Copy of contract, start and construction meeting minutes

Certificates for aggregate and asphalt plus test results for ballast, binder and granules

Working recipes

For each action reported: - Sampling and drilling plan - Delivery test documentation for asphalt, both summary and individual results,

including results from the b and c tests. - Delivery test results for coating, both summary and individual results, cavity

percentage, water sensitivity, deformation resistance and abrasion resistance, including results from the b and c tests

- Results from measurement of roughness, slope and friction - Results from measurements with infrared camera - Delivery test documentation for unbounded layers, including support strip - Quality documents for isolations, culverts, etc. - Deviation reports - Results from measurement of clear height under bridge after repavement work

During (or after) the fulfilment of the repavement contract, the project organisation delivers the following approved as-built data for actions performed:

Action reports with general construction company and object reference data


29

For each layer in the report: pavement type, stone sizes, binder type and variety, ball mill value, micro-deval, additive percentage, thickness, adjustment weight, coverage, area, price, work date, managed lanes and coordinates defining start and end of road section


30

Annex C: ‘Alignment’ use case Introduction The business use case is set in the part of an NRA organisation that is responsible for the provision, construction and maintenance of road infrastructure. In this use case, we focus in particular on the alignment aspects of the road infrastructure and the roundtrip from decision-making regarding a new/changed part of the infrastructure to an up-to-date asset management repository. In this use case description, we assume that the work is contracted under separate contracts for the design and the build. To make things as clear as possible in this Use Case, we have divided the stakeholder construction company into two more specialised stakeholders: designer and builder. The stakeholder designer is normally a technical consultant and the stakeholder builder is normally a construction company.


Asset owner The role representing the owner of the road infrastructure (the responsible minister). The political decision to construct a new road section is taken by the asset owner.

Portfolio manager The role within asset management organisation responsible for a portfolio of projects and the long-term planning, assessment and prioritisation of projects.

Stakeholder The role representing a person, group or organisation with an interest in or affected by a project.

Stakeholder manager The role within the project organisation responsible for managing the stakeholders of the project. This role inventories the stakeholder needs, and documents them in a Customer Requirement Specification (CRS).

Asset user The role representing the users of the infrastructure or the services or information related to the infrastructure and the traffic. Besides these direct users, we also include proxies for the users, e.g. service and map providers and all legal or other entities requiring information, e.g. INSPIRE.


31


Assetmanager

Builder Project organisation


T2

T3T6

T7

T9


Projectrepository

T8

T1 Portfoliomanager

Assetowner

Builder’s contractmanager


Projectconfig.

managerStakeholder

manager

Technicalmanager

Stakeholder

Systems architect

Assetuser

T10

Projectportfolio

Designer

Designer’s contractmanager

T4

T5

T11

Figure 5: Overview of the roles and transactions of the 'alignment' use case

The road infrastructure is managed by an organisational unit called asset management. In this organisational unit, we encounter the role of asset manager. The asset manager maintains an up-to-date inventory of the actual road infrastructure by using an asset management repository. In this repository we find information about the actual and historical configuration of the road infrastructure and its capabilities and regulations, as well as the physical assets that make up the actual network, and their state. The asset management organisation keeps a project portfolio and is responsible for planning and prioritisation the projects. The portfolio manager maintains a portfolio of projects and assesses and prioritises the projects. This assessment is based on a large number of parameters, from political decisions through to cost-benefit analyses. A political decision to construct larger new road sections is taken by the asset owner, the owner of the road infrastructure (the responsible minister). The asset manager acts as the principal for the project on behalf of the asset owner. The contracts are prepared and acquired by an organisational unit project organisation which performs this task on behalf of the asset manager. Within this organisation the client’s contract manager is responsible for partitioning the work into one or more contracts, performing the procurement, monitoring contract execution, and approving the results. The technical manager is the role responsible for preparing the technical part of the contract. The core of this part of the contract consists of a high-level system design of the new road sections, based on policies and standards for road design, systems engineering and life-cycle costing principles. He identifies the pre-requisites and transforms the stakeholder needs into the necessary specifications. The system design is an iterative and recursive process. Specifications are created for each required level of detail.


32

The project configuration manager is responsible of the configuration items, e.g. the requirements, specifications, documentation/data within the project. To this end he uses a project repository that contains the actual configuration of the infrastructure and physical assets that are in the scope of the contracts. This configuration consists of the actual current state, the required future state and the actual future state (including verification and validation). The stakeholder manager is responsible for managing the stakeholders of the project. He inventories the stakeholder needs, and documents them in a structured form. He also resolves conflicts between conflicting and overlapping stakeholder needs, and negotiates with the stakeholders to strike a balance between needs and applicable solution limitations (technical, planning, financial and political).

The role responsible for management of overall policies and standards within the organisation is the systems architect. This role is responsible for the overall architecture of the road network and assures that individual projects deliver products and documentation/data that are compatible and consistent with each other, and adhere to the same principles. The systems architect provides the technical manager with a set of technical standards that contains generic requirements for the construction. The actual detailed design and construction is performed by third parties called the designer (performs design) and the builder (performs construction). Within the organisations of the builder and designer, we encounter the roles builder’s contract manager and designer’s contract manager. These are the formal points of contact for the client’s contract manager. Asset user is in this context a role representing the users of the infrastructure or the services or information related to the infrastructure and the traffic. Besides these direct users, we also include proxies for the users, e.g. service and map providers and all legal or other entities requiring information, e.g. INSPIRE. The execution of the contracts is monitored and approved by the project organisation. After execution and approval, the project organisation delivers documentation/data about performed work and new conditions back to the asset management organisation. The scenario of the use case 'alignment' The scenario of the use case consists of the following steps: 1) There is a need to change the infrastructure. The origin of that need is not further

elaborated in this use case.

2) The need is assessed by the asset management organisation which performs the necessary studies. This process within the asset management organisation is not further elaborated in this use case.

3) The asset manager provides (T2) the project configuration manager with the

requirements for the project and the new road section (primarily based on the legal decision), and an extract from the asset management repository that describes the actual (as is) configuration of the network and its physical assets. The project organisation and the asset manager also agree on the Information Delivery Specification (IDS) for the transaction (T9).


33

4) The designated project configuration manager receives the request including the

datasets containing the as-is situation. For the project he creates a project repository. The information related to the as-is situation is considered to be the as-is baseline included in the project repository.

5) The project configuration manager and the asset manager agree on the requirements for

the delivery of documentation/data (T9) for the new conditions (as-designed and as-built). 6) The systems architect makes available company-wide design and build policies and

standards. He co-decides on any project-specific deviation from the company-wide policies, and incorporates the issues and recommendations into the policies and standards (T8).

7) The stakeholder manager negotiates with the stakeholders to strike a balance between

needs and applicable solution limitations (technical, planning, financial and political) (T3). 8) Based on the formal planning process (not elaborated further in this use case) resulting in

a legally approved preliminary design (road plan), the technical manager specifies and plans the project.

9) The client’s contract manager prepares contracts for the design of the new road section. He initiates a procurement process for each contract, in which the contract is provided to the candidate suppliers. After completion of the tender process, the contract is granted to a designer (T4).

10) The designer executes the design activities. The detailed system design information is

handed over to the project organisation ‘as-designed’; the design is assessed and approved (T5).

11) The project configuration manager generates a dataset in accordance with agreements

for the as-designed baseline, and offers this to the asset manager (T9a). 12) The asset manager integrates the data into the asset management repository and

publishes the information from the updated asset management repository through the agreed channels (e.g., INSPIRE view and download services) (T10). a) Especially for this business use case, the reference network for roads is updated with

the necessary elements (topology, geometry and LRS). Also, the alignment information is stored and related to the proper elements in the network. All this is performed according to the specification of the asset management repository (manually, semi-automatic or fully automatic).

13) The client’s contract manager prepares contracts for the construction of the new road section. He initiates a procurement process for each contract, in which the contract is provided to the candidate suppliers. After completion of the tender process, the contract is granted to a builder (T6).

14) The builder constructs the new road section. After completion of the new road section, the builder hands over the new road section to the client. The detailed as-built information is handed over to the client. The new road section and its documentation is assessed and approved (T7).


34

15) The project configuration manager generates a dataset in accordance with agreements

for the as-built baseline, and offers this to the asset manager (T9b). 16) The project repository is archived. 17) The asset manager integrates the received as-built data into the asset management

repository. a) Especially for this business use case, the reference network for roads is updated with

the necessary elements (topology, geometry and LRS). Also, the alignment information is stored and related to the proper elements in the network. All this is performed according to the specification of the asset management repository (manually, semi-automatic or fully automatic).

18) The asset manager publishes the information from the updated asset management repository through the agreed channels (e.g., INSPIRE view and download services) (T10) and possibly informs the asset owner of the completion of the project (T11).

Summary of transactions

Transaction Prio Role 1 Role 2 Content

T1 Low Asset manager Portfolio manager Work selection study, selected process type

T2 Medium Asset manager Project configuration manager

Work selection study or functional study, selected process type, current situation for the infrastructure within scope of the project

T3 Low Stakeholder Stakeholder manager

Stakeholder needs and requirements


Designer’s contract manager

Legally approved preliminary design (road plan)

T5 High Designer’s contract manager


As-design documentation including environmental impacts etc.


Builder’s contract manager

As-designed documentation

T7 High Builder’s contract manager


As-designed documentation, as-built documentation

T8 Low Systems architect Technical manager Policies and standards used in T4 and T6.

T9 Very High


Asset manager Legally approved preliminary design (road plan), as-design documentation, as-built documentation

T10 Low Asset manager Asset user Infrastructure, infrastructure data

T11 Low Asset manager Asset owner Project report

T9 (a, b) – exchange requirement (Alignment): To update the asset management repository and specifically the road network information from alignment information, the following is required (valid for both as-designed and as-built):


35

A line in a 3D space representing the vehicle paths at the specified detail levels (road, carriageway, lane)

The design alignment (defining the Linear Referencing System for the ‘project’) together with a classification of the road edge defined by the alignment: – Horizontal alignment:

o The possible geometric elements are straight, circular arc, clothoid (spiral curve) or spline (continuous 2nd derivative)

– Vertical alignment: o A geometry within the ‘parameter space’ of the horizontal alignment where

‘X-coordinate’ == horizontal length and ‘Y-coordinate’ == elevation o The possible elements are straight, parabola, circular arc, …

3D representation of the above (polyline or spline)

Detail level information (road, carriageway, lane)

Baseline information (as-required, as-planned, as-built)

Identification information for the new and changed infrastructure objects (road network, road number, etc…)

Information about internal (within the project) and external connectivity (with existing infrastructure)

Coordinate Reference System (CRS) information with a well-defined transformation towards the master CRS

Planar (map) representation of the new road section including road islands, road edges, etc. together with other available GI such as ortho photos

Note. The specification for alignment exchange requirement is an ongoing project within bSI in cooperation with OGC.

v-con business specification phase 1 - modelservers.org€¦ · coordinate reference system crs a...

Documents