Article count:1511 Read by:4580472

Account Entry

A brief discussion on OTA solutions under Jikrypton SOA architecture

Latest update time:2022-04-26
    Reads:


Author: JK Software and Electronics Center Rona, Charlie
Today, when software defines cars, car software needs to be iteratively updated (OTA) more quickly - this is the core capability of smart cars. SOA will bring huge changes to the automotive software ecosystem.

Why use SOA

Automotive SOA organizes the underlying capabilities of the entire vehicle's intelligence and turns the vehicle's hardware capabilities and various functions into services. These services are designed based on service-oriented interfaces according to SOA standards and split into smaller-granularity interfaces, and communicate based on SOA standard protocols. In this way, each service component can access each other, thereby expanding the service combination form.

The characteristics of SOA software architecture are high cohesion, loose coupling, service platform independence, and dynamic deployment/dynamic discovery of services. This reduces the difficulty and expands more possibilities for continuous software iteration after the car leaves the factory. In today's smart cars, due to technological innovation, EE architecture (electronic and electrical architecture) upgrades and in-vehicle Ethernet applications, the application of SOA has become logical.

The upgrade of EE architecture lays the hardware foundation

In the past, traditional cars used a distributed EE architecture, requiring hundreds of ECUs (electronic control units). Under the traditional architecture, each ECU not only directly drives actuators and sensors, but also assumes a lot of control logic for business functions. Therefore, the implementation of a function often requires coupling of multiple ECUs, and iteration of functions and upgrades and changes of a single ECU often require the joint modification of multiple ECUs. Each ECU is purchased from different suppliers, which ultimately leads to increased business complexity, increased technical complexity, higher change costs, and longer software delivery cycles. As the entire vehicle EE architecture develops towards functional domain centralized architecture, the previous generation EE architecture of JiKrypton Intelligent Technology has implemented a functional domain centralized architecture. The four major functional domain masters are responsible for the functional logic software deployment center of each domain at the vehicle level. Role, the actuators and sensors are separated from the functional logic, and the ordinary ECU becomes a pure execution and sensing unit. The logical interface interaction within the domain can be completed within the domain controller, and the cross-domain logical interface interaction is realized through the FlexRay backbone network. ECU realizes the decoupling of functional business logic and actuator control logic, and modularizes and standardizes functional interfaces. In this way, through the four functional domain masters, the control of the execution sensing layer hardware can be realized, which provides a good foundation for SOA in terms of architectural design.

The new generation EE architecture of JiKrypton smart car is based on a central computer with two zone controllers as the core. The central computer completes the capability abstraction of the sensing and execution layer hardware and based on this, develops and deploys all functional logic and builds the hardware. A vertical SOA framework system from the abstract layer to the functional logic layer to the vehicle management layer to the cloud. At the same time, it takes over the processing of large computing loads and complex tasks (eg Audio/Video processing, Lidar/Radar environment awareness processing, Machine learning, etc.). As a physical center, the zone controller is responsible for the power distribution, gateway and I/O drivers in the zone, as well as deploying some special time-sensitive functional logic. This new architectural form embodies the pattern of bio-like design concepts (central brain/regional eyes, ears, hands and feet). The latest EE architecture of Jikrypton Smart Car is committed to breaking the boundaries of functional domains, using the methodology of physical partitioning and logical layering to centralize core capabilities such as vehicle platform services, functional logic operations, and big data processing into the central computer. The controllers in each area only Controlled as an execution unit.

As shown below:

ZEEKR EE 3.0 architecture

The application of Ethernet lays the foundation for communication

The traditional vehicle network architecture mainly consists of CAN bus, which is divided into different functional domains according to functions, such as powertrain, body control and other bus domains. Each ECU has its own independent communication channel, making the vehicle wiring harness costly and the final assembly complex. Moreover, all nodes on the same CAN bus share bandwidth, and the communication bandwidth of ordinary CAN bus is only 1Mb/s. At present, JiKrypton’s vehicle backbone network has chosen to replace the traditional CAN bus with Ethernet as the new vehicle network architecture. Ethernet is a switched network communication method. All terminal nodes are connected together through switches, and information is forwarded and transmitted through switches. It has higher bandwidth (greater than 100 Mb/s) and lower latency. With better hardware infrastructure and a network with wider bandwidth and lower latency, the foundation has been laid for the application and implementation of SOA.

Create a full ecological OTA solution

The development of OTA has gone through the following stages:

OTA development history

JK Auto's OTA has entered the fourth stage, creating an industrial chain ecological OTA solution under the new generation EE architecture. The new generation EE architecture supports OTA solutions based on central computing platform + zone controller, which can realize OTA upgrades of various systems in the vehicle network, provide car owners with personalized services, meet the needs of different customers, and enhance users' understanding of the vehicle. Satisfaction and vehicle stickiness are achieved, providing full-stack and full-lifecycle rapid OTA update iterations for the entire vehicle.

1. Full-stack vehicle upgrade : Based on the limitations of traditional electronic and electrical architecture, most OTA upgrades are mainly targeted at infotainment systems. The extremely advanced new generation EE architecture realizes software and hardware decoupling, and can achieve complete vehicle software The upgrade includes the upgrade and flashing of the central computing unit, left and right banks, and other control units.

2. Full life cycle coverage : The OTA solution under this model supports the integration of vehicle R&D, manufacturing, and after-sales systems. The R&D end releases the complete vehicle software baseline and synchronizes it to the OTA system in real time. The production end of the vehicle is synchronized to the OTA in real time. The after-sales information of the after-sales end cooperates with the OTA end, so that the vehicle can be upgraded and repaired through the OTA software, forming a R&D, manufacturing, and after-sales service. OTA’s full life cycle closed loop.

Among them, vehicle function baselines, service subscriptions, unified management of vertical software versions of all controllers, conversion of different communication protocols, vehicle system status control, centralized upgrade service management and other technical means are prerequisites for realizing OTA functions.

Overview of JiKr’s self-developed OTA solution

Jikrypton OTA solution consists of cloud platform, car-cloud pipeline, and car-side components. It also supports third-party system data docking and adaptation and the use of PKI system to achieve upgraded security control.

The OTA cloud platform realizes the management of vehicles and parts within the OTA upgrade range, upgradeable software management, service subscription, service orders and software version iterative upgrade process management, and supports docking with other management systems (such as TSP, MES, PKI/KMS, etc. ), realizing data synchronization and security management closed loop.

In order to achieve flexible adaptation of different bus architectures, the vehicle end is designed according to functional decoupling and split into sub-functions such as: vehicle cloud communication management, download management, 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 between cars and clouds relies on mature communication technologies such as 4G/5G, HTTPS, MQTT, and CDN to not only ensure that communication complies with information security specifications, but also uses high bandwidth and network distribution technology to increase the probability of software packages reaching each vehicle, ensuring that every vehicle Every car can get OTA services. The entire OTA upgrade process is mainly divided into three major stages: generating the upgrade package, downloading and transmitting the upgrade package, and installing the upgrade package. The entire stage is connected through network communication, and finally the vehicle terminal code and data are updated, thereby enhancing the functions and services of the vehicle terminal.

OTA overall solution architecture

Detailed explanation of the functional modules of Jikrypton’s self-developed OTA software

JiKr's self-developed OTA is based on the SOA framework and mainly includes the following services:

1. OTA Client : Responsible for interacting with OTA Server to obtain upgrade information and upgrade packages; responsible for interacting with OTA Master to provide car cloud communication services;

2. OTA Master : The car-end upgrade control main program is responsible for parsing the installation strategy and executing the installation process.

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

4. Diagnostic Manager : It is a diagnostic management service that provides diagnostic flashing services for OTA Master. DM is mainly divided into two modules: DCM and DEM. Among them, DCM (Diagnostic Communication Management) is mainly responsible for diagnostic communication management, that is, the processing of UDS related commands. DEM (Diagnostic Event Management) is diagnostic event management, which is mainly responsible for the processing of internal events in the software platform.

5. Update Agent : Provides the service of "restoring differential files" for OTA Master.

OTA software architecture

OTA cloud management and terminal information security protection

In order to ensure the confidentiality, integrity and authenticity of the OTA upgrade package, signature, data encryption, and signature verification technologies must be used in the upgrade package production process to verify the legality of the OTA upgrade package. Through the cloud-pipe-end integrated network security protection system, combined with an independent security chip that supports the national secret algorithm, a full range of information security protection is implemented for communication links, upgraded data storage, and distribution.

Car cloud security protection solution

The value brought to JiKrypton

Data-driven to improve ecological operation capabilities

The OTA solution based on the SOA architecture broadens the scope of "service" and "operation" and increases the added value of the vehicle. With the increase in the frequency of OTA of Jikrypton smart cars, by replacing manpower with data, the rapid evolution of data-driven algorithms will form a vehicle update iteration closed loop. With the multi-layered linkage of Jikrypton Intelligent Technology's developer platform, application store, and digital container, we can create services based on software, applications, resources, content, etc., and build push and distribution strategies to support diverse operating scenarios.

Decoupling software and hardware to create a good automotive software ecosystem

The implementation of the vehicle SOA architecture decouples application development from the vehicle hardware platform. One development can adapt to different vehicle models and platforms, while providing a standard basic platform for application development. From platformization to industrialization, we will help Jikrypton Automobile transform into digital technology services, continue to iterate the XOTA (FOTA/SOTA/DOTA) linkage technical solutions, continue to empower the core competitive elements of software + services, and continue to evolve vehicle capabilities. , lengthen the user life cycle and build a complete ecological closed loop.


Finally, send a recruitment advertisement:



Latest articles about

 
EEWorld WeChat Subscription

 
EEWorld WeChat Service Number

 
AutoDevelopers

About Us Customer Service Contact Information Datasheet Sitemap LatestNews

Room 1530, Zhongguancun MOOC Times Building,Block B, 18 Zhongguancun Street, Haidian District,Beijing, China Tel:(010)82350740 Postcode:100190

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号