Creating a BoM can help hardware and software teams work better

Managing design across hardware and software teams is challenging, particularly with all the interdependencies between each other’s work. If not communicated properly, changes in architecture on either the hardware or software side can have significant implications, such as finding out later that a product simply will not work, delayed time-to-market, or even a faulty product released onto the market. One way to overcome the problem is through a digital Bill of Materials, which can also integrate into DevOps processes, help deal with issues earlier, and accelerate deployment.

Gone are the days when it was acceptable for the hardware team to carry out their designs first and the software teams follow afterwards. Now, the two need to be working in parallel. In reality, however, they are often still separate siloes. That’s understandable: in a busy, large, distributed team, working out who to communicate a change to can be difficult.

Above: One way to help hardware and software teams collaborate better is by introducing a Bill of Materials (BoM)

However, in today’s increasingly fast-paced world, particularly with the growth of system-level design, allowing hardware and software to operate independently of one another is a risky strategy. Here is a real-world example, which affected a large organisation recently. Its hardware platform had slight differences between each item in the family, so while a single version of the software ran at the platform at first, patches to the software became incompatible across all devices in the hardware platform. Unfortunately, this error was found out after the release of the patch, causing numerous failures in the field.

Of course, most companies have some representation of the overall status of a project. Still, these are typically manually-driven documents that are hard to share and maintain, meaning that they can quickly become out-of-date or inaccurate. Organisations have also tried to overcome the challenge with the Agile methodology, which has many merits, but some aspects are difficult to apply to hardware-based environments. So, Agile can help, but it will not give an organisation complete unity across the whole environment.

The acquisition-led nature of the industry makes it even more complicated. In addition to hardware and software teams thinking of themselves as being separate, there is the added challenge of bringing in teams from outside, who often take time to integrate with a new organisation.

The role of BoMs

One way to help hardware and software teams collaborate better is by introducing a Bill of Materials (BoM). This long-established and familiar concept has been around for many decades, stemming from the manufacturing world. A BoM is essentially a list of materials needed to put something together. The use of BoMs in electronics, and in particular the semiconductor market, has been growing steadily, especially with the evolution of system-on-chip design, where there is increasingly a lot of IP reuse and the need to integrate those components.

Also referred to as a Bill of Information or a Bill of IP, today’s system-level BoMs are digitally-based, helping them to be integrated better into the overall project environment. Both software and hardware can be thought of as being made up of pieces of materials or components. Once that concept is understood, the benefit of having a single BoM covering them both becomes clear, creating a standard reference to help hardware and software teams work in harness together, linking both their worlds.

Above: Another important consideration is making sure that everything associated with a project is incorporated in the BoM

This means it becomes easier to pass information across the whole community without the two teams having to make an effort to communicate, as data is clearly recorded in the BoM of what version of the hardware the software team should be supporting or vice versa.

Without this universal layer of communication, if the hardware team made a change, it would have to work out how to communicate that change to the software team and to who. That might sound simple, but with a large, distributed team, especially one with external contributors, that can be hard to manage manually.

By taking away the need for manual intervention, the software engineers can see when a change is made, understand the dependency on the software they are creating, and make their own fundamental changes. Moreover, they are making those changes more rapidly, rather than at a later stage, helping to keep projects on track, avoiding software or hardware breaking, or creating considerable rework down the line.

Where BoMs fit

So, where does a BoM sit within an organisation? Typically, it will be connected to version control engines, which are already very widely used within all kinds of electronics industries to create what is often referred to as a ‘single source of truth.’ In essence, this is a centralised view of every action or change in a project from multiple different sources and contributors, regardless of what system or tools they are using.

A BoM also needs to be flexible enough to scale up as projects or organisations grow, and it also needs to be tied into requirements and testing processes. This becomes critically important in applications where functional safety is a requirement. By tying the system BoM to requirements and testing results, the process of showing an evidence trail from requirements, through design, to verification, can be simplified, or even automated.

Finally, it is also essential to bear in mind that a BoM needs to be a living document, reflecting the current state at any time. As modifications are made, the BoM will keep changing. Having a real-time view is vital for both hardware and software teams.

As such, the BoM also becomes another asset, or component of the entire system design. The BOM can also be revisioned and tracked during the entire lifecycle of the project. So, not only does it represent the current state of the design, previous versions of the BoM can be used to track changes over the course of the project lifecycle.

It is also a good idea to ensure that whatever underlying technology is driving the BoM, it supports real-time alerts. Therefore, in addition to the change being automatically registered in the BoM, whoever is responsible for that change gets a list of people who need to be notified of that change. Depending on the tool being used, it can also automatically notify those people without the change’s instigator being involved.

Metadata

Another important consideration is making sure that everything associated with a project is incorporated in the BoM. So, it is not just the design files but also the metadata because that is what captures the linkages between software and hardware components. Metadata can be captured manually (such as spreadsheets), but those will not automatically create the relationships between the metadata and the design files. This is where a digital BoM, being able to capture both design files and metadata, will be valuable.

Above: the potential rewards of bom implementation are considerable

Metadata can be called the six Ws: the Who, What, Where, When, Why and hoW. Metadata covers: who created the IP, who else is using the IP, what version of that IP is current, when was the IP introduced into the design (and what version of that IP), etcetera. This is an example of why that traceability of metadata matters: if a bug is found, as well as being fixed, it must be communicated to anyone else using that IP. Plus, everything - IP files, verification information, metadata - needs to be visible with other processes, such as bug tracking.

Additionally, having the metadata tied together with the IP of hardware or components of software can greatly simplify or automate other tasks necessary for the completion of a project. Datasheets, release notes, and errata can be compiled quickly from this information. Documentation can be generated from the metadata, and also versioned and kept within the system as part of the BoM.

Cultural considerations

Creating an environment where a way of working is forced on design teams is never a good idea. It can create resistance and resentment, or people looking for backdoors to bypass a process or system. Even within a team, individuals often have their own preferred tools. A BoM needs to be unobtrusive, lightweight, and with as few touchpoints as possible and minimal impact on designers.

Successful implementation of a BoM requires addressing all these considerations and so will take some time and effort. However, the potential rewards are considerable: mismatches between software and hardware are weeded out early in the design process, avoiding costly mistakes and helping to deliver fit-for-purpose products to customers quickly and efficiently.