Diagnostic software gray release method and device, equipment and medium

Abstract

The invention discloses a diagnostic software gray release method and device, equipment and a medium, and the method comprises the steps: generating a gray release strategy according to the functional risk level of to-be-released new-version diagnostic software in combination with a pre-constructed user group portrait database; pushing the new-version diagnostic software to a target user group in the user group portrait database according to the gray release strategy; acquiring key business index data of the new version diagnostic software operated in the target user group; and the server compares the received key business index data with a preset dynamic threshold value, and automatically triggers a corresponding decision instruction according to a comparison result, and the decision instruction comprises a rollback instruction, an amount amplification instruction or a pause instruction.

Description

Technical Field

[0001] This application relates to the field of automotive diagnostic technology, specifically to a method, apparatus, device, and medium for grayscale release of diagnostic software. Background Technology

[0002] With the increasing intelligence of automotive electronics, fault diagnosis relies more and more on specialized diagnostic software. Modern diagnostic software is evolving towards greater functional complexity, massive data volumes, and frequent updates. To improve software maintainability, scalability, and deployment efficiency, software modularization and cloud-based services have become the mainstream technical architecture. Under this architecture, advanced functions of diagnostic software (such as calibration flashing, ECU control unit programming, and coding) are broken down into independent modules and centrally deployed on cloud servers. Clients (such as diagnostic tools and tablets) interact with the cloud via the network, loading diagnostic data and execution logic specific to different vehicle models on demand. This model greatly simplifies client maintenance and enables centralized data management and real-time updates.

[0003] However, releasing new versions of diagnostic software (including feature updates, algorithm optimizations, support for new vehicle models, and security patches) still faces significant challenges. The traditional full-release model, which pushes the new version to all users at once, has the following prominent issues that urgently need to be addressed: High-risk exposure: New versions may introduce unknown serious defects or performance bottlenecks. For example, a flawed ECU remapping algorithm, once fully released, could cause a large number of vehicles to become unusable, triggering huge repair claims.

[0004] Problem localization is difficult: When a large-scale failure occurs after a full release, the wide range of impacts and diverse user environments make problem localization extremely difficult. Fault manifestations vary across different vehicle models, diagnostic equipment, and network environments, requiring engineers to spend several days sifting through massive amounts of logs for useful information, significantly extending the fault recovery time.

[0005] High repair costs: If a problem is found after a full release, an emergency patch needs to be developed and another full update needs to be performed. This process not only incurs high maintenance costs, but more seriously, it is difficult to notify and guide all affected users (especially maintenance technicians who are on duty) to complete the update in a timely manner. The losses caused during this period continue to expand and become irreversible.

[0006] Lack of rollback mechanism: Traditional solutions lack an effective automatic rollback mechanism. Emergency rollback operations are complex, require manual intervention, and can take several hours. During the rollback process, user diagnostic services are completely interrupted, severely impacting the normal operation of repair shops.

[0007] Delayed user feedback: User feedback is only collected after the full release, making it impossible to obtain usage data for the new version across different groups in a timely manner. For critical information such as user experience issues and performance, it often takes several weeks to collect sufficient samples, severely slowing down the product optimization and iteration cycle.

[0008] Insufficient data feedback accuracy: Traditional methods struggle to accurately differentiate usage data from different user groups. The inability to accurately analyze key indicators such as "the diagnostic success rate of the new version among expert technicians" and "the usage frequency of new features in 4S store scenarios" leads to a lack of data support for product decisions.

[0009] The essence of these problems lies in the fact that existing technologies lack accurate user segmentation capabilities, intelligent monitoring and early warning mechanisms, and automated decision rollback systems, which cannot meet the stringent requirements of modern diagnostic software for release security and reliability.

[0010] The preceding description is intended to provide general background information and does not necessarily constitute prior art. Summary of the Invention

[0011] This application provides a method, apparatus, device, and medium for the gray-scale release of diagnostic software, which can solve the problems of existing technologies that cannot achieve accurate grouping, automatic decision-making, and rapid rollback.

[0012] In a first aspect, embodiments of this application provide a method for the gray-scale release of diagnostic software, the method comprising: Based on the functional risk level of the new version of the diagnostic software to be released, and combined with the pre-built user profile database, a canary release strategy is generated. According to the gray-scale release strategy, the new version of the diagnostic software is pushed to the target user group in the user group profile database; Acquire key business metrics data of the new version of the diagnostic software when running the new version on the target user group; The received key business indicator data is compared with a preset dynamic threshold, and the corresponding decision instruction is automatically triggered based on the comparison result. The decision instruction includes a rollback instruction, a volume increase instruction, or a pause instruction.

[0013] Furthermore, in some embodiments of this application, the pre-built user group profile database includes: constructing a user group profile database based on acquired user data; the user group profile database includes several user groups with different risk levels; The user data includes at least one of user attribute data, behavior data, device information data, and user preference data; The user attribute data includes at least one of the following: user ID, type of organization, and certified technician level; The behavioral data includes at least one of the following: historical diagnostic records, diagnostic operation success rate, average diagnostic time, and historical test participation records. The device information data includes at least one of the following: diagnostic instrument model, hardware configuration, and common network environments. The user preference data includes at least one of the following: frequency of function use and proactive feedback information.

[0014] Furthermore, in some embodiments of this application, the step of constructing a user group profile database based on the acquired user data includes: establishing a user evaluation model based on four dimensions: skill level, business fault tolerance rate, diagnostic vehicle value, and willingness to provide feedback on issues; classifying users into levels with different risk levels based on the comprehensive score output by the user evaluation model, and setting a dynamic threshold corresponding to each level; and automatically adjusting the risk level to which the user belongs when a change is detected in the user's historical diagnostic success rate or feedback activity.

[0015] Furthermore, in some embodiments of this application, the step of generating a canary release strategy based on the functional risk level of the new version of the diagnostic software to be released, combined with a pre-built user profile database, includes: The functional risk level is determined based on the scope of business impact and the degree of security criticality of the diagnostic function modules modified or added in the new version of the diagnostic software to be released. The canary release strategy is generated based on the mapping relationship between the functional risk level of the new version of the diagnostic software to be released and the risk level of the user group in the user group profile database.

[0016] Furthermore, in some embodiments of this application, the canary release strategy is generated based on the mapping relationship between the functional risk level of the new version of the diagnostic software to be released and the risk level of the user group, including: The new version of the diagnostic software with a high risk level will be prioritized for release to users with a high risk level. The new version of the diagnostic software, which has a low risk level for the aforementioned functions, will be released to users with low risk levels.

[0017] Furthermore, in some embodiments of this application, obtaining key business indicator data of the new version of the diagnostic software running on the target user group includes: The key business performance data includes at least one of the following: diagnostic connection success rate, fault code reading success rate, fault code clearing success rate, specific data stream reading time, electronic control unit flashing success rate, and user negative feedback rate. The key business indicator data with tags is obtained by monitoring the period or in real time. The tags include at least one of the following: user group identifier, software version identifier, executed functional module identifier, diagnosed vehicle model identifier, and timestamp.

[0018] Furthermore, in some embodiments of this application, the step of comparing the received key business indicator data with a preset dynamic threshold and automatically triggering a corresponding decision instruction based on the comparison result includes a rollback instruction, a volume increase instruction, or a pause instruction, comprising: If any of the aforementioned key business indicators remains below its corresponding dynamic threshold for N consecutive monitoring periods, a decision instruction to issue a rollback instruction will be triggered. If all the aforementioned key business indicator data are better than or equal to the historical baseline value within M consecutive monitoring periods, a decision instruction to increase volume is triggered. If the key business indicator data fluctuates but does not reach the dynamic threshold, a decision instruction to pause is triggered.

[0019] Secondly, embodiments of this application provide a diagnostic software gray-scale release apparatus, the apparatus comprising: The strategy generation module is used to generate a canary release strategy based on the functional risk level of the new version of the diagnostic software to be released, combined with a pre-built user profile database. The push module is used to push the new version of the diagnostic software to the target user group in the user group profile database according to the gray-scale release strategy; it is also used to push decision instructions to the target user group. The data acquisition module is used to acquire key business indicator data of the new version of the diagnostic software running on the target user group; The decision execution module is used to compare the received key business indicator data with preset dynamic thresholds and automatically trigger corresponding decision instructions based on the comparison results. The decision instructions include rollback instructions, volume increase instructions, or pause instructions.

[0020] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the second aspect.

[0021] Fourthly, embodiments of this application provide a storage medium storing a computer program that can be loaded by a processor and executed as described in the second aspect.

[0022] This application provides a method, apparatus, device, and medium for the gray-scale release of diagnostic software. By constructing a refined user group profile database, this application achieves precise release strategies and controllable risks, completely changing the traditional one-size-fits-all full release model. This allows high-risk new software versions to be preferentially verified on a small scale by user groups with strong technical capabilities, high fault tolerance, and positive feedback, thereby minimizing the impact of potential defects and greatly reducing the risk of widespread business interruption caused by software updates. By collecting and comparing key business indicator data related to diagnostic business in real time with dynamic thresholds, the application achieves intelligent and objective decision-making processes, eliminating the lag of relying on subjective human judgment. Based on real business data such as diagnostic connection success rate and electronic control unit write success rate, it can identify performance anomalies or functional defects within seconds and automatically trigger corresponding decision commands. Through automatic execution of rollback, ramp-up, or pause commands by the client, the application achieves automated and efficient problem response. In particular, when a deterministic defect is discovered, the application can quickly and seamlessly roll back the software to a stable version, minimizing fault recovery time, ensuring the continuity of user business, and avoiding economic losses. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0024] Figure 1 This is a flowchart illustrating the gray-scale release method for diagnostic software provided in an embodiment of this application; Figure 2 This is another flowchart illustrating the canary release method for diagnostic software provided in this application embodiment; Figure 3 This is another flowchart illustrating the gray-scale release method for diagnostic software provided in the embodiments of this application; Figure 4 This is another flowchart illustrating the gray-scale release method for diagnostic software provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the diagnostic software grayscale release device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with those detailed in the appended claims or with some aspects of this application.

[0026] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover descriptions such as non-exclusive inclusion, thereby ensuring that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0027] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0028] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0029] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for canary deployment of diagnostic software according to an embodiment of this application. This embodiment primarily uses the application of the canary deployment method to a remote server as an example. Specifically, the method for canary deployment of diagnostic software according to an embodiment of this application may include the following steps: Step S1: Construct a user group profile database based on the acquired user data; the user group profile database includes several user groups with different risk levels; Specifically, the server constructs a user profile database using user data obtained from the client. This user data includes at least one of user attribute data, behavioral data, device information data, and user preference data. User attribute data includes at least one of user ID, affiliated institution type, and certified technician level. Behavioral data includes at least one of historical diagnostic records, diagnostic operation success rate, average diagnostic time, and historical test participation records. Device information data includes at least one of diagnostic instrument model, hardware configuration, and common network environments. Based on this user data, the server establishes a user evaluation model from four dimensions: skill level, business fault tolerance, diagnostic vehicle value, and willingness to provide feedback. A comprehensive score is output through machine learning or a rule engine. The risk level is divided into L4 to L0 from high to low, where: L4 corresponds to the internal testing group, used for initial verification of the highest-risk functions; L3 corresponds to the expert user group, used for verification of medium-to-high-risk functions; L2 corresponds to the new energy vehicle user group, used for verification of specific functions; L1 corresponds to the 4S store standard user group, used for verification before widespread release; and L0 corresponds to the basic skills user group, only receiving releases after the version is highly stable. Each risk level corresponds to a specific dynamic threshold, and when changes in user behavior are detected (such as fluctuations in historical diagnosis success rate or feedback activity), the risk level of the user is automatically adjusted to ensure the real-time nature and accuracy of the profile database, providing a data foundation for subsequent differentiated gray-scale releases.

[0030] Step S2: Based on the functional risk level of the new version of the diagnostic software to be released, and combined with the pre-built user profile database, generate a canary release strategy; Specifically, the functional risk level is determined by assessing the business impact and safety criticality of the diagnostic function modules modified or added in the new version of the diagnostic software, such as high-risk functions (e.g., ECU remapping algorithm updates) or low-risk functions (e.g., UI adjustments). The canary release strategy is generated based on the mapping relationship between functional risk levels and user risk levels: high-risk new versions are prioritized for release to high-risk user groups (e.g., L4 level internal testing groups or L3 level expert user groups), while low-risk new versions are released to low-risk user groups (e.g., L1 level 4S store standard user groups or L0 level basic skills user groups), ensuring that the new version is tested within a controllable range, minimizing potential risks, and verifying software stability through gradual release.

[0031] Step S3: Push the new version of the diagnostic software to the target user group in the user group profile database according to the gray-scale release strategy; Specifically, the push methods include silent updates (automatic background download and installation) or prompt updates (installation after user confirmation), ensuring that only selected risk-level user groups receive the new version, while other user groups continue to use the stable older version. The selection of the target user group is based on a match between the functional risk level and the user's risk level. For example, high-risk new versions are first pushed to the L4 group for early verification, while low-risk versions directly cover a wider group. This achieves refined and controllable release processes, avoiding the large-scale failure risks that might result from a full release.

[0032] It should be noted that the target user group refers to the client that the user authorizes or logs in to.

[0033] Step S4: Obtain key business indicator data of the new version of the diagnostic software running on the target user group; Specifically, the server acquires tagged key business indicator data through periodic monitoring or in real-time. This tagged key business indicator data is generated when the new version of the diagnostic software is running on the client side of the target user group and is reported to the server in batches through an encrypted channel. The client side collects key business indicator data related to diagnostic operations in real-time or according to a monitoring period (e.g., every 5 minutes). The key business indicator data includes at least one of the following: diagnostic connection success rate, fault code reading success rate, fault code clearing success rate, specific data stream reading time, electronic control unit flashing success rate, and user negative feedback rate. During the collection process, each key business indicator data is tagged, including at least one of the following: user group identifier, software version identifier, executed functional module identifier, diagnostic vehicle model identifier, and timestamp, for subsequent multi-dimensional analysis.

[0034] Step S5: Compare the received key business indicator data with the preset dynamic threshold, and automatically trigger the corresponding decision instruction based on the comparison result. The decision instruction includes a rollback instruction, a volume increase instruction, or a pause instruction.

[0035] Specifically, the dynamic thresholds are set based on historical baseline values, business safety red lines (such as an ECU flashing success rate of ≥99.5%), and the tolerance levels of different user groups. If any of the key business indicators remains below its corresponding dynamic threshold for N consecutive monitoring periods, a rollback instruction is triggered. If all the key business indicators are better than or equal to the historical baseline for M consecutive monitoring periods, a volume increase instruction is triggered. If the key business indicators fluctuate but do not reach the dynamic threshold, a pause instruction is triggered. Decisions are based on business indicators rather than system resource indicators, enabling intelligent risk assessment and response, and ensuring rapid problem detection and handling.

[0036] Furthermore, in some embodiments, after step S5, the method further includes: sending the decision instruction to the client of the target user group, wherein the client of the target user group executes the decision instruction sent by the server.

[0037] Specifically, after receiving decision instructions from the server, the clients of the target user group automatically execute corresponding operations. For rollback instructions, the client downloads the specified stable older version of the diagnostic software from the server or activates a locally stored backup version to complete the version switch and quickly restore service stability. For rollout instructions, the client prepares to receive subsequent version updates, supporting a gradual expansion of the release scope. For pause instructions, the client maintains the current version state, pauses any automatic update operations, and enters an observation period. The execution results are reported to the server, forming a closed-loop feedback. The entire process ensures rapid mitigation in case of anomalies and orderly expansion when stable, improving the reliability of the diagnostic software and user experience.

[0038] Furthermore, in some embodiments, such as Figure 2 As shown, step S1, "constructing a user group profile database based on the acquired user data," may specifically include: Step S101: Establish a user evaluation model based on four dimensions: skill level, business error tolerance, diagnostic vehicle value, and willingness to provide feedback on issues; Specifically, the skill level dimension quantifies a user's technical capabilities through indicators such as their certified technician level (e.g., beginner, intermediate, advanced), historical diagnostic operation success rate (e.g., success rate of key functions such as connection, DTC reading, and clearing), and average diagnostic time. The business fault tolerance dimension considers the business scale, diagnostic frequency, and historical testing records of the user's organization type (e.g., 4S shop, general repair shop, quick repair shop) to assess the user's tolerance for software failures. The vehicle value dimension involves the value of vehicles frequently diagnosed by the user, such as high-value new energy vehicles or luxury vehicles, as diagnostic failures on these models may result in greater economic losses. The problem feedback willingness dimension assesses the user's enthusiasm for participating in testing through data such as the frequency and quality of user-initiated feedback (e.g., details of positive / negative reviews) and the frequency of function usage. The model uses machine learning algorithms (e.g., cluster analysis or decision trees) or rule engines to assign weights to each dimension and calculate a comprehensive score, thereby transforming user behavior into quantifiable risk indicators and providing a foundation for subsequent risk grading.

[0039] Step S102: Based on the comprehensive score output by the user evaluation model, divide users into levels with different risk levels and set a dynamic threshold for each level. Specifically, users are divided into tiers with different risk levels, such as five tiers from L4 (high risk, such as the internal testing group) to L0 (extremely low risk, such as the basic skills user group). The division is based on a comprehensive score distribution: high-scoring users (e.g., highly skilled, active feedback) are assigned to low-risk tiers (e.g., L1 or L0) and are responsible for more stable software versions; low-scoring users (e.g., basic skills, low fault tolerance) are assigned to high-risk tiers (e.g., L4 or L3) for early validation. Each risk tier corresponds to preset dynamic thresholds, which are based on historical averages of key business metrics (e.g., diagnostic connection success rate, ECU flashing success rate), business safety red lines (e.g., ECU flashing success rate must be ≥99.5%), and tier-specific tolerance settings. For example, the threshold for L4 may be more lenient, allowing for a higher failure rate for testing, while the threshold for L0 is stricter, ensuring zero defects. The dynamic thresholds are adjusted according to fluctuations in real-time key business metrics data. For example, the baseline value is updated through a sliding window algorithm to reflect the actual performance of the software version, ensuring the scientific validity and adaptability of the thresholds.

[0040] In the user evaluation model, the comprehensive score is calculated based on a quantitative integration of four dimensions: skill level, business tolerance rate, diagnostic vehicle value, and willingness to provide feedback. Each dimension is assigned a value through predefined indicators: the skill level dimension is converted into a percentage score based on the user's certified technician level (e.g., beginner, intermediate, advanced) and historical diagnostic operation success rate (e.g., connection success rate, fault code reading success rate); the business tolerance rate dimension assesses tolerance score based on the user's affiliated institution type (e.g., 4S store, repair shop) and historical test participation frequency; the diagnostic vehicle value dimension is weighted by the market value of frequently diagnosed vehicles; and the willingness to provide feedback dimension calculates a positivity score based on the frequency and quality of user proactive feedback (e.g., negative review rate). Subsequently, the user evaluation model uses a weighted average method or machine learning algorithm (e.g., linear regression) to assign dynamic weights to each dimension (e.g., skill level accounts for 40%, business tolerance rate accounts for 30%, and the rest each account for 15%), ultimately outputting a comprehensive score of 0-100 for risk level classification.

[0041] Step S103: When a change is detected in a user's historical diagnostic success rate or feedback activity, the risk level of that user is automatically adjusted.

[0042] Specifically, the server continuously monitors user behavior data. When it detects a significant change in a user's historical diagnostic success rate (e.g., connection success rate, DTC clearance success rate) or feedback activity (e.g., frequency of proactive feedback, negative feedback rate), it automatically triggers a risk level adjustment mechanism. For example, if a user's historical diagnostic success rate increases by more than 10% within a continuous period, or feedback activity increases (e.g., frequent submission of optimization suggestions), their risk level may be lowered (e.g., from L3 to L2), indicating increased user reliability and the ability to handle more stable software versions. Conversely, if the diagnostic success rate decreases or feedback decreases, the system may raise the risk level (e.g., from L1 to L2) to limit potential impact. Adjustments are based on preset rules (e.g., changes exceeding a threshold) or machine learning model predictions to ensure real-time performance and accuracy. This keeps the user profile database dynamically updated, allowing the canary release strategy to accurately adapt to changes in user capabilities, improving release security and efficiency.

[0043] During the training phase of the constructed machine learning model, historical user data is collected as the training set, including feature dimensions such as skill level, business fault tolerance rate, diagnostic vehicle value, and willingness to provide feedback on issues, as well as corresponding risk level adjustment records as labels. After standardizing and cross-referencing the raw data through feature engineering, algorithms such as random forest or gradient boosting decision tree are used for model training, focusing on optimizing the sensitivity to changes in user behavior and prediction accuracy. During the prediction phase, when a change in a user's historical diagnostic success rate or feedback activity is detected, the user's latest feature data is extracted in real time and input into the trained model. The machine learning model outputs the predicted risk level adjustment probability and compares it with a preset threshold: if the predicted probability exceeds the threshold, a risk level adjustment is automatically triggered, and the adjustment result is fed back to the training set to form a closed-loop optimization mechanism.

[0044] Furthermore, in some embodiments, such as Figure 3 As shown, step S2, "Based on the functional risk level of the new version of the diagnostic software to be released, and combined with the pre-built user profile database, generate a canary release strategy," may further include: Step S201: Determine the functional risk level based on the scope of business impact and the degree of security criticality of the diagnostic function modules modified or added in the new version of the diagnostic software to be released; Specifically, before releasing a new version of the diagnostic software, the server will first conduct a comprehensive risk assessment of the modified or added diagnostic function modules to determine the functional risk level of the version.

[0045] The assessment is primarily based on two dimensions: First, the scope of business impact, which refers to the range of diagnostic operations and the size of the user group affected by the change in the functional module. For example, if it involves modifications to the underlying communication library, core diagnostic protocols, or basic support functions such as ECU flashing and anti-theft matching, its impact covers almost all diagnostic processes, thus its scope of business impact is considered broad. However, if it is only an update to the fault code database for a specific vehicle model or an optimization of the user interface for non-core functions, the scope of impact is relatively limited. Second, the degree of safety criticality, which refers to the severity of the consequences that may result from the failure of the functional module. For example, high-risk operations involving vehicle control unit programming and calibration flashing may result in the vehicle becoming unusable or major system failures if they fail, making them functions with extremely high safety criticality. Read-only operations, such as reading fault codes or data streams, have a relatively low degree of safety criticality.

[0046] The server uses a predefined rule engine (such as a decision matrix) to comprehensively evaluate these two dimensions, ultimately classifying the new version's functional risk level into different levels such as high, medium, and low, providing a precise basis for formulating differentiated release strategies in the future.

[0047] The rule engine uses a predefined decision matrix to comprehensively evaluate two dimensions: business impact scope and safety criticality, thereby achieving automated and standardized classification of functional risk levels. First, the rule engine quantifies and grades the two evaluation dimensions. Business impact scope is typically divided into three levels: "broad" (affecting most diagnostic processes such as core communication libraries and basic diagnostic protocols), "local" (affecting specific vehicle models or functional module groups), and "limited" (affecting only the database or non-core UI interactions of a single vehicle model). Simultaneously, safety criticality is divided into "extremely high" (operational failure may brick the vehicle, lock the system, or cause a major safety incident), "medium" (operational failure may cause temporary functional malfunction but is recoverable), and "low" (operational failure only affects information reading, not control or writing). Subsequently, the rule engine's matrix forms a 3x3 evaluation grid with business impact scope as rows and safety criticality as columns. Each cell contains a pre-defined final risk level determination rule. For example: Rule 1: If the business impact scope is rated as "broad" and the safety criticality is "extremely high," the rule engine will directly output a functional risk level of "high." Rule 2: If the scope of business impact is "local" and the level of security criticality is "medium," then the risk level may be output as "medium." Rule 3: If the scope of business impact is "limited" and the level of security criticality is "low," then it is judged as "low" risk. This ensures the objectivity and consistency of risk level determination, providing an accurate and reliable basis for subsequently developing differentiated canary release strategies. The rule engine maintainers can also fine-tune the rules in the matrix based on historical release experience, continuously optimizing the evaluation criteria.

[0048] Step S202: The gray-scale release strategy is generated based on the mapping relationship between the functional risk level of the new version of the diagnostic software to be released and the risk level of the user group.

[0049] Specifically, after clarifying the functional risk level of the new version of the diagnostic software, the server matches it with the user risk level in the user group profile database according to the preset mapping rules, thereby generating a targeted gray release strategy. The core principle of this mapping relationship is risk hedging, that is, matching the software risk with the user's risk tolerance.

[0050] Specifically, for new versions with high functional risk levels (such as upgrades to core communication protocols or ECU remapping algorithms), the canary release strategy prioritizes mapping and releasing them to user groups with high risk levels (such as L4 internal testing groups or L3 expert user groups). This is because these users have strong technical capabilities, a high willingness to provide feedback, and their business scenarios have a certain margin for error, enabling them to effectively bear early testing risks and quickly provide high-quality feedback. For new versions with medium or low functional risk levels (such as adding support for a certain car model or optimizing the UI experience), they are mapped and released to user groups with low risk levels (such as L2 new energy user groups or L1 4S store standard user groups), and may even be gradually released to all users. Through automated mapping logic, it is ensured that high-risk changes are always verified first within a controllable small user group, effectively isolating the impact of potential defects, while low-risk optimizations can quickly benefit a wider range of users, thereby achieving a balance between minimizing release risk and maximizing value release.

[0051] Furthermore, in some embodiments, such as Figure 4 As shown, step S202, "the gray-scale release strategy is generated based on the mapping relationship between the functional risk level of the new version of the diagnostic software to be released and the risk level of the user group," may further include: Step S2021: Prioritize releasing the new version of the diagnostic software with a high risk level to users with high risk levels; Specifically, when a new version of diagnostic software is assessed as having a high functional risk level (e.g., involving modifications to core communication protocols, upgrades to ECU flashing algorithms, or changes to safety-critical modules), the server-generated canary release strategy strictly adheres to the principles of risk isolation and early verification, prioritizing releases to specific groups of users with high risk levels, such as the L4 internal testing group or the L3 expert user group. This restricts potentially unstable versions to a safe testing environment. These high-risk user groups possess strong technical capabilities, high business tolerance, and proactive and rapid problem feedback (e.g., the internal testing group can conduct 24 / 7 stress testing, and the expert user group can handle complex edge scenarios). They can not only withstand the business interruption risks that software defects may cause but also provide high-quality, in-depth technical feedback. The release strategy is typically set for targeted pushes to a small group (e.g., 0.1%-5% of users) with a short cycle (e.g., 24-72 hours), and may use update notifications to clearly inform users that they are participating in testing. It can maximize the acquisition of real performance data of the new version in high-risk scenarios while minimizing the impact, providing key basis for subsequent decision-making and effectively avoiding the serious consequences caused by high-risk changes directly impacting mainstream users.

[0052] Step S2022: Release the new version of the diagnostic software with a low risk level to users with low risk levels.

[0053] Specifically, for new versions of diagnostic software with a low functional risk level (such as user interface optimization, text correction of non-core functions, or incremental updates of diagnostic data for specific vehicle models), the server-side canary release strategy follows the principles of efficiency first and experience optimization. It directly releases the software to a large group of users with low risk levels, such as the L1 standard user group at 4S stores or the L0 basic skills user group, and can even quickly transition to a full release. These software changes typically do not affect core diagnostic logic and safety-critical operations, and their potential risks are minimal, but the optimization effects (such as improved ease of use) can benefit a wide range of daily users. The strategy employs a larger release ratio (e.g., starting directly with 20% of users) and a shorter observation period, often using silent updates to minimize disruption to users' work. This aims to quickly verify the compatibility and user experience improvements of the new version in real-world, high-volume business scenarios, and allow the broadest possible user base to benefit as soon as possible. Because the target user group (such as 4S store technicians) has a large workload and extremely high requirements for stability, successfully passing the verification is itself the strongest proof of the stability of the new version, thus providing sufficient confidence for the final decision to release it to the entire market.

[0054] Furthermore, in some embodiments, step S5, "obtaining key business indicator data of the new version of diagnostic software running in the target user group", may specifically include: obtaining the key business indicator data with tags through a monitoring cycle or in real time, wherein the tags include at least one of user group identifier, software version identifier, executed functional module identifier, diagnostic vehicle model identifier, and timestamp.

[0055] Specifically, the key business performance data includes at least one of the following: diagnostic connection success rate, fault code reading success rate, fault code clearing success rate, specific data stream reading time, electronic control unit flashing success rate, and user negative feedback rate.

[0056] When the new version of the diagnostic software runs on the clients of the target user group, a series of key business indicators strongly correlated with diagnostic operations are collected. These key business indicators comprehensively cover the core aspects of the diagnostic process and user experience. Among them, the diagnostic connection success rate measures the stability of the communication link established between the diagnostic equipment and the vehicle's ECU, serving as the foundation for all subsequent operations; the fault code reading success rate and clearing success rate directly reflect the core capability of the diagnostic software in interpreting vehicle fault information; specific data stream reading time (such as engine speed data) is used to monitor software performance and response efficiency; the electronic control unit (ECU) flashing success rate, as a high-risk, high-critical operation, is one of the most critical indicators for evaluating version security; and the user negative feedback rate, through user-submitted negative reviews or problem reports, subjectively assesses the usability and satisfaction of the new version. These indicators together constitute a multi-dimensional monitoring system from underlying technical implementation (connection, read / write) to high-level business value (high-risk operations, user experience), ensuring that the collected data accurately and comprehensively reflects the overall performance of the new version of the diagnostic software in actual business scenarios.

[0057] Furthermore, by acquiring the tagged key business indicator data through monitoring cycles, the client, while collecting key business indicator data according to a fixed monitoring cycle (e.g., every 5 minutes), will attach a set of structured metadata tags to each key business indicator data record. These tags include at least: user group identifier (e.g., "L3 expert user group"), used to distinguish which risk level user group the data comes from; software version identifier (e.g., "v2.1.0"), clearly recording the software version to which the data belongs; executed function module identifier (e.g., "ECU flashing module"), indicating the specific function point that generates the indicator; diagnostic vehicle model identifier (e.g., "vehicle model A"), associated with the specific model of the vehicle being tested; and a precise timestamp. The tagging process is a crucial step in transforming raw, isolated indicator data into traceable information units with rich context. This allows massive amounts of data to be accurately sliced, aggregated, and analyzed according to different dimensions (such as user groups, vehicle models, and functional modules) in subsequent processing, providing indispensable conditions for quickly locating the root cause of problems and conducting differentiated analysis. The client integrates the collected key business indicator data with complete tags and periodically reports it to the server's monitoring center in batches via encrypted channels (such as HTTPS and TLS protocols). The batch reporting strategy helps reduce the overhead of frequent network requests, improves data transmission efficiency, and optimizes client power consumption. Simultaneously, an exception handling mechanism is designed: batch reporting is executed under normal circumstances, but when the client detects a sudden and drastic fluctuation in key business indicator data or exceeds a preset abnormal threshold (such as an ECU flashing success rate suddenly dropping to 0), the batch plan will be immediately interrupted, triggering real-time reporting. While ensuring data transmission efficiency in most cases, it ensures that serious anomalies can be detected by the server in real time, winning valuable time for the rapid response of the automated decision engine. All data is transmitted through an encrypted channel, effectively preventing data from being stolen or tampered with during transmission, and ensuring the security and integrity of monitoring data.

[0058] Furthermore, by acquiring the tagged key business indicator data in real time, when the client detects an anomaly in any key business indicator data (such as ECU flashing success rate or diagnostic connection success rate), such as an instantaneous value exceeding a preset dynamic safety threshold or experiencing a precipitous drop, the system will immediately initiate a high-priority anomaly handling process. After completing the real-time tagging of the abnormal data points (attaching user group identifier, software version identifier, functional module identifier, vehicle model identifier, and a timestamp accurate to milliseconds), the client will not wait for the regular batch reporting cycle, but will immediately interrupt any current batch queue and create a high-priority real-time reporting task. This task will transmit these abnormal data points with complete context labels in real time through an independent, bandwidth-secured encrypted channel (such as a dedicated HTTPS long connection). The reporting data packet will contain clear anomaly event markers and severity level indicators to ensure that the server can receive and process this alarm first. It achieves minimal latency from anomaly detection to data reporting, enabling the server-side automated decision engine to detect the actual fault of a remote user within seconds, buying critical time to trigger emergency rollback or pause commands, thus achieving rapid intervention and automatic loss mitigation before potential problems begin to spread, forming an efficient risk emergency response closed loop.

[0059] Furthermore, in some embodiments, step S6, "the server compares the received key business indicator data with a preset dynamic threshold, and automatically triggers a corresponding decision instruction based on the comparison result, the decision instruction including a rollback instruction, a volume increase instruction, or a pause instruction," may further include: If any of the aforementioned key business indicators remains below its corresponding dynamic threshold for N consecutive monitoring periods, a decision instruction to issue a rollback instruction will be triggered. If all the aforementioned key business indicator data are better than or equal to the historical baseline value within M consecutive monitoring periods, a decision instruction to increase volume is triggered. If the key business indicator data fluctuates but does not reach the dynamic threshold, a decision instruction to pause is triggered.

[0060] Specifically, when the server-side automated decision engine detects that any key business metric (such as ECU flashing success rate or diagnostic connection success rate) remains below its corresponding dynamic threshold for N consecutive monitoring periods (e.g., 3 periods, each lasting 5 minutes), it immediately triggers a rollback instruction. This is designed to capture systemic risks that are not instantaneous fluctuations but rather persistent ones. The dynamic threshold is pre-set based on the historical baseline value of this function in stable versions (e.g., the average value over the past 30 days) combined with business security tolerance (e.g., the safety threshold for ECU flashing success rate is 99.5%). For example, if the "diagnostic connection success rate" of the new version continuously decreases from 99.8% to 95%, 93%, and 90% over three consecutive periods, and the threshold is set to 96%, a rollback is triggered. This design ensures that once a deterministic defect that could cause business interruption is discovered in the new version, the system can automatically and quickly perform stop-loss operations to prevent the problem from escalating. The parameter N can be adjusted according to the risk level of the function. For high-risk functions (such as writing), the N value should be smaller (e.g., 2 cycles) to achieve a fast response. For low-risk functions (such as data stream reading), the N value can be increased appropriately to avoid accidental rollback due to occasional factors such as short-term network fluctuations.

[0061] When all monitored key business metrics are better than or equal to the historical baseline for M consecutive monitoring periods (e.g., 6 periods, totaling 30 minutes), the system will trigger a release command. This judgment is based on the principle of continuous stability, requiring the new version to perform at or above the level of the old version in all core metrics. Better than means a statistically significant improvement in metric values ​​relative to the baseline (e.g., diagnostic connection success rate increases from 99.5% to 99.7%); equal to means performance remains stable and within the tolerable fluctuation range. For example, after release to the expert user group (L3), if all KBIs (connection success rate, fault code reading success rate, flashing success rate, etc.) remain stable at or better than the historical baseline for 6 consecutive periods, the new version is considered to be stable in this group and can be safely expanded to the next risk level user group (e.g., L2 new energy user group). The setting of parameter M needs to balance the release speed and stability verification requirements, ensuring a sufficiently long observation period to cover different types of business scenarios, and avoiding hastily pushing an unverified version to the next group.

[0062] When key business metrics exhibit abnormal fluctuations (such as a brief dip followed by recovery within a single period, or inconsistent changes across multiple metrics), but before reaching the threshold for triggering a rollback, the system will issue a pause command. This typically indicates a potential risk that is not yet definitively identified. For example, the diagnostic connection success rate for a particular vehicle model might fluctuate from 99% to 94% and 96% within two periods, while the threshold is 93%. The pause command serves to allow for cautious observation, immediately halting the rollout of the version to any new user groups, maintaining the current release scope, and simultaneously entering enhanced monitoring mode, such as shortening the monitoring cycle and increasing the sampling frequency, to collect more data to clarify the trend. The pause state will continue until the data trend becomes clear: either the fluctuation subsides and the metrics stabilize, triggering a rollback command; or the degradation continues, triggering a rollback command. This effectively prevents blindly expanding or terminating the release when the situation is unclear, providing a crucial buffer period for more accurate decision-making. Furthermore, in some embodiments, step S7, "the client of the target user group executes the decision instruction issued by the server," may specifically include: when the client receives a decision instruction that is a rollback instruction, it downloads the specified stable old version diagnostic software from the server or enables the locally stored backup version and completes the version switch; when the client receives a decision instruction that is a volume increase instruction, the client prepares to receive subsequent version updates; when the client receives a decision instruction that is a pause instruction, the client maintains the current version state and pauses any automatic update operations.

[0063] Specifically, when the client receives a rollback command from the server, it immediately initiates an automated rollback process. The client first parses the target stable version number (e.g., v2.0.1) contained in the command, and then intelligently selects the rollback source based on network conditions: if the network is smooth, it prioritizes downloading the specified old version diagnostic software installation package quickly from the server's secure file distribution channel; if the network is unstable or to save bandwidth, it automatically uses a locally pre-stored encrypted backup version (usually, a complete backup of the previous stable version is automatically retained when installing a new version). The version switching process employs an atomic operation design: after the new version process is gracefully terminated, the system performs integrity verification and rollback on critical data such as diagnostic configuration files and user settings, and then installs or switches to the target version. Throughout the process, the client interface displays a message to the user: "Version rollback in progress, please do not disconnect." After the switch is complete, the client automatically sends a "rollback successful" status confirmation message to the server and reactivates the collection of monitoring metrics for the old version, ensuring the system returns to a known stable state. This achieves automatic fault recovery within minutes, minimizing user service interruption time.

[0064] When the client receives a rollout instruction, it does not immediately execute a version update. Instead, it enters a "standby state" to prepare for receiving subsequent version updates. The client actively checks its local storage space to ensure sufficient capacity for downloading the new version installation package; verifies the validity of the digital certificate to confirm the trustworthiness of the subsequent update source; and maintains an active long-lived connection with the server's upgrade gateway. It updates its local policy, reactivating potentially paused automatic update check tasks and adjusting their check frequency to a higher level (e.g., once every 15 minutes) to promptly detect the next batch of update notifications released by the server. This process ensures that when the server decides to push a new version to a wider user group (e.g., expanding from the L3 expert group to the L2 user group), the client can respond quickly and smoothly, laying the foundation for a smooth rollout of the version.

[0065] Upon receiving the pause command, the client immediately enters a static freeze state. All automatic operations related to version updates are paused: tasks periodically querying the server for the new version are temporarily suspended, and background update package downloads that may be in progress are stopped and temporary files are cleaned up. However, the client's core diagnostic functions remain fully functional and available, and users can continue to perform all diagnostic operations using the current version without any impact. The message "Version update is paused, current version is stable vX.XX" displayed to the user in the settings will remain until the client receives a new release command (to lift the pause and resume updates) or a rollback command (to perform a rollback operation). The pause mechanism provides the server with a crucial observation window, enabling it to maintain the system status quo under uncertain circumstances without affecting normal user access, thus achieving a balance between risk control and business continuity.

[0066] In summary, the diagnostic software canary release method provided in this embodiment achieves precise release strategy and risk controllability by constructing a refined user group profile database on the server side. This completely changes the traditional one-size-fits-all full release model, allowing high-risk new software versions to be preferentially verified on a small scale by user groups with strong technical capabilities, high fault tolerance, and positive feedback. This minimizes the impact of potential defects and greatly reduces the risk of widespread business interruption caused by software updates. By collecting and comparing key business indicator data related to diagnostic business in real time with dynamic thresholds, the decision-making process is made intelligent and objective, eliminating the lag of relying on subjective human judgment. Based on real business data such as diagnostic connection success rate and electronic control unit write success rate, it can identify performance anomalies or functional defects in seconds and automatically trigger corresponding decision instructions. By automatically executing rollback, ramp-up, or pause instructions on the client side, the problem response is automated and efficient. In particular, when a deterministic defect is found, the software can be quickly and seamlessly rolled back to a stable version, minimizing fault recovery time, ensuring the continuity of user business, and avoiding economic losses.

[0067] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0068] To facilitate better implementation of the diagnostic software gray-scale release method of this application, this application also provides a diagnostic software gray-scale release apparatus. The meanings of the terms used are the same as in the diagnostic software gray-scale release method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0069] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of the diagnostic software grayscale release device provided in the embodiments of this application. The diagnostic software grayscale release device may specifically include: The strategy generation module is used to generate a canary release strategy based on the functional risk level of the new version of the diagnostic software to be released, combined with a pre-built user profile database. The push module is used to push the new version of the diagnostic software to the target user group in the user group profile database according to the gray-scale release strategy; it is also used to push decision instructions to the target user group. The data acquisition module is used to acquire key business indicator data of the new version of the diagnostic software running on the target user group; The decision execution module is used to compare the received key business indicator data with preset dynamic thresholds and automatically trigger corresponding decision instructions based on the comparison results. The decision instructions include rollback instructions, volume increase instructions, or pause instructions.

[0070] Specific limitations regarding the diagnostic software canary deployment device can be found in the limitations of the diagnostic software canary deployment method described above, and will not be repeated here. Each module in the aforementioned diagnostic software canary deployment device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0071] The diagnostic software canary release device provided in this embodiment achieves precise release strategies and controllable risks by building a refined user group profile database on the server side. This completely changes the traditional one-size-fits-all full release model, allowing high-risk new software versions to be preferentially verified on a small scale by user groups with strong technical capabilities, high fault tolerance, and positive feedback. This minimizes the impact of potential defects and greatly reduces the risk of widespread business interruption caused by software updates. By collecting and comparing key business indicator data related to diagnostic business in real time with dynamic thresholds, the device achieves intelligent and objective decision-making processes, eliminating the lag of relying on subjective human judgment. It can identify performance anomalies or functional defects in seconds based on real business data such as diagnostic connection success rate and electronic control unit write success rate, and automatically trigger corresponding decision instructions. By automatically executing rollback, ramp-up, or pause instructions on the client side, the device achieves automated and efficient problem response. In particular, when a deterministic defect is found, it can quickly and seamlessly roll back the software to a stable version, minimizing fault recovery time, ensuring the continuity of user business, and avoiding economic losses.

[0072] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 6 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 302, and by calling data stored in the memory 302, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0073] The memory 302 can be used to store software programs and modules. The processor 301 executes various functional applications and diagnostic software gray-scale release methods by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0074] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0075] The electronic device may also include an input unit 304, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0076] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processor 301 runs the applications stored in the memory 302 to realize various functions, as follows: Based on the functional risk level of the new version of the diagnostic software to be released, and combined with the pre-built user profile database, a canary release strategy is generated. According to the gray-scale release strategy, the new version of the diagnostic software is pushed to the target user group in the user group profile database; Acquire key business metrics data of the new version of the diagnostic software when running the new version on the target user group; The received key business indicator data is compared with a preset dynamic threshold, and the corresponding decision instruction is automatically triggered based on the comparison result. The decision instruction includes a rollback instruction, a volume increase instruction, or a pause instruction.

[0077] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0078] This application constructs a refined user profile database on the server side, achieving precise and risk-controllable release strategies. It completely changes the traditional one-size-fits-all full release model, allowing high-risk new software versions to be preferentially validated on a small scale by a user group with strong technical capabilities, high fault tolerance, and positive feedback. This minimizes the impact of potential defects and significantly reduces the risk of widespread business interruption caused by software updates. By collecting and comparing key business indicators with dynamic thresholds in real time, it achieves intelligent and objective decision-making, eliminating the lag of relying on subjective human judgment. Based on real business data such as connection success rate and electronic control unit write success rate, it can identify performance anomalies or functional defects within seconds and automatically trigger corresponding decision commands. Through automatic execution of rollback, ramp-up, or pause commands on the client side, it achieves automated and efficient problem response. In particular, when a deterministic defect is discovered, it can quickly and seamlessly roll back the software to a stable version, minimizing fault recovery time, ensuring business continuity, and avoiding economic losses.

[0079] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0080] Therefore, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the diagnostic software canary release methods provided in this application. For example, the instructions can execute the following steps: Based on the functional risk level of the new version of the diagnostic software to be released, and combined with the pre-built user profile database, a canary release strategy is generated. According to the gray-scale release strategy, the new version of the diagnostic software is pushed to the target user group in the user group profile database; Acquire key business metrics data of the new version of the diagnostic software when running the new version on the target user group; The received key business indicator data is compared with a preset dynamic threshold, and the corresponding decision instruction is automatically triggered based on the comparison result. The decision instruction includes a rollback instruction, a volume increase instruction, or a pause instruction.

[0081] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0082] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0083] Since the instructions stored in the storage medium can execute the steps in any of the diagnostic software gray-scale release methods provided in the embodiments of this application, the beneficial effects that any of the diagnostic software gray-scale release methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0084] The above provides a detailed description of a diagnostic software gray-scale release method, system, device, and medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for gray-scale release of diagnostic software, characterized in that, The method includes: Based on the functional risk level of the new version of the diagnostic software to be released, and combined with the pre-built user profile database, a canary release strategy is generated. According to the gray-scale release strategy, the new version of the diagnostic software is pushed to the target user group in the user group profile database; Acquire key business metrics data of the new version of the diagnostic software when running the new version on the target user group; The received key business indicator data is compared with a preset dynamic threshold, and the corresponding decision instruction is automatically triggered based on the comparison result. The decision instruction includes a rollback instruction, a volume increase instruction, or a pause instruction.

2. The diagnostic software gray-scale release method according to claim 1, characterized in that, The pre-built user group profile database includes: constructing a user group profile database based on the acquired user data; the user group profile database includes several user groups with different risk levels; The user data includes at least one of user attribute data, behavior data, device information data, and user preference data; The user attribute data includes at least one of the following: user ID, type of organization, and certified technician level; The behavioral data includes at least one of the following: historical diagnostic records, diagnostic operation success rate, average diagnostic time, and historical test participation records. The device information data includes at least one of the following: diagnostic instrument model, hardware configuration, and common network environments. The user preference data includes at least one of the following: frequency of function use and proactive feedback information.

3. The method for gray-scale release of diagnostic software according to claim 2, characterized in that, The step of constructing a user group profile database based on the acquired user data includes: A user evaluation model is established based on four dimensions: skill level, business error tolerance, diagnostic vehicle value, and willingness to provide feedback on issues. Based on the comprehensive score output by the user evaluation model, users are divided into levels with different risk levels, and a dynamic threshold is set for each level. When a change is detected in a user's historical diagnostic success rate or feedback activity, the user's risk level is automatically adjusted.

4. The method for gray-scale release of diagnostic software according to claim 1, characterized in that, The process involves generating a canary release strategy based on the functional risk level of the new version of the diagnostic software to be released, combined with a pre-built user profile database, including: The functional risk level is determined based on the scope of business impact and the degree of security criticality of the diagnostic function modules modified or added in the new version of the diagnostic software to be released. The canary release strategy is generated based on the mapping relationship between the functional risk level of the new version of the diagnostic software to be released and the risk level of the user group in the user group profile database.

5. The method for gray-scale release of diagnostic software according to claim 4, characterized in that, The canary release strategy is generated based on the mapping relationship between the functional risk level of the new version of the diagnostic software to be released and the risk level of the user group in the user group profile database, including: The new version of the diagnostic software with a high risk level will be prioritized for release to users with a high risk level. The new version of the diagnostic software, which has a low risk level for the aforementioned functions, will be released to users with low risk levels.

6. The method for gray-scale release of diagnostic software according to claim 1, characterized in that, The acquisition of key business metrics data of the target user group running the new version of the diagnostic software includes: The key business performance data includes at least one of the following: diagnostic connection success rate, fault code reading success rate, fault code clearing success rate, specific data stream reading time, electronic control unit flashing success rate, and user negative feedback rate. The key business indicator data with tags is obtained by monitoring the period or in real time. The tags include at least one of the following: user group identifier, software version identifier, executed functional module identifier, diagnosed vehicle model identifier, and timestamp.

7. The method for gray-scale release of diagnostic software according to claim 1, characterized in that, The process involves comparing the received key business indicator data with preset dynamic thresholds and automatically triggering corresponding decision instructions based on the comparison results. These decision instructions include rollback instructions, volume increase instructions, or pause instructions. If any of the aforementioned key business indicators remains below its corresponding dynamic threshold for N consecutive monitoring periods, a decision instruction to issue a rollback instruction will be triggered. If all the aforementioned key business indicator data are better than or equal to the historical baseline value within M consecutive monitoring periods, a decision instruction to increase volume is triggered. If the key business indicator data fluctuates but does not reach the dynamic threshold, a decision instruction to pause is triggered.

8. A diagnostic software grayscale release device, characterized in that, The device includes: The strategy generation module is used to generate a canary release strategy based on the functional risk level of the new version of the diagnostic software to be released, combined with a pre-built user profile database. The push module is used to push the new version of the diagnostic software to the target user group in the user group profile database according to the gray-scale release strategy; it is also used to push decision instructions to the target user group. The data acquisition module is used to acquire key business indicator data of the new version of the diagnostic software running on the target user group; The decision execution module is used to compare the received key business indicator data with preset dynamic thresholds and automatically trigger corresponding decision instructions based on the comparison results. The decision instructions include rollback instructions, volume increase instructions, or pause instructions.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1-7.

Images