CN110532130A - Software failure recovery method, equipment and computer readable storage medium - Google Patents
Software failure recovery method, equipment and computer readable storage medium Download PDFInfo
- Publication number
- CN110532130A CN110532130A CN201810500927.XA CN201810500927A CN110532130A CN 110532130 A CN110532130 A CN 110532130A CN 201810500927 A CN201810500927 A CN 201810500927A CN 110532130 A CN110532130 A CN 110532130A
- Authority
- CN
- China
- Prior art keywords
- software
- normal
- failure recovery
- package acquisition
- pairing
- 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.)
- Withdrawn
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 63
- 238000000034 method Methods 0.000 title claims abstract description 45
- 230000004044 response Effects 0.000 claims abstract description 72
- 230000005540 biological transmission Effects 0.000 claims description 15
- 230000015654 memory Effects 0.000 claims description 14
- 238000012795 verification Methods 0.000 description 8
- 238000001514 detection method Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000005611 electricity Effects 0.000 description 1
- -1 electricity Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/142—Reconfiguring to eliminate the error
- G06F11/143—Reconfiguring to eliminate the error with loss of software functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention discloses a kind of software failure recovery methods, this method comprises: the normal device broadcast packages acquisition request when detecting fail soft, into network；It receives the software package that the normal device is sent and obtains response；It is matched with the one of normal device for sending software package acquisition response, wherein the normal device of pairing is known as paired device；Fault recovery is carried out from paired device downloading software.In addition, the present invention also provides a kind of equipment and computer readable storage mediums.Using the present invention can automatic recognition software failure, improve faulty equipment positioning efficiency and fault recovery reliability.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to a software failure recovery method, device, and computer-readable storage medium.
Background
In many industries, such as water, electricity, gas and heat meter reading industries, on one hand, the devices deployed in the network are required to have extremely high fault tolerance, and the device software is required to run stably for a long time. On the other hand, when the software of the device fails, the device software is required to recover the normal operation as fast as possible, but due to the reasons of scattered deployment of the device and the like, the failure recovery process is a time-consuming and labor-consuming process.
The equipment fault recovery mainly comprises the following steps: positioning the fault equipment, transmitting equipment software and replacing the equipment software. The existing fault recovery technology solves the problems in the fault recovery process from the aspects of quickly positioning fault equipment, improving software transmission efficiency, ensuring equipment software replacement success rate and the like. However, these failure recovery methods have the following problems: manual participation is needed, time and labor are consumed for fault recovery, and the fault recovery efficiency is low. And human mistakes may cause failure in fault recovery or even complete damage to the equipment. Because automation cannot be realized, manual fault positioning and fault recovery flow triggering are needed.
Disclosure of Invention
The invention mainly aims to provide a software fault recovery method, equipment and a computer readable storage medium, aiming at solving the problem that the automatic recovery of software faults cannot be realized.
In order to achieve the above object, the present invention provides a software failure recovery method, including:
when the fault software is detected, broadcasting a software package acquisition request to normal equipment in the network;
receiving a software package acquisition response sent by the normal equipment;
pairing with one of the normal devices which send the software package acquisition response, wherein the paired normal device is called a paired device;
and downloading software from the paired device for failure recovery.
In addition, to achieve the above object, the present invention also provides an apparatus, which includes a processor and a memory;
the processor is configured to execute a software failover program stored in the memory to implement the method described above.
Further, to achieve the above object, the present invention also proposes a computer-readable storage medium storing one or more programs, which are executable by one or more processors to implement the above-described method.
According to the software fault recovery method, the equipment and the computer readable storage medium, when fault software is detected, a software package acquisition request is broadcasted to normal equipment in a network, after a software package acquisition response sent by the normal equipment is received, the normal equipment is paired with one of the normal equipment which sends the software package acquisition response, the paired normal equipment is called paired equipment, and the software is downloaded from the paired equipment to carry out fault recovery. The invention can automatically identify software fault, improve the efficiency of locating fault equipment, automatically acquire software from any normal equipment in the network through the network equipment which is already networked, and can recover the fault as long as the normal equipment with matched version exists in the network, thereby ensuring the reliability of fault recovery.
Drawings
Fig. 1 is a schematic flowchart of a software failure recovery method according to a first embodiment of the present invention;
FIG. 2 is a first sub-flowchart of a software failure recovery method according to a first embodiment of the present invention;
FIG. 3 is a second sub-flow diagram illustrating a software failure recovery method according to a first embodiment of the present invention;
fig. 4 is a schematic sub-flow chart of a software failure recovery method according to the first embodiment of the present invention;
FIG. 5 is a schematic flowchart of a software failure recovery method according to a first embodiment of the present invention;
FIG. 6 is a diagram illustrating a hardware architecture of a device according to a second embodiment of the present invention;
FIG. 7 is a block diagram of the software failover routine of FIG. 6.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
In the following description, suffixes such as "module", "component", or "unit" used to denote elements are used only for facilitating the explanation of the present invention, and have no specific meaning in itself. Thus, "module", "component" or "unit" may be used mixedly.
First embodiment
Fig. 1 is a schematic flow chart of a software failure recovery method according to a first embodiment of the present invention. In fig. 1, the software failure recovery method includes:
step 110, when the fault software is detected, broadcasting a software package acquisition request to normal devices in the network.
Specifically, the current running state of the software is regularly detected and recorded, if the software is detected to be in fault, the software in fault is called as fault software, and a software package acquisition request is broadcasted to other devices in the network, wherein the other devices in the network are called as normal devices.
Optionally, a priority order for recording the running state may be set, for example, whether the software is running normally currently, current version information, compatible version level, and the like are recorded preferentially.
Optionally, the software package obtaining request includes version information required by the current device.
Optionally, the number of the normal devices may be one or more, and the present invention is not limited in detail herein.
Optionally, if the detection software runs normally, the detection software waits for the next cycle of detection, and the detection is repeated.
And step 120, receiving a software package acquisition response sent by the normal device.
Specifically, the normal device in the network acquires the software package acquisition request, and compares whether its version is compatible with the version information in the software package acquisition request, if the version is compatible, the normal device confirms to acquire the software package acquisition request and returns a software package acquisition response, and if the version is incompatible, the normal device does not return a response.
And when the normal equipment returns a response, receiving a software package acquisition response sent by the normal equipment. It will be understood by those skilled in the art that the response time will vary depending on the response speed of the normal device. The software package acquisition response is a response that the normal device is compatible with the version information.
Step 130, pairing with one of the normal devices that sent the software package acquisition response.
Specifically, after receiving the software package acquisition response, one of the normal devices is selected for pairing, and the paired normal device is referred to as a paired device.
Step 140, downloading software from the paired device for failover.
Specifically, after pairing with the normal device, a software transmission request is initiated, and the paired device transmits the software program. And after the transmission of the software program is finished, verifying the integrity and the correctness of the software program, restarting the software if the verification is successful, and restarting the equipment pairing and the file transmission if the verification is failed.
Optionally, as shown in fig. 2, step 130 specifically includes:
step 210, counting the number of the received software package acquisition responses and the response time;
step 220, when the response number reaches a preset number threshold, selecting the normal device with the shortest response time for pairing.
Specifically, the number of software package acquisition responses and the response time of receiving each software package acquisition are counted. In order to avoid network congestion caused by frequent network request initiation, the pairing can be completed when the number of the received responses is larger than a certain number threshold, the fault recovery process is continuously executed, and otherwise, the pairing is finished. That is, when the number of responses reaches the number threshold, the normal device with the shortest response time among the responses obtained from all the received software packages is paired.
Optionally, when the number of responses of the software acquisition response does not reach the preset number threshold, waiting for rebroadcasting the software package acquisition request.
Optionally, as shown in fig. 3, step 130 specifically includes:
step 310, acquiring the signal intensity of the normal device corresponding to each software package acquisition response;
and step 320, selecting the normal equipment with the highest signal strength for pairing.
Specifically, the signal strength of the normal device for which each software package sending acquires a response is detected in the fault recovery process, and the device is paired with the device with the highest signal strength.
Optionally, as shown in fig. 4, step 140 specifically includes:
step 410, sending a software transmission request to the pairing device;
step 420, receiving a software program transmitted by the pairing device according to the software transmission request;
step 430, verifying the software program;
step 440, replacing the software program with the failed software when the software program is verified successfully.
Specifically, after the pairing is completed, a software transmission request is sent to the pairing device, so that the pairing device sends a corresponding software program according to the request, the integrity and the correctness of the software program are verified, if the verification is successful, the software program passing the verification is replaced by the fault software, if the replacement is successful, the fault recovery is successful, otherwise, the pairing device is paired with the normal device again and the software program is downloaded.
Optionally, as shown in fig. 5, after step 140, the software failure recovery method of this embodiment further includes:
step 510, the software program is backed up.
Step 520, the software program is restarted.
Specifically, in the software starting process, the received software program is backed up, and then the acquired software program is tried to be started. If the starting is successful, the fault recovery is successful; and if the starting fails, the fault recovery fails, and the next fault recovery is waited to be initiated.
In the software failure recovery method provided in this embodiment, when detecting a failed software, a software package acquisition request is broadcast to normal devices in a network, and after receiving a software package acquisition response sent by the normal devices, the software package acquisition request is paired with one of the normal devices that sent the software package acquisition response, where the paired normal device is called a paired device, and the software is downloaded from the paired device to perform failure recovery. The invention can automatically identify software fault, improve the efficiency of locating fault equipment, automatically acquire software from any normal equipment in the network through the network equipment which is already networked, and can recover the fault as long as the normal equipment with matched version exists in the network, thereby ensuring the reliability of fault recovery.
Second embodiment
Fig. 6 is a schematic diagram of a hardware architecture of a device according to a second embodiment of the present invention. In fig. 6, the apparatus includes: a memory 610, a processor 620, and a software failover program 630 stored on the memory 610 and operable on the processor 620. In the present embodiment, the software failover program 630 includes a series of computer program instructions stored in the memory 610, which when executed by the processor 620, implement the software failover operations of the embodiments of the present invention. In some embodiments, the software failover program 630 may be divided into one or more modules based on the particular operations implemented by the portions of the computer program instructions. As shown in fig. 7, the software failure recovery program 630 includes: a broadcast module 710, a receive module 720, a pairing module 730, a failure recovery module 740, a backup module 750, and a software launch module 760. Wherein,
the broadcasting module 710 is configured to broadcast a software package acquisition request to normal devices in the network when the faulty software is detected.
Specifically, the current operating state of the software is periodically detected and recorded, if it is detected that the software fails, the failed software is called as failed software, and the broadcast module 710 broadcasts a software package acquisition request to other devices in the network, where the other devices in the network are called as normal devices.
Optionally, a priority order for recording the running state may be set, for example, whether the software is running normally currently, current version information, compatible version level, and the like are recorded preferentially.
Optionally, the software package obtaining request includes version information required by the current device.
Optionally, the number of the normal devices may be one or more, and the present invention is not limited in detail herein.
Optionally, if the detection software runs normally, the detection software waits for the next cycle of detection, and the detection is repeated.
A receiving module 720, configured to receive a software package obtaining response sent by the normal device.
Specifically, the normal device in the network acquires the software package acquisition request, and compares whether its version is compatible with the version information in the software package acquisition request, if the version is compatible, the normal device confirms to acquire the software package acquisition request and returns a software package acquisition response, and if the version is incompatible, the normal device does not return a response.
When the normal device returns a response, the receiving module 720 receives the software package acquisition response sent by the normal device. It will be understood by those skilled in the art that the response time will vary depending on the response speed of the normal device. The software package acquisition response is a response that the normal device is compatible with the version information.
And a pairing module 730, configured to pair with one of the normal devices that sent the software package acquisition response.
Specifically, after receiving the software package obtaining response, the pairing module 730 selects one of the normal devices for pairing, and refers to the paired normal device as the paired device.
And a failure recovery module 740, configured to download software from the paired device for failure recovery.
Specifically, after pairing with the normal device, the failure recovery module 740 initiates a software transmission request, and the paired device transmits the software program. And after the transmission of the software program is finished, verifying the integrity and the correctness of the software program, restarting the software if the verification is successful, and restarting the equipment pairing and the file transmission if the verification is failed.
More specifically, the failure recovery module 740 is specifically configured to:
sending a software transmission request to the paired device;
receiving a software program transmitted by the pairing equipment according to the software transmission request;
verifying the software program;
and when the software program is successfully verified, replacing the failed software with the software program.
Specifically, after the pairing is completed, a software transmission request is sent to the pairing device, so that the pairing device sends a corresponding software program according to the request, the integrity and the correctness of the software program are verified, if the verification is successful, the software program passing the verification is replaced by the fault software, if the replacement is successful, the fault recovery is successful, otherwise, the pairing device is paired with the normal device again and the software program is downloaded.
In an alternative embodiment, the pairing module 730 may be specifically configured to:
counting the number of the received software package acquisition responses and the response time;
and when the response number reaches a preset number threshold, selecting the normal equipment with the shortest response time for pairing.
Specifically, the pairing module 730 counts the number of software package acquisition responses and the response time of receiving each software package acquisition. In order to avoid network congestion caused by frequent network request initiation, the pairing can be completed when the number of the received responses is larger than a certain number threshold, the fault recovery process is continuously executed, and otherwise, the pairing is finished. That is, when the number of responses reaches the number threshold, the normal device with the shortest response time among the responses obtained from all the received software packages is paired.
Optionally, when the number of responses of the software acquisition response does not reach the preset number threshold, waiting for rebroadcasting the software package acquisition request.
In another alternative embodiment, the pairing module 730 may also be specifically configured to:
acquiring the signal intensity of the normal equipment corresponding to each software package acquisition response;
and selecting the normal equipment with the highest signal intensity for pairing.
Specifically, the signal strength of the normal device for which each software package sending acquires a response is detected in the fault recovery process, and the device is paired with the device with the highest signal strength.
And a backup module 750 for backing up the software program.
A software starting module 760 for newly starting the software program.
Specifically, in the software starting process, the backup module 750 backs up the received software program and tries to start the acquired software program. If the software starting module 760 is successfully started, the fault recovery is successful; and if the starting fails, the fault recovery fails, and the next fault recovery is waited to be initiated.
In the device provided in this embodiment, when detecting faulty software, the broadcasting module 710 broadcasts a software package acquisition request to normal devices in the network, after the receiving module 720 receives a software package acquisition response sent by the normal devices, the pairing module 730 pairs with one of the normal devices that sent the software package acquisition response, and the fault recovery module 740 downloads software from the paired device to perform fault recovery. The invention can automatically identify software fault, improve the efficiency of locating fault equipment, automatically acquire software from any normal equipment in the network through the network equipment which is already networked, and can recover the fault as long as the normal equipment with matched version exists in the network, thereby ensuring the reliability of fault recovery.
Third embodiment
The embodiment of the invention also provides a computer readable storage medium. The computer-readable storage medium herein stores one or more programs. Among other things, computer-readable storage media may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, a hard disk, or a solid state disk; the memory may also comprise a combination of memories of the kind described above. When one or more programs in the computer-readable storage medium are executable by one or more processors, the software failure recovery method provided by the first embodiment described above is implemented.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.
While the present invention has been described with reference to the embodiments shown in the drawings, the present invention is not limited to the embodiments, which are illustrative and not restrictive, and it will be apparent to those skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the invention as defined in the appended claims.
Claims (10)
1. A method for software fault recovery, the method comprising:
when the fault software is detected, broadcasting a software package acquisition request to normal equipment in the network;
receiving a software package acquisition response sent by the normal equipment;
pairing with one of the normal devices which send the software package acquisition response, wherein the paired normal device is called a paired device;
and downloading software from the paired device for failure recovery.
2. The software failure recovery method of claim 1, wherein pairing with one of the normal devices that sent the software package acquisition response specifically comprises:
counting the number of the received software package acquisition responses and the response time;
and when the response number reaches a preset number threshold, selecting the normal equipment with the shortest response time for pairing.
3. The software failure recovery method of claim 2, wherein when the number of responses does not reach a preset number threshold, then waiting for the software package acquisition request to be rebroadcast.
4. The software failure recovery method of claim 1, wherein pairing with one of the normal devices that sent the software package acquisition response specifically comprises:
acquiring the signal intensity of the normal equipment corresponding to each software package acquisition response;
and selecting the normal equipment with the highest signal intensity for pairing.
5. The method for recovering from a software failure according to claim 1, wherein downloading software from the paired device for failure recovery specifically includes:
sending a software transmission request to the paired device;
receiving a software program transmitted by the pairing equipment according to the software transmission request;
the software program is verified.
6. The software failure recovery method of claim 5, wherein when the software program is verified to be successful, the method further comprises:
replacing the software program with the failed software.
7. The software failure recovery method of claim 6, wherein the method further comprises:
backing up the software program
And restarting the software program.
8. The software failure recovery method according to claim 1, wherein the software package acquisition request includes version information to cause the normal device to determine compatibility with the version information, and accordingly, the software package acquisition response is a response that the normal device is compatible with the version information.
9. An apparatus, comprising a processor and a memory;
the processor is configured to execute a software failover program stored in the memory to implement the method of any of claims 1-8.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores one or more programs which are executable by one or more processors to implement the method of any one of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810500927.XA CN110532130A (en) | 2018-05-23 | 2018-05-23 | Software failure recovery method, equipment and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810500927.XA CN110532130A (en) | 2018-05-23 | 2018-05-23 | Software failure recovery method, equipment and computer readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110532130A true CN110532130A (en) | 2019-12-03 |
Family
ID=68657349
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810500927.XA Withdrawn CN110532130A (en) | 2018-05-23 | 2018-05-23 | Software failure recovery method, equipment and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110532130A (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1809816A (en) * | 2003-06-30 | 2006-07-26 | 汤姆森许可贸易公司 | Network equipment and a method for monitoring the start up of such equipment |
| CN101060427A (en) * | 2006-04-19 | 2007-10-24 | 华为技术有限公司 | A system and method for realizing the remote software updating |
-
2018
- 2018-05-23 CN CN201810500927.XA patent/CN110532130A/en not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1809816A (en) * | 2003-06-30 | 2006-07-26 | 汤姆森许可贸易公司 | Network equipment and a method for monitoring the start up of such equipment |
| CN101060427A (en) * | 2006-04-19 | 2007-10-24 | 华为技术有限公司 | A system and method for realizing the remote software updating |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7805637B2 (en) | Network equipment and a method for monitoring the start up of such equipment | |
| CN109669708B (en) | Remote upgrading method for modular Internet of things terminal equipment | |
| US11513916B2 (en) | History management method, history management apparatus and history management system | |
| US20130217382A1 (en) | Radio communication system and radio communication method | |
| CN103685487A (en) | Child node updating method in wireless communication network | |
| CN113721957B (en) | Automatic test method, device and system for firmware deployment upgrade of embedded equipment | |
| CN102541604A (en) | Remote upgrading method, remote upgrading terminal equipment and remote upgrading system | |
| CN111506326A (en) | Method, device and equipment for upgrading terminal equipment and storage medium | |
| CN111026581A (en) | Application program repairing method, device, system, storage medium and electronic device | |
| CN113542318A (en) | Equipment fault repairing method | |
| CN113722181B (en) | BMC process monitoring method, device, system and medium of server | |
| CN110532130A (en) | Software failure recovery method, equipment and computer readable storage medium | |
| CN105391629A (en) | Resource backup method and device | |
| CN108319551B (en) | Software testing method and device, computer equipment and readable storage medium | |
| CN104754410B (en) | Cable modem safety method and system | |
| CN105373549A (en) | Data migration method and device and data node server | |
| CN112887161B (en) | Mobile network detection method and device | |
| CN115866357A (en) | Data transmission method, system and device, server, client and storage medium | |
| CN105824824B (en) | Standby call ticket collection equipment and call ticket file collection method thereof | |
| CN109672573B (en) | Configuration file deployment method, configuration file determination method, server and storage medium | |
| CN107179917A (en) | System architecture and dispositions method for the operating system of installing multiple test systems | |
| CN109614116B (en) | Installation method and device of embedded system | |
| CN115629916B (en) | Service program fault recovery method based on Zynq | |
| CN113868246B (en) | Bit map synchronization method, system and device in storage system and readable storage medium | |
| CN111083001B (en) | Firmware abnormity detection method and device |
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 | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20191203 |
|
| WW01 | Invention patent application withdrawn after publication |