Bureaucrats, dave_user, Administrators
8,154
edits
Changes
→A real case example of Config ID benefit
* there is a number of products deployed on the field
* the products deployed on the field needs a SW update
The ideal scenario is that all products are equal and there are no differences on the Bill Of Material(BOM):<gallery caption="all All products have the same BOM with a single Config ID">
File:Smartphone-icon.png|Config ID A
File:Smartphone-icon.png|Config ID A
File:Smartphone-icon.png|Config ID A
File:Smartphone-icon.png|Config ID A
</gallery>In this case there are no problems to deploy in anyway a new SW update on the field: all products have the <u>'''same'''</u> HW configuration, then the '''<u>same</u>''' SW configuration. Unfortunately, this is an ideal scenario. The reality is that:* component obsolescenzeobsolescence
* product shortage
* double second source strategiesforce to have an on -the -field different version of product (with same functionalitiesbut with different HW configuration) which soesndoesn't permit to realize what proposed in the ideal case. The usageof the ConfigID technique, allows the running SW to identify the underlying HW configuration and automatically adapt the BSP (i.e. the driver layer) to properly use the HW subsystems: this, maintaining the overall product geature identical from the final User point-of-view.<gallery caption="All products are similar BUT there are different Config ID between the 2 product versions">
File:Smartphone-icon.png|Config ID A
File:Smartphone-icon.png|Config ID A
File:Smartphone-icon.png|Config ID A
File:Smartphone-icon-2.png|Config ID B
</gallery>with With a scenario , like the one described above, if you would like to update the SW you need to implement a strategy for understanding what platform version is going to be updated. The Config ID is used exactly for this goal.
The Config ID provides to the software update routine the information on which product version is so the update can be adapted to the exact product version.
In this way, you can distribute one single version of the software update which will automatically adapt itself to the currently running platform in use.
== How to handle After Sales with Config ID ==
This product is returned from the field with a problem on the display:
[[File:Smartphone-icon.png|none|thumb|159x159px|Config ID A]]
After Sales Dept analizes the product and decide to substitute the display. The problem is that the existing display is not available (Because - because of is End Of Life(EOL) - and it is required to move to a different display (with : in the product a different Config ID will be written because of the 2 displays requires a dedicated SW version and cannot be distinguished automatically during the startup). The final result is to have the similar product:
[[File:Smartphone-icon-2.png|none|thumb|189x189px|Config ID B]]
As indicated, the new display requires a different Config ID (from A to B) so it can be updated with an easy software routine before start the SW update. This Config ID update routine can be implemented in manufacturing facility typically using a dedicated USB pen drive which modify the saved ConfigID to the new one depending on the storage memory in use<section end="Body" />
