Vehicle diagnostic management method, device, electronic device and readable storage medium

Abstract

The present application relates to a vehicle diagnostic management method, device, electronic device and readable storage medium, and belongs to the field of vehicle diagnostic technology. The method includes: determining the diagnostic status and diagnostic events in the vehicle diagnostic service; determining the state enumeration and triggering events based on the diagnostic status and diagnostic service, and generating a corresponding state machine, the state machine including the diagnostic task state machine and the vehicle diagnostic state machine; respectively performing event definition, state enumeration definition, condition setting and action setting on the state machine; controlling the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state through the triggering event, and using the MySQL database to persistently record the changes in the diagnostic tasks and their states; adjusting the diagnostic status, diagnostic events and flow in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine. The present application solves the problem that the existing state management method cannot effectively handle complex state transitions, resulting in disordered diagnostic processes and further low vehicle safety.

Description

Technical Field

[0001] The present application relates to the field of vehicle diagnosis technology, and in particular to a vehicle diagnosis management method, device, electronic device and storable medium. Background Art

[0002] With the advancement of intelligent vehicles, connected vehicle (IoV) and remote diagnostics have become key development areas in the automotive industry. IoV uses wireless communication to connect vehicles with each other, with road infrastructure, and with the internet, providing a more intelligent driving experience and services. Remote diagnostics, on the other hand, enable remote fault diagnosis and repair of vehicles over the internet, significantly improving repair efficiency and convenience. The COLA state machine is a lightweight, high-performance state machine framework developed open source by the Alibaba Cloud team to address state transition control issues within business processes. Based on a stateless design, it supports event-driven and distributed transactions, making it suitable for building complex and highly concurrent state machine models. Currently, remote diagnosis of faulty vehicles is typically performed using protocols such as MQTT (Message Queuing Telemetry Transport) and DOIP (Diagnostic Communication over Internet Protocol). These protocols enable the exchange of commands and data between the vehicle and the cloud, enabling remote fault diagnosis and repair. However, due to the complexity of IoV and remote diagnostics, existing state management methods often fail to effectively handle the various complex states and state transitions, leading to confusion and errors in the diagnostic process, impacting diagnostic accuracy and safety. This paper proposes a vehicle diagnosis management method based on the COLA state machine.

[0003] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0004] The present application provides a vehicle diagnostic management method, device, electronic device and storable medium to solve the above-mentioned technical problem of being unable to effectively handle various complex states and state transitions, resulting in confusion and errors in the diagnostic process.

[0005] According to one aspect of an embodiment of the present application, the present application provides a vehicle diagnostic management method, including: determining the diagnostic status and diagnostic events in the vehicle diagnostic service; determining the state enumeration and triggering events based on the diagnostic status and the diagnostic service, and generating a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine; performing event definition, state enumeration definition, condition setting and action setting for the state machine respectively; controlling the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state through the triggering event, and using the MySQL database to persistently record the changes in the diagnostic tasks and their states; adjusting the diagnostic status, the diagnostic events and the flow relationship in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine.

[0006] Optionally, determining the diagnostic status and diagnostic service in the vehicle diagnostic service includes: obtaining the vehicle diagnostic service; extracting the diagnostic status in the vehicle diagnostic service according to service requirements; and dividing the vehicle diagnostic service into services according to the diagnostic process to obtain diagnostic events.

[0007] Optionally, the state enumeration and trigger event are determined based on the diagnostic state and the diagnostic service, and a corresponding state machine is generated. The state machine includes a diagnostic task state machine and a vehicle diagnostic state machine, including: determining the state enumeration according to the diagnostic state; identifying possible trigger events for each of the diagnostic states; generating corresponding diagnostic task state machines and vehicle diagnostic state machines based on the state enumeration and the trigger event; and determining the state flow relationship, including external flow and internal flow.

[0008] Optionally, the event definition, state enumeration definition, condition setting and action setting of the state machine respectively include: event definition of the state machine according to the trigger event; event definition of the state machine according to the state enumeration; setting state flow conditions for each flow state of the state machine; and defining actions to be performed when the state flows.

[0009] Optionally, the trigger event includes a vehicle diagnostic status trigger event and a diagnostic task status trigger event; the status enumeration includes a vehicle diagnostic status enumeration and a diagnostic task status enumeration.

[0010] Optionally, the trigger event is used to control the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state, and the MySQL database is used to persistently record the changes in the diagnostic tasks and their states, including: initializing the vehicle diagnostic state machine and the diagnostic task state machine, and setting the initial state; writing event triggering logic to trigger the corresponding triggering event when specific conditions are met; executing state flow and calling corresponding actions according to the current diagnostic event and the current diagnostic state; persisting the new state information to the MySQL database during the state flow; designing the database table structure, and recording the diagnostic task state and vehicle diagnostic state through the database table structure.

[0011] Optionally, the diagnostic status, diagnostic events and flow relationships in the vehicle diagnostic business are adjusted through the state machine, and the state machine is dynamically adjusted, including: adding new diagnostic status, diagnostic events and flow relationships in real time according to changes in business needs; modifying the definitions of existing diagnostic status, diagnostic events and flow relationships to adapt to new business scenarios; using the configuration center to annotate the state machine and dynamically adjust the state machine; automatically refreshing the configuration of the state machine when the configuration changes.

[0012] According to another aspect of an embodiment of the present application, the present application provides a vehicle diagnostic management device, including: an identification module for identifying diagnostic status and diagnostic events in vehicle diagnostic services; a definition module for determining state enumeration and triggering events based on the diagnostic status and diagnostic services, and generating a corresponding state machine, the state machine including a diagnostic task state machine and a vehicle diagnostic state machine; a state machine configuration module for performing event definition, state enumeration definition, condition setting and action setting for the state machine respectively; a state flow module for controlling the vehicle diagnostic state machine to flow from the initial state to the diagnostic start-up state through triggering events, and using a MySQL database to persistently record changes in diagnostic tasks and their states; a state machine adjustment module for adjusting the diagnostic status, diagnostic events and flow in the vehicle diagnostic services through the state machine, and dynamically adjusting the state machine.

[0013] According to another aspect of an embodiment of the present application, the present application provides an electronic device, including a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate through the communication bus and the communication interface, and is characterized in that the processor implements the instructions of the above method when executing the computer program.

[0014] According to another aspect of the embodiments of the present application, the present application further provides a readable storage medium storing program instructions, which, when read and executed by a computing device, enables the computing device to execute the above method.

[0015] The above technical solution provided by the embodiment of the present application has the following advantages compared with the related art:

[0016] This application clearly defines diagnostic states and events and builds a state machine based on these definitions, making the entire diagnostic process clearer and more organized. The state machine ensures that the correct actions are executed under specific conditions, thereby avoiding diagnostic errors caused by human error or process confusion and improving diagnostic accuracy and efficiency. The COLA state machine framework's lightweight and highly scalable nature allows the system to easily adapt to new diagnostic scenarios or requirements that may be added in the future. Furthermore, its expressiveness enhances code readability and maintainability, making it easier for developers to understand and modify the system, reducing maintenance costs. The state machine allows for dynamic adjustments, including modifications to diagnostic states, events, and flow logic. This flexibility enables the system to continuously optimize based on actual operating conditions and feedback to adapt to changing diagnostic needs and environments. Remote diagnostic technology allows car owners to more conveniently obtain diagnostic results and repair recommendations for their vehicles without having to visit a repair station in person. This not only saves time and effort, but also improves customer satisfaction and loyalty. A MySQL database is used to persistently record diagnostic tasks and their state changes, providing a rich data source for subsequent data analysis and mining. By analyzing this data, we can further understand key indicators such as the distribution of vehicle faults and diagnostic efficiency, providing strong support for optimizing diagnostic processes and improving service quality. The COLA state machine supports distributed transactions and event-driven processing, enabling the system to handle highly concurrent diagnostic requests, improving overall system performance and stability. This feature is particularly important in the Internet of Vehicles (IoV) environment, where the large number of vehicles and their widespread distribution require the system to possess strong concurrent processing capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 A schematic diagram of the hardware environment of a vehicle diagnostic management method provided according to an embodiment of the present application;

[0020] Figure 2 A schematic diagram of a process flow of a vehicle diagnostic management method provided according to an embodiment of the present application;

[0021] Figure 3 A flowchart of remote diagnosis-diagnosis opening and closing provided according to an embodiment of the present application;

[0022] Figure 4 A flowchart of remote diagnosis-link establishment and routing activation provided according to an embodiment of the present application;

[0023] Figure 5 A flowchart of remote diagnosis-UDS command interaction provided according to an embodiment of the present application;

[0024] Figure 6 A flow chart of a vehicle diagnostic state machine according to an embodiment of the present application;

[0025] Figure 7 A flowchart of a diagnostic task state machine according to an embodiment of the present application;

[0026] Figure 8 This is a structural diagram of a vehicle diagnostic management device provided according to an embodiment of the present application;

[0027] Figure 9 The present invention provides an optional schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of this application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0030] In related technologies, due to the complexity of vehicle networking and remote diagnosis technology, existing state management methods are often unable to effectively handle various complex states and state transitions, resulting in confusion and errors in the diagnostic process, affecting the accuracy of vehicle diagnosis and vehicle safety.

[0031] In order to solve the problems mentioned in the background technology, according to one aspect of the embodiments of the present application, an embodiment of a vehicle diagnosis management method is provided.

[0032] Optionally, in the embodiment of the present application, the above method can be applied to Figure 1In the hardware environment composed of the terminal 101 and the server 103 shown in FIG. Figure 1 As shown, the server 103 is connected to the terminal 101 via a network and can be used to provide services for the terminal or a client installed on the terminal. A database 105 can be set on the server or independently of the server to provide data storage services for the server 103. The above-mentioned network includes but is not limited to: a wide area network, a metropolitan area network or a local area network, and the terminal 101 includes but is not limited to a PC, a mobile phone, a tablet computer, etc.

[0033] A vehicle diagnosis management method in an embodiment of the present application can be executed by the server 103, or can be executed jointly by the server 103 and the terminal 101, such as Figure 2 As shown, the method may include the following steps:

[0034] S202, determining the diagnostic status and diagnostic events in the vehicle diagnostic service;

[0035] Specifically, determining the diagnostic status and diagnostic services in the vehicle diagnostic service includes:

[0036] Obtain vehicle diagnostic services;

[0037] Obtain vehicle diagnosis time; extract the diagnosis status of vehicle diagnosis business according to business needs;

[0038] The vehicle diagnosis business is divided into business categories according to the diagnosis process to obtain the diagnosis business.

[0039] In the remote diagnosis business, it mainly includes the normal process of the package business and the abnormal process, among which the flowchart of remote diagnosis-diagnosis opening and closing is as follows: Figure 3 As shown, remote diagnosis - link establishment and routing activation are as follows Figure 4 As shown, the remote diagnosis-UDS command interaction is as follows Figure 5 As shown, remote diagnosis-status feedback is as follows Figure 6As shown. In this embodiment, the following main states are first defined to cover the entire diagnostic process: Initial state: the system has not started any diagnostic task and is in idle state. To be activated state: a diagnostic request has been received, but a communication connection with the vehicle has not yet been established. Connection establishment: an attempt is being made to establish a communication connection with the vehicle. Connection established: the communication connection with the vehicle has been successfully established. Preparing for diagnostic task: after the connection is established, the system is ready to perform a specific diagnostic task. Diagnosis execution: a UDS instruction or other diagnostic operation is being executed. Waiting for results: a diagnostic instruction has been sent, and the vehicle is waiting for a response result. Diagnosis completed: the diagnostic task has been completed, and the result processing or user confirmation is awaited. Diagnosis failed: an error was encountered during the diagnostic process, and the task was not successfully completed. Diagnosis ended: regardless of success or failure, the diagnostic task has officially ended, and the system returns to the idle state. Determine diagnostic events. The transitions between these states are usually triggered by specific events, including but not limited to: Receiving a diagnostic request: triggering a transition from the initial state to the to-be-activated state. Connection attempt: in the to-be-activated state, an attempt is made to establish a connection with the vehicle, triggering a transition to the connection establishment state. Successful connection: After the connection is successfully established, the state transitions from connection establishment to connection established state. Connection failure: When the connection attempt fails, the state transitions from connection establishment back to pending activation state or initial state. Start diagnostic task: In the connection established state, trigger the transition to the diagnostic task preparation state. Diagnostic task execution: After preparation is completed, start the diagnostic task and enter the diagnostic execution state. Receive result: Receive the diagnostic result from the vehicle and transition from waiting for result to diagnosis completion or diagnosis failure state. Task completion: The diagnostic task is successfully completed, triggering the transition to the diagnosis completion state. Task failure: The diagnostic task fails for some reason, triggering the transition to the diagnosis failure state. End diagnosis: Regardless of success or failure, the user or the system automatically ends the diagnostic task and transitions from diagnosis completion or diagnosis failure to the diagnosis end state.

[0040] In the above embodiment, by clarifying the diagnostic status and diagnostic events in the vehicle diagnostic business, the entire diagnostic process is made clearer and more organized. By dividing the diagnostic process into business, the execution order and resource allocation of each link can be optimized, thereby improving the execution efficiency of the diagnostic task. At the same time, clear status and event definitions also help the system to quickly respond to and handle various situations, shortening the diagnostic cycle. A complete diagnostic process including normal processes and abnormal processes is defined, so that the system can fully cover various possible situations. When encountering abnormal situations, the system can handle them according to the predetermined process, avoiding problems such as system crashes or data loss caused by abnormal situations, and enhancing the robustness and reliability of the system. By recording and tracking changes in diagnostic status and events, the execution process of the diagnostic task can be easily tracked, the problem can be quickly located, and maintenance efficiency and user satisfaction can be significantly improved.

[0041] S204, determining state enumeration and triggering events based on the diagnostic state and diagnostic service, and generating corresponding state machines, which include a diagnostic task state machine and a vehicle diagnostic state machine;

[0042] Specifically, based on the diagnostic status and diagnostic service, the state enumeration and triggering events are determined, and the corresponding state machine is generated. The state machine includes a diagnostic task state machine and a vehicle diagnostic state machine, including:

[0043] Determine the status enumeration based on the diagnostic status;

[0044] Identify possible triggering events for each diagnostic state;

[0045] Generate corresponding diagnostic task state machine and vehicle diagnostic state machine based on state enumeration and trigger events;

[0046] Determine the state flow relationship, including external flow and internal flow.

[0047] In this embodiment, based on the status sorted out by the remote diagnosis service, the state enumeration and trigger events are sorted out and a state machine is established. The state machine mainly includes a diagnostic task state machine and a vehicle diagnostic state machine. Among them, the diagnostic task state machine is as follows: Figure 7 As shown, the vehicle diagnostic state machine is as follows Figure 8 As shown in the figure, each state transition in a state machine defines either an external flow or an internal flow. External flows typically involve external events (such as user requests and system notifications), while internal flows may be triggered by the state machine's internal logic (such as timeouts and retry mechanisms). For example, an external event triggers an external flow from IDLE to PENDING_ACTIVATION. Internal flows may include automatically retrying a connection if it fails, or marking a task as failed after a waiting timeout.

[0048] In the above-described embodiment, by abstracting the complex logic of the vehicle diagnostic service into a state machine and state enumeration, the system structure is made clearer and more modular. When business requirements change, only the state enumeration, trigger events, or state transition relationships need to be adjusted, without requiring a large-scale reconfiguration of the entire system. By clearly defining state transition relationships and trigger conditions, the state machine ensures predictable and controllable system behavior in different states, helping to reduce problems such as system crashes or data inconsistencies caused by logical errors or abnormal conditions, thereby enhancing the robustness and stability of the system. By managing the state transitions of diagnostic tasks and vehicle diagnostics through a state machine, business processing can be optimized and efficiency improved. The state machine automatically executes corresponding operations based on the current state and trigger events, reducing the possibility of manual intervention and misjudgment, thereby accelerating business processing. The state machine can reflect the current status of diagnostic tasks and vehicle diagnostics in real time and provide clear feedback to users. Users can use the state machine's feedback to understand the progress and results of task execution, enabling them to make more accurate decisions and actions. In remote diagnostics, managing these scenarios and situations through a state machine ensures the system processes according to predefined logic and rules, avoiding confusion and errors caused by complex business logic. The state machine supports the definition of both external and internal flows, enabling the system to flexibly respond to various external events and internal logic changes. The state machine records the complete execution process of diagnostic tasks and vehicle diagnostics, including state transitions and triggering events. When system issues arise, the state machine's execution log and state transition records can be viewed to quickly locate the problem and implement appropriate remedial measures.

[0049] S206, respectively define events, define state enumerations, set conditions, and set actions for the state machine;

[0050] Specifically, based on user attribute data, the state machine is respectively subjected to event definition, state enumeration definition, condition setting, and action setting, including:

[0051] Define events for the state machine based on trigger events;

[0052] Define events for the state machine based on state enumeration;

[0053] Set state transition conditions for each transition state of the state machine;

[0054] Define the actions to be performed when the state changes.

[0055] More specifically, the events include vehicle diagnostic status triggering events and diagnostic task status triggering events; the status enumerations include vehicle diagnostic status enumerations and diagnostic task status enumerations.

[0056] In this embodiment, we first define the events and enumerations used to trigger the state machine's state transitions between the vehicle diagnostic state and the diagnostic task state. We assume that all state transitions are unconditional (i.e., all conditions are met by default). Action settings typically include state changes and associated business logic processing, assuming that each action is a simple state change record. This embodiment's state machine uses the COLA state machine framework.

[0057] The above embodiment, through clear event definitions and state enumerations, can easily adapt to new business needs or changes. When a new diagnostic task or vehicle diagnostic state arises, simply add a new event or state enumeration to the system, eliminating the need for a large-scale reconstruction of the entire state machine. Clear state transition conditions and action settings make the system logic more intuitive and easy to understand, reducing the difficulty of subsequent maintenance and debugging. When problems arise, developers can quickly locate the relevant state or event and implement targeted remediation. Each state transition is accompanied by clear condition settings and action definitions, ensuring the accuracy of the system when processing user attribute data and executing the corresponding business logic. This avoids errors or exceptions caused by unclear logic or improper processing. The state machine design is well-suited to handling complex business logic and state changes. By defining multiple states and events and setting corresponding transition conditions and actions, the system can flexibly handle a variety of complex business scenarios, such as multi-step vehicle diagnostic processes or diagnostic tasks of varying priorities. By precisely controlling state transitions and executing relevant actions in a timely manner, the system can provide users with a smoother and more efficient service experience. For example, during the vehicle diagnostic process, the system can automatically push corresponding diagnostic reports or prompts to the user based on the current status. Using the standard COLA state machine framework for development makes the system easier to integrate and collaborate with other systems or components. At the same time, the standardized design also facilitates communication and collaboration among team members, improving development efficiency.

[0058] S208, controlling the vehicle diagnostic state machine to transition from the initial state to the diagnostic enabled state by triggering an event, and using a MySQL database to persistently record diagnostic tasks and their state changes;

[0059] Specifically, the vehicle diagnostic state machine is controlled to flow from the initial state to the diagnostic start state by triggering events, and the MySQL database is used to persistently record the changes in diagnostic tasks and their states, including:

[0060] Initialize the vehicle diagnostic state machine and the diagnostic task state machine, and set the initial state;

[0061] Write event trigger logic to trigger corresponding trigger events when specific conditions are met;

[0062] According to the current diagnostic event and current diagnostic status, execute the state flow and call the corresponding action;

[0063] When the state changes, the new state information is persisted to the MySQL database;

[0064] Design the database table structure and use it to record the diagnostic task status and vehicle diagnostic status.

[0065] In this example, various vehicle diagnostic states are first defined, such as NONE (initial state), ENABLED (diagnostics enabled), RUNNING (diagnostics in progress), COMPLETED (diagnostics completed), and FAILED (diagnostics failed). Next, events that trigger state changes in the state machine are defined, such as ENABLE (diagnostics enabled), START (diagnostics started), STOP (diagnostics stopped), COMPLETE (diagnostics completed), and FAIL (diagnostics failed). A vehicle diagnostic state machine object is created and its initial state is set to NONE. Event triggers are integrated into the business logic. For example, when a user clicks the "Start Diagnostics" button in the UI, a START event is triggered internally. Before triggering the event, the system checks whether the trigger conditions are met, such as whether the vehicle is online and whether there is sufficient battery power. If these conditions are met, the event is passed to the state machine for processing. Upon receiving the event, the state machine determines whether a state transition is necessary based on the current state and event type. If necessary, the state machine updates the current state and performs any actions associated with the new state (such as starting the diagnostic process or sending a notification). State transitions are ensured to comply with predefined business rules to avoid entering invalid or inconsistent states. Design a database table for diagnostic tasks and their status, including fields such as task ID, vehicle ID, task name, start time, end time, and current status. When the state machine transitions, persist the new status information to the database. This can be achieved by updating existing records or inserting new ones, depending on business requirements and system design. During database operations, handle possible exceptions such as connection failures and SQL errors, and ensure data integrity and consistency.

[0066] In the above embodiment, the state flow of the state machine is controlled by event triggering, which can quickly respond to user operations. For example, the diagnostic process is immediately started after clicking the "Start Diagnosis" button, which reduces user waiting time and improves user experience. Before the state machine performs a state transition, the system will check the trigger conditions to ensure that the state transition is only performed when the conditions are met. This avoids system anomalies or errors caused by improper state transitions and enhances the reliability and stability of the system. By persisting the diagnostic tasks and their state changes in the MySQL database, the system can record the complete diagnostic process, including key information such as task ID, vehicle ID, task name, start time, end time, current status, etc. This provides strong support for subsequent data analysis, problem tracking and auditing. The state machine design can handle complex business logic and state changes, such as pause, continue, failure, etc. that may occur during the diagnostic process. By defining clear states and events, and corresponding actions, the system can flexibly respond to various business scenarios and ensure the smooth progress of the diagnostic process.

[0067] S210 , adjusting the diagnostic status, diagnostic events, and flow in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine.

[0068] Specifically, the diagnostic status, diagnostic events, and flow in the vehicle diagnostic service are adjusted through the state machine, and the state machine is dynamically adjusted, including:

[0069] New diagnostic status, diagnostic events and flow relationships are added in real time according to changes in business needs.

[0070] Modify the definitions of existing diagnostic status, diagnostic events, and flow relationships to adapt to new business scenarios;

[0071] Use the configuration center to annotate the state machine and dynamically adjust the state machine;

[0072] Automatically refresh the state machine configuration when the configuration changes.

[0073] In this embodiment, in the vehicle diagnostic business, as business needs continue to change, new diagnostic states, diagnostic events, and the flow relationships between them need to be added in real time. The configurable state machine design of this embodiment can easily add new states, events, and flow logic without the need for large-scale reconstruction of the code. When the existing diagnostic states, diagnostic events, or flow relationships no longer meet the new business scenarios, it is necessary to be able to easily modify these definitions. This can be achieved by editing the state machine configuration file or adjusting it using graphical tools. The modified definition should be able to be seamlessly integrated into the existing business logic to ensure the continuity and stability of the system. In order to adjust the state machine configuration more flexibly, a configuration center (such as Nacos) can be used to manage the relevant configuration information of the state machine. By storing the state machine definition, state and event mapping relationship, etc. in the configuration center, centralized management and dynamic update of the configuration can be achieved. When the configuration changes, the system can automatically sense and refresh the state machine configuration, thereby achieving dynamic adjustment without restarting the service. Combined with the @RefreshScope annotation or other similar mechanisms in frameworks such as SpringCloud, dynamic refresh of the state machine configuration can be achieved. When the state machine configuration in the configuration center changes, the system automatically reloads these configurations and updates them to the currently running state machine instance. In this way, the behavior of the state machine can be adjusted as needed even during business operation without interrupting the service. Use the flexibility and extensibility of the COLA state machine framework to supplement new diagnostic states, diagnostic events, and flow relationships. Taking the TCP link closure event as an example, it shows how to use the state machine builder (such as builder.externalTransitions()) to define the flow path from multiple existing states to the TCP link closure state. This declarative approach not only simplifies the complexity of the state machine configuration, but also improves the readability and maintainability of the system.

[0074] In the above embodiment, as business needs change, new diagnostic states, diagnostic events, and flow relationships can be added in real time, or existing definitions can be modified to accommodate new business scenarios. This enables the system to quickly respond to market changes and customer needs, improving its flexibility and adaptability. Through a configurable state machine design, states, events, and flow logic can be easily added, modified, or deleted without requiring large-scale code refactoring. This significantly reduces system maintenance costs and improves development efficiency. The use of a configuration center allows for centralized management and dynamic updates of state machine configuration information. When the system needs to expand new functionality or business scenarios, simply update the corresponding configuration information in the configuration center. The system will automatically detect and apply these changes without requiring additional development work. This scalability enables the system to easily cope with future business growth and changes. During dynamic adjustments to the state machine configuration, the system automatically refreshes the configuration and updates it to the currently running state machine instance, ensuring system continuity and stability. Even when configuration adjustments are made during business operations, normal system operation is not affected, avoiding service interruptions or data loss caused by configuration changes. By dynamically adjusting the diagnostic status, diagnostic events, and flows in vehicle diagnostic services, the system can more accurately reflect the actual status and diagnostic progress of the vehicle, providing users with more accurate and timely information feedback, helping to improve user satisfaction and trust and enhance user experience.

[0075] According to another aspect of the embodiment of the present application, Figure 8 As shown, the present application provides a vehicle diagnosis management device, comprising:

[0076] Identification module 301, used to identify diagnostic status and diagnostic events in vehicle diagnostic services;

[0077] Definition module 303, for determining state enumeration and triggering events based on diagnostic status and diagnostic services, and generating corresponding state machines, including diagnostic task state machines and vehicle diagnostic state machines;

[0078] The state machine configuration module 305 is used to define events, state enumerations, conditions and actions for the state machine;

[0079] The state transition module 307 is used to control the vehicle diagnosis state machine to transition from the initial state to the diagnosis-enabled state by triggering events, and to persistently record the changes in the diagnosis tasks and their states using a MySQL database;

[0080] The state machine adjustment module 309 is used to adjust the diagnostic state, diagnostic events and flow in the vehicle diagnostic service through the state machine, and dynamically adjust the state machine.

[0081] It should be noted that the identification module 301 in this embodiment can be used to execute step S202 in the embodiment of the present application, the definition module 303 in this embodiment can be used to execute step S204 in the embodiment of the present application, the state machine configuration module 305 in this embodiment can be used to execute step S206 in the embodiment of the present application, the state flow module 307 in this embodiment can be used to execute step S208 in the embodiment of the present application, and the state machine adjustment module 309 in this embodiment can be used to execute step S210 in the embodiment of the present application.

[0082] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. Figure 1 In the hardware environment shown, it can be implemented by software or by hardware.

[0083] According to another aspect of the embodiment of the present application, the present application provides an electronic device, such as Figure 9 As shown, it includes a memory 401, a processor 403, a communication interface 405 and a communication bus 407. The memory 401 stores a computer program that can be run on the processor 403. The memory 401 and the processor 403 communicate through the communication interface 405 and the communication bus 407. When the processor 403 executes the computer program, the steps of the above method are implemented.

[0084] The memory and processor in the electronic device communicate via a communication bus and a communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The communication bus can be divided into an address bus, a data bus, a control bus, and the like.

[0085] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage. Alternatively, the memory may be at least one storage device located away from the processor.

[0086] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0087] According to another aspect of the embodiments of the present application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the above embodiments.

[0088] Optionally, in an embodiment of the present application, the computer-readable medium is configured to store program codes for the processor to execute the following steps:

[0089] Step S202, determining the diagnostic status and diagnostic events in the vehicle diagnostic service;

[0090] Step S204: determining state enumeration and triggering events based on the diagnostic state and diagnostic service, and generating corresponding state machines, which include a diagnostic task state machine and a vehicle diagnostic state machine;

[0091] Step S206, respectively performing event definition, state enumeration definition, condition setting and action setting for the state machine;

[0092] Step S208: Control the vehicle diagnostic state machine from the initial state to the diagnostic start state through a trigger event, and use the MySQL database to persistently record the diagnostic tasks and their state changes;

[0093] Step S210 : adjusting the diagnostic status, diagnostic events, and flows in the vehicle diagnostic service through the state machine, and dynamically adjusting the state machine.

[0094] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0095] When implementing the embodiments of the present application, reference may be made to the above embodiments, which have corresponding technical effects.

[0096] It is understood that the embodiments described herein may be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of the present application, or a combination thereof.

[0097] For software implementation, the technology herein can be implemented by a unit that performs the functions herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0098] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0099] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0100] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0101] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0102] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0103] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a ROM, a RAM, a magnetic disk, or an optical disk. It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "includes", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such a process, method, article or device. Without more constraints, an element defined by the phrase "comprises a..." does not exclude the existence of additional identical elements in the process, method, article or apparatus that comprises the element.

[0104] The above are merely specific embodiments of the present application to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but rather is intended to conform to the widest scope consistent with the principles and novel features of the present application.

Claims

1. A vehicle diagnosis and management method, characterized in that: include: Determine diagnostic status and diagnostic events in vehicle diagnostic services; Determine state enumeration and trigger events based on the diagnostic state and the diagnostic service, and generate corresponding state machines, the state machines including a diagnostic task state machine and a vehicle diagnostic state machine; Perform event definition, state enumeration definition, condition setting and action setting for the state machine respectively; The trigger event controls the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state, and uses the MySQL database to persistently record the diagnostic tasks and their state changes; The diagnostic state, the diagnostic event and the flow relationship in the vehicle diagnostic service are adjusted through the state machine, and the state machine is dynamically adjusted.

2. The vehicle diagnosis and management method according to claim 1, characterized in that: The determining of the diagnostic status and diagnostic events in the vehicle diagnostic service includes: Obtain vehicle diagnostic services; Extracting the diagnostic status of the vehicle diagnostic service according to business requirements; The vehicle diagnostic service is divided into service categories according to the diagnostic process to obtain diagnostic events.

3. The vehicle diagnosis and management method according to claim 1, characterized in that: The state enumeration and triggering event are determined based on the diagnostic state and the diagnostic service, and a corresponding state machine is generated. The state machine includes a diagnostic task state machine and a vehicle diagnostic state machine, including: determining a state enumeration based on the diagnostic state; identifying a triggering event for each of said diagnostic states; Generate a corresponding diagnostic task state machine and a vehicle diagnostic state machine based on the state enumeration and the trigger event; Determine the state flow relationship, including external flow and internal flow.

4. The vehicle diagnosis and management method according to claim 1, characterized in that: The event definition, state enumeration definition, condition setting and action setting of the state machine respectively include: Performing event definition on the state machine according to the trigger event; Performing state enumeration definition on the state machine according to the state enumeration; Setting a state transition condition for each transition state of the state machine; Define the actions to be performed when the state changes.

5. The vehicle diagnosis and management method according to claim 4, characterized in that: The trigger events include vehicle diagnostic status trigger events and diagnostic task status trigger events; the status enumerations include vehicle diagnostic status enumerations and diagnostic task status enumerations.

6. The vehicle diagnosis and management method according to claim 1, characterized in that: The trigger event is used to control the vehicle diagnostic state machine to flow from the initial state to the diagnostic start state, and the MySQL database is used to persistently record the diagnostic tasks and their state changes, including: Initializing the vehicle diagnostic state machine and the diagnostic task state machine, and setting an initial state; Write event trigger logic to trigger corresponding trigger events when specific conditions are met; According to the current diagnostic event and current diagnostic status, execute the state flow and call the corresponding action; When the state changes, the new state information is persisted to the MySQL database; Design the database table structure and use it to record the diagnostic task status and vehicle diagnostic status.

7. The vehicle diagnosis and management method according to claim 1, characterized in that: The step of adjusting the diagnostic state, the diagnostic event, and the flow relationship in the vehicle diagnostic service through the state machine and dynamically adjusting the state machine includes: Add new diagnostic status, diagnostic events, and flow relationships in real time based on changes in business needs; Modify the definitions of existing diagnostic status, diagnostic events, and flow relationships to adapt to new business scenarios; Use the configuration center to annotate the state machine and dynamically adjust the state machine; Automatically refresh the configuration of the state machine when the configuration changes.

8. A vehicle diagnosis management device, applicable to the vehicle diagnosis management method according to any one of claims 1 to 7, characterized in that: include: Attribute acquisition module, used to obtain user attribute data, vehicle attribute data and event attribute data corresponding to each vehicle model; Identification module, used to identify diagnostic status and diagnostic events in vehicle diagnostic services; A definition module is used to determine state enumeration and trigger events based on diagnostic status and diagnostic services, and generate corresponding state machines, including diagnostic task state machines and vehicle diagnostic state machines; The state machine configuration module is used to define events, state enumerations, conditions, and actions for the state machine; The state transition module is used to control the vehicle diagnostic state machine from the initial state to the diagnostic start state by triggering events, and use the MySQL database to persistently record diagnostic tasks and their state changes; The state machine adjustment module is used to adjust the diagnostic status, diagnostic events and flow in the vehicle diagnostic business through the state machine, and dynamically adjust the state machine.

9. An electronic device comprising a memory, a processor, a communication interface, and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate via the communication bus and the communication interface, characterized in that: When the processor executes the computer program, the processor implements the instructions of any one of the methods 1-7 above.

10. A readable storage medium storing program instructions, which, when read and executed by a computing device, causes the computing device to execute the method according to any one of claims 1 to 7.

Images