A software design method for supporting OTA upgrade of an electric vehicle thermal management controller

Abstract

The application discloses a kind of software design method of supporting electric vehicle heat management controller OTA upgrade, comprising: first MCU power on / reset, hardware circuit automatically loads stack pointer, program entry point, waits for MCU frequency stabilization and release, provides the beat for bus, latches MCU start configuration, then enters program entry point_x (x=A, B …… N), reads internal reserved memory_option byte [0], and judges whether the current boot program partition number is consistent with option byte, if not consistent, jump to target partition number and re-enter program entry point, if consistent, enter main program main(), according to option byte partition number, determine program update state (including reset, updating, update completion, update failure), MCU hardware drive initialization and system parameter initialization, finally enter transaction processing cycle, feed watchdog.The application is fast, and the degree of updating is high, and safety is good, can significantly improve the intelligence and convenience of electric vehicle use, guarantee car experience.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of remote control of electric vehicle thermal management system, and particularly relates to a software design scheme of an electric vehicle thermal management system controller supporting OTA upgrade. BACKGROUND

[0002] The thermal management system controller is one of the core components of the electric vehicle and is an indispensable tool for the whole vehicle energy management of the electric vehicle, and the upgrade of the controller is particularly important. At present, many vehicles have the ability of OTA upgrade software, however, the traditional upgrade scheme generally has the following problems: (1) the software design scheme is complex; (2) the update time is long; (3) the Boot and the corresponding communication protocol part cannot be updated; (4) the software and hardware are incompatible due to the error brushing; (5) due to the fixed Boot program, there are serious risks such as intellectual property infringement and malicious software cracking attack. Therefore, the research on the OTA upgrade technology of the electric vehicle thermal management controller has important significance. SUMMARY

[0003] The present application provides an OTA upgrade software design scheme of an electric vehicle thermal management controller, so as to solve the problems of the complex OTA upgrade scheme, the long update time, the inability to update, the incompatibility of software and hardware and the vulnerability to attack, and can reduce the difficulty of OTA upgrade and the cost of platform application, so as to be applied in the industry on a large scale.

[0004] In order to achieve the above purpose, the present application provides the following software design scheme:

[0005] A software design method supporting OTA upgrade of an electric vehicle thermal management controller, comprising:

[0006] MCU power-on / reset, the hardware circuit automatically loads the stack pointer and the program entry point, waits for the MCU to stabilize the frequency and release, provides the beat for the bus, and latches the MCU start configuration;

[0007] Enter the program entry point_x, (x=A, B……N), wherein, _x is the version of the program, A is the first version of the program, B is the second version of the program, and N is the Nth version of the program, if the performance of the previous version of the program is not as good as the next version, then jump to the next version, if the performance of the previous version is better than the next version, then remain in the previous version;

[0008] Read the internal reserved memory_option byte[0] and judge whether the current boot program partition number is consistent with the option byte;

[0009] If not consistent, jump to the target partition number to re-enter the program entry point;

[0010] If consistent, enter the main program main(), determine the program update state, MCU hardware driver initialization and system parameter initialization according to the option byte partition number.

[0011] Enter the transaction processing loop and feed the watchdog.

[0012] Further, the program entry point_x, (x=A, B…N),_x adopts a multi-independent partition architecture including A area, B area…N area, cancels the connection between modules in A, B…N partitions to realize the Boot program upgrade including the bottom level.

[0013] Further, after reading the internal reserved memory_option byte[0], it is judged whether the current boot program partition number is consistent with the option byte, if consistent, enter the main program main();

[0014] If not consistent, jump to the target partition number to re-enter the program entry point, and Boot self-update.

[0015] Further, the entering transaction processing loop further comprises:

[0016] If yes, parse the UDS service request and response, provide UDS unified diagnostic service, update interrupt real-time monitoring, and update timeout real-time monitoring;

[0017] If no, parse the UDS service request and response, control subprogram, cache message sending, and provide UDS unified diagnostic service;

[0018] After providing the UDS unified diagnostic service, monitor the data transmission interruption caused by communication disconnection periodically, and monitor the update timeout periodically.

[0019] Further, the providing UDS unified diagnostic service further comprises:

[0020] The VCU sends an update request to the MCU;

[0021] The MCU processes the request according to the current state, and if allowed, performs software and hardware version consistency detection;

[0022] If consistent, the MCU responds to the update request, and the VCU receives the update response and downloads the update data;

[0023] The MCU performs CRC check on the data in the frame-by-frame transmission process and judges whether the check is passed;

[0024] If yes, after receiving 512kB bytes of update data or receiving the VCU transmission completion notification, perform Check Sum check and judge whether the check is passed;

[0025] If yes, real-time monitor whether VCU sends active rollback or partition jump request;

[0026] If yes, check rollback request sequence, and execute active rollback or partition jump operation after passing.

[0027] Further, after VCU sends update request to MCU, MCU processes the request according to current state, and if allowed, performs software and hardware version consistency detection, and if inconsistent, ignores the request;

[0028] If consistent, MCU responds to the update request, and VCU receives the update response and downloads update data;

[0029] MCU performs CRC check on data during frame-by-frame transmission and judges whether the check passes, and if not, indicates that the data is contaminated or interfered, cancels the update, and MCU restarts;

[0030] If yes, Check Sum check is performed after 512kB bytes of update data are received or VCU transmission completion notification is received.

[0031] Further, Check Sum check is performed after 512kB bytes of update data are received or VCU transmission completion notification is received, and whether the check passes is judged, and if not, indicates that the data is contaminated or interfered, cancels the update, and MCU restarts;

[0032] If yes, monitor whether VCU sends active rollback or partition jump request;

[0033] The real-time monitoring whether VCU sends active rollback or partition jump request further comprises:

[0034] Real-time monitor whether VCU sends active rollback or partition jump request;

[0035] If not, first erase the Flash sector to be written, and then write the program by page and write the program by half word;

[0036] Perform CRC check on received data and written content, and judge whether the writing succeeds;

[0037] If yes, continue to perform CRC check and judge whether the check passes;

[0038] If yes, it indicates that the writing succeeds, update option byte [0], write active partition number, update option byte [1], mark update state, and thus the update operation is completed, and MCU restarts.

[0039] Further, real-time monitor whether VCU sends active rollback or partition jump request, and if yes, execute active rollback or partition jump operation and then restart;

[0040] If no, first erase the flash sector to be written, then write the program by page and write the program by half word.

[0041] Further, the received data and the writing content are subjected to CRC check to determine whether the writing is successful, if yes, continue the CRC check;

[0042] If no, it indicates that the writing data process is abnormal, the update is cancelled, and the MCU is restarted;

[0043] The CRC check is continued, and it is determined whether the check is passed, if no, the option byte [0] is updated to write the original partition number, the option byte [1] is updated to mark the update failure, and the MCU is restarted;

[0044] If yes, it indicates that the writing is successful, the option byte [0] is updated to write the active partition number, the option byte [1] is updated to mark the update state, and the update operation is completed, and the MCU is restarted.

[0045] Specifically, the entering the transaction processing loop further comprises:

[0046] First, it is determined according to the comparison result whether to execute the normal business flow or to execute the update flow;

[0047] If the update flow is executed, the UDS request is parsed and an update response is made, the UDS unified diagnostic service I is run, and the communication disconnection, data transmission interruption and timeout fault are monitored in real time at the same time;

[0048] If the normal business flow is executed, the UDS request is parsed and a non-update response is made, the control subroutine is sent, the buffer message is sent, and the UDS unified diagnostic service II is run.

[0049] Specifically, the providing the UDS unified diagnostic service II (program update service) further comprises the following steps:

[0050] The vehicle control unit (VCU) sends an update request to the thermal management controller (MCU), and the MCU determines whether to process the update request according to the current state, if no, the request is ignored;

[0051] If yes, the software and hardware version consistency is detected, if inconsistent, the restart is performed;

[0052] If consistent, the MCU makes a response to the update request, and the VCU accepts the update response and downloads the update data;

[0053] To prevent error transmission resulting in the received data error, the MCU carries out CRC check on the data during the frame-by-frame transmission of the data and judges whether the check is passed, if not, it indicates that the data is contaminated or interfered, the update is cancelled, and the MCU is restarted;

[0054] If yes, the data receiving 512kB bytes or the Check Sum check value is sent after receiving the VCU transmission completion notification;

[0055] To ensure the consistency of the data of the receiving end and the sending end, the MCU carries out Check Sum check and judges whether the check is passed, if not, it is restarted;

[0056] If yes, the demonstration waits for 5s, and monitors whether the VCU sends an active rollback or partition jump request during the period, if not, the VCU executes data flashing;

[0057] If yes, the rollback request sequence is checked, and after passing, the active rollback or partition jump operation is executed.

[0058] Specifically, the request active rollback or partition jump operation further comprises the following steps:

[0059] Detecting whether the VCU sends an active rollback or partition jump request, if yes, the active rollback or partition jump operation is executed and then restarted;

[0060] If not, the Flash sector to be flashed is erased first, and then the page flashing program and the half-word flashing program are flashed;

[0061] By carrying out CRC check on the received data and the flashing content, it is judged whether the flashing is successful, if not, it indicates that the flashing data process is abnormal, the update is cancelled, and the MCU is restarted;

[0062] If yes, the CRC check is continued and it is judged whether the check is passed, if not, the update option byte [0] is updated, the original partition number is written, the update option byte [1] is updated, the update failure is marked, and the MCU is restarted;

[0063] If yes, it indicates that the flashing is successful, the update option byte [0] is updated, the active partition number is written, the update option byte [1] is updated, the update state is marked, and the update operation is completed, and the MCU is restarted.

[0064] Compared with the prior art, the application has the beneficial effects that: a software design method for supporting over-the-air (OTA) upgrade of a thermal management controller of an electric vehicle is provided, booting is intervened at a user boot entrance, and the A / B independent partition technology is used to replace and roll back, realize boot self-refresh, completely replace the boot flashed by the control manufacturer at the time of factory shipment, and the method is simple and efficient, has a fast flashing speed, and uses a multi-stage and multi-level checking method including software and hardware version consistency detection, CRC checking and Check Sum checking in the process of program flashing to support error prevention flashing, active rollback, timeout rollback, communication disconnection rollback, and checking failure rollback mechanisms, eliminate the risk of software leakage and cracking attacks, and guarantee the safety of the host manufacturer customers and automobile users. The whole process of the technology is transparent, safe and efficient, and can significantly reduce the after-sales maintenance workload of the host manufacturer, users and maintenance stations. BRIEF DESCRIPTION OF DRAWINGS

[0065] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows.

[0066] Figure 1 A flowchart of a software design method for supporting OTA upgrade of a thermal management controller of an electric vehicle according to an embodiment of the present application is shown.

[0067] Figure 2 A flowchart of a transaction processing cycle according to an embodiment of the present application is shown.

[0068] Figure 3 A flowchart of a program update service of a UDS unified diagnostic service according to an embodiment of the present application is shown.

[0069] Figure 4 A flowchart of an active rollback operation according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0070] In order to enable those skilled in the art to better understand the scheme of the embodiments of the present application, the embodiments of the present application will be further described in detail below with reference to the drawings and embodiments.

[0071] As shown in the drawings, it is a software design scheme for supporting OTA upgrade of a thermal management system controller of an electric vehicle, including the following steps: Figure 1 Step 1: The thermal management controller (MCU) is powered on / reset, the MCU hardware circuit automatically loads the stack pointer and the program entry point, waits for the MCU clock to stabilize the frequency and releases, provides the beat for the bus, and latches the MCU startup configuration (remaps the user Flash).

[0072]

[0073] ​Step 2: enter the MCU program entry point __x (x=A, B...N), read the internal reserved memory-option byte [0], and determine whether the current boot program partition number is consistent with the option byte [0] partition number.

[0074] It should be noted that the method further comprises: determining whether the current boot program partition number is consistent with the option byte, and if not, jumping to the target partition for the current boot partition number, and re-reading the internal reserved memory-option byte [0] for determination.

[0075] Step 3: if yes, enter the MCU main program main(), determine the program partition number according to the option byte [0], [1], determine the program update state (including reset, updating, update complete, and update failure), initialize the MCU hardware driver, and initialize the system parameters.

[0076] Step 4: enter the transaction processing loop and feed the watchdog.

[0077] Specifically, as shown in Figure 2 , it is a flowchart of the transaction processing loop provided according to the embodiment of the application. After entering the sub-flow, first, determine whether to execute the normal business flow or the update flow according to the comparison result. If the update flow is executed, parse the UDS request and make an update response, run the UDS unified diagnostic service (see Figure 3 for the specific flow), and monitor the communication disconnection, data transmission interruption, and timeout fault in real time at the same time; if the normal business flow is executed, parse the UDS request and make a non-update response, control the subprogram, send the cache message, and run the UDS unified diagnostic service.

[0078] Specifically, as shown in Figure 3 , it is a flowchart of the program update service of the UDS unified diagnostic service provided according to the embodiment of the application. It comprises the following steps:

[0079] Step 1: the vehicle control unit (VCU) sends an update request to the thermal management controller (MCU), and the MCU determines whether to process the update request according to the current state.

[0080] It should be noted that the method further comprises: the MCU determines whether to process the update request according to the current state, and if not, ignores the request.

[0081] Step 2: if yes, perform the software and hardware version consistency detection.

[0082] It should be noted that the method further comprises: performing the software and hardware version consistency detection, and if not consistent, restarting.

[0083] Step 3: If consistent, the MCU responds to the update request, and the VCU accepts the update response and downloads the update data.

[0084] Step 4: To prevent error transmission from causing errors in the received data, the MCU performs CRC check on the data during the frame-by-frame transmission of the data and determines whether the check is passed.

[0085] It should be noted that the method further comprises performing the CRC check and determining whether the check is passed, and if not, indicating that the data is contaminated or interfered, canceling the update, and restarting the MCU.

[0086] Step 5: If yes, the CheckSum value is sent after receiving 512 kB bytes of update data or receiving the VCU transmission completion notification.

[0087] Step 6: To ensure the consistency of the data at the receiving end and the sending end, the MCU performs Check Sum check and determines whether the check is passed.

[0088] It should be noted that the method further comprises performing the Check Sum check and determining whether the check is passed, and if not, restarting.

[0089] Step 7: If yes, the demonstration waits for 5s, and monitors whether the VCU sends an active rollback or partition jump request during this period.

[0090] It should be noted that the method further comprises determining whether the VCU sends an active rollback or partition jump request, and if not, the VCU performs data flashing.

[0091] Step 8: If yes, the rollback request sequence is checked, and after passing, the active rollback or partition jump operation is performed.

[0092] Specifically, as shown in Figure 4 the flowchart of the request active rollback or partition jump operation provided by the embodiment of the application, comprising the following steps:

[0093] Step 1: Detect whether the VCU sends an active rollback or partition jump request.

[0094] It should be noted that the method further comprises detecting whether the VCU sends an active rollback or partition jump request, and if yes, restarting after performing the active rollback or partition jump operation.

[0095] Step 2: If not, first erase the Flash sector to be flashed, and then flash the program by page and the program by half word.

[0096] Step 3: Determine whether the flashing is successful by performing CRC check on the received data and the flashing content.

[0097] It should be noted that the method further comprises: judging whether the flashing is successful, if not, indicating that the flashing data process is abnormal, canceling the update, and restarting the MCU.

[0098] Step 4: If yes, continue to perform CRC check and judge whether the check is passed.

[0099] It should be noted that the method further comprises: judging whether the check is passed, if not, updating option byte [0] to write the original partition number, updating option byte [1] to mark the update failure, and restarting the MCU.

[0100] Step 5: If yes, indicating that the flashing is successful, updating option byte [0] to write the active partition number, updating option byte [1] to mark the update state, and thus completing the update operation, and restarting the MCU.

[0101] The above only describes the preferred embodiments of the present application, but the present application is not limited to the embodiments shown in the drawings. For those skilled in the art, the present application can have various changes and variations. Any change or modification made in accordance with the concept of the present application, or equivalent embodiment with equivalent change, shall be within the scope of the present application.

Claims

1. A software design method for supporting OTA upgrade of an electric vehicle thermal management controller, characterized in that, The method comprises the following steps: MCU power-on / reset, hardware circuit automatically loads stack pointer, program entry point, waits for MCU to stabilize and release, provides beat for bus, latches MCU start configuration; Entering program entry point_x, x=A, B……N, wherein, _x is the version of the program, A is the first version of the program, B is the second version of the program, and N is the Nth version of the program, if the performance of the previous version of the program is not better than the next version, then jump to the next version, if the performance of the previous version is better than the next version, then remain in the previous version; Reading internal reserved memory_option byte[0] and judging whether the current boot program partition number is consistent with the option byte; If not consistent, jump to the target partition number to re-enter the program entry point; If consistent, enter the main program main(), determine the program update state, MCU hardware driver initialization and system parameter initialization according to the option byte partition number; Enter transaction processing loop, feed watchdog; The entering transaction processing loop further comprises the following steps: Judging whether in update state, if yes, then parse UDS service request and response, provide UDS unified diagnosis service, update interrupt real-time monitoring, update timeout real-time monitoring; If no, then parse UDS service request and response, control subprogram, cache message sending, provide UDS unified diagnosis service; After providing UDS unified diagnosis service, monitor the data transmission interruption caused by communication disconnection periodically, monitor update timeout periodically; The providing UDS unified diagnosis service further comprises the following steps: VCU sends update request to MCU; MCU processes the request according to the current state, if allowed, then performs software and hardware version consistency detection; If consistent, MCU responds to the update request, VCU receives the update response and downloads update data; MCU performs CRC check on the data in the frame-by-frame transmission process and judges whether the check is passed; If yes, after receiving 512kB bytes of update data or receiving VCU transmission completion notification, perform Check Sum check and judge whether the check is passed; If yes, real-time monitor whether VCU sends active rollback or partition jump request; If yes, then check the rollback request sequence, after passing, execute active rollback or partition jump operation; After VCU sends update request to MCU, MCU processes the request according to the current state, if allowed, then performs software and hardware version consistency detection, if not consistent, then ignore the request; If consistent, MCU responds to the update request, VCU receives the update response and downloads update data; If no, it indicates that the data is polluted or interfered, cancel the update, and MCU restarts; If yes, after receiving 512kB bytes of update data or receiving VCU transmission completion notification, perform Check Sum check; The entering program entry point_x, x=A, B……N, _x adopts a multi-independent partition architecture including A area, B area……N area, cancels the connection between the modules in A, B……N partitions, to realize the upgrade of Boot program including bottom level. After reading the internal reserved memory option byte [0], it is judged whether the current boot program partition number is consistent with the option byte, if consistent, the main program main() is entered; If not, jump to the target partition number to re-enter the program entry point, and the Boot is updated.

2. The software design method for supporting the OTA upgrade of the thermal management controller of the electric vehicle according to claim 1, characterized in that: After receiving 512kB bytes of update data or receiving the VCU transmission completion notification, Check Sum verification is performed and it is judged whether the verification is passed, if not, it indicates that the data is contaminated or interfered, the update is cancelled, and the MCU is restarted; If yes, it is monitored whether the VCU initiatively rolls back or jumps to the partition; The real-time monitoring whether the VCU initiatively rolls back or jumps to the partition further includes: Real-time monitoring whether the VCU initiatively rolls back or jumps to the partition; If not, the Flash sectors to be written are first erased, then the program is written by page and the program is written by half word; The received data and the written content are subjected to CRC verification, and it is judged whether the writing is successful; If yes, the CRC verification is continuously performed and it is judged whether the verification is passed; If yes, it indicates that the writing is successful, the option byte [0] is updated, the active partition number is written, the option byte [1] is updated, the update state is marked, the update operation is completed, and the MCU is restarted.

3. The software design method for supporting the OTA upgrade of the thermal management controller of the electric vehicle according to claim 2, characterized in that: The real-time monitoring whether the VCU initiatively rolls back or jumps to the partition, if yes, the active rollback or partition jump operation is performed and then restarted; If not, the Flash sectors to be written are first erased, then the program is written by page and the program is written by half word.

4. The software design method for supporting the OTA upgrade of the thermal management controller of the electric vehicle according to claim 3, characterized in that: The received data and the written content are subjected to CRC verification, and it is judged whether the writing is successful, if yes, the CRC verification is continuously performed; If not, it indicates that the writing data process is abnormal, the update is cancelled, and the MCU is restarted; The CRC verification is continuously performed, and it is judged whether the verification is passed, if not, the option byte [0] is updated, the original partition number is written, the option byte [1] is updated, the update failure is marked, and the MCU is restarted; If yes, it indicates that the writing is successful, the option byte [0] is updated, the active partition number is written, the option byte [1] is updated, the update state is marked, the update operation is completed, and the MCU is restarted.

Images