This section describes the architecture of the proposed framework, together with a comprehensive overview of the Common Information Model and data spaces in smart grids.
3.1. Common Information Model—IEC 61970
The Common Information Model (CIM) [
8] is an essential standard that serves as the backbone for the integration and management of information systems in the power system sector. It offers a uniform structure for data representation and exchange, enhancing compatibility and enabling smooth communication across the various segments of power systems. The drive for a standardized information model emerged from the increasing intricacy and heterogeneity of electrical networks. As the energy sector evolved, a plethora of standalone software solutions and devices emerged, leading to isolated data repositories and suboptimal data flow. This fragmentation became a significant hurdle when it came to incorporating new technologies such as renewables, smart grids, and demand response initiatives. Originating from the efforts of the Electric Power Research Institute (EPRI) in the 1990s, the CIM was designed to forge a common language for electrical system representation. It later gained international stature, being refined by the International Electrotechnical Commission (IEC) and the International Organization for Standardization (ISO). The CIM delineates an extensive, flexible schema of data models that articulate the elements and interconnections characteristic of the power system landscape. These models span a broad spectrum, from power production and delivery to market transactions and customer engagement. By unifying the depiction of these elements, the CIM paves the way for different systems and applications to work in concert. A principal benefit of the CIM is its provision of an integrated perspective of the energy network, allowing for a more cohesive and efficient management of a power system.
The CIM harnesses the Unified Modeling Language (UML) [
13] to graphically articulate the structure and behaviour of its system components [
14]. UML’s universally recognized graphical tools offer a suite of diagrams and symbols that deliver a coherent visual representation of the CIM’s constructs. This includes a variety of diagrams such as class, object, and sequence diagrams, each capturing distinct facets of the CIM. Through UML, the CIM’s entities, with their respective attributes and interrelations, are depicted, providing an intelligible and succinct map of the model’s architecture.
Adapting to the dynamic requirements of the power system domain, the CIM has expanded to incorporate modern technological practices, including web services and XML-based data exchange protocols, to maintain relevance and ensure seamless integration with current IT frameworks. A significant stride in this evolution is the FIWARE community’s integration of CIM entities into its data models. This harmonization between the CIM and FIWARE data models is instrumental in enabling efficient data interchange between systems compliant with CIM standards and those developed on the FIWARE architecture, fostering an ecosystem where data circulate freely and efficiently.
3.2. Data Space for Smart Grids
In the face of escalating energy demands driven by economic growth, industrial expansion, and population increases, the quest for sustainable energy solutions has become increasingly critical. Industries such as manufacturing, mining, and transportation, in addition to the development of urban infrastructures, are experiencing a steep climb in energy consumption [
15]. The reliance on fossil fuels to satisfy these needs, however, is a cause for environmental concern, as their combustion emits greenhouse gases, exacerbating global warming and climate change [
16]. Addressing these challenges, the modernization of power grids emerges as a pivotal strategy, transitioning from traditional systems hampered by an ageing infrastructure and a limited renewable integration capacity to smart grids that promise enhanced efficiency, resilience, and renewable compatibility [
17].
The European Commission’s initiative to create common data spaces in the energy sector is a testament to this transition, with smart grids at the forefront, enabling a two-way flow of energy and data that enriches stakeholder insights. Among the supported initiatives, FIWARE is notable for its role in shaping these data spaces through standardized data models and generic enablers, which are instrumental in developing collaborative and smart solutions.
Central to FIWARE’s ecosystem is the Context Broker, a key component that facilitates the creation of digital twins, essential for smart grid monitoring. It allows for the collection and analysis of data, improving grid management through its subscription methods. FIWARE’s architecture also addresses interoperability issues by incorporating IoT agents that act as conduits for data exchange, converting various messaging protocols into a unified FIWARE-compliant format. This harmonization ensures that different devices and systems within the smart grid can communicate effectively. The FIWARE architecture, depicted in
Figure 1, encapsulates the elements and interactions within this ecosystem, as discussed in this section.
3.3. Framework Architecture
The architectural design we propose for our framework is tailored to enhance the surveillance of essential services, particularly focusing on advanced smart grid systems. This design incorporates various elements as illustrated in
Figure 2. Our process starts with the transformation of smart grid data, organized using the CIM, into the NGSI-LD format, a standard designed for interoperability and compliance with the data space view. These data are then relayed to the Context Broker, a digital mirror of the physical grid that oversees the grid’s entities, their relationships, and their data attributes. The Context Broker is equipped with subscription features that notify the system of any changes in the grid’s condition. These notifications are sent to the Kafka message broker, which archives historical data and facilitates interaction with external applications.
Figure 2 also depicts the main technologies that have been used in each module, which will be described in detail in the following paragraph.
From the CIM to the data space. The initial step in the concrete implementation of the proposed architecture involves the critical process of data conversion. Data originating from the field, already modelled following the CIM standard, are transformed for the FIWARE Context Broker. This step is pivotal, not only for aligning with the stringent regulations governing data spaces but also for guaranteeing the uniformity of data across the system. It paves the way for a standardized data model that facilitates seamless integration and interoperability among the diverse array of applications and services deployed within this ecosystem. FIWARE’s suite of data models caters to various sectors, offering specialized solutions tailored to each domain. Pertinently, within the energy domain, we leverage the CIM-compliant data model provided by FIWARE, which we have identified as the most suitable for our case study. The CIM is typically implemented in XML or RDF syntaxes, which are both highly structured file formats. These formats are designed to be comprehensive and extensible, capable of representing the complex relationships and attributes of electrical systems. However, the level of detail and the strict schema adherence required can make CIMs somewhat rigid and cumbersome for rapid integration and real-time data exchange.
On the other hand, the NGSI-LD (Next-Generation Service Interface–Linked Data) model is a modern and context-aware API specification for context information management. It builds upon the legacy of NGSI v2 by incorporating linked data, which enables the data to be fully interoperable and machine-understandable. NGSI-LD uses a JSON-LD format, which is inherently more flexible and web-friendly than the XML/RDF formats typically used with the CIM. This flexibility allows NGSI-LD to support more dynamic and real-time applications, making it well-suited to smart applications that require rapid processing and integration of data from various sources.
The main differences between CIM and NGSI-LD are reported in
Figure 3, and can be summarized as follows:
Syntax and Format: CIM’s XML/RDF formats are document-centric and can be more verbose, whereas NGSI-LD’s JSON-LD format is data-centric, lighter in weight, and more conducive to web transmission.
Flexibility: The CIM is schema-driven and can be less flexible in accommodating changes, whereas NGSI-LD is designed to be more adaptable to the evolving needs of smart applications.
Interoperability: While CIM ensures interoperability within the energy sector, NGSI-LD’s use of linked data principles extends interoperability across different domains and applications.
Real-time Processing: NGSI-LD is optimized for real-time context awareness and processing, which is essential for dynamic environments like smart cities, whereas the CIM’s traditional use cases involve more static data exchanges.
In the context of smart grids, converting CIM-formatted data into NGSI-LD format is a transformative step that aligns the static, heavily modeled data with the dynamic, real-time operational needs of modern energy systems. This conversion facilitates the transition from a traditional grid management approach to a more agile and intelligent smart grid paradigm, where data are not only exchanged but also understood and utilized in a context-aware manner.
Orion DT and Data Management. The construction of the digital twin is facilitated through the FIWARE Orion Context Broker, which serves as the central hub for managing real-time contextual information about the infrastructure. Within this framework, entities are meticulously defined by specified data models and are enriched with detailed interrelationships. The Orion Context Broker operates via a RESTful API, allowing for operations to be executed through standard HTTPS methods.
Table 1 provides a comprehensive summary of the available operations along with their corresponding expected payloads.
Regarding data stewardship, FIWARE incorporates MongoDB, which lays the groundwork for preserving the system’s real-time data integrity. The segregation of real-time and historical data is a strategic approach that enhances the performance and efficiency of data management systems, especially in the context of a digital twin. Real-time data are dynamic and constantly changing, and they require immediate processing to accurately reflect the current state of the physical infrastructure. These data are typically transient and are stored in high-performance databases like MongoDB, which the FIWARE Orion Context Broker uses. Such databases are optimized for speed and low-latency access, ensuring that the digital twin is a real-time representation of the physical counterpart.
Historical data, on the other hand, consist of time-series records of past states and events. These data are invaluable for trend analysis, predictive maintenance, and long-term strategic planning. Storing these data requires a different approach, as the emphasis is on data retention, query flexibility, and cost-effective scalability rather than immediate write and read access. The need to separate real-time data from historical data stems from performance considerations. Real-time data systems prioritize a low latency to ensure that the digital twin is synchronized with the physical infrastructure. In contrast, historical data systems are optimized for cost-effective storage and complex data retrieval operations, which are typically more resource-intensive and can introduce latency if mixed with real-time processing.
By maintaining this separation, organizations can ensure that the performance of the digital twin remains unaffected by the intensive computational demands of historical data analysis.
External Application Interaction. The architecture we propose streamlines the incorporation of external applications by leveraging a uniform data model and the digital twin’s comprehensive representation of the smart grid. In our security-centric approach to safeguarding the smart grid infrastructure, we have adopted OpenSearch, an open-source SIEM (Security Information and Event Management) platform. OpenSearch capitalizes on the standardized data format provided by the digital twin, which is systematically archived within the Kafka broker. This harmonization of data is crucial as it ensures that OpenSearch can efficiently process and analyze information without the need for extensive data normalization procedures. By interfacing directly with the Kafka broker, OpenSearch can access a continuous stream of real-time and historical data, enabling a suite of cybersecurity services that is essential for robust smart grid protection.
As highlighted in
Figure 1, the services facilitated by OpenSearch include:
Event Management: OpenSearch aggregates and manages events across the smart grid, providing a centralized view of all activities. This enables operators to monitor the grid’s operational status and detect anomalies in real time.
Event Correlation: By correlating disparate events, OpenSearch can identify patterns that may indicate complex cyber threats. This correlation is vital for recognizing multi-stage attacks that single events might not reveal.
Incident Reporting: OpenSearch automates the generation of incident reports, which are critical for compliance with regulatory standards and for initiating appropriate response procedures.
Intrusion Detection: Utilizing advanced analytics and pattern recognition, OpenSearch serves as an intrusion detection system, spotting potential security breaches and alerting operators to take pre-emptive measures.
Through the integration of OpenSearch with the digital twin, our architecture not only enhances the security posture of smart grids but also paves the way for advanced analytical capabilities. This integration allows for the proactive management of cybersecurity threats, ensuring the resilience and reliability of energy systems in the face of evolving cyber risks.
Table 2 reports the capabilities of OpenSearch in these activities.