Are PLM Systems Ready For The Software Defined Products?

Traditional product development was mainly about designing and manufacturing physical products where Engineers worked with mechanical parts, electrical components, drawings and Bills of Materials. PLM systems were introduced to manage all this information, maintain revisions, control engineering changes and ensure that everyone was working with the correct product definition. The emergence of the Software Defined Product is transforming this landscape.

Products have changed quite a lot in recent years. In a modern car, which is still a mechanical product with an engine, wheels, brakes and thousands of physical components. But increasingly, its behaviour is controlled by software. Features such as driver assistance, battery management, connectivity and even vehicle performance depend heavily on software. And the interesting part is, many of these features can now be updated without changing a single physical component.

The same transformation is happening in industrial equipment, agricultural machinery, medical devices and many other industries. Software is becoming an essential part of the product, and sometimes it is the software that creates most of the differentiation between competing products. This is especially true for the Software Defined Product, which emphasizes the software’s role in innovation.

A question arises here, Are the traditional PLM systems really prepared to manage products where software plays such a central role?

The traditional E-BOM, M-BOM is not enough anymore, Understanding the Sofware Defined Product

The BOM has always been central to PLM. It tells us what components are required to build a product, how they are structured and which revisions are used. When a mechanical component changes, there is usually a well-defined engineering change process for impact analysis, approve the modification and release a new revision.

However, Software works a little differently. A mechanical component might remain unchanged for several years, while the software running on it could be updated multiple times in a month. A software update might fix a defect, improve performance, introduce new functionality or address a cybersecurity vulnerability. And sometimes, an update can affect only a specific configuration or a particular group of products already delivered to customers.

Traditional EBOMs were not really designed to represent this kind of complexity. This is where the concept of the Software Bill of Materials (SBOM) becomes important. An SBOM provides information about the software components included in a product, including third-party libraries, open-source components and their dependencies. It helps manufacturers understand what software they are using and identify potential vulnerabilities or licensing concerns.

But managing an SBOM separately from the engineering BOM creates another problem. How can one know which software version is compatible with which hardware configuration? What happens when a hardware change requires a software update? And how do we trace these changes across different product variants?

The challenge here iss about connecting the different product structures so that we have a complete picture of the product.

Hardware and software follow different development cycles

Additional challenges also come from the way hardware and software teams work. Mechanical engineering team typically follows structured development stages. Designs are created, reviewed, validated and released. Changes after release often require formal approval because they can affect manufacturing, procurement, tooling and other downstream activities.

Software development teams, on the other hand, often use Agile methodologies, continuous integration and continuous deployment. They may work with short development cycles and release updates much more frequently than their mechanical engineering colleagues.

Both these approaches are not wrong. They simply serve different requirements. The actual problem starts when these two worlds need to work together.

When a manufacturer develops an industrial machine, the mechanical design is released and production has already started. Meanwhile, the software team continues developing new features and fixing issues. A new software release introduces functionality that requires a different sensor or controller. Suddenly, a software change has created a hardware dependency. Without a proper connection between software development and PLM, identifying and managing such dependencies can become difficult. Information is often exchanged through emails, spreadsheets or manual discussions between teams.

This is where PLM should help the companies. But it requires moving beyond the traditional way of managing product information.

What does this mean for engineering change management?

In traditional PLM, an Engineering Change Request (ECR) or Engineering Change Order (ECO) is normally associated with changes to parts, documents or product structures. There is a clear process for reviewing the impact and approving the change. Now when a software update is introduced, which modifies the behaviour of a product without changing any physical component, Should this update go through the same engineering change process? Does every software release require a new product revision? How should we manage an urgent cybersecurity patch that needs to be deployed quickly?

There is probably no single answer that works for every manufacturer. Some software changes may have very little impact on the physical product, while others could significantly affect safety, regulatory compliance or compatibility with hardware components. The important thing is to establish a change management approach that understands these differences. PLM systems need to support both the stability required by hardware engineering and the flexibility expected by software development.

The digital thread becomes even more important

When it comes to Digital Thread, where the idea is to connect product information across different stages of its lifecycle, from requirements and engineering to manufacturing, service and eventually retirement. For software-defined products, the digital thread becomes even more important. A manufacturer should be able to answer questions like, Which software version is installed on a particular product? Which hardware revisions are compatible with that version? What requirements and test results are associated with a software release? Which products in the field are affected by a newly discovered software vulnerability? Etc.

These questions cannot always be answered from traditional PLM data alone. Information may exist in different systems such as PLM, ALM, ERP, software repositories, testing platforms and service management solutions. Each system manages a different part of the product lifecycle. Trying to move all this information into one system may not be practical. Instead, the focus should be on connecting these systems and maintaining the relationships between the information they manage.This is where integration and traceability become critical. The goal should not be to replace every existing tool, but to ensure that the complete product definition can be understood across different engineering disciplines.

So, is traditional PLM ready?

The answer is probably both yes and no. PLM already provides many of the capabilities required to manage complex products. Configuration management, change control, traceability and lifecycle management are not new concepts. Manufacturers have been using them for decades. However, the traditional implementation of PLM has largely focused on mechanical and electrical engineering. Software development has often remained outside the PLM environment, managed through separate tools and processes.

As products become increasingly software-defined, this separation becomes more difficult to maintain. The future of PLM is not necessarily about turning it into a software development platform. Software teams already have mature tools for managing source code, builds, testing and deployment. Replacing these tools with PLM would probably create more problems than it solves.

Instead, PLM needs to evolve into a platform that can connect information from different engineering domains, manage cross-domain dependencies and provide a consistent understanding of the product throughout its lifecycle. The biggest change could be not in the technology itself, but in how we think about product lifecycle management. For a long time, PLM has been strongly associated with managing engineering data and controlling the release of physical products. That remains important, but it is no longer the complete picture.

This means product lifecycle management cannot stop at manufacturing release. It needs to support the continuously evolving relationship between hardware, software and the products operating in the field. The companies that recognise this shift early will be better positioned to manage the complexity of software-defined products.

Software is already an essential part of modern products, and PLM systems need to evolve to manage it alongside hardware throughout the product lifecycle.