There are currently a lot of different classic motor fuels used in different car markets worldwide. This is either simply influenced by the driver’s impression of certain fuels quality or demanded by legislation for various reasons. For example, modern lightweight turbocharged diesel-engines in light passenger cars are still associated with rattling-smoky trucks in the US, not taking their superb fuel efficiency into account. Additionally, recent diesel emissions news stories have not improved public opinion in this regard. In Brazil, diesel engines in non-commercial cars are prohibited as a form of protection for the large scale domestic sugar cane farming which provides the source for industrial ethanol-alcohol (E85) production used as fuel mix.
On the contrary, Europe currently has a diesel-car population of about half of all light passenger cars. This is mainly driven by European efficiency requirements of 95 grams CO2 per kilometer for a manufacturer’s fleet portfolio in 2020 and the lack of sustainable engagement in hybrid electric vehicle technology (HEV) or electric vehicle technology (EV). China does not allow private diesel cars at all, whereas Japan and Norway are paradises for electric vehicles, driven by massive governmental support programs.
All in all, there are different requirements on classic powertrain engines. The automotive industry has seen these issues multiply in recent years, as their products are increasingly shipping to different countries from a handful of ECU volume production sources. Additionally, electrical motors in HEVs need to be controlled as well now, as this new breed of powertrain consists of a classic combustion engine as well as an electric motor. This results in a drastic increase of different algorithms and calibration data parameter-sets, many different applications and various software sources inside a car’s powertrain ECU to cover each geographic requirement. One result of these different requirements is that memory space has been increased by almost four to eight fold in the past decade.
Hybrid electrical vehicles and electric vehicles are projected to grow significantly in shipment in coming years, and this change in propulsion type adds further powertrain requirements for ECUs on top of this.
Total HEV/EV production is forecast to reach 11.6 million by 2020, a CAAGR of over 28% (Source: Strategy Analytics)
For an HEV, a powertrain source (also called “powertrain domain”) of two different physical engines has to be controlled at the same time, which leads to a combination of many ECUs or a highly integrated multicore-ECU processing unit of a superb performance level at higher ISO26262 ASIL levels combined with classical real time requirements in a car. To find out more about this subject, check out The Functional Safety Imperative in Automotive Design from ARM.
The main challenge is the integration of software coming from different sources or even from different vendors. As has happened in other industries, there will be a tendency toward specialization and each vendor will want to protect its intellectual property (IP) by just providing object modules to the final ECU software integrator. To add to this, the task of a powertrain domain has been increased to integrate a standardized software interface like classic AUTOSAR to other car domains (e.g. backbones to chassis domains) and to support new functionalities arising through the combination of a classic combustion-style engine with an electric motor to build an HEV drivetrain.
But deeper integration might not be a challenge at all for a drivetrain, it also generates new requirements and functionalities. In the past the engine’s only task has been to drive cars. Nowadays, HEVs demand the usage of the combustion engine to recharge the battery by using the electrified part of the powertrain as a charger, plus a related smart and sophisticated automatic gearbox management. This easily sums up to at least four main application areas:
Seen from a bill-of-materials (BOM) standpoint, the highly integrated ECU around a powerful MCU has clear benefits in terms of cost. Cost is of course a main influencing factor in the automotive industry, as it is mainly driven by volume production. Furthermore a realization scenario based on many classic ECU hardware/software environments often leads to an increase of software development overhead by maintaining unwanted dependencies, additional communication interfaces and a potential waste of CPU performance. Therefore the ECU requirements on application integration - as mentioned before - will change in the not-too-distant future. Each MCU will have to ensure that all applications to be integrated will not interfere with each other.
The requirement has not arisen from the implemented functionality, but from the application integration itself. However, this requirement has existed in the computing industry for quite a while, and a commonly used solution is virtualization. All functionalities are realized in a highly integrated ECU or a bunch of separate ECUs located under the hood.
Virtualization has been a well-known concept in the general-purpose computing industry for more than two decades. It mainly introduces a hypervisor layer, such that applications (and indeed operating systems) execute on virtual machines (VM) instead of direct execution on the underlying hardware. Vehicle-wide virtualization (VWV) is an emerging branch of the established technology. It is an attempt towards market proven general-purpose and automotive-specific technology coupling by introducing virtualization holistically to the automobile. VWV tries to simplify the integration of different innovations onto a single physical hardware platform while guaranteeing freedom of unintended interference with other system software modules (also known as “sandboxing”).
One major benefit of this is that it allows design teams to significantly cut reduce the turn-around time from invention to prototyping at engineering level and furthermore to volume production readiness. Finally it could even have backward influence in the overall engineering partitioning structure at car electronics R&D departments and car domain partitioning over time, an interesting side effect.
Many of today’s existing proprietary CPU architectures that target the classic powertrain area face an uncertain outlook into the next decade. This is due to a variety of factors; their more-or-less specific but limited use case as compared to global market penetration combined by a declining tools support and related eco-system seen from a vendor perspective. Missing links to market standard hardware security features, when considered in the context of cars becoming connected to the outside world, could limit their usage in near the future.
Secondly, code generation tools for algorithms will abstract the use of specifically trimmed hardware architectures to reduce systematic failures that are crucial for reliable operation of vehicles.
Additionally there is a missing link to globally used architectures, like the ARMv8 architecture, increasingly seen in almost all other car domains (e.g. Advance Driver Assistance Systems (ADAS) and Multimedia) as well as OTA-updates and Internet of Things in consumer spaces.
The ARM Cortex-R52 enables real-time virtualization for applications such as automotive, robotics and medical
In a bid to address the opportunity provided by a changing powertrain market, ARM recently announced the Cortex-R52 processor, its most advanced processor for functional safety. It is the first processor based on the ARM v8-R architecture that addresses the integration topics as mentioned above from a hardware perspective. Therefore highly integrated new Cortex-R52 based silicon MCU products and their interfaces will provide maximum support on hardware level to reduce the related driver, Hypervisor and board support package (BSP) software overheads.
Cortex-R52 is the first ARMv8-R-based processor, and importantly introduces a new privilege level and a two-stage MPU (Memory Protection Unit). Although MMU (memory management unit)-based approaches are typically seen as more sophisticated than MPU-based designs, for real-time deterministic systems such as powertrain control the MPU can be advantageous, as is the relative simplicity and lack of overhead of the MPU. This safety architecture allows for hardware support for hypervisors and the sandboxing of tasks. Safety-critical operations can thus be isolated from other activities, without the loss of determinism that could happen for MMU-based systems. Multiple real-time operating systems (RTOS) can be thus run, allowing the virtualization of OSes and tasks. Such capabilities are becoming increasingly important as automotive moves towards more centralized architectures and applications become consolidated on a smaller number of controllers. In January, Berlin-based software house OpenSynergy announced development of the industry's first hypervisor on Cortex-R52 for real-time applications.
The make up of an automotive powertrain is changing, as more manufacturers move to a hybrid approach of classic combustion and electric. Add to that the increase in functionality required of ECUs due to application integration and consolidation. It all signifies a shift in automotive design, which ARM and its ecosystem of partners are well placed to serve.
Dipl.-Ing. Juergen Jagst, Senior Segment Marketing Manager Automotive & Industrial at ARM, has been closely involved into Automotive system technology at Freescale/NXP before moving into ARM Segment Marketing in 2008. Juergen acted as ARM AUTOSAR representative in the MCAL team as well as System Architect at GENIVI cooperation for LINUX infotainment. He is responsible for ARM's segment marketing activities in Automotive and Industrial areas with a specific focus on Europe and South Korea.