Method and apparatus for upgrading a vehicle-mounted unit

Abstract

The present disclosure relates to a method and device for upgrading vehicle-mounted units. Specifically, the software upgrading method of a first vehicle-mounted unit comprises: downloading a software upgrading version from a second vehicle-mounted unit having the software upgrading version and storing the software upgrading version to an inactive storage partition; sending a software upgrading request to a roadside unit; and in response to the upgrading request, exchanging the software upgrading version stored in the inactive storage partition with a pre-upgrading version stored in an active storage partition to perform the upgrading. The upgrading method of the vehicle-mounted unit of the present disclosure can upgrade un-upgraded vehicle-mounted units using upgraded vehicle-mounted units, so that the number of upgraded vehicle-mounted units increases exponentially, thereby greatly improving the program upgrading efficiency of the vehicle-mounted units and saving labor and time costs. In addition, the upgrading is authenticated by the roadside unit, improving the upgrading security.

Description

Technical Field

[0001] This disclosure generally relates to the field of vehicle-mounted unit technology. Specifically, this disclosure relates to a method for upgrading a vehicle-mounted unit and a vehicle-mounted unit, as well as a method and a roadside unit performed at a roadside unit. Background Technology

[0002] This section is intended to provide background or context for embodiments of the invention set forth in the claims. The description herein may include concepts that may be explored, but not necessarily concepts that have been previously conceived or explored. Therefore, unless otherwise stated, what is described in this section is not prior art for the purposes of this application's specification and claims, and is not acknowledged as prior art simply by virtue of its inclusion in this section.

[0003] Electronic Toll Collection (ETC) is a widely used electronic automatic toll collection system for highways, bridges, tunnels, and parking lots internationally. The Onboard Unit (OBU) is an essential component of this system. The OBU transmits data to the Roadside Unit (RSU) via Dedicated Short Range Communication (DSRC) and uses computer networking technology to conduct back-end settlement with banks, enabling vehicles to complete toll payments without stopping, significantly improving traffic efficiency.

[0004] When a vehicle-mounted unit exhibits design flaws or requires program optimization upgrades, its software version needs to be upgraded to reduce product failure risks, minimize corporate losses, and improve customer satisfaction. Current software upgrade methods in my country require the use of dedicated equipment to re-download and upgrade the vehicle-mounted unit's software, which is inefficient.

[0005] In addition, current ETC operators lack control over the operating versions of on-board unit software, thus failing to detect problems in a timely manner and improve product functionality. Summary of the Invention

[0006] In order to at least solve one or more of the above-mentioned technical problems, this disclosure provides a method for upgrading an on-board unit and an on-board unit, as well as a method and a roadside unit performed at a roadside unit.

[0007] In a first aspect, this disclosure provides a software upgrade method for a first vehicle-mounted unit, the method comprising: the first vehicle-mounted unit downloading the software upgrade version from a second vehicle-mounted unit having a software upgrade version and storing it in an inactive storage partition; sending a software upgrade request to a roadside unit; and, in response to the upgrade request being approved, exchanging the software upgrade version stored in the inactive storage partition with the previous software upgrade version stored in the active storage partition to perform an upgrade.

[0008] In one embodiment, the first vehicle unit downloading the software upgrade version from the second vehicle unit includes: the first vehicle unit establishing a communication connection with the second vehicle unit via a master-slave mode of a Bluetooth module; the vehicle unit in master mode comparing the software versions of the first vehicle unit and the second vehicle unit; the first vehicle unit, which determines the software version is lower, requesting download permission security authentication with the second vehicle unit, which determines the software version is higher; and in response to successful authentication, the first vehicle unit requesting to obtain the higher software version as the software upgrade version.

[0009] In another embodiment, the method further includes: in response to obtaining a complete data packet of the software upgrade version, the first vehicle unit flips the operating mode in the current host-slave mode; in response to the incomplete data packet of the obtained software upgrade version, the first vehicle unit re-requests the software upgrade version from the second vehicle unit.

[0010] In yet another embodiment, the first onboard unit further includes performing a DSRC transaction with the roadside unit before sending a software upgrade request to the roadside unit.

[0011] In another embodiment, the software upgrade request includes one or more of the following information for authentication with the roadside unit: a device serial number for identity authentication; and a software upgrade version number and authentication code for upgrade authorization authentication.

[0012] In another embodiment, the method further includes: when the DSRC transaction between the first vehicle-mounted unit and the roadside unit fails, sending the device serial number and the currently running software version number to the roadside unit.

[0013] In another embodiment, after the first vehicle unit downloads the software upgrade version and performs the upgrade, it still runs the pre-upgrade version of the software stored in the active storage partition.

[0014] In another embodiment, the method further includes: the first vehicle unit setting a first flag to indicate that the first vehicle unit is currently running the version before the software upgrade, but has already stored the software upgrade version; the first vehicle unit setting a second flag to indicate that the first vehicle unit is currently running the version before the software upgrade, and the acquired software upgrade version is running abnormally.

[0015] In a second aspect, this disclosure provides a first vehicle-mounted unit, comprising: a storage circuit storing a computer program, the storage circuit including an inactive storage partition and an active storage partition; a communication circuit for wirelessly communicating with an external device; and a processing circuit for executing the computer program to implement the steps of the method of any embodiment of the first aspect of this disclosure.

[0016] In a third aspect, this disclosure provides a method for upgrading the software program of an on-board unit at a roadside unit, the method comprising: receiving a software upgrade request sent by the on-board unit; performing one or more authentications on the on-board unit according to the software upgrade request; and, in response to the authentication being passed, sending an indication to the on-board unit that the upgrade request has been approved.

[0017] In one embodiment, performing one or more authentications on the vehicle unit according to the software upgrade request includes: identity authentication based on the device serial number in the software upgrade request; and / or upgrade permission authentication based on the software upgrade version number and authentication code in the software upgrade request.

[0018] In another embodiment, the method further includes: when a DSRC transaction with the vehicle unit fails, receiving the device serial number and currently running software version number of the vehicle unit from the vehicle unit, and recording the failure.

[0019] In a fourth aspect, this disclosure provides a roadside unit comprising: a storage circuit for storing computer programs and data; a communication circuit for wirelessly communicating with external devices; and a processing circuit for executing the computer program to implement the steps of the method of any embodiment of the third aspect of this disclosure.

[0020] The disclosed method for upgrading vehicle-mounted units can be divided into two stages: downloading and upgrading. In the downloading stage, autonomous upgrades between vehicle-mounted products are achieved. Each upgraded vehicle-mounted unit upgrades the un-upgraded units, resulting in an exponential increase in the number of vehicle-mounted units that can be upgraded. This significantly improves the efficiency of vehicle-mounted unit program upgrades and saves labor and time costs. In the upgrading stage, roadside units are used for upgrade authorization authentication, which reduces the risk of tampering with the vehicle-mounted unit's operating program. Attached Figure Description

[0021] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments with reference to the accompanying drawings. In the drawings, several embodiments of this disclosure are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0022] Figure 1 A schematic diagram of a scenario in which embodiments of this disclosure may be implemented is shown;

[0023] Figure 2 An exemplary flowchart of an upgrade method for an on-board unit according to an embodiment of the present disclosure is shown;

[0024] Figure 3 An exemplary flowchart of a method performed at a roadside unit according to some embodiments of the present disclosure is shown;

[0025] Figure 4 An exemplary interactive flowchart illustrating the software download and upgrade process of an on-board unit according to an embodiment of this disclosure is shown; and

[0026] Figure 5 An exemplary functional block diagram of a vehicle-mounted unit or roadside unit according to an embodiment of the present disclosure is shown. Detailed Implementation

[0027] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0028] Figure 1 A schematic diagram of a scenario in which embodiments of the present disclosure may be implemented is shown.

[0029] As shown in the figure, a roadside unit 2 is arranged on one side of ETC lane 1 along the direction of vehicle travel. Roadside unit 2 is usually installed next to highway or bridge toll stations. On the other side of ETC lane 1, a camera device 3 and a guardrail 4 are arranged. The on-board unit 5, also known as a transponder or electronic tag, stores the vehicle's identification information and is usually installed on the vehicle's windshield.

[0030] The vehicle-mounted unit disclosed herein can be an on-board device installed on a user's vehicle to record vehicle traffic information. The on-board unit and the roadside device communicate in half-duplex mode using Dedicated Short-Range Communication (DSRC) in the 5.8 GHz microwave band, with a communication distance typically of tens of meters.

[0031] When a vehicle travels through the tollbooth along ETC lane 1, it is first detected by a loop sensor (not shown in the diagram) located beneath ETC lane 1. Next, the roadside unit 2 sends an inquiry signal, which is responded to by the onboard unit 5. Specifically, the roadside unit 2 and the onboard unit 5 communicate and exchange data bidirectionally. The central management system 6 then retrieves the vehicle information from the onboard unit 5, including the vehicle ID number and model, and compares it with the corresponding information in the database of the central management system 6. Based on different situations, the management system takes different actions, such as deducting the toll from the vehicle's prepayment account or sending instructions to other auxiliary facilities. For example, the camera device 3 may photograph the violating vehicle, the barrier 4 may be automatically controlled, or the vehicle may be directed to proceed via display devices (red, yellow, green lights, etc.).

[0032] The diagram also shows other vehicles, which are also equipped with the onboard unit 5. The onboard units of different vehicles can communicate with each other, for example, through DSRC or Bluetooth modules.

[0033] The vehicle-mounted unit mainly includes: a microcontroller unit (MCU), a power management module, a radio frequency (RF) module, a wake-up module, an embedded secure access module (ESAM module), and a smart IC card module. The MCU is responsible for scheduling the resources of each module within the vehicle-mounted unit and controlling its workflow; it acts as the central processing unit. The power management module employs low-power circuit design technology to ensure reliable and stable long-term operation. The RF module uses DSRC (Dedicated Short-Range Communication) technology as the interface for communication between the vehicle-mounted unit and roadside devices. The wake-up module detects wake-up sources (card insertion wake-up, transaction wake-up, anti-tamper wake-up) and initiates relevant program execution functions. The ESAM module is primarily used for key loading, storing vehicle personalization and system information, and security authentication. The smart IC card module is mainly used for two-way authentication of transactions with roadside devices, transaction record storage, deduction, and owner information storage. The warning module includes indicator lights and / or buzzers to provide visual and audible warnings.

[0034] Of course, the vehicle-mounted unit disclosed herein is not limited to this; it can be any electronic device installed in a vehicle.

[0035] When a vehicle-mounted unit exhibits a design flaw or requires program optimization and upgrades, the software version of the unit needs to be upgraded to reduce product failure risks, minimize company losses, and improve customer satisfaction. Known upgrade methods require re-downloading the new program to the entire batch of vehicle-mounted units that have already had their software downloaded, using specialized equipment. This results in low upgrade efficiency and a poor customer experience.

[0036] This disclosure provides a software upgrade method for an on-board unit (OB). This software upgrade method can be divided into two stages: a software download stage and a software upgrade stage. In the software download stage, the autonomous upgrade scheme between OBs provided in this disclosure allows vehicles equipped with OBs to download the OB software version via inter-vehicle communication, improving the program download efficiency of customer OBs and significantly reducing after-sales service costs. In the software upgrade stage, through upgrade permission authentication with the roadside unit, the risk of tampering with the OB's operating program can be reduced.

[0037] Figure 2 An exemplary flowchart of an upgrade method for an on-board unit according to an embodiment of the present disclosure is shown. Figure 2 The process steps are presented from the perspective of the first on-board unit that needs to be upgraded. As shown in the figure, the upgrade method includes the following steps S201-S203.

[0038] In step S201, the first vehicle unit to be upgraded downloads the software upgrade version from the second vehicle unit with the software upgrade version and stores it in the inactive storage partition.

[0039] In some embodiments, the software upgrade version download authentication and download process is performed via Bluetooth communication between the first vehicle unit and the second vehicle unit. Bluetooth communication supports master-slave modes. A device operating in master mode (hereinafter referred to as the master device) can search for surrounding devices and select a device operating in slave mode (hereinafter referred to as the slave device) to connect to. Slave devices can only be searched by the master device and cannot actively search for them. Slave devices can initiate Bluetooth broadcast signals to request Bluetooth connection. After the slave device connects to the master device, it can send and receive data with the master device. Devices with Bluetooth communication capabilities can switch between the two roles. Normally, they operate in slave mode, waiting for other master devices to connect. When needed, they switch to master mode to initiate calls to other devices. When a Bluetooth device initiates a call in master mode, it needs to know the other party's Bluetooth address, pairing password, and other information. After pairing is completed, it can directly initiate a call.

[0040] Specifically, in some implementations, the first vehicle unit establishes a communication connection with the second vehicle unit via a master-slave mode of the Bluetooth module. In this communication connection, the first vehicle unit may be in master mode or slave mode; correspondingly, the second vehicle unit may be in slave mode or master mode. Preferably, the first vehicle unit is in slave mode and the second vehicle unit is in master mode.

[0041] After establishing a communication connection, the on-board unit in master mode can compare the software versions of the first and second on-board units. Specifically, the master device requests the software version information of the slave device and compares it with its own version information. If the software versions of the two on-board units are the same, no version transfer is needed, and the connection can be directly disconnected. If the software versions of the two on-board units are different, the higher software version can be transferred to the on-board unit with the lower software version.

[0042] In this example, a first vehicle unit, determined to have a lower software version, requests download permission security authentication from a second vehicle unit, determined to have a higher software version. Then, in response to successful authentication, the first vehicle unit requests the higher software version as its software upgrade. Accordingly, the second vehicle unit, determined to have a higher software version, receives the authentication request from the first vehicle unit and, upon successful authentication, sends its higher software version to the first vehicle unit. The authentication method can be any currently known or future-developed permission security authentication method, and this embodiment of the disclosure is not limited in this respect. If authentication fails, the connection is directly disconnected.

[0043] Thus, the first vehicle-mounted unit completes the software upgrade download process through communication with the second vehicle-mounted unit. It is understood that the upgraded software version on the second vehicle-mounted unit can be downloaded via dedicated equipment or, similarly, derived from other vehicle-mounted units with upgraded software versions; this disclosure does not limit this aspect.

[0044] After the software upgrade version is downloaded, for the sake of safety, the first vehicle unit does not immediately activate the upgrade version, but stores the upgrade version in the inactive storage partition of the local storage circuit. At this time, the old version software program is still running in the active partition.

[0045] In some embodiments, the first vehicle unit may be set with a first flag to indicate that the first vehicle unit is currently running on the version before the software upgrade, but has already stored the software upgrade version.

[0046] Next, the first vehicle-mounted unit can authenticate with the roadside unit for upgrade permissions. Only after successful authentication can the upgrade be performed, thereby reducing the risk of the vehicle-mounted unit's operating program being tampered with.

[0047] Specifically, in Figure 2In step S202, the first vehicle-mounted unit sends a software upgrade request to the roadside unit.

[0048] In some embodiments, the first on-board unit may send the aforementioned software upgrade request after completing a DSRC transaction with the roadside unit. The software upgrade request may include various information for authentication with the roadside unit.

[0049] In one implementation, a software upgrade request may include the device serial number (device SN) for authentication with the roadside unit. Authentication determines whether the on-board unit falls under the jurisdiction of a designated operator. Additionally, the software upgrade request may also include a software upgrade version number and an authentication code for upgrade authorization authentication with the roadside unit. Performing both authentication and upgrade authorization authentication ensures the accuracy of version information and reduces the risk of errors.

[0050] Finally, in step S203, the first vehicle unit responds to the above-mentioned software upgrade request by exchanging the software upgrade version stored in the inactive storage partition with the software version before the upgrade stored in the active storage partition to perform the upgrade.

[0051] The first vehicle unit is equipped with dual internal memory, which allows for partitioned storage of high and low version software. When the low version software program is running in the active partition, the high version software program can be downloaded and stored in the inactive partition without interfering with the normal operation of the existing program.

[0052] If the upgrade permission authentication of the first vehicle-mounted unit and the roadside unit is successful, the first vehicle-mounted unit can quickly activate the higher version of the software and complete the upgrade by exchanging execution partitions.

[0053] If the first vehicle-mounted unit fails to authenticate the upgrade permission with the roadside unit or fails to exchange execution partitions, the first vehicle-mounted unit can continue to execute the lower version of the software program to prevent the vehicle-mounted unit from having no control program.

[0054] If the upgraded version encounters problems, you can switch back to the old software version by setting a corresponding flag to achieve version rollback. By retaining the previous version after a successful software upgrade, you can revert to the old version if the new version encounters issues, thus achieving a smooth transition between software versions.

[0055] Optionally or additionally, in some embodiments, the first vehicle unit may also be configured with a second flag to indicate that the first vehicle unit is currently running on the version prior to the software upgrade, and that the acquired software upgrade version is malfunctioning.

[0056] Therefore, by combining software download and upgrade processes, the efficiency and security of on-board unit (OBU) program upgrades can be significantly improved, saving labor and time costs. Furthermore, dual authentication during both the download and upgrade processes reduces the risk of tampering with the OPU's operating program. The self-service download process between OPUs is convenient and fast, enhancing customer experience. Introducing roadside units (Roadside Units) to participate in software upgrade authentication allows the upgrade process to also reflect the ETC system operator's control over the software versions of its products, improving after-sales service efficiency.

[0057] Optionally or additionally, in some embodiments, in response to receiving a complete data packet of the software upgrade version from the second vehicle unit, the first vehicle unit can flip its current operating mode in the master-slave mode. For example, if the first vehicle unit is currently in master mode, it flips to slave mode; and if the first vehicle unit is currently in slave mode, it flips to master mode. Correspondingly, in some embodiments, the second vehicle unit, determined to have a higher software version, maintains its current operating mode after data transmission is completed; that is, if it is in master mode, it remains in master mode, and if it is in slave mode, it remains in slave mode. This mode flipping of the first vehicle unit ensures that the data of vehicle units in the master-slave mode on the market is comparable, preventing all vehicle unit devices on the market from being either master or slave, thus not affecting subsequent Bluetooth pairing connections between vehicles.

[0058] Optionally or additionally, in some embodiments, in response to an incomplete data packet of the software upgrade version obtained from the second vehicle unit, a new request for the software upgrade version is made to the second vehicle unit.

[0059] In some embodiments, when a software upgrade version contains multiple data packets, a checksum can be used during the acquisition of each data packet. In one example, a first data packet from the software upgrade program, including a first checksum, can be acquired first. Then, a checksum is calculated based on the upgrade data in the received first data packet to obtain a second checksum. When the first checksum matches the second checksum, subsequent data packets can be acquired. This ensures the accuracy of each data packet and allows for the identification of the specific data packet in case of a transmission error, without requiring the transmission of all data packets.

[0060] This disclosure also provides a method for upgrading the software program of an on-board unit, performed at a roadside unit.

[0061] Figure 3 An exemplary flowchart of a method performed at a roadside unit according to some embodiments of the present disclosure is shown.

[0062] As shown in the figure, in step S301, the roadside unit receives a software upgrade request sent by the vehicle-mounted unit. The vehicle-mounted unit may be, for example, a unit that has downloaded the software upgrade version through inter-vehicle-mounted unit communication, but has not yet activated the upgraded version.

[0063] In some embodiments, the on-board unit can send the aforementioned software upgrade request after the DSRC transaction with the roadside unit is completed. Since a communication link has already been established between the on-board unit and the roadside unit during the DSRC transaction, performing the software upgrade communication before releasing the link after the transaction is completed is more convenient and efficient. Otherwise, the roadside unit would need to re-wake up the on-board unit and establish a link before subsequent software upgrade communication can proceed. As mentioned earlier, the software upgrade request may carry the device serial number, software upgrade version number, and authentication code.

[0064] Next, in step S302, the roadside unit performs one or more authentications on the on-board unit based on the received software upgrade request. Authentication may include identity authentication and upgrade permission authentication.

[0065] The roadside unit first authenticates with the on-board unit. In one example, the roadside unit can authenticate the on-board unit using the device serial number (SN) carried in the software upgrade request, based on the operator's pre-defined device serial number (SN) coding rules. If authentication fails, the roadside unit issues a failure response and does not proceed with the upgrade. If authentication succeeds, the roadside unit issues a success response and can continue with subsequent upgrade authorization authentication.

[0066] During upgrade authorization authentication, the roadside unit and the vehicle-mounted unit share the same upgrade key. In one example, if the authentication in the previous step is successful, the vehicle-mounted unit requests the roadside unit to send an 8-byte random number. Then, using the upgrade key, the software upgrade version number, and the received 8-byte random number, it calculates an 8-byte authentication code using a specific algorithm (including but not limited to 3DES or SM4 algorithms).

[0067] The vehicle unit sends the software upgrade version number and authentication code to the roadside unit. The roadside unit can calculate the authentication code using the same algorithm based on the sent random number, the received software version number, and the upgrade key, and compare it with the received authentication code to authenticate the upgrade authorization.

[0068] If the authentication codes match, the upgrade authorization authentication is successful. In step S303, in response to successful authentication, the roadside unit sends an instruction to the vehicle-mounted unit to approve the software upgrade request. Otherwise, a failure response is returned.

[0069] Therefore, by incorporating roadside units into the on-board unit software upgrade process and adding features such as roadside unit upgrade permission authentication and software upgrade version information storage, ETC operators can easily manage the software versions of their released products.

[0070] In some embodiments, when a DSRC transaction between the on-board unit and the roadside unit fails, the on-board unit can proactively send its device serial number and currently running software version number to the roadside unit. Correspondingly, the roadside unit receives the on-board unit's device serial number and currently running software version number from the on-board unit and stores the acquired identity information, fault information, and software version information over a network. This stored information can facilitate the statistical analysis of failure rates and user equipment information for each software version.

[0071] By adding software version control functionality to roadside units, ETC operators can better manage supplier software version upgrades and conduct online statistical analysis of historical software versions and transaction failures of on-board units caused by software issues. This information can also be periodically fed back to suppliers, enabling timely identification of product problems and improvement of product functionality. In some examples, upgrade reminder services for designated customers can also be added to improve after-sales service efficiency.

[0072] To fully understand the embodiments of this disclosure, Figure 4 An exemplary interactive flowchart of the software download and upgrade process for an on-board unit according to an embodiment of the present disclosure is shown.

[0073] As shown in the figure, the first vehicle unit 410, which requires software upgrade, establishes a Bluetooth communication connection (401) with the second vehicle unit 420, which has a higher software version, to download the higher software version.

[0074] After the connection is established, the first vehicle unit requests download permission security authentication from the second vehicle unit (402). The second vehicle unit performs the authentication and returns a success or failure signal based on the authentication result (403).

[0075] Upon successful authentication, the first vehicle unit can then request a higher software version from the second vehicle unit (404). The second vehicle unit then transmits the higher software version to the first vehicle unit based on this request (405).

[0076] Thus, the first vehicle unit can complete the download of the high software version, which can be stored in the inactive storage partition and its Bluetooth operating mode can be flipped (406).

[0077] Next, the first onboard unit can complete the software upgrade process through interaction with the roadside unit 430.

[0078] Specifically, the first on-board unit sends a signal requesting authentication to the roadside unit, the signal carrying the device serial number (407). The roadside unit can then use the device serial number to perform authentication and return a success or failure response signal (408) based on the authentication result.

[0079] When identity authentication is successful, permission authentication can be upgraded. The first vehicle-mounted unit sends a signal requesting a random number to the roadside unit (409). Based on the request, the roadside unit generates an 8-byte random number and returns it to the first vehicle-mounted unit (410).

[0080] The first onboard unit can then generate an 8-byte authentication code using a specific algorithm based on the random number, the upgrade software version number, and the upgrade key known to both the onboard unit and the roadside unit. The first onboard unit then sends a signal requesting upgrade authorization authentication to the roadside unit, carrying the upgrade software version number and the generated 8-byte authentication code (411). The roadside unit also generates an 8-byte authentication code using the same algorithm based on the upgrade software version number in the request, the previously sent random number, and the known upgrade key. The generated authentication code is compared with the authentication code received from the onboard unit to confirm whether the upgrade authorization authentication was successful and to provide a response (412).

[0081] Finally, the first onboard unit executes the corresponding action based on the authentication response from the roadside unit. If authentication is successful, the execution partitions of the high and low software versions are swapped, and the high software version is activated, thus completing the upgrade. If authentication fails, the low software version continues to run.

[0082] Optionally or additionally, in some embodiments, the on-board unit (OBU) can send relevant information to the roadside unit based on the upgrade result. For example, if the higher software version is successfully activated, the OBU can send an upgrade success notification signal to the roadside unit, at which point the roadside unit can store the previously acquired higher software version number (i.e., the one sent to the roadside unit during the upgrade authentication process). If activation fails, the OBU will revert to a lower software version number and send the reverted lower software version number and the upgrade failure signal to the roadside unit for storage. In the case of activation failure, the roadside unit does not store the previously acquired higher software version number. This terminates the communication between the OBU and the roadside unit.

[0083] Figure 5 An exemplary functional block diagram of a device 500 according to an embodiment of the present disclosure is shown. The device 500 can be either a vehicle-mounted unit or a roadside unit. Depending on its role, each functional module may have a corresponding different function.

[0084] As shown in the figure, the device 500 includes a storage circuit 510, a communication circuit 520, and a processing circuit 530.

[0085] The storage circuit 510 can be hardware used for processing various computer programs and data in the storage device 500. The storage circuit can include at least one of volatile memory or non-volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, phase-change RAM (PRAM), magnetic RAM (MRAM), resistive RAM (RRAM), ferroelectric RAM (FRAM), etc. Volatile memory can include dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), PRAM, MRAM, RRAM, ferroelectric RAM (FeRAM), etc.

[0086] In some embodiments, when the device 500 is an in-vehicle unit, the storage circuit 510 may be configured with active and inactive storage partitions to store the software versions before and after the upgrade.

[0087] The communication circuit 520 may include various communication components. For example, when the device 500 is a vehicle-mounted unit, the communication circuit may include Bluetooth communication components and DSRC communication components to establish communication with external devices through different types of connections, respectively. When the device 500 is a roadside unit, the communication circuit may include DSRC communication components and wired communication components to establish communication with external devices.

[0088] The processing circuit 530 provides computing and control capabilities. For example, when the device 500 is an on-board unit, the processing circuit 530 controls all functions of the on-board unit by executing a computer program stored in the circuitry, such as implementing the functions described in the preceding reference. Figure 2 The described method and steps. For example, when device 500 is a roadside unit, processing circuit 530 controls all functions of the roadside unit by executing a computer program stored in the circuitry, such as implementing the functions described in the preceding reference. Figure 3 The described methods and steps.

[0089] The processing circuit may include, but is not limited to, a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., and the number of such devices can be determined according to actual needs.

[0090] In some embodiments, when the device 500 is a vehicle-mounted unit, the vehicle-mounted unit can acquire a switching signal to perform mode switching. For example, regarding the aforementioned mode flipping of the vehicle-mounted unit after the upgrade is completed, a switching signal can be automatically generated to flip the mode after the vehicle-mounted unit upgrade is completed. Furthermore, the switching signals for switching the vehicle-mounted unit to master / slave mode and normal operating mode can also be signals sent by any other device or equipment capable of wired or wireless communication with the vehicle-mounted unit.

[0091] It is understandable that the above references Figure 5 The specific manner in which the various modules of the described apparatus 500 perform their operations has been described in detail in the embodiments relating to the upgrade method for the vehicle-mounted unit, and will not be elaborated upon here.

[0092] As can be seen from the foregoing description, the embodiments of this disclosure can be implemented as a system, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, the invention can also be implemented as a computer program product contained in one or more computer-readable media, which contains computer-readable program code. Any combination of one or more computer-readable media can be used. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0093] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] It should be understood that each block of the method flowcharts and / or block diagrams of the embodiments of this disclosure, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine that executes on the computer or other programmable data processing apparatus to create means for implementing the functions / operations specified in the blocks of the flowcharts and / or block diagrams. These computer program instructions can also be stored in a computer-readable medium that causes a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce a product including instruction means for implementing the functions / operations specified in the blocks of the flowcharts and / or block diagrams. The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, can provide a process for implementing the functions / operations specified in the blocks of the flowcharts and / or block diagrams.

[0095] It should be noted that although the operations of the methods of this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0096] It should be understood that the terms "first," "second," "third," and "fourth," etc., that may be used in the claims, specification, and drawings of this disclosure are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" as used in the specification and claims of this disclosure indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0097] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0098] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0099] While numerous embodiments of this disclosure have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and intent of this disclosure. It should be understood that various alternatives to the embodiments of this disclosure described herein may be employed in the practice of this disclosure. The appended claims are intended to define the scope of this disclosure and therefore cover equivalents or alternatives within the scope of these claims.

Claims

1. A software upgrade method for a first vehicle-mounted unit, characterized in that, The method includes: The first vehicle unit downloads the software upgrade version from the second vehicle unit that has the software upgrade version and stores it in an inactive storage partition; A software upgrade request is sent to the roadside unit, the upgrade request including the device serial number for authentication and the software upgrade version and authentication code for upgrade authorization authentication; and In response to the upgrade request being approved, the software upgrade version stored in the inactive storage partition is swapped with the previous software upgrade version stored in the active storage partition to perform the upgrade. The step of sending a software upgrade request to the roadside unit includes: The first vehicle-mounted unit sends a signal requesting identity authentication to the roadside unit, the signal carrying the device serial number; Receive the authentication success or failure response signal returned by the roadside unit; When the roadside unit returns a successful authentication response signal, the first vehicle-mounted unit sends a signal requesting a random number to the roadside unit; Receive the random number returned by the roadside unit; The first vehicle-mounted unit generates an authentication code based on the random number, the upgrade software version number, and the upgrade key known to both the first vehicle-mounted unit and the roadside unit; The first vehicle-mounted unit sends a signal requesting upgrade authorization authentication to the roadside unit, the signal carrying the upgrade software version number and the generated authentication code; The first vehicle-mounted unit receives a success or failure response from the roadside unit regarding the upgrade permission authentication.

2. The method according to claim 1, characterized in that, The first vehicle unit downloads the software upgrade version from the second vehicle unit, including: The first vehicle unit establishes a communication connection with the second vehicle unit via the master-slave mode of the Bluetooth module; The on-board unit in host mode compares the software versions of the first on-board unit and the second on-board unit; The first vehicle unit, identified as having a lower software version, requests download permission security authentication with the second vehicle unit, identified as having a higher software version; and In response to successful authentication, the first vehicle unit requests the high software version as the software upgrade version.

3. The method according to claim 2, characterized in that, Also includes: In response to obtaining the complete data packet of the software upgrade version, the first vehicle unit flips the operating mode in the current master-slave mode; In response to the incomplete data packet of the obtained software upgrade version, a new request for the software upgrade version is made to the second vehicle unit.

4. The method according to any one of claims 1-3, characterized in that, Before sending a software upgrade request to the roadside unit, the first vehicle-mounted unit also includes: Perform DSRC transactions with the roadside unit.

5. The method according to any one of claims 1-3, characterized in that, Also includes: When the DSRC transaction between the first vehicle-mounted unit and the roadside unit fails, the device serial number and the currently running software version number are sent to the roadside unit.

6. The method according to any one of claims 1-3, characterized in that, After the first vehicle unit downloads the software upgrade version and executes the upgrade, it still runs the software version before the upgrade stored in the active storage partition.

7. The method according to claim 6, characterized in that, Also includes: The first vehicle unit is equipped with a first flag to indicate that the first vehicle unit is currently running the version before the software upgrade, but the software upgrade version has been stored. The first vehicle unit is equipped with a second flag to indicate that the first vehicle unit is currently running the version before the software upgrade, and that the obtained software upgrade version is malfunctioning.

8. A first vehicle-mounted unit, characterized in that, include: A storage circuit storing a computer program, the storage circuit including an inactive storage partition and an active storage partition; Communication circuits are used for wireless communication with external devices. as well as A processing circuit for executing the computer program to implement the steps of the method according to any one of claims 1-7.

9. A method executed at a roadside unit for upgrading the software program of an on-board unit, characterized in that, The method includes: The system receives a software upgrade request sent by an onboard unit. The software upgrade request includes a device serial number for identity authentication, a software upgrade version for upgrade authorization authentication, and an authentication code. The software upgrade version is downloaded by the onboard unit from another onboard unit that has the software upgrade version and stored in an inactive storage partition. Perform one or more authentications on the vehicle unit according to the software upgrade request; and In response to the successful authentication, an instruction to pass the upgrade request is sent to the vehicle unit, so that the vehicle unit, in response to the successful upgrade request, swaps the software upgrade version stored in the inactive storage partition with the software upgrade version stored in the active storage partition to perform the upgrade. The process of receiving a software upgrade request from the vehicle unit and performing one or more authentications on the vehicle unit based on the software upgrade request includes: Receive a signal from the vehicle unit requesting authentication, which carries the device serial number; The device serial number carried in the signal requesting authentication is used to authenticate the vehicle unit. Return a success or failure authentication response signal to the vehicle unit; The system receives a signal requesting a random number from the vehicle-mounted unit, which is sent when the vehicle-mounted unit receives a successful authentication response signal. When the vehicle unit's identity authentication is successful, a random number is sent to the vehicle unit; The system receives a signal from the vehicle-mounted unit requesting upgrade authorization authentication, which carries an upgrade software version number and an authentication code. The authentication code is generated by the vehicle-mounted unit based on the random number, the upgrade software version number, and an upgrade key known to both the vehicle-mounted unit and the roadside unit. Based on the upgrade software version number sent by the vehicle unit, the upgrade key known to both the vehicle unit and the roadside unit, and the previously sent random number, an authentication code is calculated. The authentication code calculated by the roadside unit is then compared with the authentication code received from the vehicle unit to perform upgrade authorization authentication. Return a success or failure response to the upgrade permission authentication to the vehicle unit.

10. The method according to claim 9, characterized in that, Also includes: When a DSRC transaction with the vehicle unit fails, the device serial number and the currently running software version number of the vehicle unit are received from the vehicle unit, and the failure is recorded.

11. A roadside unit, characterized in that, include: Storage circuits are used to store computer programs and data; Communication circuits are used for wireless communication with external devices. as well as A processing circuit for executing the computer program to implement the steps of the method according to any one of claims 9-10.

Images