A couple of years ago, automotive analyst firm Roland Berger estimated the cost of the electronics content of new car designs could hit more than a third by value in the middle of this decade, up from 16 per cent for a vehicle launched in 2019. Much of that change would be driven by a shift to electric vehicles, with 12 per cent of the cost of the parts going into high-power semiconductors alone.
Despite mechanical components still representing the majority of the bill of materials, semiconductors inside the electronic control units (ECUs) dotted around the chassis have all but taken over when it comes to the design of these future vehicles.
Speaking at the Design Verification Conference (DVCon) Europe at the end of last year, Mercedes Benz chief software engineer Magnus Östberg pointed out, “There are pure EV companies that have been racing ahead. And the reason they have been able to trailblaze ahead is that they had an electric-only architecture. If you have an electric-only architecture the ECUs in the vehicle can be powered on all the time.” The energy in those batteries is not limitless but the carmakers feel far more comfortable about using it when the vehicle is not running compared to the battery in a petrol-driven system.
With fossil-fuel designs, Östberg says, “You can only do over the air updates with limited segments of the vehicle to limit the limited areas of the vehicle. This is what we now need to change”.
In a show of commitment to a software-oriented future, Mercedes has decided to call the infrastructure it's building for future cars MBOS, though it goes some way beyond just being an operating system. MBOS is meant to encompass the connections to the cloud that are used to manage access to services and to develop them, which means changes in how functions are not just delivered and tested.
“One of the problems our industry has always faced in the past is that there has been too much verification done at the complete vehicle level," Östberg notes. The plan at Mercedes is to introduce a staged process where components and subsystems are assembled and tested in a hardware-in-the-loop harness long before the final vehicle is ready.
Zonal architectures
A related shift is towards zonal architectures. In the past, vehicle designers have added new electronics-assisted features by giving them dedicated microcontrollers (MCUs). And the MCU count soared accordingly. Today, the focus is on consolidating software onto a relatively small number of high-powered processors and accelerators, with functions split across different cores or even modules. A braking controller might draw on data from sensors managed and manipulated by multicore MCUs in several different modules and delivered over ethernet. Those same sensors will feed into steering, navigation and other systems. This zonal architecture favours a more fluid software environment and one that carmakers see as providing a novel possibility: the idea of the software-defined vehicle.
Over time, the OEMs expect to be able to deliver, rent or sell new features to customers that take advantage of hardware already in the vehicle. They also see the possibility of using a common software base to support not just variants within a car family but one that works across the entire range. At the Arm DevSummit in October, Matt Spencer, technical director of the IP supplier's automotive business line, said the problem many OEMs have today is that “it’s easier to throw away code from previous projects and start again than to reuse it”.
The zonal architecture of uncommitted multicore processors and accelerators mirrors the evolution of cloud servers. “Cloud service providers have been able to deploy large, complex stacks efficiently and that is something we want to emulate in automotive. They did it via standardisation,” Spencer says.
One example of this standardisation is in containers: a way of parcelling Linux applications together with an operating system and firmware that have been tuned for that use. The containers are fired up as self-contained objects running under a host operating system whenever they are needed then cleared from memory once finished, a practice that lets the containers migrate easily around a network. Orchestration software works out where best to deploy the software based on what else is running in the data centre at that time. Because the I/O is virtualised, it becomes easier to test software functions in the cloud environment before they are transferred into the vehicles themselves though there is often a performance penalty to be paid for the extra level of indirection.
To assist the process, Arm teamed up a little over a year ago with a group of suppliers and a selection of car-software specialists such as Volkswagen’s Cariad and Toyota subsidiary Woven Planet to create the Scalable Open Architecture for Embedded Edge (SOAFEE). Though the current target is automotive development, the group has left the door open for other applications that need a combination of real-time control and cloud-style management.
Members of SOAFEE spent the first year collecting requirements and setting up an infrastructure that would make it easier to demonstrate how a cloud-oriented development process might fit into automotive systems. At November's SOAFEE Symposium, Robert Day, director for autonomous vehicles at Arm, said: “What are we going to do in year two is execution.”
Major issues
There are, however, several major issues with the cloud software that exists today. One weakness is a that orchestration software such as Kubernetes were designed to work with Linux targets that have no strict real-time response requirements. Konrad Hilarius, head of software-defined vehicle technologies at tier-one supplier Continental, says, "A big challenge is that there's currently no safety-certified implementation of a mixed-criticality orchestrator available. There are some solutions on the market but they are not designed for safety-certified use in automotive."
Another issue identified by SOAFEE's mixed-criticality orchestration tiger team, of which Hilarius is a member, lies in the overhead containers impose. "Key performance indicators such as the container start-up time, but also CPU and memory overhead, are often too big. We need to find out how to optimise this."
Benchmarking performed by the team found that Kubernetes on its own incurs a 20 per cent workload overhead, which Hilarius says is too high for practical automotive use.
Though containerisation will be a major part of the SOAFEE-recommended infrastructure, Day says another important aspect of the standard will lie in the ability to ensure components loaded into the same ECU do not interfere with each other by temporarily blocking or slowing access to memory or I/O. Part of this is managed by virtualisation but extends to cache and I/O management techniques that attempt to isolate real-time tasks from less-critical software modules.
"Another key part of SOAFEE is the ability to easily move across different hardware platforms, to make it easy to develop on one and deploy on another," Day says. Those development systems will include maker boards, such as the Raspberry Pi. “So that we can get developers working quickly and easily from day one,” Day adds.
"So, we have this vision that we've called Project Eagle," Day says, named after the first manned lunar lander in a nod to the original codename of Moonshot. Eagle's team aims to build deployable systems based on "blueprints" developed by the software teams so that they can be tested in the SOAFEE integration lab at Arm's HQ in Cambridge.
Members do not expect to rely on SOAFEE alone. The group expects to work alongside external efforts such as Eclipse SDV, Autosar and the Connected Vehicle Systems Alliance (Covesa), with a focus on Covesa's Vehicle Signal Specification (VSS), which aims to define a set of standard methods for conveying sensor and other information around the vehicle's network.
The broad scope of work like that undertaken by SOAFEE presents issues for even a large sector such as automotive. But if the R&D pays off with embedded-focused containers and orchestration tools, it may be an effort that delivers value well beyond the software-defined car.
