Skip to main content
Powered by ShareScore

Find research datasets worth reusing

Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.

72

datasets available to search

ShareScore release 0.9.0

Reset

Dataset results

72 results for “anomaly dataset”

Learn how ShareScore rates datasets ↗
zenodo52/100

Dataset of "Anomaly Detection in Industrial Networks: Current State, Classification, and Key Challenges"

<p>Industrial networks are adapted to their specific requirements, especially in terms of industrial processes. To ensure sufficient security in these networks, it is necessary to set and use security policies that complement government regulations, recommendations, and relevant security standards. This paper aims to provide an in-depth analysis of the anomalies occurring within the networks and propose a structure for collecting valuable data from the experimental site based on dividing anomalies into three main categories:<br>security, operational, and service anomalies (and regular traffic recognition). We present a proof-of-concept solution/design aggregating data in industrial networks for advanced anomaly classification. Multiple data sources such as industrial communication, sensor data (additional sensors controlling device behavior), and HW status data are used as data sources. A total of three scenarios (using a physical testbed) were implemented, where we achieved an accuracy of 0.8540/0.9972 in advanced anomaly classification.</p>

opencc-by-4.0Aug 2024View details →
zenodo48/100

Dataset for "Remapping of Greenland ice sheet surface mass balance anomalies for large ensemble sea-level change projections"

<p>This dataset is used to reproduce the results presented in the following publication:</p> <p>Goelzer, H., Noel, B. P. Y., Edwards, T. L., Fettweis, X., Gregory, J. M., Lipscomb, W. H., van de Wal, R. S. W., and van den Broeke, M. R.: Remapping of Greenland ice sheet surface mass balance anomalies for large ensemble sea-level change projections, The Cryosphere Discuss., https://doi.org/10.5194/tc-2019-188, in review, 2019.</p> <p>&nbsp;</p>

opencc-by-4.0Apr 2020View details →
zenodo48/100

Dataset for the paper "Anomaly Detection in Large-Scale Cloud Systems: An Industry Case and Dataset"

<p>We present a large-scale anomaly detection dataset collected from IBM Cloud's Console over approximately 4.5 months. This high-dimensional dataset captures telemetry data from multiple data centers, specifically designed to aid researchers in developing and benchmarking anomaly detection methods in large-scale cloud environments. It contains 39,365 entries, each representing a 5-minute interval, with 117,448 features/attributes, as interval_start is used as the index. The dataset includes detailed information on request counts, HTTP response codes, and various aggregated statistics. The dataset also includes labeled anomaly events identified through IBM's internal monitoring tools, providing a comprehensive resource for real-world anomaly detection research and evaluation.</p> <p><strong>File Descriptions</strong></p> <ul> <li><code>location_downtime.csv</code> - Details planned and unplanned downtimes for IBM Cloud data centers, including start and end times in ISO 8601 format.</li> <li><code>unpivoted_data.parquet</code> - Contains raw telemetry data with 413 million+ rows, covering details like location, HTTP status codes, request types, and aggregated statistics (min, max, median response times).</li> <li><code>anomaly_windows.csv</code> - Ground truth for anomalies, listing start and end times of recorded anomalies, categorized by source (Issue Tracker, Instant Messenger, Test Log).</li> <li><code>pivoted_data_all.parquet</code> - Pivoted version of the telemetry dataset with 39,365 rows and 117,449 columns, including aggregated statistics across multiple metrics and intervals.</li> <li><code>demo/demo.[ipynb|html]</code>: This demo file provides examples of how to access data in the Parquet files, available in Jupyter Notebook (<code>.ipynb</code>) and HTML (<code>.html</code>) formats, respectively.</li> </ul> <p>Further details of the dataset can be found in <strong>Appendix B: Dataset Characteristics</strong> of the <a href="https://arxiv.org/abs/2411.09047">paper</a> titled <strong><em>"Anomaly Detection in Large-Scale Cloud Systems: An Industry Case and Dataset."</em></strong> Sample code for training anomaly detectors using this data is provided in <a href="https://doi.org/10.5281/zenodo.14598119" target="_blank" rel="noopener">this package</a>.</p> <p>&nbsp;</p> <p>When using the dataset, please cite it as follows:</p> <pre><code>@misc{islam2024anomaly,</code><br><code>&nbsp; &nbsp; &nbsp; title={Anomaly Detection in Large-Scale Cloud Systems: An Industry Case and Dataset},&nbsp;</code><br><code>&nbsp; &nbsp; &nbsp; author={Mohammad Saiful Islam and Mohamed Sami Rakha and William Pourmajidi and Janakan Sivaloganathan and John Steinbacher and Andriy Miranskyy},</code><br><code>&nbsp; &nbsp; &nbsp; year={2024},</code><br><code>&nbsp; &nbsp; &nbsp; eprint={2411.09047},</code><br><code> &nbsp; &nbsp; archivePrefix={arXiv},</code><br><code> &nbsp; &nbsp; url={https://arxiv.org/abs/2411.09047}</code><br><code>}</code></pre> <p>&nbsp;</p>

opencc-by-4.0Nov 2024View details →
zenodo48/100

OPSSAT-AD - anomaly detection dataset for satellite telemetry

<p>This is the AI-ready benchmark dataset (OPSSAT-AD) containing the telemetry data acquired on board OPS-SAT---a CubeSat mission that has been operated by the European Space Agency.</p> <p>It is accompanied by the paper with baseline results obtained using 30 supervised and unsupervised classic and deep machine learning algorithms for anomaly detection. They were trained and validated using the training-test dataset split introduced in this work, and we present a suggested set of quality metrics that should always be&nbsp;calculated to confront the new algorithms for anomaly detection while exploiting OPSSAT-AD. We believe that this work may become an important step toward building a fair, reproducible, and objective validation procedure that can be used to quantify the capabilities of the emerging anomaly detection techniques in an unbiased and fully transparent way.</p> <p>The included files are:</p> <ul> <li><code>segments.csv</code> with the acquired telemetry signals from ESA OPS-SAT aircraft,</li> <li><code>dataset.csv</code> with the extracted, synthetic features are computed for each manually split and labeled telemetry segment.</li> <li>code files for data processing and example modeliing (<code>dataset_generator.ipynb</code> for data processing, <code>modeling_examples.ipynb</code> with simple examples, &nbsp;<code>requirements.txt</code>- with details on Python configuration, and the&nbsp;<code>LICENSE</code> file)</li> </ul> <p>&nbsp;</p> <p>Please have a look at our two papers commenting on this dataset:</p> <ul> <li>The benchmark paper with results of 30 supervised and unsupervised anomaly detection models for this collection:<br>Ruszczak, B., Kotowski. K., Nalepa, J., Evans, D.:<strong> The OPS-SAT benchmark for detecting anomalies in satellite telemetry, 2024</strong>, <a href="https://arxiv.org/abs/2407.04730" target="_blank" rel="noopener">preprint arxiv: 2407.04730</a>,</li> <li>the conference paper in which we presented some preliminary results for this dataset:<br>Ruszczak, B., Kotowski. K., Andrzejewski, J., et al.: (2023). Machine Learning Detects Anomalies in OPS-SAT Telemetry. Computational Science &ndash; ICCS 2023. LNCS, vol 14073. Springer, Cham, <a href="https://doi.org/10.1007/978-3-031-35995-8_21">DOI:10.1007/978-3-031-35995-8_21</a>.</li> </ul>

opencc-by-4.0Jun 2024View details →
zenodo48/100

Packaging Industry Anomaly DEtection (PIADE) Dataset

<p>PIADE dataset contains data from five industrial packaging&nbsp;machines:</p> <ul> <li>Machine s_1: from 2020-01-01 14:00:00 to 2021-12-31 13:00:00</li> <li>Machine s_2: from 2020-06-17 08:00:00 to 2021-12-31 07:00:00</li> <li>Machine s_3: from 2020-10-07 12:00:00 to 2022-01-01 23:00:00</li> <li>Machine s_4: from 2020-01-01 01:00:00 to 2022-01-01 23:00:00</li> <li>Machine s_5: from 2020-01-20 08:00:00 to 2022-01-01 12:00:00</li> </ul> <p>## Raw Data</p> <p>Each row represents a production interval, with the following schema:</p> <ul> <li>interval_start: start of the production interval&nbsp; &nbsp;&nbsp;</li> <li>equipment_ID: equipment identifier&nbsp; &nbsp;&nbsp;</li> <li>alarm: alarm code of the active stop reason, if it occurred&nbsp;&nbsp; &nbsp;&nbsp;</li> <li>type:&nbsp;idle, production, downtime, performance_loss or scheduled_downtime &nbsp; &nbsp;</li> <li>start: start of the production interval&nbsp; &nbsp;&nbsp;</li> <li>end: end of the production interval&nbsp;&nbsp; &nbsp;</li> <li>elapsed:&nbsp;duration of the production interval &nbsp; &nbsp;</li> <li>pi: input packages&nbsp; &nbsp;&nbsp;</li> <li>po: output packages&nbsp; &nbsp;&nbsp;</li> <li>speed: speed (packages per hour)</li> </ul> <p>There are 133 different types of alerts, and 429394 rows.<br> &nbsp;</p> <p>## Sequences (1h) data</p> <p>For each piece of equipment, we define sequences of length = 1 hour and we aggregate raw interval data as follows:</p> <ul> <li>&#39;equipment_ID&#39;: machine identifier</li> <li>&#39;#changes&#39;: changes in machine state</li> <li>&#39;%downtime&#39;: time spent in &#39;downtime&#39; state</li> <li>&#39;%idle&#39;: time spent in &#39;idle&#39; state</li> <li>&#39;%performance_loss&#39;: time spent in &#39;performance loss&#39; state</li> <li>&#39;%production&#39;: time spent in production</li> <li>&#39;%scheduled_downtime&#39;: time spent in scheduled downtime</li> <li>&#39;count_sum&#39;: sum of all alarm occurrences</li> <li>&#39;A_&lt;XXX&gt;&#39;: counter of alarm &lt;XXX&gt; occurrences</li> <li>&#39;&lt;state1&gt;/&lt;state2&gt;&#39;: number of transitions from &lt;state1&gt; to &lt;state2&gt;</li> </ul> <p>&nbsp;</p>

opencc-by-4.0Dec 2021View details →
zenodo48/100

Three Annotated Anomaly Detection Datasets for Line-Scan Algorithms

<h1>Summary</h1> <p>This dataset contains two hyperspectral and one multispectral anomaly detection images, and their corresponding binary pixel masks. They were initially used for real-time anomaly detection in line-scanning, but they can be used for any anomaly detection task.</p> <p>They are in .npy file format (will add tiff or geotiff variants in the future), with the image datasets being in the order of (height, width, channels). The SNP dataset was collected using sentinelhub, and the Synthetic dataset was collected from AVIRIS. The Python code used to analyse these datasets can be found at: https://github.com/WiseGamgee/HyperAD</p> <h1>How to Get Started</h1> <p>All that is needed to load these datasets is Python (preferably 3.8+) and the NumPy package. Example code for loading the Beach Dataset if you put it in a folder called "data" with the python script is:</p> <pre><code>import numpy as np # Load image file hsi_array = np.load("data/beach_hsi.npy") n_pixels, n_lines, n_bands = hsi_array.shape print(f"This dataset has {n_pixels} pixels, {n_lines} lines, and {n_bands}.") # Load image mask mask_array = np.load("data/beach_mask.npy") m_pixels, m_lines = mask_array.shape print(f"The corresponding anomaly mask is {m_pixels} pixels by {m_lines} lines.")</code></pre> <h1>Citing the Datasets</h1> <p>If you use any of these datasets, please cite the following paper:</p> <pre><code>@article{garske2024erx,</code><br><code>&nbsp; title={ERX - a Fast Real-Time Anomaly Detection Algorithm for Hyperspectral Line-Scanning},</code><br><code>&nbsp; author={Garske, Samuel and Evans, Bradley and Artlett, Christopher and Wong, KC},</code><br><code>&nbsp; journal={arXiv preprint arXiv:2408.14947},</code><br><code>&nbsp; year={2024},</code><br><code>}</code></pre> <div> <pre>If you use the beach dataset please cite the following paper as well (original source):</pre> </div> <pre><code>@article{mao2022openhsi, title={OpenHSI: A complete open-source hyperspectral imaging solution for everyone}, author={Mao, Yiwei and Betters, Christopher H and Evans, Bradley and Artlett, Christopher P and Leon-Saval, Sergio G and Garske, Samuel and Cairns, Iver H and Cocks, Terry and Winter, Robert and Dell, Timothy}, journal={Remote Sensing}, volume={14}, number={9}, pages={2244}, year={2022}, publisher={MDPI} }</code></pre>

opencc-by-4.0Aug 2024View details →
zenodo44/100

A global dataset of SST anomaly evolving processes retrieved from remote sensing products (GDSSTAEP V1.0)

<p>&nbsp;The GDSSTAEP includes three datasets and two relationship files with a time range from January 1982 to December 2009. Three datasets formatted in SHP are a dataset of process object-oriented SSTA, named DSPOSSTA, storing SSTA process objects, a dataset of sequence object-oriented SSTA, named DSSOSSTA, storing SSTA sequence objects, and a dataset of variation object-oriented SSTA, named DSVOSSTA, storing SSTA variation objects, respectively. And two relationship files formatted in CSV store the evolving behaviors among sequence objects of SSTA and variation objects of SSTA, respectively.&nbsp;</p> <p>&nbsp;</p>

opencc-by-4.0Sep 2020View details →
zenodo44/100

Precipitation and Temperature Anomalies from MERRA-2 dataset

<p>Anomalies in Precipitation and Temperature for tiles around the globe.</p> <p>Data derived from the reanalysis MERRA-2 project [1]. The dataset covers the period from 1980 to 2018, between 80&ordm;N and 80&ordm;S. The spatial resolution is 1.0&ordm; x 1.0&ordm; resulting in 45,792 tiles and a time resolution of 7 days (by averaging the values over each week). Precipitation time-series were re-scaled by applying a logarithmic function to all values.</p> <p>To discount seasonality effects, we averaged temperature and precipitation values for each of the 365 calendar days. We considered the interval from 1 January 1980 through 28 February 2018 as the climatic period for which the long-term averages were computed. The anomalies are then obtained by subtracting for each day the respective average temperature or precipitation from the climatic period (for example, the 1 January 1998 anomaly is computed as the value for that day minus the average of all January 1 values between 1980 and 2018).</p> <p>To process the data, use the code available in:</p> <p><a href="https://github.com/filipinascimento/teleconnectionsgranger/">https://github.com/filipinascimento/teleconnectionsgranger/</a></p> <p><a href="http://arxiv.org/abs/2012.03848">http://arxiv.org/abs/2012.03848</a></p> <p>[1] A. Molod, L. Takacs, M. Suarez, and J. Bacmeister, &ldquo;Development of the geos-5 atmospheric general circulation model: evolution from merra to merra2,&rdquo; Geoscientific Model Development 8, 1339&ndash;1356 (2015).</p> <p>&nbsp;</p> <p>&nbsp;</p>

opencc-by-4.0Nov 2020View details →
zenodo44/100

Dataset for the paper "Historical model biases in monthly high temperature anomalies indicate under-projection of future temperature extremes"

<div> <div>This repository holds data and scripts related to the revision of the paper entitled: <span>"Historical model biases in monthly high temperature anomalies indicate under-projection of future temperature extremes" </span>by Lei Duan, Lyssa M. Freese, Govindasamy Bala, and Ken Caldeira. <span>The paper is currently submitted for peer review. </span>Any questions regarding the data and paper could be sent to the corresponding author: Lei Duan (leiduan@carnegiescience.edu).&nbsp;</div> </div>

opencc-by-4.0Apr 2024View details →
zenodo44/100

Geospatial Dataset of GNSS Anomalies and Political Violence Events

<p><strong>Geospatial Dataset of GNSS Anomalies and Political Violence Events</strong></p> <p><strong>Overview</strong></p> <p>The <strong>Geospatial Dataset of GNSS Anomalies and Political Violence Events&nbsp;</strong>is a collection of data that integrates aircraft flight information, GNSS (Global Navigation Satellite System) anomalies, and political violence events from the ACLED (Armed Conflict Location &amp; Event Data Project) database.</p> <p><strong>Dataset Files</strong></p> <p>The dataset consists of three CSV files:</p> <ol> <li><strong>Daily_GNSS_Anomalies_and_ACLED-2023-V1.csv</strong></li> <ul> <li><strong>Description:</strong> Contains all grids and dates that had aircraft traffic during 2023.</li> <li><strong>Number of Records:</strong> 6,777,228</li> <li><strong>Purpose:</strong> Provides a complete view of aircraft movements and associated data, including grids without any GNSS anomalies.</li> </ul> <li><strong>Daily_GNSS_Anomalies_and_ACLED-2023-V2.csv</strong></li> <ul> <li><strong>Description:</strong> A filtered version of V1, including only the grids and dates where GNSS anomalies (jumps or gaps) were reported.</li> <li><strong>Number of Records:</strong> 718,237</li> <li><strong>Purpose:</strong> Focuses on areas and times with GNSS anomalies for targeted analysis.</li> </ul> <li><strong>Monthly_GNSS_Anomalies_and_ACLED-2023-V9.csv</strong></li> <ul> <li><strong>Description:</strong> Contains aggregated monthly data for each grid cell, combining GNSS anomalies and ACLED political violence events. Summarizes aircraft traffic, anomaly counts, and conflict activity at a monthly resolution.</li> <li><strong>Number of Records:</strong> 25,770</li> <li><strong>Purpose:</strong> Enables temporal trend analysis and spatial correlation studies between GNSS interference and political violence, using reduced data volume suitable for modeling and visualization.</li> </ul> </ol> <p><strong>Data Fields:&nbsp; &nbsp; </strong>Daily_GNSS_Anomalies_and_ACLED-2023-V1.csv and&nbsp;Daily_GNSS_Anomalies_and_ACLED-2023-V2.csv</p> <ol> <li><strong>grid_id</strong></li> <ul> <li><strong>Description:</strong> Unique identifier for a grid cell on Earth measuring 0.5 degrees latitude by 0.5 degrees longitude.</li> <li><strong>Format:</strong> String combining latitude and longitude (e.g., -10.0_-36.0).</li> </ul> <li><strong>day</strong></li> <ul> <li><strong>Description:</strong> Date of the recorded data.</li> <li><strong>Format:</strong> YYYY-MM-DD (e.g., 2023-03-28).</li> </ul> <li><strong>geometry</strong></li> <ul> <li><strong>Description:</strong> Polygon coordinates of the grid cell in Well-Known Text (WKT) format.</li> <li><strong>Format:</strong> POLYGON((longitude latitude, ...)) (e.g., POLYGON((-36.0 -10.0, -35.5 -10.0, -35.5 -9.5, -36.0 -9.5, -36.0 -10.0))).</li> </ul> <li><strong>flights</strong></li> <ul> <li><strong>Description:</strong> Number of aircraft flights that passed through the grid on that day.</li> <li><strong>Format:</strong> Integer (e.g., 28).</li> </ul> <li><strong>GPS_jumps</strong></li> <ul> <li><strong>Description:</strong> Number of reported GNSS "jump" anomalies (possible spoofing incidents) in the grid on that day.</li> <li><strong>Format:</strong> Integer (e.g., 1).</li> </ul> <li><strong>GPS_gaps</strong></li> <ul> <li><strong>Description:</strong> Number of reported GNSS "gap" anomalies, indicating gaps in aircraft routes, in the grid on that day.</li> <li><strong>Format:</strong> Integer (e.g., 0).</li> </ul> <li><strong>gaps_density</strong></li> <ul> <li><strong>Description:</strong> Density of GNSS gaps, calculated as the number of gaps divided by the number of flights.</li> <li><strong>Format:</strong> Decimal (e.g., 0).</li> </ul> <li><strong>jumps_density</strong></li> <ul> <li><strong>Description:</strong> Density of GNSS jumps, calculated as the number of jumps divided by the number of flights.</li> <li><strong>Format:</strong> Decimal (e.g., 0.035714286).</li> </ul> <li><strong>event_id_cnty</strong></li> <ul> <li><strong>Description:</strong> ACLED event ID corresponding to political violence events in the grid on that day.</li> <li><strong>Format:</strong> String (e.g., BRA69267).</li> </ul> <li><strong>disorder_type</strong></li> <ul> <li><strong>Description:</strong> Type of disorder as classified by ACLED (e.g., "Political violence").</li> <li><strong>Format:</strong> String.</li> </ul> <li><strong>event_type</strong></li> <ul> <li><strong>Description:</strong> General category of the event according to ACLED (e.g., "Violence against civilians").</li> <li><strong>Format:</strong> String.</li> </ul> <li><strong>sub_event_type</strong></li> <ul> <li><strong>Description:</strong> Specific subtype of the event as per ACLED classification (e.g., "Attack").</li> <li><strong>Format:</strong> String.</li> </ul> <li><strong>acled_count</strong></li> <ul> <li><strong>Description:</strong> Number of ACLED events in the grid on that day.</li> <li><strong>Format:</strong> Integer (e.g., 1).</li> </ul> <li><strong>acled_flag</strong></li> <ul> <li><strong>Description:</strong> Indicator of ACLED event presence in the grid on that day (0 for no events, 1 for one or more events).</li> <li><strong>Format:</strong> Integer (0 or 1).</li> </ul> </ol> <p><strong>&nbsp;</strong></p> <p><strong>Data Fields: </strong>Monthly_GNSS_Anomalies_and_ACLED-2023-V9.csv</p> <p>The file contains monthly aggregated GNSS anomaly and ACLED event data per grid cell. The structure and meaning of each field are detailed below:</p> <ol> <li><strong>grid_id</strong></li> <ul> <li><strong>Description</strong>: Unique identifier for a grid cell on Earth measuring 0.5&deg; latitude by 0.5&deg; longitude.</li> <li><strong>Format</strong>: String combining latitude and longitude (e.g., -0.5_-79.0).</li> </ul> <li><strong>year_month</strong></li> <ul> <li><strong>Description</strong>: Month and year of the aggregated data.</li> <li><strong>Format</strong>: String in Mon-YY format (e.g., Jan-23).</li> </ul> <li><strong>geometry</strong></li> <ul> <li><strong>Description</strong>: Polygon coordinates of the grid cell in Well-Known Text (WKT) format.</li> <li><strong>Format</strong>: POLYGON((longitude latitude, ...))<br>(e.g., POLYGON((-79.0 -0.5, -78.5 -0.5, -78.5 0.0, -79.0 0.0, -79.0 -0.5))).</li> </ul> <li><strong>flights</strong></li> <ul> <li><strong>Description</strong>: Total number of aircraft flights that passed through the grid cell during the month.</li> <li><strong>Format</strong>: Integer (e.g., 1230).</li> </ul> <li><strong>GPS_jumps</strong></li> <ul> <li><strong>Description</strong>: Total number of GNSS "jump" anomalies (possible spoofing events) in the grid cell during the month.</li> <li><strong>Format</strong>: Integer (e.g., 13).</li> </ul> <li><strong>GPS_gaps</strong></li> <ul> <li><strong>Description</strong>: Total number of GNSS "gap" anomalies, indicating interruptions in aircraft routes, during the month.</li> <li><strong>Format</strong>: Integer (e.g., 0).</li> </ul> <li><strong>event_id_cnty</strong></li> <ul> <li><strong>Description</strong>: Semicolon-separated list of ACLED event IDs associated with the grid cell during the month.</li> <li><strong>Format</strong>: String (e.g., ECU3151;ECU3158;ECU3150).</li> </ul> <li><strong>disorder_type</strong></li> <ul> <li><strong>Description</strong>: Semicolon-separated list of disorder types (e.g., "Political violence", "Demonstrations") reported by ACLED in that grid cell during the month.</li> <li><strong>Format</strong>: String.</li> </ul> <li><strong>event_type</strong></li> <ul> <li><strong>Description</strong>: Semicolon-separated list of high-level ACLED event types (e.g., "Riots", "Protests").</li> <li><strong>Format</strong>: String.</li> </ul> <li><strong>sub_event_type</strong></li> </ol> <ul> <li><strong>Description</strong>: Semicolon-separated list of detailed subtypes of ACLED events (e.g., "Mob violence", "Armed clash").</li> <li><strong>Format</strong>: String.</li> </ul> <ol> <li><strong>acled_count</strong></li> </ol> <ul> <li><strong>Description</strong>: Total number of ACLED conflict events in the grid cell during the month.</li> <li><strong>Format</strong>: Integer (e.g., 2).</li> </ul> <ol> <li><strong>acled_flag</strong></li> </ol> <ul> <li><strong>Description</strong>: Conflict presence indicator: 1 if any ACLED event occurred in the grid cell during the month, otherwise 0.</li> <li><strong>Format</strong>: Integer (0 or 1).</li> </ul> <ol> <li><strong>gaps_density</strong></li> </ol> <ul> <li><strong>Description</strong>: Monthly density of GNSS gaps, calculated as GPS_gaps / flights.</li> <li><strong>Format</strong>: Decimal (e.g., 0.0).</li> </ul> <ol> <li><strong>jumps_density</strong></li> </ol> <ul> <li><strong>Description</strong>: Monthly density of GNSS jumps, calculated as GPS_jumps / flights.</li> <li><strong>Format</strong>: Decimal (e.g., 0.0106).</li> </ul> <p><strong>&nbsp;</strong></p> <p><strong>Data Sources</strong></p> <ul> <li><strong>GNSS Anomalies Data:</strong></li> <ul> <li>Calculated from ADS-B (Automatic Dependent Surveillance-Broadcast) messages obtained via the OpenSky Network's Trino database.</li> <li>GNSS anomalies include "jumps" (potential spoofing incidents) and "gaps" (interruptions in aircraft route data).</li> </ul> <li><strong>Political Violence Events Data:</strong></li> <ul> <li>Sourced from the ACLED database, which provides detailed information on political violence and protest events worldwide.</li> </ul> </ul> <p><strong>Temporal and Spatial Coverage</strong></p> <ul> <li><strong>Temporal Coverage:</strong></li> <ul> <li>From January 1, 2023, to December 31, 2023.</li> <li>Daily records provide temporal granularity for time-series analysis.</li> </ul> <li><strong>Spatial Coverage:</strong></li> <ul> <li>Global coverage with grid cells measuring 0.5 degrees latitude by 0.5 degrees longitude.</li> <li>Each grid cell represents an area on Earth's surface, facilitating spatial analysis.</li> </ul> </ul> <p><strong>Usage and Applications</strong></p> <ul> <li><strong>Security Analysis:</strong></li> <ul> <li>Assess potential correlations between GNSS anomalies and political violence events.</li> <li>Identify regions with increased risk of GNSS spoofing or signal disruption.</li> </ul> <li><strong>Research and Development:</strong></li> <ul> <li>Develop models to predict socio-political events based on GNSS anomalies.</li> <li>Study the impact of political instability on aviation safety.</li> </ul> <li><strong>Policy and Decision Making:</strong></li> <ul> <li>Inform aviation authorities and policymakers about regions requiring enhanced navigation security measures.</li> <li>Support conflict analysis and monitoring efforts.</li> </ul> </ul> <p>&nbsp;</p> <p>&nbsp;</p>

opencc-by-4.0Nov 2024View details →
zenodo44/100

Dataset for Investigating Anomalies in Compute Clusters

<p><strong>Abstract</strong></p><p>The dataset was collected for 332 compute nodes throughout May 19 - 23, 2023. May 19 - 22 characterizes normal compute cluster behavior, while May 23 includes an anomalous event. The dataset includes eight CPU, 11 disk, 47 memory, and 22 Slurm metrics. It represents five distinct hardware configurations and contains over one million records, totaling more than 180GB of raw data.</p><p><strong>Background</strong></p><p>Motivated by the goal to develop a digital twin of a compute cluster, the dataset was collected using a Prometheus server (1) scraping the Thomas Jefferson National Accelerator Facility (JLab) batch cluster used to run an assortment of physics analysis and simulation jobs, where analysis workloads leverage data generated from the laboratory's electron accelerator, and simulation workloads generate large amounts of flat data that is then carved to verify amplitudes. Metrics were scraped from the cluster throughout May 19 - 23, 2023. Data from May 19 to May 22 primarily reflected normal system behavior, while May 23, 2023, recorded a notable anomaly. This anomaly was severe enough to necessitate intervention by JLab IT Operations staff.</p><p>The metrics were collected from CPU, disk, memory, and Slurm. Metrics related to CPU, disk, and memory provide insights into the status of individual compute nodes. Furthermore, Slurm metrics collected from the network have the capability to detect anomalies that may propagate to compute nodes executing the same job.</p><p><strong>Usage Notes</strong></p><p>While the data from May 19 - 22 characterizes normal compute cluster behavior, and May 23 includes anomalous observations, the dataset cannot be considered labeled data. The set of nodes and the exact start and end time affected nodes demonstrate abnormal effects are unclear. Thus, the dataset could be used to develop unsupervised machine-learning algorithms to detect anomalous events in a batch cluster.</p><p><a href="https://doi.org/10.48550/arXiv.2311.16129">https://doi.org/10.48550/arXiv.2311.16129</a></p>

opencc-by-4.0Oct 2023View details →
zenodo44/100

The Automotive Visual Inspection Dataset (AutoVI): A Genuine Industrial Production Dataset for Unsupervised Anomaly Detection

<p><strong>See the official website: <a href="https://autovi.utc.fr">https://autovi.utc.fr</a></strong></p> <p>Modern industrial production lines must be set up with robust defect inspection modules that are able to withstand high product variability. This means that in a context of industrial production, new defects that are not yet known may appear, and must therefore be identified.</p> <p>On industrial production lines, the typology of potential defects is vast (texture, part failure, logical defects, etc.). Inspection systems must therefore be able to detect non-listed defects, i.e. not-yet-observed defects upon the development of the inspection system. To solve this problem, research and development of unsupervised AI algorithms on real-world data is required.</p> <p>Renault Group and the Universit&eacute; de technologie de Compi&egrave;gne (Roberval and Heudiasyc Laboratories) have jointly developed the <em>Automotive Visual Inspection Dataset (AutoVI)</em>, the purpose of which is to be used as a scientific benchmark to compare and develop advanced unsupervised anomaly detection algorithms under real production conditions. The images were acquired on Renault Group's automotive production lines, in a genuine industrial production line environment, with variations in brightness and lighting on constantly moving components. This dataset is representative of actual data acquisition conditions on automotive production lines.</p> <p>The dataset contains 3950 images, split into 1530 training images and 2420 testing images.</p> <p>The evaluation code can be found at&nbsp;<a href="https://github.com/phcarval/autovi_evaluation_code">https://github.com/phcarval/autovi_evaluation_code</a>.</p> <p><strong>Disclaimer</strong><br>All defects shown were intentionally created on Renault Group's production lines for the purpose of producing this dataset. The images were examined and labeled by Renault Group experts, and all defects were corrected after shooting.</p> <p><strong>License</strong><br>Copyright &copy; 2023-2024 Renault Group</p> <p>This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of the license, visit <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/">https://creativecommons.org/licenses/by-nc-sa/4.0/</a>.</p> <p>For using the data in a way that falls under the commercial use clause of the license, please contact us.</p> <p><strong>Attribution</strong><br>Please use the following for citing the dataset in scientific work:</p> <p>Carvalho, P., Lafou, M., Durupt, A., Leblanc, A., &amp; Grandvalet, Y. (2024). The Automotive Visual Inspection Dataset (AutoVI): A Genuine Industrial Production Dataset for Unsupervised Anomaly Detection [Dataset]. <a href="https://doi.org/10.5281/zenodo.10459003">https://doi.org/10.5281/zenodo.10459003</a></p> <p><strong>Contact</strong><br>If you have any questions or remarks about this dataset, please contact us at philippe.carvalho@utc.fr, meriem.lafou@renault.com, alexandre.durupt@utc.fr, antoine.leblanc@renault.com, yves.grandvalet@utc.fr.</p> <p><strong>Changelog</strong></p> <ul> <li><em>v1.0.0</em> <ul> <li>Cropped engine_wiring, pipe_clip and pipe_staple images</li> <li>Reduced tank_screw, underbody_pipes and underbody_screw image sizes</li> </ul> </li> <li><em>v0.1.1</em> <ul> <li>Added ground truth segmentation maps</li> <li>Fixed categorization of some images</li> <li>Added new defect categories</li> <li>Removed tube_fastening and kitting_cart</li> <li>Removed duplicates in pipe_clip</li> </ul> </li> </ul>

opencc-by-nc-sa-4.0Feb 2024View details →
zenodo44/100

CESNET-TimeSeries24: Time Series Dataset for Network Traffic Anomaly Detection and Forecasting

<h2><strong>CESNET-TimeSeries24: The dataset for network traffic forecasting and anomaly detection</strong></h2> <p>The dataset called CESNET-TimeSeries24 was collected by long-term monitoring of selected statistical metrics for 40 weeks for each IP address on the ISP network CESNET3 (Czech Education and Science Network). The dataset encompasses network traffic from more than 275,000 active IP addresses, assigned to a wide variety of devices, including office computers, NATs, servers, WiFi routers, honeypots, and video-game consoles found in dormitories. Moreover, the dataset is also rich in network anomaly types since it contains all types of anomalies, ensuring a comprehensive evaluation of anomaly detection methods.<br><br>Last but not least, the CESNET-TimeSeries24 dataset provides traffic time series on institutional and IP subnet levels to cover all possible anomaly detection or forecasting scopes. Overall, the time series dataset was created from the 66 billion IP flows that contain 4 trillion packets that carry approximately 3.7 petabytes of data. The CESNET-TimeSeries24 dataset is a complex real-world dataset that will finally bring insights into the evaluation of forecasting models in real-world environments.<br><br></p> <p>Please cite the usage of our dataset as:</p> <blockquote> <p>Koumar, J., Hynek, K., Čejka, T. <em>et al.</em> CESNET-TimeSeries24: Time Series Dataset for Network Traffic Anomaly Detection and Forecasting. <em>Sci Data</em> <strong>12</strong>, 338 (2025). https://doi.org/10.1038/s41597-025-04603-x<br><br>@Article{cesnettimeseries24,<br>&nbsp;&nbsp;&nbsp; author={Koumar, Josef and Hynek, Karel and {\v{C}}ejka, Tom{\'a}{\v{s}} and {\v{S}}i{\v{s}}ka, Pavel},<br>&nbsp;&nbsp;&nbsp; title={CESNET-TimeSeries24: Time Series Dataset for Network Traffic Anomaly Detection and Forecasting},<br>&nbsp;&nbsp;&nbsp; journal={Scientific Data},<br>&nbsp;&nbsp;&nbsp; year={2025},<br>&nbsp;&nbsp;&nbsp; month={Feb},<br>&nbsp;&nbsp;&nbsp; day={26},<br>&nbsp;&nbsp;&nbsp; volume={12},<br>&nbsp;&nbsp;&nbsp; number={1},<br>&nbsp;&nbsp;&nbsp; pages={338},<br>&nbsp;&nbsp;&nbsp; issn={2052-4463},<br>&nbsp;&nbsp;&nbsp; doi={10.1038/s41597-025-04603-x},<br>&nbsp;&nbsp;&nbsp; url={https://doi.org/10.1038/s41597-025-04603-x}<br>}<br><br></p> </blockquote> <p>&nbsp;</p> <h3>Time series</h3> <p>We create evenly spaced time series for each IP address by aggregating IP flow records into time series datapoints. The created datapoints represent the behavior of IP addresses within a defined time window of 10 minutes. The vector of time-series metrics v_{ip, i} describes the IP address ip in the i-th time window. Thus, IP flows for vector v_{ip, i} are captured in time windows starting at t_i and ending at t_{i+1}. The&nbsp;time series are built from these datapoints.&nbsp;&nbsp;</p> <p>Datapoints created by the aggregation of IP flows contain the following time-series metrics:</p> <ul> <li><strong><em>Simple volumetric metrics:</em></strong> the number of IP flows, the number of packets, and the transmitted data size (i.e. number of bytes)</li> <li><strong><em>Unique volumetric metrics:</em></strong> the number of unique destination IP addresses, the number of unique destination Autonomous System Numbers (ASNs), and the number of unique destination transport layer ports. The aggregation of \textit{Unique volumetric metrics} is memory intensive since all unique values must be stored in an array. We used a server with 41 GB of RAM, which was enough for 10-minute aggregation on the ISP network. &nbsp;&nbsp;</li> <li><strong><em>Ratios metrics:</em></strong> the ratio of UDP/TCP packets, the ratio of UDP/TCP transmitted data size, the direction ratio of packets, and the direction ratio of transmitted data size</li> <li><em><strong>Average metrics:</strong></em> the average flow duration, and the average Time To Live (TTL)</li> </ul> <p>&nbsp;</p> <p><strong>Multiple time aggregation:&nbsp;</strong> The original datapoints in the dataset are aggregated by 10 minutes of network traffic. The size of the aggregation interval influences anomaly detection procedures, mainly the training speed of the detection model. However, the 10-minute intervals can be too short for longitudinal anomaly detection methods. Therefore, we added two more aggregation intervals to the datasets--1 hour and 1 day.</p> <p><strong>Time series of institutions:</strong>&nbsp; We identify 283 institutions inside the CESNET3 network. These time series aggregated per each institution ID provide a view of the institution's data.&nbsp;</p> <p><strong>Time series of institutional subnets:</strong> We identify 548 institution subnets inside the CESNET3 network. These time series aggregated per each institution ID provide a view of the institution subnet's data.&nbsp;</p> <p>&nbsp;</p> <h3>Data Records</h3> <p>The file hierarchy is described below:</p> <blockquote> <p>cesnet-timeseries24/</p> <p>&nbsp;&nbsp;&nbsp;&nbsp; |- institution_subnets/</p> <p>&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; &nbsp;&nbsp; |- agg_10_minutes/&lt;id_institution&gt;.csv</p> <p>&nbsp; &nbsp;&nbsp; | &nbsp; &nbsp; |- agg_1_hour/&lt;id_institution&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_1_day/&lt;id_institution&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- identifiers.csv</p> <p>&nbsp; &nbsp; &nbsp;|- institutions/</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_10_minutes/&lt;id_institution_subnet&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_1_hour/&lt;id_institution_subnet&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_1_day/&lt;id_institution_subnet&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- identifiers.csv</p> <p>&nbsp; &nbsp; &nbsp;|- ip_addresses_full/</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_10_minutes/&lt;id_ip_folder&gt;/&lt;id_ip&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_1_hour/&lt;id_ip_folder&gt;/&lt;id_ip&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- agg_1_day/&lt;id_ip_folder&gt;/&lt;id_ip&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp; |- identifiers.csv</p> <p>&nbsp; &nbsp; &nbsp;|- ip_addresses_sample/</p> <p>&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp;&nbsp; |- agg_10_minutes/&lt;id_ip&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; |- agg_1_hour/&lt;id_ip&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; |- agg_1_day/&lt;id_ip&gt;.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; |- identifiers.csv</p> <p>&nbsp; &nbsp; &nbsp;|- times/</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp;&nbsp;&nbsp; |- times_10_minutes.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; |- times_1_hour.csv</p> <p>&nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; |- times_1_day.csv</p> <p>&nbsp; &nbsp; &nbsp;|- ids_relationship.csv<br>&nbsp; &nbsp; &nbsp;|- weekends_and_holidays.csv</p> </blockquote> <p>The following list describes time series data fields in CSV files:</p> <ul> <li><strong>id_time: &nbsp;</strong>Unique identifier for each aggregation interval within the time series, used to segment the dataset into specific time periods for analysis.</li> <li><strong>n_flows: </strong>Total number of flows observed in the aggregation interval, indicating the volume of distinct sessions or connections for the IP address.</li> <li><strong>n_packets:&nbsp;</strong>Total number of packets transmitted during the aggregation interval, reflecting the packet-level traffic volume for the IP address.</li> <li><strong>n_bytes: </strong>Total number of bytes transmitted during the aggregation interval, representing the data volume for the IP address.</li> <li><strong>n_dest_ip: </strong>Number of unique destination IP addresses contacted by the IP address during the aggregation interval, showing the diversity of endpoints reached.</li> <li><strong>n_dest_asn: </strong>Number of unique destination Autonomous System Numbers (ASNs) contacted by the IP address during the aggregation interval, indicating the diversity of networks reached.</li> <li><strong>n_dest_port: </strong>Number of unique destination transport layer ports contacted by the IP address during the aggregation interval, representing the variety of services accessed.</li> <li><strong>tcp_udp_ratio_packets: </strong>Ratio of packets sent using TCP versus UDP by the IP address during the aggregation interval, providing insight into the transport protocol usage pattern. This metric belongs to the interval &lt;0, 1&gt; where 1 is when all packets are sent over TCP, and 0 is when all packets are sent over UDP.</li> <li><strong>tcp_udp_ratio_bytes:</strong> Ratio of bytes sent using TCP versus UDP by the IP address during the aggregation interval, highlighting the data volume distribution between protocols. This metric belongs to the interval &lt;0, 1&gt; &nbsp;with same rule as <em>tcp_udp_ratio_packets</em>.</li> <li><strong>dir_ratio_packets: </strong>Ratio of packet directions (inbound versus outbound) for the IP address during the aggregation interval, indicating the balance of traffic flow directions. This metric belongs to the interval &lt;0, 1&gt;, where 1 is when all packets are sent in the outgoing direction from the monitored IP address, and 0 is when all packets are sent in the incoming direction to the monitored IP address.</li> <li><strong>dir_ratio_bytes: </strong>Ratio of byte directions (inbound versus outbound) for the IP address during the aggregation interval, showing the data volume distribution in traffic flows. This metric belongs to the interval &lt;0, 1&gt; with the same rule as <em>dir_ratio_packets</em>.</li> <li><strong>avg_duration: </strong>Average duration of IP flows for the IP address during the aggregation interval, measuring the typical session length.</li> <li><strong>avg_ttl: </strong>Average Time To Live (TTL) of IP flows for the IP address during the aggregation interval, providing insight into the lifespan of packets.</li> </ul> <p>Moreover, the time series created by re-aggregation contains following time series metrics instead of <strong>n_dest_ip</strong>,&nbsp;<strong>n_dest_asn</strong>, and&nbsp;<strong>n_dest_port</strong>:</p> <ul> <li><strong>sum_n_dest_ip:&nbsp;</strong>Sum of numbers of unique destination IP addresses.</li> <li><strong>avg_n_dest_ip:&nbsp;</strong>The average number of unique destination IP addresses.</li> <li><strong>std_n_dest_ip: </strong>Standard deviation of numbers of unique destination IP addresses.</li> <li><strong>sum_n_dest_asn:&nbsp;</strong>Sum of numbers of unique destination ASNs.</li> <li><strong>avg_n_dest_asn:&nbsp;</strong>The average number of unique destination ASNs.</li> <li><strong>std_n_dest_asn: </strong>Standard deviation of numbers of unique destination ASNs)</li> <li><strong>sum_n_dest_port: </strong>Sum of numbers of unique destination transport layer ports.</li> <li><strong>avg_n_dest_port:&nbsp;</strong>&nbsp;The average number of unique destination transport layer ports.</li> <li><strong>std_n_dest_port: </strong>Standard deviation of numbers of unique destination transport layer ports.</li> </ul> <p>&nbsp;</p> <p>Moreover, files &nbsp;<em>identifiers.csv</em> in each dataset type contain IDs of time series that are present in the dataset. Furthermore, the <em>ids_relationship.csv</em> file contains a relationship between IP addresses, Institutions, and institution subnets. The <em>weekends_and_holidays.csv</em> contains information about the non-working days in the Czech Republic.</p>

opencc-by-4.0Sep 2024View details →
zenodo44/100

Tri-hourly dataset of wind and wave anomalies of the GFS and WAVEWATCH III models in the entire tropic region (TROPWA).

<p>This dataset contains the anomalies of the total height and peak period of the waves and of the zonal and meridional components of the wind at 10 m above the sea surface obtained from the outputs of the GFS and WAVEWATCH III coupled global models in the entire tropical region (180&deg;W to 178.75&deg;E longitude/30&deg;S to 30&deg;N latitude), with a spatial resolution of 1.25&deg;x1&deg;. It is made up of two files in NetCDF format, where the data for wind anomalies (speed module and its zonal and meridional components) and wave anomalies (total wave height and peak period) are contained separately. This dataset was created in order to study all types of tropical storms, cold fronts and other physical processes that influence significant changes in wave parameters, as well as for the design and construction of coastal engineering works. The authors thanks to Tropical Atlantic Interdisciplinary Laboratory on physical, biogeochemical, ecological and human dynamics (IJL TAPIOCA).</p>

opencc-by-4.0Jan 2019View details →
zenodo44/100

Hazards&Robots: A Dataset for Visual Anomaly Detection in Robotics

<p>This is the final version of our dataset; we further expand the Corridor scenario.</p> <p>This new version of Corridor includes 20 anomalies and the total frames are 324,408.</p> <p>In this version, we release feature embeddings extracted using a CLIP ViT-B/32 model.</p> <p>This dataset is part of a Data in Brief paper submission.</p> <p>For more information check https://github.com/idsia-robotics/hazard-detection</p> <p>&nbsp;</p>

opencc-by-4.0Mar 2022View details →
zenodo44/100

Controlled Anomalies Time Series (CATS) Dataset

<p>The Controlled Anomalies Time Series (CATS) Dataset consists of commands, external stimuli, and telemetry readings of a simulated complex dynamical system with 200 injected anomalies.</p> <p>The CATS Dataset exhibits a set of desirable properties that make it very suitable for benchmarking<strong> Anomaly Detection Algorithms in Multivariate Time Series&nbsp;</strong>[1]:</p> <ul> <li><strong>Multivariate (17 variables) </strong>including sensors reading and control signals. It simulates the operational behaviour of an arbitrary complex system including: <ul> <li><strong>4 Deliberate Actuations / Control Commands sent by a simulated operator / controller</strong>, for instance, commands of an operator to turn ON/OFF some equipment.</li> <li><strong>3 Environmental Stimuli / External Forces</strong> acting on the system and affecting its behaviour, for instance, the wind affecting the orientation of a large ground antenna.</li> <li><strong>10 Telemetry Readings</strong> representing the observable states of the complex system by means of sensors, for instance, a position, a temperature, a pressure, a voltage, current, humidity, velocity, acceleration, etc.</li> </ul> </li> <li><strong>5 million timestamps</strong>. Sensors readings are at 1Hz sampling frequency. <ul> <li><strong>1 million nominal </strong>observations (the first 1 million datapoints). This is suitable to start learning the &quot;normal&quot; behaviour.</li> <li><strong>4 million</strong> observations that include both <strong>nominal and anomalous segments</strong>. This is suitable to evaluate both semi-supervised approaches (novelty detection) as well as unsupervised approaches (outlier detection).</li> </ul> </li> <li><strong>200 anomalous segments. </strong>One anomalous segment may contain several successive anomalous observations / timestamps. Only the last 4 million observations contain anomalous segments.</li> <li><strong>Different types of anomalies </strong>to understand what anomaly types can be detected by different approaches. The categories are available in the dataset and in the metadata.</li> <li><strong>Fine control over ground truth.</strong> As this is a simulated system with deliberate anomaly injection, the start and end time of the anomalous behaviour is known very precisely. In contrast to real world datasets, there is no risk that the ground truth contains mislabelled segments which is often the case for real data.</li> <li><strong>Suitable for root cause analysis.</strong> In addition to the anomaly category, the time series channel in which the anomaly first developed itself is recorded and made available as part of the metadata. This can be useful to evaluate the performance of algorithm to trace back anomalies to the right root cause channel.</li> <li><strong>Affected channels.</strong> In addition to the knowledge of the root cause channel in which the anomaly first developed itself, we provide information of channels possibly affected by the anomaly. This can also be useful to evaluate the explainability of anomaly detection systems which may point out to the anomalous channels (root cause and affected).</li> <li><strong>Obvious anomalies.</strong> The simulated anomalies have been designed to be &quot;easy&quot; to be detected for human eyes (i.e., there are very large spikes or oscillations), hence also detectable for most algorithms. It makes this synthetic dataset useful for screening tasks (i.e., to eliminate algorithms that are not capable to detect those obvious anomalies). However, during our initial experiments, the dataset turned out to be challenging enough even for state-of-the-art anomaly detection approaches, making it suitable also for regular benchmark studies.</li> <li><strong>Context provided. </strong>Some variables can only be considered anomalous in relation to other behaviours. A typical example consists of a light and switch pair. The light being either on or off is nominal, the same goes for the switch, but having the switch on and the light off shall be considered anomalous. In the CATS dataset, users can choose (or not) to use the available context, and external stimuli, to test the usefulness of the context for detecting anomalies in this simulation.</li> <li><strong>Pure signal ideal for robustness-to-noise analysis.</strong> The simulated signals are provided without noise: while this may seem unrealistic at first, it is an advantage since users of the dataset can decide to add on top of the provided series any type of noise and choose an amplitude. This makes it well suited to test how sensitive and robust detection algorithms are against various levels of noise.</li> <li><strong>No missing data.</strong> You can drop whatever data you want to assess the impact of missing values on your detector with respect to a clean baseline.</li> </ul> <p><strong>Change Log</strong></p> <p>Version 2</p> <ul> <li><strong>Metadata:</strong> we include a metadata.csv with information about: <ul> <li>Anomaly categories</li> <li>Root cause channel (signal in which the anomaly is first visible)</li> <li>Affected channel (signal in which the anomaly might propagate) through coupled system dynamics</li> </ul> </li> <li><strong>Removal of anomaly overlaps:</strong> version 1 contained anomalies which overlapped with each other resulting in only 190 distinct anomalous segments. Now, there are no more anomaly overlaps.</li> <li><strong>Two data files: </strong>CSV and parquet for convenience.</li> </ul> <p>[1] Example Benchmark of Anomaly Detection in Time Series: &ldquo;Sebastian Schmidl, Phillip Wenig, and Thorsten Papenbrock. Anomaly Detection in Time Series: A Comprehensive Evaluation. PVLDB, 15(9): 1779 - 1797, 2022. doi:10.14778/3538598.3538602&rdquo;</p> <p><strong>About Solenix</strong></p> <p>Solenix is an international company providing software engineering, consulting services and software products for the space market. Solenix is a dynamic company that brings innovative technologies and concepts to the aerospace market, keeping up to date with technical advancements and actively promoting spin-in and spin-out technology activities. We combine modern solutions which complement conventional practices. We aspire to achieve maximum customer satisfaction by fostering collaboration, constructivism, and flexibility.</p>

opencc-by-4.0Feb 2023View details →
zenodo40/100

Dataset of Hyperspectral Melt Pool Signatures and Thermal Anomalies in DED of 316L steel

<p><strong>Description of the dataset</strong><br>The dataset includes in-situ melt pool signatures (hyperspectral NIR images) during the Directed Energy Deposition of 316L steel for several classes of thermal anomalies. Thermal anomalies were created during the process by varying the scanning speed.</p> <p>Samples were printed on the MiCLAD machine at the Vrije Universiteit Brussel (Belgium).</p> <p>Process and acquisition parameters:</p> <ul> <li>Hardware: <ul> <li>Machine: MiCLAD (Vrije Universiteit Brussel)</li> <li>Laser: High-YAG BIMO 1064nm, 2.55mm fibre, flat-top</li> <li>Nozzle: Harald-Dickler HighNo 4.0</li> </ul> </li> <li>Process parameters: <ul> <li>Laser power: 600 W</li> <li>Scanning speed: 500/700/900/1100/1300 mm/min</li> <li>Powder: 316L 45-105 um</li> <li>Powder flow rate: 3.5 g/m</li> <li>Layer thickness: 0.2 mm</li> </ul> </li> <li>Image characteristics: <ul> <li>Camera: 3D-One Avior AX-M25NIR</li> <li>Hyperspectral filter layout: 5x5 (25 wavelengths per image)</li> </ul> </li> </ul> <p><strong>Description of the files</strong></p> <ul> <li>CSV dataset (hyperspectral_nir_meltpool_dataset.csv): List of filename, sample, label, time (ms), X and Z position (mm) and local scanning speed (mm/min) for all melt pool signatures. Thermal anomalies are labelled accordingly: <ul> <li>0 : baseline</li> <li>1 : edge</li> <li>2 : underheat</li> <li>3 : strong underheat</li> <li>4 : overheat</li> <li>5 : strong overheat</li> </ul> </li> <li>Melt pool signatures (hyperspectral_nir_meltpool_images_*.zip): Raw .tif thermal images of the melt pool taken in-situ. The raw images must debayered to retrieve the spectral information, see the Python function and example script.&nbsp;</li> <li>Python debayer function (debayer.py): Debayering function to retrieve the spectral information from the raw images.&nbsp;</li> </ul>

opencc-by-4.0Dec 2023View details →
zenodo40/100

A Global Dataset of Standardized Moisture Anomaly Index Incorporating Snow Dynamics (SZIsnow) from 1948 to 2010

<p>The SZI<sub>snow</sub> dataset was calculated based on systematic physical fields from the Global Land Data Assimilation System Version 2 (GLDAS-2) with the Noah land surface model. This SZI<sub>snow</sub> dataset considers different physical water-energy processes, especially snow processes. The evaluation shows the dataset is capable of investigating different types of droughts across different timescales. The assessment also indicates that the dataset has an adequate performance to capture droughts across different spatial scales. The consideration of snow processes improved the capability of SZI<sub>snow</sub>, and the improvement is evident over snow-covered areas (e.g., Arctic region) and high-altitude areas (e.g., Tibet Plateau). Moreover, the analysis also implies that SZI<sub>snow</sub> dataset is able to well capture large-scale drought events across the world. This drought dataset has high application potential for monitoring, assessing, and supplying information on drought, and also can serve as a valuable resource for drought studies.</p>

opencc-by-4.0Oct 2021View details →
zenodo40/100

Dataset for: An experimental comparison of anomaly detection methods for collaborative robot manipulators

<p>The dataset contains data recordings from a UR5e robot during normal and anomalous operation and is recorded to support the authors Master thesis project and the associated Paper:&nbsp;<em>&quot;An Experimental Comparison of Anomaly Detection Methods for Collaborative Robot Manipulators&quot;&nbsp;</em>(inProceeding).</p> <p>An in-depth description of the dataset can be found in the pdf uploaded with the dataset and an example of a data loader is also provided.</p>

opencc-by-nc-4.0Jan 2022View details →
zenodo40/100

Dataset for Anomaly Detection in a Production Wireless Mesh Community Network

<p>CSV dataset generated gathering data from a production wireless mesh community network. Data is gathered every 5 minutes during the interval 2021-04-13 00:00:00 to 2021-04-16 00:00:00. During the interval 2021-04-14 02:00:00 2021-04-14 17:50:00 (both included) there is the failure of a gateway in the mesh (nodeid 24).&nbsp;</p> <p>Live mesh network monitoring link: <a href="http://dsg.ac.upc.edu/qmpsu">http://dsg.ac.upc.edu/qmpsu</a></p> <p>The dataset consists of single gzip compressed CSV file. The first line of the file is a header describing the features. The first column is a GMT timestamp of the sample in the format as &quot;2021-03-16 00:00:00&quot;.&nbsp; The rest of the columns provide the comma-separated values of the features collected from each node in the corresponding capture.</p> <p>A suffix with the nodeid is added to each feature. For instance, the feature having the number of processes of node with nodeid 24 is named as &quot;processes-24&quot;. In total, 63 different nodes showed up during the samples, each being assigned a different nodeid.</p> <p><br> Features are of two types: (i) absolute values, for instance, the CPU 1-minute load average, and (ii) counters that are monotonically increased, for instance the number of transmitted packets. We have converted counter-type kernel variables to rates, by dividing the difference between two consecutive samples, over the difference of the corresponding timestamps in seconds, as shown in the following pseudo-code:<br> &nbsp; feature.rate are columns computed from feature as<br> &nbsp; &nbsp; feature.rate &lt;- (feature[2:n]-feature[1:(n-1)])/(epoch[2:n]-epoch[1:(n-1)])<br> &nbsp; &nbsp; feature.rate &lt;- feature.rate[feature.rate &gt;= 0] # discard samples where the counter is restarted<br> &nbsp;&nbsp; where n is the number of samples</p> <p><strong>features</strong><br> - processes &nbsp;&nbsp; &nbsp;number of processes<br> - loadavg.m1 &nbsp;&nbsp; &nbsp;1 minute load average<br> - softirq.rate &nbsp;&nbsp; &nbsp;servicing softirqs<br> - iowait.rate &nbsp;&nbsp; &nbsp;waiting for I/O to complete<br> - intr.rate &nbsp;&nbsp; &nbsp;&nbsp;<br> - system.rate &nbsp;&nbsp; &nbsp;processes executing in kernel mode<br> - idle.rate &nbsp;&nbsp; &nbsp;twiddling thumbs<br> - user.rate &nbsp;&nbsp; &nbsp;normal processes executing in user mode<br> - irq.rate &nbsp;&nbsp; &nbsp;servicing interrupts<br> - ctxt.rate &nbsp;&nbsp; &nbsp;total number of context switches across all CPUs<br> - nice.rate &nbsp;&nbsp; &nbsp;niced processes executing in user mode<br> - nr_slab_unreclaimable &nbsp;&nbsp; &nbsp;The part of the Slab that can&#39;t be reclaimed under memory pressure<br> - nr_anon_pages &nbsp;&nbsp; &nbsp;anonymous memory pages<br> - swap_cache &nbsp;&nbsp; &nbsp;Memory that once was swapped out, is swapped back in but still also is in the swapfile<br> - page_tables &nbsp;&nbsp; &nbsp;Memory used to map between virtual and physical memory addresses<br> - swap &nbsp;&nbsp; &nbsp;&nbsp;<br> - eth.txe.rate &nbsp;&nbsp; &nbsp;tx errors over all ethernet interfaces<br> - eth.rxe.rate &nbsp;&nbsp; &nbsp;rx errors over all ethernet interfaces<br> - eth.txb.rate &nbsp;&nbsp; &nbsp;tx bytes over all ethernet interfaces<br> - eth.rxb.rate &nbsp;&nbsp; &nbsp;rx bytes over all ethernet interfaces<br> - eth.txp.rate &nbsp;&nbsp; &nbsp;tx packets over all ethernet interfaces<br> - eth.rxp.rate &nbsp;&nbsp; &nbsp;rx packets over all ethernet interfaces<br> - wifi.txe.rate &nbsp;&nbsp; &nbsp;tx errors over all wireless interfaces<br> - wifi.rxe.rate &nbsp;&nbsp; &nbsp;rx errors over all wireless interfaces<br> - wifi.txb.rate &nbsp;&nbsp; &nbsp;tx bytes over all wireless interfaces<br> - wifi.rxb.rate &nbsp;&nbsp; &nbsp;rx bytes over all wireless interfaces<br> - wifi.txp.rate &nbsp;&nbsp; &nbsp;tx packets over all wireless interfaces<br> - wifi.rxp.rate &nbsp;&nbsp; &nbsp;rx packets over all wireless interfaces<br> - txb.rate &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tx bytes over all ethernet and wifi interfaces<br> - txp.rate &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tx packets over all ethernet and wifi interfaces<br> - rxb.rate &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; rx bytes over all ethernet and wifi interfaces<br> - rxp.rate &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; rx packets over all ethernet and wifi interfaces<br> - sum.xb.rate&nbsp;&nbsp;&nbsp; tx+rx bytes over all ethernet and wifi interfaces<br> - sum.xp.rate&nbsp;&nbsp;&nbsp; tx+rx packets over all ethernet and wifi interfaces<br> - diff.xb.rate &nbsp; &nbsp;&nbsp; tx-rx bytes over all ethernet and wifi interfaces<br> - diff.xp.rate &nbsp; &nbsp;&nbsp; tx-rx packets over all ethernet and wifi interfaces</p>

opencc-by-4.0Feb 2022View details →

ScienceDex guides

Understand access before you commit

These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.

Compare curated datasets

Allen Brain Atlas

Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.

allen-brain-atlas
neuroscienceopenDocumentation, web resources, and API references are available online.
Last verified 2026-04-30Open record

Annotated Behaviour and Observability Dataset (ABODe)

ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.

abode-home-cage
behavioral-neuroscienceopenThe DataShare record exposes download links for annotations, documentation, license text, and the zipped per-snippet data directory.
Last verified 2026-04-30Open record

DANDI Archive for NWB datasets

DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.

dandi-nwb
electrophysiologyopenPublished Dandiset metadata and archive endpoints are available through the production DANDI API.
Last verified 2026-04-30Open record

International Brain Laboratory public data

The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.

ibl
behavioral-neuroscienceopenPublic sessions can be searched and loaded from the IBL public data server through ONE.
Last verified 2026-04-29Open record

OpenNeuro

OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.

openneuro
neuroscienceopenPublished datasets are available on demand over the internet.
Last verified 2026-04-29Open record