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
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
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Use Cases and Derived Requirements
- 6. Candidate Underground Information Models
- 7. MUDDI Overview and Core
- 8. MUDDI Modules and Interfaces
- 9. Mappings between MUDDI and Candidate Models
- Appendix A: Abstract MUDDI Test Suite
- Appendix B: UML model
- Appendix C: Revision History
- Appendix D: Bibliography
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:
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.
-
ASCE 38-02: Standard Guideline for the Collection and Depiction of Existing Subsurface Utility Data, American Society of Civil Engineers, 2002.
-
CityGML Utility Network ADE (CUA):: http://en.wiki.utilitynetworks.sig3d.org
-
EarthResourceML(ERML): http://www.cgi-iugs.org/tech_collaboration/earthResourceML.html
-
ESRI Utility Network Model (EUN): https://pro.arcgis.com/en/pro-app/help/data/utility-network/a-quick-tour-of-utility-networks.htm
-
GeoSciML (GSML): http://www.opengeospatial.org/standards/geosciml
-
Geographic Markup Language: http://www.opengeospatial.org/standards/gml
-
Industry Foundation Classes (IFC): https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/
-
INSPIRE Utility Networks (IUN): http://inspire.ec.europa.eu/theme/us
-
Information model for cable and pipes (IMKL): https://www.agiv.be/producten/klip/meer-over/technische-documentatie/technische-documentatie-imkl
-
Land Infra (LI): Land and Infrastructure Conceptual Model Standard at http://www.opengeospatial.org/standards/landinfra
-
PAS 128:2014 (PAS128): Specification for Underground Utility Detection, Verification and Location, British Standards Institution, 2014.
-
PAS 256:2017 (PAS256): Buried assets. Capturing, Recording, Maintaining and Sharing of Location Information and Data, British Standards Institution, 2017.
-
Common Information Model (CIM): International Electrotechnical Commission global series of standards for electric power transmission and distribution at https://webstore.iec.ch/home?ReadForm.
-
MultiSpeak (MSU): North American standard for data exchange between enterprise systems at http://www.multispeak.org/
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
- 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
-
Description of application use cases, priorities, and derived model requirements
-
Description of candidate model scopes, characteristics, goals, strengths, and weaknesses
-
Overview and narrative of the MUDDI Unified Modeling Language (UML) model
-
Details of individual MUDDI modules / interfaces and the use cases they address
-
Mappings between MUDDI and elements of significant existing models
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
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.
-
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.
-
Types of objects and their properties to be represented.
-
Object naming conventions to be observed.
-
Complexity of object representation, e.g. 2D point or 3D solid geometry.
-
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.
-
Relations represented between distinct networks.
-
Relations represented to other underground or above-ground features.
-
Operations and other processing to be performed on the data.
-
System architecture of implementing systems, e.g. distributed storage or a centralized system.
-
Visualisation requirements (2D/3D, web, specialized software)
-
Size, scope, and update frequency of the represented infrastructure area.
-
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.
-
Electricity network
-
Oil, Gas & Chemicals network
-
Sewer network
-
Telecommunications network
-
Thermal network
-
Water network
-
Transport network
-
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
-
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.
Figure 1. CityGML Utility Network ADE Data Model -
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).
Figure 2. INSPIRE utilities network common types model
-
-
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.
Figure 3. Flanders refinement of IMKL data modelThe 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.
Figure 4. IMKL data modelFigure 5. IMKL multiple object inheritance pattern -
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.
-
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.
-
-
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.
Figure 6. MultiSpeak Process Model Overview -
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.
-
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.
-
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
-
Soil units
-
Bedrock units
-
Groundwater units
-
Geological structures / cavities
-
Fill / debris
-
Abandoned structures & artifacts
-
Roots / burrows
-
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
-
INSPIRE
Data Specification on Geology uses and extends GeoSciML to cover a range of geologic thematic features
-
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.
-
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
-
Foundation assemblies
-
Vaults / conduits
-
Transport tunnels / tracks / stations
-
Underground storage
-
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.
-
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.
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.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.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.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.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
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.
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
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
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
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
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 |
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
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.
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 |
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
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 C: 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 |