Software BOM, Traceability and Digital Recipe Library

Modern products are super complex and include multiple ingredients. Every product today pretty much has some mechanical components to it, electronics / PCB, and also software. The last component is getting very painful to manage and track, which causes multiple headaches to OEMs. The software (especially embedded software) often comes from multiple suppliers and it is not an unusual thing that these software components are embedded OEM platforms with their own lifecycle and history of changes. 

Software BOM Traceability Problem

Let’s touch on the problem first. The POLITICO article can tell you how complex the issue could be if you miss tracking vulnerability and history of changes of the software. The title speaks for itself – BlackBerry resisted announcing major flaws in software powering cars, hospital equipment. The story in the nutshell is described in the following two passages: 

The back-and-forth between BlackBerry and the government highlights a major difficulty in fending off cyberattacks on increasingly internet-connected devices ranging from robotic vacuum cleaners to wastewater-plant management systems. When companies such as BlackBerry sell their software to equipment manufacturers, they rarely provide detailed records of the code that goes into the software — leaving hardware makers, their customers, and the government in the dark about where the biggest risks lie.

“BlackBerry cannot possibly fully understand the impact of a vulnerability in all cases,” said David Wheeler, a George Mason University computer science professor and director of open source supply chain security at the Linux Foundation, the group that supports the development of the Linux operating system. “We need to focus on helping people understand the software components within their systems, and help them update in a more timely way.” For years, the Commerce Department’s National Telecommunications and Information Administration has been convening industry representatives to develop the foundation for this kind of digital ingredient list, known as a “software bill of materials.” In July, NTIA published guidance on the minimum elements needed for an SBOM, following a directive from President Joe Biden’s cybersecurity executive order.

Managing data silos is a major problem that can jeopardize many product development and manufacturing organizations. Silo thinking instead of thinking about integrated information flow leads to inefficiency, problems with data traceability, compliance, and results in big claims and expenses. Which means – the loss of money and (sometimes) the CEO going to jail. You certainly want to avoid this scenario. How can OpenBOM help? 

From Silo Thinking to Data Thinking 

In my article earlier this week, I shared best practices and standard ways to escape the nightmare of managing data in Excel(or other spreadsheets). The way to do so is to become data-oriented and think about data in a granular form. Check this article out to learn more. Once you get rid of Excel, your life will be much better. 

MCAD / PCB / Software BOMs

This is a typical combination of data in every product. OpenBOM data model gives you an easy way to manage it. You start from catalogs to store items. You have a flexible way to create as many catalogs as you need – mechanical, standard items, electrics, software items, etc. You can go with any level of granularity and include different properties in each catalog. In such a way a mechanical item will include the type of screw and thread length, electrical item will get voltage and packaging and software catalog will include build numbers and binary codes. 

Once these catalogs are prepared, you can manage item revisions in all catalogs independently. Doing so will allow independent changes to each item. It is important because the model changes are different between MCAD, PCB, and software. 

The data is combined in BOMs together by organizing structures. Below is just one example of how to organize the data together by combining different types of data and assemblies. 
Software BOM and Digital Recipe Library Traceability 

Is software BOM special or different from other BOMs? From a data management perspective, software BOM is the same as mechanical or electronic assembly BOMs structure. It is important to remember about traceability, change management, and the lifecycle of software BOM. 

Product BOM is not completed until full information about software components, builds, and dependencies are included. From a configuration management standpoint, software BOM requires disclosing changes and dependencies of software across multiple companies and providers. OpenBOM gives you a way to share data between multiple companies, which is a foundation for building shared digital ingredients libraries. 

Special treatment must be done for maintenance BOM and updates of software in already released products. OpenBOM gives you multiple dimensions capabilities to manage software BOM and turn it into a mechanism to discover traceability between multiple software elements to prevent issues described in the POLITICO article. 

Conclusion

Products are getting more complex and managing software and other related components in a single organized data structure is not an option anymore. OpenBOM gives you a flexible way to organize the data, manage items, revisions and combine them into structured BOMs. The last can be managed as well with revision and changes. Altogether it will help the OEM to deal with the complexity of data, regulation, and quality requests. 

Software BOM is not an option anymore. OpenBOM gives you a way to organize software BOM, manage software BOM dependencies, and build traceability between software components usage from multiple vendors. 

Check out what OpenBOM can do – REGISTER FOR FREE and start your 14-day trial today. 

Best, Oleg