Ota control method, system and computer readable storage medium

Abstract

The application provides an OTA control method, system and computer readable storage medium, receiving a control instruction sent by an OTA server in bidirectional communication connection with an OTA master; analyzing the control instruction to determine a target ECU and a control operation; calling an interface corresponding to the control operation and sending a service request to a vehicle communication device providing hardware services for the OTA master. So that the vehicle communication device responds to the service request, calls the hardware resources required by the service request, executes the control operation and sends the control instruction to the target ECU to complete the control of the target ECU. Through modular development of the OTA master module, the OTA master and the vehicle communication device interact through explicit interfaces and protocols, reducing the coupling degree between the OTA software and the hardware, quickly adapting to the integration of new technologies and new functions, and reducing the maintenance cost.

Description

Technical Field

[0001] This application relates to the field of over-the-air (OTA) download technology, and in particular to an OTA control method, system, and computer-readable storage medium. Background Technology

[0002] With the digital transformation of the automotive industry and the increasing popularity of intelligent connected vehicles, OTA (Over-the-Air) software updates have become an important means for automakers to keep vehicle software up-to-date, fix security vulnerabilities, and improve user experience.

[0003] Traditional OTA (Over-The-Air) systems are often tightly coupled with hardware. When updating software, specific hardware characteristics and limitations must be fully considered, requiring customized development and testing of the update program for these specific hardware components, increasing update complexity. Furthermore, during the subsequent maintenance of the OTA system, both software and hardware changes need to be monitored simultaneously. If the hardware is adjusted, the OTA system may need corresponding modifications, increasing maintenance costs. Simultaneously, when hardware upgrades are needed, the tightly coupled OTA system may limit the flexibility of hardware upgrades, also increasing upgrade costs. Moreover, tightly coupled OTA systems often require comprehensive hardware testing and adaptation during updates, leading to lengthy update processes, especially in large-scale deployments such as OTA updates for a large number of vehicles or smart devices. Extended update times can significantly impact user experience and normal device operation.

[0004] Therefore, traditional OTA systems often have close dependencies on various hardware components of the vehicle at multiple levels, which makes traditional OTA system updates complex, costly, and inefficient. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this specification provides OTA control methods, systems, and computer-readable storage media.

[0006] According to a first aspect of the embodiments of this specification, an OTA control method is provided, applied to an OTA master, the method comprising:

[0007] Receive control commands sent by the OTA server, which is bidirectionally connected to the OTA master;

[0008] The control commands are parsed to determine the target ECU and the control operation;

[0009] The interface corresponding to the control operation is invoked to send a service request to the vehicle communication device that provides hardware services to the OTA master, so that the vehicle communication device responds to the service request, invokes the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU;

[0010] The OTA master has multiple built-in interfaces that correspond to and are adapted to multiple hardware services provided by the vehicle communication device.

[0011] According to an OTA control method provided in this application, the step of calling the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware services for the OTA master includes:

[0012] Determine whether the vehicle communication device supports the communication protocol format of the OTA master;

[0013] If supported, the interface is invoked to send a service request to the in-vehicle communication device that provides hardware resources for the OTA master.

[0014] According to an OTA control method provided in this application, the method further includes:

[0015] If not supported, the interface is invoked to send a service request to the vehicle communication device that provides hardware resources to the OTA master through a preset communication protocol, wherein the preset communication protocol is a communication protocol format supported by the vehicle communication device.

[0016] According to an OTA control method provided in this application, the preset communication protocol includes the MQTT protocol. The architecture of the MQTT protocol includes an MQTT server and an MQTT client. The MQTT server has a bidirectional communication connection with the OTA master, the MQTT server has a bidirectional communication connection with the MQTT client, and the MQTT client has a bidirectional communication connection with the communication module of the vehicle communication device.

[0017] The step of calling the interface and sending a service request to the in-vehicle communication device that provides hardware resources to the OTA master via a preset communication protocol includes:

[0018] The interface is invoked to forward the service request to the MQTT client through the MQTT server, so that the MQTT client can pass it to the communication module of the vehicle communication device, and the communication module can respond to the service request.

[0019] According to the OTA control method provided in this application, the vehicle communication device includes any one of a T-BOX, a vehicle gateway, and a domain controller.

[0020] This application also provides an in-vehicle communication device, which integrates a modular OTAmaster, and the OTAmaster communicates bidirectionally with the communication module of the in-vehicle communication device;

[0021] The OTA master is configured to receive control commands sent by an OTA server with which it has a bidirectional communication connection; parse the control commands to determine the target ECU and the control operation; call the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware resources to the OTA master, so that the in-vehicle communication device responds to the service request, calls the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU; wherein the OTA master has multiple interfaces built-in that are adapted to multiple hardware services provided by the in-vehicle communication device.

[0022] According to the present application, an in-vehicle communication device is provided, wherein the in-vehicle communication device further integrates an MQTT client, and the MQTT client establishes a bidirectional communication connection with an MQTT server in the cloud;

[0023] The MQTT server communicates bidirectionally with the OTA master, and the MQTT server is used to forward the service requests of the OTA master to the MQTT client.

[0024] The MQTT client has a bidirectional communication connection with the communication module of the vehicle communication device. The MQTT client sends the service request to the communication module to access the hardware resources of the vehicle communication device.

[0025] According to the present application, an in-vehicle communication device is provided, which further integrates an MQTT client and an MQTT server.

[0026] This application also provides an OTA system based on the above-mentioned vehicle-mounted communication device, the system comprising:

[0027] OTA server stores control commands used to control the target ECU;

[0028] The vehicle-mounted communication device is used to provide hardware services for OTA. The vehicle-mounted communication device integrates a modular OTA master. The OTA master is configured with multiple interfaces that are adapted to multiple hardware services. The hardware resources required by the control command are called through the interfaces.

[0029] The target ECU communicates bidirectionally with the vehicle communication device, receives the control commands sent by the vehicle communication device, and responds to the control commands.

[0030] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the OTA control method as described above.

[0031] The OTA control method, system, and computer-readable storage medium described in the embodiments of this specification have the following advantages compared to the current OTA system, which often has a close dependency on various hardware components of the vehicle at multiple levels. This makes the traditional OTA system update complex, costly, and inefficient:

[0032] Firstly, the system receives control commands from an OTA server that is bidirectionally connected to the OTA master; parses the control commands to determine the target ECU and control operation; and calls the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware services to the OTA master. Through modular development of the OTA master, the OTA master interacts with the in-vehicle communication device through clear interfaces and protocols, reducing the coupling between the OTA software and hardware. This also enhances the scalability of the OTA system, enabling rapid adaptation to the integration of new technologies and functions, and reducing maintenance costs.

[0033] Secondly, the OTA master includes multiple built-in interfaces that correspond to and are compatible with various hardware services provided by the in-vehicle communication device. Different hardware can support the same interfaces, ensuring the software continues to function correctly even if the hardware changes, thus improving software compatibility. Furthermore, it eliminates the need to redevelop OTA functionality, reducing development costs.

[0034] Thirdly, the vehicle communication device responds to the service request, invokes the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU. The modular design also makes OTA functionality easier to port to different hardware platforms; in implementing OTA functionality, there is no need to focus too much on the vehicle communication device's handling of service requests.

[0035] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0037] Figure 1 This is a schematic diagram of an OTA system illustrated in this specification according to an exemplary embodiment;

[0038] Figure 2 This is a flowchart illustrating an OTA control method according to an exemplary embodiment of this specification;

[0039] Figure 3 This is a schematic diagram of an OTA control device illustrated in this specification according to an exemplary embodiment;

[0040] Figure 4 This is a schematic block diagram of an OTA control device illustrated in this specification according to an exemplary embodiment. Detailed Implementation

[0041] The technical solutions in the embodiments (or "implementations") of this application will be clearly and completely described herein with reference to the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0042] If the embodiments of this application contain terms relating to directional indications or positional relationships (such as up, down, left, right, front, back, inside, outside, top, bottom, center, vertical, horizontal, longitudinal, transverse, length, width, counterclockwise, clockwise, axial, radial, circumferential, etc.), such terms are only used to explain the relative positional relationships and movements between components in a specific posture (as shown in the attached figures); if the specific posture changes, the directional indications or positional relationships will also change accordingly. Furthermore, the terms "first" and "second" used in the embodiments of this application are only for descriptive convenience and should not be construed as indicating or implying relative importance.

[0043] This application provides an OTA control method, system, and computer-readable storage medium. The application will now be described in detail with reference to the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0044] With the digital transformation of the automotive industry and the increasing popularity of intelligent connected vehicles, OTA (Over-the-Air) software updates have become an important means for automakers to keep vehicle software up-to-date, fix security vulnerabilities, and improve user experience.

[0045] Traditional OTA systems are often tightly coupled with the vehicle's hardware, resulting in complex, costly, and inefficient updates.

[0046] To address the aforementioned technical issues, this specification provides an OTA software architecture.

[0047] By modularizing OTA functions and calling relevant hardware resources according to preset functional protocols, the OTA software and hardware are separated. This allows OTA software development to be no longer limited by hardware, and both can be developed, tested, and upgraded independently, resulting in more efficient, secure, and flexible software upgrades.

[0048] The hardware mentioned in this article refers to in-vehicle communication equipment that provides basic hardware services for OTA software, enabling the corresponding hardware resources to be called during OTA upgrades to realize OTA functions.

[0049] This specification provides an embodiment of an in-vehicle communication device, which integrates a modular OTA master (OTA device). The in-vehicle communication device includes a communication module for bidirectional communication with a controlled object within the vehicle. The communication module communicates bidirectionally with the OTA master. The controlled object refers to a component in the vehicle that requires OTA control for software updates, security vulnerability fixes, or user experience improvements. This can include, but is not limited to, ECUs and transmitter controllers within the vehicle; the ECU will be used as an example below.

[0050] In some embodiments, OTA master refers to the OTA function module, which is responsible for the entire OTA control and upgrade work, such as receiving control commands from the OTA server, such as upgrade commands, communicating with different ECUs in the vehicle, managing the upgrade process, handling error situations, etc.

[0051] The OTA master is developed separately, and several common interfaces are defined in the OTA master. These interfaces are adapted to multiple hardware services provided by the vehicle communication device, so that the hardware resources of the vehicle communication device can be called through the interface to realize the corresponding functions of OTA.

[0052] In defining a common interface, a set of universal interface specifications is established for the interaction between the OTA master and the hardware. Regardless of changes in the hardware, as long as it conforms to this interface specification, the OTA master can communicate with it. This reduces the OTA software's dependence on specific hardware.

[0053] For example, in the OTA software of IoT devices, a set of universal interface specifications can be defined, including but not limited to data transmission interfaces, storage interfaces, device status query interfaces, etc., or opening / closing CAN channels, receiving / sending CAN data, etc. Different IoT device manufacturers can implement their own hardware drivers according to this specification, enabling the OTA software to interact with various different IoT devices.

[0054] Simultaneously, verification tests are performed on the OTA master. For example, functional tests, performance tests, and compatibility tests are conducted on the OTA master. Passing these tests indicates that the OTA master can function normally.

[0055] In other examples, the OTA master is further subdivided into different modules based on its functions, including but not limited to instruction parsing modules, communication modules, and verification modules. Each module is developed independently, and the communication interfaces between modules are defined to implement the functions of the OTA master and the communication between the OTA master and the vehicle communication device.

[0056] In some embodiments, the in-vehicle communication device provides basic hardware services for the OTA master function module to ensure the normal operation and implementation of the OTA master function. The in-vehicle communication device may include, but is not limited to, an in-vehicle telematics processor (T-BOX), an in-vehicle gateway, and a domain controller. For example, an in-vehicle gateway: As a core node of the vehicle network, the in-vehicle gateway can integrate the OTA function module and is responsible for managing the software upgrades of various ECUs within the vehicle. Another example is the T-BOX, which is mainly responsible for remote communication between the vehicle and the outside world, realizing functions such as remote monitoring, diagnostics, and software upgrades, and can interact with the ECUs within the vehicle to a certain extent through specific communication protocols. Yet another example is an intelligent in-vehicle terminal, such as the domain controller of an in-vehicle entertainment system, which has processing power and storage resources and can integrate the OTA function module to realize its own software upgrades and collaborative upgrades with other ECUs.

[0057] Develop and verify in-vehicle communication equipment individually to determine its basic hardware service capabilities. This includes hardware testing, communication testing, and stability testing to ensure each module meets design requirements when operating independently.

[0058] In the early stages of project development, the OTA master and the vehicle communication device can be developed independently or simultaneously. Different development teams can focus on their respective modules, which improves development efficiency. Simultaneously, individual module verification tests are conducted on the OTA master and the vehicle communication device during development.

[0059] After both the OTA master and the vehicle communication device pass their respective tests, the OTA master is deployed to the vehicle communication device for integration testing. The purpose of integration testing is to verify whether each module can function properly when working together, and whether there are any compatibility issues, performance problems, or functional defects. Through integration testing, the stability and reliability of the entire system can be ensured.

[0060] The integrated OTA master receives control commands from the OTA server, which has a bidirectional communication connection with the OTA master. It parses the control commands to determine the target ECU and the control operation. It then calls the interface corresponding to the control operation and sends a service request to the in-vehicle communication device that provides hardware resources to the OTA master. This causes the in-vehicle communication device to respond to the service request, call the necessary hardware resources, execute the control operation, and send the control commands to the target ECU to complete the control of the target ECU. The OTA master has multiple built-in interfaces that correspond to various hardware services provided by the in-vehicle communication device. This process enables control of the target ECU, including but not limited to updating vehicle software and patching security vulnerabilities, which will be described in detail in later chapters.

[0061] Because the OTA master is developed as an independent module, relatively independent of specific hardware platforms (such as in-vehicle communication devices), it only requires some adaptive adjustments and configurations to run on different hardware. This eliminates the need for redeveloping the OTA master, significantly reducing the development cycle and costs of new products.

[0062] Therefore, in this embodiment, the OTA master developed through a modular development approach decouples the OTA software from the hardware, making it very easy to port to different hardware platforms in the future, thus achieving more efficient, secure, and flexible software upgrades.

[0063] In other embodiments, the OTA master communicates bidirectionally with the existing communication module in the vehicle communication device to send control commands received from the OTA server to the communication module and call the hardware resources of the vehicle communication device to control the target ECU.

[0064] In practical use, the communication method between OTAmaster and the original communication module in the vehicle communication device can be set according to factors such as the attributes of the vehicle communication device, communication requirements, and network environment. This can include, but is not limited to, the MQTT protocol, the HTTP protocol, and the communication channel built into the communication module of the vehicle communication device, thus forming a variety of vehicle communication devices.

[0065] As an example, the OTA master interacts with the communication module of the vehicle communication device via the MQTT protocol. The vehicle communication device integrates the OTA master and the MQTT client, which establishes a bidirectional communication connection with the MQTT server in the cloud.

[0066] The MQTT server communicates bidirectionally with the OTA master, and the MQTT server forwards the service requests from the OTA master to the MQTT client. The MQTT client has a bidirectional communication connection with the communication module of the vehicle communication device, and the MQTT client sends the service requests to the communication module to access the hardware resources of the vehicle communication device.

[0067] MQTT (Message Queuing Telemetry Transport) is a lightweight message publish / subscribe protocol widely used in the Internet of Things (IoT) field. In this scheme, the OTA master and the communication module of the in-vehicle communication device interact through an MQTT server. For example, the OTA master can publish upgrade commands and status information to the MQTT server. The in-vehicle communication device can also act as an MQTT client, subscribing to relevant topics and receiving commands and information from the OTA master. Simultaneously, the in-vehicle communication device can publish vehicle status information to the MQTT server for the OTA master to subscribe to and retrieve. Interacting through an MQTT server enables loosely coupled communication, improving system flexibility and scalability.

[0068] As another example, the OTA master interacts with the communication module of the vehicle communication device via the MQTT protocol. The vehicle communication device integrates an OTA master, an MQTT client, and an MQTT server, and the MQTT server communicates bidirectionally with both the OTA master and the MQTT client.

[0069] For example, when an upgrade to the controlled ECU (Electronic Control Unit) is required, the OTA master accesses the hardware resources of the vehicle communication device through a predefined interface.

[0070] As another example, the vehicle communication device integrates an OTA master, and the vehicle communication device supports the protocol format of the OTA master interface. That is, the interface protocol between the OTA master and the vehicle communication device hardware can work stably in different hardware versions and software environments, and also has good compatibility with the communication protocol of the target ECU.

[0071] When control of the target ECU is required, the OTA master directly accesses the hardware resources of the in-vehicle communication device through a predefined interface to implement the OTA function. These hardware resources include, but are not limited to, network connectivity resources and storage resources. When controlling the target ECU, the OTA master transmits control commands to the target ECU via the CNA bus of the in-vehicle communication device, enabling the target ECU to respond to the control commands. If the control command is an upgrade command, the target ECU, upon receiving the upgrade command, begins the software upgrade process, which may include steps such as verifying the update package, backing up the old software version, and installing the new software version.

[0072] As another example, the OTA master communicates bidirectionally with the communication module of the in-vehicle communication device via the HTTP protocol. Accordingly, an HTTP-based interface is defined for the OTA master to access the hardware resources of the in-vehicle communication device through this defined interface.

[0073] In this embodiment, the implementation of the OTA function involves the collaborative work of multiple links and devices. The selection and use of the interface protocol need to take into account various factors. The corresponding communication protocol can be selected based on factors such as whether the vehicle communication device supports the interface protocol format of the OTA master.

[0074] This specification provides an OTA system, the system comprising:

[0075] OTA server stores control commands used to control the target ECU;

[0076] The vehicle-mounted communication device is used to provide hardware services for OTA. The vehicle-mounted communication device integrates a modular OTA master. The OTA master is configured with multiple interfaces that are adapted to multiple hardware services. The hardware resources required by the control command are called through the interfaces.

[0077] The target ECU communicates bidirectionally with the vehicle communication device, receives the control commands sent by the vehicle communication device, and responds to the control commands.

[0078] The following is a detailed explanation of the bidirectional communication between the vehicle communication device T-BOX, the controlled object ECU of the vehicle, the OTA master and the communication module of the vehicle communication device via the MQTT protocol.

[0079] In some embodiments, refer to Figure 1 The OTA system includes an OTA server, a T-BOX, and a target ECU. The OTA server and the T-BOX communicate via the HTTP protocol, and the T-BOX and the target ECU communicate via eth or can. "eth" usually refers to "Ethernet"; "can" usually refers to "Controller Area Network".

[0080] After deploying the OTA master, MQTT server, and T-BOX basic functions onto the T-BOX hardware, system initialization is complete, and all modules are ready. This allows for subsequent control of the corresponding target ECUs based on control commands issued by the OTA server, thereby achieving OTA software functions such as keeping vehicle software up-to-date, fixing security vulnerabilities, and improving user experience.

[0081] Based on the above-mentioned vehicle communication equipment and OTA system, this specification provides an OTA control method in its embodiments.

[0082] Reference Figure 2 The Figure 2 This is a flowchart illustrating an OTA control method.

[0083] The method includes the following steps:

[0084] S100, receive control commands sent by the OTA server that is bidirectionally connected to the OTA master.

[0085] OTA server

[0086] The control commands mentioned in this article refer to commands that control the controlled object (such as the ECU of a vehicle) through OTA, including but not limited to software upgrade commands and fault diagnosis commands.

[0087] As an example, when the OTA server detects that a new software version is applicable to a certain ECU of the vehicle or device that provides hardware resources for the OTA function, it generates control commands and sends the control commands to the vehicle's in-vehicle communication device.

[0088] As another example, when an OTA server receives a diagnostic task, it sends a fault diagnosis command to the onboard communication device of the target vehicle with which it communicates.

[0089] The control commands include, but are not limited to, the download address of the upgrade package, the target ECU identifier, and verification information.

[0090] For in-vehicle communication devices that integrate modular OTA master, the OTA master communicates bidirectionally with the OTA server. The OTA server sends control commands to the vehicle's T-BOX via mobile network or other remote communication methods (such as HTTP protocol), and the OTA master on the T-BOX receives the control commands sent by the OTA server.

[0091] S200: The control command is parsed to determine the target ECU and control operation.

[0092] The T-BOX receives control commands from the OTA server and parses them through the OTA master to determine the target ECU to be controlled and the corresponding control operation. This control operation refers to the operation of the T-BOX hardware resources invoked to implement the control command. For example, it may open the CAN channel to send an upgrade package and receive the upgrade result in response to the upgrade command.

[0093] S300, call the interface corresponding to the control operation to send a service request to the vehicle communication device that provides hardware services for the OTA master, so that the vehicle communication device responds to the service request, calls the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU;

[0094] The OTA master has multiple built-in interfaces that correspond to and are adapted to multiple hardware services provided by the vehicle communication device.

[0095] The interface protocol for the OTA master to call the basic services of the vehicle communication device can be customized or standardized. For example, a set of APIs (Application Programming Interfaces) can be defined, through which the OTA master calls the vehicle communication device's services such as opening / closing / CAN / channel, sending / receiving / CAN / data.

[0096] Continuing with the example above, when the in-vehicle communication device is a T-BOX, the basic services provided by the T-BOX include, but are not limited to, opening / closing the CAN channel, receiving / transmitting CAN data, service requests, heartbeat, opening / closing the diagnostic channel, and receiving / transmitting diagnostic data. The OTA master has multiple built-in interfaces corresponding to these hardware services, and the T-BOX's hardware services are called according to the interface protocol. For example, if the control command corresponds to opening the CAN channel, a function interface named "openCanChannel()" is defined on the OTA master. When the OTA master needs to open the CAN channel, it calls this interface. The relevant modules inside the T-BOX receive this call request, execute the operation to open the CAN channel, and return the operation result to the OTA master.

[0097] The OTA master sends a service request to the T-BOX via a specific communication method (such as an internal communication bus or network connection). This request can contain specific command codes and parameters. The command codes indicate that the CAN channel needs to be opened, and the parameters can include information such as the identifier of the target ECU.

[0098] After receiving a service request from the OTA master, the T-BOX parses the request content. Based on the request, the T-BOX calls the relevant internal modules to perform the operation of opening the CAN channel. For example, after receiving the instruction, the CAN communication module in the T-BOX configures the hardware registers and opens the CAN channel corresponding to the target ECU.

[0099] Once the CAN channel is open, the OTA master retrieves the upgrade package from its storage location (either the T-BOX's local storage or by downloading it in real-time from the OTA server). The OTA master then sends the upgrade package to the target ECU via the CAN channel, adhering to the CAN protocol's data format and communication rules.

[0100] The target ECU receives the upgrade package and performs the upgrade. After the upgrade is complete, the target ECU sends an upgrade result message to the T-BOX via the CAN channel. The T-BOX's CAN channel module receives the upgrade result message from the ECU and forwards it to the OTA master. The OTA master, through its communication connection with the OTA server, feeds back the upgrade result to the OTA server. The feedback message may include information such as the upgrade status, timestamp, and error codes (if any).

[0101] In some embodiments, the step of invoking the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware services to the OTA master includes:

[0102] Determine whether the vehicle communication device supports the communication protocol format of the OTA master.

[0103] If supported, the interface is invoked to send a service request to the in-vehicle communication device that provides hardware resources for the OTA master. If the communication module of the in-vehicle communication device can interact directly with the OTA master, then control commands are sent directly to the communication module of the in-vehicle communication device.

[0104] If not supported, the interface is invoked to send a service request to the vehicle communication device that provides hardware resources to the OTA master through a preset communication protocol, wherein the preset communication protocol is a communication protocol format supported by the vehicle communication device.

[0105] The preset communication protocol includes the MQTT protocol, and the MQTT protocol architecture includes an MQTT server and an MQTT client. (Refer to...) Figure 1 As shown, the MQTT server establishes a bidirectional communication connection with the OTA master, the MQTT server establishes a bidirectional communication connection with the MQTT client, and the MQTT client establishes a bidirectional communication connection with the communication module of the vehicle communication device.

[0106] The step of calling the interface and sending a service request to the in-vehicle communication device that provides hardware resources to the OTA master via a preset communication protocol includes:

[0107] The interface is invoked to forward the service request to the MQTT client through the MQTT server, so that the MQTT client can pass it to the communication module of the vehicle communication device, and the communication module can respond to the service request.

[0108] In this embodiment, interacting via an MQTT server achieves better decoupling. This makes OTAmaster and other functional modules of T-BOX relatively independent, facilitating development, testing, and maintenance. For example, if other functional modules of T-BOX experience problems, it will not directly affect the operation of OTAmaster, and vice versa.

[0109] In some embodiments, specific functions are defined through TOPIC based on the MQTT protocol.

[0110] Specifically, SequenceId is set as a unique identifier for the request, initialized by the requester, and remains unchanged by the responder when responding to the message.

[0111] Reply timeout settings:

[0112] If no reply is received within the timeout period after sending a message, the message will time out; a resend is required after the timeout. Unless otherwise specified, the timeout period and number of resends are as follows: Timeout period: 3 seconds, Number of resends after timeout: 3.

[0113] After designing the basic communication rules, the interface of the OTA master is defined.

[0114] As an example, T-BOX provides the OTA master with the hardware service to open / close the CAN channel.

[0115] When the OTA master receives an upgrade command requiring communication with the target ECU, it sends a request to the T-BOX to open the CAN channel. Upon receiving the request, the T-BOX opens the corresponding CAN channel and sends feedback to the OTA master confirming the channel is open. The OTA master can then send upgrade commands and data to the target ECU via the CAN channel.

[0116] Specifically, the following is an example of retrieving the protocol information of the interface that opens the CAN channel:

[0117] Request / Response TOPIC:

[0118] T-BOX sent the following topic: mqtt / ota_master / can_open

[0119] The topic sent by the OTA master is: mqtt / tbox / can_open

[0120] The OTA master sends a service request to T-BOX to open the CAN channel:

[0121]

[0122] The T-BOX is responsible for receiving data from the target ECU on the CAN bus and forwarding it to the OTA master. Simultaneously, the T-BOX can also send data to the target ECU on the CAN bus upon request from the OTA master.

[0123] Specifically, the protocol example for the request and response of TBOX to open the CAN channel is as follows:

[0124]

[0125]

[0126] As an example, T-BOX provides hardware services for sending heartbeat signals to the OTA master, and determines whether the OTA master is working properly based on the OTA master's heartbeat signals.

[0127] Specifically, the protocol for the interface that retrieves and sends the OTA master heartbeat signal is as follows:

[0128] Request / Response TOPIC:

[0129] The topic sent by the OTA master is: mqtt / ota_slave / heart_beat

[0130] Sending interval: once every 5 seconds

[0131] Timeout mechanism: If no heartbeat is received for 15 consecutive seconds, it indicates that the master heartbeat is abnormal.

[0132] T-BOX does not require a reply.

[0133] Send heartbeat data:

[0134] {

[0135] "sequenceId": "xxxxxx", / / Unique identifier for the request, initialized by the requester.

[0136] }

[0137] As an example, T-BOX provides hardware services for reading / setting data to the OTA master. An example of the interface protocol is as follows:

[0138] Request / Response TOPIC:

[0139] The topic sent by T-BOX is: mqtt / ota_master / read_tbox_data

[0140] The topic sent by the OTA master is: mqtt / tbox / read_tbox_data

[0141] Read / set data request:

[0142]

[0143]

[0144] By customizing or standardizing the interface protocol for the OTA master to call T-BOX basic services, OTA functionality can be developed. The developed OTA master can then be easily ported to different hardware without needing to be redeveloped; only the OTA architecture parameters need to be modified according to the hardware's attributes. This includes, but is not limited to, adjustments in hardware adaptation, software adaptation, and communication adaptation. For example, hardware interfaces need to be adapted to the characteristics of new hardware. For instance, the communication interface of new hardware (such as Ethernet, CAN bus, etc.) may differ from that of T-BOX, requiring reconfiguration of communication parameters and drivers. Furthermore, if the new hardware communicates with external systems in a different way, the OTA master's communication method needs to be adjusted to adapt to the new communication protocol and network environment.

[0145] As an example, based on the OTA system provided in this application, the OTA master is modularly developed based on the following protocol, which decouples the OTA master from the hardware and allows it to be equipped with T-BOXs from different brands. For ease of understanding, the OTA control method will be fully explained using the example of the OTA master calling the T-BOX diagnostics for data transmission and reception.

[0146] Specifically, the process of OTA master calling T-BOX diagnostics to send and receive data involves the following steps:

[0147] Step 1: Query the network segment where the controller being diagnosed is located.

[0148] The OTA master sends an MQTT request to obtain the UDS network segment where the controller is located, and T-BOX adds relevant information to the response.

[0149] Step 2: Open the network segment where the controller being diagnosed is located.

[0150] Based on the query results from the previous step, the OTA master sends an MQTT request to open the UDS protocol stack, and the T-BOX replies with the open result.

[0151] Step 3: Send diagnostic data

[0152] If the opening is successful, the OTA master can call the request to send UDS data, and the T-BOX will reply whether the sending was successful or not.

[0153] Step 4: Query diagnostic response

[0154] After the OTA master completes the diagnostic data transmission, it periodically sends a request to read UDS data to query the T-BOX for the response information of the diagnosed controller. The T-BOX then replies with the result (if the diagnosed controller responds, it replies with a response; otherwise, it replies with NULL).

[0155] Step 5: Shut down the network segment where the diagnosed controller is located.

[0156] After completing all diagnostic requirements, the OTA master sends a request to shut down the UDS protocol stack to close the network segment where the diagnosed controller is located, and T-BOX replies with the shutdown result.

[0157] The specific process is as follows:

[0158] 1. Obtain information about the UDS network segment where the controller is located.

[0159] Request / Response TOPIC: tbox sent topic: mqtt / ota_master / uds_get_net_name; OTA master sent topic: mqtt / tbox / uds_get_net_name; Name: Retrieved UDS network segment name.

[0160] Send a request to obtain the UDS network segment where the controller is located.

[0161]

[0162]

[0163] 2. Enable the UDS protocol stack

[0164] Request Response TOPIC

[0165] The topic sent by tbox is: mqtt / ota_master / uds_open_client

[0166] The topic sent by the OTA master is: mqtt / tbox / uds_open_client

[0167] Master exception handling:

[0168] Upon detecting an abnormal Master heartbeat, TBOX proactively shuts down all open UDS protocol stacks.

[0169] Name: Open UDS Protocol Stack

[0170] Send request to open UDS protocol stack

[0171]

[0172]

[0173] 3. Disable the UDS protocol stack

[0174] The request and response TOPICs are as follows: tbox sends a TOPIC: mqtt / ota_master / uds_shut_client; OTAmaster sends a TOPIC: mqtt / tbox / uds_shut_client to request the shutdown of the UDS protocol stack.

[0175]

[0176] 4. Send UDS data

[0177] Request / Response TOPIC: tbox sends the topic TOPIC: mqtt / ota_master / uds_diag_write; OTAmaster sends the topic TOPIC: mqtt / tbox / uds_diag_write; Name: Send UDS data request.

[0178]

[0179]

[0180] 5. Read UDS data

[0181] Request / Response TOPIC: tbox sends the topic: mqtt / ota_master / uds_diag_read; OTAmaster sends the topic: mqtt / tbox / uds_diag_read; Name: Reading UDS

[0182] Read UDS data request

[0183]

[0184]

[0185] 6. Turn on CAN

[0186] Request Response TOPIC

[0187] The topic sent by tbox is: mqtt / ota_master / can_open

[0188] The topic sent by the OTA master is: mqtt / tbox / can_open

[0189] Master exception handling:

[0190] Upon detecting an abnormal Master heartbeat, TBOX proactively closes all open CAN channels, and periodic message data reverts to default data. Please refer to the communication matrix for specific default data.

[0191] Name: open can

[0192] Open CAN request

[0193]

[0194]

[0195] 7. Send CAN data

[0196] Request / Response TOPIC: tbox sends the topic TOPIC: mqtt / ota_master / can_write; OTAmaster sends the topic TOPIC: mqtt / tbox / can_write; Name: Sending CAN data.

[0197] Send CAN data request

[0198]

[0199]

[0200] 8. Accept CAN data

[0201] The request response TOPIC sent by the tbox is for the following topic: TOPIC: mqtt / ota_master / can_read Name: Accepts CAN data

[0202] Accept CAN data

[0203]

[0204]

[0205] 9. Turn off CAN

[0206] Request / Response TOPIC: tbox sends the topic TOPIC: mqtt / ota_master / can_close; OTAmaster sends the topic TOPIC: mqtt / tbox / can_close; Name: close can

[0207] Disable CAN request

[0208]

[0209]

[0210] This application provides an OTA control method, system, and computer-readable storage medium. Compared with current OTA systems, which often have close dependencies on various hardware components of the vehicle at multiple levels, making traditional OTA system updates complex, costly, and inefficient, this application offers the following advantages:

[0211] Firstly, the system receives control commands from an OTA server that is bidirectionally connected to the OTA master; parses the control commands to determine the target ECU and control operation; and calls the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware services to the OTA master. Through modular development of the OTA master, the OTA master interacts with the in-vehicle communication device through clear interfaces and protocols, reducing the coupling between the OTA software and hardware. This also enhances the scalability of the OTA system, enabling rapid adaptation to the integration of new technologies and functions, and reducing maintenance costs.

[0212] Secondly, the OTA master includes multiple built-in interfaces that correspond to and are compatible with various hardware services provided by the in-vehicle communication device. Different hardware can support the same interfaces, ensuring the software continues to function correctly even if the hardware changes, thus improving software compatibility. Furthermore, it eliminates the need to redevelop OTA functionality, reducing development costs.

[0213] Thirdly, the vehicle communication device responds to the service request, invokes the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU. The modular design also makes OTA functionality easier to port to different hardware platforms; in implementing OTA functionality, there is no need to focus too much on the vehicle communication device's handling of service requests.

[0214] Based on the same concept as the methods described above, this application also proposes an OTA control device, such as... Figure 3 As shown.

[0215] The device includes:

[0216] The instruction receiving module 402 is used to receive control instructions sent by the OTA server, which is bidirectionally connected to the OTA master;

[0217] The instruction parsing module 404 is used to parse the control instructions and determine the target ECU and control operation;

[0218] The service call module 406 is used to call the interface corresponding to the control operation, send a service request to the vehicle communication device that provides hardware services for the OTA master, so that the vehicle communication device responds to the service request, calls the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU;

[0219] The OTA master has multiple built-in interfaces that correspond to and are adapted to multiple hardware services provided by the vehicle communication device.

[0220] The specific implementation process of the functions and roles of each module / submodule / unit in the above device can be found in the implementation process of the corresponding steps in the above method, which can achieve the same technical effect, and will not be repeated here.

[0221] Figure 4 An example is a schematic diagram of the physical structure of an OTA control device, such as... Figure 4 As shown, the OTA control device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840. The processor 810, communication interface 820, and memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions from the memory 830 to execute the OTA control method.

[0222] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0223] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to execute the OTA control method provided by the above methods.

[0224] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the OTA control methods provided by the above methods.

[0225] It should be noted that the technical solutions or features described in the above embodiments can be combined or supplemented with each other without conflict. The scope of protection of this application is not limited to the precise structures described in the above embodiments and shown in the accompanying drawings; all modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An over-the-air (OTA) download control method, characterized in that, Applied to OTA master, the method includes: Receive control commands sent by the OTA server, which is bidirectionally connected to the OTA master; The control commands are parsed to determine the target ECU and the control operation; The process involves calling the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware services to the OTA master. This causes the in-vehicle communication device to respond to the service request, invoke the hardware resources required for the service request, execute the control operation, and send the control command to the target ECU to complete the control of the target ECU. The control operation refers to the operation of invoking the hardware resources of the in-vehicle communication device when implementing the control command. The hardware resources include at least a CAN channel and a diagnostic channel. Calling the interface corresponding to the control operation to send the service request to the in-vehicle communication device that provides hardware services to the OTA master includes: determining whether the in-vehicle communication device supports the communication protocol format of the OTA master; if supported, calling the interface to send the service request to the in-vehicle communication device that provides hardware resources to the OTA master. The OTA master has multiple built-in interfaces that are adapted to the various hardware services provided by the vehicle communication device.

2. The OTA control method as described in claim 1, characterized in that, The method further includes: If not supported, the interface is invoked to send a service request to the vehicle communication device that provides hardware resources to the OTA master through a preset communication protocol, wherein the preset communication protocol is a communication protocol format supported by the vehicle communication device.

3. The OTA control method as described in claim 2, characterized in that, The preset communication protocol includes the MQTT protocol. The architecture of the MQTT protocol includes an MQTT server and an MQTT client. The MQTT server establishes a bidirectional communication connection with the OTA master, the MQTT server establishes a bidirectional communication connection with the MQTT client, and the MQTT client establishes a bidirectional communication connection with the communication module of the vehicle communication device. The step of calling the interface and sending a service request to the in-vehicle communication device that provides hardware resources to the OTA master via a preset communication protocol includes: The interface is invoked to forward the service request to the MQTT client through the MQTT server, so that the MQTT client can pass it to the communication module of the vehicle communication device, and the communication module can respond to the service request.

4. The OTA control method as described in claim 1, characterized in that, The vehicle-mounted communication equipment includes any one of a T-BOX, a vehicle-mounted gateway, or a domain controller.

5. A vehicle-mounted communication device, characterized in that, The vehicle-mounted communication device integrates a modular OTA master, and the OTA master communicates bidirectionally with the communication module of the vehicle-mounted communication device. The OTA master receives control commands from an OTA server with which it has a bidirectional communication connection; parses the control commands to determine the target ECU and the control operation; calls the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware resources to the OTA master, so that the in-vehicle communication device responds to the service request, calls the hardware resources required by the service request, executes the control operation, and sends the control command to the target ECU to complete the control of the target ECU; wherein the OTA master has multiple interfaces built-in that are adapted to multiple hardware services provided by the in-vehicle communication device, and the control operation refers to the operation of the hardware resources of the in-vehicle communication device invoked when implementing the control command; the hardware resources include at least a CAN channel and a diagnostic channel; calling the interface corresponding to the control operation to send a service request to the in-vehicle communication device that provides hardware resources to the OTA master includes: determining whether the in-vehicle communication device supports the communication protocol format of the OTA master; if it supports it, calling the interface to send a service request to the in-vehicle communication device that provides hardware resources to the OTA master.

6. The vehicle-mounted communication device as described in claim 5, characterized in that, The vehicle-mounted communication device also integrates an MQTT client, which establishes a bidirectional communication connection with the MQTT server in the cloud. The MQTT server communicates bidirectionally with the OTA master, and the MQTT server is used to forward the service requests of the OTA master to the MQTT client. The MQTT client has a bidirectional communication connection with the communication module of the vehicle communication device. The MQTT client sends the service request to the communication module to access the hardware resources of the vehicle communication device.

7. The vehicle-mounted communication device as described in claim 6, characterized in that, The vehicle-mounted communication device also integrates an MQTT client and an MQTT server.

8. An OTA system, characterized in that, The system includes: OTA server stores control commands used to control the target ECU; The vehicle communication device as described in any one of claims 5-7 is used to provide hardware services for OTA (Over-The-Air). The vehicle communication device integrates a modular OTA master, which is configured with multiple interfaces that are adapted to multiple hardware services. The hardware resources required by the control command are called through the interfaces. The hardware resources include at least a CAN channel and a diagnostic channel. The target ECU communicates bidirectionally with the vehicle communication device, receives the control commands sent by the vehicle communication device, and responds to the control commands.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an OTA control program, which, when executed, implements the steps of the OTA control method as described in any one of claims 1-4.

Images