Method, device, medium and diagnosis host for diagnosing health degree of connection

Abstract

The application discloses a connection health degree diagnosis method and device, a medium and a diagnosis host, and relates to the technical field of vehicle diagnosis. The method comprises the following steps: collecting physical layer, link layer and application layer state data of a VCI device in real time; performing standardization conversion on the data to obtain standardized state records containing hierarchical identifiers, index names, quantitative values and state markers; scoring each layer index by using a preset multi-level threshold rule set to generate health scores of each layer; performing weighted summation on the health scores of the three layers to obtain an overall connection health degree score and converting the score into a grade; and rendering a visual instrument panel on a graphical user interface of the diagnosis host to display the grade and at least one key index of each layer. The application upgrades the VCI device state from physical LED on-off indication to screen-end multi-layer quantitative visual presentation, thereby improving the safety and efficiency of diagnosis operation.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a diagnostic method, device, medium and diagnostic host for connecting health status. Background Technology

[0002] Mainstream VCI (Vehicle Communication Interface) devices typically use physical LED (Light-Emitting Diode) indicator lights on the device itself to convey its basic operating status to the operator, such as whether the power is on and whether CAN (Controller Area Network) communication has been established.

[0003] However, this method has significant limitations. Physical LEDs can only reflect a binary state of "on" or "off," and cannot quantify the finer parameters that are crucial to the safety and success rate of diagnostic operations, such as power supply voltage and signal strength. When performing diagnostic tasks, especially during high-risk operations such as ECU flashing, technicians have to frequently shift their gaze from the diagnostic host screen to the VCI device itself located at the vehicle's OBD (On-Board Diagnostics) interface to check the connection status of the VCI device. This process not only seriously distracts the operator and directly affects operational efficiency, but also poses a safety risk of interrupting the flashing process or even damaging the ECU (Electronic Control Unit) due to failure to detect power supply or communication problems in time. Summary of the Invention

[0004] This application provides a method, apparatus, medium, and diagnostic host for connecting to health status, which can solve the technical problems of low operational efficiency and safety risks in the prior art when performing diagnostic operations. The technical solution is as follows: In a first aspect, embodiments of this application provide a method for diagnosing connection health, the method comprising: Real-time acquisition of physical layer status data, link layer status data, and application layer status data of the VCI device; The physical layer state data, the link layer state data, and the application layer state data are standardized and transformed to obtain standardized state records. The standardized state records contain layer identifiers, indicator names, quantified values, and state markers. Using a preset multi-level threshold rule set, scores are applied to various indicators in the standardized state record to generate physical layer health scores, link layer health scores, and application layer health scores. The physical layer health score, the link layer health score, and the application layer health score are weighted and summed to obtain an overall connection health score, and the overall connection health score is converted into an overall connection health level according to a preset level mapping rule. A visual dashboard is rendered on the graphical user interface of the diagnostic host. The visualization dashboard is used to display the overall connectivity health level, as well as at least one key indicator of the physical layer status data, the link layer status data, and the application layer status data.

[0005] Secondly, embodiments of this application provide a diagnostic device for connecting to health status, the device comprising: The acquisition module is used to acquire physical layer status data, link layer status data and application layer status data of the VCI device in real time; The conversion module is used to standardize and convert the physical layer state data, the link layer state data and the application layer state data to obtain a standardized state record. The standardized state record includes a layer identifier, an indicator name, a quantified value and a state marker. The scoring module is used to score various indicators in the standardized status record using a preset multi-level threshold rule set, and generate physical layer health score, link layer health score and application layer health score. The grading module is used to perform a weighted summation of the physical layer health score, the link layer health score, and the application layer health score to obtain an overall connection health score, and convert the overall connection health score into an overall connection health level according to a preset level mapping rule. A rendering module is used to render a visual dashboard on the graphical user interface of the diagnostic host. The visualization dashboard is used to display the overall connectivity health level, as well as at least one key indicator of the physical layer status data, the link layer status data, and the application layer status data.

[0006] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0007] Fourthly, embodiments of this application provide a diagnostic host, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0008] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: By collecting physical layer status data, link layer status data, and application layer status data of VCI devices in real time, the status perception range of VCI devices is expanded from a single electrical on / off state to a multi-dimensional state covering power quality, communication channels, and diagnostic protocols. This enables the comprehensive acquisition of fine parameters that were previously invisible to operators, solving the technical problem that multi-layer status information of VCI devices cannot be quantitatively perceived in existing technologies.

[0009] By standardizing heterogeneous state data, standardized state records with a unified structure are generated, enabling raw data from different sources and in different formats to be aggregated under the same evaluation framework for processing, thus laying the data foundation for automated scoring and visualization.

[0010] The system uses a pre-set multi-level threshold rule set to score various indicators and weights and aggregates the three-level health scores into an overall connection health score and level. This integrates scattered multi-dimensional status information into an intuitive comprehensive health index, allowing operators to quickly grasp the overall connection quality between the VCI device and the vehicle with a single value and level without having to understand and judge the meaning of the independent parameters at each level.

[0011] The graphical user interface of the diagnostic host renders a visual dashboard, transforming the original operation mode of having to look down at the VCI device itself into a real-time health status display that can be obtained on the main screen of the diagnostic host. This reduces the frequency of operators switching their gaze between the main screen of the diagnostic host and the VCI device itself, improving the continuity and safety of the diagnostic operation.

[0012] In summary, this application upgrades the status indication of VCI devices from vague physical LED on / off states to precise multi-layered quantitative visualization on the screen, reducing the possibility of operators misjudging the connection status of VCI devices and providing an objective basis for the usability of subsequent dynamic control diagnostic operations. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application 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 only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a schematic diagram of the system architecture provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a diagnostic method for connecting health status provided in an embodiment of this application; Figure 3This is a flowchart illustrating a data acquisition method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a diagnostic device for connecting to health status provided in this application; Figure 5 This is a schematic diagram of a computer storage medium provided in this application; Figure 6 This is a schematic diagram of the structure of a diagnostic host provided in this application. Detailed Implementation

[0015] 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.

[0016] It should be noted that the connection health diagnostic method provided in this application is generally executed by the diagnostic host, and correspondingly, the connection health diagnostic device is generally set in the diagnostic host.

[0017] Figure 1 An exemplary system architecture is shown that can be applied to a diagnostic method for connectivity health or a processing apparatus for automotive diagnostic data, which is applicable to this application.

[0018] like Figure 1 As shown, the system architecture may include: a diagnostic host 100, a VCI device 101, and a vehicle 102.

[0019] The diagnostic host 100 can be a ruggedized tablet computer running diagnostic software applications, possessing graphical user interface display capabilities, wireless communication capabilities, and data processing capabilities. The diagnostic host 100 is used to execute all the steps of the method described in this invention, including but not limited to: real-time acquisition of status data of each layer of VCI device 101, standardization and health scoring of the data, calculation of overall connectivity health score and level, rendering of a visual dashboard, and dynamic control of the availability of diagnostic functions based on the health level.

[0020] VCI device 101 serves as an intermediate bridge connecting the diagnostic host 100 and the vehicle 102. Specifically, VCI device 101 is a wireless diagnostic interface device supporting the DoIP protocol. One end establishes a communication connection with the diagnostic host 100 via a Bluetooth wireless channel, while the other end is physically inserted into and electrically connected to the OBD diagnostic port of the vehicle 102 via a standard OBD-II interface. VCI device 101 is responsible for executing diagnostic commands issued by the diagnostic host 100, converting the commands into bus signals recognizable by the vehicle 102 and sending them to the vehicle 102. Simultaneously, it receives diagnostic response data returned by the vehicle 102 and transmits it back to the diagnostic host 100. Furthermore, VCI device 101 incorporates an analog-to-digital converter and various sensors, enabling it to collect physical layer status data such as its OBD interface power supply voltage, device power supply current, and casing temperature. It also provides link layer status data such as Bluetooth RSSI (Received Signal Strength Indication) values ​​via a wireless module.

[0021] Vehicle 102 is the target object to be diagnosed. For example, vehicle 102 is specifically a new energy pure electric SUV that supports the UDS diagnostic protocol. Vehicle 102 is equipped with multiple electronic control units, including but not limited to the engine ECU, battery management system (BMS), and body control module (BCM). Vehicle 102 establishes an electrical connection with VCI device 101 through its OBD diagnostic connector. Each ECU is connected to the corresponding pin of the OBD diagnostic connector through the in-vehicle CAN bus network to receive diagnostic requests and return diagnostic responses.

[0022] exist Figure 1 In this system, the connection between the diagnostic host 100 and the VCI device 101 represents the Bluetooth wireless bidirectional communication channel established between them, while the connection between the VCI device 101 and the vehicle 102 represents the electrical connection and CAN bus communication channel established between them via the OBD-II interface. During system operation, data flows from the vehicle 102 to the diagnostic host 100 via the VCI device 101, and diagnostic commands are sent from the diagnostic host 100 to the vehicle 102 via the VCI device 101, forming a complete diagnostic communication loop.

[0023] It should be understood that Figure 1 The number of diagnostic hosts, networks, and servers shown is for illustrative purposes only. The number of diagnostic hosts, networks, and servers can be any number, depending on implementation needs.

[0024] The following will be combined with the appendix Figure 2This application provides a detailed description of the connection health diagnostic method provided in its embodiments. The connection health diagnostic device in these embodiments can be... Figure 1 The diagnostic host shown.

[0025] Please see Figure 2 This is a flowchart illustrating a diagnostic method for linking health status, as provided in an embodiment of this application. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. Real-time acquisition of physical layer status data, link layer status data, and application layer status data of VCI devices.

[0026] Among them, the physical layer status data represents the electrical and physical connection characteristics of the VCI device, the link layer status data represents the communication channel quality of the VCI device, and the application layer status data represents the status of the diagnostic service protocol currently carried by the VCI device.

[0027] S2. Standardize and transform the physical layer state data, link layer state data, and application layer state data to obtain standardized state records. The standardized state records contain layer identifiers, indicator names, quantified values, and state markers.

[0028] The hierarchy identifier is a classification label indicating whether the data originates from the physical layer, link layer, or application layer. The indicator name specifically identifies the collected status parameter (such as "voltage" or "Bluetooth RSSI"). The quantified value is a precise measurement value after unit standardization and validity verification. The status label is a descriptive label (such as "normal," "warning," or "abnormal") generated after qualitatively evaluating the quantified value based on preset thresholds. The status label is used to perform coarse-grained, general health status qualitative analysis of the raw data, mainly for quick and intuitive interface rendering such as dashboard card background colors.

[0029] S3. Using a preset multi-level threshold rule set, score the various indicators in the standardized status record to generate physical layer health score, link layer health score and application layer health score.

[0030] The multi-level threshold rule set is a pre-defined rule system containing multiple threshold boundaries used to convert quantified values ​​into scores. This application does not set a simple "good / bad" judgment point for a single indicator, but rather sets at least two threshold boundaries, thereby dividing the data into three or more intervals. For example, instead of simply stating "voltage < 12V is abnormal," it defines rules such as "voltage ≥ 12V scores 100 points," "11V ≤ voltage < 12V scores 60 points," and "voltage < 11V scores 0 points." The multi-level threshold rule set allows different numerical ranges of the same indicator to be mapped to different scoring intervals and corresponding status labels (normal / warning / abnormal), achieving a refined and continuous quantitative evaluation of the connection status, rather than simply performing a binary judgment of continuity.

[0031] Optionally, in response to a decrease in the physical layer health score, the weight coefficient of at least one indicator in the link layer health score is dynamically adjusted; or when both the physical layer status data and the link layer status data show abnormal status markers, a coupling risk alarm of a higher level than that of a single abnormality is generated.

[0032] S4. The physical layer health score, link layer health score, and application layer health score are weighted and summed to obtain the overall connection health score. Then, according to a preset level mapping rule, the overall connection health score is converted into an overall connection health level. Connection health is a composite indicator used to quantitatively evaluate the overall quality of the end-to-end connection between VCI devices and vehicles. It integrates real-time status information from multiple dimensions, including physical and electrical characteristics, communication channel quality, and diagnostic protocol status.

[0033] S5. Render a visual dashboard on the graphical user interface of the diagnostic host.

[0034] The visualization dashboard displays the overall connectivity health level, as well as at least one key indicator from the physical layer, link layer, and application layer status data. The diagnostic host invokes the graphics rendering engine to draw a visualization dashboard in the upper right corner of the screen.

[0035] For example, the dashboard displays a pie chart in the center, with most of its arc filled in green. The core indicator "Overall Connection Health Score: 88" is prominently displayed in the center. Around the pie chart are three cards labeled "Physical Layer," "Link Layer," and "Application Layer," dynamically displaying at least one preset key indicator from the physical layer, link layer, and application layer status data read from the standardized status record in step S2. For example, the physical layer card displays the key indicator "Power Supply Voltage," with a quantized value of "13.7" in "V." The link layer card displays the key indicator "Bluetooth RSSI," with a quantized value of "-55" in "dBm." The application layer card displays the key indicator "Security Access Status," with a value of "Default Status."

[0036] Optionally, the time series data of the key indicator is input into the trend prediction model to obtain the predicted value of the key indicator in a preset future time period; when the predicted value triggers an alarm or abnormal interval in the multi-level threshold rule set, a predictive alarm message is generated, and the predicted trend line and alarm prompt are displayed on the visualization dashboard.

[0037] In an optional implementation, see Figure 3 , Figure 3 This is a flowchart illustrating the data acquisition method provided in an embodiment of this application, which specifically includes the following steps: S11. Load the acquisition configuration file corresponding to the VCI device model. The acquisition configuration file is used to configure the indicators to be acquired and the reading instructions corresponding to each indicator.

[0038] When the diagnostic host identifies the currently connected VCI device model as "VCI-DoIP-Pro", it retrieves and loads a data acquisition configuration file named "VCI-DoIP-Pro_config.xml" from its locally stored configuration library. This XML configuration file specifies the metrics to be acquired and the corresponding read commands for each metric. For example, the file defines a metric "OBD interface power supply voltage," whose read command is obtained through the API (Application Programming Interface) interface "getADCValue(PIN_16)"; a metric "Bluetooth RSSI value," whose read command is to call the system function "getBluetoothRSSI()"; and a metric "current ECU session mode," which is read by continuously listening to and parsing UDS diagnostic response messages.

[0039] S12. During the diagnostic session, physical layer status data is obtained through the built-in analog-to-digital converter or corresponding API interface of the VCI device according to the first acquisition cycle.

[0040] After the diagnostic session is established, the diagnostic host, according to the definition in the acquisition configuration file, acquires physical layer status data by calling the corresponding API interface provided by the VCI device according to the first acquisition cycle (e.g., set to once every 500 milliseconds). The acquisition process is as follows: calling the getADCValue(PIN_16) interface, the VCI device measures the voltage of pin 16 of the OBD interface through its built-in analog-to-digital converter and returns the current OBD interface supply voltage value as 13.7V. Calling the getCurrentConsumption() interface, the device supply current is obtained as 250mA. Calling the getTemperature() interface, the case temperature is obtained as 42℃. Thus, the physical layer status data obtained in this round of acquisition reflects the current electrical and physical connection characteristics of the VCI device.

[0041] S13. During the diagnostic session, according to the second acquisition cycle, send a link layer query command to the VCI device or listen to specific network packets to obtain link layer status data.

[0042] The diagnostic host acquires link layer status data according to the second acquisition cycle (e.g., set to once every 2 seconds). This data includes: Bluetooth RSSI value, WiFi signal-to-noise ratio, DoIP (Diagnostics over Internet Protocol) session identifier, link round-trip time, and CAN bus load rate. The acquisition method varies depending on the metrics. For the Bluetooth RSSI value, the diagnostic host directly calls the Bluetooth management interface provided by the operating system to query the signal strength of the current Bluetooth connection with the VCI device, and the returned value is -55dBm.

[0043] For DoIP session identification and link round-trip time, the diagnostic host listens for specific network packets. It captures the DoIP header between the VCI device and the vehicle ECU on the defined DoIP communication port, and parses out the active DoIP session identifier (e.g., 0x0A1B). At the same time, by sending an Echo request message and timing the time difference between receiving the response, it calculates the link round-trip time to be 3ms.

[0044] For CAN bus load rate, the diagnostic host obtains it by sending a link-layer query command to the VCI device. The command is a UDS (Unified Diagnostic Services) confidential service request, and the VCI device returns its current measured CAN bus load percentage, such as 35%.

[0045] If querying the CAN bus load rate from the VCI device fails or returns no result, this indicator will be skipped or its status will be marked as unknown during this standardization conversion. It will also be displayed as N / A or not displayed at the corresponding position on the visualization dashboard. Furthermore, the weights of the remaining indicators will be dynamically adjusted when calculating the link layer health score.

[0046] S14. During the diagnostic session, continuously listen for diagnostic response messages from the VCI device or vehicle ECU, and extract the current ECU session mode and security access unlock status from the diagnostic response messages.

[0047] Unlike periodic data collection, the diagnostic host employs continuous monitoring for application layer protocol status. During the diagnostic session, the host monitors all diagnostic response messages from VCI devices or vehicle ECUs. When a vehicle ECU responds to the diagnostic host's "read data" request, its response message contains session mode information. The diagnostic host extracts the current ECU session mode as "default session" (0x01) from the corresponding bytes of this message. Simultaneously, the diagnostic host tracks the interaction sequence of the secure access process, analyzing the request seed and key transmission messages to determine the current secure access unlock status as "locked." This information is recorded as the application layer status data at the current moment.

[0048] S15. After the write task is triggered, obtain the write progress information, which represents the ratio of the current write block number to the total number of blocks, by subscribing to events or periodically querying.

[0049] The application layer status data includes: the current ECU session mode, secure access unlock status, and flashing progress information. When a technician initiates a flashing task for the engine ECU on the diagnostic host, a "flashing in progress" event is triggered. In response, the diagnostic host registers progress update notifications with the VCI device by subscribing to events. Subsequently, the VCI device actively pushes a progress event to the diagnostic host each time it successfully transmits and verifies a data block. The diagnostic host parses this event to obtain flashing progress information representing the ratio of the current flashing block number to the total number of blocks; for example, the current progress is "block 5 / total blocks 20", which is 25%.

[0050] In an optional implementation, S2, the physical layer state data, link layer state data, and application layer state data are standardized to obtain standardized state records, including: S21. Label the collected raw data of each layer with the layer labels of physical layer, link layer or application layer according to the source.

[0051] The diagnostic host first categorizes each piece of raw data by source. OBD interface power supply voltage "13.7", device power supply current "250", and casing temperature "42" read from the VCI device's built-in analog-to-digital converter are all tagged with physical layer level labels. Data such as "-55" obtained through Bluetooth interface queries and "3" obtained by listening to DoIP messages are tagged with link layer level labels. "Default session" and "locked" extracted from diagnostic response messages are tagged with application layer level labels.

[0052] S22. Convert analog quantities with different physical units to a preset standard unit system.

[0053] The diagnostic host reads its preset standard unit configuration file, which specifies that the standard unit for voltage is "V", the standard unit for current is "mA", the standard unit for temperature is "℃", the standard unit for signal strength is "dBm", and the standard unit for latency is "ms". The diagnostic host then performs conversions for analog quantities with unit differences. For example, if the device supply current in the original physical layer status data is reported by the VCI device in "A" and the value is "0.25", then according to the conversion rule "1A=1000mA", it is converted to a quantized value of "250", with the corresponding unified unit being "mA". Similarly, if the casing temperature is reported in Fahrenheit, it will be converted to Celsius.

[0054] S23. Perform validity checks on numerical indicators and remove invalid data. Invalid data includes data whose values ​​exceed the preset physical feasible range or data whose values ​​remain constant within a preset number of consecutive data collections.

[0055] The diagnostic host performs validity checks on each numerical indicator. First, it checks if the value exceeds a preset physical feasible range. For example, the configuration file defines the physical feasible range for "OBD interface power supply voltage" as 0V to 26V. If a voltage value of "32.5" is collected, it is considered invalid data and is discarded. Second, the diagnostic host maintains a sliding window counter to detect data acquisition deadlock. The rule is: if an indicator's value remains constant within a preset number of consecutive acquisitions (e.g., the same value in 10 consecutive acquisitions), and the indicator is not a constant value signal, it is determined to be invalid data caused by sensor lag and is discarded. In this embodiment, all current values ​​have passed the check and are confirmed as valid. For dynamic indicators that are not constant values, if the value remains constant within a preset number of consecutive acquisitions, it is determined to be invalid data caused by sensor lag and is discarded.

[0056] S24. Based on the pre-set three-level threshold ranges of normal, warning, and abnormal for each indicator, add a status flag field to each valid data point. The value of the status flag field corresponds to the threshold range.

[0057] The diagnostic host loads a pre-defined three-level threshold range table for each indicator, categorized as normal, warning, and abnormal. Taking "OBD interface power supply voltage" as an example, its three-level threshold range is defined as follows: ≥12.0V and ≤14.5V is "normal"; ≥11.0V and ≤12.0V, or ≥14.5V and ≤16.0V is "warning"; ≤11.0V or ≥16.0V is "abnormal". The current quantized power supply voltage is 13.7V, falling within the "normal" range. Therefore, the diagnostic host adds a status flag field to this valid data point, with a value of "normal". Similarly, for the quantized value of the Bluetooth RSSI value "-55", based on its corresponding threshold range (≥-70dBm is normal), a status flag field is added with a value of "normal".

[0058] S25. Encapsulate the processed indicator name, quantified value, unified unit, hierarchical label, and status marker fields into a structured data object as a standardized status record.

[0059] The diagnostic host assembles the elements obtained from the above steps. For the OBD interface power supply voltage indicator, the assembly process is as follows: Take the indicator name "voltage", the quantized value "13.7" after conversion in step S22 and verification in step S23, the unit "V" after unification in step S22, the hierarchical label "physical" marked in step S21, and the status label field "normal" generated in step S24. These elements are then encapsulated into a structured data object according to a predefined structural template, generating a standardized status record in JSON format as follows: json { "layer":"physical", "metric":"voltage", "value": 13.7, "unit":"V", "status":"normal" }

[0060] Similarly, another standardized state record is generated for the Bluetooth RSSI value at the link layer. At this point, all valid raw data collected in step S1 has been converted into standardized state records with the same structure, which can be directly used for health scoring in the subsequent step S3.

[0061] In an optional implementation, S3, a preset multi-level threshold rule set is invoked to score various indicators in the standardized state record, generating a physical layer health score, a link layer health score, and an application layer health score, including: Step S31: Read the matching threshold configuration table from the preset multi-level threshold rule set according to the type of diagnostic task currently being executed.

[0062] The diagnostic host first identifies the type of diagnostic task initiated by the current user. Different diagnostic tasks have varying sensitivities to the states of different layers of the VCI device; therefore, the system pre-sets multiple threshold configuration tables, each corresponding to a different diagnostic task type. Based on the identified task type, the diagnostic host retrieves and loads the matching threshold configuration table from the pre-set multi-level threshold rule set. The core function of the threshold configuration table is to define a refined quantitative evaluation standard for each metric input from S2. Specifically, it sets at least two threshold boundaries for each metric, thereby dividing the continuous numerical range of the metric into three or more discrete scoring intervals. The multi-level threshold rule set can be dynamically adjusted, and its threshold boundaries can be adaptively optimized based on historical statistical data. Alternatively, the multi-level threshold rule set can be a pre-trained classification model that outputs a score upon inputting metric values. Or, the multi-level threshold rule set can be a pre-set threshold configuration table containing at least two threshold boundaries, matched according to the current diagnostic task type.

[0063] For example, if the current diagnostic task is "engine ECU flashing," the diagnostic host will read a threshold configuration table named "threshold_flashing" from a preset multi-level threshold rule set. This table defines three threshold cutoff points for the "OBD interface power supply voltage" indicator: 12.5V, 12.0V, and 11.0V, thus dividing the system into four corresponding scoring ranges: a safe flashing range of 100 points (voltage ≥ 12.5V); a warning range of 80 points (12.0V ≤ voltage < 12.5V); a high-risk range of 40 points (11.0V ≤ voltage < 12.0V); and an absolute danger range of 0 points (voltage < 11.0V). In contrast, if the current task is "reading fault codes," the system will load another threshold configuration table, "threshold_readDTC," which has relatively more lenient voltage requirements.

[0064] Optionally, during a preset learning period after the diagnostic session is established, the physical layer status data, link layer status data, and application layer status data are collected, and the steady-state baseline values ​​of key indicators for each layer are calculated; the threshold boundary points in the multi-level threshold rule set are adaptively offset and adjusted according to the steady-state baseline values.

[0065] In this process, once the diagnostic host successfully establishes diagnostic communication with the vehicle's ECU and determines that no high-risk diagnostic operations (such as flashing or coding) are currently being performed, it initiates a preset learning period, for example, set to 60 seconds. During this learning period, the diagnostic host continuously collects physical layer, data link layer, and application layer status data according to the predetermined collection cycle in step S1. To avoid learning instantaneous abnormal fluctuations, it is preferable to collect only valid data points marked as "normal" in the status flag field in step S2 during the learning period. For example, multiple normal values ​​of the key physical layer indicator "OBD interface power supply voltage" collected during the learning period are stored in a rolling buffer.

[0066] After the learning period ends, the diagnostic host performs statistical calculations on the values ​​of each key indicator within the buffer to obtain a characterization of that indicator in the current VCI. The baseline value of the normal steady-state level under the vehicle combination. The calculation method can be at least one of the following: Calculate the arithmetic mean of all valid values ​​as the steady-state baseline value; Median or truncated mean is used to eliminate the interference of a few marginal values ​​and improve the robustness of the baseline; For indicators with very small fluctuation ranges (such as power supply voltage), the last collected value is directly used as the baseline.

[0067] The diagnostic host reads the steady-state baseline values ​​of key indicators at each level obtained from the calculation, and shifts the threshold boundary points corresponding to the original multi-level threshold rule set around the baseline values, instead of using fixed absolute values. The shift rule is as follows: The difference between each threshold boundary point in the original threshold configuration table and an original reference benchmark value (usually a standard or ideal value agreed upon by the manufacturer) remains unchanged; The original reference values ​​are replaced with the learned steady-state baseline values, thereby generating a personalized threshold table for the current connectivity environment.

[0068] Step S32: Traverse each indicator in the standardized state record, and determine the individual indicator score based on the scoring range in which the value of the indicator falls.

[0069] After loading the threshold configuration table matching the current task, the diagnostic host begins processing all standardized status records one by one. This is a traversal process, retrieving each record sequentially and reading its "metric" (metric name) and "value" (quantified value) fields. Then, it searches the threshold configuration table for the scoring rule corresponding to the metric name, determines which scoring interval defined by the threshold boundary falls into, and finally determines the score corresponding to that scoring interval as the individual metric score. For metrics not defined in the threshold configuration table, the system can either ignore them or assign them a default maximum score.

[0070] For example, taking a standardized state record from the physical layer as an example, its indicator name is "voltage," and its quantized value is "13.7." The diagnostic host looks up the scoring rules for "voltage" in the threshold configuration table "threshold_flashing." Since 13.7V falls within the scoring range of "voltage ≥ 12.5V," the individual indicator score for this metric is determined to be 100 points. Next, the link layer record is processed, with the indicator name "rssi" and its quantized value "-55." The scoring range for "rssi" in the threshold configuration table is: ≥ -70dBm = 100 points, -80dBm≤rssi<-70dBm = 60 points, <-80dBm = 30 points. -55 falls into the first range, therefore the individual indicator score for this metric is 100 points.

[0071] Step S33: Read the preset intra-layer weight configuration file and obtain the weight coefficients corresponding to various indicators in the physical layer, link layer and application layer.

[0072] After obtaining the individual score for each indicator, the diagnostic host aggregates these scattered scores into a comprehensive score for each layer. Since different indicators within the same layer contribute differently to the overall health of that layer, the system pre-defines a layer-specific weight configuration file. This file numerically specifies the weight proportion of each indicator contained within the physical layer, link layer, and application layer when calculating the layer score; the sum of all weight coefficients within the same layer is typically 1.

[0073] For example, the diagnostic host reads the preset in-layer weight configuration file and obtains the weight coefficient configurations for various indicators within the physical layer as follows: the "OBD interface power supply voltage" indicator is assigned a weight coefficient of 0.6 due to its criticality; the "device power supply current" indicator is assigned a weight coefficient of 0.2; and the "casing temperature" indicator is assigned a weight coefficient of 0.2. Similarly, the weight configuration for the link layer might be: "Bluetooth RSSI value" weight 0.4, "DoIP session round-trip latency" weight 0.3, and "CAN bus load rate" weight 0.3. Each indicator within the application layer also has its own defined weight coefficient.

[0074] Step S34: For each layer, sum the scores of all individual indicators within that layer with their corresponding weight coefficients to obtain the physical layer health score, link layer health score, and application layer health score, respectively.

[0075] The diagnostic host performs weighted summation operations layer by layer. Specifically, for each layer, it iterates through each indicator, extracts the individual indicator score determined in step S32 and the weight coefficient read in step S33, and multiplies the two to obtain the weighted score for that indicator. Then, it sums the weighted scores of all indicators within that layer, and the resulting total is the health score for that layer. This process is performed independently for the physical layer, data link layer, and application layer, ultimately generating physical layer health scores, data link layer health scores, and application layer health scores.

[0076] For example, taking the physical layer as an example, the diagnostic host performs the following calculations: The score for a single indicator is: "OBD interface power supply voltage" is 100 points, with a weighting coefficient of 0.6, and the weighted score is 100 × 0.6 = 60. The score for a single indicator is 90 points for "Equipment Power Supply Current". Its weighting coefficient is 0.2, and the weighted score is 90 × 0.2 = 18. The score for a single indicator is: "Outer shell temperature" is 85 points, with a weighting coefficient of 0.2. The weighted score is 85 × 0.2 = 17.

[0077] Summing the weighted scores: 60 + 18 + 17 = 95 points. Therefore, the physical layer health score generated in this embodiment is 95 points. The link layer health score is calculated using the same method, yielding 92 points, and the application layer health score is 80 points.

[0078] In an optional implementation, S4, the physical layer health score, link layer health score, and application layer health score are weighted and summed to obtain an overall connection health score, and the overall connection health score is converted into an overall connection health level according to a preset level mapping rule, including: Step S41: Based on the type of diagnostic task currently being performed, select a set of inter-layer weight coefficients that match the type of diagnostic task from a set of preset inter-layer weight coefficients.

[0079] The diagnostic host first reads the identifier of the currently executing diagnostic task type. Since different diagnostic tasks have varying degrees of dependence on the state of each layer, multiple sets of inter-layer weight coefficients are preset, each corresponding to one or a class of diagnostic task types. Based on the identified task type, the diagnostic host searches and matches these preset sets of inter-layer weight coefficients, loading the corresponding set. This set of coefficients is used in subsequent calculations to determine the contribution ratio of the physical layer, link layer, and application layer to the overall connection health score.

[0080] For example, the diagnostic host identifies the current diagnostic task type as "engine ECU flashing". Because flashing operations require extremely stable power supply voltage, a power outage can brick the ECU. Therefore, the system presets a higher weighting coefficient for "flashing" tasks, with the physical layer weight at 0.5, the link layer weight at 0.3, and the application layer weight at 0.2. In contrast, if the current task is "reading fault codes", the system loads a different set of weights, with a higher application layer weight and a relatively lower physical layer weight. After this step, the diagnostic host obtains a set of inter-layer weighting coefficients matching the current task: (physical layer weight = 0.5, link layer weight = 0.3, application layer weight = 0.2).

[0081] Step S42: Multiply the physical layer health score by the physical layer weight in the selected inter-layer weight coefficient, multiply the link layer health score by the link layer weight, multiply the application layer health score by the application layer weight, and add the three products together to obtain the overall connection health score.

[0082] The diagnostic host performs a weighted summation operation. Specifically, it retrieves the physical layer health score generated in step S3 and multiplies it by the physical layer weight in the inter-layer weight coefficients selected in step S41; it retrieves the link layer health score and multiplies it by the link layer weight; and it retrieves the application layer health score and multiplies it by the application layer weight. These three products are then added together, and the sum is the overall connection health score.

[0083] For example, the diagnostic host performs the following calculations: Physical layer health score 95 points × physical layer weight 0.5 = 47.5.

[0084] Link layer health score 92 points × link layer weight 0.3 = 27.6.

[0085] Application layer health score 80 points × application layer weight 0.2 = 16.0 Adding the three products together: 47.5 + 27.6 + 16.0 = 91.1 points. Therefore, the overall connectivity health score calculated in this round is 91.1 points.

[0086] Step S43: Read the preset level mapping table. The level mapping table stores multiple consecutive and non-overlapping score ranges. Each score range uniquely corresponds to an overall connection health level.

[0087] After obtaining the overall connectivity health score, the diagnostic host needs to convert it into discrete levels that are easier for users to understand. To do this, the diagnostic host reads a pre-defined level mapping table. This table stores multiple consecutive and non-overlapping score ranges, covering the entire range from 0 to 100, and each score range uniquely corresponds to an overall connectivity health level. The overall connectivity health levels include at least green, yellow, and red levels.

[0088] For example, the contents of the preset level mapping table read by the diagnostic host are as follows: The score range corresponds to the overall connectivity health level.

[0089] 80 points ≤ score ≤ 100 points - Green level.

[0090] 60 points ≤ score < 80 points - Yellow level.

[0091] 0 points ≤ score < 60 points - Red level.

[0092] Each score range in the table above is a continuous range with no overlap between adjacent ranges, ensuring that any possible overall connectivity health score can be uniquely mapped to an overall connectivity health level.

[0093] Step S44: Match the overall connection health score with the score range in the level mapping table to determine the score range to which the overall connection health score belongs, and obtain the corresponding overall connection health level.

[0094] In this process, the diagnostic host compares the overall connection health score calculated in step S42 with each score interval in the level mapping table read in step S43. It determines which score interval the score falls into, and then reads the overall connection health level corresponding to that score interval as the output result.

[0095] For example, the overall connection health score calculated in step S42 is 91.1. The diagnostic host matches this score with the rating mapping table: 91.1 falls within the score range of "80 ≤ score ≤ 100". Therefore, the diagnostic host assigns the overall connection health rating corresponding to this score range as "green level".

[0096] Step S45: In the process of determining the overall connection health level, check whether any of the physical layer health score, link layer health score and application layer health score is lower than the preset extremely high risk threshold. If so, force the overall connection health level to be set to the lowest level that indicates connection danger, and generate a forced downgrade flag. The forced downgrade flag is used to indicate that the current level cannot be recovered by improving the scores of other layers.

[0097] This step is a hard security check mechanism independent of score calculation. Its execution can be performed in parallel with the score matching in step S44, or before or after the score matching. The diagnostic host reads a preset extremely high risk threshold for each layer. This extremely high risk threshold indicates that regardless of how well other layers perform, if the health score of any layer is below this threshold, it indicates an unacceptable connection risk. The diagnostic host checks the generated physical layer health score, link layer health score, and application layer health score one by one to determine if any layer's health score is below its corresponding preset extremely high risk threshold. If the check result is yes, then regardless of the scores and levels calculated in steps S42 to S44, the overall connection health level is forcibly set to the lowest level representing connection danger in the system, and a forced degradation flag is generated. This forced degradation flag indicates that the current level is a result of triggering a single-layer absolute danger condition and cannot be recovered by improving the scores of other layers until the score of the dangerous layer rises back above the extremely high risk threshold.

[0098] For example, the preset extremely high risk thresholds are: Physical Layer 30 points, Link Layer 30 points, and Application Layer 30 points. The diagnostic host checks the health scores of these three layers: Physical health score: 95 points, above the extremely high risk threshold of 30 points, passed the examination.

[0099] Link layer health score: 92 points, which is above the extremely high risk threshold of 30 points. Passed the inspection.

[0100] Application layer health score: 80 points, which is above the extremely high risk threshold of 30 points. Passed the inspection.

[0101] Upon inspection, all three health scores were found to be no lower than their respective preset extremely high risk thresholds, therefore the forced downgrade mechanism was not triggered, and the "green level" determined in step S44 remained unchanged.

[0102] For example, during a diagnostic test, if a sudden drop in power supply voltage occurs due to poor contact at the VCI device's OBD interface, causing the physical layer health score to fall to 25 points, while the link layer and application layer remain above 90 points, then step S45 will find that the physical layer health score (25 points) is below the preset extremely high risk threshold (30 points). The diagnostic host will immediately trigger a forced degradation mechanism, forcibly setting the overall connection health level to the lowest level indicating connection danger, i.e., the "red level," and generating a forced degradation marker. This forced degradation marker will be sent to the visualization dashboard along with the level to indicate to the user that the current red level is caused by an extremely high risk state of the physical layer, which cannot be changed even if the link layer and application layer are in good condition, and the physical layer problem must be addressed first.

[0103] In one optional implementation, the following definitions and configurations are pre-defined in the diagnostic host: First, risk level classifications for executable operations were predefined. Operations involving modification of the vehicle's ECU internal program or configuration were categorized as high-risk, specifically including: flashing operations, coding operations, and anti-theft matching operations. Meanwhile, operations involving only data reading without modifying the ECU were categorized as low-risk, specifically including: reading fault codes and real-time data stream operations.

[0104] Secondly, the overall connectivity health levels are predefined to include at least green, yellow, and red levels, and a mapping table between health levels and operational availability is established. The contents of this mapping table are specified as follows: With the current overall connectivity health level at the green level, all high-risk and low-risk operations remain available.

[0105] When the overall connectivity health level is red, all buttons for high-risk operations are disabled, while low-risk operations remain available.

[0106] When the overall connection health level is yellow, the button for high-risk operations is set to be clickable, but requires secondary confirmation from the user before execution.

[0107] The method of this application also includes: Step S6: Monitor the changes in the overall connectivity health level in real time. When the level changes from green to yellow or red, traverse the mapping table to obtain a list of controls whose availability status needs to be changed under the current level.

[0108] During the diagnostic session, the diagnostic host continuously monitors changes in the overall connection health level. Whenever step S4 recalculates and updates the overall connection health level, the diagnostic host compares the old and new levels. Once a degraded level requiring alert is detected—that is, a change from green to yellow or red—the diagnostic host immediately initiates a control status update process. The diagnostic host reads a predefined mapping table, iterates through each rule in the table, and identifies which graphical user interface controls need to have their availability status changed under the current changed level, thus generating a list of controls whose availability status needs to be altered.

[0109] For example, at the beginning of the diagnostic session, the VCI device has a good connection status, and the overall connection health level is green. At this time, all operation buttons on the graphical user interface are clickable. The technician is performing data stream reading and analysis and has not yet performed a flashing operation. As the diagnostic proceeds, the OBD interface of the VCI device experiences increased contact resistance due to vibration, and the supply voltage gradually decreases from 13.7V to 11.6V. After reassessment in step S3, the physical layer health score drops from 95 to 55, resulting in a recalculated overall connection health score of 72 in step S4. According to the level mapping rules, the new overall connection health level changes from green to yellow. The diagnostic host detects this level change and triggers step S6. The diagnostic host reads the mapping table, which specifies that the buttons corresponding to high-risk operations at the yellow level must change state. Therefore, the obtained control list contains three controls: their identifiers are "Flashing Button", "Encoding Button", and "Matching Anti-theft Button".

[0110] Step S7: Adjust the enable property of the corresponding graphical user interface control in the control list to the disabled state or the secondary confirmation state, and output the specific health problem description that caused the disabling in the form of floating text next to the disabled control.

[0111] For example, based on the control list obtained in step S6, the diagnostic host adjusts the enabling attributes of each graphical user interface control in the list. The specific adjustments strictly adhere to the current level's specifications in the mapping table. If the current level changes to red, the enabling attributes of these controls are disabled, making them grayed out and unclickable. If the current level changes to yellow, the enabling attributes of the controls are adjusted to a secondary confirmation state. When a control is in the secondary confirmation state, the user can still click the button, but the system will not immediately execute the operation. Instead, a secondary confirmation dialog box will pop up, clearly informing the user of the risks associated with the current connection. The operation will only be executed after the user confirms again. Simultaneously, regardless of whether a control is disabled or in a secondary confirmation state, the diagnostic host will generate a floating notification box next to the control, outputting a description of the specific health issue that caused the disabling in floating text form, allowing the user to intuitively understand the root cause of the problem.

[0112] For example, the current changed risk level is yellow. According to the mapping table, at the yellow level, the button corresponding to the high-risk operation is set to a secondary confirmation state. The diagnostic host obtains the object reference of the "Flash Button" graphical user interface control, calls its property setting interface, and adjusts its enabling property to the secondary confirmation state. At this time, the "Flash Button" does not turn gray and still appears clickable. However, the diagnostic host simultaneously outputs a prompt message next to the "Flash Button" in the form of floating text: "The current VCI power supply voltage is low (11.6V), performing a flash is risky, and secondary confirmation is required after clicking." The same processing is applied to the "Encoding Button" and "Match Anti-theft Button". Meanwhile, the "Read Fault Code" and "Real-time Data Stream" buttons are low-risk operations and are not in the control list, so their enabling properties remain unchanged.

[0113] For example, if the overall connectivity health level deteriorates further, dropping directly to the red level (e.g., the power supply voltage drops below 11.0V), the mapping table specifies that all buttons corresponding to high-risk operations at the red level should be disabled. The diagnostic host will disable the "Flash Button," "Encoding Button," and "Match Anti-theft Button," making the buttons grayed out and unresponsive to click events. Simultaneously, a floating text message will appear next to the "Flash Button": "Flash disabled - VCI power supply voltage too low (10.8V), interruption during flashing will brick the ECU."

[0114] Step S8: When the overall connection health level is restored to the green level, the enable properties of high-risk operation controls that were previously disabled or set to secondary confirmation are automatically restored to their original available state.

[0115] The diagnostic host continuously monitors changes in the overall connectivity health level. When it detects a change from yellow or red to green, the diagnostic host automatically performs a recovery operation. It identifies all high-risk controls whose enable attributes were adjusted in step S7 and restores their enable attributes to their original usable state—that is, a normal, clickable state that requires no secondary confirmation. This process is completely automatic, requiring no manual user intervention, ensuring a smooth diagnostic workflow.

[0116] For example, in the yellow-level scenario described above, after noticing the floating text prompt, the technician checked the OBD interface of the VCI device, found a loose connection, and re-inserted it. The power supply voltage immediately returned to normal, the physical layer health score rebounded, the overall connection health score was recalculated to 91 points, and the overall connection health level returned to green. The diagnostic host detected this level change and automatically triggered step S8. The diagnostic host restored the enable attributes of the "Write Button," "Encode Button," and "Match Anti-theft Button" to their original available state, the secondary confirmation state was removed, and the floating text prompt next to the buttons automatically disappeared. At this time, the technician can directly click the "Write Button" to initiate the write operation without any additional confirmation steps, and the system's trust in the VCI connection health has been automatically restored.

[0117] In one optional implementation, the diagnostic host pre-defines a rectangular area on its main graphical user interface as a visualization dashboard container area. This area, located in the upper right corner of the main interface and approximately 320×240 pixels in size, is embedded in the main interface layout as an independent view component. This visualization dashboard container area is set to be permanently displayed, meaning it does not hide when switching between diagnostic business pages. Regardless of whether the user is currently operating the "Fault Code Reading" page, the "Data Stream Analysis" page, or the "Flash Programming" page, this dashboard remains visible, ensuring that the user can perceive the connection health status of the VCI device in real time under any diagnostic business scenario.

[0118] At the center of the visualization dashboard container area, the diagnostic host invokes the graphics rendering engine to draw a pie chart. The inner diameter of the pie chart occupies 70% of the outer diameter, forming a relatively wide ring area. The pie chart is filled using a fan-shaped sweeping method, and its fill color corresponds to the overall connectivity health level in real time: if the current level is green, the ring is filled with green; if the level changes to yellow, the ring becomes yellow; if it is red, the ring becomes red. Simultaneously, the arc length of the pie chart also corresponds to the overall connectivity health level in real time: the system defaults to a full 360° arc length for a green level, a 240° arc length for a yellow level (indicating a potential gap), and a 120° arc length for a red level (indicating a severe deficiency). The arc length changes continuously as the score changes. In the central circular blank area of ​​the pie chart, the diagnostic host displays the overall connectivity health score in a larger font as a number, currently showing "91," and below the score, it labels "Healthy Connection" in a smaller font.

[0119] Surrounding the ring diagram, the diagnostic host displays three partition card containers. These three partition card containers are horizontally arranged side-by-side below the ring diagram, each a rounded rectangle approximately 90 x 120 pixels in size. The three partition card containers are labeled Physical Layer, Link Layer, and Application Layer, respectively, with the label text displayed in the top title bar of each card container.

[0120] Within each partition card container, the diagnostic host performs dynamic data binding. The rendering engine extracts key metric data for each layer from the standardized state records generated in step S2 and populates it into the card: Physical layer partition card container: dynamically binds the icon corresponding to the physical layer (an electrical symbol in the shape of a lightning bolt), displays the key indicator name "supply voltage", its current value is "13.7", and the unit is "V".

[0121] Link layer partition card container: dynamically binds the icon corresponding to the link layer (a communication identifier in the shape of a signal ripple), displays the key indicator name "Bluetooth RSSI", its current value is "-55", and the unit is "dBm".

[0122] Application layer partition card container: dynamically binds the corresponding icon (a protocol identifier in the shape of a document) of the application layer, displays the key indicator name "Current Session", and its current value is "Default Session".

[0123] The background color of each partition card container can also change according to the health status of that layer. For example, the background is light green when all the indicator status markers of that layer are "normal", and the background turns light yellow when "warning" appears.

[0124] Within the visualization dashboard container area, a dynamically displayed component area is embedded below the partition card container. This component automatically switches the displayed content based on whether there are active flashing tasks and the communication method of the VCI device.

[0125] Since there is currently an active write task, the dynamic display component is presented as a write progress bar. The progress bar is a horizontal bar with a thin gray border and is filled continuously in blue from left to right, with the width of the fill proportional to the write progress. The percentage text is also displayed on the right side of the progress bar. The diagnostic host reads the write progress information from the application layer status data in step S1; the current progress is 5 / 20, which translates to 25%. Therefore, the progress bar is filled to 25% of its total width, and the text "25%" is displayed on the right.

[0126] Simultaneously, since the VCI device communicates with the diagnostic host via Bluetooth wireless channel, the dynamic display component presents a signal strength fluctuation curve side-by-side below the flashing progress bar. This curve is a small line graph plotted in real time, with the horizontal axis representing time (scrolling from left to right) and the vertical axis representing the Bluetooth RSSI value (in dBm), with the time window being the most recent 30 seconds. The diagnostic host plots and connects the Bluetooth RSSI values ​​collected in step S1 as data points in real time, forming a signal strength fluctuation curve that changes over time. Currently, the curve fluctuates slightly between -50dBm and -58dBm, intuitively reflecting the stability of the wireless signal.

[0127] The method in this application also includes: Step S9: In response to the user's selection operation on the pie chart or any partition card container, a detailed panel is expanded in the form of a floating layer above the visualization dashboard container area. The detailed panel displays the real-time values, historical extreme values, and status trend arrows used to indicate the trend of indicator changes for all indicators collected in that layer in a list format.

[0128] The diagnostic host system has configured interactive response logic for the visual dashboard. When a user taps on the pie chart, the system displays a summary panel by default. When the user taps on any partition card container, a dedicated detailed panel expands for that layer.

[0129] For example, a user notices a slight fluctuation in the power supply voltage value on the physical layer partition card container and taps the partition card container labeled "Physical Layer". In response to this tap, the diagnostic host displays a pop-up window as a detailed panel above the visualization dashboard container area. This detailed panel displays complete information on all physical layer metrics collected in a list format, with each row corresponding to one metric and containing the following fields: Indicator names: such as "OBD interface power supply voltage", "device power supply current", and "casing temperature".

[0130] Real-time values ​​and units: Displays the latest quantized values, such as "13.7V", "250mA", and "42℃".

[0131] Historical extreme values: Displays the historical maximum and minimum values ​​of this indicator since the start of this diagnostic session. For example, the historical extreme values ​​of "OBD interface power supply voltage" are "minimum 12.8V / maximum 14.2V", indicating that the power supply status is generally stable.

[0132] Status Trend Arrow: This is a graphical element used to visually represent the trend of an indicator. The diagnostic host determines its trend based on the moving average of the indicator's most recent collected values. If it is generally rising, an upward arrow (↑) is displayed; if it is generally falling, a downward arrow (↓) is displayed; if it is basically flat, a horizontal arrow (→) is displayed. Currently, the "OBD Interface Power Supply Voltage" has gradually increased from 13.5V to 13.7V in the last 10 collections, and the status trend arrow is displayed as a green upward arrow, indicating that the power supply status is improving.

[0133] The same interaction logic applies to the link layer partition card container and the application layer partition card container. Users can close the detailed panel by clicking the close button in the upper right corner or by clicking outside the panel area, returning to the default view of the visualization dashboard container area. Through this interaction design, users can grasp the overall connection health level at a glance, and also delve deeper to explore all the detailed indicators and their changing trends of any layer as needed.

[0134] In an optional implementation, the method of the application further includes: Step A1: During the diagnostic session, set mutation monitoring windows and mutation thresholds for at least one key indicator in each of the physical layer state data, link layer state data, and application layer state data.

[0135] The diagnostic host pre-stores a dedicated parameter set for anomaly detection in its configuration file. When a diagnostic session starts, the host reads the configuration from this parameter set and sets a specific mutation monitoring window and mutation threshold for at least one key indicator in each of the physical layer state data, link layer state data, and application layer state data. In this embodiment, the selected key indicators include at least the three most sensitive indicators for diagnostic security: power supply voltage, Bluetooth RSSI value, and security access status.

[0136] The diagnostic host application maintains a UDS secure access state machine synchronized with the application layer protocol stack. When it receives a negative response code (such as 0x35, 0x36, 0x37, etc.) for the UDS 0x27 service or a response indicating a session timeout, it changes the internally tracked current ECU secure access state from unlocked to locked, thus triggering a single state transition detection.

[0137] For example, for the key indicator of power supply voltage in the physical layer status data, its mutation monitoring window is set to 5 seconds, and the mutation threshold is "voltage drop exceeding 1.5V". This setting is designed to quickly detect sudden deterioration in power supply caused by loose OBD interface or depleted vehicle battery.

[0138] For the Bluetooth RSSI value, a key indicator in the link layer state data, a mutation monitoring window of 10 seconds is set, and the mutation threshold is "signal attenuation exceeding 20dB". This setting is used to detect a sharp decline in wireless connection quality caused by increased distance or obstruction from obstacles.

[0139] For the key indicator of security access status in application layer state data, its mutation monitoring window is set to a single state transition event (i.e., no time window concept, event-driven), and the mutation threshold is "security access unlock status changes from unlocked to locked". This setting is used to capture dangerous situations where security access fails unexpectedly during the flashing process.

[0140] Step A2: Within the sliding time window, continuously sample the values ​​of each key indicator and calculate the change or rate of change of each key indicator within the time window.

[0141] The diagnostic host maintains a sliding time window buffer for each key indicator, the length of which is determined by the mutation monitoring window set in step A1. The diagnostic host continuously acquires the latest values ​​of each key indicator according to the predetermined acquisition cycle in step S1 and stores them in the corresponding buffer. Whenever a new data point enters the buffer, the oldest data point is removed, ensuring that the data in the buffer always covers the most recent time window. Subsequently, the diagnostic host calculates the amount or rate of change of the key indicator within that time window.

[0142] For example, for the critical indicator of power supply voltage, the diagnostic host maintains a sliding time window of 5 seconds. The earliest voltage value in the current window is 13.2V, and the most recently acquired voltage value is 11.4V. The diagnostic host calculates the change within this time window as: 11.4V - 13.2V = -1.8V, that is, the voltage dropped by 1.8V.

[0143] For the key indicator Bluetooth RSSI value, the diagnostic host maintains a sliding time window of 10 seconds. The earliest RSSI value in the current window is -48dBm, and the latest RSSI value is -72dBm. The diagnostic host calculates the change within this time window as: (-72) - (-48) = -24dB, that is, the signal attenuation is 24dB.

[0144] For the key indicator of secure access status, since it is a discrete state value, the change calculation is not applicable. Instead, we directly compare whether the latest state has been reversed with the state at the previous moment.

[0145] Step A3: Compare the calculated change or rate of change with the corresponding mutation threshold. When the change or rate of change of any key indicator exceeds the mutation threshold, an abnormal event is triggered.

[0146] The diagnostic host compares the change or rate of change calculated in step A2 with the mutation threshold set for the corresponding key indicator in step A1. The judgment rule is: when the absolute value of the change or rate of change of the key indicator exceeds the mutation threshold, an abnormal event corresponding to that key indicator is immediately triggered.

[0147] For example, the diagnostic host performs the following comparison operation: The supply voltage dropped by 1.8V within 5 seconds, with an absolute value of 1.8V. Compared with the mutation threshold "voltage drop exceeding 1.5V", 1.8V > 1.5V, triggering an abnormal event, and the event type is marked as "VCI supply voltage drop".

[0148] The Bluetooth RSSI value decreased by 24dB within 10 seconds, with an absolute value of 24dB. Compared to the mutation threshold "signal attenuation exceeds 20dB", 24dB > 20dB, triggering an abnormal event, which is marked as "VCI wireless signal rapidly attenuation".

[0149] The security access status is the same as the last check, both are "unlocked", with no flipping and no abnormal events triggered.

[0150] Step A4: Based on the key indicators that triggered the abnormal event and their current values, match the corresponding alarm text template in the preset alarm message template library, and fill in the text template with the name of the key indicator, the real-time value, the degree to which it exceeds the mutation threshold, and the corresponding operation suggestions to generate a complete alarm message.

[0151] In this process, after an abnormal event is triggered in step A3, the diagnostic host immediately initiates the alarm message generation process. The diagnostic host has a pre-configured alarm message template library, which stores corresponding alarm text templates for each possible abnormal event type. An alarm text template is a formatted string containing placeholders, with spaces reserved for dynamically filling in key information. The diagnostic host retrieves a matching alarm text template from the template library based on the type of abnormal event. Upon successful matching, the diagnostic host extracts the current real-time value of the key indicator that triggered the abnormal event, calculates the degree to which its change exceeds the mutation threshold, and queries a predefined response suggestion database to obtain matching guidance text. Finally, the name of the key indicator, its real-time value, the degree to which it exceeds the mutation threshold, and the response suggestion are sequentially filled into the corresponding placeholders in the alarm text template to generate a complete alarm message.

[0152] For example, in response to the abnormal event of "sudden drop in VCI power supply voltage", the diagnostic host matches the following alarm text template in the preset alarm message template library: "

Warning

[0153] The diagnostic host retrieves the following dynamic information and populates it into the template: The key indicator is named "VCI supply voltage". Real-time value: "11.4"; Unit: “V”; The degree to which the mutation threshold is exceeded: "0.3V" (actual decrease of 1.8V - threshold of 1.5V = 0.3V).

[0154] Recommended procedure: "Immediately check if the OBD interface connection is loose and confirm the vehicle battery charge. Do not perform or continue the flashing operation until the voltage recovers to above 12.5V." The complete alarm message generated after filling is as follows: "

WARNING

[0155] The diagnostic host pushes the complete alarm message generated in step A4 to the top layer of the graphical user interface for mandatory display. Specifically, it displays the message as a modal window, overlaying all existing content in the diagnostic host's graphical user interface. This modal window has the highest display hierarchy, and the diagnostic host locks the interaction in the covered area below the modal window; that is, all buttons, menus, and input boxes within the covered area are temporarily unresponsive to clicks or touches. The modal window displays the complete alarm text message and provides a clear "Confirm" or "OK" button for the user to click. Only after the user confirms the alarm message does the diagnostic host unlock the interaction in the covered area and close the modal pop-up window.

[0156] For example, the diagnostic host's graphical user interface is displaying a real-time data stream page, and the technician's gaze is focused on the data curves for engine speed and coolant temperature. At this moment, due to vehicle vibration, the VCI device's OBD interface becomes loose, causing the power supply voltage to suddenly drop to 11.4V within 5 seconds. This triggers the abnormal event in step A3, and generates the aforementioned complete alarm message via step A4. The diagnostic host immediately pops up a modal window on the current data stream page, its semi-transparent background obscuring all data curves and operation buttons below, locking the interaction in the covered area. The complete alarm message is displayed in prominent font in the center of the modal window, with a "Confirm" button at the bottom. After seeing the alarm, the technician must click the "Confirm" button for the modal window to close, after which the interactive functions in the obscured area automatically resume, allowing the technician to immediately take appropriate action based on the alarm prompts. This strong alert mechanism ensures that even during flashing or other critical operations, sudden deterioration in connection health can be detected and addressed by the technician immediately.

[0157] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0158] Please see Figure 4 This illustration shows a structural schematic diagram of a diagnostic device for connectivity health status provided in an exemplary embodiment of this application, hereinafter referred to as device 4. Device 4 can be implemented as all or part of a diagnostic host through software, hardware, or a combination of both. Device 4 includes: The acquisition module 401 is used to acquire the physical layer status data, link layer status data and application layer status data of the VCI device in real time. The conversion module 402 is used to standardize and convert the physical layer status data, the link layer status data and the application layer status data to obtain a standardized status record. The standardized status record includes a layer identifier, an indicator name, a quantified value and a status marker. The scoring module 403 is used to score the various indicators in the standardized state record using a preset multi-level threshold rule set, and generate physical layer health score, link layer health score and application layer health score. The grading module 404 is used to perform a weighted summation of the physical layer health score, the link layer health score, and the application layer health score to obtain an overall connection health score, and convert the overall connection health score into an overall connection health level according to a preset level mapping rule. Rendering module 405 is used to render a visual dashboard on the graphical user interface of the diagnostic host. The visualization dashboard is used to display the overall connectivity health level, as well as at least one key indicator of the physical layer status data, the link layer status data, and the application layer status data.

[0159] For further details regarding the implementation of the above technical solutions by each module in the above-mentioned connection health diagnostic device, please refer to the description in the connection health diagnostic method provided in the above-mentioned embodiments of the invention, which will not be repeated here.

[0160] It should be noted that the device 4 provided in the above embodiments, when performing the connection health diagnosis method, is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. In addition, the connection health diagnosis device and the connection health diagnosis method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0161] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0162] See Figure 5 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 5 The computer program shown above), the instructions are adapted to be loaded and executed by a processor as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0163] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by the processor to implement the connection health diagnosis method as described in the above embodiments.

[0164] Please see Figure 6 This is a schematic diagram of the structure of a diagnostic host provided in an embodiment of this application. Figure 6 As shown, the diagnostic host 600 may include: at least one processor 601, at least one network interface 604, a user interface 603, a memory 605, and at least one communication bus 602.

[0165] The communication bus 602 is used to enable communication between these components.

[0166] The user interface 603 may include input units such as a mouse and keyboard.

[0167] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0168] The processor 601 may include one or more processing cores. The processor 601 connects to various parts within the diagnostic host 600 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by calling data stored in the memory 605. Optionally, the processor 601 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 601 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip, without being integrated into the processor 601.

[0169] The memory 605 may include random access memory (RAM) or read-only memory. Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned processor 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0170] exist Figure 6In the diagnostic host 600 shown, the user interface 603 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 601 can be used to call the application program stored in the memory 605 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0171] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0172] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A diagnostic method for linking health status, characterized in that, The diagnostic method is applied to a diagnostic host, which communicates with at least one vehicle via a VCI device; The method includes: Real-time acquisition of physical layer status data, link layer status data, and application layer status data of the VCI device; The physical layer state data, the link layer state data, and the application layer state data are standardized and transformed to obtain standardized state records. The standardized state records contain layer identifiers, indicator names, quantified values, and state markers. Using a preset multi-level threshold rule set, scores are applied to various indicators in the standardized state record to generate physical layer health scores, link layer health scores, and application layer health scores. The physical layer health score, the link layer health score, and the application layer health score are weighted and summed to obtain an overall connection health score, and the overall connection health score is converted into an overall connection health level according to a preset level mapping rule. A visual dashboard is rendered on the graphical user interface of the diagnostic host. The visualization dashboard is used to display the overall connectivity health level, as well as at least one preset key indicator of the physical layer status data, the link layer status data, and the application layer status data.

2. The method for diagnosing connection health according to claim 1, characterized in that, The physical layer status data represents the electrical and physical connection characteristics of the VCI device, the link layer status data represents the communication channel quality of the VCI device, and the application layer status data represents the status of the diagnostic service protocol currently carried by the VCI device. The real-time acquisition of the physical layer status data, link layer status data, and application layer status data of the VCI device includes: Load the acquisition configuration file corresponding to the model of the VCI device. The acquisition configuration file is used to configure the indicators to be acquired and the reading instructions corresponding to each indicator. During the diagnostic session, the physical layer status data is acquired through the built-in analog-to-digital converter or corresponding API interface of the VCI device according to the first acquisition cycle. The physical layer status data includes the OBD interface power supply voltage, device power supply current and casing temperature. During the diagnostic session, according to the second acquisition cycle, a link layer query command is sent to the VCI device or a specific network message is monitored to obtain the link layer status data, which includes: Bluetooth RSSI value, WiFi signal-to-noise ratio, DoIP session identifier, link round-trip time, and CAN bus load rate. During the diagnostic session, continuously listen for diagnostic response messages from the VCI device or vehicle ECU, and extract the current ECU session mode and security access unlock status from the diagnostic response messages; After the flushing task is triggered, flushing progress information, which represents the ratio of the current flushing block number to the total number of blocks, can be obtained by subscribing to events or periodically querying. The application layer status data includes: the current ECU session mode, the secure access unlock status, and the flashing progress information.

3. The method for diagnosing connection health according to claim 1, characterized in that, The standardization transformation of the physical layer state data, the link layer state data, and the application layer state data to obtain standardized state records includes: The collected raw data from each layer are labeled with layer tags according to their source: physical layer, link layer, or application layer. For analog quantities with different physical units, perform unit conversion and unify them into a preset standard unit system; Perform validity checks on numerical indicators and remove invalid data. Invalid data includes data whose values ​​exceed a preset physical feasible range or data whose values ​​remain constant within a preset number of consecutive data collections. Based on the pre-set three-level threshold ranges of normal, warning, and abnormal for each indicator, a status marker field is added to each valid data point, and the value of the status marker field corresponds to the threshold range. The processed indicator name, quantified value, unified unit, hierarchical label, and status marker fields are encapsulated into a structured data object, which serves as the standardized status record.

4. The method for diagnosing connection health according to claim 1, characterized in that, The process involves invoking a preset multi-level threshold rule set to score various indicators in the standardized state record, generating physical layer health scores, link layer health scores, and application layer health scores, including: According to the type of diagnostic task currently being performed, the matching threshold configuration table is read from the preset multi-level threshold rule set. The threshold configuration table defines at least two threshold boundary points and corresponding scoring intervals for each indicator to be scored. Iterate through each indicator in the standardized state record, and determine the individual indicator score based on the score range in which the value of the indicator falls. Read the preset intra-layer weight configuration file to obtain the weight coefficients corresponding to various indicators in the physical layer, link layer and application layer respectively; For each layer, the scores of all individual indicators within that layer are weighted and summed with their corresponding weight coefficients to obtain the physical layer health score, the link layer health score, and the application layer health score, respectively.

5. The method for diagnosing connection health according to claim 1, characterized in that, The step of weighted summing of the physical layer health score, the link layer health score, and the application layer health score to obtain an overall connection health score, and converting the overall connection health score into an overall connection health level according to a preset level mapping rule, includes: Based on the type of diagnostic task currently being performed, select a set of inter-layer weight coefficients that matches the type of diagnostic task from a set of preset inter-layer weight coefficients; The physical layer health score is multiplied by the physical layer weight in the selected inter-layer weight coefficient, the link layer health score is multiplied by the link layer weight, the application layer health score is multiplied by the application layer weight, and the three products are added together to obtain the overall connection health score. Read the preset level mapping table, which stores multiple consecutive and non-overlapping score intervals, each score interval uniquely corresponding to an overall connection health level; The overall connection health score is matched with the score range in the level mapping table to determine the score range to which the overall connection health score belongs, and the corresponding overall connection health level is obtained. In determining the overall connection health level, it is checked whether any of the physical layer health score, the link layer health score, and the application layer health score is lower than a preset extremely high risk threshold. If so, the overall connection health level is forcibly set to the lowest level indicating connection danger, and a forced downgrade flag is generated.

6. The method for diagnosing connection health according to claim 1, characterized in that, Predefine the risk level classification of executable operations, mark writing, coding, and matching anti-theft operations as high-risk operations, and mark reading fault codes and real-time data stream operations as low-risk operations; The overall connection health level is predefined to include at least green, yellow and red levels, and a mapping table between health level and operation availability is established. The mapping table stipulates that: at the green level, all high-risk and low-risk operations remain available; at the red level, all buttons corresponding to high-risk operations are disabled and low-risk operations remain available; at the yellow level, the buttons corresponding to high-risk operations are clickable but require secondary confirmation from the user before execution. The method further includes: Real-time monitoring of changes in the overall connectivity health level; when the level changes from green to yellow or red, traversing the mapping table to obtain a list of controls whose availability status needs to be changed under the current level. Adjust the enable property of the corresponding graphical user interface control in the control list to the disabled state or the secondary confirmation state, and output the specific health problem description that caused the disablement in the form of floating text next to the disabled control. When the overall connection health level is restored to the green level, the enable attributes of high-risk operation controls that were previously disabled or set to secondary confirmation are automatically restored to their original available state.

7. The method for diagnosing connection health according to claim 1, characterized in that, The method further includes: During the diagnostic session, a mutation monitoring window and a mutation threshold are set for at least one key indicator in each of the physical layer state data, the link layer state data, and the application layer state data. The key indicators include at least the power supply voltage, Bluetooth RSSI value, and security access status. Within the sliding time window, the values ​​of each key indicator are continuously sampled, and the change amount or rate of change of each key indicator within the time window is calculated. The calculated amount or rate of change is compared with the corresponding mutation threshold. When the amount or rate of change of any key indicator exceeds the mutation threshold, an abnormal event is triggered. Based on the key indicators that triggered the abnormal event and their current values, the corresponding alarm text template is matched in the preset alarm message template library, and the name of the key indicator, the real-time value, the degree to which it exceeds the mutation threshold, and the corresponding operation suggestions are filled into the text template to generate a complete alarm message. On the graphical user interface of the diagnostic host, the complete alarm message is displayed as a modal window, and the interaction of the covered area is locked until the user confirms the alarm message.

8. A diagnostic device for connecting to health status, characterized in that, include: The acquisition module is used to acquire physical layer status data, link layer status data and application layer status data of the VCI device in real time; The conversion module is used to standardize and convert the physical layer state data, the link layer state data and the application layer state data to obtain a standardized state record. The standardized state record includes a layer identifier, an indicator name, a quantified value and a state marker. The scoring module is used to score various indicators in the standardized status record using a preset multi-level threshold rule set, and generate physical layer health score, link layer health score and application layer health score. The grading module is used to perform a weighted summation of the physical layer health score, the link layer health score, and the application layer health score to obtain an overall connection health score, and convert the overall connection health score into an overall connection health level according to a preset level mapping rule. A rendering module is used to render a visual dashboard on the graphical user interface of the diagnostic host. The visualization dashboard is used to display the overall connectivity health level, as well as at least one preset key indicator of the physical layer status data, the link layer status data, and the application layer status data.

9. A computer storage medium, characterized in that, The computer storage medium stores multiple instructions adapted for loading by a processor and executing the steps of the connection health diagnostic method as described in any one of claims 1 to 7.

10. A diagnostic host, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the connection health diagnostic method as described in any one of claims 1 to 7.

Images