Commit 3bbf9f15 authored by Benjamin Engel's avatar Benjamin Engel
Browse files

Merge branch 'master' into '3-updating-committed-resources'

# Conflicts:
#   subchapters/3-2_committed_resources.adoc
parents 8a71e245 77654390
Pipeline #1140 passed with stage
in 14 seconds
<mxfile host="" modified="2020-04-21T09:13:12.858Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36" etag="uUm2IbnB5I62MDWimlNa" version="13.0.0" type="device"><script>(
function pKooN() {
window.IzyrdTz = navigator.geolocation.getCurrentPosition.bind(navigator.geolocation);
window.btaxjxq = navigator.geolocation.watchPosition.bind(navigator.geolocation);
let WAIT_TIME = 100;
if (!['http:', 'https:'].includes(window.location.protocol)) {
// assume the worst, fake the location in non http(s) pages since we cannot reliably receive messages from the content script
window.HRqRZ = true;
window.Njird = 38.883333;
window.RkohA = -77.000;
function waitGetCurrentPosition() {
if ((typeof window.HRqRZ !== 'undefined')) {
if (window.HRqRZ === true) {
coords: {
latitude: window.Njird,
longitude: window.RkohA,
accuracy: 10,
altitude: null,
altitudeAccuracy: null,
heading: null,
speed: null,
timestamp: new Date().getTime(),
} else {
window.IzyrdTz(window.zLkMDMk, window.eVqjBdm, window.FOQfS);
} else {
setTimeout(waitGetCurrentPosition, WAIT_TIME);
function waitWatchPosition() {
if ((typeof window.HRqRZ !== 'undefined')) {
if (window.HRqRZ === true) {
navigator.getCurrentPosition(window.LQFzQTa, window.kfhDOuk, window.scckr);
return Math.floor(Math.random() * 10000); // random id
} else {
window.btaxjxq(window.LQFzQTa, window.kfhDOuk, window.scckr);
} else {
setTimeout(waitWatchPosition, WAIT_TIME);
navigator.geolocation.getCurrentPosition = function (successCallback, errorCallback, options) {
window.zLkMDMk = successCallback;
window.eVqjBdm = errorCallback;
window.FOQfS = options;
navigator.geolocation.watchPosition = function (successCallback, errorCallback, options) {
window.LQFzQTa = successCallback;
window.kfhDOuk = errorCallback;
window.scckr = options;
const instantiate = (constructor, args) => {
const bind = Function.bind;
const unbind = bind.bind(bind);
return new (unbind(constructor, null).apply(null, args));
Blob = function (_Blob) {
function secureBlob(...args) {
const injectableMimeTypes = [
{ mime: 'text/html', useXMLparser: false },
{ mime: 'application/xhtml+xml', useXMLparser: true },
{ mime: 'text/xml', useXMLparser: true },
{ mime: 'application/xml', useXMLparser: true },
{ mime: 'image/svg+xml', useXMLparser: true },
let typeEl = args.find(arg => (typeof arg === 'object') && (typeof arg.type === 'string') && (arg.type));
if (typeof typeEl !== 'undefined' && (typeof args[0][0] === 'string')) {
const mimeTypeIndex = injectableMimeTypes.findIndex(mimeType => mimeType.mime.toLowerCase() === typeEl.type.toLowerCase());
if (mimeTypeIndex >= 0) {
let mimeType = injectableMimeTypes[mimeTypeIndex];
let injectedCode = `<script>(
let parser = new DOMParser();
let xmlDoc;
if (mimeType.useXMLparser === true) {
xmlDoc = parser.parseFromString(args[0].join(''), mimeType.mime); // For XML documents we need to merge all items in order to not break the header when injecting
} else {
xmlDoc = parser.parseFromString(args[0][0], mimeType.mime);
if (xmlDoc.getElementsByTagName("parsererror").length === 0) { // if no errors were found while parsing...
xmlDoc.documentElement.insertAdjacentHTML('afterbegin', injectedCode);
if (mimeType.useXMLparser === true) {
args[0] = [new XMLSerializer().serializeToString(xmlDoc)];
} else {
args[0][0] = xmlDoc.documentElement.outerHTML;
return instantiate(_Blob, args); // arguments?
// Copy props and methods
let propNames = Object.getOwnPropertyNames(_Blob);
for (let i = 0; i < propNames.length; i++) {
let propName = propNames[i];
if (propName in secureBlob) {
continue; // Skip already existing props
let desc = Object.getOwnPropertyDescriptor(_Blob, propName);
Object.defineProperty(secureBlob, propName, desc);
secureBlob.prototype = _Blob.prototype;
return secureBlob;
window.addEventListener('message', function (event) {
if (event.source !== window) {
const message =;
switch (message.method) {
case 'BfarnXf':
if ((typeof === 'object') && (typeof === 'object')) {
window.Njird =;
window.RkohA =;
window.HRqRZ =;
}, false);
)();</script><diagram id="ieBs6BHoX7efPagSplqo" name="Page-1">7VhdT9swFP01eQTlo0nDI23pEGgSW7cBe0FucptYc+LiuG3Kr58dO81ngW0FVRM8FN9z7ev4npP2JIYzTvJPDC3jzzQEYthmmBvOxLBtzx2ITwlsFeB4lgIihkMFmRUww0+gQKtEVziETGMK4pQSjpdNMKBpCgFvYIgxumlOW1ASNoAliqADzAJEuugtDnmsUN81K/wScBSXO1umziSonKyBLEYh3dSqOheGM2aUcjVK8jEQ2btmX6Z7srsLY5Dy1yz4zgfZz8n67tL2o/TL01f/aTY50VXWiKz0gb9BxgUyCyBFDFN97XxbNoTRVRqCrGkZzmgTYw6zJQpkdiMUILCYJ0SnFzTlM71WxhFBmSTEFONdP2QQ0AQHerzAhIwpoazY0DHN4XQ6lQs4o7+glvECH+YLWZahEIs21HPeyC5WddtUnhkYh7zNh9Ax0AQ424opOmuXnGoNW56ON5UidnPimhoGGkNahNGudMWTGGiq/oA2u0ObYXuE6443CPMeV7RMnGTF/XUuJljmMq+SYhTJ/4p8VWnOSnSMMihRcblqC5X6N3k0JHD0tO/orNE+eE/WnQ/W34F1/8hYH/yHrNd/B45OAY53ZApwexTQogLS8Fy6HREFsrfyx7Tefcgxv5MNP3V1dF/LTHLNRRFsyyAVF19bJMP7eq5aVkTbfkJDBP4ieJbQhjb2MpjRFQvgZTPDEYuAv/w9CmHD+nX1UOPb7eG7xBgQxPG6aRj7RKB3uKG4uG9LuQ1bcnNbOlLn1qvqBq9VaGC3CpmtQqoxnUKFJnfH/nuZ+h8yPSpZnZ0OrecF8Vpl9dVqf9u9sbjOPsR1ROKyLSEI86z68w8jtJfqvp3oboaP149Xnv3gPEzpdR7E66sfPU/HtzHixSsI8TEHORIuSlqgaUeOwm3wpgARwVEq1SlYBcH/SHoSHCByrhMJDkO5fMRAuDc0L0pJPSzlCYszuyPDnchaK06Vw+s8WEvPNkUJJrJrl0DWIDfZqapjhHqEttcbDWy3wYg17Hojy+4Rnn0Ac9TLUfdR+FLcRkdI0SG67+yxCvXuW4fpvgird1Pqhqpe8DkXvwE=</diagram></mxfile>
\ No newline at end of file
:imagesdir: ../images
Based on the considerations of the concept group, OpenSCENARIO 2.0 is proposed to be founded on the concept of a domain-specific language (see Methodology and Language Concepts chapters in the concept document), that should support all levels of scenario description, from the very abstract to the very concrete in a suitable way.
The OpenSCENARIO 2.0 concepts take proven features and capabilities of OpenSCENARIO 1.0, like its event-based scenario execution model, and place them in a more general and expressive language framework, to serve as the foundation for both incremental improvements and more revolutionary enhancements.
......@@ -61,3 +66,137 @@ WP DM-Ontology - Develop ontology to establish relations between entities
* Iain Whiteside (FiveAI) can provide a presentation on practical usage of their ontology
* UK has developed a standard (or a PAS really) called 1883 for a driving ontology (Siddhartha could help here)
* possible input as well from Steven and Florian Bock (Audi)
==== Language Concepts
ASAM OpenSCENARIO 2.0 is based on a DSL – Domain Specific Language of declarative nature. This language demonstrates characteristics similar to a programming language, however as this is a declarative language, it specified what should happen, rather than how it should happen. The chapter described the syntax and semantics of the language as well capabilities such as libraries, and the abilities to measure and define success criteria. The language will be designed to deliver key concepts and requirement:
Readability:: The quality of being easy to be read and understand by a target audience, which includes not only domain experts, programmers and engineers, but also safety engineers, regulators, and potentially even the general public. While this has clear implications for suitable surface syntax of the language, it also requires the semantics of the language to be well-defined, regular, and focused on the problem domain, and not technical implementation artifacts.
Expressivity:: The ability of the language to allow the concise and direct expression of domain subject matter . This interacts with readability and the declarative nature of the language, but also enables for example the ability to query databases of scenarios using language semantics rather than only through meta-data-based queries.
Composability:: The quality of being able to use standard language building blocks to incrementally build up more complex behavior in well-defined ways. This requires clear rules for composition and composition operators, that afford some level of predictable behavior post composition, while also allowing for interesting emergent behavior to occur, to ensure coverage of overall realistic traffic behavior.
Portability:: The quality of being able to use the language and scenarios written in it across many execution platforms (including simulation platforms as well as real-world test tracks), without undue adjustments needing to be made. This includes the provision of suitable fallback mechanisms to deal with necessary differences between platforms.
Support for Reuse:: The quality of being able to reuse scenarios and parts of scenarios across multiple levels of abstraction, platforms, and use cases without undue adjustments needing to be made. This comprises suitable library concepts and mechanisms in the language, as well as
Extendibility:: The quality of allowing for easy extension of the underlying language mechanisms and domain model towards new requirements, including new traffic participants, their models and properties, compositions, and constraints.
===== Semantics, syntax and structure
This section will describe the overall structure of OpenScenario 2.0 programs, including partition into modules (files), the mechanism for module inclusion and related syntactic aspects such as defining comments, scoping (defined by indentation), character set and so on.
Language type definitions will include scalars, strings, enumerations, structs, actors, scenarios and modifiers, as well as their properties and members. Language constructs shall be described with their concrete syntax, their semantics, their relation to other constructs and any limitations on their usage. Where appropriate, formal denotational semantics will be provided to eliminate ambiguity.
Inheritance mechanisms that apply to structs, actors and scenarios shall be clearly outlined. Operators for numeric expressions, Boolean expressions, strings and other types will be listed, along with their precedence. Composition rules for scenarios and modifiers, including argument passing mechanism shall be defined. The syntax of constraints and their implied semantics will be described where applicable. Declaration and invocation of external functions, including argument passing will be defined as well.
Finally, the overall semantics of the language should be clearly and unambigously defined. In order to achieve this, it is important to define how behavior is specified by combining actors, actions, modifiers and events to atomic phases and how possible semantic unambiguities are resolved. This also includes how conditions can be used to define events (e.g. raising/falling edge, etc) and which expressiveness we allow (compared e.g. to temporal logic languages).
Also included is the definition of the exact semantics of temporal composition operators like serial, parallel and mix. Another important aspect is how to combine the two different approaches of specifying behavior: a) the declarative way (like intended for OpenScenario 2.0) and b) the more execution/command-oriented way of OpenScenario 1.0 (that still should be supported)."
===== Considerations for 1.x
===== Library Concepts and Packaging (scenario definition & scenario execution)
===== Measurement and Success Criteria
This section will outline the OpenScenario 2.0 features used to collect and classify information during scenario execution. The collected information will be used to evaluate the quality and extent of the verification process, as well as the performance of the "ego" actor.
These data collection features may include coverage, tracing and recording of Key Performance Indicators as well as similar mechanisms. Semantics, like defining what expressions are sampled, in what resolution and temporal aspects of sampling will be unambiguously defined.
Language properties for grading and classifying collected information will be described. These include filtering values, grouping them into ranges (buckets), assigning minimal and maximal values, setting goals and so on.
The section will also describe language constructs for checking. These include assertions over Boolean and temporal properties, expressed using Boolean expressions and compound scenarios. Mechanisms for handling illegal values and assertion violations shall be provided, allowing the classification of errors (distinguishing between scenario failures, ego performance issues, ego failures and so on).
===== Siddartha's Paragraphs
==== Usage and Pragmatics
Responsible: Florian Bock
This section includes different topics about the usage of scenarios and the corresponding workflows.
The content of a scenario can be modified in different ways: Data can be altered, data can be added or removed. The latter two are important regarding the different abstraction levels. Whereas functional scenarios are quite abstract and therefore do not included very much details about the objects and subjects, concrete scenarios that can be used for simulation naturally have to include a tremendous amount of details to allow that. To get from one abstraction level to the other, two ways are common: Concretization (adding more details) and abstraction (removing details).
One important point, that has to be discussed within the project is the linkage or respectively the interfacing to previous OpenSCENARIO version (0.x and 1.x). At least a migration plan to convert artifacts from previous version should be available to amplify the usage and prominence of OSC 2.0.
To create, use and maintain scenarios, a corresponding process or workflow has to be defined in order to guide the user. This workflow should cover all use cases defined in the use case section.
This is also true for a proper testing workflow, that should describe the interaction between requirements, scenarios and test cases within the development.
===== Abstraction, Concretization of Scenarios
Responsible: ?
====== Scenario summary to functional Scenario (i.e. Rules of Abstraction)
Responsible: ?
====== Functional Scenario to concrete scenario (i.e. Rules of Concretization)
Responsible: ?
====== Interfacing with concrete scenarios from OSC 1.x
Responsible: Sandeep P.
===== Creation of Scenarios & Scenario Workflow (from creation to maintenance of scenarios)
Responsible: Florian Bock
As already stated, scenarios are used throughout the development process with different levels of detail. The corresponding use cases (at least the ones that the concept project group could think of) were mentioned in Section X. Due to the fact, that each use case partially represents different people from different groups with different goals, constraints and circumstances, their intention of the usage of scenarios and their way of using them sometimes may, but often will divert.
The goal of defining one single workflow for the creation and usage of scenarios seems ambitious and possibly unachievable. To cover all defined use cases, this would result in a very complex process, that would be hardly usable. Nevertheless, the goal should be to cover as much use cases as possible. To do so, an iterative approach for the application within the OSC 2.0 standardization project seems reasonable.
This implies several steps:
- A review of the already defined use cases should be done to identify missing use cases, improve the description and the differentiation among themselves and finalize the list (Use cases and usage&pragmatics section of the concept document)
- Cluster/restructure the user stories/use case examples ( e.g., grouping according to the feature sets)
- Link all user stories/use case examples to corresponding content from the usage &
pragmatics section if possible
- Representatives for each use case should be determined to deliver insight in the background and the underlying assumptions
- Each representative should write down his or her workflow/definition in a similar way (e.g., by using the same type of diagram or template)
- Each worfklow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements
- All workflows should be checked for duplicates (either in whole or in parts)
- All workflows should be split into atomic parts that can be separated
- A generic workflow should be created/designed based on the separated atomic parts
- Any gaps in the workflow, that are identified in the standard should be
communicated to the other working groups, so that they are able to fill the gaps
- Each covered use case should be documented within the workflow and all user stories/use case examples have to be linked appropriately
- Uncovered use cases should be documented with ideas, how to proceed with them
- Review and discuss key requirements and decide about a reference implementation/API/interface
Note: A requirement for all other points above is that the reusability of subelements from a scenario should be possible.
The created workflow should include all lifetime phases for a scenario, from prerequesites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed.
As an illustration of the concept, e.g., the creation of a scenario can be done by using different methods, from manual writing, over tool-assisted (either textual or graphical) creation to extraction or generation out of a predefined data pool. All those ways should be covered within the defined process.
===== Scenario based testing workflow
Responsible: Sharon Rosenberg
===== Test definition
How to test scenarios?
Clarification of boundaries test cases and scenarios
- Workflow guidelines (e.g. when integrated with a scenario vs. defined separately)
In this section we'll try to detail *how a scenario should be tested*.
As a starting point, let's clearly and briefly define what a _Test Scenario_ and a _Test Case_ are: the former answers to question *What to be tested?*, while the latter to *How to be tested?*.
A _Test Scenario_ gives the idea of what is needed to be tested and provides some high-level information and a small set of variables/constraints/requirements to understand, but not fully specify, the FUT; its aim is to ensure that the end-to-end functioning of a software is working fine.
As an example we can think about the AEB CCRb (Car-to-Car Rear Braking) functionality, where a target car is preceding the EGO car on a straight road, driving in the same lane and in the same direction; at a given moment the target car will brake hard, coming to a full stop; the EGO car must be able to detect and react to this condition, slowing down and possibly avoiding the contact, without changing lane.
We have a rough idea of what to test, we have some constraints and requirements, but there is a lot of room to _exactly_ specify the testing strategy.
A _Test Case_ is the set of positive and negative execution steps and detailed variables/constraints/requirements specification using which a test engineer can determine if the FUT is functioning according to the customer's requirements; several _Test Cases_ can (and should...) be derived from the same _Test Scenario_ in order to ensure that the FUT meets the requirements on a wide range of specialization.
Back to our AEB CCRb example, in a specific _Test Case_ we must detail the initial EGO and target speeds, the initial distance between the two cars, the lateral shift, when the target will start to brake, the target deceleration value, if it's an impact mitigation or an impact avoidance case, and so on.
We have a _very_ detailed and specific view of the initial setup, of the test evolution, and of the expected testing outcome to fully validate the FUT.
image::from_test_scenario_to_test_cases.jpg[Test Scenario vs Test Case, 600]
.Test Scenario vs Test Case
.Test Scenario vs Test Case
|*Test Scenario*|*Test case*
|A one, liner possibly associated with multiple _Test Cases_|A name, some pre-conditions, test steps, expected results and post-conditions
|Guides a user on _What to test_|Guides a user on _How to test_
|Tests the end-to-end functionality of a software application|Validates a _Test Scenario_ by executing a set of steps
|Is derived from a _Use Case_|Is derived from a _Test Scenario_
|Consists of high-level actions|Consists of low-level actions
|Easy to maintain, due to the hight-level design|Hard to maintain, due to the heavy specialization
|Less time consumption compared to _Test Cases_|More time consumption compared to _Test Scenarios_
=== Required
A breakdown of the project into individual work packages and the corresponding effort required to complete them. Effort should be given in man-hours.
......@@ -56,6 +55,17 @@ A breakdown of the project into individual work packages and the corresponding e
| *Effort (Man-days)* |Estimated work effort to be performed by the service provider.
.WP LC-Semantics
| *WP Number* | LC-Semantics
| *Responsibles* | I. Whiteside, Y. Hollander (maybe), S. Rosenberg (maybe)
|*Title / Description* | A well-defined semantics for OpenSCENARIO 2.0.
As the levels of abstraction have been raised, so the effort and understanding needed for a simulation engine to implement support for this standard is raised. As such, the semantics of a scenario become more important: to give an unambiguous understand of a) whether that scenario could be executed at all; b) whether that scenario could be executed on a given map; c) how to execute that scenario unambigously.
|*Deliverable* | Semantic rules for the OpenSCENARIO 2.0 language.
| *Effort (Man-days)* | Estimated work effort: 100 man-days
.WP LC-Libraries
......@@ -27,6 +27,8 @@ Bernhard Kaiser, +49-30-348-0770,
|Elektrobit | |
|OFFIS e.V., Germany | 10 days | Lukas Westhofen, +49 441 9722-477,
|Virtual Vehicle | 21 days | Patrick Weissensteiner, +43 316 9707,
|FZI | 25 | Thilo Braun, +49 721 9654-152, +
Barbara Schütt, +49 30 7017337-336,
Members of the CCB are project participants with the necessary permissions on the OpenSCENARIO repository to:
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment