The primary type of data that the database is centred around is Scenarios and for the purposes of this document it makes sense to describe what data is stored for a scenario.
The intention of the database is that it should store scenarios at the functional and logical levels but not the concrete level, the reason for this being that as there are potentially an infinite number of concrete scenarios for a given logical scenario, so it makes sense for the SPSD to store the logical scenario and leave the decision as to which concrete scenarios to generate for testing to the systems responsible for the performing the testing.
The actual definition of a scenario, i.e. the data which can be used to realise and execute a scenario, is defined using the Scenario Definition Language (SDL) developed by WMG. There are two levels of SDL, Level 1 and Level 2, where Level 1 is at a higher level of abstraction and is useful for defining scenarios in a easy to understand natural language where execution in simulation is not required, whereas Level 2 is at a more detailed lower level which can be executed in simulation whilst at the same time maintaining human readability.
The SPSD currently stores scenarios in SDL Level 2, and it is in this form that scenarios are made available to external systems as that is the level which can be ingested by testing toolchains for simulation.
In order to organise scenarios in the database and allow them to be searched on efficiently, scenarios are indexed with tags which describe their content, e.g. junctions, as well as additional extrinsic information, e.g. hazard level.
The tags used in Safety Pool are those defined in the ASAM OpenLabel standard that comprises Operational Design Domain (ODD) tags from the BSI PAS 1883 ODD taxonomy, covering things such as: road features, road geometries, and environmental conditions, as well as tags that cover types of road user and their behaviours, and also administrative tags which cover things such as scenario ownership.
Using a standardised ODD for tagging scenarios has the benefit of allowing users to search for scenarios using the same taxonomy that can describe the ADS technology that they wish to test.
In addition to the OpenLabel tags, SPSD defines additional tags which extend the OpenLabel tag set.
It is also possible for organisations to add additional tags for their own purposes to their own scenarios by using the ‘Custom Tag Editor’ in the SPSD.
It is recognised that testing systems may require additional data in order to execute scenarios in simulation, and to accommodate this the SPSD has the facility to allow files to be uploaded and held with scenarios, an example of this could be that a simulator requires a definition of a virtual world in order to execute a scenario, in which case the virtual world corresponding to the scenario could be uploaded and then retrieved with the scenario for testing.