DATA PROCESSING METHOD, CONTROL DEVICE, DIAGNOSIS DEVICE, COMPUTER PROGRAM, AND ELECTRONIC DEVICE
The data processing method allows intelligent ECUs to be upgraded by receiving and storing upgrade files based on memory addresses and file paths, addressing the limitations of traditional flash programming methods and ensuring compatibility with the UDS protocol.
Patent Information
- Application Number
- JP2023542916
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-01-30
- Filing Date
- 2021-10-27
- Publication Date
- 2025-04-22
- Estimated Expiration
- 2041-10-27
AI Technical Summary
Intelligent ECUs in vehicles cannot be upgraded using traditional flash programming methods, which are based on the UDS protocol, making it impossible to implement upgrade procedures effectively.
A data processing method where the control device receives a memory address from the diagnostic device, obtains a corresponding file path, and stores the upgrade file received from the diagnostic device in that file path, allowing the upgrade operation to be implemented under UDS protocol constraints.
Enables the successful upgrade of intelligent ECUs by allowing the diagnostic device to send and store upgrade files in the control device, ensuring compatibility with the UDS protocol and improving the reliability of the upgrade process.
Smart Images

Figure 0007666873000001 
Figure 0007666873000002 
Figure 0007666873000003
Abstract
Description
[Technical field]
[0001] This application claims priority to Chinese Patent Application No. 202110131693.8, filed with the State Intellectual Property Office of China on January 30, 2021, entitled "DATA PROCESSING METHOD AND RELATED DEVICE," which is incorporated herein by reference in its entirety.
[0002] The present application relates to the vehicle field, in particular to data processing methods and related devices. [Background technology]
[0003] In the field of vehicle electronics, an electronic control unit (ECU) is a "computer" applied to a vehicle to implement functions such as vehicle status monitoring and signal processing, and is the controller of the vehicle. Currently, most vehicles perform an upgrade procedure based on the unified diagnostic services (UDS) protocol to upgrade the ECU in the vehicle. Specifically, in the programming stage in the UDS protocol, the diagnostic device sends the memory address of the upgrade file and the file size of the upgrade file to the ECU, and notifies the ECU to store the upgrade file downloaded from the diagnostic device in the location indicated by the memory address. Since the traditional ECU is based on Flash (registered trademark), the file download process is a flash programming process, and the completion of the download means the completion of the programming. The file takes effect immediately after the ECU is reset.
[0004] With the development of chip technology, Internet of Things technology and communication technology, more and more vehicles are equipped with intelligent ECUs with operating systems to implement functions such as autonomous driving and audio and video entertainment. However, the upgrade of the intelligent ECU cannot be implemented by programming the flash. As a result, the upgrade procedure based on the UDS protocol cannot be met. Summary of the Invention
[0005] The embodiments of the present application provide a data processing method and related devices. After the memory address sent by the diagnostic device is received, a file path corresponding to the memory address is obtained, and the received upgrade file is stored in the file path, that is, the upgrade file can be downloaded by the diagnostic device under the constraint of the UDS protocol to implement the upgrade operation on the control device.
[0006] In order to solve the above technical problems, the embodiments of the present application provide the following technical solutions:
[0007] According to a first aspect, an embodiment of the present application provides a data processing method, and the method can be applied to a vehicle field. The method includes: in a programming stage, the control device receives a first data transmission request sent by the diagnostic device. Under the constraint of the UDS protocol, the process in which the diagnostic device is used to upgrade the control device can be divided into a pre-programming stage, a programming stage, and a post-programming stage. The first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file and a file size of the upgrade file, and the upgrade file is used to upgrade the control device. Furthermore, the first data transmission request is a judgment command, and a diagnostic service identifier SID of the first data transmission request can be 0x36. The control device obtains a first file path corresponding to the first memory address, creates a first file based on an indication of the first file path, and sends an acknowledgment corresponding to the first data transmission request to the diagnostic device. The control device receives the upgrade file sent by the diagnostic device, and stores the upgrade file in the first file pointed to by the first file path. It should be noted that the file format of the first file created in this embodiment of the present application may be a file format that does not retain address information, i.e., the file format may be zip or tar.gz, or another file format that does not retain address information, or it may be a file format that retains address information, such as s19 or hex.
[0008] In this implementation, after receiving the memory address sent by the diagnostic device, the control device first obtains a file path corresponding to the memory address, and then stores the upgrade file received from the diagnostic device in the file path. Since the control device can determine the storage location based on the file path, the control device can store the upgrade file sent by the diagnostic device in the file indicated by the file path, and complete the operation of storing the upgrade file. Furthermore, the control device can obtain the upgrade file through the diagnostic device under the constraint of the UDS protocol.
[0009] In a possible implementation of the first aspect, the control device obtaining a first file path corresponding to the first memory address includes the control device obtaining a stored target mapping relationship and obtaining a first file path corresponding to the first memory address based on the target mapping relationship, where the target mapping relationship indicates a one-to-one correspondence between at least one memory address and at least one file path. Furthermore, since there are multiple storage units in the memory of the vehicle, a memory address needs to be assigned to each storage unit to find each storage unit, and the memory address indicates the number of the storage unit in the memory. The target mapping relationship may be pre-configured in the vehicle when the control device is delivered from the factory, or the target mapping relationship may be updated during an upgrade process of the control device.
[0010] In this implementation, the control device pre-stores a target mapping relationship, which indicates a one-to-one correspondence between at least one memory address and at least one file path, so that the control device can quickly obtain a first file path corresponding to a first memory address based on the stored target mapping relationship, which helps increase the speed of obtaining the first file path.
[0011] In a possible implementation of the first aspect, before the control device receives the first data transmission request sent by the diagnostic device, the method further includes, in the programming step, the control device receives a second data transmission request sent by the diagnostic device, the second data transmission request is used to request the control device to receive a flash drive program, and the second data transmission request holds a second memory address corresponding to the flash drive program and a size of the flash drive program. The control device obtains a stored target mapping relationship (i.e., a correspondence relationship between a memory address and a file path), obtains a second file path corresponding to the second memory address based on the target mapping relationship, creates a second file based on an indication of the second file path, and sends an acknowledgement corresponding to the second data transmission request to the diagnostic device, where the first file path and the second file path are different file paths. The control device receives the flash drive program sent by the diagnostic device, and stores the flash drive program in a second file pointed to by the second file path.
[0012] In this implementation, in the programming stage, after receiving a request to transmit the flash drive program, the control device can obtain a second file path (i.e., the starting storage address of the flash drive program in memory) corresponding to the second memory address, and store the flash drive program in the file pointed to by the second file path. That is, under the constraint of the UDS protocol, the control device can also store the flash drive program in memory to ensure that the processing manner of the control device meets the requirements of the UDS protocol, thereby reducing the stop in the upgrade process of the control device. This helps to improve the success rate of upgrading the control device by using the diagnostic device.
[0013] In a possible implementation of the first aspect, after the control device stores the upgrade file in the file pointed to by the first file path, the method further comprises: when the control device is in a programming session, the control device receives a reset request sent by the diagnostic device, and sends an acknowledgment corresponding to the reset request to the diagnostic device, where the reset request may specifically indicate the control device to perform a hard reset, i.e., to the control device to perform a restart operation. The programming session, the extended diagnostic session, and the default session are three different session modes of the control device. The sub-service code of the programming session is 02. The control device can only be upgraded in the programming session. In response to the received reset request, the control device determines whether a programming dependency check operation is performed by the control device, and when it determines that the programming dependency check operation is performed by the control device, triggers the execution of an upgrade operation on the control device based on the upgrade file, and executes a reset operation on the control device. The programming dependency check operation is intended to check the validity and compatibility of the downloaded upgrade file. In the UDS protocol, the programming dependency is converted into an English validate application, and the meaning of the programming dependency can be understood with reference to the UDS protocol.
[0014] In this implementation, in the UDS protocol, after the non-control device completes downloading the upgrade file, the upgrade operation for the control device is considered to be completed. However, for the control device, the upgrade operation of the control device cannot be completed by only locally downloading the upgrade file. In this embodiment of the present application, after the control device receives a reset request, the trigger of the upgrade operation is selected to be automatically completed, ensuring that the upgrade process of the control device is fully automated.
[0015] In a possible implementation of the first aspect, the control device determining whether a programming dependency check operation is performed by the control device includes the control device determining whether a programming dependency check operation is performed by the control device based on a target record, where the target record indicates whether a programming dependency check operation is performed by the control device. The target record may specifically be represented as a flag bit in the control device, which records whether a programming dependency check is performed. When the value of the flag bit is a first value, it is indicated that the programming dependency check operation is performed by the control device; or when the value of the flag bit is a second value, it is indicated that the programming dependency check operation is performed by the control device, where the first value and the second value are different values. If the target record indicates that the programming dependency check operation is performed by the control device, the control device updates the target record again after determining whether the programming dependency check operation is performed by the control device, and the updated target record indicates that the programming dependency check operation is not performed by the control device.
[0016] In a possible implementation of the first aspect, the control device performing an upgrade operation on the control device based on the upgrade file includes the control device performing a decompression operation on the downloaded upgrade file to obtain a plurality of upgrade sub-files, configuration information, and a system version number. The configuration information indicates an installation manner of each upgrade sub-file in the upgrade file. The control device installs the plurality of upgrade sub-files in the upgrade file in a corresponding manner based on the indication of the configuration information, and completes the upgrade operation on the control device.
[0017] In a possible implementation of the first aspect, the method further includes, in the programming step, a step in which the control device receives a third diagnostic instruction sent by the diagnostic device, the third diagnostic instruction instructs the control device to perform an erase operation on data in the first storage space. The first storage space is a storage location of an upgrade file that the diagnostic device wants to send to the control device, and the third diagnostic instruction holds a first memory address and a size of the space that the diagnostic device needs the control device to erase, i.e., the start point of the first storage space is the first memory address, and the size of the first storage space is the size of the space that the diagnostic device needs the control device to erase (i.e., the size of the upgrade file of the control device). In response to the received third diagnostic instruction, the control device obtains a first file path corresponding to the first memory address based on the target mapping relationship, and performs a delete operation on the third file pointed to by the first file path. It should be noted that the third file and the first file are different files, the third file is a file created by the control device in a previous upgrade process, and when the delete operation is performed on the third file, the control device has not created the first file.
[0018] In a possible implementation of the first aspect, the method further comprises, during the programming step, the control device receiving a third diagnostic command sent by the diagnostic device, the third diagnostic command instructing the control device to perform an erase operation on the data in the first storage space, and in response to the received third diagnostic command, the control device sending an acknowledgement corresponding to the third diagnostic command directly to the diagnostic device, the acknowledgement corresponding to the third diagnostic command indicating that the erase operation on the data in the first storage space is completed by the control device.
[0019] In a possible implementation of the first aspect, the method further comprises receiving a reset request when the control device is in a programming session, and in response to the received reset request, triggering a reset operation of the control device only when a programming dependency check operation is not performed by the control device.
[0020] In this implementation, when the control device is in a programming session, the control device may receive a reset request not only in the upgrade program but also in another program. Thus, the control device determines whether a programming dependency check operation is performed, and determines whether the control device is in an upgrade procedure. When it is determined that the control device is not in an upgrade procedure, the control device only performs a reset operation, does not execute the upgrade program, and only uses the upgrade file during the upgrade process, thereby ensuring that the control device performs the upgrade operation and avoiding inaccurate triggering of the upgrade operation.
[0021] In a possible implementation of the first aspect, after the control device triggers execution of an upgrade operation on the control device based on the upgrade file, the method further includes a step of setting a system version number of the control device to an invalid value when it is determined that the upgrade operation has failed, where the invalid value indicates that the upgrade operation has failed; and a step of setting the system version number of the control device to the system version number held in the upgrade file (i.e., a valid system version number) when it is determined that the upgrade operation has been successfully executed.
[0022] In this implementation, in the UDS protocol, downloading the upgrade file to the ECU is considered to complete the upgrade operation of the ECU. Therefore, the diagnostic device controls the ECU to perform a programming dependency check operation. If the programming dependency check operation passes, the diagnostic device determines that the upgrade of the ECU is successful; or, if the programming dependency check operation does not pass, the diagnostic device determines that the upgrade of the ECU is unsuccessful. In addition, in the UDS protocol, the diagnostic device determines whether the upgrade of the ECU is successful by determining whether the programming dependency check operation passes. Therefore, in the current non-intelligent ECU, according to the current UDS protocol, the upper computer does not check whether the upgrade is successful based on the system version number. In this solution, after determining that the upgrade operation is unsuccessful, the intelligent ECU sets the system version number of the intelligent ECU to an invalid value, so that the diagnostic device can check whether the upgrade of the intelligent ECU is successful in time to ensure that the upgrade of the intelligent ECU is really successful, thereby ensuring the safety of the vehicle running process.
[0023] According to a second aspect, an embodiment of the present application provides a data processing method, which can be applied to a vehicle field, the method includes: in a programming stage, a diagnostic device sends a first data transmission request to a control device, the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and the diagnostic device receives a first acknowledgement sent by the control device, and sends the upgrade file to the control device according to the first acknowledgement, and the upgrade file is stored in the first file pointed to by the first file path.
[0024] In a possible implementation of the second aspect, after the diagnostic device sends the upgrade file to the control device, the method further comprises, in a post-programming stage, the diagnostic device sending a reset request to the control device, where the reset request indicates to the control device to trigger an upgrade operation on the control device based on the upgrade file and a reset operation when the programming dependency check operation is performed.
[0025] In a possible implementation of the second aspect, the method further includes a step of the diagnostic device sending a version number query request to the control device and receiving a system version number sent by the control device, wherein when the system version number is an invalid value, it indicates that the upgrade of the control device has failed.
[0026] In the second aspect of this embodiment of the present application, the diagnostic device may further perform the steps performed by the diagnostic device in the possible implementation of the first aspect. For the specific implementation steps of the second aspect of this embodiment of the present application and the possible implementations of the second aspect, and the beneficial effects brought about by each possible implementation, please refer to the description in the possible implementations of the first aspect. Here, details will not be described again.
[0027] According to a third aspect, an embodiment of the present application provides a control device, which may be used in a vehicle field, comprising: a receiving module configured to receive a first data transmission request sent by a diagnostic device during a programming phase, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, and the upgrade file is used to upgrade the control device; an acquiring module configured to acquire a first file path corresponding to the first memory address; and a storage module configured to receive the upgrade file sent by the diagnostic device and store the upgrade file in the first file pointed to by the first file path.
[0028] In the third aspect of this embodiment of the present application, the control device may further execute the steps executed by the control device in the possible implementation of the first aspect. For the specific implementation steps of the third aspect of this embodiment of the present application and the possible implementations of the third aspect, and the beneficial effects brought about by each possible implementation, please refer to the description in the possible implementations of the first aspect. Here, the details will not be described again.
[0029] According to a fourth aspect, an embodiment of the present application provides a diagnostic device, which may be used in a vehicle field, comprising: a sending module configured to send a first data transmission request to a control device during a programming phase, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and a receiving module configured to receive a first acknowledgement sent by the control device, where the sending module is further configured to send the upgrade file to the control device based on the first acknowledgement, and the upgrade file is stored in a file pointed to by the first file path.
[0030] In the fourth aspect of this embodiment of the present application, the diagnostic device may further perform the steps performed by the diagnostic device in the possible implementation of the second aspect. For the specific implementation steps of the fourth aspect of this embodiment of the present application and the possible implementations of the fourth aspect, as well as the beneficial effects brought about by each possible implementation, please refer to the description in the possible implementations of the second aspect. Here, the details will not be described again.
[0031] According to a fifth aspect, an embodiment of the present application provides an electronic device. The electronic device may include a processor, the processor coupled to a memory, the memory storing program instructions. When the program instructions stored in the memory are executed by the processor, the data processing method according to the first or second aspect is implemented.
[0032] According to a sixth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, the computer program being capable of executing the data processing method according to the first or second aspect when executed on a computer.
[0033] According to a seventh aspect, an embodiment of the present application provides a circuit system comprising a processing circuit, the processing circuit configured to perform the data processing method according to the first or second aspect.
[0034] According to an eighth aspect, an embodiment of the present application provides a computer program, which when run on a computer enables the computer to carry out the data processing method of the first or second aspect.
[0035] According to a ninth aspect, the present invention provides a chip system. The chip system includes a processor configured to implement the functions of the above aspects, such as transmitting or processing data and / or information in the above methods. In a possible design, the chip system further includes a memory. The memory is configured to store program instructions and data required for the server or communication device. The chip system may include a chip, or may include a chip and another discrete component.
[0036] According to a tenth aspect, an embodiment of the present application provides a vehicle, comprising one or more control devices arranged in the vehicle, the control devices configured to perform the steps performed by the control devices in the data processing method of the first or second aspect.
[0037] According to an eleventh aspect, an embodiment of the present application provides a data processing system, the data processing system comprising a control device and a diagnostic device, the control device configured to perform the steps performed by the control device in the data processing method of the first or second aspect, the diagnostic device configured to perform the steps performed by the diagnostic device in the data processing method of the first or second aspect. [Brief description of the drawings]
[0038] [Figure 1a] FIG. 1 is a diagram of a system architecture of a data processing system according to an embodiment of the present application.
[0039] [Figure 1b] FIG. 2 is another system architecture diagram of a data processing system according to an embodiment of the present application.
[0040] [Diagram 2] 1 is a schematic flowchart of a data processing method according to an embodiment of the present application;
[0041] [Diagram 3] 4 is another schematic flowchart of a data processing method according to an embodiment of the present application;
[0042] [Figure 4] 4 is a schematic flow chart of a data transmission method according to an embodiment of the present application, in which a diagnostic device sends a flash drive program to an intelligent ECU;
[0043] [Diagram 5] 11 is another schematic flow chart of a diagnostic device sending a flash drive program to an intelligent ECU in a data transmission method according to an embodiment of the present application;
[0044] [Figure 6] 4 is yet another schematic flowchart of a data processing method according to an embodiment of the present application;
[0045] [Figure 7] 2 is a schematic diagram of an interface for obtaining a target instruction in a data processing method according to an embodiment of the present application;
[0046] [Figure 8] FIG. 2 is a schematic diagram of the structure of a control device according to an embodiment of the present application.
[0047] [Figure 9] FIG. 2 is a schematic diagram of another structure of a control device according to an embodiment of the present application.
[0048] [Figure 10] 1 is a schematic diagram of a structure of a diagnostic device according to an embodiment of the present application;
[0049] [Figure 11] 1 is a schematic diagram of a structure of an electronic device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0050] The following describes embodiments of the present application with reference to the accompanying drawings. Those skilled in the art can recognize that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application can also be applied to similar technical problems.
[0051] In the specification, claims and accompanying drawings of this application, the terms "first", "second", etc. are intended to distinguish between similar objects and do not necessarily indicate a particular order or sequence. It should be understood that the terms used in this manner are interchangeable in appropriate circumstances, and this is merely a method of identification used when objects having the same attributes are described in the embodiments of this application. In addition, the terms "including", "comprises" and any variations thereof are meant to cover a non-exclusive inclusion, and a process, method, system, product, or device that includes example units is not necessarily limited to these units, and may include other units that are not expressly listed or that are inherent to such a process, method, product, or device.
[0052] In embodiments of the present application, the control device is a control unit or data center of the vehicle, and may be a controller of a component of the vehicle or may be a vehicle controller, such as an electronic control unit (ECU), a vehicle control unit (VCU), a domain control unit (DCU), or a mobile data center (MDC). These control devices may have operating systems and manage memory, files, and the like. To distinguish from traditional flash-based ECUs and for ease of explanation, in embodiments of the present application, the control device may sometimes be referred to as an intelligent control device, an intelligent ECU, or the like.
[0053] Furthermore, an operating system is integrated into the intelligent ECU. The difference between the intelligent ECU and the non-intelligent ECU (which may also be referred to as a "traditional flash-based ECU", a "traditional ECU", or the like) is that in terms of software, the function of the non-intelligent ECU is simple, the non-intelligent ECU executes simple tasks by executing a simple system, and the intelligent ECU has a complex operating system and powerful parallel processing capabilities, and can execute tasks such as audio and video entertainment, assisted driving, and autonomous driving. In terms of hardware, the non-intelligent ECU includes a single micro controller unit (MCU). The central processing unit (CPU) has limited processing power and is configured with limited storage space. The intelligent ECU has a powerful CPU and more storage space, or has a complex heterogeneous computer system consisting of multiple processors.
[0054] The UDS protocol is a general vehicle diagnostic protocol defined based on the ISO15765 and ISO14229 standards. The UDS protocol defines a process in which a diagnostic device acts as a client side to upgrade (also referred to as "update") a control device, such as an ECU, in a vehicle, on a server side. The upgrade process can be divided into a pre-programming stage, a programming stage, and a post-programming stage. The diagnostic device can also be referred to as an upper computer in some scenarios. Furthermore, FIG. 1a is a diagram of a system architecture of a data processing system according to an embodiment of the present application. In FIG. 1a, an intelligent ECU on the server side and a diagnostic device on the client side are included. The process of upgrading an intelligent ECU by using a diagnostic device under the constraints of the UDS protocol is also a process in which the diagnostic device sends diagnostic commands to the intelligent ECU under the constraints of the UDS protocol to control and upgrade the intelligent ECU.
[0055] Specifically, in the programming stage, the diagnostic device sends a data transmission request to an intelligent ECU in the vehicle, and the data transmission request is used to request to start data transmission between the diagnostic device and the control device. The data transmission request holds a memory address corresponding to the upgrade file and a file size of the upgrade file. When an intelligent ECU (see below for an explanation of "intelligent ECU") is configured in the vehicle, the intelligent ECU cannot comply with the upgrade procedure based on the UDS protocol, so it cannot store the received upgrade file, i.e., the diagnostic device cannot send the upgrade file to the intelligent ECU, and as a result, the upgrade operation on the intelligent ECU cannot be completed.
[0056] To solve the problem, an embodiment of the present application provides a data processing method. In order to more intuitively understand this solution, a data processing system provided in this embodiment of the present application is first described. Figure 1b is a system architecture diagram of the data processing system according to an embodiment of the present application. As shown in Figure 1b, the data processing system includes one or more intelligent ECUs 1 and a diagnostic device 2. The one or more intelligent ECUs 1 may be configured in a vehicle, and the diagnostic device 2 is connected to the intelligent ECUs 1 through a wired network.
[0057] Specifically, under the constraint of the UDS protocol, in the programming stage, before sending the upgrade file to the intelligent ECU 1, the diagnostic device 2 first sends a data transmission request to the intelligent ECU 1, where the data transmission request holds a memory address corresponding to the upgrade file and a file size of the upgrade file. After receiving the data transmission request, the intelligent ECU 1 obtains a file path corresponding to the memory address. The intelligent ECU 1 can determine a storage location based on the file path, so that the intelligent ECU 1 can store the upgrade file sent by the diagnostic device 2 in the file pointed to by the file path, that is, the upgrade operation for the intelligent ECU 1 can be implemented by using the diagnostic device 2 under the constraint of the UDS protocol.
[0058] The diagnostic device may also be referred to as a tester. The vehicle may be a device in which an intelligent ECU is disposed, such as a car, a truck, a motorcycle, a bus, a boat, an airplane, a helicopter, a lawn mower, a recreational vehicle, a playground vehicle, a construction device, a trolley, a golf cart, a train, or a pushcart. In the present embodiment of the present application, there is no particular limitation thereon.
[0059] Specifically, in one case, multiple intelligent ECUs 1 are configured in a vehicle, and different intelligent ECUs 1 in the multiple intelligent ECUs 1 are responsible for different functions. For example, the intelligent ECU 1 may be referred to as an engine management system (EMS), and is responsible for controlling functions such as fuel injection, ignition, and torque distribution of the engine. In another example, the intelligent ECU 1 may be alternatively referred to as an automatic transmission control unit (TCU), and is mainly responsible for using different gear policies based on the driving status of the vehicle. In yet another example, for example, the intelligent ECU 1 may be alternatively referred to as a body control module (BCM), and is mainly responsible for controlling body equipment such as lamps, wipers, door locks, electric windows, skylights, and electric rearview mirrors. In still another example, the intelligent ECU 1 may also be an operating system configured to control the stability of the vehicle body, or the intelligent ECU 1 may be represented as a battery management system (BMS), or the intelligent ECU 1 may be configured to coordinate the operation of components such as an engine, a drive motor, a converter, and a power battery to improve the economy, power, and security of the vehicle, reduce exhaust pollution, and the like. The specific functions of the intelligent ECU 1 are not comprehensively described herein. It should be noted that when multiple intelligent ECUs 1 are configured in the vehicle, the diagnostic device 2 may upgrade the multiple intelligent ECUs 1 one by one.
[0060] In another case, one intelligent ECU 1 may be configured in the vehicle. The intelligent ECU 1 may be a general-purpose control system for the whole vehicle. Functions such as transmitter management, battery management, body control, and transmission control unit control are integrated in the intelligent ECU 1. It should be noted that FIG. 1b shows only one intelligent ECU 1, but the number of intelligent ECUs 1 actually included in the vehicle should be determined based on the actual configuration of the vehicle.
[0061] Before describing the data processing method provided in the embodiment of the present application in detail, the main improvements in the embodiment of the present application are first described. Figure 2 is a schematic flow chart of the data processing method according to the embodiment of the present application. In the left sub-schematic diagram of Figure 2, C1: the intelligent ECU switches the session mode to a programming session. C2: the intelligent ECU performs a security access operation. C3: the intelligent ECU records a diagnostic device fingerprint. C4: the intelligent ECU locally downloads a flash drive program and performs an integrity check on the flash drive program. Specifically, as shown in the top right sub-schematic diagram of Figure 2, C4 includes: D1: the intelligent ECU receives a second data transmission request sent by the diagnostic device, where the second data transmission request carries a second memory address. D2: the intelligent ECU obtains a second file path corresponding to the second memory address, and creates a second file according to an indication of the second file path. D3: the intelligent ECU sends an acknowledgment corresponding to the second data transmission request to the diagnostic device. D4: The intelligent ECU receives a second file transfer command sent by the diagnostic device, where the second file transfer command holds a flash drive program. D5: The intelligent ECU writes the data in the second file transfer command to a second file indicated by a second file path. D6: The intelligent ECU sends an acknowledgement corresponding to the second file transfer command to the diagnostic device. C5: The intelligent ECU performs an erase operation on the data in the first storage space. C6: The intelligent ECU downloads the upgrade file locally and performs an integrity check on the upgrade file. Specifically, as shown in the lower right sub-schematic diagram of FIG. 2, C6 includes: E1: The intelligent ECU receives a first data transmission request sent by the diagnostic device, where the first data transmission request holds a first memory address.E2: The intelligent ECU obtains a first file path corresponding to the first memory address, and creates a first file according to an indication of the first file path. E3: The intelligent ECU sends an acknowledgment corresponding to the first data transmission request to the diagnostic device. E4: The intelligent ECU receives a first file transfer command sent by the diagnostic device, where the first file transfer command holds an upgrade file. E5: The intelligent ECU writes the data in the first file transfer command to the first file indicated by the first file path. E6: The intelligent ECU sends an acknowledgment corresponding to the first file transfer command to the diagnostic device. C7: The intelligent ECU performs a programming dependency check operation. From FIG. 2, it can be seen that the main improvement in the embodiment of the present application is the two steps of downloading the upgrade file and the flash drive program by the intelligent ECU. It should be noted that the main problem to be solved in the embodiment of the present application is how to send the upgrade file to the intelligent ECU by using the diagnostic device under the constraint of the UDS protocol, that is, the main steps in this embodiment of the present application are E1 to E6. The example of FIG. 2 is merely for facilitating understanding of the present solution and is not intended to limit the present solution.
[0062] The process of upgrading an ECU by using a diagnostic device defined in the UDS protocol is divided into a pre-programming step, a programming step, and a post-programming step. However, the data processing method provided in the embodiment of the present application is mainly modified in the programming step and the post-programming step. In consideration of the completeness of the solution, the following first describes in order the specific implementation procedures of the programming step and the post-programming step in the data processing method provided in the embodiment of the present application.
[0063] 1. Programming Phase
[0064] In this embodiment of the present application, please refer to Fig. 3. Fig. 3 is a schematic flow chart of a data processing method according to an embodiment of the present application. As shown in Fig. 3, in the programming stage, steps 308 to 310 are executed, so that an upgrade file can be sent to the intelligent ECU by using a diagnostic device under the constraint of the UDS protocol. In order to facilitate understanding of this solution, the entire programming stage will be described in detail below by executing steps 301 to 311. The data processing method provided in this embodiment of the present application may include the following steps:
[0065] 301: A diagnostic device sends a first diagnostic command to an intelligent ECU, where the first diagnostic command instructs the intelligent ECU to enter a programming session.
[0066] In this embodiment of the present application, after determining that the intelligent ECU completes the pre-programming stage operation, the diagnostic device may send a first diagnostic command to the intelligent ECU. The first diagnostic command instructs the intelligent ECU to switch a current session mode to a programming session. Furthermore, the name of the first diagnostic command in the UDS protocol may be a Diagnostic Session Control command.
[0067] In response to the received first diagnostic command, the intelligent ECU first recognizes whether the intelligent ECU is currently in a programming session. If the intelligent ECU is in a programming session, the intelligent ECU directly sends a positive response to the diagnostic device, where the positive response is used to notify the diagnostic device that the intelligent ECU has entered a programming session. If the intelligent ECU is not in a programming session, the intelligent ECU performs a session mode switching operation to switch the current session mode of the intelligent ECU to the programming session. If the intelligent ECU successfully switches to the programming session, the intelligent ECU sends a positive response to the diagnostic device. If the intelligent ECU fails to switch to the programming session, the intelligent ECU sends a negative response to the diagnostic device, where the negative response is used to notify the diagnostic device that the intelligent ECU has failed to enter the programming session.
[0068] If the diagnostic device receives a positive response sent by the intelligent ECU, step 302 is executed. If the diagnostic device receives a negative response sent by the intelligent ECU, the program upgrade for the intelligent ECU is stopped. Optionally, the diagnostic device may further output prompt information, where the prompt information is used to notify a person skilled in the art that the program upgrade for the intelligent ECU has failed.
[0069] The formats of the first diagnostic command, the positive response, and the negative response all follow the definition of the related commands in the UDS protocol. The first diagnostic command holds a diagnostic service identifier (SID). The intelligent ECU may determine the operation type corresponding to the diagnostic command based on the SID held in the first diagnostic command. Furthermore, in the ECU upgrade procedure defined in the UDS protocol, the interaction between the diagnostic device and the ECU is in the form of diagnostic commands, and each diagnostic command holds an SID. The UDS protocol defines the correspondence between different SIDs and different types of operations. In an example, the SID held in the first diagnostic command may be 0x10. In another example, if the SID held in the diagnostic command sent by the diagnostic device to the intelligent ECU is 0x34, the diagnostic command indicates that the diagnostic device sends a data transmission start request to the intelligent ECU. In another example, if the SID held in the diagnostic command sent by the diagnostic device to the intelligent ECU is 0x36, the diagnostic command indicates that the diagnostic device sends data that needs to be stored to the intelligent ECU. It should be understood that the examples in this specification are merely for facilitating understanding of the present solution, and all SIDs are not comprehensive. In addition, under the constraints of the UDS protocol, different vehicle manufacturers may have slightly different definitions of the correspondence between SIDs and operation types, and the meaning of each SID depends on the actual application scenario.
[0070] If the intelligent ECU's reply to the first diagnostic command is a positive response, the SID of the positive response may be specifically represented as the SID held in the first diagnostic command + 0x40. If the intelligent ECU's reply to the first diagnostic command is a negative response, the SID of the negative response may be 0x7F, and the negative response may further include the SID of the first diagnostic command.
[0071] Programming session, extended diagnostic session, and default session are three different session modes of an intelligent ECU. The sub-service code for programming session is 02. An intelligent ECU can only be upgraded in a programming session.
[0072] 302: The diagnostic device sends a second diagnostic command to the intelligent ECU, where the second diagnostic command instructs the intelligent ECU to perform a security access operation.
[0073] In this embodiment of the present application, after determining that the intelligent ECU has entered a programming session, the diagnostic device sends a second diagnostic command to the intelligent ECU, where the second diagnostic command instructs the intelligent ECU to perform a security access operation. Further, the name of the second diagnostic command in the UDS protocol may be a Security Access command, and the SID held in the second diagnostic command may be 0x27.
[0074] Specifically, the second diagnostic command may be used to request to obtain a seed. In response to the received second diagnostic command, the intelligent ECU may randomly generate a seed and send the seed to the diagnostic device. The diagnostic device performs a calculation on the received seed based on a preconfigured first algorithm to obtain a first key. The diagnostic device sends the first key to the intelligent ECU. The intelligent ECU obtains a second key through calculation and compares the first key obtained from the diagnostic device with the second key. If the first key matches the second key, it is determined that the diagnostic device has successfully authenticated the security access, and the intelligent ECU sends a positive response to the diagnostic device. If the first key does not match the second key, it is determined that the diagnostic device has not successfully authenticated the security access, and the intelligent ECU sends a negative response to the diagnostic device. The second key is obtained after the intelligent ECU performs a calculation on the seed based on the second algorithm.
[0075] If the diagnostic device receives a positive response, it is determined that the diagnostic device has successfully authenticated the security access of the intelligent ECU, and step 303 is executed. If the diagnostic device receives a negative response, it is determined that the diagnostic device has not successfully authenticated the security access of the intelligent ECU, and the upgrade procedure of the intelligent ECU is stopped. Optionally, the diagnostic device may output prompt information to inform a person skilled in the art that the diagnostic device has not succeeded in authenticating the security access of the intelligent ECU. It should be noted that step 301 shows the rules for generating a positive response and a negative response, and the positive responses corresponding to different types of diagnostic commands have different contents, and the negative responses corresponding to different types of diagnostic commands have different contents. In particular, the specific contents of the positive response / negative response sent by the intelligent ECU to the diagnostic device should be determined with reference to the actual situation. This is not limited in this embodiment of the present application. In addition, when the diagnostic device is a secure diagnostic device, the first algorithm and the second algorithm configured in the diagnostic device are the same algorithm, and as a result, the first key obtained by the diagnostic device through calculation is consistent with the second key.
[0076] 303: The intelligent ECU receives a diagnostic device fingerprint sent by the diagnostic device.
[0077] In this embodiment of the present application, after the diagnostic device determines that the security access of the intelligent ECU has been successfully authenticated, the diagnostic device sends a diagnostic device fingerprint to the intelligent ECU. Correspondingly, after receiving the diagnostic device fingerprint sent by the diagnostic device, the intelligent ECU writes the diagnostic device fingerprint into the memory of the vehicle. The diagnostic device fingerprint may be specifically represented as a string, and the diagnostic device fingerprint holds the identification information of the diagnostic device. The identification information is used to uniquely identify the diagnostic device.
[0078] Optionally, the diagnostic device fingerprint further holds a corresponding time of storing the identification information of the diagnostic device, which may be the time of generating the diagnostic device fingerprint, the time of transmitting the diagnostic device fingerprint, or another time, but is not limited thereto in this specification.
[0079] If the intelligent ECU successfully writes the diagnostic device fingerprint to the vehicle's memory, the intelligent ECU sends a positive response to the diagnostic device. After receiving the positive response, the diagnostic device recognizes that the intelligent ECU successfully stores the diagnostic device fingerprint locally, and then step 304 is executed. If the intelligent ECU fails to write the diagnostic device fingerprint to the vehicle's memory, the intelligent ECU sends a negative response to the diagnostic device. After receiving the negative response, the diagnostic device recognizes that the intelligent ECU fails to store the diagnostic device fingerprint locally. In this case, the upgrade procedure of the intelligent ECU is stopped. Optionally, the diagnostic device may output prompt information to inform a person skilled in the art that the diagnostic device fails to store the diagnostic device fingerprint locally.
[0080] 304: The intelligent ECU receives a second data transmission request sent by the diagnostic device, where the second data transmission request is used to request the ECU to receive a flash drive program, and the second data transmission request holds a second memory address.
[0081] In this embodiment of the present application, after determining that the intelligent ECU has locally stored the diagnostic device fingerprint, the diagnostic device sends a second data transmission request to the intelligent ECU. In response, the intelligent ECU receives the second data transmission request sent by the diagnostic device.
[0082] The second data transmission request is used to request the intelligent ECU to receive the flash drive program, and the second data transmission request holds a file size of the flash drive program and a second memory address corresponding to the flash drive program. Furthermore, the name of the second data transmission request in the UDS protocol may be a request download command, and the SID of the second data transmission request may be 0x34.
[0083] The intelligent ECU is integrated into the vehicle, and the second memory address is a memory address. Furthermore, since there are many storage units in the memory of the vehicle, in order to find each storage unit, a memory address needs to be assigned to each storage unit, and the memory address indicates the number of the storage unit in the memory.
[0084] The second data request further holds the size of the data to be transmitted (i.e., the flash drive program). For example, the second data request holds "the size of the data to be transmitted is 10240 bytes." It should be understood that the examples in this specification are not used to limit the present solution.
[0085] 305: The intelligent ECU obtains a second file path corresponding to the second memory address.
[0086] In this embodiment of the present application, the intelligent ECU may pre-store a target mapping relationship, where the target mapping relationship indicates a one-to-one correspondence between at least one memory address and at least one file path. For example, the second memory address is 0x12345678, and the second file path corresponding to the second memory address is / home / upgrade / upgrade file.zip. It should be understood that the example memory address and the example file path in this specification are merely for ease of understanding, and are not intended to limit this solution.
[0087] Furthermore, the target mapping relationship may be pre-configured in the vehicle when the intelligent ECU is delivered from the factory, or the target mapping relationship may be updated during an upgrade process of the intelligent ECU.
[0088] After obtaining the second memory address, the intelligent ECU obtains a second file path corresponding to the second memory address based on the correspondence between the memory address and the file path, and creates a second file based on an indication of the second file path, where the second file may store the flash drive program sent by the diagnostic device. After successfully creating the second file, the intelligent ECU sends an acknowledgement to the diagnostic device, where the acknowledgement instructs the diagnostic device to start sending the flash drive program to the intelligent ECU.
[0089] It should be noted that the file format of the second file created in this embodiment of the present application may be a file format that retains address information, such as s19 or hex, or may be a file format that does not retain address information, i.e., the file format may be zip, tar.gz, or another file format that does not retain address information, which is not limited in this embodiment of the present application.
[0090] In addition, before the upgrade file is used to upgrade the intelligent ECU, the first storage space (described in a subsequent step 307) stores the upgrade file used in the previous upgrade. In the UDS protocol, the diagnostic device sends a flash drive program to the intelligent ECU to erase the upgrade file used in the previous upgrade, thereby placing the upgrade file in the first storage space.
[0091] However, in the process of storing the upgrade file in the first file pointed to by the first file path, the intelligent ECU may not perform a delete operation on the upgrade file of the intelligent ECU before upgrading, and the new file may directly overwrite the old file. Therefore, step 305 is an optional step. If the intelligent ECU does not perform step 305, the intelligent ECU may directly send an affirmative response to the diagnostic device after receiving the second data transmission request by performing step 304. The first file is an empty file newly created by the intelligent ECU, and the intelligent ECU storing the upgrade file in the first file means that the intelligent ECU places a plurality of files included in the upgrade file in the first file. To understand this concept more intuitively, the first file may be similar to a container, and the plurality of files included in the upgrade file are placed in the container (first file).
[0092] 306: The diagnostic device sends a flash drive program to the intelligent ECU.
[0093] In this embodiment of the present application, after receiving an acknowledgment for the second data transmission request, the diagnostic device starts to send the flash drive program to the intelligent ECU. The diagnostic device can send the entire flash drive program to the intelligent ECU by sending one or more second data transmission commands to the intelligent ECU. The name of the second data transmission command in the UDS protocol can be a request download (transfer data) command, and the SID held in the second data transmission command can be 0x36.
[0094] Specifically, in the implementation, when the intelligent ECU executes step 305, in step 306, the intelligent ECU receives the flash drive program sent by the diagnostic device and stores the flash drive program in a second file pointed to by the second file path. Furthermore, the diagnostic device sends a second data transmission command to the intelligent ECU, and the second data transmission command holds part / all of the data in the flash drive program. If the size of the flash drive program exceeds the upper limit of the amount of data that can be held in one data transmission command, the one second data transmission command holds part of the data in the flash drive program. If the size of the flash drive program does not exceed the upper limit of the amount of data that can be held in one data transmission command, the one second data transmission command holds all of the data in the flash drive program.
[0095] The intelligent ECU stores the data in the received second data transmission command in a second file, and sends an affirmative response to the diagnostic device. After receiving the affirmative response, the diagnostic device determines whether the transmission of the flash drive program is completed. If the transmission of the flash drive program is not completed, the diagnostic device continues to send the next second data transmission command to the intelligent ECU, that is, repeats the transmission process of one or more files. If the transmission of the flash drive program is completed, the diagnostic device sends a download termination request to the intelligent ECU, and the name of the download termination request in the UDS protocol may be a request transfer exit command, and the SID held in the download termination request may be 0x37. In response to the received download termination request, the intelligent ECU sends an affirmative response corresponding to the download termination request to the diagnostic device, and after receiving the affirmative response corresponding to the download termination request, the diagnostic device determines that the transmission operation of the flash drive program is completed.
[0096] To understand this solution more intuitively, please refer to FIG. 4. FIG. 4 is a schematic flow chart of a diagnostic device sending a flash drive program to an intelligent ECU in a data transmission method according to an embodiment of the present application. A1: The diagnostic device sends a file transfer command to the intelligent ECU, and the SID held in the file transfer command is 0x36. A2: After receiving the file transfer command, the intelligent ECU writes the data held in the file transfer command to a second file indicated by a second file path. A3: The intelligent ECU sends an affirmative response corresponding to the file transfer command to the diagnostic device, and the SID held in the affirmative response is 0x76. A4: After receiving an affirmative command corresponding to the file transfer command, the diagnostic device determines whether the transmission of the flash drive program is completed; if the transmission of the flash drive program is not completed, step A1 is executed again, so that the next file transfer command is sent to the intelligent ECU; or if the transmission of the flash drive program is completed, step A5 is executed. A5: The diagnostic device sends a download termination request to the intelligent ECU, and the SID held in the download termination request is 0x37. A6: The intelligent ECU sends a positive response corresponding to the download termination request to the diagnostic device, and the SID held in the positive response is 0x77. After receiving the positive response corresponding to the download termination request, the diagnostic device determines that the flash drive program transmission operation is completed. It should be understood that the example in FIG. 4 is merely for facilitating understanding of this solution, and is not intended to limit this solution.
[0097] In this embodiment of the present application, in the programming stage, after receiving a request to transmit the flash drive program, the intelligent ECU may obtain a second file path corresponding to a second memory address, and store the flash drive program in a second file pointed to by the second file path. That is, under the constraint of the UDS protocol, the intelligent ECU may also store the flash drive program in memory to ensure that the processing manner of the intelligent ECU meets the requirements of the UDS protocol, thereby reducing the stoppage in the upgrade process of the intelligent ECU. This helps to improve the success rate of upgrading the intelligent ECU by using the diagnostic device.
[0098] In another implementation, if the intelligent ECU does not execute step 305, step 306 includes the intelligent ECU receiving a second data transmission command sent by the diagnostic device, and directly sending an acknowledgment corresponding to the second data transmission command to the diagnostic device in response to the received second data transmission command. After receiving the acknowledgment corresponding to the second data transmission command, the diagnostic device determines whether the transmission of the flash drive program is completed. If the transmission of the flash drive program is not completed, the diagnostic device continues to send the next second data transmission command to the intelligent ECU. If the transmission of the flash drive program is completed, the diagnostic device sends a download termination request to the intelligent ECU. In response to the received download termination request, the intelligent ECU sends an acknowledgment corresponding to the download termination request to the diagnostic device, and after receiving the acknowledgment corresponding to the download termination request, the diagnostic device determines that the transmission operation of the flash drive program is completed.
[0099] To understand this solution more intuitively, please refer to FIG. 5. FIG. 5 is a schematic flow chart of a diagnostic device sending a flash drive program to an intelligent ECU in a data transmission method according to an embodiment of the present application. A1: The diagnostic device sends a file transfer command to the intelligent ECU, and the SID held in the file transfer command is 0x36. B2: After receiving the file transfer command, the intelligent ECU directly sends an acknowledgment corresponding to the file transfer command to the diagnostic device, and the SID held in the acknowledgment is 0x76. B3: After receiving the acknowledgment corresponding to the file transfer command, the diagnostic device judges whether the transmission of the flash drive program is completed; if the transmission of the flash drive program is not completed, step B1 is executed again, so that the next file transfer command is sent to the intelligent ECU; or if the transmission of the flash drive program is completed, step B4 is executed. B4: The diagnostic device sends a download end request to the intelligent ECU, and the SID held in the download end request is 0x37. B5: The intelligent ECU sends an affirmative response corresponding to the download end request to the diagnostic device, and the SID held in the affirmative response is 0x77. After receiving the affirmative response corresponding to the download end request, the diagnostic device determines that the flash drive program transmission operation is completed. It should be understood that the example in FIG. 5 is merely for facilitating understanding of this solution, and is not intended to limit this solution.
[0100] In this embodiment of the present application, when the intelligent ECU creates a new file, the old file can be directly overwritten, i.e., the intelligent ECU does not need to perform an erase operation by storing a flash drive program and calling up the flash drive program, i.e., the intelligent ECU does not store a flash drive program, which helps to improve the utilization of the storage space of the intelligent ECU, avoids the steps of mapping a second memory address to a second file path and storing a flash drive program, and helps to improve the efficiency of the entire upgrade process of the intelligent ECU.
[0101] After determining that the intelligent ECU has completed the operation of downloading the flash drive program, the diagnostic device sends an integrity check command to the intelligent ECU, where the integrity check command holds a first check code. In response to the received integrity check command, the intelligent ECU calculates a second check code based on the preconfigured target check algorithm and the downloaded flash drive program. The intelligent ECU compares the first check code with the second check code to determine whether the first check code matches the second check code. If the first check code matches the second check code, the intelligent ECU determines that the data of the downloaded flash drive program is complete and sends a positive response to the diagnostic device, where the positive response indicates that the data of the flash drive program downloaded by the intelligent ECU is complete, and triggers the execution of step 307. If the first check code does not match the second check code, the intelligent ECU sends a negative response to the diagnostic device, where the negative response indicates that the data of the flash drive program downloaded by the intelligent ECU is incomplete, and triggers the diagnostic device to stop the upgrade procedure of the intelligent ECU. The target check algorithm may include, but is not limited to, a cyclic redundancy check (CRC) algorithm, an exclusive-OR check algorithm, a message-digest algorithm 5 (MD5) check algorithm, another check algorithm, or the like, which is not intended as a limitation herein.
[0102] 307: The intelligent ECU receives a third diagnostic command sent by the diagnostic device, where the third diagnostic command instructs the intelligent ECU to perform an erase operation on the data in the first storage space.
[0103] In this embodiment of the present application, after determining that the intelligent ECU has acquired the completed flash drive program, the diagnostic device may send a third diagnostic command to the intelligent ECU, where the third diagnostic command commands the intelligent ECU to perform an erase operation on the data in the first storage space. The first storage space is a storage location of the upgrade file that the diagnostic device wants to send to the intelligent ECU, and the third diagnostic command holds a first memory address and a size of the space that the diagnostic device needs the intelligent ECU to erase, i.e., the start point of the first storage space is the first memory address, and the size of the first storage space is the size of the space that the diagnostic device needs the intelligent ECU to erase (i.e., the size of the upgrade file of the intelligent ECU). Furthermore, the name of the third diagnostic command in the UDS protocol may be an erase memory command.
[0104] Specifically, in the implementation, in step 307, in response to the received third diagnostic command, the intelligent ECU obtains a first file path corresponding to the first memory address based on the target mapping relationship, and performs a delete operation on the third file pointed to by the first file path. It should be noted that the third file and the first file are different files, the third file is a file created by the intelligent ECU in a previous upgrade process, and when the delete operation is performed on the third file, the intelligent ECU did not create the first file. After the third file pointed to by the first file path is successfully deleted, a positive response corresponding to the third diagnostic command is sent to the diagnostic device. If the deletion of the third file pointed to by the first file path fails, a negative response corresponding to the third diagnostic command is sent to the diagnostic device, and the negative response corresponding to the third diagnostic command indicates that the intelligent ECU fails to erase the data in the first storage space. In response to the received negative response corresponding to the third diagnostic command, the diagnostic device stops the program upgrade for the intelligent ECU. In this embodiment of the present application, the data at the storage address of the upgrade file is explicitly erased, and the file at the storage address of the upgrade file is explicitly deleted. That is, when the intelligent ECU performs a storage operation on the received upgrade file in a subsequent stage, the data is stored in a blank position. In this solution, a delete operation on the file is performed first, and a storage operation on the file is performed after a period of time. Compared with directly using a new upgrade file to overwrite an old file, this helps reduce the probability of errors in the data storage process.
[0105] In another implementation, in step 307, in response to the received third diagnostic command, the intelligent ECU sends an affirmative response corresponding to the third diagnostic command to the diagnostic device, where the affirmative response corresponding to the third diagnostic command indicates that the erase operation on the data in the first storage space has been completed by the intelligent ECU.
[0106] 308: The intelligent ECU receives a first data transmission request sent by the diagnostic device, where the first data transmission request is used to request the intelligent ECU to receive an upgrade file, and the first data transmission request holds a first memory address.
[0107] In this embodiment of the present application, after receiving an affirmative response corresponding to the third diagnostic command sent by the intelligent ECU, the diagnostic device sends a first data transmission request to the intelligent ECU, the first data transmission request is used to request the intelligent ECU to receive an upgrade file, and the first data transmission request holds a first memory address corresponding to the upgrade file.
[0108] Moreover, since the first data transmission request and the second data transmission request determine the same type of command, the SID held in the first data transmission request can be the same as the SID held in the second data transmission request. The concept of the first memory address is similar to that of the second memory address, and the first memory address and the second memory address are each a memory address. For detailed explanation, please refer to the explanation in the above steps. The details will not be described again in this specification.
[0109] 309: The intelligent ECU obtains a first file path corresponding to the first memory address.
[0110] In this embodiment of the present application, the intelligent ECU may pre-store a target mapping relationship. For the meaning of the target mapping relationship, please refer to the description of step 305. In response to the received first data transmission request, the intelligent ECU obtains a first file path corresponding to the first memory address based on the target mapping relationship (i.e., the corresponding relationship between the memory address and the file path), and creates a first file based on the first file path, and the first file is used to store the upgrade file sent by the diagnostic device. After successfully creating the first file, the intelligent ECU sends an affirmative response corresponding to the first data transmission request to the diagnostic device, and the affirmative response corresponding to the first data transmission request indicates the diagnostic device to start sending the upgrade file to the intelligent ECU. It should be noted that, similar to the second file, the file format of the first file created in this embodiment of the present application may be a file format that does not hold address information, i.e., the file format may be zip or tar.gz, or may be a file format that holds address information, such as s19 or hex.
[0111] If the intelligent ECU fails to create the first file, the intelligent ECU sends a negative response corresponding to the first data transmission request to the diagnostic device, and the negative response corresponding to the first data transmission request indicates the intelligent ECU to refuse to download the upgrade file. Further, for example, the file path corresponding to the first memory address does not exist in the target mapping relationship, or in another example, the intelligent ECU fails to create the first file in the process of creating the first file. As a result, the intelligent ECU cannot succeed in creating the first file. After receiving the negative response corresponding to the first data transmission request, the diagnostic device stops the program upgrade for the intelligent ECU.
[0112] Optionally, the diagnostic device outputs prompt information to inform a person skilled in the art that the program upgrade for the intelligent ECU is stopped because the intelligent ECU refuses to download the upgrade file.
[0113] In this implementation, the intelligent ECU pre-stores a target mapping relationship, which indicates a one-to-one correspondence between at least one memory address and at least one file path, so that the intelligent ECU can quickly obtain a first file path corresponding to a first memory address based on the stored target mapping relationship, which helps increase the speed of obtaining the first file path.
[0114] 310: The intelligent ECU receives the upgrade file sent by the diagnostic device, and stores the upgrade file in a first file pointed to by a first file path.
[0115] In this embodiment of the present application, after receiving an affirmative response corresponding to the first data transmission request, the diagnostic device starts to send the upgrade file to the intelligent ECU. The diagnostic device may send the entire upgrade file to the intelligent ECU by sending one or more first data transmission commands to the intelligent ECU. The intelligent ECU receives the upgrade file sent by the diagnostic device and stores the upgrade file in a first file pointed to by a first file path.
[0116] Specifically, similar to the implementation of step 306, the diagnostic device sends a first data transmission command to the intelligent ECU, where the first data transmission command carries part / all of the data of the upgrade file. The intelligent ECU stores the file content carried in the first data transmission command in a first file, and sends an affirmative response to the diagnostic device. After receiving the affirmative response, the diagnostic device determines whether the transmission of the upgrade file is completed. If the transmission of the upgrade file is not completed, the diagnostic device continues to send the next first data transmission command to the intelligent ECU, that is, repeats the process of transmitting part of the data of the upgrade file. If the transmission of the upgrade file is completed, the diagnostic device sends a download termination request to the intelligent ECU. In response to the received download termination request, the intelligent ECU sends an affirmative response corresponding to the download termination request to the diagnostic device, and after receiving the affirmative response corresponding to the download termination request, the diagnostic device determines that the transmission operation of the upgrade file is completed.
[0117] For further explanation, see the explanation for step 306. The difference is that in step 306, the diagnostic device sends the flash drive program to the intelligent ECU and stores the flash drive program in a second file, while in step 310, the diagnostic device sends the upgrade file to the intelligent ECU and stores the upgrade file in a first file.
[0118] Similar to step 306, after completing the operation of downloading the upgrade file, the intelligent ECU also needs to check the integrity of the upgrade file. Specifically, after determining that the operation of downloading the upgrade file is completed by the intelligent ECU, the diagnostic device sends an integrity check command to the intelligent ECU, where the integrity check command holds a third check code. In response to the received integrity check command, the intelligent ECU calculates a fourth check code based on the preconfigured target check algorithm and the downloaded upgrade file. The intelligent ECU compares the third check code with the fourth check code, and determines whether the third check code is consistent with the fourth check code. If the third check code is consistent with the fourth check code, the intelligent ECU determines that the data of the downloaded upgrade file is complete, and sends a positive response to the diagnostic device, where the positive response indicates that the data of the upgrade file downloaded by the intelligent ECU is complete, and triggers the execution of step 311. If the third check code does not match the fourth check code, the intelligent ECU sends a negative response to the diagnostic device, where the negative response indicates that the data in the upgrade file downloaded by the intelligent ECU is incomplete, and triggers the diagnostic device to stop the upgrade procedure of the intelligent ECU.
[0119] 311: The intelligent ECU receives a fourth diagnostic command sent by the diagnostic device, where the fourth diagnostic command instructs the intelligent ECU to perform a programming dependency check operation.
[0120] In this embodiment of the present application, after determining that the intelligent ECU has downloaded the complete upgrade file, the diagnostic device sends a fourth diagnostic command to the diagnostic device to instruct the intelligent ECU to perform a programming dependency check operation. The programming dependency check operation aims to check the validity and compatibility of the downloaded upgrade file. In the UDS protocol, the programming dependency is converted to the English word validate application, and the meaning of the programming dependency can be understood with reference to the UDS protocol. For example, the programming dependency check operation includes, but is not limited to, an operation of checking whether the downloaded upgrade file is compatible with this intelligent ECU hardware, an operation of whether the digital signature of the upgrade file downloaded by the intelligent ECU is accurate, or another operation. It should be noted that the specific content checked in a specific programming dependency check operation may be defined by the manufacturer of the intelligent ECU with reference to the actual situation, and is not limited in this specification.
[0121] When completing the programming dependency check operation and determining that the current software and hardware environment of the intelligent ECU is normal, the intelligent ECU sends a positive response corresponding to the fourth diagnostic instruction to the diagnostic device, and after receiving the positive response corresponding to the fourth diagnostic instruction, the diagnostic device triggers the execution of steps of the post-programming phase (specific steps are described in subsequent embodiments). When the intelligent ECU fails to complete the programming dependency check operation, the intelligent ECU sends a negative response corresponding to the fourth diagnostic instruction to the diagnostic device, and after receiving the negative response corresponding to the fourth diagnostic instruction, the diagnostic device stops the program upgrade for the intelligent ECU.
[0122] After successfully executing the programming dependency check operation, the intelligent ECU further updates the target record, where the target record records whether the programming dependency check operation is executed by the intelligent ECU, and the updated target record indicates that the programming dependency check operation is executed by the intelligent ECU. The target record may specifically be represented as a flag bit in the intelligent ECU, which records whether the programming dependency check is executed. When the value of the flag bit is a first value, it is indicated that the programming dependency check operation is executed by the intelligent ECU; or when the value of the flag bit is a second value, it is indicated that the programming dependency check operation is not executed by the intelligent ECU, where the first value and the second value are different values. For example, the first value may be true, and the second value may be false. In another example, the first value may be 1, and the second value may be 0. The first value and the second value are not inclusive in this specification. It should be noted that the target record may alternatively be represented in another form, which is not limited in this specification.
[0123] In this implementation, after receiving the memory address sent by the diagnostic device, the intelligent ECU first obtains a file path corresponding to the memory address, and then stores the upgrade file received from the diagnostic device in the file path. The intelligent ECU can determine the storage location based on the file path, so that the intelligent ECU can store the upgrade file sent by the diagnostic device in the file indicated by the file path, thereby completing the operation of storing the upgrade file. Furthermore, the control device can obtain the upgrade file through the diagnostic device under the constraint of the UDS protocol.
[0124] According to the UDS protocol, the process of upgrading an intelligent ECU includes a programming stage, a post-programming stage, and a pre-programming stage. Since the post-programming stage is also improved in this embodiment of the present application, the following first describes the specific execution stages of the post-programming stage.
[0125] 2. Post-programming stage
[0126] In this embodiment of the present application, please refer to Figure 6. Figure 6 is a schematic flowchart of a data processing method according to an embodiment of the present application. The data processing method provided in this embodiment of the present application may include the following steps:
[0127] 601: A diagnostic device sends a reset request to an intelligent ECU.
[0128] In this embodiment of the present application, after determining that the intelligent ECU has downloaded the complete upgrade file, the diagnostic device sends a reset request to the intelligent ECU. The reset request may specifically indicate to the intelligent ECU to perform a hard reset, i.e., to perform a restart operation. Furthermore, the name of the reset request in the UDS protocol may be an ECU reset command, and the SID of the reset request may be 0x11.
[0129] In response to the received reset request, the intelligent ECU sends an acknowledgement corresponding to the reset request to the diagnostic device. If the intelligent ECU is in a programming session at this time, the intelligent ECU triggers the execution of step 602. Note that the diagnostic device may also send a reset request to the intelligent ECU without being in an upgrade program of the intelligent ECU, and step 602 is executed only when the intelligent ECU is in a programming session. Otherwise, the intelligent ECU performs the reset operation directly.
[0130] 602: The intelligent ECU determines whether a programming dependency checking operation is performed, and if a programming dependency checking operation is performed, executes step 603; or if a programming dependency checking operation is not performed, executes step 607.
[0131] In this embodiment of the present application, after sending an affirmative response corresponding to the reset request to the diagnostic device, the intelligent ECU reads the target record mentioned in step 311 in the embodiment corresponding to FIG. 3 to determine whether a programming dependency check operation is performed by the intelligent ECU. If it is determined based on the target record that a programming dependency check operation is performed by the intelligent ECU, step 603 is executed, and the target record is updated again, where the updated target record indicates that a programming dependency check operation is not performed by the intelligent ECU. For example, the value of the flag bit is changed from true to false, and in another example, the value of the flag bit is changed from 1 to 0. If it is determined that a programming dependency check operation is not performed, step 607 is executed.
[0132] 603: The intelligent ECU performs an upgrade operation based on the upgrade file, and performs a reset operation on the intelligent ECU.
[0133] In this embodiment of the present application, the intelligent ECU performs an upgrade operation on the intelligent ECU based on the upgrade file. Specifically, the intelligent ECU performs a decompression operation on the downloaded upgrade file to obtain a plurality of upgrade sub-files, configuration information, and a system version number. The configuration information indicates an installation manner of each upgrade sub-file in the upgrade file. The intelligent ECU installs the plurality of upgrade sub-files in the upgrade file individually in a corresponding manner based on the indication of the configuration information, completes the upgrade operation on the intelligent ECU, and then performs a reset operation (i.e., a restart operation) on the intelligent ECU.
[0134] In this embodiment of the present application, in the UDS protocol, after a non-intelligent ECU completes downloading the upgrade file, the upgrade operation for the ECU is considered to be completed. However, for an intelligent ECU, only downloading the upgrade file locally cannot complete the upgrade operation for the intelligent ECU. In this embodiment of the present application, after the intelligent ECU receives a reset request, the trigger of the upgrade operation is selected to be automatically completed, ensuring that the upgrade process of the intelligent ECU is fully automated.
[0135] It should be noted that steps 602 and 603 are optional steps. If steps 602 and 603 are not performed, after the intelligent ECU downloads the upgrade file locally, a person skilled in the art may manually trigger the intelligent ECU to perform the upgrade operation based on the upgrade file.
[0136] It should be noted that when performing a reset (i.e., restart) operation, the intelligent ECU switches the session mode from a programming session to an extended diagnostic session, adjusts the communication mode of the intelligent ECU to receive and transmit all types of packets normally, enables diagnostic trouble code (DTC) detection and DTC storage functions, and switches the session mode from an extended diagnostic session to a default session.
[0137] According to the UDS protocol, in the pre-programming stage, the diagnostic device sends a communication control command to the intelligent ECU to adjust the communication mode of the intelligent ECU to prohibit receiving and transmitting non-diagnostic packets. Therefore, after the intelligent ECU completes the upgrade operation, the communication mode of the intelligent ECU needs to be adjusted to normally receive and transmit all kinds of packets.
[0138] According to the UDS protocol, in the pre-programming stage, the diagnostic device further sends a control DTC setting command to the intelligent ECU to disable the DTC detection function and DTC storage function of the intelligent ECU, so that the DTC detection function and DTC storage function need to be re-enabled after the intelligent ECU completes the upgrade operation.
[0139] 604: The intelligent ECU determines whether the upgrade is successful, and if the upgrade is successful, executes step 605; or if the upgrade is not successful, executes step 606.
[0140] In this embodiment of the present application, when performing a reset operation, i.e., after being restarted, the intelligent ECU reads the data in the upgrade file. If the intelligent ECU can be restarted successfully, i.e., no failure occurs in the restart process, it indicates that the upgrade of the intelligent ECU is successful. If a failure occurs in the restart process of the intelligent ECU, it indicates that the upgrade of the intelligent ECU fails. For example, the failure in the restart process may be a failure in switching a storage system partition of the intelligent ECU, a failure in starting some applications in the intelligent ECU, or another type of failure, which is not comprehensive in this specification. It should be noted that if the upgrade of the intelligent ECU fails, some functions of the intelligent ECU will fail. The above failures are detected in the restart process of the intelligent ECU, and the failure of some functions of the intelligent ECU will not cause a failure in starting the intelligent ECU.
[0141] 605: The intelligent ECU updates a system version number of the intelligent ECU.
[0142] In this embodiment of the present application, the intelligent ECU stores a current system version number of the intelligent ECU. After it is determined that the upgrade operation is successful, the system version number held in the upgrade file is obtained, and the system version number of the intelligent ECU is updated to the system version number held in the upgrade file (i.e., a valid system version number). For example, the system version number may be S00001, S00002, S00003, or another version number. The examples in this specification are merely for facilitating understanding of the present solution, and are not intended to limit the present solution.
[0143] 606: The intelligent ECU sets the intelligent ECU's system version number to an invalid value.
[0144] In this embodiment of the present application, after determining that the upgrade operation has failed, the intelligent ECU sets the system version number of the intelligent ECU to an invalid value, where the invalid value indicates that the upgrade operation has failed. For example, the invalid value may be 000000, FFFFFF, or another value, which is not inclusive in this specification.
[0145] 607: The intelligent ECU performs only the reset operation.
[0146] In this embodiment of the present application, when the intelligent ECU is in a programming session, after receiving a reset request and determining based on the target record that the programming dependency check is not performed, the intelligent ECU determines that the intelligent ECU is not in an upgrade program and only performs a reset operation.
[0147] When the intelligent ECU is in a programming session, the intelligent ECU may receive not only the upgrade program but also a reset request in another program. Therefore, the intelligent ECU determines whether a programming dependency check operation is performed to determine whether the intelligent ECU is in an upgrade procedure. When it is determined that the intelligent ECU is not in an upgrade procedure, the intelligent ECU only performs a reset operation and does not execute the upgrade program, ensuring that the intelligent ECU performs the upgrade operation by only using the upgrade file during the upgrade process, and avoiding inaccurate triggering of the upgrade operation.
[0148] 608: The diagnostic device sends a get version number command to the intelligent ECU, where the get version number command is used to obtain a current system version number of the intelligent ECU.
[0149] In some embodiments of the present application, the diagnostic device may obtain a target command entered by a user and, in response to the target command, transmit a version number obtainment command to the intelligent ECU. In response, the intelligent ECU may receive the version number obtainment command transmitted by the diagnostic device.
[0150] For the process of the diagnostic device acquiring the target command input by the user, please refer to the following description. In one case, the target command is an acquisition command for the current system version number of the intelligent ECU. Specifically, in an implementation, the diagnostic device is configured with a display, and an icon used to receive the target command is pre-configured on the display. In this case, the user may perform a tap operation on the icon to input the target command, the user may drag the icon to a predefined position on the display to input the target command, the user may perform a double tap operation on the icon to input the target command, or the like. In another implementation, the user may directly send the target command to the diagnostic device through a wired or wireless network. It should be understood that the examples in this specification are merely for facilitating understanding of this solution, and are not used to limit the manner in which the diagnostic device acquires the target command.
[0151] In another case, the target instruction is an instruction indicating whether the intelligent ECU has successfully completed the upgrade operation, i.e., the target instruction is an instruction that triggers the diagnostic device to determine whether the intelligent ECU has successfully completed the upgrade operation. Specifically, similar to the above case, the diagnostic device may obtain the target instruction through a display, or may obtain the instruction through a wired network or a wireless network. The specific implementation is not described again in this specification.
[0152] For a more intuitive understanding of this solution, please refer to FIG. 7. FIG. 7 is a schematic diagram of an interface for acquiring a target command in a data processing method according to an embodiment of the present application. FIG. 7 includes a left subdiagram and a right subdiagram. In the left schematic diagram of FIG. 7, F1 indicates an icon used to acquire a target command. In the left subdiagram of FIG. 7, the target command is a command used to trigger the intelligent ECU to acquire a current system version number. When the diagnostic device receives a tap operation for F1, the target command input by the user is deemed to be acquired. In the right subdiagram of FIG. 7, G1 indicates an icon used to acquire a target command. In the right subdiagram of FIG. 7, an example is illustrated in which the target command is a command used to trigger the diagnostic device to determine whether the intelligent ECU has successfully completed the upgrade operation. When the diagnostic device receives a tap operation for G1, the target command input by the user is deemed to be acquired. It should be understood that the example in FIG. 7 is merely for facilitating an understanding of the present solution, and is not intended to limit the present solution.
[0153] 609: The diagnostic device receives the current system version number sent by the intelligent ECU.
[0154] In some embodiments of the present application, the intelligent ECU transmits the current system version number of the intelligent ECU to the diagnostic device in response to the received target command. In one case, the target command is the version number of the intelligent ECU. In an implementation, after receiving the current system version number of the intelligent ECU, the diagnostic device may output the system version number of the intelligent ECU through a display, so that a user may determine that the upgrade of the intelligent ECU has failed based on the system version number. In another implementation, the diagnostic device may transmit the current system version number of the intelligent ECU to a user through a wireless network or a wired network.
[0155] In another case, the target instruction is an instruction indicating whether the intelligent ECU has successfully completed the upgrade operation. After receiving the system version number sent by the intelligent ECU, the diagnostic device determines whether the system version number of the intelligent ECU is an invalid value; if the system version number of the intelligent ECU is an invalid value, the intelligent ECU outputs first prompt information, where the first prompt information is used to notify a user that the upgrade of the intelligent ECU has failed; or if the system version number of the intelligent ECU is not an invalid value, the intelligent ECU outputs second prompt information, where the second prompt information is used to notify a user that the upgrade of the intelligent ECU has succeeded.
[0156] Furthermore, the diagnostic device may directly output the first prompt information or the second prompt information through a display, where the first prompt information and the second prompt information may be specifically represented in the form of a text box, a voice, an icon, or the like, which is not limited herein. Alternatively, the diagnostic device may transmit the first prompt information or the second prompt information to the user through a wireless network or a wired network, which is not limited herein.
[0157] In this embodiment of the present application, in the UDS protocol, downloading the upgrade file to the ECU is considered to complete the upgrade operation of the ECU. Therefore, the diagnostic device controls the ECU to perform a programming dependency check operation. If the programming dependency check operation passes, the diagnostic device determines that the upgrade of the ECU is successful; or, if the programming dependency check operation does not pass, the diagnostic device determines that the upgrade of the ECU is unsuccessful. In addition, in the UDS protocol, the diagnostic device determines whether the upgrade of the ECU is successful by determining whether the programming dependency check operation passes. Therefore, in the current non-intelligent ECU, according to the current UDS protocol, the upper computer does not check whether the upgrade is successful based on the system version number. In this solution, after determining that the upgrade operation is unsuccessful, the intelligent ECU sets the system version number of the intelligent ECU to an invalid value, so that the diagnostic device can check whether the upgrade of the intelligent ECU is successful in time to ensure that the upgrade of the intelligent ECU is really successful, thereby ensuring the safety of the vehicle running process.
[0158] Based on the embodiment corresponding to Figures 2 to 7, in order to better implement the above-mentioned solution in the embodiment of the present application, the following further provides a related device configured to implement the above-mentioned solution. Specifically, Figure 8 is a schematic diagram of the structure of a control device according to the embodiment of the present application. The control device 800 includes: a receiving module 801 configured to receive a first data transmission request sent by a diagnostic device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, and the upgrade file is used to upgrade the control device; an acquiring module 802 configured to acquire a first file path corresponding to the first memory address; and a storage module 803 configured to receive the upgrade file sent by the diagnostic device and store the upgrade file in the first file pointed to by the first file path.
[0159] In a possible design, the obtaining module 802 is specifically configured to obtain a first file path corresponding to the first memory address based on a correspondence relationship between the memory addresses and the file paths.
[0160] In a possible design, the receiving module 801 is further configured to receive a second data transmission request sent by the diagnostic device, where the second data transmission request is used to request the control device to receive the flash drive program, where the second data transmission request holds a second memory address corresponding to the flash drive program; the acquiring module 802 is further configured to acquire a second file path corresponding to the second memory address; the storage module 803 is further configured to receive the flash drive program sent by the diagnostic device and store the flash drive program in a second file pointed to by the second file path.
[0161] In a possible design, as shown in FIG. 9, FIG. 9 is a schematic diagram of the structure of an electronic control unit control device according to an embodiment of the present application. The receiving module 801 is further configured to receive a reset request sent by the diagnostic device when the control device is in a programming session. The control device 800 further includes an upgrade module 804 configured to determine that a programming dependency check operation has been performed by the control device, perform an upgrade operation based on an upgrade file, and perform a reset operation in response to the received reset request.
[0162] In a possible design, as shown in FIG. 9, the receiving module 801 is further configured to receive a reset request when the control device is in a programming session, and the control device 800 further includes a reset module 805 configured to, in response to the received reset request, determine that a programming dependency check operation is not performed by the control device and trigger only the reset operation.
[0163] In a possible design, as shown in FIG. 9 , the control device 800 further includes a setting module 806 configured to set a system version number of the control device to an invalid value when it is determined that the upgrade operation has failed to be executed, where the invalid value indicates that the upgrade operation has failed.
[0164] It should be noted that the contents such as information exchanges and execution processes between modules / units in the control device 800 are based on the same concept as those in the method embodiments corresponding to Figures 2 to 7 in this application. For specific contents, please refer to the description of the steps performed by the intelligent ECU in the above method embodiments in this application. Here, details will not be described again.
[0165] An embodiment of the present application further provides a diagnostic device. Figure 10 is a schematic diagram of the structure of a diagnostic device according to an embodiment of the present application. The diagnostic device 1000 includes a sending module 1001 configured to send a first data transmission request to a control device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and a receiving module 1002 configured to receive a first acknowledgement sent by the control device, where the sending module 1001 is further configured to send the upgrade file to the control device based on the first acknowledgement, and the upgrade file is stored in the first file pointed to by the first file path.
[0166] In a possible design, the sending module 1001 is further configured to send a reset request to the control device, where the reset request indicates to the control device to trigger an upgrade operation and a reset operation based on the upgrade file when a programming dependency check operation is performed.
[0167] In a possible design, the sending module 1001 is further configured to send a version number query request to the control device, and the receiving module 1002 is further configured to receive a system version number sent by the control device, where when the system version number is an invalid value, it indicates that the upgrade of the control device has failed.
[0168] It should be noted that the contents such as information exchanges and execution processes between modules / units in the diagnostic device 1000 are based on the same concept as the method embodiments corresponding to Figures 2 to 7 in this application. For specific contents, please refer to the description of the steps performed by the diagnostic device in the above method embodiments in this application. Here, details will not be described again.
[0169] The electronic device according to the embodiment of the present application will be described below. FIG. 11 is a schematic diagram of the structure of the electronic device according to the embodiment of the present application. When the control device 800 described in the embodiment corresponding to FIG. 8 or FIG. 9 is deployed on the electronic device 1100, in order to implement the function of the intelligent ECU in the embodiment corresponding to FIG. 2 to FIG. 7, the electronic device 1100 can be specifically represented as a vehicle. When the diagnostic device 1000 described in the embodiment corresponding to FIG. 10 is deployed on the electronic device 1100, in order to implement the function of the diagnostic device in the embodiment corresponding to FIG. 2 to FIG. 7, the electronic device 1100 can be specifically represented as a terminal device such as a mobile phone, a tablet computer, a notebook computer, or a desktop computer. This is not limited in this specification. Specifically, the electronic device 1100 includes a receiver 1101, a transmitter 1102, a processor 1103, and a memory 1104 (the electronic device 1100 can include one or more processors 1103, and one processor is used as an example in FIG. 11). The processor 1103 may include an application processor 11031 and a communication processor 11032. In some embodiments of the present application, the receiver 1101, the transmitter 1102, the processor 1103, and the memory 1104 may be connected through a bus or in another manner.
[0170] The memory 1104 may include read-only memory and random access memory and may provide instructions and data to the processor 1103. A portion of the memory 1104 may further include non-volatile random access memory (NVRAM). The memory 1104 stores processor and operating instructions, executable modules or data structures, or a subset or extended set thereof. The operating instructions may include various operating instructions for implementing various operations.
[0171] The processor 1103 controls the operation of the electronic device. In certain applications, the components of the electronic device are coupled together through a bus system. In addition to a data bus, the bus system may further include a power bus, a control bus, a status signal bus, etc. However, for clarity of explanation, various types of buses will be referred to as a bus system in the figures.
[0172] The methods disclosed in the above embodiments of the present application may be applied to or implemented by the processor 1103. The processor 1103 may be an integrated circuit chip and has a signal processing function. In the implementation process, each step of the above method may be completed by using an integrated logic circuit of hardware in the processor 1103 or an instruction in the form of software. The processor 1103 may be a general-purpose processor, a digital signal processor (DSP), a microprocessor, or a microcontroller, and may further include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor 1103 may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc. The steps of the method disclosed with reference to the embodiments of the present application can be directly performed and achieved by using a hardware decode processor, or can be performed and achieved by using a combination of hardware and software modules in the decode processor. The software modules may be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory 1104, and the processor 1103 reads the information in the memory 1104 and realizes the steps in the aforementioned method in combination with the hardware of the processor.
[0173] The receiver 1101 may be configured to receive input numeric or textual information and generate signal inputs related to relevant setting and function control of the electronic device. The transmitter 1102 may be configured to output the numeric or textual information through the first interface. The transmitter 1102 may further be configured to send commands to the disk group through the first interface to modify data in the disk group. The transmitter 1102 may further include a display device, such as a display.
[0174] In this embodiment of the present application, in one case, the processor 1103 is configured to execute the data processing method performed by an intelligent ECU in an embodiment corresponding to Figures 2 to 7. In another case, the processor 1103 is configured to execute the data processing method performed by a diagnostic device in an embodiment corresponding to Figures 2 to 7.
[0175] It should be noted that the specific manner in which the processor 1103 executes the above steps is based on the same concept as the method embodiment corresponding to Figure 2 and Figure 7 in this application. The technical effect brought about by the specific manner is the same as the method embodiment corresponding to Figure 2 and Figure 7 in this application. For the specific content, please refer to the description in the above method embodiment in this application. Here, the details will not be described again.
[0176] An embodiment of the present application further provides a computer program product, which when executed on a computer enables the computer to perform the steps performed by an intelligent ECU in the method described in the embodiments shown in Figures 2 to 7, or enables the computer to perform the steps performed by a diagnostic device in the method described in the embodiments shown in Figures 2 to 7.
[0177] The embodiment of the present application further provides a computer-readable storage medium, which stores a program used for signal processing, and when the program is executed on a computer, the computer is capable of executing the steps performed by an intelligent ECU in the method described in the embodiment shown in Figures 2 to 7, or the computer is capable of executing the steps performed by a diagnostic device in the method described in the embodiment shown in Figures 2 to 7.
[0178] The electronic device, intelligent ECU, or diagnostic device provided in the embodiments of the present application may specifically be a chip. The chip includes a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, a pin, or a circuit. The processing unit may execute computer-executable instructions stored in the storage unit, and the chip in the electronic device executes the data processing method described in the embodiments shown in FIG. 2 or FIG. 7. Optionally, the storage unit may be a storage unit in the chip, for example, a register or a cache; or the storage unit may be a storage unit located outside the chip in the wireless access device, for example, a read-only memory (ROM), another type of static storage device that can store static information and instructions, or a random access memory (RAM).
[0179] An embodiment of the present application further provides a vehicle, comprising one or more control devices configured in the vehicle, the control devices configured to perform the steps performed by the intelligent ECU in the methods described in the embodiments shown in Figures 2 to 7.
[0180] An embodiment of the present application further provides a data processing system, the data processing system including a control device and a diagnostic device, the control device configured to perform steps performed by the intelligent ECU in the methods described in the embodiments shown in Figures 2 to 7, and the diagnostic device configured to perform steps performed by the diagnostic device in the methods described in the embodiments shown in Figures 2 to 7.
[0181] The processor referred to anywhere above may be a general purpose central processing unit, a microprocessor, an ASIC, or one or more integrated circuits configured to control program execution of the method in the first aspect.
[0182] In addition, it should be noted that the described device embodiments are merely exemplary. Units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, located in one location or distributed across multiple network units. Some or all of these modules may be selected according to actual needs to achieve the objectives of the solutions of the embodiments. In addition, in the accompanying drawings of the device embodiments provided by the present application, the connection relationships between modules indicate that the modules have communication connections with each other, which may be specifically implemented as one or more communication buses or signal cables.
[0183] Based on the above implementation description, those skilled in the art can clearly understand that the present application can be implemented by software in addition to the necessary universal hardware, or by dedicated hardware, including dedicated integrated circuits, dedicated CPUs, dedicated memories, dedicated components, and the like. Generally, any function that can be performed by a computer program can be easily implemented by using corresponding hardware. Furthermore, the specific hardware structure used to achieve the same function can be in various forms, such as in the form of an analog circuit, a digital circuit, or a dedicated circuit. However, for the present application, in most cases, a software program implementation is a better implementation. Based on such understanding, the technical solution of the present application can be essentially or partly contributed to the prior art can be implemented in the form of a software product. The computer software product includes a plurality of instructions for instructing a computer device (which can be a personal computer, a training device, or a network device) to execute the method in the embodiment of the present application, which is stored in a readable storage medium such as a computer floppy disk, a USB flash drive, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.
[0184] All or some of the above embodiments may be implemented using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, all or some of the embodiments may be implemented in the form of a computer program product.
[0185] A computer program product includes one or more computer instructions. When the computer program instructions are loaded into a computer and executed, all or part of the procedures or functions according to the embodiments of the present application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, training device, or data center to another website, computer, training device, or data center in a wired (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio, or microwave) manner. The computer-readable storage medium may be any available medium accessible by a computer, or a data storage device, such as a training device or data center, that incorporates one or more available media. The usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, or a magnetic tape), an optical medium (eg, a DVD), a semiconductor medium (eg, a Solid State Disk (SSD)), or the like. [Other possible items] (Item 1) receiving, by a control device, a first data transmission request sent by a diagnostic device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, and the upgrade file is used to upgrade the control device; obtaining, by the control device, a first file path corresponding to the first memory address; and receiving, by the control device, the upgrade file transmitted by the diagnostic device, and storing the upgrade file in a first file pointed to by the first file path; A data processing method comprising: (Item 2) The step of obtaining a first file path corresponding to the first memory address by the control device includes: obtaining, by the control device, the first file path corresponding to the first memory address based on a correspondence between memory addresses and file paths; The method according to item 1, comprising: (Item 3) Prior to the step of receiving, by the control device, the first data transmission request transmitted by the diagnostic device, the method further comprises: receiving, by the control device, a second data transmission request sent by the diagnostic device, where the second data transmission request is used to request the control device to receive a flash drive program, the second data transmission request carrying a second memory address corresponding to the flash drive program; obtaining, by the control device, a second file path corresponding to the second memory address; and receiving, by the control device, the flash drive program transmitted by the diagnostic device and storing the flash drive program in the second file pointed to by the second file path. 3. The method according to item 1 or 2, comprising: (Item 4) After the step of storing, by the control device, the upgrade file in a first file pointed to by the first file path, the method further comprises: receiving, by the controlling device when the controlling device is in a programming session, a reset request sent by the diagnostic device; and determining, by the control device, in response to the received reset request, that a programming dependency check operation is to be performed by the control device; performing, by the control device, an upgrade operation based on the upgrade file; and performing a reset operation. 3. The method according to item 1 or 2, comprising: (Item 5) The method further comprises: receiving a reset request by the controlling device when the controlling device is in a programming session; and determining, by the controlling device, in response to the received reset request of the controlling device, that the controlling device will not perform a programming dependency check operation and triggering only a reset operation; 3. The method according to item 1 or 2, comprising: (Item 6) After the step of performing, by the control device, an upgrade operation based on the upgrade file, the method further comprises: setting a system version number of the control device to an invalid value when it is determined that the upgrade operation has failed, wherein the invalid value indicates that the upgrade operation has failed. The method of claim 4, comprising: (Item 7) sending, by the diagnostic device, a first data transmission request to a control device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and receiving, by the diagnostic device, a first acknowledgment sent by the control device, and sending, based on the first acknowledgment, the upgrade file to the control device, where the upgrade file is stored in a first file pointed to by the first file path; A data processing method comprising: (Item 8) 8. The method of claim 7, wherein after the step of sending the upgrade file to the control device by the diagnostic device, the method further comprises the step of sending a reset request by the diagnostic device to the control device, wherein the reset request indicates to the control device to trigger an upgrade operation and a reset operation based on the upgrade file when a programming dependency check operation is performed. (Item 9) The method further comprises: sending, by the diagnostic device, a version number query request to the control device and receiving a system version number sent by the control device, where an invalid value of the system version number indicates a failure of the upgrade of the control device; 9. The method according to item 7 or 8, comprising: (Item 10) A control device, a receiving module configured to receive a first data transmission request sent by a diagnostic device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, and the upgrade file is used to upgrade the control device; an acquisition module configured to acquire a first file path corresponding to the first memory address; and a storage module configured to receive the upgrade file sent by the diagnostic device and store the upgrade file in a first file pointed to by the first file path; A control device comprising: (Item 11) 11. The control device of claim 10, wherein the acquisition module is specifically configured to acquire the first file path corresponding to the first memory address based on a correspondence between a memory address and a file path. (Item 12) The receiving module is further configured to receive a second data transmission request sent by the diagnostic device, where the second data transmission request is used to request the control device to receive a flash drive program, and the second data transmission request carries a second memory address corresponding to the flash drive program; The obtaining module is further configured to obtain a second file path corresponding to the second memory address; the storage module is further configured to receive the flash drive program transmitted by the diagnostic device and store the flash drive program in a second file pointed to by the second file path. Item 12. A control device according to item 10 or 11. (Item 13) The receiving module is further configured to receive a reset request sent by the diagnostic device when the controlling device is in a programming session; The control device further includes an upgrade module configured to, in response to the received reset request, determine that a programming dependency check operation is performed by the control device, perform an upgrade operation based on the upgrade file, and perform a reset operation. Item 12. A control device according to item 10 or 11. (Item 14) The receiving module is further configured to receive a reset request when the controlling device is in a programming session; the control device further comprising a reset module configured to, in response to the received reset request, determine that the control device will not perform a programming dependency check operation and trigger only a reset operation. Item 12. A control device according to item 10 or 11. (Item 15) The control device further comprises a setting module configured to set a system version number of the control device to an invalid value when it is determined that the upgrade operation has failed, the invalid value indicating that the upgrade operation has failed. (Item 16) a sending module configured to send a first data transmission request to a control device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and a receiving module configured to receive a first acknowledgment transmitted by the control device; the transmission module is further configured to transmit the upgrade file to the control device based on the first acknowledgment, the upgrade file being stored in a first file pointed to by the first file path. Diagnostic devices. (Item 17) Item 18. The diagnostic device of item 16, wherein the sending module is further configured to send a reset request to the control device, the reset request indicating to the control device to trigger an upgrade operation and a reset operation based on the upgrade file when a programming dependency check operation is performed. The sending module is further configured to send a version number query request to the control device; 18. The diagnostic device of claim 16 or 17, wherein the receiving module is further configured to receive a system version number transmitted by the control device, and when the system version number is an invalid value, indicates that an upgrade of the control device has failed. (Item 19) A computer-readable storage medium including a program, the program being executed on a computer to enable the computer to execute the method according to any one of items 1 to 6, or the computer to execute the method according to any one of items 7 to 9. (Item 20) An electronic device comprising a processor and a memory, the processor coupled to the memory; The memory is configured to store a program; The processor is configured to execute the program in the memory, such that the electronic device executes the method according to any one of claims 1 to 6, or the electronic device executes the method according to any one of claims 7 to 9. Electronic devices.
Claims
1. receiving, by a control device, a first data transmission request sent by a diagnostic device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request carrying a first memory address corresponding to the upgrade file, the upgrade file being used to upgrade the control device; obtaining, by the control device, a first file path corresponding to the first memory address; and receiving, by the control device, the upgrade file transmitted by the diagnostic device, and storing the upgrade file in a first file pointed to by the first file path; A data processing method comprising:
2. The step of obtaining, by the control device, a first file path corresponding to the first memory address, further comprises: obtaining, by the control device, the first file path corresponding to the first memory address based on a correspondence between memory addresses and file paths; The data processing method according to claim 1 , comprising:
3. Prior to the step of receiving, by the control device, the first data transmission request sent by the diagnostic device, the data processing method further comprises: receiving, by the control device, a second data transmission request sent by the diagnostic device, where the second data transmission request is used to request the control device to receive a flash drive program, the second data transmission request carrying a second memory address corresponding to the flash drive program; obtaining, by the control device, a second file path corresponding to the second memory address; and receiving, by the control device, the flash drive program sent by the diagnostic device, and storing the flash drive program in a second file pointed to by the second file path; 3. The data processing method according to claim 1, wherein the first data transmission request and the second data transmission request are based on an integrated diagnostic service protocol.
4. After the step of storing the upgrade file in a first file pointed to by the first file path by the control device, the data processing method further comprises: receiving, by the controlling device when the controlling device is in a programming session, a reset request sent by the diagnostic device; and determining, by the control device, in response to the received reset request, that a programming dependency check operation is to be performed by the control device; performing, by the control device, an upgrade operation based on the upgrade file; and performing a reset operation. The data processing method according to claim 1 or 2, comprising:
5. The data processing method further comprises: receiving a reset request by the controlling device when the controlling device is in a programming session; and determining, by the control device, in response to the received reset request, that the control device will not perform a programming dependency check operation and triggering only a reset operation; The data processing method according to claim 1 or 2, comprising:
6. After the step of performing an upgrade operation by the control device based on the upgrade file, the data processing method further includes: setting a system version number of the control device to an invalid value when it is determined that the upgrade operation has failed, wherein the invalid value indicates that the upgrade operation has failed. The data processing method according to claim 4 , comprising:
7. sending, by the diagnostic device, a first data transmission request to a control device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and receiving, by the diagnostic device, a first acknowledgment sent by the control device, and sending, based on the first acknowledgment, the upgrade file to the control device, where the upgrade file is stored in a first file pointed to by the first file path; A data processing method comprising:
8. After the step of transmitting the upgrade file to the control device by the diagnostic device, the data processing method further comprises: sending, by the diagnostic device, a reset request to the control device, where the reset request indicates to the control device to trigger an upgrade operation based on the upgrade file and a reset operation when a programming dependency check operation is performed; The data processing method according to claim 7 , comprising:
9. The data processing method further comprises: sending, by the diagnostic device, a version number query request to the control device and receiving a system version number sent by the control device, where an invalid value of the system version number indicates a failure of the upgrade of the control device; 9. The data processing method according to claim 7, wherein the first data transmission request is based on an integrated diagnostic service protocol.
10. A control device, a receiving module configured to receive a first data transmission request sent by a diagnostic device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, and the upgrade file is used to upgrade the control device; an acquisition module configured to acquire a first file path corresponding to the first memory address; and a storage module configured to receive the upgrade file sent by the diagnostic device and store the upgrade file in a first file pointed to by the first file path; A control device comprising:
11. The control device of claim 10 , wherein the obtaining module is specifically configured to obtain the first file path corresponding to the first memory address based on a correspondence relationship between a memory address and a file path.
12. The receiving module is further configured to receive a second data transmission request sent by the diagnostic device, where the second data transmission request is used to request the control device to receive a flash drive program, and the second data transmission request carries a second memory address corresponding to the flash drive program; The obtaining module is further configured to obtain a second file path corresponding to the second memory address; the storage module is further configured to receive the flash drive program transmitted by the diagnostic device and store the flash drive program in a second file pointed to by the second file path; The control device according to claim 10 or 11, wherein the first data transmission request and the second data transmission request are based on an integrated diagnostic service protocol.
13. The receiving module is further configured to receive a reset request sent by the diagnostic device when the controlling device is in a programming session; The control device further includes an upgrade module configured to, in response to the received reset request, determine that a programming dependency check operation is performed by the control device, perform an upgrade operation based on the upgrade file, and perform a reset operation. A control device according to claim 10 or 11.
14. The receiving module is further configured to receive a reset request when the controlling device is in a programming session; the control device further comprising a reset module configured to, in response to the received reset request, determine that the control device will not perform a programming dependency check operation and trigger only a reset operation. A control device according to claim 10 or 11.
15. The control device of claim 13 , further comprising a setting module configured to set a system version number of the control device to an invalid value when it is determined that the upgrade operation has failed, the invalid value indicating that the upgrade operation has failed.
16. a sending module configured to send a first data transmission request to a control device, where the first data transmission request is used to request the control device to receive an upgrade file, the first data transmission request holds a first memory address corresponding to the upgrade file, the first memory address corresponds to a first file path, and the upgrade file is used to upgrade the control device; and a receiving module configured to receive a first acknowledgment transmitted by the control device; the transmission module is further configured to transmit the upgrade file to the control device based on the first acknowledgement, the upgrade file being stored in a first file pointed to by the first file path. Diagnostic devices.
17. The diagnostic device of claim 16 , wherein the sending module is further configured to send a reset request to the control device, the reset request indicating to the control device to trigger an upgrade operation and a reset operation based on the upgrade file when a programming dependency check operation is performed.
18. The sending module is further configured to send a version number query request to the control device; The receiving module is further configured to receive a system version number sent by the control device, and when the system version number is an invalid value, indicates that the upgrade of the control device has failed; the first data transmission request is based on an integrated diagnostic service protocol; A diagnostic device according to claim 16 or 17.
19. A computer program, which when executed on a computer enables the computer to carry out the data processing method according to any one of claims 1 to 6, or enables the computer to carry out the data processing method according to any one of claims 7 to 9.
20. An electronic device comprising a processor and a memory, the processor coupled to the memory; The memory is configured to store a program; The processor is configured to execute the program in the memory, such that the electronic device executes the data processing method according to any one of claims 1 to 6, or the electronic device executes the data processing method according to any one of claims 7 to 9. Electronic devices.
Citation Information
Patent Citations
Information processor and program
JP2016167295A
Software updating device and software updating method
JP2016170740A
Vehicle data communicating system
JP2017146655A
Updating apparatus, and updating system
JP2019101917A
Information processing apparatus, update method of information processing apparatus, and program
JP2019204152A