LAVA

Linking ADAS Via Android (LAVA) is a research and development project, driven by the latest trends in the automotive industry regarding in-vehicle communication targeting the connection between Advanced Driver Assistance (ADAS) and Android-based Infotainment systems. There are two main aspects of this project solution. The first is leveraging automotive SOA paradigm and enabling exchange of the data coming from hardware resources and software components between ADAS and Infotainment platforms over SOME/IP and DDS and ensuring inter-operability with Android binder IPC. The second is making the solution automated by utilizing only the Interface Definition Languages (IDLs) typical for standards used in these two domains (AUTOSAR XML – ARXML, Android IDL – AIDL, Franca IDL – FIDL, and OMG IDL) and the principles of the Model Driven Development (MDD). The first aspect of the solution encountered the challenges regarding definition of the suitable communication protocols and embracing the SOME/IP and DDS as Service-oriented Architecture (SOA) mechanisms for signal messages and smaller amounts of exchanged data. Besides, LAVA solution provides the DataChannelAPI for big data streams where SOME/IP and DDS are not suitable. The second aspect of the solution encountered the challenges of AIDL and OGM IDL meta-models implementation and further translation between the ARXML, AIDL, FIDL, and OMG IDL models. The generation of the actual code of communicating parties and distributing the data through the system are also covered by this solution.

Background, Motivation, and Problem Statement

Unsustainable solutions for enabling connectivity between hundreds of stand-alone Electronic Control Units (ECUs) led to evolution of the automotive system architecture to domain-structured ecosystem. This way, the vehicular components are decoupled on several major domains based on the functionality they perform. Even such evolution of automotive system architecture was not enough to encounter the connectivity challenges inherited from the comprehensive functionality requirements of the modern vehicles. The main reason is because likewise grouped domains are having the minimal interference with each other which results with multiple utilization of the same hardware resources and multiple implementations of the same algorithms with the purpose to obtain the same data within different domains.

Domain-structured, zonal-structured, and centralized architecture

From that reason, connectivity challenges have been approached from the two perspectives:

• wiring problem, i.e. determining the exact communication mechanism, i.e., in-vehicle bus suitable for exchanging data coming from sensors, actuators and processing units
• determining the exact communication mechanism, i.e., protocol suitable for particular case of exchanging data coming from software components and algorithms

Wiring problems are solving through the enhancement of the in-vehicle buses performances and by further evolving of the automotive system architecture to zonal-structed and completely centralized ecosystems. Zonal and completely centralized architectures are not threatening to eliminate the nature of decoupled processing units which implements ADAS and Infotainment use-cases (regardless of whether they are on the same of physically separated platforms). But only to enable better hardware utilization by connecting them to the same sensors, actuators or other processing units specialized for certain functionality. On the other hand, zonal-structed and centralized approaches are not solving the problem of determining and implementing the exact communication mechanism, i.e., protocol suitable for particular case of exchanging data coming from algorithms and software components. Because of system heterogeneity, more efficient solution is required to enhance not only the inter-domain communication, but the entire integration of components simultaneously and separately developed by different teams or even vendors.

From the software complexity point of view, Advanced Driver Assistance System (ADAS) and In-Vehicle Infotainment (IVI) domains are representatives of the new era vehicle functionality demands. Therefore, achieving inter-operability between these domains is the big aspect of enhancing the entire vehicle performance. LAVA is automated solution which covers both aspects of the connectivity challenges stated above by allowing reusability and exchanging data coming from both, hardware resources and software components between ADAS and Android-based IVI processing units following the Original Equipment Manufacturers (OEMs) standards of choice for each domain.

Goals & Benefits

Android Automotive is being adopted by the OEMs as a system of choice for IVI domain at a fast pace mainly because representing the proven embedded solution with rich application development ecosystem. On the other hand, Service-Oriented Architecture integration within the automotive industry is trailblazing approach which arise SOME/IP as a protocol specifically designed to adopt the SOA principles and DDS to fullfil QoS demands in the automotive use-cases. SOA mechanisms enabled easier design, integration, and maintenance of complex systems by allowing encapsulation of the particular component and its jobs in the entity called service which can be offered and consumed by the clients without clients being acquainted with the specifics of the service implementation. Therefore, the main goal is to bridge the gap between ADAS and newly adopted Android Automotive OS Infotainment and integrate Android in overall car SOA. This will benefit not just in a way of better resources utilization, but the evolvement of Android community by shifting the focus on building the Android applications having the data from ADAS software components, algorithms and hardware resources completely available.

Additionally, IDLs enable the generative programming to get its role by generating the lower layer of the communication enabling developer to focus on the implementation of components itself and not the communication mechanisms. Considering that, speed of the development cycles can be even more increased by the solution automation and reducing the custom integration to minimum.

Such automation implied enabling developers only to model the interfaces of the data to be exchanged in either of four common IDLs (ARXML, FIDL, AIDL and OMG IDL) and those interfaces shall be automatically translated to the remaining IDLs and the communicating parties in each domain will be generated by the LAVA generator too.

Use-cases

Enabling such inter-domain connectivity opens up the endless source of use-cases which can be beneficial for the automotive industry because with this solution there is no need for Infotainment systems to re-implement already existing algorithms from ADAS or involve already existing hardware resources in order to build their applications as it is the case with the following examples:

• Detected signs on the road are available within the Android applications by the information coming from reliable ADAS software components
• Notifications about driver drowsiness monitored by ADAS can be exposed in Android applications to propose the nearest rest areas
• It is possible to implement 2D or 3D visualization and Augmented Reality (AR) layouts  of the vehicle environment perception based on the information about the detected road lanes, detected traffic participants, their positions, speed and movement predictions
• It is even possible to implement applications for driver coaching which will communicate the optimal paths, steering and movement in general based on the ADAS algorithms for paths optimizations. This use-cases can be particularly useful for racing and supercars as already recognized by RIMAC Automobile
• Also, sensors from ADAS can be used in numerous ways:
  • front view cameras from ADAS can be used for tacking landscape pictures
  • cabin camera from ADAS can be used for video calls
  • surround view cameras from ADAS can be directly streamed into the Vehicle Environment applications and Vehicle HAL for Android Automotive
• various vehicle setting information can also be available in Android this way (tire pressure, mechanical monitoring, etc.)

Challenges

There are several major challenges in achieving this solution:

• Adopting SOME/IP and DDS communication mechanisms paradigms within “Binder-ized” communication from AIDL so the data coming from SOME/IP or DDS can be properly distributed to Android applications via AIDL.
• Enabling exposure of ADAS information in Android services deployed in both, service and vendor partitions, i.e., exposure to application layer and HAL modules simultaneously
• Implementation of meta-model for AIDL so it can be involved in model-to-model translations by the MDD principles
• Encountering incompatibilities between the four most common IDLs (ARXML, AIDL, FIDL, and OMG IDL) and bridging the gap within their translation
• Safety and security aspects (especially considering that SOME/IP standard does not include any of the security mechanisms)

Solution Architecture

Solution presented by the LAVA project is independent from hardware platform. For achieving the inter-domain communication, on ADAS side Classic or Adaptive AUTOSAR software platforms or even custom Middleware having the same purpose can be deployed as long as it supports SOME/IP or DDS protocols. Yet, keep in mind that current automation limitation from LAVA solution is covering only the usage of the Adaptive Platform because of the version of ARXML schemes. In other cases, the solution from LAVA must be applied manually.

Furthermore, on the Infotainment side Android OS shall be deployed. Besides the communication via SOME/IP and DDS, LAVA provides the DataChannelAPI for big data streams. This API can be used in any component or even environment and covers streaming via TCP, UDP, RTP, RTSP and AVB protocols.

LAVA solution workflow:

• LAVA generator and ADAS side
  • Firstly, existing ADAS software components shall have SOME/IP or DDS calls for delivering needed data (this must be implemented by OEMs or SWCs vendors because LAVA generator will not access the software components of other vendors from safety reasons)
  • Secondly, communication interfaces defined within ARXML shall be provided to LAVA generator and desired selection of using distributed or centralized approach shall be performed
  • If centralized approach is selected, ServiceProxy software component will be generated from given ARXML with the goal to collect data from existing components and forward them to the Infotainment system. If distributed approach is selected, SOME/IP and DDS calls from existing components would be used to directly communicate with the Infotainment system and no Proxy component shall be generated
  • With generating ServiceProxy, features for security enhancement can be deployed in order to ensure confidentiality, integrity and authenticity for inter-domain communication
• LAVA generator and model translation
  • Our generator will translate given ARXML and generate corresponding AIDL and FIDL or OMG IDL models
• LAVA generator and Infotainment side
  • Android services will be generated along with the SE policies and needed makefiles (supported selection of whether the Android service will be integrated in Android HAL or not and whether the Android service will be generated in Native, Java or Kotlin language)
  • Integrated SOME/IP or DDS clients will be generated via FIDL or OMG IDL files based on the chosen communication mechanism

LAVA IN MOTION: WORKFLOW SHOWCASE (INCLUDING DEMOS ON QUALCOMM AND TELECHIPS)

WE’VE HOSTED A LAVA WEBINAR. TO LEARN MORE, GET THE SLIDES & RECORDING: