Why does automotive struggle, and what's the way forward? (Part 3)
5.1.2023
5.1.2023
5
min read
In Part 2 of the Why does automotive struggle series, we analysed the reasons for the current automotive industry struggle. In this chapter, I would like to dive deeper into the current hardware and software groups in vehicles and how they are connected and dependent on each other. This will create a basis for further analysis of possible ways of development for automotive sector.
While preparing for this article, I read a number of articles where the authors are mixing all aspects together without separating them into logical structures based on technical limitations and hardware elements of different solutions.
Let’s split the discussion into general main groups: in-car and around-car. Another thing I saw was that many articles tend to overcomplicate quite simple things. I do not know the reason, I will just try to simplify as much as I can, so we do not get lost in irrelevant technical details. Our purpose is to look further in time.
In-car topics:
Around-car services:
It’s not about ICE or EV or PHEV or whatever - it doesn't matter how the car moves, let the “green” and “brown” activists fight about that. Their opinions don't matter that much in the end, because they are not the ones who decide - it is the market that makes the ultimate decisions.
The same goes for autonomous driving. For the purpose of this analysis, the matter of who is turning the wheel and pushing the pedals is completely secondary. In addition, to reach advanced levels of autonomous vehicles, one must be connected via Car2X technology to the vehicle's surroundings. This is enabled by Connected car technology.
There are two main architectures - Central Gateway Architecture (further "old") and Consolidated Vehicle Server Architecture (further "new"). There are obviously other architectures carrying “smart” names, but they all are transitional (frankensteinish) from old to new architectures.
The old architecture is interconnects different CANs and is usually built on a very slow communication network. Every electronic control unit (further ECU) requires having its own operating system (further “OS”), running software on it. Those ECUs are usually developed by separate development and testing teams, most of the time even different companies. Cars having dozens or hundreds of those units require an enormous amount of coordination during the development of testing before the start of production. With the growing number of ECUs and the complexity of communication, the number of things that can go wrong grows exponentially.
The majority of current EVs from famous brands are still using a version of this old architecture.
The new architecture has a powerful computing central unit, ECUs with residual functionality or just sensors, and a variety of peripherals, all connected to the central unit. The new architecture is replicating the current software architecture trends on the market much better and deep IT knowledge is used.
In this case, the vehicle is becoming a computer (or smartphone :-) ) on wheels with a much clearer separation between how hardware and software engineering actually works. The keyword is separation, I will get back to it.
Obviously, one can argue that implementing the new architecture requires a very powerful central unit (computer) that is very costly. However, while calculating the total cost of ownership, it is necessary to include all R&D costs next to the actual hardware, and in this case, in the long term, the new architecture might be significantly more cost-efficient, scalable, and reliable. Reliability. Vehicle owners pay enormous amounts of money for their cars and expect that they will simply work. That doesn't happen very often.
There can be a number of reasons why automakers do not migrate quickly from the old to the new architecture:
This is a fairly boring topic. Car infotainment consists of two main parts - information and entertainment centers. Vehicle information centers have a very limited amount of information to provide - this has remained pretty much the same for decades - consumption, distance, and driver assistance systems. For entertainment, it's hard to compete with mobile phones, mainly because people carry phones all the time with them, and systems (HW and SW) are much more evolved and integrated with our lives, rather than with our vehicles. If there is a chance, users prefer to use Apple Carplay or Android Auto solutions, which simply mirror the smartphone UI on the vehicle's display.
To make cars connected, they must be equipped with a communication unit, connected to a backend. This unit or “gateway” has to be able to gather (read) all needed data and send them to the backend, but at the same time also give commands (write) to the vehicle.
"Connected Cars are the backbone of car sharing and mobility services. Without the ability to communicate and share information through clouds, you wouldn't be able to rent a car, scooter, or bike online through your phone."
Read the whole quoted article on Connected Cars from Jimmy: https://www.fromjimmy.com/blog/connected-cars
All above mentioned (and many other) services like various shared economy (carsharing, ridesharing, etc), and complementary services (trunk delivery, carwash, charging/fuelling, etc) are technically dependent only on the connected car interface. Such (third-party or OEM2) service should have the ability to trigger specific in-vehicle actions like opening/closing doors and/or trunks, enabling vehicle driving, sharing location, etc.
Let's simplify, compile and distill above mentioned:
In the last part, we'll look at a possible way-out and how can small & medium companies help large OEMs from troubles.
Gerasim, Co-Founder
---------
1 ICE - internal combustion engine, PHEV - plug-in hybrid vehicle, EV - electric vehicle
2 OEM - original equipment manufacturer
