COCOON Energy Community dataset and results in Laboratory Environment

# Energy-community pilot dataset — Real-time FDI attack detection tests (COCOON project) ## Description This dataset contains the raw measurements, configuration files, automation scripts and result plots produced during the **real-time Hardware-in-the-Loop (HIL/CHIL) and Power-Hardware-in-the-Loop (PS-HIL/PHIL) testing campaign** of the False Data Injection Identification (FDII) tool developed within the **COCOON** project (*COoperative Cyber prOtectiON for modern power grids*). The tests reproduce, at the Cyber-Physical Power System Laboratory (CPPS Lab, Department of Electrical Engineering, University of Sevilla), the electrical and OT infrastructure of an **energy-community (EC) pilot demonstration** used in COCOON Work Package 8 (*Secure DRES Deployments*). The pilot network hosts 16 PV plants, five of which belong to the energy community represented in this testing campaign. The data corresponds to the work reported in COCOON deliverable **D3.2 — "Cyber-physical security integration in renewable power plants and energy communities"** (Chapter 4, "FDI attacks on the energy community"). ## Project and funding | | ||---|---|| Project | COCOON — COoperative Cyber prOtectiON for modern power grids || Programme | Horizon Europe (HORIZON-CL5-2022-D3-01) || Grant Agreement No. | [101120221](https://cordis.europa.eu/project/id/101120221) || Coordinator | University of Cyprus — KIOS Research and Innovation Center of Excellence || Responsible partner for this dataset | Universidad de Sevilla (USE) — Cyber-Physical Power System Laboratory (CPPS Lab), with the energy-community network model and FDII algorithm contributed by Aristotle University of Thessaloniki (AUTH) || Project website | https://www.cyber-cocoon.eu/ | This project has received funding from the European Union's Horizon Europe research and innovation programme under Grant Agreement No. 101120221. Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the granting authority; neither the European Union nor the granting authority can be held responsible for them. ## Authors / Contact - José María Maza-Ortega — Universidad de Sevilla (USE)- Manuel Barragán-Villarejo — Universidad de Sevilla (USE)- Álvaro Rodríguez del Nozal — Universidad de Sevilla (USE)- Stelios C. Dimoulias — Aristotle University of Thessaloniki (AUTH)- Georgios C. Kryonidis — Aristotle University of Thessaloniki (AUTH)- Kyriaki-Nefeli D. Malamaki — Aristotle University of Thessaloniki (AUTH)- Charis S. Demoulias — Aristotle University of Thessaloniki (AUTH) Department of Electrical Engineering, Universidad de Sevilla, Spain (real-time laboratory testing); Department of Electrical and Computer Engineering, Aristotle University of Thessaloniki, Greece (energy-community network model and FDII-for-energy-communities algorithm). ## Context: what is being tested ### The energy-community pilot The pilot network is an exclusively active MV (20 kV)/LV (400 V) distribution feeder comprising 16 PV plants, five of which belong to the energy community. For real-time testing, the network is represented by two increasingly simplified equivalents: - **HIL model (`CHIL/`)**: executed in real time on the OPAL-RT simulator, keeping the nine energy-community-relevant PV connection nodes plus the point of interconnection (POI) with the upstream grid, with the remaining (non-EC) PV plants aggregated into a single equivalent node.- **PS-HIL model (`PHIL/`)**: implemented on the scaled-down MV distribution network of the CPPS Lab (base 400 V / 100 kVA), which is limited to a smaller number of laboratory branches/OLEs (Output Load Emulators). A second simplification groups the power of three of the PV plants into a single equivalent node, labelled **`N04-19`** in the data. Measurement points referenced in the JSON result files use the naming `POI / Slack` (point of interconnection) and `PV 1` … `PV 9` (each followed by a local feeder label as recorded by the site's SCADA system). ### The FDII tool for energy communities The FDII tool used in this campaign combines two sequential modules (D3.2 §4.4): 1. **MbPA** — Measurement-based Plausibility Analysis, a deterministic check on the PV nodes verifying that active/reactive/apparent power injections stay within each plant's installed capacity.2. **EC-WLSE** — the Equality-Constrained Weighted Least Squares state Estimator, with bad-data detection/removal via the iterative Largest Normalised Residual (LNR) test (playing the role of both false-data detection, FDD, and false-data injection response, FDIR). Consequently, the SCADA output table does **not** carry per-algorithm `*_flag_1/2/3` columns. Instead, detection/identification results are provided in the separate `*_FDD.json` files as, for each time step, a list of `[quantity, bus_index, node_name]` triples identifying which magnitude at which node was flagged as false data (quantity ∈ {`V`, `P`, `Q`, `I`}). Two attack types were injected on the field measurements: - **Dummy** attacks: field measurements altered without respecting the power-flow constraints of the system. Between 1 and 4 (out of 30 total energy-community measurements) can be attacked simultaneously; a full 56-test combinatorial matrix (tests 1–56) covers all single/double/triple/quadruple combinations used in the campaign (see D3.2 Table 4.6).- **Smart / sophisticated** attacks: measurements manipulated coherently with the power-flow equations to remain stealthy. In this dataset the sophisticated case is fixed to the same 4-measurement combination as unitary dummy test **56**. Both attack types were tested under **two attack-magnitude bands**, encoded in the folder names as `XX_YY` → attack magnitude in the range ±[XX%, YY%] of the true value (confirmed from the `factor_applied` values stored in the condensed result files):- `10_15` → present only in the `CHIL` block included here.- `15_20` and `30_40` → the two bands used throughout the `PHIL` block, matching the ranges reported in D3.2 §4.6.1 for the energy-community tests. and under **three power-factor operating points** of the PV plants (folders `PF1`, `PF09C`, `PF09I`): unity (1.0), 0.9 capacitive, and 0.9 inductive. ## Folder structure ```CHIL/ Hardware-in-the-Loop tests (energy community simulated in real time on OPAL-RT)└── Unitary_test/ Single operating-point tests (steady-state, rated power) └── Dummy/10_15/PF1/ The only block included for CHIL: full 56-test definition/analytical files, plus raw data and figures for the representative attack (Test 56 and a subset of the individual tests 1–56, see below) PHIL/ Power-Hardware-in-the-Loop tests (scaled-down physical MV network + OLEs emulating the EC PV nodes, replacing the OPAL-RT real-time simulation)├── Unitary_Test/ Single operating-point tests│ ├── Dummy/15_20|30_40/PF1|PF09C|PF09I/ Dummy-attack unitary tests│ ├── Smart/15_20|30_40/PF1|PF09C|PF09I/ Smart/coordinated-attack unitary tests (fixed combo = Test 56)│ └── WithoutAttack/ Reference (no-attack) run└── Profile_Test/ 24-hour PV generation profile tests ├── Dummy/, Smart/ Same band/power-factor structure as above, run over a daily profile │ └── attack_scenarios.json Test-plan/attacked-tag definitions shared by the Dummy Profile_Test block └── WithoutAttack/ Reference (no-attack) daily-profile run``` Note the folder-name capitalisation differs between blocks as originally produced by the researchers: `Unitary_test`/`Profile_test` (lower-case *t*) under `CHIL`, but `Unitary_Test`/`Profile_Test` (capital *T*) under `PHIL`. Within each leaf test folder the following files recur: | File / folder | Content ||---|---|| `Archivo_OPAL/myfile_*.csv` | Raw real-time simulation output. Present only in a few `PHIL/Unitary_Test/Smart/30_40/*` folders in this dataset (kept as originally produced); not present elsewhere. || `Tabla_DB_MEAS/DB_INPUT_*.csv` | Raw field measurements as logged by the SCADA database, one column pair (`TagN_Name`, `TagN_Value`) per monitored SCADA point, before/after the attack is injected. || `Tabla_DB_SE/DB_OUTPUT_*.csv` | Output of the FDII/state-estimation tool as logged by the SCADA database: estimated variables as `TagN_Name`/`TagN_Value` pairs. **No per-algorithm detection flags are embedded in this table**; flags are provided separately in the `*_FDD.json` file of the same folder (see above). || `attack_scenarios.json` / `attack_scenarios_correct.json` | Test-plan definitions: test ID, attack type (dummy/smart), test type (unitary/profile), attack timing, PV generation level, and the list of attacked SCADA tags (`attack_details`) per test. || `Unitary_test_HEDNO_*_CHIL.json` | Consolidated pre/post-attack measurement values for the test(s) of that block, keyed by SCADA tag. || `Unitary_test_HEDNO_*_CHIL_FDD.json` | Per-time-step FDI detection/identification flags for the test(s) of that block, as `[quantity, bus_index, node_name]` triples (see above). || `Unitary_test_HEDNO_*_CHIL_Factor_smart.json` | Per-time-step multiplicative attack factors applied to each attacked tag, for the smart/coordinated-attack profile tests. || `FDII_results_condensed.json`, `PF_1_condensed_*.json`, `PF_09_cap_condensed_*.json`, `PF_09_ind_condensed_*.json` | Offline-computed, per-test analytical summary: the `false_data_analytical` list of `[quantity, bus_index, node_name]` triples flagged, and a `summary` block with the array index, node name, quantity, bus index, applied attack factor, and measured/estimated values — used to cross-check the real-time DB output for each of the 56 unitary tests. || `Unitary_test_10_15_CHIL_v1.json` | **Caveat**: only present in `CHIL/Unitary_test/Dummy/10_15/PF1/`. This is an auxiliary file that carries measurement names/labels not used elsewhere in this dataset (e.g. `U_POI`, `P_SS1`, `Q_SS1`), which do not correspond to real node names of this network. The plotting script in the same folder (`figs_ut_dum_1015_pf1.py`) inherits this naming for figure titles/labels; the underlying numerical values, however, are specific to this campaign. For an authoritative test/measurement mapping, use `attack_scenarios_correct.json`, `Unitary_test_HEDNO_10_15_CHIL.json` and `FDII_results_condensed.json` in the same folder, or D3.2 Table 4.6. || `figs_*.py` | Python/matplotlib scripts that regenerate the result plots (time evolution of measurements/estimates and detection/identification flags) from the `Tabla_DB_MEAS` / `Tabla_DB_SE` CSV files and the `*_FDD.json` file. || `easyres.mplstyle` | Matplotlib style sheet used by the plotting scripts to produce the figures. || `fig/pdf/`, `fig/svg/` | Rendered result figures in PDF and SVG format. | Raw per-test CSV/figure coverage varies by folder: some blocks retain data only for the representative attack combination shown in D3.2 (`Test_56`), others additionally retain a handful of the lower-numbered unitary tests, and the single `CHIL` block retains data for most of the 56 tests. The `*_condensed.json` files, in contrast, always cover all 56 unitary tests analytically. ## Software The `figs_*.py` scripts are the analysis/plotting software accompanying the data. They are standard Python 3 scripts built on `pandas`/`numpy`/`matplotlib` (using the provided `easyres.mplstyle` style sheet) that: 1. Load the corresponding `Tabla_DB_MEAS`/`Tabla_DB_SE` CSV files (and, where present, the `Archivo_OPAL` file) for a given test.2. Reconstruct the true vs. attacked vs. estimated time series for the relevant electrical magnitudes, using the `Tag*_Value` columns (some scripts define an explicit `map_tags` dictionary translating estimator-side tags to measurement-side tags).3. Overlay the FDI detection/identification flags read from the corresponding `*_FDD.json` file.4. Export the figures to `fig/pdf/` and `fig/svg/`. No installation package is provided; the scripts are meant to be run directly (`python figs_..._v1.py`) from within their own test folder, with `pandas`, `numpy` and `matplotlib` as dependencies. ## Data format notes - CSV files use `Tag0_Value` as the first column (a timestamp), followed by `TagN_Name`/`TagN_Value` pairs for each monitored SCADA point; missing/not-applicable fields are left empty.- JSON files are UTF-8 text, human-readable, and follow the same schema across test blocks (see table above), except for the legacy `Unitary_test_10_15_CHIL_v1.json` file discussed above.- Timestamps in the CSV files reflect the clock of the laboratory data-acquisition system at the time of the experimental campaign and do not carry calendar significance beyond sequencing the recorded samples.- The `PHIL` folders use a finer-grained, tag-based file/labelling convention; consult D3.2 Table 4.6 (or the `attack_scenarios*.json` files) to map a given `TagN_Value` to the physical quantity and node it represents. ## How to cite If you use this dataset, please cite the COCOON deliverable it originates from: > Maza-Ortega, J.M., Barragán-Villarejo, M., Rodríguez del Nozal, Á., Dimoulias, S.C., Kryonidis, G.C., Malamaki, K.-N.D., Demoulias, C.S. (2026). *D3.2 Cyber-physical security integration in renewable power plants and energy communities*. COCOON Project, Grant Agreement No. 101120221. and this Zenodo record (see the "Cite as" box generated by Zenodo once published). ## License The data and scripts in this dataset are released under the **Creative Commons Attribution 4.0 International (CC BY 4.0)** license. See https://creativecommons.org/licenses/by/4.0/ for the full license text. ## Disclaimer Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the Directorate-General for Communications Networks, Content and Technology. Neither the European Union nor the Directorate-General for Communications Networks, Content and Technology can be held responsible for them.