Software upgrading method of vehicle-mounted electronic controller, vehicle-mounted electronic controller and vehicle

Abstract

The embodiment of the invention discloses a software upgrading method of a vehicle-mounted electronic controller, the vehicle-mounted electronic controller and a vehicle, relates to the technical field of automobile software upgrading, and can improve the reliability of software operation and the flexibility of upgrading. The method comprises the following steps: starting a first boot loader; the first boot loader carries out safety verification on starting of the second boot loader, and if the starting safety verification of the first boot loader and the second boot loader is passed, the second boot loader is started; the second boot loader carries out safety verification on starting of the vehicle-mounted application program, and if the starting safety verification of the second boot loader on the vehicle-mounted application program is passed, the vehicle-mounted application program is started; and the vehicle-mounted application program obtains the remote upgrading file and utilizes the upgrading file to upgrade the second boot loader and / or the vehicle-mounted application program stored in the backup partition in the flash memory. The method is suitable for software upgrading of the vehicle-mounted electronic controller.

Description

Technical Field

[0001] The present invention relates to the technical field of automobile software upgrade, and in particular to a software upgrade method of an on-board electronic controller, an on-board electronic controller and a vehicle. Background Art

[0002] With the development of intelligent driving technology and intelligent connected vehicles, the complexity of automotive electronic systems has increased significantly, and modern vehicles have an increasing demand for real-time software upgrades and maintenance in different scenarios.

[0003] The vehicle electronic controller ECU (Electronic Control Unit) is a microcomputer system built into the car, which collects information from various sensors and performs precision processing to ensure accurate control of multiple subsystems in the vehicle. The ECU software usually includes PBL (primary boot loader) and APP (vehicle application). After the vehicle electronic controller is powered on, the vehicle application is started through the PBL boot. When the vehicle application is started, it is easy to start invalid software, causing the vehicle electronic controller to lose the ability to recover from faults through remote upgrades. In addition, the current vehicle electronic controller software usually only supports local upgrades, and the upgrade method is relatively simple. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a software upgrade method of an on-vehicle electronic controller, an on-vehicle electronic controller and a vehicle, which can improve the reliability of software operation and the flexibility of upgrading.

[0005] In a first aspect, an embodiment of the present invention provides a software upgrade method for a vehicle-mounted electronic controller, comprising: starting a first boot loader; the first boot loader performs a security check on the startup of a second boot loader, and if the first boot loader passes the security check on the startup of the second boot loader, the second boot loader is started; the second boot loader performs a security check on the startup of a vehicle-mounted application, and if the second boot loader passes the security check on the startup of the vehicle-mounted application, the vehicle-mounted application is started; the vehicle-mounted application obtains a remote upgrade file, and uses the upgrade file to upgrade the second boot loader and / or the vehicle-mounted application stored in a backup partition in a flash memory.

[0006] In one embodiment, after starting the first boot loader, the method further includes: The first boot loader obtains the local upgrade file of the second boot loader from the local upgrade host computer, and uses the local upgrade file of the second boot loader to upgrade the second boot loader stored in the current activation area in the flash memory.

[0007] In one embodiment, after starting the second boot loader, the method also includes: the second boot loader obtains the local upgrade file of the vehicle-mounted application from the local upgrade host computer, and uses the local upgrade file of the vehicle-mounted application to upgrade the vehicle-mounted application stored in the current activation area in the flash memory.

[0008] In one embodiment, before the vehicle-mounted application obtains the remote upgrade file, the method further includes performing at least one of the following operations: closing the currently running business algorithm program; closing inter-chip business data transmission; and closing the recording of diagnostic fault codes.

[0009] In one embodiment, the vehicle-mounted electronic controller includes a first control unit, which includes a first processing core and a second processing core; wherein the vehicle-mounted application obtains a remote upgrade file, including: the first processing core obtains the remote upgrade file, and sends the upgrade file to the second processing core through a shared memory; the second processing core calls a flash memory driver to erase the backup partition in the flash memory, so as to use the upgrade file to upgrade the second boot loader and / or the vehicle-mounted application stored in the backup partition in the flash memory.

[0010] In one embodiment, after the first processing core sends the upgrade file to the second processing core through the shared memory, the method further includes: the first processing core updates the flash memory state machine from flash memory operation idle to flash memory operation start erase / write; wherein, after the second processing core erases the backup partition in the flash memory, the method further includes: if the second processing core successfully erases the backup partition in the flash memory, the flash memory state machine is updated to the flash memory operation erase / write end; if the second processing core fails to erase the backup partition in the flash memory, the flash memory state machine is updated to the flash memory operation erase / write error.

[0011] In one embodiment, the method also includes: the first processing core, before updating the flash memory state machine to the start of the flash memory operation erase / write, obtains the operation spin lock of the flash memory state machine, and after updating the flash memory state machine to the start of the flash memory operation erase / write, releases the obtained flash memory state machine operation spin lock; and the second processing core, before updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error, obtains the operation spin lock of the flash memory state machine, and after updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error, releases the obtained flash memory state machine operation spin lock.

[0012] In one embodiment, after obtaining the local upgrade file of the second boot loader or the vehicle-mounted application from the local upgrade host computer, it includes: calling the flash memory driver to erase the current active partition in the flash memory to upgrade the second boot loader or the vehicle-mounted application stored in the current active partition.

[0013] In one embodiment, the vehicle-mounted electronic controller includes a first control unit and a second control unit communicatively connected to the first control unit; wherein the second control unit downloads a remote upgrade file from a remote upgrade host computer via Ethernet, and sends the remote upgrade file to the first control unit, and the first control unit uses the remote upgrade file to upgrade the second boot loader and / or vehicle-mounted application stored in the backup partition in the flash memory.

[0014] In a second aspect, an embodiment of the present invention further provides a vehicle-mounted electronic controller, comprising: a first control unit and a flash memory; the flash memory stores a first boot loader, a second boot loader and a vehicle-mounted application; wherein the first control unit is used to execute the software upgrade method of the vehicle-mounted electronic controller provided by any embodiment of the present invention.

[0015] In a third aspect, an embodiment of the present invention further provides a vehicle, wherein the vehicle is equipped with an on-board electronic controller, and the on-board electronic controller is the on-board electronic controller provided by any embodiment of the present invention.

[0016] The software upgrade method of the vehicle electronic controller, the vehicle electronic controller and the vehicle provided by the embodiment of the present invention start the first boot loader; the first boot loader performs a security check on the startup of the second boot loader, and if the first boot loader passes the security check on the startup of the second boot loader, the second boot loader is started; the second boot loader performs a security check on the startup of the vehicle application, and if the second boot loader passes the security check on the startup of the vehicle application, the vehicle application is started; the vehicle application obtains a remote upgrade file, and uses the upgrade file to upgrade the second boot loader and / or the vehicle application stored in the backup partition in the flash memory. In this way, the vehicle electronic controller of the present invention runs the upgrade function in the first boot loader, the second boot loader and the vehicle application, and can upgrade the second boot loader and / or the vehicle application, avoiding the problem that the prior art only supports local upgrades and the upgrade method is relatively single, and improves the flexibility of software upgrades; multiple security checks are added before the vehicle application is started to avoid starting invalid software, thereby causing the vehicle electronic controller to lose the ability to recover from faults through remote upgrades, and improve the reliability of software upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 A flow chart of a software upgrade method for a vehicle-mounted electronic controller provided by an embodiment of the present invention; Figure 2 A schematic diagram of a program architecture in an embodiment of the present invention; Figure 3 A flowchart of program startup in an embodiment of the present invention; Figure 4 A schematic diagram of remote upgrade in an embodiment of the present invention; Figure 5 A schematic diagram of local upgrade in an embodiment of the present invention; Figure 6 A flowchart of remote upgrade in an embodiment of the present invention; Figure 7 A schematic diagram of a multi-core flashing mechanism in an embodiment of the present invention; Figure 8 A flow chart of the state change of the flash memory state machine in an embodiment of the present invention; Fig. 9 is a schematic diagram of a vehicle-mounted electronic controller in an embodiment of the present invention; Fig.10 A detailed flow chart of a method for upgrading the software of a vehicle-mounted electronic controller in an embodiment of the present invention; Fig.11 Schematic diagram of a structure of a vehicle-mounted electronic controller in an embodiment of the present invention. DETAILED DESCRIPTION

[0019] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0020] It should be clear that the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0021] In a first aspect, an embodiment of the present invention provides a method for upgrading software of a vehicle-mounted electronic controller, which can improve the reliability of software operation and the flexibility of upgrading.

[0022] like Figure 1As shown, an embodiment of the present invention provides a software upgrade method for a vehicle-mounted electronic controller, comprising: S11, starting the first boot loader; In an embodiment of the present invention, before starting the first boot loader, it is necessary to generate the first boot loader, and the first boot loader is generated by the following steps: the vehicle electronic controller includes a control unit, the control unit includes a first boot loader project, Figure 2 This is a schematic diagram of the program architecture, such as Figure 2 As shown, the first boot loader project implements a private protocol based on the microcontroller abstraction layer of the control unit, generates an executable target file, and the executable target file includes the first boot loader, and the first boot loader runs in a single core. When the control unit performs a task, it needs to receive a command from the host computer, and the host computer sends an instruction, and the control unit starts the first boot loader.

[0023] S12, the first boot loader performs a security check on the startup of the second boot loader, and if the first boot loader passes the security check on the startup of the second boot loader, the second boot loader is started; Before starting the second boot loader, it is necessary to generate the second boot loader first. The second boot loader is generated by the following steps: the control unit includes a second boot loader project, such as Figure 2 As shown, the second boot loader project implements private protocols and public protocols based on the microcontroller abstraction layer of the control unit, generates an executable target file, and the executable target file includes the second boot loader and flash driver software. The second boot loader runs in a single core.

[0024] Figure 3 1 is a flowchart of program startup in an embodiment of the present invention, such as Figure 3 As shown, first start the first boot loader, then read the data through the shared memory area to determine whether the current session is a private programming session. If the current session is a private programming session, it resides in the first boot loader and re-enters the loader to continue the determination. If the current session is not a private programming session, perform a security check on the start of the second boot loader, and determine whether to start the second boot loader based on the check result. If the second boot loader passes the security check, start the second boot loader; if the second-level software data does not pass the security check, it resides in the first boot loader and re-enters the loader to continue the determination.

[0025] S13, the second boot loader performs a security check on the startup of the vehicle-mounted application, and if the second boot loader passes the security check on the startup of the vehicle-mounted application, the vehicle-mounted application is started; Before starting the vehicle application, the vehicle application needs to be generated first. The vehicle application is generated by the following steps: The control unit also includes the vehicle application engineering, such as Figure 2 As shown in the figure, the vehicle application engineering is based on the microcontroller abstraction layer of the control unit, deploys the automotive open system architecture operating system, implements private and public protocols, and generates executable target files. The executable target files include vehicle applications, predetermined main chip configuration software, calibration software, and flash drive software. The vehicle application can run on multiple cores to realize the diagnostic flashing function.

[0026] like Figure 3 As shown, after starting the second boot loader, the data is read from the shared memory area to determine whether the current session is a programming session. If the current session is a programming session, the second boot loader is resident, and the loader is re-entered to continue the determination. If the current session is not a programming session, a security check is performed on the start of the vehicle-mounted application, and it is determined whether to start the vehicle-mounted application based on the check result. If the vehicle-mounted application passes the security check, the vehicle-mounted application is started; if the vehicle-mounted application fails the security check, the second boot loader is resident, and the loader is re-entered to continue the determination.

[0027] S14, the in-vehicle application obtains a remote upgrade file, and uses the upgrade file to upgrade the second boot loader and / or the in-vehicle application stored in the backup partition in the flash memory.

[0028] After the vehicle application is started, the vehicle application obtains the remote upgrade file and uses the obtained upgrade file to perform remote upgrade. Figure 4 This is a remote upgrade schematic diagram. Figure 4 As shown, two storage spaces (A / B storage spaces) are opened on the control unit, and a system is installed on each storage space, one of which is in active use and the other is in standby standby. Assuming that B is a backup partition, the second boot loader and / or vehicle application stored in the backup partition in the flash memory is upgraded, and after the upgrade is completed and restarted, it switches to the newly upgraded system.

[0029] The software upgrade method of the vehicle-mounted electronic controller provided by the embodiment of the present invention starts the first boot loader; the first boot loader performs a security check on the startup of the second boot loader, and if the first boot loader passes the security check on the startup of the second boot loader, the second boot loader is started; the second boot loader performs a security check on the startup of the vehicle-mounted application, and if the second boot loader passes the security check on the startup of the vehicle-mounted application, the vehicle-mounted application is started; the vehicle-mounted application obtains a remote upgrade file, and uses the upgrade file to upgrade the second boot loader and / or the vehicle-mounted application stored in the backup partition in the flash memory. In this way, the vehicle-mounted electronic controller of the present invention runs the upgrade function in the first boot loader, the second boot loader and the vehicle-mounted application, and can upgrade the second boot loader and / or the vehicle-mounted application, avoiding the problem that the prior art only supports local upgrades and the upgrade method is relatively single, and improves the flexibility of software upgrades; multiple security checks are added before the vehicle-mounted application is started to avoid starting invalid software, thereby causing the vehicle-mounted electronic controller to lose the ability to recover from faults through remote upgrades, and improves the reliability of software upgrades.

[0030] In some embodiments, after starting the first boot loader, the method also includes: the first boot loader obtains the local upgrade file of the second boot loader from the local upgrade host computer, and uses the local upgrade file of the second boot loader to upgrade the second boot loader stored in the current activation area in the flash memory.

[0031] In an embodiment of the present invention, the first boot loader is started, a local upgrade file of the second boot loader is obtained from a local upgrade host computer, and the upgrade is completed using the local upgrade file. Figure 5 Schematic diagram of local upgrade in an embodiment of the present invention. Figure 5 As shown, two storage spaces (A / B storage spaces) are opened on the device, one system is in an activated use state, and the other system is in a standby standby state. A local diagnostic flashing function based on CAN (Controller Area Network) communication is implemented for the local upgrade file of the second boot loader, so that the second boot loader stored in the current active area (one of the A / B storage spaces is in an activated use state) in the flash memory is upgraded. During the flashing process, the flash memory driver software used by the first boot loader and the second boot loader use the same software.

[0032] In some embodiments, after starting the second boot loader, the method also includes: the second boot loader obtains the local upgrade file of the vehicle-mounted application from the local upgrade host computer, and uses the local upgrade file of the vehicle-mounted application to upgrade the vehicle-mounted application stored in the current activation area in the flash memory.

[0033] In the embodiment of the present invention, the second boot loader is started, the local upgrade file of the vehicle-mounted application is obtained from the local upgrade host computer, the local diagnostic flashing function based on CAN communication is implemented for the local upgrade file of the vehicle-mounted application, and the vehicle-mounted application stored in the current activation area (one of the A / B storage spaces is in an activated use state) in the flash memory is upgraded. Figure 5 shown.

[0034] The above two embodiments realize the local upgrade of the second boot loader and / or the vehicle-mounted application program when the vehicle-mounted application program is not started and the first boot loader and / or the second boot loader program are started. The first boot loader software as firmware is no longer upgraded and changed. When the second boot loader or the vehicle-mounted application program in the memory of the control unit has any problem, the control unit still has the ability to upgrade and recover. The first boot loader, the second boot loader and the vehicle-mounted application program in the local upgrade are actually a layered mechanism. By introducing layered upgrades, the fault tolerance and stability of the system are improved. Even if the upgrade fails at a certain level, it can still be restored through upgrades at other levels, which will not affect the overall availability of the system and ensure the normal use of the vehicle. In addition, each layer supports upgrade methods under different sessions. In some examples, the session includes private programming sessions, programming sessions, and OTA sessions, and can also meet different upgrade requirements, such as local upgrades and remote upgrades, private protocol upgrades and public protocol upgrades, and upgrades to this partition and spare partitions, which improves the flexibility and adaptability of the solution, can provide reliable upgrade services in various scenarios, and reduce restrictions and obstacles in the upgrade process.

[0035] In some embodiments, before the in-vehicle application obtains the remote upgrade file, the method also includes performing at least one of the following operations: closing the currently running business algorithm program; closing inter-chip business data transmission; closing the recording of diagnostic fault codes.

[0036] After starting the vehicle application and before obtaining the remote upgrade file, determine whether the session control is in OTA (Over The Air, cloud upgrade) session mode. If the session control is in OTA session mode, turn off the business algorithm software to release computing resources, turn off inter-chip business data transmission to release communication resources, and turn off diagnostic fault code recording to release storage resources. Before performing a remote upgrade, a business decoupling operation is required. The above operation is to decouple the upgrade task from other business functions, release the communication, computing and storage resources occupied by the business functions, and the system can focus on the upgrade when executing the upgrade task without being disturbed by other business functions. Improve the stability of the upgrade, reduce upgrade failures or abnormal situations caused by resource conflicts and task preemption, and achieve the upgrade stability and independence of the vehicle application.

[0037] After the business is decoupled, remote upgrade is performed. Figure 6 Flow chart of remote upgrade in an embodiment of the present invention, as shown in FIG. Figure 6 As shown, the vehicle application is in OTA mode and executes the OTA flashing process. If the flashing is successful, the control unit is restarted after receiving the 11 reset command to restore the previously decoupled business functions. Among them, 11 reset belongs to 11 service. 11 service is a specific service defined in the general diagnostic protocol with a service number of 0x11. It is also a restart service (ECURest) used to control the restart of the control unit. Restart is divided into hardware restart and software restart, corresponding to different sub-services of 11 service. If an exception occurs during the flashing, exit the OTA session and restart the control unit, re-decouple the business and put the vehicle application in OTA mode to execute the OTA flashing process.

[0038] In some embodiments, the vehicle-mounted electronic controller includes a first control unit, which includes a first processing core and a second processing core; wherein, the vehicle-mounted application obtains a remote upgrade file, including: the first processing core obtains the remote upgrade file, and sends the upgrade file to the second processing core through a shared memory; the second processing core calls a flash memory driver to erase the backup partition in the flash memory, so as to use the upgrade file to upgrade the second boot loader and / or the vehicle-mounted application stored in the backup partition in the flash memory.

[0039] In the process of executing the OTA flashing process, the embodiment of the present invention uses a multi-core (first processing core and second processing core) flashing mechanism to perform the flashing task. The control unit in the vehicle-mounted electronic controller includes a first control unit, and the first processing core and the second processing core are located in the first control unit. The first processing core is responsible for deploying diagnostic communication and data transmission tasks, and the second processing core is responsible for flash memory erasing tasks. The first control unit conducts diagnostic communication with the remote upgrade host computer via Ethernet and receives the upgrade file. The first processing core in the first control unit receives the downloaded upgrade file and stores it in a preset register.

[0040] After the first control unit downloads the upgrade file, it flashes the upgrade file. Figure 7 Schematic diagram of a multi-core flashing mechanism in an embodiment of the present invention. Figure 7 As shown, when the first processing core obtains the diagnostic communication instruction for data transmission, the upgrade file is transmitted to the second processing core through the shared memory, and the flash memory erase operation task of the second processing core is triggered. The second processing core calls the flash memory driver to erase the backup partition in the flash memory, erase the old second boot loader and / or the vehicle application, and write the new second boot loader and / or the vehicle application to the corresponding storage area to complete the upgrade of the second boot loader and / or the vehicle application. After the second processing core operation is completed, the flash memory state machine stored in the shared memory area is modified to "operation end" or "operation error", and the first processing core reads and parses the state machine, and responds to "flash success" or "flash failure" according to the result.

[0041] The first control unit shares the task load through multi-core processing, improves the stability and efficiency of the flashing process, reduces the risk of data transmission failure or flash memory operation failure during the flashing process, and ensures the smooth progress of the upgrade process.

[0042] In some embodiments, after the first processing core sends the upgrade file to the second processing core through shared memory, the method further includes: the first processing core updates the flash memory state machine from flash memory operation idle to flash memory operation start erase / write; wherein, after the second processing core erases the backup partition in the flash memory, the method further includes: if the second processing core successfully erases the backup partition in the flash memory, the flash memory state machine is updated to the flash memory operation erase / write end; if the second processing core fails to erase the backup partition in the flash memory, the flash memory state machine is updated to the flash memory operation erase / write error.

[0043] The first processing core sends the upgrade file to the second processing core through the shared memory. The first processing core and the second processing core interact by updating and reading the flash state machine stored in the shared memory. The shared memory is set in the space used for storage by the first control unit. When multi-core flashing is performed, the state of the flash state machine also changes accordingly.

[0044] Figure 8 FIG. 1 is a flow chart of the state change of the flash memory state machine in an embodiment of the present invention. Figure 8 As shown, the starting state of the flash memory state machine is "flash memory operation idle". After the first processing core sends the upgrade file to the second processing core through the shared memory, the flash memory erase / write operation task of the second processing core is activated, and the flash memory state machine state is updated to "flash memory operation starts erase / write".

[0045] The first processing core interacts with the second processing core by updating and reading a state machine stored in a shared memory area. The second processing core updates the flash state machine to "flash operation is being erased / written" based on the state machine status of "flash memory operation starts to erase / write". If the flash memory driver is judged to be idle, the flash state machine is updated to "flash memory operation is being erased / written" and the flash memory driver is called to start the erase / write operation; if the flash memory driver status is not idle, the flash state machine is updated to "flash memory operation erase / write error".

[0046] When the flash memory state machine is "flash memory operation idle", the second processing core updates the flash memory state machine according to the flash memory drive state. When the flash memory state machine is "flash memory operation is being erased / written", the second processing core updates the flash memory state machine according to the flash memory drive state. If the second processing core successfully erases and writes the backup partition in the flash memory, and the flash memory drive state is erase / write operation completed, the flash memory state machine is updated to "flash memory operation erase / write completed"; if the second processing core fails to erase and write the backup partition in the flash memory, and the flash memory drive state is erase / write operation completed, the flash memory state machine is updated to "flash memory operation erase / write error".

[0047] When the flash memory state machine is in "flash memory operation erase / write error", the first processing core responds to the data transmission failure through diagnostic communication and updates the flash memory state machine to the end state "flash memory operation idle".

[0048] When the flash memory state machine is in the state of "flash memory operation erase / write completed", the first processing core responds to the successful data transmission through the diagnostic communication, and updates the flash memory state machine to the end state of "flash memory operation idle".

[0049] In some embodiments, the method also includes: the first processing core, before updating the flash memory state machine to the start of the flash memory operation erase / write, obtains the operation spin lock of the flash memory state machine, and after updating the flash memory state machine to the start of the flash memory operation erase / write, releases the obtained flash memory state machine operation spin lock; and the second processing core, before updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error, obtains the operation spin lock of the flash memory state machine, and after updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error, releases the obtained flash memory state machine operation spin lock.

[0050] The first processing core and the second processing core need to acquire the spin lock before reading or updating the flash memory state machine, and release the spin lock after the operation is completed. That is, the first processing core acquires the operation spin lock of the flash memory state machine before updating the flash memory state machine to the start of the flash memory operation erase / write and before the second processing core updates the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error; after updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error, the acquired flash memory state machine operation spin lock is released.

[0051] In some embodiments, after obtaining the local upgrade file of the second boot loader or the vehicle-mounted application from the local upgrade host computer, it includes: calling the flash memory driver to erase the current active partition in the flash memory to upgrade the second boot loader or the vehicle-mounted application stored in the current active partition.

[0052] After obtaining the local upgrade file of the second boot loader or the vehicle-mounted application from the local upgrade host computer, the flash memory driver is called to erase the current active partition in the flash memory (the current active partition is as follows Figure 5 As shown, one of the A / B storage spaces is in active use).

[0053] During the erasing process, the second boot loader or vehicle application can communicate with the external diagnostic instrument based on the communication protocol through the unified diagnostic service. In some examples, the communication protocol can be a low-level bus protocol such as CAN or Ethernet. After verifying the permissions of the diagnostic instrument, the second boot loader or vehicle application will download the second-level boot program on the diagnostic instrument to the RAM (random access memory) of the first control unit, and then the second-level boot program will flash it. The second-level boot program contains all the services provided by the second boot loader or vehicle application, as well as a flash drive and some additional general diagnostic services. Triggered by the general diagnostic service, the second-level boot program will use the flash drive to erase the old second boot loader or vehicle application, and write the new second boot loader or vehicle application to the corresponding storage area, completing the upgrade of the second boot loader or vehicle application stored in the currently active partition.

[0054] In one embodiment, the vehicle-mounted electronic controller includes a first control unit and a second control unit communicatively connected to the first control unit; wherein the second control unit downloads a remote upgrade file from a remote upgrade host computer via Ethernet, and sends the remote upgrade file to the first control unit, and the first control unit uses the remote upgrade file to upgrade the second boot loader and / or vehicle-mounted application stored in the backup partition in the flash memory.

[0055] If the embodiment of the present invention is applied to a multi-chip vehicle-mounted electronic controller, the control unit of the vehicle-mounted electronic controller should include a first control unit and a second control unit, and the first control unit and the second control unit communicate with each other through a wire connection. The second control unit performs diagnostic communication with the outside of the vehicle-mounted electronic controller based on Ethernet, and downloads the upgrade file from the remote upgrade host computer to the second control unit. The vehicle-mounted application of the first control unit performs diagnostic communication with the second control unit based on the serial peripheral device interface to obtain the upgrade file. The vehicle-mounted application of the first control unit uses the remote upgrade file to upgrade the backup partition (such as Figure 4 As shown, assuming that B is a backup partition), the second boot loader and / or the in-vehicle application stored in the partition is upgraded.

[0056] At the same time, the local upgrade host computer is connected to the first control unit through a wire, and the first control unit performs diagnostic communication with the vehicle electronic controller outside based on the CAN communication protocol. The upgrade file is downloaded from the local upgrade host computer to the first control unit, and the current activation area (such as Figure 5 As shown, the A / B storage space (one of the systems is in active use) stores a second boot loader and / or in-vehicle applications for upgrading.

[0057] For example, Fig. 9 is a schematic diagram of a vehicle-mounted electronic controller in an embodiment of the present invention, such as Fig. 9 As shown, the first control unit and the second control unit are distributed on a predetermined master chip and a predetermined slave chip. The remote upgrade host computer is connected to the predetermined slave chip through a wire, and the local upgrade host computer is connected to the predetermined master chip. In some examples, the predetermined master chip can be a U2A8 chip, and the predetermined slave chip can be a J3 chip. The predetermined master chip performs diagnostic communication with the outside of the vehicle electronic controller based on the CAN communication protocol, and the upgrade file is downloaded from the local upgrade host computer to the predetermined master chip. The predetermined slave chip performs diagnostic communication with the outside of the vehicle electronic controller based on Ethernet, downloads the upgrade file to the chip, and the vehicle-mounted application on the predetermined master chip performs diagnostic communication with the predetermined slave chip based on the serial peripheral device interface to obtain the upgrade file.

[0058] During the remote upgrade process that supports the dual backup mechanism of remote upgrade and local upgrade, it is necessary to perform partition switching and consider the upgrade status and partition status of all chips during the partition switching process. When the upgrade fails, the partition switching fails, the response timeout of the scheduled slave chip occurs, the scheduled master chip needs to be switched back to the original partition. The data interaction between the scheduled slave chip and the scheduled master chip during the partition switching process needs to carry the following information: the status of the scheduled slave chip before the upgrade, combined with the signature verification result, compatibility verification result, installation process result, etc. The partition where the scheduled slave chip is currently located. According to the upgrade type (multi-chip whole package upgrade, single chip single package upgrade), determine whether the scheduled slave chip needs to be upgraded. Based on the mechanism of the scheduled slave chip coordinated partition switching instruction response timeout, if the scheduled master chip does not receive the response of the scheduled slave chip or the scheduled slave chip fails to respond to the partition switching, the scheduled master chip needs to be switched back to the original partition.

[0059] The software upgrade method of the vehicle-mounted electronic controller provided by the embodiment of the present invention is described in detail below through a specific embodiment.

[0060] like Fig.10 As shown, the software upgrade method of the vehicle electronic controller provided by the embodiment of the present invention includes the following steps: S201, starting a first boot loader; S202, the first boot loader performs a security check on the startup of the second boot loader, and if the first boot loader passes the security check on the startup of the second boot loader, the second boot loader is started; S203: If the first boot loader fails the startup security check of the second boot loader, use the first boot loader to upgrade the second boot loader; S204, the second boot loader performs a security check on the startup of the vehicle-mounted application, and if the second boot loader passes the security check on the startup of the vehicle-mounted application, the vehicle-mounted application is started; S205: If the second boot loader fails to pass the startup security check of the in-vehicle application, use the second boot loader to upgrade the in-vehicle application; S206: The started in-vehicle application obtains a remote upgrade file, and uses the upgrade file to upgrade the second boot loader and / or the in-vehicle application stored in the backup partition in the flash memory.

[0061] In a second aspect, an embodiment of the present invention provides a vehicle-mounted electronic controller that can improve the reliability of software operation and the flexibility of upgrading.

[0062] like Fig.11 As shown, an embodiment of the present invention further provides a vehicle-mounted electronic controller, comprising: a first control unit 21 and a flash memory 22; the flash memory 22 stores a first boot loader 23, a second boot loader 24 and a vehicle-mounted application 25; wherein the first control unit 21 is used in the software upgrade method of the vehicle-mounted electronic controller provided in any of the aforementioned embodiments.

[0063] In a third aspect, an embodiment of the present invention further provides a vehicle, on which is installed an on-board electronic controller, and the on-board electronic controller is the on-board electronic controller provided in the above embodiment.

[0064] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0065] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0066] In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0067] For the convenience of description, the above device is described by dividing the functions into various units / modules. Of course, when implementing the present invention, the functions of each unit / module can be implemented in the same or multiple software and / or hardware.

[0068] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0069] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A software upgrade method for an on-vehicle electronic controller, characterized in that: include: Start the first boot loader; The first boot loader performs a security check on the startup of the second boot loader, and if the first boot loader passes the security check on the startup of the second boot loader, the second boot loader is started; The second boot loader performs a security check on the startup of the vehicle-mounted application, and if the second boot loader passes the security check on the startup of the vehicle-mounted application, the vehicle-mounted application is started; The vehicle-mounted application obtains the remote upgrade file, and uses the remote upgrade file to upgrade the second boot loader and / or the vehicle-mounted application stored in the backup partition in the flash memory.

2. The software upgrade method according to claim 1, characterized in that: After starting the first boot loader, the method further includes: The first boot loader obtains the local upgrade file of the second boot loader from the local upgrade host computer, and uses the local upgrade file of the second boot loader to upgrade the second boot loader stored in the current activation area in the flash memory.

3. The software upgrade method according to claim 1, characterized in that: After starting the second boot loader, the method further includes: The second boot loader obtains the local upgrade file of the vehicle-mounted application from the local upgrade host computer, and uses the local upgrade file of the vehicle-mounted application to upgrade the vehicle-mounted application stored in the current activation area in the flash memory.

4. The software upgrade method according to claim 1, characterized in that: Before the in-vehicle application obtains the remote upgrade file, the method further includes performing at least one of the following operations: Close the currently running business algorithm program; Disable inter-chip service data transmission; Turn off logging of diagnostic trouble codes.

5. The software upgrade method according to claim 1, characterized in that: The vehicle-mounted electronic controller includes a first control unit, wherein the first control unit includes a first processing core and a second processing core; The vehicle-mounted application obtains the remote upgrade file, including: The first processing core obtains a remote upgrade file and sends the upgrade file to the second processing core through a shared memory; The second processing core calls the flash memory driver to erase the backup partition in the flash memory, so as to upgrade the second boot loader and / or the vehicle-mounted application stored in the backup partition in the flash memory using the upgrade file.

6. The software upgrade method according to claim 5, characterized in that: After the first processing core sends the upgrade file to the second processing core through the shared memory, the method further includes: The first processing core updates the flash memory state machine from flash memory operation idle to flash memory operation start erase / write; After the second processing core erases and writes the backup partition in the flash memory, the method further includes: If the second processing core successfully erases or writes the backup partition in the flash memory, the flash memory state machine is updated to indicate that the flash memory operation erase / write is completed; If the second processing core fails to erase or write the backup partition in the flash memory, the flash memory state machine is updated to a flash memory operation erase / write error.

7. The software upgrade method according to claim 6, characterized in that: The method further comprises: The first processing core acquires an operation spin lock of the flash state machine before updating the flash state machine to start erasing / writing the flash operation, and releases the acquired flash state machine operation spin lock after updating the flash state machine to start erasing / writing the flash operation; and The second processing core acquires the operation spin lock of the flash memory state machine before updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error, and releases the acquired flash memory state machine operation spin lock after updating the flash memory state machine to the end of the flash memory operation erase / write or the flash memory operation erase / write error.

8. The software upgrade method according to claim 2 or 3, characterized in that: After obtaining the local upgrade file of the second boot loader or the vehicle-mounted application from the local upgrade host computer, the method includes: The flash memory driver is called to erase the current active partition in the flash memory to upgrade the second boot loader or the vehicle-mounted application stored in the current active partition.

9. The software upgrade method according to claim 1, characterized in that: The on-board electronic controller includes a first control unit and a second control unit communicatively connected to the first control unit; Among them, the second control unit downloads the remote upgrade file from the remote upgrade host computer via Ethernet, and sends the remote upgrade file to the first control unit, and the first control unit uses the remote upgrade file to upgrade the second boot loader and / or vehicle-mounted application stored in the backup partition in the flash memory.

10. A vehicle-mounted electronic controller, characterized in that: include: a first control unit and a flash memory; The flash memory stores a first boot loader, a second boot loader and an in-vehicle application program; Wherein, the first control unit is used to execute the software upgrade method of the vehicle-mounted electronic controller as described in any one of claims 1 to 7.

11. A vehicle, characterized in that: The vehicle is equipped with an on-board electronic controller, which is the on-board electronic controller as claimed in claim 9.

Images