GNSS simulation-based tbox log verification method, device and equipment

Abstract

The application discloses a kind of based on GNSS simulation TBOX log verification method, device and equipment, is related to vehicle-mounted intelligent network connection test technical field, which method includes creating TBOX test scene, the TBOX test scene includes the GNSS simulator for switching satellite signal scene at preset time, the event dependency directed graph for recording ECALL event dependency relationship, the program-controlled power supply for realizing TBOX power supply, the clock drift statistical procedure for recording time information in TBOX log;Based on the created TBOX test scene, GNSS simulator linkage log verification, event link semantics verification, abnormal power failure log integrity test, clock drift long-term statistical analysis are carried out.This application can realize the comprehensive automation verification to TBOX maintenance survey log time accuracy, content integrity and system stability.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted intelligent connected vehicle testing technology, specifically to a TBOX log verification method, device, and equipment based on GNSS simulation. Background Technology

[0002] In the current TBOX (Telematics Box for Vehicles) testing work, the testing of maintenance logs mainly relies on manual operation, which leads to the following problems: (1) Manually triggered events (such as sleep / wake-up, weak network switching, ECALL (emergency call, Emergency Call button, etc.) are difficult to guarantee the accurate recording of the trigger time, resulting in large time verification errors; (2) Existing tests only cover basic events and lack verification of log responses caused by GNSS (Global Navigation Satellite System) positioning changes (tunnels, obstruction, signal loss); (3) Edge scenarios such as power outages and storage overflow rely entirely on manual simulation, resulting in poor repeatability and low efficiency; (4) Log verification relies solely on human visual comparison, which cannot detect the integrity of the upstream and downstream logical links of event fields, resulting in a high rate of missed detections; (5) Long-term clock drift problems cannot be detected through a single test, and there is a lack of quantitative evaluation methods.

[0003] Therefore, how to effectively test TBOX maintenance logs has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a TBOX log verification method, device, and equipment based on GNSS simulation, which can realize comprehensive automated verification of the time accuracy, content integrity, and system stability of TBOX maintenance logs.

[0005] In a first aspect, embodiments of this application provide a TBOX log verification method based on GNSS simulation, the TBOX log verification method based on GNSS simulation comprising: Create a TBOX test scenario, which includes a GNSS simulator for switching satellite signal scenarios at preset times, an event dependency directed graph for recording ECALL event dependencies, a programmable power supply for powering the TBOX, and a clock drift statistics program for recording time information in the TBOX log. Based on the created TBOX test scenario, we performed GNSS simulator linkage log verification, event link semantic verification, abnormal power failure log integrity testing, and long-term statistical analysis of clock drift.

[0006] In conjunction with the first aspect, in one implementation method, the verification of GNSS simulator linkage logs specifically includes: Power on the TBOX using a programmable power supply and record the power-on time. Control the GNSS simulator to output a normal positioning scene. After waiting for the TBOX log to record the positioning success event, record the current time. Control the GNSS simulator to switch to the satellite signal blockage scene in a step-attenuation mode, and record the time when the satellite signal begins to attenuate and the time when the satellite signal is completely blocked. After waiting for a preset time, control the satellite signal to recover with the same advance slope, and record the time when the satellite signal recovery is completed. Read the TBOX logs and, based on the recorded time information, as well as the GPS status field, event timestamp, and HDOP value in the TBOX logs, determine whether the GNSS simulator linkage log verification passes.

[0007] In conjunction with the first aspect, in one implementation method, If the GPS status field exists, the HDOP value is invalid during the period when the satellite signal is completely blocked, the difference between the timestamp of the satellite signal loss event and the time when the satellite signal begins to attenuate in the TBOX log file is less than or equal to the first threshold, and the difference between the timestamp of the satellite signal recovery event and the time when the satellite signal recovery is completed in the TBOX log file is less than or equal to the second threshold, then the GNSS simulator linkage log verification is deemed to have passed. Otherwise, the GNSS simulator linkage log verification is deemed to have failed.

[0008] In conjunction with the first aspect, in one implementation method, the event chain semantic verification specifically includes: Define the ECALL event dependency as follows: after the ECALL event is triggered, record the GPS location field, the MSD minimum dataset transmission field, and the TSP handshake response field. The ECALL button is connected via a relay to simulate being pressed, and the moment of pressing is recorded. After waiting for the set time, read the TBOX log and traverse the fields in the event dependency directed graph. If the ECALL event field, GPS location field, MSD minimum dataset sending field, and TSP handshake response field all exist, the event link semantic verification is considered to have passed; otherwise, it fails.

[0009] In conjunction with the first aspect, in one implementation, the event chain semantic verification further includes: For fields existing in the event-dependent directed graph, verify whether the difference between the timestamp corresponding to the field and the time it was pressed is within a preset range.

[0010] In conjunction with the first aspect, in one implementation method, the integrity test of the abnormal power outage log specifically includes: After the TBOX is powered on and running normally, a continuous event is triggered and the TBOX storage write operation status is monitored. When the TBOX is in write operation mode, the programmable power supply cuts off the main power supply of the TBOX and waits for the first set time before powering the TBOX back on. A script based on the integrity of the TBOX log file is used to verify whether the last complete log record before the TBOX power failure exists and whether there are any garbled characters or truncation issues.

[0011] In conjunction with the first aspect, in one implementation method, The write operation status of the TBOX is identified by IO signals; The TBOX log file integrity check script is used to check the file size, inode status, and last line integrity of the TBOX log.

[0012] In conjunction with the first aspect, in one implementation method, long-term statistical analysis of clock drift specifically includes: The stress test loop is executed a preset number of times, and after each successful power-on and time calibration of the TBOX, the deviation between the timestamp in the TBOX log and the standard time on the host computer is recorded to construct the deviation time series. Linear regression is performed on the deviation time series to fit the drift slope and compare it with a preset threshold to determine whether there is clock drift anomaly in TBOX.

[0013] Secondly, embodiments of this application provide a TBOX log verification device based on GNSS simulation, the TBOX log verification device based on GNSS simulation comprising: A creation module is used to create a TBOX test scenario, which includes a GNSS simulator for switching satellite signal scenarios at preset times, an event dependency directed graph for recording ECALL event dependencies, a programmable power supply for powering the TBOX, and a clock drift statistics program for recording time information in the TBOX log. The execution module is used to perform GNSS simulator linkage log verification, event link semantic verification, abnormal power failure log integrity testing, and long-term clock drift statistical analysis based on the created TBOX test scenario.

[0014] Thirdly, embodiments of this application provide a TBOX log verification device based on GNSS simulation. The TBOX log verification device based on GNSS simulation includes a processor, a memory, and a TBOX log verification program based on GNSS simulation stored in the memory and executable by the processor. When the TBOX log verification program based on GNSS simulation is executed by the processor, it implements the steps of the TBOX log verification method based on GNSS simulation described above.

[0015] The beneficial effects of the technical solutions provided in this application include: It can effectively improve the coverage of GNSS-related TBOX logs, covering major positioning scenarios such as tunnels, weak GPS, and signal recovery; improve the depth of log verification, from single-field matching to multi-node logical link integrity verification, significantly reducing the false negative rate; it has strong repeatability, and power outage scenarios can be accurately reproduced through scripts, eliminating human operation errors; it has high maintainability, and clock drift trend analysis can detect potential hardware hazards in advance, avoiding the accumulation of problems. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the TBOX log verification method based on GNSS simulation proposed in this application. Figure 2 This is a detailed flowchart of the TBOX log verification method based on GNSS simulation in practical application. Figure 3 This is a schematic diagram of the functional modules of the TBOX log verification device based on GNSS simulation in this application; Figure 4 This is a schematic diagram of the hardware structure of the TBOX log verification device based on GNSS simulation in this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] In the first aspect, the embodiments of this application provide a TBOX log verification method based on GNSS simulation, which comprehensively utilizes GNSS signal simulation, programmable power supply control and log link semantic verification and other technical means to achieve full automated verification of the time accuracy, content integrity and system stability of TBOX maintenance logs.

[0020] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the TBOX log verification method based on GNSS simulation proposed in this application. Figure 1 As shown, the TBOX log verification method based on GNSS simulation includes: S1: Create a TBOX test scenario, which includes a GNSS simulator for switching satellite signal scenarios at preset times, an event dependency directed graph for recording ECALL event dependencies, a programmable power supply for powering the TBOX, and a clock drift statistics program for recording time information in the TBOX log. S2: Based on the created TBOX test scenario, perform GNSS simulator linkage log verification, event link semantic verification, abnormal power failure log integrity test, and long-term statistical analysis of clock drift.

[0021] Specifically, a GNSS simulator is used as the hardware trigger source to achieve precise timing control of satellite signal scenarios and multi-dimensional joint verification of logs; an event link semantic verification mechanism based on DAG (Directed Acyclic Graph) is introduced to upgrade the verification from single-field existence matching to multi-event logical link integrity verification; precise power failure testing with write operation awareness is used to simulate abnormal power failures in specific storage stages; and long-term clock drift statistics are used to upgrade single time difference verification to trend quantitative analysis. By comprehensively utilizing GNSS signal simulation, programmable power supply control, and log link semantic verification technologies, a comprehensive automated verification of the time accuracy, content integrity, and system stability of TBOX maintenance logs is achieved.

[0022] Furthermore, in one embodiment, the verification of the GNSS simulator linkage log specifically includes: S201: Power on the TBOX using a programmable power supply and record the power-on time; control the GNSS simulator to output a normal positioning scene; wait for the TBOX log to record a successful positioning event and then record the current time. S202: Control the GNSS simulator to switch to the satellite signal blockage scene in a step-attenuation mode, and record the time when the satellite signal begins to attenuate and the time when the satellite signal is completely blocked. After waiting for a preset time, control the satellite signal to recover with the same advance slope, and record the time when the satellite signal recovery is completed. S203: Read the TBOX log, and based on the recorded time information, as well as the GPS (Global Positioning System) status field, event timestamp, and HDOP (Horizontal Dilution of Precision) value in the TBOX log, determine whether the GNSS simulator linkage log verification passes.

[0023] Specifically, if the GPS status field exists, the HDOP value is invalid during the period when the satellite signal is completely blocked, the difference between the timestamp of the satellite signal loss event and the time when the satellite signal begins to attenuate in the TBOX log file is less than or equal to the first threshold, and the difference between the timestamp of the satellite signal recovery event and the time when the satellite signal recovery is completed in the TBOX log file is less than or equal to the second threshold, then the GNSS simulator linkage log verification is considered to have passed; otherwise, the GNSS simulator linkage log verification is considered to have failed.

[0024] The following is a detailed explanation of the GNSS simulator linkage log verification process.

[0025] The test environment was set up as follows: the TBOX under test was connected to a GNSS simulator (to replace the real satellite signal source), and a programmable power supply and an ADB (Android Debug Bridge) host computer were also connected.

[0026] The script controls the programmable power supply to connect to the TBOX power supply terminal, powering on the TBOX and recording the power-on time T0. After waiting 3 minutes for network setup to complete, the script controls the GNSS simulator to output a normal positioning scenario (number of satellites ≥ 4, HDOP value ≤ 2.0), waiting for the TBOX log to record a successful positioning event, recording the time T1. Then, the script controls the GNSS simulator to switch to a signal obstruction scenario in a step-attenuation manner (i.e., the signal strength decreases step by step at a slope of 1dBm) until the number of satellites = 0 (simulating a tunnel environment), recording the time when the satellite signal begins to attenuate T2 and the time when the satellite signal is completely obstructed T2'. After 30 seconds, the script controls the satellite signal to recover step by step at the same advance slope, recording the time when the satellite signal recovery is complete T3. This step-quantization method more realistically restores the gradual process of a vehicle entering a tunnel compared to the signal abrupt change method, and can verify the continuous recording capability of the TBOX log during the signal gradual change process.

[0027] Then, the script retrieves the TBOX log file via ADB and automatically searches the TBOX log for: GPS status field, verifying field existence; the difference between the satellite signal loss event timestamp and T2 is ≤5s; the difference between the satellite signal recovery event timestamp and T3 is ≤5s; and whether the HDOP value was recorded as an invalid value (e.g., 99.9) during the obstruction phase. If all verifications pass, the test item is considered passed; if any fails, it is marked as a failure and a difference report is output.

[0028] Furthermore, in one embodiment, the event chain semantic verification specifically includes: S211: Define the ECALL event dependency as recording the GPS location field, MSD minimum dataset transmission field, and TSP handshake response field after the ECALL event is triggered; S212: Connect the ECALL button via a relay to simulate the ECALL button being pressed and record the time of pressing; S213: After waiting for the set time, read the TBOX log and traverse the fields in the event dependency directed graph. If the ECALL event field, GPS location field, MSD minimum dataset sending field, and TSP handshake response field all exist, the event link semantic verification is considered to have passed; otherwise, it fails.

[0029] The following provides a detailed explanation of the event chain semantic verification process.

[0030] Based on the GNSS simulator linkage log verification, a new DAG (Directed Acyclic Graph) verification module has been added. The dependencies of the ECALL (Emergency Call in Vehicle) event are defined as follows: ECALL trigger event → {GPS positioning field (latitude and longitude not empty), MSD minimum dataset sending field, TSP (Telematics Service Platform) handshake response field}.

[0031] The script controls the relay to connect to the ECALL button, simulates the button being pressed, records the time of the press (Tecall), and then waits 5 minutes before pulling the log. The script then traverses the DAG, sequentially searching the ECALL event field, GPS location field, MSD minimum dataset transmission field, and TSP handshake response field. If any field is missing, the link is considered incomplete and marked as a failure.

[0032] Furthermore, for event chain semantic verification, it also includes: for fields existing in the event dependency directed graph, verifying whether the difference between the timestamp corresponding to the field and the time of pressing is within a preset range.

[0033] That is, for each existing associated field, verify whether the time difference between its timestamp and Tecall is within a reasonable range (GPS positioning field ≤ 3s, MSD minimum dataset sending field ≤ 10s, TSP handshake response field ≤ 30s).

[0034] Furthermore, in one embodiment, the integrity test of the abnormal power outage log specifically includes: S221: After the TBOX is powered on and running normally, a continuous event is triggered and the write operation status of the TBOX is monitored; the write operation status of the TBOX is identified through IO (Input / Output) signals. S222: When the TBOX storage is in write operation mode, the programmable power supply is cut off to the main power supply of the TBOX, and after waiting for the first set time, the TBOX is powered on again. S223: A script for checking the integrity of the TBOX log file, used to verify the existence of the last complete record in the log file before the TBOX power failure, and to check for garbled characters or truncation. The TBOX log file integrity check script checks the file size, inode (index node) status, and last line integrity of the TBOX log file.

[0035] The following is a detailed explanation of the abnormal power outage log integrity test process.

[0036] After the TBOX is powered on and running normally, a continuous event is triggered (such as a large volume of log writes in a loop). The script monitors the TBOX's write operation status and, during the write operation, controls the programmable power supply to cut off the TBOX's main power supply (simulating an abnormal power outage). After waiting 5 seconds, power is restored, and a TBOX log file integrity check script is executed via ADB connection (checking log file size, inode status, and last line integrity). It verifies the existence of the last complete log record before the power outage and checks for garbled characters or truncation to determine the effectiveness of the log preservation mechanism.

[0037] Furthermore, in one embodiment, long-term statistical analysis of clock drift specifically includes: S231: Perform the stress test loop a preset number of times, and after each successful power-on time calibration of the TBOX, record the deviation between the timestamp in the TBOX log and the standard time of the host computer, and construct the resulting deviation time series; S232: Perform linear regression on the deviation time series, fit the drift slope and compare it with a preset threshold to determine whether there is clock drift anomaly in TBOX.

[0038] The following provides a detailed explanation of the long-term statistical analysis of clock drift.

[0039] In the stress test loop, after each successful power-on calibration of the TBOX, the deviation value δt(n) between the timestamp in the TBOX log and the standard time on the host computer is recorded. After N loops (N≥50 is recommended), a deviation time series {δt(1),δt(2),...,δt(N)} is constructed. Linear regression is performed on the deviation time series to fit the drift slope k (unit: ms / cycle). If k exceeds the preset threshold (±10ms / cycle), the TBOX is automatically marked as having clock drift anomaly, and an alarm report is output.

[0040] See Figure 2The diagram shows a detailed flowchart of the TBOX log verification method based on GNSS simulation in practical application. This application employs precise timing control of the GNSS simulator and multi-dimensional joint verification of the TBOX logs. A script controls the GNSS simulator to switch signal scenarios at preset times, and the switching times are combined with the GPS status field and HDOP value in the log for timestamp and numerical verification. An event-dependent directed graph-based log link semantic verification mechanism is used, defining a dependency graph between the target event and its strongly correlated sub-events, and verifying the co-occurrence integrity of multiple event fields in the TBOX log through graph traversal. A write operation-aware, precise power-off log integrity testing method is adopted, which combines monitoring the TBOX storage write operation status, triggering power-off during specific write phases, and automatically performing file integrity checks after power-on. Long-term quantitative analysis of TBOX clock drift based on time-series linear regression is used, accumulating a time-calibration deviation sequence through multiple iterative tests, and using linear regression to fit the drift trend for anomaly warning.

[0041] The TBOX log verification method based on GNSS simulation in this application can effectively improve the coverage of GNSS-related TBOX logs, covering major positioning scenarios such as tunnels, weak GPS, and signal recovery; it can improve the depth of log verification, from single-field matching to multi-node logical link integrity verification, significantly reducing the false negative rate; it has strong repeatability, and power outage scenarios can be accurately reproduced through scripts, eliminating human operation errors; it has high maintainability, and clock drift trend analysis can detect potential hardware vulnerabilities in advance, avoiding the accumulation of problems.

[0042] Secondly, embodiments of this application also provide a TBOX log verification device based on GNSS simulation.

[0043] In one embodiment, reference is made to Figure 3 , Figure 3 This is a schematic diagram of the functional modules of the TBOX log verification device based on GNSS simulation in this application. Figure 3 As shown, the TBOX log verification device based on GNSS simulation includes: a creation module and an execution module.

[0044] The creation module is used to create TBOX test scenarios. These scenarios include a GNSS simulator for switching satellite signal scenarios at preset times, an event dependency directed graph for recording ECALL event dependencies, a programmable power supply for powering the TBOX, and a clock drift statistics program for recording time information in the TBOX logs. The execution module is used to perform GNSS simulator linkage log verification, event link semantic verification, abnormal power outage log integrity testing, and long-term clock drift statistical analysis based on the created TBOX test scenarios. By comprehensively utilizing GNSS signal simulation, programmable power supply control, and log link semantic verification technologies, the system achieves comprehensive automated verification of the TBOX maintenance log's time accuracy, content integrity, and system stability.

[0045] In one possible implementation, the TBOX log verification device based on GNSS simulation of this application may include a scene triggering module, a log acquisition module, a semantic verification module, and a statistical analysis module in practical applications. The modules work together to realize log generation control, content verification, and long-term behavior analysis.

[0046] For GNSS simulator linkage testing: Introduce a GNSS simulator (or GNSS signal simulator), and use a script to control the GNSS simulator to switch satellite signal scenarios at preset times (normal positioning → signal obstruction → signal recovery), accurately record the signal switching time, and perform joint verification of the timestamp and numerical values ​​with the GPS status field and positioning accuracy parameters (HDOP value) in the TBOX log.

[0047] For event log link semantic verification: Define an event dependency directed graph (DAG) to describe the necessary co-occurrence relationship between the target event and its strongly related sub-events (such as ECALL event → GPS location field + MSD dataset + background handshake signal). During verification, traverse the DAG to verify the integrity of the associated link, rather than just matching a single field.

[0048] For abnormal power outage log integrity testing: The write operation status of TBOX storage is monitored by a programmable power supply. A power outage is triggered at a specific stage in the write operation. After power is restored, the log file integrity check is automatically performed to verify the preservation of critical logs after an illegal shutdown.

[0049] For long-term statistical analysis of clock drift: after each successful time synchronization event, record the deviation between the TBOX time and the standard source, construct a time series, use linear regression to fit the drift trend, and automatically mark potential hardware anomalies when the drift exceeds a preset threshold.

[0050] Thirdly, this application provides a TBOX log verification device based on GNSS simulation. The TBOX log verification device based on GNSS simulation can be a personal computer (PC), laptop computer, server or other device with data processing capabilities.

[0051] Reference Figure 4 , Figure 4 This is a schematic diagram of the hardware structure of the TBOX log verification device based on GNSS simulation involved in the embodiments of this application. In this embodiment, the TBOX log verification device based on GNSS simulation may include a processor, a memory, a communication interface, and a communication bus.

[0052] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0053] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the GNSS-simulated TBOX log verification device, as well as interfaces used for interconnecting the GNSS-simulated TBOX log verification device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0054] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0055] The processor can be a general-purpose processor, which can call the GNSS simulation-based TBOX log verification program stored in memory and execute the GNSS simulation-based TBOX log verification method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the GNSS simulation-based TBOX log verification program is called can be referred to the various embodiments of the GNSS simulation-based TBOX log verification method of this application, and will not be repeated here.

[0056] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0057] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0058] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0059] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0060] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0061] 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 this application, 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 is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0062] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A TBOX log verification method based on GNSS simulation, characterized in that, The TBOX log verification method based on GNSS simulation includes: Create a TBOX test scenario, which includes a GNSS simulator for switching satellite signal scenarios at preset times, an event dependency directed graph for recording ECALL event dependencies, a programmable power supply for powering the TBOX, and a clock drift statistics program for recording time information in the TBOX log. Based on the created TBOX test scenario, we performed GNSS simulator linkage log verification, event link semantic verification, abnormal power failure log integrity testing, and long-term statistical analysis of clock drift.

2. The TBOX log verification method based on GNSS simulation as described in claim 1, characterized in that, For GNSS simulator linkage log verification, the specific requirements include: Power on the TBOX using a programmable power supply and record the power-on time. Control the GNSS simulator to output a normal positioning scene. After waiting for the TBOX log to record the positioning success event, record the current time. Control the GNSS simulator to switch to the satellite signal blockage scene in a step-attenuation mode, and record the time when the satellite signal begins to attenuate and the time when the satellite signal is completely blocked. After waiting for a preset time, control the satellite signal to recover with the same advance slope, and record the time when the satellite signal recovery is completed. Read the TBOX logs and, based on the recorded time information, as well as the GPS status field, event timestamp, and HDOP value in the TBOX logs, determine whether the GNSS simulator linkage log verification passes.

3. The TBOX log verification method based on GNSS simulation as described in claim 2, characterized in that: If the GPS status field exists, the HDOP value is invalid during the period when the satellite signal is completely blocked, the difference between the timestamp of the satellite signal loss event and the time when the satellite signal begins to attenuate in the TBOX log file is less than or equal to the first threshold, and the difference between the timestamp of the satellite signal recovery event and the time when the satellite signal recovery is completed in the TBOX log file is less than or equal to the second threshold, then the GNSS simulator linkage log verification is deemed to have passed. Otherwise, the GNSS simulator linkage log verification is deemed to have failed.

4. The TBOX log verification method based on GNSS simulation as described in claim 1, characterized in that, For event chain semantic verification, the specific components include: Define the ECALL event dependency as follows: after the ECALL event is triggered, record the GPS location field, the MSD minimum dataset transmission field, and the TSP handshake response field. The ECALL button is connected via a relay to simulate being pressed, and the moment of pressing is recorded. After waiting for the set time, read the TBOX log and traverse the fields in the event dependency directed graph. If the ECALL event field, GPS location field, MSD minimum dataset sending field, and TSP handshake response field all exist, the event link semantic verification is considered to have passed; otherwise, it fails.

5. The TBOX log verification method based on GNSS simulation as described in claim 4, characterized in that, For event chain semantic verification, it also includes: For fields existing in the event-dependent directed graph, verify whether the difference between the timestamp corresponding to the field and the time it was pressed is within a preset range.

6. The TBOX log verification method based on GNSS simulation as described in claim 1, characterized in that, The integrity test for abnormal power outage logs specifically includes: After the TBOX is powered on and running normally, a continuous event is triggered and the TBOX storage write operation status is monitored. When the TBOX is in write operation mode, the programmable power supply cuts off the main power supply of the TBOX and waits for the first set time before powering the TBOX back on. A script based on the integrity of the TBOX log file is used to verify whether the last complete log record before the TBOX power failure exists and whether there are any garbled characters or truncation issues.

7. The TBOX log verification method based on GNSS simulation as described in claim 6, characterized in that: The write operation status of the TBOX is identified by IO signals; The TBOX log file integrity check script is used to check the file size, inode status, and last line integrity of the TBOX log.

8. The TBOX log verification method based on GNSS simulation as described in claim 1, characterized in that, Long-term statistical analysis of clock drift specifically includes: The stress test loop is executed a preset number of times, and after each successful power-on and time calibration of the TBOX, the deviation between the timestamp in the TBOX log and the standard time on the host computer is recorded to construct the deviation time series. Linear regression is performed on the deviation time series to fit the drift slope and compare it with a preset threshold to determine whether there is clock drift anomaly in TBOX.

9. A TBOX log verification device based on GNSS simulation, characterized in that, The TBOX log verification device based on GNSS simulation includes: A creation module is used to create a TBOX test scenario, which includes a GNSS simulator for switching satellite signal scenarios at preset times, an event dependency directed graph for recording ECALL event dependencies, a programmable power supply for powering the TBOX, and a clock drift statistics program for recording time information in the TBOX log. The execution module is used to perform GNSS simulator linkage log verification, event link semantic verification, abnormal power failure log integrity testing, and long-term clock drift statistical analysis based on the created TBOX test scenario.

10. A TBOX log verification device based on GNSS simulation, characterized in that, The GNSS-emulated TBOX log verification device includes a processor, a memory, and a GNSS-emulated TBOX log verification program stored in the memory and executable by the processor. When the GNSS-emulated TBOX log verification program is executed by the processor, it implements the steps of the GNSS-emulated TBOX log verification method as described in any one of claims 1 to 8.

Images