OTA control method and system and computer readable storage medium

Abstract

The invention provides an OTA control method and system and a computer readable storage medium. The method comprises the following steps: receiving a control instruction sent by an OTA server in bidirectional communication connection with an OTA master; analyzing the control instruction, and determining a target ECU and a control operation; and calling an interface corresponding to the control operation, and sending a service request to the vehicle-mounted communication equipment which provides the hardware service for the OTA master. And sending the service request to the vehicle-mounted communication equipment, so that the vehicle-mounted communication equipment responds to the service request, calls hardware resources required by the service request, executes control operation and sends a control instruction to the target ECU to complete control of the target ECU. According to the invention, through the modularized development of the OTA master, the OTA master interacts with the vehicle-mounted communication equipment through a clear interface and a protocol, the coupling degree between OTA software and hardware is reduced, integration of a new technology and a new function can be rapidly adapted, and the maintenance cost is reduced.

Description

Technical Field

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

[0002] With the digital transformation of the automotive industry, smart connected cars are becoming increasingly popular. 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 systems are often tightly coupled with hardware. When performing software updates, specific hardware characteristics and limitations need to be fully considered. This requires that the update program must be customized and tested for these specific hardware, which increases the complexity of the update. In addition, in the subsequent maintenance process of OTA system development, it is also necessary to pay attention to changes in software and hardware at the same time. Once the hardware is adjusted, the OTA system may need to be modified accordingly, increasing maintenance costs. At the same time, when the hardware needs to be upgraded, the tightly coupled OTA system may limit the flexibility of hardware upgrades and also increase the cost of hardware upgrades. Furthermore, when updating tightly coupled OTA systems, comprehensive hardware testing and adaptation are often required, which will cause the update process to take a long time, especially in large-scale deployments, such as OTA updates for a large number of cars or smart devices. The extension of the update time will have a greater impact on the user experience and the normal use of the device.

[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 the related art, this specification provides an OTA control method, system and computer-readable storage medium.

[0006] According to a first aspect of an embodiment of this specification, an OTA control method is provided, which is applied to an OTA master. The method includes:

[0007] Receiving a control instruction sent by an OTA server in bidirectional communication with the OTA master;

[0008] Parsing the control instruction to determine the target ECU and the control operation;

[0009] Calling the interface corresponding to the control operation, sending a service request to the in-vehicle communication device that provides hardware services for the OTA master, so that the in-vehicle communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instruction to the target ECU, so as to complete the control of the target ECU;

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

[0011] According to an OTA control method provided by the present application, 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] Determining whether the in-vehicle communication device supports the communication protocol format of the OTA master;

[0013] If supported, the interface is called 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 by the present application, the method further includes:

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

[0016] According to an OTA control method provided by the present application, the preset communication protocol includes an MQTT protocol, the architecture of the MQTT protocol includes an MQTT server and an MQTT client, the MQTT server is bidirectionally connected to the OTA master, the MQTT server is bidirectionally connected to the MQTT client, and the MQTT client is bidirectionally connected to the communication module of the vehicle-mounted communication device;

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

[0018] The interface is called, and the service request is forwarded to the mqtt client through the mqtt server, so that the mqtt client passes it to the communication module of the vehicle-mounted communication device, and responds to the service request through the communication module.

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

[0020] The present application also provides an in-vehicle communication device, wherein the in-vehicle communication device is integrated with a modular OTA master, and the OTA master communicates bidirectionally with a communication module of the in-vehicle communication device;

[0021] Among them, the OTA master is used to receive control instructions sent by an OTA server that is bidirectionally connected to the OTA master; parse the control instructions to determine the target ECU and the control operation; call the interface corresponding to the control operation, and send a service request to the vehicle communication device that provides hardware resources for the OTA master, so that the vehicle communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instructions to the target ECU to complete the control of the target ECU; Among them, the OTA master has built-in definitions of multiple interfaces that correspond to multiple hardware services provided by the vehicle communication device.

[0022] According to a vehicle-mounted communication device provided by the present application, the vehicle-mounted communication device is also integrated with an MQTT client, and the MQTT client is connected to the MQTT server in the cloud for two-way communication;

[0023] The mqtt server performs two-way communication with the OTA master, and the mqtt server is used to forward the service request of the OTA master to the mqtt client;

[0024] The mqtt client is bidirectionally connected to the communication module of the vehicle-mounted communication device, and the mqtt client sends the service request to the communication module to retrieve the hardware resources of the vehicle-mounted communication device.

[0025] According to a vehicle-mounted communication device provided by the present application, the vehicle-mounted communication device also integrates an MQTT client and an MQTT server.

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

[0027] OTA server, storing control instructions for controlling the target ECU;

[0028] An in-vehicle communication device, used to provide hardware services for OTA, wherein a modular OTA master is integrated in the in-vehicle communication device, and the OTA master is configured with multiple interfaces corresponding to multiple hardware services, and the hardware resources required for the control instruction are called through the interfaces;

[0029] The target ECU performs two-way communication with the vehicle-mounted communication device, receives the control instruction sent by the vehicle-mounted communication device, and responds to the control instruction.

[0030] The present application also provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the OTA control method as described above is implemented.

[0031] The OTA control method, system and computer-readable storage medium in the embodiments of this specification have the following beneficial effects compared with the current OTA system, which often has a close dependency relationship with various hardware components of the vehicle at multiple levels, making the traditional OTA system update complex, costly and inefficient:

[0032] On the one hand, it receives control instructions sent by the OTA server that is connected to the OTA master in a two-way communication; parses the control instructions to determine the target ECU and control operation; calls the interface corresponding to the control operation and sends a service request to the vehicle communication device that provides hardware services for the OTA master. Through the modular development of the OTA master, the OTA master and the vehicle communication device interact through clear interfaces and protocols, reducing the coupling between OTA software and hardware. At the same time, it enhances the scalability of the OTA system, can quickly adapt to the integration of new technologies and new functions, and reduces maintenance costs.

[0033] Secondly, the OTA master has built-in definitions of multiple interfaces that correspond to multiple hardware services provided by the vehicle-mounted communication device. Different hardware can support the same interface, so that even if the hardware changes, the software can still run normally, which improves the compatibility of the software. There is no need to redevelop the OTA function, which reduces the development cost.

[0034] Thirdly, the vehicle-mounted communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instruction to the target ECU to complete the control of the target ECU. The modular design also makes it easier to transplant the OTA function to different hardware platforms. In implementing the OTA function, there is no need to pay too much attention to the processing of the service request by the vehicle-mounted communication device.

[0035] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 1 is a schematic diagram of an OTA system according to an exemplary embodiment of the present specification;

[0038] Figure 2 is a flowchart of an OTA control method according to an exemplary embodiment of the present specification;

[0039] Figure 3 is a schematic diagram of an OTA control device according to an exemplary embodiment of the present specification;

[0040] Figure 4 It is a schematic block diagram of an OTA control device shown in this specification according to an exemplary embodiment. DETAILED DESCRIPTION

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

[0042] If there are terms involving directional indications or positional relationships in the embodiments of the present application (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 relationship, movement, etc. between the components under a certain specific posture (as shown in the accompanying drawings); if the specific posture changes, the directional indication or positional relationship will also change accordingly. In addition, the terms "first", "second", etc. involved in the embodiments of the present application are only used for the purpose of convenience of description and cannot be understood as indicating or implying relative importance.

[0043] The present application provides an OTA control method, system and computer-readable storage medium. The present application is described in detail below in conjunction with the accompanying drawings. The features of the following embodiments and implementations can be combined with each other without conflict.

[0044] With the digital transformation of the automotive industry, smart connected cars are becoming increasingly popular. 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, making updates complex, costly and inefficient.

[0046] In order to solve the above technical problems, this specification provides an OTA software architecture.

[0047] By modularizing the OTA function and calling the relevant hardware resources according to the preset functional protocol, the separation of OTA software and hardware is achieved. This makes the OTA software function development no longer restricted by hardware. The two can be developed, tested and upgraded independently to achieve more efficient, secure and flexible software upgrades.

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

[0049] The embodiment of this specification provides a vehicle-mounted communication device, which is integrated with a modular OTA master (OTA device), and includes a communication module for bidirectional communication with a controlled object in the vehicle, and the communication module communicates bidirectionally with the OTA master. The controlled object refers to a component in the vehicle that needs to update the software version, fix security vulnerabilities, or improve user experience, which requires OTA control, and may include but is not limited to the ECU and transmitter controller in the vehicle, etc. The following takes the ECU as an example for explanation.

[0050] In some embodiments, OTA master refers to an OTA functional module that is responsible for the entire OTA control upgrade work, such as receiving control instructions such as upgrade instructions from an OTA server, communicating with different ECUs in the vehicle, managing the upgrade process, handling errors, etc.

[0051] The OTA master is developed separately, and multiple common interfaces are defined in the OTA master. The interfaces are adapted to multiple hardware services provided by the vehicle communication device, so as to call the hardware resources of the vehicle communication device through the interfaces and realize the corresponding functions of OTA.

[0052] In the process of defining a common interface, a set of common interface specifications is formulated for the interaction between the OTA master and the hardware. No matter how the hardware changes, as long as it conforms to this interface specification, the OTA master can communicate with it. This can reduce the dependence of OTA software on specific hardware.

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

[0054] At the same time, the OTA master is verified and tested. For example, the OTA master is tested for functionality, performance, and compatibility. If the test passes, it means that the OTA master can operate normally.

[0055] In other examples, the OTA master is further subdivided into different modules according to its functions, including but not limited to a command parsing module, a communication module, a verification module, etc. Different modules are developed independently, and the communication interfaces between the modules are defined to realize the functions of the OTA master and the communication between the OTA master and the vehicle-mounted communication device.

[0056] In some embodiments, the vehicle-mounted communication device provides basic hardware services for the OTA function module OTA master to ensure that the OTA master function can run normally and be implemented. The vehicle-mounted communication equipment may include but is not limited to the vehicle-mounted telematics processor T-BOX, the vehicle-mounted gateway, the domain controller, etc. For example, the vehicle-mounted gateway: As the core node of the vehicle network, the vehicle-mounted gateway can integrate the OTA function module and be responsible for managing the software upgrades of each ECU in the vehicle. Another example is T-BOX, which is mainly responsible for the remote communication between the vehicle and the outside, realizing remote monitoring, diagnosis, software upgrades and other functions, and can interact with the ECU in the vehicle to a certain extent through a specific communication protocol. For another example, an intelligent vehicle-mounted terminal, such as a domain controller of a vehicle-mounted entertainment system, has processing capabilities and storage resources, and can integrate OTA function modules to realize the upgrade of its own software and the coordinated upgrade with other ECUs.

[0057] Carry out separate development and module verification of vehicle communication equipment to determine the basic hardware service capabilities of vehicle communication equipment. For example, perform hardware testing, communication testing, stability testing, etc. on vehicle communication equipment to ensure that each module can meet the design requirements when running independently.

[0058] In the early stages of project development, the OTA master and the vehicle communication equipment can be developed independently or simultaneously, and different development teams can focus on their respective modules, which can improve development efficiency. At the same time, during the development process, the OTA master and the vehicle communication equipment are verified and tested as individual modules.

[0059] When the OTA master and the vehicle communication device have passed their own tests, the OTA master is deployed to the vehicle communication device for integration testing. The purpose of the integration test is to verify whether each module can operate normally when working together, and whether there are compatibility issues, performance issues or functional defects. Through integration testing, the stability and reliability of the entire system can be ensured.

[0060] The integrated OTA master is used to receive control instructions sent by the OTA server that is connected to the OTA master in a two-way communication; parse the control instructions to determine the target ECU and control operation; call the interface corresponding to the control operation, and send a service request to the vehicle communication device that provides hardware resources for the OTA master, so that the vehicle communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instruction to the target ECU to complete the control of the target ECU; among them, the OTA master has built-in definitions of multiple interfaces that correspond to multiple hardware services provided by the vehicle communication device. The control of the target ECU is achieved through this process, where the control includes but is not limited to updating vehicle software, repairing security vulnerabilities, etc. This process will be described in detail in the following chapters.

[0061] Since OTA master is developed as an independent module, it is relatively independent of the specific hardware platform (such as vehicle communication equipment), and only needs some adaptive adjustments and configurations to run on different hardware. In this way, there is no need to redevelop OTA master, which can greatly reduce the development cycle and development cost of new products.

[0062] Therefore, in this embodiment, the OTA master developed through a modular development method decouples the OTA software from the hardware, and can be easily ported to different hardware platforms later, thereby achieving more efficient, secure and flexible software upgrades.

[0063] In other embodiments, the OTA master performs two-way communication with an existing communication module in the vehicle communication device to send control instructions received from the OTA server to the communication module, and calls hardware resources of the vehicle communication device to control the target ECU.

[0064] In actual use, the communication method between OTAmaster and the original communication module in the vehicle communication equipment is set according to the properties of the vehicle communication equipment, communication requirements, network environment and other factors. It can be but not limited to the MQTT protocol, HTTP protocol, and the communication channel of the communication module of the vehicle communication equipment, thereby forming a variety of vehicle communication equipment.

[0065] As an example, the OTA master interacts with the communication module of the vehicle-mounted communication device through the MQTT protocol. The vehicle-mounted communication device is integrated with the OTA master and the MQTT client, and the MQTT client is connected to the MQTT server in the cloud for two-way communication.

[0066] The mqtt server performs two-way communication with the OTA master, and the mqtt server is used to forward the service request of the OTA master to the mqtt client; the mqtt client is connected to the communication module of the vehicle-mounted communication device for two-way communication, and the mqtt client sends the service request to the communication module to retrieve the hardware resources of the vehicle-mounted communication device.

[0067] Among them, the MQTT protocol (Message Queuing Telemetry Transport) is a lightweight message publish / subscribe protocol that is widely used in the field of Internet of Things. In this solution, the OTA master interacts with the communication module of the vehicle-mounted communication device through the MQTT server. For example, the OTA master can publish upgrade instructions and status information to the MQTT server. The vehicle-mounted communication device can also act as an MQTT client, subscribe to relevant topics, and receive instructions and information from the OTAmaster. At the same time, the vehicle-mounted communication device can publish the vehicle's status information to the MQTT server for the OTA master to subscribe and obtain. Interacting through the MQTT server can achieve a loosely coupled communication method and improve the flexibility and scalability of the system.

[0068] As another example, the OTA master interacts with the communication module of the vehicle-mounted communication device through the MQTT protocol. The vehicle-mounted communication device is integrated with the OTA master, the MQTT client and the MQTT server, and the MQTT server communicates bidirectionally with the OTA master and the MQTT client respectively.

[0069] For example, when the controlled ECU (electronic control unit) needs to be upgraded, the OTA master accesses the hardware resources of the vehicle communication device through a predefined interface.

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

[0071] When the target ECU needs to be controlled, the OTA master directly accesses the hardware resources of the vehicle communication device through a pre-defined interface to implement the OTA function. The hardware resources include but are not limited to network connection resources, storage resources, etc. When controlling the target ECU, the OTA master transmits the control command to the target ECU through the CNA bus of the vehicle communication device, so that the target ECU responds to the control command after receiving the control command. If the control command is an upgrade command, the target ECU starts the software upgrade process after receiving the upgrade command, which may include steps such as verifying the update package, backing up the old version of the software, and installing the new version of the software.

[0072] As another example, the OTA master and the communication module of the vehicle communication device communicate bidirectionally via the http protocol. Accordingly, an interface based on the http protocol is defined for the OTA master to access the hardware resources of the vehicle communication device via the defined interface.

[0073] In this embodiment, the realization of the OTA function involves the collaborative work of multiple links and devices. The selection and use of the interface protocol need to comprehensively consider various factors. The corresponding communication protocol can be selected based on, but not limited to, whether the in-vehicle communication device supports the interface protocol format of the OTA master.

[0074] An OTA system provided in an embodiment of the present specification includes:

[0075] OTA server, storing control instructions for controlling the target ECU;

[0076] An in-vehicle communication device, used to provide hardware services for OTA, wherein a modular OTA master is integrated in the in-vehicle communication device, and the OTA master is configured with multiple interfaces corresponding to multiple hardware services, and the hardware resources required for the control instruction are called through the interfaces;

[0077] The target ECU performs two-way communication with the vehicle-mounted communication device, receives the control instruction sent by the vehicle-mounted communication device, and responds to the control instruction.

[0078] The following is a detailed description of the example in which the vehicle-mounted communication device is T-BOX, the controlled object is the vehicle's ECU, and the OTA master and the communication module of the vehicle-mounted communication device use the MQTT protocol for two-way communication.

[0079] In some embodiments, reference Figure 1 The OTA system includes an OTA server, T-BOX, and a target ECU. The OTA server and 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", and "can" usually refers to "Controller Area Network".

[0080] After the OTA master, mqtt server, and T-BOX basic functions are deployed on the T-BOX hardware, the system initialization is completed and each module is in a ready state. This allows the corresponding target ECU to be controlled according to the control instructions issued by the OTA server, so as to achieve the OTA software functions of keeping the vehicle software up to date, fixing security vulnerabilities, and improving user experience.

[0081] Based on the above-mentioned vehicle-mounted communication device and OTA system, an OTA control is provided in an embodiment of this specification.

[0082] Reference Figure 2 , Figure 2 A flowchart of an OTA control method is shown in FIG.

[0083] The method comprises the following steps:

[0084] S100, receiving a control instruction sent by an OTA server that is in bidirectional communication connection with the OTA master.

[0085] OTA Server

[0086] The control instructions described in this article refer to instructions for controlling a controlled object (such as a vehicle's ECU) through OTA, including but not limited to software upgrade instructions, fault diagnosis instructions, etc.

[0087] As an example, when the OTA server detects that a new software version is applicable to an ECU of a vehicle or device to which the on-board communication device that provides hardware resources for the OTA function belongs, it generates a control instruction and sends the control instruction to the on-board communication device of the target vehicle.

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

[0089] The control instruction includes but is not limited to the download address of the upgrade package, the target ECU identifier, verification information, etc.

[0090] For the in-vehicle communication equipment integrated with the modular OTA master, the OTA master communicates with the OTA server in a two-way manner. The OTA server sends control instructions to the vehicle's T-BOX through the mobile network or other remote communication methods (such as the http protocol), and the OTA master on the T-BOX receives the control instructions sent by the OTA server.

[0091] S200, parsing the control instruction to determine the target ECU and the control operation.

[0092] T-BOX receives control instructions from the OTA server, and parses the control instructions through the OTA master to determine the target ECU to be controlled and the control operation corresponding to the control instruction. The control operation refers to the operation of the T-BOX hardware resources called when implementing the control instruction. For example, opening the CAN channel to send the upgrade package and receive the upgrade result in response to the upgrade instruction.

[0093] S300, calling the interface corresponding to the control operation, sending a service request to the in-vehicle communication device that provides hardware services for the OTA master, so that the in-vehicle communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instruction to the target ECU, so as to complete the control of the target ECU;

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

[0095] Customize or standardize the interface protocol for the OTA master to call the basic services of the vehicle communication device. For example, a set of APIs (Application Programming Interface) can be defined, and the OTA master uses these APIs to call the vehicle communication device's services such as opening / closing / CAN / channel, sending / receiving / CAN / data, etc.

[0096] Continuing with the above example, when the in-vehicle communication device is T-BOX, the basic services provided by T-BOX include but are not limited to opening / closing CAN channels, receiving / sending CAN data, service requests, heartbeats, opening / closing diagnostic channels, receiving / sending diagnostic data, etc. Multiple interfaces that are compatible with these hardware services are defined in the OTA master, and the hardware services of T-BOX are called according to the interface protocol of the interface. Exemplarily, the control operation corresponding to the control instruction is to open the CAN channel. A function interface named "openCanChannel()" is defined on the OTA master. The OTA master calls this interface when it needs to open the CAN channel. After receiving this call request, the relevant modules inside the T-BOX execute the operation of opening the CAN channel and return the operation result to the OTA master.

[0097] The OTA master sends a service request to the T-BOX through a specific communication method (such as an internal communication bus or network connection). This request may contain a specific command code and parameters. The command code indicates that the CAN channel needs to be opened, and the parameters may include information such as the target ECU's identification.

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

[0099] After the CAN channel is opened, the OTA master obtains the upgrade package from the storage location (which can be the local storage of the T-BOX or downloaded from the OTA server in real time). The OTA master sends the upgrade package to the target ECU through the CAN channel. The data format and communication rules of the CAN protocol are followed during the sending process.

[0100] The target ECU receives the upgrade package and performs the upgrade operation. After the upgrade is completed, the target ECU sends the upgrade result message to the T-BOX through the CAN channel. The CAN channel module of the T-BOX receives the upgrade result message from the ECU and forwards it to the OTAmaster. The OTA master feeds back the upgrade result to the OTA server through the communication connection with the OTA server. The feedback message can contain information such as the upgrade status, timestamp, error code (if any), etc.

[0101] In some embodiments, 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:

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

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

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

[0105] The preset communication protocol includes the MQTT protocol, and the architecture of the MQTT protocol includes an MQTT server and an MQTT client. Figure 1 As shown, the mqtt server is connected to the OTA master for bidirectional communication, the mqtt server is connected to the mqtt client for bidirectional communication, and the mqtt client is connected to the communication module of the vehicle-mounted communication device for bidirectional communication.

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

[0107] The interface is called, and the service request is forwarded to the mqtt client through the mqtt server, so that the mqtt client passes it to the communication module of the vehicle-mounted communication device, and responds to the service request through the communication module.

[0108] In this embodiment, better decoupling can be achieved by interacting through the MQTT server. This makes OTAmaster and other functional modules of T-BOX relatively independent, which is convenient for development, testing and maintenance. For example, if there is a problem with other functional modules of T-BOX, it will not directly affect the operation of OTA master, and vice versa.

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

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

[0111] Reply timeout settings:

[0112] After sending a message, if there is no reply within the timeout period, it will time out. After the timeout, it needs to be resent. Unless otherwise specified, the timeout time and the number of repetitions are implemented according to the following data. Among them, the timeout time is 3s and the number of timeout retransmissions is 3.

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

[0114] As an example, T-BOX provides the OTA master with a hardware service for opening / closing the CAN channel.

[0115] When the OTA master receives an upgrade instruction and needs to communicate with the target ECU, it sends a request to the T-BOX to open the CAN channel. After receiving the request, the T-BOX opens the corresponding CAN channel and feeds back the information that the channel has been opened to the OTA master. The OTA master can send upgrade instructions and data to the target ECU through the CAN channel.

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

[0117] Request response TOPIC:

[0118] Topic sent by T-BOX: mqtt / ota_master / can_open

[0119] Topic TOPIC sent by OTA master: mqtt / tbox / can_open

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

[0121]

[0122] T-BOX is responsible for receiving data from the target ECU on the CAN bus and forwarding it to the OTA master. At the same time, T-BOX can also send data to the target ECU on the CAN bus according to the request of the OTA master.

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

[0124]

[0125]

[0126] As an example, T-BOX provides a hardware service for sending a heartbeat signal to the OTA master, and determines whether the OTA master is working normally according to the heartbeat signal of the OTA master.

[0127] Specifically, the protocol for calling the interface of the hardware resource that sends the OTA master heartbeat signal is as follows:

[0128] Request response TOPIC:

[0129] Topic TOPIC sent by OTA master: mqtt / ota_slave / heart_beat

[0130] Sending cycle: 5 seconds to send once

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

[0132] T-BOX does not require a reply

[0133] Send heartbeat data:

[0134] {

[0135] "sequenceId": "xxxxxx", / / unique identifier of the request, initialized by the requester

[0136] }

[0137] As an example, T-BOX provides hardware services for OTA master to read / set data. The interface protocol example is as follows:

[0138] Request response TOPIC:

[0139] Topic sent by T-BOX: mqtt / ota_master / read_tbox_data

[0140] Topic TOPIC sent by OTA master: mqtt / tbox / read_tbox_data

[0141] Read / Set Data Request:

[0142]

[0143]

[0144] By customizing or standardizing the interface protocol for OTA master to call T-BOX basic services, the development of OTA functionality can be realized. The developed OTA master can be easily ported to different hardware at a later stage without the need for redevelopment. The parameters of the OTA architecture can be modified according to the properties of the hardware. This includes but is not limited to adjustments in hardware adaptation, software adaptation, communication adaptation, and other aspects. For example, the hardware interface is adapted according to the characteristics of the new hardware. For example, the communication interface of the new hardware (such as Ethernet, CAN bus, etc.) may be different from that of T-BOX, and the communication parameters and driver need to be reconfigured. For another example, if the new hardware communicates differently with the external system, the communication method of the OTA master needs to be adjusted to adapt to the new communication protocol and network environment.

[0145] As an example, based on the OTA system provided by this application, the OTA master is modularly developed based on the following protocol, so that the OTA master is no longer strongly bound to the hardware and can be equipped with T-BOXs of different brands. For ease of understanding, the OTA control method is fully described by taking the OTA master calling T-BOX diagnosis for data transmission and reception as an example.

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

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

[0148] OTA master sends an mqtt request to obtain the UDS network segment where the controller is located, and T-BOX adds relevant information in the reply result

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

[0150] OTA master sends an mqtt request to open the UDS protocol stack based on the query result in the previous step, and T-BOX replies with the opening 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 T-BOX will reply whether the sending is successful or not.

[0153] Step 4: Query diagnostic response

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

[0155] Step 5: Close the network segment where the diagnosed controller is located

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

[0157] The specific process is as follows:

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

[0159] Request response TOPIC Topic TOPIC sent by tbox: mqtt / ota_master / uds_get_net_name Topic TOPIC sent by OTA master: mqtt / tbox / uds_get_net_name Name: Get UDS network segment name

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

[0161]

[0162]

[0163] 2. Open the UDS protocol stack

[0164] Request Response TOPIC

[0165] Topic TOPIC sent by tbox: mqtt / ota_master / uds_open_client

[0166] Topic TOPIC sent by OTA master: mqtt / tbox / uds_open_client

[0167] Master exception handling:

[0168] After detecting the abnormal heartbeat of the Master, TBOX will actively close all opened UDS protocol stacks.

[0169] Name: Open UDS protocol stack

[0170] Send a request to open the UDS protocol stack

[0171]

[0172]

[0173] 3. Close the UDS protocol stack

[0174] Request response TOPIC Topic TOPIC sent by tbox: mqtt / ota_master / uds_shut_client Topic TOPIC sent by OTAmaster: mqtt / tbox / uds_shut_client Send a request to shut down the UDS protocol stack

[0175]

[0176] 4. Send UDS data

[0177] Request response TOPIC Topic sent by tbox: mqtt / ota_master / uds_diag_write Topic sent by OTAmaster: mqtt / tbox / uds_diag_write Name: Send UDS uds data sending request

[0178]

[0179]

[0180] 5. Read UDS data

[0181] Request response TOPIC Topic sent by tbox: mqtt / ota_master / uds_diag_read Topic sent by OTAmaster: mqtt / tbox / uds_diag_read Name: Read UDS

[0182] Read UDS data request

[0183]

[0184]

[0185] 6. Open CAN

[0186] Request Response TOPIC

[0187] Topic TOPIC sent by tbox: mqtt / ota_master / can_open

[0188] Topic TOPIC sent by OTA master: mqtt / tbox / can_open

[0189] Master exception handling:

[0190] After detecting the abnormal heartbeat of the Master, TBOX will actively close all opened CAN channels and restore the periodic message data to the default data. For specific default data, please refer to the communication matrix.

[0191] Name:open can

[0192] Open CAN request

[0193]

[0194]

[0195] 7. Send CAN data

[0196] Request response TOPIC Topic sent by tbox: mqtt / ota_master / can_write Topic sent by OTAmaster: mqtt / tbox / can_write Name: Send CAN data

[0197] Send CAN data request

[0198]

[0199]

[0200] 8. Receive CAN data

[0201] Request response TOPIC Topic sent by tbox: mqtt / ota_master / can_read Name: Receive can data

[0202] Receive CAN data

[0203]

[0204]

[0205] 9. Turn off CAN

[0206] Request response TOPIC Topic sent by tbox: mqtt / ota_master / can_close Topic sent by OTAmaster: mqtt / tbox / can_close Name: close can

[0207] Disable CAN request

[0208]

[0209]

[0210] The present application provides an OTA control method, system and computer-readable storage medium, which have the following beneficial effects compared with the current OTA system, which often has a close dependency on multiple hardware components of the vehicle at multiple levels, making the traditional OTA system update complex, costly and inefficient:

[0211] On the one hand, it receives control instructions sent by the OTA server that is connected to the OTA master in a two-way communication; parses the control instructions to determine the target ECU and control operation; calls the interface corresponding to the control operation and sends a service request to the vehicle communication device that provides hardware services for the OTA master. Through the modular development of the OTA master, the OTA master and the vehicle communication device interact through clear interfaces and protocols, reducing the coupling between OTA software and hardware. At the same time, it enhances the scalability of the OTA system, can quickly adapt to the integration of new technologies and new functions, and reduces maintenance costs.

[0212] Secondly, the OTA master has built-in definitions of multiple interfaces that correspond to multiple hardware services provided by the vehicle-mounted communication device. Different hardware can support the same interface, so that even if the hardware changes, the software can still run normally, which improves the compatibility of the software. There is no need to redevelop the OTA function, which reduces the development cost.

[0213] Thirdly, the vehicle-mounted communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instruction to the target ECU to complete the control of the target ECU. The modular design also makes it easier to transplant the OTA function to different hardware platforms. In implementing the OTA function, there is no need to pay too much attention to the processing of the service request by the vehicle-mounted communication device.

[0214] Based on the same application concept as the above method, the embodiment of the present application also proposes an OTA control device, such as Figure 3 shown.

[0215] The device comprises:

[0216] An instruction receiving module 402 is used to receive a control instruction sent by an OTA server connected to the OTA master for bidirectional communication;

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

[0218] The service calling 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 instruction to the target ECU to complete the control of the target ECU;

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

[0220] The implementation process of the functions and effects of each module / submodule / unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and the same technical effect can be achieved, so it will not be repeated here.

[0221] Figure 4 An example of a physical structure diagram of an OTA control device is shown below. 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, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the OTA control method.

[0222] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

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

[0224] On the other hand, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which is implemented when the computer program is executed by a processor to execute the OTA control method provided by the above methods.

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

Claims

1. An over-the-air download OTA control method, characterized in that: Applied to OTA master, the method includes: Receiving a control instruction sent by an OTA server in bidirectional communication with the OTA master; Parsing the control instruction to determine the target ECU and the control operation; Calling the interface corresponding to the control operation, sending a service request to the in-vehicle communication device that provides hardware services for the OTA master, so that the in-vehicle communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instruction to the target ECU, so as to complete the control of the target ECU; The OTA master has built-in definitions of multiple interfaces that are adapted to multiple hardware services provided by the in-vehicle communication device.

2. The OTA control method according to claim 1, characterized in that: The calling of the interface corresponding to the control operation to send a service request to the in-vehicle communication device providing hardware services for the OTA master includes: Determining whether the in-vehicle communication device supports the communication protocol format of the OTA master; If supported, the interface is called to send a service request to the in-vehicle communication device that provides hardware resources for the OTA master.

3. The OTA control method according to claim 2, characterized in that: The method further comprises: If it is not supported, the interface is called to send a service request to the vehicle-mounted communication device that provides hardware resources to the OTAmaster through a preset communication protocol, and the preset communication protocol is a communication protocol format supported by the vehicle-mounted communication device.

4. The OTA control method according to claim 3, characterized in that: The preset communication protocol includes an mqtt protocol, the architecture of the mqtt protocol includes an mqtt server and an mqtt client, the mqtt server is connected to the OTAmaster in a two-way communication, the mqtt server is connected to the mqtt client in a two-way communication, and the mqtt client is connected to the communication module of the vehicle-mounted communication device in a two-way communication; The calling of the interface and sending a service request to the vehicle-mounted communication device that provides hardware resources to the OTAmaster through a preset communication protocol includes: The interface is called, and the service request is forwarded to the mqtt client through the mqtt server, so that the mqtt client passes it to the communication module of the vehicle-mounted communication device, and responds to the service request through the communication module.

5. The OTA control method according to claim 1, characterized in that: The vehicle-mounted communication equipment includes any one of a T-BOX, a vehicle-mounted gateway, and a domain controller.

6. A vehicle-mounted communication device, characterized in that: The vehicle-mounted communication device is integrated with a modular OTAmaster, and the OTAmaster communicates bidirectionally with the communication module of the vehicle-mounted communication device; Among them, the OTAmaster is used to receive control instructions sent by an OTA server that is bidirectionally connected to the OTA master; parse the control instructions to determine the target ECU and the control operation; call the interface corresponding to the control operation, and send a service request to the vehicle-mounted communication device that provides hardware resources for the OTA master, so that the vehicle-mounted communication device responds to the service request, calls the hardware resources required for the service request, executes the control operation and sends the control instructions to the target ECU to complete the control of the target ECU; Among them, the OTA master has built-in definitions of multiple interfaces that correspond to multiple hardware services provided by the vehicle-mounted communication device.

7. The vehicle-mounted communication device according to claim 6, characterized in that: The vehicle-mounted communication device is also integrated with an mqtt client, and the mqtt client is connected to the mqtt server in the cloud for two-way communication; The mqtt server performs two-way communication with the OTA master, and the mqtt server is used to forward the service request of the OTA master to the mqtt client; The mqtt client is bidirectionally connected to the communication module of the vehicle-mounted communication device, and the mqtt client sends the service request to the communication module to retrieve the hardware resources of the vehicle-mounted communication device.

8. The vehicle-mounted communication device according to claim 6, characterized in that: The vehicle-mounted communication device also integrates an MQTT client and an MQTT server.

9. An OTA system, characterized in that: The system comprises: OTA server, storing control instructions for controlling the target ECU; An in-vehicle communication device, used to provide hardware services for OTA, wherein a modular OTAmaster is integrated in the in-vehicle communication device, and the OTA master is configured with multiple interfaces corresponding to multiple hardware services, and the hardware resources required for the control instruction are called through the interfaces; The target ECU performs two-way communication with the vehicle-mounted communication device, receives the control instruction sent by the vehicle-mounted communication device, and responds to the control instruction.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores an OTA control program, and when the OTA control program is executed, the steps of the OTA control method according to any one of claims 1 to 5 are implemented.

Images