Operation diagnosis method and system based on vehicle end cabin controller, and electronic equipment

Abstract

The invention relates to the technical field of vehicles, and discloses an operation diagnosis method and system based on a vehicle end cabin controller and electronic equipment, and the method comprises the steps: calling a diagnosis service in response to a service request for a target diagnosis object, periodically monitoring the resource occupation condition of a process, and receiving an event notification triggered by the process in real time; when an event notification triggered by a process is received, reading key business data related to the notification event from the data pool to perform global judgment so as to determine an abnormal event and an abnormal level; executing resetting measures of corresponding levels according to different abnormal levels of the abnormal events; and according to a predefined information transmission rule in the target diagnosis object system, uploading the diagnosis data file at the occurrence moment of the abnormal event. According to the scheme, immediate disk storage of field fault data is realized, and powerful support is provided for subsequent fault analysis and processing.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and specifically to an operation diagnosis method, system, storage medium and electronic equipment based on a vehicle-side cockpit controller. Background Art

[0002] As the integration of vehicle domain controllers continues to increase, the realization of single-point functions increasingly relies on the close coordination between multiple controllers. In this context, the number of software modules in the domain controller has increased dramatically, and the interdependencies between modules have become more complex. In order to meet this challenge, an innovative soft diagnostic data collection strategy is urgently needed.

[0003] The existing solution mentions that when a vehicle fails, a diagnostic fault code is sent to the cloud platform. The cloud platform starts the data acquisition interface based on the data acquisition interface start instruction sent by the diagnostic fault code, and the vehicle side starts the data acquisition interface to collect and store the vehicle's operating data in a temporary storage. When the vehicle fails again, the diagnostic fault code and the operating data in the temporary storage are sent to the cloud platform or stored in a permanent storage.

[0004] The existing solutions have the following limitations:

[0005] 1. Over-reliance on network stability: When the actual vehicle network is unstable or disconnected, the entire solution will not be able to be executed.

[0006] 2. Fault data is not captured in time: When a fault occurs for the first time, only the data in the memory is updated, and the data is only written to the disk or uploaded to the cloud when the fault occurs again. In addition, the network delay between the cloud and the vehicle may cause the fault data to be captured in time, thus affecting the accuracy of fault diagnosis. This method may cause data to be captured in time when solving occasional problems, and because the causes of occasional problems are diverse and may be different each time, it is difficult to accurately determine the cause of the fault.

[0007] 3. Lack of multi-module collaborative fault handling capabilities: Existing solutions are mainly designed for single module failures. There is a lack of effective rule-based judgment mechanisms for problems caused by coordination or timing between multiple modules. It is impossible to accurately determine whether a triggering event is a fault, which leads to untimely data storage.

[0008] 4. Limited to snapshot data storage: The existing solution only records snapshot data when a failure occurs, lacks recovery measures when the failure actually occurs, and cannot effectively avoid the adverse impact of the failure on user experience.

[0009] 5. Limited to a single controller: In case of business function anomalies between controllers, data collection at the vehicle level cannot be provided. Summary of the invention

[0010] The purpose of the present invention is to provide an operation diagnosis method, system and electronic equipment based on a vehicle-side cockpit controller, which makes up for the problems existing in the prior art in vehicle-side diagnosis, such as excessive reliance on the network, untimely capture of fault data, lack of multi-module collaborative fault handling capabilities, and inability to provide vehicle-level data collection for abnormal business functions between controllers.

[0011] To achieve the above object, the present invention provides the following technical solutions:

[0012] In a first aspect, the present application provides an operation diagnosis method based on a vehicle-side cockpit controller, the method comprising:

[0013] Respond to service requests for target diagnostic objects, call diagnostic services, periodically monitor process resource usage, and receive event notifications triggered by processes in real time;

[0014] When receiving an event notification triggered by a process, read the key business data related to the notification event from the data pool for global judgment to determine the abnormal event and abnormal level;

[0015] According to the different abnormal levels of abnormal events, corresponding levels of recovery measures are implemented;

[0016] According to the information transmission rules pre-defined in the target diagnosis object system, the diagnostic data file at the time when the abnormal event occurred is uploaded.

[0017] Optionally, after the periodic monitoring of the resource occupancy of the process, the method further comprises: collecting statistics of resource occupancy data obtained by periodically monitoring the resource occupancy of each process, and updating the statistics results to a data pool;

[0018] The resource usage of the process includes execution time and memory consumption.

[0019] Optionally, the real-time reception of the event notification triggered by the process includes:

[0020] Drive related processes to monitor the system hardware status in real time; update the hardware status data, key business data of each module and DTC fault data to the data pool;

[0021] By judging whether the code operation logic, upstream and downstream process data and kernel service operation in the process are normal, deterministic abnormal events can be obtained; when it is impossible to judge, the event notification is triggered to the diagnostic service through inter-process communication for the non-deterministic abnormal events and deterministic abnormal events that cannot be judged;

[0022] The event notification includes deterministic abnormal event information and non-deterministic abnormal event information.

[0023] Optionally, the process is a basic service of the cockpit controller, a communication middleware, and a driver process of a key business;

[0024] Among them, the basic services of the cockpit controller include MCU services, SOA services, TSP services and diagnostic services;

[0025] The key business data includes statistical information, key status, and business cache.

[0026] Optionally, when receiving an event notification triggered by a process, reading key business data related to the notification event from a data pool for global judgment to determine the abnormal event and the abnormal level includes:

[0027] When receiving an event notification triggered by any process, read the log monitoring information of the time period adjacent to the time when the exception occurred in the log space, as well as the process variables of all processes in the data pool, and store them on disk as the first storage file;

[0028] When monitoring obtains abnormal resource usage, the abnormal resource usage data is integrated with the first disk storage file, and the files are stored as a second disk storage file; the second disk storage file is stored in a shared file partition between the QNX system and the operating system;

[0029] Read the second disk storage file in the shared file partition between the QNX system and the operating system, and match the rules with the predefined rules;

[0030] Determine whether the notification event is an abnormal event based on the rule matching result, and define the abnormal level based on the fault type, nature and severity of the abnormal event;

[0031] The abnormality levels include single-point abnormality and multi-point abnormality.

[0032] Optionally, the executing corresponding levels of restoration measures for different abnormal levels of abnormal events includes:

[0033] For multi-point anomalies, verify whether the triggered event notification is reasonable. After the verification is completed, execute different levels of recovery measures, including: when an abnormal event occurs, perform preliminary recovery of the abnormality by calling the recovery interface provided by each process; if the initial recovery is unsuccessful, restart the process and QNX system where the abnormality occurs; or, identify through the MCU system whether it is an abnormality of the peer controller. If so, notify the peer controller of the abnormal event.

[0034] Optionally, uploading the diagnostic data file at the time when the abnormal event occurs according to the information transmission rules predefined in the target diagnosis object system includes:

[0035] The target diagnostic objects include QNX system and operating system;

[0036] When the target diagnostic object is the QNX system, the diagnostic service on the operating system side is notified of the occurrence of an abnormal event based on the publish-subscribe model DDS, and the diagnostic data file at the time of the abnormal event is uploaded;

[0037] When the target diagnosis object is the operating system, the TSP service inside the operating system is notified to send a request to the cloud to upload the soft diagnosis data file.

[0038] In a third aspect, the present application also provides an operation diagnosis system based on a vehicle-side cockpit controller, the system comprising:

[0039] The data collection module is used to respond to service requests for target diagnostic objects, call diagnostic services, periodically monitor the resource usage of processes, and receive event notifications triggered by processes in real time;

[0040] The decision module is used to read key business data related to the notification event from the data pool to make a global judgment when receiving an event notification triggered by the process, so as to determine the abnormal event and abnormal level;

[0041] An execution module is used to execute corresponding levels of recovery measures according to different abnormal levels of abnormal events;

[0042] The analysis module is used to upload the diagnosis data file at the time when the abnormal event occurs according to the information transmission rules pre-defined in the target diagnosis object system.

[0043] In a third aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method steps as described in any one of the first aspects.

[0044] In a fourth aspect, the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the method steps as described in any one of the first aspects.

[0045] The beneficial effects of the present invention are embodied in:

[0046] The above-mentioned operation diagnosis method, system and electronic equipment based on the vehicle-side cockpit controller can realize the instant storage of fault site data, providing strong support for subsequent fault analysis and processing.

[0047] The above-mentioned operation diagnosis method, system and electronic equipment based on the vehicle-side cockpit controller mainly include four parts: data collection, decision-making, regression and analysis. It effectively solves the following key problems:

[0048] 1. Independent operation and diagnosis of the vehicle-side cockpit controller subsystem: Each subsystem in the vehicle-side cockpit controller (MCU system, QNX system, Android operating system) runs its own rule engine and diagnostic service. The decision-making process of these subsystems is independently completed by the vehicle-side "operating brain" without relying on the cloud backend.

[0049] 2. Instant data preservation when a fault occurs: Once a fault occurs, the soft diagnostic service in each subsystem will immediately save the relevant data to disk. This process only relies on the inter-process communication and file reading function inside the controller to ensure fast data capture and storage.

[0050] 3. Accurate judgment and processing of multi-trigger source faults: When encountering a trigger event, the soft diagnosis service can distinguish and judge multiple possible trigger sources. For example, when the backlight of the car screen is turned off, it may be that the user manually turns off the screen, or the system automatically shuts down due to high temperature, high pressure or energy saving. This method effectively solves the coordination problem between multiple modules through preset rules and priorities.

[0051] 4. Design and application of graded recovery measures: This paper designs corresponding recovery measures for different types of faults. When a fault occurs, different levels of recovery measures are taken according to the nature and severity of the fault to achieve rapid recovery or reduce potential risks.

[0052] 5. Realize synchronous data storage among multiple controllers to quickly and accurately locate timing and logic anomalies between related components. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for the specific embodiments or the description of the prior art. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn according to the actual scale.

[0054] Figure 1 A flow chart of the operation diagnosis method based on the vehicle-side cockpit controller provided by the present invention;

[0055] Figure 2 A flow chart of the diagnostic method for the QNX subsystem provided by the present invention;

[0056] Figure 3 A flow chart of the diagnostic service method for SOA handware anomalies provided by the present invention;

[0057] Figure 4 A schematic diagram of an operation diagnosis system based on a vehicle-side cockpit controller provided by the present invention;

[0058] Figure 5 The present invention provides a schematic structural diagram of an electronic device. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0060] The embodiment of the present application provides an operation diagnosis method, system and electronic device based on a vehicle-side cockpit controller, which are mainly used in vehicle-mounted equipment. The method can be applied to a terminal, a server, or a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, etc.

[0061] The following embodiment takes the vehicle-side cockpit controller as an example to elaborate the design process of the method in detail. The diagnostic method proposed in the embodiment of the present invention realizes the instant storage of fault scene data, which provides strong support for subsequent fault analysis and processing.

[0062] In one embodiment, Figure 1 As shown, an embodiment of the present invention provides an operation diagnosis method based on a vehicle-side cockpit controller, the method comprising:

[0063] S101 responds to the service request for the target diagnosis object, calls the diagnosis service, periodically monitors the resource usage of the process, and receives event notifications triggered by the process in real time;

[0064] S102: When receiving an event notification triggered by a process, read key business data related to the notification event from the data pool to perform a global judgment to determine the abnormal event and abnormal level;

[0065] S103 executes corresponding level of restoration measures according to different abnormal levels of abnormal events;

[0066] S104 uploads the diagnosis data file at the time when the abnormal event occurs according to the information transmission rules predefined in the target diagnosis object system.

[0067] The above steps S101-S104 summarize a larger protection scope, which mainly faces the diagnosis object of the cockpit controller, including the basic services of the two subsystems QNX and Android, the communication middleware and the driver process of the key points.

[0068] In the above embodiment, after executing step S101 to periodically monitor the resource occupancy of the process, the method further includes: collecting statistics on resource occupancy data obtained by periodically monitoring the resource occupancy of each process, and updating the statistics results to the data pool;

[0069] The resource usage of the process includes execution time and memory consumption.

[0070] In the above embodiment, before executing step S101, the process includes: driving the relevant process to monitor the system hardware status in real time; updating the hardware status data, key business data of each module and DTC fault data to the data pool;

[0071] By judging whether the code operation logic, upstream and downstream process data and kernel service operation in the process are normal, deterministic abnormal events can be obtained; when it is impossible to judge, the event notification is triggered to the diagnostic service through inter-process communication for the non-deterministic abnormal events and deterministic abnormal events that cannot be judged;

[0072] The event notification includes deterministic abnormal event information and non-deterministic abnormal event information.

[0073] Optionally, the process is a basic service of the cockpit controller, a communication middleware, and a driver process of a key business;

[0074] Among them, the basic services of the cockpit controller include MCU services, SOA services, TSP services and diagnostic services;

[0075] The key business data includes statistical information, key status, and business cache.

[0076] In step S102 of the above embodiment, when a process-triggered event notification is received, key business data related to the notification event is read from the data pool for global judgment to determine the abnormal event and abnormal level, including:

[0077] When receiving an event notification triggered by any process, read the log monitoring information of the time period adjacent to the time when the exception occurred in the log space, as well as the process variables of all processes in the data pool, and store them on disk as the first storage file;

[0078] When monitoring obtains abnormal resource usage, the abnormal resource usage data is integrated with the first disk storage file, and the files are stored as a second disk storage file; the second disk storage file is stored in a shared file partition between the QNX system and the operating system;

[0079] Read the second disk storage file in the shared file partition between the QNX system and the operating system, and match the rules with the predefined rules;

[0080] Determine whether the notification event is an abnormal event based on the rule matching result, and define the abnormal level based on the fault type, nature and severity of the abnormal event;

[0081] The abnormality levels include single-point abnormality and multi-point abnormality.

[0082] In step S103 of the above embodiment, executing corresponding levels of restoration measures for different abnormal levels of abnormal events includes:

[0083] For multi-point anomalies, verify whether the triggered event notification is reasonable. After the verification is completed, execute different levels of recovery measures, including: when an abnormal event occurs, perform preliminary recovery of the abnormality by calling the recovery interface provided by each process; if the initial recovery is unsuccessful, restart the process and QNX system where the abnormality occurs; or, identify through the MCU system whether it is an abnormality of the peer controller. If so, notify the peer controller of the abnormal event.

[0084] In step S104 of the above embodiment, uploading the diagnostic data file at the time when the abnormal event occurs according to the information transmission rules predefined in the target diagnosis object system includes:

[0085] The target diagnostic objects include QNX system and operating system; wherein, the diagnostic services for QNX system and Android operating system are basically the same, except for the uploading of diagnostic data files in step S104, which is slightly different. The differences are mainly reflected in:

[0086] When the target diagnostic object is the QNX system, the diagnostic service on the operating system side is notified of the occurrence of an abnormal event based on the publish-subscribe model DDS, and the diagnostic data file at the time of the abnormal event is uploaded;

[0087] When the target diagnostic object is the Android operating system, the TSP service inside the operating system is notified to send a request to the cloud to upload the soft diagnostic data file.

[0088] Optionally, a specific embodiment is provided based on the above content:

[0089] Taking the QNX system as an example, Figure 2 The core methods for the QNX subsystem diagnostic service are shown below:

[0090] a1: Each business process monitors its own code operation logic and whether the upstream and downstream data are normal. If an abnormal event occurs, the inter-process communication notifies the diagnostic service;

[0091] a2: After receiving the abnormal event notification, the diagnostic service reads the logs stored 10 seconds before the event and 10 seconds after the event from the log space and stores them on disk;

[0092] a3: After receiving the abnormal event notification, the diagnostic service reads the process variables of all current processes from the data pool and stores them on disk;

[0093] a4: In addition to passively receiving notifications of abnormal events triggered by processes, the diagnostic service can also actively monitor the resource usage of all processes in the system, including execution time and memory consumption.

[0094] When resource usage is abnormal, the real-time resource usage data and the data involved in a1 and a2 are saved to disk;

[0095] a5: Integrate and package multiple files into one file and store it in the shared file partition of QNX and Android;

[0096] a6: The diagnostic service collects the results and performs calculations and rule matching. It identifies the abnormal level of the current trigger event based on the matching results and executes necessary recovery measures.

[0097] a7: Based on the publish-subscribe model DDS, notify the Android-side diagnostic service that an abnormal event has occurred, and upload the soft diagnostic data file at the corresponding time when the network is allowed.

[0098] In one embodiment, the core method of the diagnostic service of the Android operating system is similar to that of the QNX side, with the only difference being step b7, where the Android system needs to notify the TSP service (TSP_Service) inside the Android system to request the cloud to upload the soft diagnostic file. The TSP (Telematics Service Provider) service is a business model that provides connection, management, and application services for vehicle-related data.

[0099] To further describe the above embodiment, typical stages of data collection, decision-making, execution, and analysis of the QNX system diagnostic service are introduced respectively:

[0100] Data collection phase:

[0101] 1. The QNX-side driver-related processes need to monitor the hardware status (such as backlight brightness, camera peripheral status, volume status, etc.) in real time and update the status data to the QNX data pool.

[0102] 2. Each QNX system process needs to update the key business data of various modules (including statistical information, key status, business cache, etc.) to the QNX data pool. Taking the power management module as an example, the key business data includes power supply voltage, temperature, power mode, vehicle mode, etc.

[0103] 3. Each process needs to update the data related to DTC faults to the QNX data pool.

[0104] 4. The diagnostic service periodically monitors the resource usage and heartbeat of each process and updates the statistical information to the QNX data pool.

[0105] 5. Each process identifies the trigger notification and sends it to the diagnostic service, including abnormal events determined within the process (such as logic abnormalities, upstream and downstream process data abnormalities, kernel service operation abnormalities) and notification events that cannot be directly judged as abnormal (such as the screen brightness value is set to zero, etc.). For such notification events, the diagnostic service needs to pull the data of each module related to the brightness value setting function from the data pool and make a global judgment to determine whether it is a clear abnormal event. Each module should notify the soft diagnostic service through the high-priority inter-process communication capability.

[0106] Decision-making stage:

[0107] The diagnostic service determines whether the triggering event is a clear abnormal event and its abnormal level based on predefined rules. For single-point abnormalities, the soft diagnostic service does not require additional decisions. However, for chain problems caused by multiple points, it is necessary to reversely infer whether the cause of the event triggering is reasonable.

[0108]

[0109] For example, after the driver module recognizes that the backlight value is set to 0, it notifies the soft diagnostic service. The soft diagnostic service identifies the data of each module related to the brightness function based on priority. When high temperature and high pressure are identified as abnormal, the event is judged as a normal scene, because under high temperature and high pressure, the system is in a hardware protection state for its own controller, and the screen backlight will be turned off, making it clear that the trigger event is not abnormal. On the contrary, if the above conditions are all normal, the event needs to be marked as an abnormal event.

[0110] Execution phase:

[0111] According to the decision results, the following corresponding treatment measures are implemented according to the level of abnormal events:

[0112] The system quickly takes snapshots of key business data and writes them to disk. These data include but are not limited to detailed logs within the application, all contents in the data pool, and network communication logs captured by TCPDUMP. In particular, TCPDUMP, as a network packet capture tool, uses an efficient way to store the captured messages: cyclic storage in a specific area designated in memory, rather than directly writing to disk files in real time. This design is intended to reduce the risk of disk damage and mitigate performance loss.

[0113] When a fault occurs, the latest 5S data in the TCPDUMP memory and the 5S data to be received are integrated and written to the disk.

[0114] 2. Each process provides a recovery interface, and the diagnostic service attempts to perform a preliminary recovery of the exception by calling the recovery interface. If the initial recovery is unsuccessful, the system can perform a restart operation on the process with the exception, and restart the entire QNX system if necessary.

[0115] 3. Identify whether it is an abnormality of the peer controller. If so, notify the peer that an abnormal event has occurred and execute necessary processing strategies.

[0116] Analysis phase:

[0117] After the QNX system completes the writing of snapshot data to disk, it stores the data in a shared partition between the QNX and Android systems.

[0118] Subsequently, the Android system is notified of the abnormal event through the intra-domain communication mechanism of the shared partition.

[0119] After receiving the notification, the Android system establishes a connection with the cloud to upload the data.

[0120] The data is transferred from the QNX system to the Android side via the NFS protocol, and then uploaded to the cloud for analysis and dashboard display.

[0121] In addition, the system supports the USB export function, which automatically copies all files in the path where the soft diagnostic data is located to the USB disk for offline analysis and archiving. The following table shows an example of abnormal events.

[0122]

[0123]

[0124] The above table is an example of some abnormal events. The table defines the level and the repair measures that need to be performed for some abnormalities. When an abnormality is identified in other controllers, the predefined CAN message specifies the signal and notifies the counterparty in an event-triggered manner. After receiving the notification event, the counterparty immediately takes measures to write the application log and TCPDUMP log of this controller to the disk. Multiple controllers analyze abnormal events based on the same timestamp, which facilitates the rapid location of problems in the entire vehicle.

[0125] Based on the above technical solution, a diagnostic service implementation example for SOA counterparty abnormalities is provided, such as Figure 4 As shown:

[0126] 1: SOA_Service, used to determine the abnormal state of the monitoring counterpart; it includes abnormalities such as disconnection, timeout, and service not online, and notifies the diagnostic service Diag_Service of the C++ layer of abnormal events;

[0127] 2: After receiving the abnormal notification event, the diagnostic service Diag_Service extracts the SOA module log, key business data in the data center, the latest 5S data of TCPDUMP, and the 5S data to be received, and stores them on the disk to UFS.

[0128] 3: The diagnostic service Diag_Service needs to notify the counterpart SOA of the exception and inform the counterpart of the exception type. First, assign the corresponding CarProperty to the Android VHAL.

[0129] 4: VHAL communicates with MCU_Service on the QNX side and passes the corresponding value of CarProperty;

[0130] 5: MCU_Service communicates with MCU based on the intra-domain bus (SPI) to transfer the value of the abnormal signal;

[0131] 6: MCU triggers the corresponding CAN signal and sends it to the peer controller. The peer controller processes it on its own;

[0132] 7: Diag_Service requests TSP_Service to upload the file;

[0133] 8: TSP_Service allows network upload, and transmits the soft diagnosis data file to the cloud in the form of fault ID + timestamp + snapshot data. The cloud will display and store the data on the dashboard and provide a download link.

[0134] During the whole process, Diag_Service only writes to the disk and uploads once for the same module, the same signal, and the same abnormal type in the same driving cycle. When the abnormal event occurs again, only the number of times is accumulated and the statistical data is sent at the next startup.

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

[0136] Based on the same inventive concept, the embodiment of the present application also provides an operation diagnosis system based on a vehicle-side cockpit controller for implementing the above-mentioned operation diagnosis method based on a vehicle-side cockpit controller. The implementation scheme for solving the problem provided by the system is similar to the implementation scheme recorded in the above-mentioned method, so the specific limitations in one or more embodiments of the operation diagnosis system based on the vehicle-side cockpit controller provided below can be found in the above limitations on the above-mentioned operation diagnosis method based on the vehicle-side cockpit controller, which will not be repeated here. It can be understood that the above description of its method is also applicable to the description of the system.

[0137] In one embodiment, an operation diagnosis system based on a vehicle-side cockpit controller is also provided. The embodiments of the present invention are described below in conjunction with the accompanying drawings. Figure 4 As shown, the system specifically includes:

[0138] The data collection module 110 is used to respond to service requests for target diagnostic objects, call diagnostic services, periodically monitor the resource usage of processes, and receive event notifications triggered by processes in real time;

[0139] The decision module 120 is used to read key business data related to the notification event from the data pool to make a global judgment when receiving an event notification triggered by a process, so as to determine the abnormal event and the abnormal level;

[0140] An execution module 130 is used to execute corresponding levels of restoration measures according to different abnormal levels of abnormal events;

[0141] The analysis module 140 is used to upload the diagnosis data file at the time when the abnormal event occurs according to the information transmission rules predefined in the target diagnosis object system.

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

[0143] 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 an operation diagnosis method based on a vehicle-side cockpit controller.

[0144] 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 310 and a storage device 320; the processor 310 in the electronic device may be one or more, Figure 3 A processor 310 is taken as an example; the storage device 320 is used to store one or more programs; the one or more programs are executed by the one or more processors 310, so that the one or more processors 310 implement the method for processing node setting conflicts as described in any one of the embodiments of the present invention.

[0145] The electronic device may further include: an input device 330 and an output device 340 .

[0146] The processor 310, storage device 320, input device 330 and output device 340 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.

[0147] The storage device 320 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 operation diagnosis method based on the vehicle-side cockpit controller provided in the embodiment of the present invention. The processor 310 executes various functional applications and data processing of the electronic device by running the software programs, instructions and modules stored in the storage device 320, that is, the method for processing node setting conflicts in the above method embodiment is implemented.

[0148] The storage device 320 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 320 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 320 may further include a memory remotely arranged relative to the processor 310, 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.

[0149] The input device 330 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 340 may include a display device such as a display screen.

[0150] The present invention also provides a computer-readable storage medium, which stores a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of an operation diagnosis method based on a vehicle-side cockpit controller.

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

[0152] 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. An operation diagnosis method based on a vehicle-side cockpit controller, characterized in that: The method comprises: Respond to service requests for target diagnostic objects, call diagnostic services, periodically monitor process resource usage, and receive event notifications triggered by processes in real time; When receiving an event notification triggered by a process, read the key business data related to the notification event from the data pool for global judgment to determine the abnormal event and abnormal level; According to the different abnormal levels of abnormal events, corresponding levels of recovery measures are implemented; According to the information transmission rules pre-defined in the target diagnosis object system, the diagnostic data file at the time when the abnormal event occurred is uploaded.

2. The method according to claim 1, characterized in that After the periodic monitoring of the resource occupancy of the process, the method further includes: collecting statistics of resource occupancy data obtained by periodically monitoring the resource occupancy of each process, and updating the statistics results to a data pool; The resource usage of the process includes execution time and memory consumption.

3. The method according to claim 2, characterized in that The real-time reception of the event notification triggered by the process includes: Drive related processes to monitor the system hardware status in real time; update the hardware status data, key business data of each module and DTC fault data to the data pool; By judging whether the code operation logic in the process, the upstream and downstream process data and the kernel service are running normally, deterministic abnormal events can be obtained; when it is impossible to judge, the event notification is triggered to the diagnostic service through inter-process communication for the non-deterministic abnormal events and deterministic abnormal events that cannot be judged; The event notification includes deterministic abnormal event information and non-deterministic abnormal event information.

4. The method according to claim 3, characterized in that The processes are the basic services of the cockpit controller, the communication middleware and the driver processes of key businesses; Among them, the basic services of the cockpit controller include MCU services, SOA services, TSP services and diagnostic services; The key business data includes statistical information, key status, and business cache.

5. The method according to claim 1, characterized in that When receiving an event notification triggered by a process, the key business data related to the notification event is read from the data pool for global judgment to determine the abnormal event and the abnormal level, including: When receiving an event notification triggered by any process, read the log monitoring information of the time period adjacent to the time when the exception occurred in the log space, as well as the process variables of all processes in the data pool, and store them on disk as the first storage file; When monitoring obtains abnormal resource usage, the abnormal resource usage data is integrated with the first disk storage file, and the files are stored as a second disk storage file; the second disk storage file is stored in a shared file partition between the QNX system and the operating system; Read the second disk storage file in the shared file partition between the QNX system and the operating system, and match the rules with the predefined rules; Determine whether the notification event is an abnormal event based on the rule matching result, and define the abnormal level based on the fault type, nature and severity of the abnormal event; The abnormality levels include single-point abnormality and multi-point abnormality.

6. The method according to claim 5, characterized in that The recovery measures of corresponding levels for different abnormal levels of abnormal events include: For multi-point anomalies, verify whether the triggered event notification is reasonable. After the verification is completed, execute different levels of recovery measures, including: when an abnormal event occurs, perform preliminary recovery of the abnormality by calling the recovery interface provided by each process; if the initial recovery is unsuccessful, restart the process and QNX system where the abnormality occurs; or, identify through the MCU system whether it is an abnormality of the peer controller. If so, notify the peer controller of the abnormal event.

7. The method according to claim 1, characterized in that The method of uploading the diagnostic data file at the time when the abnormal event occurs according to the information transmission rules predefined in the target diagnosis object system includes: The target diagnostic objects include QNX system and operating system; When the target diagnostic object is the QNX system, the diagnostic service on the operating system side is notified of the abnormal event based on the publish-subscribe model DDS, and the diagnostic data file at the time of the abnormal event is uploaded; When the target diagnosis object is the operating system, the TSP service inside the operating system is notified to send a request to the cloud to upload the soft diagnosis data file.

8. An operation diagnosis system based on a vehicle-side cockpit controller, characterized in that: The system comprises: The data collection module is used to respond to service requests for target diagnostic objects, call diagnostic services, periodically monitor the resource usage of processes, and receive event notifications triggered by processes in real time; The decision module is used to read key business data related to the notification event from the data pool to make a global judgment when receiving an event notification triggered by the process, so as to determine the abnormal event and the abnormal level; An execution module is used to execute corresponding levels of recovery measures according to different abnormal levels of abnormal events; The analysis module is used to upload the diagnosis data file at the time when the abnormal event occurs according to the information transmission rules pre-defined in the target diagnosis object system.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method steps described in any one of claims 1 to 7 are implemented.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the method steps as claimed in any one of claims 1 to 7.

Images