ASAM OSI Kick-off Workshop

Date: February 21, 2020

Location: ASAM e.V.

Report: ASAM OSI Kick-off Workshop


1. Introduction

On behalf of ASAM we would like to thank our almost 100 participants of the recent kickoff workshop for the ASAM Open Simulation Interface (OSI). We had participants from all across the globe, ranging from OEMs, to Tier 1s, tool vendors and hardware suppliers.


Klaus Estenfeld (ASAM) began the day by presenting an Overview of ASAM for those new to the table.


2. Open Source @ ASAM

Ben Engel (ASAM) then presented an overview of the new Open Source Project Process at ASAM. This presentation is intended to give a first insight into how we are planning to manage open source projects and tooling at ASAM.


In short, ASAM will have two project types:

  • Open release - Only releases are open and available to the public - no external contributions (ASAM OpenSCENARIO)
  • Open source - Entire workflow is open, contributions by non-project members are permitted (ASAM OSI)


In addition, ASAM will provide an open platform on e.g. GitHub to host complimentary tools to its standards. Submission to this platform is via an "Open Source Tool Proposal", the template for which will be made available in the near future.


The legal side of contributing to ASAM open source projects will be covered by the Developer Certificate of Origin  for all contributions, with member companies having the option to sign an additional Member Contributor Agreement with a list of authorized contributors. Project licenses will be project-specific and selected from a list of recognised open source licenses 


Any feedback on what we can improve to allow your companies to participate is welcome: Please contact us at info(at)


3. Introduction to OSI

Presentation by Carlo van Driesten (BMW) on: What is OSI?


4. Workshop Session: What is OSI for you?

The purpose of this workshop was to review the participants' use cases for OSI in order to gain an overview of current or future requirements on the Standard. This will be used as input for the upcoming project proposal.



Description format for object lists of idealized sensor data

  • Integration of raw sensor data (e.g. lidar point clouds)

  • Inclusion of further object data, e.g. 3D models



Unified way to express environment data


Interface to bridge the virtual and real worlds. Still missing:

  • moving objects do not include assigned lane Ids

  • include lane parameters of the lane model



Real representation of the state of the virtual world (i.e. ground truth), e.g. references to the lane parameters by referencing OpenDRIVE


OSI should contain references to and harmonise with OpenX standards


Generic interface to tools in the Simulation tool landscape


Generic Data Model to represent tool internal data structures


Generic representation of sensor data

  • OSI does not implement vendor specific sensor data

  • radar, lidar, camera, ultrasonic sensors are currently supported (to varying degrees)
    → Should be extended (e.g. increased support for ultrasonic, V2X, etc.)



Representation of sensor specific material information. As a messaging format, OSI should be able to include such data but will not define the information itself (i.e. will be defined by other standards) e.g. refer/make use of MDL


5. Currently Planned Features & Enhancements

Presentation by Pierre Mai (PMSF IT) on: Currently Planned Features and Enhancements


Additional content by Thomas Nader (BMW), Clemens Habedank (IAV), Thomas Schlömicher (AVL)(not presented): Empowering OSI - Beyond Sensor Modelling


6. Workshop Session: Work packages for a new ASAM OSI project

Goal: Identify and cluster topics for a first ASAM OSI development project


4 initial work packages identified:

  • Physical sensor modelling (i.e. a better ground truth)
  • Traffic participants & roadside infrastructure
  • OSI performance and packaging (e.g. improvements for real time)
  • Harmonization with other OpenX standards

Right now a project proposal is being developed. Four webex meeting are scheduled to further discuss the work package content and begin bringing it and relevant use cases into the project proposal (


Each meeting is planned for 1 hr: 

  1. Physical sensor modelling - Mar 16, 2020 @ 10:30 CET – Webex link – Meeting password: ZRfh7phW7r4 
  2. OSI performance and packaging - Mar 16, 2020 @ 14:00 CET – Webex link – Meeting password: YqphYF2tw74 
  3. Traffic participants & roadside infrastructure - Mar 17, 2020 @ 10:30 CET – Webex link – Meeting password: p6wM6KVhVW4 
  4. Harmonization with other OpenX standards - Mar 17, 2020 @ 14:00 CET – Webex link – Meeting password: npTZAwRh655 


The meetings are open to anyone so please feel free to join! If you or your company have a further work package you feel needs to be considered, please get in touch with benjamin.engel(at) and we will support you in checking for other interested parties.



6.1. Physical sensor modelling (i.e. a better ground truth)

  • What is ASAM OSI, what is it not (boundaries)
  • What is a sensor? Is a driver a sensor?
  • Harmony with lane modeling
  • ASAM XIL - can we standardize ASAM OSI so it couples with the XIL automation interface?
  • We have the SIM element, but what about vehicle in the loop and what interfaces to them?

6.2. Traffic participants & roadside infrastructure

  • Other non ego agents treated similar to ego agent with reduced complexity (maybe with less sensor models)
  • better description of traffic participants & pedestrians
  • wheels and their movement
  • to what abstraction level could pedestrians be described in osi
  • external control of agents (no behavior models but maybe e.g. osc) * need to integrate osc descriptions into osi
  • identification of pedestrian rules
  • separate dynamic model from environmental model? can osi help here?
  • v2x sensor?

6.3. OSI performance and packaging (e.g. improvements for real time)

  • how efficiently can you package an osi message
  • 500mb or more is very hardware dependent. what are the options?
  • protobuf can be compiled to proto2/3 or even flatbuffer, each has adv. / disadv.
  • for hil - flatbuffer
  • → documentation or hints on which approach to use for which use case? (encoding, memory handling, etc.) / real time vs non real time
  • fmi behavior in these use cases? currently fmi does not "need" to provide a response
  • → Should this be solved with a minimal response? i.e. "no answer"
  • best practices:
  • maintain a usage guide for different implementations

6.4. Harmonization with other OpenX standards

  • layered structure for a productive co-simulation

7. Next Steps

  1. Begin preparing a project proposal - anyone can contribute via the repository below, just register and submit a merge request with your content. The most up to date version of the proposal can be downloaded on the project page.

    To get the momentum going, we decided to start with at least one webex for each of the previously determined work packages. The dates and links for these webexes will be sent around in an email to all registered participants. These meetings will be used to begin bringing the workshop content into the project proposal. Expected outcome for each Work Package:
    Technical motivation for the WP & use cases & the features/improvements these will lead to
  2. Once the project proposal has enough content, ASAM will host a proposal workshop. This workshop will refine the project proposal by:
    • Coming up with a project timeline & roadmap based on the features detailed
    • Defining resource requirements for the project
      • Man-days to complete the project roadmap 
      • Service provider requirements
    • Gathering initial (non-binding) resource comittments (man-days) from interested companies
  3. The project proposal refined in 2) will then be presented to the ASAM TSC and, if approved, an ASAM project will be initiated.
Stay informed! Subscribe to our Newsletter.