Market Overview:

The global quantum random number generator RNG sales market is expected to grow at a CAGR of 7.5% during the forecast period from 2022 to 2030. The growth of the quantum RNG market can be attributed to the increasing demand for secure communication and data security. In addition, the growing adoption of Quantum Cryptography in various applications. However, a lack of awareness about quantum cryptography among end users may restrain the growth of this market during the forecast period.

Product Definition:

Quantum Random Number Generator Sales is the process of selling quantum random number generators. These are devices that generate random numbers using the principles of quantum mechanics. They are used for security applications, such as generating cryptographic keys, and in other settings where true randomness is important.

PCIe Type:

PCIe is a high-speed I/O interconnect standard for external cards. It is used in computers, servers, storage devices, and other electronic devices. PCIe provides better performance over PCI and also uses less power; making it an ideal choice for high-end systems that require more than basic functions such as graphics adapters.

USB Type:

USB Type is a specification for a type of connector used on portable devices, such as personal computers. USB Connectors are typically rectangular with a protrusion in one corner that fits into the corresponding receptacle on the device. It has three major interfaces, namely USB Mass Storage (MS), Universal Serial Bus (USB) Power Delivery, and USB Host Control.

Application Insights:

Quantum communication is expected to be the fastest-growing application segment over the forecast period. Quantum communication offers enhanced security and privacy as compared to classical communication systems due to characteristics of quantum mechanics such as uncertainty principle, non-locality, and entanglement. Traditional Information Security is expected to be the second-fastest growing application segment over the forecast period. Traditional Information Security applications use classical security methods such as passwords, firewalls, and intrusion detection systems to protect information.

Cryptography is expected to be the third-fastest growing application segment over the forecast period. Cryptography uses mathematical algorithms to secure data and communication. The betting industry is expected to be the fourth-fastest growing application segment over the forecast period. The betting industry uses cryptography for security purposes such as preventing fraud and ensuring fairness in gambling transactions. Other is expected to be the slowest growing application segment over the forecast period. Other includes applications that are not classified into any other category

Regional Analysis:

North America dominated the global market in terms of revenue share in 2019. The region is expected to continue its dominance over the forecast period owing to the high demand for secure and private communication channels among enterprises and government agencies. Moreover, the growing adoption of PCIe-type RNGs by several key companies for their critical applications is also likely to drive the regional growth over the forecast period. Europe is expected to witness modest growth over the forecast period owing to the increasing demand for quantum-safe cryptography and other applications in the region. The Asia Pacific is expected to grow at a faster pace than other regions due to the growing adoption of blockchain technology and increased investment in RNGs by key companies in this region. The Middle East & Africa is expected to account for a small share of the global market over the forecast period, as there are limited opportunities for quantum-safe cryptography and other key applications in this region.

Growth Factors:

• Increasing demand for secure data transmission and storage.
• A growing number of cyber-attacks and data breaches.
• The proliferation of IoT devices and big data analytics.
• Development of quantum computing technology.
• Rising awareness about the benefits of using quantum random number generators.

Report Scope

Tough Tables (2T) is a dataset designed to evaluate table annotation approaches in solving the CEA and CTA tasks.
The dataset is compliant with the data format used in SemTab 2019, and it can be used as an additional dataset without any modification. The target knowledge graph is DBpedia 2016-10.
Check out the 2T GitHub repository for more details about the dataset generation.

New in v3.0: We release the updated version of 2T! The target knowledge graphs are DBpedia 2016-10 and Wikidata 20220521. Starting from this version, the dataset is split into valid and test sets.

This work is based on the following paper:

Cutrona, V., Bianchi, F., Jimenez-Ruiz, E. and Palmonari, M. (2020). Tough Tables: Carefully Evaluating Entity Linking for Tabular Data. ISWC 2020, LNCS 12507, pp. 1–16.

Note on License: This dataset includes data from the following sources. Refer to each source for license details:
- Wikipedia https://www.wikipedia.org/
- DBpedia https://dbpedia.org/
- Wikidata https://www.wikidata.org/
- SemTab 2019 https://doi.org/10.5281/zenodo.3518539
- GeoDatos https://www.geodatos.net
- The Pudding https://pudding.cool/
- Offices.net https://offices.net/
- DATA.GOV https://www.data.gov/

THIS DATA IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Changelog:

v3.0

• Both datasets require SemTab2020 CEA format (tab_id, row_id, col_id, entity).
• Tables IDs and artificial noise values differ from previous versions.
• Datasets are split into Valid and Test sets of tables.
• New GT for ToughTables-WD (2T_WD)
  • Entities Q23772518 and Q7327323 have been removed because they are no longer represented in WD
  • Updated ancestor/descendant hierarchies to evaluate CTA.
• Evaluation scripts are provided with the data sets.

v2.0

• New GT for 2T_WD
  • A few entities have been removed from the CEA GT, because they are no longer represented in WD (e.g., dbr:Devonté points to wd:Q21155080, which does not exist)
  • Tables codes and values differ from the previous version, because of the random noise.
  • Updated ancestor/descendant hierarchies to evaluate CTA.

v1.0

• New Wikidata version (2T_WD)
• Fix header for tables CTRL_DBP_MUS_rock_bands_labels.csv and CTRL_DBP_MUS_rock_bands_labels_NOISE2.csv (column 2 was reported with id 1 in target - NOTE: the affected column has been removed from the SemTab2020 evaluation)
• Remove duplicated entries in tables
• Remove rows with wrong values (e.g., the Kazakhstan entity has an empty name "''")
• Many rows and noised columns are shuffled/changed due to the random noise generator algorithm
• Remove row "Florida","Floorida","New York, NY" from TOUGH_WEB_MISSP_1000_us_cities.csv (and all its NOISE1 variants)
• Fix header of tables:
  • CTRL_WIKI_POL_List_of_current_monarchs_of_sovereign_states.csv
  • CTRL_WIKI_POL_List_of_current_monarchs_of_sovereign_states_NOISE2.csv
  • TOUGH_T2D_BUS_29414811_2_4773219892816395776_videogames_developers.csv
  • TOUGH_T2D_BUS_29414811_2_4773219892816395776_videogames_developers_NOISE2.csv

v0.1-pre

• First submission. It contains only tables, without GT and Targets.

1. Introduction

The file “gen_dd_channel.zip” is a package of a wideband multiple-input multiple-output (MIMO) stored radio channel model at 140 GHz in indoor hall, outdoor suburban, residential and urban scenarios. The package consists of 1) measured wideband double-directional multipath data sets estimated from radio channel sounding and processed through measurement-based ray-launching and 2) MATLAB code sets that allows users to generate wideband MIMO radio channels with various antenna array types, e.g., uniform planar and circular arrays at link ends.

2. What does this package do?

Outputs of the channel model

The MATLAB file “ChannelGeneratorDD_hexax.m” gives the following variables, among others. The .m file also gives optional figures illustrating antennas and radio channel responses.

Inputs to the channel model

In order for the MATLAB file “ChannelGeneratorDD_hexax.m” to run properly, the following inputs are required.

User’s parameters

When using “ChannelGeneratorDD_hexax.m”, the following choices are available.

List of files in the dataset

MATLAB codes that implement the channel model

The MATLAB files consist of the following files.

Measured multipath data

The directory "data_030123_double_directional_paths" in the package contains the following files.

References

Details of the data set are available in the following two documents:

The stored channel models

A. Nimr (ed.), "Hexa-X Deliverable D2.3 Radio models and enabling techniques towards ultra-high data rate links and capacity in 6G," April 2023, available: https://hexa-x.eu/deliverables/

@misc{Hexa-XD23,
author = {{A. Nimr (ed.)}},
title = {{Hexa-X Deliverable D2.3 Radio models and enabling techniques towards ultra-high data rate links and capacity in 6G}},
year = {2023},
month = {Apr.},
howpublished = {https://hexa-x.eu/deliverables/},
}

Derivation of the data, i.e., radio channel sounding and measurement-based ray-launching

M. F. De Guzman and K. Haneda, "Analysis of wave-interacting objects in indoor and outdoor environments at 142 GHz," IEEE Transactions on Antennas and Propagation, vol. 71, no. 12, pp. 9838-9848, Dec. 2023, doi: 10.1109/TAP.2023.3318861

@ARTICLE{DeGuzman23_TAP,
author={De Guzman, Mar Francis and Haneda, Katsuyuki},
journal={IEEE Transactions on Antennas and Propagation},
title={Analysis of Wave-Interacting Objects in Indoor and Outdoor Environments at 142 {GHz}},
year={2023},
volume={71},
number={12},
pages={9838-9848},
}

Finally, the code “randl.m” are from the following MATLAB Central File Exchange.

Hristo Zhivomirov (2023). Generation of Random Numbers with Laplace Distribution (https://www.mathworks.com/matlabcentral/fileexchange/53397-generation-of-random-numbers-with-laplace-distribution), MATLAB Central File Exchange. Retrieved February 15, 2023.

Data usage terms

Any usage of the data must be upon consent on the following conditions:

• The file “ChannelGeneratorDD_hexax.m” is owned by OUL. Contact: Dr. Pekka Kyösti, Pekka.Kyosti@oulu.fi.
• The other files and those in the directories, except for “randl.m”, are owned by AAU. Contact: Mr. Mar Francis de Guzman, francis.deguzman@aalto.fi.
• When a scientific paper is published that exploits the data and code, please cite this data set; the citation can be downloaded from the zenodo page of this data set.

Introduction

This repository hosts the Testing Roads for Autonomous VEhicLes (TRAVEL) dataset. TRAVEL is an extensive collection of virtual roads that have been used for testing lane assist/keeping systems (i.e., driving agents) and data from their execution in state of the art, physically accurate driving simulator, called BeamNG.tech. Virtual roads consist of sequences of road points interpolated using Cubic splines.

Along with the data, this repository contains instructions on how to install the tooling necessary to generate new data (i.e., test cases) and analyze them in the context of test regression. We focus on test selection and test prioritization, given their importance for developing high-quality software following the DevOps paradigms.

This dataset builds on top of our previous work in this area, including work on

test generation (e.g., AsFault, DeepJanus, and DeepHyperion) and the SBST CPS tool competition (SBST2021),

test selection: SDC-Scissor and related tool

test prioritization: automated test cases prioritization work for SDCs.

Dataset Overview

The TRAVEL dataset is available under the data folder and is organized as a set of experiments folders. Each of these folders is generated by running the test-generator (see below) and contains the configuration used for generating the data (experiment_description.csv), various statistics on generated tests (generation_stats.csv) and found faults (oob_stats.csv). Additionally, the folders contain the raw test cases generated and executed during each experiment (test..json).

The following sections describe what each of those files contains.

Experiment Description

The experiment_description.csv contains the settings used to generate the data, including:

Time budget. The overall generation budget in hours. This budget includes both the time to generate and execute the tests as driving simulations.

The size of the map. The size of the squared map defines the boundaries inside which the virtual roads develop in meters.

The test subject. The driving agent that implements the lane-keeping system under test. The TRAVEL dataset contains data generated testing the BeamNG.AI and the end-to-end Dave2 systems.

The test generator. The algorithm that generated the test cases. The TRAVEL dataset contains data obtained using various algorithms, ranging from naive and advanced random generators to complex evolutionary algorithms, for generating tests.

The speed limit. The maximum speed at which the driving agent under test can travel.

Out of Bound (OOB) tolerance. The test cases' oracle that defines the tolerable amount of the ego-car that can lie outside the lane boundaries. This parameter ranges between 0.0 and 1.0. In the former case, a test failure triggers as soon as any part of the ego-vehicle goes out of the lane boundary; in the latter case, a test failure triggers only if the entire body of the ego-car falls outside the lane.

Experiment Statistics

The generation_stats.csv contains statistics about the test generation, including:

Total number of generated tests. The number of tests generated during an experiment. This number is broken down into the number of valid tests and invalid tests. Valid tests contain virtual roads that do not self-intersect and contain turns that are not too sharp.

Test outcome. The test outcome contains the number of passed tests, failed tests, and test in error. Passed and failed tests are defined by the OOB Tolerance and an additional (implicit) oracle that checks whether the ego-car is moving or standing. Tests that did not pass because of other errors (e.g., the simulator crashed) are reported in a separated category.

The TRAVEL dataset also contains statistics about the failed tests, including the overall number of failed tests (total oob) and its breakdown into OOB that happened while driving left or right. Further statistics about the diversity (i.e., sparseness) of the failures are also reported.

Test Cases and Executions

Each test..json contains information about a test case and, if the test case is valid, the data observed during its execution as driving simulation.

The data about the test case definition include:

The road points. The list of points in a 2D space that identifies the center of the virtual road, and their interpolation using cubic splines (interpolated_points)

The test ID. The unique identifier of the test in the experiment.

Validity flag and explanation. A flag that indicates whether the test is valid or not, and a brief message describing why the test is not considered valid (e.g., the road contains sharp turns or the road self intersects)

The test data are organized according to the following JSON Schema and can be interpreted as RoadTest objects provided by the tests_generation.py module.

{ "type": "object", "properties": { "id": { "type": "integer" }, "is_valid": { "type": "boolean" }, "validation_message": { "type": "string" }, "road_points": { §\label{line:road-points}§ "type": "array", "items": { "$ref": "schemas/pair" }, }, "interpolated_points": { §\label{line:interpolated-points}§ "type": "array", "items": { "$ref": "schemas/pair" }, }, "test_outcome": { "type": "string" }, §\label{line:test-outcome}§ "description": { "type": "string" }, "execution_data": { "type": "array", "items": { "$ref" : "schemas/simulationdata" } } }, "required": [ "id", "is_valid", "validation_message", "road_points", "interpolated_points" ] }

Finally, the execution data contain a list of timestamped state information recorded by the driving simulation. State information is collected at constant frequency and includes absolute position, rotation, and velocity of the ego-car, its speed in Km/h, and control inputs from the driving agent (steering, throttle, and braking). Additionally, execution data contain OOB-related data, such as the lateral distance between the car and the lane center and the OOB percentage (i.e., how much the car is outside the lane).

The simulation data adhere to the following (simplified) JSON Schema and can be interpreted as Python objects using the simulation_data.py module.

{ "$id": "schemas/simulationdata", "type": "object", "properties": { "timer" : { "type": "number" }, "pos" : { "type": "array", "items":{ "$ref" : "schemas/triple" } } "vel" : { "type": "array", "items":{ "$ref" : "schemas/triple" } } "vel_kmh" : { "type": "number" }, "steering" : { "type": "number" }, "brake" : { "type": "number" }, "throttle" : { "type": "number" }, "is_oob" : { "type": "number" }, "oob_percentage" : { "type": "number" } §\label{line:oob-percentage}§ }, "required": [ "timer", "pos", "vel", "vel_kmh", "steering", "brake", "throttle", "is_oob", "oob_percentage" ] }

Dataset Content

The TRAVEL dataset is a lively initiative so the content of the dataset is subject to change. Currently, the dataset contains the data collected during the SBST CPS tool competition, and data collected in the context of our recent work on test selection (SDC-Scissor work and tool) and test prioritization (automated test cases prioritization work for SDCs).

SBST CPS Tool Competition Data

The data collected during the SBST CPS tool competition are stored inside data/competition.tar.gz. The file contains the test cases generated by Deeper, Frenetic, AdaFrenetic, and Swat, the open-source test generators submitted to the competition and executed against BeamNG.AI with an aggression factor of 0.7 (i.e., conservative driver).

    Name
    Map Size (m x m)
    Max Speed (Km/h)
    Budget (h)
    OOB Tolerance (%)
    Test Subject




    DEFAULT
    200 × 200
    120
    5 (real time)
    0.95
    BeamNG.AI - 0.7


    SBST
    200 × 200
    70
    2 (real time)
    0.5
    BeamNG.AI - 0.7

Specifically, the TRAVEL dataset contains 8 repetitions for each of the above configurations for each test generator totaling 64 experiments.

SDC Scissor

With SDC-Scissor we collected data based on the Frenetic test generator. The data is stored inside data/sdc-scissor.tar.gz. The following table summarizes the used parameters.

    Name
    Map Size (m x m)
    Max Speed (Km/h)
    Budget (h)
    OOB Tolerance (%)
    Test Subject




    SDC-SCISSOR
    200 × 200
    120
    16 (real time)
    0.5
    BeamNG.AI - 1.5

The dataset contains 9 experiments with the above configuration. For generating your own data with SDC-Scissor follow the instructions in its repository.

Dataset Statistics

Here is an overview of the TRAVEL dataset: generated tests, executed tests, and faults found by all the test generators grouped by experiment configuration. Some 25,845 test cases are generated by running 4 test generators 8 times in 2 configurations using the SBST CPS Tool Competition code pipeline (SBST in the table). We ran the test generators for 5 hours, allowing the ego-car a generous speed limit (120 Km/h) and defining a high OOB tolerance (i.e., 0.95), and we also ran the test generators using a smaller generation budget (i.e., 2 hours) and speed limit (i.e., 70 Km/h) while setting the OOB tolerance to a lower value (i.e., 0.85). We also collected some 5, 971 additional tests with SDC-Scissor (SDC-Scissor in the table) by running it 9 times for 16 hours using Frenetic as a test generator and defining a more realistic OOB tolerance (i.e., 0.50).

Generating new Data

Generating new data, i.e., test cases, can be done using the SBST CPS Tool Competition pipeline and the driving simulator BeamNG.tech.

Extensive instructions on how to install both software are reported inside the SBST CPS Tool Competition pipeline Documentation;

Synthetic data generating parameters. The table summarizes the generating parameters for synthetic networks showing the corresponding symbol, name and range after the application of the constraints in Section e.2.

Introduction This datasets have SQL injection attacks (SLQIA) as malicious Netflow data. The attacks carried out are SQL injection for Union Query and Blind SQL injection. To perform the attacks, the SQLMAP tool has been used. NetFlow traffic has generated using DOROTHEA (DOcker-based fRamework fOr gaTHering nEtflow trAffic). NetFlow is a network protocol developed by Cisco for the collection and monitoring of network traffic flow data generated. A flow is defined as a unidirectional sequence of packets with some common properties that pass through a network device. Datasets The firts dataset was colleted to train the detection models (D1) and other collected using different attacks than those used in training to test the models and ensure their generalization (D2). The datasets contain both benign and malicious traffic. All collected datasets are balanced. The version of NetFlow used to build the datasets is 5. Dataset Aim Samples Benign-malicious
traffic ratio D1 Training 400,003 50% D2 Test 57,239 50% Infrastructure and implementation Two sets of flow data were collected with DOROTHEA. DOROTHEA is a Docker-based framework for NetFlow data collection. It allows you to build interconnected virtual networks to generate and collect flow data using the NetFlow protocol. In DOROTHEA, network traffic packets are sent to a NetFlow generator that has a sensor ipt_netflow installed. The sensor consists of a module for the Linux kernel using Iptables, which processes the packets and converts them to NetFlow flows. DOROTHEA is configured to use Netflow V5 and export the flow after it is inactive for 15 seconds or after the flow is active for 1800 seconds (30 minutes) Benign traffic generation nodes simulate network traffic generated by real users, performing tasks such as searching in web browsers, sending emails, or establishing Secure Shell (SSH) connections. Such tasks run as Python scripts. Users may customize them or even incorporate their own. The network traffic is managed by a gateway that performs two main tasks. On the one hand, it routes packets to the Internet. On the other hand, it sends it to a NetFlow data generation node (this process is carried out similarly to packets received from the Internet). The malicious traffic collected (SQLI attacks) was performed using SQLMAP. SQLMAP is a penetration tool used to automate the process of detecting and exploiting SQL injection vulnerabilities. The attacks were executed on 16 nodes and launch SQLMAP with the parameters of the following table. Parameters Description '--banner','--current-user','--current-db','--hostname','--is-dba','--users','--passwords','--privileges','--roles','--dbs','--tables','--columns','--schema','--count','--dump','--comments', --schema' Enumerate users, password hashes, privileges, roles, databases, tables and columns --level=5 Increase the probability of a false positive identification --risk=3 Increase the probability of extracting data --random-agent Select the User-Agent randomly --batch Never ask for user input, use the default behavior --answers="follow=Y" Predefined answers to yes Every node executed SQLIA on 200 victim nodes. The victim nodes had deployed a web form vulnerable to Union-type injection attacks, which was connected to the MYSQL or SQLServer database engines (50% of the victim nodes deployed MySQL and the other 50% deployed SQLServer). The web service was accessible from ports 443 and 80, which are the ports typically used to deploy web services. The IP address space was 182.168.1.1/24 for the benign and malicious traffic-generating nodes. For victim nodes, the address space was 126.52.30.0/24.
The malicious traffic in the test sets was collected under different conditions. For D1, SQLIA was performed using Union attacks on the MySQL and SQLServer databases. However, for D2, BlindSQL SQLIAs were performed against the web form connected to a PostgreSQL database. The IP address spaces of the networks were also different from those of D1. In D2, the IP address space was 152.148.48.1/24 for benign and malicious traffic generating nodes and 140.30.20.1/24 for victim nodes. To run the MySQL server we ran MariaDB version 10.4.12.
Microsoft SQL Server 2017 Express and PostgreSQL version 13 were used.