CN112905375A - Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment - Google Patents
Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment Download PDFInfo
- Publication number
- CN112905375A CN112905375A CN202110175332.3A CN202110175332A CN112905375A CN 112905375 A CN112905375 A CN 112905375A CN 202110175332 A CN202110175332 A CN 202110175332A CN 112905375 A CN112905375 A CN 112905375A
- Authority
- CN
- China
- Prior art keywords
- application program
- state information
- service application
- target
- fault
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error 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/0706—Error 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error 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/0793—Remedial or corrective actions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application relates to a self-recovery method and device of a double-core intelligent ammeter management unit and computer equipment. Determining whether each business application program has an operation fault or not according to the read operation state information by reading the operation state information of each business application program stored in the shared pipeline file; under the condition that a target service application program in each service application program has an operation fault, determining a fault removal strategy according to the read operation state information of the target service application program, and repairing the target service application program according to the fault removal strategy; according to the method and the device, the running state of each service application program is monitored, when the service application program breaks down, the service application program is subjected to fault repair instead of restarting the whole management unit to realize self-repairing of the fault, the self-recovery time of the electric meter management core system is greatly shortened, and loss or chaos of electric meter service data is avoided.
Description
Technical Field
The application relates to the technical field of software fault recovery, in particular to a self-recovery method and device of a double-core intelligent ammeter management unit, computer equipment and a storage medium.
Background
With the development of smart meters, a dual-core smart meter which separates legal metering function and management function from each other appears, including a metering core for legal metering function and a management core for software management function; the management unit of the intelligent electric meter corresponding to the management core can be loaded with a software operating system, and a plurality of different service application programs can be operated on the software operating system to realize functions of electric meter display, communication, online upgrade of a plurality of applications and the like.
In the conventional technology, a hardware watchdog mode is generally adopted, and when software of a management unit fails, the whole management unit is restarted to realize self-recovery of a software operating system.
However, the above-mentioned restart operation will cause the software operating system and the hardware peripheral to be initialized again, and each service application to be reloaded, resulting in slow self-recovery time of the system, and further causing loss or confusion of the electric meter service data.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a self-recovery method and apparatus for a two-core smart electricity meter management unit, a computer device, and a storage medium, which can reduce the self-recovery time of the system.
In a first aspect, a self-recovery method for a two-core intelligent electric meter management unit is provided, and the method includes:
reading the running state information of each service application program stored in a shared pipeline file, wherein the shared pipeline file is used for writing the running state information of each service application program into the shared pipeline file by each service application program installed in a power supply table;
determining whether each business application program has an operation fault according to the read operation state information;
under the condition that a target business application program in all business application programs has an operation fault, determining a fault removal strategy according to the read operation state information of the target business application program;
and repairing the target business application program according to the troubleshooting strategy.
In one embodiment, before the operation state information of each business application stored in the shared pipeline file is read, the method further includes:
after the electric meter is powered on, controlling the starting of each service application program; reading the starting state information of each service application program at a preset storage position, wherein the storage position is used for each service application program to write the starting state information of each service application program into the storage position; determining whether business application programs which are not started successfully exist in all the business application programs according to the read starting state information; and controlling the unsuccessfully started business application program to restart in the case that the unsuccessfully started business application program exists.
In one embodiment, determining whether an operation failure occurs in each service application according to the read operation state information includes:
determining whether the read running state information has fault state information, wherein the fault state information is used for representing that a service application program has faults in the running process; and under the condition that the read running state information has the fault state information, taking the business application program corresponding to the fault state information as a target business application program with a fault.
In one embodiment, determining a troubleshooting policy according to the read running state information of the target service application includes:
under the condition that the fault state information corresponding to the target business application program comprises a restart identifier, taking the target business application program as the fault elimination strategy; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: and restarting the target business application program.
In one embodiment, determining a troubleshooting policy according to the read running state information of the target service application includes:
taking a repair file as the troubleshooting strategy under the condition that the fault state information corresponding to the target service application program comprises a file error identifier; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: and repairing the target file related to the operation of the target business application program.
In one embodiment, the method further comprises:
detecting whether the target file is successfully repaired; and under the condition that the target file is failed to be repaired, deleting the target file and restarting the target business application program.
In one embodiment, determining a troubleshooting policy according to the read running state information of the target service application includes:
when the fault state information corresponding to the target service application program comprises a hardware component error identifier, taking the initialized hardware component and the restarted target service application program as the fault removal strategy; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: initializing the hardware component called by the target business application program, and restarting the target business application program.
In a second aspect, a self-recovery device of a two-core intelligent electricity meter management unit is provided, the device comprising:
the first reading module is used for reading the running state information of each service application program stored in a shared pipeline file, wherein the shared pipeline file is used for writing the running state information of each service application program into the shared pipeline file by each service application program installed in the power supply table.
And the first determining module is used for determining whether the operation faults occur to each business application program according to the read operation state information.
And the second determining module is used for determining a fault removal strategy according to the read running state information of the target business application program under the condition that the target business application program in the business application programs has running faults.
And the repair module is used for repairing the target service application program according to the troubleshooting strategy.
In a fourth aspect, a computer device is provided, which includes a memory and a processor, where the memory stores a computer program, and the processor implements the self-recovery method of the two-core smart electricity meter management unit according to any one of the first aspect when executing the computer program.
In a fifth aspect, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the self-recovery method of the two-core intelligent electricity meter management unit according to any one of the first aspect.
According to the self-recovery method and device of the double-core intelligent ammeter management unit, the computer equipment and the storage medium, whether the operation fault occurs to each business application program is determined by reading the operation state information of each business application program stored in the shared pipeline file and according to the read operation state information; under the condition that a target service application program in each service application program has an operation fault, determining a fault removal strategy according to the read operation state information of the target service application program, and repairing the target service application program according to the fault removal strategy; that is to say, in the embodiment of the present application, whether each service application normally operates may be determined by monitoring the operation state of each service application, and when a service application fails, a corresponding troubleshooting policy may be determined according to the operation state information of the service application, and a target service application that fails is repaired according to the troubleshooting policy, instead of restarting the entire management unit to achieve self-repair of a software failure, so that, in the embodiment of the present application, operations of reinitializing an operating system and a peripheral device and reloading each service application are not required, which greatly shortens the self-recovery time of the electricity meter management core system, and avoids loss or confusion of electricity meter service data; in addition, in the process of programming the program of the electric meter management unit, the difficulty of programming the program can be reduced, the running time of each service application program does not need to be accurately calculated, the problem of calling a dog feeding function does not need to be considered all the time, the problem of restarting when a time-consuming service function is used does not need to be worried about, the service logic of each service application program only needs to be considered, and the software programming efficiency of the electric meter management unit is greatly improved.
Drawings
FIG. 1 is a diagram of an exemplary self-recovery method for a two-core smart meter management unit;
FIG. 2 is a schematic flow chart illustrating a self-recovery method of a two-core smart meter management unit in one embodiment;
FIG. 3 is a schematic flow chart illustrating a self-recovery method of a two-core smart electricity meter management unit according to another embodiment;
FIG. 4 is a schematic flow chart illustrating a self-recovery method of a two-core smart electricity meter management unit according to another embodiment;
FIG. 5 is a schematic flow chart illustrating a self-recovery method of a two-core smart electricity meter management unit according to another embodiment;
FIG. 6 is a schematic flow chart illustrating a self-recovery method of a two-core smart electricity meter management unit according to another embodiment;
FIG. 7 is a block diagram of a self-recovery apparatus of a two-core smart electricity meter management unit in one embodiment;
FIG. 8 is a diagram illustrating an internal structure of a computer device according to an embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
At present, when a software fault occurs in a management core of a dual-core smart electric meter, a hardware watchdog mode is mostly adopted, that is, the frequency of feeding the hardware watchdog is calculated in a service application program carried by a management unit corresponding to the management core, a dog feeding function is periodically called, and counting is emptied.
If a certain business application program does not call the dog feeding function in an expected time period, so that the counting of the watchdog timer reaches the maximum upper limit, the business application program is considered to have a fault and cannot be executed according to an expected flow; after this happens, at the hardware level of the smart meter, the hardware watchdog will restart the entire management unit of the meter, i.e. reinitialize the operating system and the peripherals, and reload the applications. By adopting the self-recovery mode, the writing requirement on the business application program is higher, and the accurate calculation needs to be carried out on the business application program so as to ensure that the dog feeding function is actively called in fixed time.
If a certain service application program spends too long time when calling other peripheral equipment, the unexpected problem of restarting by the watchdog can occur; after the business application program exits, if the watchdog is not closed, the problem that the dog bites the business application program may occur; in addition, by adopting the method, for various software failures, the system is restarted, various hardware peripherals are required to be initialized, and a service application program is required to be loaded, so that the intelligent ammeter management unit cannot rapidly realize self-recovery, the use of the intelligent ammeter is influenced, and the service data is lost or disordered.
According to the self-recovery method of the double-core intelligent ammeter management unit, a supervisory program is started outside a business application program of the intelligent ammeter management core, the supervisory program monitors the running state of each business application program, when a certain business application program is found to run abnormally, corresponding fault processing can be carried out according to the abnormal type, complex operations of restarting a system and reloading the business application program are avoided, and self-recovery time when software fails can be prolonged.
The self-recovery method of the double-core intelligent ammeter management unit can be applied to the application environment shown in figure 1. The computer device may be a two-core smart meter, and the internal structure diagram of the computer device may be as shown in fig. 1. The computer device includes a processor, a memory, a communication interface, and a display screen connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program including a hypervisor. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless communication can be realized through WIFI, an operator network, NFC (near field communication) or other technologies. The computer program is executed by a processor to realize a self-recovery method of the double-core intelligent ammeter management unit. The display of the computer device may be a liquid crystal display or an electronic ink display.
In one embodiment, as shown in fig. 2, there is provided a self-recovery method for a two-core intelligent electricity meter management unit, which is described by taking a supervisory program applied to a computer device in fig. 1 as an example, and includes the following steps:
In the process of realizing the self-recovery of the software failure of the twin-core intelligent ammeter management unit, the embodiment of the application can add a supervisory program in addition to each service application program of the twin-core intelligent ammeter management unit, and the supervisory program can monitor the running state of each service application program and can also realize the self-recovery of the failure when the software failure occurs to the service application program; optionally, the mode of monitoring the operation state of each service application by the hypervisor may be that, between the hypervisor and each service application, a shared pipeline file is established, so that each service application can write the respective operation state information into the shared pipeline file, and the hypervisor can read the operation state information of each service application from the shared pipeline file, and by establishing the shared pipeline file, the monitoring of the operation state of each service application by the hypervisor can be achieved.
In an optional implementation manner of this embodiment, each service application may store an identifier of the shared pipeline file in advance, where the identifier may be a filename of the shared pipeline file or a pathname of the shared pipeline file; after each service application program is normally started to run, the running state information of the service application program can be written into the shared pipeline file at regular time according to the identifier of the shared pipeline file, and the running state information can be the running state information in normal running or the fault state information in fault; optionally, when the software failure occurs in the service application, the failure state information of the service application may also be written into the shared pipeline file at the time of the occurrence of the software failure; the supervisor can read the running state information of each business application stored in the shared pipeline file.
In an optional implementation manner of this embodiment, the supervisor may determine whether an operation failure occurs in each business application according to the read operation state information of each business application stored in the shared pipeline file; optionally, it may be determined whether the read running state information has fault state information, where the fault state information is used to represent that a fault occurs in the running process of the service application; and under the condition that the read running state information has the fault state information, determining that the service application program has a running fault, and taking the service application program corresponding to the fault state information as a target service application program with the fault.
And 203, under the condition that the target business application program in the business application programs has operation faults, determining a fault removal strategy according to the read operation state information of the target business application program.
In an optional implementation manner of this embodiment, for different software faults, the management unit of the smart meter may be allowed to execute self-recovery processes corresponding to the different software faults, instead of only recovering the various software faults by restarting the operation of the entire management unit; that is, for different operating status information, different troubleshooting strategies may be set, such as: for the business application program with the endless loop, the business application program can be repaired by restarting the operation of the business application program; optionally, the running state information may include an identifier of the service application program and a current running state identifier of the service application program, and the troubleshooting policy corresponding to the current running state identifier in the running state information of the target service application program may be determined according to a correspondence between a preset running state identifier and the troubleshooting policy.
And step 204, repairing the target service application program according to the troubleshooting strategy.
In the self-recovery method of the double-core intelligent ammeter management unit, whether the operation fault occurs to each business application program is determined by reading the operation state information of each business application program stored in the shared pipeline file and according to the read operation state information; under the condition that a target service application program in each service application program has an operation fault, determining a fault removal strategy according to the read operation state information of the target service application program, and repairing the target service application program according to the fault removal strategy; that is to say, in the embodiment of the present application, whether each service application normally operates may be determined by monitoring the operation state of each service application, and when a service application fails, a corresponding troubleshooting policy may be determined according to the operation state information of the service application, and a target service application that fails is repaired according to the troubleshooting policy, instead of restarting the entire management unit to achieve self-repair of a software failure, so that, in the embodiment of the present application, operations of reinitializing an operating system and a peripheral device and reloading each service application are not required, which greatly shortens the self-recovery time of the electricity meter management core system, and avoids loss or confusion of electricity meter service data; in addition, in the process of programming the program of the electric meter management unit, the difficulty of programming the program can be reduced, the running time of each service application program does not need to be accurately calculated, the problem of calling a dog feeding function does not need to be considered all the time, the problem of restarting when a time-consuming service function is used does not need to be worried about, the service logic of each service application program only needs to be considered, and the software programming efficiency of the electric meter management unit is greatly improved.
Fig. 3 is a schematic flow chart illustrating a self-recovery method of the two-core smart electricity meter management unit in another embodiment. The embodiment relates to an optional implementation process for ensuring that all service applications are normally started to operate after an electric meter is powered on. On the basis of the above embodiment, as shown in fig. 3, the method further includes:
In an optional implementation manner of this embodiment, after the electric meter is powered on, operations of starting an operating system of the electric meter management core, initializing a hardware peripheral, and controlling starting of each service application program may be performed, and in addition, operations of creating the shared pipeline file and starting the hypervisor may also be performed.
In an optional implementation manner of this embodiment, after each business application program is successfully started, each business application program may further write start state information of each business application program into a preset storage location, so that the supervisor program can read the start state information of each business application program from the storage location; optionally, the start state information may include an identifier of the service application and a start state of the service application, where the identifier of the service application may be a name of the service application or an ID of the service application; for unsuccessfully started service applications, the startup state information of the unsuccessfully started service application will not be included in the storage location.
In an optional implementation manner of this embodiment, the supervisor may read the start state information of each service application from the storage location, may determine an identifier of each successfully started service application according to the start state information of each service application, and may determine an identifier of a service application that is not successfully started according to the identifier of each successfully started service application and identifiers of all service applications that are stored in the supervisor in advance; since the storage location does not contain the startup status information of the unsuccessfully started service application, that is, the storage location does not contain the identification of the unsuccessfully started service application, it can be determined whether the unsuccessfully started service application exists in the successfully started service applications by comparing the identification of each successfully started service application with the identifications of all service applications.
And step 304, controlling the unsuccessfully started service application program to restart under the condition that the unsuccessfully started service application program exists.
After step 303, in the case that there is an unsuccessfully started service application, the unsuccessfully started service application can be controlled to be restarted according to the identification of the unsuccessfully started service application.
In the embodiment, after the electric meter is powered on, the start of each service application program is controlled, the start state information of each service application program is read in a preset storage position, and whether the service application program which is not started successfully exists in each service application program is determined according to the read start state information; under the condition that the unsuccessfully started service application program exists, controlling the unsuccessfully started service application program to be restarted; the method and the device can ensure that all service application programs can be started and operated normally in the initial starting process after the electric meter is powered on, and can improve the accuracy of the monitoring program in monitoring the operating state of each service application program.
Fig. 4 is a schematic flow chart illustrating a self-recovery method of the two-core smart electricity meter management unit in another embodiment. The present embodiment relates to an optional implementation process for determining a troubleshooting policy according to the read running state information of the target service application. On the basis of the above embodiment, as shown in fig. 4, the step 203 includes:
In an optional implementation manner of this embodiment, in a case that a current operating state identifier in the fault state information corresponding to the target service application program is a restart identifier, the target service application program may be restarted as the troubleshooting policy, and the restart identifier corresponding to the fault may be written into the shared pipeline file as the fault state information to instruct the hypervisor to restart the target service application program according to the restart identifier; optionally, when the target service application program has a fault such as a dead cycle, a running error of its own program, or the like, the target service application program may be restarted, and the restart identifier may be written into the shared pipeline file to instruct the monitoring program to restart the target service application program.
Correspondingly, the step 204 includes:
In this embodiment, when it is determined that the failure state information corresponding to the target service application includes the restart identifier, the target service application is restarted as the troubleshooting policy, and the target service application is restarted according to the troubleshooting policy; the method can restart the failed business application program without influencing the normal use of other business application programs, avoids the operation of restarting the whole electric meter management unit, greatly shortens the self-recovery time of the software fault of the electric meter management unit, and improves the self-recovery efficiency of the software fault of the electric meter management unit.
Fig. 5 is a flowchart illustrating a self-recovery method of the two-core smart electricity meter management unit in another embodiment. The embodiment relates to another alternative implementation process for determining the troubleshooting strategy according to the read running state information of the target business application program. On the basis of the above embodiment, as shown in fig. 5, the step 203 includes:
In an optional implementation manner of this embodiment, if the failure cause of the target service application is that the target service application fails due to an error of a file when the target service application calls or runs the file, for example: software failures caused by file data errors in Flash may include: when the file is failed to open or the size of the file is insufficient, file errors can be caused, and further the target business application program fails; in this case, even if the service application is restarted again or the management unit of the electricity meter is restarted, a software failure may be caused by the file error when the file is read; therefore, the repair file can be used as the troubleshooting policy, and the file error identifier corresponding to the fault can be written into the shared pipeline file as the fault state information to instruct the supervisor to repair the target service application program according to the file error identifier; optionally, for the failure caused by different file errors, different file repair processes may also be adopted, that is, different troubleshooting strategies may be corresponded, and different file errors may also be corresponded to different file error identifications; for example: when the file error is the failure of opening the file, creating a new file as a troubleshooting strategy for repairing the file; in the case where the file error is a file size shortage, the missing part of the file may be filled with 0 as a troubleshooting policy for repairing the file.
Correspondingly, the step 204 includes:
In an optional implementation manner of this embodiment, when detecting that the fault state information of the target service application includes a file error identifier, the hypervisor needs to repair a target file related to the operation of the target service application; optionally, a troubleshooting policy corresponding to the file error identifier may be determined according to the different file error identifiers, and the target file related to the operation of the target service application program may be repaired according to the troubleshooting policy.
In an optional implementation manner of this embodiment, after the hypervisor performs the repair operation on the target file, it may further detect whether the target file is successfully repaired, and in a case that the target file is unsuccessfully repaired, the target file may be deleted and the target service application program may be restarted, so as to solve a fault occurring in the target service application program and implement normal operation of the target service application program; based on the content of the above example, for the target file that fails to open the file, whether the target file is successfully repaired may be determined by detecting whether the created new file can be opened normally, and in the case that the created new file can be opened normally, it may be determined that the target file is successfully repaired; for the target file with the file size which is insufficient, whether the target file is successfully repaired can be determined by detecting whether the size of the repaired target file meets the requirement, and the target file can be successfully repaired under the condition that the size of the repaired target file meets the requirement.
In this embodiment, when it is determined that the failure state information corresponding to the target service application includes a file error identifier, a repair file is used as the troubleshooting policy, and a target file related to the operation of the target service application is repaired according to the troubleshooting policy; the method can repair the error file under the condition of file errors, solves the problem of faults caused by file errors even if the service application program is restarted due to the error file, greatly improves the fault self-recovery capability of the electricity meter management unit, and improves the comprehensive performance of the electricity meter management unit.
Fig. 6 is a flowchart illustrating a self-recovery method of the two-core smart electricity meter management unit in another embodiment. The embodiment relates to another alternative implementation process for determining the troubleshooting strategy according to the read running state information of the target business application program. On the basis of the above embodiment, as shown in fig. 6, the step 203 includes:
In an optional implementation manner of this embodiment, if the failure cause of the target service application is that the target service application fails due to an error of a hardware component when the target service application calls or runs the hardware component, for example: when a communication component is called to realize data interaction, the communication component cannot normally receive and transmit data, so that the target service application program cannot normally run and fails; in this case, initializing the hardware component and restarting the target service application may be used as the troubleshooting policy, and a hardware component error flag corresponding to the failure may be written into the shared pipeline file as the failure status information to instruct the hypervisor to repair the target service application according to the hardware component error flag; optionally, the fault status information may further include an identifier of the hardware component, where the identifier of the hardware component may be a name or an ID of the hardware component.
Correspondingly, the step 204 includes:
In an optional implementation manner of this embodiment, the hypervisor may initialize the hardware component called by the target service application according to the identifier of the hardware component in the fault state information, and restart the target service application.
In this embodiment, when it is determined that the fault state information corresponding to the target service application program includes a hardware component error identifier, initializing a hardware component and restarting the target service application program as the troubleshooting policy, initializing a hardware component called by the target service application program according to the troubleshooting policy, and restarting the target service application program; the method can only repair the wrong hardware component under the condition that the hardware component is wrong, does not affect the normal use of other hardware components, does not affect the normal use of other business application programs except the target business application program, greatly improves the efficiency and the speed of self-recovery of the software fault of the electricity meter management unit, and improves the comprehensive performance of the electricity meter management unit. In addition, according to the description of different fault conditions and the description of the fault removal strategies corresponding to the different fault conditions, it can be seen that the embodiment of the application can flexibly process different types of software faults, the monitoring program can accurately process different software faults according to the running state information of each business application program, and the situation that the faults caused by the same reason occur for multiple times can be avoided.
In an optional embodiment of the present application, when a service application normally exits, the service application may also write exit state information of the service application into the shared pipeline file, so as to indicate that the supervisor marks that the service application normally exits under the condition that the supervisor reads the exit state information of the service application, and may no longer monitor the service application; optionally, when the exited service application is restarted again, the service application may also write the startup state information of the service application into the shared pipeline file to instruct the supervisor to monitor the running state of the service application after reading the startup state information of the service application.
In this embodiment, the running state of the normally running service application program can be monitored, or the monitoring of the service application program can be suspended when the service application program normally exits, and the service application program can be monitored again when the business application program after exiting restarts; the intelligence and the reliability of this electricity meter management unit can be improved.
It should be understood that although the various steps in the flow charts of fig. 2-6 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2-6 may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed in turn or alternately with other steps or at least some of the other steps.
In one embodiment, as shown in fig. 7, there is provided a self-recovery apparatus of a two-core smart electricity meter management unit, including: a first reading module 701, a first determining module 702, a second determining module 703 and a repairing module 704, wherein:
a first reading module 701, configured to read operation state information of each service application stored in a shared pipeline file, where the shared pipeline file is used for each service application installed in a power supply table to write the operation state information of each service application into the shared pipeline file.
A first determining module 702, configured to determine whether an operation failure occurs in each service application according to the read operation state information.
The second determining module 703 is configured to determine a troubleshooting policy according to the read running state information of the target service application program when the target service application program in the service application programs has a running fault.
A repair module 704, configured to repair the target business application according to the troubleshooting policy.
In one embodiment, the apparatus further comprises: the device comprises a starting module, a second reading module, a third determining module and a restarting module; the starting module is used for controlling the starting of each service application program after the electric meter is powered on; the second reading module is used for reading the starting state information of each service application program at a preset storage position, wherein the storage position is used for each service application program to write the starting state information of each service application program into the storage position; a third determining module, configured to determine whether there is an unsuccessfully started service application program in each service application program according to the read start state information; the restarting module is used for controlling the unsuccessfully started service application program to restart under the condition that the unsuccessfully started service application program exists.
In one embodiment, the first determining module 702 is specifically configured to determine whether the read running state information has fault state information, where the fault state information is used to represent that a fault occurs in a running process of a service application; and under the condition that the read running state information has the fault state information, taking the business application program corresponding to the fault state information as a target business application program with a fault.
In one embodiment, the second determining module 703 is specifically configured to, when the fault state information corresponding to the target service application includes a restart identifier, use the restart target service application as the troubleshooting policy; correspondingly, the repair module 704 is specifically configured to restart the target service application.
In one embodiment, the second determining module 703 is specifically configured to, when the fault status information corresponding to the target service application includes a file error identifier, use a repair file as the troubleshooting policy; correspondingly, the repairing module 704 is specifically configured to repair the target file related to the operation of the target service application.
In one embodiment, the apparatus further comprises: a detection module; the detection module is used for detecting whether the target file is successfully repaired; and under the condition that the target file is failed to be repaired, deleting the target file and restarting the target business application program.
In one embodiment, the second determining module 703 is specifically configured to, when the fault status information corresponding to the target service application includes a hardware component error identifier, take initializing a hardware component and restarting the target service application as the troubleshooting policy; correspondingly, the repair module 704 is specifically configured to initialize a hardware component called by the target service application program, and restart the target service application program.
For specific limitations of the self-recovery device of the two-core intelligent electric meter management unit, reference may be made to the above limitations on the self-recovery method of the two-core intelligent electric meter management unit, and details are not repeated here. The modules in the self-recovery device of the dual-core intelligent ammeter management unit can be wholly or partially realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
In one embodiment, a computer device is provided, which may be a two-core smart meter, the internal structure of which may be as shown in fig. 8. The computer device includes a processor, a memory, a communication interface, and a display screen connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises 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 an operating system and computer programs in the non-volatile storage medium. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless communication can be realized through WIFI, an operator network, NFC (near field communication) or other technologies. The computer program is executed by a processor to realize a self-recovery method of the double-core intelligent ammeter management unit. The display of the computer device may be a liquid crystal display or an electronic ink display.
Those skilled in the art will appreciate that the architecture shown in fig. 8 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having a computer program stored therein, the processor implementing the following steps when executing the computer program:
reading the running state information of each service application program stored in a shared pipeline file, wherein the shared pipeline file is used for writing the running state information of each service application program into the shared pipeline file by each service application program installed in a power supply table;
determining whether each business application program has an operation fault according to the read operation state information;
under the condition that a target business application program in all business application programs has an operation fault, determining a fault removal strategy according to the read operation state information of the target business application program;
and repairing the target business application program according to the troubleshooting strategy.
In one embodiment, the processor, when executing the computer program, further performs the steps of: after the electric meter is powered on, controlling the starting of each service application program; reading the starting state information of each service application program at a preset storage position, wherein the storage position is used for each service application program to write the starting state information of each service application program into the storage position; determining whether business application programs which are not started successfully exist in all the business application programs according to the read starting state information; and controlling the unsuccessfully started business application program to restart in the case that the unsuccessfully started business application program exists.
In one embodiment, the processor, when executing the computer program, further performs the steps of: determining whether the read running state information has fault state information, wherein the fault state information is used for representing that a service application program has faults in the running process; and under the condition that the read running state information has the fault state information, taking the business application program corresponding to the fault state information as a target business application program with a fault.
In one embodiment, the processor, when executing the computer program, further performs the steps of: under the condition that the fault state information corresponding to the target business application program comprises a restart identifier, taking the target business application program as the fault elimination strategy; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: and restarting the target business application program.
In one embodiment, the processor, when executing the computer program, further performs the steps of: taking a repair file as the troubleshooting strategy under the condition that the fault state information corresponding to the target service application program comprises a file error identifier; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: and repairing the target file related to the operation of the target business application program.
In one embodiment, the processor, when executing the computer program, further performs the steps of: detecting whether the target file is successfully repaired; and under the condition that the target file is failed to be repaired, deleting the target file and restarting the target business application program.
In one embodiment, the processor, when executing the computer program, further performs the steps of: when the fault state information corresponding to the target service application program comprises a hardware component error identifier, taking the initialized hardware component and the restarted target service application program as the fault removal strategy; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: initializing the hardware component called by the target business application program, and restarting the target business application program.
In one embodiment, a computer-readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of:
reading the running state information of each service application program stored in a shared pipeline file, wherein the shared pipeline file is used for writing the running state information of each service application program into the shared pipeline file by each service application program installed in a power supply table;
determining whether each business application program has an operation fault according to the read operation state information;
under the condition that a target business application program in all business application programs has an operation fault, determining a fault removal strategy according to the read operation state information of the target business application program;
and repairing the target business application program according to the troubleshooting strategy.
In one embodiment, the computer program when executed by the processor further performs the steps of: after the electric meter is powered on, controlling the starting of each service application program; reading the starting state information of each service application program at a preset storage position, wherein the storage position is used for each service application program to write the starting state information of each service application program into the storage position; determining whether business application programs which are not started successfully exist in all the business application programs according to the read starting state information; and controlling the unsuccessfully started business application program to restart in the case that the unsuccessfully started business application program exists.
In one embodiment, the computer program when executed by the processor further performs the steps of: determining whether the read running state information has fault state information, wherein the fault state information is used for representing that a service application program has faults in the running process; and under the condition that the read running state information has the fault state information, taking the business application program corresponding to the fault state information as a target business application program with a fault.
In one embodiment, the computer program when executed by the processor further performs the steps of: under the condition that the fault state information corresponding to the target business application program comprises a restart identifier, taking the target business application program as the fault elimination strategy; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: and restarting the target business application program.
In one embodiment, the computer program when executed by the processor further performs the steps of: taking a repair file as the troubleshooting strategy under the condition that the fault state information corresponding to the target service application program comprises a file error identifier; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: and repairing the target file related to the operation of the target business application program.
In one embodiment, the computer program when executed by the processor further performs the steps of: detecting whether the target file is successfully repaired; and under the condition that the target file is failed to be repaired, deleting the target file and restarting the target business application program.
In one embodiment, the computer program when executed by the processor further performs the steps of: when the fault state information corresponding to the target service application program comprises a hardware component error identifier, taking the initialized hardware component and the restarted target service application program as the fault removal strategy; correspondingly, repairing the target business application program according to the troubleshooting policy comprises the following steps: initializing the hardware component called by the target business application program, and restarting the target business application program.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (10)
1. A self-recovery method of a twin-core intelligent electricity meter management unit is characterized by comprising the following steps:
reading running state information of each service application program stored in a shared pipeline file, wherein the shared pipeline file is used for writing the running state information of each service application program into the shared pipeline file by each service application program installed in a power supply list;
determining whether each service application program has an operation fault according to the read operation state information;
under the condition that a target business application program in each business application program has an operation fault, determining a fault removal strategy according to the read operation state information of the target business application program;
and repairing the target service application program according to the troubleshooting strategy.
2. The method of claim 1, wherein prior to reading the running state information of each business application stored in the shared pipe file, the method further comprises:
after the electric meter is powered on, controlling each service application program to be started;
reading the starting state information of each business application program at a preset storage position, wherein the storage position is used for each business application program to write the starting state information of each business application program into the storage position;
determining whether business application programs which are not started successfully exist in the business application programs according to the read starting state information;
and if the unsuccessfully started service application program exists, controlling the unsuccessfully started service application program to be restarted.
3. The method according to claim 1, wherein the determining whether each of the service applications has an operation failure according to the read operation state information includes:
determining whether the read running state information has fault state information, wherein the fault state information is used for representing that a service application program has faults in the running process;
and if the read running state information has the fault state information, taking a service application program corresponding to the fault state information as the target service application program with the fault.
4. The method according to claim 3, wherein the determining a troubleshooting policy according to the read running state information of the target service application program comprises:
if the fault state information corresponding to the target business application program comprises a restart identifier, taking the restart of the target business application program as the fault elimination strategy;
correspondingly, the repairing the target business application program according to the troubleshooting policy includes:
and restarting the target business application program.
5. The method according to claim 3, wherein the determining a troubleshooting policy according to the read running state information of the target service application program comprises:
if the fault state information corresponding to the target business application program comprises a file error identifier, taking a repair file as the fault removal strategy;
correspondingly, the repairing the target business application program according to the troubleshooting policy includes:
and repairing the target file related to the operation of the target service application program.
6. The method of claim 5, further comprising:
detecting whether the target file is successfully repaired;
and if the target file is failed to be repaired, deleting the target file and restarting the target service application program.
7. The method according to claim 3, wherein the determining a troubleshooting policy according to the read running state information of the target service application program comprises:
if the fault state information corresponding to the target business application program comprises a hardware component error identifier, initializing a hardware component and restarting the target business application program as the fault elimination strategy;
correspondingly, the repairing the target business application program according to the troubleshooting policy includes:
initializing the hardware component called by the target business application program, and restarting the target business application program.
8. A self-healing device of a two-core smart meter management unit, characterized in that it comprises:
the system comprises a first reading module, a second reading module and a third reading module, wherein the first reading module is used for reading the running state information of each service application program stored in a shared pipeline file, and the shared pipeline file is used for writing the running state information of each service application program into the shared pipeline file by each service application program installed in a power supply table;
the first determining module is used for determining whether each business application program has an operation fault according to the read operation state information;
the second determining module is used for determining a fault removal strategy according to the read running state information of the target business application program under the condition that the target business application program in each business application program has running faults;
and the repair module is used for repairing the target service application program according to the troubleshooting strategy.
9. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method of any of claims 1 to 7.
10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110175332.3A CN112905375A (en) | 2021-02-07 | 2021-02-07 | Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110175332.3A CN112905375A (en) | 2021-02-07 | 2021-02-07 | Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112905375A true CN112905375A (en) | 2021-06-04 |
Family
ID=76122869
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110175332.3A Pending CN112905375A (en) | 2021-02-07 | 2021-02-07 | Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112905375A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114567518A (en) * | 2022-02-15 | 2022-05-31 | 深圳绿米联创科技有限公司 | Prompting method and device for equipment state, electronic equipment and storage medium |
-
2021
- 2021-02-07 CN CN202110175332.3A patent/CN112905375A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114567518A (en) * | 2022-02-15 | 2022-05-31 | 深圳绿米联创科技有限公司 | Prompting method and device for equipment state, electronic equipment and storage medium |
| CN114567518B (en) * | 2022-02-15 | 2024-03-12 | 深圳绿米联创科技有限公司 | Device state prompting method and device, electronic device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112948157B (en) | Server fault positioning method, device and system and computer readable storage medium | |
| CN105930236A (en) | Application program version returning method based on BMS Bootloaderupgrade | |
| JP2014130585A (en) | Firmware upgrade error detection and automatic rollback | |
| WO2023115999A1 (en) | Device state monitoring method, apparatus, and device, and computer-readable storage medium | |
| CN111881014B (en) | System test method, device, storage medium and electronic equipment | |
| CN111767172A (en) | Self-repairing method for set top box based on watchdog and bootloader | |
| US10261720B2 (en) | Method for optimizing the use of a non-volatile memory in a motor vehicle computer for monitoring a functional member | |
| CN114816022B (en) | Method, system and storage medium for monitoring server power supply abnormality | |
| CN113672306B (en) | Server component self-checking abnormity recovery method, device, system and medium | |
| CN111651304A (en) | Software recovery method and device based on double-core intelligent electric meter and computer equipment | |
| CN112905375A (en) | Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment | |
| US8984333B2 (en) | Automatic computer storage medium diagnostics | |
| CN114385418A (en) | Protection method, device, equipment and storage medium for communication equipment | |
| CN109766207A (en) | Restoration methods, device, monitoring device and the storage medium of firmware remote upgrade | |
| CN107273291B (en) | Processor debugging method and system | |
| CN114942859A (en) | Method, device, equipment, medium and program product for processing node failure | |
| CN112527343A (en) | Firmware updating method and device, computer equipment and storage medium | |
| CN109672573B (en) | Configuration file deployment method, configuration file determination method, server and storage medium | |
| US20200379645A1 (en) | Computing device operational control using monitored energy storage device health parameters | |
| CN111858183A (en) | Restarting method and apparatus for electronic device | |
| EP3754657B1 (en) | Electronic control device | |
| CN114978891B (en) | Processing method, device and storage medium for BIOS configuration of network device | |
| CN117234787B (en) | Method and system for monitoring running state of system-level chip | |
| CN117472291B (en) | Data block verification method and device, storage medium and electronic equipment | |
| CN109491872B (en) | Memory supervision method and device and computer readable storage medium |
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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20230404 Address after: Full Floor 14, Unit 3, Building 2, No. 11, Middle Spectra Road, Huangpu District, Guangzhou, Guangdong 510700 Applicant after: China Southern Power Grid Digital Grid Technology (Guangdong) Co.,Ltd. Address before: Room 86, room 406, No.1, Yichuang street, Zhongxin Guangzhou Knowledge City, Huangpu District, Guangzhou City, Guangdong Province Applicant before: Southern Power Grid Digital Grid Research Institute Co.,Ltd. |