Discussion on OTA Solution under Extreme SOA Architecture.

Translation

Author: Rona and Charlie from Extreme Kratos Software and Electronics Center

In today’s software-defined automotive industry, automotive software needs to be updated and iterated more quickly through over-the-air updates (OTA) – this is the core capability of intelligent cars. SOA will bring huge changes to the automotive software ecosystem.

Why SOA?

Automotive SOA organizes the underlying intelligence of the entire vehicle, making the hardware capabilities and various functional services on the vehicle terminal service-oriented. These services are decomposed into smaller granular interfaces according to the SOA standard, and communicated based on SOA standard protocols. In this way, the service components can access each other, thereby expanding the combination of services.

The characteristics of SOA software architecture are high cohesion, loose coupling, service platform independence, and dynamic deployment/discovery of services. Therefore, it lowers the difficulty of continuous software iteration for automotive production and expands more possibilities. With the technological innovation, the upgrading of the EE architecture (electronic and electrical architecture), and the application of the in-car Ethernet network, SOA has become a logical application for today’s intelligent cars.

EE architecture upgrade lays the hardware foundation

Traditional automobiles used a distributed EE architecture, which required hundreds of ECUs (Electronic Control Units). In the traditional architecture, each ECU not only directly drives the actuator and sensor, but also shoulders much of the control logic of the business function. Therefore, the implementation of a function often requires multiple ECUs to be coupled. The iteration and modification of a single ECU often requires multiple ECUs to cooperate in modification. As a result, each ECU is purchased from different suppliers, resulting in increased commercial complexity, increased technical complexity, higher modification costs, and longer software delivery cycles. With the development of the entire vehicle EE architecture towards a functional domain-centric approach, the previous EE architecture of Extreme Kratos Intelligent Technology has achieved functional domain-centric architecture. Four major functional domain controllers take on the role of the software deployment center of various domain functions at the whole vehicle level, separating the actuator and sensor from the functional logic. Ordinary ECUs become pure execution and sensing units, and the interface interaction within the domain can be completed within the domain controller. Cross-domain logic interface interaction is achieved through the FlexRay backbone network. The ECU decouples the functional business logic and actuator control logic and becomes modular and standardized. In this way, through four functional domain controllers, the control of the hardware of the execution and sensing layer can be realized, which provides a good foundation for SOA in the architecture design.The next-generation EE architecture of ZEEKR intelligent automobiles is based on one central computer and two area controllers. The central computer completes the abstraction of sensing and executing layer hardware capabilities and develops and deploys all functional logic based on this, constructing a vertical SOA framework system from hardware abstraction layer to functional logic layer to whole vehicle management layer to cloud. At the same time, it takes over high computing and complex task processing (e.g. audio/video processing, Lidar/radar environment perception processing, machine learning, etc.). The area controllers, as the physical center, undertake power distribution, gateway and I/O driver in the area as well as deploying some special time-sensitive functional logic. This new architecture embodies the design concept of biologic characteristics (central brain/area eyes, ears, hands, and feet). ZEEKR’s latest EE architecture is committed to breaking functional domain boundaries, using physical partitioning and logical layering methodology, and concentrating core capabilities such as whole vehicle platform services, functional logic calculation, big data processing, etc., into the central computer, with each area controller only serving as an execution unit.

See the following picture:

ZEEKR EE 3.0 Architecture

Ethernet Application Lays Communication Foundation

Traditional vehicle network architectures are mainly composed of CAN bus, which divides different functional domains according to functions such as powertrain and body control. Each ECU has its own independent communication channel, making the cost of the entire vehicle harness high and the assembly more complex. Moreover, all nodes on the same CAN bus share the bandwidth. The communication bandwidth of a common CAN bus is only 1 Mb/s. Currently, ZEEKR’s main vehicle backbone network chooses Ethernet to replace the traditional CAN bus as the new vehicle network architecture. Ethernet is a switched network communication method, and all terminal nodes are connected to each other through a switch, which forwards and transfers information, with higher bandwidth (greater than 100 Mb/s) and lower latency. With better hardware infrastructure and wider and lower-latency network bandwidth, a foundation for SOA application and implementation has been laid.

Build a Complete OTA Solution

The development of OTA has gone through the following stages:

See the following picture:

OTA development process# The OTA of JiKe car has entered the fourth stage, creating an industrial ecological OTA solution under the new generation of EE architecture. The new generation of EE architecture supports OTA schemes based on central computing platform + area controller, which can realize OTA upgrade of various systems in the car network to provide personalized services for car owners, meet the needs of different customers, enhance user satisfaction and vehicle stickiness, and provide fast OTA updates and iterations for the whole vehicle in the whole lifecycle.

1. Whole vehicle full-stack upgrade: Based on the limitations of traditional electronic and electrical architecture, most of the OTA upgrades mainly focus on the information and entertainment system. The advanced new generation of EE architecture of JiKe can achieve software-hardware decoupling, and upgrade and flash the entire vehicle software, including the central computing unit, left and right banks, and other control units.

2. Full-lifecycle coverage: The OTA solution under this mode supports the integration of whole vehicle R&D, production and manufacturing, and after-sales system. The R&D end releases the entire vehicle software baseline in real time to synchronize with the OTA system, the vehicles produced by the manufacturing end are synchronized with the OTA system in real time, and the after-sales information is coordinated with the OTA end, so that the vehicle can form a closed loop of R&D, manufacturing, and after-sales OTA through software upgrade and maintenance.

Among them, the whole vehicle functional baseline and service subscription unify the vertical software versions of all controllers, and the conversion of different communication protocols, control of whole vehicle system status, centralized upgrade service management and other technical means are the prerequisites for the implementation of OTA functions.

Overview of JiKe’s developed OTA solution

JiKe’s OTA solution consists of a cloud platform, a vehicle cloud pipeline, and vehicle-side components, supporting the adaptation and interoperability of third-party system data and realizing secure management and control upgrades through the PKI system.

The OTA cloud platform realizes the management of vehicles and parts within the OTA upgrade scope, manages software upgrades, service subscriptions, service orders, and software version iterative upgrade processes, supports integration with other management systems (such as TSP, MES, PKI/KMS, etc.), and realizes data synchronization and secure management Closed loop.

In order to achieve flexible adaptation of different bus architectures, the vehicle-side is designed based on functional decoupling, and the sub-functions are split, such as vehicle cloud communication management, download management, whole vehicle upgrade status management, specific ECU upgrade control management, differential upgrade management, HMI user interaction management and other functions. And supports the upgrade of intelligent ECU (Android/Linux/QNX operating system) and non-intelligent ECU.The pipeline in Cheyunjian adopts mature communication technologies such as 4G/5G, HTTPS, MQTT, and CDN to ensure communication compliance with information security standards. With the help of high-bandwidth and network distribution technology, it increases the probability of delivering software packages to each vehicle and ensures that every vehicle can receive OTA services. The entire OTA upgrade process can be mainly divided into three stages: generating upgrade packages, downloading and transmitting upgrade packages, and installing upgrade packages. The entire process is connected through network communication, ultimately realizing the update of terminal code and data of vehicles to enhance their functions and services.

OTA architecture diagram

Functions and Modules of JiKe’s Self-Developed OTA Software

JiKe’s self-developed OTA software is based on the SOA framework, which mainly includes the following services:

1. OTA Client: responsible for interacting with the OTA server, obtaining upgrade information and upgrade packages, and providing Cheyun cloud communication services to the OTA Master.

2. OTA Master: responsible for parsing the installation strategy and executing the installation process for vehicle-side upgrades.

3. APP Install: responsible for upgrading the application programs of the central computing platform CSC, left zone controller ZC-L, and right zone controller ZC-R.

4. Diagnostic Manager: provides diagnostic flashing services for the OTA Master, which is divided into DCM (Diagnostic Communication Management) and DEM (Diagnostic Event Management) modules. DCM mainly handles diagnostic communication management, such as UDS-related commands processing, while DEM mainly handles internal events of the software platform.

5. Update Agent: provides OTA Master with the service of “restoring differential files”.

OTA software architecture diagram

Information Security Protection on the OTA Cloud Management Side

To ensure the confidentiality, integrity, and authenticity of OTA upgrade packages, signature, data encryption, and verification technologies are adopted to achieve the legality of OTA upgrade packages. A comprehensive information security protection system has been implemented through the cloud management side, combining with independent secure chips that support national cryptographic algorithms, for various aspects such as communication links, upgrade data storage, and distribution.Cybersecurity Solution for Cars

Value brought by Zeekr

Data-driven, improve ecosystem operation ability

Based on the OTA solution under the SOA architecture, the scope of “service” and “operation” is broadened, and the additional value of vehicles is increased. With the increasing frequency of Zeekr’s intelligent car OTA, a vehicle update and iteration loop is formed by replacing manpower with data and driving algorithm’s high-speed evolution with data. With the Zeekr intelligent technology’s developer platform, application store, digital cabinet, and other multi-layer linkage, services based on software, applications, resources, contents can be built, and push, distribution, and other strategies are supported to support diversified operation scenarios.

Decoupling of software and hardware, creating a good ecosystem for automotive software

The implementation of the whole vehicle SOA architecture allows application development and the whole vehicle hardware platform to decouple. A single development can adapt to different vehicle model platforms while providing a standard basic platform for application development. From platformization to industrialization, assisting Zeekr’s automobile to transform into a digitalization of technological services, continually iterating XOTA (FOTA/SOTA/DOTA) linkage technical solutions, empowering software+service core competitive elements, continually evolving the whole vehicle’s capabilities, lengthening user life cycle, and constructing a complete ecological loop.

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.