Glossary

Abstract scenarios utilize constraints to formally define the dependencies and relationships between attributes and behaviors. This scope of abstraction encompasses scenario maneuvers, specific locations, and Operational Design Domain (ODD) requirements.

An object that participates in scenarios. Actors in the OSC DSL domain include the top actor, the SUT actor, the vehicle actor, as well as traffic participants such as car_group, person, cyclist, and more.

Foretify feature which automates the real-time adjustment of scenario parameters during simulation to ensure that the intended objectives are achieved, even when minor deviations or uncertainties occur. This approach minimizes invalid test runs, reduces manual intervention, and preserves scenario intent, improving the efficiency and reliability of large-scale autonomous vehicle validation.

Groups of electronic technologies that assist drivers in driving and parking functions. Examples of ADAS technologies include automatic emergency braking (AEB), adaptive cruise control (ACC), and lane keeping assist (LKA).

An AV software architecture that heavily relies on artificial intelligence and sensor data for vehicle control and decision-making, rather than relying solely on traditional rule-based programming.

Key standards group for standards related to tools used in the development and V&V of Automated Driving Systems.

The hardware and software in a vehicle that together can perform all real-time driving tasks such as steering, acceleration, braking, and environment monitoring without human intervention, within defined operational limits. ADS typically refers to SAE Levels 3, 4, and 5, where the system takes full responsibility for dynamic vehicle control and response while engaged.

Refers to the specific component being evaluated or assessed in a testing environment. Deprecated term replaced by System Under Test (SUT).

Simulation focused on behaviors of vehicles and pedestrians.

OSC DSL entities which are special types of watchers designed to flag incorrect behaviors of the ADS or the scenario and produce issues (special types of intervals).

A type of simulation where outputs (decisions/actions) feed back into the system, affecting subsequent behavior.

A specific, executable instance of a scenario where all parameters, such as speed, distance, and location, have fixed and deterministic values.

A metric used to quantify the completeness of testing by measuring how much of the defined Operational Design Domain and scenario space has been validated.

An item that defines a parameter that needs to be covered, based on the Operational Design Domain (ODD) and the V&V objectives. You use the OSC2 cover() construct to create coverage items. Coverage items have a defined set of buckets (values or value ranges) that have to be exercised (reached) during run executions.

Testing approach focused on systematically covering all relevant scenarios and edge cases.

Refers to the specific component being evaluated or assessed in a testing environment. Deprecated term replaced by System Under Test (SUT).

A high-fidelity virtual replica of a physical vehicle, sensor, or environment used to simulate and validate real-world behavior in a safe digital setting.

A specialized programming language tailored to a specific application domain, offering precise syntax and features that make it easier to express domain-specific requirements and solutions compared to general-purpose languages. OpenSCENARIO DSL is used to define and simulate complex traffic situations and scenarios for autonomous vehicle testing and development.

The raw data recording of all vehicle sensors and internal states during a real-world drive, which is processed to extract scenarios and analyze performance.

Rare, extreme, or unexpected driving situations, such as adverse weather or erratic road users, that occur infrequently but are critical for proving safety.

OSC DSL scenarios which define the movements, multi-phase behaviors, and/or trajectories of one or more actors, along with environmental factors that an ADS may encounter. Evaluation Scenarios are used to: 1) Monitor, detect, and match scenarios, 2) Produce interval data for each matched scenario occurrence.

A machine learning approach where a system learns to map raw sensor inputs directly to vehicle control outputs (like steering and braking) without relying on distinct, manually coded sub-modules.

(Commission Implementing Regulation (EU) 2022/1426)
A European Union regulation that establishes uniform procedures and technical specifications for the type-approval of automated driving systems (ADS) regarding their safety.

OSC DSL scenarios which define the movements, multi-phase behaviors, and/or trajectories of one or more actors, along with environmental factors that an ADS may encounter. Evaluation Scenarios are used to: 1) Monitor, detect, and match scenarios, 2) Produce interval data for each matched scenario occurrence.

OSC DSL entities which independently detect, monitor, and produce interval data for the situations that an ADS encounters in real-world driving logs or simulation tests to evaluate the performance and ODD test coverage of the ADS.

The real-world environmental, geographical, and roadway factors that an autonomous driving system is reasonably likely to encounter during operation. EOC represents the actual conditions anticipated for the system, in contrast to the Operational Design Domain (ODD), which specifies the designed limits within which the system can safely operate.

OSC DSL scenarios (executable simulation scenarios) which define how to activate the movements, multi-phase behaviors, and/or trajectories of one or more actors, along with environmental factors, to challenge and test an ADS in simulation. There are 2 types of generation scenarios: abstract & smart replay.

Attributes that are collected for every run in a test suite, providing global information like the simulator and map versions. You can add your own global metrics.

Reference data accurately describing the environment, objects, and events for validating sensor outputs.

The working party on Automated/Autonomous and Connected Vehicles. A subsidiary body of the UNECE/WP.29 that is specifically responsible for developing and maintaining international regulations for automated and connected vehicles.

Machine learning technique where AI models learn behaviors by imitating human-generated examples.

Data structures for storing, tracking, and visualizing interesting behaviors over slices of time. They have a start time, end time, and data attributes. Generation, Evaluation Scenarios and Evaluators produce intervals with the capability to add two types of additional data to their intervals: 1) cover(): Data used to measure testing completeness or training completeness based on the goals for the safe operation of the ADS in a specific Operational Design Domain (ODD), 2) record(): Data used for other analytics, mainly KPIs.

An international standard that defines a taxonomy and structured format for specifying an Operational Design Domain (ODD), enabling standardized descriptions of AV operating environments.

An international standard that provides methodologies and metrics for evaluating the performance and safety of automated driving systems in various traffic scenarios.

Metrics (such as recall, precision, error rates, response times, coverage, etc.) that are monitored to gauge performance, quality, and effectiveness, and to set success criteria for projects and product features.

An AI-driven technique that transforms 2D sensor data from real-world drive logs into 3D, editable simulation environments, allowing for the creation of new scenario variations from recorded data.

NVIDIA’s platform for creating physically accurate virtual worlds and simulations.

An ASAM standard that uses language and a domain model to develop, verify, and validate the safety and efficiency of automated driving systems.

A collaborative, open-source project that creates and provides free, editable maps of the world. It is built by a community of mappers who contribute and maintain geographic data, such as roads, trails, buildings, and more, from sources like GPS devices, aerial imagery, and manual survey.

Operating conditions under which a given driving automation system or feature thereof is specifically designed to function, including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics.

Evaluating AV systems’ ability to accurately interpret sensor data from cameras, LiDAR, and radar to recognize their surrounding environment.

The application of artificial intelligence to systems that interact directly with the physical world, requiring specialized training and validation to ensure safety in dynamic, unpredictable environments.

Simulation methods grounded in physics to replicate sensor responses under various real-world conditions.

A hub in Foretify Manager where your team can collaborate on a verification and validation (V&V) project. From a project, you can launch and view test suite results, analyze run issues, and create shared workspaces for further analysis using coverage and KPIs.

An event that is associated with a specific condition that must be met before the event can occur.

Defines a parameter that is used to record values such as the version name or the current SUT. You can also use record items as Key Performance Indicators (KPIs) to track or check values. You use the OSC DSL record() construct to create record items.

Machine learning approach where an AV system learns by interacting with an environment, receiving feedback in the form of rewards or penalties.

Robot Operating System (ROS) is an open-source software framework for building, programming, and integrating robotics systems. ROS provides tools, libraries, and conventions for developing complex and modular robot applications across a wide range of hardware platforms.

Systematic process used to identify the primary underlying cause of defects or issues within the software. By pinpointing the root cause, it enables developers to implement effective solutions to prevent the recurrence of similar problems.

A measurable value used to assess the safety-related performance of an automated driving system. SPIs are metrics that indicate the likelihood of crash involvement or the presence of unsafe conditions, and are designed to serve as proxy or surrogate measures for actual crash risk.

A Verification and Validation methodology that is an iterative process that progresses from high-level safety requirements on a restricted Operational Design Domain (ODD) to a fully performant and safety-assured project.

The automated process of mining vast amounts of driving data to identify, extract, and organize the most valuable or safety-critical events for testing.

The automated process of identifying and clustering driving scenarios based on their underlying characteristics, parameters (e.g., actor behaviors, maneuvers, road geometry, etc.)

A methodology for streamlining the development of abstract scenarios using OpenSCENARIO DSL for test generation and evaluation. SDM is based on the best practices for developing modular, consistent, and reusable scenarios.

A validation approach that focuses on evaluating specific driving situations and behaviors rather than simply accumulating random test miles.

A seed, also called a generation seed, is a unique numeric value that, when specified for a run, causes Foretify to generate a specific set of values for the test. Foretify is repeatable, in other words, it reacts in exactly the same way to identical inputs. If the test platform is also repeatable, then the same run definition, including the test, seed and test configuration, will produce exactly the same cycle-by-cycle results.

The process of synthetically generating realistic raw sensor data (such as camera pixels or radar returns) to test perception systems in a virtual environment.

Rendering realistic sensor data (e.g., lidar, radar, camera images) based on simulated environments.

Open-source, microscopic, multi-modal traffic simulation tool designed to simulate the movement of vehicles, pedestrians, and other traffic participants within complex road networks.

A software component (API) that translates the messages between the Foretify API (represented as a set of Protobuf messages) and the simulator API.

Testing methodology in which software components of a system are executed in a simulated environment to verify their functionality, performance, and interactions before deployment on actual hardware. This approach allows for early identification of issues and evaluation of software behavior under diverse, repeatable scenarios, supporting safe and efficient development of complex systems.

Creating artificial datasets, such as simulated sensor feeds, used to train AI models and validate perception systems when real-world data is insufficient.

The system being tested and evaluated. The SUT can be just the planning-and-control part of the vehicle, or the whole vehicle, or multiple vehicles plus the remote-supervision and map-update facilities, and so on.

A set of runs to be executed. The test suite defines what is to be run, including the list of tests, one or more seeds for each test, and the test configuration for each test. Also known as a regression.

The test suites that are added to a Foretify Manager project

Driver Control Assistance Systems. A United Nations regulation (under development/finalization) covering advanced driver assistance features that support the driver more comprehensively than basic systems, requiring scalable validation methods.

UN Regulation No. 152. A UNECE regulation governing the approval of Advanced Emergency Braking Systems (AEBS) which was recently amended to officially accept virtual testing (simulation) as part of the certification process.

UN Regulation No. 157. A UNECE regulation that establishes the uniform provisions concerning the approval of vehicles with regard to Automated Lane Keeping Systems (ALKS), the first binding international regulation for “Level 3” automation.

A consistent set of metrics and tools for evaluating AV system performance across both simulated and real-world conditions.

An event that occurs without any specified triggering condition or criteria.

Quantitatively determines the degree to which the simulation accurately represents the real world for its intended use.

Used to describe the non-ego vehicle actors in a scenario. Some companies use the term “NPC”, but in Foretellix, we use the term “vehicle” for this purpose, e.g., the cut_in_vehicle is the vehicle cutting in front of the ego in a cut_in scenario. Vehicles categories include sedan, van, bus, box_truck, semi_trailer_truck, full_trailer_truck, motorcycle, and bicycle.

Simulations that model the physical motion and handling characteristics of vehicles under different scenarios.

Verification ensures the simulation model complies with its requirements and specifications. It demonstrates the mathematical/physical correctness of models and the quality of the framework.

A Foretify Manager feature that provides a hierarchical structure for defining and tracking your verification and validation objectives based on the required scenarios and coverage metrics.

Refers to a pedestrian or cyclist actor. Note: In the industry this often refers to any road user that is not in a cabin car, meaning it often includes motorcycles.

OSC DSL entities which monitor simpler behaviors, actions, or events, along with environmental factors that an ADS may encounter. Watchers produce interval data and can be used in procedural code to influence simulation execution.