Modelling utilities by developing a domain ontology

(1)

PDEng – Final report

PDEng Candidate Date Version

(2)

(3)

Colophon

PDEng Candidate

Name

Email

Ir. R.B.A. (Ramon) Huurne

r.b.a.terhuurne@utwente.nl Organization Name Faculty Department Contact details University of Twente

Engineering Technology (ET)

Construction Management & Engineering

P.O. Box 217 7500 AE Enschede

Client

Name

Contact details

Campus and Facility Management University of Twente

Dienstweg 5 7522 ND Enschede

Graduation Committee

Dr. drs. J.T. (Hans) Voordijk

Prof. dr. ir. A.G. (André) Dorée

Dr. ir. L.L. (Léon) olde Scholtenhuis

Ing. R. (Ray) Klumpert

H.J.M. (André) de Brouwer Dr. C.P.L. (Carl) Schultz C. (Caroline) Groot University of Twente University of Twente University of Twente

Campus & Facility Management

Aarhus University

Kadaster

PDEng Programme Director

Thesis Supervisor Daily Supervisor Company Supervisor Company Supervisor External Examiner External Examiner

(4)

Document characteristics

Title ID Author Date Subject Publisher Type Format Language Version

PDEng – Final report

PDEng_Final_Report.pdf

Ramon ter Huurne

Date of last adjustment – 11-01-2019

University of Twente

Text

Portable Document Format (PDF)

English

2.0

Changelog

Version Date Changes made by Sections changed Change(s) made 2.0 11-01-2019 Ramon ter Huurne All Chapter 6 Chapter 7 Appendix VI

Textual changes throughout the whole report

Added section about the gradual development of the ontology

Added proof of concept

Added possible BSC / MSc research subjects 1.0 05-12-2018 Ramon ter

Huurne

All First complete version of the report

List of figures

Figure 1 – Engineering cycle by Wieringa (2014) applied to the project context and its objectives 9 Figure 2 – Stakeholder mapping following Alexander’s (2005) onion model 16 Figure 3 – Distribution of attribute types within elicited realities 19 Figure 4 – The place of a domain ontology within the industry (left as-is, right with a domain ontology included) 25 Figure 5 – UML notation (ISO 19103:2015 Geographic Information – Conceptual Schema Language) 33 Figure 6 – Example of a UML class model (from ‘Operations and Maintenance – Data specification’) 35 Figure 7 – Network components UML class model (from ‘Operations and Maintenance – Data Specification’) 38

(5)

List of tables

Table 1 – Project characteristics 1

Table 2 – Stakeholders within the project 15 Table 3 – Snap of empirical analysed utility data from the telecom domain 18 Table 4 – Snap of empirical analysed utility data from the gas domain 18 Table 5 – Comparison between and overview of utility digital modelling standards 22 Table 6 – Goals, needs and requirements following the INCOSE method 31 Table 7 – UML stereotypes applied in the domain ontology 34 Table 8 – UML values types applied in the ontology 34 Table 9 – Reporting style applied within Feature Catalogue for feature types and data types 39 Table 10 – Reporting style applied within Feature Catalogue for codelist and enumerations 39 Table 11 – Changelog of ontology development process 42

List of publications

All publications can be found in Appendix VII of this report. Publications included are the following: ter Huurne, R.B.A. (2018). Digitization for integration: fragmented realities in the utility sector. 92-100. Paper presented at ARCOM 2018, Belfast, United Kingdom.

ter Huurne, R.B.A. (2018). Introductie van een uniform objectmodel voor het beheer en onderhoud van ondergrondse infrastructuur. 1-9. Paper presented at CRWO Infradagen 2018, Arnhem, Netherlands.

(6)

Foreword and acknowledgements

In front of you lies the report of my PDEng project. A project I have been working on for the past two years. A project that gave me lots of new insights and knowledge, but also brought me new friendships and good memories. A project that not could have been accomplished without the help of many people. Therefore, I want to take the opportunity here in the report to thank all of those.

First of all, I have to thank all of my supervisors for their time, enthusiasm, and thoughtful advices and recommendations. In specific, I want to thank prof. dr. ir. André Dorée and dr. ir. Léon olde Scholtenhuis as my supervisors from the University of Twente and ing. Ray Klumpert and André de Brouwer as my supervisors from the Campus and Facility Management of the University of Twente.

Second, I want to thank the experts being part of my expert panel for their feedback and useful advice, allowing me to shape the ontology in the way it is presented in this report. In specific, I want to thank the representative(s) from CityGML UtilityNetwork ADE, Siers Infraconsultancy, Geonovum, and the Kadaster.

Third, I am very grateful to all my colleagues and friends from the department of Construction Management and Engineering I have been working with for the past two years. Even though the workload was quite high several times, it never felt as a burden for me to work, due to the amazing atmosphere at our office. Even more, I learned a lot from all of your projects and work, and I want to thank you for the support and encouragement you gave me.

Fourth, but definitely not last, I wish to extent a huge thank to my girlfriend Evelien, my family, and my friends who all supported me throughout these two years. I cannot thank you all enough for your encouragement and understanding.

(7)

Terms and definitions

[1.] Aggregation

Special form of association (3) that specifies a whole-part relationship (24) between the aggregate (whole) and a component (7) part [UML 1]

[2.] Application

Manipulation and processing of data in support of user requirements [ISO 19101-1:2014] [3.] Association

Semantic relationship (24) that can occur between classes [UML 2] [4.] Association role

Explanation of how a class participates in the association. [5.] Attribute

Feature (14) within a classifier that describes a range of values that instances of the classifier may hold [UML 1]

[6.] Class

Description of a set of objects (21) that share the same attributes (5), operations, methods, relationships (24), and semantics [UML 1]

[7.] Component

Representation of a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment [UML 2]

[8.] Composition

Aggregation (1) where the composite object (21) (whole) has responsibility for the existence and the storage of the composed objects (parts) [UML 2]

[9.] Conceptual model

Model that defines concepts of a universe of discourse [ISO 19101-1:2014] [10.] Conceptual schema

Formal description of a conceptual model [ISO 19101-1:2014] [11.] Data specification

Detailed description of a data set or data set series together with additional information that will enable it to be created, supplied to and used by another party [ISO 19131:2007]

[12.] Data type

Specification of a value domain with operations allowed on values in this domain [ISO 19103:2015] [13.] Depth

Distance of a point from a chosen reference surface measured downward along a line perpendicular to that surface [ISO 19111:2007]

(8)

[14.] Feature

Abstraction of a real world phenomenon [ISO 19101-1:2014] In UML also defined as the property of a classifier [UML 2]

[15.] Feature catalogue

Catalogue containing definitions and descriptions of the feature (14) types, feature attributes, and feature relationships occurring in one or more spatial data sets, together with any feature operations that may be applied [ISO 19101-1:2014]

[16.] Feature type

Class of features (14) having common characteristics [ISO 19156:2011] [17.] Generalization (inheritance)

Taxonomic relationship (24) between a more general element and a more specific element of the same element type [UML 2]

[18.] Infrastructure asset management

Set of activities performed and strategies implemented with the goal to preserve and extend the service life of the utilities

[19.] Interoperability

Capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units [ISO/IEC 2382:2009, 212317]

[20.] Multiplicity

Specification of the range of allowable cardinalities that a set may assume [ISO 19103:2015] [21.] Object

Entity with a well-defined boundary and identity that encapsulates state and behavior [UML 1] [22.] Ontology

Formal and explicit specifications of shared conceptualizations. In the report also defined as a digital modelling standard

[23.] Operations and maintenance

See ‘Infrastructure asset management’ (18) [24.] Relationship

Semantic connection among model elements [UML 1] [25.] Stereotype

Extension of an existing metaclass that enables the use of platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass [UML 2]

[26.] Utility infrastructure

(9)

Abbreviations

AEC

Architecture, Engineering and Construction ADE

Application Domain Extension BIM

Building Information Modeling CFM

Campus and Facility Management GIS

Geographic Information System GML

Geography Markup Language IFC

Industry Foundation Classes IMKL

Informatiemodel Kabels en Leidingen (ENG – Information model Cables and Pipes) INSPIRE

Infrastructure for Spatial Information in Europe ISO

International Organization for Standardization OGC

Open Geospatial Consortium UML

Unified Modelling Language XML

(10)

(11)

Executive summary

The utility sector is shifting more towards a life cycle oriented management approach. This means utility owners increasingly want to have a comprehensive set of digital information about their utilities. This need is also recognized at the Campus and Facility Management (CFM) of the University of Twente. The CFM – client within the PDEng project – is responsible for the installation, operations and maintenance of their utilities. Consequently, the CFM wants to be able to rely on uniform and consistent digital information about these utilities.

However, the problem, and thereby the starting point of the PDEng project, is that the utility sector currently lacks a digital modelling standard with the emphasis on lifecycle management, i.e. operations and maintenance. The lack of a standard leads to confusion and misunderstandings while exchanging data during the preparation and execution of utility works. Therefore, it is necessary to develop a sector-wide digital modelling standard that covers the main concepts and relations for utilities’ operations and maintenance. Digital modelling standards are also called ‘ontologies’ in information science. An ontology can be seen as a formal and explicit model of shared conceptualizations about reality. Once adopted and shared amongst end-users, they represent knowledge in a unified, simplified, and consistent way. If ontologies are focusing on the conceptualization of knowledge in a specific domain – such as operations and maintenance of utilities – they are called domain ontologies.

Main goal during the two-year course of the PDEng project has been the development of a domain ontology that does include those concepts and relations required within operations and maintenance related activities. The domain ontology was designed while keeping the PDEng assessment criteria in mind. These criteria elaborate on the design process (construction, realisiblity, functionality, impact and presentation) and design process (organization and planning, problem analysis and solution, communication and social skills).

To structure the ontology development process, I applied the engineering cycle of Wieringa (2014), including the following four phases: (1) problem investigation, (2) treatment design, (3) treatment validation, and (4) treatment implementation. Since ontology development is necessarily an iterative process, I used the concept of concurrent design from systems engineering. This meant treatment design and validation were iterated multiple times, sometimes even leading to a situation in which a next iteration was already started while the previous iteration one was still running. Ultimately, this iterative and concurrent fashion resulted in the creation of eight versions of the domain ontology, becoming increasingly sophisticated every iteration, up till the current version.

The problem within the PDEng project was investigated through the means of a stakeholder analysis, qualitative case study, a literature review, a document study and input of an expert panel. I found evidence that for utilities’ operations and maintenance, the main concepts and relations are not covered within a digital modelling standard. Consequently, organizations create and use their own organizational standards to model their utility information. Ultimately, this leads to the current widespread of utility modelling practices in the utility sector, and consequently, confusion and miscommunication when exchanging utility information. The problem, thereby, justifies the development of the domain ontology.

In order to design the ontology, I first established an ontology design method through an in-depth study of literature and existing ontology design methods. This method followed the steps of defining competency

(12)

questions, defining the ontology’s requirements, choosing an ontology development tool and ontology language, and building the ontology. I executed these steps within the treatment design phase of the engineering cycle. The main principle I followed during the ontology development process was active end-user engagement. End-end-users, in specific the CFM, actively participated in the development of the ontology. An overview of all meetings conducted during the two-year course of the PDEng can be found in Appendix II. Through the active involvement of end-users, it was ensured that the real information need for operations and maintenance on utilities was captured within the ontology.

To validate that the developed ontology did cover the concepts and relations of the domain of operations and maintenance, I applied four validation techniques: (1) assessment against a source of domain data, (2) check against class modelling rules, (3) assessment against expert panel input and (4) assessment against competency questions. As a result of the validation, the final version of the ontology was proven capable of delivering the utility information as required by the end-user, in specific, the CFM. In addition, validation proved the ontology to be ready for implementation in (spatial) asset management and GIS (Geographic Information System) software.

Implementation of the ontology was limited to a proof of concept. I was able to model utility data within a GIS environment following the ontology’s format. However, this proof of concept only covered a small piece of the ontology. As a consequence, the ontology has not been evaluated. Therefore, full implementation of the entire ontology in (spatial) asset management and GIS software is still required. To ease this process, a brief guideline was written on how to implement the ontology. Moreover, the ontology and all documentation and data have been made available through an online repository. Via this repository, potential users have open access to all materials required for implementation and use of the ontology.

In order to achieve full-scale implementation within the utility sector as a whole, adoption is necessary. Whereas the purpose of the ontology is to improve the system interoperability of utility data in the sector, main prerequisite is then that the ontology is also used within the sector. Whereas the PDEng project did not focus on widespread adoption of the model, is it recommended for future work to make this one of the main drivers, since once adopted, the domain ontology does provide the following potential:

 To the client – the CFM – the domain ontology provides a comprehensive structure alongside utility data can be stored. The domain ontology is a vast improvement over the existing utility modelling practice. The domain ontology provides the CFM a more detailed insight in its utilities and can support visualization, up to the creation of 3D utility models. In addition, the ontology can facilitate the uptake towards digital maintenance practices.

 To the utility sector as a whole, the ontology provides a domain concept overview that is useful to bridge the various organizational standards within the domain. This may facilitate the transfer between formats and shape standardized object descriptions improving system interoperability of utility data.

 To software developers the domain ontology provides the support of smarter reasoning within utility models. This may lead to the digital maintenance practices, and possibly even the creation of cyber-physical systems.

Altogether, the PDEng project delivers a domain ontology that can be used to model utilities in a uniform and consistent manner. To this end, the domain ontology does fulfil to the requirements of the CFM and stakeholders in general, while making the first step towards improved system interoperability utility data.

(13)

Product summary

Within the PDEng project, I developed a domain ontology, i.e. a digital modelling standard. The domain covered by the ontology is the domain of operations and maintenance of utilities. The name given to this ontology is the ‘Operations and Maintenance conceptual schema’. A conceptual schema is a formal description of a model that defines a universe of discourse.

The Operations and Maintenance conceptual schema is empirically grounded and provides an overview of those concepts and relations relevant for operations and maintenance of utilities. Use of the conceptual schema allows consistent processing and exchange of operations and maintenance related utility data, thereby improving system interoperability of utility data. The Operations and Maintenance conceptual schema is developed with support of the developers of the internationally recognized CityGML UtilityNetwork ADE (Application Domain Extension). As a result, the schema builds upon the CityGML UtilityNetwork ADE conceptual schema (CityGML, 2016) and adds those concepts and relations relevant for the domain of operations and maintenance.

The Operations and Maintenance conceptual schema is developed within the system Enterprise Architect. The schema consist of classes formatted in the Unified Modelling Language (UML). UML is an often applied language in class modelling due to its graphical notation, and moreover, also applied by the developers of CityGML UtilityNetwork ADE. In total the whole conceptual schema consist of eight UML class models. These class models describe the following domains of interest:

[1.] Core and geometry [2.] Functional characteristics [3.] Network properties [4.] Network components [5.] Component properties

[6.] Operations and maintenance properties [7.] Performance properties

[8.] Hollow space

The targeted use of the conceptual schema lies in asset management related applications, covering the domain of operations and maintenance of utilities. The Operations and Maintenance conceptual schema is applicable to the following utility disciplines: (1) electricity, (2) oil, (3) gas, (4) chemicals, (5) sewage, (6) water, (7) thermal and (8) telecommunication. The use of the schema has no geographic boundary, but is based on utility networks of developed countries.

The documentation of the Operations and Maintenance conceptual schema contains three documents: (1) a data specification, (2) a feature catalogue, and (3) an overview of the class models in UML. The data specification is the main document, which includes all eight class models together with a detailed description for each of these and the conceptual schema as a whole. The feature catalogue contains the complete vocabulary as applied within the ontology, and provides a definition and explanation for all used terms and names. The overview of UML class models contains solely the class models of the domain ontology in UML.

(14)

In summary, the documentation includes the following documents: [1.] Operations and Maintenance – Data Specification version 4.1

o OM_Data_Specification.pdf

[2.] Operations and Maintenance – Feature Catalogue 2.1 o OM_Feature_Catalogue.pdf

[3.] Operations and Maintenance – Overview of class models in UML version 4.1 o OM_UML_Overview_pdf

To implement the conceptual schema in (spatial) asset management and GIS (Geographic Information System) software, it has first been converted to an Extensive Markup Language (XML) schema file. XML is a widely adopted standard language for exchanging information. The XML schema file allows mapping of the utility data according to the Operations and Maintenance conceptual schema. However, before the XML schema can be utilized, it has to be programmed within the software FME, which still has to be done. Besides programming in FME, all preparation in order to use the domain ontology in (spatial) asset management and GIS software is finished. An online GitHub repository is created to make all the documentation and data on the Operations and Maintenance conceptual schema available:

https://github.com/RamonTerHuurne/UtilityNetwork-OperationsAndMaintenance

A list of the main features of Operations and Maintenance conceptual schema are:  Geospatial data model for operations and maintenance on utilities

 Based on the CityGML UtilityNetwork ADE conceptual schema  Representation of utilities in both 2D and 3D

 Representation of a subnetwork and superordinate network  Representation of supply areas

 Representation of detailed utility objects, including: o Spatial attributes o Material attributes o Dimensional attributes o Shape attributes o Cost attributes o Performance attributes o Impact attributes o Use attributes

o Surrounding soil attributes o Status attributes

 Integration of the utility domain with CityGML models: o Buildings (CityGML Building module)

o City furniture (CityGML CityFurniture module) o Land use (CityGML LandUse module)

o Vegetation (CityGML Vegetation module) o Water objects (CityGML WaterBody module) o Transportation (CityGML Transportation module) o Tunnels (CityGML Tunnel module)

(15)

1 Introduction

This chapter introduces the PDEng project, starting with a project description and explanation of the programme in which the project was executed. Thereafter, a list of PDEng criteria is presented, followed by an explanation about the role of this document. The chapter concludes with a reading guide for this PDEng report as a whole.

1.1 Project description

A PDEng (Professional Doctorate in Engineering) programme is a two years post-Master design programme focussing on the direct needs of the industry. Part of the PDEng programme is a tailor-made design project in close collaboration with an industry partner. The ‘industry’ partner within the project is the Campus and Facility Management (CFM) of the University of Twente. An overview of the main project characteristics are included in Table 1.

Table 1 – Project characteristics

Project title

Project type

Project client

Project period

Professional Doctorate in Engineering (PDEng)

Campus and Facility Management University of Twente

October 2016 – January 2019

The CFM has a unique role as the manager of the campus of the University of Twente. She is one of the few park and terrain managers in the Netherlands with full ownership rights over her utilities. Consequently, the CFM is responsible for the installation, operations and maintenance of – amongst others – cables and pipes. Being part of her maintenance duty, the CFM collects and registers all sorts of information about her utilities. This information covers, for example, location, material and status related properties. In addition to being an asset manager, the CFM is also client of works on the campus. During these works she wants to be able to rely on uniform and consistent information about the as-built situation of their utilities. However, how registration of the as-built information occurs often depends on personal preferences of utility owners and operators, with as a result, inconsistency in how the information is stored. In the process of modelling as-built information, construction assets are often digitized by defining their concepts and relations (El-Diraby & Osman, 2011). Digitized asset information is, consequently, stored in digital databases and information models. The use of such digital databases and information models in the Architecture, Engineering and Construction (AEC) industry to manage asset information is a much-discussed topic in literature (e.g. Bradley et al., 2016; Lu et al., 2015; Pauwels et al., 2016). For example, within the design of buildings Building Information Modeling (BIM) software in combination with digital modelling standards such as the Industry Foundation Classes (IFC) is used.

Digital modelling standards are also called an ‘ontology’ in information science. Ontologies describe the world as seen by a group of people at a certain time according to a school of thought that is based on a set

(18)

of fundamental propositions or world views (El-Diraby & Osman, 2011). An ontology can be defined as formal and explicit specifications of shared conceptualizations (Studer, Benjamins, & Fensel, 1998). Conceptualization refers to the universe of discourse (El-Diraby & Osman, 2011). Shared refers to the multiple views an ontology should be able to represent. Formal and explicit refers to the fact that the concepts within the ontology should be described in a clear computer-interpretable format (Olde Scholtenhuis & Hartmann, 2015).

Ontologies promise a shared and common understanding of a particular domain that can be communicated across people and computers. In other words, ontologies model ‘realities’. They form the knowledge base of information systems and allow sharing and reuse of knowledge. Once adopted and shared amongst end-users, they represent domain knowledge in a unified, simplified, and consistent way. An ontology offers the CFM – and utility owners, utility operators and contractors in general – a structure alongside they can store the utility asset information to utilize it for installation, operations and maintenance purposes. Moreover, in the context of asset management, an ontology can enable digital maintenance practices, and even the creation of cyber-physical systems. However, an ontology covering the domain of operations and maintenance of utilities has not yet been developed. Therefore, to support operations and maintenance of utilities, there is need for an ontology covering those operations and maintenance related concepts and relations.

1.2 ReDUCE

The PDEng project is part of the ReDUCE (Reduction of Damage to Utilities & Careful Excavation) programme. ReDUCE is a collaboration between Dutch utility operator KPN (previously Reggefiber) and the University of Twente. The aim of ReDUCE is to improve design, construction, installation, and maintenance of (buried) utilities. ReDUCE wants to promote the awareness within the excavation supply-chain regarding reduction of damages and careful excavation through the development of new methods and techniques for excavation (ZoARG, 2018).

An important step towards reduction of damages to utilities and careful excavation is to have a uniform and consistent view about the information of utilities. However, as previously explained, a standard for the classification of utilities’ concepts and relations in the domain of operations and maintenance is missing. Consequently, owners and operators of utilities classify and name similar concepts in different ways. This leads to confusion and misunderstandings at the preparation and execution of utility works. Therefore, the development of an ontology describing how concepts are classified and which data elements are used to describe them is necessary. With a good and useful ontology the installation, operations and maintenance of works in the future can be arranged more precise, making the relevance of the project to ReDUCE explicit.

1.3 PDEng criteria

The PDEng project is assessed on criteria for its design process and design product. To fulfil to these criteria, I decided to make them explicit for myself right from the start of the project. These criteria follow from the ‘Study Guide PDEng programme in Civil Engineering University of Twente’ and are presented below. I refer back to the PDEng criteria in the conclusion of this report, chapter 9, to assess how I did fulfil to these.

(19)

Design product:

 Construction – Structuring, inventivity, convincingness.  Realisability – Technical and economic realisability.  Functionality – Satisfaction, ease of use, reusability.  Impact – Societal impact, risk.

 Presentation – Completeness, correctness. Design process:

 Organization and planning – Project planning, plan realization, structure and consistency, conducting meetings.

 Problem analysis and solution – Analysis, understanding of impact, creativity, genericity.

 Communication and social skills – Reporting, knowledge management, stakeholder motivation, social skills, independency, reflection and critical attitude.

 Structure and attitude – Structure and consistency, reflection and critical attitude, independency. In addition to the design process and product, educational activities were conducted to fulfil the required ECTS within a PDEng project. An overview of the educational activities is provided in Appendix I.

1.4 Role of document

Aim of this document is to explain the complete ontology development process I conducted within the PDEng project. The rationale behind the ontology development process, as well as all the choices I made within this process are explained. This document, however, does not include the actual domain ontology itself. It was chosen to create a separate document – a data specification – in which the domain ontology itself is provided. This data specification contains a detailed description of the domain ontology, and does not elaborate on the design process. In addition to the data specification, also a feature catalogue is developed. This document contains the complete vocabulary as applied within the ontology, and provides a definition and explanation for all used terms and names. Having these separate documents for the domain ontology eases external publication of the product. The third document provides a sole overview of the ontology’s class models, for those not requiring all additional explanation and information. Besides this report, the complete documentation of my PDEng project therefore includes the following three documents:

[1.] Operations and Maintenance – Data Specification version 4.1  OM_Data_Specification.pdf

[2.] Operations and Maintenance – Feature Catalogue version 2.1  OM_Feature_Catalogue_pdf

[3.] Operations and Maintenance – Overview of class models in UML version 4.1  OM_UML_Overview_pdf

1.5 Reading guide

This document is structured in nine chapters – of which this being the first – divided over three sections. The first section involves the project initiation. This section exists of three chapters, of which this being

(20)

the project. Chapter 2 clarifies the project goal, questions, scope and objectives. The first section ends with the project methodology in chapter 3.

The second section involves the engineering cycle. The engineering cycle is a rational problem-solving process proposed by Wieringa (2014). The engineering cycle starts in chapter 4 with the problem investigation assessing which phenomenon should be improved and why. Chapter 5 includes the treatment design, describing how the product at hand – the domain ontology – is designed and thereby could treat the problem. After the design, the engineering cycle continues with the treatment validation in chapter 6. Validation assesses whether the designed ontology actually treats the problem as it should. Last part of the engineering cycle is the treatment implementation, discussed in chapter 7.

The third section involves concluding words. Chapter 8 elaborates on various points of discussion. Chapter 9 concludes the report with conclusions and recommendations.

(21)

2 Project goal, scope, questions and objectives

This chapter elaborates on the project goal, scope, questions and objectives, as is presented in the following three sections.

2.1 Project goal and scope

This section elaborates on the project goal and scope of the PDEng project. 2.1.1 Goal

Having uniform and consistent information about utilities is essential to (1) effectively utilize it for installation, operations and maintenance purposes, (2) carefully excavate, and (3) thereby reducing damages to utilities. As explained in the project description the lack of a digital modelling standard of utilities leads to confusion and misunderstandings at the preparation and execution of works. Therefore, the main goal within the PDEng project is to develop an ontology that offers a structure alongside utility information can be stored in a uniform and consistent manner. The goal is formulated as follows: Development of a domain ontology that includes the relevant concepts and relations for the operations and maintenance of utilities.

2.1.2 Scope

In the context of the PDEng project, utilities are defined as buried utility infrastructure in shallow subsurface, together with the utility infrastructure at the surface itself. With shallow, a depth of maximum two meters is meant. Goal of the project is to develop an ontology relevant for the domain of operations and maintenance. Operations and maintenance refers here to the set of activities performed and strategies implemented with the goal to preserve and extend the service life of the utilities. The meaning of operations and maintenance in the context of this report is, thereby, comparable with what is known as distinct phases in infrastructure asset management.

The utility sector is a multi-disciplinary domain in which various utility disciplines are present. To ensure proper coverage of the complete (physical) domain of utilities, the developed domain ontology includes the following utility disciplines:

[1.] Electricity [2.] Oil [3.] Gas [4.] Chemicals [5.] Sewage [6.] Water [7.] Thermal [8.] Telecommunication

The coverage of these utility disciplines is based on utility networks from developed countries, and moreover, draws upon the European INSPIRE (Infrastructure for Spatial Information in Europe) directive (European Commission, s.d.). INSPIRE aims to provide an integrated infrastructure in which interoperability and exchangeability of the spatial data of the Member States of the European Union is

(22)

every kind of utility network. Further detailing of the utility disciplines, for example towards a high-voltage electricity network, is thereby possible through the addition of attributes to each discipline.

The domain ontology is developed in close collaboration with the client, the CFM. Consequently, the domain ontology is specifically developed for a Dutch utility owner. However, the ontology was built in such a way that it allows global coverage of utility networks, as long as the utilities are within the subsurface or at the surface. The outreach of the ontology is, therefore, likely to be greater than just the Netherlands. To create support of the ontology, connection was sought with the developers of the internationally recognized CityGML UtilityNetwork ADE. CityGML UtilityNetwork ADE is an application domain extension (ADE) on the CityGML city model standard. The UtilityNetwork ADE adds heterogeneous modelling of utility networks to the 3D city models of CityGML (CityGML, 2016). Both CityGML and CityGML UtilityNetwork ADE are part of the Open Geospatial Consortium (OGC). The developed domain ontology in the PDEng report builds upon the existing conceptual schema of the UtilityNetwork ADE. The domain ontology adds the concepts and relations relevant to the domain of operations and maintenance and, therefore, is called the ‘Operations and Maintenance conceptual schema’. By building on an already known and OGC approved standard, the potential for greater support is there.

Implementation of the ontology is limited to a proof of concept. The proof of concept is performed to demonstrate how the ontology can be implemented in (spatial) asset management and GIS (Geographic Information System) software.

2.2 Project questions

In order to achieve the project goal, within the boundaries of the project scope, various questions had to be asked. In total, four questions were formulated:

[1.]What are the methodological steps required to develop a domain ontology?

A domain ontology is built on multiple principles. Key is to develop an ontology that ensures system interoperability, the linkage across domains, and logical inferences and proofs (Pauwels, Zhang, & Lee, 2017).

[2.]Which (international) digital modelling standards for utilities exist and how do these relate to the domain of operations and maintenance?

The utility sector knows digital modelling standards as the Dutch IMKL (Informatiemodel Kabels en Leidingen) and European INSPIRE. Interesting is to analyze how operations and maintenance – i.e. infrastructure asset management – is covered within these existing standards. It is analysed which concepts and relations are covered within their conceptual schemas, possibly providing leads for the development of the domain ontology.

[3.]How do end-users within the utility sector classify and register their utility data?

Classification and registration of utility data by end-users – such as utility owners, utility operators and contractors – can greatly differ comparing theory and practice. Whereas the existing digital modelling standards may not be able to suffice to the end-users’ information need, end-users use their own way of classifying their concepts and relations. This results in a widespread of utility modelling practices.

(23)

[4.]Which concepts and relations relevant to the domain of operations and maintenance must the domain ontology cover?

Coverage of the right concepts and relations by the ontology is crucial for it being widely accepted and adopted. End-users in the utility sector all have specific information uses and needs concerning the operations and management of their utilities. These uses and needs are direct input for the concepts and relations of the domain ontology. Compared to the third question, which analyzes what in practice is registered, this fourth question analyzes what the information uses and needs of the utility sector are and how these can be translated to the concepts and relations to be covered by the domain ontology.

2.3 Project objectives

To answer the project questions and progress towards the project goal within the boundary of its scope, five project objectives have been defined.

[1.]Define the methodological steps and structural requirements for the design of the domain ontology.

In order to develop a domain ontology that ensures system interoperability, linkage across domains, and logical inferences and proofs (Pauwels, Zhang, & Lee, 2017) the definition of structural requirement to be met is a necessity. Within this objective it is (1) decided which ontology design method will be used for the development of the ontology to and (2) defined what the domain ontology’s structural requirements are. The first project objective, thereby, aligns to the first project question.

[2.]Define the functional requirements for the design of the domain ontology.

Functional requirements define the required functionality by the domain ontology. Functional requirements are elicited from (1) the end-users, i.e. the end-user and (2) from existing digital modelling standards. Since current practices show confusion and misunderstandings at the preparation and execution of works in the utility sector, the ontology must be based on a shared set of conceptualizations. Engagement of the end-user is necessary to capture these conceptualizations, and therefore crucial to make the ontology functionally sound. The second project objective aligns with the second, third and fourth project questions.

[3.]Design the domain ontology.

After making the requirements for the domain ontology explicit in the first two objectives, the third objective involves the design and modelling of the domain ontology. Design of the domain ontology includes modelling following the methodological steps and structural requirements of the first objective, while ensuring the functional requirements from the second objective are covered.

[4.]Validate the domain ontology.

The fourth objective is to validate the domain ontology on its structural and functional soundness. Aim of the objective is to justify that the designed ontology does meet the requirements from the first and second objective.

[5.]Implement the domain ontology.

Implementation in the context of this PDEng project is restricted to a proof of concept. Although not directly related to the project questions nor the project goal, implementation, in a sense, acts as a final evaluation measure.

(24)

3 Project design and methodology

An ontology – i.e. digital modelling standard – related to the domain of operations and maintenance for utilities missing. The ontology to be designed should comprehend those concepts and relations relevant to the particular domain of operations and maintenance. In order to design the ontology, the engineering cycle as proposed by Wieringa (2014) was taken as a basis for the overall design process. Within product engineering - in the context of this project ontology engineering – the engineering cycle is a well-known approach to follow and was, therefore, considered as most appropriate. The engineering cycle is a rational problem-solving process consisting of five phases being (1) problem investigation, (2) treatment design, (3) treatment validation, (4) treatment implementation, and (5) implementation evaluation.

Within the scope of the project the fifth phase is not performed. The domain ontology is only partially implemented. Evaluation of the implemented domain ontology requires full implementation within multiple organizations and presumably the sector as a whole. To this end, the remaining four engineering cycle phases are coupled to the project context and its objectives, resulting in the following structure:

[1.] Problem investigation –which phenomena must be improved and why? [2.] Treatment design – design of ontology to treat the problem.

 Define the methodological steps and structural requirements for the domain ontology.  Define the functional requirements for the domain ontology.

 Design the domain ontology.

[3.] Treatment validation – assessment whether the ontology treats the problem.  Validate the domain ontology.

[4.] Treatment implementation – actual treatment of the problem with the ontology.  Implement the domain ontology.

For each of the four phases of the engineering cycle – including the project objectives – the following sections assess (1) what the goal within the phase is, (2) what methods and strategies are followed to reach that goal and (3) what the outcome of the phase is. As part of the methods and strategies, it is also explained how data was collected and analysed.

The engineering cycle does not prescribe a rigid sequence of the phases. However, ontology development is necessarily an iterative process (Noy & McGuinnes, 2001). Therefore, I made use of systems engineering and its concept of concurrent design (Blanchard & Fabrycky, 2014). Before implementation, the steps of treatment design and validation are iterated multiple times, until the project goal is fully met. This also means that a next iteration may be started when the previous iteration is still running, i.e. concurrent design of the engineering cycle. This, according to Wieringa (2014), leads to “increasingly sophisticated versions of the artefact, all aimed at treating the same complex problem”.

Figure 1 shows how the engineering cycle and the principle of concurrent design were applied to the project context and its objectives.

(25)

Design Validation Requirements engineering [2.] Treatment design [3.] Treatment validation Sufficient requirements? Implementation [1.] Problem investigation Meets requirements? Implementation? Problem statement [4.] Treatment implementation Domain ontology Perform stake-holder analysis Assess expert input

Asess against source of domain data Perform literature review Methodological steps Validation techniques Structural and functional requirements Perform document study Perform document study Perform qualitative case study Perform qualitative case study Activity Project objective Phase in engineering cycle

Outcome

Assess against competency questions

Check against class modelling rules

Assess expert input Perform document study Define competency questions Perform literature review

(26)

3.1 Problem investigation

Goal:

Identifying, describing, explaining and analysing the problem to be treated, before design of the treatment and identification of the requirements.

Methods and strategies:

In order to investigate the problem to be treated, multiple methods and strategies are applied, as is explained below:

First a stakeholder analysis was conducted, in which the stakeholders and their goals were mapped. Mapping occurs following the onion model of Alexander (2005). This model focuses on the relations of the stakeholders to the final product, rather than on power and interest. The stakeholder mapping provides immediate value in identifying and validating stakeholder roles in the requirements elicitation. Second the phenomena were investigated. Phenomena of interest are (1) existing utility modelling practices and (2) standardization efforts. It was analysed what the mechanism behind these phenomena were to occur. I conducted a qualitative case study to gain insights in existing utility modelling practices (Yin, 1989). In specific, the utility modelling practices within a Dutch utility engineering consultancy firm were studied. This company registers and processes the data of twelve major utility owners. The twelve utility owners cover the disciplines of water, gas, electricity, telecommunication and thermal. It was studied how standards and data protocols were used by these utility owners. The data collection approaches followed within the case study include observations of works practices and study of asset management guidelines. To this end, seven information managers were observed whose daily task was to model utility networks. During the observations, the information managers showed and explained how utility owners model their utility networks in digital environments. While keeping notes on this, there were dialogues in which the information managers explained their asset management work routines. Within the case study also six asset management guidelines were collected, used by utility owners as a guideline to verify the utility data modelled within the digital environments. More asset management guidelines were either not available or made accessible due to privacy reasons. The collected data were analysed in a two-staged process: (1) qualitative coding to abstract and compare the utility modelling practices, and (2) identification of similarities and differences between the practices. Within the qualitative coding (Saldaña, 2015), the typology of infrastructure objects of El-Diraby and Osman (2011) was applied. This typology distinguishes between component level, subsystem level, and system level objects and captures, for example, spatial, dimensional and material attributes. To justify the development of the domain ontology, I also identified similarities and differences between the utility modelling practices, following the typology of Gasevic et al. (2009). This typology essentially describes three elements of an ontology, being: (1) taxonomy and hierarchy, (2) vocabulary, terms and names, and (3) semantics, the linguistic meaning of the representation. The taxonomy and hierarchy refer to the hierarchical categorization of the concepts within the ontology. The vocabulary refers to the set of terms and names that are used in the subject area captured by the ontology. Semantics refers to the linguistic meaning of the applied terms and names, often prone to ambiguity and multi-interpretability.

Assessment of existing standardization efforts concerning utility modelling happened through a document study. The INSPIRE, IMKL, and CityGML UtilityNetwork ADE standard were studied in depth, whilst also other standards such as the Utility Survey Standard, PAS 128 and ASCE 38-02 were taken into account. Insights were retrieved in how existing standards are capable of modelling operations and

(27)

maintenance related utility information, providing leads for the development of the domain ontology. The infrastructure typology from El-Diraby and Osman (2011) was applied to qualitatively analyze covered infrastructure objects and attributes.

Third the phenomena were reflected upon the stakeholder goals assessing whether the phenomena do contribute or extract from the goals. This led to the problem statement.

Outcome:

Problem statement based on phenomena investigation and assessment of stakeholder goals.

3.2 Treatment design

Objective 1: Define the methodological steps and the structural requirements for design of the domain ontology

Goal:

Identifying and describing the methodological steps and structural requirements for the design of the domain ontology.

In order to elicit the methodological steps and structural requirements for the domain ontology, both a literature review and document study were conducted, as is explained below:

Through a literature review, both the methodological steps and structural requirements were identified. Various search engines were used to gain access to appropriate literature: (1) FindUT (search engine of the University of Twente, (2) Scopus, (3) Google Scholar, and (4) ScienceDirect. I searched for the following keywords, either individually or combined: ontology, domain ontology, classification, taxonomy, class-modelling, representation, methodology, requirements and criteria. To this end, I analysed the following literature on ontology design methods and principles:

 Corcho et al. (2002) – Methodologies, tools and languages for building ontologies.

 Fernández-López et al. (1999) – Building a chemical ontology using Methondology and the Ontology Design Environment.

 Gasevic et al. (2009) – Model Driven Engineering and Ontology Development.  Jakus et al. (2013) – Concepts, Ontologies, and Knowledge Representation.

 Noy and McGuinness (2001) – Ontology Development 101: A Guide to Creating Your First Ontology.

 Pinto et al. (2009) – Ontology Engineering and Evolution in a Distributed World using DILIGENT.

 Sure and Studer (2002) – On-To-Knowledge – Final Version.  Sure et al. (2009) – Ontology Engineering Methodology.

 Tempich (2006) – Ontology Engineering and Routing in Distributed Knowledge Management Applications.

Elicited methodological steps and structural requirements were assessed on the applicability within the project context. The methodological steps act as a framework for the ontology design, and are discussed in chapter 5. In addition, I documented the acquired knowledge from the literature review in a separate

(28)

report called Designing and ontology. A proposed framework. This report includes a thorough assessment on ontology design methods and can be made available on request.

The document study included analysis of existing standardization efforts, performed simultaneously with the document study of the problem investigation. Whereas in the problem investigation it was assessed how the domain of operations and maintenance is captured within the standards, within this step it was analysed how the standards were actually designed. This involves analysis of the class-modelling techniques applied within the standardization efforts. I documented the acquired knowledge from the document study in a separate report called Utility modeling. This report provides an overview of utility modelling methods and standardizations practices and can be made available on request.

The structural requirements are written down following the method proposed by INCOSE (International Council of Systems Engineering) (2015). They distinguish requirements from five different viewpoints, being: (1) enterprise, (2) business management, (3) business operations, (4) system and (5) system element. In accordance with these five viewpoints, the structural requirements of the domain ontology were established.

Outcome:

Methodological steps and list of structural requirements for the design of the domain ontology. Objective 2: Define the functional requirements for design of the domain ontology

Goal:

Identifying and describing the functional requirements to design the domain ontology. Methods and strategies:

In order to elicit the functional requirements, multiple methods and strategies were applied, as is explained below.

First, I applied the principle of end-user engagement. Crucial for the ontology to be successful is to create a shared set of conceptualizations about the domain. As such, the principle of end-user engagement was one followed throughout the whole project, but first and foremost within the functional requirements elicitation. Through active end-user engagement I was able to elicit tacit knowledge. End-user engagement was realized through (1) a qualitative case study, (2) an expert panel and (3) regular contact with the client, the CFM, being an end-user herself. The qualitative case study is the study referred to within the problem investigation, and allowed insights in the actual information need of the end-user. The expert panel is a multi-disciplinary panel consisting of the CFM, information managers, the cadastre and standardization establishments. Two plenary sessions were held with the panel, of which the first session provided most input concerning requirements engineering. In the first session, the use cases of the ontology were defined. In addition to the plenary sessions, I had up to ten sessions with experts individually. The regular talks with the CFM – ranging weekly to monthly – were held to guarantee proper coverage of the domain of operations and maintenance within the ontology. Being an end-user herself, the CFM provided lots of useful insights in the actual information need for operations and maintenance on utilities. Moreover, the regular talks kept the expectations from me as a designer and the CFM as a client aligned.

Second, the stakeholders’ goals as defined earlier on during the problem investigation were translated towards requirements. Capturing these goals through requirements within the ontology’s design, allows justification to the stakeholders’ goals.

(29)

Third, competency questions were defined. Competency questions describe questions that the domain ontology should be able to answer. Two types of competency questions can be distinguished, being (1) informal and (2) formal (Obrst, Ceusters, Mani, Ray, & Smith, 2008). To elicit the functional requirements informal competency questions are used. Informal competency questions are not yet expressed in the formal computer-interpretable ontology language. Therefore, informal questions act as a qualitative assessment of the requirements in terms of the ontology’s expressiveness (Grüninger & Fox, 1995). Formal competency questions are expressed in a computer-interpretable format, and are also referred to as queries. These only can be asked once the ontology is fully implemented. However, this is not part of the PDEng project, and therefore, not executed.

Similar to the structural requirements, the functional requirements are written down following the method proposed by INCOSE (2015).

Outcome:

List of functional requirements for the design of the domain ontology. Objective 3: Design the domain ontology

Goal:

Design of the domain ontology. Methods and strategies:

To ensure the domain ontology’s structural and functional soundness, the methodological steps and requirements as defined within the first and second objective are taken into account during the design. In addition, a mix between a bottom-up and top-down approach is applied to model the ontology’s concepts and relations. The top-down approach is an often applied approach used within ontology development, and well-known for its delivery of high-quality ontologies (Sure, Staab, & Studer, 2009). Within the top-down approach the more generic and abstract concepts are defined first and related to each other. This assures coverage of the broader context of the ontology. However, to assure that the ontology really delivers the information as required by the end-user, the bottom-up approach is applied as well. Through the involvement of end-users within the ontology development process, as explained in the previous section, is it ensured that the real information need for operations and maintenance on utilities is captured. Outcome:

Designed domain ontology. The design of the ontology has been redesigned multiple times after validation, characterizing the iterative design process followed.

3.3 Treatment validation

Objective 4: Validate the domain ontology Goal:

Justifying that the developed domain ontology does contribute to the stakeholder goals while meeting the structural and functional requirements.

In order to validate the domain ontology on its structural and functional requirements, four validation techniques were applied, as is explained below:

(30)

First, I compared the ontology against sources of domain data. The sources of domain data were retrieved during the qualitative case study as well as the document study of existing digital modelling standards. I compared the domain ontology with the elicited utility modelling practices and digital modelling standards by following the ontology typology of Gasevic et al. (2009). To this end, I could validate whether the ontology was capable of reproducing the utility concepts and relations as seen within these data sources. Second, I checked the ontology on its class modelling rules. In the project context, the domain ontology was modelled within the Unified Modelling Language (UML). By applying UML rules, I could validate the domain ontology on its structural soundness from a modelling perspective.

Third, I used input from an expert panel to validate the ontology. The expert panel sessions held for validation, both the plenary and individual ones, are the same sessions as were held to define the requirements during the design phase. This illustrates the concurrent design process followed during the project. To this end, two plenary expert panel sessions were held of which the second provided most input concerning validation. In this session, it was validated whether the information need belonging to the use cases and competency questions could actually be modelled by the domain ontology. The individual sessions with the experts were in general more in-depth, discussing, for example, the use of a single concept within the ontology.

Fourth, I assessed the ontology against the (informal) competency questions defined during the design phase. Even though the ontology was already evaluated within the second plenary expert panel session on its use cases and competency questions, not all of them were validated because of a limited amount of time. Therefore, I once more validated the ontology against the competency questions.

Outcome:

Validated domain ontology.

3.4 Treatment implementation

Objective 5: Implement the domain ontology Goal:

Partial implementation of the domain ontology in asset management related GIS software. Methods and strategies:

The designed domain ontology cannot directly be implemented in (spatial) asset management and GIS related software. UML is a graphically oriented ontology language, and consequently, not directly interpretable by (spatial) asset management and GIS software. Therefore, I converted the domain ontology in UML to an XML (Extensive Markup Language) schema file. XML is a widely adopted standard language for exchanging information. Through the XML schema file, I was able to write existing utility data towards a GML (Geography Markup Language) file, which is a format widely supported by GIS related software. To this end, the domain ontology can be applied in GIS software.

Outcome:

(31)

4 Problem investigation and analysis

This chapter elaborates on phase one of the engineering cycle, the problem investigation. To investigate the problem, first a stakeholder analysis is conducted. Second, the phenomena of interest are investigated, including an investigation of existing utility modelling practices and standardization efforts. The chapter concludes with the problem statement and opportunities.

4.1 Stakeholder analysis

This section includes the stakeholder analysis. First, the stakeholders of interest to the PDEng project are identified. Second, the identified stakeholders are mapped according to the onion model of Alexander (2005).

4.1.1 Stakeholder identification

A stakeholder is a person, group of persons or an institution affected by the to be treated problem. They are the source of goals and constraints within the project context, which in their turn are the source for the requirements (Wieringa, 2014). Therefore, identification of stakeholders is regarded highly relevant to ensure all requirements are taken into account. The stakeholders of interest to this PDEng project are described within Table 2, together with their goals and constraints.

Table 2 – Stakeholders within the project

# Stakeholder Description Goal(s) Constraint(s)

1 Designer PDEng trainee of the University of Twente, responsible for development of the domain ontology.

 Acquiring PDEng certificate.  Project duration of two years.

2 Client (CFM) Industry partner within the PDEng project. Park and terrain manager of the campus of the University of Twente with full ownership over her utilities.

 Real-time insight in the as-built information of their utilities.  Easy utilization of ontology.  Improving effectiveness and efficiency of operations and maintenance related activities.

 As-built information currently CAD based.

 Limited extensiveness of as-built information.

3 Utility owners Organizations with ownership over utilities. This includes public domain authorities as well.

 Real-time insight in the as-built information of their utilities.  Easy utilization of ontology.

 Organizational (utility modelling) routines.

 Privacy of utilities information. 4 Utility

operators

Organizations responsible for operations and maintenance related activities on utilities.

 Improving effectiveness and efficiency of operations and maintenance related activities.  Easy utilization of ontology.

 Organizational (utility modelling) routines.

 Privacy of utilities information. 5 Excavation

contractors

Organizations responsible for excavation works.

 Reducing excavation damages to utilities.

 Easy utilization of ontology.

-

6 Authorities Organizations concerned with class-modelling of utilities (such as the cadastre).

 Improving system

interoperability of utility data.

 Conformance with existing class-modelling standards.

(32)

7 Software developers

Organizations developing the (spatial) asset

management related (GIS) software.

 Development of sector-wide (spatial) asset management related (GIS) software.

 Application within existing (spatial) asset management related (GIS) software.

8 Utility users End-user of utilities.  Reliable use of the services by utilities.

-

9 Investors Organizations funding the project.

 Project accomplishment within budget.

 Project budget.

4.1.2 Stakeholder mapping

Mapping of the stakeholders follows the onion model of Alexander (2005). This model focuses on the stakeholders’ relationship to the final product rather than on the stakeholders’ power and interest. The onion model builds a stakeholder taxonomy and provides insights in the relevance of the stakeholders towards the domain ontology. Mapping of the stakeholders according to the onion model is shown in Figure 2.

Figure 2 shows the onion model including the stakeholders within the project. The inner circle comprises ‘The Product’, which is the product of design, in this project the domain ontology for utilities. The next circle, ‘The System’ circle, involves the stakeholders that do have an influence on the design of this domain ontology and / or eventually will be the end-user of the product. Following the earlier explained principle of end-user engagement, this circle includes the client, utility operators and utility owners, in addition to the designer. Creating a shared set of conceptualizations amongst these stakeholders is of great importance. The next circle, ‘The Containing System’, involves beneficiaries and

others, who are not directly involved in the design of the product. This circle includes the excavation contractors, software developers, investors and authorities. Albeit they do have an influence on the design, their influence is indirect, whilst they don’t have a direct say in the design choices to be made. In the last circle, ‘The Wider Environment’, all other stakeholders that are recognized within the project are included. This circle includes the utility user, which might benefit from less down-time of utilities, due to more effective and efficient operations and maintenance of utilities.

Modelling utilities by developing a domain ontology

PDEng – Final report

Colophon

Document characteristics

Changelog

List of figures

List of tables

List of publications

Foreword and acknowledgements

Terms and definitions

Abbreviations

Executive summary

Product summary

Table of contents

1 Introduction

1.1 Project description

1.2 ReDUCE

1.3 PDEng criteria

1.4 Role of document

1.5 Reading guide

2 Project goal, scope, questions and objectives

2.1 Project goal and scope

2.2 Project questions

2.3 Project objectives

3 Project design and methodology

3.1 Problem investigation

3.2 Treatment design

3.3 Treatment validation

3.4 Treatment implementation

4

Problem investigation and analysis

4.1 Stakeholder analysis