Diagnostic event processing method and device, storage medium and electronic device

Abstract

The embodiment of the invention provides a diagnosis event processing method and device, a storage medium and an electronic device.The method comprises the steps that under the condition that a monitor on a target operating system partition monitors a first diagnosis event, jitter removal processing is conducted on the first diagnosis event till whether the first diagnosis event is a fault event or not is judged, the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of the current vehicle, the first diagnosis event is used for describing that the target monitored object is diagnosed to have a fault, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle; when it is judged that the first diagnosis event is the fault event, the first diagnosis event is reported to the main core in the multi-core processor through the target operating system partition, and the problem that in the prior art, according to a diagnosis event processing method, due to the fact that the event processing efficiency is low, the reliability of vehicle running is low is solved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of traffic control, and in particular, to a method and device for processing a diagnostic event, a storage medium, and an electronic device. Background Art

[0002] The electronic systems of modern vehicles are becoming increasingly complex. In order to ensure the reliability and safety of the vehicles, diagnostic functions are usually integrated, that is, by monitoring different components or component functions in the vehicle system and reporting possible faults.

[0003] At present, the diagnostic events in related technologies cannot adapt to multi-core systems, resulting in inefficient fault diagnosis and processing. In a multi-core processor environment, an effective method is needed to distinguish and confirm the real faults in diagnostic events to improve the safety and reliability of vehicle systems.

[0004] It can be seen that the method for processing diagnostic events in the related art has the problem of low reliability of vehicle operation due to low event processing efficiency. Summary of the invention

[0005] Embodiments of the present invention provide a method and device for processing a diagnostic event, a storage medium, and an electronic device to at least solve the problem that the diagnostic event processing method in the related art has low reliability of vehicle operation due to low event processing efficiency.

[0006] According to one embodiment of the present invention, a method for processing diagnostic events is provided, comprising: in a case where a monitor on a target operating system partition detects a first diagnostic event, de-jittering the first diagnostic event until it is determined whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of a current vehicle, the first diagnostic event is used to describe that the target monitored object is diagnosed as having a fault, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle; in a case where it is determined that the first diagnostic event is a fault event, the first diagnostic event is reported to the main core in the multi-core processor via the target operating system partition.

[0007] According to another embodiment of the present invention, a device for processing diagnostic events is provided, comprising: a de-jitter unit, for de-jittering a first diagnostic event when a monitor on a target operating system partition detects the first diagnostic event, until determining whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of a current vehicle, the first diagnostic event is used to describe that the target monitored object is diagnosed as having a fault, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle; and a reporting unit, for reporting the first diagnostic event to a main core in the multi-core processor via the target operating system partition when determining that the first diagnostic event is a fault event.

[0008] According to yet another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any one of the above method embodiments when run.

[0009] According to yet another embodiment of the present invention, there is provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0010] According to yet another embodiment of the present invention, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0011] Through the present invention, through de-jitter processing, false alarms caused by short-term signal fluctuations or noise can be reduced, and the accuracy of diagnosis can be improved. The target operating system partition runs on the target satellite core, which can achieve the isolation of fault diagnosis and vehicle core control, avoiding the impact of a single fault on the entire system. At the same time, the fault event is reported to the main core through a specific channel, ensuring the timely transmission and processing of fault information. In a multi-core processor architecture, different cores can undertake different computing tasks, which improves the processing power and reliability of the system. Therefore, it is possible to effectively process diagnostic events in the vehicle electronic system under the multi-core processor architecture, report real faults in a timely manner, reduce system misoperation, and improve the safety and reliability of vehicle operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a schematic diagram of a logical structure of a DEM multi-core distribution according to an embodiment of the present invention;

[0013] Figure 2 is a flowchart of a method for processing a diagnostic event according to an embodiment of the present invention;

[0014] Figure 3 A DEM hierarchical position and interaction components in an AUTOSAR architecture according to an embodiment of the present invention;

[0015] Figure 4 is a schematic diagram of multi-core communication according to an embodiment of the present invention;

[0016] Figure 5 is a schematic diagram of a satellite diagnostic event processing queue according to an embodiment of the present invention;

[0017] Figure 6 is a schematic diagram of a CompareAndSwap (CAS) lock-free atomic operation according to an embodiment of the present invention;

[0018] Figure 7 is a schematic diagram of a data exchange and communication mechanism between a satellite and a host satellite according to an embodiment of the present invention;

[0019] Figure 8 is a schematic diagram of another data exchange and communication mechanism between a satellite and a host satellite according to an embodiment of the present invention;

[0020] Fig. 9 It is a flowchart of another method for processing a diagnostic event according to an embodiment of the present invention.

[0021] Fig.10 It is a structural block diagram of a diagnostic event processing device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings and in combination with the embodiments.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0024] According to one aspect of an embodiment of the present invention, a method for processing a diagnostic event is provided. Optionally, in this embodiment, the logical structure diagram of the multi-core distribution of the DEM (Diagnostic Event Manager) module can be as follows: Figure 1 Specifically, Figure 1In the system, OS partition 0 and OS partition 1 run on core 0, and OS partition 2 runs on core 1. SWC (Software Components) and other BSW (Basic Software) monitor whether the state of the monitored object changes. RTE (Runtime Environment) is a key component in AUTOSAR (Automotive Open System Architecture). It mainly plays the role of an intermediate layer, connecting the upper-layer software components (SWC) and the lower-layer basic software modules (BSW). RTE's responsibilities include handling communication between software components, managing the calling sequence of components, and providing data exchange and synchronization services between components. In the AUTOSAR architecture, RTE ensures the independence and configurability of software components, so that components can be reused and transplanted between different ECUs (Electronic Control Units).

[0025] ECU, Electronic Control Unit, is an important component in automotive electronic systems. ECU is usually a microcontroller that receives sensor signals, executes control algorithms, and sends control commands to actuators. In modern vehicles, ECU is responsible for controlling various aspects of the car, from engine management, braking system, airbags, to infotainment system, etc. Under the AUTOSAR architecture, ECU is designed as a hardware platform to host the operation of software components, while software components and basic software modules interact through RTE to realize their respective functions. DEM receives the results of the monitor from SWC through RTE, that is, in the AUTOSAR architecture, when the monitor of SWC detects an abnormality, these abnormal information will be passed to the DEM module through RTE, allowing DEM to perform further fault management logic, such as debounce, fault storage, etc., to ensure the accuracy and timeliness of fault reporting.

[0026] FIM (Failure Information Management): FIM is a module under the AUTOSAR architecture, mainly used to manage fault information. It is responsible for collecting and storing fault information from various software components, including fault status, timestamp of fault occurrence, related data, etc. The FIM module is part of the Diagnostic Event Management (DEM) and is used to support fault confirmation, storage and reporting, as well as updating and clearing of fault status.

[0027] DCM (Diagnostic Communication Manager): The DCM module is responsible for managing diagnostic communications in the AUTOSAR architecture. It handles communication with external diagnostic tools, including receiving diagnostic service requests and sending responses. The DCM module performs diagnostic services according to the protocol defined by the AUTOSAR standard and interacts with other parts of the AUTOSAR architecture (such as DEM, NVM, RTE, etc.) to obtain the necessary information to respond to diagnostic service requests.

[0028] Figure 2 FIG. 1 is a flow chart of a method for processing a diagnostic event according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0029] Step S202, when the monitor on the target operating system partition detects the first diagnostic event, debounce the first diagnostic event until it is determined whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of the current vehicle, the first diagnostic event is used to describe that the target monitored object is diagnosed as having a fault, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle;

[0030] A method for processing a diagnostic event in an embodiment of the present invention can be applied to a scenario of processing a diagnostic event on a vehicle. At least some embodiments of the present application are described by taking the processing of a diagnostic event on a vehicle equipped with a multi-core processor as an example.

[0031] With the introduction and application of concepts such as new energy, advanced driver assistance, software-defined cars, and central integrated electrical and electronic architecture, it indicates that the previous distributed electrical and electronic architecture is developing towards a centralized electrical and electronic architecture with software centralization and domain controllers. It has obvious advantages in computing performance, communication bandwidth, and software updates and iterations. This trend has led to more and more complex automotive electrical and electronic architectures and higher performance requirements for automotive electronic control units. Moreover, the new electrical and electronic architecture integrates more and more complex control systems, and also faces more complex problems in terms of functional safety and information security. In order to solve these problems, many chip suppliers have launched multi-core processors.

[0032] Multi-core processors can solve the theoretical possibility of operating efficiency problems, but due to factors such as CPU resources, multi-core task allocation and scheduling, and inter-core communication, the performance of multi-core processors is not improved exponentially. Reasonable optimization of the multi-core operating system schedule has become a key technology to unleash the performance of multi-core processors.

[0033] However, compared with single-core systems, some application modules are limited in application in the multi-core field. For example, the diagnostic event processing module cannot fully adapt to the multi-core system. On the one hand, in a multi-core environment, applications on different cores may access shared resources at the same time, resulting in resource competition and deadlock problems, affecting the timely processing of diagnostic events. On the other hand, the diagnostic event processing module may not be able to effectively synchronize events between multiple cores. In addition, there are many other problems caused by the incompatibility of the diagnostic event processing module with the multi-core system.

[0034] Diagnostic management can collect diagnostic events on the car. Diagnostic events are used to diagnose the working status of a certain component of the car. Diagnostic management can collect diagnostic events to help diagnose the working status of a certain component of the car.

[0035] In order to at least partially solve the above technical problems, in this embodiment, a method for processing diagnostic events that is adapted to a multi-core system is provided, in which the reporting process of diagnostic events is managed through specific operating system partitions in the multi-core system to ensure effective communication and writing between different cores.

[0036] The DEM hierarchical position and interaction components in the AUTOSAR architecture can be Figure 3 As shown in the figure, the DEM module is a key component in the AUTOSAR (Automotive Open System Architecture) software architecture, which is responsible for managing and processing diagnostic events in the vehicle. The main functions of the DEM module include: Event monitoring: monitoring diagnostic events reported by sensors, actuators, and electronic control units (ECUs) in the vehicle. Debounce processing: performing a debounce algorithm on diagnostic events to distinguish between real faults and temporary or false alarm events. Fault confirmation: confirm whether the diagnostic event represents a real fault and set the corresponding DTC (Diagnostic Trouble Codes). Fault handling: taking appropriate measures based on the severity and type of the fault, such as notifying the driver, recording fault information, activating redundant systems, or limiting vehicle performance. Fault code management: managing the life cycle of fault codes, including setting, storing, clearing, and freezing fault codes. Reporting and communication: reporting diagnostic information and fault status to other systems in the vehicle, and communicating with external diagnostic tools.

[0037] Specifically, the functions of the DEM module include:

[0038] 1. Management of fault status reported by Monitor: The diagnostic monitor is a general entity that determines whether the component is operating normally. This monitoring function can identify specific fault types of the monitoring path (such as short circuit to ground, open load, etc.). The monitoring path represents the physical system or circuit being monitored (such as sensor input). Each monitoring path is associated with a diagnostic event. "Diagnostic event" defines the smallest unit that the Dem module can handle. The state of the "diagnostic event" represents the result of the monitor. Dem receives the results of the monitor from SW-C through RTE or other BSW modules. The Dem module uses EventId to manage the status of the system's "diagnostic event" and perform required operations on individual test results, such as storing a freeze frame.

[0039] 2. Check enabling conditions: In certain cases, the event algorithm reserves the parameters that depend on the operating system level. These parameters are combined and define a certain number of check scopes (such as correct voltage range, presence of associated components, Ignition status, startup monitoring time requirements, etc.) before the event report is accepted or the event is qualified. The Dem module provides the ability to report results (whether specific conditions are met) during event processing.

[0040] 3. Processing event de-jittering: ECU can implement various types of de-jittering to improve signal quality. Common de-jittering algorithms in DEM modules include: count-based de-jittering algorithm, time-based de-jittering algorithm, and Monitor internal de-jittering algorithm.

[0041] 4. Check the maturity of event algorithms.

[0042] 5. Check the fault storage condition: The storage condition is defined as a set of parameters that are assigned to a specific condition. As long as this condition is not met, the Dem module will not store the event into the event memory.

[0043] 6. The number of fault confirmations has been reached: After reporting the fault and entering the pending state, the fault confirmation process starts in Dem. This fault confirmation process leads to the confirmed state. For this purpose, the corresponding counter threshold and counter type are specified. The Dem module provides a configuration parameter DemEventConfirmationThreshold for each event, which defines the maximum number of test and failure cycles before the event becomes "confirmed" and enters the confirmed state.

[0044] 7. Trigger snapshot storage: "Event snapshot data" is the field data when the fault is confirmed, such as sensor values ​​or timestamps / mileage, stored when the event occurs. ISO-14229-1 defines two different types of event-related data: snapshot data (freeze frame) and extended data. The amount or set of event-related data stored is closely related to the OEM / fault and is therefore configurable. This data is provided by SW-C or other BSW modules.

[0045] 8. Fault indication: The Dem module provides the functionality to activate and deactivate the fault indication for each event stored in the event memory. The deactivation process is defined as the cure of the diagnostic event.

[0046] 9. Fault aging and clearing: If the fault condition of a specific event is not met within a certain period of time (operation cycle), the Dem module can delete the specific event from the event memory. This process is called "aging" or "unlearning".

[0047] Among them, DEM is located in the system service layer of the AUTOSAR architecture, mainly involving fault event monitoring, fault information reporting, and fault information storage (including storage of event-related data). This layer provides an interface between the operating system and the application. DEM is closely related to the diagnostic communication module and is responsible for processing diagnostic requests and responses.

[0048] Interactive components include:

[0049] RTE (Runtime Environment): DEM communicates with applications (such as software components, SWC) through RTE. RTE provides a communication interface that allows DEM to receive diagnostic events from applications and send diagnostic responses. Monitor: DEM interacts with the monitor, which is responsible for monitoring the status of the ECU and notifying DEM when the status changes. NVM (Non-Volatile Memory): DEM interacts with the NVM module to store and retrieve diagnostic events and related data. These data include fault codes, freeze frame data, etc. OS (Operating System): DEM relies on services provided by the operating system, such as task scheduling, memory management, etc.

[0050] Software components (SWC) and basic software modules (BSW): When the Monitor detects a change in the state of the monitored object, it notifies the DEM module to update the data. If the de-jitter algorithm determines that it is a fault, the NVM interface is called to save the diagnostic event, diagnostic event data, and fault snapshot information from the volatile memory storage area RAM to the non-volatile storage area (such as Flash or EEPROM). In addition, the DEM notifies the monitor of the error status data and presents it to the user in a warning state (status bit Warning Indicator). In short, SWC and BSW can act as error detection functions, and the Monitor module can present some important errors (OEM or standard regulations) to the user through channels.

[0051] Filter Services (optional) is an optional filtering service module in the AUTOSAR architecture, which is mainly used to process and filter data to ensure that only data that matches specific conditions or thresholds will be further processed or stored. For example, in diagnostic events, Filter Services can be used to filter unimportant events to reduce the burden on the DEM module.

[0052] SW-C providing data (used for event memory entries) SW-C, the full name of SoftwareComponent, is a software component in the AUTOSAR architecture that is responsible for providing specific functions. The SW-C mentioned here is a component that provides data for event storage. For example, when a fault event occurs, this SW-C will provide relevant data, such as sensor readings, event timestamps, etc. These data will be stored in the event memory for subsequent fault analysis and diagnosis.

[0053] SW-C control indicators (eglamps, text, message, etc.) This SW-C component is used to control the external indications of the ECU (Electronic Control Unit), such as indicator lights, text information, warning messages, etc., which are used to display the current status of the ECU or specific fault information to the user or other system components.

[0054] The ECU state management module is responsible for managing the overall state of the ECU. This includes tracking the ECU's operating mode (such as startup, running, sleeping, etc.), monitoring its health, and performing recovery operations when the ECU encounters a problem. The state management module needs to work in conjunction with the DEM module to ensure that diagnostic events correctly reflect the state of the ECU.

[0055] J1939Dem is a DEM module for the J1939 communication protocol. J1939 is a network communication standard widely used in commercial vehicles and industrial equipment. The J1939Dem module handles fault events and diagnostic information related to the J1939 network.

[0056] NVRAM Manager is a non-volatile random access memory (NVRAM) management module that manages NVRAM resources in the ECU. NVRAM is a memory that retains its data even after power is disconnected and is typically used to store diagnostic events, fault snapshots, and other important data. NVRAM Manager ensures the correct writing, protection, and recovery of data to support the fault storage and recovery functions of the DEM module.

[0057] These modules and services work together in the AUTOSAR architecture to ensure that the ECU can effectively perform self-monitoring, fault diagnosis, storage and reporting, and communicate with other system components. In a multi-core system, they may be distributed in different OS partitions (satellites), ensuring data consistency and real-time responsiveness of the system through efficient communication mechanisms (such as CAS, spin locks, etc.).

[0058] In a vehicle multi-core system, different operating system partitions are set up to separate and manage different functions. In this embodiment, a software component running on a specific operating system can be set up as a monitor to monitor diagnostic events, thereby monitoring a specified target monitored object. Here, the monitor can be set up in an operating system partition corresponding to a target monitored object of the vehicle system of the current vehicle. The target monitored object can be a specific component in the vehicle system or a subsystem of the vehicle system. In other words, the target monitored object can be actual vehicle hardware or a software part in the vehicle system, such as an engine control unit, a braking system, etc., that is, it can be a specific component or certain functions of a component. By setting each operating system partition to only process diagnostic events of the monitored object associated with it, the complexity and response time of data processing can be reduced.

[0059] In this embodiment, the target operating system partition runs on a satellite core in a multi-core processor. Here, the satellite core can be an auxiliary core in the multi-core processor used to run specific tasks or services. In a multi-core processor architecture, there are usually one or more main cores responsible for processing high-priority or complex tasks, while the satellite cores are used to run relatively independent tasks.

[0060] Considering that in vehicle systems, frequent false triggering of diagnostic events may lead to unnecessary warnings and interventions, thus affecting driving experience and safety, the diagnostic events can be debounced when a car is diagnosed with a fault. Here, debounce is a technology that prevents false or frequent triggering of diagnostic events. Its purpose is to distinguish between real faults and temporary or false alarm events, and avoid incorrect fault diagnosis due to signal fluctuations or sensor instability.

[0061] Optionally, in the event that the target monitored object is diagnosed with a fault (i.e., when the monitor detects a first diagnostic event), the first diagnostic event can be debounced to distinguish between a true fault event and a false alarm that may be caused by signal fluctuations or transient interference. This process continues until it can be determined whether the first diagnostic event represents an actual fault.

[0062] Here, for each operating system partition, an independent debounce algorithm can be set.

[0063] Step S204, when it is determined that the first diagnostic event is a fault event, reporting the first diagnostic event to a main core in the multi-core processor through the target operating system partition;

[0064] In this embodiment, the target operating system partition runs on the target satellite core of the multi-core processor. That is, the processing and management of diagnostic events can be performed in a partition independent of the main core. By running on the satellite core, the target operating system partition is isolated from other tasks and services running on the main core, thereby ensuring that the response and processing of diagnostic events are not affected by other non-real-time tasks and reducing the burden on the main core.

[0065] When the first diagnosis event is confirmed to be a fault event through debounce processing, the event can be reported to the main core of the multi-core processor through the target operating system partition for further analysis, decision and response.

[0066] The satellite core is responsible for processing the diagnostic events related to it, executing the debounce algorithm, etc. When the status of the diagnostic event reaches the "mature" state (that is, it is confirmed as a valid fault event) after debounce processing, the satellite core sends the updated event status to the main core through a specific communication mechanism, such as Figure 4 As shown, when satellite (core) 0 determines that event 0 is mature, the fault event can be reported to the main core; when satellite (core) 1 determines that event 1 is mature, the fault event can be reported to the main core; when satellite (core) 2 determines that event 2 is mature, the fault event can be reported to the main core.

[0067] Optionally, a reliable reporting mechanism may be set between the target operating system partition and the main core to ensure that the reporting of the fault event will not be lost, delayed or erroneous.

[0068] Optionally, the reporting mechanism may include but is not limited to shared memory, setting a first-in-first-out queue, setting a spin lock, an interrupt request, etc. By setting a reliable reporting mechanism, the main core can obtain and respond to fault event information in a timely and accurate manner.

[0069] Through the above steps, when the monitor on the target operating system partition detects the first diagnostic event, the first diagnostic event is de-jittered until it is determined whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to the target monitored object of the vehicle system of the current vehicle, the first diagnostic event is used to describe that the target monitored object is diagnosed as having a fault, and the target operating system partition runs on a target satellite core in the multi-core processor of the current vehicle; when it is determined that the first diagnostic event is a fault event, the first diagnostic event is reported to the main core in the multi-core processor through the target operating system partition, thereby solving the problem of low reliability of vehicle operation due to low event processing efficiency in the diagnostic event processing method in the related art.

[0070] In an exemplary embodiment, debounce processing is performed on the first diagnostic event until it is determined whether the first diagnostic event is a fault event, including:

[0071] S11, de-jittering the first diagnostic event reported by the monitor through the target operating system partition until it is determined whether the first diagnostic event is a fault event; or,

[0072] S12: De-jittering the first diagnostic event detected by the monitor, until it is determined whether the first diagnostic event is a fault event.

[0073] In vehicle electronic systems, electromagnetic interference, hardware failures, or software errors may cause short-lived diagnostic event signals. If these signals are not properly filtered, they may be mistaken for real faults, resulting in unnecessary warnings or system responses, or even triggering the erroneous pop-up of safety equipment such as airbags, posing a hidden danger to driving safety. Therefore, debounce processing can be used to ensure that only real and persistent fault events are reported, avoiding waste of resources and possible driving interference. In multi-core systems, different diagnostic events can correspond to different operating system partitions, and the robustness and efficiency of diagnostic event processing can be improved by combining debounce processing with multi-core processors.

[0074] In this embodiment, the debounce method can be performed either through the target operating system partition or directly through the monitor.

[0075] Optionally, the target operating system partition may be responsible for de-jittering the first diagnostic event reported by the monitor, that is, the target operating system partition receives the diagnostic event report from the monitor, and from the first time the event is received, the partition continuously monitors whether the event persists until the target operating system partition determines whether the event meets a preset end condition to confirm whether it is a real fault event. Here, the end condition may be that the event duration reaches a preset threshold, or that no new diagnostic event inconsistent with the current event is received within a preset time, etc. If the first diagnostic event meets the end condition, the first diagnostic event is confirmed to be a fault event; conversely, if the first diagnostic event does not meet the end condition, the first diagnostic event is confirmed to be a non-fault event.

[0076] For example, the satellite diagnostic event processing queue can be as follows Figure 5 As shown, taking the target core as satellite core 2 as an example, satellite core 2 can be associated with multiple monitors, for example, monitor 1, monitor 2, monitor 3, and monitor 4. Multiple monitors can report diagnostic events to satellite core 2, and then, satellite core 2 can process the reported diagnostic events in the order shown in the figure.

[0077] Optionally, de-jittering can also be performed on the monitor, that is, before the event is generated and reported, the monitor directly analyzes the monitored diagnostic event and determines through internal logic whether the first diagnostic event meets the preset end condition. If the first diagnostic event meets the preset end condition, the monitor will mark it as a fault event and report it.

[0078] It should be noted that the subject that performs the debounce processing can be selected based on the system priorities in the actual design, such as resource allocation, response time requirements, and system complexity.

[0079] Through this embodiment, the first diagnostic event is de-jittered by the target operating system or the monitor, so that the stability and efficiency of the fault diagnosis can be improved.

[0080] In an exemplary embodiment, de-jittering the first diagnostic event reported by the monitor is performed by the target operating system partition until it is determined whether the first diagnostic event is a fault event, including:

[0081] S21, starting from the first receipt of the first diagnostic event reported by the monitor, de-jittering the first diagnostic event reported by the monitor through the target operating system partition until one of the first end condition and the second end condition is met;

[0082] The first termination condition is that the duration of continuously receiving the first diagnostic event reported by the monitor reaches a preset time threshold, and the second termination condition is that before the duration of continuously receiving the first diagnostic event reported by the monitor reaches the preset time threshold, a second diagnostic event reported by the monitor is received; or,

[0083] The first termination condition is that the number of times the first diagnostic event reported by the monitor is continuously received reaches a preset number threshold, and the second termination condition is that before the number of times the first diagnostic event reported by the monitor is continuously received reaches the preset number threshold, a second diagnostic event reported by the monitor is received;

[0084] Among them, the second diagnostic event is used to describe that the target monitored object has not been diagnosed with a fault. When the first end condition is met, the first diagnostic event is determined to be a fault event. When the second end condition is met, the first diagnostic event is determined not to be a fault event.

[0085] In order to filter out short-term, non-continuous error signals caused by noise, unstable conditions or transient faults, and ensure that only persistent, real fault events are reported to the core processing unit of the system, the diagnostic events can be de-bounced. Similar to the aforementioned embodiment, the first diagnostic event reported by the monitor can be de-bounced through the target operation partition.

[0086] In this embodiment, an appropriate termination condition may be set, and when the termination condition is met, the first diagnostic event is determined to be a fault event.

[0087] Optionally, the continuity of the first diagnostic event can be determined, that is, a preset time threshold can be set to determine whether the first diagnostic event lasts long enough to confirm that it is a real fault. For example, if the sensor continuously sends signals about brake system faults in a short period of time, and the duration of these signals exceeds a preset time threshold (such as 5 seconds), then the system will consider that there is indeed a fault in the brake system.

[0088] Optionally, before the first termination condition is reached, if the system receives a second diagnostic event that is opposite to the first diagnostic event, i.e., an event describing that the target monitored object (such as the braking system) has not been diagnosed with a fault, then the first diagnostic event will be determined as a non-fault event, thereby preventing misjudgment caused by short-term signal fluctuations.

[0089] Optionally, the first diagnostic event can also be judged by the number of times, that is, a preset number threshold is set to determine whether the first diagnostic event occurs repeatedly within a certain number of times to confirm that it is a real fault. For example, if the brake fault signal exists in 10 consecutive readings, then the brake system may have a real fault. Similarly, if the second diagnostic event is received before the preset number threshold is reached, the first diagnostic event will be judged as a non-fault event. This also helps to filter out false alarms caused by transient instability of sensors or actuators.

[0090] Through this embodiment, by setting an end condition to determine whether the first diagnosis event is a fault event, the accuracy of fault diagnosis can be improved.

[0091] In an exemplary embodiment, after reporting the first diagnostic event to the main core in the multi-core processor through the target operating system partition, the method further includes:

[0092] S3 1, encapsulating the event data of the first diagnostic event, and storing the encapsulated target event data in a first storage area, wherein the event data of the first diagnostic event is used to describe the first diagnostic event, and the target event data stored in the first storage area is allowed to be used by multiple cores in the multi-core processor, and the multiple cores include a target satellite core and a main core;

[0093] S32, when a target core among the multiple cores is to update a value of target event data, obtaining, through the target core, a value of the target event data stored in the first storage area, backing up the obtained first value of the target event data, and updating the obtained first value of the target event data to a second value;

[0094] S33, reacquiring the value of the target event data stored in the first storage area through the target core to obtain the current value of the target event data;

[0095] S34, when the current value of the target event data is the first value, updating the value of the target event data stored in the first storage area to the second value.

[0096] After processing the first diagnostic event and determining it to be a fault event, in order to ensure that each core in the multi-core processor can access consistent event information, the event data can be encapsulated and stored in a shared first storage area, thereby improving the integrity and consistency of data maintained in the multi-core system, especially when data synchronization between cores is required.

[0097] Optionally, the event data of the first diagnostic event can be packaged into a structured data packet, where the event data of the first diagnostic event may include detailed information about the event, including but not limited to: event type (i.e., the specific type of diagnostic time, such as hardware failure, software failure, sensor problem, etc.), timestamp (i.e., recording the time point when the diagnostic event occurs), event code (used to identify a specific fault type), event description, event level, etc. For example, FDC (Fault Detection Criteria), de-bounce status, and monitor status can be encapsulated into a 4-Byte data.

[0098] In this embodiment, the encapsulated target event data can be stored in the first storage area, which should be designed to support multi-core access, that is, allowing multiple cores (including target satellite cores and main cores) to read and write to ensure data sharing and communication.

[0099] Furthermore, in order to prevent data contention and inconsistency caused by multiple cores in a multi-core system accessing the same area, CAS (Compare And Swap, lock-free atomic operation) can be used to avoid data inconsistency problems caused by uncertainty in execution order and unpredictability of interrupts when multiple threads simultaneously rewrite a certain data. Here, the CAS operation is a lock-free atomic operation, which is often used in concurrent programming to achieve thread-safe data access. It involves three parameters: memory location, old value and new value. The CAS instruction checks whether the value of the memory location is the old value. If the same, the old value is replaced by the new value, otherwise no operation is performed. This operation is atomic, that is, it is either fully executed or not executed at all, and will not be interrupted by other threads. Therefore, when multiple threads try to access and modify the same shared variable, CAS can prevent data contention and inconsistency and ensure data consistency and integrity.

[0100] For example, Figure 6 As shown, when the target core (main core or satellite core) attempts to update the value of event data, it checks whether the variable value is still equal to the old value. If so, the old value can be successfully updated to the new value; if not, it means that another core has already updated the value. At this time, the CAS operation returns, and the target core can re-acquire the current value and proceed to the next step.

[0101] That is, if a data abc (value is 123) is used by multiple cores, if Core1 wants to update the data abc, it first obtains the old value of abc old before the update (value is 123), and then calculates the value of the data abc new to (321). When preparing to update (321) to abc, it obtains the value of abc again. If abc (value is 123) = abc old (value is 123), it means that no other core has updated the data during the calculation, and abc new (value is 321) can be directly updated to abc; if abc (value is 125) ≠ abc old (value is 123), it means that other cores have updated the data during the calculation, and the process is repeated again until the newly calculated value is updated to abc.

[0102] Specifically, when a target core among multiple cores (it can be any core, including but not limited to the main core or the target satellite core) needs to update the value of the target event data, it first obtains the value of the currently stored target event data from the first storage area, backs up this value (first value), and updates it to the second value based on the obtained first value. Here, by backing up the data, the original state of the data can be restored when the update fails or needs to be rolled back. The second value here refers to the value after the event data needs to be updated. That is to say, at this time, the event data in the first storage area has not actually been updated.

[0103] Furthermore, the target core reacquires the value of the target event data in the first storage area to obtain the current value, and then checks whether the current value is the same as the previously backed up first value. If the acquired current value is still the backed-up value (first value), it means that no other core has accessed the data during the update process, then the event data in the first storage area can be updated to the second value; if they are not the same, it means that other cores have accessed the data. In this case, the operation can be terminated or the update operation can be performed again, thereby avoiding overwriting of the event data after it has been modified by other cores, ensuring data consistency and preventing concurrent access problems in a multi-core environment.

[0104] Through this embodiment, event data is encapsulated and stored in a multi-core shared storage area, and data is updated through a comparison and exchange mechanism, thereby improving data consistency of diagnostic events and reliability of inter-core communication.

[0105] In an exemplary embodiment, a first-in first-out queue is respectively configured on each operating system partition of the vehicle system of the current vehicle, and a spin lock is configured on each first-in first-out queue on the operating system partition;

[0106] When it is determined that the first diagnostic event is a fault event, reporting the first diagnostic event to a main core in the multi-core processor through the target operating system partition includes:

[0107] S41, when it is determined that the first diagnostic event is a fault event, performing an enqueue operation through the target operating system partition to write event indication information of the first diagnostic event into a first-in-first-out queue on the target operating system partition, wherein during the enqueue operation, a spin lock of the first-in-first-out queue on the target operating system partition is in a locked state, and the event indication information is used to indicate that the first diagnostic event is a fault event;

[0108] S42, when the spin lock of the first-in-first-out queue on the target operating system partition is in an unlocked state, a dequeue operation is performed by the main core to read event indication information from the first-in-first-out queue on the target operating system partition, wherein during the dequeue operation, the spin lock of the first-in-first-out queue on the target operating system partition is in a locked state.

[0109] In this embodiment, after determining that the first diagnostic event is a fault event, the subject of the diagnostic event de-bouncing processing (i.e., it can be the target operating system partition or the monitor) can generate an event indication information to indicate that the first diagnostic event is a fault event, wherein the event indication information can only include information indicating whether the first diagnostic event is a fault event, or it can include key data of the first diagnostic event, such as event type, timestamp, etc.; further, the target operating system partition can write the event indication information into its corresponding first-in-first-out queue by executing a queue operation.

[0110] Here, the first-in-first-out queue is a special linear data structure, in which the addition and removal of data follows the first-in-first-out principle, that is, the element added to the queue first will be the first element to be removed. In this embodiment, the diagnostic event reporting process of different operating system partitions under the multi-core processor architecture is performed through the first-in-first-out queue, which can ensure that the events are processed in the order in which they are detected. This helps to maintain the timing of events.

[0111] Optionally, in this embodiment, the data exchange and communication mechanism between the satellite and the main core can be as follows: Figure 7 , Figure 8 As shown, specifically, in Figure 7 In the first-in-first-out queue corresponding to satellite 1, the first-written event 5 is read (dequeued) by the main core first, and the later-written event 6 is read (dequeued) by the main core later; Figure 8 In the first-in-first-out queue corresponding to satellite 2, satellite 2 writes (enters the queue) in the order of event 1, event 2, event 3, and event 4, and the main core reads (dequeues) in the order of event 1, event 2, event 3, and event 4. Among them, NULL is used to represent the state of "none" or "empty".

[0112] Furthermore, the consistency of data in a multi-core system can be ensured by combining a first-in-first-out queue with a spin lock. Here, a spin lock is a simple synchronization mechanism that allows one core to lock the data when accessing it, and other cores trying to access it will wait in a loop until the lock is released.

[0113] In this embodiment, during the enqueue operation, the spin lock of the first-in-first-out queue will be locked to ensure that the queue will not be accessed by the dequeue operation on other cores during the writing of the event indication information; further, before the main core is ready to read the fault event indication information, it will check whether the spin lock of the first-in-first-out queue on the target operating system partition is in an unlocked state. Only when the spin lock is in an unlocked state, the queue is allowed to be accessed by other cores, that is, the main core can safely perform the dequeue operation and read the first diagnostic event indication information from the first-in-first-out queue of the target operating system partition.

[0114] Optionally, during the read process, the spin lock will be locked again to prevent the queue from being modified by other cores during the read process.

[0115] Through this embodiment, by combining the use of a first-in-first-out queue and a spin lock, the event indication information of the first diagnostic event can be safely and efficiently transferred from the target operating system partition to the main core in a multi-core processor environment, avoiding data competition and inconsistency problems.

[0116] In an exemplary embodiment, after reporting the first diagnostic event to the main core in the multi-core processor through the target operating system partition, the method further includes:

[0117] When the first diagnostic event reported by the target operating system partition is received within a plurality of designated periods, the event snapshot data of the first diagnostic event is stored in the second storage area on the main core through the main core.

[0118] In this embodiment, after the first diagnostic event is determined to be a fault event and reported to the main core, the system needs to continuously monitor whether the fault event still exists within multiple specified cycles. Here, multiple specified cycles refer to a series of time windows or monitoring cycles set to confirm the stability and persistence of the fault event. For example, if the main core receives the first diagnostic event reported by the target operating system partition within three consecutive fault monitoring cycles, this may mean that the fault persists rather than being transient or a false alarm.

[0119] In order to further process and record these persistent fault events, the main core can store the event snapshot data of the first diagnostic event in the second storage area thereon. Here, the event snapshot data contains specific information of the fault event, such as the type of event, occurrence time, diagnostic parameters, etc. This information is helpful for subsequent fault analysis, recording and processing.

[0120] Here, the second storage area can be a storage space that can be accessed and used by the main core, which can be a memory area, a cache or a special storage structure of the main core, for storing and managing fault event data from the target operating system partition. Storing the event snapshot data in the second storage area can ensure the security and integrity of the data, and also facilitate the main core to quickly access the data when needed for further processing, such as generating, recording and transmitting fault codes, and taking corresponding system response measures.

[0121] Through this embodiment, by storing the fault event data in the second storage area of ​​the main core, the accuracy and reliability of system fault diagnosis can be improved.

[0122] In an exemplary embodiment, after debounce processing is performed on the first diagnostic event until it is determined whether the first diagnostic event is a fault event, the method further includes:

[0123] S61: When it is determined that the first diagnostic event is a fault event, use of a target monitored object is suppressed through a target operating system partition.

[0124] In this embodiment, when the first diagnostic event is determined to be a fault event, the use of the target monitored object can be suppressed through the target operating system partition, thereby preventing the confirmed fault event from causing further damage or risk to the vehicle system or other key components.

[0125] Optionally, inhibiting usage may take a variety of forms, depending on the nature and severity of the fault event.

[0126] Optionally, the use of fault functions can be restricted. For example, if the target monitored object is a component in the engine control system, once a fault is determined, the target operating system partition can restrict certain functions of the engine, such as reducing the maximum output power, etc., to prevent the fault from worsening or causing more serious safety problems.

[0127] Optionally, the affected system or component may be disabled. For example, if the target monitored object is a throttle of a car, the use of the throttle may be prohibited if it is determined that the throttle is faulty.

[0128] Optionally, depending on the type of fault, fault information can be sent to the driver through the vehicle's dashboard, central control screen or other warning systems to remind the driver to pay attention and take appropriate measures, such as finding a safe place to park or contacting professional maintenance services.

[0129] In addition, the car's emergency system can also be set up according to design requirements.

[0130] Through this embodiment, when it is determined that the target detected object has a fault, the target detected object is suppressed, which can effectively improve the stability and safety of the vehicle when encountering a fault.

[0131] As an optional exemplary embodiment, a multi-core system compatible with the diagnostic event processing module is taken as an example to explain the diagnostic event processing method of the present invention.

[0132] Specifically, the multi-core distribution of the data processing flow:

[0133] In the early stage of diagnostic event processing, the main issues that need to be addressed are event de-jittering and pre-storing freeze frames, and the most time-consuming of these is event de-jittering.

[0134] The basic unit of fault monitoring is the event. The reported event can come from the BSW module or the SWC module. The monitoring test (de-jitter filtering algorithm) of the event is determined by each module that reports the fault event. It is mainly divided into: time-based de-jitter, counter-based de-jitter, and monitor internal de-jitter.

[0135] When a fault information is just reported, the event status is often not confirmed (such as PREFAILED). The current freeze frame data needs to be recorded and stored. When the event status is confirmed after several times or time de-jittering, the pre-stored freeze frame data needs to be used.

[0136] In order to reduce the CPU main core's processing of a large number of frequent event de-jittering and pre-stored freeze frames, the technical solution is to distribute the de-jittering to different partitions (satellites), and cross-operating system partition communication will only be performed when the diagnostic event status changes (confirmed), and the pre-stored freeze frame action, which does not require very high immediacy, is placed on the main function.

[0137] Communication design between main satellites:

[0138] 1. In event debounce, when the interrupt of the main core and the tasks & interrupts of the satellite may update the debounced data and status, this solution adopts compare & exchange lock-free atomic operations to avoid data inconsistency problems caused by uncertainty in execution order and unpredictability of interrupts when multiple threads rewrite a certain data at the same time. The fault detection code, debounce status, and monitoring status are encapsulated into a 4-byte data, and the correctness of the data is guaranteed by the compare & exchange mechanism.

[0139] 2. Cross-core communication. When an event is processed in the operating system partition and the satellite needs to send the event confirmation status to the main core, the conflict between satellite enqueue (push) and main core dequeue (pop) is resolved: the event status is sent to the main core only after the event is confirmed, and a spin lock is used to ensure the security of data access; the event processing result FIFO queue is configured in each satellite (eliminating the Push conflict between satellites), and the conflict between the main core's Pop and the satellite's Push is resolved through a spin lock; when a satellite is Pushing, the main core can Pop on other satellites, providing a lock for each satellite to ensure the timing of event processing.

[0140] Combination Fig. 9 , the diagnostic event data processing flow can be completed. Specifically, on the target operating system partition, the monitor can report the fault status, check the enabling conditions and complete the debounce processing of the diagnostic event. When the diagnostic event is determined to be a fault event, it is judged that the event is mature and the event data of the diagnostic event is reported to the main core; in the main core, the fault storage condition can be checked. When the number of faults meets the fault storage condition, the snapshot storage is triggered, that is, the snapshot data of the diagnostic event is stored, and a fault indication is issued to prompt the user or driver of the vehicle fault.

[0141] The satellite is responsible for processing the diagnostic events related to it, executing the debounce algorithm, etc. When the status of the diagnostic event reaches the "mature" state (that is, it is confirmed as a valid fault event) after debounce processing, the satellite sends the updated event status to the main core through a specific communication mechanism. When the event status is "mature", the satellite is responsible for collecting and pre-storing snapshot data related to the event. After the subsequent event status is updated to the main core, the main core decides whether to store these data in NVM (non-volatile memory).

[0142] Optionally, in the present application, the satellite is also responsible for managing event suppression information within its partition, which is also synchronized to the main core when the event status is updated to ensure that the main core has a comprehensive understanding of the current status of the event.

[0143] Through this application, the debounce algorithm is distributed to different OS partitions (i.e., satellites) according to the function of the event, and each satellite handles a specific fault object. By limiting the frequency of communication across OS partitions, communication is only performed when the event state is "mature", and the use of CAS operations and spin locks is optimized to reduce communication overhead and improve communication efficiency. The DEM module can effectively work under a multi-core system architecture, handle different types of fault events, coordinate work with other OS partitions and modules, achieve reasonable allocation and efficient use of resources, and ensure data consistency and system stability. This design method makes full use of the parallel processing capabilities of multi-core processors and provides new ideas and solutions for the development of automotive electronic control software.

[0144] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of various embodiments of the present invention.

[0145] In the present embodiment, a processing device for diagnostic events is also provided, and the device is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made are not repeated here. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware is also possible and conceived.

[0146] Fig.10 is a structural block diagram of a diagnostic event processing device provided by an embodiment of the present invention, such as Fig.10 As shown, the device comprises:

[0147] a de-jitter unit 1002, configured to, when a monitor on a target operating system partition detects a first diagnostic event, de-jitter the first diagnostic event until determining whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of a current vehicle, the first diagnostic event is used to describe that a fault is diagnosed in the target monitored object, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle;

[0148] The reporting unit 1004 is configured to report the first diagnostic event to the main core in the multi-core processor through the target operating system partition when the first diagnostic event is determined to be a fault event.

[0149] It should be noted that the de-bouncing unit 1002 in this embodiment can be used to execute the above step S202, and the reporting unit 1004 in this embodiment can be used to execute the above step S204.

[0150] Through the embodiments of the present invention, when the monitor on the target operating system partition detects the first diagnostic event, the first diagnostic event is de-jittered until it is determined whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to the target monitored object of the vehicle system of the current vehicle, the first diagnostic event is used to describe that the target monitored object is diagnosed as having a fault, and the target operating system partition runs on a target satellite core in the multi-core processor of the current vehicle; when it is determined that the first diagnostic event is a fault event, the first diagnostic event is reported to the main core in the multi-core processor through the target operating system partition, thereby solving the problem of low reliability of vehicle operation due to low event processing efficiency in the method for processing diagnostic events in the related art.

[0151] In an exemplary embodiment, a de-jitter unit comprises:

[0152] a first de-jitter module, configured to perform de-jitter processing on a first diagnostic event reported by the monitor through a target operating system partition until it is determined whether the first diagnostic event is a fault event; or

[0153] The second de-jitter module is used to perform de-jitter processing on the first diagnostic event monitored by the monitor through the monitor until it is determined whether the first diagnostic event is a fault event.

[0154] In an exemplary embodiment, a de-jitter unit comprises:

[0155] A third de-jitter module is used for performing de-jitter processing on the first diagnostic event reported by the monitor through the target operating system partition starting from the first receipt of the first diagnostic event reported by the monitor, until one of the first end condition and the second end condition is met;

[0156] The first termination condition is that the duration of continuously receiving the first diagnostic event reported by the monitor reaches a preset time threshold, and the second termination condition is that before the duration of continuously receiving the first diagnostic event reported by the monitor reaches the preset time threshold, a second diagnostic event reported by the monitor is received; or,

[0157] The first termination condition is that the number of times the first diagnostic event reported by the monitor is continuously received reaches a preset number threshold, and the second termination condition is that before the number of times the first diagnostic event reported by the monitor is continuously received reaches the preset number threshold, a second diagnostic event reported by the monitor is received;

[0158] Among them, the second diagnostic event is used to describe that the target monitored object has not been diagnosed with a fault. When the first end condition is met, the first diagnostic event is determined to be a fault event. When the second end condition is met, the first diagnostic event is determined not to be a fault event.

[0159] In an exemplary embodiment, the apparatus further comprises:

[0160] A first execution unit is used to encapsulate event data associated with the first diagnostic event after reporting the first diagnostic event to a main core in the multi-core processor through a target operating system partition, and store the encapsulated target event data in a first storage area, wherein the event data of the first diagnostic event is used to describe the first diagnostic event, and the target event data stored in the first storage area is allowed to be used by multiple cores in the multi-core processor, the multiple cores including a target satellite core and a main core;

[0161] a second execution unit, configured to, when a target core among the multiple cores is to update a value of target event data, obtain, through the target core, the value of the target event data stored in the first storage area, back up the obtained first value of the target event data, and update the obtained first value of the target event data to a second value;

[0162] An acquisition unit, configured to reacquire the value of the target event data stored in the first storage area through the target core to obtain the current value of the target event data;

[0163] The updating unit is configured to update the value of the target event data stored in the first storage area to a second value when the current value of the target event data is the first value.

[0164] In an exemplary embodiment, a first-in first-out queue is respectively configured on each operating system partition of the vehicle system of the current vehicle, and a spin lock is configured on each first-in first-out queue on the operating system partition;

[0165] Reporting unit, including:

[0166] A first execution module is used to perform an enqueue operation through a target operating system partition to write event indication information of the first diagnostic event into a first-in-first-out queue on the target operating system partition when the first diagnostic event is determined to be a fault event, wherein during the enqueue operation, a spin lock of the first-in-first-out queue on the target operating system partition is in a locked state, and the event indication information is used to indicate that the first diagnostic event is a fault event;

[0167] The second execution module is used to perform a dequeue operation through the main core when the spin lock of the first-in-first-out queue on the target operating system partition is in an unlocked state, so as to read event indication information from the first-in-first-out queue on the target operating system partition, wherein during the execution of the dequeue operation, the spin lock of the first-in-first-out queue on the target operating system partition is in a locked state.

[0168] In an exemplary embodiment, the apparatus further comprises:

[0169] A storage unit is used to store event snapshot data of the first diagnostic event in a second storage area on the main core through the main core after the first diagnostic event is reported to the main core in the multi-core processor through the target operating system partition, if the first diagnostic event reported by the target operating system partition is received within multiple specified cycles.

[0170] In an exemplary embodiment, the apparatus further comprises:

[0171] The suppression unit is used to debounce the first diagnostic event until it is determined whether the first diagnostic event is a fault event. If the first diagnostic event is determined to be a fault event, the use of the target monitored object is suppressed through the target operating system partition.

[0172] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0173] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0174] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0175] An embodiment of the present invention further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0176] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0177] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0178] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0179] An embodiment of the present invention further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0180] An embodiment of the present invention also provides a computer program, which includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in any one of the above-mentioned method embodiments.

[0181] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.

[0182] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for processing a diagnostic event, characterized in that: include: In the case where a monitor on a target operating system partition detects a first diagnostic event, debounce the first diagnostic event until determining whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of a current vehicle, the first diagnostic event is used to describe that a fault is diagnosed for the target monitored object, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle; When it is determined that the first diagnostic event is a fault event, the first diagnostic event is reported to a main core in the multi-core processor through the target operating system partition.

2. The method according to claim 1, characterized in that The de-jittering process is performed on the first diagnostic event until it is determined whether the first diagnostic event is a fault event, including: Debounce the first diagnostic event reported by the monitor through the target operating system partition until it is determined whether the first diagnostic event is a fault event; or, The monitor performs de-jitter processing on the first diagnostic event monitored by the monitor until it is determined whether the first diagnostic event is a fault event.

3. The method according to claim 2, characterized in that The de-jittering process is performed on the first diagnostic event reported by the monitor by the target operating system partition until it is determined whether the first diagnostic event is a fault event, including: Starting from the first receipt of the first diagnostic event reported by the monitor, debounce processing is performed on the first diagnostic event reported by the monitor by the target operating system partition until one of a first end condition and a second end condition is met; The first termination condition is that the duration of continuously receiving the first diagnostic event reported by the monitor reaches a preset time threshold, and the second termination condition is that before the duration of continuously receiving the first diagnostic event reported by the monitor reaches the preset time threshold, a second diagnostic event reported by the monitor is received; or The first termination condition is that the number of times the first diagnostic event reported by the monitor is continuously received reaches a preset number threshold, and the second termination condition is that before the number of times the first diagnostic event reported by the monitor is continuously received reaches the preset number threshold, a second diagnostic event reported by the monitor is received; Among them, the second diagnostic event is used to describe that the target monitored object has not been diagnosed with a fault. When the first end condition is met, the first diagnostic event is determined to be a fault event. When the second end condition is met, the first diagnostic event is determined not to be a fault event.

4. The method according to claim 1, characterized in that: After reporting the first diagnostic event to the main core in the multi-core processor through the target operating system partition, the method further includes: Encapsulating the event data of the first diagnostic event, and storing the encapsulated target event data in a first storage area, wherein the event data of the first diagnostic event is used to describe the first diagnostic event, and the target event data stored in the first storage area is allowed to be used by multiple cores in the multi-core processor, and the multiple cores include the target satellite core and the main core; When a target core among the multiple cores is to update the value of the target event data, obtaining the value of the target event data stored in the first storage area through the target core, backing up the obtained first value of the target event data, and updating the obtained first value of the target event data to a second value; reacquiring, by the target core, the value of the target event data stored in the first storage area to obtain a current value of the target event data; When the current value of the target event data is the first value, the value of the target event data stored in the first storage area is updated to the second value.

5. The method according to claim 1, characterized in that A first-in-first-out queue is respectively configured on each operating system partition of the vehicle system of the current vehicle, and a spin lock is configured on each first-in-first-out queue on the operating system partition; When determining that the first diagnostic event is a fault event, reporting the first diagnostic event to a main core in the multi-core processor through the target operating system partition includes: In the case where it is determined that the first diagnostic event is a fault event, an enqueue operation is performed through the target operating system partition to write event indication information of the first diagnostic event into a first-in-first-out queue on the target operating system partition, wherein during the process of performing the enqueue operation, a spin lock of the first-in-first-out queue on the target operating system partition is in a locked state, and the event indication information is used to indicate that the first diagnostic event is a fault event; When the spin lock of the first-in-first-out queue on the target operating system partition is in an unlocked state, a dequeue operation is performed by the main core to read the event indication information from the first-in-first-out queue on the target operating system partition, wherein during the execution of the dequeue operation, the spin lock of the first-in-first-out queue on the target operating system partition is in a locked state.

6. The method according to claim 1, characterized in that After reporting the first diagnostic event to the main core in the multi-core processor through the target operating system partition, the method further includes: In a case where the first diagnostic event reported by the target operating system partition is received within a plurality of specified periods, the event snapshot data of the first diagnostic event is stored in a second storage area on the main core through the main core.

7. The method according to any one of claims 1 to 6, characterized in that After performing debounce processing on the first diagnostic event until determining whether the first diagnostic event is a fault event, the method further includes: In the case where it is determined that the first diagnostic event is a fault event, use of the target monitored object is suppressed through the target operating system partition.

8. A diagnostic event processing device, characterized in that: include: a debounce unit, configured to, when a monitor on a target operating system partition detects a first diagnostic event, debounce the first diagnostic event until determining whether the first diagnostic event is a fault event, wherein the target operating system partition is an operating system partition corresponding to a target monitored object of a vehicle system of a current vehicle, the first diagnostic event is used to describe that a fault is diagnosed for the target monitored object, and the target operating system partition runs on a target satellite core in a multi-core processor of the current vehicle; A reporting unit is used to report the first diagnostic event to a main core in the multi-core processor through the target operating system partition when the first diagnostic event is determined to be a fault event.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 7 when executed by a processor.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method described in any one of claims 1 to 7 are implemented.

Images