1 Automotive Message Broker testing
5 This document outlines steps that should be taken in order to test Automotive Message Broker (AMB) functionality.
11 III. Performance testing
16 AMB performs internal testing of core functionality via the "test" plugin[1]. This plugin tests
17 AbstractRoutingEngine methods. If a test failes, ambd will abort. This plugins also prints out the total
18 property capabilities of AMB. This is useful for verifying the addition of core properties to AMB's capabilities.
19 To run the test plugin, simply run ambd with the following example configuration[2]:
21 ambd -c testsourceconfig -d5
23 Debug level 5 is usually enough to get most debug or log information from ambd.
26 [1] - Test plugin: https://github.com/otcshare/automotive-message-broker/blob/master/plugins/testplugin/README
27 [2] - Test plugin config: https://github.com/otcshare/automotive-message-broker/blob/master/examples/testsourceconfig
31 AMB exposes a complex API over DBus[1]. This document will only lightly touch on the organization of the API for
32 testing purposes. For a information, please refer to the AMB DBus API documentation. The API has two general
33 interfaces: "Manager", and "DataType". DataType refers to a particular type of vehicle data such as "VehicleSpeed".
34 The easiest way to test the AMB DBus API is to run the example dbus config[3]:
36 ambd -c dbusconfig -d5
40 The Manager interfaces[2] is located in "/" with the interface "org.automotive.Manager". Manager is used to create
41 and find DataTypes. It has the following methods:
46 FindObjectForSourceZone
50 Please refer to the Manager documentation for specific explaination on what these methods do.
52 To test these methods, dbus-send, which comes with most linux distros can be used. The following is the general
55 dbus-send --system --print-reply --dest=org.automotive.message.broker / org.automotive.Manager.{METHOD_NAME} ...
57 To test the "List" method:
59 dbus-send --system --print-reply --dest=org.automotive.message.broker / org.automotive.Manager.List
61 This should return a list of supported DataTypes that can be used to create and find object paths representing that
64 To test the "FindObject" method:
66 dbus-send --system --print-reply --dest=org.automotive.message.broker / org.automotive.Manager.FindObject string:VehicleSpeed
68 This should return a list of objects that provide the data type "VehicleSpeed"
70 The other methods follow the same pattern. See the documentation for the arguments and return values.
72 Because of the dynamic nature of the API (objects may not exist until Manager creates them), simple tools like dbus-send, gdbus or qdbus will not suffice for most operations. To compensate for these lack of tools, AMB includes several helper scripts:
79 These scripts can be used to get values of objects, set properties on objects, get historic/logged data and listen
80 for changes to objects. For usage, please see [command] -h. For example: "amb-get -h".
83 [1] - DBus API documentation: https://github.com/otcshare/automotive-message-broker/blob/master/docs/README
84 [2] - Manager interface documentation: https://github.com/otcshare/automotive-message-broker/blob/master/docs/manager.txt
85 [3] - DBus config: https://github.com/otcshare/automotive-message-broker/blob/master/examples/dbusconfig
89 In addition to general profiling tools, AMB comes with a few ways you can measure performance. When running ambd
90 with the -d1 option, you can see how many property updates are being generated per second and how many are actually
91 being fired because a plugin is subscribed to that property. Coupling this with CPU usage measuring tools can help
92 with measuring performance.