Diagnosis method and device and storage medium

Abstract

The invention discloses a diagnosis method and device and a storage medium, and relates to the field of electronic device application. According to the scheme, firstly, based on a diagnostic rule definition file independent of equipment firmware, a diagnostic rule database recording a plurality of diagnostic items and corresponding support rules thereof is generated, and the support rules are logic judgment conditions based on equipment configuration information; then, when specific conditions such as system starting or configuration updating are met, centralized evaluation is carried out on support rules of all the diagnosis items in the diagnosis rule database based on current equipment configuration information, and diagnosis support snapshots for recording the support states of all the diagnosis items under current configuration are generated; and finally, when a query request for a target diagnosis item is received, the support state of the target diagnosis item is determined by querying the diagnosis support snapshot, and a corresponding diagnosis process is executed when the support state is determined. According to the scheme, the diagnosis logic and the firmware code are decoupled, so that the configuration flexibility and reliability of the diagnosis of the electronic equipment are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of electronic device applications, and in particular to a diagnosis method, device and storage medium. BACKGROUND

[0002] In complex embedded devices for vehicle, industrial control and other fields, the built-in diagnosis logic is usually directly fixed in the firmware program in a hard-coded manner. This implementation severely limits the flexibility of the system, making it difficult to effectively adapt to the diversified needs brought about by differences in hardware configuration (such as high-end and low-end), software version iteration or different external market regulation requirements. In order to cover all possible scenario combinations, device manufacturers are forced to develop, test and maintain multiple independent firmware versions for different configurations or market regions, resulting in complex software branch management, serious version fragmentation, and difficulty in ensuring consistency between versions. More seriously, any adjustment of the diagnosis logic for a specific configuration requires a full upgrade of the entire firmware, which not only increases maintenance costs, but also significantly increases the risk of introducing new faults due to underlying code modifications. SUMMARY

[0003] The present application provides a diagnosis method, device and storage medium, aiming to solve the problems of poor adaptation flexibility, high maintenance cost and high upgrade risk caused by directly writing diagnosis logic in the firmware code in the prior art. The specific technical solutions are as follows: A diagnosis method applied to a target electronic device, comprising: generating a diagnosis rule database based on a pre-configured diagnosis rule definition file; wherein the rule definition file is independent of the firmware of the target electronic device; the diagnosis rule database is used to record a plurality of diagnosis items and their corresponding support rules configured by the diagnosis rule definition file, the support rules being logical judgment conditions based on device configuration information; when a specific condition is met, judging whether the support rules corresponding to each diagnosis item in the diagnosis rule database meet based on the current target device configuration information of the target electronic device, generating a diagnosis support snapshot, the diagnosis support snapshot recording the support status of each diagnosis item in the diagnosis rule database under the target device configuration information; in response to a diagnosis request for a target diagnosis item, determining the support status of the target diagnosis item by querying the diagnosis support snapshot; if the support status of the target diagnosis item indicates support, executing the diagnosis process of the target diagnosis item.

[0004] An electronic device, comprising: a processor; and a memory arranged to store computer executable instructions which, when executed, cause the processor to perform the above diagnosis method.

[0005] A computer-readable storage medium storing a computer program that, when executed, implements the above-described diagnostic method.

[0006] This application decouples diagnostic logic from the firmware and achieves efficient and reliable diagnostic capability assessment through dynamic evaluation and pre-generated snapshots. Specifically, the solution first compiles and generates a diagnostic rule database based on a diagnostic rule definition file independent of the firmware. This database records multiple diagnostic items and their corresponding supporting rules, where the supporting rules are logical judgment conditions based on device configuration information. Subsequently, when specific conditions are met, the supporting rules for each diagnostic item in the diagnostic rule database are centrally evaluated based on the target electronic device's current device configuration information, generating a diagnostic support snapshot that records the support status of all diagnostic items under the current configuration. Finally, when a diagnostic request for a specific target diagnostic item is received, the diagnostic support snapshot is directly queried to determine whether the target electronic device supports the target diagnostic item. If the support status is true, the corresponding diagnostic process is triggered. Through the above mechanism, this solution achieves multiple technical benefits: Firstly, it generates a diagnostic rule database independent of the firmware by defining diagnostic rules in the diagnostic rule definition file. The support rules for each diagnostic item in this database, combined with the current device configuration information, automatically determine the support status of each diagnostic item. This allows the diagnostic item support status determination mechanism to flexibly adapt to different hardware configurations, software versions, or regulatory scenarios, thus completely solving the problems of poor adaptability and version fragmentation caused by hard coding. Secondly, updating diagnostic rules only requires upgrading the diagnostic rule definition file and regenerating the diagnostic rule database, without modifying or releasing the entire firmware. This significantly reduces maintenance costs and fundamentally avoids system stability risks caused by firmware upgrades. Thirdly, by pre-storing the determined support status of each diagnostic item as a diagnostic support snapshot, when a diagnostic request for a target diagnostic item is received, the system can quickly determine whether the target diagnostic item is supported by statically querying the diagnostic support snapshot, thus ensuring real-time diagnostic response.

[0007] Optionally, after generating the diagnostic support snapshot, the method further includes: loading the diagnostic support snapshot into the cache of the target electronic device; the step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot includes: determining the support status of the target diagnostic item by querying the diagnostic support snapshot in the cache. This technical solution achieves extreme optimization of the query path by introducing a caching mechanism to preload the diagnostic support snapshot into the device's high-speed cache area. Compared to accessing slow non-volatile memory or re-executing rule evaluation for each query, directly querying snapshot data from the cache transforms the query operation into a highly efficient memory access, reducing the query time complexity from the original O(n) or O(log n) to the ideal O(1) constant level, and significantly reducing the query latency from milliseconds to microseconds or even nanoseconds, thereby meeting the real-time requirements of high-frequency diagnostic query scenarios. In addition, this design effectively avoids I / O bottlenecks and additional power consumption caused by frequent reading of external storage media, significantly reduces the computational load and parsing overhead of the system CPU, and allows resources to be more concentrated on critical diagnostic tasks.

[0008] Optionally, loading the diagnostic support snapshot into the cache of the target electronic device includes: loading the diagnostic support snapshot into the cache of the target electronic device using atomic operations. This technical solution ensures the integrity and consistency of cached data during the update process through atomic operations, effectively avoiding data contention issues such as dirty reads and dirty writes that may occur in concurrent query scenarios. Specifically, the atomic loading mechanism ensures that when updating the cache, the query operation reads either the complete old version snapshot data or the complete new version snapshot data, and will not read partially updated or invalid data in an intermediate state, thereby significantly improving the reliability and determinism of the system. In addition, this mechanism is a key technical foundation for realizing hot updates of diagnostic rules. It allows the system to safely complete the dynamic switching of diagnostic support status without downtime or service interruption, further enhancing the practicality and robustness of the system in scenarios with extremely high continuity requirements, such as vehicle operation.

[0009] Optionally, after generating the diagnostic support snapshot, the method further includes: storing the diagnostic support snapshot in the non-volatile memory of the target electronic device; the step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot further includes: if querying the diagnostic support snapshot from the cache fails, then querying the diagnostic support snapshot in the non-volatile memory to determine the support status of the target diagnostic item. This technical solution effectively improves the system's fault tolerance and data reliability by establishing a multi-level query mechanism and introducing a non-volatile storage backup layer on top of the cache. Specifically, when the cache is cleared due to system restart or abnormal clearing, the diagnostic support snapshot can be directly obtained from the non-volatile memory to ensure the continuity of diagnostic services.

[0010] Optionally, based on the diagnostic rule definition file, key diagnostic items that must be supported are determined; the key diagnostic items are written into the static fallback list of the target electronic device in the form of code, wherein the static fallback list is pre-created in the firmware of the target electronic device; the step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot further includes: if querying the diagnostic support snapshot from the non-volatile memory fails, then determining the support status of the target diagnostic item by querying whether the target diagnostic item is written in the static fallback list. This technical solution establishes a three-layer guarantee mechanism, including caching, non-volatile storage backup, and a firmware-level static rollback list, to build a complete system fault tolerance system. The static rollback list serves as the final reliability barrier, ensuring that even in extreme failure scenarios where the cache fails and the diagnostic support snapshot in non-volatile storage is inaccessible, the system can still maintain the operation of core diagnostic functions by querying the key diagnostic items pre-set in the firmware. This design not only minimizes the risk of system function loss due to storage media damage, file system errors, or other unforeseen hardware failures, but also achieves the engineering goal of "not losing core diagnostic capabilities even if the system suffers a serious failure" by embedding relatively important key diagnostic items in read-only memory.

[0011] Optionally, the target electronic device is a vehicle, and the key diagnostic items include brake system diagnostic items and / or emergency call diagnostic items. This technical solution provides the highest level of functional safety assurance for the vehicle diagnostic system by solidifying core diagnostic items related to driving safety and life protection into a static rollback list. Even in extreme fault scenarios (such as complete storage system failure or rule database corruption), the system can still ensure the continued availability of the vehicle's most basic safety diagnostic functions by querying the pre-set brake system and emergency call diagnostic items in the firmware. Specifically, by prioritizing the protection of brake system diagnostic items, the system ensures that the vehicle has continuously available diagnostic capabilities in terms of the most basic active safety functions. Even in extreme cases of network anomalies or complete storage system failure, it can still maintain monitoring of key braking system parameters and fault alarms, meeting the fault tolerance requirements for the highest safety level (ASIL-D) systems in automotive functional safety standards such as ISO 26262. Secondly, the solidified guarantee of emergency call (eCall) diagnostic items ensures that the diagnostic functions on which the vehicle and the rescue center rely to establish a communication link in the event of an emergency such as a collision are absolutely reliable. This avoids the risk of emergency call function failure due to storage system failure and provides a crucial line of defense for occupant safety.

[0012] Optionally, after the target electronic device's system restarts, if the cache does not load the diagnostic support snapshot, and the non-volatile memory stores the diagnostic support snapshot, then the diagnostic support snapshot in the non-volatile memory is loaded into the cache. This technical solution establishes an efficient recovery mechanism for the situation where the diagnostic support snapshot in the cache is lost after a system restart. After a system restart, when it is detected that the diagnostic support snapshot is not loaded in the cache, the pre-stored diagnostic support snapshot in the non-volatile memory is automatically loaded into the cache, ensuring that the system can immediately restore its ability to quickly query the diagnostic item support status after a cold start, without waiting for the time-consuming re-evaluation of the diagnostic item support rules.

[0013] Optionally, the specific conditions include changes in the device configuration information of the target electronic device and / or a system restart of the target electronic device. This technical solution constructs an intelligent and adaptive state synchronization mechanism by clearly defining key events that trigger the re-evaluation of support rules, ensuring a high degree of consistency between the diagnostic support list and the actual operating environment of the device. Its technical effectiveness is mainly reflected in two dimensions: dynamic adaptability and state reliability. Regarding dynamic adaptability, by monitoring changes in device configuration information (e.g., detecting changes in the device's main control unit, additions or removals of peripheral modules, software license updates, or adjustments to regional compliance settings), the system can respond to these dynamic changes in real time, proactively triggering the rule evaluation process to regenerate a diagnostic support snapshot that precisely matches the current hardware, software, and compliance configuration. This mechanism effectively avoids misjudgments of diagnostic functions caused by configuration information lagging behind the actual state, ensuring the real-time accuracy of diagnostic logic and meeting the high requirements for functional configurability of devices in complex and ever-changing field environments. In terms of state reliability, setting system restart as a trigger condition provides a mandatory synchronization and calibration opportunity for diagnostic state. After a cold / warm boot, the system can ensure that the diagnostic support list in memory is a completely new state that is fully consistent with the current system base environment by reloading or evaluation. This effectively clears any temporary state errors or data inconsistencies that may have existed during previous runtime, providing a reliable basis for system diagnostic queries.

[0014] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0015] 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 recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the first type of diagnostic method according to an embodiment of this application.

[0017] Figure 2 This is a schematic diagram of a second flowchart of the diagnostic method according to an embodiment of this application.

[0018] Figure 3 This is a schematic diagram of the third type of diagnostic method according to an embodiment of this application.

[0019] Figure 4 This is a schematic diagram of the fourth process of the diagnostic method according to an embodiment of this application.

[0020] Figure 5 This is a schematic diagram of the fifth type of diagnostic method according to an embodiment of this application.

[0021] Figure 6 This is a schematic diagram of the structure of the diagnostic device according to an embodiment of this application.

[0022] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

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

[0024] In complex embedded devices in fields such as vehicles and industrial control, the built-in diagnostic logic is typically hard-coded directly into the firmware. Taking vehicles as an example, electronic control units (such as T-Boxes) must comply with diagnostic protocols such as OBD-II and ISO14229. The related diagnostic support logic includes the determination of specific diagnostic fault codes (DTCs) and data identifiers (DIDs), requiring extensive use of #ifdef macros or if-else conditional branches directly coded into the C / C++ firmware. This implementation severely limits system flexibility, making it difficult to adapt to diverse needs arising from differences in hardware configurations (e.g., high-end / low-end models), software version iterations, or different market regulations (e.g., new EU emission diagnostic requirements). To cover all possible scenarios, device manufacturers must develop, test, and maintain multiple firmware versions for different vehicle configurations or market regions, leading to complex software branch management, increased version fragmentation, and difficulty in ensuring functional consistency between versions. Even more serious is that any adjustment to the diagnostic logic for a specific configuration (such as supporting new DTCs to meet new regulations) requires a full firmware upgrade. This not only significantly increases maintenance costs but also greatly increases the risk of introducing new faults due to modifications to the underlying code. Such problems are also prevalent in other complex embedded systems, and will not be elaborated upon here.

[0025] Therefore, this application provides a diagnostic method, device, and storage medium, aiming to solve the problems of poor adaptability, high maintenance costs, and high upgrade risks caused by directly writing diagnostic logic into firmware code in the prior art. The technical solutions provided by various embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] One embodiment of this application provides a diagnostic method that can be applied to a target electronic device (operating system). Figure 1 This is a flowchart illustrating the diagnostic method, which includes the following steps: S101, Based on the pre-configured diagnostic rule definition file, a diagnostic rule database is generated; wherein, the diagnostic rule definition file is independent of the firmware of the target electronic device; the diagnostic rule database is used to record multiple diagnostic items configured in the diagnostic rule definition file and their corresponding supporting rules, and the supporting rules are logical judgment conditions based on device configuration information.

[0027] This embodiment first generates a diagnostic rule database based on a pre-configured diagnostic rule definition file. This diagnostic rule definition file uses a structured data format (such as JSON or XML) independent of the device firmware, is written and maintained by diagnostic engineers, and its core function is to serve as the authoritative data source for diagnostic business rules. It should be noted that the diagnostic rule definition file itself is not executable code, but rather a declarative configuration description file. The system parses this file using an offline compilation toolchain (such as a Python script) running in the development environment, converting it into an optimized binary format—the diagnostic rule database. This conversion process is similar to the compilation process of a high-level programming language, compiling human-readable rule "source code" into "object code" that the embedded device can efficiently read at runtime.

[0028] The diagnostic rule database primarily records two types of key information: diagnostic items and their corresponding supporting rules. Diagnostic items refer to entity objects whose support status needs to be queried. In a vehicle scenario, this can be specifically represented as diagnostic fault codes (e.g., DTCP0128 indicating abnormal engine coolant temperature) or data identifiers (e.g., DID 0xF12C used to obtain specific sensor data). Supporting rules are Boolean logic expressions based on device configuration vectors, used to dynamically determine the activation status of diagnostic items.

[0029] Taking a vehicle as an example, the support rule for diagnostic item P0128 can be defined as: (Market Region == "EU") && Vehicle Configuration == "High-end". This means that the system will only enable support for this diagnostic item when the device detects that the current vehicle is sold in the Chinese or EU market and is a high-end model. Through this rule-based expression, the system achieves complete decoupling between diagnostic logic and firmware code, laying a solid foundation for subsequent dynamic evaluation and flexible configuration.

[0030] It should be understood that this embodiment achieves complete decoupling between diagnostic logic and firmware code through this structured expression of diagnostic support rules. Specifically, traditional implementations hard-code diagnostic support rules directly into the firmware source code (C / C++, etc.), requiring any rule adjustments to necessitate modification, recompilation, and firmware upgrades. This solution innovatively extracts diagnostic rules from the program code, making them independently stored structured data entities. This decoupled architecture brings a fundamental change: changes to diagnostic rules are no longer equivalent to firmware changes. When adjustments to the diagnostic support strategy are needed, such as adding diagnostic items to comply with new market regulations or modifying the activation conditions of existing diagnostic items, engineers only need to update the external diagnostic rule definition file and regenerate the diagnostic rule database using the accompanying toolchain. The entire process does not involve any modification to the firmware source code, thus eliminating the need for cumbersome firmware compilation, full testing, and OTA upgrade procedures.

[0031] S102, when certain conditions are met, based on the current target device configuration information of the target electronic device, it is determined whether the support rules corresponding to each diagnostic item in the diagnostic rule database are met, and a diagnostic support snapshot is generated. The diagnostic support snapshot records the support status of each diagnostic item in the diagnostic rule database under the target device configuration information.

[0032] In this embodiment, when specific conditions are met, the system will perform centralized logical judgment on the support rules corresponding to each diagnostic item in the diagnostic rule database based on the target electronic device's current target device configuration information (including a configuration vector composed of parameters such as hardware version, activated function licenses, and regional settings). This process is executed by the built-in rule evaluation engine, which traverses all diagnostic items in the database, substitutes the actual value of the current configuration vector into the Boolean expression corresponding to each diagnostic item for real-time calculation, and determines whether the diagnostic item is supported based on the expression result (true or false): if the expression is true, it is marked as "supported"; otherwise, it is marked as "not supported". It should be noted that the diagnostic rule database essentially covers all diagnostic items that the device may be involved in, and the system can automatically and accurately filter out a subset of effective diagnostic items applicable to the current scenario based on the actual configuration vector. This dynamic identification mechanism has good versatility and can be widely adapted to the diverse configuration needs of various electronic devices. For device manufacturers, there is no need to develop and maintain multiple independent firmware versions for different configuration combinations, thus fundamentally solving the version fragmentation problem caused by hard coding, and significantly reducing the complexity and cost of long-term system maintenance.

[0033] The support status of each diagnostic item determined by the above process is recorded by the diagnostic support snapshot mechanism. The diagnostic support snapshot is essentially a concise, read-only query directory that clearly records the final support status (usually represented by a Boolean value of true or false) of each diagnostic item in the diagnostic rule base under the current device configuration. Its purpose is that when the system needs to query whether a diagnostic item is supported, it can simply perform a quick lookup in this snapshot, like looking up a dictionary, to obtain a definite result.

[0034] In practical applications, the aforementioned specific conditions mainly include two scenarios: first, changes in the device configuration information of the target electronic device, such as updating the vehicle's market configuration or functional characteristics via OTA; and second, a system restart of the target electronic device. To address the issue of lost diagnostic support snapshots in the cache after a system restart, this solution establishes an intelligent recovery mechanism. During a system cold start, when a valid diagnostic support snapshot is detected not being loaded into the cache, the system will prioritize attempting to load a pre-stored diagnostic support snapshot from non-volatile memory into the cache. This mechanism ensures that the system can immediately restore its ability to quickly query the status of diagnostic item support after a restart, avoiding the need to re-execute the time-consuming rule evaluation process. This allows the system to recover to normal operation within tens of milliseconds, significantly improving system startup efficiency and business continuity.

[0035] S103, in response to a diagnostic request for a target diagnostic item, the support status of the target diagnostic item is determined by querying the diagnostic support snapshot.

[0036] This embodiment determines the support status of a target diagnostic item by querying a pre-generated diagnostic support snapshot. Based on the foregoing, a diagnostic support snapshot can be understood as a static mapping table recording the support status of all diagnostic items under the current device configuration, transforming complex rule logic judgments into simple key-value pair queries. This design allows the system to obtain accurate support status results through a single efficient query operation, rather than re-executing time-consuming support rule evaluations each time a diagnostic request is processed, greatly improving the system's response efficiency.

[0037] To improve the query performance of diagnostic support status, this embodiment loads diagnostic support snapshots into the high-speed memory cache of the target electronic device, thereby optimizing the query path from complex rule parsing or external storage access to efficient direct memory access. Specifically, each diagnostic query request no longer needs to perform support rule calculations or read non-volatile memory, but can be completed through a single cache query. This reduces the query time complexity from O(n) or O(log n) to the O(1) constant level, and the query latency is significantly reduced from milliseconds to microseconds or even nanoseconds, thus meeting the real-time requirements of high-concurrency diagnostic scenarios. In addition, this mechanism effectively avoids the I / O bottleneck and additional power consumption caused by frequent access to external storage, significantly reducing the computational burden and data parsing overhead of the system CPU, thereby further improving system energy efficiency and resource utilization.

[0038] In implementing cache loading, this embodiment employs atomic operations to load the entire diagnostic support snapshot into the cache. An atomic operation is an uninterruptible operation or series of operations in a computer system; these operations either execute completely or not at all, avoiding partial execution. This mechanism ensures the integrity and consistency of cached data during the update process, effectively preventing data contention issues such as dirty reads and dirty writes that may occur in concurrent query scenarios. Specifically, the atomic loading mechanism is implemented through hardware-level atomic instructions or software-level synchronization primitives, ensuring that when updating the cache, the query operation either fully reads the old version of the snapshot data or fully reads the new version of the snapshot data, without reading partially updated or invalid snapshot data in an intermediate state. It should be understood that atomic operations are key to implementing hot updates of diagnostic item support rules, allowing the system to safely complete dynamic updates of the diagnostic support status without downtime or service interruption. In scenarios with extremely high continuity requirements, such as vehicle operation, this uninterrupted update capability is particularly important, ensuring the continuity of diagnostic functions.

[0039] Furthermore, to further enhance the reliability of diagnostic execution, this embodiment also persistently stores diagnostic support snapshots in the non-volatile memory of the target electronic device, thereby establishing a multi-level query guarantee mechanism. Specifically, when querying the diagnostic support snapshot from the cache fails, the system automatically switches to querying the backup diagnostic support snapshot stored in the non-volatile memory. This design introduces an additional non-volatile storage backup layer in addition to the memory-based cache layer, forming a hierarchical data protection architecture that effectively improves the system's fault tolerance and data reliability. The value of this mechanism in practical applications lies in the fact that when the cache is cleared due to system restart, abnormal power failure, or memory errors, the system can still directly restore the complete diagnostic support snapshot from the non-volatile memory, ensuring the continuous availability of diagnostic services under abnormal conditions. Simultaneously, to further enhance system robustness, this embodiment further introduces a data integrity verification mechanism during the process of storing the diagnostic support snapshot in the non-volatile memory. Specifically, when writing a diagnostic support snapshot, the system simultaneously generates corresponding verification data (such as a CRC checksum or hash value). When subsequently reading the snapshot, the system prioritizes verifying its integrity using this verification data, effectively identifying data errors caused by partial damage to the storage medium, unexpected power outages during the writing process, or other abnormal situations. This mechanism can promptly block the use of corrupted snapshots, preventing misjudgments of diagnostic status due to data errors. When integrity verification fails, indicating that the snapshot is unavailable, the system automatically triggers a recovery process. It regenerates a new diagnostic support snapshot based on the diagnostic rule database and the current device configuration, reloads it into the cache, updates it in the non-volatile memory, and simultaneously refreshes the corresponding verification data to continuously ensure the reliability of persistent data and the continuity of system services.

[0040] Furthermore, as the ultimate guarantee of system reliability, this embodiment establishes a third-layer fault-tolerance system based on a static fallback list. During the compilation phase, the system extracts key diagnostic items from the diagnostic rule definition file and embeds them as code into a static fallback list within the device firmware. When neither the diagnostic support snapshots in the memory cache nor the non-volatile memory can provide a valid query, the system automatically falls back to querying this static list, determining its support status by verifying whether the target diagnostic item exists in the list. This design ensures that even in the most extreme system failure scenarios, such as cache corruption accompanied by complete storage media failure, the core diagnostic functions can still be maintained through the preset key diagnostic items in the firmware.

[0041] Taking vehicle applications as an example, this static rollback list specifically includes two core functions related to driving safety: brake system diagnostics and emergency call diagnostics. By permanently embedding the brake system diagnostics, the system can continuously monitor key brake system parameters and trigger fault alarms even in the event of a vehicle-wide network anomaly or complete failure of the storage system, meeting the fault tolerance requirements of the ISO 26262 standard for the highest safety level systems. Simultaneously, the permanent presence of the emergency call diagnostics ensures that the diagnostic functions required to establish an emergency communication link are absolutely reliable in the event of a collision, building a crucial last line of defense for occupant safety. This layered and progressive fault-tolerant architecture enables the system to maintain a minimum level of safe diagnostic capabilities even when facing multiple faults, providing a solid foundation for high-reliability applications such as intelligent connected vehicles.

[0042] S104. If the support status of the target diagnostic item indicates support, then execute the diagnostic process for the target diagnostic item.

[0043] Once the target diagnostic item is confirmed to be in a "supported" state, this embodiment immediately triggers the execution of its corresponding diagnostic process, thereby seamlessly connecting the aforementioned support status judgment mechanism with the actual diagnostic operation and constructing a complete closed loop from "whether a diagnosis can be made" to "execution of the diagnosis".

[0044] It should be noted that the specific execution of the diagnostic process varies depending on the type of diagnostic item. Taking a typical vehicle system as an example, for data identifier-type diagnostic items, the system will perform corresponding data read and write operations, such as reading the voltage and current parameters of the battery management system, or writing specific configuration parameters to the relevant ECU; for fault diagnosis code-type diagnostic items, the system will activate the corresponding fault detection algorithm, such as continuously monitoring whether the engine coolant temperature exceeds the normal range, and generating a standard format fault code when an abnormality is confirmed.

[0045] In practical applications, this embodiment constructs a complete three-layer data redundancy structure to achieve the optimal balance between performance and reliability in diagnostic queries. Specifically: The first layer is a memory cache layer, which loads diagnostic support snapshots into the device's high-speed memory and uses data structures such as hash tables to achieve fast lookups with O(1) time complexity, providing performance guarantees for high-frequency diagnostic requests under normal system operation. The second layer is a non-volatile storage backup layer, which persistently stores diagnostic support snapshots in non-volatile storage such as Flash, establishing a second level of data protection. When the memory cache fails, the system can quickly restore the diagnostic state from this layer, effectively handling common abnormal scenarios such as system restarts; The third layer is the firmware static rollback layer, which embeds key diagnostic items related to the core functions of the system into the device firmware in the form of code. In the extreme case where both of the current two layers of storage fail, the system can roll back to this layer to maintain a minimum level of diagnostic capability and ensure the continued availability of core functions.

[0046] It should be understood that this three-layer data redundancy structure forms a fault-tolerant system with progressive degradation: the first layer ensures performance, the second layer ensures availability, and the third layer ensures security. Through this hierarchical design, the system can provide ultimate performance under normal conditions and gracefully degrade under abnormal conditions, providing various embedded devices with flexible diagnostic capabilities to adapt to different operating conditions.

[0047] in, Figure 2 This embodiment demonstrates a complete three-tier data redundancy architecture, covering the entire process from offline development to online operation. In the offline environment, engineers write structured diagnostic rule definition files (usually in JSON or XML format) according to business requirements. These files are then compiled and converted using a dedicated offline compilation toolchain to generate an optimized diagnostic rule database that can be efficiently read by embedded devices for deployment to the target electronic device. Upon entering the online runtime environment, the target electronic device system, under specific conditions, performs a full evaluation of diagnostic item support rules on the diagnostic rule database based on the current device configuration vector. This evaluation process is completed through a built-in rule engine, ultimately generating a complete diagnostic support snapshot. This snapshot records the specific support status of each diagnostic item under the current device configuration. The diagnostic support snapshot will establish a safeguard mechanism from three dimensions: First, the diagnostic support snapshot will be fully loaded into the cache of the target electronic device, and real-time queries with O(1) time complexity will be achieved through data structures such as hash tables; Second, the diagnostic support snapshot will be fully persisted to non-volatile memory to establish a reliable backup data source, ensuring that the system can quickly restore diagnostic query capabilities after restarting and avoiding repeated execution of time-consuming rule evaluations; Third, the key diagnostic items that must be supported in the diagnostic support snapshot and the key diagnostic items that are natively specified to be supported in the firmware will be written in code and solidified into the static rollback list of the device firmware to build the final fault-safe defense.

[0048] Correspondingly, Figure 3The complete query process for handling diagnostic requests is demonstrated: When the system receives a query request for a target diagnostic item, it first queries the diagnostic support snapshot in the first-level memory cache. If a valid snapshot exists in the cache and the target diagnostic item is matched, its support status is immediately returned. If the cache misses (i.e., the target diagnostic item is not in the current snapshot) or there is no valid snapshot in the cache (e.g., the system has just started and has not yet been initialized), the system queries the second-level non-volatile memory. When the second-level query also fails to provide a valid result (including the absence of a diagnostic support snapshot, failure of data integrity verification of the diagnostic support snapshot, and the target diagnostic item still not being matched), the system queries the static rollback list in the third-level firmware. This strict hierarchical query mechanism reflects the design principle of "performance first, reliability as a fallback," ensuring a reliable response to diagnostic requests in most abnormal situations through a step-by-step rollback strategy. This guarantees query efficiency during normal operation while preserving basic diagnostic functions during extreme failures.

[0049] also, Figure 4 This demonstrates the process of rebuilding a diagnostic support snapshot when a system restart causes the loss of the cached snapshot. After system startup, it first checks if a valid (i.e., data integrity verified) diagnostic support snapshot is stored in the second-level non-volatile memory. If it exists, it is directly loaded into the first-level cache to quickly restore query capabilities. If it does not exist, the evaluation process for support rules is restarted: based on the current device configuration vector, a full evaluation of diagnostic support rules is performed using the diagnostic rule database, generating a new diagnostic support snapshot. Subsequently, a dual-write operation is performed, simultaneously loading the snapshot into the cache and persisting it to the non-volatile memory. This intelligent recovery mechanism maximizes system startup efficiency while ensuring data integrity, while the third-level static fallback list provides ultimate security throughout the process, forming a complete fault-tolerant closed loop.

[0050] also, Figure 5This demonstrates the process of rebuilding diagnostic support snapshots when diagnostic rule definition files are updated. In an offline environment, engineers write new diagnostic rule definition files, which are then compiled using offline tools to generate a new diagnostic rule database and deployed to the target electronic device. In an online environment, the system re-evaluates the support rules for each diagnostic item based on the current device configuration vector and the new diagnostic rule database, generating a new diagnostic support snapshot. Subsequently, the new snapshot is fully loaded into the cache (first layer) via atomic operations and simultaneously persisted to non-volatile memory (second layer). It's important to note that during the atomic update process, the system checks if the old diagnostic support snapshot is still in use. If it is confirmed to be unused, the old snapshot is cleaned up to ensure effective release of storage resources. This process enables hot updates of diagnostic support snapshots, ensuring data consistency and service continuity while smoothly switching diagnostic support states.

[0051] In summary, the core of this embodiment lies in decoupling diagnostic logic from the firmware and achieving efficient and reliable diagnostic capability assessment through dynamic evaluation and pre-generated snapshots. Specifically, the solution first compiles and generates a diagnostic rule database based on a diagnostic rule definition file independent of the firmware. This database records multiple diagnostic items and their corresponding supporting rules, where the supporting rules are logical judgment conditions based on device configuration information. Subsequently, when specific conditions are met, the supporting rules for each diagnostic item in the database are centrally evaluated based on the target electronic device's current device configuration information, generating a diagnostic support snapshot that records the support status of all diagnostic items under the current configuration. Finally, upon receiving a diagnostic request for a specific target diagnostic item, the diagnostic support snapshot is directly queried to determine whether the target electronic device supports the target diagnostic item. If the support status is true, the corresponding diagnostic process is triggered. Through the above mechanism, this solution achieves multiple technical benefits: Firstly, it generates a diagnostic rule database independent of the firmware by defining diagnostic rules in the diagnostic rule definition file. The support rules for each diagnostic item in this database, combined with the current device configuration information, automatically determine the support status of each diagnostic item. This allows the diagnostic item support status determination mechanism to flexibly adapt to different hardware configurations, software versions, or regulatory scenarios, thus completely solving the problems of poor adaptability and version fragmentation caused by hard coding. Secondly, updating diagnostic rules only requires upgrading the diagnostic rule definition file and regenerating the diagnostic rule database, without modifying or releasing the entire firmware. This significantly reduces maintenance costs and fundamentally avoids system stability risks caused by firmware upgrades. Thirdly, by pre-storing the determined support status of each diagnostic item as a diagnostic support snapshot, when a diagnostic request for a target diagnostic item is received, the system can quickly determine whether the target diagnostic item is supported by statically querying the diagnostic support snapshot, thus ensuring real-time diagnostic response.

[0052] In addition, corresponding to Figure 1 In addition to the method shown, another embodiment of this application also provides a diagnostic device. Figure 6 This is a schematic diagram of the structure of the diagnostic device 600, including: The database generation module 610 generates a diagnostic rule database based on a pre-configured diagnostic rule definition file; wherein, the diagnostic rule definition file is independent of the firmware of the target electronic device; the diagnostic rule database is used to record multiple diagnostic items configured in the diagnostic rule definition file and their corresponding supporting rules, wherein the supporting rules are logical judgment conditions based on device configuration information; The rule judgment module 620, when a specific condition is met, determines whether the support rules corresponding to each diagnostic item in the diagnostic rule database are met based on the current target device configuration information of the target electronic device, so as to generate a diagnostic support snapshot. The diagnostic support snapshot records the support status of each diagnostic item in the diagnostic rule database under the target device configuration information. The status query module 630, in response to a diagnostic request for a target diagnostic item, determines the support status of the target diagnostic item by querying the diagnostic support snapshot; The diagnostic execution module 640 executes the diagnostic process for the target diagnostic item if the support status of the target diagnostic item indicates support.

[0053] Optionally, after generating the diagnostic support snapshot, the method further includes: loading the diagnostic support snapshot into the cache of the target electronic device; the step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot includes: determining the support status of the target diagnostic item by querying the diagnostic support snapshot in the cache. This technical solution achieves extreme optimization of the query path by introducing a caching mechanism to preload the diagnostic support snapshot into the device's high-speed cache area. Compared to accessing slow non-volatile memory or re-executing rule evaluation for each query, directly querying snapshot data from the cache transforms the query operation into a highly efficient memory access, reducing the query time complexity from the original O(n) or O(log n) to the ideal O(1) level, and significantly reducing the query latency from milliseconds to microseconds or even nanoseconds, thereby meeting the real-time requirements of high-frequency diagnostic query scenarios. In addition, this design effectively avoids I / O bottlenecks and additional power consumption caused by frequent reading of external storage media, significantly reduces the computational load and parsing overhead of the system CPU, and allows resources to be more concentrated on critical diagnostic tasks.

[0054] Optionally, loading the diagnostic support snapshot into the cache of the target electronic device includes: loading the diagnostic support snapshot into the cache of the target electronic device using atomic operations. This technical solution ensures the integrity and consistency of cached data during the update process through atomic operations, effectively avoiding data contention issues such as dirty reads and dirty writes that may occur in concurrent query scenarios. Specifically, the atomic loading mechanism ensures that when updating the cache, the query operation reads either the complete old version snapshot data or the complete new version snapshot data, and will not read partially updated or invalid data in an intermediate state, thereby significantly improving the reliability and determinism of the system. In addition, this mechanism is a key technical foundation for realizing hot updates of diagnostic rules. It allows the system to safely complete the dynamic switching of diagnostic support status without downtime or service interruption, further enhancing the practicality and robustness of the system in scenarios with extremely high continuity requirements, such as vehicle operation.

[0055] Optionally, after generating the diagnostic support snapshot, the method further includes: storing the diagnostic support snapshot in the non-volatile memory of the target electronic device; the step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot further includes: if querying the diagnostic support snapshot from the cache fails, then querying the diagnostic support snapshot in the non-volatile memory to determine the support status of the target diagnostic item. This technical solution effectively improves the system's fault tolerance and data reliability by establishing a multi-level query mechanism and introducing a non-volatile storage backup layer on top of the cache. Specifically, when the cache is cleared due to system restart or abnormal clearing, the diagnostic support snapshot can be directly obtained from the non-volatile memory to ensure the continuity of diagnostic services.

[0056] Optionally, based on the diagnostic rule definition file, key diagnostic items that must be supported are determined; the key diagnostic items are written into the static fallback list of the target electronic device in the form of code, wherein the static fallback list is pre-created in the firmware of the target electronic device; the step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot further includes: if querying the diagnostic support snapshot from the non-volatile memory fails, then determining the support status of the target diagnostic item by querying whether the target diagnostic item is written in the static fallback list. This technical solution establishes a three-layer guarantee mechanism, including caching, non-volatile storage backup, and a firmware-level static rollback list, to build a complete system fault tolerance system. The static rollback list serves as the final reliability barrier, ensuring that even in extreme failure scenarios where the cache fails and the diagnostic support snapshot in non-volatile storage is inaccessible, the system can still maintain the operation of core diagnostic functions by querying the key diagnostic items pre-set in the firmware. This design not only minimizes the risk of system function loss due to storage media damage, file system errors, or other unforeseen hardware failures, but also achieves the engineering goal of "not losing core diagnostic capabilities even if the system suffers a serious failure" by embedding relatively important key diagnostic items in read-only memory.

[0057] Optionally, the target electronic device is a vehicle, and the key diagnostic items include brake system diagnostic items and / or emergency call diagnostic items. This technical solution provides the highest level of functional safety assurance for the vehicle diagnostic system by solidifying core diagnostic items related to driving safety and life protection into a static rollback list. Even in extreme fault scenarios (such as complete storage system failure or rule database corruption), the system can still ensure the continued availability of the vehicle's most basic safety diagnostic functions by querying the pre-set brake system and emergency call diagnostic items in the firmware. Specifically, by prioritizing the protection of brake system diagnostic items, the system ensures that the vehicle has continuously available diagnostic capabilities in terms of the most basic active safety functions. Even in extreme cases of network anomalies or complete storage system failure, it can still maintain monitoring of key braking system parameters and fault alarms, meeting the fault tolerance requirements for the highest safety level (ASIL-D) systems in automotive functional safety standards such as ISO 26262. Secondly, the solidified guarantee of emergency call (eCall) diagnostic items ensures that the diagnostic functions on which the vehicle and the rescue center rely to establish a communication link in the event of an emergency such as a collision are absolutely reliable. This avoids the risk of emergency call function failure due to storage system failure and provides a crucial line of defense for occupant safety.

[0058] Optionally, after the target electronic device's system restarts, if the cache does not load the diagnostic support snapshot, and the non-volatile memory stores the diagnostic support snapshot, then the diagnostic support snapshot in the non-volatile memory is loaded into the cache. This technical solution establishes an efficient recovery mechanism for the situation where the diagnostic support snapshot in the cache is lost after a system restart. After a system restart, when it is detected that the diagnostic support snapshot is not loaded in the cache, the pre-stored diagnostic support snapshot in the non-volatile memory is automatically loaded into the cache, ensuring that the system can immediately restore its ability to quickly query the diagnostic item support status after a cold start, without waiting for the time-consuming re-evaluation of the diagnostic item support rules.

[0059] Optionally, the specific conditions include changes in the device configuration information of the target electronic device and / or a system restart of the target electronic device. This technical solution constructs an intelligent and adaptive state synchronization mechanism by clearly defining key events that trigger the re-evaluation of support rules, ensuring a high degree of consistency between the diagnostic support list and the actual operating environment of the device. Its technical effectiveness is mainly reflected in two dimensions: dynamic adaptability and state reliability. Regarding dynamic adaptability, by monitoring changes in device configuration information (e.g., detecting changes in the device's main control unit, additions or removals of peripheral modules, software license updates, or adjustments to regional compliance settings), the system can respond to these dynamic changes in real time, proactively triggering the rule evaluation process to regenerate a diagnostic support snapshot that precisely matches the current hardware, software, and compliance configuration. This mechanism effectively avoids misjudgments of diagnostic functions caused by configuration information lagging behind the actual state, ensuring the real-time accuracy of diagnostic logic and meeting the high requirements for functional configurability of devices in complex and ever-changing field environments. In terms of state reliability, setting system restart as a trigger condition provides a mandatory synchronization and calibration opportunity for diagnostic state. After a cold / warm boot, the system can ensure that the diagnostic support list in memory is a completely new state that is fully consistent with the current system base environment by reloading or evaluation. This effectively clears any temporary state errors or data inconsistencies that may have existed during previous runtime, providing a reliable basis for system diagnostic queries.

[0060] It should be noted that the specific methods by which each module performs its operation in the diagnostic device described in the above embodiments have been described in detail in the embodiments of the method, and will not be elaborated here.

[0061] In addition, another embodiment of this application provides an electronic device. Figure 7This is a schematic diagram of the electronic device, including a memory 701 and a processor 702. The memory 701 stores executable program code 7011, and the processor 702 is used to call and execute the executable program code 7011 to perform the electronic device control method provided in the above embodiment. The corresponding steps include: A diagnostic rule database is generated based on a pre-configured diagnostic rule definition file. The diagnostic rule definition file is independent of the firmware of the target electronic device. The diagnostic rule database is used to record multiple diagnostic items configured in the diagnostic rule definition file and their corresponding supporting rules. The supporting rules are logical judgment conditions based on device configuration information.

[0062] When certain conditions are met, based on the current target device configuration information of the target electronic device, it is determined whether the support rules corresponding to each diagnostic item in the diagnostic rule database are met, and a diagnostic support snapshot is generated. The diagnostic support snapshot records the support status of each diagnostic item in the diagnostic rule database under the target device configuration information.

[0063] In response to a diagnostic request for a target diagnostic item, the support status of the target diagnostic item is determined by querying the diagnostic support snapshot.

[0064] If the support status of the target diagnostic item indicates support, then the diagnostic process for the target diagnostic item is executed.

[0065] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each module can correspond to a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0066] When each functional module is divided according to its corresponding function, the electronic device may include: a database generation module, a rule judgment module, a status query module, and a diagnostic execution module. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0067] When using integrated units, the electronic device may include a processing module and a storage module. The processing module is used to control and manage the operation of the electronic device. The storage module is used to support the execution of program code and data by the electronic device.

[0068] The processing module may be a processor or a controller, which can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and microprocessors, etc., and the storage module may be a memory.

[0069] Furthermore, another embodiment of this application provides a computer-readable storage medium storing computer program code. When the computer program code is executed on a computer, the computer performs the aforementioned method steps to implement a diagnostic method provided in the above embodiments, which includes the following steps: A diagnostic rule database is generated based on a pre-configured diagnostic rule definition file. The diagnostic rule definition file is independent of the firmware of the target electronic device. The diagnostic rule database is used to record multiple diagnostic items configured in the diagnostic rule definition file and their corresponding supporting rules. The supporting rules are logical judgment conditions based on device configuration information.

[0070] When certain conditions are met, based on the current target device configuration information of the target electronic device, it is determined whether the support rules corresponding to each diagnostic item in the diagnostic rule database are met, and a diagnostic support snapshot is generated. The diagnostic support snapshot records the support status of each diagnostic item in the diagnostic rule database under the target device configuration information.

[0071] In response to a diagnostic request for a target diagnostic item, the support status of the target diagnostic item is determined by querying the diagnostic support snapshot.

[0072] If the support status of the target diagnostic item indicates support, then the diagnostic process for the target diagnostic item is executed.

[0073] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0074] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual 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 functions described above.

[0075] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0076] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0077] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A diagnostic method applied to a target electronic device, characterized in that, include: A diagnostic rule database is generated based on a pre-configured diagnostic rule definition file; wherein, the diagnostic rule definition file is independent of the firmware of the target electronic device; the diagnostic rule database is used to record multiple diagnostic items configured in the diagnostic rule definition file and their corresponding supporting rules, wherein the supporting rules are logical judgment conditions based on device configuration information; When certain conditions are met, based on the current target device configuration information of the target electronic device, it is determined whether the support rules corresponding to each diagnostic item in the diagnostic rule database are met, so as to generate a diagnostic support snapshot. The diagnostic support snapshot records the support status of each diagnostic item in the diagnostic rule database under the target device configuration information. In response to a diagnostic request for a target diagnostic item, the support status of the target diagnostic item is determined by querying the diagnostic support snapshot. If the support status of the target diagnostic item indicates support, then the diagnostic process for the target diagnostic item is executed.

2. The method according to claim 1, characterized in that, After generating the diagnostic support snapshot, the method further includes: The diagnostic support snapshot is loaded into the cache of the target electronic device; The step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot includes: The support status of the target diagnostic item is determined by querying the diagnostic support snapshot in the cache.

3. The method according to claim 2, characterized in that, The step of loading the diagnostic support snapshot into the cache of the target electronic device includes: The diagnostic support snapshot is loaded into the cache of the target electronic device using atomic operations.

4. The method according to claim 2, characterized in that, After generating the diagnostic support snapshot, the method further includes: The diagnostic support snapshot is stored in the non-volatile memory of the target electronic device; The step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot further includes: If querying the diagnostic support snapshot from the cache fails, the support status of the target diagnostic item is determined by querying the diagnostic support snapshot in the non-volatile memory.

5. The method according to claim 4, characterized in that, Also includes: Based on the diagnostic rule definition file, the key diagnostic items that must be supported are determined; The key diagnostic items are written into the static rollback list of the target electronic device in the form of code, wherein the static rollback list is pre-created in the firmware of the target electronic device; The step of determining the support status of the target diagnostic item by querying the diagnostic support snapshot further includes: If querying the diagnostic support snapshot from the non-volatile memory fails, the support status of the target diagnostic item is determined by querying the static rollback list to see if the target diagnostic item is written.

6. The method according to claim 5, characterized in that, The target electronic device is a vehicle, and the key diagnostic items include brake system diagnostic items and / or emergency call diagnostic items.

7. The method according to claims 4 to 6, characterized in that, Also includes: If the diagnostic support snapshot is not loaded in the cache after the target electronic device's system restarts, and the diagnostic support snapshot is stored in the non-volatile memory, then the diagnostic support snapshot in the non-volatile memory is loaded into the cache.

8. The method according to claims 1 to 6, characterized in that, The specific conditions include changes in the device configuration information of the target electronic device and / or a system restart of the target electronic device.

9. An electronic device, comprising: processor; And a memory arranged to store computer-executable instructions, characterized in that, when executed, the executable instructions cause the processor to perform the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 8.

Images