This dataset consists of measurements from a foot-mounted inertial measurement unit (IMU). In total, we provide data from five different test subjects travelling over more than 7.6 km. The data are combined with various forms of ground truth positioning information that can be used to evaluate the accuracy of a zero-velocity-aided, foot-mounted inertial navigation system (INS).


Herein, we provide inertial data (produced from an inertial measurement unit) collected in three different test environments. Each environment contains multiple trajectories, and we provide the raw, foot-mounted inertial measurements for each trajectory. Additionally, we include forms of ground truth for each trajectory (the form of ground truth varies within each test environment). For each trajectory, we include processed results that can be used for benchmarking other systems. Our processed results (six degree-of-freedom trajectory estimates) are generated from a baseline zero-velocity-aided inertial navigation system (INS).

Once the dataset has been downloaded, it should be unpacked into the PyShoe repository in order to use the available tools with the provided dataset: To do so, unzip the results and data folders into the main directory. The correct folder structure is as follows:

| - - pyshoe

|        | - - data

|                | - - hallway

|                | - - stairs

|                | - - vicon

|         | - - results

Following this, we refer you to the readme instructions in the Github repository for detailed instructions on how the data can be used with our open-source INS. See the individual readme files within the various data subdirectories to understand how the dataset is formatted.


Extensive experimental measurement campaigns of more than 30,000 data points of end-to-end latency measurements for the following network architecture schemes is available:

  • Unlicensed IoT (standalone LoRa)
  • Cellular IoT (standalone LTE-M)
  • Concatenated IoT (LoRa interfaced with LTE-M)

Download to access all relevant files for the open data measurements.

Related Paper:


Driving behavior plays a vital role in maintaining safe and sustainable transport, and specifically, in the area of traffic management and control, driving behavior is of great importance since specific driving behaviors are significantly related with traffic congestion levels. Beyond that, it affects fuel consumption, air pollution, public health as well as personal mental health and psychology. Use of Smartphone sensors for data acquisition has emerged as a means to understand and model driving behavior. Our aim is to analyze driving behavior using on Smartphone sensors’ data streams.


The datasets folder include .csv files of sensor data like Accelerometer, Gyroscope, etc. This data was recorded in live traffic while driver was executing certain driving events. The travel time for each one way trip was approximately 5kms - 20kms. The smartphone position was fixed horizontally in the vehicles utility box. Vehicle type used for data recording was LMV.


High-voltage batteries in battery electric vehicles face significant load fluctuations due to driving behavior. This dynamic performance of the powertrain is contrasted by the almost constant load of the auxiliary consumers. The highest auxiliary consumption is generated by the heating and air conditioning system, which decreases the vehicles range significantly. 72 real driving trips with a BMW i3 (60 Ah) were recorded, serving for model validation of a full vehicle model consisting of the powertrain and the heating circuit.


Plase see the attached readme.txt.


The dataset has Gaussian Blobs of varying samples, centers and features.  The number of samples ranges from 500 to 50,000. Similarly, the number of centers varies from 2 to 100, while the number of features varies from 2 to 2048. These different sets of Gaussian blobs can be used for testing clustering algorithms for their scalability and effectiveness. There are two kinds of files inside the compressed sets. Files ending with "_X.csv" consist of datapoints, while the files ending with "_y.csv" represent respective class data.


Please go through the documentation file before downloading the compressed zips. The PDF contains list of files that are within each compressed file.

The datapoints have real numbers up to 15 decimal places. The algorithm might converge, taking a long time because of such decimal precision. So if you need to round off the numbers, you can do that through DataFrameName.round(decimals=decimal_place).


Cyber-Physical Production Systems (CPPS) are the key enabling for industrial businesses and economic growth. The introduction of the Internet of Things (IoT) in industrial processes represents a new Internet revolution, mostly known as 4th Industrial Revolution, towards the Smart Manufacturing concept. Despite the huge interest from the industry side to innovate their production systems, in order to increase revenues at lower costs, the IoT concept is still immature and fuzzy, which increases security related risks in industrial systems.


The generation of the dataset containing OPC UA traffic was possible due to the setup and execution of a laboratory CPPS testbed. This CPPS uses OPC UA standard for horizontal and vertical communications.Regarding the CPPS testbed setup, it consists on seven nodes in the network.Each network node consist on a Raspberry Pi device, running the Python FreeOpcUa implementation. In this configuration, there are two production units, each one containing three devices, and one node representing a Manufacturing Execution System (MES). Each device implements both OPC UA server and client, where the server publish to a OPC UA variable updates regarding sensor readings and the client subscribes all OPC UA variables from all other devices in the same production unit. On the other side, the MES only implements the OPC UA client, which subscribes all OPC UA variables from all devices in both production units. Also, connected to this network, is an attack node as it is assumed that the attacker already gained access to the CPPS network.After setting up the CPPS testbed, a python implementation that implements Tshark was used to capture OPC UA packets and export this traffic to a csv file format dataset. This traffic includes both normal and anomalous behaviour. Anomalous behaviour is achieved with the malicious node, which injects attacks into the CPPS network, targeting one or more device nodes and the MES. The attacks selected for the malicious activities are:

    • Denial of Service(DoS);
    • Eavesdropping or Man-in-the-middle (MITM) attacks;
    • Impersonation or Spoofing attacks.


To perform the attacks mentioned, a python script is used, which implements the Scapy module for packet sniffing, injection and modification. Regarding the dataset generation, another python script, that implements Tshark (in this case Pyshark) was used to capture only OPC UA packets and export this traffic to a csv file format dataset. Actually, the OPC UA packets are converted to bidirectional communication flows, which are characterized by the following 32 features:

    • src_ip: Source IP address;
    • src_port: Source port;
    • dst_ip: Destination IP address;
    • dst_port: Destination port;
    • flags: TCP flag status;
    • pktTotalCount: Total packet count;
    • octetTotalCount: Total packet size;
    • avg_ps: Average packet size;
    • proto: Protocol;
    • service: OPC UA service call type;
    • service_errors: Number of service errors in OPC UA request responses;
    • status_errors: Number of status errors in OPC UA request responses;
    • msg_size: OPC UA message transport size;
    • min_msg_size: minimum OPC UA message size;
    • flowStart: Timestamp of flow start;
    • flowEnd: Timestamp of flow end;
    • flowDuration: Flow duration in seconds;
    • avg_flowDuration: Average flow duration in seconds;
    • flowInterval: Time interval between flows in seconds;
    • count: Number of connections to the same destination host as the current connection in the past two seconds;
    • srv_count: Number of connections to the same port number as the current connection in the past two seconds;
    • same_srv_rate: The percentage of connections that were to the same port number, among the connections aggregated in Count;
    • dst_host_same_src_port_rate: The percentage of connections that were to the same source port, among the connections having the same port number;
    • f_pktTotalCount: Total forward packets count;
    • f_octetTotalCount: Total forward packets size;
    • f_flowStart: Timestamp of first forward packet start;
    • f_rate: Rate at which forward packets are transmitted;
    • b_pktTotalCount: Total backwards packets count;
    • b_octetTotalCount: Total backwards packets size;
    • b_flowStart: Timestamp of first backwards packet start;
    • label: Binary label classification;
    • multi_label: Multi classification labeling.


The generated dataset has 33.567 normal instances, 74.013 DoS attack instances, 50 impersonation attack instances, and 7 MITM attack instances. This gives a total of 107.634 instances. Also, all attacks were grouped into one class (anomaly - 1) and the rest of the instances belong to the normal class (0).

For more information, please contact the author: Rui Pinto (


We provide the data corresponding to the studies of our paper Path Outlines

- Study 1: 

    - data collected:study1.csv

    - analysis: analyseStudy1.R

    - tasks: tasksStudy1.rtf

- Study 2: 

   - RDF data to run the study:

   - data collected: study2.csv

   - analysis: analyseStudy2.R

   - tasks: tasksStudy2.txt



a research data about campaign participation in Surabaya City 2015


This dataset was collected for research conducted within the project AN.ON-Next funded by the German Federal Ministry of Education and Research (BMBF) with grant number: 16KIS0371.


The data are primarily gathered with 7-point Likert scales (exceptions are shown in the documentation). Thus, the analysis requires statistical approaches which are applicable to ordinal data. Examples of how the dataset was used in prior research can be found in the documentation.