What is AMB?

AMB is a framework for accessing vehicle information from an application without the application having to know the specific details of the vehicle's network. AMB is maintained with scalability, stability, performance and security in mind. AMB's plugin architecture makes it very scalable (see plugin section in FAQ below). AMB is frequently performance tested using valgrind/callgrind and other profiling software. AMB security is an important goal. More information can be found on the AMB Security page

AMB in the IVI 3.0 release:

AMB received many improvements during this development cycle. Documentation has been greatly improved and bluemonkey now supports zones. Additionally, a new tool ambctl has been developed that makes testing AMB from the command-line a breeze. Finally, AMB now includes the crosswalk vehicle extension that implements the W3C automotive business groups vehicle and data specifications.

Binary images and source code for this release are available here for both 32 and 64-bit for X86 and ARM architectures.
AMB provides a open standard API for applications to target that is not vehicle specific or proprietary. This means applications written to use this API will "just work" on vehicles that support AMB. This creates value for vendors to use AMB and maximizes application deployment.

How do I get it on Tizen?

AMB is included by default on Tizen IVI images.

Configure AMB on Tizen

AMB installs a configuration file to /etc/ambd/config. By default, ambd, the daemon that comes with AMB, is configured to load the example and dbus plugins. You may also want to try one of the other plugins (zypper se | grep automotive-message-broker-plugins.

Configuring and using the OBD-II plugin

One particularly interesting plugin for developers is the OBD-II plugin. This plugin uses ELM-327 compatible scantools to communicate with any OBD-II compliant vehicle. In the US, most vehicles later than 1996 are OBD-II compatible. Vehicles later than 2008 sold in the US have OBD-CAN (ISO 15765-4) which many scantools also support. AMB is tested in Tizen using the OBDLink MX scantool and the ECUSim OBD-II simulator. A simulator is not required, but makes things a bit easier for testing at a desk instead of in a car.

To configure AMB to use the OBD-II plugin, use your favorite editor (vi comes installed by default so we will use that for now) and edit the config:

vi /etc/ambd/config

We want to change the example "Source" plugin to the obd2-plugin. Here is an example of a OBD-II enabled config from the AMB source tree: obdsourceconfig. Make changes to the "device" and "baud" as necessary. Most USB scantools show up as "/dev/ttyUSB*". If you are using the OBDLink MX or any other bluetooth scantool, use the bluetooth address as your device (ie "device" : "00:00:00:AA:BB:CC"). For many bluetooth scantools such as the OBDLink MX, baud rate doesn't matter.

Now let's stop the already running ambd and start a new instance:

systemctl stop ambd.service
ambd -d4

If everything is configured correctly, the ECUSim (or engine if testing in a vehicle) is started, you should see the example "Sink" plugin outputting data from the car.

FAQ

How do I write apps that use AMB?

I want to make an AMB plugin, where should I start?

There are two types of plugins, plugins that produce data called "sources" and plugins that consume data called "sinks". There are example plugins for both of these types and the plugin interfaces are documented in the AMB docs.