Software-defined cars present a host of technical, institutional and bureaucratic challenges, writes Megan Lampinen
Software-defined vehicles have become a buzzword in today’s industry and pose a major challenge to existing automakers. Vehicles’ features and functions are increasingly enabled through software, moving the average new car from a predominantly stationary, hardware-based machine to an evolving software-focused electronic device. SBD Automotive, a CASE (Connected, Autonomous, Shared and Electronic) technology and safety advisor for the automotive industry, traces it from Vehicle 1.0 to Vehicle 4.0.
Under this internal terminology, Vehicle 1.0 would be a basic functional vehicle without any kind of connectivity. Digitization enters with Vehicle 2.0, introducing the infotainment system and a highly capable digital cockpit, offering high-speed connectivity and the ability to connect individual devices for features such as music streaming and limited software updates.
Right now most of the activity is around Vehicle 3.0 location: Updatable vehicles. Alex Oyler, software domain at SBD Automotive, says, “These are the vehicles that have really gone through quite a significant change in the guts of the platform, especially when it comes to autonomous driving or Advanced Driver Assistance System (ADAS) capabilities, digital cockpits and connectivity. Is.” Principal with overall responsibility for end-to-end software and information technology projects. “The main result is that many of the in-vehicle experiences, features the customer uses, and the services available to them are highly updateable.” He expects automakers with the Vehicle 3.0-enabled platform to start deploying software updates to their vehicles regularly, anywhere from one to three months, depending on the brand.
“Most of today’s activity is toward treating the vehicle as a product that continues to improve over time, rather than as something once sold. That—plus parts and maintenance—is where profit is made. It is,” Oiler insists.
In addition, some automakers have begun targeting Vehicle 4.0, the SBD’s term for true software-defined vehicle. Its main feature is that this vehicle is almost an extension of the cloud. In particular, the software running on the car can be controlled mainly by the central runtime environment in the cloud. As Oyler says: “There are a lot of different use cases where you’re going to use high-performance computing in the car in conjunction with other vehicles that might be nearby or in the cloud itself to create more edge-of-the-range uses. such as local autonomous driving and infrastructure or smart city applications.”
This is clearly the direction in which the industry is headed, but reaching the end goal requires some very specific technology. SBD divides the component parts of a software-defined vehicle into six main layers, each with its own set of technical requirements, interfaces, patterns, and vendors. The lower layer consists of the hardware and electronic/electrical (E/E) architecture. “In this domain you have the real configuration of the E/E architecture: how the components are connected to each other, their responsibilities and the criticality they support,” he explains. “Is this a security critical environment, or could it be a less security critical workload, or both?”
Vehicles 3.0 and 4.0 fully compete for the new revenue growth. will be based on
The other part of this is ECU integration in high performance computers (HPCs). While the term HPC has traditionally referred to very powerful cloud computing infrastructure, the automotive industry has co-opted the term to refer to in-vehicle integrated computing platforms that are capable of significantly more than traditional ECUs. Instead of being two or three networks of many smaller microcontrollers, a main backbone of HPCs is increasingly responsible for the entire domain of computing. Other ECUs can be plugged in for specific functions but the bulk of the software that drives the most important elements of the user experience all resides on the HPC.
The next two layers in the breakdown of the SBD fall within the vehicle platform and are the platform and middleware, and the operating system and virtualization. Some automakers are branding their own versions of these two layers, as seen with Volkswagen’s vw.os and VolvoCars.OS. Essentially, this layer refers to the category of device operating systems as well as any virtualization. “These HPCs can have multiple device operating systems running, which are doing different things,” he noted. “You can have a real-time operating system right next to a virtualized Linux OS that is providing sensor and camera data processing through an adaptive autoserver.”
For the platform and middleware layer, the main function is to abstract the hardware from the software. Developers will want to ensure that all interfaces of a new feature are not directly tied to a specific hardware implementation or operating context. “The more mature it is, the more capable the vehicle will be to perform 4.0-type workloads because developers can write and test software completely independently of the vehicle,” Oyler says. “Middleware also solves the issue of legacy fragmentation for OEMs, by ensuring that any software written for the platform can be deployed on a fragmented hardware platform – a requirement for automakers managing multiple brands and segments.” A major cost driver for today.”
The next three layers all fall under the dynamic software stack, where most of the brand differentiation takes place. “This includes working with vehicle data to achieve specific business use cases, including infotainment and digital cockpit systems, or what’s happening in the background, or even ADAS systems,” they said. telling. “This software must be implemented on top of all vehicle platforms, and this makes it a more updateable runtime.”
Often these applications are combined with ancillary cloud services, the top layer in the SBD vision of a software-defined vehicle technology stack. This includes ADAS services and over-the-air (OTA) services. Just below the cloud services layer is a layer SBD calls shared services, referring to supporting infrastructure such as 5G, V2X and OTA infrastructure, both in the cloud and in the car.
Along with the technical requirements, companies face institutional and bureaucratic challenges in their pursuit of Vehicle 4.0. Most current automakers have been around for decades and have grown into large organizations, often spanning multiple brands. A large part of their workforce has been trained to work in specific ways with specific equipment. However, this shift to software-defined vehicles requires a new approach to the vehicle development lifecycle as well as new skills. “The first part of this is reorganizing itself and establishing new processes to support more iterative product development, as well as new business models that support new revenue streams throughout the vehicle’s full lifecycle,” Oiler said. give advice. “The other part is finding or training people with the skills to build that infrastructure you need to do this.”
For example, Volkswagen launched a recruitment spree for software developers for the Cariad division, and Toyota recently announced that it aims to hire more than 18,000 people to work on software and connected initiatives. “It’s not an easy task,” insists Oiler. “What they’re working on has traditionally been done by Tier 1 suppliers or done in-house with a completely different toolset.”
Notably, this is an inherent advantage of the few electric mobility-focused start-ups to appear on the scene. Oiler specifically marks Tesla and Rivian as companies that “have been able to start with Tabula Rasa.”
There is a change for suppliers as well, and some of the bigger Tier 1s are reinventing themselves. “It used to be that an OEM would come to them with a need for something like an infotainment system or an ADAS controller. The supplier will then handle the software development and testing and distribute it to the OEMs,” says Oyler. Now automakers are developing most of the software required and only the supplier needs to manufacture the parts. “You have automakers saying, ‘We’re all going to do software development. We have our own platform. We have a specific set of software partners. They just want Tier 1 to take this package, put it on the components. Flash it and then deliver the component to our factory.
In response, SBD has seen a change now called Tier 0.5. Here, Tier 1s are hiring experts to work as part of the automaker’s development team, co-developing the software and helping it keep up with the times. “In a way, the supplier becomes almost part of the OEM, realizing the revenue for the systems integration, but with it the manufacturing business as well.”
Bosch’s Cross-Domain Computing Solutions Group is an example of this development, which can also be seen in some of the major Tier 1s in other forms. Going forward, such changes in both technology and strategy will inevitably be required from all players wishing to realize Vehicle 4.0.
While the long-term future of mobility requires a foundation of Vehicle 4.0, short-term growth will require a mix of evolutionary platforms to properly balance investment, risk and growth opportunities. Over the next decade, revenue growth for automakers will be driven by adding value-added services, features and experiences over the lifetime of the vehicle, further strengthening consumer loyalty to the OEM brand. While automakers must continue to manufacture and distribute legacy vehicle types to sustain their business in various markets and segments, competition for new revenue growth will be based entirely on Vehicles 3.0 and 4.0. Automakers who can invest effectively in new platforms while continually optimizing and consolidating their existing portfolios will be the biggest winners in the world of Vehicle 4.0.