Fault diagnosis method and system based on SOA and vehicle

Abstract

The invention relates to the technical field of vehicles, and discloses an SOA-based fault diagnosis method and system, an electronic device, a storage medium and a vehicle, and the method comprises the steps: a data synchronization step: responding to key data captured in real time, and uploading the key data to a cloud for storage, the key data comprising burying point information and a key log; a service monitoring step: comprehensively monitoring an SOA service state based on an SOME / IP protocol, and synchronizing monitoring information to the cloud in real time, the monitoring information including key state information of the SOA service; a log reporting step: based on the SOA service state, triggering a cloud log reporting mechanism when detecting that a function link is abnormal; and a fault analysis step: performing fault judgment in response to the received report log and the key state information of the SOA service, the fault judgment comprising positioning a fault source and judging a fault level. The SOA service monitoring can be deepened, the cloud data synchronization is enhanced, and the data processing and fault detection capabilities are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and in particular to a SOA-based fault diagnosis method, system, electronic equipment, storage medium and vehicle. Background Art

[0002] At present, the adoption of SOA (service-oriented architecture) for vehicle communications is gradually developing in the market. As the software foundation for software-defined vehicles, SOA is being adopted by more and more automakers. SOA architecture effectively solves the complexity and scalability problems of traditional point-to-point communication between ECUs by dividing vehicle functions into different service components and using service middleware to complete service publishing, subscription and communication. The introduction of SOA architecture improves the flexibility and scalability of automotive software, reduces the cost of upgrades and migration, and is in line with the development trend of automotive intelligence and networking.

[0003] In existing technologies, although SOA architecture brings many advantages, fault detection methods still have some limitations and shortcomings:

[0004] 1. Limited log storage space: The log storage space of the vehicle computer is limited, making it difficult to store vehicle status information and tcpdump information for all time periods, which limits the comprehensive monitoring of vehicle status and fault analysis.

[0005] 2. Difficulty in fault diagnosis: When an SOA service fails, related functions may be abnormal, and the tcpdump message at the time of the failure cannot be captured in real time, making it difficult to locate the root cause of the problem.

[0006] 3. Occasional problems are difficult to reproduce: Some occasional problems may be short-lived and difficult to predict. The lack of effective means to reproduce these problems increases the difficulty of problem diagnosis.

[0007] Therefore, the present application provides a fault diagnosis method based on SOA to solve the above technical problems. Summary of the invention

[0008] The purpose of the present invention is to provide a fault diagnosis method, system, electronic device, storage medium and vehicle based on SOA, so as to solve the technical problems in the prior art that the SOA architecture log storage space is limited, occasional problems are difficult to reproduce, and thus fault diagnosis is difficult.

[0009] In order to solve the above technical problems, the present invention provides a fault diagnosis method based on SOA, comprising:

[0010] A data synchronization step includes uploading to cloud storage in response to key data captured in real time, wherein the key data includes tracking point information and key logs;

[0011] A service monitoring step, including comprehensively monitoring the SOA service status based on the SOME / IP protocol, and synchronizing the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service;

[0012] The log reporting step includes triggering a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status;

[0013] The fault analysis step includes performing fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level.

[0014] In some specific embodiments, the data synchronization step includes uploading to cloud storage in response to key data captured in real time, wherein the key data includes tracking point information and key logs, and further includes:

[0015] Real-time data collection, capturing the buried point information and key logs during vehicle operation to form the key data;

[0016] Preprocessing the key data, including unifying timestamps, converting data types, and performing corresponding formatting and compression;

[0017] Using an encryption algorithm to encrypt the pre-processed key data;

[0018] Based on a secure channel, the encrypted key data is uploaded to the cloud storage.

[0019] In some specific embodiments, the service monitoring step includes comprehensively monitoring the SOA service status based on the SOME / IP protocol, and synchronizing the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service, and further includes:

[0020] Initialize service status monitoring and configure monitoring parameters of the SOME / IP protocol, including monitoring period, monitoring range, and abnormal threshold;

[0021] Key status information collection: periodically collect the status information of the provision, discovery, subscription, stop, response and value sending of the SOA service;

[0022] Exception information capture: real-time monitoring and capture of exception information in the SOA service, including response timeout and data error;

[0023] Status information synchronization: synchronizing the collected status information and the abnormal information to the cloud.

[0024] In some specific embodiments, the log reporting step includes triggering a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status, further including:

[0025] Based on the SOA service status, detecting anomalies in the functional link through preset rules;

[0026] When an anomaly is detected, an alarm message is generated containing the node location, upstream and downstream node information, and anomaly details;

[0027] The alarm information is reported to the cloud, and the overall log capture mechanism is started to capture log information corresponding to the alarm information.

[0028] In some specific embodiments, the fault analysis step includes performing fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level, and further includes:

[0029] In response to the received warning information and log information, judging whether the function is abnormal and the abnormality level in combination with the vehicle status, the SOA service status and the function preset conditions;

[0030] A fault tree is generated based on the abnormal function, and the fault type and fault cause are analyzed according to the alarm information and the log information.

[0031] In some specific embodiments, a fault handling step is also included, including:

[0032] Based on the fault judgment results, confirm the nature of the fault and the scope of impact;

[0033] Based on the fault, executing corresponding emergency measures, including adjusting configuration to bypass the fault point;

[0034] In response to the emergency measures, a corresponding repair plan is executed, and the repair effect is verified until the fault is resolved.

[0035] Based on the same concept, the present invention also provides a fault diagnosis system based on SOA, comprising:

[0036] A data synchronization module is configured to include uploading to cloud storage in response to key data captured in real time, wherein the key data includes buried point information and key logs;

[0037] A service monitoring module, configured to comprehensively monitor the SOA service status based on the SOME / IP protocol, and synchronize the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service;

[0038] A log reporting module is configured to trigger a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status;

[0039] The fault analysis module is configured to perform fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level.

[0040] Based on the same concept, the present invention also provides an electronic device, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the SOA-based fault diagnosis method.

[0041] Based on the same concept, the present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the SOA-based fault diagnosis method.

[0042] Based on the same concept, the present invention also provides a vehicle, wherein the vehicle is provided with the SOA-based fault diagnosis system as described above.

[0043] Compared with the prior art, the invention has the following beneficial effects:

[0044] The present invention discloses a fault diagnosis method, system, electronic device, storage medium and vehicle based on SOA, which can deepen SOA service monitoring, enhance cloud data synchronization, and significantly improve data processing and fault detection capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is a flowchart of a SOA-based fault diagnosis method in some specific embodiments of the present invention;

[0046] Figure 2 It is a schematic diagram of a node log acquisition process of a SOA-based fault diagnosis method in some applications of the present invention;

[0047] Figure 3 It is a flowchart of a SOA-based fault diagnosis method in some applications of the present invention;

[0048] Figure 4 It is a structural schematic diagram of a SOA-based fault diagnosis system in some specific embodiments of the present invention;

[0049] Figure 5It is a schematic diagram of the structure of an electronic device in some specific embodiments of the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0051] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings, and "multiple" generally includes at least two.

[0052] It should be understood that the term "and / or" used in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0053] It should be understood that although the terms first, second, third, etc. may be used to describe in the embodiments of the present application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, without departing from the scope of the embodiments of the present application, the first may also be referred to as the second, and similarly, the second may also be referred to as the first.

[0054] As used herein, the words "if" and "if" may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0055] It should also be noted that the term "includes", "comprising" or any other variation thereof is intended to cover non-exclusive inclusion, so that a commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprising a ..." do not exclude the existence of other identical elements in the commodity or device including the elements.

[0056] It should be particularly noted that any symbols and / or numbers in the specification that are not marked in the accompanying drawings are not drawing marks.

[0057] Reference Figure 1 , a fault diagnosis method based on SOA, comprising:

[0058] S101, a data synchronization step, including uploading to cloud storage in response to key data captured in real time, wherein the key data includes tracking point information and key logs;

[0059] It is understandable that, first of all, the key data types that need to be captured are clearly defined, including but not limited to user interaction behaviors (such as clicks, slides, etc.), system operation status (such as CPU usage, memory usage, etc.), and key business logic execution results, etc. In this embodiment, the focus is on the tracking point information and key logs.

[0060] Tracking point information collection: Tracking points are preset in the application or system. When users perform specific operations or meet specific conditions, the tracking point information is automatically triggered. Including event type (such as click, page visit, etc.), event timestamp, event parameters (such as clicked button ID, page URL, etc.), etc.

[0061] Key log collection: Through the log mechanism, key log information is captured and recorded in real time. The log records the detailed process of system operation, exception information, error stack, etc.

[0062] Clean and format the collected raw data. For example, remove duplicate data, complete missing fields, convert timestamps to a unified format, etc. Desensitize sensitive information to protect user privacy. In order to reduce the amount of data transmission and improve security, compress the pre-processed data. At the same time, use encryption algorithms (such as AES, RSA, etc.) to encrypt the data to ensure the security of the data during transmission. Develop an upload strategy based on business needs and data characteristics. For example, you can set up scheduled upload tasks (such as uploading every 5 minutes), triggered uploads (such as automatic uploads when the data volume reaches a certain threshold), or real-time uploads.

[0063] Establish a connection with the cloud through a secure network channel (such as HTTPS). Upload the compressed and encrypted data to the storage location specified by the cloud according to the established upload strategy. After receiving the data, the cloud performs integrity verification and decryption. After confirming that the data is correct, it returns a confirmation message of successful upload to the sender.

[0064] For example, when a vehicle is driving,

[0065] Tracking point information collection: When a user clicks a navigation button, the tracking point information such as the timestamp, event type (click), event parameters (navigation button ID), etc. of the event is automatically recorded.

[0066] Key log collection: Vehicle sensors continuously monitor vehicle speed, acceleration, direction and other data, and record these data as key logs. At the same time, they record information such as its operating status and execution instructions. Every 5 minutes, the pre-processed data is compressed and encrypted, and uploaded to the cloud via the HTTPS protocol. The cloud performs integrity verification and decryption on the received data, and returns confirmation information of successful upload to the vehicle.

[0067] In some of these applications, the data synchronization step includes uploading to cloud storage in response to real-time captured key data, where the key data includes tracking point information and key logs, real-time data collection, capturing tracking point information and key logs during vehicle operation to form key data; preprocessing the key data, including unified timestamps, data type conversion, and corresponding formatting and compression; encrypting the preprocessed key data using an encryption algorithm; and uploading the encrypted key data to cloud storage based on a secure channel.

[0068] It is understandable that the monitoring points preset in the application inside the vehicle are used to record key events such as user interaction behaviors, state changes, etc. For example, the user's actions such as starting the vehicle, adjusting the air conditioning temperature, and triggering emergency braking can all be recorded as buried point information.

[0069] Key logs are detailed operation records generated by various vehicle subsystems (such as engine control unit, braking system, navigation system, etc.), including key parameters, state changes, abnormal information, etc. during operation.

[0070] The timestamps of all collected data are uniformly converted to UTC time or a specified time standard to ensure the timeliness and consistency of the data.

[0071] For example, if the timestamp format contained in the original data is "2023-04-01 12:00:00GMT+8", it needs to be converted into UTC time during the preprocessing process, such as "2023-03-3104:00:00UTC".

[0072] According to data usage requirements, data from different sources are converted to a unified data type. For example, string-type temperature data is converted to floating-point type for numerical calculation.

[0073] For example, the temperature in the original data is expressed in string form, such as "25°C", which is converted to a floating point number 25.0 during preprocessing.

[0074] Format the data to ensure consistency and readability.

[0075] Use data compression algorithms (such as GZ IP, LZ4, etc.) to compress the preprocessed data to reduce the amount of data transmission and improve transmission efficiency.

[0076] For example, convert log records containing multiple fields from raw text format to JSON format and perform GZ IP compression.

[0077] Select encryption algorithms based on data sensitivity and security requirements, including AES, RSA, etc.

[0078] For example, the AES-256 encryption algorithm is selected to encrypt the preprocessed and compressed key data.

[0079] Use the key to initialize the encryption algorithm. Use the preprocessed data as input and encrypt it through the encryption algorithm. The encrypted data exists in ciphertext form and the original information cannot be directly deciphered.

[0080] Use HTTPS, VPN or other security protocols to establish an encrypted communication channel with the cloud to ensure the security and reliability of data transmission. Upload the encrypted key data to the designated storage location in the cloud according to the established format and protocol. During the upload process, you can set a data verification mechanism (such as MD5, SHA-256, etc.) to ensure the integrity and consistency of the data. After receiving the data, the cloud storage will verify and store it.

[0081] S102, a service monitoring step, including comprehensively monitoring the SOA service status based on the SOME / IP protocol, and synchronizing the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service;

[0082] It is understandable that the service monitoring steps mainly include two core links: one is the comprehensive monitoring of the SOA service status based on the SOME / IP protocol; the other is to synchronize the monitored key status information to the cloud in real time.

[0083] Configure the SOME / IP protocol in SOA to ensure that each service node can communicate and exchange data based on the protocol. Specify key parameters such as service ID, message ID, and data format during the configuration process to ensure the accuracy and efficiency of data transmission. Set monitoring points in key nodes and processes of SOA services to capture the operating status and key performance indicators (KPIs) of the service. Monitoring points include but are not limited to service start / stop status, request processing time, resource utilization, number of exceptions, etc. Use the mechanism provided by the SOME / IP protocol to collect data from each monitoring point regularly or in an event-triggered manner. Process and analyze the collected data to evaluate the health status and performance of SOA services. Identify possible service anomalies or performance bottlenecks through preset thresholds and rules. Encapsulate the evaluated monitoring information into a network transmission format, such as JSON or XML. Encrypt the encapsulated data to ensure data security during transmission. Encryption algorithms such as AES and RSA can be selected, and the key length is selected according to data sensitivity and transmission requirements. Upload the encapsulated monitoring information to the cloud in real time. The cloud system receives the uploaded monitoring information and performs corresponding analysis and processing. Generate visual reports based on the received monitoring information, trigger alarm notifications, or perform other automated operations (such as service restart, resource allocation, etc.).

[0084] For example, assume that an intelligent in-vehicle entertainment system based on the SOME / IP protocol (as part of the SOA service) provides services such as music playback, navigation, and voice interaction. Set monitoring points at key nodes of the service (such as music player playback control, navigation map update request, voice recognition response time, etc.). Through the SOME / IP protocol, regularly collect data from monitoring points, including key status information such as whether the service is running normally and whether the request processing time exceeds the preset threshold. Encapsulate this data into JSON format and upload it to the cloud in real time through the HTTPS protocol. After receiving the data, the cloud parses and processes it, generates a monitoring report, and triggers an alarm when an abnormality is found.

[0085] In some of the applications, the service monitoring step includes comprehensive monitoring of the SOA service status based on the SOME / IP protocol, and synchronizing the monitoring information to the cloud in real time. The monitoring information includes the key status information of the SOA service, service status monitoring initialization, configuration of the monitoring parameters of the SOME / IP protocol, including the monitoring cycle, monitoring range and abnormal threshold; key status information collection, periodic collection of the status information of the provision, discovery, subscription, stop, reply and value sending of the SOA service; abnormal information capture, real-time monitoring and capture of abnormal information in the SOA service, including response timeout and data error; status information synchronization, synchronization of the collected status information and abnormal information to the cloud.

[0086] It is understandable that the monitoring parameters of the SOME / IP protocol are configured first. The configured monitoring parameters include but are not limited to:

[0087] Monitoring cycle: Set the time interval for collecting SOA service status information, such as collecting once every 5 minutes.

[0088] Monitoring scope: Clarify the scope of SOA services that need to be monitored, such as a specific set of service IDs or all services.

[0089] Abnormality threshold: Set the quantitative standard for judging service abnormality, such as setting the response timeout threshold to 2 seconds and the data error rate threshold to 0.1%.

[0090] For example, configure the monitoring period to 5 minutes, the monitoring range includes all services with service IDs from 1001 to 1010, the response timeout threshold is set to 2 seconds, and the data error rate threshold is set to 0.1%.

[0091] Initialize monitoring components according to configured monitoring parameters, including timers, data acquisition modules, anomaly detection modules, etc.

[0092] According to the configured monitoring cycle, the data collection module is started regularly to collect key status information such as the provision, discovery, subscription, stop, response and sent value of SOA services. The collected data includes timestamp, service ID, status type (such as provision, response, etc.) and specific status value. The collected status information is recorded in the data structure locally or in memory for subsequent processing and synchronization. During the service operation, the operation status of SOA services is monitored in real time through the anomaly detection module. The monitoring content includes but is not limited to the response time of service requests and the integrity and correctness of returned data. When the service response timeout (i.e. the response time exceeds the configured threshold) or the data error (such as data format inconsistency, data inconsistency, etc.) is found, the exception information is immediately captured and recorded. The exception information includes the exception type, occurrence time, service ID and specific exception description. The collected key status information and captured exception information are sorted into a unified format, such as JSON or XML. Ensure the integrity and readability of the data, which is convenient for the cloud to parse and process. Synchronize the sorted status information and exception information to the cloud. The cloud receives the uploaded status information and exception information and performs corresponding parsing and processing. Based on the processing results, the cloud can generate monitoring reports, trigger alarm notifications, or perform other automated operations (such as automatically restarting services, adjusting resource configurations, etc.).

[0093] For example, the monitoring cycle is configured to be 5 minutes, and the monitoring scope includes all services with service IDs 1001 to 1010. In a certain monitoring cycle, the data acquisition module finds that the service with service ID 1003 takes more than 2 seconds to respond (i.e., the response timeout), and the anomaly detection module immediately captures and records the anomaly information. Subsequently, all the collected status information and captured anomaly information are organized into JSON format and synchronized to the cloud via the HTTPS protocol. After receiving the data, the cloud generates the corresponding monitoring report.

[0094] S103, a log reporting step, including triggering a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status;

[0095] It is understandable that comprehensive monitoring of the SOA service status includes but is not limited to the service's operating status, performance indicators, resource usage, etc. In-depth analysis of the functional links in the SOA service is carried out to clarify the dependencies and interaction processes between the service components. When a key indicator of the SOA service (such as response time, error rate, etc.) is monitored to exceed the preset threshold, it is considered that the functional link is abnormal. When a functional link abnormality is detected, the cloud log reporting mechanism is triggered. The reporting mechanism automatically collects log information related to the abnormality, including but not limited to the time, location, cause, and scope of impact of the abnormality. The collected log information is sorted, and during the sorting process, the log information is classified, marked, or encrypted. The sorted log information is reported to the cloud. The cloud receives the reported log information and performs corresponding analysis and processing.

[0096] In some of these applications, the log reporting steps include triggering the cloud log reporting mechanism based on the SOA service status when a functional link abnormality is detected, detecting anomalies in the functional link through preset rules based on the SOA service status; when an anomaly is detected, generating an alarm information including the node location, upstream and downstream node information and anomaly details; reporting the alarm information to the cloud, and starting the overall log capture mechanism to capture the log information corresponding to the alarm information.

[0097] It is understandable that the operation status of all SOA services is monitored in real time, including but not limited to key indicators such as service response time, throughput, error rate, etc. By collecting call data between services, a topology diagram of the functional link is constructed to clarify the dependency relationship between each service node.

[0098] Define preset rules for detecting functional link anomalies based on business requirements and system characteristics. The rules may include but are not limited to response time thresholds, error rate thresholds, service call times limits, etc.

[0099] For example, set the response time of service A calling service B to no more than 2 seconds and the error rate to no more than 0.1%.

[0100] Perform anomaly detection on functional links periodically or in real time according to preset rules, and determine whether there are anomalies in the functional links by comparing the actual service operation data with the preset rules.

[0101] When an anomaly is detected in a functional link, an alarm message is automatically generated. The alarm message includes but is not limited to the node location where the anomaly occurs (such as service ID, interface name), upstream and downstream node information (caller and callee), and anomaly details (anomaly type, anomaly description, occurrence time, etc.).

[0102] For example, the alarm information content is "A response timeout exception occurred when service A called service B. The service AID is 1001, the service BID is 1002, the exception type is response timeout, and the occurrence time is 2023-04-01 12:00:00".

[0103] Report the generated alarm information to the cloud server. After the alarm information is reported to the cloud, the cloud generates the corresponding log capture instructions based on the alarm content. Send the capture instructions to the corresponding SOA service node. The service node that receives the capture instruction executes the log capture operation. Capture the log information corresponding to the alarm information, including the service call log and system log before and after the exception occurs. Upload the captured log information to the cloud for storage and analysis.

[0104] S104 is a fault analysis step, which includes performing fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level.

[0105] In some of the applications, the fault analysis step includes making a fault judgment in response to the received reporting log and key status information of the SOA service, wherein the fault judgment includes locating the source of the fault and judging the fault level; in response to the received alarm information and log information, combining the vehicle status, SOA service status and function preset conditions, judging whether the function is abnormal and the abnormality level; generating a fault tree based on the abnormal function, and analyzing the fault type and cause according to the alarm information and log information.

[0106] It is understandable that the reported logs received from different sources include but are not limited to logs generated during the operation of SOA services, system monitoring logs, user operation logs, etc. At the same time, key status information of SOA services is collected, such as service response time, error rate, resource occupancy rate, etc. The reported logs are deeply analyzed, and the specific location of the fault (such as service node, interface, database, etc.) is located in combination with the architecture and business process of the SOA service.

[0107] For example, by analyzing the error stack information in the log, it can be located that an exception occurred in a specific interface in the SOA service when processing a request.

[0108] Combine the received alarm information (including alarm type, alarm level, etc.) and the abnormal description in the log to evaluate the impact of the fault on the overall operation of the system. Set fault level standards, such as severe (affecting the main functions of the system), general (affecting some functions or performance degradation), minor (occasional abnormalities, not affecting the main functions), etc.

[0109] In response to the received alarm information and log information, combined with the vehicle status (such as driving speed, location, power, etc.), SOA service status and function preset conditions (such as security policies, business rules, etc.), determine whether a specific function is abnormal.

[0110] For example, if the vehicle is in motion but the navigation system cannot display the route normally, and at the same time a connection failure alarm occurs in the service node responsible for map data in the SOA service, it is determined that the navigation system is malfunctioning.

[0111] Assess the abnormality level based on the specific manifestations of the functional abnormality and the degree of impact on vehicle operation.

[0112] For example, if a navigation system anomaly causes the vehicle to be unable to find the correct driving route, and the anomaly lasts for a long time, it is evaluated as a high-level anomaly.

[0113] Based on the abnormal function, a fault tree model is constructed. The fault tree takes the abnormal function as the root node and gradually expands to the specific fault cause and fault mode.

[0114] For example, take navigation system anomaly as the root node and expand to sub-nodes such as map service node connection failure, network request timeout, and map data corruption.

[0115] According to the alarm information and log information, combined with the fault tree model, the specific type and possible causes of the fault are analyzed.

[0116] For example, by analyzing the network request log and the error log of the map service node in the log, it is determined that the cause of the navigation system abnormality is the failure to load the map data due to the network request timeout.

[0117] Some of these applications also include fault handling steps, which include confirming the nature and scope of the fault based on the fault judgment results; executing corresponding emergency measures based on the fault, including adjusting the configuration to bypass the fault point; responding to the emergency measures, executing the corresponding repair plan and verifying the repair effect until the fault is resolved.

[0118] It is understandable that the result of receiving the fault judgment output includes key information such as fault source location, fault level, functional abnormality status, etc. According to the fault judgment result, it is clear whether the fault is a hardware fault, a software fault, a network fault or other types of faults.

[0119] For example, if the fault diagnosis result shows that the service response timed out and the error log points to a database connection problem, it can be preliminarily determined to be a network failure or a database service failure.

[0120] Analyze the potential impact of the failure on SOA services, vehicle operation and user experience. Determine the number of affected users, service scope, key business processes, etc.

[0121] For example, if the fault affects the navigation system, it may cause all vehicles using the system to be unable to obtain the correct driving route, which will have a wide-ranging and critical impact.

[0122] Develop an emergency response plan based on the nature and scope of the fault. Implement specific steps in the emergency plan, such as adjusting service routing, enabling backup servers, switching to redundant systems, etc., to bypass the fault point.

[0123] For example, if a database service fails, data requests from application services can be temporarily redirected to a backup database server to ensure uninterrupted service.

[0124] Monitor system status and user feedback in real time to evaluate the effectiveness of emergency measures. While implementing emergency measures, analyze the cause of the failure and develop a repair plan. The repair plan includes specific repair steps, required resources, and estimated completion time. Perform repair operations step by step according to the repair plan, such as fixing code defects, replacing faulty hardware, and optimizing network configuration.

[0125] For example, if the cause of the failure is improper configuration of the database connection pool, the repair operation may include adjusting the connection pool parameters, optimizing database queries, etc. After the repair is completed, perform comprehensive tests to verify the repair effect. Analyze the test results to confirm whether the failure has been completely resolved and whether it has returned to normal.

[0126] Combine the following Figure 2 and Figure 3 The following describes the embodiments of the SOA-based fault diagnosis method of the present invention in some applications:

[0127] This embodiment significantly improves the data processing and fault detection capabilities through the following optimization measures:

[0128] 1. Enhanced cloud data synchronization: By uploading real-time tracking information and key logs to cloud storage, the problem of limited local storage capacity of the vehicle computer is effectively solved.

[0129] 2. Deepen SOA service monitoring: Using the SOME / IP protocol, comprehensive monitoring of the status of each node of the vehicle SOA service is achieved. Key status information including service provision, discovery, subscription, stop, response, and sent value, together with abnormal information, are synchronized to the cloud in real time, improving the accuracy and response speed of fault diagnosis.

[0130] 3. Instant cloud log reporting: When any abnormality is detected on the vehicle function link, the cloud log reporting mechanism is triggered, ensuring that even occasional problems can be quickly captured and uploaded to the cloud.

[0131] like Figure 2 As shown,

[0132] 1. Function item number F ID. When an abnormality occurs at a node in the link, the abnormality information is sent to the cloud, triggering the overall log capture mechanism of the cloud.

[0133] 2. After receiving the abnormal information collection instruction from the cloud, the function node numbered F ID parses the instruction and uploads it to the cloud. At the same time, the cockpit domain, central computing domain and each regional control domain of the vehicle synchronously upload their status information, load conditions, etc. to the cloud as a diagnostic basis for abnormal analysis.

[0134] 3. The fault analysis module in the cloud gives the analysis result after comprehensive judgment based on the preset function status and the status information of the whole vehicle. It comprehensively considers the connection status of upstream and downstream nodes, the vehicle status, and the preset working conditions of the function to judge whether the function corresponding to the F ID is in an abnormal state, the frequency of the abnormality, the level of the abnormality, etc. At the same time, it analyzes the root cause of the abnormality based on the collected logs.

[0135] like Figure 3 As shown,

[0136] Step 1: Reporting of functional abnormalities:

[0137] In a function link of a vehicle based on SOA communication, when a function module of a node in it is abnormal, the current abnormal level is first determined. When it exceeds the abnormal threshold, an alarm message is actively sent to the cloud. The alarm message includes: function F ID, node position POS, upstream and downstream node connection information PRE_POS_1...PRE_POS_N; NEXT_POS_1,...,NEXT_POS_N, abnormal information (including abnormal value Except_Value, abnormal level Except_Level, abnormal cause Except_Cause), etc.

[0138] Step 2: Information collection instructions are issued:

[0139] After receiving the abnormal alarm information, the cloud sends information collection instructions to each module of the functional F ID. After receiving the instructions, each module parses the collection instructions.

[0140] Step 3: Node information collection and reporting:

[0141] The vehicle-machine communication mode is divided into communication based on internal SDK, external SOA service communication based on some / ip protocol, and CAN bus communication. The information reporting module collects the communication status information of upstream and downstream nodes and the module's own status information, and reports it to the cloud through the http protocol.

[0142] Step 4: Fault Analysis Module:

[0143] The cloud receives the alarm information from each node and can determine the location of the node where the abnormality occurs. At this time, the current vehicle status, vehicle mode (show car mode, production line mode, transportation mode, etc.), vehicle power mode (PRE_ON, STANDBY, DRIVING, PRE_OFF, AWAKE, SLEEP), SOA service status (service subscription failure, service discovery failure, service provision has stopped, service event sending timeout, etc.) are determined. According to the vehicle status and the preconditions for the normal operation of the preset functions, and whether the current function is abnormal, the corresponding fault tree is generated for the abnormal function.

[0144] In the above embodiment, the status report of the entire function is triggered by the abnormal information of a node in the function link. SOA service collects and reports all status information from offer service, find service, submit, submit ack, send event. According to the information reported by the information collection module, the vehicle status, three connection status information, and the preset working conditions of the function are comprehensively considered to determine whether the current function is abnormal and the level of the abnormality. The module where the abnormality occurs is located, and data analysis is provided based on the collected logs to obtain the root cause of the fault.

[0145] For the method steps disclosed in the above embodiments, the method steps are described as a series of action combinations for the purpose of simple description, but those skilled in the art should know that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0146] like Figure 4 As shown, the present invention also provides a fault diagnosis system based on SOA, comprising:

[0147] The data synchronization module 201 is configured to include uploading to the cloud storage in response to the key data captured in real time, wherein the key data includes the embedding point information and the key log;

[0148] A service monitoring module 202 is configured to comprehensively monitor the SOA service status based on the SOME / IP protocol and synchronize the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service;

[0149] The log reporting module 203 is configured to trigger a cloud log reporting mechanism based on the SOA service status when a function link abnormality is detected;

[0150] The fault analysis module 204 is configured to perform fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level.

[0151] It is worth noting that although only some basic functional modules are disclosed in the embodiments of the present invention, it does not mean that the composition of the present system is limited to the above basic functional modules. On the contrary, what the present embodiment wants to express is that on the basis of the above basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. In other words, the present system is open rather than closed. Just because the present embodiment only discloses individual basic functional modules, it cannot be considered that the protection scope of the claims of the present invention is limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above devices are described in terms of functions and are described separately in various units and modules. Of course, when implementing the present invention, the functions of each unit and module can be implemented in the same or one or more software and / or hardware.

[0152] like Figure 5 As shown, the present invention also provides an electronic device, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the SOA-based fault diagnosis method.

[0153] Figure 5 Schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 5 The electronic device provided in the embodiment of the present invention includes: one or more processors 710 and a storage device 720; the processor 710 in the electronic device may be one or more, Figure 5A processor 710 is taken as an example; the storage device 720 is used to store one or more programs; the one or more programs are executed by the one or more processors 710, so that the one or more processors 710 implement the SOA-based fault diagnosis method as described in any one of the embodiments of the present invention.

[0154] The electronic device may further include: an input device 730 and an output device 740 .

[0155] The processor 710, storage device 720, input device 730 and output device 740 in the electronic device can be connected via a bus or other means. Figure 5 The example of connecting through bus is taken in the following.

[0156] The storage device 720 in the electronic device is a computer-readable storage medium that can be used to store one or more programs, which can be software programs, computer executable programs, and modules, such as program instructions / modules corresponding to the SOA-based fault diagnosis method provided in the embodiment of the present invention. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the storage device 720, that is, the SOA-based fault diagnosis method in the above method embodiment is implemented.

[0157] The storage device 720 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the storage device 720 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the storage device 720 may further include a memory remotely arranged relative to the processor 710, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0158] The input device 730 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. The output device 740 may include a display device such as a display screen.

[0159] The present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the SOA-based fault diagnosis method.

[0160] Specifically, the computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0161] The present invention also provides a vehicle, wherein the vehicle is provided with the SOA-based fault diagnosis system as described above.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fault diagnosis method based on SOA, characterized in that: include: A data synchronization step includes uploading to cloud storage in response to key data captured in real time, wherein the key data includes tracking point information and key logs; A service monitoring step, including comprehensively monitoring the SOA service status based on the SOME / IP protocol, and synchronizing the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service; The log reporting step includes triggering a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status; The fault analysis step includes performing fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level.

2. The SOA-based fault diagnosis method according to claim 1, characterized in that: The data synchronization step includes uploading to cloud storage in response to key data captured in real time, wherein the key data includes tracking point information and key logs, and further includes: Real-time data collection, capturing the buried point information and key logs during vehicle operation to form the key data; Preprocessing the key data, including unifying timestamps, converting data types, and performing corresponding formatting and compression; Using an encryption algorithm to encrypt the pre-processed key data; Based on a secure channel, the encrypted key data is uploaded to the cloud storage.

3. The SOA-based fault diagnosis method according to claim 1, characterized in that: The service monitoring step includes comprehensively monitoring the SOA service status based on the SOME / IP protocol, and synchronizing the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service, and further includes: Initialize service status monitoring and configure monitoring parameters of the SOME / IP protocol, including monitoring period, monitoring range, and abnormal threshold; Key status information collection: periodically collect the status information of the provision, discovery, subscription, stop, response and value sending of the SOA service; Exception information capture: real-time monitoring and capture of exception information in the SOA service, including response timeout and data error; Status information synchronization: synchronizing the collected status information and the abnormal information to the cloud.

4. The SOA-based fault diagnosis method according to claim 1, characterized in that: The log reporting step includes triggering a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status, and further includes: Based on the SOA service status, detecting anomalies in the functional link through preset rules; When an anomaly is detected, an alarm message is generated containing the node location, upstream and downstream node information, and anomaly details; The alarm information is reported to the cloud, and the overall log capture mechanism is started to capture log information corresponding to the alarm information.

5. The SOA-based fault diagnosis method according to claim 4, characterized in that: The fault analysis step includes performing fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level, and further includes: In response to the received warning information and log information, judging whether the function is abnormal and the abnormality level in combination with the vehicle status, the SOA service status and the function preset conditions; A fault tree is generated based on the abnormal function, and the fault type and fault cause are analyzed according to the alarm information and the log information.

6. The SOA-based fault diagnosis method according to claim 1, characterized in that: It also includes troubleshooting steps, including: Based on the fault judgment results, confirm the nature of the fault and the scope of impact; Based on the fault, executing corresponding emergency measures, including adjusting configuration to bypass the fault point; In response to the emergency measures, a corresponding repair plan is executed, and the repair effect is verified until the fault is resolved.

7. A fault diagnosis system based on SOA, characterized in that: include: A data synchronization module is configured to include uploading to cloud storage in response to key data captured in real time, wherein the key data includes buried point information and key logs; A service monitoring module, configured to comprehensively monitor the SOA service status based on the SOME / IP protocol, and synchronize the monitoring information to the cloud in real time, wherein the monitoring information includes key status information of the SOA service; A log reporting module is configured to trigger a cloud log reporting mechanism when a function link abnormality is detected based on the SOA service status; The fault analysis module is configured to perform fault judgment in response to the received reporting log and the key status information of the SOA service, wherein the fault judgment includes locating the fault source and judging the fault level.

8. An electronic device, characterized in that: include: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the method described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: It stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the method described in any one of claims 1 to 6.

10. A vehicle, characterized in that: The vehicle is provided with the SOA-based fault diagnosis system as claimed in claim 7.

Images