Software flashing method, device and vehicle
Patent Information
- Application Number
- CN202610876794.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-16
- Publication Date
- 2026-10-13
AI Technical Summary
[0005]本申请实施例的目的是提供一种软件刷写方法、设备和车辆,能够解决相关技术中的ECU软件刷写效率不佳的问题
[0010]本申请实施例提供的软件刷写方法,可以通过通用串行总线接口得到一个与车辆内容网络逻辑连通的高速数据传输路径,为刷写文件传输提供了高带宽的传输通道,从而能够提升刷写效率。并且采用双通道传输模式,通过控制器局域网总线发送升级指令,通过通用串行总线进行升级过程中升级请求、升级响应信息和刷写文件的传输,能够解决相关技术中单一通道难以兼顾实时控制与文件输出的矛盾,既能保障刷写文件的高速传输又能保障控制指令的实时发送,从而能够实现高效的电子控制单元的软件刷写。
Smart Images

Figure CN122903012A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of automotive electronics technology, specifically relating to a software flashing method, device, and vehicle. Background Technology
[0002] As the complexity of in-vehicle software increases, the frequency of software updates for electronic control units (ECUs) has increased significantly, making fast and reliable flashing processes crucial for ensuring vehicle functionality and safety.
[0003] Related technologies typically rely on DoCAN (Diagnostic Communication over Controller Area Network) or DoIP (Diagnostic Communication over Internet Protocol) for flashing, using the data transmission service within the diagnostic protocol to transfer the flash file. However, the DoCAN flashing method is limited by the inherently low bandwidth of the CAN bus (Controller Area Network), resulting in extremely long flashing times and poor flashing efficiency when transferring large flash files. In practical applications, DoIP technology requires eight cables for Gigabit Ethernet, but current standard OBD-II (On-Board Diagnostics II) diagnostic interfaces in vehicles typically only support 100M Ethernet, which also affects transmission bandwidth and thus limits flashing efficiency.
[0004] Therefore, how to provide a software flashing method that can meet the requirements of high flashing efficiency has become an urgent problem to be solved. Summary of the Invention
[0005] The purpose of this application is to provide a software flashing method, device, and vehicle that can solve the problem of poor ECU software flashing efficiency in related technologies.
[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a software flashing method applied to a vehicle, wherein the vehicle is connected to a diagnostic device via a Universal Serial Bus and a Controller Area Network (Controller Area Network) bus, and the method includes: In response to an upgrade command sent by the diagnostic device via the controller area network bus, the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, so that the diagnostic device responds to the upgrade request by returning upgrade response information via the universal serial bus; the upgrade response information includes the flashing file download address; The vehicle's electronic control unit obtains the corresponding flashing file through the universal serial bus according to the flashing file download address, and performs a software flashing operation based on the flashing file.
[0007] This application also provides a software flashing method for a diagnostic device connected to a vehicle via a Universal Serial Bus and a Controller Area Network (Controller Area Network) bus. The method includes: Upgrade commands are sent to the vehicle via the controller local area network bus; The diagnostic controller of the vehicle receives the upgrade request sent via the Universal Serial Bus in response to the upgrade command. In response to the upgrade request, upgrade response information is returned to the vehicle's diagnostic controller via the universal serial bus; the upgrade response information includes a flash file download address, which enables the vehicle's electronic control unit to download the corresponding flash file according to the flash file download address, and perform a software flashing operation based on the flash file.
[0008] In a second aspect, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.
[0009] Thirdly, embodiments of this application provide a vehicle that includes the electronic equipment described in the second aspect.
[0010] The software flashing method provided in this application embodiment can obtain a high-speed data transmission path logically connected to the vehicle's content network through a universal serial bus interface, providing a high-bandwidth transmission channel for flashing file transmission, thereby improving flashing efficiency. Furthermore, it adopts a dual-channel transmission mode, sending upgrade commands via the controller area network bus and transmitting upgrade requests, upgrade response information, and flashing files during the upgrade process via the universal serial bus. This resolves the contradiction in related technologies where a single channel cannot simultaneously handle real-time control and file output, ensuring both high-speed transmission of flashing files and real-time sending of control commands, thus enabling efficient software flashing of electronic control units. Attached Figure Description
[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0012] Figure 1 This is a flowchart illustrating the steps of an embodiment of the software flashing method of this application; Figure 2 This is a flowchart illustrating the steps of another embodiment of the software flashing method of this application; Figure 3 This is a schematic diagram of the architecture of an embodiment of the software flashing method of this application; Figure 4 This is a schematic diagram of the software package download process according to an embodiment of the software flashing method of this application; Figure 5 This is a schematic diagram of the software package installation process according to an embodiment of the software flashing method of this application; Figure 6 This is a schematic diagram of the software package download process in another embodiment of the software flashing method of this application; Figure 7 This is a structural block diagram of an embodiment of a software flashing device according to this application; Figure 8 This is a structural block diagram of another embodiment of the software flashing device of this application. Detailed Implementation
[0013] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0015] The software flashing method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.
[0016] In related technologies, ECU software flashing typically relies on DoCAN or DoIP. However, DoCAN-based software flashing is limited by the physical layer characteristics of the CAN bus, with a maximum theoretical bandwidth of 500Kbps. In practical applications, due to factors such as ISO-TP (ISO Transport Protocol) overhead, flow control mechanisms, and bus arbitration, the effective data transmission rate is significantly reduced. Transmitting a 100MB ECU flashing file can take 60-90 minutes, which cannot meet the efficiency requirements of modern automotive software updates and the flashing of large ECUs (such as autonomous driving domain controllers and intelligent cockpit controllers). Furthermore, prolonged occupation of CAN bus communication resources during ECU software flashing can affect the execution of other vehicle diagnostic functions and may interfere with the real-time communication of the vehicle control system. Long-term continuous transmission also increases the risk of communication link interference or interruption. The error recovery mechanism of the CAN-based transport layer protocol under long-term transmission is complex, and the success rate of resuming transmission after interruption is low. DoIP-based software flashing is limited by the physical structure of the OBD-II interface. The standard OBD-II diagnostic interface (SAE J1962) only provides 16 pins, of which a limited number are available for Ethernet. This is insufficient to meet the physical connection requirements of Gigabit Ethernet (1000BASE-T) with its four pairs of differential signal lines (eight cables). It typically only supports 100M Ethernet (100BASE-TX, using two pairs of differential lines), thus limiting the transmission bandwidth and consequently restricting flashing efficiency. Furthermore, implementing vehicle Ethernet communication requires modifications to the vehicle's network architecture and the addition of hardware such as Ethernet switches, significantly increasing implementation costs and technical complexity.
[0017] To address the aforementioned issues, this application provides a software flashing method that enables efficient software flashing of electronic control units.
[0018] Reference Figure 1 This is a flowchart illustrating the steps of a software flashing method embodiment of this application. The method is applied to a vehicle, which is connected to a diagnostic device via a Universal Serial Bus and a Controller Area Network (CLAN) bus.
[0019] The diagnostic equipment can be an electronic device with diagnostic software installed. This software can be a vehicle diagnostic tool. The electronic devices include, but are not limited to, smartphones, tablets, laptops, desktop computers, wearable devices, etc. The diagnostic equipment establishes a physical connection with the vehicle via a Universal Serial Bus (USB) interface. USB is an industry-standard serial bus and input / output interface technology specification that provides a scalable, plug-and-play serial interface, ensuring standard, low-cost connectivity for the device. The diagnostic equipment also establishes a physical connection with the vehicle via a Controller Area Network (CAN) bus and an OBD-II interface, enabling efficient command transmission.
[0020] The software flashing method for vehicles applied in this application includes the following steps: Step 101: In response to the upgrade command sent by the diagnostic device through the controller area network bus, the vehicle's diagnostic controller sends an upgrade request to the diagnostic device through the universal serial bus, so that the diagnostic device responds to the upgrade request and returns upgrade response information through the universal serial bus; the upgrade response information includes the flashing file download address; The upgrade command can be an instruction used to instruct the vehicle to initiate the software flashing process. The diagnostic equipment uses the upgrade command to indicate to the vehicle that software flashing can begin. The vehicle's Intelligent Diagnostic Controller (IDC) is an intelligent diagnostic controller used for vehicle fault diagnosis and data management, capable of communicating with other ECUs in the vehicle via diagnostic protocols. The upgrade request can be a request to download the flashing files required for upgrading the vehicle's electronic control units; the upgrade request can be an HTTP POST request. The upgrade response information can be the response information generated by the diagnostic equipment based on the upgrade request. The upgrade response information can include the flashing file download address, signature information, and flashing file size information. The signature information may include a signature certificate. The flashing file download address can be the internal storage address of the diagnostic equipment, used to indicate the download location of the corresponding flashing file.
[0021] Step 102: The vehicle's electronic control unit obtains the corresponding flashing file through the universal serial bus according to the flashing file download address, and performs a software flashing operation based on the flashing file; The vehicle's electronic control unit (ECU) is connected to the diagnostic controller. The ECU includes, but is not limited to, the battery management system, vehicle controller, motor controller, body control module, and transmitter control unit. The flashing file can be an upgrade software package used to flash the ECU software. Flashing refers to the process of updating and managing the ECU's software programs and parameters based on the flashing file, writing new software data to the ECU's internal non-volatile memory to optimize, repair, or upgrade the vehicle's control functions.
[0022] In this embodiment, the vehicle can initiate a software flashing process in response to an upgrade command sent by the diagnostic device via the Controller Area Network (CAN) bus. The vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the Universal Serial Bus (USB), causing the diagnostic device to respond by returning upgrade response information, including the download address of the flashing file, via the USB. Subsequently, the vehicle's Electronic Control Unit (ECU) can obtain the corresponding flashing file via the USB based on the received download address and perform a software flashing operation on the corresponding ECU based on the flashing file. Through the above implementation process, a high-speed data transmission path logically connected to the vehicle's internal network can be obtained through the USB interface, providing a high-bandwidth transmission channel for flashing file transmission, thereby improving flashing efficiency. Furthermore, the dual-channel transmission mode, sending the upgrade command via the CAN bus and transmitting the upgrade request, upgrade response information, and flashing file during the upgrade process via the USB, resolves the contradiction in related technologies where a single channel cannot simultaneously handle real-time control and file output. This ensures both high-speed transmission of flashing files and real-time sending of control commands, thus achieving efficient software flashing of the ECU.
[0023] In some embodiments of this application, before the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, the method includes: In response to a detection command sent by the diagnostic device, the remote network driver capability of the diagnostic controller is returned to the diagnostic device via the Universal Serial Bus (USB), so that the diagnostic device loads the corresponding driver and generates a first virtual address corresponding to the diagnostic device according to the remote network driver capability, allocates a second virtual address to the diagnostic controller according to the first virtual address, and constructs a network channel on the USB according to the driver, the first virtual address, and the second virtual address; the network channel is used to transmit the upgrade request and the upgrade response information.
[0024] In this embodiment, the detection command can be an instruction from the diagnostic device's operating system used to detect the RNDIS (Remote Network Driver Interface Specification) capability of the vehicle's diagnostic controller. The diagnostic device's operating system can be Windows, Linux, or other systems; this application does not impose specific limitations. The vehicle's diagnostic controller can respond to the detection command sent by the diagnostic device by returning its remote network driver capability to the diagnostic device via a universal serial bus, enabling the diagnostic device to automatically load the corresponding driver and generate a first virtual address based on the received remote network driver capability. The driver corresponding to the remote network driver capability can be an RNDIS-class driver corresponding to the vehicle's diagnostic controller's RNDIS capability, allowing the diagnostic controller to be recognized as a standard Ethernet network adapter on the diagnostic device's operating system, thus enabling network data transmission via a USB cable. The first virtual address can be a private address assigned by the diagnostic device's operating system to the virtual network card generated based on the remote network driver, i.e., the diagnostic device's virtual address. After generating the first virtual address, the diagnostic device can also assign a second virtual address to the diagnostic controller based on the first virtual address. The second virtual address can be an IP address in the same network segment as the first virtual address, i.e., the diagnostic controller's virtual address. Based on the driver, the first virtual address, and the second virtual address, a network channel can be established between the diagnostic device and the diagnostic controller using a Universal Serial Bus (USB). This network channel can be a virtual Ethernet channel built on the physical USB link based on the RNDIS protocol. This enables a high-speed data transmission path for logical connectivity between the diagnostic device and the vehicle's internal network, allowing the HTTP (Hypertext Transfer Protocol) protocol to run on the USB connection. This allows for the transmission of upgrade requests and response information via this virtual Ethernet channel. Through the above implementation process, a virtual Ethernet connection based on the USB physical link can be established between the diagnostic device and the vehicle's diagnostic controller. This allows subsequent HTTP protocol data packets to be transmitted on this virtual link, bypassing the limitation on the number of OBD-II interface cables, unlocking the high bandwidth potential of USB, and achieving high-speed transmission of subsequent flashing files without relying on the vehicle's traditional in-vehicle network system, thus improving flashing efficiency.
[0025] In some embodiments of this application, in response to an upgrade command sent by the diagnostic device via the controller area network bus, the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, including: In response to an upgrade command sent by the diagnostic device via the controller local area network bus, the electronic control unit sends an upgrade request to the diagnostic controller; the upgrade request includes the address of the electronic control unit and the address of the diagnostic controller; The diagnostic controller converts the address of the electronic control unit in the upgrade request into a second virtual address of the diagnostic controller, and sends the converted upgrade request to the diagnostic device via the universal serial bus.
[0026] In this embodiment, in response to an upgrade command sent by the diagnostic device via the controller area network (CLAN) bus, the electronic control unit (ECU) can send an upgrade request to the diagnostic controller. The original upgrade request may include ECU parameters and the addresses of the ECU and the diagnostic controller within the vehicle's internal network. ECU parameters may include at least the ECU name and ECU part number. After receiving the original upgrade request, the diagnostic controller can convert the ECU address in the upgrade request into a second virtual address for the diagnostic controller and send the converted upgrade request to the diagnostic device via the universal serial bus. The converted upgrade request also includes the ECU parameters.
[0027] For example, the ECU can first send an HTTP POST request (i.e., an upgrade request) to the IDC to request the download of the flashing files required for the ECU upgrade. The request address is http: / / xx, where xx is a placeholder representing the IDC's gateway address in the vehicle network. Furthermore, the upgrade request can also carry parameters such as ECUName (electronic control unit name) and PartNumber (electronic control unit part number). After receiving the upgrade request, the IDC will convert the request address in the upgrade request to a first virtual address and the ECU address in the upgrade request to a second virtual address. Then, the IDC will forward the converted upgrade request to the diagnostic device via the USB-RNDIS virtual Ethernet channel (i.e., a pre-built USB-based network channel).
[0028] In related technologies, when an ECU needs to download and rewrite files, it typically sends an HTTP request directly to the diagnostic device, or the ECU sends a request to the IDC (Internet Data Center), which then forwards it directly to the diagnostic device. These request operations directly expose the ECU's internal address to external devices. Through the above implementation process, when the ECU sends a request to the diagnostic device to rewrite the files, the source address in the upgrade request, i.e., the ECU address, can be converted into the second virtual address corresponding to the IDC. This effectively hides the actual addresses of the diagnostic device and the vehicle's internal network during transmission, maintaining the vehicle's internal network security and enhancing system security.
[0029] In some embodiments of this application, before the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, the method further includes: The vehicle's diagnostic controller responds to a secure access command sent by the diagnostic device via the controller area network bus to authenticate the diagnostic device. If the authentication result is successful, the diagnostic controller switches to the target device mode in response to the mode switching command sent by the diagnostic device through the controller local area network bus; the target device mode is used to enable the diagnostic controller to communicate with the diagnostic device through the network channel on the universal serial bus. The diagnostic controller initiates the address translation function in response to an address translation command sent by the diagnostic device via the controller local area network bus; the address translation function is used to perform the translation between the address of the electronic control unit and the second virtual address.
[0030] In this embodiment, the diagnostic device can send a secure access command to the diagnostic controller via the controller area network bus. The vehicle's diagnostic controller can respond to the secure access command, authenticate the diagnostic device, and return the authentication result to the diagnostic device. The secure access command is used to request authentication.
[0031] If authentication is successful, the diagnostic device can send a mode switching command to the diagnostic controller via the Controller Area Network (CLAN) bus. This command requests the vehicle diagnostic controller to switch its USB interface from default mode to target device mode. The default mode can be storage mode, in which the vehicle diagnostic controller is recognized as a serial device or a basic network interface card (NIC), primarily used for transmitting simple AT (Attention) commands (a text command format) or low-speed data, and cannot directly run higher-level HTTP protocols. The target device mode can be RNDIS device mode, used to support communication between the vehicle diagnostic controller and the diagnostic device via a virtual link. In RNDIS device mode, the vehicle diagnostic controller is recognized as a full-featured virtual NIC, and the diagnostic device's operating system can load a complete TCP / IP protocol stack for the vehicle diagnostic controller, supporting IP routing, HTTP / HTTPS protocols, and capable of handling large-scale software downloads. The diagnostic controller can respond to the mode switching command by switching from default mode to target device mode. For example, the diagnostic device can use service 31 (RoutineControl) of the UDS (Unified Diagnostic Services) command to send a mode switching command to the diagnostic controller via the Controller Area Network (CLAN) bus. After successfully switching to the target device mode, the diagnostic controller can use service 71 (PositiveResponse) of the UDS command to return a successful switching service feedback result to the diagnostic device via the CLAN bus, confirming that the diagnostic controller's RNDIS device mode is ready. If the diagnostic controller fails to switch to the target device mode, it can return a switching failure service feedback result to the diagnostic device. After receiving the switching failure service feedback result, the diagnostic device can generate a mode switching failure prompt message and display it on the diagnostic device's display screen, and then terminate the current flashing process.
[0032] After the network channel on the Universal Serial Bus (USB) is established, the diagnostic device can use the UDS command's 31 service to send address translation commands to the diagnostic controller via the Controller Area Network (CLAN) bus. The diagnostic controller can respond to the address translation commands and initiate the address translation function. This address translation function is used to translate between the address of the Electronic Control Unit (ECU) and the second virtual address. The address translation command can carry at least the ECU information of the target ECU to be diagnosed, which can include at least the ECU's diagnostic address, to ensure that the address translation command is correctly sent to the vehicle diagnostic controller. Upon receiving the address translation command, the vehicle diagnostic controller can internally configure network address translation rules related to the target ECU corresponding to the UDS command, such as configuring the translation between the IDC's vehicle network address and the diagnostic device's first virtual address, and configuring the translation between the ECU's vehicle network address and the IDC's second virtual address. For example, service 31 of the UDS command typically carries a specific routine identifier (RID). For instance, the RID "0xAEC3" represents "Start NAT (Network Address Translation) forwarding." After receiving this address translation command, the diagnostic controller configures the address mapping relationship in its internal network protocol stack, redirecting the request from the target ECU to the diagnostic device. When the target ECU sends an HTTP request to download a software package, the corresponding upgrade request is first sent to the diagnostic controller. Assuming the source address of this upgrade request is 172.16.xx (ECU address) and the target address is 172.16.96 (IDC address), after starting the address translation function, the vehicle diagnostic controller can convert the source address of the request to the second virtual address 10.1.1.yy corresponding to the diagnostic controller, and the target address to the first virtual address corresponding to the diagnostic device. Then, it sends the converted HTTP request to the diagnostic device from the second virtual address. After the address translation function is successfully started, the diagnostic controller can use service 71 of the UDS command to return a successful service feedback result to the diagnostic device via the controller area network bus, confirming that the NAT forwarding channel is ready.
[0033] Through the above implementation process, the diagnostic controller's authentication of the diagnostic device ensures the security of data transmission between the diagnostic device and the vehicle's diagnostic controller. By sending a mode switching command, the diagnostic device switches the diagnostic controller to target device mode, allowing the diagnostic controller to be recognized as a virtual network interface card (NIC). This enables the virtual link to support IP routing and HTTP / HTTPS protocols, allowing for large-capacity software downloads, improving data transmission efficiency, and thus ensuring flashing efficiency. Before activating the address translation function, the ECU needs to download the flashing file, typically by directly sending an HTTP request to the diagnostic device, or by sending a request to the IDC (Internet Data Center), which then forwards it to the diagnostic device. These requests directly expose the vehicle's internal ECU address to external devices. By sending an address translation command to activate the address translation function of the vehicle's diagnostic controller, NAT (Network Address Translation) can be used to translate the source address of the request during transmission. This effectively hides the actual addresses of the diagnostic device and the vehicle's internal network during transmission, maintaining the vehicle's internal network security and enhancing system security.
[0034] In some embodiments of this application, the vehicle's diagnostic controller, in response to a secure access command sent by the diagnostic device via the controller area network bus, performs authentication of the diagnostic device, including: In response to a secure access command sent by the diagnostic device via the controller LAN bus, the diagnostic controller returns a random seed value to the diagnostic device, so that the diagnostic device generates an authentication key based on the random seed value. The diagnostic controller receives the authentication key sent by the diagnostic device through the controller local area network bus, and performs identity authentication on the diagnostic device based on the authentication key.
[0035] In this embodiment, the diagnostic device can send a secure access command to the vehicle diagnostic controller via the OBD-II interface through the vehicle's Controller Area Network (CAN) bus. This secure access command can be the 2721 service (i.e., secure access service) in the UDS command, which requests a random seed value. In response to the secure access command, the diagnostic controller can return a random seed value to the diagnostic device via the CAN bus, such as 6721+XX, where 6721 is the service identifier and XX is the random seed value. The diagnostic device can receive the random seed value returned by the diagnostic controller in response to the secure access command, and then use a pre-configured IDC security algorithm to generate an authentication key based on the received random seed value, such as 2722+XX*, where 2722 is the service identifier and XX* is the authentication key. Subsequently, the diagnostic device can send the authentication key to the diagnostic controller via the CAN bus. The diagnostic controller can receive the authentication key and authenticate the diagnostic device based on it. After receiving the authentication key, the diagnostic controller internally calculates the verification key based on the previously sent random seed value and the corresponding security algorithm, and compares the authentication key with the verification key. If the authentication key and the verification key match, the authentication is successful and the diagnostic controller enters the unlocked state. If the authentication key and the verification key do not match, the authentication fails, the diagnostic controller enters the locked state and ends the flashing process.
[0036] Through the above implementation process, a secure handshake between the diagnostic device and the diagnostic controller can be achieved. Only after successful identity authentication will the diagnostic controller enter the unlocked state, allowing the diagnostic device to perform subsequent flashing procedures with the diagnostic controller. This effectively ensures the communication security of the vehicle's internal network and improves system security.
[0037] In some embodiments of this application, the vehicle's electronic control unit obtains the corresponding flashing file via the universal serial bus according to the flashing file download address, and performs a software flashing operation based on the flashing file, including: The vehicle's electronic control unit generates a corresponding file retrieval request based on the flashing file download address, and sends the file retrieval request to the vehicle's diagnostic controller; the file retrieval request includes the address of the electronic control unit and the address of the diagnostic controller; The diagnostic controller converts the address of the electronic control unit in the file retrieval request into a second virtual address of the diagnostic controller, and sends the converted file retrieval request to the diagnostic device via the universal serial bus; the file retrieval request is used to enable the diagnostic device to return the flash file to the diagnostic controller via the universal serial bus; The electronic control unit downloads the flashing file; In response to the download progress query command sent by the diagnostic device through the controller local area network bus, the electronic control unit determines the corresponding flash file download progress, and sends the flash file download progress to the diagnostic device through the controller local area network bus, so that the diagnostic device can determine whether the electronic control unit has completed the download of the flash file based on the flash file download progress; After the flashing file is downloaded, the electronic control unit responds to the installation command sent by the diagnostic device through the controller local area network bus and performs a flashing operation on the software of the electronic control unit based on the flashing file.
[0038] In this embodiment, after receiving the upgrade response information from the diagnostic device, the vehicle's diagnostic controller can perform address translation on the upgrade response information to forward it to the corresponding electronic control unit (ECU). Upon receiving the upgrade response information, the ECU can generate a corresponding file retrieval request based on the download address of the flash file. The file retrieval request generated by the ECU can include the address of the ECU and the address of the diagnostic controller, and the ECU sends the file retrieval request to the diagnostic controller. The diagnostic controller can convert the address of the ECU in the file retrieval request to its second virtual address and convert the address of the diagnostic controller to the first virtual address corresponding to the diagnostic device, and then send the converted file retrieval request to the diagnostic device via the Universal Serial Bus (USB). The file retrieval request can be used to enable the diagnostic device to return the flash file to the diagnostic controller via the USB. The diagnostic device can respond to the file retrieval request by returning the flash file to the diagnostic controller via a network channel built on the USB, and the diagnostic controller then sends the flash file to the ECU after address translation. Subsequently, the ECU can download the corresponding flash file. For example, the ECU generates an HTTP GET request (i.e., a file retrieval request) based on the download address in the received upgrade response information to request the actual download of the corresponding flash file. The IDC (Internet Data Center) again acts as an intermediary, performing address translation on the file retrieval request before sending it to the diagnostic device. Upon receiving the request, the diagnostic device sends the corresponding flashing file to the IDC via a network channel built over USB. The IDC then forwards the flashing file to the corresponding ECU, allowing the ECU to download the appropriate flashing file.
[0039] Through the above implementation process, a high-speed virtual Ethernet channel based on USB-RNDIS can be used to replace the traditional CAN transmission for flashing files. This effectively shortens the ECU flashing time, significantly improves flashing efficiency, and avoids long-term occupation of the CAN bus by large data packets, ensuring the real-time performance of other vehicle control functions. Furthermore, direct transmission of flashing files between the diagnostic device and the ECU poses security risks. By activating the address translation function of the vehicle diagnostic controller, a logically isolated forwarding channel can be established between the diagnostic device and the vehicle's internal network. Using the IDC as a gateway for address translation hides the real network addresses of the diagnostic device and the ECU, enhancing data transmission security during the electronic control unit software flashing process.
[0040] In this embodiment, after the diagnostic device sends the flash file to the diagnostic controller, it can send a download status query command to the electronic control unit (ECU) via the Controller Area Network (CLAN) bus using the UDS instruction 22 service (high-frequency diagnostic service) according to a preset download progress query period. The preset download progress query period allows the diagnostic device to poll the download progress of the flash file for the ECU. The specific period length can be set according to actual needs, and this application does not impose specific limitations on it. Responding to the download progress query command sent by the diagnostic device via the CLAN bus, the ECU can determine the corresponding flash file download progress and send it to the diagnostic device via the CLAN bus. For example, the flash file download progress range can be set to 0-100%, with a download progress of 100 indicating that the flash file download is complete. The range can also be set to 0-100% or set according to needs, and this application does not impose specific limitations on it. The diagnostic device can determine whether the ECU has completed the flash file download based on the received flash file download progress.
[0041] For example, the diagnostic device can periodically send a 22+DID1 (Data Identifier, Data Request) command, which is a download status query command, to the corresponding ECU via the CAN channel and IDC, based on the DoCAN protocol, to obtain the download progress of the flash file in the ECU. After receiving the download status query command, the ECU can return "62 + flash file download progress". Here, the 62 service of the UDS command is used to indicate a positive response of the 22 service. The diagnostic device can continuously query the download progress of the flash file corresponding to the ECU according to a preset download progress query period until the returned flash file download progress is 100%. At this time, the diagnostic device determines that the corresponding ECU has completed the download of the flash file and can proceed with the subsequent flashing steps.
[0042] After the flashing file is downloaded, the diagnostic device can send an installation command to the electronic control unit (ECU) via the Controller Area Network (CLAN) bus. The installation command instructs the ECU to perform a software flashing operation based on the flashing file. The ECU can respond to the installation command by performing the software flashing operation based on the flashing file. For example, the installation command can be a command sent via the CAN channel using the UDS command's 31 service, based on the DoCAN protocol, to request the ECU to perform the software flashing operation.
[0043] Through the above implementation process, the diagnostic equipment can query the download progress of the flashing file in the ECU in real time via the controller area network bus, ensuring the real-time and deterministic nature of the query command issuance and download progress feedback. After the ECU completes the flashing file download, it can quickly react and send installation commands, promptly instructing the ECU to perform the flashing operation. The dual-channel transmission mode, which separates control commands and data files, effectively improves the problem of traditional single-channel transmission's inability to simultaneously handle real-time control and high-bandwidth data transmission.
[0044] For example, the flashing file download address can be an internal address of the diagnostic device, an internal address of the IDC or ECU, or an HTTP address link. The flashing file can be stored in the space pointed to by the flashing file download address. This application does not impose any specific restrictions on this.
[0045] In some embodiments of this application, before the electronic control unit performs a flashing operation on the software of the electronic control unit based on the flashing file in response to an installation command sent by the diagnostic device via the controller area network bus, the method includes: The electronic control unit receives a verification value sent by the diagnostic device via the controller local area network bus; the verification value is generated based on the content of the flash file; The electronic control unit performs an integrity check on the flash file based on the verification value; The electronic control unit responds to the signature verification command sent by the diagnostic device through the controller local area network bus to perform security verification on the flashing file; If the integrity check and the security check pass, the electronic control unit receives the installation command sent by the diagnostic device through the controller local area network bus.
[0046] In this embodiment, the diagnostic device, upon determining that the electronic control unit (ECU) has completed downloading the flash file, can generate a checksum corresponding to the flash file. The checksum can be generated based on the content of the flash file. For example, the checksum corresponding to the flash file can be calculated using the SHA-256 (Secure Hash Algorithm 256-bit, a cryptographic hash function) method. The diagnostic device can then send this checksum to the ECU via the Controller Area Network (CAN) bus using UDS's 31 service (Routine Control Service). The ECU can receive the checksum and perform an integrity check on the flash file based on it. The integrity check can be used to verify the consistency between the flash file received by the ECU and the flash file sent by the diagnostic device, thereby determining whether the flash file received by the ECU is complete. For example, the ECU can use SHA-256 to calculate the hash value of the downloaded flash file, and then compare this hash value with the received checksum. If the hash value calculated by the ECU matches the received checksum, the integrity check for the flash file has passed.
[0047] The diagnostic device can also send signature verification commands to the electronic control unit (ECU) via the Controller Area Network (CLAN) bus using UDS service 31 (Routine Control Service). The signature verification command drives the ECU to perform digital signature verification on the flashing file using the signature information carried in the upgrade response information, thus achieving security verification. Security verification can be used to determine whether the flashing file sent by the diagnostic device has been maliciously tampered with during transmission. In response to the signature verification command, the ECU can perform security verification on the flashing file based on the signature information. The specific process of digital signature verification can be designed with reference to existing technologies in the field, and this application does not impose specific limitations on it. If the comparison verification results of the digital signatures are consistent, it indicates that the security verification for the flashing file has passed.
[0048] The electronic control unit (ECU) can send verification results back to the diagnostic device via the Controller Area Network (CLAN) bus. If both integrity and security verifications pass, the diagnostic device can send installation instructions to the ECU via the CLAN bus. The ECU can receive these instructions and continue the flashing process. If either integrity or security verification fails, the diagnostic device can terminate the flashing process, generate a corresponding error message, and display it on its screen. This process allows for rigorous integrity and security verification of the flashing file after transmission. Integrity verification ensures the data in the transmitted flashing file is complete and error-free, while security verification prevents malicious code injection, thus enhancing the security of the flashing process.
[0049] In some embodiments of this application, after performing a software flashing operation based on the flashing file, the method includes: In response to the installation progress query command sent by the diagnostic device through the controller local area network bus, the electronic control unit determines the corresponding flashing file installation progress, and sends the flashing file installation progress to the diagnostic device through the controller local area network bus, so that the diagnostic device can determine whether the electronic control unit has completed the flashing operation based on the flashing file installation progress.
[0050] In this embodiment, the diagnostic device can send an installation progress query command to the electronic control unit (ECU) via the Controller Area Network (CLAN) bus using the UDS instruction 22 service (high-frequency diagnostic service) according to a preset installation progress query period. The preset installation progress query period allows the diagnostic device to poll the installation progress of the ECU's flash file. The specific period length can be set according to actual needs. The preset installation progress query period and the preset download progress query period can be the same or different; this application does not impose specific limitations on this. The ECU can respond to the installation progress query command, determine the corresponding flash file installation progress, and send the flash file installation progress to the diagnostic device via the CLAN bus. For example, the flash file installation progress range can be set to 0-100%, where a download progress of 100% indicates that the flash file installation is complete. The flash file installation progress range can also be set to 0-100% or set according to needs; this application does not impose specific limitations on this. The diagnostic device can determine whether the ECU has completed the flashing operation based on the received flash file installation progress.
[0051] For example, the diagnostic device can periodically send a 22+DID2 command (installation progress query command) to the corresponding ECU via the CAN channel and IDC, based on the DoCAN protocol, to obtain the installation progress of the flash file in the ECU. After receiving the installation progress query command, the ECU can return "64 + installation progress". The diagnostic device can continuously query the installation progress of the flash file corresponding to the ECU according to a preset installation progress query period until the returned flash file installation progress is 100%, at which point the diagnostic device can determine that the corresponding ECU has completed the installation of the flash file.
[0052] Through the above implementation process, the integrity and correctness of the entire flashing file installation process can be monitored in real time by polling the installation progress of the flashing file in the electronic control unit.
[0053] For example, after the diagnostic equipment determines that the electronic control unit (ECU) has been successfully flashed, it can send an ECU reset command to the ECU via the controller area network (CLAN) bus and read the corresponding software version to confirm that the ECU software has been successfully flashed. Upon confirming successful software flashing, the diagnostic equipment can send a connection termination command to the vehicle's diagnostic controller. This command causes the diagnostic controller to disable address translation (NAT) functionality (i.e., disable the NAT forwarding channel), reset from target device mode to default mode, and release relevant network resources.
[0054] Reference Figure 2 This is a flowchart illustrating the steps of a software flashing method embodiment of this application. The method is applied to a diagnostic device, which is connected to a vehicle via a Universal Serial Bus and a Controller Area Network (CAN) bus.
[0055] The software flashing method for diagnostic equipment according to the embodiments of this application includes the following steps: Step 201: Send an upgrade command to the vehicle via the controller local area network bus; Step 202: Receive the upgrade request sent by the vehicle's diagnostic controller in response to the upgrade command via the Universal Serial Bus; Step 203: In response to the upgrade request, upgrade response information is returned to the vehicle's diagnostic controller via the universal serial bus; the upgrade response information includes a flashing file download address, which enables the vehicle's electronic control unit to download the corresponding flashing file according to the flashing file download address, and to perform a software flashing operation based on the flashing file.
[0056] The software flashing method for diagnostic equipment described in this application corresponds to the software flashing method for vehicles described above. The parts that are the same in this application and the software flashing method for vehicles described above will not be repeated. Please refer to the corresponding parts in the embodiments of the software flashing method for vehicles described above.
[0057] In this embodiment, a virtual link can be established between the diagnostic device and the vehicle diagnostic controller based on a Universal Serial Bus (USB). Then, a first upgrade request sent by the vehicle diagnostic controller via the virtual link is received. In response to the first upgrade request, a flashing file is returned to the vehicle diagnostic controller via the virtual link, enabling the vehicle diagnostic controller to control the electronic control unit (ECU) to download the flashing file. After the ECU completes the flashing file download, an installation command can be sent to the vehicle diagnostic controller via the Controller Area Network (CLAN) bus. This allows the vehicle diagnostic controller to convert the request source address in the installation command into a virtual address of the diagnostic controller using an address translation function, and then send the converted installation command to the ECU. The installation command controls the ECU to perform a flashing operation on the ECU software based on the flashing file. Through the above implementation process, the virtual link provides a high-speed data transmission path logically connected to the vehicle's internal network via the USB interface, providing a high-bandwidth transmission channel for flashing file transmission and thus improving flashing efficiency. Furthermore, it adopts a dual-channel transmission mode, transmitting the flash file in response to the first upgrade request via a virtual link, and sending control commands via the controller LAN bus. This can resolve the contradiction between real-time control and file output that is difficult to achieve with a single channel in related technologies. It can ensure both high-speed transmission of flash files and real-time sending of control commands, thereby enabling efficient software flashing of electronic control units.
[0058] In some embodiments of this application, before receiving an upgrade request sent via a Universal Serial Bus in response to the upgrade command from the vehicle's diagnostic controller, the method includes: The diagnostic command is sent to the vehicle's diagnostic controller via the universal serial bus, so that the vehicle's diagnostic controller returns the remote network drive capability of the diagnostic controller. Load the corresponding driver program according to the remote network driving capability and generate the first virtual address corresponding to the diagnostic device; A second virtual address is assigned to the diagnostic controller based on the first virtual address; A network channel is constructed on the Universal Serial Bus based on the driver, the first virtual address, and the second virtual address; the network channel is used to transmit the upgrade request and the upgrade response information.
[0059] In some embodiments of this application, before receiving an upgrade request sent via a Universal Serial Bus in response to the upgrade command from the vehicle's diagnostic controller, the method further includes: A secure access command is sent to the vehicle's diagnostic controller via the controller area network bus, so that the diagnostic controller responds to the secure access command and authenticates the diagnostic device. If the authentication result is successful, a mode switching command is sent to the diagnostic controller via the controller local area network bus to switch the diagnostic controller to the target device mode; the target device mode is used to enable the diagnostic controller to communicate with the diagnostic device through the network channel on the universal serial bus. The address translation command is sent to the diagnostic controller via the controller local area network bus to enable the diagnostic controller to start the address translation function; the address translation function is used to translate between the address of the electronic control unit and the second virtual address.
[0060] In some embodiments of this application, sending a secure access command to the vehicle's diagnostic controller via the controller area network bus, so that the diagnostic controller responds to the secure access command and authenticates the diagnostic device, includes: Send a secure access command to the diagnostic controller via the controller local area network bus; Receive the random seed value returned by the diagnostic controller in response to the secure access command; Generate an authentication key based on the random seed value; The authentication key is sent to the diagnostic controller via the controller local area network bus, so that the diagnostic controller can authenticate the diagnostic device based on the authentication key.
[0061] In some embodiments of this application, after returning upgrade response information to the vehicle's diagnostic controller via the universal serial bus, the method further includes: In response to a file retrieval request sent by the diagnostic controller via the Universal Serial Bus, the corresponding flash file is returned to the diagnostic controller via the Universal Serial Bus. The controller local area network bus sends a download progress query command to the electronic control unit so that the electronic control unit can determine the download progress of the corresponding flashing file. The system receives the flash file download progress sent by the electronic control unit through the controller local area network bus, and determines whether the electronic control unit has completed the download of the flash file based on the flash file download progress. After the electronic control unit completes the download of the flashing file, it sends an installation command to the electronic control unit via the controller local area network bus.
[0062] In some embodiments of this application, the method includes, before sending installation instructions to the electronic control unit via the controller area network bus: Generate a verification value based on the contents of the file being written; The verification value is sent to the electronic control unit via the controller local area network bus, so that the electronic control unit performs an integrity verification on the flash file based on the verification value. The controller local area network bus sends a signature verification command to the electronic control unit so that the electronic control unit can perform security verification on the flashing file. If the integrity check and the security check pass, an installation command is sent to the electronic control unit via the controller local area network bus.
[0063] In some embodiments of this application, after sending an installation command to the electronic control unit via the controller area network bus, the method includes: The controller local area network bus sends an installation progress query command to the electronic control unit so that the electronic control unit can determine the installation progress of the corresponding flashing file. The system receives the flashing file installation progress sent by the diagnostic controller via the controller local area network bus, and determines whether the electronic control unit has completed the flashing operation based on the flashing file installation progress.
[0064] The above implementation process utilizes a high-speed data transmission path logically connected to the vehicle's internal network via a universal serial bus interface, providing a high-bandwidth transmission channel for flashing file transfer and thus improving flashing efficiency. Furthermore, the dual-channel transmission mode, sending upgrade commands via the controller area network bus and transmitting upgrade requests, upgrade response information, and flashing files during the upgrade process via the universal serial bus, resolves the contradiction in related technologies where a single channel cannot simultaneously handle real-time control and file output. This ensures both high-speed transmission of flashing files and real-time sending of control commands, thereby enabling efficient software flashing of the electronic control unit.
[0065] Reference Figure 3 This is a schematic diagram of the architecture of an embodiment of the software flashing method of this application.
[0066] The software flashing method architecture of this application includes external devices and an internal vehicle network. The internal vehicle network includes a vehicle diagnostic controller (IDC), a gateway module (GWM), and an electronic control unit (ECU). The GWM is used for forwarding diagnostic commands; both diagnostic commands sent by the diagnostic tool and the ECU are forwarded through the GWM. The external devices are electronic devices equipped with diagnostic tools, i.e., diagnostic equipment. These external devices have USB interfaces, enabling a physical USB connection with the vehicle's IDC. The IDC can use its address translation function to convert the vehicle network address (source address) in the request sent by the ECU into a USB network card address (diagnostic controller virtual address) using NAT forwarding.
[0067] During the flash file download phase, the ECU can send an HTTP request to the IDC. The IDC can then use the enabled address translation function and NAT forwarding mechanism to forward this HTTP request to the diagnostic tool via a USB-RNDIS channel (virtual channel) built based on the USB physical connection to request the download of the flash file. Large flash files can also be transferred from external devices to the vehicle's internal network via the HTTP-based virtual channel.
[0068] Other diagnostic control commands are transmitted on the vehicle's CAN bus based on the mature DoCAN protocol. Diagnostic control commands can be used for critical diagnostic session control (requesting entry into an extended session), secure access (authentication), flash condition checks (service 31), and control commands for the flashing process (such as requesting an upgrade, querying status, requesting installation, etc.).
[0069] In such Figure 3 The architecture shown can solve the contradiction between real-time control and high-bandwidth transmission that is difficult to balance in a traditional single-channel system by adopting a dual-channel transmission mode that separates control commands and data files. This ensures the standardization and reliability of vehicle ECU diagnosis and flashing operations, avoids the long-term occupation of the CAN bus by large flashing files, guarantees the real-time performance of other vehicle control functions, optimizes the utilization of communication resources, and improves the software flashing efficiency of electronic control units.
[0070] Reference Figure 4 This is a schematic diagram of the software package download process according to an embodiment of the software flashing method of this application.
[0071] Figure 4In this context, the diagnostic equipment can be a computer equipped with a diagnostic tool. The diagnostic equipment is connected to the IDC via an OBD-II interface using an OBD cable and an OBD-to-RJ45 cable. One end of the OBD cable is connected to the computer's network cable interface, and the other end is connected to the vehicle's OBD port. The IDC is connected to the diagnostic equipment via a USB interface using a USB cable. One end of the USB data cable is connected to the computer, and the other end is connected to the vehicle's USB interface, which is connected to the internal IDC. The download process for the software flashing package for the electronic control unit is as follows: The diagnostic device unlocks the host IDC security via OBD, sends a diagnostic command 10 03 (for requesting parameters) to the IDC, requests to enter an extended session, and obtains a random seed value. The IDC sends a diagnostic command 50 03 (used to return parameters) to the diagnostic device, indicating that it has entered an extended session, and sends a random seed value. The diagnostic device generates a corresponding security key (i.e., authentication key) based on the obtained random seed value and sends diagnostic command 27 21 (to request the sending of the security key) to the host IDC. The host IDC returned diagnostic command 67 21, indicating that the security key has been successfully received. The diagnostic device continues to send diagnostic command 27 22 to the host IDC to request the password; The host IDC returned diagnostic command 67 22, indicating that the verification password had been successfully sent. After completing the authentication, the diagnostic device sends a diagnostic command via service 31 to the IDC, requesting the IDC to switch to USBdevice mode (i.e., target device mode). After the host IDC performs a mode switch, it sends diagnostic commands to the diagnostic device via Service 71 to provide feedback on the USB mode switch result. The switch result can include switch success or switch failure. If the switch is successful, the next step of interaction will continue; if the switch fails, the process will end. The diagnostic device sends diagnostic commands to the IDC via service 31, requesting the activation of NAT forwarding (activation of address translation function). After starting NAT forwarding, the host IDC sends diagnostic commands to the diagnostic device via service 71 to provide feedback on the NAT forwarding startup result. The startup result can include startup success or startup failure. If startup is successful, the next step of interaction will continue; if startup fails, the process will end. The diagnostic device unlocks the ECU via OBD and sends a diagnostic command 10 03 to the ECU to request entry into an extended session in order to obtain programming permissions for the ECU. This diagnostic command can be forwarded via NAT through the IDC. The ECU sends a diagnostic command 50 03 (used to return parameters) to the diagnostic device, indicating that it has entered an extended session. This diagnostic command can be initiated via NAT forwarding through the IDC. The diagnostic device can generate a corresponding security key and send a diagnostic command 27 21 (to request the sending of the security key) to the ECU. This diagnostic command can be initiated via NAT forwarding through the IDC. The ECU sends diagnostic command 67 21 back to the diagnostic device, indicating that the security key has been successfully received. This diagnostic command can be forwarded via NAT through the IDC. The diagnostic equipment continues to send diagnostic commands 27 and 22 to the ECU to request the transmission of a password. These diagnostic commands can be forwarded via NAT through the IDC. The ECU returned diagnostic command 67 22, indicating that the verification password had been successfully sent. This diagnostic command can be forwarded via NAT through the IDC. The diagnostic device sends a diagnostic command to the ECU via service 31, requesting a flashing condition check. This may include checking whether the vehicle is in a safe state, whether the power supply voltage is within the allowable range, and whether the ECU is working properly. This diagnostic command can be forwarded via NAT through the IDC. The ECU sends the flashing condition check results back to the diagnostic equipment. This diagnostic command can be forwarded via NAT through the IDC. After the flashing condition check is completed, the diagnostic device can send a diagnostic command 31 service to the ECU to instruct the ECU to start requesting the download of the upgrade package (flash file), including the size of the upgrade package (using the definition of 1 byte as 8 bits). This diagnostic command can be initiated via NAT forwarding through the IDC. The ECU sends a request to the diagnostic equipment to download the result, indicating that the ECU has started downloading the upgrade package. This diagnostic command can be forwarded via NAT through the IDC. During the ECU upgrade package download process, the diagnostic device can send diagnostic commands to the ECU via service 22 to request a query on the download status of the flashing file in a polling manner. This diagnostic command can be forwarded via NAT through the IDC. The ECU sends the download progress feedback to the diagnostic equipment, and this diagnostic command can be initiated via NAT forwarding through the IDC. The ECU can download upgrade packages sent by a computer with diagnostic equipment installed via the HTTP protocol. These upgrade packages can be forwarded via NAT through a virtual channel via the IDC. After the upgrade package is downloaded, the ECU can send a diagnostic command via the 22 service to the diagnostic device and report the download result to the diagnostic device, indicating that the ECU has completed the download of the upgrade package. This diagnostic command can be forwarded via NAT through the IDC. The diagnostic device can use the SHA-256 method to calculate the hash value of the upgrade package, and then send it to the ECU through the diagnostic command 31 service, so that the ECU can verify the file integrity of the upgrade package based on the hash value. This diagnostic command can be initiated via NAT forwarding through the IDC. After completing the integrity verification, the ECU sends the verification result back to the diagnostic equipment. This diagnostic command can be forwarded via NAT through the IDC. The diagnostic device can send a signature verification command to the ECU through the 31 service of the diagnostic command, which drives the ECU to verify the signature of the upgrade package, that is, to perform a security verification. This diagnostic command can be forwarded via NAT through the IDC. After completing the safety verification, the ECU sends the verification result back to the diagnostic equipment. This diagnostic command can be forwarded via NAT through the IDC.
[0072] Reference Figure 5 This is a schematic diagram of the software package installation process according to an embodiment of the software flashing method of this application.
[0073] The installation process for the software flashing package is as follows: The diagnostic equipment can send diagnostic commands to the ECU via the 31 service, requesting the ECU to start the installation program. These diagnostic commands can be forwarded via NAT through the IDC. The ECU can send the corresponding installation start result back to the diagnostic equipment, indicating that the ECU has started installing the corresponding upgrade package. This diagnostic command can be forwarded via NAT through the IDC. After determining that the ECU has started installing the upgrade package, the diagnostic equipment can send diagnostic commands to the ECU via the 22 service to periodically query the installation progress of the upgrade package on the ECU. These diagnostic commands can be forwarded via NAT through the IDC. The ECU can report the installation progress to the diagnostic equipment until the upgrade package is successfully installed. The diagnostic command can be initiated via NAT forwarding through the IDC. The diagnostic equipment can continuously send diagnostic commands to the ECU via the 22 service until the ECU reports a successful upgrade, indicating that the corresponding upgrade package has been installed. This diagnostic command can be forwarded via NAT through the IDC. Once the diagnostic equipment confirms that the upgrade package has been installed, it can send a diagnostic command 11 01 to the ECU to request a restart of the ECU for a hardware reset. This diagnostic command can be forwarded via IDC NAT. After completing the hardware reset, the ECU can return a diagnostic command to the diagnostic device indicating a successful restart. This diagnostic command can be forwarded via NAT through the IDC. After confirming that the ECU has restarted successfully, the diagnostic equipment can send diagnostic commands to the ECU via the 22 service to read the corresponding software version of the ECU. This diagnostic command can be forwarded via NAT through the IDC. The ECU can send feedback on its current software version to the diagnostic equipment, allowing the equipment to confirm that the ECU software flashing was successful.
[0074] Reference Figure 6 This is a schematic diagram of the software package download process in another embodiment of the software flashing method of this application.
[0075] The download process for another software flashing method is as follows: The ECU sends an HTTP request to the IDC to download the file. Through the POST command (i.e., the first upgrade request), it obtains the download URL (Uniform Resource Locator), which is the download address of the corresponding flashing file. After receiving the request from the ECU, the IDC will pass the HTTP request through the USB link to the diagnostic tool. The diagnostic tool responds to the POST command by sending an upgrade response message to the IDC, which includes the corresponding download URL; When the IDC receives the upgrade response information sent by the diagnostic tool, it forwards the upgrade response information to the corresponding ECU, thereby forwarding the download URL to the ECU. The ECU uses the GET command to request and download the corresponding upgrade file (i.e., flashing file) based on the received download URL; After receiving the GET command from the ECU, the IDC forwards it to the diagnostic tool to download the upgrade file according to the URL.
[0076] It should be noted that the software flashing method provided in this application embodiment can be executed by a software flashing device, or a control module in the software flashing device for executing the loading software flashing method. This application embodiment uses the execution of the loading software flashing method by a software flashing device as an example to illustrate the software flashing method provided in this application embodiment.
[0077] Reference Figure 7 This is a structural block diagram of a software flashing device embodiment of this application, applied to a vehicle. The vehicle is connected to a diagnostic device via a Universal Serial Bus and a Controller Area Network (Controller Area Network) bus, and may specifically include the following modules: The upgrade request sending module 701 is used to send an upgrade request to the diagnostic device via the Universal Serial Bus in response to an upgrade command sent by the diagnostic device through the Controller Area Network (CAN) bus, so that the diagnostic device returns upgrade response information via the CAN bus in response to the upgrade request; the upgrade response information includes the download address of the flashing file corresponding to the vehicle's electronic control unit; The software flashing module 702 is used to download the corresponding flashing file according to the flashing file download address, and perform software flashing operation based on the flashing file.
[0078] Reference Figure 8 This is a structural block diagram of an embodiment of a software flashing device according to this application, applied to a diagnostic device. The diagnostic device is connected to a vehicle via a universal serial bus and a controller area network bus, and may specifically include the following modules: The upgrade instruction sending module 801 is used to send upgrade instructions to the vehicle through the controller local area network bus; The upgrade request receiving module 802 is used to receive the upgrade request sent by the vehicle's diagnostic controller in response to the upgrade command via a universal serial bus; The upgrade response information return module 803 is used to respond to the upgrade request by returning upgrade response information to the vehicle's diagnostic controller via the universal serial bus; the upgrade response information includes a flashing file download address, which enables the vehicle's electronic control unit to download the corresponding flashing file according to the flashing file download address and perform a software flashing operation based on the flashing file.
[0079] The software flashing device in this application embodiment can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.
[0080] The software flashing device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.
[0081] The software writing device provided in this application embodiment can achieve... Figures 1 to 6 The various processes implemented by the software flashing device in the method embodiment will not be described again here to avoid repetition.
[0082] The software flashing device provided in this application embodiment can obtain a high-speed data transmission path logically connected to the vehicle's content network through a universal serial bus interface, providing a high-bandwidth transmission channel for flashing file transmission, thereby improving flashing efficiency. Furthermore, it adopts a dual-channel transmission mode, sending upgrade commands via the controller area network bus and transmitting upgrade requests, upgrade response information, and flashing files during the upgrade process via the universal serial bus. This resolves the contradiction in related technologies where a single channel cannot simultaneously handle real-time control and file output, ensuring both high-speed transmission of flashing files and real-time sending of control commands, thus enabling efficient software flashing of electronic control units.
[0083] This application also provides an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When executed by the processor, the program or instructions implement the various processes of the above-described software flashing method embodiments and achieve the same technical effects. To avoid repetition, further details are omitted here. It should be noted that the electronic device in this application includes the aforementioned mobile electronic device and non-mobile electronic device.
[0084] This application also provides a readable storage medium storing a program or instructions. When executed by a processor, the program or instructions implement the various processes of the above-described method embodiments and achieve the same technical effects. To avoid repetition, these will not be described again here. The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as a computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0085] This application also provides a vehicle that may include the electronic equipment described above.
[0086] This application also provides a computer program product containing instructions, which, when run on a computer, causes the computer to execute the various processes of the above-described software flashing method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.
[0087] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
[0088] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0089] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
Claims
1. A software flashing method, characterized in that, Applied to vehicles, where the vehicles are connected to diagnostic devices via a Universal Serial Bus and a Controller Area Network (Controller Area Network) bus, the method includes: In response to an upgrade command sent by the diagnostic device via the controller area network bus, the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, so that the diagnostic device responds to the upgrade request by returning upgrade response information via the universal serial bus; the upgrade response information includes the flashing file download address; The vehicle's electronic control unit obtains the corresponding flashing file through the universal serial bus according to the flashing file download address, and performs a software flashing operation based on the flashing file.
2. The method according to claim 1, characterized in that, Before the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, the method includes: In response to a detection command sent by the diagnostic device, the remote network driver capability of the diagnostic controller is returned to the diagnostic device via the Universal Serial Bus (USB), so that the diagnostic device loads the corresponding driver and generates a first virtual address corresponding to the diagnostic device according to the remote network driver capability, allocates a second virtual address to the diagnostic controller according to the first virtual address, and constructs a network channel on the USB according to the driver, the first virtual address, and the second virtual address; the network channel is used to transmit the upgrade request and the upgrade response information.
3. The method according to claim 1 or 2, characterized in that, In response to an upgrade command sent by the diagnostic device via the controller area network bus, the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, including: In response to an upgrade command sent by the diagnostic device via the controller local area network bus, the electronic control unit sends an upgrade request to the diagnostic controller; the upgrade request includes the address of the electronic control unit and the address of the diagnostic controller; The diagnostic controller converts the address of the electronic control unit in the upgrade request into a second virtual address of the diagnostic controller, and sends the converted upgrade request to the diagnostic device via the universal serial bus.
4. The method according to claim 2, characterized in that, Before the vehicle's diagnostic controller sends an upgrade request to the diagnostic device via the universal serial bus, the method further includes: The vehicle's diagnostic controller responds to a secure access command sent by the diagnostic device via the controller area network bus to authenticate the diagnostic device. If the authentication result is successful, the diagnostic controller switches to the target device mode in response to the mode switching command sent by the diagnostic device through the controller local area network bus; the target device mode is used to enable the diagnostic controller to communicate with the diagnostic device through the network channel on the universal serial bus. The diagnostic controller responds to an address translation command sent by the diagnostic device via the controller local area network bus and initiates the address translation function; the address translation function is used to perform the translation between the address of the electronic control unit and the second virtual address.
5. The method according to claim 4, characterized in that, The vehicle's diagnostic controller, in response to a secure access command sent by the diagnostic device via the controller area network bus, performs authentication of the diagnostic device, including: In response to a secure access command sent by the diagnostic device via the controller LAN bus, the diagnostic controller returns a random seed value to the diagnostic device, so that the diagnostic device generates an authentication key based on the random seed value. The diagnostic controller receives the authentication key sent by the diagnostic device through the controller local area network bus, and performs identity authentication on the diagnostic device based on the authentication key.
6. The method according to claim 1, characterized in that, The vehicle's electronic control unit obtains the corresponding flashing file via the universal serial bus according to the flashing file download address, and performs a software flashing operation based on the flashing file, including: The vehicle's electronic control unit generates a corresponding file retrieval request based on the flashing file download address, and sends the file retrieval request to the vehicle's diagnostic controller; the file retrieval request includes the address of the electronic control unit and the address of the diagnostic controller; The diagnostic controller converts the address of the electronic control unit in the file retrieval request into a second virtual address of the diagnostic controller, and sends the converted file retrieval request to the diagnostic device via the universal serial bus; the file retrieval request is used to enable the diagnostic device to return the flash file to the diagnostic controller via the universal serial bus; The electronic control unit downloads the flashing file; In response to the download progress query command sent by the diagnostic device through the controller local area network bus, the electronic control unit determines the corresponding flash file download progress, and sends the flash file download progress to the diagnostic device through the controller local area network bus, so that the diagnostic device can determine whether the electronic control unit has completed the download of the flash file based on the flash file download progress; After the flashing file is downloaded, the electronic control unit responds to the installation command sent by the diagnostic device through the controller local area network bus and performs a flashing operation on the software of the electronic control unit based on the flashing file.
7. A software flashing method, characterized in that, Applied to diagnostic equipment, the diagnostic equipment being connected to a vehicle via a Universal Serial Bus and a Controller Area Network (Controller Area Network) bus, the method includes: Upgrade commands are sent to the vehicle via the controller local area network bus; The diagnostic controller of the vehicle receives the upgrade request sent via the Universal Serial Bus in response to the upgrade command. In response to the upgrade request, upgrade response information is returned to the vehicle's diagnostic controller via the universal serial bus; the upgrade response information includes a flash file download address, which enables the vehicle's electronic control unit to download the corresponding flash file according to the flash file download address, and perform a software flashing operation based on the flash file.
8. The method according to claim 7, characterized in that, Before receiving an upgrade request sent via Universal Serial Bus in response to the upgrade command from the vehicle's diagnostic controller, the method includes: The diagnostic command is sent to the vehicle's diagnostic controller via the universal serial bus, so that the vehicle's diagnostic controller returns the remote network drive capability of the diagnostic controller. Load the corresponding driver program according to the remote network driving capability and generate the first virtual address corresponding to the diagnostic device; A second virtual address is assigned to the diagnostic controller based on the first virtual address; A network channel is constructed on the Universal Serial Bus based on the driver, the first virtual address, and the second virtual address; the network channel is used to transmit the upgrade request and the upgrade response information.
9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the software flashing method as described in any one of claims 1-8.
10. A vehicle, characterized in that, The vehicle includes the electronic equipment as described in claim 9.