- Author: KimChan
The concept of “SOA” is becoming increasingly popular in the automotive software industry. If you don’t mention the word “SOA” when communicating, you will appear unprofessional. Is this concept new? Not really. The internet industry has already played with this concept, and now micro-service even serverless concepts are the trend.
So, what exactly is SOA? Why has SOA only just become popular in the automotive software industry? How difficult is it to implement such an architecture?
Almost all cars you can see on the road now have such an architecture (domain architecture), divided according to different functions, with each ECU connected to its own function, and then connected through a gateway. If you need to connect to the Internet, the T-Box can also connect to mobile data (4G & 5G).
If you want to add more functions later, you can continue to add ECU as long as they can be connected via CAN/LIN/Ethernet.
At this point, you may have a question: If you do this, won’t there be more and more ECUs?
You’re right. Actually, there are already cars with dozens, even hundreds of ECUs. After all, each functional block has its own task requirements, and most of the performance of ECUs is not high. Considering cost and functional safety, the performance of ECUs is enough, so the number of ECUs can only increase.
Another side effect is that as the number of automotive ECUs increases, the harnesses they use to connect to each other become longer and longer, which means that the weight of the car increases and it consumes more fuel.
For manufacturers, various OEMs can hand over different ECUs to different Tier1s to complete, and then complete vehicle-level integration, testing, and acceptance on their own. This division of labor has also been running well to this day.
Future trends
People’s expectations of the functions that cars have are increasing. Even the experience of the cabin entertainment is becoming more and more important for many young people who buy cars. All these experiences require a large number of applications and constant updates to complete.Although the traditional cars have the ability to update with the internet, every update still requires a complete software refresh, making dynamic deployment impossible. Thus, some people are contemplating whether to introduce an operating system like Linux that can run on high-performance cores, such as A53 and A57, to replace the functionality of many past ECU and achieve dynamic updates and deployment of apps based on Linux.
With the introduction of high-performance computing chips, the number of available functions increases and traditional domain fusions can also be achieved, leading to a reduction in the number of ECUs.
Moving forward, the car could have only one central computing unit that connects to several area controllers, with each area controller then further connecting to execution units. This architecture would optimize the entire electrical and electronic structure compared to current models.
Additionally, the separation of soft and hard components is unnecessary when the OEM completes the car OS on a POSIX system. The car manufacturer (+Tier 1) focuses on operating systems, while app developers concentrate on application development.
Automotive SOA architecture and technical points
The core of SOA is services; everything is a service.
For example, developing the Zhihu platform includes a PC web version, as well as Android or IOS versions. To obtain a hot list, you wouldn’t write three different APIs for each of these platforms. The final solution is to provide the same content with a service interface for the three platforms. The display UI on each individual platform is a separate consideration.
-
S2S: SOA services are all based on Ethernet. However, to communicate with MCUs that use CAN or LIN buses, there is still a need to transmit many signal-based messages. The focus is on reducing the consumption of chip resources, instead of how to implement signal-to-service or service-to-signal communication, which should not be an issue in practice.
-
Core-to-core communication: Originally, the HPC architecture did not have a dedicated hardware channel or driver for core-to-core communication, and developers had to write virtual Ethernet drivers respectively on the MCU and MPU ends to achieve communication through shared memory. However, most new chips now have built-in solutions, which will be convenient.
-
Hypervisor: If domain fusion is required, deploying multiple VMs running each own operating system is likely. Issues such as hypervisor efficiency, resource consumption, and VM communication efficiency should also be considered.- OS: Is it easy? On the surface, it seems so simple. Just deploy Linux onto an MPU for use in automotive entertainment systems, right? However, now with Linux needed for vehicle control, autonomous driving, and more, stability and security must be considered. If one is not experienced in automotive software, this area may not be so easy to master. And to make matters more complicated, handling Misra C++ is enough to make anyone feel nauseous… (I have some complaints here, hahaha).
-
AP: Relatively speaking, the Autosar organization has also established standards for AP compared to CP, but there can be too many solutions on Linux, and many manufacturers still have a reserved attitude towards AP. For example, will it become too complex, or will it fall into playing along with Europe’s pace (after all that’s how CP developed)? Furthermore, the AP standard is not yet fully mature. In my personal opinion, I believe that AP standards are still developed after overcoming many obstacles. Even if one chooses not to follow AP standards, in reality, these functions need to be developed, or many third-party middleware suppliers use AP standards to develop middleware. Therefore, AP is still very significant.
-
SOA Layer: In fact, for OS or AP things that are more platform-oriented, the SOA layer is the most critical. In this layer, various system-level management functions need to be considered, such as power management, time management, state management, log management, etc. Additionally, it is necessary to consider how to encapsulate automotive functions and provide permission-based access restrictions, for use by the top-level App. Of course, how to update the App and firmware also needs to be considered. There are too many things to consider, and this is why SOA has been discussed for so many years. Actually, in practice, there is nobody who can say that their architecture is completely in line with their intended design (although some claim they have). However, in my conversations with customers, I think that domestic manufacturers have progressed very quickly and have many excellent ideas. I believe that each company’s SOA platform will be launched by the end of this year.
What challenges will automotive OS face?
What challenges will automotive OS face? How many obstacles are there? Excluding Tesla, Volkswagen’s ID.4 (ID.3 in Europe), which has just been launched, utilized this architecture. The entire project took three to four years, and issues with system upgrades were exposed before launch. This illustrates just how challenging a system like this can be for automotive manufacturers.
-
Complexity: Currently, most consider the use of S32G or TDA 4-type heterogeneous SoCs. How to deploy CP and Linux, ensure inter-core communication, signal-to-service conversion, multi-VM management, dynamic deployment and updates, and more difficult than simply deploying CP onto an MCU in the past- Temporality: With the increasing presence of automotive technology, failure to implement SOA on the new HPC architecture could potentially lead to market elimination. How to achieve faster implementation of SOA and deployment is crucial to maintaining market share.
-
Functional safety: Automotive safety is of utmost importance, unlike playing with SOA on servers. If functional safety cannot be ensured, it could cost lives. How to ensure functional safety with open source Linux? Even if one uses commercial Linux that meets functional safety requirements, how can one guarantee system-level functional safety?
-
Network security: Future automotive computing units will undoubtedly connect to the internet. How to proactively monitor or passively handle such connectivity? How to prevent even non-monetary, life-threatening outcomes, and potential data theft or unauthorized use of in-vehicle cameras by hackers?
-
Differentiation: With similar architectures, how can one ensure ecological differentiation in the resulting system to set it apart from competitors?
-
Long-term support: SOA requires continuous updates, while the life cycle of a car model may span over a dozen years. With too many components and suppliers involved, how can we assure the long-term support of such a system?
Domestic Status Quo (Software Platforms and Basic Software)
CP is no longer viable, with Vector and EB cornering the market share. ETAS also has a share, but some local solutions such as Neusoft and Huawei are in use in China.
On the AP front, the industry is still in its nascent stages. EB was the earliest mover and worked with Volkswagen to implement the SOA platform on the ID.3 (4), but Vector has performed well in the domestic market. Although there are many other commercial Linux suppliers and middleware providers, there is still intense competition in the Linux market.
Unlike foreign OEMs, domestic OEMs have yet to achieve full autonomy in defining their HPC platforms like Volkswagen or BMW, so they still need to cooperate with various providers.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.