Function verification system, method and device for replacement tbox and storage medium

Abstract

This invention discloses a functional verification system, method, device, and storage medium for a replacement TBOX. The system includes an OBD (On-Board Diagnostics) system, a cloud platform, and a TBOX. The OBD encapsulates TBOX replacement information, vehicle identification information, and operational status information into a standard information packet. The cloud extracts the vehicle VIN and TBOX-ICCID from the standard information packet, performs binding verification on the VIN and ICCID, and generates a session ID upon successful verification. The replacement type is determined using the session ID, and the corresponding diagnostic level instruction set is matched based on the replacement type. The diagnostic level instruction set is then broken down into functional instructions, and these fragments are sent to the OBD. After receiving the fragments, the OBD sequentially sends each functional instruction fragment to the TBOX for functional verification based on the session ID. This invention establishes a collaborative link between the OBD and the cloud, issuing dynamic diagnostic instructions to achieve accurate TBOX functional verification.

Description

Technical Field

[0001] This invention relates to the field of TBOX function verification technology, and in particular to a function verification system, method, device and storage medium for a replaceable TBOX. Background Technology

[0002] With the rapid development of the intelligent connected vehicle industry, the on-board telematics terminal (TBOX) has become a core component of intelligent connected vehicles. Its operational stability and functional integrity are directly related to vehicle driving safety, user experience, and the normal operation of vehicle connectivity services.

[0003] Throughout the entire lifecycle of a TBOX, hardware wear and tear, as well as malfunctions and repairs, often necessitate replacement. After replacement, rigorous functional verification is required to ensure the new TBOX can interact correctly with the vehicle's ECU and cloud platform, fully replacing all the functions of the original device. Currently, the industry-standard functional verification schemes for TBOX replacements are no longer suitable for the evolving technology of TBOXes towards intelligent connected domain controllers, and have significant shortcomings. First, the verification method is relatively simple. It relies heavily on maintenance personnel operating local diagnostic tools to perform fixed offline tests on the TBOX. The effectiveness of the interaction with the cloud cannot be confirmed through local testing, which easily leads to the hidden danger of "local testing is normal, but cloud interaction fails". Second, the diagnostic commands lack dynamic adaptability. Regardless of whether a brand-new or repaired part is replaced, or whether a core module or an auxiliary module is replaced, a unified command set is used, resulting in low verification efficiency or the risk of missed detections.

[0004] Therefore, how to achieve accurate verification of the TBOX function has become an urgent problem to be solved.

[0005] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main objective of this invention is to provide a functional verification system, method, device, and storage medium for TBOX replacement parts, aiming to address the technical problem of how to accurately verify the function of TBOX.

[0007] To achieve the above objectives, the present invention provides a functional verification system for a replacement TBOX, the replacement TBOX functional verification system comprising OBD, cloud, and TBOX; The OBD is used to receive TBOX replacement information, vehicle identity information and operating status information sent by the TBOX, and encapsulate the TBOX replacement information, the vehicle identity information and the operating status information into a standard information package and upload it to the cloud. The cloud is used to extract the vehicle VIN code and TBOX-ICCID from the standard information packet, perform binding verification on the vehicle VIN code and the TBOX-ICCID, generate a session ID after successful verification, and send the verification result and the session ID to the OBD. The cloud platform is also used to determine the replacement type through the session ID, match the corresponding diagnostic level instruction set according to the replacement type, split the diagnostic level instruction set into functional instructions, and send the split functional instructions to the OBD. The OBD is also used to, after receiving the data, sequentially send each function instruction fragment to the TBOX for function verification based on the session ID.

[0008] Optionally, the system also includes a maintenance terminal; Before receiving the TBOX replacement information, vehicle identification information, and operating status information sent by the TBOX, the process also includes: Upon receiving the replacement verification command triggered by the maintenance terminal, an information reading request is sent to the TBOX so that the TBOX can return the TBOX replacement information, vehicle identity information, and operating status information.

[0009] Optionally, the binding and verification of the vehicle VIN code and the TBOX-ICCID includes: Match the corresponding TBOX binding code from the preset binding code library based on the vehicle VIN code; The vehicle VIN code and the TBOX-ICCID are bound and verified according to the vehicle VIN code and the TBOX binding code.

[0010] Optionally, after the verification is successful, the method further includes: The vehicle data is matched with the corresponding vehicle data from a preset information database based on the vehicle VIN code, and the vehicle data is sent to the OBD.

[0011] Optionally, after sending the verification result and the session ID to the OBD, the method further includes: A notification message indicating successful information reporting is sent to the maintenance department, completing the startup process.

[0012] Optionally, determining the replacement type using the session ID includes: Associate the session ID with the TBOX replacement information; The replacement type is determined based on the TBOX replacement information.

[0013] Optionally, the TBOX is also used to send back the functional verification results of each functional instruction fragment and the corresponding progress snapshot to the OBD; The OBD is also used to report the session ID, the mutual key, the functional verification results of each functional instruction fragment, and the corresponding progress snapshot to the cloud so that the cloud can perform legal verification.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes a functional verification method for a replacement TBOX, the functional verification method for a replacement TBOX comprising the following steps: The OBD receives TBOX replacement information, vehicle identification information, and operating status information sent by the TBOX, and encapsulates the TBOX replacement information, vehicle identification information, and operating status information into a standard information package and uploads it to the cloud. The cloud extracts the vehicle VIN code and TBOX-ICCID from the standard information packet, performs binding verification on the vehicle VIN code and the TBOX-ICCID, generates a session ID after successful verification, and sends the verification result and the session ID to the OBD. The cloud determines the replacement type through the session ID, matches the corresponding diagnostic level instruction set according to the replacement type, and splits the diagnostic level instruction set into functional instructions, sending the split functional instructions to the OBD in fragments. After the OBD receives the data, it sends the function commands in fragments to the TBOX sequentially based on the session ID for function verification.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a functional verification device for a replacement TBOX, the device comprising: a memory, a processor, and a functional verification program for the replacement TBOX stored in the memory and executable on the processor, the functional verification program for the replacement TBOX being configured to implement the steps of the functional verification method for the replacement TBOX as described above.

[0016] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a functional verification program for a replacement TBOX, wherein when the functional verification program for the replacement TBOX is executed by a processor, the program implements the steps of the functional verification method for the replacement TBOX as described above.

[0017] This invention discloses a functional verification system for a replacement TBOX. The system includes a TBOX functional verification mechanism. First, the OBD receives TBOX replacement information, vehicle identity information, and operational status information from the TBOX. This information is then encapsulated into a standard information packet and uploaded to the cloud. The cloud then extracts the vehicle VIN and TBOX-ICCID from the standard information packet and performs binding verification on them. Upon successful verification, a session ID is generated, and the verification result and session ID are sent to the OBD. The cloud then determines the replacement type using the session ID, matches the corresponding diagnostic level instruction set based on the replacement type, and performs functional instruction decomposition within the diagnostic level instruction set. The decomposed functional instruction fragments are sent to the OBD. After receiving the fragments, the OBD sequentially sends each functional instruction fragment to the TBOX for functional verification based on the session ID. This invention establishes a collaborative link between the OBD and the cloud, issuing dynamic diagnostic instructions to achieve accurate TBOX functional verification. Attached Figure Description

[0018] Figure 1 This is a structural block diagram of the first embodiment of the TBOX replacement function verification system of the present invention; Figure 2 This is an interaction timing diagram of the first embodiment of the TBOX replacement function verification system of the present invention; Figure 3 This is a schematic diagram of the structure of the TBOX functional verification device, which is a component of the hardware operating environment involved in the embodiments of the present invention. Figure 4 This is a flowchart illustrating the first embodiment of the functional verification method for the replacement TBOX of the present invention.

[0019] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0021] Reference Figure 1 , Figure 1 This is a structural block diagram of the first embodiment of the TBOX functional verification system of the present invention.

[0022] like Figure 1 As shown, the functional verification system for the replacement TBOX proposed in this embodiment of the invention includes an on-board diagnostic system (OBD) 1001, a cloud platform 1002, and a telematics box TBOX 1003.

[0023] In the specific implementation, refer to Figure 2 , Figure 2 This is an interactive timing diagram of the first embodiment of the TBOX replacement function verification system of the present invention. The system also includes a maintenance terminal, which can trigger the replacement verification command.

[0024] After replacing the TBOX, insert the OBD connector into the OBD interface and trigger the "replacement verification" command through the maintenance terminal. The OBD immediately sends an information read request to the TBOX, so that the TBOX can return the TBOX replacement information, vehicle identification information, and operating status information. The OBD receives the TBOX replacement information, vehicle identification information, and operating status information sent by the TBOX, encapsulates the TBOX replacement information, vehicle identification information, and operating status information into a standard information packet, and uploads it to the cloud via a 4G or 5G network.

[0025] The TBOX replacement information includes the type of replacement part (including new, repaired, or used), part number, and hardware version; vehicle identification information includes the vehicle VIN code and the TBOX Integrated Circuit Card Identifier ICCID; and operating status information includes power supply status and network status.

[0026] The cloud-based 1002 extracts the vehicle VIN code and TBOX-ICCID from the standard information packet, performs binding verification on the vehicle VIN code and TBOX-ICCID, generates a session ID after successful verification, and sends the verification result and session ID to the OBD1001.

[0027] The verification result is either successful or failed.

[0028] It should also be noted that after receiving the standard information packet, the cloud parses the packet and extracts the vehicle VIN code and TBOX-ICCID from it. Then, it matches the corresponding TBOX binding code from a preset binding code library based on the vehicle VIN code. There is a one-to-one correspondence between the vehicle VIN code and the TBOX binding code in the preset binding code library. The binding verification is then performed on the vehicle VIN code and TBOX-ICCID based on the vehicle VIN code and the TBOX binding code.

[0029] The process for binding and verifying the vehicle VIN code and TBOX-ICCID based on the vehicle VIN code and TBOX binding code is as follows: It is determined whether the vehicle VIN code and TBOX binding code correspond to the vehicle VIN code and TBOX-ICCID. If they match, the verification is successful; otherwise, the verification fails and manual binding is required. After successful verification, a session ID is established, and the verification result and session ID are sent to the OBD. Then, the corresponding vehicle data is matched from a preset information database based on the vehicle VIN code, and the vehicle data, including the vehicle model and function data corresponding to the vehicle VIN code, is sent to the OBD. Simultaneously, the OBD pushes a "Information reporting successful, awaiting instructions" message to the maintenance terminal, completing the startup process.

[0030] The cloud-based 1002 is also used to determine the replacement type through the session ID, match the corresponding diagnostic level instruction set according to the replacement type, and split the diagnostic level instruction set into functional instructions, and send the split functional instructions to the OBD1001.

[0031] The process for determining the replacement type using the session ID is as follows: associate the session ID with the TBOX replacement information; determine the replacement type based on the TBOX replacement information.

[0032] In practice, the cloud uses session IDs to associate replacement information and initiates a "replacement type - diagnostic level instruction set" matching strategy. For example, a brand-new communication module (core component) matches the "core level" instruction set, a repair-grade positioning module matches the "basic level + core level" instruction set, and a disassembled vehicle matches the "basic level" instruction set. After matching, the corresponding instruction set is generated and split into independent segments (i.e., functional instruction segments) according to function. Each segment is attached with a unique identifier, a triple signature of VIN + ICCID + timestamp, and an execution timeout threshold to prepare for subsequent transmission.

[0033] In practice, the cloud sequentially sends function command fragments via a long TCP connection. After receiving the fragment, the OBD must send back a "fragment reception confirmation". If the cloud does not receive confirmation within 1 second, it will automatically retransmit in increments of 1 second, 2 seconds, and 3 seconds (up to 3 times). After a single fragment is confirmed, the cloud prepares and sends the next fragment, forming an ordered chain of "send-confirm-re-send" until all function command fragments have been sent.

[0034] The OBD1001 is also used to send the fragmented function commands to the TBOX1003 for function verification based on the session ID after receiving the data.

[0035] In its implementation, OBD forwards function command fragments sequentially to TBOX, enabling TBOX to perform functional checks based on these fragments (e.g., basic-level function command fragments check power supply / bus, core-level function command fragments check remote control / positioning, etc.). Upon completion, TBOX generates an "execution result + progress snapshot" for each function command fragment and sends it back to OBD. OBD appends a session ID and a mutual key (i.e., the interaction key between OBD and TBOX) and reports it to the cloud. After the cloud performs dual verification of legitimacy and key consistency, it sends a "result confirmed" message and subsequent notifications. Throughout the process, the cloud and OBD maintain a connection via a 5-second heartbeat to ensure state synchronization.

[0036] It should also be noted that the cloud pre-stores the regulations related to the legality of the vehicle and the interaction key between OBD and TBOX. The "execution result + progress snapshot" is legally verified by using the pre-stored regulations related to the legality of the vehicle, and the pre-stored interaction key is checked to see if it is consistent with the mutual transmission key attached to OBD.

[0037] In this embodiment, cloud verification detects anomalies and responds in a tiered manner: if execution times out, an adjustment command is issued to drive OBD to re-forward; if the network is interrupted, the OBD caches the fragments, and upon recovery, requests a resume transmission from the breakpoint, with the cloud re-transmitting the remaining content based on a snapshot; if the signature is incorrect, the OBD discards the command, the cloud triggers an alarm, and terminates the session. If a fragment fails to retrace twice consecutively, the cloud pushes an anomaly report containing the cause of the fault to the maintenance end, guiding manual troubleshooting and re-triggering verification, thus achieving a closed loop for the abnormal link.

[0038] After all segments are successfully executed, a pass report containing verification time and instruction details is generated in the cloud and synchronized to the maintenance terminal and vehicle archive. After confirmation by the maintenance personnel, the OBD connector is disconnected. The OBD sends a "verification complete" command to the TBOX, which resumes normal operation and provides confirmation. Finally, the OBD reports "process terminated" to the cloud, and the cloud records the end status. If verification fails, the cloud freezes the TBOX's remote access until a second verification is successful, completing the closed-loop process.

[0039] In this implementation, the OBD first receives the TBOX replacement information, vehicle identification information, and operational status information sent by the TBOX. It then encapsulates these information into a standard information packet and uploads it to the cloud. The cloud then extracts the vehicle VIN and TBOX-ICCID from the standard information packet, performs binding verification on the VIN and TBOX-ICCID, and generates a session ID upon successful verification. The verification result and session ID are then sent to the OBD. The cloud determines the replacement type based on the session ID, matches the corresponding diagnostic level instruction set, and decomposes the diagnostic level instruction set into functional instructions. These decomposed functional instructions are then sent to the OBD. After receiving the data, the OBD sequentially sends each functional instruction fragment to the TBOX for functional verification based on the session ID. This embodiment establishes a collaborative link between the OBD and the cloud, issuing dynamic diagnostic instructions to achieve accurate TBOX function verification.

[0040] Reference Figure 3 , Figure 3 This is a schematic diagram of the functional verification device structure of the TBOX component in the hardware operating environment involved in the embodiments of the present invention.

[0041] like Figure 3 As shown, the functional verification device for the TBOX may include: a processor 3001, such as a central processing unit (CPU), a communication bus 3002, a user interface 3003, a network interface 3004, and a memory 3005. The communication bus 3002 is used to enable communication between these components. The user interface 3003 may include a display screen and an input unit such as a keyboard; optionally, the user interface 3003 may also include a standard wired interface or a wireless interface. The network interface 3004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 3005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk storage device. Optionally, the memory 3005 may also be a storage system independent of the aforementioned processor 3001.

[0042] Those skilled in the art will understand that Figure 3 The structure shown does not constitute a limitation on the functional verification device of the TBOX, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0043] like Figure 3As shown, the memory 3005, which serves as a storage medium, may include an operating system, a network access module, a user interface module, and a function verification program for the replacement TBOX.

[0044] exist Figure 3 In the functional verification device for the replacement TBOX shown, the network interface 3004 is mainly used for data communication with the network server; the user interface 3003 is mainly used for data interaction with the user; the processor 3001 and the memory 3005 in the functional verification device for the replacement TBOX of the present invention can be set in the functional verification device for the replacement TBOX. The functional verification device for the replacement TBOX calls the functional verification program for the replacement TBOX stored in the memory 3005 through the processor 3001 and executes the functional verification method for the replacement TBOX provided in the embodiment of the present invention.

[0045] This invention provides a method for verifying the function of a replacement TBOX, referring to... Figure 4 , Figure 4 This is a flowchart illustrating the first embodiment of the functional verification method for the replacement TBOX of the present invention.

[0046] In this embodiment, the functional verification method of the replacement TBOX includes the following steps: S1, the OBD receives the TBOX replacement information, vehicle identity information and operating status information sent by the TBOX, and encapsulates the TBOX replacement information, the vehicle identity information and the operating status information into a standard information package and uploads it to the cloud; S2, the cloud extracts the vehicle VIN code and TBOX-ICCID from the standard information packet, performs binding verification on the vehicle VIN code and the TBOX-ICCID, generates a session ID after successful verification, and sends the verification result and the session ID to the OBD; S3, the cloud determines the replacement type through the session ID, matches the corresponding diagnostic level instruction set according to the replacement type, splits the diagnostic level instruction set into functional instructions, and sends the split functional instructions to the OBD in fragments; S4, after the OBD receives the data, it sends each function instruction fragment to the TBOX sequentially based on the session ID for function verification.

[0047] Other embodiments or specific implementations of the functional verification method for the replacement TBOX of the present invention can be referred to the above system embodiments, and will not be repeated here.

[0048] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0049] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0050] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0051] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A function verification system of a replacement TBOX, characterized by, The system includes OBD, cloud computing, and TBOX; The OBD is used to receive TBOX replacement information, vehicle identity information and operating status information sent by the TBOX, and encapsulate the TBOX replacement information, the vehicle identity information and the operating status information into a standard information package and upload it to the cloud. The cloud is used to extract the vehicle VIN code and TBOX-ICCID from the standard information packet, perform binding verification on the vehicle VIN code and the TBOX-ICCID, generate a session ID after successful verification, and send the verification result and the session ID to the OBD. The cloud platform is also used to determine the replacement type through the session ID, match the corresponding diagnostic level instruction set according to the replacement type, split the diagnostic level instruction set into functional instructions, and send the split functional instructions to the OBD. The OBD is also used to, after receiving the data, sequentially send each function instruction fragment to the TBOX for function verification based on the session ID.

2. The system as described in claim 1, characterized in that, The system also includes a maintenance terminal; Before receiving the TBOX replacement information, vehicle identification information, and operating status information sent by the TBOX, the process also includes: Upon receiving the replacement verification command triggered by the maintenance terminal, an information reading request is sent to the TBOX so that the TBOX can return the TBOX replacement information, vehicle identity information, and operating status information.

3. The system as described in claim 1, characterized in that, The binding and verification of the vehicle VIN code and the TBOX-ICCID includes: Match the corresponding TBOX binding code from the preset binding code library based on the vehicle VIN code; The vehicle VIN code and the TBOX-ICCID are bound and verified according to the vehicle VIN code and the TBOX binding code.

4. The system as described in claim 1, characterized in that, After the verification is successful, it also includes: The vehicle data is matched with the corresponding vehicle data from a preset information database based on the vehicle VIN code, and the vehicle data is sent to the OBD.

5. The system as described in claim 1, characterized in that, After sending the verification result and the session ID to the OBD, the process further includes: A notification message indicating successful information reporting is sent to the maintenance department, completing the startup process.

6. The system as described in claim 1, characterized in that, The step of determining the replacement type through the session ID includes: Associate the session ID with the TBOX replacement information; The replacement type is determined based on the TBOX replacement information.

7. The system as described in claim 1, characterized in that, The TBOX is also used to send back the functional verification results of each functional instruction fragment and the corresponding progress snapshot to the OBD; The OBD is also used to report the session ID, the mutual key, the functional verification results of each functional instruction fragment, and the corresponding progress snapshot to the cloud so that the cloud can perform legal verification.

8. A method for verifying the function of a replaceable TBOX, characterized in that, The method includes the following steps: The OBD receives TBOX replacement information, vehicle identification information, and operating status information sent by the TBOX, and encapsulates the TBOX replacement information, vehicle identification information, and operating status information into a standard information package and uploads it to the cloud. The cloud extracts the vehicle VIN code and TBOX-ICCID from the standard information packet, performs binding verification on the vehicle VIN code and the TBOX-ICCID, generates a session ID after successful verification, and sends the verification result and the session ID to the OBD. The cloud determines the replacement type through the session ID, matches the corresponding diagnostic level instruction set according to the replacement type, and splits the diagnostic level instruction set into functional instructions, sending the split functional instructions to the OBD in fragments. After the OBD receives the data, it sends the function command fragments to the TBOX sequentially based on the session ID for function verification.

9. A functional verification device for a replaceable TBOX, characterized in that, The device includes: a memory, a processor, and a functional verification program for the replacement TBOX stored in the memory and executable on the processor, the functional verification program for the replacement TBOX being configured to implement the steps of the functional verification method for the replacement TBOX as described in claim 8.

10. A storage medium, characterized in that, The storage medium stores a functional verification program for the replacement TBOX, which, when executed by the processor, implements the steps of the functional verification method for the replacement TBOX as described in claim 8.

Images