Why having two different kinds of ids?

The complexity of up-to-date IVI-systems demand to support sources and sinks dynamically added and removed in order to support the variety of CE products, but parts of the system are never going to change - to start a dynamic registration here is a waste of system capacity.

The setup

The AudioManagement is capable of handling static, dynamic or mixed setups. In case of a dynamic setup, all elements of the system like domains, sinks, sources, gateways etc are registered at system start-up. In a static setup, the IDs of the elements are known and fixed - no further registration is needed. The start-up for static elements works as follows:
when a domain known as static (this is knowledge of the AudioManagerController, recognized by the unique name of the domain) registers, the AudioManagerController enters all elements of this domain in the database. Still, this domain can register additional elements during runtime. In case of static setups, the RoutingAdapter needs to ensure that all static elements are ready to be used when the domain registers.
In order to ensure the uniqueness of IDs, there exist two separate ID areas (for each of sources, sinks, gateways and crossfaders):

In case of dynamic added elements, the audiomanagerdaemon ensures the uniqueness of the ID's, in case of the static setup, the project has to ensure the uniqueness by assigning the IDs wisely. The knowledge of the static IDs need to be in the AudioManagerController, the RoutingAdapters and in the HMI (optional because IDs will be reported anyway).
Domains cannot be static because registering them is the trigger for the AudioManagerController to enter the static values into the database.