A couple of weeks ago Oleg Shilovitsky posted an article on LinkedIn about the Software Bill of Material (BoM) and in the comments Jos Voskuil asked for my opinion. So for my last article of 2024 I will give my perspective on the Software BoM or more accurately how to deal with Software in the Configuration Management Baselines of products that consist out of Hardware and Software.
When it comes to Software I distinguish between: third party software and inhouse developed software. These require different solutions when it comes to integrating them in the configuration management baselines of the product.
Third Party Software
Third party software can be an entire executable that is embedded in the product or software components like a library that is used to for instance develop inhouse software for the product. The important aspect here is the license model that is used for the third party software. Some software comes with an open source license and while you do not have to pay license fees you have to ensure you conform to the license of the third party software, otherwise you expose yourself to legal risk.
Next to open source you might have closed source software for which different license models exist. You might be required to purchase a license per CPU core or per data usage. Or per occurrence in the product or just one license per product sold.
To support this properly you need to be able to link the software in the bill of material with the required license model. However the location of the software can be different for deploying the software than it is for the ‘physical’ location of the software in the product. In case you need to calculate the occurrences you need to have a bill of material where the software is located in where it is actually located in the product. Not the BoM used for the deployment because that could be done when the product is completely assembled and you just insert a flash drive to load the software.
In the below picture you see different 3rd Party Software Parts used across different assemblies with different license types. Managing the accurate accounting of the required software licenses, requires you to either have these parts in the Bill of Material or part of the configuration as built and as maintained baselines (also known as the instance or equipment hierarchy). In any case you need to link the license and license type information to the 3rd party software parts.
Inhouse Developed Software
Commercial Options in Software
When software comes with commercial options, these options are often captured in software parameters. Depending on the value of the parameter a certain function is enabled or disabled for instance. Or you achieve a certain performance level e.g. default is an speed of 100 km/h and you can increase it to 150 km/h or 200 km/h by buying that option as shown below.
Some of these options are independent of the hardware, but some might require very specific hardware. Especially if you have product with a long life, at some point you develop options that also require new hardware. To ensure that the right software and software settings are used with the correct hardware a lot of dependencies need to be managed. In the example above you can see that you have 3 choices when it comes to the option Autonomy: Level 2, Level 2+ or Level 3 Autonomy. Level 2 requires only Cameras, Level 2+ requires only Lidar, and Level 3 requires Cameras and Lidar.
The above examples are quite simple use cases however things can get complex very quickly, not only with the amount of options, but also when you have all kinds of dependencies between options. These dependencies need to be managed across your IT application landscape to ensure consistency and prevent problems.
These dependencies are not necessarily managed in the bill of material but do relate to the various parts and software parameters involved. Note typically these kind of functions or performance levels are already defined as part of system engineering. So in an ideal world where you would have a system bill of information which describes these functions, performances and options the link to the software starts here. This is also the place where the hardware is linked. This way you can manage the configuration items with the appropriate dependencies.
Deployment of Software
For deployment of the Software you need to define a process or routing with work instructions or automation if this can be automated. In any case you need to identify the hardware part that is required, which could be an assembly or the product itself. You need to ensure that the software and settings you deploy match with the hardware. With the wrong settings or wrong software you can brick a product. Or inadvertently with a software-over-the-air update give your Microwave Combi Oven an identity crisis as it now thinks it is a steam oven. Yes this really happened. And note the steam oven does not support over-the-air updates so now a technician had to visit to fix the problem.
Another example of problematic deployments is CrowdStrike as I wrote about in recently, causing a lot of flight cancellations and delayed medical treatments.
Conclusion
That software needs to be part of the Configuration Management Baselines is not in question. How this needs to be done is key and depends on the specific use case. Software in the Bill of Material is key when it comes to accounting for the required license fees that are owed to the various Third Party Software vendors. However managing dependencies and options between Hardware and Software are a completely different topic that requires to already identify these dependencies as part of your system bill of information. Ensuring consistency of these dependencies throughout the lifecycle of the product will also prevent deployment issues like the ones from CrowdStrike or the Microwave Combi Oven.
What do you think?
Don’t forget to subscribe to this newsletter and follow me!
Header Photo generated by Microsoft Bing on 26 November 2024