Project Number |
P2022-01 |
Domain |
Simulation |
Relevant Standard |
ASAM OSI V4.0.0 |
Project Name |
P_2022_01_OSI |
Project Type |
Major Version Development |
Start Date |
01.08.2022 |
End Date |
15.04.2024 |
ASAM Funds |
14.000€ |
1. Executive Summary
The Open Simulation Interface provides a well-established standard for the interface between environment simulations and various simulation models, including environmental effect, sensor, sensor fusion, and AD function models, as well as whole traffic participant models.
After transition of OSI to ASAM a number of minor releases, including ASAM OSI 3.4.0 and 3.5.0 with greatly increased functionality and features were successfully released and saw adoption in the market place.
The current proposal intends to carry this work forward into 2023 with another planned minor release for 2022, and a major release in 2023.
The minor and major releases will focus on the following areas:
-
Further alignment with other ASAM standards, including ASAM OpenDRIVE and ASAM OpenSCENARIO, as well as the ISO 23150 standard, in the areas of traffic signs, traffic lights and logical lane information.
-
Performance enhancements and flexibility through the adoption of a Flatbuffers data encoding layer.
-
Enhanced interface types for streaming of OSI updates, for example for visualization and evaluation applications.
-
Incremental feature improvements in existing interface types based on new use cases.
-
Increased support for new application domains, including space vehicles, advanced sensor modeling, real-world data transport.
Technical fixes and minor continual enhancements as part of the normal maintenance of the standard across the project duration form the additional content for the expected releases.
Current and future users of OSI, as well as related standards, are invited to join this project to drive the collaborative, incremental development of OSI for future needs.
2. Overview
2.1. Motivation
After transition of OSI to ASAM a number of minor releases, including ASAM OSI 3.4.0 and 3.5.0 with greatly increased functionality and features were successfully released and saw adoption in the market place.
The current proposal intends to carry this work forward into 2023 with another planned minor release for 2022, and a major release in 2023.
The minor and major releases will focus on the following areas:
-
Further alignment with other ASAM standards, including ASAM OpenDRIVE and ASAM OpenSCENARIO, as well as the ISO 23150 standard, in the areas of traffic signs, traffic lights and logical lane information.
-
Performance enhancements and flexibility through the adoption of a Flatbuffers data encoding layer.
-
Enhanced interface types for streaming of OSI updates, for example for visualization and evaluation applications.
-
Incremental feature improvements in existing interface types based on new use cases.
-
Increased support for new application domains, including space vehicles, advanced sensor modeling, real-world data transport.
2.2. Use Cases
Type of use case |
Technical Use-Case |
Description |
The description of traffic signs and traffic lights should be aligned among the Open-X standards OpenDRIVE, OpenSCENARIO and OSI to enable the standards to be used consistently within a simulation environment. Having already introduced a generalized description for traffic signs in OSI v3.4 and thus aligned with OpenDRIVE, an additional generalized semantic representation of the signs would be beneficial to easily determine the meaning. Such representation must be aligned with OpenDRIVE, therefore a direct collaboration between OpenDRIVE and OSI should be aimed for. If the existing enum for Traffic sign classification, which is already marked as “deprecated” since OSI v3.4, will be adapted in this case, breaking changes are needed and thus requires a new major version. |
Author |
Hendrik Amelunxen, hamelunxen@dspace.de |
Type of use case |
Technical Use-Case |
Description |
Currently the BoundingBox is very strict according to its definition. The whole vehicle is included, except the side mirrors. This should be more flexible in the future. Corresponding to that, the contour line should be redefined. It is not clearly defined, e.g. if it contains the side mirrors. Therefore a new concept for the BoundingBox and ContourLine should be defined, which also enables the objects to describe state changes, e.g., opening of doors. Also the description of spatially complex objects should be possible, e.g. for objects like curved streetlamps reaching over the lanes, or trees with big tree tops. |
Author |
Hendrik Amelunxen, hamelunxen@dspace.de |
Type of use case |
Technical Use-Case |
Description |
Currently speed limits can only be modeled using traffic signs positioned as stationary objects causing high efforts determening the current speed limit for a certain position. For traffic participant models it would be helpful to have the speed limit information available more easily (see also issue #606). |
Author |
Markus Lemmer, lemmer@fzi.de |
Type of use case |
Technical Use-Case |
Description |
The messages TrafficCommand, SensorView and TrafficUpdates are suitable interfaces for traffic participants. Neverthless, interfaces between models for vehicle internal messages are not yet present. A first draft for an interface between the planning and motion control was proposed in PR #452. Future work should extend this work and also add additional interface messages (for example between motion control model and vehicle dynamics model) focusing on modularity of the message. These messages are necessary in order to create interfaces between internal component model and create exchangability of these models. |
Author |
Markus Lemmer, lemmer@fzi.de |
Type of use case |
Technical Use-Case |
Description |
With some minor modifications, ASAM OSI can be used for simulation of spaceflight and robotic exploration scenarios, without sacrificing its focus on automotive driving applications. We are interested in discussing and implementing such an extension. Basic support for our current scenarios (orbital rendezvous and docking, and robotic exploration) could already be achieved by moderate changes. |
Author |
Kmeid Saad on behalf of Gregor Jochmann and Jörn Thieling, kmeid.saad@ansys.com, Gregor.Jochmann@rt.rif-ev.de, Thieling@mmi.rwth-aachen.de. |
Type of use case |
Technical Use-Case |
Description |
SensorView and SensorViewConfiguration update for camera, radar and lidar. This use-case also includes merging additional results that emerged from the SETLevel project. For example in case of a radar, the SensorView needs to have information about the first and last interaction with the environment model in the osi3::Reflections interface to simulate MIMO antenna arrays. This information is missing within the RadarSensorView. |
Author |
Kmeid Saad on behalf of Lukas Elster, kmeid.saad@ansys.com, lukas.elster@tu-darmstadt.de. |
Type of use case |
Technical Use-Case |
Description |
Some use cases for sensor models to access processed representations of geometric information and related properties through ray tracing have already been discussed.
For example, in radar sensor model ray tracing, there are the following two approaches for calculating the ray receiving azimuth. The difference is that Approach 2 does not disclose the reflection point coordinates in the ray tracing model. This helps protect ray tracing algorithms from the risks of reverse engineering.
In general, sensor model is a corporate IP and the contents are often concealed. The same is true for ray tracing model. Therefore, we need a ray tracing interface that can communicate even if both the sensor model and the ray tracing model are black boxes. |
Author |
Kmeid Saad on behalf of Mine Seki, kmeid.saad@ansy.com, mine.seki@mail.toyota-td.jp. |
Type of use case |
Technical Use-Case |
Description |
The number of vehicles equipped with a large number of radars is increasing rapidly. Multiple millimeter wave radar systems can improve the safety and reliability of autonomous driving. There are no rules for interference avoidance and coexistence in the millimeter wave radar band. Therefore, the spatial environment is congested with radar signals, and interference often causes millimeter wave radar malfunction. To support radar to radar radio wave propagation, OSI messages need to contain more information. For example, you should consider including the transmit radar ID and receive radar ID in the SensorView for filtering ray tracing data.
|
Author |
Kmeid Saad on behalf of Mine Seki, kmeid.saad@ansy.com, mine.seki@mail.toyota-td.jp. |
Type of use case |
Technical Use-Case |
Description |
Streaming Interface for Visualization. Outcome of the last OSI-Project was, that using explicitly OSI as IDL as a visualization interface works. Main reason is to make simulation environment and graphics engine exchangeable. In this Project the focus is on how to package the information paying attention to performance and also the "control layer". |
Relevant users |
Provider and Consumer of visualzation data. |
Author |
Thomas Nader and Hubert Cao, thomas.nader@bmw.de hubert.cao@bmw.de |
Type of use case |
Technical Use-Case |
Description |
Extension regarding NCAP-Targets It should be possible to transport NCAP-Targets via OSI. Questions regarding that are, how to * differentiate between adults and children * classify "deer", "wild boar" and others * map a bicycle being pushed or a buggy being pushed Pay attention to what is really necessary and also needed. There may be a connection to the use case "Rework of bounding boxes". |
Relevant users |
HiL Users |
Author |
Lorenz Schmidt, lorenz.ls.schmidt@partner.bmw.de |
Type of use case |
Technical Use-Case |
Description |
For the integration of detailed pedestrian movement a more detailed model is necessary. To exchange the movement of one simulation environment to another simulation environment, the position is not accurate enough. Furthermore the will be additional descriptions needed for, e.g. arms and legs. In the Use case of the Technische Hochschule Ingolstadt, the movement data will be generated through motion capturing and therefore needs to be transmitted into the driving simulation in its details. |
Author |
Thomas Hempen, thomas.hempen@carissma.eu; Jakob Peintner, jakob.peintner@carissma.eu |
Type of use case |
Technical Use-Case (expected for the future) |
Description |
Within a research Project (AutoBit) at the Technische Hochschule Ingolstadt, a test vehicle for automated driving functions is currently under construction. For the research on prototype functions, all interfaces shall be abstracted through OSI. When converting the data from the real sensors (different (thermal) cameras, radars and a lidar) to OSI, it is expected to run into different problems through missing, or unexpected data description. There will be work done to improve these data descriptions. |
Author |
Thomas Hempen, thomas.hempen@carissma.eu; |
Type of use case |
Technical Use-Case |
Description |
In OSI 3.X Serialization and Deserialization are more or less hard coded into the protobuf files. We would like to make this optional, meaning that the independent datamodel can be build using different Middleware/serialization/deserialization technologies. Background: There is for example FEP as Open Source Framework developed and used within the VW Group https://github.com/audi/fep3_sdk and probably many more used by other companies. Thus by giving flexibility here, ASAM OSI could get running simulation systems based on OSI Datamodel and consequently more users/use cases. |
Author |
Kmeid Saad on behalf of Marc Semrau, kmeid.saad@ansys.com; marc.david.semrau@cariad.technology. |
Type of use case |
Technical Use-Case |
Description |
In order to model the surface of roads more realistically, a more detailed way to describe road shapes, bumps, inclines etc. needs to be introduced. Currently the road surface is only partially described by the lane boundary points, which result in a more or less flat surface. The surface description should describe junction surfaces as well as normal roads. A first approach with the use of so called surface lines was developed but needs to be more clearly defined for all use cases. |
Author |
Arne Düselder; arne.dueselder@fka.de |
Type of use case |
Technical Use-Case |
Description |
Currently the OSI SensorData output interface is the output after object identification and tracking. Intermediate interfaces that correspond to intermediate processing stages inside sensors are currently treated as out of scope for OSI, since they are internal to sensors and proprietary. For certain more research oriented use cases, exchangeability of partial sensor models is desired, and hence intermediate interfaces might need to be standardized. An example would be the introduction of object identification in 2D image coordinates, or a depth map of a 2D image for camera sensors. |
Author |
Pierre R. Mai on behalf of Gregor Jochmann, pmai@pmsfit.de; gregor.jochmann@rt.rif-ev.de. |
Type of use case |
Technical Use-Case |
Description |
Physical sensor models need enhanced information on the environmental conditions of the surroundings of a vehicle. These enhancements should be aligned with similar enhancements discussed in the OpenSCENARIO and OpenODD working groups. |
Author |
Pierre R. Mai on behalf of Yasuyuki Nakanishi, pmai@pmsfit.de; nakanishi@adac.co.jp. |
Type of use case |
Technical Use-Case |
Description |
Where possible and useful, terminologies on the operational domain definition should be aligned with other relevant ASAM standards, like OpenODD, OpenLABEL, OpenXOntology and OpenSCENARIO. |
Author |
Pierre R. Mai on behalf of Jason Zhang, pmai@pmsfit.de; jason.zhang@warwick.ac.uk. |
Type of use case |
Technical Use-Case |
Description |
The SensorData output interface was already aligned with earlier drafts and releases of the ISO 23150 standard; given further developments in ISO 23150 and the AUTOSAR ADI rendering of ISO 23150, further alignment is sought, where possible and useful, with those definitions. |
Author |
Pierre R. Mai, pmai@pmsfit.de. |
Type of use case |
Technical Use-Case |
Description |
While OSI has had support for the separation of static and dynamic data during a simulation run for performance purposes, since OSI 3.4.0, it is left to implementations to define what is considered static information. To aid interoperability, a clearer definition of what is to be considered static information is to be included in the OSI standard. This might include further clarifications at attribute level on whether some information is considered static or dynamic. |
Author |
Pierre R. Mai on behalf of Thomas Hempen, pmai@pmsfit.de, thomas.hempen@carissma.eu. |
Type of use case |
Technical Use-Case |
Description |
While the standard packaging layer for OSI is specified in OSMP using FMI, there are a number of use cases where ROS2 is used as a standardized middleware in conjunction with OSI. For this it would make sense to create a standardized packaging layer description for use with ROS2. |
Author |
Pierre R. Mai on behalf of Thomas Hempen, pmai@pmsfit.de, thomas.hempen@carissma.eu. |
2.3. Requirements
Requirement |
Description |
technical requirement 1 |
OSI shall provide a semantic traffic sign classification scheme that is able to support international traffic signs, i.e. beyond the StVO set currently supported. |
technical requirement 2 |
The semantic traffic sign classification scheme shall be aligned with OpenDRIVE and OpenSCENARIO. |
| Requirement | Description |
|---|---|
technical requirement 3 |
OSI shall provide more detailed abstract geometry representations that go beyond the current singular bounding boxes and contour outlines, without relying on detailed geometric models as supported by the model references. |
technical requirement 4 |
The detailed abstract geometry representations shall fully support dynamic behavior of the represented objects. |
| Requirement | Description |
|---|---|
technical requirement 5 |
OSI shall provide speed limit and other related limit information within the lane (or the newly introduced logical lane). |
| Requirement | Description |
|---|---|
technical requirement 6 |
OSI shall provide additional optional interfaces and model types for vehicle internal AD functions, like motion planning and vehicle dynamics control. |
| Requirement | Description |
|---|---|
technical requirement 7 |
OSI shall be enhanced with an optional profile to support spaceflight and related robotics applications, without impacting existing application areas. |
technical requirement 8 |
OSI range rules for existing osi3::EnvironmentalConditions should be relaxed in the space application profile to support atmospheric pressure and temperature conditions in spaceflight applications. |
technical requirement 9 |
The type list in osi3::MovingObject::VehicleClassification shall be extended in the space application profile to include types for spacecrafts (like satellites, orbiting or ground-stations) and rovers. |
technical requirement 10 |
In the next major release of OSI, thought should be given to make names like TrafficCommand/TrafficUpdate etc. more generic for other application domains. |
technical requirement 11 |
Full support for accellerometer and inertial measurement unit sensors as required for space applications shall be implemented in relevant messages. |
technical requirement 12 |
Support for arbitrary directional velocity/accelleration changes shall be implemented in relevant Actions. |
technical requirement 13 |
Actions to support the docking/joining of vehicles shall be added. |
technical requirement 14 |
Movement and Position updates shall be expressible relative to other moving objects and/or in moving reference coordinate systems (for orbital movements). |
| Requirement | Description |
|---|---|
technical requirement 15 |
OSI shall be enhanced with refactored and broadened techology-specific SensorView and SensorViewConfiguration sub-messages based on SETLevel project results. This includes e.g. support for MIMO sensing technologies as well as more clearly-defined fields for existing sensing technologies. |
| Requirement | Description |
|---|---|
technical requirement 16 |
The OSI SensorView and SensorViewConfiguration interfaces shall be enhanced to better support ray tracing technologies while treating both environment simulation and/or ray-tracing models and sensor models as black-box models. |
| Requirement | Description |
|---|---|
technical requirement 17 |
The OSI SensorView and SensorViewConfiguration interfaces shall be enhanced to better support interference avoidance modeling in sensor models in congested environments. |
| Requirement | Description |
|---|---|
technical requirement 18 |
OSI shall be enhanced with a new streaming interface type that allows the exchange of e.g. traffic update (and other GroundTruth update) information as it becomes available, rather than as a fully integrated update as currently provided by SensorView/GroundTruth messages. This new interface type will support e.g. attachment of visualization systems. As part of the interface type the control plane for such applications shall be considered. |
| Requirement | Description |
|---|---|
technical requirement 19 |
OSI shall be enhanced to support the differentiation of all NCAP target types in the supplied GroundTruth/SensorView data. Where no direct enhancements to the interface definitions are needed, how-to information on mapping NCAP target types to GroundTruth information shall be added to the documentation. |
| Requirement | Description |
|---|---|
technical requirement 20 |
OSI shall be enhanced to support the more detailed representation of pedestrian behavior, including limb articulation, in GroundTruth/SensorView data, as well as relevant update messages. |
| Requirement | Description |
|---|---|
technical requirement 21 |
OSI shall be enhanced to support the transportation of additional real-world sensor data in its SensorData interfaces, where this data can be standardized across platforms and sensors. |
| Requirement | Description |
|---|---|
technical requirement 22 |
The current separation of data definition layer and encoding layer in the OSI architecture shall be enhanced to more easily support the use of OSI definitions across other encodings or for internal data model synthetization. Existing support for this shall be documented more clearly in the OSI and OSMP supporting documentation. Especially the layer separations and the restricted IDL subset used shall be documented more prominently to support mapping to other encodings/middleware. |
technical requirement 23 |
As part of the switchover of the encoding layer for the next major release of OSI, relevant changes to the data definition layer in terms of DDL/IDL to-be-used shall be considered to better support the already existing independence between data definition layer and encoding layer. |
| Requirement | Description |
|---|---|
technical requirement 24 |
The ability to model the surface of roads between lane boundaries and inside junctions needs to be added to OSI. This should be aligned with OpenDRIVE approach to that description, while interacting correctly with the current surface description that is part of the lane boundaries. |
| Requirement | Description |
|---|---|
technical requirement 25 |
Interfaces for the transmission of intermediate processing results of sensors, like object identification or depth maps, needs to be added to OSI. This should take into account the changes developed as part of the SETLevel project in this regard. |
| Requirement | Description |
|---|---|
technical requirement 26 |
The environmental condition data in SensorView shall be extended to provide more relevant details needed for physical sensor modeling. The additions shall be aligned with similar enhancements discussed in the OpenSCENARIO and OpenODD working groups. |
| Requirement | Description |
|---|---|
technical requirement 27 |
Where possible and useful, terminologies on the operational domain definition should be aligned with other relevant ASAM standards, like OpenODD, OpenLABEL, OpenXOntology and OpenSCENARIO. |
| Requirement | Description |
|---|---|
technical requirement 28 |
The SensorData output interface was already aligned with earlier drafts and releases of the ISO 23150 standard; given further developments in ISO 23150 and the AUTOSAR ADI rendering of ISO 23150, further alignment is sought, where possible and useful, with those definitions. |
| Requirement | Description |
|---|---|
technical requirement 29 |
A clearer definition of what is to be considered static information is to be included in the OSI standard. This might include further clarifications at attribute level on whether some information is considered static or dynamic. |
| Requirement | Description |
|---|---|
technical requirement 30 |
An additional packaging layer specification for use with ROS2 shall be made available. |
2.4. Relations To Other Standards And Organizations
Relations to other ASAM standards
-
ASAM OpenDRIVE
-
ASAM OpenSCENARIO 1.x and 2.x
-
ASAM OpenCRG
-
ASAM OpenLABEL
-
ASAM OpenXOntology
These relationships are taken into account in the harmonization-related work packages through participation by experts from the relevant standards, as well as activities in the CG:SIM coordination group for harmonization.
Relations to upcoming ASAM standards or ASAM development projects
Currently no overlap with upcoming standards or development projects is foreseen, with the obvious exception of any follow-on projects to the above mentioned standards, which will be dealt with as given above.
Relations to non-ASAM standards
-
ISO 23150 https://www.iso.org/standard/74741.html
This standard will be taken into account in the SensorData-related work packages, together with the AUTOSAR mapping thereof, called AUTOSAR ADI.
Since those areas are already mostly harmonized with the existing ISO 23150 release, only minor adjustments are anticipated.
-
This is the AUTOSAR mapping of the ISO 23150 abstract standard.
-
Modelica Association FMI 3.0
The OSMP specification will be adjusted to support the new FMI 3.0 standard directly for packaging of models.
3. Technical Content
3.1. Performance & Packaging
Given the increasing scope of OSI, as well as the higher degree of detail that can be transported, the area of performance and packaging will need incremental and non-incremental improvements to allow the use of OSI across the whole range of use cases, from real-time HiL simulations, faster than real-time object-level simulation, to slower than real-time highly detailed physics-based simulations.
This entails a structured migration path to Google Flatbuffers as the encoding layer going forward, based on the experimental Flatbuffers support in OSI 3.4/3.5, and the performance evaluations in the OSI 3.5 project and the SETLevel project.
Based on those results, as a first step, full support for Flatbuffers encoding as an option will be developed for the next minor release, fixing issues identified in OSI 3.5 and the performance evaluations. This will include decision on how to map certain aspects of the current definitions to Flatbuffer tables and structs.
Once this work is completed and further experience has been gained in the use of Flatbuffer encoding with no show stopping problems, the Flatbuffer encoding will be promoted to the main encoding, with ProtoBuf encoding relegated to legacy status in the next major release.
As part of this work the clear separation between the data definition layer and the encoding layer will be enhanced: While the data definition layer uses the ProtoBuf IDL, it is independent of either ProtoBuf or any particular encoding layer, as demonstrated by the move to Flatbuffers. The documentation will be enhanced to show-case this existing capability also for other use cases, including UC13.
As part of the major release work, beneficial changes to the DDL/IDL to be used for the data definition layer will be examined and implemented where considered useful to enhance the separation between data definition and encoding layers.
Similarly, an additional packaging layer specification for use with ROS2 as the component technology is planned to be introduced. As part of this work, the refactoring of common content across packaging layer specifications into a base layer is planned.
Related to this packaging work, further specifications on the static vs. dynamic properties of message content is expected.
3.2. Road Model
OSI 3.4 introduced the new concept of LogicalLanes enabling the description of lane information independent of the physical layout. The main purpose of the newly introduced separate logical lane information stemmed from the need for a road and lane description more suited for traffic participants.
In order to clearly separate physical and logical lane information further work needs to be done documenting the intended use for physical and logical lanes. Additionaly, the current content of the Lane message will be revised and cleaned up for OSI 4.0 deleting no longer needed information moved to the logical lanes.
Additional information that is beneficial to LogicalLane consumers, like traffic participant models, is to be added where relevant: One example is the speed limit information of UC3 (requirement 5), which should be handled in conjunction with the overall TrafficSign alignment, and a generic approach to linking applicable signs to logical lanes or parts thereof.
Overall refactoring of the surface description of lanes, e.g. the surface line proposal, as well as the handling of lane boundaries is included in this overhaul. The definition of lane boundary heights (e.g. curb heights) should be clarified in line with the potential surface line approach and the ISO 23150 standard.
3.3. Semantic Traffic Sign Classification
The traffic sign classification has been adapted in OSI v3.4 in such a way, that the traffic sign properties from an OpenDRIVE road can directly be used. For this “code, “subcode”, “country” and “countryRevision” have been introduced (to match with "type", "subtype", "country" and "countryRevision"), while a deprecation-remark has been added to the existing traffic sign type enumeration. By this the traffic sign classification has been aligned between OpenDRIVE and OSI.
However, further adaptation of the traffic sign classification is needed. It seems beneficial to introduce a generalized semantic classification of traffic signs. By this it would be possible for OSI consumers to understand traffic signs more easily. The development of a generalized semantic classification of traffic signs needs to be done in close collaboration with the other OpenX standards, especially OpenDRIVE.
Removing or reinterpreting the existing traffic sign type-enumeration would necessitate a major OSI version.
This work will take requirements 1-2 from UC1 into account.
3.4. Enhanced Geometry Modeling for GroundTruth
The currently fairly limited BoundingBox and Contour-based abstract modeling of geometry in GroundTruth shall be enhanced to allow a more fine-grained, yet still abstract modeling of the geometry, without resorting to exact 3D geometry models.
This will include necessary enhancements for NCAP target types, pedestrians, dynamic moving object behavior, and complex stationary objects, as detailed in requirements 3, 4 (UC2), 19 (UC10), and 20 (UC11).
3.5. Technology-specific Sensor Modeling
The enhancements suggested by requirements 15, 16, 17, and 21 (related to UC6, UC7, UC8, and UC12) to the SensorView and SensorViewConfiguration interfaces are developed in a unified way and integrated into the upcoming minor and major releases.
3.6. Streaming Interface for Visualization
Based on UC9, requirement 18, a new streaming interface type to support visualization and other evaluatory applications will be developed. This interface will allow consumers to receive incremental updates on the changing ground truth situation as soon as they become available: Where the existing SensorView interface will always provide a consolidated and therefore internally consistent state for a certain point in time, the new streaming interface will provide piecemeal updates as soon as they become available. This can even be ahead-of-time due to different rates of calculation for different models. It is then the responsibility of the recipient to ensure consistency in its use of the data. This lower-latency interface is especially important for visualization purposes to enable sufficently smooth updates for human consumption.
The developed interface will also take necessary minimum control plane messaging into account.
3.7. Space Applications Profile
Based on the requirements 7-14 (UC5) for space-based applications of OSI, an optional space applications profile will be developed with necessary additions beyond the current automotive domain.
Where necessary or beneficial, general enhancements to the core standard are performed in a backward-compatible way for the next minor release. For the next major release changes to make certain names in the core standard more generic will be developed where useful to better support all application domains.
3.8. Vehicle-internal Interfaces
With the introduction of the TrafficCommand and TrafficUpdate messages suitable interfaces between the simulation engine and traffic participants models (automated and non-automated road users) have been introduced. While these can be used for test cases simulating the overall behaviour of the device under test, standardized simulations with exchangable models for (sub-) components of the vehicle can not performed.
In order to enable the usage of standardized component models for components such as trajectory controller models and vehicle dynamic models additional message are needed. While a first draft was for an interface between HAD function and trajectory controllers was developed in the last project, additional work needs to be done.
In a first step, the started work in the last will be finished, taking requirement 6 (UC4) into account. In the next step, additional interfaces needing standardized messages will be identified. Based on this result relevant messages can be developed considering flexibility to support a variety of use-cases.
3.9. Project Resources
3.9.1. Work Packages [WPs]
3.9.1.1. Performance & Packaging
Description |
Structured migration path to Google Flatbuffers as the encoding layer going forward, based on the experimental Flatbuffers support in OSI 3.4/3.5, and the performance evaluations in the OSI 3.5 project and the SETLevel project. |
Related issue in Gitlab (optional, if applicable) |
https://github.com/OpenSimulationInterface/open-simulation-interface/issues/56 |
Type (optional) |
Improvement |
Target content (optional) |
Documentation, Implementation |
Deliverable |
Full support for Flatbuffers encoding as an option will be developed for the next minor release, fixing issues identified in OSI 3.5 and the performance evaluations. This will include decision on how to map certain aspects of the current definitions to Flatbuffer tables and structs. |
Effort (person days) |
60 |
Participating company |
PMSF (20), BMW (15) |
Responsible |
Pierre R. Mai |
Description |
Enhance documentation to allow mapping of the OSI data model to additional encodings and other modeling languages. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Documentation |
Deliverable |
Enhancements to the documentation that will help other use cases to map the existing data model to different encodings or other modeling languages. |
Effort (person days) |
25 |
Participating company |
PMSF (5) |
Responsible |
Pierre R. Mai |
Description |
New packaging layer specification for packaging OSI models as ROS2 components. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Documentation, Implementation |
Deliverable |
Packaging specification for use with ROS2. |
Effort (person days) |
40 |
Participating company |
PMSF (5) |
Responsible |
Thomas Hempen |
Description |
Clarification of the static vs. dynamic parts of message data for use e.g. with GroundTruthInit and omit static data features of OSI. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Documentation |
Deliverable |
Clarified specification of static and dynamic parts of message data. |
Effort (person days) |
20 |
Participating company |
PMSF (5), BMW (15) |
Responsible |
Thomas Hempen |
Description |
Introduce a new interface with top-level messages for use as a streaming interface to world state updates, including any necessary control messages for relevant use cases. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Documentation, Implementation |
Deliverable |
New top-level messages for the interface, as well as related packaging layer definitions. |
Effort (person days) |
50 |
Participating company |
PMSF (15), BMW (20) |
Responsible |
Thomas Nader |
3.9.1.2. Harmonisation
Description |
Development of a generalized semantic classification. The workpackage contains research, exchange and alignment with OpenDRIVE/OpenSCENARIO and implementation. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Improved and aligned semantic classification of traffic signs. |
Effort (person days) |
70 |
Participating company |
(dSPACE GmbH), BMW (10) |
Responsible |
(Hendrik Amelunxen) |
Description |
Harmonisation of basic static ODD describing terminology with OpenODD, OpenDRIVE, OpenSCENARIO and as input to OpenXOntology. The workpackage contains research, exchange and alignment with OpenDRIVE/OpenSCENARIO/OpenODD and implementation. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Improved and enhanced ODD static terminology in relevant standard parts. |
Effort (person days) |
40 |
Participating company |
Warwick University |
Responsible |
Jason Zhang |
Description |
Harmonisation of dynamic ODD describing terminology with OpenODD, OpenDRIVE, OpenSCENARIO and as input to OpenXOntology. The workpackage contains research, exchange and alignment with OpenDRIVE/OpenSCENARIO/OpenODD and implementation, potentially also in backward-compatibility breaking ways. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Improved and aligned ODD static and dynamic terminology in relevant standard parts. |
Effort (person days) |
60 |
Participating company |
Warwick University |
Responsible |
Jason Zhang |
Description |
Provide further detailed alignment with new revisions of ISO 23150 and AUTOSAR ADI mapping thereof where applicable in the OSI context. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Improved and aligned SensorData interface. |
Effort (person days) |
40 |
Participating company |
BMW (10), PMSF (10) |
Responsible |
Carlo van Driesten or Thomas Nader |
3.9.1.3. Other Models
Description |
Rework of Bounding Boxes to support more fine granular geometric modeling without fallback on actual geometry. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Enhanced BoundingBox definitions. |
Effort (person days) |
40 |
Participating company |
(dSPACE, THI), BMW (5) |
Responsible |
(Hendrik Amelunxen, Thomas Hempen) |
Description |
Enhance message definitions to provide basic support for spaceflight applications as an optional spaceflight profile for OSI. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Spaceflight OSI Profile |
Effort (person days) |
30 |
Participating company |
(RIF) |
Responsible |
(Gregor Jochmann) |
Description |
Enhance message definitions to provide enhanced support for detailed pedestrian modeling, including limb articulation. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
OSI enhancements for pedestrian modeling |
Effort (person days) |
30 |
Participating company |
(THI), BMW (10) |
Responsible |
(Jakob Peintner) |
Description |
Add further top-level messages for vehicle-internal sub-models, like dynamic control, etc. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
OSI enhancements for vehicle-internal sub-models |
Effort (person days) |
40 |
Participating company |
(FZI), BMW (10) |
Responsible |
(Markus Lemmer) |
Description |
Enhance logical lane definitions to allow direct access to relevant speed limit information. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
OSI enhancements for logical lane speed limit information |
Effort (person days) |
10 |
Participating company |
(FZI), BMW (5) |
Responsible |
(Markus Lemmer) |
Description |
Map NCAP target types to corresponding OSI Moving/StationaryObjects and properties. Where necessary to map these types effectively, extensions to those properties and messages are developed and implemented. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Documentation, Implementation |
Deliverable |
Guidelines for mapping of NCAP target types, and OSI enhancements for additional properties |
Effort (person days) |
15 |
Participating company |
BMW (10) |
Responsible |
Lorenz Schmidt i.A.v. BMW |
3.9.1.4. Sensor Models
Description |
Allow transfer of intermediate camera sensor processing steps (prior to and post perception) in the relevant sensor interface messages (SensorView and/or SensorData) or potentially new messages. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Enhancements to the OSI sensor interface to allow intermediate camera sensor processing data to be exchanged |
Effort (person days) |
20 |
Participating company |
(RIF) |
Responsible |
(Gregor Jochmann) |
Description |
Based on refactorings in the SETLevel project, the VIVALDI/DIVP project, and other sources, a refactoring of the current technology-specific SensorView sub-messages will be undertaken to more clearly separate different interface levels between environment simulation and sensor models. This will include separation of concerns between rendering and sensor model parts of a model (cf. blackbox ray tracing use case). |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Refactored SensorView/SensorViewConfiguration messages |
Effort (person days) |
70 |
Participating company |
(Toyota TD, Persival, TUD, PMSF), BMW (10) |
Responsible |
(Mine Seki, Philipp Rosenberger, Lukas Elster, Pierre Mai) |
Description |
The SensorView interface for radar is to be enhanced to support bi-static radar, interference and MIMO effects. |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Enhanced RadarSensorView/RadarSensorViewConfiguration messages |
Effort (person days) |
20 |
Participating company |
(Toyota TD) |
Responsible |
(Mine Seki) |
Description |
The SensorData interface will be enhanced as needed to better support real sensor data being represented |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Enhanced SensorData message |
Effort (person days) |
60 |
Participating company |
(THI) |
Responsible |
(Thomas Hempen) |
Description |
The environmental conditions represented in OSI shall be enhanced in alignment with other OpenX projects to better support physical sensor models |
Related issue in Gitlab (optional, if applicable) |
|
Type (optional) |
Improvement |
Target content (optional) |
Implementation |
Deliverable |
Enhanced Environmental Conditions message |
Effort (person days) |
30 |
Participating company |
(ADAC) |
Responsible |
(Yasuyuki Nakanishi) |
3.9.1.5. Project Coordination
Description |
A subgroup of experts in the project responsible for internal alignment of topics, release management & approval/review of pull requests. The CCB has at a minimum a representative from each working group, from ASAM and the PL. 
Figure 1. The CCB structure
CCB Tasks:
|
Effort (person days) |
2 hour meeting every 2 weeks + offline review of content as preparation. 76 weeks project duration → ca. 6-8 days per person. At least 4 participants are required → 30 days total |
Participating company |
(PMSF, Persival, Hexagon, CARIAD, ANSYS, Siemens, BMW) |
Responsible |
(PL, TBD) |
Description |
Integration of the OSI reference documentation (from doxygen) with the OSI user guide (from asciidoc) into a unified document. Currently the OSI standard consists of separate documentation for the reference documentation and for the user guide. A Proof of Concept was created and shared with the project, it is available for review here. The consolidation of both documents would also allow the simplification of the repository structure, which would improve the workflow. The unified documentation would provide the following benefits:
This WP will be coordinated by the ASAM office and all work will be performed by a service provider. |
Effort (person days) |
20 |
Participating company |
Service provider only (with CCB review) |
Responsible |
ASAM office |
3.10. Company Commitments
| Company | Commitment | Participants | Participant Email |
|---|---|---|---|
ADaC |
30 |
Masahiko Kohda |
|
AVL |
30 |
Klaus Schuch |
|
BMW Group |
50 |
Thomas Nader |
|
BMW Group |
30 |
Lorenz Schmidt |
|
CARIAD |
30 |
Marc Semrau |
marc.david.semrau@cariad.technology |
dSPACE |
30 |
Hendrik Amelunxen |
|
FZI Forschungszentrum Informatik |
30 |
Markus Lemmer |
|
Hexagon |
30 |
Adrian |
|
Hexagon |
30 |
Esther Hekele |
|
KAIT/ADaC |
30 |
Yasuyuki Nakanishi |
|
KAIT/TTDC |
30 |
Mine Seki |
|
KAN Engineering Ltd |
30 |
Ashwil Kaniamparambil |
|
KAN Engineering Ltd |
30 |
Rajive Wisidagama |
|
Mercedes-Benz AG |
30 |
Martin Stump |
|
PMSF IT Consulting |
50 |
Pierre R. Mai |
|
PMSF IT Consulting |
50 |
Thomas Sedlmayer |
|
RIF e.V. |
30 |
Gregor Jochmann |
|
Siemens |
30 |
Rajesh Kumar |
|
THI |
30 |
Georg Seifert |
|
THI |
30 |
Jakob Peintner |
jakob.peintner@ carissma.eu |
THI |
30 |
Thomas Hempen |
thomas.hempen@ carissma.eu |
THI |
30 |
Yahyaei Mahdi |
mahdi.yahyaei@ carissma.eu |
Vector Informatik |
30 |
Jakob Kaths |
|
WMG |
30 |
Jason Zhang |
3.11. Effort Summary
| WP category | Project members | Service provider | Total |
|---|---|---|---|
WP1 |
60 |
0 |
60 |
WP2 |
25 |
0 |
25 |
WP3 |
40 |
0 |
40 |
WP4 |
20 |
0 |
20 |
WP5 |
50 |
0 |
50 |
WP6 |
70 |
0 |
70 |
WP7 |
40 |
0 |
40 |
WP8 |
60 |
0 |
60 |
WP9 |
40 |
0 |
40 |
WP10 |
40 |
0 |
40 |
WP11 |
30 |
0 |
30 |
WP12 |
30 |
0 |
30 |
WP13 |
40 |
0 |
40 |
WP14 |
10 |
0 |
10 |
WP15 |
15 |
0 |
15 |
WP16 |
20 |
0 |
20 |
WP17 |
70 |
0 |
70 |
WP18 |
20 |
0 |
20 |
WP19 |
60 |
0 |
60 |
WP20 |
30 |
0 |
30 |
WP21 |
30 |
0 |
30 |
WP22 |
0 |
20 |
20 |
Total |
800 |
20 |
820 |
Currently no service provider is required for the project work. Major changes to the documentation infrastructure are considered to be under the guidance of the ASAM Project Office but are included in this proposal for transparency.
| Project members | Service provider | Total | |
|---|---|---|---|
Required |
860 |
20 |
820 |
Committed |
648 |
0 |
648 |
If not enough resources are contributed to cover the whole work programm, then the scope of some of the larger harmonisation and refactoring WPs, like WP6, WP7, WP8, WP17, and WP19 will be reduced. Especially the harmonisation work packages WP6-8 depend on contributions from the other projects, like OpenDRIVE, and OpenODD.
3.11.1. Budget
|
This section details the budget required by the project to pay service providers, for example, and the funds to be provided by ASAM. The limits are determined as a factor of the total required work effort. The corresponding effort is allocated a fixed price of 700 EURO per person day.
|
| Task description | Effort [person days] | Cost |
|---|---|---|
WP 22 - Document consolidation |
20 |
14.000 |
3.12. Project Plan
3.12.1. Timeline
|
Timeline of work packages may change after the project has started. Especially the parallelization of WPs will be determined by the sub-working group internal scheduling. |
3.13. Deliverables
At the end of the project, the project group will hand over the following deliverables to ASAM:
| Item no. | Description |
|---|---|
01 |
Release Candidate for OSI V3.6.0 |
02 |
Release Candidate for OSI V4.0.0 |
3.14. Review Process
The project will carry out the following quality assurance measures:
-
[X] Continuous public and project member review on GitHub for all PRs
-
[X] Project CCB review for all PRs
-
Project member review
-
[X] Public review
-
Reference implementation