Information technology and the car amalgamate
Electric vehicles (EVs) have come of age: Instead of being conventional cars with a squeezed-in electric drivetrain, oncoming generations of EVs are specifically designed to be electrified. This brings the chance for a clean sweep. OEMs are beginning to utilize this opportunity to leave behind the burden of the established electric and electronic architecture (E/E architecture). With 50 to 100 microcontrollers spread all over a conventional vehicle, you are looking at a complex network of heterogeneous embedded hardware, connected via several types of physical interfaces. This stands in the way of a fresh start. Designing a new type of EV offers endless design and architectural beginnings. In order to prevent these endless beginnings from turning into lost opportunities, there is one particular issue that is worth addressing:
It is time to say goodbye to the underlying “one box per function domain” E/E architecture philosophy for several reasons. This kind of network is a nightmare to update, it stubbornly refuses installing new functions after the end-of-the line, and the wire harness has grown into another bother weight-wise and complexity-wise. Plus, where do you host the enormous amounts of software, which will be shaping tomorrow’s cars? Due to the increasing amount of software that gives the vehicle its functionality, safety, efficiency and comfort, a conventional premium car is likely to reach an impressive 750 million lines of code per car by 2025. Mind you – that is just “programmed code”, i.e., without factoring in the algorithms to come with artificial intelligence (AI).
The timing is right for cleaning up the E/E architecture.
There is yet another rationale behind this: Car makers traditionally perceive the engine (and sometimes the transmission) as key unique selling propositions for their brand. In times of digitalization, however, the variety of functions is particularly exciting for electromobility and its users as it is precisely them who have a great affinity for technology. Accordingly, the cockpit and human-machine interface are becoming more and more important. Drivers and users expect a “digital vehicle”. This has a correspondingly high influence on their perception of the vehicle and thus on the purchase decision.
Having said that, “the cockpit” means more and bigger displays, natural language conversation, haptics (e.g. haptic feedback with 3D shaped displays), full connectivity, and lots of software to provide it all! The future cockpit is fully networked, and a Digital Assistant will be able to take on different roles and responsibilities such as a driver’s companion or coach. Now, this working relation is developing into a genuine relationship as the EV becomes fully connected and turns into a member of the global Internet of Everything. Can that be done with the existing E/E architecture? No. The answer lies in centralization, and higher integration. The answer is: in-vehicle servers.
There is a great opportunity in the EV as a clean slate. Freed from all the legacy traditions of conventional vehicles, an EV is the natural choice to make a step-change. Why should an EV offer anything less than a user experience (UX) that tops the expectations of an online generation? An EV offers more space and fewer design restraints. So why not seize this opportunity to introduce new technologies such as pillar-to-pillar displays? They offer maximum freedom to display whatever content, app, service, or entertainment to the driver and passengers. Connectivity, flexible allocation of contents, and context-oriented user interfaces will give any vehicle a new UX; which will strongly influence the driver’s appreciation of his/her car. 3D display technology and curved surfaces will help to guide the user’s attention, help her/him to control functions and to enjoy high-resolution viewing quality.
What we need to make all that possible is to alter the E/E architecture. In order to bring all the elements of human-machine interaction together and to offer a seamless combination of information, entertainment, apps and services, the many strings of entertainment and information need to come together in one hardware.
In the cockpit domain, this trend towards a new UX means changing over to a server-based architecture that supports a systematic separation of hardware and software, smooth (firmware) updates over the air (F)OTA), cyber security, the safe use of ASIL and non-ASIL functions (and various operating systems) on a single hardware, higher functional safety, fast interconnection to other on-board servers, memory and processing power for future flashing and hosting of updated features and new functions. All of which translates into a future-proof system.
Is this just an attempt to conjure up a future development? No, the change is already underway! Volkswagen uses a server concept for ID. vehicle models based on the modular electric drive matrix (MEB). The conceptual framework for one of these servers (the in-car application server ICAS1) is a high-performance computer platform developed by Continental in cooperation with Elektrobit. It is called HPC (High Performance Computer), and the ID. Vehicle models with the ICAS 1 HPC showcase the move forward to a new E/E architecture based on server technology.
As a Cockpit HPC, the server integrates functions previously split up between several electronic control units (ECUs), including the instrument cluster ECU and the ECU, controlling the center panel display and infotainment world. However, the cockpit HPC does a lot more. Based on its capabilities, the cockpit and multi-modal human-machine interface are turning from what we once knew as the “driver workplace” into a dialogue partner, which adapts to the needs of drivers or their instantaneous role. In an automated EV, the driver may well be a passenger for long phases of the journey. During these phases, he or she will want to make good use of the time in the car. Screens will therefore have to display different types of information, provide the environment for different apps and pursuits, both private and business – and maybe they have to offer more display surface to meet that requirement. Natural language exchange between human and machine will have to be supported, and new elements such as Augmented Reality head-up displays require sufficient computing power for models that are equipped with it.
Higher integration levels and standardized hardware along with scalability of computing power and memory provide the possibility to adapt an HPC to the differing requirements of various models and vehicle segments. It is true that rather a lot of the computing power of an HPC will not be utilized when the car begins its service life. Probably even the biggest amount of computing power and memory may be reserved for the installation of new functions and feature upgrades over the service life of the vehicle – and new business models that come with it. Of course, this will only work, if the HPC provides cyber security and (F)OTA updates. The two make an inseparable pair anyway: There is no cyber security without OTA updates, but there can also be no OTA update without cyber security.
Some may consider this new level of, e.g., above 10 kDMIPS computing power per server in the vehicle a luxury but think again: Today, each and every one of the 50…100 ECUs has its own embedded periphery. They all have a housing, they all have connectors, and they all require thermal management, and they are all cabled. However, quite a few of these ECUs will never be active at the same time because their activity is restricted to certain driving or operating conditions that may be mutually exclusive. So, who’s wasting now?
The features of the HPC create optimal conditions for the integration of software from many sources. As an example, Continental uses the HPC capabilities for a strategic partnership with Pioneer. During the development of a Cockpit HPC, a complete Pioneer infotainment solution can be integrated into the server, if an OEMs requests it.
Meanwhile, while the server-based approach offers the chance for vehicle manufacturers to reduce complexity with a leaner vehicle architecture, it increases the complexity for Tier 1 suppliers. Manual software development, for instance, is no longer an answer to worldwide development with ever more internal and external partners. To handle this complex process efficiently and to ensure the quality of the server and the software a new approach is required: It takes a highly automated software factory and a cooperation portal providing the security, tools, automated testing and validation, and managing documents for hundreds of software developers all over the world, who are working on functions and features. It is not only the E/E architecture that is changing dramatically – beginning with the EV – it is the complete automotive industry as information technology and the car amalgamate.
Stefan Wagener
Product Manager Infotainment at Continental
