For systems to interoperate, they must integrate. Integration is an activity that can be trivial (the interfaces match!) or challenging (umm… which side is up and what is that?). When integration isn’t straightforward, a component must be used to adapt the systems to one another.
Interoperation is the result. Interoperability is a measure of the degree of interoperation among integrated systems.
“Interoperability is the ability for systems, units, or forces to provide services to and accept services from their systems, units, or forces, and to use those services so exchanged to enable them to operate effectively together.”
– ATIS Telecom Glossary 2000 and Dictionary of Military and Associated Terms. US Department of Defense 2005
Interoperability is “the capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units.”
– ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms
A system of systems is a “set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities.”
– Office of the Under Secretary of Defense (OUSD) 2008
Interoperability as a Requirement
Unlike specific behaviors in functional requirements, criteria that are used to judge the operation of a system are called non-functional requirements (or qualities of the system).
The plan for implementing functional requirements is detailed in the system design, while the plan for implementing non-functional requirements is detailed in the system architecture.
Interoperability is a non-functional requirement. Systems of systems, in particular, require a high level of interoperability – specifically, semantic interoperability.
But to understand semantic interoperability properly, we first need to walk through the different levels of interoperability.
Degrees or Levels of Interoperation
I like to think about non-functional requirements in this way:
Consider a ballet dancer – very flexible, right? That dancer, when she’s doing the splits, exhibits a quality we refer to as flexibility. Depending on how far into the movement she can go, we can say that she is more flexible or less flexible. If you were the director for a ballet company, you could require that all dancers meet a certain flexibility requirement.
Non-functional requirements? They’re the system engineering version of this.
This graphic comes from the Levels of Conceptual Interoperability Model. This model was born out of the modeling and simulation world, where discussion concluded that interoperability wasn’t black or white. Systems could demonstrate different levels of interoperability.
By describing the kinds of characteristics that a system would have at each of these levels, among other things, we have a really great reference point to discuss interoperability in more detail and to specify and/or meet interoperability requirements with a bit more accuracy.
Level 0: No Interoperability
These systems are silos of excellence and stand-alone systems. They demonstrate no capability for interoperation.
Level 1: Technical Interoperability
With respect to the levels of interoperability, after Level 0, a system with no interoperation, there is the ability to technically interoperate.
You move from a Level 0 system (no interoperability) to an Level 1 system (technical interoperability) by establishing a communications infrastructure and unambiguously defining the common network protocols to use.
Why Would You Want to Achieve Technical Interoperability?
By achieving technical interoperability, you enable your systems to exchange bits/bytes via a shared communication infrastructure using some unambiguously defined network protocols.
What Kind of Information Exchange can be Achieved?
When systems can technically interoperate, they exchange bits in an unambiguous manner. Unfortunately, this only guarantees the proper transmission of bits, and that includes zero information about what the bits represent or mean – not even whether they’re video or text.
Example 1: Interfaces are technically matched.
If the solution is designed in – no need for a mediation component because the interface’s technical standards are matched – then technical interoperation can be achieved through straightforward integration, because the systems were designed to technically interoperate.
In this example, 2 doctors are having a conversation. They each communicate via spoken language and can hear what the other one is saying – they can encode and transmit. However, because of the mismatch in language and symbol set, when interoperating with each other, they can only receive unknown sounds/symbols.
Because of the mismatch, they can talk all they want and be heard, but beyond that, not much can be accomplished. This is a great example of achieving technical interoperation, but no further.
With technical interoperability, you can exchange bits/bytes, but you don’t know what they mean, let alone if the structures themselves are valid, as is the case in this example.
Example 2: Interfaces are not technically matched.
If 2 systems are required to technically interoperate, but they don’t have a common communication channel/mechanism and protocol, then the gap must somehow be bridged.
In the current example with 2 doctors conversing, an obvious problem that would prevent technical interoperation would be if one person was deaf and blind, and the other person was speaking.
To bridge the gap, you would have to place something between the 2 doctors to facilitate interoperation, such as a translator, or use another means of communication.
Example 3: Further clarification
When interfaces are not technically compatible, interoperation requires integration via some technical standard. One interface can by changed to interoperate via the specification of the other. Alternatively, both interfaces maybe required to undergo some change so information can be used by both systems properly. If this happens, they can conform to a common standard via some adaptation to their interfaces.
This is commonly seen is between USB drive and a SATA drive. Using a USB interface, I can drive the SATA interface if I’ve placed the SATA drive into a case that allows it to interface to a USB port.
Also consider protocols such as RTPS and AMQP. AMQP is not as flexible and controllable as RTPS; while they are equally understandable protocols, from a user and system implementation standpoint they are not equally manageable. If someone made a choice to use RTPS and another system already specified AMQP, those systems can still technically interoperate.
We can send information/transmissions using any system or device that complies with standards and uses the communications infrastructure, to other systems and devices using compliant infrastructures.
Why Does This Work?
Technical interoperation is something that RTI is pretty successful at; the development, specification, and use of types of standards are the most mature and well understood. Technical standards, such as those that specify the USB interface, are implementable specifications that enable systems to interoperate via spec. While this is important, it is not significant. Interoperability between two or more different technical standards provides more value.
Conclusion and Transition
Technical interoperability meets our requirement for replaceability, and is a start on achieving interchangeability. Thankfully, we have other standards that are used to reach higher levels of interoperability .
Technical interoperability is required to achieve syntactic interoperability (Level 2 interoperability).Next: The Path to Semantic Interoperability (Part 2)