Automotive Message Broker (AMB) is a framework for getting vehicle application from vehicle networks to applications.  It allows applications to be developed irregardless of the underlying differences in the vehicle network so that developers can focus on value-added differenciation instead of on the details of any given vehicle network.

AMB works by:

1. Providing a Normalized common dataset that application can use in their applications (ie, 'Vehicle Speed')
2. Providing a plugin-based architecture so that system providers can add support for various networks
3. Providing a DBus interface so applications can access data using numerous programming languages

Architecture

AMB consists of 3 main parts: sources, the routing engine, and sinks.  Sources are plugins that provide data to AMB.  In a vehicle, the source plugin would connect to the CAN Bus (or similar network), translate the messages and provide the data to AMB.  The routing engine then routes the data to interested sinks.  Sinks are consumers of the data.  They can do something useful with it, like log it to a database, or they can pass the data to applications using DBus (in the case of the DBus sink plugin) or a websocket (in the case of the websocket sink plugin).

Consider the following architecture image:

One unique aspect of AMB is that it can handle numerous sources and sinks simultaneously.  This allows multiple types of networks to be supported at the same time (ie Low Speed and High Speed CAN).  For developers, this also means that AMB can be used with a number of different simulation devices to make development easier.  For example, a developer could combine a racing wheel with the gps receiver sources to get speed and location data.