Software Transforming Vehicle Development
Software-defined vehicles are driving major changes in hardware and control architectures.
Software, already a major factor in vehicle operation, is driving major changes in design processes as its role continues to expand. Electronic architectures and software development strategies are changing rapidly as software transforms into a dominant vehicle technology, growing from a few million lines of code to more than 100 million in many vehicles. Some projections predict typical vehicles will have 300 to 500 million lines of code within a few years. These changes, as well as the increase in the amount of data generated by vehicular systems, are occurring at breakneck speed.
“It’s predicted that within the next couple of years, vehicle functions controlled by software will have increased from 10 percent to 40 percent in a span of one decade,” said Tamara Snow, head of research and advanced engineering, Continental North America. “And it’s not only the software that’s increasing. The volumes of data generated require high-performance computing in order to process and interpret information coming from connected sensors, roadways and the cloud.”
Many factors support the creation of what many call the “software-defined car.” Software is a critical element in autonomous driving. Suppliers note that software makes it possible to alter vehicle features over the full lifetime of the vehicle, transforming the way features are created and marketed. “Software-defined cars bring an end to static life cycles,” said Dirk Walliser, executive VP corporate R&D, Innovation and Technology, at ZF. “Carmakers can add things that nobody thought about when the vehicle was designed.”
The electronic architectures that make it possible to create and manage hundreds of millions of lines of software are changing swiftly. Burgeoning engineering and programming operations are rapidly adding manpower as managers transform operations and strategies. Software teams are looking at new ways to write and deploy programs, with a focus on simplifying the adoption of third-party applications.
On the hardware side, engineers must devise plans that make it possible to process code that may be written and deployed years after the hardware designs are finalized. Flexibility, scalability and compatibility are critical factors as strategists find ways to get the most from hardware and software developments. “What’s required is to have a centralized computing element. Software can give the hardware the personality you want to give it,” said Nakul Duggal, head of automotive products at Qualcomm. “We designed our next generation hardware to be agnostic.”
Open to change
Creating the applications that give product lines and individual models their personality and functionality will require a lot of software creation and management. Automated code generation and software reuse have become commonplace, giving engineering staffs code that can be upgraded and altered easily compared to most legacy software.
Open-source software is among the technologies and tools that are seeing more use. Automotive quality and reliability levels are being achieved with Adaptive AUTOSAR and Linux, which enable the porting, integration and use of application software from third parties. Leveraging modules from automotive industry open-source libraries can dramatically reduce development time.
“We see a trend of OEMs and Tier 1s beginning to undertake software development on Linux and later merge to more embedded and traditional automotive operating systems,” said Daniel Weyl, VP automotive software at NXP. “This helps to save cost and have a better time to market. What we might also see is that even very automotive-centric software stacks will be published and maintained in open-source manner in the future.”
Apple and Google, along with their third-party software partners, are also touting their automotive capabilities. Regardless of what platforms programmers use to create apps, the software needs to be tied to each OEM’s proprietary operating layers. Typically, that’s handled by middleware, which provides common interfaces so programmers don’t have to write code variations for each OEM. ZF recently made middleware the core of its software platform [https://www.sae.org/news/2020/12/zf-middleware], serving as the mediator and interaction layer for applications that connect to middleware using standard interfaces.
Ecosystems are another avenue for software development. They provide ways for experts in many areas to work together to create holistic software for use in a range of vehicle models. When the many issues associated with software design are combined with the challenges of managing global design teams, software management becomes an important aspect of vehicle development.
“To manage such complexity, a high degree of collaboration between the customer, Continental and all third parties is needed,” Snow said. She noted that Continental created the Cooperation Portal to improve efficiency and effectiveness of software integration. Logged-in users access encrypted manuals and software libraries so they are constantly up to date on project activity. “Time is saved as software can be pre-validated and pre-integrated by vehicle manufacturers and third-party software suppliers,” Snow noted.
Staying up to date
When software is the basis of a vehicle’s features and functions, automakers can add new features and functions well after new vehicles leave dealerships. Artificial intelligence (AI) systems can alter operations over time, and conventional programs can be updated to add capabilities.
Over-the-air (OTA) updating is an important offering for both. AI algorithms are changing rapidly, and changes created by AI tools will need to be checked before they are widely deployed. Traditional software updating will mimic cell phones. Infotainment platforms, which need to keep pace with evolving consumer tastes, are likely to be the first domain to implement the technology. “Product life cycles in the cockpit are different than those in powertrains,” said Matt Cole, senior VP, product development, at Visteon. “In cockpits, there are more functions that need over-the-air updating. By 2025, 35% of our domain controllers will have OTA.”
OTA implementations are expanding rapidly. On the commercial-vehicle side, Volvo Trucks recently expanded its remote programming service to include what it calls “unlimited parameter updates.” Smaller vehicles are also moving updates into the mainstream. Ford’s electric Mustang Mach-E and its new F-150 pickup both offer OTA, with the company claiming it can extend vehicle lifetimes while improving features. GM plans to provide OTA updating on most vehicles by 2023. Market analyst Technavio predicts OTA-equipped vehicle shipments will exceed 90 million during the next three years.
AI will come into play from both sides of the OTA platform. When deep-learning tools learn while vehicles are being driven, systems will generally report back to OEMs. Programmers in labs will also use AI tools in the development of software that will be downloaded to vehicles over their lifetimes. That’s going to push computing requirements far higher. Many systems will address these requirements with a combination of CPUs, graphical processing units and neural network processors. “There absolutely has to be some ability to learn, there has to be some kind of AI,” Visteon’s Cole said. “CPUs will need at least 100 GFLOPs, neural processors will need five to 10, tops.”
Creating scalable designs for the hardware that runs these programs will be a big factor in the rollout of upgradable software. Processors and communication systems will need to be able to perform upgraded tasks without compromising existing functions. Initially, hardware engineers will meet the needs of expanded software services by designing in plenty of overhead. “Systems need margins of 30 percent, maybe even 50 percent,” said Stefan Buerkle, global customer lead at Bosch. “Expectations are that vehicles will have longer life cycles, maybe 10 to 15 years. Hardware needs to be equipped to support that. We need to think about upgrades in the field.”
But when upgrades become more common over long vehicle lifetimes, it may be more efficient to upgrade hardware in the field. Automotive engineers are looking for ways to make field upgrades part of the planning requirement for vehicle systems. Many military programs allow field upgrades, but military techniques are generally far too costly for civilian passenger vehicles.
“The industry needs to start planning for hardware upgradability,” said Stefan Butz, engineering information VP at BMW. “We need to account for not only the cost of hardware, but also consider how easily it can be exchanged. There’s a pretty high likelihood that the hardware in a car at the start of production will not be the same as in vehicles later in production.”
Upgrades could become easier as the industry shifts to more centralized architectures. Some OEMs are creating zones that combine related systems together. These zones share data with each other, but they also send data to a centralized module that will make decisions based on all available information.
Reducing the number of modules will make it simpler to upgrade hardware to meet changing demands. The ultimate goal of some strategies is to have a single control module linked to an array of sensors. Upgrading that module will be expensive, but it will be easier than attempting to upgrade today’s distributed systems. “Cars today have 80 to 90 CPUs; our ultimate vision is to have only one CPU,” Bosch’s Buerkle said. “OEMs are taking different paths and different approaches for this consolidation, so we need to stay flexible.”
Foundation for autonomy
When myriad sensors and powerful processors are sharing data that must be transmitted and analyzed in milliseconds, networks are a critical part of the architecture. Ethernet is now a critical vehicle networking technology, though legacy CAN and other architectures continue to play important roles.
Ethernet is fairly new in vehicle communications, but its high performance and low cost make it attractive for carmakers. Researchers at MarketsandMarkets expect Ethernet to grow at 20%, rising from $1.8 billion last year to $5.6 billion by 2026. Some vehicle electronic systems are increasingly resembling personal computer architectures. PCI Express (PCIe), a local serial communications standard common in PCs, augments Ethernet in some vehicle systems.
“When we then talk about the data in the central computer, we see the zones connected over Ethernet links to an aggregation switch,” NXP’s Weyl said. “As the aggregated bandwidth is easily exceeding the available Ethernet uplink speeds, more and more switches are offering a PCIe network interface card uplink.”
Many vehicles will employ zones, in which different subsystems share data with other zones and central computers. Zones and domains will typically communicate with everything in their segment using a range of legacy interfaces including CAN, LIN and FlexRay. Ethernet links will connect zones with powerful central controllers as well as with other zones. This data sharing, combined with the huge volumes of data needed to provide higher levels of autonomy, shifts the spotlight to wiring harnesses. Ethernet helps reduce the bulk of wiring harnesses.
“To achieve a reduction in the cabling complexity, we must consider the whole vehicle electronic/electrical architecture and the introduction of zone controllers for the connection of sensors and actuators,” said Tamara Snow, head of research and advanced engineering, Continental North America. “Software-defined functions require re-partitioning of functionalities and dynamic allocation of resources. This results in a significant reduction of wire harnesses.”
All the available communications options give automakers many paths to connect sensors, actuators and controllers. Getting data to the central controller so sensor inputs can be fused and analyzed requires significant changes in both hardware and software. OEMs have differing strategies.
“There are a lot of different approaches from the various OEMs on how to go to zonal architectures, but they all intend to use Ethernet as the main backbone technology to move the data from the zones to the center,” Weyl said. “Therefore, you need high-speed communication via PCIe or Ethernet. But from the software side, you also need to have middleware abstracting this interaction with ease of use.”