CN114756270A - Automatic driving system firmware upgrading method and automatic driving system - Google Patents
Automatic driving system firmware upgrading method and automatic driving system Download PDFInfo
- Publication number
- CN114756270A CN114756270A CN202210676733.1A CN202210676733A CN114756270A CN 114756270 A CN114756270 A CN 114756270A CN 202210676733 A CN202210676733 A CN 202210676733A CN 114756270 A CN114756270 A CN 114756270A
- Authority
- CN
- China
- Prior art keywords
- firmware
- automatic driving
- controller
- data packet
- check
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Abstract
The embodiment of the invention discloses an automatic driving system firmware upgrading method and an automatic driving system. The automatic driving system comprises an automatic driving computing platform, an automatic driving controller and an automatic driving vehicle; the method is applied to the automatic driving computing platform and comprises the following steps: in response to a server issuing a new version of firmware for the autonomous driving controller or in response to the autonomous driving controller requesting an upgrade of firmware, controlling the autonomous driving vehicle to curb a stop and notifying the autonomous driving controller via a CAN bus of a preparation for the upgrade of firmware; subcontracting, in response to the autopilot controller being ready, new version firmware and a plurality of check codes from the server to the autopilot controller over the CAN bus; and the plurality of check codes are used for the automatic driving controller to check each data packet and the new-version firmware, and the firmware is upgraded after the check is passed. The embodiment solves the problem of complex operation of upgrading the firmware by using a special downloader.
Description
Technical Field
The embodiment of the invention relates to the technical field of automatic driving, in particular to an automatic driving system firmware upgrading method and an automatic driving system.
Background
An embedded computing platform is one of important devices of an automatic driving system in a vehicle, and the computing platform generally adopts an MCU (micro controller Unit) chip as a main controller to control a vehicle state. The automatic driving system program code firmware (hereinafter referred to as firmware) running in the MCU is continuously improved and upgraded with the need of automatic driving function expansion. How to rapidly, safely and effectively realize the firmware upgrade of the automatic driving system is one of the important problems in the field of automatic driving.
In the prior art, a Joint Test Action Group (JTAG) downloader is used to upgrade MCU firmware, which requires a dedicated download interface for an embedded device, and is inconvenient for function expansion of an embedded platform, especially after a product arrives at a client.
Disclosure of Invention
The embodiment of the invention provides an automatic driving system firmware upgrading method and an automatic driving system, and aims to solve the problem that a special downloader is complex to upgrade firmware.
In a first aspect, an embodiment of the present invention provides a method for upgrading firmware of an automatic driving system, where the automatic driving system includes an automatic driving computing platform, an automatic driving controller, and an automatic driving vehicle; the method is applied to the automatic driving computing platform and comprises the following steps:
In response to a server issuing a new version of firmware for the autonomous driving controller or in response to the autonomous driving controller requesting an upgrade of firmware, controlling the autonomous driving vehicle to curb a stop and notifying the autonomous driving controller via a CAN bus of a preparation for the upgrade of firmware;
subcontracting, in response to the autopilot controller being ready, new version firmware and a plurality of check codes from the server to the autopilot controller over the CAN bus;
and the plurality of check codes are used for the automatic driving controller to check each data packet and the new-version firmware, and the firmware is upgraded after the check is passed.
In a second aspect, an embodiment of the present invention provides a method for upgrading firmware of an automatic driving system, where the automatic driving system includes an automatic driving computing platform, an automatic driving controller, and an automatic driving vehicle; a first indicating bit for indicating upgrading of local firmware and a second indicating bit for indicating running of the local firmware are arranged in the automatic driving controller; the method is applied to the automatic driving controller and comprises the following steps:
requesting, via a CAN bus, an upgrade to firmware from the autonomous computing platform in response to both the first indicator bit and the second indicator bit being cleared;
Responding to the notice of firmware upgrading preparation of the automatic driving computing platform, setting the first indicating bit, clearing the second indicating bit, and notifying the automatic driving computing platform of readiness through the CAN bus; restarting and receiving a new version firmware and a plurality of check codes from the automatic driving computing platform through the CAN bus sub-packets, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indication bit after the check is passed, setting the firmware operation indication bit and restarting to finish firmware upgrading.
In a third aspect, an embodiment of the present invention further provides an automatic driving system, including: an autonomous driving computing platform, an autonomous driving controller, and an autonomous driving vehicle;
the autopilot computing platform is to: in response to a server issuing a new version of firmware for the autonomous driving controller or in response to the autonomous driving controller requesting an upgrade of firmware, controlling the autonomous driving vehicle to curb a stop and notifying the autonomous driving controller via a CAN bus of a preparation for the upgrade of firmware; subcontracting, in response to the autopilot controller being ready, new version firmware and a plurality of check codes from the server to the autopilot controller over the CAN bus; the plurality of check codes are used for the automatic driving controller to check each data packet and the new-version firmware, and after the check is passed, the firmware is upgraded;
A first indicating bit for indicating upgrading of local firmware and a second indicating bit for indicating operation of the local firmware are arranged in the automatic driving controller; the autopilot controller is to: requesting, via a CAN bus, an upgrade firmware from the autonomous computing platform in response to the first indicator bit and the second indicator bit both being cleared; responding to the notice of firmware upgrading preparation of the automatic driving computing platform, setting the first indicating bit, clearing the second indicating bit, and notifying the automatic driving computing platform of readiness through the CAN bus; restarting and receiving a new version firmware and a plurality of check codes from the automatic driving computing platform through the CAN bus sub-packets, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indication bit after the check is passed, setting the firmware operation indication bit and restarting to finish firmware upgrading.
The embodiment of the invention realizes the firmware upgrade of the controller by means of the original existing CAN bus between the computing platform and the controller, does not need to carry out additional equipment transformation on the embedded computing platform and the controller, such as adding a special downloader, and the like, does not depend on the original firmware currently running in the controller in the upgrading process, does not require the consistency of a basic package, has simple operation and more flexible application scene, and is beneficial to the function expansion of an automatic driving system.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a schematic diagram of an automatic driving system according to an embodiment of the present invention.
Fig. 2 is a flowchart of a method for upgrading firmware of an automatic driving system according to an embodiment of the present invention.
Fig. 3 is a schematic diagram of various CAN message structures for firmware upgrade according to an embodiment of the present invention.
Fig. 4 is a flowchart of another method for upgrading firmware of an autopilot system according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions of the present invention will be clearly and completely described below. It is to be understood that the disclosed embodiments are merely exemplary of the invention, and are not intended to be exhaustive or exhaustive. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, and are only for convenience of description and simplification of description, but do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus, should not be construed as limiting the present invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance.
In the description of the present invention, it should also be noted that, unless otherwise explicitly stated or limited, the terms "mounted," "connected," and "connected" are to be construed broadly, e.g., as being fixed or detachable or integrally connected; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meanings of the above terms in the present invention can be understood in a specific case to those of ordinary skill in the art.
The embodiment of the invention provides an automatic driving system firmware upgrading method which is used for upgrading firmware in an automatic driving system. To illustrate the method, an autopilot system is described that deploys the method. Fig. 1 is a schematic diagram of an automatic driving system provided in an embodiment of the present invention, and as shown in fig. 1, the automatic driving system includes: an autonomous driving computing platform, an autonomous driving controller, and an autonomous driving vehicle.
An autonomous vehicle (hereinafter referred to as a vehicle) is a drive-by-wire vehicle or chassis. An autonomous computing platform (hereinafter computing platform) is an on-board computer deployed within a vehicle. The computing platform is used for computing vehicle decision information by combining a high-precision graph according to the real-time position and state information of the vehicle; on the other hand, the method is used for operating the firmware upgrading method of the automatic driving system provided by the embodiment of the application when the firmware of the automatic driving controller (hereinafter referred to as the controller) needs to be upgraded, and assisting the controller in upgrading the firmware.
The controller is an MCU controller for realizing vehicle drive-by-wire logic and is a communication medium between the vehicle and the computing platform. CAN (Controller Area Network) buses are respectively connected between the Controller and the vehicle and between the computing platform and the vehicle, the computing platform sends vehicle decision information to the Controller through the CAN buses, and the Controller realizes control of the vehicle. The firmware in the controller includes programs for functions such as transmitting vehicle controlled data, switching the automatic driving mode, and the like. The firmware is downloaded to the controller through the computing platform, the real-time state data of the vehicle is transmitted upwards in the running process of the firmware, and the vehicle drive-by-wire command is issued downwards.
The server is mainly used for storing various versions of firmware of the controller. And when the firmware of the controller needs to be upgraded every time, the firmware of the new edition is encrypted and stored to the server, so that the information tampering of the firmware is prevented. The server transmits the new firmware to the computing platform through a 5G or 4G network, and the computing platform transmits the new firmware to the controller through the CAN bus. It should be noted that the server in fig. 1 is shown by a dotted line to assist understanding of the operation mechanism of the automatic driving system, and is not a necessary component of the automatic driving system.
Based on the automatic driving system shown in fig. 1, fig. 2 is a flowchart of an automatic driving system firmware upgrading method according to an embodiment of the present invention. The method is executed by the computing platform and is suitable for assisting the controller in upgrading the local firmware. As shown in fig. 2, the method specifically includes the following steps:
and S110, responding to a server to release new-version firmware of the automatic driving controller, or responding to a request of upgrading the firmware of the automatic driving controller, controlling the automatic driving vehicle to stop at the roadside, and informing the automatic driving controller to prepare for upgrading the firmware through a CAN bus.
And the computing platform periodically monitors the updating condition of the firmware version on the server in the running process of the whole automatic driving system. The trigger conditions for the computing platform to run the firmware upgrading method provided by the embodiment include two conditions, one is that the server issues a new firmware version, and the other is that the controller actively requests to update the firmware version. And after any trigger condition is met, the computing platform makes a decision of slow parking according to the current road information, and meanwhile, the CAN bus informs the controller of preparing to upgrade the firmware.
Specifically, after any trigger condition is met, the computing platform firstly controls the automatic driving vehicle to switch to a manual driving mode, and sends a secret key to the automatic driving controller through the CAN bus to establish safe connection. Optionally, the secret key is determined by combining a VIN code (Vehicle Identification Number) and a unique ID of the MCU chip, and the connection is permitted only if the secret key is correct, and is not permitted if the secret key is incorrect, so that the Vehicle and the controller are in one-to-one correspondence, and the firmware is prevented from being hacked. After a secure connection is successfully established, the autopilot controller is notified of a preparation for firmware upgrade based on the secure connection.
S120, responding to the readiness of the automatic driving controller, and transmitting the new firmware and a plurality of check codes from the server to the automatic driving controller in a subpackage mode through the CAN bus; and the plurality of check codes are used for the automatic driving controller to check each data packet and the new firmware version, and the firmware is upgraded after the check is passed.
The check codes comprise a first check code used for checking the whole new firmware version and a second check code used for checking each data packet. Optionally, the first check code adopts an MD5 (Message-Digest Algorithm) check code, which is used to check the integrity and correctness of the entire new-version firmware; a second CRC (Cyclic Redundancy Check) Check code for checking the integrity and correctness of each data packet.
In a specific embodiment, the computing platform first transmits the first check code to the automatic driving controller through the CAN bus; in response to the autopilot controller successfully receiving the first check code, dividing the new version firmware from the server into at least one data packet. Optionally, the size of the single data packet is set by the controller. When the computing platform is ready to send the new firmware version, the size of the data packet in the controller is firstly queried, for example, 1024 bytes are obtained, and then the whole new firmware version is divided into a plurality of data packets according to the size.
And after dividing the data packets, the computing platform sequentially transmits each data packet to the automatic driving controller through the CAN bus, and a corresponding second check code is transmitted behind each data packet. Specifically, when the CAN bus is used to transmit the data packet, each data packet needs to be transmitted in multiple frames, and each frame is a complete CAN message. In order to ensure the safety and the integrity of data, the second check code of the data packet can be transmitted after any data packet is transmitted, so that the controller can check the data packet according to the second check code, and the data packet is successfully transmitted after the check is passed, and the next data packet is transmitted. And after all the data packets are successfully transmitted, the first check code is used for the controller to check the whole new-version firmware, and the firmware is successfully upgraded after the check is passed.
The firmware upgrading of the controller is realized by means of the existing CAN bus between the computing platform and the controller, the embedded computing platform and the controller are not required to be additionally modified, if a special downloader is added, the upgrading process does not depend on the original firmware of the current internal operation of the controller, the basic package is not required to be consistent, the operation is simple, the application scene is more flexible, and the function expansion of the automatic driving system is facilitated. In addition, the integrity of each data packet is verified through the second check code in the transmission of the new firmware version, the integrity of the whole firmware is verified through the first check code, the safe connection is established between the keys corresponding to the vehicles one by one and the controller, the defense controller receives external attack, the firmware is prevented from changing bricks in the upgrading process through multiple modes, and the safety and the stability of the automatic driving system are ensured.
On the basis of the above embodiment and the following embodiment, the present embodiment details the process of transmitting data packets by a computing platform. Optionally, the method sequentially transmits each data packet to the automatic driving controller through the CAN bus, and a corresponding second check code is transmitted after each data packet, and specifically includes the following steps:
Step one, constructing a plurality of CAN message structures for firmware upgrading, and notifying the automatic driving controller.
Based on the data transmission protocol of the CAN bus, the length of the CAN message is fixed and comprises 8 bytes. In the embodiment, firmware upgrade is performed through the CAN bus, a CAN message structure specially used for firmware upgrade is firstly constructed, and in a subsequent process, the computing platform and the controller analyze relevant information of the firmware upgrade according to the CAN message structure constructed in the step.
In one embodiment, first, a first field identifying the content of a transmission, a second field identifying a traffic statistics policy of the autopilot controller, a third field identifying a number of bytes of the new version of firmware, and a fourth field identifying a message sequence number are determined. In the transmission of the new firmware version, the transmission content of the CAN packet includes a data packet and a check code, in this embodiment, the data packet and the check code are transmitted by adopting different packet structures, and the first field is used to distinguish whether the transmitted data packet or the check code is transmitted. The second field is used for identifying a flow statistic strategy of the controller, including whether flow statistic is started or not, and a specific statistic mode when the flow statistic is started, and is used for judging whether the transmission of the new version firmware is finished or not according to the flow statistic strategy after the controller receives the CAN message. Specifically, the check code does not belong to the data content of the new version firmware, so that the message for transmitting the check code does not fall into the statistical range, and the controller does not need to start flow statistics; if the byte number of the new firmware version is small, the transmission can be finished through a frame of message, and the controller can directly judge that the transmission of the new firmware version is finished without starting flow statistics; if the number of bytes of the new firmware version is large and the transmission is finished through the multi-frame message, the controller needs to start flow statistics to judge whether the transmission of the new firmware version is finished.
Optionally, when the computing platform and the controller agree to implement traffic statistics by counting the number of valid bytes of the new version firmware that is accumulatively transmitted, different field values may be set for the second field to identify the following three traffic statistics policies:
the first flow statistical strategy is as follows: no flow statistics need to be initiated. The strategy is suitable for the situation that the new version firmware CAN be completely transmitted through one CAN message, or the transmission content of the current message is a check code (the check code usually has fewer digits and CAN be completely transmitted through one CAN message).
The second flow statistic strategy is as follows: and starting flow statistics, wherein the statistical mode is that valid bytes in the current message are counted from 0. The strategy is suitable for the condition that the current message is the first frame message of the data packet.
The third traffic statistic strategy is: and starting flow statistics, wherein the statistical mode is that the number of the effective bytes in the current message is continuously accumulated from the counted number of the effective bytes in the message of the previous frame. The strategy is suitable for the condition that the current message is not the first frame message of the data packet.
The third field is used for identifying the number of effective bytes actually included by the whole new firmware version, and is used for judging whether the whole new firmware version is completely transmitted or not by matching with a flow statistic strategy by the controller, and when the counted number of the received effective bytes is equal to the number in the third field, the new firmware version is completely transmitted. The fourth field is used for identifying the message sequence number, and is used for judging whether the messages in each data packet are received in sequence by the controller and checking the receiving correctness of the data packet from another angle.
After the four fields are determined, a first CAN message structure comprising the first field, the second field and the third field, a second CAN message structure comprising the second field and the third field, a third CAN message structure comprising the second field and the fourth field and a fourth CAN message structure comprising the first field and the second field are constructed. At least one of bytes of a data packet or a check code, the first field, the second field and the third field is fixed at the initial position in any one CAN message structure; the first field is used for identifying the current transmission content as a data packet in the first message structure, and is used for identifying the current transmission content as a check code in the fourth CAN message structure; the second field is used for identifying that the flow statistics does not need to be started in the first CAN message structure, and is used for identifying the start flow statistics in the second CAN message structure.
Fig. 3 is a schematic diagram of various CAN message structures for firmware upgrade according to an embodiment of the present invention. As shown in fig. 3, the first row of each CAN packet structure shows the name of a byte or a field, and the second row shows the value of the byte (0 x represents a 16-ary number, and the following field values are default to 16-ary representation). A field CMD is a first field, if the first field exists in the CAN message, the initial position of the first field is fixed at the fourth byte of the CAN message, and when CMD =03, the transmission content of the current message is indicated as a data packet; and when CMD =0E, indicating that the transmission content of the current message is the check code. The high four bits of the field Resource Availability are a second field, and if the second field exists in the CAN message, the initial position of the second field is fixed to a second byte of the CAN message; when four high bits of Resource Availability =0, indicating that a first flow statistic strategy is adopted by the current message; when four high bits of Resource Availability =1, indicating that a second flow statistic strategy is adopted by the current message; and when the four high bits of Resource Availability =2, indicating that the current message adopts a third traffic statistic strategy. The field CTR is a fourth field, and if the fourth field exists in the CAN message, the initial position of the fourth field is fixed in a third byte of the CAN message; the field CTR is used for identifying the message serial number in the data packet and circulates from 0 to 255. If the third field exists in the CAN message, the initial position of the third field is fixed to the fourth bit of the second byte; in the first CAN message structure, the lower four bits of Resource Availability are the third field, and as the number of bytes of firmware is less, the length of the firmware is recorded by 4 bits; in the second CAN message structure, the lower four bits and the third byte of Resource Availability together form a second field, and the length of 12-bit recording firmware is set because the number of bytes of firmware is more. The starting position of the effective byte of the data packet in each CAN message structure is fixed, the effective byte starts from the fifth byte in the first CAN message structure, starts from the sixth sub-street in the second CAN message structure, and starts from the fourth byte in the third CAN message structure. The check code is fixedly started from the fifth byte in the fourth CAN message structure.
It should be noted that, in this embodiment, the above-mentioned construction and notification process of the CAN message structure is executed by a computing platform. In fact, the process of constructing and notifying may be executed by the controller, or may be executed by a third-party device, as long as the message structure is constructed and then notified to each other between the computing platform and the controller to form a convention.
And step two, determining a plurality of CAN message structures for transmitting each data packet and the corresponding second check code according to the byte number of the new firmware version. After the four CAN message structures are determined, different message structures or combinations thereof are selected according to the data characteristics to transmit the data packet and the second check code, so that the controller CAN correctly identify effective information from the message according to the four message structures after receiving the CAN message. This embodiment describes a selection manner of a message structure, and an identification manner of the controller will be described in detail in the following embodiments, which are not described herein again.
Optionally, it is determined that the fourth CAN message structure is adopted to transmit the second check code; if the byte number of the new firmware version is smaller than or equal to a set threshold value, determining that each data packet is transmitted by adopting the first CAN message structure; if the byte number of the new firmware version is larger than the set threshold value, determining that the first frame byte of each data packet is transmitted by adopting the second message structure, and transmitting the rest bytes of each data packet except the first frame byte by adopting the third message structure; wherein the set threshold is determined according to the minimum number of bytes required by the first field, the second field and the third field.
Continuing with the example of fig. 3, CMD =0E in the fourth CAN message structure is suitable for the case of transmitting the second check code. In the first CAN message structure, the upper four bits of Resource Availability =0, which is suitable for the case that the new firmware version CAN be transmitted through one CAN message, and except for Resource Availability (the second field and the third field) and CMD (the first field), the number of bytes that CAN be held by the remaining idle fields is the set threshold, and the set threshold =4 in fig. 3. In the second message structure, the upper four bits =0 of Resource Availability is applicable to the case of transmitting the first frame byte of the data packet. In the third message structure, the upper four bits =0 of Resource Availability is applicable to the case of transmitting the remaining bytes except the first frame byte of the data packet.
And step three, packaging each data packet and the corresponding second check code into a plurality of CAN messages according to the plurality of CAN message structures, and identifying the plurality of CAN messages for firmware upgrading through the appointed CAN ID. The unoccupied ID in the existing CAN bus is selected and agreed as the ID for firmware upgrade, so that the CAN message for firmware upgrade in this embodiment CAN be distinguished from the existing CAN message (e.g., a fault diagnosis message) in the automobile.
And step four, sequentially transmitting each CAN message to the automatic driving controller through the CAN bus.
In the embodiment, in order to transmit the new firmware version through the CAN bus, a CAN message structure special for firmware upgrading is constructed through the permutation and combination of information such as transmission content, a flow statistic strategy, the byte number of the new firmware version, message serial number and the like, various data characteristics in data packet and check code transmission are covered by the minimum identification field, the CAN message for firmware upgrading and the original CAN message are distinguished through the appointed CAN ID, and the controller CAN accurately identify effective information of firmware upgrading after receiving the CAN message.
In the automatic driving system shown in fig. 1, a first indication bit for indicating upgrading of local firmware and a second indication bit for indicating running of the local firmware are provided in the automatic driving controller. The first indication bit is set after responding to the notification of the computing platform that the firmware is to be upgraded, the indication bit is set after the firmware is executed for the first time, and after the controller is started up each time and completes hardware initialization, the controller firstly runs a starting bootstrap program, reads the first indication bit and the second indication bit, and executes subsequent operations according to the indication of the first indication bit and the second indication bit. The starting bootstrap program is burned in the controller through a JTAG interface before the controller leaves a factory. By running the first indicator bit and the second indicator bit read by the boot loader, which still keep the value of the last shutdown, the following situations can occur:
The first indicator bit =0 and the second indicator bit =0, which are used to indicate that there is no firmware program that can be executed in the controller, the controller continues to perform the subsequent operation of starting the boot program.
And in case two, the first indicator bit =1 and the second indicator bit =0 are used to instruct the controller to upgrade the local firmware, and then the controller performs an operation of receiving a new version of firmware in the boot program.
And in case three, the first indication bit =0 and the second indication bit =1 are used for indicating the controller to run the local firmware, and then the controller jumps to the firmware program and executes the firmware program.
And in the fourth case, the first indication bit =1 and the second indication bit =1, when the instructions for upgrading the local firmware and running the local firmware are contradictory, the controller stops the program execution and reports an error.
Based on the above program execution logic of the controller, fig. 4 is another method for upgrading firmware of an automatic driving system according to an embodiment of the present invention. The method is executed by the controller and is suitable for the condition of upgrading the local firmware of the controller with the assistance of the computing platform. As shown in fig. 4, the method specifically includes the following steps:
and S210, responding to the situation that the first indicating bit and the second indicating bit are all cleared, and requesting the automatic driving computing platform to upgrade the firmware through a CAN bus.
As described above, when the first indicator bit =0 and the second indicator bit =0 indicate that there is no firmware program that can be executed within the controller, the controller requests the computing platform to upgrade the firmware while continuing to execute the boot loader.
S220, responding to the notice of the automatic driving computing platform to prepare for updating the firmware, setting the first indicating bit, clearing the second indicating bit, and notifying the automatic driving computing platform of readiness through the CAN bus; restarting and receiving a new version firmware and a plurality of check codes from the automatic driving computing platform through the CAN bus sub-packets, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indicating bit after the check is passed, setting the firmware running indicating bit and restarting to finish firmware upgrading.
Specifically, the controller first receives a key sent by the computing platform, and the computing platform requests to establish a secure connection through the key. The controller verifies the key, the key is allowed to be sent again after being wrong, and the verification is not continued after the verification fails for a set number of times (for example, 3 times). And after the verification is passed, judging whether the current speed of the vehicle is 0 or not. And if the vehicle speed is 0, setting a first indicating bit, clearing a second indicating bit, and informing the automatic driving computing platform of readiness through a CAN bus. And after the notification is finished, the controller is restarted, the boot program is still executed after the restart, the first indication bit =1 and the second indication bit =0 are read, then the readiness is fed back to the computing platform, and meanwhile, the process of receiving the new version firmware is started.
To prevent the firmware from being tiled during the upgrade process, the FLASH area of the autopilot controller includes a firmware execution area and a firmware backup area. The firmware backup area is used for storing each data packet of the new version firmware in the receiving process, and the firmware execution area is used for storing the completely received and executable new version firmware. Correspondingly, the process of the controller receiving the new firmware version specifically includes:
firstly, receiving the second check code and writing the second check code into the firmware backup area, then receiving a current data packet and a corresponding second check code, and checking the current data packet according to the corresponding second check code. And if the verification is not passed, requesting the computing platform to resend the current data packet until the verification is passed. And if the verification is passed, writing the current data packet into the firmware backup area, and entering an iterative loop operation of receiving the next data packet and the corresponding second check code until each data packet passes the verification.
And after each data packet passes the verification, verifying the whole new-version firmware by using the second verification code. Optionally, the second check code is an MD5 check code, and the MD5 check is performed on the whole new version firmware by using the check code. And writing the new version firmware into a firmware execution area after the verification is passed.
And after the firmware execution area is written, continuously checking the whole new version firmware written in the firmware execution area by using the second check code. And if the verification is not passed, directly restarting, returning to the operation of 'feeding back to the computing platform to be ready and starting the flow of receiving the new firmware version' until the whole verification of the new firmware version written into the firmware execution area is passed. And clearing the firmware upgrading indicating bit after the verification is passed, setting the firmware running indicating bit and restarting.
In this embodiment, in order to prevent the firmware from changing into a brick due to a failed firmware upgrade, a firmware execution area and a firmware backup area are partitioned in a FLASH area of the controller, the firmware in the firmware backup area is allowed to be carried to the firmware execution area after being subjected to the overall verification, and the first indicator bit is allowed to be clear after the firmware in the firmware execution area is subjected to the overall verification. Because the original firmware operated by the current controller is stored in the firmware execution area, the whole firmware upgrading process does not depend on the original firmware and does not require the consistency of the basic package. The setting of first instruction bit and second instruction bit has stipulated the program execution logic of controller on the one hand, and on the other hand cooperates with measures such as the completion of data check, just sets and clears away after all checks pass, effectively prevents that the firmware from changing the brick in the upgrading process, realizes the cross-level extension of same controller function, and the upgrading of controller firmware provides safe convenient mode.
On the basis of the above-described embodiment and the following embodiment, the present embodiment refines the process of receiving a data packet by a controller. Optionally, the new firmware and the check codes are packaged to be transmitted as a CAN message, the CAN message adopts the agreed CAN ID and the four CAN message structures, and the controller receives the new firmware and the check codes from the autopilot computing platform by sub-packet through the CAN bus, which specifically includes the following steps:
step one, identifying the CAN message for firmware upgrading according to the CAN ID of the received CAN message. After the controller receives a CAN message, if the CAN ID of the message is the ID for firmware upgrading agreed by the controller and the computing platform, the next operation is carried out according to the subsequent firmware upgrading flow; if the CAN ID of the message is not the agreed ID for firmware upgrade, the next operation is performed according to other procedures (such as a fault diagnosis procedure), and specific operations of other procedures do not belong to the scope discussed in this embodiment and are not described again.
And step two, reading a data packet or a check code from the CAN message based on the CAN message structure used for firmware upgrading notified by the automatic driving computing platform. After recognizing that the received message is a CAN message for firmware upgrading, the controller reads key fields and effective data contents in the message according to a CAN message structure agreed with the computing platform.
In one embodiment, the four CAN message structures shown in fig. 3 are still used to transmit the new firmware version, and after receiving a CAN message for firmware upgrade, the controller first reads the second field starting from the first fixed location, i.e. the upper four bits of Resource Availability in the second byte. If the high four digits of Resource Availability =0, it indicates that the current CAN message adopts the first CAN message structure or the fourth CAN message structure, and the two message structures both adopt the first traffic statistic strategy, that is, the traffic statistic does not need to be started. The controller then further reads the first field starting at the second fixed location, i.e., the CMD field located in the fourth byte. If CMD =03, it is indicated that the transmission content of the current message is a data packet of a new version firmware with the byte number smaller than or equal to the set threshold value, and the valid bytes of the data packet are directly read from the third fixed position according to the agreed message structure, that is, the data 1-data 4 are read from the fifth byte, and the data packet is completely read. And if CMD =0E, indicating that the transmission content of the current message is the check code, directly reading the second check code from the fourth fixed position according to the agreed message structure, namely reading the CRC check code from the fifth byte and the sixth byte.
If the high four bits of Resource Availability =1, it is indicated that the current CAN message adopts a second CAN message structure, and the first frame message of the data packet of the new version firmware with the byte number larger than the set threshold value is transmitted. Therefore, according to the agreed data structure, the number of valid bytes actually included in the new version firmware is read from the lower four bits and the third byte of the Resource Availability, and the valid bytes of the current data packet are read from the fifth fixed position, that is, the data 1 to the data 3 are read from the sixth byte as the valid bytes of the current data packet. Meanwhile, the message adopts a second flow statistic strategy, starts flow statistic, and counts the effective bytes in the current message from 0.
If the high four bits of Resource Availability =2, it is indicated that the current message adopts a third CAN message structure, and the transmitted messages are the rest messages except the first frame message in the data packet of the new version firmware with the byte number larger than the set threshold. Therefore, according to the agreed data structure, the valid byte of the current data packet is read from the sixth fixed position, and the data 1-data 5 are read from the fourth byte as the valid byte of the current data packet; and meanwhile, the message adopts a third flow counting strategy to start flow counting, and the number of the effective bytes in the current message is continuously accumulated from the counted number of the effective bytes in the previous frame of message. Furthermore, when the data packet is sent in frames, each frame of message has a sequence number, the sequence number of the message of two continuous frames is verified through the record of a fourth field (CTR field) after the controller receives the data, if the sequence number of the message of the previous frame and the sequence number of the current message frame do not meet the set rule (if the sequence number is discontinuous), the data is judged to be lost, and the firmware upgrading readiness is fed back to the computing platform again until the firmware upgrading is completed.
It should be noted that, when the new firmware version includes a plurality of data packets, the second traffic statistic policy and the third traffic statistic policy are executed in cooperation, so that the number of effective bytes transmitted by each data packet can be counted. After the number of the effective bytes transmitted by each data packet is counted, the number of the effective bytes transmitted by all the data packets is accumulated, and the number of the effective bytes transmitted by the whole new firmware version can be obtained. When the number is equal to the number of valid bytes actually included in the entire newer firmware version (identified by the third field), it can be determined that the entire newer firmware version is completely transferred.
In this embodiment, the CAN packet for firmware upgrade is identified based on the CAN ID agreed by the computing platform and the controller, the current packet structure is determined by the agreed field value, and the valid bytes of the data packet or the check code are read from the corresponding fixed position in the packet structure. The embodiment realizes data transmission of the new version firmware completely based on the existing form of the CAN bus and the CAN message, does not need to construct a new basic message, is simple to use, and CAN ensure the correctness of information transmission.
An automatic driving system provided by the embodiment of the invention is shown in figure 1. The automatic driving system includes: an autonomous driving computing platform, an autonomous driving controller, and an autonomous driving vehicle. The autopilot computing platform is to: in response to a server issuing a new version of firmware for the autonomous driving controller or in response to the autonomous driving controller requesting an upgrade of firmware, controlling the autonomous driving vehicle to curb a stop and notifying the autonomous driving controller via a CAN bus of a preparation for the upgrade of firmware; subcontracting, in response to the autopilot controller being ready, new version firmware and a plurality of check codes from the server to the autopilot controller over the CAN bus; and the plurality of check codes are used for the automatic driving controller to check each data packet and the new-version firmware, and the firmware is upgraded after the check is passed.
A first indicating bit for indicating upgrading of local firmware and a second indicating bit for indicating operation of the local firmware are arranged in the automatic driving controller; the autopilot controller is to: requesting, via a CAN bus, an upgrade firmware from the autonomous computing platform in response to the first indicator bit and the second indicator bit both being cleared; responding to the notice of firmware upgrading preparation of the automatic driving computing platform, setting the first indicating bit, clearing the second indicating bit, and notifying the automatic driving computing platform of readiness through the CAN bus; restarting and receiving a new version firmware and a plurality of check codes from the automatic driving computing platform through the CAN bus sub-packets, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indication bit after the check is passed, setting the firmware operation indication bit and restarting to finish firmware upgrading.
The computing platform and the controller of this embodiment are adapted to perform the method of any of the above and below described embodiments, and have the technical effects of any of the above described embodiments.
The following further describes operation steps and timing of each part in the automatic driving system in the firmware upgrading process through a specific implementation mode. The firmware upgrading process of the whole automatic driving system comprises the following operations:
1) When the embedded computing platform is used for the first time, the startup boot program is downloaded to the controller through the JTAG special downloader, and then the firmware upgrading method or the JTAG special downloader provided by the embodiment can be operated to download the new version firmware to the controller. However, once the computing platform is installed on the automatic driving vehicle, the operation of using the JTAG dedicated downloader is very cumbersome and suitable for firmware upgrade using the method provided in the above embodiment. And verifying a secret key formed by combining the VIN code of the vehicle and the unique ID of the MCU chip when the firmware runs for the first time, setting a firmware running zone bit after the secret key is correct, and otherwise, clearing the firmware running zone bit.
2) After the controller is started each time and hardware initialization is completed, a starting bootstrap program is operated firstly, a first indicating bit and a second flag bit are judged in the starting bootstrap program, and the starting bootstrap program is divided into several conditions: the first indication bit =1 and the second indication bit =0, at this time, the controller feeds back the readiness of upgrading the firmware to the upper computer from the computing platform, executes a new version firmware receiving process in the boot program, and waits for receiving the new version firmware; the first indication bit =0 and the second indication bit =1, and the controller jumps to the existing firmware and executes the existing firmware; the first indicator bit =0 and the second indicator bit =0, when the controller requests the computing platform to upgrade firmware, no firmware is available inside the controller, and the boot loader is executed. The second indication bit is set when the firmware is upgraded and is executed for the first time. And after the computing platform notifies that the firmware is ready to be upgraded, setting the first indication bit and clearing the second indication bit. In the firmware upgrading process, the controller is used for receiving the second frame message in order to prevent the second frame message from being received when the previous frame message is not processed, and an FIFO multi-buffer data area is used for receiving the firmware data.
3) After monitoring that the server releases the new version firmware in the running process of the vehicle, the computing platform makes a decision for enabling the vehicle to stop at the side according to the current road and vehicle information, downloads the latest version firmware from the server after the vehicle stops stably, and then sends a secret key to establish safe connection with the controller. The controller verifies the secret key, and if the secret key is correct, the secure connection is successfully established. If the key is wrong, three attempts are allowed, and after the three attempts fail, the controller clears the second indicating bit and runs the boot starting program.
4) After the computing platform is safely connected with the controller, the controller judges whether the current speed of the vehicle is 0 or not, if the vehicle speed is 0, the second indicating bit is set, the first indicating bit is cleared, and the controller is restarted.
5) After the controller is restarted, a starting application program is operated, the first indicating bit =1 and the second indicating bit =0 are read, and the computing platform is informed that the firmware is ready for upgrading.
6) After receiving the ready notification, the computing platform firstly sends an MD5 check code of the whole new firmware version, the controller writes the MD5 check code into a corresponding FLASH area after receiving the MD5 check code, and feeds back to the computing platform that the firmware data packet is required to be sent after receiving the complete MD5 check code.
7) And after receiving the request for sending the firmware data packet, the computing platform sends the firmware data packet of the new edition, and the size of each packet of data is set in the controller. When the computing platform sends a data packet, firstly, the value of the data packet size in the firmware is inquired, for example, 1024 bytes, and the whole firmware data packet is sent according to the data size of a single packet. Each packet of data is sent in multiple frames, each frame is a complete CAN message, and the CAN message structure shown in fig. 3 is adopted for sending. To ensure data integrity, each packet of data is checked for CRC16 and the check bits are sent to the controller after the packet of data. When each packet of data is sent in frames, a message serial number is provided, the controller CAN verify the message serial numbers of two continuous frames after receiving the CAN message, if the serial number of the previous frame and the serial number of the current frame do not meet the set rule, the message is judged to be lost, and the current data packet is requested to be sent again to the computing platform.
8) And in the process of sending the data packet and the check code, the computing platform determines the used CAN message structure according to the byte number included in the whole new-version firmware. And when the byte number of the whole new-version firmware is less than or equal to 4 bytes, sending the data packet by adopting a first CAN message structure, and sending the CRC (cyclic redundancy check) code of the data packet by adopting a fourth CAN message structure. When the byte number of the whole new firmware version is more than 4 bytes, the first frame message of each data packet adopts a second CAN message structure, a third CAN message structure is adopted from the second frame, and when the byte number is less than 6 bytes, the first frame message is supplemented by 0 xFF; and after the whole data packet is sent, sending the CRC16 check value of the data packet by adopting a fourth CAN message structure. In fig. 3, the node address in the message structure is obtained by specific calculation from the unique chip ID of the controller. After the controller receives the CAN message for firmware upgrading, the specific CAN message structure is judged according to bytes such as Resource Availability, CMD and the like. If the result of Resource Availability &0xf0 is 0x00, whether the structure is the first CAN message structure or the fourth CAN message structure is distinguished according to the type of CMD; if the result of Resource Availability &0xf0 is 0x10, determining that the current message is the second CAN message structure; if the result of Resource Availability &0xf0 is 0x20, determining that the current message is a third CAN message structure; and after the specific message structure is judged, acquiring corresponding firmware information according to the position of the effective byte corresponding to the data structure.
9) The controller performs a CRC16 check each time a packet is received. And if the verification is not passed, the current data packet is requested to be sent again, and the current data packet is written into the firmware backup area after the verification is passed until all the data packets are received. And then MD5 verification is carried out on the whole new firmware, after the verification is passed, the firmware backup area is copied to the firmware execution area, and then MD5 verification is carried out on the data of the firmware execution area. After the verification is passed, the controller erases the first indication bit, sets the second indication bit and restarts the controller; otherwise, directly restarting the controller, and returning to the step 5) until the firmware is upgraded successfully.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present invention.
Claims (10)
1. An automatic driving system firmware upgrading method is characterized in that the automatic driving system comprises an automatic driving computing platform, an automatic driving controller and an automatic driving vehicle; the method is applied to the automatic driving computing platform and comprises the following steps:
in response to a server issuing a new version of firmware for the autonomous driving controller or in response to the autonomous driving controller requesting an upgrade of firmware, controlling the autonomous driving vehicle to curb a stop and notifying the autonomous driving controller via a CAN bus of a preparation for the upgrade of firmware;
subcontracting, in response to the autopilot controller being ready, new version firmware and a plurality of check codes from the server to the autopilot controller over the CAN bus;
and the plurality of check codes are used for the automatic driving controller to check each data packet and the new-version firmware, and the firmware is upgraded after the check is passed.
2. The method of claim 1, wherein notifying the autonomous driving controller via the CAN bus of a readiness to upgrade firmware comprises:
controlling the autonomous vehicle to switch to a manual driving mode;
sending a secret key to the automatic driving controller through a CAN bus to establish safe connection;
Notifying the autopilot controller, via the secure connection, that firmware is ready for upgrade.
3. The method according to claim 1, wherein the plurality of check codes comprise a first check code for checking the whole of the new version firmware and a second check code for checking each data packet;
the transmitting the new version firmware and the plurality of check codes from the server to the automatic driving controller by sub-packets through the CAN bus comprises:
transmitting the first check code to the automatic driving controller through the CAN bus;
in response to the autopilot controller successfully receiving the first check code, dividing the new version firmware from the server into at least one data packet;
and sequentially transmitting each data packet to the automatic driving controller through the CAN bus, wherein a corresponding second check code is transmitted behind each data packet.
4. The method of claim 3, wherein transmitting each data packet in turn to the autopilot controller over the CAN bus, each data packet being followed by a corresponding second parity code comprises:
determining various CAN message structures for transmitting each data packet and the corresponding second check code according to the byte number of the new firmware version;
Packaging each data packet and the corresponding second check code into a plurality of CAN messages according to the plurality of CAN message structures, and identifying the plurality of CAN messages for firmware upgrading through the appointed CAN ID;
and sequentially transmitting each CAN message and the corresponding second check code to the automatic driving controller through the CAN bus.
5. The method of claim 4, further comprising, before determining the plurality of CAN message structures for transmitting each packet and the corresponding second check code according to the number of bytes of the new firmware version:
determining a first field for identifying transmission content, a second field for identifying a flow statistics strategy of the automatic driving controller, a third field for identifying the number of bytes of the new version firmware, and a fourth field for identifying a message sequence number, wherein the transmission content comprises a data packet and a check code, and the flow statistics strategy comprises whether flow statistics is started or not and a statistics mode;
constructing a first CAN message structure comprising the first field, the second field and the third field, a second CAN message structure comprising the second field and the third field, a third CAN message structure comprising the second field and the fourth field and a fourth CAN message structure comprising the first field and the second field, and notifying the automatic driving controller;
The first field is used for identifying the current transmission content as a data packet in the first message structure, and is used for identifying the current transmission content as a check code in the fourth CAN message structure; the second field is used for marking that the flow statistics does not need to be started in the first CAN message structure, and is used for marking that the flow statistics is started in the second CAN message structure.
6. The method of claim 5, wherein determining a plurality of CAN message structures for transmitting each data packet and the corresponding second check code according to the number of bytes of the new firmware version comprises:
determining to transmit the second check code by adopting the fourth CAN message structure;
if the byte number of the new firmware version is smaller than or equal to a set threshold value, determining that each data packet is transmitted by adopting the first CAN message structure;
if the byte number of the new firmware version is larger than the set threshold value, determining that the first frame byte of each data packet is transmitted by adopting the second message structure, and transmitting the rest bytes of each data packet except the first frame byte by adopting the third message structure;
wherein the set threshold is determined according to the minimum number of bytes required by the first field, the second field and the third field.
7. An automatic driving system firmware upgrading method is characterized in that the automatic driving system comprises an automatic driving computing platform, an automatic driving controller and an automatic driving vehicle; a first indicating bit for indicating upgrading of local firmware and a second indicating bit for indicating operation of the local firmware are arranged in the automatic driving controller; the method is applied to the automatic driving controller and comprises the following steps:
requesting, via a CAN bus, an upgrade firmware from the autonomous computing platform in response to the first indicator bit and the second indicator bit both being cleared;
responding to the notice of the automatic driving computing platform to prepare for updating the firmware, setting the first indicating bit, clearing the second indicating bit, and notifying the automatic driving computing platform of the readiness through the CAN bus; restarting and receiving a new version firmware and a plurality of check codes from the automatic driving computing platform through the CAN bus sub-packets, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indicating bit after the check is passed, setting the firmware running indicating bit and restarting to finish firmware upgrading.
8. The method according to claim 7, wherein the plurality of check codes comprise a first check code for checking the whole of the new version firmware and a second check code for checking each data packet; the FLASH area of the automatic driving controller comprises a firmware execution area and a firmware backup area;
the method comprises the following steps of receiving new version firmware and a plurality of check codes from the automatic driving computing platform by sub-packet through the CAN bus, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indicating bit after the check is passed, setting the firmware running indicating bit and restarting the firmware, and comprises the following steps:
receiving the second check code and writing the second check code into the firmware backup area;
receiving a current data packet and a corresponding second check code, checking the current data packet according to the second check code, writing the current data packet into the firmware backup area after the check is passed, and entering an iterative loop operation of receiving a next data packet and the corresponding second check code until each data packet is checked to be passed;
checking the whole new firmware version through the second check code, and writing the new firmware version into a firmware execution area after the check is passed;
And checking the whole new-version firmware written into the firmware execution area by using the second check code, clearing the firmware upgrading indicating bit after the check is passed, and setting the firmware operation indicating bit.
9. The method of claim 7, wherein the new version firmware and the plurality of check codes are encapsulated into a CAN message transmission;
the receiving of the new version firmware and the plurality of check codes from the autopilot computing platform through the CAN bus sub-package comprises:
identifying the CAN message for firmware upgrading according to the CAN ID of the received CAN message;
and reading a data packet or a check code from the CAN message based on the CAN message structure for firmware upgrading notified by the automatic driving computing platform.
10. An autopilot system, comprising: an autonomous driving computing platform, an autonomous driving controller, and an autonomous driving vehicle;
the autopilot computing platform is to: in response to a server issuing a new version of firmware for the autonomous driving controller or in response to the autonomous driving controller requesting an upgrade of firmware, controlling the autonomous driving vehicle to curb a stop and notifying the autonomous driving controller via a CAN bus of a preparation for the upgrade of firmware; subcontracting, in response to the autopilot controller being ready, new version firmware and a plurality of check codes from the server to the autopilot controller over the CAN bus; the plurality of check codes are used for the automatic driving controller to check each data packet and the new-version firmware, and after the check is passed, the firmware is upgraded;
A first indicating bit for indicating upgrading of local firmware and a second indicating bit for indicating running of the local firmware are arranged in the automatic driving controller; the autopilot controller is to: requesting, via a CAN bus, an upgrade to firmware from the autonomous computing platform in response to both the first indicator bit and the second indicator bit being cleared; responding to the notice of the automatic driving computing platform to prepare for updating the firmware, setting the first indicating bit, clearing the second indicating bit, and notifying the automatic driving computing platform of the readiness through the CAN bus; restarting and receiving a new version firmware and a plurality of check codes from the automatic driving computing platform through the CAN bus sub-packets, checking each data packet and the whole new version firmware according to the check codes, clearing the firmware upgrading indicating bit after the check is passed, setting the firmware running indicating bit and restarting to finish firmware upgrading.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210676733.1A CN114756270B (en) | 2022-06-16 | 2022-06-16 | Automatic driving system firmware upgrading method and automatic driving system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210676733.1A CN114756270B (en) | 2022-06-16 | 2022-06-16 | Automatic driving system firmware upgrading method and automatic driving system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114756270A true CN114756270A (en) | 2022-07-15 |
| CN114756270B CN114756270B (en) | 2022-09-16 |
Family
ID=82337201
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210676733.1A Active CN114756270B (en) | 2022-06-16 | 2022-06-16 | Automatic driving system firmware upgrading method and automatic driving system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114756270B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2353959A1 (en) * | 2010-01-28 | 2011-08-10 | Centrum Dopravniho Vyzkumu | Apparatus for monitoring and analysing a manner of driving |
| CN104266671A (en) * | 2014-09-05 | 2015-01-07 | 延锋伟世通电子科技（上海）有限公司 | Automobile instrument driving information automatic testing system based on CAN bus and vision detection |
| CN106114623A (en) * | 2016-06-16 | 2016-11-16 | 江苏大学 | A kind of automatic parking paths planning method based on human vision and system |
| CN106648669A (en) * | 2016-12-26 | 2017-05-10 | 广东芬尼克兹节能设备有限公司 | Remote firmware upgrading method and system for product equipment |
| CN110659049A (en) * | 2019-09-24 | 2020-01-07 | 北京智行者科技有限公司 | OTA (over the air) upgrading method and terminal equipment for automatic driving vehicle |
| CN112486554A (en) * | 2020-12-01 | 2021-03-12 | 中国科学院合肥物质科学研究院 | Vehicle-mounted networking terminal software upgrading method |
| CN112788129A (en) * | 2020-12-31 | 2021-05-11 | 江苏徐工工程机械研究院有限公司 | Engineering machinery vehicle remote upgrading system and method |
| CN113886899A (en) * | 2021-09-17 | 2022-01-04 | 中汽数据(天津)有限公司 | Method, device, equipment and medium for managing service life of automatic driving software |
-
2022
- 2022-06-16 CN CN202210676733.1A patent/CN114756270B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2353959A1 (en) * | 2010-01-28 | 2011-08-10 | Centrum Dopravniho Vyzkumu | Apparatus for monitoring and analysing a manner of driving |
| CN104266671A (en) * | 2014-09-05 | 2015-01-07 | 延锋伟世通电子科技（上海）有限公司 | Automobile instrument driving information automatic testing system based on CAN bus and vision detection |
| CN106114623A (en) * | 2016-06-16 | 2016-11-16 | 江苏大学 | A kind of automatic parking paths planning method based on human vision and system |
| CN106648669A (en) * | 2016-12-26 | 2017-05-10 | 广东芬尼克兹节能设备有限公司 | Remote firmware upgrading method and system for product equipment |
| CN110659049A (en) * | 2019-09-24 | 2020-01-07 | 北京智行者科技有限公司 | OTA (over the air) upgrading method and terminal equipment for automatic driving vehicle |
| CN112486554A (en) * | 2020-12-01 | 2021-03-12 | 中国科学院合肥物质科学研究院 | Vehicle-mounted networking terminal software upgrading method |
| CN112788129A (en) * | 2020-12-31 | 2021-05-11 | 江苏徐工工程机械研究院有限公司 | Engineering machinery vehicle remote upgrading system and method |
| CN113886899A (en) * | 2021-09-17 | 2022-01-04 | 中汽数据(天津)有限公司 | Method, device, equipment and medium for managing service life of automatic driving software |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114756270B (en) | 2022-09-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10437680B2 (en) | Relay apparatus, relay method, and computer program product | |
| US20220156057A1 (en) | In-vehicle update device, update processing program, and program update method | |
| CN109828769B (en) | Embedded program remote updating system and method based on TCP/IP | |
| CN105278994A (en) | Updating method and updating system of vehicle-mounted ECU (Electronic Control Unit) software | |
| CN112953775B (en) | Vehicle machine upgrading system and method | |
| CN105426198A (en) | Vehicle onboard double-control-chip system and auxiliary control chip program update method therefor | |
| JPH10289108A (en) | Remote program downloading device | |
| WO2020179592A1 (en) | Vehicle-mounted updating device, update processing program, and program updating method | |
| CN111886576A (en) | Method and apparatus for updating remote network device | |
| EP3399410A1 (en) | Method and system for software installation in a vehicle | |
| CN110995724A (en) | Remote upgrading method for whole vehicle controller of new energy bus | |
| CN110262820A (en) | Method, apparatus, system and storage medium based on MQTT protocol realization OTA upgrading | |
| CN113905039A (en) | System upgrade file transmission method, device and system | |
| CN111949293A (en) | Firmware upgrading method and device, computer equipment and storage medium | |
| CN114756270B (en) | Automatic driving system firmware upgrading method and automatic driving system | |
| CN113805916A (en) | Upgrading method, system, readable storage medium and vehicle | |
| US20210107325A1 (en) | Method and device for upgrading tpms diagnostic tool | |
| WO2021024792A1 (en) | Vehicle control device, update program, program update system, and writing device | |
| WO2023241458A1 (en) | Software upgrade method and apparatus for vehicle-mounted controller, and device and storage medium | |
| CN115134684A (en) | Remote upgrading method, system and device for water meter centralized reading equipment | |
| US20220245085A1 (en) | Method of dialogue with a computer on an on-board bus of a vehicle | |
| CN115982710A (en) | OTA (over the air) security upgrading method based on Ethernet | |
| CN115102855A (en) | Intelligent water meter embedded software online upgrading method and system | |
| CN114144759A (en) | Method and device for updating software of a vehicle computer comprising an execution memory, a backup memory and a check memory | |
| KR101436135B1 (en) | software update apparatus for slave device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |