Automobile software upgrading system

Abstract

The invention relates to the technical field of automobile control, and particularly discloses an automobile software upgrading system which comprises an upper computer, a CAN adapter, a lower computer and control software, the control software comprises an MFC interface software control module, a CAN communication software control module and a UDS flashing software control module, the upper computer is connected with the adapter through a USB line, and the lower computer is connected with the CAN adapter through a USB line. The CAN adapter is connected with the lower computer through the OBD wire harness, and the MFC interface software control module is used for developing a software interface. According to the automobile software upgrading system, the user experience can be improved, and the automobile software can be quickly and stably upgraded.

Description

Technical Field

[0001] This invention relates to the field of automotive control technology, and more particularly to an automotive software upgrade system. Background Technology

[0002] The development of new energy vehicles has gradually emerged as a new trend. my country has clearly stated its commitment to the in-depth development of new energy vehicles, greatly promoting the development of the vehicle electronics industry. Simultaneously, people's demands for various high-end functions, driving safety, and comfort in automobiles are increasing, inevitably requiring the addition of numerous Electronic Control Units (ECUs), leading to greater difficulty in resource scheduling and functional control of the entire vehicle. For vehicle manufacturers, in-vehicle application software cannot be fully developed to meet user needs from the outset; software vulnerabilities and functional improvements are frequent occurrences. To meet customer expectations for vehicle software functionality, extensive development and testing, along with continuous software iterations and upgrades, are necessary for gradual improvement. Otherwise, immature software development and logical flaws can cause abnormal vehicle conditions, leading to safety hazards during driving. Moreover, a car's lifecycle can last up to ten years, including development and debugging, mass production, and after-sales maintenance. Vehicle manufacturers have different software requirements at each stage, necessitating frequent ECU software updates to fix software functional defects and ensure safe vehicle operation.

[0003] Traditional upgrade methods for automotive software require a BDM debugger connected to a BDM interface to download and update the ECU program during the development and debugging phase. While this method has drawbacks such as slow flashing speeds and inconvenient plugging and unplugging, it is acceptable in terms of complexity and waiting time, as this stage only involves debugging a small number of ECUs. However, once the production and after-sales phases begin, with numerous ECUs produced in bulk, the limitations of traditional upgrade methods become apparent. Furthermore, after ECU development reaches the production stage, debugging interfaces are generally no longer provided, making software upgrades extremely difficult and requiring the removal of all ECUs in the vehicle. Upgrading the software of every vehicle by removing the ECU controller would significantly increase upgrade costs. Moreover, each manufacturer has its own upgrade process, which varies considerably. Therefore, it is clear that traditional upgrade methods are unsuitable for such frequent software updates.

[0004] Many researchers have studied automotive ECU upgrade technologies, paying particular attention to upgrade efficiency and data transmission security. Achieving intelligent fault diagnosis and improving communication efficiency for diagnostic flashing have become major research directions in automotive diagnostics. These studies have led to the development of UDS software applications, especially in bootloader flashing via UDS. However, there is a lack of clear guidance among manufacturers, focusing only on basic diagnostic flashing functions, resulting in diverse and unstandardized flashing implementations. Upgrade solutions for new energy vehicle ECUs are limited, typically focusing on only one key technology in new energy vehicle software upgrades without proposing a comprehensive upgrade solution. Systems capable of directly flashing and upgrading ECUs for new energy vehicles are extremely rare. The increasing richness of software functions for automotive ECUs, coupled with errors during software development leading to various runtime problems, and the limited availability of current new energy vehicle software upgrade solutions, highlight the urgent need to improve user experience and provide a fast and stable automotive software upgrade system and method in the new energy vehicle field. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems mentioned above, and to provide an automotive software upgrade system to improve user experience and achieve fast and stable automotive software upgrades.

[0006] To achieve the above objectives, the technical solution adopted by this invention is as follows: an automotive software upgrade system, comprising a host computer, a CAN adapter, a slave computer, and control software, using a PC as the host computer and the vehicle main control board as the slave computer. The control software includes an MFC interface software control module, a CAN communication software control module, and a UDS flashing software control module. The host computer is connected to the adapter via a USB cable, and the CAN adapter is connected to the slave computer via an OBD wiring harness. The MFC interface software control module is used for software interface development. Based on a dialog box, combo box controls are used to select items and ports, button controls are used to control the start and stop of the flashing program, and triggers the resource manager to complete the selection of automotive software upgrade files. The CAN communication software control module is used to establish communication between the host computer and the slave computer, and to perform packet processing of large data, responsible for the transmission of data and commands. The UDS flashing software control module is used for access control of the ECU. The UDS flashing software control module is equipped with three functional units: diagnostics and communication management, upload and download, and routine services, and has the functions of secure access, file parsing, and program download.

[0007] Preferably, the CAN adapter uses an STM32F072C8T6 main controller, and this main controller is connected to a USB_OTC and provides a physical interface via USB_OTG, allowing a PC to connect to the adapter using a USB cable. Simultaneously, to add the host computer to the CAN network, a TJA1051 / 3 CAN transceiver is connected to the main controller to convert the CAN controller's logic signals into differential signals for CAN data transmission. Furthermore, an LED module is designed on the main controller; during data reading and writing, two LEDs, yellow and green, will flash alternately to indicate that the data is in read / write mode.

[0008] Preferably, one end of the USB cable is connected to the USB interface of the PC, and the other end is connected to the CAN adapter. The CAN adapter leads out two CAN_H and CAN_L lines to the OBD harness, and the OBD harness is connected to the main control board through the OBD interface to realize the connection between the host computer, the CAN adapter and the slave computer.

[0009] Preferably, after the PC controls the software to start, it configures the project through the software interface. After clicking "Start," it starts the flashing program. The flashing program initializes the system parameters by reading the ini configuration file and establishes communication between the host computer and the slave computer. The host computer requests access to the ECU through UDS, calculates the received ECU seed to obtain access permissions to the ECU, and parses the upgrade file. The host computer sends a download request to the ECU. If a positive response is received, it starts downloading the upgrade file and verifies the data. If the data is error-free, it flashes the ECU according to the process written in the UDS diagnostic design and updates the flashing progress in the host computer software to upgrade the vehicle software.

[0010] Preferably, the human-computer interaction interface of the control software is developed based on MFC.

[0011] Preferably, the CAN communication software control module initializes the USB and CAN by setting the system clock and baud rate. When the receive buffer receives data, the program enters an interrupt. If the received data is a CAN message, the data, ID, and frame type in the message are extracted, organized, processed, and converted before being transmitted to the PC via the USB transmit buffer. If the received data is USB data, the data is verified and valid data is extracted, then converted into a CAN message. It is determined whether the data is a configuration parameter transmitted from the host computer. If it is a configuration parameter, it is used to configure the CAN controller and USB for software updates within the adapter. Otherwise, the data is converted into a CAN message and sent to the CAN bus.

[0012] Preferably, the CAN communication software control module uses the ISO 15765-2 protocol to implement CAN bus network communication and provides interface services for the UDS application layer.

[0013] The beneficial effects are as follows: Compared with the prior art, the automotive software upgrade system of the present invention adopts the UDS OnCAN solution. Through the application development of MFC, the CAN bus communication method in the automotive industry and UDS technology, the design of the flashing process is completed on the basis of UDS to realize the software upgrade of ECU. The automotive software upgrade system of this application has real-time and reliable characteristics. After multiple stability tests and applications on the main control board and the ECU of new energy vehicles, it can stably upgrade the ECU software on the whole vehicle and can be applied to the actual industrial production environment. Attached Figure Description

[0014] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0015] Figure 1 This is a diagram of the overall system framework.

[0016] Figure 2 This is a block diagram of the overall system software design.

[0017] Figure 3 Wiring diagram for USB-CAN module;

[0018] Figure 4 This refers to the basic process of program design.

[0019] Figure 5 A flowchart of the CAN communication software control module;

[0020] Figure 6 Design a flowchart for packet transmission;

[0021] Figure 7 Flowchart for the pre-programming phase;

[0022] Figure 8 Flowchart for the programming phase;

[0023] Figure 9 Flowchart for the post-programming stage;

[0024] Figure 10 Design a flowchart for secure access;

[0025] Figure 11 Here is a flowchart of the file parsing process;

[0026] Figure 12 This is a flowchart of the download thread. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0028] It should be noted that when a component is described as "fixed to" another component, it can be directly on the other component or may have a central component. When a component is described as "connected to" another component, it can be directly connected to the other component or may have a central component. When a component is described as "set on" another component, it can be directly set on the other component or may have a central component. When a component is described as "set in the middle," it is not simply set in the exact center, as long as it is not set within the area defined by both ends being in the middle. The terms "vertical," "horizontal," "left," "right," and similar expressions used in this document are for illustrative purposes only.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0030] This application discloses an automotive software upgrade system, including a host computer, a CAN adapter, a slave computer, and control software. A PC is used as the host computer, and the vehicle's main control board is used as the slave computer. The control software includes an MFC interface software control module, a CAN communication software control module, and a UDS flashing software control module. The host computer is connected to the adapter via a USB cable, and the CAN adapter is connected to the slave computer via an OBD wiring harness. The MFC interface software control module is used for software interface development. Based on a dialog box, combo box controls are used to select items and ports, and button controls are used to control the start and stop of the flashing program, as well as triggering the resource manager to select the automotive software upgrade file. The CAN communication software control module is used to establish communication between the host computer and the slave computer, and to process large data packets, responsible for the transmission of data and commands. The UDS flashing software control module is used for access control of the ECU. The UDS flashing software control module has three functional units: diagnostics and communication management, upload / download, and routine services, and has functions for secure access, file parsing, and program download.

[0031] Specifically, the automotive software upgrade system in this application adopts the UDS on CAN solution. In-depth research is conducted on the CAN protocol, UDS diagnostic services, and the application of MFC. The human-machine interface of the host computer software is developed using Microsoft Foundation Classes (MFC), communication between the host computer and the slave computer is established using CAN, and ECU remapping is performed based on the UDS diagnostic services.

[0032] like Figure 1 As shown, the system consists of three parts: a PC (as the host computer), an adapter, and a main control board (as the slave computer). The host computer's ECU flashing functionality relies on the UDS protocol; the slave computer's communication link relies on the CAN protocol. In the entire system, the host computer is connected to the adapter via a USB cable, and the adapter is connected to the main control board via an OBD harness. The slave computer is powered by an external 12V power supply, and the adapter adds the PC as a CAN node to the CAN bus. During the ECU flashing process, the host computer software initiates the UDS diagnostic flashing program, sending the parsed upgrade file data and flashing commands to the adapter via the UDS diagnostic service. The adapter then transmits the data to the vehicle ECU via the OBD harness, and the ECU performs the flashing upgrade based on the received UDS service request.

[0033] The main hardware aspect of this system lies in the design of the USB-CAN adapter. An STM32F72C8T6 is used as the master controller for the USB-CAN adapter; a USB_OTG provides a USB interface for connecting to a PC; an external TJA1051 / 3 is connected as a CAN transceiver for communication with the lower-level machine; and an LED module is connected as a flashing indicator for read / write operations.

[0034] like Figure 2 As shown, the control software of this system mainly includes the MFC interface software control module, the CAN communication software control module, and the UDS flashing software control module. The MFC interface software control module, as the software interface development, uses combo box controls to select items and ports based on dialog boxes; it uses button controls to control the start and stop of the flashing program, and to trigger the resource manager to select the vehicle software upgrade file; the CAN communication software control module is responsible for establishing communication between the host computer and the slave computer, and for packet processing of large data, handling the transmission of data and commands; the UDS flashing software control module is responsible for ECU access control. The UDS flashing software control module has three functional units: diagnostics and communication management, upload / download, and routine services, and also includes designs for secure access, file parsing, and program download.

[0035] The wiring diagram for the USB-CAN adapter is as follows: Figure 3As shown, the adapter uses an STM32F072C8T6 controller. A USB_OTC port is connected to this controller, providing a physical interface via USB_OTG, allowing a PC to connect to the adapter using a USB cable. To add the host computer to the CAN network, a TJA1051 / 3 CAN transceiver is connected to the controller to convert the CAN controller's logic signals into differential signals for CAN data transmission. An LED module is also designed; during data reading and writing, two LEDs, yellow and green, will flash alternately to indicate that data is in read / write mode.

[0036] Connect the male end of the USB cable to the USB port on the PC, and the Micro USB port on the other end of the data cable to the adapter. Then, connect the two CAN_H and CAN_L lines from the CAN adapter to the OBD harness, and the OBD harness is connected to the main control board through the OBD interface. This completes the construction of the entire hardware system.

[0037] The control software was designed using C++ programming and object-oriented development principles in Visual Studio 2015, with modular code writing and integration testing. The basic design process is as follows: Figure 4 As shown.

[0038] After launching the host computer software on the PC, configure the project through the software interface, and click "Start" to launch the flashing program. The flashing program initializes the system parameters by reading the INI configuration file and then establishes communication between the host computer and the slave computer. The host computer requests access to the ECU through UDS, calculates the received ECU seed to obtain access permissions to the ECU, and parses the upgrade file. The host computer sends a download request to the ECU. If a positive response is received, the upgrade file download begins, and the data is verified. If the data is error-free, the ECU is flashed according to the process written in the UDS diagnostic design, and the flashing progress is updated in the host computer software, completing the vehicle software upgrade.

[0039] The human-computer interface of the host computer software is developed based on MFC. A basic MFCApplication project is created in Visual Studio 2015 to facilitate MFC calls. A blank dialog box is created and set as the main dialog box, serving as the main interface after the software runs. The software logo icon is defined using the icon subclass under the project resource tree, and character hints are added to the interface using the string table subclass. Since only a single interface is used in the software design, this interface is the main dialog box, and IDD_ADDITION_DIALOG is used as the configuration ID for the dialog box template. The dialog box title is set to "Flashloader SDA", the border type is set to Dialog Frame, the maximize button is disabled, a pop-up window is used, and a title bar with move, close, and other menu items is added to its upper left corner. The default font is used as the display font. Multiple static text boxes are added to the dialog box to display characters, and their IDs are modified to correspond one-to-one with the character display position. Multiple edit boxes are added to the dialog box to display a series of information obtained by the interface, including the project name, flashing date, the port used, the path of the APP file, and the request and response messages during flashing. Add button controls to the dialog template in the same way, changing their titles to "Start," "Stop," and "Open," and their IDs to "Start," "Stop," and "Open," respectively. "Start" triggers the start of the download process when clicked, "Stop" terminates the download, and "Open" triggers the file explorer, allowing selection of app files. Adjust the size of the dialog template appropriately based on the layout of each control to ensure a suitable relative size and aesthetically pleasing interface.

[0040] The CAN communication implementation was written in software using MDK5 Keil uVision5. An STM32F072C8T6 was used as the master controller and USB-CAN adapter. In STM32CubeMx, the chip clock frequency was set to 40MHz and the baud rate to 500Kbps. A USB_OTG interface was used. To achieve plug-and-play functionality on the PC, a driverless HID mode was used for the USB configuration. The chip pins used were PA11 and PA12, corresponding to USB_DM and USB_DP respectively. The HID message description was modified in the configuration file, and the transmit and receive lengths were set to 64 bytes. For CAN, PB8 was used as CAN_RX and PB9 as CAN_TX. The flowchart of the CAN communication software control module is as follows. Figure 5 As shown.

[0041] The system clock and baud rate are set to initialize the USB and CAN connections. When data is received in the receive buffer, the program enters an interrupt. If a CAN message is received, the data, ID, and frame type are extracted, organized, processed, and converted before being transmitted to the PC via the USB transmit buffer. If USB data is received, the data is verified, valid data is extracted, and then converted into a CAN message. It is then determined whether the data is configuration parameters transmitted from the host computer. If it is, the CAN controller and USB are configured for software updates within the adapter; otherwise, the data is converted into a CAN message and sent to the CAN bus.

[0042] To enable the transmission of large amounts of data, the ISO 15765-2 protocol is used to implement CAN bus network communication and provide interface services for the UDS application layer. Two methods, single-frame and multi-frame, are designed for data transmission and reception. When the length of the pre-transmitted content is not equal to the maximum transmission length, zeros are appended to the data to make its length equal to the maximum transmission length. If the data content is large, the length of the data and the maximum transmission length are calculated to determine how many frames the data needs to be transmitted in. Since the data is fragmented, to facilitate reassembly after reception, the sequence number of each frame needs to be recorded before it is sent out. The packet transmission design is as follows: Figure 6 As shown.

[0043] Using packetized transmission to split data allows for segmentation, reassembly, and flow control. When the message length is less than or equal to 8 bytes, a single-frame transmission method is used; when it is greater than 8 bytes, the message is split into a first frame and subsequent frames. The specific message length range is determined by the addressing mode. The first frame contains the total length of the split data and information such as partial data frames. The first byte of each subsequent frame is the split sequence number, and the remaining bytes are used to store the data, thus realizing the purpose of packetized transmission based on the message frame length.

[0044] To facilitate modular code implementation, three functional units were designed for the required UDS request services: diagnostics and communication management, upload / download, and routines. These three functional units are responsible for data transmission and issuing write commands. UDS services are conducted by initiating requests and receiving responses. The request services contained in each functional unit are shown in Table 4-1.

[0045] Table 4-1 Functional Unit Module Table

[0046] Functional Unit SID Diagnostic services Diagnostics and Communication Management 10 Diagnostic Session Control 11 ECU reset 27 Secure access 28 Communication control 85 DTC control Routine 31 Routine control Upload and download 34 Request to download 36 Data transmission 37 Exit Transmission

[0047] In the host computer software, a UDS function interface is designed to obtain CAN bus information, including the bus ID, device port, and channel number. Point-to-point communication is established in the CAN network via the CAN ID. The host computer software interface allows selection and configuration of the required device ports. Currently, only a single channel is designed, so channel 0 is used by default.

[0048] For the initialization of the UDS diagnostic service, the service response timeout is configured to be 3000ms, and the frame type is set to CAN standard frame. If the data to be sent is less than 8 bytes, it will be padded with "00" to reach 8 bytes before transmission. When the negative response value is 0x78, the timeout is extended to 5000ms. Physical addressing and diagnostic information transmission and reception are performed using the 11-bit CAN ID. The host computer acts as the device source, with the physical request address set to 0x7A2, and the slave computer acts as the target device, with the physical response address set to 0x7AA. The diagnostic message encoding is defined as 8 bytes in length, and the baud rate of channel 0 is configured to 500Kbps. By reading the relevant configuration information in the configuration file and combining it with the UDS diagnostic service, the communication status is checked to see if a normal CAN link communication can be established. For requesting the UDS service, a function interface for requesting the UDS service is designed to implement requests for various services. The bus ID is specified by BusID, and the service is requested using Req. Req is a string array that stores the source address, target address, suppress response flag, UDS service number, and UDS service data. The system retrieves the response status for each UDS service request. A positive response indicates normal communication configuration and effective data transmission. If the flashing conditions are not met, the flashing process exits. The UDS diagnostic flashing process is designed as follows: Figure 7 , Figure 8 , Figure 9 As shown.

[0049] The entire flashing software design can be divided into three stages: pre-programming, main programming, and post-programming. Initially, a function addressing method is used to send service request 10 to the vehicle ECU, switching the session mode to an extended session, and using service 85 to disable the diagnostic fault code detection function. To improve flashing efficiency, service 28 is used to disable communication functions of other ECUs and shut down regular communication on the selected channel to free up bandwidth on the communication medium and avoid high occupancy due to other ECUs accessing CAN bus resources during flashing. In the main programming stage, service 10 is used again to switch to the programming session, and service 27 enters the appropriate security level, allowing the ECU to authenticate with the host computer to ensure the ECU can execute the host computer's UDS flashing commands. Then, service 34 requests the ECU to download software update data. After a positive response to the download request, service 36 transmits valid data between the PC and the ECU according to the communication protocol, transferring the software upgrade file from the PC to the ECU's memory for flashing. However, because the data addresses in the upgrade file are not contiguous and there are offsets in the address information, it is necessary to request service 31 to erase the contents of the ECU address before each execution of service 36. After all data has been downloaded, service 37 is called to declare that no more data needs to be downloaded. Then, it is necessary to verify the integrity of the data, requesting service 31 to verify the data, which relies on the built-in verification algorithm and checks the memory address where the data was written. Then, it enters the third stage, the post-programming state, where service 11 restarts the ECU. After power-on, it jumps to the newly downloaded APP program, thus completing the diagnostic flashing upgrade of the ECU software.

[0050] UDS (User-Defined System) can provide extensive control over in-vehicle ECUs. However, for security reasons, critical UDS services must be accessed securely only after authentication. Secure access is designed as follows: Figure 10 As shown. The system currently has three built-in security algorithms, combined with eight unsigned character type variables, performing addition, subtraction, multiplication, division, shifting, and XOR operations on the Seed. The algorithms have a certain degree of complexity, which can guarantee the security of the Key. When the host computer makes a secure access request, the ECU sends a seed to the host computer. The host computer calculates a key based on the received seed according to the security algorithm and sends the key back to the ECU. At the same time, the ECU also calculates a key based on its own security algorithm. The two keys are compared and verified. If the verification is successful, the ECU unlocks, and the host computer can access security-critical services; otherwise, the ECU fails to unlock, and the host computer cannot obtain access rights. However, after successful unlocking, since the switching between authentication levels is completed through diagnostic session control, the time of the non-default session state is limited. Therefore, when switching to a non-default session during diagnostic flashing, it is also necessary to set up periodic "presence" messages to request the retention of this access right to avoid returning to the default session.

[0051] The host computer supports parsing two mainstream file formats: S19 and HEX. The file parsing process is as follows: Figure 11 As shown. S19 file parsing: In order to transmit program code and data across different computer devices, Motorola developed an encoding method to convert ASCII format to S19 format for program and data file conversion. Each line of an S file is an S record, and each record consists of type, length, address, data, and checksum. Each byte is two hexadecimal ASCII encoded characters.

[0052] The file is read by accessing characters one by one using pointers, and the process involves judging the flag character and key bits. Each time an "S" is obtained, it represents a new record. If the data following "S" is "7", "8", or "9", it means the data is unused, and the parsing operation for that record ends. If it's "0", it means the storage address is unused, and the address is filled with "0000". If it's "1", "2", or "3", it means the address length of the record is 2, 3, and 4 bytes respectively. Based on the data type, the storage address length is skipped, and the data bits are directly obtained. The data is converted based on the difference between integer and character types. This process continues, reading the next data bit until all data in the record has been converted. This process iterates through each record, completing the data conversion for the entire file. Simultaneously, each record is divided into different regions based on the key bits, and the data information of each region is extracted to complete the parsing of the file records.

[0053] Hex file parsing: Hex is a text file in ASCII encoding format, which follows the standard set by Intel Corporation and is often used for burning MCU firmware and as an executable file. Each line of a Hex file is a Hex record, which mainly consists of machine language and hexadecimal data

[15] . Each Hex record is marked with ":" as the beginning of the record, followed by the length, address, type, data, and checksum.

[0054] Since the data area of ​​a Hex file begins at the 10th character in each record, after reading the file, we directly locate the 10th character of each record and use it as the starting point. We process two bytes of data at a time: we left-shift the high four bits of the first byte by 28 bits to obtain the first ASCII code, convert it to a normal character, and perform a logical AND operation with 0xFFFF0000. Then, we left-shift the low four bits of the first byte by 24 bits to obtain the second ASCII code, convert it, and perform a AND operation with the result of the previous operation. Similarly, we left-shift the high and low bits of the second byte by 20 bits and left-shift by 16 bits respectively, performing the same operation to obtain the current two bytes of data for that record. This process iterates through the entire data area of ​​the Hex file, completing the data conversion. Simultaneously, we divide each record into different regions based on key bits, extract the data information from each region, and complete the parsing of the file records.

[0055] A new thread was designed for the program's download section. The download thread flowchart is as follows: Figure 12 As shown, the download thread will make multiple requests to UDS (34, 36, and 37) to complete data transmission and update the flushing progress. Before transmitting a new record, the number of splittable frames H for each record is obtained. H is decremented after each frame is sent, and when H is zero, the transmission of that record is complete. After the new record is parsed, it is sent again through the download thread. Additionally, during message transmission, the host computer interface will call back the progress display method based on the frame transmission progress, displaying the flushing progress in real time on the software interface using a progress bar. To make the flushing progress more intuitive, the host computer software will display flushing log information on the right side of the interface for easy tracking of the flushing process.

[0056] Therefore, the automotive software design system of this application has the following characteristics:

[0057] (1) In response to the lack of ECU software upgrade solutions for new energy vehicles, this design was implemented using the UDS On CAN solution, and a new solution for software upgrade of new energy vehicles was designed and implemented.

[0058] (2) In response to the problem of developing the host computer interface, we have done the design and implementation of the human-computer interaction interface, and completed the development of the software interface using MFC. It can conveniently send control commands and configure and start program parameters through the interface.

[0059] (3) To address the communication problem between devices, we made a USB-CAN adapter for connecting the upper and lower computers, and completed the addition of the device as a CAN node to the CAN network and the packet transmission of data, which enabled the establishment of CAN network communication between devices.

[0060] (4) Regarding the issue of automotive software upgrades, we conducted design and development work on ECU flashing based on UDS, and completed multiple tests on flashing upgrades, including testing of each independent module during the development phase, overall testing after system completion, and finally testing on multiple vehicles. We conducted multiple tests to determine whether the system can meet the application requirements and the reliability and stability requirements in automotive upgrades.

[0061] The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of the technical solutions of the present invention.

Claims

1. A vehicle software upgrade system, characterized in that, The system includes a host computer, a CAN adapter, a slave computer, and control software. A PC serves as the host computer, and the vehicle's main control board serves as the slave computer. The control software includes an MFC interface software control module, a CAN communication software control module, and a UDS flashing software control module. The host computer connects to the adapter via a USB cable, and the CAN adapter connects to the slave computer via an OBD wiring harness. The MFC interface software control module is used for software interface development. Based on dialog boxes, combo box controls are used to select items and ports, and button controls are used to start and stop the flashing program, as well as trigger the resource manager to select the vehicle software upgrade file. The CAN communication software control module establishes communication between the host and slave computers, processes large data packets, and is responsible for data and command transmission. The UDS flashing software control module controls access to the ECU. It includes three functional units: diagnostics and communication management, upload / download, and routine services, and features secure access, file parsing, and program download capabilities.

2. The automotive software upgrade system according to claim 1, characterized in that, The CAN adapter uses an STM32F072C8T6 main controller, which is connected to a USB_OTC and provides a physical interface via USB_OTG, allowing a PC to connect to the adapter using a USB cable. To add the host computer to the CAN network, a TJA1051 / 3 CAN transceiver is connected to the main controller to convert the CAN controller's logic signals into differential signals for CAN data transmission. Furthermore, an LED module is designed on the main controller; during data reading and writing, two LEDs, yellow and green, will flash alternately to indicate that data is in read / write mode.

3. The automotive software upgrade system according to claim 2, characterized in that, One end of the USB cable is connected to the USB interface of the PC, and the other end is connected to the CAN adapter. The CAN adapter leads out two CAN_H and CAN_L lines to the OBD harness, and the OBD harness is connected to the main control board through the OBD interface to realize the connection between the host computer, the CAN adapter and the slave computer.

4. The automotive software upgrade system according to claim 1, characterized in that, After the PC controls the software to start, it configures the project through the software interface. Clicking "Start" launches the flashing program. The flashing program initializes the system parameters by reading the ini configuration file and establishes communication between the host computer and the slave computer. The host computer requests access to the ECU through UDS, calculates the received ECU seed to obtain access permissions to the ECU, and parses the upgrade file. The host computer sends a download request to the ECU. If a positive response is received, it begins downloading the upgrade file and verifies the data. If the data is error-free, it flashes the ECU according to the process written in the UDS diagnostic design and updates the flashing progress in the host computer software to upgrade the vehicle software.

5. The automotive software upgrade system according to claim 1, characterized in that, The human-computer interaction interface of the control software is developed based on MFC.

6. The automotive software upgrade system according to claim 1, characterized in that, The CAN communication software control module initializes the USB and CAN by setting the system clock and baud rate. When data is received in the receive buffer, the program enters an interrupt. If a CAN message is received, the data, ID, and frame type in the message are extracted, organized, processed, and converted before being transmitted to the PC via the USB transmit buffer. If USB data is received, the data is verified, valid data is extracted, and then converted into a CAN message. It is then determined whether the data is a configuration parameter transmitted from the host computer. If it is a configuration parameter, it is used to configure the CAN controller and USB for software updates within the adapter. Otherwise, the data is converted into a CAN message and sent to the CAN bus.

7. The automotive software upgrade system according to claim 1, characterized in that, The CAN communication software control module uses the ISO 15765-2 protocol to implement CAN bus network communication and provides interface services for the UDS application layer.

Images