Adapting to the Evolution of the Automotive Industry

Managing the complexity of the digital transformation in the automotive industry with ALM and PLM solutions

Much like other sectors, a digital transformation is sweeping through the automotive industry, but unlike other sectors, this one is driven by software. Most of you have heard about the five megatrends changing everything in the automotive industry - electrification, autonomous driving, shared vehicles, connected cars, and over-the-air updates; these changes are enormous, fundamental, and disruptive. In this PTC Talk, guest speaker, Andreas Pabinger, Global Head of Automotive - ALM at Codebeamer, explained how manufacturers must adapt to the evolution in the automotive industry.

Automotive OEMs and their supply chains are navigating significant change. According to McKinsey, vehicle software is growing nine percent annually and will continue until the decade's end. Christopher Grote, SVP of Electronics at BMW, recently said that "today 95 percent of innovation in automotive is software based". That is a view backed up by Olla Kallenius, board chairman at Daimler and Mercedes Benz, who said: "to stay relevant, we have to control the software in our vehicles."

It is a bold statement from BMW. But it must be remembered that software is not just a line of code, software stack, components, or architecture; it is very often linked to sophisticated processes and documentation, but it is still very much related to the people who write the software and understand the architecture and code. This underlines the importance of human capital in the process.

What will happen to traditional automotive architecture?

The traditional automotive architecture contains numerous electronic control units (ECU) across a distributed electric and electronic architecture (EEA). Several years ago, this moved on to a centralized cross-domain EEA with power, chassis, body, and infotainment but still heavily ECU inflated. The current architecture can be termed a centralized vehicle architecture incorporating vehicle cloud computing.

On the horizon, and we will see this in cars at the end of the decade, is a central computing platform with real-time ethernet and peripheral elements such as sensors, actuators, and power elements. But the architecture will be a multi-core, robust computing architecture with multiple applications with different levels of safety and security. This will be separated with a zip separation kernel to segment applications, but it will run powerful computing-intensive applications. This will have hardware architectures that are overpowered for the current software. That means there will be application upgradability with over-the-air updates. In this scenario, the software will enable the value chain and the vehicle's lifecycle capabilities, impacting the business models. Significant revenues and streams will come from software, either sold through subscription or pay by use.

What are the challenges of managing complex software?

There are seven significant challenges when managing software complexity; functional redundancy, version variety, interfering sub-systems, closed systems, point-to-point interfaces, multiple hardware platforms, and code and documentation quality. Two of these are particularly relevant in version variety and interference of sub-systems. Both will be very important for future architecture because when you have over-the-air updates, you are updating not only applications but the operating system.

Therefore, you need to know which version of the software the full stack is running. It also has implications regarding architecture because you need to ensure that the hardware and the software are not as tightly coupled as they are today. This can only be achieved with a clean architecture incorporating clear separation in modularity, explicit interfaces, and upgradeability. When undertaking requirements management for the architecture, you need to understand what you want to do with the software stack and assets.

This brings us to the challenges research and development teams face in a software-driven world. It requires different ways of thinking and working across five main processes. First, manufacturers must move from a component-based waterfall development process and develop agile systems engineering experience. Then they must move from a distributed embedded software mindset to a centralized EEA way of working. The next change is to shift from a start of production cost optimization model to consider lifecycle economics. Another mindset change will see OEMs move from a product and technology focus to a customer-centric approach. Finally, there will be a transition from engineering-driven processes to data-enabled and virtual engineering capabilities.

What is required to manage this process?

Software-driven product development requires a combination of ALM and PLM to manage the systems engineering, change management, and product configuration. Strong synergies exist with the Codebeamer ALM product and PTC's powerful PLM capabilities to enable this. The software will not run in isolation but always in a cyber-physical system environment, combined with a powerful multi-core ECU with sensors and mechanical elements. To achieve system traceability beyond the electronics, you must have this combination of ALM and PLM elements.

With systems engineering, there are standard elements that must be managed. These range from requirements engineering through variant management, software modeling, source code management, DevOps and complete agile innovation, and test management to system simulation and co-simulation. Simulation will be essential because it facilitates rapid innovation integration. When you simulate, you do not need the physical element, so that you can run cycles faster.

When you have a software-defined vehicle, where software is the central brain of the vehicle, and you allow your customers to upgrade software, eventually, you have components that are used to create features. These features are used to create architecture, which will be deployed in multiple models. When this goes over the lifecycle, you have numerous complex permutations, and you need to have a toolchain that allows you to manage that with all the corresponding traceability. With traceability, you know which line of source code is linked to a specific component, sub-component, or complete architecture.

In this environment, is a waterfall approach still applicable? The answer is no because if you work in that manner, you will probably miss key market windows. The waterfall approach is sequential; what is required is a parallel approach, and that comes with agile workflows. Meeting market, innovation, quality, and time-to-market requirements is only possible with a parallel process. But the crucial takeaway is that each agile team must focus on value.