Architecture


Introduction


The AGA SDK enables applications to receive and send vehicle signals. This page goes through the AGA architecture and it's specific components. There is also a consolidated Software components wiki page.

Components


Automotive Service


This is the main automotive software component in the Android integration. All android specific code is contained in this node. The automotive service is started on boot of the system and is responsible to launch all the vehicle interface layer singleton instances. The applications can then request a new interface tube through Context.getSystemService(Context.AUTOMOTIVE_SERVICE). This will return an automotive manager which is the application interface to the service and will connect this to the created tube.

Automotive service is run in the system JVM and the interfacing manager is run in application JVM. Communication between these will internally use Binder.

Tubes


Every application that fetches the automotive manager from the service will internally use a separate tube in the platform. Tubes are used to guarantee that the policy is enforced separately for different applications. Signals not following the policy is dropped in the tube.

Policy decision point


Policy settings is an area that is very different for different OEMs and is a component that is left up to the OEM to implement. The policy decision point module has an interface that the OEM should implement to set the policies for the tubes.

The OEM should implement these two interfaces:

public interface PolicyEnforcement {
  Authorizations getAuthorizations(AutomotiveCertificate certificate);
}

public interface Authorizations {
  boolean isReadAllowed(int signalId);
  boolean isWriteAllowed(int signalId);
}

​To help out there is a default implementation using access control lists to use.

Hardware button controller


Buttons in the vehicle can be integrated and mapped into standard Android key-presses. When the automotive service launches at boot the hardware button controller is launched. In the AGA code there are a default implementation of this module that uses the simulator to get button presses. This implementation is only a mock implementation that should be changed by the OEM to integrate i.e. steering wheel buttons.

Proxy


Tubes are handled individually but them all call functions in the proxy to communicate with the vehicle. The proxy aggregates signal registrations and provides towards the vehicle. To hook in signals into the proxy node there is a SDP node that one can connect to. AGA has a mock implementation using an Ethernet gateway node to receive signals from the simulator. This implementation should be changed by the OEM to integrate real signals.

Signal Configuration


Every signal in AGA has a 16 bit signal identification number. To configure available signals the configuration module is used. Many of the signals should not be changed but we reserve numbers for OEMs to be able to set their own signals. A signal is configured with two values:

  1. Payload type
  2. Unit

To add OEM specific signals one have to change the SignalConfigurationImpl file in the vehicle interface layer module.

Driver distraction


AGA uses the concept of levels of distraction to evaluate the state of the driver. This level is used to for instance stop applications that does not handle high driver distraction when the user is occupied with other things. The distraction level can also be listened to by applications through Android broadcasts. If an application reacts on these events and gracefully degrades the interface an OEM can allow it to run.

AGA specifies an interface for the OEM to implement. Calculation of the level is done by OEM and AGA will enforce the level towards applications. A mock implementation receiving values from simulator is provided in the code base.

Logical View


Legend

  • Gray boxes, represents the different actor domains (i.e. the 3PP and the OEM)
  • Blue boxes, are logical entities and almost mappable to a Java object instance
  • White boxes, represents Android services and also the VIL (Vehicle Interface Layer)
  • Dashed lines, symbolizes logical broadcast channels or calls
  • Solid lines, represents connectivity between entities using the SDPNode and SDPMessage mechanism
  • Document node, i.e. the Singal Configuration which is a configuration file for mapping standard and OEM signal IDs

Vehicle Interface Layer (VIL)


Throughout the documentation the vehicle interface layer is mentioned. This layer comprices of all the modules and interfaces gating the southbound interface towards the vehicle. It is typically in these modules that an OEM wants to do configurations and supply i/o to create a product.

Internal Communication


There are different types of internal communication within the AGA stack. The application uses binder inter process communication to send and receive signals from the automotive service. Within the system JVM communication is based on method calls and SDP. Follow the link to get more information about SDP. Externally the proxy exposes a SDP node for the OEM to connect to. Information from the driver distraction subsystem uses Android broadcast signaling to notify applications about state changes.