Overview

With the new ADTF Device Toolbox 3 it is possible to implement and deploy custom database parser services for reading communication specifications. The parser service can therefore be used to support special file formats or handle deviations from standard file formats. Such a special parser service consists of two classes. A bus specific database implementation and a database loader that is capable of accepting and loading one or multiple communication specifications. The process of implementing a custom database parser hence involves at least three interfaces:

adtf::devicetb::sdk::IBusDatabaseLoader is the database loader that keeps a list of parsers and instantiate them when loading a communication database file which was explicity accepted before. The loading mechanism of this interface will be triggered by the appropriate bus service during initialization.
adtf::devicetb::sdk::can::ICANDbcParser is the bus specific database interface that must be implemented by a parser service for DBC databases. For more information please find the bus specific SDK header files to more information about other database formats. The loading mechanism of this interface will be triggered by the appropriated bus service during initialization.
The bus specific database interface is the third part of the parser service which builds the parser part. An implementation of such an interface (e.g. adtf::devicetb::sdk::can::ICANDatabase) provides a set of functions and a description of how the specific bus communication is organized. This part also has to be implemented by the user.

Database Registry

The database registry is the maintainer of the database loader instances that are registered to a specific bus support service. Upon loading a set of communication database files, the registry iterates through its list of registered databases and asks whether a database is capable of loading those files or not until one loader is found which is responsible. A database loader of course first has to be registered to the registry. So it is necessary to load an appropriate bus service as well, which takes care to register a database loader on startup and unregister it on shutdown.

For every bus type there is a separate registry, holding a list of parsers for that bus type, which can be requested by the Class ID CID_DEVTB_BUS_DB_REGISTRY.

Bus Database Implementation

A database implementation has to realize the interfaces specific to the underlying bus type. Currently the ADTF Device Toolbox provides the interfaces adtf::devicetb::sdk::can::ICANDatabase in conjunction with adtf::devicetb::sdk::can::ICANDatabaseList for CAN based busses and --> adtf::devicetb::sdk::canfd::ICANFDDatabase in conjunction with adtf::devicetb::sdk::canfd::ICANFDDatabaseList for CAN FD based busses.

Database Loader Implementation

The interface to implement a database loader is named adtf::devicetb::sdk::IBusDatabaseLoader. The database loader decides whether it is responsible for supporting bus communiation files or not (see adtf::devicetb::sdk::IBusDatabaseLoader::Accept()). If it is, a new database instance is created and passed back to the caller of adtf::devicetb::sdk::IBusDatabaseLoader::Load(). The methods in adtf::devicetb::sdk::IBusDatabaseLoader are not specific to a certain bus type.

The pure virtual methods that need to be implemented in your parser classes are only these three functions:

adtf::devicetb::sdk::IBusDatabaseLoader::GetName()
This method only provides a name of the implementation which is used allow identification of this class in the console log output.
adtf::devicetb::sdk::IBusDatabaseLoader::Accept()
In this method the loader has to decide whether it is able to handle the set of files passed as parameter in conjunction to the specific bus parameter or not.
adtf::devicetb::sdk::IBusDatabaseLoader::Load()
If the file set is accepted by the implementation, adtf::devicetb::sdk::IBusDatabaseRegistry calls this method so the loader has to read the files and provide the information in an instance of the bus specific network database interface.

Attention: The database is passed to several stakeholders in the device toolbox which will gather information from the database. In order not to destroy a database before all stakeholders have finished their work with the database, reference counting with ucom::object_ptr is used. This implies that each time a database is created from the loader, this instance is automatically Ref()'ed for the calling service! For details on reference counting or ucom::object_ptr in ADTF have a look at ADTF's SDK documentation.

Special Considerations regarding CAN

There are two restrictions regarding signal access with those interfaces, that need to be taken into account in your implementation:

Attention: CAN signal IDs (adtf::devicetb::sdk::can::tSignalInfo.nSignalID) have to be in a contiguous range starting from zero up to the total number of signals. Signal IDs have to be unique within the database.

Attention

CAN signal names have to be prefixed by the message's name in which the signal is used, separated by a '.'. The interfaces in which this has to be considered are:

For example message Test_Signals_WrongUnits holds values for signal TestMultiplexor. This signal hence is expected to be accessible by the name Test_Signals_WrongUnits.TestMultiplexor.