OTA upgrade method, device, electronic device and medium based on service-oriented architecture

Abstract

The present application provides an OTA upgrade method, device, electronic device and medium based on a service-oriented architecture. The method includes: configuring an upgrade master control module in the vehicle network, and communicating and connecting at least one upgrade proxy module with the upgrade master control module; configuring multiple upgrade slave control modules in the vehicle network, each upgrade slave control module communicating and connecting with at least one electronic control unit; receiving upgrade instructions from a remote OTA cloud platform, and generating a protocol message containing upgrade instructions based on a service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying a service request, as well as data related to the requested service; forwarding the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message, and performs an upgrade flash operation on the electronic control unit according to the instructions and data in the protocol message. The present application improves the efficiency of OTA upgrades, reduces memory resource consumption, and improves the success rate of upgrade flashing.

Description

Technical Field

[0001] The present application relates to the field of new energy vehicle technology, and in particular to an OTA upgrade method, device, electronic device and medium based on a service-oriented architecture. Background Art

[0002] Service-oriented architecture (SOA) is a software design approach that aims to meet user needs through a set of loosely coupled and highly interoperable services. In the SOA architecture, network nodes provide independent services that are used by other participants in a standardized way. This design concept and communication mechanism are widely used in automotive Ethernet, often implemented through the SOME / IP protocol, which promotes efficient communication between clients and servers.

[0003] Over-the-air (OTA) technology provides a convenient way to upgrade vehicle software, by remotely downloading upgrade packages to fix system defects, accelerate product iterations, and improve user experience. As cars evolve towards software-defined, SOA provides strong support for the implementation of OTA, promotes the development of service-oriented OTA upgrade methods, helps simplify the upgrade process, and improves upgrade efficiency.

[0004] However, existing OTA technologies usually rely on UDS / DOIP protocols for point-to-point data transmission during implementation, which limits the parallel performance of the upgrade operation and leads to low upgrade efficiency. Especially when upgrading multiple ECUs, existing technologies cannot flash ECUs in parallel within the same domain, and excessive memory resources are occupied during the parallel flashing process. In addition, the point-to-point transmission method also increases the risk of the entire upgrade failing due to a single communication link failure.

[0005] Therefore, there is an urgent need to provide a new OTA upgrade method that can overcome the limitations of existing technologies and achieve more efficient and reliable vehicle software upgrades. Summary of the invention

[0006] In view of this, the embodiments of the present application provide an OTA upgrade method, device, electronic device and medium based on a service-oriented architecture to solve the problems of low upgrade efficiency, high memory resource consumption and easy failure of upgrade flashing in the prior art.

[0007] According to a first aspect of an embodiment of the present application, there is provided an OTA upgrade method based on a service-oriented architecture, comprising: configuring an upgrade master control module in a vehicle network, and communicating with at least one upgrade proxy module to the upgrade master control module, wherein the upgrade proxy module is used to forward the upgrade data packet received by the upgrade master control module to an associated upgrade slave control module; configuring multiple upgrade slave control modules in the vehicle network, each upgrade slave control module being communicated with at least one electronic control unit so as to apply the upgrade data packet from the upgrade master control module to the electronic control unit; in the upgrade master control module, receiving an upgrade instruction from a remote OTA cloud platform, and generating a protocol message containing the upgrade instruction based on a service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying a service request, and data related to the requested service; forwarding the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message, and performs an upgrade flash operation on the electronic control unit according to the instructions and data in the protocol message.

[0008] According to a second aspect of an embodiment of the present application, an OTA upgrade device based on a service-oriented architecture is provided, comprising: a configuration module, configured to configure an upgrade master control module in a vehicle network, and to communicate with at least one upgrade proxy module to the upgrade master control module, wherein the upgrade proxy module is used to forward an upgrade data packet received by the upgrade master control module to an associated upgrade slave control module; a communication module, configured to configure multiple upgrade slave control modules in the vehicle network, each upgrade slave control module being communicated with at least one electronic control unit so as to apply the upgrade data packet from the upgrade master control module to the electronic control unit; a generation module, configured to receive an upgrade instruction from a remote OTA cloud platform in the upgrade master control module, and to generate a protocol message containing the upgrade instruction based on a service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying a service request, and data related to the requested service; an upgrade module, configured to forward the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message, and performs an upgrade flash operation on the electronic control unit according to the instructions and data in the protocol message.

[0009] According to a third aspect of an embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0010] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0011] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0012] By configuring an upgrade master control module in the vehicle network, and communicating with at least one upgrade proxy module and the upgrade master control module, wherein the upgrade proxy module is used to forward the upgrade data packet received by the upgrade master control module to the associated upgrade slave control module; configuring multiple upgrade slave control modules in the vehicle network, each upgrade slave control module is communicated with at least one electronic control unit, so as to apply the upgrade data packet from the upgrade master control module to the electronic control unit; in the upgrade master control module, receiving the upgrade instruction from the remote OTA cloud platform, and generating a protocol message containing the upgrade instruction based on the service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying the service request, as well as data related to the requested service; forwarding the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message, and performs an upgrade flash operation on the electronic control unit according to the instructions and data in the protocol message. This application improves the efficiency of OTA upgrades, reduces memory resource consumption, and improves the success rate of upgrade flashing. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0014] Figure 1 It is a flow chart of an OTA upgrade method based on a service-oriented architecture provided in an embodiment of the present application;

[0015] Figure 2 It is a schematic diagram of the framework of the service-oriented architecture provided in the embodiment of the present application;

[0016] Figure 3 It is a schematic diagram of the network topology relationship and SOA design method provided by the embodiment of the present application;

[0017] Figure 4 It is a schematic diagram of the electronic and electrical architecture provided by an embodiment of the present application;

[0018] Figure 5 is a schematic diagram of switching from a primary communication channel to a backup communication channel provided in an embodiment of the present application;

[0019] Figure 6 It is a schematic diagram of the structure of the SOME / IP message provided in the embodiment of the present application;

[0020] Figure 7This is a schematic diagram of the principle of one-to-one OTA upgrade flashing provided in an embodiment of the present application;

[0021] Figure 8 This is a schematic diagram of upgrading and flashing an ECU using a UDS message provided in an embodiment of the present application;

[0022] Fig. 9 It is a schematic diagram of the message conversion process provided by the embodiment of the present application;

[0023] Fig.10 It is a structural diagram of an OTA upgrade device based on a service-oriented architecture provided in an embodiment of the present application;

[0024] Fig.11 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0026] SOA (Service-Oriented Architecture) is a service-oriented architecture. SOA is a design method that includes multiple services, and the services will eventually provide a series of functions through cooperation. SOA expresses a software architecture concept, which is defined as the use of services to meet the needs of software users. In the SOA environment, nodes on the network open their resources to other participants on the network in the form of independent services, and other participants use resources in a standard way. Different from the traditional point-to-point architecture, various SOAs are composed of loosely coupled and highly interoperable application services. SOA is an idea and a design method, and the carrier of SOA is the design of a communication mechanism, which is often implemented using SOME / IP. The SOME / IP protocol is a service-oriented communication middleware that provides a standard service interface for the client / server communication mechanism of automotive Ethernet.

[0027] OTA stands for Over the Air Technology, which means over-the-air download technology. Car OTA upgrades refer to firmware and software upgrades over the air. OTA not only brings a more convenient way to upgrade vehicles, but also allows consumers to experience a smarter and more convenient car experience. Downloading new software update packages from a remote server over the Internet to upgrade the system has the following meanings for connected cars: 1) quickly repair system defects; 2) quickly iterate, improve products and user experience; 3) save both parties time and money.

[0028] OTA has gradually moved from the early "function-oriented" OTA to the "service-oriented" OTA. SOA provides a strong support capability and foundation for OTA. With the development of software-defined cars and the realization of SOA architecture, the potential of OTA has been better exerted, the difficulty of OTA has been reduced, and the upgrade efficiency has been improved.

[0029] Currently, OTA upgrades usually use the UDS / DOIP protocol to upgrade and flash the target ECU. Both protocols are characterized by point-to-point, one-to-one data transmission and exclusive bus resources. If you want to flash ECUs in parallel, you need to monopolize the domain bus resources, so you can only flash between domains, not within a domain. To achieve this type of parallel flashing, you need to create multiple clients, and memory resources are also very expensive. Because it is point-to-point, one-to-one data transmission, if the link fails, the upgrade will fail.

[0030] In view of the problems existing in the above-mentioned prior art, the embodiment of the present application provides a new OTA upgrade method based on a service-oriented architecture. The present application performs OTA upgrades based on SOA services, and can subscribe or provide upgrade services according to the needs of the ECU itself. The present application can configure different protocols for upgrade flashing (SOMEIP / DOIP / UDS) according to the needs of each ECU. The technical solution of the present application has the following characteristics: 1) It can realize one-to-one and one-to-many (multiple ECUs required by the same upgrade package) upgrade flashing; 2) It can realize parallel flashing between domains and within domains, and does not monopolize bus resources, which greatly saves bus resources; 3) In the upgrade data transmission path, a protection link is configured according to the needs, so that the upgrade success rate is greatly increased; 4) According to the target ECU, such as supporting A / B partitions, the ECU can be upgraded without any sense, which does not affect the driving and use of the car by the owner, and greatly saves the waiting time of the owner consumed by the upgrade.

[0031] The contents of the technical solution of the present application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] Figure 1 It is a flow chart of the OTA upgrade method based on service-oriented architecture provided in an embodiment of the present application. Figure 1The OTA upgrade method based on the service-oriented architecture can be executed by the OTA upgrade system. Figure 1 As shown, the OTA upgrade method based on the service-oriented architecture may specifically include:

[0033] S101, configuring an upgrade master control module in the vehicle network, and establishing communication connection between at least one upgrade proxy module and the upgrade master control module, wherein the upgrade proxy module is used to forward an upgrade data packet received by the upgrade master control module to an associated upgrade slave control module;

[0034] S102, configuring a plurality of upgrade slave control modules in the vehicle network, each upgrade slave control module being communicatively connected with at least one electronic control unit so as to apply the upgrade data packet from the upgrade master control module to the electronic control unit;

[0035] S103, in the upgrade main control module, receiving an upgrade instruction from a remote OTA cloud platform, and generating a protocol message containing the upgrade instruction based on a service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying a service request, and data related to the requested service;

[0036] S104, forwarding the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message and performs an upgrade flashing operation on the electronic control unit according to the instructions and data in the protocol message.

[0037] In some embodiments, before configuring the upgraded main control module in the vehicle network, the method further includes:

[0038] Build a service-oriented architecture that decouples software, hardware, and vehicle platform. The service-oriented architecture includes a scalable electronic and electrical architecture, a scalable hardware computing platform, an operating system kernel, a device abstraction layer, an atomic service layer, and an application and composite service layer.

[0039] Specifically, the embodiment of the present application provides a hierarchical structure of a service-oriented architecture (SOA), which constructs a system with software and hardware decoupling, completes the abstraction and adaptation of services, and establishes a standardized service system. This system includes six levels: an extensible electronic and electrical architecture (also known as a computing and communication architecture), an extensible hardware computing platform, an operating system kernel, a device abstraction layer, an atomic service layer, and an application and combined service layer.

[0040] The specific components and functions of the service-oriented architecture are described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 2 Schematic diagram of the framework of the service-oriented architecture provided by the embodiment of the present application. Figure 2 As shown, the service-oriented architecture may specifically include the following contents:

[0041] In this architecture, software and hardware are separated. That is, software services can run on different hardware without changes, just like applications can run on different models of mobile phones. Service abstraction is to hide a complex function (such as data storage or user management) behind a simple operation. Adaptation refers to ensuring that services can run optimally in different environments. A standardized service system is a set of services with fixed standards and protocols. The development, testing and deployment of these services are carried out in accordance with unified standards. The construction process of a service-oriented architecture includes:

[0042] 1) Establish a scalable electronic and electrical architecture: This layer is equivalent to the foundation of the entire system, ensuring that the system can be expanded as technology develops and support more functions and services. This includes building a network architecture that supports multiple communication protocols and data transmission methods.

[0043] 2) Develop an extensible hardware computing platform: At this level, the hardware is designed to support a variety of sensors and external devices, as well as future upgrades and expansions. This means that the hardware platform can adapt to different computing needs and emerging technologies.

[0044] 3) Optimization of the operating system kernel: This layer is responsible for managing the basic environment for all software operations and must be stable and efficient. The operating system kernel provides an interface between software and hardware.

[0045] 4) Create a device abstraction layer: The device abstraction layer allows the upper-layer software to not care about the specific details of the lower-layer hardware. This allows software developers to focus on functional implementation rather than specific hardware issues of the device.

[0046] 5) Build the atomic service layer: This layer provides basic service functions, such as data storage, network communication, etc. Atomic services are the building blocks for building more complex services.

[0047] 6) Develop applications and composite service layer: At the top level, individual atomic services are combined into complex applications that provide user interfaces and business logic. This layer is responsible for services and functions directly facing end users.

[0048] By using standard services, development teams can iterate products quickly because they can reuse existing services instead of starting from scratch each time. The layered design allows each layer to be tested and verified separately, thereby reducing the complexity of overall integration testing. Different teams can work separately on product lines and platform lines. The product line is responsible for developing specific vehicle projects, while the platform line builds a technical support platform. The scalability of the hardware computing platform enables it to adapt to various sensors and external devices, while supporting hardware upgrades to ensure long-term compatibility. The scalability of the computing and communication architecture allows the platform to be quickly adapted to new models, minimizing the differentiation between models and reducing the pressure of later maintenance.

[0049] It should be noted that SOME / IP (Scalable service-oriented MiddlewarE over IP) refers to scalable service-oriented middleware based on IP. It is a service-oriented automotive Ethernet communication protocol, located on top of TCP / UDP, and is compatible with the basic software development platform currently being discussed internationally. The SOME / IP protocol adopts a C / S (Client / Server) communication architecture, where the Server is the service provider and the Client is the service consumer. According to the service interface type, the Remote Service Call mechanism is used to enable data to be transmitted in the network through data serialization and deserialization. The dynamic configuration of services is achieved through the available service discovery SD (Service Discovery) mechanism.

[0050] Furthermore, the embodiment of the present application also provides the implementation of the network topology and SOA (service-oriented architecture) design method between the main components during the OTA upgrade process. The main components include the OTA master control (UMC), the upgrade agent (UA) and the upgrade slave control (US). The following is a detailed description of the relationship and communication process between them, as well as how they work together to complete the OTA upgrade task, in conjunction with the accompanying drawings and specific embodiments. Figure 3 Schematic diagram of network topology and SOA design method provided by the embodiment of the present application. Figure 3 As shown, the network topology relationship and OTA upgrade process may specifically include the following contents:

[0051] 1. Network topology

[0052] OTA Master Controller (UMC): UMC is the central node of the OTA system, which manages the entire OTA upgrade process. It is responsible for communicating with the remote server, obtaining the OTA upgrade package, and transmitting the update to the corresponding ECU in the vehicle through the network.

[0053] Upgrade Agent (UA): UA acts as an intermediary to coordinate the communication between the UMC and each ECU. It receives upgrade packages from the UMC and distributes them to the correct upgrade slave (US) or directly to the ECU according to the guidance of the SOA.

[0054] Upgrade slave (US): US is the terminal node that receives OTA updates. It communicates directly with the vehicle's ECU and applies the upgrade package from UMC to the ECU.

[0055] 2. Implementation process of SOA design method

[0056] UMC obtains the upgrade package: UMC obtains the latest firmware or software upgrade package from the remote server. This process is achieved through vehicle-to-everything (V2X) or other communication methods.

[0057] UMC processes upgrade packages: UMC processes and forwards upgrade packages using protocols such as SOME / IP, MQTT, DOIP, or UDS. These protocols provide a standard method for data communication on different networks and devices.

[0058] UMC distributes the update package to UA: UMC distributes the update package to UA, which is usually done through SOM E / IP or other applicable protocols. UA is the component responsible for distributing updates to individual US or ECUs.

[0059] UA forwards the upgrade package to US: UA sends the upgrade package to the corresponding US according to the requirements and protocol support of each ECU. At this stage, data packets can be relayed and cached to ensure the reliability and efficiency of data transmission.

[0060] US applies the upgrade package to ECU: US receives the upgrade package from UA and applies it to the vehicle's ECU. This usually involves direct communication with the ECU and uses protocols such as SOME / IP, DOIP or UDS to ensure the correct transmission of data.

[0061] Confirm and verify the upgrade: Once the upgrade package is applied, the US will report the completion status to the UA, and the UA will report it to the UMC. The UMC will verify the results of the upgrade and confirm whether the update was successful.

[0062] Through the above embodiments, the OTA upgrade of the vehicle can be carried out smoothly between different components, and each component has its clear role and responsibility. The UMC is responsible for managing the acquisition and distribution of the upgrade package, the UA is responsible for ensuring that the upgrade package is correctly delivered to each US, and the US is responsible for the actual firmware or software update. The design of SOA allows this process to flexibly respond to different upgrade requirements and configurations, thereby ensuring the scalability and reliability of the upgrade process.

[0063] In some embodiments, the scalable electronic and electrical architecture adopts a ring network design, each node has at least two communication paths, the status of the communication paths is monitored, and the communication channels are detected for faults. When a fault in the main communication channel is detected, data transmission is automatically switched to a predetermined backup communication channel. After each OTA upgrade operation, upgrade status feedback is sent to the upgrade master control module through the upgrade slave control module, so that the upgrade master control module can confirm the result of the OTA upgrade operation.

[0064] Specifically, an electronic and electrical (E / E) architecture is designed inside the vehicle to implement a service-oriented architecture (SOA) and distribute OTA upgrade packages throughout the vehicle. The architecture includes the distribution and connection methods of the OTA upgrade master control (UMC), the upgrade agent (UA), and the upgrade slave control (US), including how to protect the communication channel.

[0065] In order to achieve the purpose of downloading OTA upgrade packages and upgrading ECU components, the OTA download and upgrade processing technology mentioned in the embodiment of this application mainly involves OTA upgrade master control (UMC), OTA upgrade agent (UA) and OTA upgrade slave control (US), etc. This technology is mainly implemented in the VBOX (vehicle remote communication module), VIU1~4 (vehicle gateway) and ECU (electronic control unit) components that are respectively carried. VBOX and VGW are connected through 100M / 1000M Ethernet, VIU1~4 are connected to each ECU component below it through Ethernet or CAN bus, and one or more ECU components are mounted below it.

[0066] The electronic and electrical architecture of the embodiment of the present application is described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 4 Schematic diagram of the electronic and electrical architecture provided by the embodiment of the present application. Figure 4 As shown, the electronic and electrical architecture may specifically include the following contents:

[0067] OTA Upgrade Master Controller (UMC): Responsible for coordinating the entire OTA upgrade process, including communication with the remote OTA cloud platform to download the upgrade package.

[0068] Vehicle Telematics Module (VBOX): As a node connected to the external network (such as 4G / 5G), it provides telematics capabilities for the UMC.

[0069] OTA upgrade agent (UA): distributed in different locations of the vehicle, responsible for distributing UMC upgrade packages to different ECUs.

[0070] OTA upgrade slave controller (US): directly connected to the ECU and responsible for applying the upgrade package to the ECU.

[0071] Vehicle Gateway (VIU1-4): As a network node inside the vehicle, it connects various ECUs and helps manage communications within the vehicle.

[0072] The architecture adopts a ring network design, and each node (such as VIU and ECU) has more than two connection paths. This ensures that even if there is a problem with one path, data can be transmitted through another path. The system monitors the status of the communication path to quickly detect when a failure occurs. Once a failure in the main channel is detected, the system automatically switches data transmission to the backup channel to ensure that the transmission of the upgrade package will not be interrupted.

[0073] Furthermore, after receiving the upgrade package, the upgrade slave (US) will confirm receipt to the upgrade agent (UA), and the UA will then feedback to the UMC to ensure that the data packet has been successfully delivered. Once the upgrade package is confirmed, the US will instruct the ECU to execute the upgrade procedure. During the upgrade process, if there is any change in the communication channel, the US will keep monitoring the communication status and continue the upgrade operation through the available channel.

[0074] Furthermore, after the upgrade is completed, the US feeds back the results to the UA and finally to the UMC. The UMC records the upgrade results and takes further actions when necessary, such as upgrading again or recording logs.

[0075] Through the process of the above-mentioned embodiment, the vehicle's OTA system can ensure that the upgrade process can still proceed smoothly even when problems occur in certain ECUs or network paths, thereby ensuring the continuity of the upgrade and the stability of the vehicle's functions.

[0076] In some embodiments, when a failure of the primary communication channel is detected, automatically switching data transmission to a predetermined backup communication channel includes:

[0077] Continuously monitor the status of the main communication channel. When a failure is detected in the main communication channel, a fault alarm is triggered and data transmission is switched to the backup communication channel according to the preset path.

[0078] Before data is transmitted through the backup communication channel, the availability of the backup communication channel is verified, and when the verification is passed, the upgrade message is transmitted along the path corresponding to the backup communication channel.

[0079] Specifically, the vehicle's OTA system is designed to have a primary communication channel and a backup communication channel to ensure that the upgrade process can continue when the primary communication channel fails. This is a redundancy mechanism that improves the robustness of the upgrade process.

[0080] The communication channel switching process of the embodiment of the present application is described in detail below with reference to the accompanying drawings and specific embodiments. Figure 5Schematic diagram of switching from a primary communication channel to a backup communication channel provided by an embodiment of the present application. Figure 5 As shown, the communication channel switching process may specifically include the following contents:

[0081] During the OTA upgrade of VIU4 and its lower-mounted ECUs, if the main communication channel of VBOX->VIU4 fails, the backup channel VBOX->VIU1->VIU2->VIU3->VIU4 will be switched to transmit the upgrade message to ensure the smooth progress of the upgrade and avoid upgrade failure due to communication failure.

[0082] First, the system continuously monitors the status of the primary communication channel from VBOX to VIU4. This channel is the preferred route for ECU upgrade flashing. If a disruption or performance degradation is detected in the primary channel, such as increased latency, data loss, or other signs of communication failure, the system will trigger an alarm and initiate the backup channel search process.

[0083] Then, the system will switch to the backup communication channel according to the pre-set path, for example: VBOX->VIU1->VIU2->VIU3->VIU4. This design ensures that if the direct path to VIU4 is unavailable, data can be transmitted through an alternative longer path.

[0084] Then, before transmitting through the backup channel, the system will first verify the availability of this backup channel to ensure that it can transmit the upgrade package. Once it is confirmed that the backup channel is unobstructed, the upgrade message will be transmitted along this path. During the process, each VIU and US node will work together to ensure that the upgrade data packet can reach the target ECU.

[0085] Finally, after the OTA upgrade is completed, the relevant ECU will feedback the upgrade status to VIU4 through US, and then feedback to UMC to confirm whether the upgrade process is successful. The entire switching process and its results will be monitored and recorded in the system log for subsequent review and fault analysis.

[0086] Through the steps of the above embodiments, the vehicle OTA system in the technical solution of the present application can use the predefined backup channel to continue the upgrade operation when the main communication channel fails, thereby reducing the risk of upgrade failure caused by communication failure and improving the reliability of the entire system.

[0087] In some embodiments, the protocol message adopts a service-oriented middleware protocol, and the composition of the protocol message includes:

[0088] A header having an Ethernet frame structure, including physical address information for identifying a network device;

[0089] The network layer header is used to carry the control information and routing information required for IP communication;

[0090] The transport layer header is used to determine the communication port and protocol-specific control information based on TCP or UDP;

[0091] The service-oriented middleware protocol header is used to define the service identifier and method identifier of the requested service, as well as the length of the subsequent data area and the identification information of the request;

[0092] The data area is used to carry OTA upgrade data and other information related to the requested service; the data area includes source address and destination address fields, as well as a type field that identifies the nature of the message.

[0093] Specifically, the embodiment of the present application also provides the composition of the SOME / IP message, which is a service-oriented middleware protocol used in vehicle Ethernet communication and can be carried on TCP / UDP. The composition of the SOME / IP message of the embodiment of the present application is described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 6 Schematic diagram of the structure of the SOME / IP message provided in the embodiment of the present application. Figure 6 As shown, the SOME / IP message may specifically include the following contents:

[0094] Figure 6 The upper part shows that SOMEIP is carried in Ethernet packets for communication, carried on TCP / UD P. The SOMEIP packet is divided into a SOMEIP header and a data area. The SOMEIP header is shown in Figure 6 The middle section of the upper part is shown, and the lower section is the specific definition of the SOMEIP header. Figure 6 The lower part is the specific definition of the SOMEIP data domain. DOIP and SOMEIP are located at the same layer, and their main functions are used for diagnosis and upgrade. The specific definition is basically the same as SOMEIP, so I will not repeat it here.

[0095] 1. Composition of SOME / IP message

[0096] Ethernet frame: This is the outermost layer, which includes the Ethernet header (EthHead), including information such as the destination and source MAC addresses, and it wraps the entire SOME / IP message.

[0097] Network layer and transport layer headers: The IP header (IPHead) contains information about the network layer, such as the IP address and other control information. The TCP / UDP header (TCP / UDP Head) is the header of the transport layer, which contains the port number and other transmission control information. The SOME / IP header includes a fixed format of 16 bytes, which defines how to interpret the subsequent data area.

[0098] Service ID (i.e. service identification): indicates the requested service.

[0099] Method ID (i.e. method identifier): specifies the specific method or event to be called within the service.

[0100] Length field: identifies the length of the subsequent data area.

[0101] Request ID: Usually generated by the client and used to match the response with the request.

[0102] SOME / IP data area:

[0103] OTA message: Message for OTA (Over-The-Air Technology) upgrade, which may contain firmware or software update data.

[0104] SA (source address) / DA (destination address) field: identifies the addresses of the sender and receiver of the message.

[0105] Message Type: Indicates whether the message is a request, response, or notification type.

[0106] 2. Working process of SOME / IP message protocol

[0107] Encapsulation and transmission: When a device needs to make a service request, it sets the appropriate service and method ID in the SOME / IP header and then packages the requested data in the data area. This message is then encapsulated in the appropriate transport layer (TCP or UDP) and network layer protocol and sent over Ethernet.

[0108] Receiving and parsing: After receiving the Ethernet frame, the target device will parse out the SOME / IP header and data area. It will determine how to process the received data based on the service ID and method ID. If it is an OTA upgrade request, it will perform the corresponding firmware or software update.

[0109] Response: Once the service is completed, a response message is constructed and sent back to the requester. This response also contains the SOME / IP header and the data area, which contains the execution result or return data.

[0110] Through such a structure and working process, the SOME / IP protocol provides a flexible and powerful way to handle service requests within the vehicle, especially complex tasks such as diagnosis and OTA upgrades. It allows devices within the vehicle to communicate efficiently in a standardized way.

[0111] In some embodiments, the method further comprises:

[0112] After receiving the upgrade service subscription of the electronic control unit, the upgrade main control module initiates a query to the remote OTA cloud platform to obtain the latest software version of the electronic control unit. When an update is available, it downloads the latest version and assembles the protocol message. The protocol message contains the service identifier and method identifier specified for the electronic control unit, as well as the corresponding upgrade data. The protocol message is sent to the corresponding electronic control unit for upgrade flashing.

[0113] Specifically, the embodiment of the present application also provides a one-to-one OTA upgrade flashing implementation process. The one-to-one OTA upgrade flashing process of the embodiment of the present application is described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 7 This is a schematic diagram of the principle of one-to-one OTA upgrade flashing provided by the embodiment of the present application. Figure 7 As shown, the one-to-one OTA upgrade flashing process may include the following contents:

[0114] When VIU4 itself needs to be upgraded, it sends a subscription upgrade service to VBOX UMC. VBOX UMC initiates a query to the cloud OTA cloud platform for the latest version of VIU4. If there is an update, it downloads the latest version. VBOX UMC provides upgrade service to VIU4 and assembles SOMEIP message. SOM EIP header: 0x0 (VBOX), 1024 (if the data length of the frame message is 1024 bytes), 0x4 (VIU4), 1, 1, 0, 0; SOMEIP data domain: 0x1000 (OTA upgrade service), 0x0 (VBOX address), 0x4 (VIU4), [1-SOMEIP, 1-Support A / B partition, 0-None, 1-Configure active / standby protection, <vbox->VIU4>, <vbox->VIU1->VIU2->VIU3->VIU4>], xxxx (upgrade data). Realize one-to-one OTA upgrade and flash.

[0115] In some embodiments, the method further comprises:

[0116] When the upgrade main control module performs an upgrade operation on multiple electronic control units, a protocol message is configured to include a service identifier, a method identifier and an upgrade data packet shared by the multiple electronic control units, and the upgrade main control module is used to transmit the protocol message through different nodes of the vehicle network so as to distribute the upgrade data packet to the multiple electronic control units at one time;

[0117] When multiple electronic control units support different upgrade protocols, the upgrade main control module is used to configure the corresponding message format according to the protocol support of each electronic control unit, and the message conversion is performed through the network node.

[0118] Specifically, the embodiment of the present application also provides a process for implementing simultaneous upgrade and flashing of multiple ECUs. The process for simultaneously upgrading and flashing of multiple ECUs in the embodiment of the present application is described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 8 This is a schematic diagram of using UDS messages to upgrade and flash an ECU according to an embodiment of the present application. Fig. 9 Schematic diagram of the message conversion process provided by the embodiment of the present application. Figures 8 to 9 As shown, the process of upgrading and flashing multiple ECUs simultaneously may include the following:

[0119] When VIU1~VIU4 itself needs to be upgraded, it sends a subscription upgrade service to VBOX UMC, and VBOX UMC initiates a query to the cloud OTA cloud platform for the latest version of VIU1~4. If there is an update, it downloads the latest version, and VBOX UMC provides upgrade services to VIU1~VIU4. Since VIU1~VIU4 are the same parts deployed in different locations of the vehicle system and use the same upgrade package, the traditional OTA upgrade method needs to be upgraded one by one. In this embodiment, the same upgrade program can be used to upgrade VIU1~VIU4 at the same time, greatly improving efficiency and network bandwidth. In the "same upgrade package ECU group" of the configuration information field of the SOMEIP data domain, it can be set as: [1-VIU1, 2-VIU2, ..., 4-VIU4]. When VBOX UMC sends an upgrade message, each intermediate network node (VDC, ADC, CDC, VIU1~4) parses and forwards the message, and sends the upgrade data from the source address of VBOX to the target VIU1~VIU4 at the same time, realizing one-to-many upgrade writing.

[0120] Different ECUs support different upgrade protocols. This application can provide different protocols for upgrade flashing. For example, when flashing VIU1 itself and its attached components ECU1-1 and VIU2 in parallel, VIU1 supports the SOMEIP protocol, VIU2 supports the DOIP protocol, and ECU1-1 supports the UDS protocol. Different upgrade methods are used, which are described as follows: (1) VBOX UMC encapsulates SOME IP messages and DOIP messages for VIU1 and VIU2 respectively (such as Figure 7 (2) When VBOX UMC upgrades ECU1-1, the lower-hanging component of VIU1, SOMEIP message transmission is still used in the backbone network of VBOX->VIU1, and VIU1 parses and encapsulates it into UDS message (such as Figure 8 The method of converting SO MEIP to UDS (CAN) message format is the same as Figure 9 (3) When VBOX UMC upgrades ECU2-1, the lower-mounted component of VIU2, DOIP messages are still used for transmission in the backbone network of VBOX->VIU2, and VIU2 parses and encapsulates them into UDS messages (such as Figure 8 The method of converting SOMEIP to UDS (CAN) message format is the same as Fig. 9 The DOIP is shown below.

[0121] based on Figures 7 to 9 The content shown in this embodiment describes in detail the OTA upgrade process of the vehicle and the composition and working principle of the message protocol. In this process, the upgrade instructions and data are encapsulated and transmitted to each electronic control unit (ECU) of the vehicle through different communication protocols. The following is an explanation of the composition of the message protocol, the OTA upgrade process, and the message conversion:

[0122] 1. Composition and working principle of message protocol

[0123] SOME / IP protocol: used to transmit data between devices in the vehicle network. It is designed to be carried on top of TCP or UDP and sent over Ethernet.

[0124] SOME / IP message: contains a header and a data area. The header defines the basic attributes of the message such as service ID and method ID, while the data area carries specific upgrade data.

[0125] 2. OTA upgrade process

[0126] 1. Single ECU upgrade:

[0127] like Figure 7 As shown in Figure 1, when a single ECU (such as VIU4) needs to be upgraded, it will request the upgrade service from the UMC through a SOME / IP message. The UMC queries the cloud to obtain the latest version of the upgrade package, encapsulates it in a SOME / IP message, and then sends it to the corresponding ECU for upgrading.

[0128] 2. Multiple identical ECU upgrades:

[0129] like Figure 7 and Figure 8 As shown in the figure, when multiple ECUs of the same type need to be upgraded (such as VIU1-4), the UMC will encapsulate a SOME / IP message, which contains the upgrade data for all these ECUs. The UMC sends a common SOME / IP message, and the intermediate network nodes (such as VIU1-4) will distribute the upgrade package to each corresponding ECU as needed.

[0130] 3. ECU upgrade with different protocols:

[0131] If each ECU supports different protocols, UMC will encapsulate multiple types of messages (such as SOME / IP, DOIP, UDS) to adapt to the specific needs of each ECU. For example, for ECUs that support SOME / IP, UMC will directly send SOME / IP messages; while for ECUs that only support UDS protocol, UMC will convert SOME / IP or DOIP messages into UDS messages on the way so that ECUs can correctly parse and apply upgrades.

[0132] 3. Message Conversion Example

[0133] like Fig. 9 As shown in the figure, it describes how to convert SOME / IP or DOIP messages into UDS messages on the CAN network. This conversion usually occurs in the VIU node, which is responsible for converting the protocol on the network into a protocol compatible with the downstream ECU. The message conversion process includes converting the header information of the network layer and the transport layer into the frame format of the CAN network and ensuring that the original data content (upgrade data) is accurately transmitted.

[0134] According to the technical solution provided by the above embodiment, the entire OTA upgrade process is a complex communication and data processing process involving multiple communication protocols and network technologies. Through this multi-level, multi-protocol design, the technical solution of this application ensures that ECUs of different types and supported by different network protocols can receive and apply necessary upgrades, so that the vehicle's software can be kept up to date.

[0135] In summary, this application is based on SOA services for OTA upgrades, and can subscribe to or provide upgrade services according to the needs of the ECU itself. This application can configure different protocols for upgrade flashing (SOMEIP / DOIP / UDS) according to the needs of each ECU, and can achieve one-to-one and one-to-many (multiple ECUs with the same upgrade package requirements) upgrade flashing; it can achieve parallel flashing between domains and within domains, without monopolizing bus resources, greatly saving bus resources; in the upgrade data transmission path, protection links are configured according to needs, which greatly increases the success rate of the upgrade; according to the target ECU, such as supporting A / B partitions, the ECU can be upgraded without any sense, which does not affect the owner's driving and use of the car, and greatly saves the owner's waiting time consumed by the upgrade.

[0136] This application is based on service-oriented design, realizing layered design and decoupling of software and hardware, making it easier to iterate and update software functions; supporting the configuration of master-slave protection for the ring network channel to ensure the stability of channel communication; each ECU component subscribes to its own OTA upgrade service, which can realize parallel upgrade and flashing of multiple ECU components; through service-oriented design, communication is carried out by subscription, publishing and other methods, which greatly saves network bandwidth.

[0137] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0138] Fig.10 is a schematic diagram of the structure of an OTA upgrade device based on a service-oriented architecture provided in an embodiment of the present application. Fig.10 As shown, the OTA upgrade device based on the service-oriented architecture includes:

[0139] The configuration module 1001 is configured to configure an upgrade master control module in the vehicle network, and to establish a communication connection between at least one upgrade agent module and the upgrade master control module, wherein the upgrade agent module is used to forward an upgrade data packet received by the upgrade master control module to an associated upgrade slave control module;

[0140] The communication module 1002 is configured to configure a plurality of upgrade slave control modules in the vehicle network, each upgrade slave control module being in communication connection with at least one electronic control unit so as to apply the upgrade data packet from the upgrade master control module to the electronic control unit;

[0141] The generation module 1003 is configured to receive an upgrade instruction from a remote OTA cloud platform in the upgrade main control module, and generate a protocol message containing the upgrade instruction based on the service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying the service request, and data related to the requested service;

[0142] The upgrade module 1004 is configured to forward the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message and performs an upgrade flash operation on the electronic control unit according to the instructions and data in the protocol message.

[0143] In some embodiments, Fig.10 The construction module 1005 is used to build a service-oriented architecture in which software, hardware and vehicle platform are decoupled from each other before configuring and upgrading the main control module in the vehicle network. The service-oriented architecture includes an extensible electronic and electrical architecture, an extensible hardware computing platform, an operating system kernel, a device abstraction layer, an atomic service layer and an application and composite service layer.

[0144] In some embodiments, the scalable electronic and electrical architecture adopts a ring network design, each node has at least two communication paths, the status of the communication paths is monitored, and the communication channels are detected for faults. When a fault in the main communication channel is detected, data transmission is automatically switched to a predetermined backup communication channel. After each OTA upgrade operation, upgrade status feedback is sent to the upgrade master control module through the upgrade slave control module, so that the upgrade master control module can confirm the result of the OTA upgrade operation.

[0145] In some embodiments, Fig.10 The detection module 1006 is used to continuously monitor the status of the main communication channel. When a failure is detected in the main communication channel, a fault alarm is triggered, and data transmission is switched to the backup communication channel according to a preset path; before data is transmitted through the backup communication channel, the availability of the backup communication channel is verified, and when the verification is passed, the upgrade message is transmitted along the path corresponding to the backup communication channel.

[0146] In some embodiments, the protocol message adopts a service-oriented middleware protocol, and the composition of the protocol message includes: a header with an Ethernet frame structure, including physical address information for identifying the network device; a network layer header, used to carry control information and routing information required for IP communication; a transport layer header, used to determine the communication port based on TCP or UDP and protocol-specific control information; a service-oriented middleware protocol header, used to define the service identifier and method identifier of the requested service, as well as the length of the subsequent data area and identification information of the request; a data area, used to carry OTA upgrade data and other information related to the requested service; the data area includes source address and destination address fields, and a type field that identifies the nature of the message.

[0147] In some embodiments, Fig.10 The upgrade module 1004 is also used for initiating a query to the remote OTA cloud platform to obtain the latest software version of the electronic control unit after the upgrade main control module receives the upgrade service subscription of the electronic control unit. When there is an available update, the latest version is downloaded and a protocol message is assembled. The protocol message contains a service identifier and a method identifier specified for the electronic control unit, as well as corresponding upgrade data, and the protocol message is sent to the corresponding electronic control unit for upgrade flashing.

[0148] In some embodiments, Fig.10 The upgrade module 1004 is also used to configure the protocol message to include the service identifier, method identifier and upgrade data packet shared by multiple electronic control units when the upgrade main control module performs an upgrade operation on multiple electronic control units, and use the upgrade main control module to transmit the protocol message through different nodes of the vehicle network so as to distribute the upgrade data packet to multiple electronic control units at one time; wherein, when multiple electronic control units support different upgrade protocols, the upgrade main control module is used to configure the corresponding message format according to the protocol support of each electronic control unit, and perform message conversion through the network node.

[0149] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0150] Fig.11 1 is a schematic diagram of the structure of the electronic device 11 provided in the embodiment of the present application. Fig.11 As shown, the electronic device 11 of this embodiment includes: a processor 1101, a memory 1102, and a computer program 1103 stored in the memory 1102 and executable on the processor 1101. When the processor 1101 executes the computer program 1103, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 1101 executes the computer program 1103, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0151] Exemplarily, the computer program 1103 may be divided into one or more modules / units, which are stored in the memory 1102 and executed by the processor 1101 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 1103 in the electronic device 11.

[0152] The electronic device 11 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 11 may include, but is not limited to, a processor 1101 and a memory 1102. Those skilled in the art will appreciate that Fig.11 It is only an example of the electronic device 11 and does not constitute a limitation of the electronic device 11. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0153] The processor 1101 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0154] The memory 1102 may be an internal storage unit of the electronic device 11, for example, a hard disk or memory of the electronic device 11. The memory 1102 may also be an external storage device of the electronic device 11, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card (FlashCard), etc. equipped on the electronic device 11. Further, the memory 1102 may also include both an internal storage unit of the electronic device 11 and an external storage device. The memory 1102 is used to store computer programs and other programs and data required by the electronic device. The memory 1102 may also be used to temporarily store data that has been output or is to be output.

[0155] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0156] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0157] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0158] In the embodiments provided in the present application, it should be understood that the disclosed devices / computer equipment and methods can be implemented in other ways. For example, the device / computer equipment embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. Multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0159] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0160] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0161] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. Computer-readable media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0162] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An OTA upgrade method based on a service-oriented architecture, characterized in that: include: An upgrade master control module is configured in a remote communication module of the vehicle network, and at least one upgrade agent module is communicatively connected to the upgrade master control module, wherein the upgrade agent modules are distributed at different locations of the vehicle and are used to forward upgrade data packets received by the upgrade master control module to associated upgrade slave control modules; A plurality of the upgrade slave control modules are configured in a vehicle gateway of the vehicle network, each of the upgrade slave control modules being communicatively connected with at least one electronic control unit so as to apply the upgrade data packet from the upgrade master control module to the electronic control unit; In the upgrade main control module, an upgrade instruction from a remote OTA cloud platform is received, and a protocol message containing the upgrade instruction is generated based on a service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying a service request, as well as data related to the requested service; The service-oriented architecture includes an expandable electronic and electrical architecture, an expandable hardware computing platform, an operating system kernel, a device abstraction layer, an atomic service layer, and an application and combined service layer; the expandable electronic and electrical architecture adopts a ring network design, each node has at least two communication paths, the status of the communication path is monitored, and the communication channel is detected for faults. When a fault in the main communication channel is detected, data transmission is automatically switched to a predetermined backup communication channel; The protocol message adopts the service-oriented middleware protocol SOME / IP; The protocol message is forwarded to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message and performs an upgrade flashing operation on the electronic control unit according to the instructions and data in the protocol message.

2. The method according to claim 1, characterized in that Before configuring and upgrading the main control module in the vehicle network, the method further includes: Build a service-oriented architecture in which software, hardware, and vehicle platform are decoupled from each other.

3. The method according to claim 2, characterized in that After each OTA upgrade operation, the upgrade slave control module sends upgrade status feedback to the upgrade master control module, so that the upgrade master control module confirms the result of the OTA upgrade operation.

4. The method according to claim 3, characterized in that When a failure of the primary communication channel is detected, automatically switching data transmission to a predetermined backup communication channel includes: Continuously monitoring the status of the primary communication channel, and when a failure of the primary communication channel is detected, triggering a failure alarm, and switching data transmission to the backup communication channel according to a preset path; Before data is transmitted through the backup communication channel, the availability of the backup communication channel is verified, and when the verification is passed, the upgrade message is transmitted along the path corresponding to the backup communication channel.

5. The method according to claim 1, characterized in that The composition of the protocol message includes: A header having an Ethernet frame structure, including physical address information for identifying a network device; The network layer header is used to carry the control information and routing information required for IP communication; The transport layer header is used to determine the communication port and protocol-specific control information based on TCP or UDP; The service-oriented middleware protocol header is used to define the service identifier and method identifier of the requested service, as well as the length of the subsequent data area and the identification information of the request; The data area is used to carry OTA upgrade data and other information related to the requested service; the data area includes source address and destination address fields, and a type field that identifies the nature of the message.

6. The method according to claim 1, characterized in that The method further comprises: After receiving the upgrade service subscription of the electronic control unit, the upgrade main control module initiates a query to the remote OTA cloud platform to obtain the latest software version of the electronic control unit. When there is an available update, the latest version is downloaded and the protocol message is assembled. The protocol message includes the service identifier and method identifier specified for the electronic control unit, as well as the corresponding upgrade data. The protocol message is sent to the corresponding electronic control unit for upgrade flashing.

7. The method according to claim 1, characterized in that The method further comprises: When the upgrade main control module performs an upgrade operation on a plurality of electronic control units, the protocol message is configured to include a service identifier, a method identifier and an upgrade data packet shared by the plurality of electronic control units, and the upgrade main control module is used to transmit the protocol message through different nodes of the vehicle network, so as to distribute the upgrade data packet to the plurality of electronic control units at one time; When the multiple electronic control units support different upgrade protocols, the upgrade main control module is used to configure the corresponding message format according to the protocol support of each electronic control unit, and perform message conversion through the network node.

8. An OTA upgrade device based on a service-oriented architecture, characterized in that: include: a configuration module configured to configure an upgrade master control module in a remote communication module of an in-vehicle network, and to communicatively connect at least one upgrade agent module to the upgrade master control module, wherein the upgrade agent modules are distributed at different locations of the vehicle and are used to forward upgrade data packets received by the upgrade master control module to associated upgrade slave control modules; A communication module configured to configure a plurality of the upgrade slave control modules in a vehicle gateway of an in-vehicle network, each of the upgrade slave control modules being communicatively connected with at least one electronic control unit so as to apply an upgrade data packet from the upgrade master control module to the electronic control unit; A generation module is configured to receive an upgrade instruction from a remote OTA cloud platform in the upgrade main control module, and generate a protocol message containing the upgrade instruction based on a service-oriented architecture, wherein the protocol message contains a service identifier and a method identifier for identifying a service request, as well as data related to the requested service, and the service-oriented architecture contains an extensible electronic and electrical architecture, an extensible hardware computing platform, an operating system kernel, a device abstraction layer, an atomic service layer, and an application and composite service layer; the extensible electronic and electrical architecture adopts a ring network design, each node has at least two communication paths, the status of the communication paths is monitored, and the communication channels are fault-detected, and when a fault in the main communication channel is detected, data transmission is automatically switched to a predetermined backup communication channel; The protocol message adopts the service-oriented middleware protocol SOME / IP; The upgrade module is configured to forward the protocol message to the upgrade slave control module, so that the upgrade slave control module parses the received protocol message and performs an upgrade flash operation on the electronic control unit according to the instructions and data in the protocol message.

9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images