Y.MIM Overview
The following is an excerpt of the current Draft Recommendation ITU-T Y.MIM (May 2024) and includes the sections on
Concept and role of Minimal Interoperability Mechanisms
Required characteristics of a MIM
MIMs Structure
Minimal Interoperability Mechanisms for Smart and Sustainable Cities and Communities
Concept and role of Minimal Interoperability Mechanisms
Definition and Concept
The Minimal Interoperability Mechanisms (MIMs) are designed to support cities and communities become smarter, although they may have a wider relevance.
A smart city or community is one in which there is an effective integration of physical, digital, and human systems in the built environment to deliver a sustainable, prosperous and inclusive future for its citizens [b-ISO/IEC 30182]. To achieve this, it is necessary to be able to gather and share large amounts of data from the different systems, such as transport, energy, health and so on, that serve that city or community. This data is collected and managed by a range of different agencies within the city that may each have different ways of handling the data. It is therefore important to identify processes to support at least a minimal level of interoperability between these different ways of collecting and handling the data to make it easier for it to be shared and reused.
This is where the MIMs can have a key role.
A MIM specifies a set of requirements that any mechanism, or set of technical solutions, needs to address to provide a minimal but sufficient set of capabilities needed to achieve a certain city or community objective. The MIM documentation also provides informative content describing Mechanisms and technical solutions to individual requirements already commonly used in cities and communities to address that set of capabilities, along with guidance on methods to achieve relevant interoperability between those different mechanisms and technical solutions and on conformance and compliance testing. It may also provide informative content as to procurement and other relevant issues.
Minimal is used to describe something that can meet a specific objective with no unnecessary complexity. It is used in two senses.
To refer to a minimal but sufficient set of capabilities and the functional and quality requirements needed to achieve them that will enable a basic implementation of what is needed to achieve a city objective.
To refer to achieving a minimal but useful level of interoperability between two different mechanisms that offer alternative methods to provide a city or community with the capabilities to achieve the same objective.
Identifying a minimal but sufficient set of capabilities to achieve an objective is important because to achieve an objective completely might demand many different capabilities, requiring the expenditure of significant time and resource. However, implementing a much smaller set of capabilities can often enable the key aspects of an objective to be achieved quickly and affordably. Further capabilities can then be put in place, as and when they prove appropriate.
By encouraging many cities and communities to implement mechanisms that address the same minimal set of capabilities and the requirements needed to achieve them, this will simplify the work needed to provide interoperability between them.
In addition, because these requirements are often taken from more comprehensive sets of technical solutions, the same basic level of interoperability is also provided with cities and communities that are implementing those technical solutions more fully.
Similarly, achieving minimal interoperability between two mechanisms is important because the achievement of complete interoperability is often complicated and difficult and may require a high level of expertise and time to implement. The development of methods to enable an intermediate level of interoperability between two mechanisms can make it easier for a city or community to integrate any implementation of those mechanisms within its data sharing ecosystem. Figure 1 illustrates the spectrum of levels of interoperability.
Figure 1 depicts 4 different levels of interoperability between two systems, ranging from having no standards and thus requiring completely customised integration to achieve interoperability, to “plug and play” interoperability, where integration between those systems becomes simple and automatic. The challenge with “plug and play” standards is that developing them may take a significant amount of time and resources and may require modifications to the two different systems. MIMs focus on levels of interoperability between these two extremes and two examples are given of how minimal but useful levels of interoperability can be achieved – the identification of Pivotal Points of Interoperability (PPIs) and the development of connectors to link common interfaces. Both can significantly simplify the task of integration between the two systems.
Pivotal Points of Interoperability
One way to help integrate several alternative mechanisms is to identify and use PPIs.
Technical solutions to delivering specific capabilities will normally use existing concepts, standards, and specifications. For instance, solutions addressing different aspects of internet-based services are likely to use common standards such as http. Where several alternative solutions to delivering the same set of capabilities use the same concepts, standards and specifications, or ones where there are simple methods to covert between them, these can form PPIs [b- IES-CF] that can be used to simplify the effort needed to integrate them.
One example of PPIs is where mechanisms use different identification schemes. There are two common identification schemes: Uniform Resource Identifiers (URIs) and Digital Object Identifiers (DOIs). So, there may be one mechanism that uses DOIs as identifiers and another that uses URIs.
The use of DOIs and URIs can become a PPI to support the integration of two different mechanisms because DOIs can be turned into URIs by setting up a “resolver” service, which can generate URIs for each DOIs.
Figure 2 shows two different technical solutions, indicated by the green and blue lines, to address a common requirement. These two solutions may be very different from each other and thus it might seem difficult to align them. However, if any concepts, standards, or specifications can be identified that are used by both solutions, then these can help make alignment easier. The figure illustrates two possible PPIs – the common use of REST APIs and the use of DOIs by one solution that can easily be converted to URIs as used by the other solution.
Connectors
Another way to help integrate several alternative mechanisms is to develop common connectors that can be used by each of them.
Normally, any mechanism will need to interact/communicate with other systems in order to fulfil the capabilities needed to meet the overall objective. For example, a city administration may set up a local data sharing ecosystem involving a number of data sources and data-using services. These different data sources and data-using services may use different standards and other technical solutions to handle the data they manage or use. If the data-using services require access to specific data sets/streams held by different data sources, then they need to be able to communicate and interact with each of them. Given that each of them may use different mechanisms to handle the data, access to that data may potentially require separate APIs to be developed to enable and manage the interaction of each data-using service with each data source.
This clearly greatly increases the complexity of integrating the data between the different agencies in the data sharing ecosystem.
However, given that interaction and communication between these different data sources and data using services is a common requirement, it is possible to develop a connector to serve as a common method for those mechanisms to interact and communicate.
In this instance, the connector would be an easily configurable proxy service that uses a common API and can adapt to the technical interfaces and protocols of the different data sources and data using services.
Work will still be needed to align the data being shared within the different mechanisms to enable the different data sets to be combined in useful ways, but the use of a common connector removes a significant amount of complexity. In this way, their level of interoperability is improved, thus making integration between them significantly easier.
In general, by identifying the common interfaces a set of alternative mechanisms that address the same set of requirements use to connect to the wider systems to which they contribute, a common connector to such an interface can be developed that can be used by each of those mechanisms.
Value and role
Interoperability is a key issue for any city and community, both within, and between different community stakeholders to enable data and services to work together and support a scalable and open market of solutions.
To address this, Standards Development Organisations are developing many comprehensive and detailed sets of requirements to help cities and communities in their journey to become smart and sustainable. These may describe detailed requirements - the precise actions and processes that need to be put in place to achieve certain capabilities, or they may describe technical specifications that provide solutions for how those requirements can be implemented.
However, several challenges need to be addressed:
Cities and communities are not monolithic organisations, but consist of many autonomous or semi-autonomous agencies, both public and private, that together provide the services that enable the city to function for the benefit of the citizen. It is difficult, if not impossible, to ensure that all agencies in a city follow identical processes and standards.
Cities and communities also are managed independently of each other and largely make decisions about how they function based on their own needs and background.
There are many Standards Development Organisations, each building families of standards from different viewpoints, and these standards are not always compatible with each other.
Many cities and communities and their stakeholder organisations have contracts with technology companies that may require the use of proprietary solutions.
Finally, the very detail and complexity of standards may deter smaller cities and communities or those with limited resources from attempting standards implementation.
There is therefore value in an intermediate approach to interoperability; the MIMs. These focus on the core requirements of standards and thus provide a simple but solid starting place for standards implementation. They also address the variety of technical approaches followed by different sets of standards and proprietary solutions and provide methodologies to help align these as far as practical. In this way, cities and communities can put in place “good enough” mechanisms to get them started in gaining value from potential smart solutions and that take into account differing types of legacy infrastructure and standards ecosystems.
The role of MIMs for different stakeholders
By providing a cost effective and practical way to enable cities and communities and their service providers to start to implement common solutions and approaches, the MIMs benefit many different stakeholders. The MIMs are therefore need to be designed to provide them with different but complementary roles for a variety of stakeholders to enable them to take appropriate decisions and actions.
Regional and national policy makers need to understand the role of the MIMs as a whole, and individual MIMs in particular, in establishing interoperability on a regional or national level.
Smart city or community ICT leadership need the MIMs to help them review the options available to them for mechanisms that will deliver the capabilities required.
IT professionals need the MIMs to help them find the standards and good practice that will address the requirements and how to bring them together to build a package of workable solutions.
Companies need the MIMs to specify the functional and quality requirements that their products and services need to comply with to address the opportunities of the scalable markets that the MIMs will enable.
Procurement managers need the MIMs to help them know how to word procurement documentation to ensure that what suppliers offer will comply with the requirements agreed on and know how that compliance can be tested.
Not all these audiences can be directly addressed by the MIMs themselves, but agencies developing MIMs should ensure that appropriate documentation and guidelines with practical examples and use cases are provided alongside the MIMs to ensure that the right decisions and actions can be made at all levels.
The role of the MIMs in domain specific data sharing ecosystems
The MIMs are designed to support data sharing ecosystems within and between smart cities and communities. They are therefore also applicable to data sharing ecosystems within individual domains within a community such as energy, mobility, and health.
This is because:
Domain specific data sharing ecosystems like city or community data sharing ecosystems, are made up of many organisations at different levels of maturity in handling data and following differing sets of standards and approaches. Setting minimal levels of interoperability is therefore a practical necessity to make data sharing feasible and MIMs that work for the greater complexity of data sharing within all the domains of a city/community will clearly also work well within individual domains.
Cities and communities need to draw on data from domain specific data sharing ecosystems in order to gain a comprehensive picture of what is happening in the city. This would be made much easier if those separate data sharing ecosystems comply with the MIMs.
Different domain specific data sharing ecosystems need to be able to share data between themselves. For instance, energy and mobility data ecosystems need to be able to share data to enable better management of the supply to electric vehicles. This is clearly easier if both ecosystems use the same MIMs.
Required characteristics of a MIM
To ensure that a MIM achieves the above purposes, it should comply with the following requirements.
It is required that a MIM be developed in response to a need identified by cities and communities to help them become smarter and more sustainable, to ensure it addresses genuine requirements.
It is required that a MIM be implementable by a very wide selection of cities and communities, particularly those with limited resources and expertise. Well-resourced cities and communities are already served by the work of formal Standards Development Organisations. MIMs are intended to provide all cities with a common way forward.
It is required that a MIM provides the minimal but sufficient requirements needed to achieve interoperability across multiple governance levels.
It is required that a MIM be based on an inclusive list of baselines and references so that they can take account of the different backgrounds of cities and communities and allow cities to achieve interoperability.
It is required that a MIM be simple, open, vendor neutral and technology agnostic, enabling anybody to use them and integrate them in and between existing systems and offerings, complementing existing standards and technologies.
It is required that a MIM be designed to allow compliance to be testable. In this way industry will have the clarity needed to develop the appropriate products and services and cities and communities, along with organisations delivering city services, will be able to specify MIMs compliance in procurement processes.
It is required that a MIM be specified using the common template described here, to facilitate understanding of the value of this approach and the interworking of different MIMs.
It is required that a MIM enables flexibility regarding implementation if PPIs in any given technical architecture use the same interoperability mechanisms. The PPIs should assure the replicability of the technical solutions as these are decoupled from the specific technological implementations and deployments.
In addition, a MIM may define a hierarchy of levels of interoperability based on sectorial needs or the need for tighter integration.
MIMs Structure
Overview
The documentation for any particular MIM is required to cover the following content:
Objective
Capabilities
Requirements
Mechanisms
Interoperability guidance
Conformance and compliance testing
In addition, MIM documentation may include informative content regarding:
Relevance to public policy
Procurement guidelines
Implementation guidelines
Objective
The first section of any MIM is a short description of the desired outcome of the implementation of a particular MIM.
The objective forms the scope of that particular MIM.
This should provide the basis to make the case for implementing that MIM to the key decision makers in the city and to regional and national policy makers.
Capabilities
The capabilities section provides a short description of the core set of business requirements needed within a MIM to enable the objective to be achieved to a good enough extent. These will normally be listed as bullet points or as a set of short paragraphs each pointing to a particular capability.
This section will also help make the case to the key decision and policy makers.
Requirements
This is the key section of the MIM, where the functional and quality requirements needed to achieve the capabilities described in a MIM are listed. These should be clear and specific enough to enable compliance with the MIM to be tested. As mentioned under capabilities, it may be helpful for the Requirements section to be merged with the capabilities section and have both shown together in a table.
An option is for this section to be merged with the capability section to form a table in which the capabilities are listed alongside the requirements derived from each capability. This format is illustrated in Appendix I.
The requirements section is focused on providing necessary information to the staff responsible for applying the MIMs and to those responsible for procuring MIMs-compliant solutions.
Mechanisms
The mechanisms section describes how each of one or more alternate sets of tried and tested technical solutions can deliver the functional and quality requirements covered in the MIM. These may be taken from technical specifications, formal standards documentation or may be drawn from emerging or de facto standards.
Should there be no commonly used mechanisms to address the full set of requirements, then this section may describe technical solutions that can address each of the requirements separately.
To demonstrate how a particular mechanism addresses the set of requirements, that mechanism may be shown in a table alongside the list of requirements.
This section is useful for technical experts in the implementation team and to companies developing MIMs-compliant products and services.
Interoperability guidance
This section provides a description of methods that can enable as good as possible a level of interoperability between the different mechanisms or individual technical solutions that meet the requirements covered in that MIM. This may include the identification of PPIs and connectors and guidance as to how these can be used to support integration between the different mechanisms within a data ecosystem.
This section supports those staff responsible for integrating different technical solutions within a city or community and helps product and solution providers to design their offerings to address those different approaches.
Conformance and compliance testing
This section provides a description of how to test conformance to, and compliance with, the MIM.
This section supports the delivery implementation team by enabling them to be sure that their implementation conforms to the MIM, industry by enabling them to demonstrate that their products and services comply with the MIMs, and procurement officers by showing how they can check that the proposals they are assessing are MIMs compliant.
Optional additional sections
This section may provide informative guidance regarding relevance to Public Policy, and regarding procurement and implementation. These will not be formally part of the MIM but would be designed to facilitate its implementation. They may be attached to the MIM as an annex or may be provided as separate and more detailed documentation.
Logical order of the core sections of the MIM
There is a logical order to each of the sections in the MIM structure and this is indicated in Figure 3.
The Objective describes what the MIM should achieve. Once this is agreed, a minimal set of business requirements is derived from this that will enable the objective to be achieved and this forms the capabilities section. The next stage is to identify the functional and quality requirements that are needed to provide that minimal set of capabilities, and this forms the requirements section, which is the heart of the MIM.
Mechanisms or individual technical solutions that are already in use by cities and communities that address the set of requirements are then identified, and the description of how each of these do this forms the mechanisms section.
The information provided in the mechanisms section can then be used to identify any PPIs and common interfaces for which connectors can be developed and these are described in the Interoperability Guidance section.
The final required section of the MIM describes methods to test how far each mechanism can address each of the Requirements and this forms the Conformance and Compliance Testing section.
