Software and Hardware engineering has a long history of love and hate relationships in every possible way related to tools and methodology. Although both disciplines can produce “products”, the differences between hardware and software products are so big that tool markers clearly distinguish between them.
Hardware vs Software – The Big Change
Life was probably good for hardware and software engineers and each of them were looking into their own toolset and mindset. Until, the reality started to change and hardware and software products started to merge in different ways. Nowadays all modern products contain tons of software. Here are some examples that will explain the change:
- The control software to run a U.S. military drone uses 3.5 million lines of code.
- A Boeing 787 has 6.5 million lines behind its avionics and online support systems.
- A Chevy Volt uses 10 million lines.
According to the Wired magazine article, a typical new car has about 100 million lines of code- with the advent of sophisticated, cloud-connected infotainment systems. Software has become a competitive advantage as vital to General Motors or Toyota as it is to Apple or Google.
A typical product today contains mechanical, electronics, and software components. In addition to that, products are using software running in the cloud. All these elements must be connected and provide a way to coordinate changes. Now, think about all the engineers behind the development of these subsystems and you can realize the complexity of product lifecycle and change management.
The data is the foundation of every process. So, if you would like to get things right, you need to focus on data first. And when it comes to the data, product development tools for MCAD, PCB, and Software are very different and provide you with very different ways to manage Bill of Materials and changes.
Lifecycle Methodologies – Software, MCAD, PCB
This is a typical change methodology in software development (example is taken from Github). Software engineers are using branches, pull requests, and bring features back to master.
In hardware design, things are different. Very old PDM (eg. SOLIDWORKS PDM) systems are using revisions and check-in/check-out methods.
Modern MCAD tools (eg. Onshape and Autodesk Fusion 360) made a number of improvements to change the revision schema and allow branching, still, it is quite different from software methodologies. Here is the example from Autodesk Fusion 360 Manage.
Another example is from Onshape. While Onshape probably gives you one of the best environments to create branches, the release process is very much similar to a typical MCAD PDM environment.
PCB Lifecycle Management is slightly different from MCAD tool, but also not the same as Software lifecycle management. Here is the example from Alitum Designer 21 Lifecycle management.
Bringing It All Together – Multi-Disciplinary BOM
The biggest challenge in all these environments is that they are different and engineers that use them are also working in silos. While it is very natural, it also brings challenges and questions about how to manage an entire data set that ensures that the right piece of software will be combined with the right PCB board and both will fit the last revision of the mechanical enclosure.
A multi-disciplinary Bill of Materials is the way to solve this problem. It allows you to get information from all design systems and bring them together under a single roof and, most importantly, to establish a single revision management schema. To make it happen you need to have a flexible data model capable of including data from mechanical design, PCB design, and software design together and to control the revisions seamlessly.
Reference-Instance Model – Catalogs and BOMs
OpenBOM provides a completely flexible data model to manage product structures that can be used to create multi-disciplinary BOMs. Check OpenBOM training library for more information. The foundation of this model is a system of catalogs to manage item masters (different catalogs can manage different item types and as a result to assign different metadata elements to each item – mechanical, electronic, software). Bill of Materials can instantiate items from catalogs and add specific instance-level properties. These properties can be different in mechanical, PCB and software BOMs (eg. Quantity for mechanical, Reference Designators for electronics).
OpenBOM allows you to combine all information and manage an entire multi-disciplinary product structure for this structure (BOM). OpenBOM revision functionality is seamlessly applied to all disciplines BOMs and OpenBOM provides. It is an easy way to capture immutable revisions for specific combination hardware, electronic, and software.
Once it is done, you can always go back to BOM revisions in OpenBOM and check what mechanical parts, electronics, and software revisions were used for specific product revisions.
Check out more on how OpenBOM is managing revisions and changes in structure in our training library.
OpenBOM CAD add-ins and out-of-the-box spreadsheet import functions allow you to bring all BOMs from multiple environments (eg. Solidworks, Altium, Jira/Github) and to combine them in a single multi-disciplinary BOM. In the next articles, I will bring more specific examples of how you can do so.
Modern products are combined with hardware and software. To manage the information about an entire product, you need to have tools capable of managing a multi-disciplinary BOM – a data set combining all information and capable of managing revisions of the data in a seamless way.
OpenBOM gives you a flexible set of tools to manage a multi-disciplinary dataset (BOMs) combined from catalogs to manage different item types and BOMs to combine all of them in a single product structure.
Register for FREE to check out how OpenBOM can help you manage multi-disciplinary BOM and bring all your product data developed by multiple teams of engineers, contractors, and suppliers under one roof.