Management method and device after change of vehicle-mounted terminal network equipment

Abstract

The invention relates to the technical field of vehicles, and provides a vehicle-mounted terminal network equipment post-replacement management method and device, and the method comprises the steps: carrying out the network access verification of old piece equipment based on a preset first white list and a logic network address carried in a request under the condition that a network connection request of the old piece equipment is received, the first white list stores logic network addresses of offline old pieces; and under the condition that the network verification result indicates that the old piece equipment is allowed to access the in-vehicle domain network, vehicle binding relationship verification is performed on the old piece equipment based on a preset second white list, the equipment identification code of the old piece equipment and the change condition of the vehicle identification code bound with the old piece equipment, and the equipment identification code of the offline old piece is stored in the second white list. According to the method and the device provided by the invention, a traditional mode which completely depends on manual recording, judgment and operation is replaced, so that human errors are reduced, and accurate and automatic management of the life cycle state of the equipment is realized.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to a method and apparatus for managing in-vehicle terminal network equipment after component replacement. Background Technology

[0002] As a core electronic component enabling remote vehicle communication, status monitoring, and fault diagnosis, the correct binding and stable operation of in-vehicle terminal network equipment directly affects the safety and reliability of the entire vehicle's functions. Therefore, the industry has generally established a unique binding standard of "one device, one vehicle," meaning that a single in-vehicle terminal network device can only be bound to a unique Vehicle Identifier (VIN). This standard aims to ensure the traceability of software upgrades, fault records, and parts sourcing throughout the entire lifecycle of the equipment.

[0003] However, the management of the aforementioned binding relationships by related technologies relies heavily on offline manual operation processes and lacks a systematic automated verification and enforcement mechanism, mainly exhibiting the following two major technical shortcomings: First, there is a risk of tampering with the binding relationship due to the misinstallation of old parts, which seriously undermines the accuracy of the traceability system. In vehicle repair scenarios, old parts replaced from vehicle A may be mistakenly installed in vehicle B. Operators can rewrite the VIN code of the old part into vehicle B, thereby illegally tampering with its binding relationship. This confusion in binding relationships renders after-sales traceability data invalid, making it impossible to accurately locate the source of problematic parts and the compatible vehicles.

[0004] Secondly, there is a risk that new parts may be mistakenly removed from the production line due to the failure to clear the VIN code of old parts, which could seriously affect the normal functioning of the vehicle. If the VIN code of an old on-board terminal network device (such as part A) is not forcibly cleared after replacement, it may report the old binding relationship (part A - VIN code A) to the cloud if it is accidentally connected to the network during subsequent bench testing or other scenarios. The cloud does not distinguish between the "in use / out of service" status of parts and may mistakenly identify the old part as an in use part, thereby forcibly removing the new on-board terminal network device (part B) already installed in vehicle A from the production line, resulting in the interruption of the vehicle's remote communication and status monitoring functions. Summary of the Invention

[0005] This invention provides a method and apparatus for managing vehicle-mounted terminal network devices after component replacement, in order to solve the reliability and security problems caused by the reliance on manual operation in the management of the binding relationship of vehicle-mounted terminal network devices in the prior art. This invention provides a method for managing vehicle-mounted terminal network equipment after component replacement, comprising: Upon receiving a network connection request from an old device, the network access of the old device is verified based on a preset first whitelist and the logical network address carried in the request, and a network verification result is obtained. The first whitelist stores the logical network addresses of the offline old devices. If the network verification result indicates that the old device is allowed to access the vehicle domain network, the vehicle binding relationship of the old device is verified based on the preset second whitelist, the device identifier code of the old device, and the changes in the vehicle identifier code bound to the old device. The second whitelist stores the device identifier code of the offline old device.

[0006] According to the vehicle terminal network equipment replacement management method provided by the present invention, the step of verifying the vehicle binding relationship of the old equipment based on a preset second whitelist, the device identification code of the old equipment, and changes in the vehicle identification code bound to the old equipment includes: Determine whether the device identification code of the old device is in the second whitelist; If it is not in the second whitelist, then the old device is allowed to establish a new binding relationship with the current vehicle; If it is in the second whitelist, then obtain and compare whether the original vehicle identification code bound to the old device has changed with the newly written vehicle identification code, and verify the vehicle binding relationship based on the comparison result.

[0007] According to the vehicle terminal network equipment replacement management method provided by the present invention, the step of verifying the vehicle binding relationship based on the comparison result includes: If the comparison result indicates that the original vehicle identification code and the new vehicle identification code have not changed, then the binding relationship between the old equipment and the original vehicle is maintained. If the comparison result indicates that the original vehicle identification code has changed from the new vehicle identification code, then the old device is rejected from establishing a new binding relationship with the current vehicle.

[0008] According to the vehicle terminal network equipment replacement management method provided by the present invention, after rejecting the old equipment from establishing a new binding relationship with the current vehicle, the method further includes: Send an instruction to the current vehicle to refuse the establishment of a new binding relationship between the old device and the current vehicle.

[0009] According to the vehicle-mounted terminal network device replacement management method provided by the present invention, the step of performing network access verification on the old device based on a preset first whitelist and the logical network address carried in the request, and obtaining the network verification result, includes: Determine whether the logical network address of the old device is in the first whitelist; If the device is not on the first whitelist, then access to the in-vehicle domain network is permitted. If the device is on the first whitelist, then access to the in-vehicle domain network is prohibited.

[0010] According to the vehicle-mounted terminal network device replacement management method provided by the present invention, before performing network access verification on the old device based on a preset first whitelist and the logical network address carried in the request, the method further includes: By using a preset vehicle-to-cloud communication protocol, the device identification code and the vehicle domain logical network address reported by the vehicle terminal network device are received, and the correspondence between the device identification code and the logical network address is established and stored.

[0011] The method for managing vehicle-mounted terminal network equipment after component replacement according to the present invention further includes: If it is determined that the old device needs to be reactivated, the logical network address of the old device is removed from the first whitelist, and the device identifier of the old device is removed from the second whitelist.

[0012] The present invention also provides a management device for vehicle-mounted terminal network equipment after component replacement, comprising: The network access verification unit is used to perform network access verification on the old device based on a preset first whitelist and the logical network address carried in the request when a network connection request is received from the old device, and obtain the network verification result. The first whitelist stores the logical network addresses of the offline old devices. The binding relationship verification unit is used to verify the vehicle binding relationship of the old device based on a preset second whitelist, the device identifier code of the old device, and the changes in the vehicle identifier code bound to the old device when the network verification result indicates that the old device is allowed to access the in-vehicle domain network. The second whitelist stores the device identifier code of the old device that has been decommissioned.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the vehicle terminal network device replacement management method as described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vehicle terminal network device replacement management method as described above.

[0015] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements the vehicle terminal network device replacement management method as described above.

[0016] The method and apparatus for managing vehicle-mounted terminal network equipment after parts replacement provided by this invention replaces the traditional mode that relies entirely on manual recording, judgment and operation with a dual-verification automated process based on network access verification based on a first whitelist and data verification based on a second whitelist and VIN changes. This not only greatly reduces human error, but also achieves accurate and automated management of the equipment lifecycle status, significantly improving the efficiency of the entire management process and the intelligence level of the system. Attached Figure Description To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is one of the flowcharts illustrating the management method for vehicle-mounted terminal network equipment after component replacement provided by the present invention.

[0018] Figure 2 is a second flowchart illustrating the management method for vehicle-mounted terminal network equipment after component replacement provided by the present invention.

[0019] Figure 3 This is a schematic diagram of the structure of the vehicle-mounted terminal network equipment after component replacement management device provided by the present invention.

[0020] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0022] To address the reliability and security issues arising from the reliance on manual operation in managing the binding relationships of in-vehicle terminal network devices in existing technologies, this invention proposes a method for managing in-vehicle terminal network devices after replacement. In this method, upon receiving a network connection request from an old device, network access verification is performed on the old device based on a preset first whitelist and the logical network address carried in the request, yielding a network verification result. The first whitelist stores the logical network addresses of the decommissioned old devices. If the network verification result indicates that the old device is allowed to access the in-vehicle domain network, vehicle binding relationship verification is performed on the old device based on a preset second whitelist, the device identifier code of the old device, and changes in the vehicle identifier code bound to the old device. The second whitelist stores the device identifier code of the decommissioned old device.

[0023] The method provided in this invention first uses a first whitelist storing the logical network addresses of old components for pre-filtering at the network layer. This accurately identifies and blocks any connection requests from offline old components at the network access level, ensuring that old components (even if their VIN codes are not cleared) cannot arbitrarily access the network and report their outdated binding information to the cloud. This avoids erroneous operations by the cloud that might forcibly remove newly installed equipment from the vehicle due to misjudgment, fundamentally guaranteeing the continuity and stability of vehicle communication and control functions. For devices that pass network verification, a second whitelist is used to confirm their old component identity and forcibly verify changes in their VIN codes. This ensures that when a marked old component's VIN code changes (i.e., it is mistakenly installed in another vehicle), a new binding relationship is refused, thereby technically eliminating the possibility of binding relationship tampering and guaranteeing the uniqueness and accuracy of the device-vehicle correspondence.

[0024] The embodiments of the present invention employ a dual-verification automated process based on network access verification using a first whitelist and data verification based on a second whitelist and VIN changes. This process replaces the traditional mode that relies entirely on manual recording, judgment, and operation, significantly reducing human error and enabling precise and automated management of the device's lifecycle status. This greatly improves the efficiency of the entire management process and the intelligence level of the system. This invention is applicable to scenarios requiring management of binding relationships between vehicle-mounted terminal network devices, and can be applied throughout the entire lifecycle of vehicle-mounted terminal network devices, from production to installation, use, maintenance, and disposal / reuse. The implementing entity for this method can be a cloud device, computer, server, server cluster, or a specially designed post-replacement management device for vehicle-mounted terminal network devices, or a management device installed within such an electronic device. This device can be implemented through software, hardware, or a combination of both.

[0025] In the description of the embodiments of the present invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of the present invention, "multiple" means two or more, unless otherwise explicitly specified.

[0026] Figure 1 This is one of the flowcharts illustrating the management method for vehicle-mounted terminal network equipment after component replacement provided by the present invention, such as... Figure 1 As shown, the method includes the following steps 110-120.

[0027] Step 110: Upon receiving a network connection request from an old device, perform network access verification on the old device based on a preset first whitelist and the logical network address carried in the request, obtain the network verification result, and store the logical network address of the offline old device in the first whitelist.

[0028] Specifically, the execution entity in this embodiment can be a cloud management platform. "Legacy equipment" refers to electronic control units with network communication capabilities that are removed from vehicles that have already been discontinued and are planned to be installed in new vehicles. "Network connection request of legacy equipment" refers to the process by which legacy equipment, after being powered on again, attempts to establish communication with the current vehicle's in-vehicle network (such as CAN bus or Ethernet).

[0029] To prevent unauthorized devices from accessing the in-vehicle network, this step verifies network access using a primary whitelist. The primary whitelist records the logical network addresses of all officially decommissioned components (those that have reached the end of their lifecycle). A logical network address is a unique address used to identify and address an ECU within the in-vehicle network, similar to an in-vehicle domain IP address. The network verification result is typically a Boolean value: yes / no, indicating whether access is allowed or denied.

[0030] First, determine whether the logical network address of the legacy device is in the first whitelist; if it is not in the first whitelist, allow the legacy device to access the in-vehicle domain network; if it is in the first whitelist, prohibit the legacy device from accessing the in-vehicle domain network.

[0031] When the in-vehicle terminal network equipment is replaced from the original vehicle as an old part, if the new vehicle's VIN code is rewritten by offline diagnostic equipment and an attempt is made to establish a connection with the cloud, the cloud will first perform a first whitelist access verification.

[0032] If the device's IP address belongs to the preset "disabled IP whitelist for replacement," meaning the device's logical network address is in the first whitelist, it means the device has been marked as an outdated component. The cloud immediately triggers a network blocking command to prevent the device from accessing the in-vehicle domain network, directly terminating data interaction and blocking the risk of false reporting of outdated components at the network layer.

[0033] If the device's IP address is not in the disabled whitelist, meaning the device's logical network address is not in the first whitelist, it means that the device is not an old device or is not marked as an old device. In this case, it is allowed to temporarily access the in-vehicle domain network and proceed to the next stage of data layer verification.

[0034] Step 120: If the network verification result indicates that the old device is allowed to access the vehicle domain network, the old device is verified for vehicle binding relationship based on the preset second whitelist, the device identification code of the old device, and the changes in the vehicle identification code bound to the old device. The second whitelist stores the device identification code of the offline old device.

[0035] Specifically, to ensure that each used device can only be used on one vehicle, this step combines the second whitelist and changes in the vehicle identification code to perform data layer verification, verifying whether the binding between the used device and the current vehicle is legal.

[0036] The second whitelist records the device identification codes of all discontinued older components. A device identification code is a unique, unchangeable hardware identifier for a device, fixed during manufacturing; it can be, for example, a hardware serial number (SN). A vehicle identification code is a unique identifier for a vehicle, typically a Vehicle Identification Number (VIN).

[0037] The change in vehicle identification code refers to whether the VIN (VIN) stored inside the old device that was successfully bound last time (i.e., the "old VIN") is consistent with the VIN (i.e., the "new VIN") of the vehicle currently being tried to connect.

[0038] In some embodiments, step 120 specifically includes: Determine if the equipment identification code of the old equipment is in the second whitelist; If it is not in the second whitelist, then the old device is allowed to establish a new binding relationship with the current vehicle; If the device is in the second whitelist, the system retrieves and compares the original vehicle identification code bound to the old device with the newly written vehicle identification code to see if there has been a change, and verifies the vehicle binding relationship based on the comparison results.

[0039] Specifically, the cloud platform receives the old device identification code sent by the gateway, queries the second whitelist, and determines whether the device identification code is within the preset replacement SN whitelist, i.e., whether it is within the second whitelist. If the device identification code is not within the whitelist, it means that the device is a new part or a compliant reused part, and the cloud allows the old device to establish a new binding relationship with the current vehicle and conduct normal data interaction.

[0040] If the device identification code is on the whitelist, it means that the device is indeed a legitimate, decommissioned old part. At this time, the cloud platform reads the "original VIN" previously bound to the old part reported by the device and obtains the current vehicle's "new VIN". It then compares the original vehicle identification code with the new vehicle identification code to see if there have been any changes.

[0041] If the comparison results indicate that the original vehicle identification code and the new vehicle identification code have not changed, then the binding relationship between the old equipment and the original vehicle will be maintained. If the comparison result indicates that the original vehicle identification code has changed from the new vehicle identification code, then the old device is rejected from establishing a new binding relationship with the current vehicle.

[0042] Specifically, if the original vehicle identification code and the new vehicle identification code remain unchanged, it indicates that the old part has not been mistakenly installed back into another vehicle. For example, it may have been repaired on the original vehicle. In this case, the binding relationship between the old part and the original vehicle is maintained, allowing normal interaction. If the original vehicle identification code and the new vehicle identification code have changed, it indicates that the old part has been mistakenly installed into another vehicle. The cloud will refuse to allow the old part to establish a new binding relationship with the current vehicle and will send an instruction to the current vehicle to refuse the establishment of a new binding relationship between the old part and the current vehicle. The instruction content could be, for example, "The device is a replacement part and cannot be reused," to prevent the binding relationship from being tampered with.

[0043] In other embodiments, before performing network access verification on the legacy device based on a preset first whitelist and the logical network address carried in the request, i.e. before step 110, the method further includes: By using a pre-defined vehicle-to-cloud communication protocol, the device identification code and in-vehicle domain logical network address reported by the vehicle terminal network device are received, and the correspondence between the device identification code and the logical network address is established and stored.

[0044] Specifically, this step involves dynamically and automatically collecting and building a database of basic equipment information for subsequent old parts verification throughout the normal lifecycle of the vehicle.

[0045] When the vehicle-mounted terminal network device establishes initial interaction with the cloud management platform, it automatically reports its unique device identifier (SN code) and in-vehicle domain logical network address (IP address) through a preset vehicle-to-cloud communication protocol. After receiving the data, the cloud establishes and stores a one-to-one correspondence between the device's SN code and IP address in its database, forming the basic data support for subsequent verification.

[0046] When the vehicle is finally scrapped and removed from the production line, the cloud system can mark all the on-board network devices that have reported information for the vehicle as "offline used parts", and put their logical network address list into the first whitelist and their device identification code list into the second whitelist.

[0047] This invention, through the automated mechanism of vehicle-cloud collaboration, avoids the workload and error risks of manually entering device information, realizes full automation of data collection, and provides accurate verification basis.

[0048] Based on any of the above embodiments, the method further includes: If it is determined that an old device needs to be reactivated, remove the logical network address of the old device from the first whitelist and remove the device identifier of the old device from the second whitelist.

[0049] Specifically, for special scenarios where vehicle-mounted terminal network equipment needs to be reactivated, such as reuse after fault repair or dedicated bench testing, a "dynamic whitelist removal" function module is set up in the cloud. Through manual triggering or automatic system determination, when it is determined that an old device needs to be reactivated, the target device's logical network address (IP address) is removed from the first whitelist, and the device identification code (SN code) is simultaneously removed from the second whitelist. After the restrictions are lifted, the device can re-establish its binding relationship with the target vehicle, access the network normally, and complete data interaction. This step solves the technical shortcomings of traditional fixed control that cannot adapt to special business scenarios, improving the practicality of the solution.

[0050] Figure 2 This is the second flowchart illustrating the management method for vehicle-mounted terminal network equipment after component replacement provided by the present invention, as follows: Figure 2 As shown, taking the vehicle-mounted terminal network device TBOX as an example, the method includes: 1. Construction of basic information association When TBOX establishes initial interaction with the cloud management platform, it uses a preset vehicle-cloud communication protocol. The cloud receives the device identification code and the vehicle domain logical network address reported by TBOX, and establishes and stores the correspondence between the device identification code and the logical network address.

[0051] 2. Network layer access control after component replacement When a TBOX is replaced from the original vehicle as a used part, upon receiving a network connection request from the used part, the system determines whether the logical network address of the used part is in the first whitelist. If it is not in the first whitelist, the used part is allowed to access the in-vehicle domain network; if it is in the first whitelist, the used part is prohibited from accessing the in-vehicle domain network.

[0052] 3. Data layer binding verification after component replacement The cloud performs dual data verification of the SN code and VIN code for TBOXes that have passed IP verification.

[0053] Step 1: SN code ownership verification: Determine whether the old device's device identification code is in the second whitelist; if it is not in the second whitelist, then allow the old device to establish a new binding relationship with the current vehicle.

[0054] The second step is VIN change verification: If the device identification code is in the second whitelist, then obtain and compare the original vehicle identification code bound to the old device with the newly written vehicle identification code to see if there is a change. If there is no change, then maintain the binding relationship between the old device and the original vehicle; if there is a change, then refuse to establish a new binding relationship between the old device and the current vehicle, and report the reason for the failure to the vehicle.

[0055] 4. Dynamic adaptation for special scenarios For special scenarios where TBOX needs to be reactivated, the logical network address of the old device is removed from the first whitelist, and the device identifier of the old device is removed from the second whitelist.

[0056] The method provided by this invention breaks through the existing management mode that relies solely on manual operation. It forms a closed-loop control system through dual technical means of "network layer blocking (IP) + data layer verification (SN-VIN)" and adds a dynamic whitelist adaptation mechanism. This ensures the uniqueness of the binding relationship between the vehicle terminal network device and the vehicle, while also taking into account the flexibility of business scenarios, effectively solving the vulnerabilities of the existing technology.

[0057] The following describes the vehicle-mounted terminal network equipment after parts replacement management device provided by the present invention. The vehicle-mounted terminal network equipment after parts replacement management device described below can be referred to in correspondence with the vehicle-mounted terminal network equipment after parts replacement management method described above.

[0058] Based on the above embodiments, Figure 3 This is a schematic diagram of the structure of the vehicle-mounted terminal network equipment after component replacement management device provided by the present invention, as shown below. Figure 3 As shown, the device includes: The network access verification unit 310 is used to perform network access verification on the old device based on a preset first whitelist and the logical network address carried in the request when a network connection request is received from the old device, and obtain a network verification result. The first whitelist stores the logical network addresses of the offline old devices. The binding relationship verification unit 320 is used to verify the vehicle binding relationship of the old device based on a preset second whitelist, the device identifier code of the old device, and the changes in the vehicle identifier code bound to the old device when the network verification result indicates that the old device is allowed to access the in-vehicle domain network. The second whitelist stores the device identifier code of the offline old device.

[0059] Based on the above embodiments, the binding relationship verification unit is specifically used for: Determine whether the device identification code of the old device is in the second whitelist; If it is not in the second whitelist, then the old device is allowed to establish a new binding relationship with the current vehicle; If it is in the second whitelist, then obtain and compare whether the original vehicle identification code bound to the old device has changed with the newly written vehicle identification code, and verify the vehicle binding relationship based on the comparison result.

[0060] Based on the above embodiments, the binding relationship verification unit is specifically used for: If the comparison result indicates that the original vehicle identification code and the new vehicle identification code have not changed, then the binding relationship between the old equipment and the original vehicle is maintained. If the comparison result indicates that the original vehicle identification code has changed from the new vehicle identification code, then the old device is rejected from establishing a new binding relationship with the current vehicle.

[0061] Based on the above embodiments, the device further includes an instruction sending unit, used for: Send an instruction to the current vehicle to refuse the establishment of a new binding relationship between the old device and the current vehicle.

[0062] Based on the above embodiments, the network access verification unit is specifically used for: Determine whether the logical network address of the old device is in the first whitelist; If the device is not on the first whitelist, then access to the in-vehicle domain network is permitted. If the device is on the first whitelist, then access to the in-vehicle domain network is prohibited.

[0063] Based on the above embodiments, the device further includes a relationship building unit, used for: By using a preset vehicle-to-cloud communication protocol, the device identification code and the vehicle domain logical network address reported by the vehicle terminal network device are received, and the correspondence between the device identification code and the logical network address is established and stored.

[0064] Based on the above embodiments, the device further includes a whitelist adaptation unit, used for: If it is determined that the old device needs to be reactivated, the logical network address of the old device is removed from the first whitelist, and the device identifier of the old device is removed from the second whitelist.

[0065] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communications interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a management method for vehicle terminal network devices after replacement. This method includes: upon receiving a network connection request from an old device, performing network access verification on the old device based on a preset first whitelist and the logical network address carried in the request, and obtaining a network verification result, wherein the first whitelist stores the logical network address of the decommissioned old device; if the network verification result indicates that the old device is allowed to access the in-vehicle domain network, performing vehicle binding relationship verification on the old device based on a preset second whitelist, the device identifier code of the old device, and changes in the vehicle identifier code bound to the old device, wherein the second whitelist stores the device identifier code of the decommissioned old device.

[0066] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0067] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the vehicle terminal network device replacement management method provided by the above methods. The method includes: upon receiving a network connection request from an old device, performing network access verification on the old device based on a preset first whitelist and the logical network address carried in the request, and obtaining a network verification result, wherein the first whitelist stores the logical network address of the offline old device; and if the network verification result indicates that the old device is allowed to access the vehicle domain network, performing vehicle binding relationship verification on the old device based on a preset second whitelist, the device identifier code of the old device, and changes in the vehicle identifier code bound to the old device, wherein the second whitelist stores the device identifier code of the offline old device.

[0068] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the vehicle terminal network device replacement management method provided by the above methods. The method includes: upon receiving a network connection request from an old device, performing network access verification on the old device based on a preset first whitelist and the logical network address carried in the request, and obtaining a network verification result, wherein the first whitelist stores the logical network address of the offline old device; and if the network verification result indicates that the old device is allowed to access the in-vehicle domain network, performing vehicle binding relationship verification on the old device based on a preset second whitelist, the device identifier code of the old device, and changes in the vehicle identifier code bound to the old device, wherein the second whitelist stores the device identifier code of the offline old device.

[0069] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0070] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0071] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for managing vehicle-mounted terminal network equipment after component replacement, characterized in that, include: Upon receiving a network connection request from an old device, the network access of the old device is verified based on a preset first whitelist and the logical network address carried in the request, and a network verification result is obtained. The first whitelist stores the logical network addresses of the offline old devices. If the network verification result indicates that the old device is allowed to access the vehicle domain network, the vehicle binding relationship of the old device is verified based on the preset second whitelist, the device identifier code of the old device, and the changes in the vehicle identifier code bound to the old device. The second whitelist stores the device identifier code of the offline old device.

2. The method for managing vehicle-mounted terminal network equipment after component replacement according to claim 1, characterized in that, The method of verifying the vehicle binding relationship of the old device based on a preset second whitelist, the device identification code of the old device, and changes in the vehicle identification code bound to the old device includes: Determine whether the device identification code of the old device is in the second whitelist; If it is not in the second whitelist, then the old device is allowed to establish a new binding relationship with the current vehicle; If it is in the second whitelist, then obtain and compare whether the original vehicle identification code bound to the old device has changed with the newly written vehicle identification code, and verify the vehicle binding relationship based on the comparison result.

3. The method for managing vehicle-mounted terminal network equipment after component replacement according to claim 2, characterized in that, The vehicle binding relationship verification based on the comparison results includes: If the comparison result indicates that the original vehicle identification code and the new vehicle identification code have not changed, then the binding relationship between the old equipment and the original vehicle is maintained. If the comparison result indicates that the original vehicle identification code has changed from the new vehicle identification code, then the old device is rejected from establishing a new binding relationship with the current vehicle.

4. The method for managing vehicle-mounted terminal network equipment after component replacement according to claim 3, characterized in that, After rejecting the establishment of a new binding relationship between the old device and the current vehicle, the method further includes: Send an instruction to the current vehicle to refuse the establishment of a new binding relationship between the old device and the current vehicle.

5. The method for managing vehicle-mounted terminal network equipment after component replacement according to claim 1, characterized in that, The process of performing network access verification on the legacy device based on a preset first whitelist and the logical network address carried in the request, and obtaining the network verification result, includes: Determine whether the logical network address of the old device is in the first whitelist; If the device is not on the first whitelist, then access to the in-vehicle domain network is permitted. If the device is on the first whitelist, then access to the in-vehicle domain network is prohibited.

6. The method for managing vehicle-mounted terminal network equipment after component replacement according to any one of claims 1 to 5, characterized in that, Before performing network access verification on the legacy device based on a preset first whitelist and the logical network address carried in the request, the method further includes: By using a preset vehicle-to-cloud communication protocol, the device identification code and the vehicle domain logical network address reported by the vehicle terminal network device are received, and the correspondence between the device identification code and the logical network address is established and stored.

7. The method for managing vehicle-mounted terminal network equipment after component replacement according to any one of claims 1 to 5, characterized in that, The method further includes: If it is determined that the old device needs to be reactivated, the logical network address of the old device is removed from the first whitelist, and the device identifier of the old device is removed from the second whitelist.

8. A management device for vehicle-mounted terminal network equipment after component replacement, characterized in that, include: The network access verification unit is used to perform network access verification on the old device based on a preset first whitelist and the logical network address carried in the request when a network connection request is received from the old device, and obtain the network verification result. The first whitelist stores the logical network addresses of the offline old devices. The binding relationship verification unit is used to verify the vehicle binding relationship of the old device based on a preset second whitelist, the device identifier code of the old device, and the changes in the vehicle identifier code bound to the old device when the network verification result indicates that the old device is allowed to access the in-vehicle domain network. The second whitelist stores the device identifier code of the old device that has been decommissioned.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the vehicle-mounted terminal network device replacement management method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the vehicle-mounted terminal network device replacement management method as described in any one of claims 1 to 7.

Images