2.1.  General

This Standard defines a Conceptual Model (Clause 10.1) which is independent of any encoding or formatting techniques.

The Standardization Targets for this Standard are Logical Models that implement MUDDI in a specific context.

The MUDDI Conceptual Model (CM) defines a number of feature classes, their properties and relationships. The MUDDI CM is intended to be a useful starting point for the development of a more specific, but still platform independent, Logical Model and its Encodings. The MUDDI CM has formal conformance targets as well as a number of mechanisms to tailor the model to detailed requirements as specified below.

2.2.  Conceptual Models

A Conceptual Model standardization target is a version of the MUDDI CM tailored for a specific user community.

This tailoring can include:

1. Omission of one or more of the optional UML packages,

2. Reduction of the multiplicity for an attribute or association,

3. Replacement of abstract value types with concrete value types (including geometry representations),

4. Restriction on the valid values for an attribute,

5. Renaming of any concept term (including Feature class names and their attributes)

The MUDDI CM explicitly allows renaming of concept terms in order to enable the re-use of one or more vocabularies that have been adopted by the relevant user community. Renaming of terms also supports implementations of the MUDDI CM in languages other than English.

The mapping table is the mechanism that documents the relationship between any altered concept term in the Logical Model and the concept terms specified in the MUDDI UML model is a mapping table (the class ‘LogicalName’ in the UML model) that is contained in the MUDDI CM UML model.

2.3.  Logical Models

Logical Models define how a Conceptual Model should be implemented in a specific context. This context specialization can be geographic, for a dedicated user community, specific to defined use-cases or specific to some other application of underground data.

Each Feature Class in the MUDDI CM has a provision for the geometric representation of the Feature Class. However, the CM does not suggest the use of a specific geometry type for any feature. MUDDI requires the specialization of the abstract value type in the geometry property of each Feature Class (specified in ‘MUDDIObject’) into one or more implementable ISO19107 geometries when a Logical Model is being derived from the CM. Assignment of a Simple Features geometry type as specified in ISO 19125-1 is recommended as a minimum.

Conformant Logical Models provide evidence that they are an accurate representation of the Conceptual Model. This evidence should include implementations of the abstract tests specified in Annex A of this document.

Since this Standard is agnostic to the implementing technologies, the specific techniques to be used for conformance testing cannot be specified. Logical Models need to provide evidence of conformance which is appropriate for the implementing technologies. This evidence should be provided as an annex to any specification of a Logical Model.

2.4.  Conformance Classes

This Standard identifies two (2) conformance classes. Each conformance class is defined by one requirements class. The tests in Annex A are organized by Requirements Class. Therefore, an implementation of the Core conformance class must pass all tests specified in Annex A for the Core requirements class.

The core conformance class relates to a small set of features classes that comprise a minimum underground data model. This is referred to as the ‘Core’ model.

The second conformance class contains additional feature class that are optional. It is referred to as the ‘Extended’ model.

Only the Core conformance class is mandatory. All other conformance classes are optional. In the case where a conformance class has a dependency on another conformance class, that conformance class should also be implemented.

The practical implication of this is that the feature classes in the Core part of the model are required to be implemented in any Logical Model. These broadly include objects that represent underground utility networks. All other feature classes specified in the Extended Model are in a separate conformance class. The implementation of any of these classes will depend on the scope and use-cases of the Logical Model and are optional.

The MUDDI Conceptual Model is defined by the MUDDI UML model. This Standard is a representation of that UML model in document form. In the case of a discrepancy between the UML model and this document, the UML model takes precedence.

4.1.  Terms and definitions

4.1.1. underground infrastructure

UGI ADMITTED

infrastructure located at or beneath the surface of the earth or ground level

4.1.2. underground infrastructure information

UGII ADMITTED

information about underground infrastructure

4.1.3. conceptual model

CM ADMITTED

model that defines concepts of a universe of discourse

[SOURCE: ISO 19101-1, Clause 4.1.5]

4.1.4. conceptual schema

formal description of a conceptual model (Clause 4.1.3)

[SOURCE: ISO 19101-1, Clause 4.1.6]

4.1.5. model-driven standard

MDS ADMITTED

standard created using a model-driven architecture

[SOURCE: OGC 21-035r1, Clause 2.1.4]

4.1.6. conformance test case

test for a particular requirement or a set of related requirements

[SOURCE: OGC 08-131r3]

4.1.7. conformance test module

set of related tests, all within a single conformance test class (Clause 4.1.8)

[SOURCE: OGC 08-131r3]

4.1.8. conformance test class

conformance test level ADMITTED

set of conformance test modules (Clause 4.1.7) that must be applied to receive a single certificate of conformance

[SOURCE: OGC 08-131r3]

4.1.9. conformance test

test, abstract or real, of one or more requirements (Clause 4.1.11) contained within a standard, or set of standards

[SOURCE: OGC 08-131r3]

4.1.10. recommendation

expression in the content of a document conveying that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited

4.1.11. requirement

expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted

[SOURCE: OGC 08-131r3]

4.1.12. requirements class

aggregate of all requirement modules (Clause 4.1.13) that must all be satisfied to satisfy a conformance test class (Clause 4.1.8)

[SOURCE: OGC 08-131r3]

4.1.13. requirements module

aggregate of requirements (Clause 4.1.11) and recommendations (Clause 4.1.10) of a specification against a single standardization target type (Clause 4.1.17)

[SOURCE: OGC 08-131r3]

4.1.14. specification

document containing recommendations (Clause 4.1.10), requirements (Clause 4.1.11) and conformance tests (Clause 4.1.9) for those requirements (Clause 4.1.11)

4.1.15. standard

specification (Clause 4.1.14) that has been approved by a legitimate Standards Body

4.1.16. standardization target

entity to which some requirements (Clause 4.1.11) of a standard (Clause 4.1.15) apply

[SOURCE: OGC 08-131r3]

4.1.17. standardization target type

type of entity or set of entities to which the requirements (Clause 4.1.11) of a standard (Clause 4.1.15) apply

[SOURCE: OGC 08-131r3]

4.1.18. statement

expression in a document conveying information

[SOURCE: OGC 08-131r3]

4.2.  Abbreviated terms

CM::Conceptual Model MDA:: Model-Driven Architecture MDS:: Model-Driven Standard OCL:: Object Constraint Language PIM:: Platform Independent Model PSM:: Platform Specific Model UML:: Unified Modeling Language

5.1.  General

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.2.  Identifiers

The normative provisions in this standard are denoted by the URI

http://www.opengis.net/spec/{standard}/{m.n}

All requirements classes, requirements, conformance classes, and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

The normative provisions in this standard are denoted by the URI namespace:

http://www.opengis.net/spec/muddi/1.0/cm

All requirements that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

For the sake of brevity, the use of “req” in a requirement URI denotes:

http://www.opengis.net/spec/muddi/1.0/cm/req

An example might be:

req/core/classes-concepts

All conformance tests that appear in this document are denoted by partial URIs which are relative to the namespace shown above.

For the sake of brevity, the use of “conf” in a requirement URI denotes:

http://www.opengis.net/spec/muddi/1.0/cm/conf

6.1.  Utilities and the Built Environment

The economic life of communities around the world depends to a significant extent upon the quality and efficiency of the built environment. This includes the structures where people live and work and the infrastructure that connects every structure – and serves all who use those structures — with essential resources such as water, energy, and communications services. If buildings and their occupants can be compared to the cells in a human body then infrastructure networks are like the human circulatory and nervous systems without which modern life would not be possible. Further, infrastructure is not static: technological change and economic dynamics require that the infrastructure services be in a constant state of repair, renewal and re-invention to keep up with society’s needs, technological advancement, and competitive necessities.

6.2.  Utilities Go Underground

In developed countries, most jurisdictions have made the decision, sometimes hundreds of years ago, that some or all of the infrastructure serving the populace should be placed underground, running along the street network and branching off to connect with buildings and other structures and street elements. The reasons for this decision are obvious: water and sewer networks cannot be efficiently engineered at the street level and other types of utilities are protected by being buried in the earth, where they do not clutter the streets and sidewalk which are needed to support safe public mobility. For example: the decision by New York City to put utility lines underground was made after the blizzard of 1888 when heavy snows caused the widespread collapse of utility poles and lines, resulting in widespread outages, and a major threat to public safety especially from severed electric wires.

6.3.  Invisible Infrastructure

Yet once infrastructure was placed underground, utilities were and continue to be forced to address another set of problems arising from the fact that pipes, conduits and connections can not be seen at street level nor physically reached when work on them needs to be done. The exception is for small segments of the network that could be accessed via manholes and vaults, and street accessible valve shafts.

The following cases often necessitate an excavation below street level:

• New service connections need to be made,

• Utility lines break and need to be repaired or replaced,

• New kinds of services need to be provided,

• Higher capacity services need to be installed to deal with increased demand

Scenarios in which six, seven or more different kinds of utility pipe and conduit can be found that lie close to or on top of one another, are not uncommon.

Workers are obliged to proceed with great caution because they can not see what might be hit, damaged or severed by their next blind shovel thrust. One miscalculation could lead to a flood from a punctured water line, a gas line explosion or even a lethal shock from a severed electricity conduit. Even so, accidental utility “strikes” were, and continue to be, a regular feature of utility work, delaying projects, wasting money and inconveniencing the public.

6.4.  Utility Data Sharing Procedures Solve Only Part of the Problem

Due to the persistent hazards of uninformed excavations into streets tightly packed with infrastructure, ultimately almost all jurisdictions with underground utilities adopted “One Call” or “Safe Dig” procedures. These procedures require all utilities with infrastructure elements near the site of a planned excavation to either share their records or mark their locations on the street. However, such excavation coordination efforts are only as good as their records which need to be easily accessible, complete, accurate and understandable. In an ideal world, all underground information would meet the FAIR principles for data being Findable, Accessible, Interoperable and Re-Usable.

All too often data flaws and incompatibility lead to misinterpretation and mistakes which result in delays and damages. This might only be a minor annoyance if it were not for the fact that utility excavations are quite frequent. Looking at information from older cities like New York, Chicago and London (and regions like Flanders, Belgium) for every street mile there may be as many as 30 to 40 or more excavations annually. When dealing with the large scale of these transactions, inefficiencies in bringing data together, can be costly, annoying and even dangerous.

6.5.  Utilities and Records Management

Organizations that own and manage underground utilities have generally kept records that depict their networks including geographic location, feature attributes and logical/functional/engineering characteristics. This information supports utility business and field operations including customer service, utility hookup and repair, utility replacement and modernization, and customer billing and collecting, but is not necessarily shared with interested parties. Because the infrastructures of many utilities were designed and created many decades ago, their records reflect the information technology — or absence of technology — available at the time. Even to this day, many records are still kept on manually drafted drawing sheets and service connection cards. More recently record keeping has progressed to include scanned drawings, CAD electronic designs, and databases to store attribute data. More advanced utilities have combined their old records and CAD drawings to create GIS based seamless utility maps with GIS features linked to attribute data.

For utilities, as with almost every other form of business, the efficiency with which information is handled has a significant influence on how effectively the business is run. For underground utilities, this challenge is complicated by the fact that safe and efficient utility operations require a knowledge of the location of other nearby utilities. Since different utilities have different methods for storing and formatting their data, and have a natural reluctance to share based on security concerns, the bringing together of data, even with excavation coordination programs, has been historically problematic. As computer visualization and analytic capabilities continue to grow, opportunities to take full advantage of new information tools are not always realized due to barriers in sharing compatible data quickly in an integrated way, ready for analysis.

The objective of the MUDDI conceptual data model is to reduce this barrier and to show how underground data can be integrated to deliver value.

7.1.  Excavation / strike avoidance

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. If 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.

7.2.  Environmental

Human development and industrialization over the last few centuries lead to activities that polluted our environment. A significant proportion of these activities have impacted the sub-surface. Further, the sub-surface, particularly in urban areas, is heavily modified and these modifications can affect the pathways by which movement can take place. In other words, movement of various physical properties through the underground (UG) can be tracked from their source on or close to the surface through the sub-surface using a conceptual approach. Further, the data requirements of characterizing and monitoring the sub-surface in both space (3D) and changes with time are important. The time element has two aspects: one is the time taken for any change to propagate or travel through the subsurface and the second is how the source itself may change with time. Changes to the source can be sudden, so-called step change in the state of the source, such as a storm event related to heavy rainfall or gradual, such as sea level rise over many decades.

7.3.  Emergency Response / Disaster Management

Large scale disasters do not happen very often. 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, 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 storms, floods or heat events 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, dominated as it is by street-level distribution branches, and concerns for their security often work 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.

8.1.  Design requirements

The development of MUDDI was motivated by several specific design requirements:

Functionality

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

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 (Informatie Model Kabels en Leidingen).

Modularity

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

Traceability

The model should provide for Underground Infrastructure Information 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.

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.

FAIR principles

The principles of making data Findable, Accessible, Interoperable and Re-Usable.

8.2.  Design patterns

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

Relational

The pattern of fixed tables connected by foreign key relations. This is an established implementation pattern, but tends to result in duplication of data to support specialization and can contain brittle relationships between model elements.

Graph

An extremely flexible pattern of data elements connected by diverse relation predicates and tends to represent knowledge webs and physical networks very well. However, this pattern 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.

8.3.  Representation of Location and Geometries

All MUDDI feature classes should be geolocated, meaning that their location is represented by a geometry in a defined Coordinate Reference System (CRS) as specified in OGC Simple Feature Access: Part 1. The root ‘MUDDIObject’ feature class has a geometry property that has an abstract value type. This means there is no explicit geometry type specified in the CM and that the concrete geometry type needs to be implemented in the Logical Model.

At least one simple feature geometry is recommended and is assigned to each feature class in a MUDDI Logical Model. Any simple features geometries are permitted, though implementers are encouraged to choose only geometry types that can reasonably expected to be present in data and are required for the use cases the Logical Model is meant to support.

The CM does not exclude the possibility to use more than one geometry property per feature class (Multiple Geometry Representation). Whether this is desirable or not is an implementation decision that will influence the Logical Model and Encodings.

8.4.  Management of Identifiers

The MUDDI CM includes an Identifier scheme that distinguishes between the following three main identifiers:

1. ObjectID: The Object Identifier refers to the Real-World Object. Ideally the ObjectID would be globally unique or unique within the information sharing community, though it may only be unique for one single data provider. ObjectIDs should be persistently managed. One Real World Object can be represented by one or more representations, or records.

2. RecordID: The Record Identifier refers to data representations of the Real World Object and is unique at least within a defined dataset and persistent.

3. SystemID: The System Identifier refers to an identifier for data or system management purposes that is typically assigned by the specific implementation technology in an automated fashion. The SystemID is either globally unique or unique within a given system of a single data provider. A combination of the SystemID together with the identifier for a particular system or data provider should be unique. Ideally, the SystemID would be persistent between subsequent updates of a feature, though in practice this ID may not always be persistent.

While the maintenance and dereference mechanisms for identifiers are implementation dependent and should be specified in more detail for any implementation, the reason to include these Identifiers in the CM is to set an expectation and understanding for different types of IDs.

9.1.  General

This clause specifies the requirements for the conceptual model.

9.2.  Requirements of the Core conceptual model

The classes of the Core package of the conceptual model are:

• MUDDIObject

• MUDDIAsset

• MUDDIEvent

• MUDDISpace

• Network

• NetworkAsset

• NetworkConveyance

• NetworkNode

• NetworkLink

• NetworkAccessory

These classes are described in chapter 10 in a feature catalogue as well as UML class diagrams.

Requirements class 1: Logical implementation of the Core conceptual model
Identifier	/req/core
Target type	Logical model
Conformance class	Conformance class A.1: /conf/core
Description	A logical model implementation must implement the MUDDI Core conceptual model.
Normative statements	Requirement 1: /req/core/classes-concepts Requirement 2: /req/core/classes-associations Requirement 3: /req/core/classes-attributes Requirement 4: /req/core/concrete-value-types
Guidance	The MUDDI core conceptual models are illustrated in Figure 1 .

Requirement 1: Specification of concepts in the core conceptual models
Identifier	/req/core/classes-concepts
Included in	Requirements class 1: /req/core
Statement	For each UML class defined or referenced in the Core Package, the logical model SHALL contain an element which represents the same concept as that defined for the UML class.

Requirement 2: Specification of associations in the core conceptual models
Identifier	/req/core/classes-associations
Included in	Requirements class 1: /req/core
Statement	For each UML class defined or referenced in the Core Package, the logical model SHALL represent associations with the same source, target, direction, roles, and maximum multiplicities as those of the UML class.

Requirement 3: Specification of attributes in the core conceptual models
Identifier	/req/core/classes-attributes
Included in	Requirements class 1: /req/core
Statement	For each UML class defined or referenced in the Core Package, the logical model SHALL represent the attributes of the UML class including the name, definition, type, and maximum multiplicity.

Requirement 4: Abstract value types in core conceptual models replaced with concrete value types
Identifier	/req/core/concrete-value-types
Included in	Requirements class 1: /req/core
Statement	For each attribute specified with the AbstractValueType value type in a UML class defined or referenced in the Core Package, the logical model SHALL provide a concrete value type for that attribute that replaces the AbstractValueType value type. Note: This is particularly important for the geometry property where a concrete ISO_19107 geometry type needs to be assigned.

9.3.  Requirements for the extended conceptual models

The logical model may decide on which UML classes in the extended conceptual models to implement on an as needed basis.

In the Extended requirements class, there are no mandatory UML classes.

Therefore by default, if the minimum obligation in a relationship to a UML class is zero, then that UML class does not have to be implemented.

Requirements class 2: Logical implementation of extended conceptual models
Identifier	/req/extended
Target type	Logical model
Conformance class	Conformance class A.2: /conf/extended
Description	An implementation of a MUDDI Logical Model may implement any elements of the MUDDI extended Conceptual Model.
Normative statements	Requirement 5: /req/extended/classes-concepts Requirement 6: /req/extended/classes-associations Requirement 7: /req/extended/classes-attributes Requirement 8: /req/extended/concrete-value-types
Guidance	The MUDDI extended conceptual models are illustrated in Figure 2 .

Requirement 5: Specification of concepts in the extended conceptual models
Identifier	/req/extended/classes-concepts
Included in	Requirements class 2: /req/extended
Statement	For each UML class adopted from the Extended Package to be implemented in the logical model, the logical model SHALL contain an element which represents the same concept as that defined for the UML class.

Requirement 6: Specification of associations in the extended conceptual models
Identifier	/req/extended/classes-associations
Included in	Requirements class 2: /req/extended
Statement	For each UML class adopted from the Extended Package to be implemented in the logical model, the logical model SHALL represent associations with the same source, target, direction, roles, and maximum multiplicities as those of the UML class.

Requirement 7: Specification of attributes in the extended conceptual models
Identifier	/req/extended/classes-attributes
Included in	Requirements class 2: /req/extended
Statement	For each UML class adopted from the Extended Package to be implemented in the logical model SHALL represent the attributes of the UML class including the name, definition, type, and maximum multiplicity.

Requirement 8: Abstract value types in the extended conceptual models replaced with concrete value types
Identifier	/req/extended/concrete-value-types
Included in	Requirements class 2: /req/extended
Statement	For each attribute specified with the AbstractValueType value type in a UML class adopted from the Extended Package, the logical model SHALL provide a concrete value type for that attribute that replaces the AbstractValueType value type. Note: This is particularly important for the geometry property where a concrete ISO_19108 geometry type needs to be assigned.

10.1.  Core Conceptual Model package

10.2.  Extended Conceptual Model package