CN117312027A - Fault processing method, device, electronic equipment and medium - Google Patents

Fault processing method, device, electronic equipment and medium Download PDF

Info

Publication number
CN117312027A
CN117312027A CN202311104291.4A CN202311104291A CN117312027A CN 117312027 A CN117312027 A CN 117312027A CN 202311104291 A CN202311104291 A CN 202311104291A CN 117312027 A CN117312027 A CN 117312027A
Authority
CN
China
Prior art keywords
fault
target
application
layer
analysis result
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311104291.4A
Other languages
Chinese (zh)
Inventor
秦民
韩露
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Automotive Innovation Corp
Original Assignee
China Automotive Innovation Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Automotive Innovation Corp filed Critical China Automotive Innovation Corp
Priority to CN202311104291.4A priority Critical patent/CN117312027A/en
Publication of CN117312027A publication Critical patent/CN117312027A/en
Pending legal-status Critical Current

Links

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application relates to a fault processing method, a fault processing device, electronic equipment and a medium. The method may include: registering a target application in an application layer, and monitoring the registered target application to obtain monitoring data of the target application; performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result; determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing a fault severity level; under the condition that the target fault type is an application level fault type, carrying out fault processing on the target application; and under the condition that the target fault type is the system-level fault type, sending a target fault analysis result of the target application to a decision processing layer, and carrying out fault processing on the target application by the decision processing layer. According to the technical scheme provided by the application, the fault processing efficiency can be improved, the fault processing pressure of the decision processing layer is reduced, the fault processing time is shortened, and the fault processing is more flexible.

Description

Fault processing method, device, electronic equipment and medium
Technical Field
The application relates to the technical field of functional safety processing of automobile systems, in particular to a fault processing method, a fault processing device, electronic equipment and a medium.
Background
With the continuous development of computer function safety processing technology, automobile intellectualization, networking and the like have become main development directions in the current and future automobile fields. Meanwhile, the safety and reliability of automobile systems are important factors of concern. In the related art, when a functional fault is prevented and monitored, and when the fault occurs, the fault cannot be rapidly and effectively processed, and when a system-level fault and an application-level fault occur at the same time, the fault cannot be flexibly processed, so that the fault processing efficiency is low.
Disclosure of Invention
The application provides a fault processing method, a device, electronic equipment and a medium, which at least solve the problem of how to improve the fault processing efficiency and enable the fault processing to be more flexible in the related technology. The technical scheme of the application is as follows:
according to a first aspect of embodiments of the present application, a fault handling method is provided, which is applied to a security monitoring layer in a three-layer security software architecture, where the three-layer security software architecture further includes an application layer and a decision processing layer; the fault processing method comprises the following steps:
monitoring the target application to obtain monitoring data of the target application; the target application is an application registered with the security monitoring layer in the application layer; performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result;
determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing a fault severity level;
under the condition that the target fault type is an application level fault type, carrying out fault processing on the target application;
under the condition that the target fault type is a system-level fault type, sending a target fault analysis result of the target application to a decision processing layer, and performing fault processing on the target application by the decision processing layer; the failure severity level of the system level failure is higher than the failure severity level of the application level failure.
According to a second aspect of embodiments of the present application, there is provided a fault handling system, the fault handling system including a three-layer security software architecture, the three-layer security software architecture including a security monitoring layer, an application layer, and a decision processing layer, including:
an application layer for managing applications in the terminal;
the security monitoring layer is used for registering the target application in the application layer and monitoring the registered target application to obtain monitoring data of the target application; performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result; determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing the fault severity level; under the condition that the target fault type is an application level fault type, carrying out fault processing on the target application; or, under the condition that the target fault type is a system level fault type, sending a target fault analysis result of the target application to a decision processing layer; the failure severity level of the system level failure is higher than that of the application level failure; the target application is an application which is registered with the security monitoring layer in the application layer;
and the decision processing layer is used for receiving the target fault analysis result sent by the safety monitoring layer and performing fault processing.
According to a third aspect of embodiments of the present application, there is provided an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement the method as in any of the first aspects above.
According to a fourth aspect of embodiments of the present application, there is provided a computer readable storage medium, which when executed by a processor of an electronic device, causes the electronic device to perform the method of any of the first aspects of embodiments of the present application.
According to a fifth aspect of embodiments of the present application, there is provided a computer program product comprising computer instructions which, when executed by a processor, cause the computer to perform the method of any of the first aspects of embodiments of the present application.
The technical scheme provided by the embodiment of the application at least brings the following beneficial effects:
registering a target application in an application layer, registering the registered target application, and monitoring the registered target application to obtain monitoring data of the target application; performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result; determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing the fault severity level; the safety monitoring layer can analyze fault conditions from the monitoring data to obtain a target fault analysis result, and then determine a target fault according to the target fault analysis result, so that a corresponding fault processing mode is adopted, the influence of the fault on a system and a target application is reduced, and the reliability and the stability of the system are improved.
Performing fault processing on the target application under the condition that the target fault type is an application-level fault type; under the condition that the target fault type is a system-level fault type, sending a target fault analysis result of the target application to a decision processing layer, and performing fault processing on the target application by the decision processing layer; the fault severity level of the system level fault is higher than that of the application level fault, so that the safety monitoring layer and the decision processing layer perform layered processing on the fault, the processing pressure of the decision processing layer is reduced, the processing effects of the application level fault and the system level fault are improved, the fault processing flexibility is higher, and the efficiency and the performance of the system are improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Other features and aspects of the present application will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application and do not constitute an undue limitation on the application.
FIG. 1 is a schematic diagram of an application environment, shown in accordance with an exemplary embodiment.
Fig. 2 is a schematic diagram illustrating a three-tier security software architecture, according to an example embodiment.
FIG. 3 is a flow chart illustrating a fault handling method according to an exemplary embodiment.
FIG. 4 is a flowchart illustrating a method of security monitoring layer fault handling according to an exemplary embodiment.
FIG. 5 is a flowchart illustrating an application level post-fault handling verification method according to an example embodiment.
Fig. 6 is a block diagram of an electronic device for fault handling, according to an example embodiment.
Fig. 7 is a block diagram two of an electronic device for fault handling, according to an example embodiment.
Detailed Description
In order to enable those skilled in the art to better understand the technical solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
It should be noted that the terms "first," "second," and the like in the description and claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.
Referring to fig. 1, fig. 1 is a schematic diagram illustrating an application environment according to an exemplary embodiment, and as shown in fig. 1, the application environment may include a server 01 and a terminal 02.
In an alternative embodiment, terminal 02 may be used for fault handling. Specifically, the terminal 02 may include, but is not limited to, a smart phone, a desktop computer, a tablet computer, a notebook computer, a smart speaker, a digital assistant, an augmented reality (augmented reality, AR)/Virtual Reality (VR) device, a smart wearable device, and other types of electronic devices. Alternatively, the operating system running on the electronic device may include, but is not limited to, an android system, an IOS system, linux, windows, and the like.
In an alternative embodiment, the server 01 may be used in connection with the terminal 02 for fault handling, e.g. providing preset configuration information etc. to the terminal 02. Specifically, the server 01 may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs (Content Delivery Network, content delivery networks), basic cloud computing services such as big data and artificial intelligence platforms, and the like.
In addition, it should be noted that fig. 1 is only one application environment of the fault handling method provided in the present application.
In the embodiment of the present disclosure, the server 01 and the terminal 02 may be directly or indirectly connected through a wired or wireless communication method, which is not limited herein.
It should be noted that, a possible sequence of steps is shown in the following figures, and is not limited to the strict order of the sequence. Some steps may be performed in parallel without mutual dependency. User information (including, but not limited to, user device information, user personal information, user behavior information, etc.) and data (including, but not limited to, data for presentation, training, etc.) referred to herein are both information and data that is authorized by the user or sufficiently authorized by the parties.
Fig. 2 is a schematic diagram illustrating a three-tier security software architecture, according to an example embodiment. As shown in fig. 2, the fault handling system may include a three-layer security software architecture that includes a security monitoring layer, an application layer, and a decision processing layer.
In one possible implementation, the application layer is used for applications (i.e., application programs) that may be used in managing the terminal, which may include, but are not limited to, adding newly added applications in the terminal, deleting uninstalled applications in the terminal, triggering registration of applications with the security monitoring layer, and so forth. Wherein, the application managed in the application layer may be represented using an identification of the application, and the identification of the application may include a name, an icon, and the like of the application.
The safety monitoring layer is used for monitoring the target application to obtain monitoring data of the target application; performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result; determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing the fault severity level; under the condition that the target fault type is an application level fault type, carrying out fault processing on the target application; or, under the condition that the target fault type is a system level fault type, sending a target fault analysis result of the target application to a decision processing layer; the failure severity level of the system level failure is higher than that of the application level failure;
the decision processing layer is used for receiving the target fault analysis result sent by the safety monitoring layer and performing fault processing.
In the embodiment of the present disclosure, a plurality of applications run in an application layer, and a security monitoring layer includes a monitoring service sub-layer and a security service sub-layer, where the monitoring service sub-layer in the security monitoring layer registers the plurality of applications in the application layer, monitors a target application to obtain monitoring data, and performs fault analysis on the target application based on the monitoring data to obtain a target fault analysis result. The monitoring service sub-layer reports the target fault analysis result to the safety service sub-layer, the safety service sub-layer acquires preset configuration information, the target fault type corresponding to the target fault analysis result is determined according to the preset configuration information, the target fault type is divided into an application-level fault type and a system-level fault type, and when the target fault type is determined to be the application-level fault type, the safety service sub-layer processes the fault of the target application. When the target fault type is determined to be the system-level fault type, the security service sub-layer sends a target fault analysis result of the target application to the decision processing layer, and the decision processing layer receives the target fault analysis result sent by the security service sub-layer and processes the fault.
It should be noted that, specific processing contents of the security monitoring layer, the application layer and the decision processing layer may be described below, and will not be described herein.
FIG. 3 is a flow chart illustrating a fault handling method that may be applied to a security monitoring layer in a three-layer security software architecture, according to an exemplary embodiment; the three-layer security software architecture also includes an application layer and a decision processing layer. In the embodiment of the present disclosure, the fault may be an error in an application program, for example, in an automobile driving application, the fault may refer to that a vehicle navigation is jammed, a reverse image is black, and the like, which is not limited in this application.
As shown in fig. 3, the fault handling method may include the following steps.
In step S301, the target application is monitored, and monitoring data of the target application is obtained.
The target application is an application registered with the security monitoring layer in the application layer. That is, the application layer may include at least one application, which may be referred to as a target application after one application registers with the security monitoring layer. In fault processing, the security monitoring layer monitors target applications, and does not monitor unregistered applications.
The monitoring data may refer to data obtained by monitoring the running process of the target application, for example, the running state of the target application or stored data in the running process of the target application.
In the embodiment of the present disclosure, for an application in an application layer, the application is registered to a security monitoring layer, where the security monitoring layer monitors data such as an operation state of the application after registration in the application layer, and obtains monitoring data of a target application.
In one possible implementation manner, as shown in fig. 2, fig. 2 is a three-layer security software architecture flow chart, where application 1 represents an application program running in an application layer, a monitoring service sub-layer in a security monitoring layer may provide multiple registration interfaces, application 1 may register in the monitoring service sub-layer through the registration interfaces, and after registration is completed, the monitoring service sub-layer monitors the target application 1, where monitoring may be timed monitoring or periodic monitoring, and the monitoring mode is not limited in this application. And after the target application is monitored, the monitoring service sub-layer obtains the monitoring data of the target application 1.
In another possible implementation, when the application 2 in fig. 2 also represents an application running in the application layer, but is not registered with the registration interface in the monitoring service sub-layer, the monitoring service sub-layer cannot monitor the application 2, and thus cannot derive the monitoring data.
In step S303, fault analysis is performed on the target application based on the monitoring data, and a target fault analysis result is obtained.
The target fault analysis result may refer to fault information obtained after fault analysis, for example, a target application appears a black screen, a target application appears a messy code, and the like.
In the embodiment of the specification, according to the monitoring data of the target application obtained by the security monitoring layer, performing fault analysis on the monitoring data of the target application, analyzing that a fault occurs in the target application, and obtaining a target fault analysis result in the target application.
In one example, as shown in fig. 2, a monitoring service sub-layer in the security monitoring layer in fig. 2 obtains the monitoring data of the target application 1 and the monitoring data, performs fault analysis on the monitoring data in the monitoring service sub-layer, and when the fault occurs in the target application 1 from the monitoring data of the target application 1, obtains a target fault analysis result of the target application 1. Based on the result, the target fault analysis result of the target application 1 is reported to a security service sub-layer in the security monitoring layer for target fault classification and processing.
In one possible implementation manner, reference data corresponding to the monitoring data is obtained, the monitoring data is compared with the reference data to obtain differences or abnormal conditions, and therefore the differences or abnormal conditions can be summarized to obtain a target fault analysis result. The reference data may be preset, and the comparison is not limited in this application. The monitoring data may include performance metrics, log records, error reports, resource usage, database query and response time, and the like.
The monitoring data may be visually compared with reference data, for example.
Optionally, when the analyzed data and the visual chart are normal, the target application is indicated to have no fault and can normally operate.
In step S305, determining a target fault type corresponding to the target fault analysis result; the target fault type is used to characterize the fault severity level.
The target fault type may be used to characterize a fault severity level, and the fault severity level may be used to indicate a difficulty level of target fault handling.
In the embodiment of the present disclosure, in the security monitoring layer, according to a target failure analysis result of a target application, a target failure type corresponding to the target failure analysis result is determined.
In one possible implementation manner, acquiring preset configuration information, wherein the preset configuration information comprises a corresponding relation between preset fault result information and preset fault types; and determining the target fault type corresponding to the target fault analysis result based on the corresponding relation.
In this embodiment of the present disclosure, the preset configuration information may refer to preset configuration information, where the configuration of the preset configuration information is set according to actual needs, which is not limited in this application. The preset fault result information may refer to preset fault information for describing possible fault information. The preset fault type may refer to a preset fault type, and is used for describing a possible fault type, for example, may include an application level fault, a system level fault, and the like.
In practical application, preset configuration information is obtained, the preset configuration information comprises preset fault result information, preset fault types and corresponding relations thereof, the target fault analysis result is matched with the preset fault result information in the corresponding relations, the preset fault result information matched with the target fault analysis result is obtained, and the preset fault type corresponding to the matched preset fault result information is determined as the target fault type.
In step S307, in the case where the target failure type is the application-level failure type, the failure processing is performed on the target application.
The application level fault may be a fault affecting normal operation of the target application, or may be a fault caused by an error, abnormality, or deficiency in the target application. Such as code failure or performance failure, etc.
In the embodiment of the present disclosure, when the target fault type is determined as an application-level fault, the fault processing is performed on the target application having the application-level fault according to the fault processing manner of the target application, so that the target application can recover from a normal running state.
In one possible implementation, a plurality of fault handling modes configured under an application level fault type are acquired; screening out a target fault processing mode matched with the target fault analysis result from the multiple fault processing modes; and performing fault processing on the target application by using a target fault processing mode.
In the embodiment of the present description, the fault handling manner may refer to a manner for handling an application level fault. The target fault handling means may refer to means for performing fault handling on the matched target fault analysis result. Illustratively, the multiple failure handling approaches configured under the application level failure type may be carried in a tabular manner, such as shown in table 1.
TABLE 1
In one example, taking table 1 as an example, if the target failure analysis result of the target application is application level failure 1, the matching target failure processing mode is mode 1.
In one possible implementation manner, under the condition that the target fault type is an application level fault type, acquiring the current accumulated fault times of the target application on which the application level fault occurs; and restarting the target application to perform fault processing if the current accumulated fault times are smaller than or equal to a preset fault times threshold value.
In this embodiment of the present disclosure, the current accumulated number of failures may refer to an accumulated number of failures of the target application at an application level, and the preset failure number threshold may refer to a preset failure number threshold.
In practical application, under the condition that the target fault type is determined to be the application level fault type, the current accumulated fault times of the application level faults of the target application are obtained, and if the current accumulated fault times of the target application are smaller than or equal to a preset fault times threshold value, the target application is restarted to represent fault processing.
In another possible implementation manner, if the current accumulated number of faults is less than or equal to the preset number of faults threshold, restarting the target application, and if the restarting fault processing manner cannot solve the application-level fault, performing the same step as S307 on the target application-level fault processing; when the current accumulated failure number of the target application is greater than the preset failure number threshold, the same step as S307 is also performed on the failure processing of the application level of the target application.
In step S309, in the case where the target failure type is the system-level failure type, the target failure analysis result of the target application is sent to the decision processing layer, and the decision processing layer performs failure processing on the target application; the failure severity level of the system level failure is higher than the failure severity level of the application level failure.
The system-level fault type may refer to a fault type in which a fault occurring in the target application is associated with a system. The decision processing layer may refer to an independent part in the three-layer security software architecture, and is configured to receive the system-level fault sent by the security monitoring layer, and process the hardware fault reported by the system-level fault and the external interrupt.
In the embodiment of the specification, according to the corresponding relation in the preset configuration file, determining that the target fault type is a system level fault type, and sending a target fault analysis result of the target application to a decision layer when the target fault type is the system level fault type, and performing fault processing on the target application with the system level fault by the decision processing layer.
In one possible implementation manner, as shown in fig. 2, the decision processing layer receives a target fault analysis result sent by a security service sub-layer in the security monitoring layer and having a system-level fault, and performs fault processing on the system-level fault of the target application; the decision processing layer also receives the hardware fault reported by the interrupt outside the three-layer security software architecture and processes the hardware fault.
In an alternative embodiment, after the step S307 is performed, the secondary application level fault process may also be verified. In particular, the method comprises the steps of,
in one possible implementation manner, restarting the target application, recording a restart event, and repeatedly performing steps of monitoring and fault analysis on the target application registered in the application layer to obtain a current fault analysis result; and operating the target application under the condition that the current fault analysis result is no fault.
In the embodiment of the present specification, the restart event may refer to an event of restarting the target application. The current failure analysis result may refer to an analysis result obtained by performing failure analysis on the current monitoring data. The fault-free condition may refer to a condition that the target fault analysis result has completed processing and the target application may operate normally.
In practical application, restarting the target application after fault processing, recording an event of restarting the target application after fault processing is completed, repeatedly monitoring the target application registered in the application layer, acquiring monitoring data, and performing fault analysis on the monitoring data to obtain a current fault analysis result of the target application. And under the condition that the current fault analysis result is no fault, the target application can be operated.
In another possible implementation manner, in the case that the current fault analysis result is consistent with the target fault analysis result, acquiring the record number of the restart event; and if the recorded times are smaller than the preset times threshold, returning to the step of restarting the target application.
In the embodiment of the present specification, the recording number may refer to recording the number of times of restarting the current target application. The preset number of times threshold may refer to a preset number of times threshold, the number of which is greater than 1.
In practical application, the current fault analysis result is faulty, the recorded times of restarting the target application after the fault processing is completed are obtained under the condition that the current fault analysis result is the same as the target fault analysis result of the fault processing, and when the recorded times are smaller than a preset time threshold, the step of restarting the target application can be returned, and the target application with the current fault analysis result is restarted again.
In another possible implementation manner, if the number of times of recording reaches a preset number of times threshold, the current fault analysis result is ignored, and the target application is operated.
In practical application, the current fault analysis result is faulty, when the recording frequency reaches the preset frequency threshold under the condition that the current fault analysis result is the same as the target fault analysis result, the current fault analysis result is ignored, the target application can be restarted, and the target application can be operated.
In one possible implementation manner, determining a fault type corresponding to the current fault analysis result under the condition that the current fault analysis result is inconsistent with the target fault analysis result; and performing fault processing on the target application based on the fault type corresponding to the current fault analysis result.
In practical application, if the current fault analysis result is faulty and the current fault analysis result is different from the target fault analysis result, the processing steps of no fault and consistent fault result are not performed any more, the determination of the fault type corresponding to the current fault analysis result can be performed, and if the fault type corresponding to the current fault analysis result is determined to be an application level fault, the fault processing can be continued according to the step of S307; if it is determined that the fault type corresponding to the current fault analysis result is a system level fault, fault processing may be continued according to the step of S309.
Optionally, in the step of verifying the fault handling, in order to improve the reading convenience of the verification manner of the fault handling, the verification situation after the completion of the application level fault handling can be more conveniently and clearly known from table 2.
TABLE 2
In one example, when the preset number of times threshold is 3, the value of the preset number of times threshold is not limited. As shown in fig. 5, the target application is restarted, a restart event is recorded, data monitoring is performed on the current target application, fault analysis is performed on the monitored data to obtain a current fault analysis result, and the restart event is recorded once under the condition that the current fault analysis result is fault-free, so that the target application can be operated. Under the condition that the current fault analysis result is faulty, and the current fault analysis result is consistent with the target fault analysis result, obtaining the restarting record frequency of the target application, wherein the frequency is 1, the current target application record frequency is 1 less than the preset frequency threshold value for 3 times, restarting the target application again, the current fault analysis result is found to be consistent with the target fault analysis result, the obtaining record frequency is 2 times, the current target application record frequency is 2 times less than the preset frequency threshold value for 3 times, restarting the target application again, after restarting, the current fault analysis result is still consistent with the target fault analysis result, the obtaining the restarting record frequency of the target application is 3 times, the current target application record frequency reaches the preset frequency threshold value for 3 times, ignoring the current fault analysis result, and running the target application; restarting the target application, recording a restart event, performing data monitoring on the current target application, performing fault analysis on the monitored data to obtain a current fault analysis result, and under the condition that the current fault analysis result is faulty, determining a target fault type corresponding to the current fault analysis result, if the current fault analysis result is different from the target fault analysis result, executing the fault processing step of S307 if the target fault type is an application level fault, and executing the fault processing step of S309 if the target fault type is a system level fault.
Fig. 6 is a block diagram illustrating an electronic device for fault handling, which may be a terminal, according to an exemplary embodiment, and an internal structure diagram thereof may be as shown in fig. 6. The electronic device includes a processor, a memory, a network interface, a display screen, and an input device connected by a system bus. Wherein the processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic device includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the electronic device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of fault handling. The display screen of the electronic equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the electronic equipment can be a touch layer covered on the display screen, can also be keys, a track ball or a touch pad arranged on the shell of the electronic equipment, and can also be an external keyboard, a touch pad or a mouse and the like.
It will be appreciated by those skilled in the art that the structure shown in fig. 6 is merely a block diagram of a portion of the structure associated with the present application and is not limiting of the electronic device to which the present application is applied, and that a particular electronic device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.
Fig. 7 is a block diagram illustrating an electronic device for fault handling, which may be a server, and an internal structure diagram thereof may be as shown in fig. 7, according to an exemplary embodiment. The electronic device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic device includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the electronic device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of fault handling.
It will be appreciated by those skilled in the art that the structure shown in fig. 7 is merely a block diagram of a portion of the structure associated with the present application and is not limiting of the electronic device to which the present application is applied, and that a particular electronic device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.
In an exemplary embodiment, there is also provided an electronic device including: a processor; a memory for storing the processor-executable instructions; wherein the processor is configured to execute the instructions to implement the fault handling method as in the embodiments of the present application.
In an exemplary embodiment, a computer readable storage medium is also provided, which when executed by a processor of an electronic device, enables the electronic device to perform the fault handling method in the embodiments of the present application. The computer readable storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.
In an exemplary embodiment, a computer program product containing instructions is also provided which, when run on a computer, cause the computer to perform the method of fault handling in the embodiments of the present application.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the various embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims (10)

1. The fault processing method is characterized by being applied to a safety monitoring layer in a three-layer safety software architecture; the three-layer security software architecture further comprises an application layer and a decision processing layer; the method comprises the following steps:
monitoring a target application to obtain monitoring data of the target application; the target application is an application which is registered with the security monitoring layer in the application layer;
performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result;
determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing a fault severity level;
performing fault processing on the target application under the condition that the target fault type is an application-level fault type;
under the condition that the target fault type is a system-level fault type, sending a target fault analysis result of the target application to the decision processing layer, and performing fault processing on the target application by the decision processing layer; the failure severity level of the system level failure is higher than the failure severity level of the application level failure.
2. The method of claim 1, wherein the determining the target fault type corresponding to the target fault analysis result comprises:
acquiring preset configuration information, wherein the preset configuration information comprises a corresponding relation between preset fault result information and preset fault types;
and determining the target fault type corresponding to the target fault analysis result based on the corresponding relation.
3. The method of claim 1, wherein, in the case where the target fault type is an application-level fault type, performing fault processing on the target application includes:
acquiring a plurality of fault processing modes configured under the application level fault type;
screening out a target fault processing mode matched with the target fault analysis result from the multiple fault processing modes;
and performing fault processing on the target application by using the target fault processing mode.
4. A method according to claim 1 or 3, wherein, in case the target fault type is an application level fault type, after the fault handling step on the target application, the method further comprises:
restarting the target application, recording a restarting event, and repeatedly executing the steps of monitoring the target application registered in the application layer and analyzing faults to obtain a current fault analysis result;
and operating the target application under the condition that the current fault analysis result is no fault.
5. The method according to claim 4, wherein the method further comprises:
under the condition that the current fault analysis result is consistent with the target fault analysis result, acquiring the record times of the restarting event;
if the recorded times are smaller than a preset times threshold, returning to the step of restarting the target application;
and if the recorded times reach the preset times threshold, ignoring the current fault analysis result and running the target application.
6. The method of claim 5, further comprising:
under the condition that the current fault analysis result is inconsistent with the target fault analysis result, determining a fault type corresponding to the current fault analysis result;
and performing fault processing on the target application based on the fault type corresponding to the current fault analysis result.
7. The method of claim 1, wherein, in the case where the target fault type is an application-level fault type, performing fault processing on the target application includes:
under the condition that the target fault type is an application level fault type, acquiring the current accumulated fault times of the target application on which the application level fault occurs;
and restarting the target application to perform fault processing if the current accumulated fault times are smaller than or equal to a preset fault times threshold value.
8. The fault processing system is characterized by comprising a three-layer security software architecture, wherein the three-layer security software architecture comprises a security monitoring layer, an application layer and a decision processing layer; comprising the following steps:
the application layer is used for managing applications in the terminal;
the safety monitoring layer is used for monitoring the target application to obtain monitoring data of the target application; performing fault analysis on the target application based on the monitoring data to obtain a target fault analysis result; determining a target fault type corresponding to the target fault analysis result; the target fault type is used for representing a fault severity level; performing fault processing on the target application under the condition that the target fault type is an application-level fault type; or, if the target fault type is a system-level fault type, sending a target fault analysis result of the target application to the decision processing layer; the failure severity level of the system level failure is higher than the failure severity level of the application level failure; the target application is an application which is registered with the security monitoring layer in the application layer;
and the decision processing layer is used for receiving the target fault analysis result sent by the safety monitoring layer and performing fault processing.
9. An electronic device, comprising:
a processor;
a memory for storing the processor-executable instructions;
wherein the processor is configured to execute the instructions to implement the fault handling method of any one of claims 1 to 7.
10. A computer readable storage medium, characterized in that instructions in the computer readable storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the fault handling method of any one of claims 1 to 7.
CN202311104291.4A 2023-08-29 2023-08-29 Fault processing method, device, electronic equipment and medium Pending CN117312027A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311104291.4A CN117312027A (en) 2023-08-29 2023-08-29 Fault processing method, device, electronic equipment and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311104291.4A CN117312027A (en) 2023-08-29 2023-08-29 Fault processing method, device, electronic equipment and medium

Publications (1)

Publication Number Publication Date
CN117312027A true CN117312027A (en) 2023-12-29

Family

ID=89287413

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311104291.4A Pending CN117312027A (en) 2023-08-29 2023-08-29 Fault processing method, device, electronic equipment and medium

Country Status (1)

Country Link
CN (1) CN117312027A (en)

Similar Documents

Publication Publication Date Title
CN107329894B (en) Application program system testing method and device and electronic equipment
CN108667855B (en) Network flow abnormity monitoring method and device, electronic equipment and storage medium
CN113489713B (en) Network attack detection method, device, equipment and storage medium
US20220050765A1 (en) Method for processing logs in a computer system for events identified as abnormal and revealing solutions, electronic device, and cloud server
CN108038039B (en) Method for recording log and micro-service system
CN108256322B (en) Security testing method and device, computer equipment and storage medium
CN111475376A (en) Method and device for processing test data, computer equipment and storage medium
CN109542764B (en) Webpage automatic testing method and device, computer equipment and storage medium
CN109408361A (en) Monkey tests restored method, device, electronic equipment and computer readable storage medium
CN114116496A (en) Automatic testing method, device, equipment and medium
CN112817831A (en) Application performance monitoring method, device, computer system and readable storage medium
CN112306833A (en) Application program crash statistical method and device, computer equipment and storage medium
CN110659435A (en) Page data acquisition processing method and device, computer equipment and storage medium
CN114579446A (en) Data processing method and device, computer equipment and computer readable storage medium
CN108650123B (en) Fault information recording method, device, equipment and storage medium
CN114528201A (en) Abnormal code positioning method, device, equipment and medium
CN111371581A (en) Method, device, equipment and medium for detecting business abnormity of Internet of things card
CN113110965A (en) Abnormal information monitoring method and device, computer storage medium and terminal
CN117312027A (en) Fault processing method, device, electronic equipment and medium
CN115878358A (en) Abnormal log analysis method and device, electronic equipment and storage medium
CN105988917B (en) Abnormal information acquisition method and device
CN116414594A (en) Fault tree updating method, device, computer equipment and storage medium
CN116107781A (en) Log tracking method, device, electronic equipment and computer program product
CN112463783A (en) Index data monitoring method and device, computer equipment and storage medium
CN111475400A (en) Verification method of service platform and related equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination