New PLM demands for the cars of tomorrow

An increasing number of vehicle functions are being defined by software. Daniel Baldus, Principal and PLM Consultant at UNITY AG, and Dr. Patrick Müller, Chief Customer Officer at CONTACT, explain what demands the Software-Defined Vehicle (SDV) places on development processes and tools. Both companies work hand in hand in process and methodology consulting.

Software in cars is nothing new. What makes a vehicle a Software-Defined Vehicle?

Baldus: For over 100 years, automotive engineering was driven by a mechanical mindset, with software development secondary. Today, the philosophy is fundamentally changing. Manufacturers now assume it is faster and more cost-effective to develop the entire vehicle in the same way as software.

Müller: Software is no longer just used at the component level, but as a holistic architecture. This includes a process that enables continuous deployment and the need to know or be able to recognize the vehicle’s condition, including the software, at all times.

What does this mean for the PLM system landscape? 

Müller: In addition to the traditional layered architecture with ERP, PDM/PLM, TDM, and authoring systems, there may be another explicit layer for configuration and change management. There will also be Application Lifecycle Management (ALM) and Source Code Management (SCM) for managing requirements and software code, which will also be anchored in the PLM to a certain extent. It is important to have a system that links the overarching maturity level process with the DevOps process for software development.

Baldus: PLM systems will have to evolve to link data from silos and evaluate it predictively. They will move much more towards end-to-end processes to monitor the product even in downstream processes. This product tracking provides information about which software to install and which services to offer.

How important is consistent data management for the SDV?

Baldus: In a greenfield scenario, data consistency would be a reasonably simple issue. The problem is the legacy data that has built up over 30 years in different silos with statuses inconsistent with one another.

Müller: To “clean this up”, we need PLM technology with flexible data models and automatisms that combine classic PLM automation and data integrity with new possibilities for AI support. Due to its advantages in data modeling, PLM technology can increasingly develop into the central tool for data orchestration in the context of the SDV.

How do the approaches of different PLM vendors differ regarding the SDV?

Baldus: Many PLM vendors are trying to expand their offerings in this direction by acquiring authoring systems – but then struggle to integrate them into a seamless toolchain. Furthermore, few PLM manufacturers have flexible architectures that allow software to be handled differently from hardware. This, however, is a crucial requirement for the SDV. 

Müller: Basically, many PDM systems are not ideally designed for managing software compatibilities. However, some systems are better suited than others. We aim to develop standard functions that allow mechatronic components to be integrated into model-series-like building blocks and linked to the corresponding software versions and compatibilities. CONTACT Elements enters as a PLM challenger in this arena. We are confident in our capabilities and differentiating features.

To what extent can the changes associated with the SDV be transferred to other industries?

Baldus: It’s not the industry that matters, but the product type. Products with a software component are now present in many sectors – solutions like those in the automotive industry make sense everywhere. Another promising opportunity for companies is that mechatronic products can be developed and manufactured in a much more standardized way than the purely mechanical products of the past.

Doesn’t that contradict CONTACT’s approach regarding industrial blueprints for various industries?

Müller: Actually, no. Industrial blueprints are more about industry-specific processes, for example, concerning special guidelines. However, similarities arise in the convergence of disciplines. I completely agree with Daniel: the Software-Defined Product mindset applies to the entire manufacturing industry, even if the manifestation is different for an automotive company than for a plant manufacturer.