Feature Request for Config Management

[michaelsaborov]

Embedded software usually needs specific adaptations to a particular vehicle in terms of configuration properties. Such configuration properties are called parameters in the following abstract. Examples of parameters are vehicle geometry or geographical region of use. Parameters are used in manifold computations and are expected to be constant during a driving cycle in customers hand.
Currently we differntiate between two types of parameters depending on type of configuration and related development process: coding parameters and calibration parameters.

ConfigDaemon application implements an on-target data base for all parameters used in a particular ECU and a generic interface for parameter accesses by user applications.

The basic idea of ConfigDaemon is justified by the use case of having only flexible runtime dependencies on parameters from the view point of a user application. Generic interface to access a parameter is defined by key-value principle, where key is a unique name for a required parameter and value is any data related to this name. Runtime dependencies have an additional value in comparison to statically defined interfaces for every specific parameter, which have to be resolved at build time. This approach allows to shorten build times and avoids the necessity of system model changes and following re-builds if a parameter changes.

ConfigDaemon is internally structured as

• an application, which implements a parameter data base and interface for parameter access and
• additional plugins, which handle specific kinds of parameters according to OEM functional requirements, like
• coding plugin or
• calibration plugin

Flexibility of the generic interface is achieved by representation of any parameter value as a string. To convert the string representation to the original data type of a parameter an addition library ConfigProvider is offered. ConfigProvider is supposed to be integrated in a user application. ConfigProvider, thus, is responsible for

• establishing of communication to ConfigDaemon,
• receiving eventual parameter updates,
• providing of typed access methods to parameters towards a user application.

[HartmannNico]

Do you envision the components to rather using an RPC scheme, e.g. App requesting a config when required and get the parameter set as response to that request
or
see parameters as something that is accessed by the applications as a value, so the messaging pattern is more a pub/sub one.

[michaelsaborov]

Hi, it´s the first approach: an app requests a predefined parameter set by it´s name and receives the set of parameters with their respective values.

[qor-lb]

Please create a PR and add the feature request to the "features" section of our documentation using the feature request template. See the Change Request Guideline or the IPC feature request for reference.

[steenlarsen]

Architecture note: This is basically specifying a key-value database. Instead of re-inventing the wheel for automotive ;) you could have a look at etcd. See https://etcd.io/ - This the configuration DB used by kubernetes. Since this DB can be distributed on multiple ECUs/hosts it could enable redundancy for all configuration data in a car if one of the big ECUs is out of action for some reason.

[michaelsaborov]

Hi @steenlarsen, thank you so much for the hint provided. You are right, there are numerous key-value databases available as open source. Besides of etcd, there are e.g. Berkeley DB, Redis, ... However, none of them is certified for automotive according to ISO26262. As our application is required with an ASIL B, we must certify not just the application as such, but also all the libraries it depends on or at least prove their freedom from interference (basically the same effort). In case of etcd we find an impressive list under Libraries and tools. It would look similar for other DBs. Theoretically it might work out, practically from our experience - not feasible. Summary: automotive needs a wheel which fits to its requirements ;-).