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.
17
datasets available to search
ShareScore release 0.7.1
Dataset results
17 results for “Automated Driving”
Interactive maps for the visualization of ESRIUM automated driving tests with various EGNSS localization solutions
<p>In order to make the test results available to a broader audience in an easy manner, we have generated interactive maps. These maps are attached to this report and can be viewed in a web-browser. </p><p>Due to the large number of datasets, we have color-coded them on the map and in the menu. An arbitrary number of datasets can be selected at a time.</p><p>Due to the high accuracy of the EGNSS receivers, one can clearly identify the lane on which the vehicle was driving, and where the vehicle was performing a lane-change. However, the satellite/areal-images are not perfectly geo-referenced, thus one can notice a slight offset between satellite/areal-images and real-world lanes.</p><p> </p><p><strong>How to use the map?</strong></p><ul><li>The map can be used in a similar manner than other map-applications, such as google maps. By using the mouse, you can set the focus on the area of your interest. By using the +/- buttons (top left), you can zoom in/out.</li><li>By hovering over the layer-symbol (top right), a popup emerges. Here, you can select different background-tiles (such as satellite/areal-images). In addition, you can select different datasets which should be visualized on the map.</li></ul><p><strong>Background-tiles:</strong></p><ul><li>Basemap – Sat - Satellite/Areal images (from Basemap) -Symbolic map with high resolution (from Basemap)</li><li>Basemap – HighDPI Symbolic map with high resolution (from Basemap)</li><li>OpenStreetMap - Symbolic map (from OpenStreetMap)</li><li>OpenTopoMap - Symbolic map including topology information (from OpenTopoMap)</li></ul><p><strong>Datasets:</strong></p><ul><li>GNSS (Vehicle) - Position of vehicle, according to on-board GPS receiver</li><li>EGNSS (AsteRx SB3 Pro+) - Position of vehicle, according to AsteRx SB3 Pro+ receiver</li><li>EGNSS (mosaic-X5) - Position of vehicle, according to mosaic-X5 receiver</li><li>EGNSS (mosaic-H) - Position of vehicle, according to mosaic-H receiver</li><li>PVT Mode: EGNSS (AsteRx SB3 Pro+) - PVT Mode of AsteRx SB3 Pro+ receiver</li><li>PVT Mode: EGNSS (mosaic-X5) - PVT Mode of mosaic-X5 receiver</li><li>PVT Mode: EGNSS (mosaic-H) - PVT Mode of mosaic-H receiver</li><li>in-lane Offset Change-Request - Position, at which an in-lane offset change (relative to middle of the current lane) was requested via C-ITS</li><li>Lane Change to left - Position, at which a lane-change towards left was performed </li><li>Lane Change to right - Position, at which a lane-change towards right was performed</li></ul><p>Interactive maps are attached are two precision levels one with 4 and the other in 7 digits. The list files and the corresponding test conditions are listed below. </p><p>Test velocities [km/h]: 90, 110, 130 </p><p>interactive map files: </p><p>speed: 90 km/h</p><ul><li>Testrun_01.html</li><li>Testrun_03.html</li><li>Testrun_04.html</li></ul><p>speed: 110 km/h</p><ul><li>Testrun_05.html</li><li>Testrun_06.html</li><li>Testrun_07.html</li></ul><p>speed: 130 km/h </p><ul><li>Testrun_08.html</li><li>Testrun_09.html</li><li>Testrun_10.html</li></ul>
Supplementary Material for 'Leveraging the GIDAS Database for the Criticality Analysis of Automated Driving Systems'
<p>This repository contains the supplementary material for the publication 'Leveraging the GIDAS Database for the Criticality Analysis of Automated Driving Systems'.<br> It consists of four files:</p> <ol> <li>Criticality-Phenomena-Catalog.CSV: The catalog of criticality phenomena (CP)</li> <li>Criticality-Phenomena-Phi-Coefficient.CSV: The calculation of the Phi coefficient between all pairs of CP</li> <li>Criticality-Phenomena-Risk-Calculation.CSV: The case-phenomenon relation matrix, including the calculated values for the risk of each CP for all three severity levels</li> <li>Criticality-Phenomena-Sorted-By-Risk.CSV: A list of the CP from the CP catalog sorted by risk for all three severity classes</li> </ol>
Versailles, Urban driving, Automated Driving and VRU detection
<p>Scenario description: cyclist and pedestrian detection during automated driving.</p> <p>Session description: Automated Driving part of the trip only. Two rounds: the first one without IoT (VRUs not connected) then with IoT (pedestrian with smartphone/watch and cyclist with connected bike).</p> <p>Datasets descriptions:</p> <p><strong>AUTOPILOT_Versailles_UrbanDriving_Vehicle: </strong>Data generated from the vehicle sensors</p> <p>Vehicle datasets generated by the vehicle sensors during urban driving at Versailles. This includes the data coming from the CAN bus and GPS. It includes following kind of datasets: Vehicle: general data (speed, battery), PositioningSystem: data from GPS, VehicleDynamics: data about dynamic (acceleration...), Accel: acceleration data, EnvironmentSensorsAbsolute: environment sensors in absolute coordinates</p> <p><strong>AUTOPILOT_Versailles_UrbanDriving_V2X: </strong>V2X messages during uraban driving sessions</p> <p>Data exchanged with other vehicles and pedestrian during urban driving. SortOfCam: messages sent or received from bicycles</p> <p><strong>AUTOPILOT_Versailles_UrbanDriving_IoT: </strong>Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by urban driving and car sharing application with vehicle, across oneM2M platform. oneM2M: car sharing status data</p> <p><strong>AUTOPILOT_Versailles_UrbanDriving_CAM: </strong>CAM messages</p> <p>This dataset refers to messages captured inside the vehicle during car sharing.</p>
Livorno, Urban driving, Automated vehicle detects fallen bicycle
<p><strong>Scenario description</strong>:</p> <p>Test session for AD+connected car and connected cars approaching a fallen bicycle.</p> <p><strong>Session description</strong>:</p> <p>The fallen bicycle use case aims to demonstrate the possibility for a vehicle to detect in advance, using V2X communication, the presence of a fallen bicycle on the road. In case of fall, the bicycle signals its presence to the other vehicles using DENM messages. The AD car publishes the detected event to the oneM2M and safely reduces its speed until to stop. Goal is to record data for the technical evaluation.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Driving in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
ES-PT, Remote Driving, Automated shuttle remote driving across borders
<p>Use Case Category: <strong>Remote Driving</strong><br> User Story: <strong>Automated shuttle remote driving across borders</strong><br> Location: Spain-Portugal (ES-PT) cross-border corridor</p> <p>According to 3GPP TS 22.186 R16, Remote Driving “enables a remote driver or a V2X application to operate a remote vehicle for those passengers who cannot drive themselves or a remote vehicle located in dangerous environments. For a case where variation is limited, and routes are predictable, such as public transportation, driving based on cloud computing can be used. In addition, access to cloud-based back-end service platform can be considered for this use case group”.</p> <p>User Story: <strong>Automated shuttle remote driving across borders</strong></p> <p>This use case is focussed in the deployment of last mile EV Automated shuttle vehicles in different environments:</p> <p>· Cross Border environment: The shuttle will cover a route between Spain and Portugal connecting the cities of Tui and Valença through the old international bridge.</p> <p>· Urban environment: The shuttle will cover a route in the city of Vigo.</p> <p>For both environments, we will consider these two scenarios:</p> <p>· Scenario 1: Cooperative automated operation: In this scenario, the EV Autonomous shuttle is able to receive information coming from other actors (like a Vulnerable Road User) and adapt its behaviour according to specific needs.</p> <p>· Scenario 2: Remote Control: In this scenario the EV autonomous vehicle is driving following a predefined route, and suddenly an obstacle appears in its path blocking the original route. In this situation, an operator is alarmed, and he/she is able to remotely take the control of the EV autonomous vehicle or issue a set of new navigation commands in order to handle a new route.</p>
ES-PT, Advanced driving, Complex manoeuvres: Automated Overtaking
<p>Use Case Category: <strong>Advanced Driving</strong><br> User Story: <strong>Complex manoeuvres in cross-border settings</strong><br> Location: Spain-Portugal (ES-PT) cross-border corridor</p> <p>According to 3GPP TS 22.186 R16, Advanced Driving “enables semi-automated or fully-automated driving. Longer inter-vehicle distance is assumed. Each vehicle and/or Road Side Unit (RSU) shares data obtained from its local sensors with vehicles in proximity, thus allowing vehicles to coordinate their trajectories or manoeuvres. In addition, each vehicle shares its driving intention with vehicles in proximity. The benefits of this use case group are safer traveling, collision avoidance, and improved traffic efficiency”.</p> <p>Scenario 2: <strong>Automated Overtaking</strong>:</p> <p>When an automated vehicle needs to overtake a vehicle that precedes it, additional information provided by communication technologies will drastically improve and complement the information provided by its sensor constellation.</p> <p>There are many situations where the dimensions of other vehicles can cover the field of view of the autonomous vehicle sensors (for example, a truck can reduce the vision of a camera, a laser or a radar sensor). Moreover, according to the route followed by the vehicle, it can happen that a highway exit or a toll is near to the point where the overtaking takes place, and a queue of vehicles can complicate the scenario reducing free space and therefore producing a less appropriate manoeuvre.</p> <p>Other complex scenario can appear when there are vehicles behind the automated vehicles that occludes the vision of rear sensors. Considering that we are driving on a two-lane road with a right-hand traffic regulation, this occlusion can produce that the automated vehicle is not able to perceive a vehicle driving fast in the left lane.</p> <p>The purpose of this use case is to extend the 360º perception layer of the automated vehicle by integrating communication capabilities in the different vehicles of the scenario and additional road sensors (e.g. traffic radars) in the infrastructure. In this way, vehicles will be able to share their positions, speeds, sizes, etc., as well as the road-side infrastructure, helping automated vehicle to understand current situation and thus take the best decision of how to proceed with the automated overtaking.</p>
ES-PT, Advanced Driving, Automated Shuttle
<p>Use Case Category: <strong>Advanced Driving</strong><br> User Story: <strong>Automated shuttle remote driving across borders</strong><br> Location: Spain-Portugal (ES-PT) cross-border corridor</p> <p>According to 3GPP TS 22.186 R16, Advanced Driving “enables semi-automated or fully-automated driving. Longer inter-vehicle distance is assumed. Each vehicle and/or Road Side Unit (RSU) shares data obtained from its local sensors with vehicles in proximity, thus allowing vehicles to coordinate their trajectories or manoeuvres. In addition, each vehicle shares its driving intention with vehicles in proximity. The benefits of this use case group are safer traveling, collision avoidance, and improved traffic efficiency”</p> <p>User story: Automated shuttle remote driving across borders</p> <p>This use case is focussed in the deployment of last mile EV Automated shuttle vehicles in different environments:<br> - Cross Border environment: The shuttle will cover a route between Spain and Portugal connecting the cities of Tui and Valença through the old international bridge.<br> · Urban environment: The shuttle will cover a route in the city of Vigo.</p> <p>Scenario: Cooperative automated operation: In this scenario, the EV Autonomous shuttle is able to receive information coming from other actors (like a Vulnerable Road User) and adapt its behaviour according to specific needs.</p>
Data from: Automation and machine learning drive rapid optimization of isoprenol production in Pseudomonas putida
Open the record for dataset details and reuse information.
Livorno, Urban driving, Automated vehicle and smart traffic light
<p><strong>Scenario description</strong>:</p> <p> </p> <p><strong>Session description</strong>:</p> <p> </p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Driving in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
Livorno, Urban driving, Automated and connected vehicle and smart traffic light
<p><strong>Scenario description</strong>:</p> <p>Test session for AD+connected car and connected cars approaching an intersection regulated by a "smart" traffic light.</p> <p><strong>Session description</strong>:</p> <p>A "smart" traffic light sends SPaT and MAP messages describing the topology, actual status of the traffic light to other connected vehicles and to the oneM2M platform on the cloud.<br> An AD vehicle consumes the information and autonomously adapts its speed in order to cross the intersection without violating the traffic light phases, considering also other vehicles moving in front. Goal is to record data for the technical evaluation.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Drining in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
Livorno, Urban driving, Automated vehicle approaching intersection
<p><strong>Scenario description</strong>:</p> <p>Test session for AD vehicle approaching an intersection with jaywalking at traffic light</p> <p><strong>Session description</strong>:</p> <p>A "smart" traffic light with a stereocamera sends SPaT and MAP messages describing the topology, actual status of the traffic light, presence of pedestrian, and jaywalking occurrence to other connected vehicles (via DENM) and to the oneM2M platform on the cloud. An AD vehicle consumes the information and autonomously adapts its speed in order to cross the intersection without violating the traffic light phases, or even stop to avoid collision with pedestrian. The influence of other vehicles moving in front is considered too.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Driving in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
Livorno, Urban driving, Automated car detects pothole
<p><strong>Scenario description</strong>:</p> <p>Test session for connected car detecting potholes using the combination of one or more of the following sensors: smartphone, 6LoWPAN vibration sensor, IMU.<br> The information is sent to the cloud and can be sent back to other connected vehicles for warning.<br> The information is also transmitted via V2V to AD cars that can automatically adapt the speed.</p> <p><strong>Session description</strong>:</p> <p>Test session with only a connected car with smartphone based pothole detector, lap of 1,9 km on the harbour's public road. Goal is to record data for the technical evaluation.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Driving in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
A dataset on the physiological state and behavior of drivers in conditionally automated driving
<p>A detailed description of the data collected, the experimental design, materials and methods used in each experiment, and the references associated with this work can be found in the manuscript published in the journal Data in Brief, available in Open Access <a href="https://doi.org/10.1016/j.dib.2023.109027">here</a><strong>.</strong> <strong>Please cite this publication if you use the dataset.</strong></p> <p><strong>Reference : </strong>Quentin Meteier, Marine Capallera, Emmanuel de Salis, Leonardo Angelini, Stefano Carrino, Marino Widmer, Omar Abou Khaled, Elena Mugellini, Andreas Sonderegger. A dataset on the physiological state and behavior of drivers in conditionally automated driving, Data in Brief, 2023, 109027, ISSN 2352-3409, <a href="https://doi.org/10.1016/j.dib.2023.109027">https://doi.org/10.1016/j.dib.2023.109027</a>.</p> <p>--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------</p> <p>This is a set of physiological and behavioural data collected in 6 fixed-base driving simulator experiments from 346 drivers. The data was collected as part of the AdVitam project (for Adaptive Driver-Vehicle Interaction to Make future driving safer), a joint research project funded by the Hasler Foundation, led by the Human Tech Institute (HEIA-FR), the He-Arc, the EPFL+ECAL Lab, and the University of Fribourg (Switzerland).</p> <p>All experiments simulated conditional automation (Level 3 of automation according to the taxonomy released by the <a href="https://www.sae.org/standards/content/j3016_202104/">Society of Automotive Engineers</a>), except for experiment 1 (Level 0 - manual driving).</p> <p>Each folder contains raw and preprocessed data collected in each experiment:</p> <ul> <li>Exp1: Experimental manipulation of relaxation before driving and presence of passenger while driving (manual driving)</li> <li>Exp2: Experimental manipulation of cognitive workload at 2 levels using a verbal task (backwards counting)</li> <li>Exp3: Experimental manipulation of cognitive workload at 3 levels using visual and auditory tasks (N-back task)</li> <li>Exp4: Experimental manipulation of fatigue (sleep deprivation) and driving environment (rural vs. urban scenario)</li> <li>ExpTOR: Multiple takeovers requested through different modalities (visual, auditory, haptic), while performing different non-driving related tasks</li> <li>ExpFinal: Testing a contextual multimodal system for maintaining situation awareness and takeover quality in conditionally automated driving</li> </ul> <p>Physiological data (Electrocardiogram, electrodermal activity and respiration) were collected in all experiments. They were preprocessed in Python with the <a href="https://github.com/neuropsychology/NeuroKit">Neurokit</a> library. It was also used to process the physiological raw signals and calculate a large range of physiological indicators.</p> <p>Some of these measures were also collected in the various experiments: situation awareness, takeover performance (reaction, time, maximum steering wheel angle, ..), affective state, mental workload, non-driving-related task performance, sleepiness..</p> <p>More details on each experiment are provided in the ExpX_README.md of each folder.</p>
A Survey on Automated Driving System Testing: Landscapes and Trends [Supplementary material]
<p>This is a supplementary material for our paper <a href="https://arxiv.org/abs/2206.05961">"A Survey on Automated Driving System Testing: Landscapes and Trends"</a>.</p>
Safety of Perception System for Automated Driving: A Case Study on Apollo
<p>This replication package consists of the detailed results of the safety assessment process of Apollo 7.0’s perception system for its use on a 3.4-kilometer segment of the Dutch highway, A270.<br> <br> <strong>‘Operational design domain description’</strong> consists of a detailed description of the operational area (operational design domain).</p> <p><strong>‘Hazard Analysis and Risk Assessment’ </strong>is a Microsoft Excel workbook of 6 sheets comprising of all intermediate results from the first two steps of safety requirement elicitation (hazard analysis, risk assessment), along with the final result (safety goals and their risk levels).</p> <p><strong>‘Safety Analysis’</strong> is a pdf document showing the translation of system-wide safety goals to the safety goals specific to components using fault tree analysis.</p> <p><strong>‘Safety Requirements’ </strong>is a Microsoft Excel workbook of 2 sheets comprising the final result of the safety requirement elicitation process, i.e., safety requirements (1) for traditional software (2) specific to ML-based systems.</p> <p><strong>‘Design assessment’ </strong>is a Microsoft Excel workbook of 2 sheets comprising the design assessment results. Specifically, the sheets consist of (1) the safety requirements and applicable design choices for each requirement; (2) where did we assess each requirement; (3) the final verdict for assessment of each requirement; (4) the reason for the verdict and the design decisions found in Apollo’s perception system related artifacts.<br> <br> </p> <p><strong>How to navigate this replication package with a complete running example.<br> —-------------------------------------------------------------------------------------------------------</strong><br> The identification of safety requirements starts from the Microsoft Excel workbook: ‘Hazard Analysis and Risk Assessment’ of 6 sheets presenting all intermediate results from the first two steps of safety requirement elicitation (hazard analysis, risk assessment). In the rest of this document, we demarcate running examples with bullets. <br> <br> In the sheet “Homepage” of this Excel workbook are descriptions and pointers to the other sheets in the same workbook if readers want to skip directly to the other pages. The second sheet “Operational scenarios” describes the operational scenarios and associated operational modes. The combination of operational scenarios and associated operational modes form operational conditions, each with a unique identifier. These operational conditions are used further. The sheet also describes which variables are considered from the Operational design domain description (see the separate document with the same name for a detailed description of the operational area) to form these operational conditions.</p> <ul> <li> <p>An example operational condition is “driving in lane” + “slower-moving vehicle in front” with its unique identifier OC1 (see row 11 in the second sheet).</p> </li> </ul> <p>The third sheet “Operational modes & functions” describes the functions (specific to functional safety or functional insufficiency) of the automated driving vehicle and which operational modes (from the second sheet) these functions are activated. Each function is associated with a unique identifier.</p> <ul> <li> <p>An example function is “avoid collision with an object in driving lane” and its unique identifier is F1 (see rows 2-5 of the third sheet).</p> </li> </ul> <p>The fourth sheet “Hazards identification” shows hazards identified by crossing each function from the third sheet with guide words. Each hazard has a unique identifier.</p> <ul> <li> <p>An example hazard created from the above example function F1 is “does not avoid collision with an object in driving lane” with its unique identifier H1 (see second row of the fourth sheet).</p> </li> </ul> <p>The fifth sheet “ASIL parameters” describes the parameters for identifying risk levels. The parameters are given to each of the operational modes and operational situations from the prior sheets. The sixth sheet “Hazardous events & safety goals” describes the derivation of safety goals from hazards identified from the fourth sheet and the identification of the risk level for each safety goal based on the risk parameters from the fifth sheet (they are automatically applied using the formula function in Excel). This sheet gives at least four new pieces of information (and how this information is derived): (1) hazardous event; (2) safety goal derived from each of the hazardous events; (3) aggregate safety goal; and (4) risk level (ASIL) for the aggregated safety goal. Each of these has its own unique identifiers. An example of each of these four (following from the example hazard given above) is given below,</p> <ul> <li> <p>An example hazardous event (in the second row of the sixth sheet) is “does not avoid collision with an object in driving lane” (third column) + “driving in lane” (fifth column) + “slower-moving vehicle in front” (sixth column). This can be combined as “the automated driving vehicle does not avoid collision with a slower-moving vehicle in its driving lane”. Its unique identifier is HE1.</p> </li> <li> <p>The safety goal derived from the above hazardous event (HE1) is “avoid collision in scenario: slower-moving vehicle in front in operational mode: driving in lane” (see second row, 15th column, of the sixth sheet) with its unique identifier SG1.</p> </li> <li> <p>The above safety goal (SG1) along with other similar safety goals, forms the aggregated safety goal: “avoid collision with an object (obstacle or vehicle) in driving lane in all operational modes” (see rows two to ten, column 17, of the sixth sheet) with its unique id Aggreg_SG1.</p> </li> <li> <p>The risk level associated with the aggregated safety goal, Aggreg_SG1, is ASIL D (see rows two to ten, column 18, of the sixth sheet). This aggregated risk level is the highest risk level of the associated safety goals (see rows two to ten, column 13 of the sixth sheet). The risk level in each row of column 13 is derived from the risk parameters in columns 10-12 (sixth sheet). The risk parameters in columns 10-12 (sixth sheet) come from the fifth sheet and are associated with the operational mode in column 5 (sixth sheet) and the operational scenario in column 6 (sixth sheet). </p> </li> </ul> <p>The next part of requirements elicitation is presented in the pdf titled ‘Safety Analysis’. The pdf document shows the translation of system-wide safety goals to the safety goals specific to components using fault tree analysis. Pipeline-level safety-critical events derived from the fault tree analysis are marked with unique identifiers.</p> <ul> <li> <p>The fault tree for aggregated safety goal with the unique identifier Aggreg_SG1 is shown from page 2 of the document. One of the safety-critical event resulting from the aggregated safety goal is “Lidar obstacle detection, classification and tracking pipeline estimates incorrect state of vehicle / obstacle” with unique identifier SCE1 (see page 13).</p> </li> </ul> <p>The final part of the safety requirement elicitation is shown in the Microsoft Excel workbook ‘Safety Requirements’. The workbook consists of 2 sheets comprising the final result of the safety requirement elicitation process, i.e., safety requirements (1) for traditional software (2) specific to ML-based systems. </p> <ul> <li> <p>An example traditional software safety requirement resulting from the safety-critical event with the unique identifier SCE1 is "if any component in LiDAR obstacle detection, classification, and tracking pipeline becomes non-operational then this failure shall not lead to an incorrect estimation of the state of vehicles or other obstacles.” and its unique identifier is 26262_3 (see the first sheet, rows 28-40, fourth column)</p> </li> <li> <p>An example ML pipeline safety requirement resulting from the safety-critical event with the unique identifier SCE1 is “If the performance of Lidar obstacle detection, classification, and tracking pipeline is deteriorated due to strong sunlight, then this deterioration in performance shall not lead to an incorrect estimation of the state of vehicles or other obstacles.” with unique identifier SOTIF_8 (see the second sheet, rows 73-82, sixth column)</p> </li> </ul> <p>Finally, the design assessment of the safety requirements is shown in the Microsoft Excel workbook ‘Design assessment’. The workbook consists of 2 sheets comprising the design assessment results. Specifically, the sheets provide the following information: (1) the safety requirements and applicable design choices for each requirement; (2) where did we assess each requirement; (3) the final verdict for assessment of each requirement; (4) the reason for the verdict and the design decisions found in Apollo’s perception system related artifacts.</p> <ul> <li> <p>The assessment of the traditional safety requirement with the identifier 26262_3 (from above) is shown in the first sheet in rows 28-40.</p> </li> <li> <p>The assessment of the ML pipeline related safety requirement with the identifier SOTIF_8 is shown in the second sheet in rows 73-82.</p> </li> </ul>
Does Automated Closed-Loop Ventilation Reduce the DRiving Pressure Levels in Patients With ARDS
ClinicalTrials.gov study NCT03211494. IPD Sharing: UNDECIDED. Countries: 1. Publications: 1.
Dataset of bugs in automated driving softwares
Open the record for dataset details and reuse information.
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research 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.
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.
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.
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.
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.