The Theory of Interoperability
Rather like the Internet, the smart grid is a coupled ‘‘system of systems’’ requiring strong coordination across the participating domains and their subsystems. The NIST and SG-CG reference architectural models reflect the need for a disparate number of technologies and functional domains to interoperate effectively. Dif- ferent definitions of interoperability exist but in the context of the smart grid it should incorporate the following characteristics:
• A capability between two or more systems, networks, organizations, applications, components, processes, or devices to exchange meaningful information that is readily usable.
• A shared understanding of the exchanged information.
• An expectation of the response to such information that is agreed upon.
• A requisite quality of service in terms of security, reliability, and fidelity even though the information may be exchanged over different systems, infrastruc- tures, or regions.
The GridWise® Architecture Council (GWAC) was formed by the US DoE to lead on promotion of interoperability between the entities in the USA that make up the smart grid in recognition of interoperability as a key enabler of the smart grid as a whole. The GWAC ‘‘Stack’’ methodology [18] has now been adopted by NIST and the SG-CG as an interoperability reference framework between the different domains and actors in their models. By being integrated into the dominant conceptual reference architectures this interoperability framework has become fundamental to our conceptualization of smart grid interoperability. Although not standardized in itself and modifiable to suit the context, it remains an important reference to what we mean by interoperability. The GridWise® vision acknowl- edges the premise that ICT will revolutionalise the planning and operation of the power grid, just as it has in other business domains (such as healthcare, telecoms, and finance), and that ICT will form the nervous system that integrates smart grid technologies.
The GWAC Stack comprises eight levels in its conceptualization of end-to-end interoperability, ranging from ‘‘Basic Connectivity’’ at the physical level of component interoperability to ‘‘Economic/Regulatory Policy’’ at the organiza- tional level where it incorporates Business Objectives and Procedures. ‘‘End-to- end’’ interoperability is a term used to describe effective interoperability across all levels between its extremities. It is within the Informational layers of ‘‘Business Context’’ and ‘‘Semantic Understanding’’ in the middle of the Stack, that the IEC CIM can be deployed. These layers form the bridge that transfers meaning in the form of syntactic conformity, semantic understanding, and context from the signals arising from the lower technical layers (mainly concerned with physical interop- erability), upwards to the Business Objectives and Policy layers at the top of the Stack. This is of critical importance as it is necessary for the business components involved at each level to share information between themselves and others (as in an enterprise-to-enterprise scope) in order to achieve their tactical and strategic objectives (Fig. 1.) This can only happen if they are working in a sympathetic and federated manner across their boundaries of jurisdiction with full understanding of message content and close conceptual conformance with actual reality.
Any ‘‘standard approach’’ to interoperability must be scalable and be able to recognize agreements established at component interfaces as well as boundaries of jurisdiction. Scaling-up will inevitably encounter hierarchical, organizational, and structural challenges, such as when different business domains interoperate or integrate with an Enterprise Data Model (EDM) because of the use of different
models. In the case of wider manifestation of the smart grid such as with system operation and intersystem operation [19], it will also be necessary to interoperate across enterprise boundaries. A Transmission System Operator (TSO) will have to interoperate with Distribution Network Operators (DNOs), requiring novel infra- structure protecting security, privacy, and service level agreements [20]. Never- theless, from a resilience point of view, the smart grid is also composed of small and in some cases autonomous operations, such as with DER and protection systems management, which could reduce the scope and scaling challenges. Despite the scalability of the smart grid, therefore, many of the processes to establish interoperability will be cross-cutting issues, effective at all levels of scale. Ambrosio and Widergren in [21] discuss many examples of cross-cutting issues including resource identification, time synchronization, security, and pri- vacy that are important to establish interoperability at any level of the smart grid.
Data model exchange within the context of utility information integration is a key part of the interoperable glue between corporate objectives in terms of busi- ness positioning and Power System Application (PSA) solutions that facilitate the enterprise orientating as intended. It is likely therefore that the form of the information architecture will inform the function of the enterprise and raise the question of whether it is fit for purpose [22]. Such an appraisal informs the need for enterprise architecture to be coherent with corporate objectives and regulatory constraints. Connecting this concept to the ‘‘solutions level’’ (levels 1–4 in the GWAC Stack) of the enterprise, especially in times of rapid market change, places greater emphasis upon information integration and the removal of legacy system obstacles such as data silos and manual trans-literation interfaces between bespoke systems.
Tolk has addressed these concerns in his Levels of Conceptual Interoperability Model (LCIM), and observed that the ‘‘conceptual ideas of the enterprise and the implementation details of the systems’’ often do not connect [23]. This may be due to inappropriate architectural design but also that the interoperability of legacy systems within a complex multisystem architecture cannot always be decidable in
advance. Examples of undecidable problems (there is no algorithmic solution but a result relies upon a good heuristic) include questions such as, ‘‘Is the specification complete or minimal?’’ ‘‘Is the order of two modeled actions independent or requiring orchestration?’’ In [23] Tolk proposes that the utility of enterprise architecture to fully support interoperability develops through three broad stages.
• Integratability—concerns physical and technical connectivity of systems, including hardware, networks, firmware, and protocols.
• Interoperability—concerns software and firmware to support information
exchange through the use of common semantic models.
• Composabililty—concerns the alignment of the use of models as conceptual abstractions of reality for given business intentions.
The LCIM was created to present these related issues in a consistent framework that exposed six levels of interoperability, ranging from ‘‘Technical’’ to ‘‘Con- ceptual’’ Interoperability. These levels rise from the physical concern of infrastructure communications to the more abstract concern of the interoperability composition in meeting the objectives it was conceived for. At the center of this hierarchy we find ‘‘Semantic Interoperability’’ linking the ‘‘Syntactic’’ level to the ‘‘Pragmatic’’ interoperability level. The Syntactic level deals with protocol chal- lenges while the Pragmatic level deals challenges of interpreting message patterns. The LCIM was adopted and informed the creation of the GWAC Stack framework, underpinning the centrality of the IEC CIM and the importance of ICT interop- erability to smart grid control and integrity as it infuses all levels of the energy domain.
System architectures are developed to fill the gaps in enterprise capabilities.
The architecture should map to the detail of the functional requirements but in a rapidly developing environment like the smart grid where there is added pressure to evolve the enterprise alongside multiple independent stakeholder interventions, the risk of Conceptual Interoperability intentions misaligning with actual inter- operability outcomes are high. Tolk identifies some major practical challenges to maintaining interoperability in alignment with the overall conceptual design:
• Interoperability satisfies the needs of a limited number of stakeholders due to independent interventions and becomes unaligned with enterprise interopera- bility concepts.
• The implementation suffers from not being maintained in step with the latest developments.
• The diversity of smart grid developers, regulators, implementers, and other
actors are not as aligned as desirable.
• Interventions of one kind have negative secondary impacts on other systems.
These are familiar concerns to system integrators within electricity utilities involved in developing greater interoperability at PSA and enterprise levels. They are especially likely to develop in situations without hierarchical supervision and coordination of stakeholder interventions and where insufficient attention is paid to
cross-cutting challenges. The fourth issue is particularly relevant to the topic of resource identification. Where multiple independent actors who share a common domain exist, the opportunity for the same network entity or resource (such as a power transformer, substation, circuit breaker, or process) to be identified differ- ently is very real. Within a single actors’ model of the network, this may not give rise to ambiguity but when models are exchanged and shared with other actors the issue of resource identity can cause conflicts in semantic understanding and disrupt interoperability. It is a vexing challenge to the application of a common infor- mation model across multiple PSAs and business domains where there are multiple uncoordinated points of data entry.
Systems Engineering Interoperability
Rather like the Internet, the smart grid is a coupled ‘‘system of systems’’ requiring strong coordination across the participating domains and their sub-systems. Taking a systems engineering approach at the PSA-to-PSA level, the use of metadata is important in assessing the possibility for, and then supporting interoperability. Between two PSAs with a common operational intention there would be the need for three sets of metadata, one set describing each PSA and the third describing the design for the desired functionality. It is then possible for an assessment of composable interoperation between heterogeneous PSAs to be made, subject to the decidability of the interoperability outcome as previously discussed. Ralyté et al. say that due to the complexity of the interoperability challenge across multiple domains, including business and technology, it is not possible to find a solution to the decidability problem captured by a single method. They discuss a Situational Method Engineering (SME) approach to interoperability problems that involves modularized reusable method chunks to compose situation-specific interoperability solutions as they arise [24]. Hug et al. [25] support this view from an information systems engineering perspective and say even the use of standardized metamodels may reveal the limitations of a ‘‘one-size fits all approach’’ in future. This could mean, as the use and understanding of metamodels becomes more widely appre- ciated, we see the need for more situational metamodel engineering (SMME) to underpin process interoperability in the power industry. Such a Model Driven Engineering (MDE) approach would employ the key principles of a standardized method to building the metamodel appropriate to the situation, and a general trend toward the use of higher levels of abstraction.
Similarly, this has already started to happen within the power industry through developments involving the IEC CIM as a domain ontology [26]. For example, in [27], Britton and deVos recognize, ‘‘The trouble with a global information model is precisely that global is a pretty big area to manage.’’ They see the value in the CIM moving from an ‘‘explicit interface specification role to a design methodol- ogy role’’ and the possibility for it to underpin a service-oriented architecture (SOA). SOA is a software model in which the concept of a service is an abstraction
of a function used by an application [28]. Services either provide information, or change data from one state to another. A service is a function that may be reusable within a business process [29]. Once these functional components of the business process have been identified and related to a semantic model, it becomes possible to model them into an efficient structure, such as to emphasize the value of service reusability, interoperability, and open-availability of data. In this way modeling can be used to drive better understanding of business processes and further their integration within the enterprise.
Interoperability and Service-Oriented Architecture
SOA can therefore further the scope of interoperability through closer integration of Business Process Management (BPM) to reusable information message exchanges that call for different service operations. Such an approach is summa- rized by Soley in [30], where he sees BPM design being linked to SOA infra- structure by the ‘‘vital bridge’’ of Model Driven Architecture (MDA). MDA is underpinned by the use of metadata standards to adapt business process models to service requirements in a changing environment such as the smart grid. MDA, itself based on the principles of Model Driven Design (MDD) [31] can also aid in the recovery of design knowledge from existing applications through its use of standards. This approach has been adopted by McMorran et al. to develop trans- formation applications for CIM-structured metadata files to the Siemens Power System Simulation (PSS/E) standard for model exchanges supporting PSA–PSA interoperability [32, 33].
Another important aspect of SOA is that it opens the way for data to be shared across an enterprise by way of a web service. Web Services Description Language (WSDL) is a commonly supported means of describing the necessary interactions between a service requester and a service provider. It rests as a separate layer upon the data architecture of the enterprise, independent of the code required to implement the service but offering the potential to develop common interfaces for various types of interactions, which leverage the value of software assets as well as data resources. As this web-based approach also opens the number of data access points, security becomes a greater consideration to protect the integrity of pro- prietary data and system functionality.
In this way, SOA enables a looser connection to the service provider technology and enhances the scope to offer vendor-neutral solutions. In [34] Cao et al. also propose the use of the CIM within an SOA to address information-islanding problems encountered within Enterprise Application Integration (EAI) challenges. Khare et al. [35] develop this theme, describing the use of an Enterprise Service Bus (ESB) within the SOA to ‘‘simplify and manage interconnectedness.’’ They also describe the use of metadata within ‘‘design patterns’’ to support interoper- ability problem description and contribute to process design for common modeling practices such as CIM extension, profiling, and model validation.
Announcement and discovery of metadata underpins the ability to access and leverage the available data and services in an interoperable infrastructure. Rohjans et al. [36] propose a SOA based on the Open Platform for Communications (OPC) Unified Architecture (UA), a standardized server-client architecture specification (see IEC 62451) that embraces security, platform independence, and information models to support interoperability. Their approach brings together a general automation industry SOA solution (OPC UA) for access to real time and historical data and events, to run semantic web services that interact with the Platform Independent Model (PIM) provided by the CIM. Service descriptions are provided by metadata annotations derived from Web Service Modeling Language (WSML) ontology.
Interoperability and CIM
Neumann and Nielsen in [37] refer to profiles, or context-constrained sets of CIM classes that make up the Common Power System Model (CPSM) and the Common Distribution Power System Model (CDPSM) [38, 39]. These ‘‘sub-models’’ of the CIM are accredited standards in themselves and like other available profiles address ‘‘common integration patterns’’ within interoperability challenges and therefore resemble the approach to situational interoperability advocated above. The earliest releases of the IEC CIM were designed to only support interopera- bility of control center applications [40, 41]. As packages of classes are now added to it that refer to the operation of more diverse aspects of the smart grid, it is conceivable that ‘‘method chunks’’ of the reference metamodel could be applied to interoperability challenges yet to come. Effort is also being made on the harmo- nization of adjacent standards, such as IEC 61970 with IEC 61850 [42, 43] and IEC 60870 [44] in the interest of extending interoperability across different con- ceptual metamodels. The power of standards-based metadata at all levels of interoperability described in the LCIM then becomes evident, subject to the lim- itations of one-size-fits-all, in supporting composable solutions appropriate to the capability-requirement gaps within the enterprise architecture.
Metadata plays a key role in the absence of a fully self-organizing system of systems, in which operational systems have built-in evidence of their components’ functionality, necessary for their level of interoperability to be evident to the other interoperating parties. We may currently approach this level of self-evidence by exploiting the built-in rules in Resource Description Framework (RDF) and Extensible Markup Language (XML) notation in ‘‘knowledge representation’’ [45, 46] but these form only the surface of interactions between our enterprise com- ponent systems at present. Deeper evidence of the capacity for interoperability in future could be evinced from meaning encoded into the structure of the metadata, thus raising the attraction of standard forms of metadata as in the cases of the IEC Common Information Model standards. The intention of building this kind of ‘‘structural intelligence’’ into our metadata models would be to make it possible to see some degree of self-organization (perhaps similar to biological systems) at the interface between interoperating entities. This degree of interoperability could then extend the current aim of ‘‘self-description’’ and ‘‘self-discovery’’ for advanced distribution automation systems for example.