The rapid growth of renewable energy toward industry 4.0, particularly renewable solar, has amplified the need for findable, accessible, interoperable, and reusable data sets collected from meteorological stations, sensors, renewable equipments, infrastructures, and others. In particular, solar plants generate large volumes of operational data, often structured using the IEC 61850 standard, a widely adopted protocol for energy systems that defines models for communication between intelligent devices. While IEC 61850 ensures consistency at the data exchange level, it does not provide full semantic interoperability needed for advanced analytics, data discovery, crossdomain integration, and automated reasoning. This paper describes an automatic pipeline for transforming IEC 61850-tagged data into knowledge graphs, enabling seamless integration with diverse datasets such as weather and grid structure for operation maintenance services as well as energy prediction services. This pipeline allows the transformation of these tags into a KG aligned with the Omega-X ontology, reducing the need for manual intervention, enabling continuous data integration, and enhancing the reuse of these data by service providers in the energy sector. We evaluate this approach in the context of the Omega-X project, using real-world datasets from a solar park that combines meteorological and electrical parameters.
The continuous use of renewable energy systems has driven the emergence of new digital services
designed to accelerate the integration of photovoltaic (PV) technologies. These services include the
optimization of Operation & Maintenance (O&M) workflows for early fault detection, as well as
congestion forecasting, and energy production estimation [
In IEC 61850 tags, each physical device (Ph, in this case the solar park) consists of logical devices
(LD), which consist of logical nodes (LN) that represent specific functions, and have data objects (DO)
qualified by data attributes (DA) and functional constraints (FC) that categorise their purpose [
Ph_LD∖DL.DO.DA.FC For example tag PARK_ECP001_S3_SHL001_Inverter01\s4dinv.heatsinktmp.mag.f can be decomposed as follows: PARK is the Ph and represents a PV park. ECP001_S3_SHL001_Inverter01 is the LD and represents an inverter. s4dinv is the LN and represents the specific function of averaging some property of the inverter over a period of 10 minutes. heatsinktmp means that the property of interest is the heat sink temperature of the inverter. The DA.FC mag.f means magnitude expressed as a float.
These tags will be the headers of the CSV files which are extracted each week encompassing. Each file
encompasses 250 tags. The aim is to transform these CSV files to a KG conformant with the Omega-X
pattern.5 To address this, we implemented a semantic Extract Transform Load (ETL) pipeline (illustrated
in Figure 1) that transforms CSV files into a unified and understandable representation using KGs.
Since the ontologies and data schemas were pre-defined in the project, and that the input data followed
standard protocols, we adopted a top-down approach for KG creation [
In the process of building KGs from heterogeneous data sources, RML (RDF Mapping Language) is used
to define declarative rules that map data from formats like CSV, JSON, or XML, into RDF [
3Detailed information about the pilot site cannot be disclosed in this paper for confidentiality reasons. 4Substations are key facilities of the power grid where voltage is transformed and electricity is routed between generation, transmission, and distribution networks. 5The Omega-X pattern can be found on GitHub - https://github.com/NaveenVarmaK/Pipeline_Mapping_IEC61850_ OmegaX-CSDM/images/pattern.jpg KG storage, Ontotext GraphDB 6 is used. as a triple store solution, tailored for storing, managing, and querying RDF data. It supports advanced features like reasoning and querying using SPARQL query language, which enables flexible and expressive querying over linked datasets.
The pipeline is FAIRly available on GitHub7, illustrated in 1 and consists of the following steps: 1. Extract: The extraction step begins with the normalisation of timestamps, converting all temporal data into the ISO 8601 date & time format with the UTC timezone. Following this, the list of devices is identified, and the dataset is segmented by device. For each device, a dedicated CSV file is generated. This step allows to attach the Ph_LD evaluation point to the data collection. 2. Transform: This stage constitutes the core of our semantic enrichment pipeline. The CSV files are transformed into KGs using RML mapping generated from a Jinja Template 8. The RML files are then processed using SDM-Rdfizer to create the KG. 3. Load: Once generated, the KGs are loaded to a GraphDB triple store, which serves as the semantic data endpoint. The stored data is queried using SPARQL, enabling the validation and evaluation of the system against a set of competency questions.
To illustrate the proposed pipeline, we use the example of two CSV datasets, one containing
meteorological data and another with inverter data from EDF pilot site. We first extract the list of devices from
the CSV files to create the topology KG. Typically, the topology creation step is performed once and
reused by the service providers to enable intelligent services. Weather stations and inverter datasets
are then transmitted periodically, typically on a weekly basis. In order to determine the unit and the
property, a rule-based parsing (regex + dictionary lookup) is being used. Regular expressions allow
lfexible pattern matching on text, while dictionary lookup ensures correct identification of known
units and properties, improving accuracy and maintainability of the parsing system [
To validate our pipeline, we conducted testing using data from sixteen inverters, sixteen weather stations, and approximately one hundred combiner boxes over eighteen weeks. Each week, the system processed around 1009 data points. The inverter data included DC current, DC voltage, DC power, 6https://www.ontotext.com/products/graphdb/ 7All source files are available on GitHub - https://github.com/NaveenVarmaK/Pipeline_Mapping_IEC61850_OmegaX-CSDM 8https://jinja.palletsprojects.com/en/stable/templates/ 9https://qudt.org/3.1.4/vocab/unit @prefix ets: <https://w3id.org/omega-x/ontology/EventTimeSeries/> . @prefix eds: <https://w3id.org/omega-x/ontology/EnergyDataSet/> . @prefix prop: <https://w3id.org/omega-x/ontology/Property/> . @prefix unit: <http://qudt.org/vocab/unit/>. <PARK_ECP001_S3_SHL001Inverter01/week-1> a ets:DataCollection, eds:EnergyDataSet ; eds:includesEvaluationPoint <PARK_ECP001_S3_SHL001Inverter01> ; eds:isExchangedIn <PARK_ECP001_S3_SHL001Inverter01/week-1/EC> ; ets:comprises <PARK_ECP001_S3_SHL001Inverter01/week-1/4dinv.heatsinktmp> . <PARK_ECP001_S3_SHL001Inverter01/week-1/4dinv.heatsinktmp> a ets:DataCollection ; ets:isAboutProperty prop:HeatSinkTemperature ; ets:hasUnit unit:DEG_C . <PARK_ECP001_S3_SHL001Inverter01/week-1/4dinv.heatsinktmp_DP_6163972> a ets:DataPoint ; ets:belongsTo <PARK_ECP001_S3_SHL001Inverter01/week-1/4dinv.heatsinktmp> ; ets:hasPropertyValue ˓→ <PARK_ECP001_S3_SHL001Inverter01/week-1/s4dinv.heatsinktmp_DP_6163972_PV6163972> ; ets:dataTime "2025-01-06 00:13:20"^^xsd:dateTime . enclosure temperature, heat sink temperature, and total active power. From the weather stations, we captured ambient temperature, plane of array insolation, and back-of-panel temperature. The evaluation of the produced KG focuses on its completeness, consistency, size and usability for intelligent services in renewable energy use cases. To assess the completeness of the KG, we executed a list of fity CQs which are written as SPARQL queries and executed in GraphDB. Basically, the queries aim to retrieve the device, the property, unit of measure, timestamp, and the values. In addition, for predictive maintenance services, we used queries depicting the topology of the park. These queries retrieve the connected devices as well as some datasheet properties like maximum DC current and maximum DC voltage for each inverter. All needed information was successfully retrieved. The responses to these queries proved highly valuable for the service providers of the Omega-X project, who previously found it dificult to interpret the raw CSV files before semantic enrichment. To ensure semantic consistency, we used the Pellet reasoner [10]. Furthermore, we evaluated the number of triples of the produced KG. The weekly inverter KG consists of 10240 triples generated from a CSV file with 39 columns and 1009 rows, while the weekly weather station KG consists of 6144 triples generated from a CSV file with 19 columns and 1009 rows. The semantic enrichment significantly improves the data’s utility and interoperability with other data from other data providers who were not using the IEC 61850 tags but reused the same Omega-X pattern to describe semantically their measurements. For example, the predictive maintenance service is tested on two distinct datasets provided by EDF (that uses IEC 61850) and ESTABANELL-EYPESA. This demonstration illustrates the potential of deploying services across diferent companies adopting heterogenous dataset format by relying on a common data representation model. Moreover, the shared taxonomy of properties used in the KG allows for the reuse of the dataset in flexibility services. To evaluate the usability of the produced KGs, we assessed their adoption by service providers. Four out of five service providers in Omega-X were able to successfully utilise the KGs to generate their services, demonstrating the practicality and efectiveness of the graph structure and data model. However, the remaining one encountered dificulties due to the absence of some inverter properties description, whose inclusion requires significant manual efort and time. On average, the complete pipeline for generating a weekly KG for a single device takes less than 1 minute. To better understand performance at a finer granularity, we analysed a representative execution using a CSV file for an inverter. All experiments and performance evaluations were conducted on a personal laptop running Ubuntu, equipped with the following hardware specifications: CPU: 11th Gen Intel® CoreTM i7-1185G7 @ 3.00GHz, 4 cores, 8 threads; CPU Frequency: 400 MHz (min) – 4.8 GHz (max); RAM: 16 GB; Operating System: Ubuntu 22.04 LTS (64-bit). Over the span of 18 weeks, on average, the creation of the KG is done in 47.3 seconds and the peak memory usage is 75.20 MB.
The paper describes the steps of the automatic ETL pipeline for KG creation from IEC 61850 tags and structured using the Omega-X ontology. The proposed solution consists of three main components: Extraction of devices and grouping data per device; KG generation using Jinja and RML files; KG storage in GraphDB triple store for information retrieval using SPARQL queries defined from CQs. To the best of our knowledge, using text-based templates to generate RML mappings and then use these mappings automatically is an innovative approach that proved to be both simple and a pragmatic fit to our needs. RML mappings being expressed in RDF, an alternative could consist in using RML itself to generate RML mappings, although we believe it would be less understandable and maintainable. The produced KGs have been utilised by various service providers who consumed the KGs in the Omega-X project to deliver services related to predictive maintenance and energy prediction. This has improved the understandability and reusability of the datasets. Moreover, the application of semantic techniques has proven efective in addressing the interoperability challenges between datasets from the same data provider as well as across diferent data providers. Fortunately, the creation of these KGs paves the way for their application across diverse use case families. Notably, they enhance scenarios where energy production prediction is required, such as in flexibility related use cases. EDF is planning to test this pipeline in other departments than solar production where IEC 61850 is used for data exchange. However, a major challenge lies in the scale of these KGs, the diversity of data sources, and the complexity introduced by IEC 61850 tags. There is a clear need for adaptable approach where the mapping process should be generated based on the IEC 61850 tags encountered in the data.
information extraction systems!, in: Proceedings of the 2013 Conference on Empirical Methods in Natural Language Processing, 2013, pp. 827–832. [10] S. Abburu, A survey on ontology reasoners and comparison, International Journal of Computer Applications 57 (2012).