D2 - Cybersecurity In the Loop for multi energy infrastructures

Summary

The energy infrastructures are evolving towards multi-energy systems where different energy vectors (e.g. electricity, heat, gas) cooperate to guarantee efficient and sustainable energy services. The project MISSION – “Multivector Integrated Smart Systems and Intelligent microgrids for accelerating the energy transition”, within the MISSION Innovation Smart Grid program, aims to study, explore and test the potential and role of multi-vector and smart energy microgrids in supporting the energy transition. The two multi energy RSE Test Facility sites at Milano and Piacenza campus are used to test the project developments. The Smart Grids are extended to aggregate Distributed Energy Resources (DERs) sites also in wide geographical areas and to provide ancillary services to the system and improve the use of the different energy vectors, including renewable energy resources with possible not programmable energy sources. The digitalization plays a crucial role in the development of these infrastructures where new communication, monitoring and control functionalities are required. The resilience of advanced cyber-physical control systems for multi-vector energy networks strictly depends on the ability of the ICT infrastructure to prevent and manage in real time the effects of cybersecurity threats affecting communications and components. The availability of cyber-physical infrastructures for the validation in the field of technical cybersecurity measures effectiveness is a fundamental element for the technological development required by the energy transition. In this paper we present the design of the demonstrator CIL - Cybersecurity In the Loop which aims to exploit the best cybersecurity technologies available in control devices to the digital architectures of the RSE test facilities (TF). Both preventive and defensive cybersecurity measures are included in the CIL architecture by design, through the implementation of data encryption and communication authentication supported by a PKI (Public Key Infrastructure), as well as defensive measures required to mitigate residual risks due to threats not covered by preventive measures and based on ICT monitoring and anomaly detection functions. The paper describes the selection of the security measures that can be implemented in the infrastructures highlighting the main hardware and software components supporting the CIL cybersecurity functionalities. The extended architecture design with preventive and defensive cybersecurity measures is then illustrated and the main solutions explained. Concerning preventive measures, the paper focuses on TF devices supporting IEC 61850 communications secured by IEC 62351 profiles. Moreover, the design addresses the functions and the architecture of a Public Key Infrastructure in charge of the key and certificate lifecycle management. For the defensive security, the paper presents a platform for collecting information and events relevant to cybersecurity and the implementation of a centralized SIEM (Security Information and Event Management) system for RSE test facilities. The SIEM system is equipped with advanced security monitoring functions, detection of cyber anomalies through the application of Artificial Intelligence and Machine Learning techniques and the management of cybersecurity incidents. The CIL demonstrator will allow to test and validate the resilience capabilities of the ICT secured infrastructure through the simulation of attack processes to facility devices with reference to selected operational scenarios of the RSE test facilities.

1. Cyber Security in the loop

The resilience of advanced cyber-physical control systems for multi-vector energy grids essentially depends on the ability of the digital infrastructure to neutralize and manage in real time the effects of cybersecurity threats that afflict IT/OT technologies. The availability of cyber-physical infrastructures for the "in-field" validation of the effectiveness of technical cybersecurity measures constitutes a fundamental step in the technological development required by the energy transition. In this paper we present the design of the demonstrator CIL - Cybersecurity In the Loop that aims to deploy the best cybersecurity technologies available in control devices to the digital architectures of the RSE test facilities (TF) located in Milan and Piacenza. The inspiring idea of the CIL demonstrator is to equip the RSE TFs with an environment for the field validation of resilience functions to cybersecurity attacks. The TFs, being made up of digitalized energy resources and processing and communication systems, are characterized as cyber-physical infrastructures (smart micro grids) subject to cybersecurity threats. The phrase “Cybersecurity In the Loop” refers to a cyber-physical technological environment that allows testing the behaviour of energy control schemes with/without cybersecurity measures enabled in the control loop, in presence /absence of cyber attacks (Figure 1 (sx)). In functional terms, the CIL demonstrator provides a real-time execution environment for experimenting, in an "in vitro" energy service, the effects of cybersecurity attacks on cyber-physical systems and the effectiveness of cybersecurity measures.

To protect/defend the cyber-physical infrastructures from multiple types of cyber threats, potentially originating from the internal and external communication networks of the test facilities, the CIL demonstrator adopts a "security by design" approach according to which the cyber-physical infrastructures integrate security measures into network architectures and communication applications. Specifically, the CIL demonstrator includes:

• the protection of the OT protocols used by energy resource monitoring and control applications through cryptographic algorithms suitable for power system operation;
• the use of an infrastructure providing key and certificate management services (PKI in Figure 1 (dx));
• the detection of anomalies in the TF data flows through a security management infrastructure (SIEM in Figure 1 (dx)).

The CIL architecture design is illustrated in Figure 2. The next sections of the paper detail its preventive and defensive cybersecurity measures and their corresponding solutions.

2. Preventive cybersecurity measures

Concerning preventive measures, CIL focuses on TF devices supporting IEC 61850 communications secured by IEC 62351 profiles. The IEC 62351 suite of standards [3] is the reference for securing communications within the electrical sector. It offers technical solutions and guidelines aimed at ensuring the cybersecurity of networks and control systems utilized in the industry, thereby preserving the reliability and integrity of the electrical system.

Among the most effective solutions for communication security, not only within the electrical domain but across various sectors, is the Transport Layer Security (TLS) protocol. TLS boasts a rich history within the realm of Internet security protocols. Its origins stem from the Secure Sockets Layer (SSL) protocol, developed by Netscape Communications in the 1990s. Over the years, SSL underwent multiple revisions, addressing security vulnerabilities in a young and evolving tool. In 1999, SSL 3.0 was standardized as TLS 1.0 by the Internet Engineering Task Force (IETF), overseeing the protocol development and management. TLS 1.0 significantly enhanced security and reliability compared to earlier versions of SSL. Subsequently, new iterations of TLS were released to tackle emerging security challenges and enhance performance. TLS 1.1 was introduced in 2006, followed by TLS 1.2 in 2008. The latter version introduced more robust cryptographic algorithms and addressed identified weaknesses. More recently, TLS 1.3 was standardized in 2018. This version brought substantial improvements in security and performance. TLS 1.3 streamlined the connection negotiation process and eliminated older, less secure encryption algorithms. Presently, TLS stands as one of the most widely adopted protocols for securing communications over the Internet. It is utilized to safeguard a broad spectrum of applications. The adoption of TLS has significantly contributed to ensuring privacy and protecting sensitive data exchanged between entities across public or private networks. One of TLS's key strengths, which has contributed to its success and widespread adoption, lies in its adaptability to new technologies and next-generation devices.

IEC 62351-3 specifies how to provide confidentiality, integrity, and authentication for telecontrol protocols utilizing TCP/IP as the transport layer for information. This may encompass SCADA (Supervisory Control and Data Acquisition) and telecontrol protocols, as well as other protocols used for diverse or ancillary purposes. IEC has assessed that TLS is applicable to modern electrical devices, enabling the implementation of robust security measures without the need for significant changes to the TLS protocol itself. IEC's profiling primarily involves selecting parameters within the operational ranges offered by TLS. This simplifies implementation and promotes the adoption of TLS as an integral component of security solutions in the electrical sector. IEC 62351-3 provides a detailed specification regarding the TLS functionalities that devices must support, imposing constraints on device behaviour and the utilization of TLS algorithms, ensuring adequate communication security. This includes allowed TLS versions, appropriate cryptographic algorithms, and devices behaviour during the telecontrol session and at the occurrence of specific events. The specification focuses on the TLS 1.2 as the mandatory protocol version to be supported by devices and software, while the specification for TLS 1.3 has also been introduced in the recent second edition of the standard to leverage the advances of latest TLS version.

IEC 62351-3 also defines security events for specific conditions which the device should detect and notify, to support error management, security control logs, intrusion detection, and compliance testing. A telecontrol session typically involves the interaction between a controlling station (i.e. a SCADA system) and a controlled Intelligent Electronic Device (IED); for maximum security and interoperability both have to support IEC 62351. Unfortunately, IEC 62351 is not yet widely supported by the products and devices available on the market, but the situation is rapidly changing in consequence of the raising awareness of the impact of cyberattacks and the normative requirements introduced by national regulations. For RSE TF a survey was conducted to identify products with proper IEC 62351 support.
The SCADA system that was selected benefits from the participation by the developers in IEC 62351 standardization committees, enabling quicker product updates to meet new specifications. The product is designed considering the needs of the energy sector, and is well-suited for applications in energy generation, transmission, and distribution, automating control of power substations, renewable generation, and storage management. The SCADA product was chosen due to its TLS support. Table 1 summarizes the most relevant configuration parameters supported by the software tool.

Regarding the controlled device side, the opportunity was seized to integrate in the RSE TF a Plant Central Controller, or Controllore Centrale di Impianto (CCI), recently introduced by the Italian regulation in compliance with the Norm CEI (Comitato Elettrotecnico Italiano) 0-16 [1]. The primary tasks of the CCI include:

• coordinating the operation of various components within the system to ensure that the system itself operates to meet the Distribution System Operator (DSO) requirements at the point of connection with the power grid, as well as the needs of other operators, such as aggregators and plant owner;
• gathering relevant information about the energy infrastructure to ensure the network observability and transmitting it to the DSO through standard and secure communications.

In the context of energy microgrids telecontrol, the CCI device is adequate as the Annex T of CEI 0-16 outlines cybersecurity requirements directly derived from those of IEC 62351, including specifications for the TLS protocol. Therefore, it becomes possible to establish secure telecontrol sessions via the IEC 61850/MMS protocol [2] with TLS protection on the SCADA-CCI segment in Figure 3, thereby reducing the attack surface exposed to malicious entities, in alignment with the security by design principle. To meet the needs relating to the time synchronization of the communications, a powerful synch server installed at the PCS-ResTest Laboratory is deployed, capable of distributing the standard PTP (Precision Time Protocol) [4] synchronization information within the RSE TF networks and supporting the NTP (Network Time Protocol) service to the CCI device. For maximum precision, the synch server acquires the time reference from the Global Navigation Satellite System (GNSS) constellations via a dedicated external antenna.

Public Key Infrastructure

The CIL design addresses the functions and the architecture of a Public Key Infrastructure (PKI) providing the services for the key and certificate lifecycle management. A PKI is a security framework that manages the creation, distribution, storage, and revocation of cryptographic keys and their associated digital certificates. Digital certificates are collections of information that bind relevant details associated with an individual subject or entity (e.g., an individual, an organization, or a device) to a public cryptographic key. Public key cryptography offers several advantages over traditional symmetric key cryptography, which uses a single key for encrypting and decrypting data, including:

• secure information exchange: in public key cryptography, two parties can securely communicate even without previously sharing a secret key. One party can use the other party's public key to encrypt data and securely transmit it; only the recipient, possessing the corresponding private key, can decrypt it;
• authentication and digital signatures: public key cryptography enables the authentication of digital identities (in combination with digital certificates) and the digital signing of information. A party can use its private key to digitally sign data, creating a unique digital signature. The digital signature can then be verified by anyone using the corresponding public key, ensuring the authenticity and the integrity of the information received.

PKIs provide a mechanism to ensure the reliability of certificates and the authenticity of public keys. This is achieved using certification entities, more commonly known as Certification Authorities (CAs), which issue digital certificates after verifying the applicant's identity. The issuance of digital certificates is governed by established procedures that can ideally be attributed to three distinct authorities (Figure 4), whose distinction arises not from an actual physical separation but mostly from temporal separation:

• pre-issuance activities for a digital certificate primarily involve the Registration Authority (RA);
• activities concurrent with the issuance of a digital certificate primarily involve the CA;
• lifecycle management activities of the digital certificate primarily involve the Validation Authority (VA), with contributions from the CA as appropriate.

The RA is an entity that collaborates with the CA to facilitate the issuance process of digital certificates. The primary activities of an RA include:

• information collection: the RA gathers pertinent information from digital certificate applicants. These details may encompass personal information such as name, address, identification number, organizational affiliation, etc. The RA might request documents or proof of identity to verify the applicant's identity;
• information verification: the RA verifies the collected information from the applicant to ensure its accuracy and correctness. This process might involve cross-referencing provided documents, checking databases, or consulting reliable sources to confirm the submitted information;
• request forwarding: after collecting and verifying information, the RA forwards certificate requests to the CA for the actual issuance of digital certificates.

The RA plays a crucial role in the digital certificate registration process, serving as an interface between certificate applicants and the CA. The RA's objective is to ensure that the registration process is accurate, secure, and compliant with the certification policies established by the CA. The most relevant tasks of the CA are as follows:

• certificate issuance: the CA is responsible for issuing digital certificates containing information such as the certificate holder's public key, name, expiration date, and other relevant details. The CA generates the certificate and digitally signs it using its private key. The certificate issuance verifies that the public key contained in the certificate belongs to the specified holder;
• certificate management: the CA oversees the lifecycle of digital certificates. This involves recording issued certificates, managing renewal requests, and revoking certificates if the private key is compromised or for other reasons. The CA keeps track of issued certificates and manages their validity status.

The Validation Authority (VA) is the entity within a PKI that conducts activities related to validation and verification of digital certificates. The primary task performed by a VA is the provision of verification services to clients or parties intending to use digital certificates. These services may involve authenticating and ensuring the integrity of a certificate, analysing the identity information associated with the certificate and providing a mechanism to verify the certificate's validity over time. It may publish this information using solutions such as Certificate Revocation Lists (CRLs) or specific protocols like the Online Certificate Status Protocol (OCSP) for real time verification by interested parties.
Digital certificates follow a lifecycle encompassing various stages, from generation to revocation and termination of use. The main phases of the digital certificate lifecycle are listed below:

• key generation: the lifecycle of a certificate begins with its generation. This process involves the initial creation of the private and public cryptographic key pair. Key generation can occur either by the certificate requester (a preferable solution for maximum secrecy of the private key) or by the PKI, which subsequently provides the private key securely to the requester;
• certificate request and issuance: when a subject or entity wishes to obtain a digital certificate, they must submit a request to the CA. The request may include identity information and other details required by the CA. After verifying the identity and provided information, the CA issues the digital certificate containing, along with the details, the requester's public key;
• certificate usage: the digital certificate can be utilized for various purposes such as data encryption, identity authentication, digital signing, among others. During this phase, the public key included in the certificate is used to verify the authenticity and integrity of encrypted data or generate a digital signature;
• certificate validity: each certificate has an expiration date, after which it is no longer considered valid. To maintain operability, it's crucial to monitor expiry dates and renew the certificate before it becomes obsolete;
• certificate revocation: in some instances, a digital certificate might need to be revoked before its scheduled expiration date. This could occur if the private key associated with the certificate is compromised or if there are changes in the certificate holder's identity information. Revocation is executed by the CA and published via CRL or OCSP;
• cessation of use: upon certificate expiration or revocation, the digital certificate becomes invalid and should no longer be used for cryptographic or authentication purposes. The certificate holder must cease reliance on it and, if necessary, request a new certificate;
• renewal: prior to certificate expiration, the certificate holder may request its renewal. Renewal involves submitting a new certificate request to the CA. During the renewal process, the CA re-verifies the requester's identity, and if the request is accepted, issues a new certificate with a new expiration date.

The open source frameworks available for the creation of PKIs were investigated. Based on the analyses conducted OpenXPI appears to be more suitable for the implementation of functions within the project architecture. The support of the Enrollment over Secure Transport (EST) protocol, as recommended by IEC 62351-9 is certainly a decisive factor that makes this solution preferable. The Enterprise JavaBeans Certificate Authority (EJBCA) can be considered in the future, for example, to set up scenarios involving multiple PKIs to verify the interoperability of different solutions or identify the strengths of each.

3. Defensive cybersecurity measures

For the defensive security, the CIL design includes a platform for collecting information and events relevant to cybersecurity in a centralized SIEM (Security Information and Event Management) system for RSE test facilities. The SIEM system is equipped with advanced security monitoring functions, detection of cyber anomalies through the application of Artificial Intelligence and Machine Learning techniques and management of cybersecurity incidents. In the field of cybersecurity, a SIEM is an environment that allows integrating the functions of SIM (Security Information Management) and SEM (Security Event Management). The SIM allows to automatically manage the collection and management of non real time logs by storing them long-term for analysis and reporting. SEM allows to monitor and manage data in real time by collecting and evaluating the events of the infrastructure under analysis. The complementary capabilities of the two environments make it possible to obtain platforms capable of analysing both real time data and storing and managing them in a deferred mode.
The SIEM platform can automate the process of collection, aggregation and normalization of data coming from RSE TFs, allowing to obtain significant information and detect potential security incidents. The platform accomplishes the following tasks:

• logs and events collection: the platform is able to collect and aggregate logs and events from different sources through probes and modules positioned in the OT networks, both from IT devices (switches, routers, firewalls, intrusion detection systems (IDS)) and from OT devices such as RTU (Remote Terminal Unit), SCADA and field IEDs. This information is managed and stored in a centralized repository;
• events and logs correlation: the platform correlates IT/OT events and logs by applying algorithms and rules to identify relationships and patterns to identify any malicious activity;
• anomaly detection: through correlation rules and algorithms, a real time and, if necessary, deferred analysis is performed to detect security anomalies;
• alerting: the platform can generate alerts and signals for suspicious activity, such as unusual network traffic or unauthorized access attempts, and activate modules for proactive defence.

Log and event collection

To monitor the OT components and communications implemented in the multi-energy TF, a distributed data collection and analysis platform was designed. The SIEM platform is based on the tools made available by the Elastic environment through the ELK stack. ELK stands for Elasticsearch, Logstash and Kibana, the main components that make up a powerful framework known as Elastic Stack. The ELK stack is widely used for log management, real time analysis and data visualization in various sectors, appropriately configured and extended it is also a useful tool for the electro-energetic sector. Each component of the ELK stack has a specific purpose:

• Elasticsearch: Elasticsearch is a distributed search and analytics engine that forms the core of the ELK stack. It is designed to store, search and analyse large volumes of data in real time. Elasticsearch enables fast and efficient search, indexing, and retrieval of structured and unstructured data. It provides scalability, fault tolerance, and supports horizontal scaling by distributing data across multiple nodes;
• Logstash: Logstash is a data collection and ingestion tool that facilitates the centralized collection and processing of log data from various sources. It allows to analyse, filter, transform and enrich log files, events and data streams. Logstash supports a wide range of inputs, including log files, syslogs, beats, and other data sources. It can apply various filters and transformations to the data before sending it to Elasticsearch for indexing and storage;
• Kibana: Kibana is a data visualization and exploration tool that provides an intuitive interface for querying, analysing, and visualizing data stored in Elasticsearch. It offers powerful data visualization capabilities, including charts, graphs, dashboards, and maps, allowing to gain insights and perform ad hoc data analysis. Kibana allows the creation of custom dashboards and reports for monitoring and viewing log data.

Together, Elasticsearch, Logstash and Kibana form a complete solution for log management, search, analysis and visualization. Figure 5 shows the process of acquiring, analysing, storing and displaying information via the ELK stack. Elastic provides a scalable, flexible framework that can handle high volumes of data, perform real time analytics, and enable data-driven decision making. In addition to the core components of ELK, Elastic Stack also includes other tools and features, such as Beats (lightweight data providers), Elasticsearch Machine Learning (for anomaly detection), and Elastic Security (for advanced threat detection and prevention). These add-ons expand the capabilities of Elastic Stack, making it a complete solution for data analytics and security operations.

The data collection, analysis and visualization environment based on the ELK stack represents the support framework for monitoring and identifying attack scenarios to RSE energy infrastructures. The main components described in the previous section are positioned in key points of the infrastructure. The Milan and Piacenza TF will each have a local installation of the ELK stack (see Figure 2). These will collect detailed information from the different devices and provide inputs to a SOC (Security Operation Center) capable of collecting and analysing aggregate data relating to both TFs. There will therefore be different levels of monitoring in a hierarchical structure: a local layer and a centralized layer, thus allows testing of scenarios at different levels of granularity, for example attack processes that involve only one site (either Milan or Piacenza) and more extensive cases in which, for example, both facilities may be involved due e.g., to lateral movements of the attacker between them.
Particular attention must be paid to the choice of data sources and information collected. Indeed, it is important to combine the classic IT indicators with specific OT events and measures obtained from the analysis of communication protocols and devices in the electro-energy context.
The communication protocols used in the RSE TFs are: IEC 61850, Modbus, OCPP, MQTT, XMPP. Natively, the ELK stack mainly implements modules oriented towards more generic contexts, not specifically developed for the energy context. It is therefore necessary to extend and configure the platform to allow the identification of significant events and measures for the scenarios of interest. A preliminary analysis made it possible to identify a first minimum set of events and measurements sent to the analysis nodes via standard monitoring protocols such as Syslog and SNMP (Simple Network Management Protocol). This set of events is based on the categorised list of events in the current draft of IEC 62351-14, including events about user activities, configuration changes and system status; events coming from TLS communications and telecontrol protocols; events on access control, authorization and keys and certificates management.

Anomaly detection

The collection of measurements and events of interest requires the configuration of a data network hosting the nodes of the monitoring architecture. As monitoring activities can create considerable amounts of traffic and, in some situations, this can cause increased latency in control communications dedicated VLAN-based monitoring subnets have been created that are segregated from other communication networks.
Starting from the SIEM design described previously, installation and configuration activities of the different platform modules were carried out. A first node has been configured in which the various fundamental modules of the ELK stack were installed. This server will be positioned for data collection in the Milan TF (TF SOC in Figure 2). This node must be able, in addition to carrying out data collection activities, to perform analyses and identify any anomalies. To guarantee the security of the platform, security functions have been activated using digital certificates for access to the various modules. Both Logstash and Kibana have been configured to be able to communicate securely with Elasticsearch to enter and retrieve the information contained. The authentication functionality has been activated to be able to access Kibana for viewing and analysing information. The installation of TF SOC allows to collect logs from the process nodes. The syslog agents present on OT nodes send information to the TF SOC that receives them via the Logstash module. This information is parsed through an appropriate pipeline and sent to the Elasticsearch module for indexing and storage. Through Kibana it is possible to view them and perform analyses. Figure 6 presents an example of the interface that allows to view the logs collected by the platform.

The information stored and appropriately indexed by Elasticsearch can then be processed by advanced modules. An example is presented in Figure 7 where the Artificial Intelligence module made available by the platform is able to identify anomalies in the data collected. Various graphic representations provide the status of the infrastructure at a visual level highlighting, for example with different colours, the criticality of the anomaly found.

The platform allows to perform real time data analyses in terms of baseline and deviation from normal behaviour by executing automatic correlation analysis tasks at a configurable frequency. For getting real time detection, the correlation frequncey can be set to a few seconds. The deviations caused by known configuration changes in the OT networks are recognised as non-critical anomalies by the alert system. Figure 8 shows an example obtained by analysing the content of the log messages collected in the last month: the fields that lead to deviations are highlighted in the top-right. A further example of anomaly detection supported by the platform analyses the content of the log messages to identify recurring patterns. They can then be investigated further by selecting the item of interest.
At present, OT devices, including those in the RSE TFs, are lacking functionality for the collection of measurements and events: they are not equipped with technologies that allow the extraction of this information and in most cases they do not support protocols, such as SNMP and Syslog, for sending monitoring data to external systems. They only have display functions internal to the device or the software modules. The data relating to the status of OT nodes, such as the SCADA and the CCI, and the communications carried out with the process protocols will be made available by the implementations and functionalities in the sensors and agents of the architecture. Some important categories to consider for defensive anomaly detection include user activities (login/logout), changes in configurations and permission or access denied, also to SSH connections. Moreover, the system itself has to be monitored in terms of start and restarts, as well as request and various user action failures. Focussing on the IEC 61850/MMS communications, some interesting data comprise write commands and operations, cyber security events as connection failures on TLS or in certificate or role management.

4. Final remarks

The CIL’s architecture presented in the paper is highly configurable to adapt and scale to expanding number of OT devices in the system. The most critical issue in the wide deployment of the CIL security measures is related to the capability of devices in the market to support the security functionalities. The market scouting revealed that a scarcity of commercial devices actually supports the hardware (e.g. network interfaces) and software (e.g. protocol stack, reporting and logging) requirements necessary for implementing the cybersecurity by design in RSE TFs. The development of the CIL demonstrator necessarily has to adapt to the technological limits resulting from the low maturity of market products. The future work concerns the following activities:

• instrumentation of control and communication devices with cybersecurity measures;
• functional and performance testing of the cybersecurity mechanisms included in the data exchange flow between the infrastructure devices;
• development of the platform for the collection of security information and events and implementation of the centralized SIEM system;
• validation of the demonstrator's resilience capabilities through operational tests;
• testing the CIL functionality through cybersecurity demonstration scenarios.

In a medium-term timeframe, the CIL architecture will allow to test and validate the resilience capabilities of the digital infrastructures through the simulation of attack processes to facility devices with reference to selected operational multi-energy scenarios supported by RSE test facilities.

Acknowledgments

This research was funded by the Ministry of Ecological Transition under the Contract Agreement “Accordo di Programma Mission Innovation 2021-2024” – project “MISSION - Multivector Integrated Smart Systems and Intelligent microgrids for accelerating the energy transition.

References

1. CEI 0-16, Regola tecnica di riferimento per la connessione di Utenti attivi e passivi alle reti AT e MT delle imprese distributrici di energia elettrica.
2. IEC 61850-8-1:2011 Communication networks and systems for power utility automation - Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3.
3. IEC 62351:2020 SER Power systems management and associated information exchange - Data and communications security - ALL PARTS.
4. IEEE 1588:2019 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.

---

• Contact Author: G. DONDOSSOLA