Publication Date: 2021-03-23

Approval Date: 2020-01-03

Posted Date: 2019-02-01

Reference number of this document: OGC 19-081

Reference URL for this document: http://www.opengis.net/doc/PER/MUDDI

Category: Public Engineering Report

Editor: Josh Lieberman

Title: MUDDI v1.1 (Model for Underground Data Definition and Integration) Engineering Report


OGC Engineering Report

COPYRIGHT

Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

1. Summary

The Underground Infrastructure Concept Development Study (UICDS) Engineering Report [1] examined the present state of underground infrastructure information (UGII), costs and benefits of that state, as well as future opportunities for an improved state. That report describes a number of candidate models for UGII and recommends a number of follow-on activities, including development of a prototype UGII integration model to support subsequent UGII integration and exchange initiatives. A follow-up workshop and model development effort resulted in another engineering report describing an initial (1.0) version of the conceptual UGII integration model MUDDI (Model for Underground Data Definition and Interchange) [2]. The present updated report describes MUDDI version 1.1. The goal of MUDDI is to serve as the basis for integration of datasets from different models, at the levels of detail required to address application use cases described in [1]. MUDDI as described here is a conceptual model which will serve as the basis for one or more conformant and interchangeable logical and physical implementations such as GML (Geographic Markup Language) or SFS (Simple Features SQL). The current version 1.1 of MUDDI has been updated and refined from the initial version 1.0, but is still intended to serve as an input to the proposed OGC Underground Infrastructure Pilot as well as similar implementations and deployments in realistic application scenarios. The present model is also suitable as input to begin development of a formal conceptual model standard.

1.1. Requirements & Research Motivation

The development of MUDDI has been motivated by a number of specific design requirements described in the Overview but the principal motivation has been to achieve compatibility and minimal information loss with regard to data represented by several significant existing models and model standards, in order to support both data interchange and data integration across a variety of underground infrastructure components, functions, and associated environmental properties.

1.2. Prior-After Comparison

Findings presented in [1] describe the present generally inadequate state of UGII in many cities and suburban regions. The model presented here, and subsequent pilot activities based on it, along with needed policy, financial, and cultural advances, have the potential to improve UGII quality, reduce incurred costs, and provide numerous opportunities to improve how cities function.

1.3. Future Recommendations

Naturally, publication of a prototype MUDDI is intended to support both the proposed Pilot initiative, as well as development and approval of complete conceptual and implementation specifications.

1.4. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name Organization

Josh Lieberman, editor

Tumbling Walls

George Percivall

OGC

Alan Leidner

FCNY

Carsten Roensdorf

Ordnance Survey

1.5. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following normative documents are referenced in this document.

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

Soils

This term has a precise definition as the primary component of the Earth’s pedosphere. It is used here in a more general sense to refer to all overburden earth materials in the underground environment, including soils, sediments, and construction fill, that might surround and support underground infrastructure components.

Subsurface Infrastructure

See Underground Infrastructure

Underground Environment

Material forming the ground in which underground infrastructure is embedded, and its aspects such as geology, hydrology, chemistry, and engineering properties. This term also covers dynamic subsurface processes such as physical deformation, fluid flow, and chemical / biological alteration.

Underground Infrastructure

The totality of built components or structures embedded below ground surface that are part of services such as utility networks and/or that support ground surface structures.

Underground Infrastructure Information

Information collected about or pertaining to Underground Infrastructure

Underground Infrastructure Information System

Computing system or platform that manages information pertaining to Underground Infrastructure

4. Overview

The Underground Infrastructure Concept Development Study (UICDS) Engineering Report [1] examined the present state of underground infrastructure information (UGII), costs and benefits of that state, as well as future opportunities for an improved state. That report describes a number of candidate models for UGII and recommends a number of follow-on activities, including development of a prototype UGII integration model to support subsequent UGII integration and exchange initiatives. A follow-up workshop and model development effort resulted in another engineering report describing an initial (1.0) version of the conceptual UGII integration model MUDDI (Model for Underground Data Definition and Interchange) [2]. The present updated report describes MUDDI version 1.1. The goal of MUDDI is to serve as the basis for integration of datasets from different models, at the levels of detail required to address application use cases described in [1]. MUDDI as described here is a conceptual model which will serve as the basis for one or more conformant and interchangeable logical and physical implementations such as GML (Geographic Markup Language) or SFS (Simple Features SQL). The current version 1.1 of MUDDI has been updated and refined from the initial version 1.0, but is still intended to serve as an input to the proposed OGC Underground Infrastructure Pilot as well as similar implementations and deployments in realistic application scenarios. The present model is also suitable as input to begin development of a formal conceptual model standard.

4.1. Design Requirements

The development of MUDDI has been motivated by a number of specific design requirements:

1) Functionality

The model should specifically address three priority application use cases (Excavation, Large-scale Construction Design, Disaster Planning)

2) Compatibility

The model should derive from or map to/from existing candidate models such as INSPIRE [IUN] (Infrastructure for Spatial Information in the European Community), CityGML UN ADE [CUA] (Utility Networks Application Domain Extension), GeoSciML [GSML], or IMKL [IMKL] (Informatie Model Kabels en Leidingen).

3) Modularity

The model should have a modular structure with a simple mandatory core and additional elements in the form of optional extensions or interfaces, in order to minimize the quantity and detail of data required for specific use cases.

4) Traceability

The model should provide for UGII to be linked directly with the survey measurements, sensor observations, and supporting evidence from which it was derived and from which its quality can be determined.

5) Flexibility

The model should support implementations that include the geometric and topological representations needed for specific applications, such as 2D geometries for excavation planning, 3D geometries for construction design, or functional graph topologies for disaster vulnerability assessments.

4.2. Design Patterns

There are a number of common model design patterns which might satisfy MUDDI requirements, particularly modularity and flexibility:

Relational

the pattern of fixed tables connected by foreign key relations. Clearly an established implementation pattern, but tends to result in duplication of data to support specialization and rather brittle relationships between model elements.

Graph

an extremely flexible pattern of data elements connected by diverse relation predicates tends to represent knowledge webs and physical networks very well, but is still hard to implement for spatial data.

Object

inheritance patterns are particularly well suited to UML modeling, but specialization hierarchies themselves can lack flexibility in terms of being able to choose different configurations of specialized attributes for specific applications.

Interface

a variant of the object model in which specializations can also be supported by the addition of interface elements (consisting of attributes and/or operations) to primary objects. Interfaces can be mixed and matched as well as reused for different primary objects, but the variety of ways in which they can be implemented may present a risk of non-interoperability between implementations.

4.3. Report Structure

  1. Description of application use cases, priorities, and derived model requirements

  2. Description of candidate model scopes, characteristics, goals, strengths, and weaknesses

  3. Overview and narrative of the MUDDI Unified Modeling Language (UML) model

  4. Details of individual MUDDI modules / interfaces and the use cases they address

  5. Mappings between MUDDI and elements of significant existing models

  6. Guidelines for MUDDI implementations

5. Use Cases and Derived Requirements

The following 6 UGII application use cases are detailed in [1] and the first 3 use cases are considered a priority for the OGC Underground Pilot.

5.1. Use cases

  1. Routine street excavations (EX)

    There are on average between 30 and 40 excavations annually per mile of roadway in many developed areas. Since urban and even suburban underground space is typically crowded with many different utility lines, most jurisdictions require that utilities share their data at the location of a proposed excavation in order to avoid utility strikes, which can cause extensive damage and result in significant costs and delays. In many cases, mark-up crews must locate records for the street in question and bring them out into the field in their vehicles. Information sharing and collaboration consists of "graffiti-style" sketches made on the street with spray paint or chalk. Getting all the utilities to respond routinely takes several days to a couple of weeks – if essential records can be located at all. The effectiveness of the street markup process depends upon the often questionable, rarely documented, and even more rarely tested accuracy and completeness of the records being referenced.

    With utilities records in standards-based digital formats, information requests can be answered with digital submissions from each utility. Because the utility data is in a common format, it can be seamlessly integrated by excavators and used to guide underground work. Modern methods of data exchange, including wireless communications to mobile devices in the field, then make it possible to rapidly assemble utility information directly in the field, potentially lowering the strike risk and also reducing the time to mitigate strike hazards from days or weeks to minutes.

  2. Planning, design and construction of large scale projects (AE)

    Cities and other large jurisdictions undergo constant change. At any one moment there may be a dozen or more new projects on the drawing boards and in construction. It is in the interests of these jurisdictions that new development be as economical as possible: that costs are held to a minimum and that projects are completed on schedule and in budget. To meet these objectives, project planners, engineers and architects need access to the best possible information to guide their plans and designs. They need to know if the capacity of utilities and characteristics of the underground environment can support the scale of the project envisioned. They will also need to know precisely where those utilities are located in order to properly plan building foundations and new building service connections. Answers to these questions require access to high quality information in a form that is straightforward to integrate and analyze.

    Comprehensive and interoperable information about existing infrastructure networks is a pre-requisite for efficient planning and design for major new development. Information about existing and potential natural conditions is also essential for assessing both impacts to the environment and vulnerabilities to events such as flooding, hurricanes, and earthquakes. All of these need to be appropriately accounted for in good designs. When data are incomplete, incompatible, and difficult to find, this can lead to unduly large contract contingencies as well as significant delays in moving forward. Once construction does commence, unexpected discoveries of serious underlying conditions too often require very expensive change orders and long time delays. Major projects that cover a large area and extend over many years need continuing access to good underground data. If this access is not maintained, it adds additional cost and risk to the project.

  3. Disaster planning and response (DP)

    Large scale disasters do not happen very often, but when they do, the failure to anticipate effects on major infrastructure features as well as on other components of the built environment that depend upon that infrastructure, can add billions to costs and result in the displacement, injury and death of large numbers of people. Disasters that are particularly associated with infrastructure failures include power blackouts, floods, tsunamis and storm surges; earthquakes, tornados, hurricanes and other high wind events; high heat events, fuel explosions, and terrorist attacks. A disaster event, at its most disabling, can lead to the failure of major utility generating, storage, control or transmission facilities, cutting off utility resources to large areas. Power failures caused by storm, flood or heat can black out an entire region and cause the shutdown of many critical facilities. A storm surge can flood transit and vehicular tunnels, short circuit electric substations and knock out basement utilities. Interdependencies between infrastructure networks can mean that the failure of one system disables others in a cascading effect. Although not all the damage caused by a disaster event can be anticipated or prevented, any capacity to do so is utterly dependent on the rapid availability of high-quality, interoperable, geospatially enabled data for analyzing vulnerabilities to disaster consequences.

    Interoperable underground utility data that depict large-scale and/or critical transmission, generation, or storage features with their physical and functional interconnections are particularly important. They enable analysis and simulation of the effects of a disaster event, development of protective strategies, and quick reaction to outages and damage. Such data are also important for identifying single points of failure, interdependencies, and triggers for cascading effects. Data about corresponding above-surface features along with underground environment characteristics such as permeability and saturation are also needed to examine the effects of disaster scenarios such as storm surge levels. Major utility features comprise only a small percentage of the overall utility infrastructure, which is dominated by street-level distribution branches; and concerns for their security often mitigate against data standardization and sharing. Nevertheless, without proper integration and analysis of data for both strategic and street-level infrastructure components, jurisdictions will remain hopelessly vulnerable and reactive to disaster events rather than properly prepared.

  4. Utility related emergency response (ER)

    Bringing together utility information for routine excavations may take a significant amount of time, but there is far more urgency when dealing with a potential emergency. Not only must on-scene responders know about all the utility lines they may encounter, and their capacity, before excavation, but they also need to know about the location of utility control features that can rapidly shut off service in the event of a significant break. For example, when a water main leak is strongly suspected, a series of control valves must be located and shut off in sequence to stop the flow since a water supply system is a looped rather than a radial network. Soil and sediment data is also helpful in understanding whether flow and scour from a major water main break may undermine adjacent utility lines and nearby building foundations. Slow or incomplete delivery of this information can lead to a dangerous and costly event. Stories abound of utility workers at the scene of an incident huddling over paper plans on the hood of a truck, trying to figure out what might be happening.

    Complete, accurate and interoperable underground infrastructure data available via wireless communications to the field can enable emergency field responders to rapidly understand the nature of a utility problem and to take informed action. Shut off valves can be quickly located and closed. Digging to expose the damaged pipe or conduit can be commenced immediately with confidence that all other utilities locations in the vicinity are known and can be avoided.

  5. Private and public utility operations, maintenance, repair and replacement programs (OM)

    All utilities have maintenance programs to ensure that their networks are functioning optimally with a minimum of complaints and outages. An important part of such maintenance operations is the replacement of old and obsolete infrastructure elements with new, safer and higher-capacity components. The ability to comprehensively analyze the performance of individual utility features as well as entire networks, on the basis of complete and accurate utility feature information including age, material, capacity and location, is essential for making economically responsible decisions. While installing new gas lines or electric conduit may be expensive, analysis can show it to be less expensive than dealing with major service outages when utility components fail or no longer meet demand.

    Utility maintenance and repair processes depend upon data that relates complaints and problems to specific utility element locations and characteristics. Information about the underground environment, including earth materials and structures, moisture, vibration and the effects of adjacent utility lines, can also help utility analysts understand where segments of their networks are at greatest risk of corrosion, damage and breakage. As the use of utility-monitoring sensors becomes more widespread, additional layers of information and intelligence can be made available to support decision making processes.

  6. Smart Cities, Future Cities (SC) New generations of sensors and smart control valves that can be attached to underground infrastructure components are transforming the way in which infrastructure networks are monitored, and are revolutionizing the way infrastructure product delivery is managed. In turn, these sensors and controls will likely require new supportive power and telecommunications infrastructure, increasing the interdependencies between utilities. Furthermore, innovative technologies coming into use will require new types of utility services such as curb outlets for recharging electric vehicles and navigation infrastructure to guide autonomous vehicles. As underground networks adapt to such new developments, comprehensive knowledge of infrastructure locations and characteristics will be essential for modernization.

    To keep up with the pace of technological transformation it will be necessary for jurisdictions to be prepared for major overhauls of their underground infrastructure environment. There is likely to be increased need to access buried networks and install new services as efficiently as possible. An important step in preparing for these changes will be to fully document the infrastructure that is currently in place, and to evolve standard data models for the new services and devices that are on the way. Losing track of what is underground will be a substantial barrier to realizing the benefits of future city innovations.

5.2. Derived model requirements

The following model requirements are drawn from the foregoing use cases and reference back to them.

Table 2. Use case derived model requirements
ID Requirement Capability Example

EX1

Horizontal cross-section of all UGI (Underground Information) entities with high horizontal, medium vertical accuracy

2.5D feature geometries

AE1

Detailed 3D UGI geometry

3D feature geometries

AE2

Detailed 3D underground environment information

Voxel indexing

AE3

Survey, sample, and measurement information

Linked survey measurements

DP1

Physical and operational dependency relationships

Topological, structural, functional dependencies

DP2

Vulnerabilities - inundation, fire, frost, environmental hazards, terrorism / vandalism

Vulnerability assessments

DP3

Simulations and predictions (thencast / nowcast / forecast)

Simulation model parameters

ER1

Spatial and functional relationships between all UGI elements

Network topology

OM1

Within-network topology and functional relationships above-below ground

Network roles

OM2

UGI asset status and lifecycle information for cross-utility planning

Feature-as-asset lifecycle

SC1

Instrumentation, property, and feature-of-interest relationships

Related sensor observations and inspections

SC2

Sensing data streams

Time-series properties

SC3

Contributed observations

Data quality / provenance indicators

6. Candidate Underground Information Models

6.1. Overview

The UICDS contribution from Sisi Zlatanova and Ben Gorte (Delft University of Technology, Netherlands) listed a number of design criteria for UGII models which help explain the diversity of existing models which are presently in development or use.

UGII model design criteria
  1. Different applications and user roles require different information. For example, some stakeholders need the location of the utilities, while others need the details like the type of transported material.

  2. Types of objects and their properties to be represented.

  3. Object naming conventions to be observed.

  4. Complexity of object representation, e.g. 2D point or 3D solid geometry.

  5. Aggregation and generalization of objects and object details. For example, a collector with multiple cables can be modeled by many objects or by one object with a property of number of cables.

  6. Relations represented between distinct networks.

  7. Relations represented to other underground or above-ground features.

  8. Operations and other processing to be performed on the data.

  9. System architecture of implementing systems, e.g. distributed storage or a centralized system.

  10. Visualisation requirements (2D/3D, web, specialized software)

  11. Size, scope, and update frequency of the represented infrastructure area.

  12. Granularity and flexibility of data query and access.

Existing models identified in the UICDS can be divided into those covering generic utility infrastructure, specific utility networks, underground geology / hydrology, land infrastructure, and practices of surveying and measuring underground features.

Significant utility network types
  • Electricity network

  • Oil, Gas & Chemicals network

  • Sewer network

  • Telecommunications network

  • Thermal network

  • Water network

  • Transport network

Common feature attributes
  • Location – e.g., XY coordinate and/or Z-depth

  • Shape – e.g., a rectangle or round pipe

  • Color

  • Diameter – e.g., exterior/interior diameter

  • Material – e.g., rubber, steel, iron, etc.

  • Ownership

  • Date (Installation and Last update)

6.2. Candidate infrastructure models and characteristics

  1. CityGML Utility Network ADE (Application Domain Extension) [CUA] leverages CityGML by representing supply and disposal networks in 3D city models. CityGML is an OGC data model and XML-based format for the storage and exchange of virtual 3D city models. As a CityGML extension, the Utility Network (UN) ADE directly supports 3D topographic, topological and functional modeling of hierarchies; it can thus provide homogenized and integrated views of multi-utility networks together with other CityObjects. It would likely require specialized CityGML software systems, however, to leverage more advanced UN ADE characteristics such as network vs feature graphs or functional network roles.

    6 citygml
    Figure 1. CityGML Utility Network ADE Data Model
  2. INSPIRE Utility Networks [IUN] is one of the 34 INSPIRE spatial data themes. INSPIRE is a European Union initiative to establish an infrastructure for spatial information that is geared to help to make spatial or geographical information more accessible and interoperable for a wide range of purposes supporting sustainable development. The theme Utility and Government Services provides basic information (e.g. the location, basic technical characteristics or involved parties) on a wide range of administrative and social services of public interest.

    Subtheme(INSPIRE, 2013)

    • Utility Networks: Node-link-node structured networks for collection, transmission and distribution, including electricity, oil/gas and chemicals, sewer, thermal, water or (not mandatory) telecommunications networks;

    General service information

    • Feature location;

    • Party involved in the service (Administration or organization on behalf of an administrative mandate);

    • Basic technical characteristics, such as capacity or details on the type of service provided.

    Utilities considered

    • Electricity network,

    • Oil, Gas & Chemicals network,

    • Sewer network,

    • Thermal network,

    • Water network,

    • Telecommunications network (only proposed in the technical guidance, not in legislation).

      6 inspire utilities
      Figure 2. INSPIRE utilities network common types model
  3. IMKL (Information model for cable and pipes) [IMKL] is an INSPIRE-based specification for the exchange of cable and pipe information. As mentioned in UICDS contribution from Sisi Zlatanova and Ben Gorte of Delft University of Technology, Netherlands, IMKL has been developed by the Dutch Cadastre and further refined by Informatie Vlaanderen. It extends the INSPIRE Utility Services model as illustrated in Figure 3.

    6 imkl
    Figure 3. Flanders refinement of IMKL data model

    The UICDS contribution from Jef Daems of Informatie Vlaanderen highlights the adoption of IMKL in the KLIP system which facilitates the sharing of underground information from network operators in the Flanders region of Belgium in order to service excavation requests. The version of IMKL used in KLIP is based on the initial Dutch model and has evolved to meet the practical needs of excavators and the utility sector in Flanders. Essentially IMKL further specializes the specific utility network types defined in the INSPIRE theme model by inheriting additional properties from IMKL types such as Depth or ExtraTopography (Figure 4). This multiple inheritance pattern adding the IMKL Kabelenleiding (CableConduit) properties to the INSPIRE SewerPipe object is shown in Figure 5.

    6 imkl model
    Figure 4. IMKL data model
    6 imkl SewerPipe
    Figure 5. IMKL multiple object inheritance pattern
  4. ESRI Utility Network Model [EUN] represents a number of models constructed as geodatabases that leverage ArcGIS geometric networks to represent the connections between utility objects specialized for particular utilities, including

    • Utility and Pipeline Data Model

    • Fiber Network Data Model

    • Gas, Water, Electric, and Wireline Cable models

These models contain large numbers of features specialized for particular industries, but the geometric network construction can restrict which forms and dimensions of connectivity can easily be represented in the model.

+

6.3. Candidate models and characteristics for specific utilities

The models described here are intended to represent data for particular utility industries. They are potential sources of data objects, properties, and codelists for UGI pertaining to those utilities. Information from datasets conforming to these models may also need to be mapped into an integration model. They themselves are not, however, candidates for cross-utility integration models.

  1. Power Utilities – IEC (International Electrotechnical Commission) CIM (Common Information Model) [CIM] is a global standard for electric power transmission and distribution. The CIM is currently maintained as a UML model. It defines a common vocabulary and basic ontology for aspects of the electric power industry. The standards are listed below:

    • IEC 62357 specifies a reference Service Oriented Architecture (SOA) and framework for the development and application of IEC standards for the exchange of power system information in distribution, transmission, and generation systems involved in electric utility operations and planning. The multi-layer reference architecture considers new concepts and evolving technologies, such as semantic modeling and canonical data models, in order to build on technology trends of other industries and standards activities to achieve the interoperability goals of the Smart Grid.

    • IEC 61970 defines an application programming interface for energy management including a Common Information Model (CIM) that defines the standard for data models in electrical networks and energy management. It supports the import and export of formats such as XDF, RDF and SVG, which are based on the XML standard

    • IEC 61850 defines a standard for the design of electrical substation automation. The standard defines standard data models that allows for the mapping of various communications protocols.

    • IEC 61968 defines a Common Information Model (CIM) for distribution management systems and builds on the benefits provided by 61970 in Transmission.

    • IEC 62351 defines handling of security of protocols including authentication of data transfer to ensure authenticated access and detection of intrusion.

    • IEC 62056 defines a set of standards for meter reading including data exchange for meter reading, and tariff and load control. The specification is not unique to electric meters and has been adopted for other industries including water and gas meters.

    • IEC 61508 specifies the functional safety of electrical/electronic/programmable electronic safety-related systems.

  2. Enterprise Systems for Utilities – The MultiSpeak specification [MSU] is a North American standard for data exchange between enterprise systems which is commonly applied in utilities. It started in at the beginning of this century as a collaborative effort between NRECA (National Rural Electric Cooperative Association in the United States) and a small group of vendors supplying software to U.S. electric cooperatives. The current version of the standard covers: Distribution System Modeling, Work Management, Business Functional External to Distribution Management, Distribution Operations, and Distribution Engineering, Planning Construction and Geographic Information Systems (GIS). MultiSpeak has its origins in serving the small utility and electric cooperative markets and is currently in use in the daily operations of more than 600 electric cooperatives, investor-owned utilities, municipals, and public power districts in the US and around the world.

    6 MultiSpeak
    Figure 6. MultiSpeak Process Model Overview
  3. Wastewater Pipeline & Manhole Condition Assessment – Condition inspection, assessment and monitoring of buried water and wastewater assets using both destructive and non-destructive trenching and trenchless technologies are well advanced in the water industry. The industry is organized around well-established national and international standards and guidelines for the assessment of the condition and performance of sewer and water pipes and there is a mature ecosystem of specialist wastewater and water contractors who carry out these inspections, hardware technology firms who provide the specialist equipment and appropriately trained staff to carry out these inspections, and software vendors who provide data management, GIS, decision support, capital planning, maintenance prioritization/scheduling systems etc. that leverage the results of the condition inspections for asset management purposes. National standards for wastewater pipeline and manhole condition assessment have been adopted around the world – principally European Union (EU EN13505-2:2000), PACP/LACP (USA NASSCO), MACP (USA NASSCO), MSCC SRM4/5 (WRc. UK), WSSA (Australian), and other European Country specific standards (for example ISYBAU in Germany and Belgium). Each coding standard has its own condition scoring algorithm that is used to convert defect code observations into scores and indexes that are ultimately used to update a pipe’s structural and maintenance/service condition grade.

  4. Gas Distribution – The Gas Technology Institute has recently completed version 1.0 of their Gas Distribution Model (GDM). This standard serves three purposes: (i) data exchange between operators and vendor software; (ii) managing transmission and distribution data to facilitate vertical data integration; and (iii) the primary data model for operators.

  5. Water/Wastewater Modeling – US Environmental Protection Agency models – the Stormwater Management Model (SWMM) for storm and sanitary sewers and EPANET for water distribution systems, have become a de facto standard. However, they tend to only contain data needed for the simplest modeling applications; these models can only describe one scenario.

6.4. Underground environment candidate models

Significant underground environment entities
  • Soil units

  • Bedrock units

  • Groundwater units

  • Geological structures / cavities

  • Fill / debris

  • Abandoned structures & artifacts

  • Roots / burrows

    1. GeoSciML

      Used for geological map data, boreholes, and structural features such as faults and folds. GeoSciML is the model/exchange format leveraged by INSPIRE for its Data Specification on Geology

    2. INSPIRE

      Data Specification on Geology uses and extends GeoSciML to cover a range of geologic thematic features

    3. GeoTOP

      GeoTOP is a detailed three-dimensional model of the upper 30 to 50 meters of the subsurface produced by the Netherlands Organization for Applied Scientific Research (TNO). It provides the user with a cell-based description of the spatial variability of geological, physical, and chemical parameters in the subsurface.

    4. BGS National Geological Model – UK 3D NGM

      As part of the EU funded EarthServer project, the British Geologic Survey implemented geological surfaces as GML coverages, and uses GeoSciML to describe the rock bodies in relation to their bounding surfaces, with the GeoSciML being added to the extension metadata of the surface coverages.

6.5. Other infrastructure candidate models

Other infrastructure features
  • Foundation assemblies

  • Vaults / conduits

  • Transport tunnels / tracks / stations

  • Underground storage

    1. Industry Foundation Classes [IFC] is the most widely used architecture and engineering standard for representing and exchanging data about buildings and their components. IFC represents logical building structures and their accompanying properties (attributes) along with 2D and 3D geometry. IFC can also represent utilities components as building services, but generally focuses on buildings themselves rather than general city infrastructure.

    2. Land and Infrastructure Conceptual Model (LandInfra) [LI] is an OGC standard for division of land. The standard includes support for topography as well as subsurface information. It also provisions support for information about civil engineered facilities such as roads and railways, and in the future, “wet” infrastructure including storm drainage, wastewater, and water distribution systems. LandInfra is divided into 15 Requirements Classes for particular subject areas. LandInfra does overlap onto many underground infrastructure elements but it’s focus is on the land divisions that may be implied by infrastructure components such as water systems, rather than the components themselves.

      6 landinfra
      Figure 7. Current LandInfra requirement classes and corresponding InfraGML packages (minus prospective utility network classes)

7. MUDDI Overview and Core

7.1. System context

As described in earlier sections of this report, the MUDDI model is intended to serve as a basis for integrating underground data from multiple sources, systems, and schemas. Datasets may be virtually integrated, so that each dataset is accessed remotely in the form of MUDDI data, or physically integrated and stored as MUDDI data in one system, either as a performance-enhancing cache, or as a tested and authoritative repository. With either system approach, the model requires multiple input interfaces that enable datasets to be mapped into the model from diverse sources, and multiple output interfaces that provide access to the right perspectives for each of several data-driven applications.

7 integration architecture
Figure 8. Integration architecture for MUDDI

7.2. MUDDI model architecture

The MUDDI model consists of a small number of core entities derived from a general feature object, including network features, support and container features, and underground environment features. The core entities are further specialized for specific utility network types with both additional attributes and utility-specific type codes.

These core feature entities are then enhanced as needed by realizing one or more interfaces that support specific types of input data, transformations to/from significant external model schemas, additional geometry types such as 2D, 3D, and voxel, network connectivity and functionality, data quality measures, and so on that are further described in Section 7.

7 model structure
Figure 9. MUDDI

7.3. MUDDI core model elements

The MUDDI model packages are shown in Figure 10 and comprises a core package, network package, environment package, and package of extended interfaces. An additional package is an example of a logical model specialization of the conceptual model. The core MUDDI classes are shown in Figure 11. The root class of the model is MUDDIObject, whose attributes include many of those recommended for infrastructure assets in the ASCE As-Built draft specification

A child network object feature includes most of the other attributed specified by the ASCI As-Built is specialized by three network elements: a network node, a network surface node, and a network link. The basic network also includes network and network facility objects as well as simple optional relationships between them.

Two other MUDDIObject children are the container and support object features, for built structures which do not constitute directly either network infrastructure or environmental elements, but contain or support other infrastructure elements.

A significant update to the version 1.0 model is inclusion of a number of codelists shown in Figure 12 that provide both controlled and authoritative values for many of the attributes for the core MUDDI features.

7 model packages
Figure 10. MUDDI packages
7 model core features
Figure 11. MUDDI core features
7 model codelists
Figure 12. MUDDI code lists

7.4. MUDDI environment entities and relationships

Another MUDDIObject specialization shown in Figure 13 is the Environment Object feature, further specialized into features representing geological, hydrological, pedological (soil-specific), and phenomenological features of the subsurface environment. The general geometry type for these features will be a region bounded by surfaces, but interfaces add both cross-sections and borehole geometries as input and/or output capabilities.

7 model environment features
Figure 13. MUDDI environment features

7.5. MUDDI network entities and relationships

The combination of MUDDI network features and network-specific interfaces need only describe collections of network infrastructure elements, but may optionally support a number of distinct levels of network representation complexity, as well as levels of detail. Figure 11 hides the inheritance relations between the different network entities in order to focus on the relationships that can be represented between them. The IGraph interface adds these specific relationships. For example, networks can be related to each other as either subnetworks (containment) or subordinate networks (dependency). Networks consist of nodes and links, which in turn connect to each other. Relative to a particular network, however, either a node or a link may in addition serve as an interfacial element, belonging to more than one network or connecting to an element of another network.

A capability supported by CityGML UN ADE is the option to represent inter-network assemblages ("internal" relationship) which depict additional graph detail inside of what is represented as either a node or a link at a lower level of detail. This generally requires interfacial relations to describe the connection between the internal network and elements of the enclosing network

7 model network
Figure 14. MUDDI network features and relations

The MUDDI interfaces package comprises some 19 different interfaces that add geometric attributes, additional network relations, transformations to other model perspectives, and other capabilities to any parent or child object without the requirement for them to be carried along to further specializations.

7 model interfaces
Figure 15. MUDDI extended interfaces

8. MUDDI Modules and Interfaces

8.1. Modules

The following tables describe core MUDDI elements and some extended elements. The relations and attributes shown in the module tables may realize optional (but commonly used) interfaces. Other interface relations, attributes, and operations are shown below.

Each of these elements include attributes that describe the specific class or type classification of more specialized instances, such as containerClass. This allows aggregation of diverse utility structures without losing their more specialized identities. More general MUDDI elements such as NetworkLink could also be specialized for the specific utility types listed in Section 6 and/or for specialized types that characterize the candidate models. Such subclass entities are not (yet) included in this report.

8.1.1. Core elements

Table 3. MUDDI core elements
Name Description Relations Attributes

Structure

Base unit of underground features

partOf, surfaceConnect, hasProperty

localIdentifier, class, position, extent, shape, size, color, material, ownership, status, validTime, inService, description

NetworkObject

Base unit of network elements

connect, transport, produce, consume

function, usage, commodityClass, isComplex

EnvironmentObject

Base underground environmental region

surrounds, underlays, overlays, adjoins, boundedBy, unit, hasSample

featureClass, domain, method, regionName, unitName

ContainerObject

Base unit of structures that primarily contain other structures

contains

containerClass

FoundationObject

Base unit of structures that primarily give physical support to other structures

supports

foundationClass

8.1.2. Network elements

Table 4. MUDDI network elements derived from NetworkObject
Name Description Relations Attributes

Network

Network complex structure that transports / stores / provides / consumes a utility commodity

subNet, subordinateNet, constitutes, commodity

networkClass

NetworkNode

Network node structure that connects NetworkLinks, may connect Networks, and may control and/or measure a utility commodity property

connectsFrom, connectsTo, consistsOf, internalTo, interfacesWith, sensedBy, actuatedBy

nodeClass, isSource, isSink, isTerminal

NetworkLink

Network edge structure that connects between NetworkNodes

linksTo, linksFrom

linkClass

8.1.3. Environment elements

Table 5. MUDDI environment elements derived from EnvironmentObject
Name Description Relations Attributes

GeoObject

Environmental region defined in the geological domain

geoClass, rockType

PedoObject

Environmental region defined in the pedological (soil) domain

soilHorizon, soilClass

HydroObject

Environmental region defined in the hydrological domain

hydroClass, saturation, head

PhenomObject

Environmental region defined by an observable physical-chemical characteristic

delimitationMethod

8.1.4. Container and support elements

Table 6. MUDDI container elements derived from containerObject
Name Description Relations Attributes

Conduit

Simple network link / node container

conduitClass

Vault

Multipurpose network element container

commodity

vaultClass

Shield

Structure providing limited protection (e.g. grout curtain) for other underground structures

shields, shieldsFrom

shieldClass, shieldOrientation

Access

Access structure (e.g. manhole) for container or other structure

accessTo, accessFrom

accessClass

Table 7. MUDDI support elements derived from supportObject
Name Description Relations Attributes

Footing

Simple footing support

footingClass

Foundation

Foundation for underground or surface structures

foundationClass

Piling

Vertical foundation element for underground or surface structures

pilingClass

8.2. Interfaces

Table 8. MUDDI Interfaces
Name Description RealizedBy Attributes/Operations Relations

IAsset

Attributes of maintained asset, such as lifecycle stage

Structure

assetID, assetClass, operator, lifecycleStage, serviceLife, timeToFailure, initialValue, depreciationMethod, predecessor, getPresentValue

I2D

2D Geometry plus depth

Structure

GM_Geometry (2D), elevation, depthBelowSurface, footprint, scale

I3D

3D Geometric solid in 3D space

Structure

GM_Geometry (3D), anchorPosition, resolution

IVoxel

Collection of voxels containing the 3D extent of the feature

Structure

voxelClassification, voxelScheme, anchorPosition, voxelResolution, getVoxels

IRendered

3D rendered model of the feature (e.g. Collada)

Structure

model, modelClass, modelFormat, anchorPosition

modelConfiguration

IIFC

Operations for reading or writing IFC objects

Structure

GetIFC, GetMUDDI

ICityGML

Operations for reading/writing CityGML with or without the UN ADE

Structure

GetCityGML, GetMUDDI

ISurveyed

Position and extent measurements

Structure

surveyMethod, positionResult, extentResult, resultPrecision, resultAccuracy

surveyEvent

IObserved

Measurements of observed properties

Structure

observedProperty, procedure, resultValue

observationEvent

IDataQuality

Quality of positioning and other measurements of infrastructure characteristics

Structure

surveyQualityLevelASCE3802, completeness, positionalAccuracy, topologicalConsistency, thematicAccuracy, maximalFootprint

surveyEvent

ILink

General link facility for distributed data

Structure

linkClass, role, targetClass, action

linkTarget

IModel

Configuration, input and output attributes specific to simulation models and model results

Structure

inputProperty[0..*], outputProperty[1..*]

model, modelEvent

IGraph

Attributes and relations for topological networks

NetworkObject

isComplex

connectsFrom, connectsTo, consistsOf, constitutes

IService

Network service area, sources, and sinks

Network

providerArea, consumerArea

IControl

Attributes of network nodes which control network operation

NetworkNode

controlClass, controlState, isSource, isSink

dependsOn, actuationEvent

IDistribute

Attributes of network links affecting or reflecting network operation

NetworkLink

cross-section, flowVelocity, flowRate, flowDirection, potential, potentialDifference, commodityStatus, measuredTime

IBore

Borehole geometry and interval features, either real or synthetic

EnvironmentObject

surfacePosition, axisLinestring, diameter, isSample, interpolationMethod, getCore, getCoreInterval

ISection

Cross-section geometry and 2D region features constructed from environmental objects

EnvironmentObject

interpolationMethod, surfaceTrace, getSectionSurface, depth, getModel,

sectionRegion

9. Mappings between MUDDI and Candidate Models

This section presents provisional mappings between MUDDI entities and those of candidate models described in Section 6. Some mappings may be direct, broader, or narrower. There may also be different cardinalities, e.g. one MUDDI entity mapping into multiple entities in a different model. The mappings presented here are a first pass for developing data conversion routines, as well as guiding future MUDDI implementations.

Table 9. Mappings from MUDDI to candidate infrastructure model entities
MUDDI Entity Name CityGML UN ADE Target Fit INSPIRE / IMKL Target Fit

Structure

AbstractCityObject

wider

Feature

wider

NetworkObject

AbstractNetworkFeature

narrower

NetworkElement

level

Network

Network +/- NetworkGraph +/- FeatureGraph

level

Network

level

NetworkNode

Node +/- FeatureGraph

level / complex

Node

level

NetworkLink

AbstractLink +/- FeatureGraph +/- AbstractDistributionElement

level / complex

Link

level

ContainerObject

ProtectiveElement

wider

UtilityNodeContainer

narrower

SupportObject

Bedding

narrower

PoleFoundation

narrower

Table 10. Mappings from MUDDI to candidate environment model entities
MUDDI Entity Name GeoSciML Fit INSPIRE Geo / Hydrogeo / Soil Fit

GeoObject

GeologicFeature

level

GeologicUnit or GeologicStructure

level

PedoObject

-

SoilBody or SoilHorizon or SoilLayer

narrower

HydroObject

-

HydrogeologicalObject or HydrogeologicalUnit or GroundwaterBody

narrower

PhenomObject

PhysicalDescription

narrower

GroundwaterProfile or PossibleContaminatedSoilSite

narrower

Appendix A: Abstract MUDDI Test Suite

Table 11. A.1.1 Conformance Class OGC 17-090_c1

Test identifier

MUDDI_UML

Test purpose:

Confirm that a valid implementation of MUDDI is conformant with the UML model

Test method:

Inspection of all required and optional implementation elements for MUDDI UML conformance

Requirement:

OGC 17-090_r1

Test type:

Implementation conformance

Appendix B: UML model

Appendix C: Revision History

Table 12. Revision History
Date Editor Release Primary clauses modified Descriptions

December 1, 2017

J. Lieberman

0.1

all

initial version

January 21, 2018

J. Lieberman

0.5

all

expanded draft with mappings

July 23, 2018

J. Lieberman

0.9

all

expanded draft with mappings

November 29, 2017

J. Lieberman

1.0

all

Complete after reviews

January 3, 2020

J. Lieberman

1.1

all

Updated model

Appendix D: Bibliography

[1] J. Lieberman and A. Ryan, Eds., “OGC Underground Infrastructure Concept Study Engineering Report,” 2017.

[2] J. Lieberman, Ed., “Model for Underground Data Definition and Integration (MUDDI) Engineering Report,” 2018.