APIs for Virtual Testing

Authors:
Cansin Demir, Ramakrishna Nanjundaiah
// Published
2/8/2021

The facilitating technology for collaboration on the software level are Application Programming Interfaces (=API), which enable data exchange between solution A and B.

Introduction: 

In today’s complex global ecosystem suppliers understand the importance of partnerships and collaboration to provide a superior solution for the end customer. The facilitating technology for collaboration on the software level are Application Programming Interfaces (=API), which enable data exchange between solution A and B. In this article we will explain APIs, the relevance for autonomous driving (=AD) and how it is applied at Phantasma. 

Overview Coupling (Source: Phantasma)

What is an API? 

API stands for Application Programming Interface. An API is a set of definitions and protocols for building and integrating application software. In basic terms, APIs are a set of functions and procedures that allow for the creation of applications that access data and features of other applications, services, or operating systems. Benefits are twofold for developers as well as end users. In short, APIs let you open up access to your resources while maintaining security and control

What is the context of APIs in the AD simulation environment? 

In the simulation domain many established  players have a core expertise and then there are smaller suppliers which complement those solutions. In the context of virtual testing of autonomous systems, the epicenter of the simulation domain is the environmental simulator, such as Carla, IPG or VTD. The interacting entities and subsystems (e.g. Sensors, Vehicle Dynamics, HiL, SiL)  that collectively represent the autonomous driving functions are so complex that no single environment simulator can model them to the required level of accuracy.  For this reason, environmental simulators can be seen as an orchestration platform through which several subsystems that are developed by other providers can be seamlessly integrated - via APIs  Let's assume the environmental simulator starts an execution sequence  at time  t=0, at which the state of subsystems should be initialized. The initialization involves passing a set of information between the environment simulator and the subsystems, such as the information of the map, the position of the entities in the environment, the state sensors etc. Once the simulation and the subsystems are initialized, the environment simulator marches to time t+Δt and exchanges a different set of information from the subsystems. In the meantime the subsystems are computing their new states at t+Δt based on the information received by the environment simulator at time t.  While this process is conceptually simple, it is technically a hard problem to implement as different subsystems send and receive information in different formats and compute at different time scales. This calls for establishing API standards for:

  1. Co-simulation protocols (in simple terms, the language in which information is communicated)
  2. Communication protocols (the medium through with communication is done)

API based data exchange (Source: Clemens Habedank ASAM OSI Working Group)

In the AD context, the R&D engineers define a test plan and then require the different components to test and validate the features. Seamless interaction between the components is essential for a successful execution of testing and validation plans. Some examples of such components are HD Maps, Scenario Databases, Sensor Models and Behaviour Models etc.; 

At Phantasma Labs, we take care of the co-simulation subsystem that deals with providing accurate human behaviour through our behaviour models. We work closely with our customers, environment simulation providers and also standardization bodies to establish an efficient interface for integrating VRU behaviour models into environment simulators. However, there are still many open topics, which need to be addressed, such as: 


Which interfaces are currently applicable? 

  • Functional Mock-up Interface (FMI) combines a container and an interface to exchange dynamic models based on XML files, binaries and C code united in one file (e.g. preferred co-simulation format of Robert Bosch GmbH). 
  • MATLAB/Simulink
  • C code
  • Open Simulation Interface (OSI)
  • Carla and other open-source tools use own API interfaces written specifically for their own environments. New upcoming ES also have their own interface written in C++, python or C#, which is also a hindrance in trying to standardize the api interface.)

What are challenges and limitations? 

Currently there is not one standard for interfacing with several tools. This leads to major integration efforts till cycle times, parameter exchange and other factors are synchronically adapted to each other. To integrate with the various Environmental Simulators out there, the team has to read & understand the specific requirement within the API documentation and jointly define a way to establish a process without impacting performance. One additional argument, which currently holds back the roll out of a standard interface are the performance downturns of coupling this way. 

  • OSI: Focus on Sensor View (limited application)
  • FMI: Performance Disadvantages 

What is the idea behind establishing an interface standard?

  • The ability to have an open tool chain where you can exactly define what information is exchanged 
  • Simplify the interfacing process - connect to all tools the same way (process & cost efficient) 
  • Prototyping & testing becomes much easier
  • A standard requires multiple parties to interact and contribute, which means the solution might more powerful and valid 

Sources: 

OSI: 

FMI:


//Contact Form

Thank you! Your message has been received and someone will be in contact with you soon.
Oops! Something went wrong while submitting the form.