Global replacement type on-orbit programming method and system supporting multiple memories
By using a global replacement on-orbit programming method, and leveraging FPGA signals to generate software-uploaded remote control packages, clearing the cache area and embedding them into various memory sources, the problem of cumbersome on-orbit programming of spaceborne software is solved, achieving efficient software upgrades and compatibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI SATELLITE ENG INST
- Filing Date
- 2026-01-04
- Publication Date
- 2026-05-12
AI Technical Summary
In existing technologies, on-orbit programming methods for spaceborne software require multiple code comparisons, which are cumbersome, and the limited storage capacity of EEPROM makes it difficult to meet the storage requirements of complex tasks.
Employing a global replacement on-orbit programming method, the system generates a software-uploaded remote control package by coordinating FPGA program gating signals, clears the buffer, verifies and hardens the data into various memory sources, including MRAM and FLASH, enabling seamless software upgrades.
It improves the efficiency and convenience of on-orbit programming and testing of satellite software, simplifies the on-orbit software update process, adapts to various storage media, and enhances the availability and reliability of satellites.
Smart Images

Figure CN122018934A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of aerospace technology, and more specifically, to a global replacement on-orbit programming method and system that supports multiple types of memory. Background Technology
[0002] With the continuous development of aerospace technology, the missions undertaken by satellites are becoming increasingly complex, expanding from simple communication and remote sensing in the early days to multi-mission collaboration and high-precision observation. This places higher demands on the functionality and performance of onboard software.
[0003] As embedded software running on a single satellite, the scale of onboard software continues to expand with the increasing complexity of missions, and the storage medium is gradually shifting from traditional types to FLASH to meet the needs of larger storage capacity and more stable operation.
[0004] However, the operating conditions of onboard software during ground testing differ from actual in-orbit conditions, making it highly likely that software requirements will change during in-orbit testing. Against this backdrop, simplifying the in-orbit software programming process can improve the efficiency of version upgrades during in-orbit software testing, thereby enhancing the satellite's availability and reliability. Therefore, in-orbit programming methods capable of being written to multiple media have significant economic and social benefits in aerospace engineering practice.
[0005] A patent search revealed an invention patent with publication number CN107391189B, which discloses an on-orbit programming method for spaceborne software. The method includes steps one through uploading a program patch package; step two through receiving and verifying the received data; step three through storing the patch package in the on-orbit programming area; step four through uploading software signature settings; step five through modifying backup area data based on the software signature; step six through loading monitoring software to perform dog-feeding and hardware initialization operations; and step seven through clearing the corresponding sector based on the EDAC error address. This patent requires comparing the stored software with the new software and then uploading the on-orbit programming package based on this comparison. When problems arise during ground testing and a new software update is needed, multiple code comparisons and uploading operations are required, making the testing process quite cumbersome.
[0006] Patent CN107957874B discloses a recoverable, resident spaceborne software on-orbit programming method, comprising the following steps: establishing a testing system platform; after the testing system platform completes a mature SRAM on-orbit programming process and verifies the on-orbit programming information is correct, remote control commands are uploaded to solidify the on-orbit programming information into the free area of the EEPROM; after a reset, the original code stored in the EEPROM and the on-orbit programming information stored in the free area of the EEPROM are moved to the SRAM, and remote control commands are uploaded from the ground to determine whether to run only the original code or the on-orbit programmed program. This patent requires analysis and modification of the original stored code, which may lead to errors. Both of the above on-orbit programming methods use EEPROM as the storage medium, which has limited storage capacity.
[0007] In summary, given the problems of the existing technologies, researching a global replacement-based on-orbit programming method and system that supports multiple memory types has become a critical task that urgently needs to be addressed. Summary of the Invention
[0008] In view of the deficiencies in the prior art, the purpose of this invention is to provide a global replacement on-orbit programming method and system that supports multiple types of memory.
[0009] A global replacement-based on-orbit programming method supporting multiple memory types, provided by the present invention, includes the following steps: Step S1: Generate the software-uploaded remote control package based on the executable bin file of the satellite software; Step S2: Send a cache clearing command to clear the cache of the current storage software, and confirm the completion of cache clearing via telemetry; Step S3: Send the software betting remote control package to the buffer area and confirm the betting is completed via telemetry; Step S4: Verify the betting software in the cache area. If the verification is successful, generate a successful betting telemetry. Step S5: Send software hardening command to write the verified uploading software from the cache to the uploading area of the specified hardenable storage device. After the writing is completed, generate a write completion flag. The hardenable storage device supports MRAM and FLASH memory. Step S6: Generate a memory area selection signal through FPGA gating operation. When the write completion flag is detected, point the selection signal to the upper bet area. Step S7: Perform a hardware restart. The monitoring program loads the betting software from the betting area into memory for execution based on the memory area selection signal generated by the FPGA.
[0010] Preferably, in step S1, the onboard software bin file is in binary file format, and the remote control package is packaged into a remote control package conforming to a specific format by packaging software to encapsulate the binary data in the onboard software bin file.
[0011] Preferably, in step S2, after sending the buffer clearing instruction, the operation of clearing the buffer is performed; the clearing operation is completed in a multi-cycle time-sharing manner, and the clearing progress is characterized by area counting and status telemetry; when the buffer is cleared, the betting process control state machine is set to the state of allowing betting remote control packages.
[0012] Preferably, in step S3, when the injection process control state machine is in the state of allowing injection remote control packages, it receives and processes software injection remote control packages; compares the received package count with the package sequence number in the currently received software injection remote control package; if they match, it calculates the XOR sum checksum of the on-orbit programming program data in the software injection remote control package and compares it with the XOR sum checksum in the software injection remote control package; when the checksum matches, it copies the on-orbit programming program data to the buffer area and stores the checksum valid flag at the checksum flag of the corresponding package sequence number; if the package sequence number does not match or the checksum does not match, it records the abnormal telemetry and transmits it; when the received package count is equal to the total number of on-orbit programming packages defined in the software injection remote control package, it sets the injection completion flag.
[0013] Preferably, in step S4, the betting software in the buffer is subjected to XOR check; when all flags in the check flag storage array are valid, the check is determined to be successful, the state of the betting process control state machine is set to the check completed state, and the software master control enable flag is set to disabled. After the check is successful, a successful betting telemetry is generated.
[0014] Preferably, in step S5, after sending the software hardening command, the verified uploading software is written from the cache to the designated hardenable storage device; during the writing process, all periodically running functions of the software are disabled.
[0015] When the hardenable storage device is an MRAM memory, data is directly assigned to the destination address, one sector is written per cycle, and the write completion flag is set after all sectors have been written. When the hardenable storage device is a FLASH memory, the target sector is erased first and then a separate write thread is started. The write thread is started by waiting for the write start semaphore. After each sector is written, a write count is given. After all sectors are written, the write completion flag is set. Preferably, in step S5, the solidifiable storage device is divided into four physical areas, three of which are pre-storage areas that store the program before it is programmed on track, and one is an uploading area that stores the uploading software after the software uploading remote control package is reassembled, that is, the uploaded new program.
[0016] Preferably, in step S6, after the write completion flag is set, the hardware strobe signal is configured through the FPGA to make the selection signal point to the upper injection area.
[0017] Preferably, in step S7, when the memory selection signal generated by the FPGA points to the pre-stored area, a three-out-of-two fault-tolerant operation is performed on the program in the three pre-stored areas to restore the program data in the faulty area and load the unified program; when the memory selection signal points to the upper betting area, the upper betting software is loaded from the upper betting area.
[0018] This invention also provides a globally replaceable on-orbit programming system supporting multiple memory types, comprising: Module M1 generates a software-uploaded remote control package based on the executable bin file of the onboard software; Module M2 sends a cache clearing command to clear the cache of the current storage software and confirms the cache clearing is complete via telemetry; Module M3 sends the software betting remote control package to the buffer area and confirms the betting completion via telemetry; Module M4 verifies the betting software in the cache. Once the verification is successful, a telemetry signal for successful betting is generated. Module M5 sends a software hardening command to write the verified uploading software from the cache to the uploading area of the specified hardenable storage device. After the writing is completed, a write completion flag is generated. The hardenable storage device supports MRAM and FLASH memory. Module M6 generates a memory area selection signal through FPGA gating operation. When a write completion flag is detected, the selection signal is pointed to the upper bet area. Module M7 performs a hardware restart. The monitoring program selects the memory area based on the memory area selection signal generated by the FPGA and loads the betting software from the betting area into memory for execution.
[0019] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention, in conjunction with the FPGA program gating area signal, enables global replacement-type on-orbit programming of spaceborne software supporting multiple memories, thereby improving the efficiency of on-orbit programming and testing of spaceborne software and helping on-orbit software to quickly complete testing, updates, and iterations.
[0020] 2. This invention enables a comprehensive upgrade of onboard software without the need for difference comparison, and can be embedded in multiple storage media, improving the convenience and adaptability of onboard software upgrades in orbit. Attached Figure Description
[0021] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1This is a state transition diagram for a global replacement on-orbit programming method supporting multiple memory types, as described in an embodiment of the present invention. Detailed Implementation
[0022] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.
[0023] This invention provides a global replacement on-orbit programming method and system supporting multiple memory types. The method includes the following steps: S1, generating a software-uploaded remote control package based on the executable program bin file of the on-board software; S2, sending a command to clear the buffer of the currently received software-uploaded software, simultaneously observing telemetry information during the clearing of the buffer, and waiting for the clearing action to be completed; S3, uploading the software-uploaded remote control package generated in step S1, while simultaneously observing the corresponding telemetry, until the uploading is completed; S4, the software verifies all the uploaded remote control packages, and outputs a successful uploading telemetry after verification; S5, sending a software hardening command, writing the uploaded software in the buffer into a hardenable storage device according to the configuration, supporting multiple memory types such as MRAM and FLASH; S6, performing an FPGA selection operation to select and load the newly written hardened storage area program; and S7, hardware restart, loading the monitoring software according to the FPGA selection signal to load the hardened program into memory for execution. This invention allows for complete re-uploading of the program without interrupting the onboard software operation, eliminating the need for comparing old and new versions of the code, and simplifying the operation. By adopting a management model that separates the pre-stored area from the uploading area for the onboard code, the storage device where the pre-stored program is located is completely isolated, ensuring that the pre-stored program is not tampered with or destroyed, simplifying the satellite's on-orbit programming operation, and making on-orbit software changes easier and more reliable. Furthermore, the fixed memory supports configuration according to specific devices and is compatible with various types of memory for writing.
[0024] Example 1: Figure 1 This is a state transition diagram for a global replacement on-orbit programming method supporting multiple memory types, as described in an embodiment of the present invention.
[0025] like Figure 1 As shown, this embodiment provides a global replacement-based on-orbit programming method that supports multiple memory types, including the following steps: Step S1: Generate the software-uploaded remote control package based on the executable bin file of the satellite software.
[0026] Specifically, in step S1, the onboard software bin file is in binary file format and contains the machine code required for program execution. The onboard software bin file is generated by the compiler by compiling the software source file. This machine code can be burned into the device's storage chip.
[0027] The software-uploaded remote control package uses packaging software to encapsulate the binary data in the onboard software's bin file into a remote control package conforming to a specific format. Based on a given packet header and packet length, the packaging software generates a software-uploaded remote control package containing all the data from the bin file. The software-uploaded remote control package is generated based on the complete onboard software bin file and does not require comparison with the previous version of the software.
[0028] The software betting remote control package contains the total number of packets to be betting and the global checksum of the new betting software. The total number of packets is used to verify the continuity of data packets, and the global checksum is used to verify the integrity of data, that is, whether all on-orbit programming data packets have been received.
[0029] In this embodiment, the data structure of the remote control package uploaded by the software includes a package header and auxiliary data, the total number of on-orbit programming packages, the current package serial number, on-orbit programming program data, XOR checksum, and frame tail.
[0030] The data structure is shown in the table below:
[0031] Step S2: Send a buffer clearing command to clear the buffer of the current storage software receiving and uploading software, and confirm the completion of buffer clearing through telemetry.
[0032] Specifically, to avoid leaving information from the previous betting package in memory, the buffer is cleared after sending the buffer clearing command each time during on-orbit programming. The clearing operation is completed in a multi-cycle time-sharing manner, and the clearing progress is characterized by area counting and status telemetry. When the buffer is cleared, the betting process control state machine is set to the state of allowing remote betting packages.
[0033] In this embodiment, the on-orbit programming process is controlled by a state machine, which includes the following states: idle state, clearing the buffer, clearing the buffer, injecting, injecting completed, verifying, verifying completed, writing, and writing completed. The state transitions of the state machine are transmitted in real time through a telemetry channel, and the entire injecting process can be monitored.
[0034] Step S3: Send the software betting remote control package to the buffer area and confirm the betting is completed via telemetry.
[0035] In this embodiment, the buffer for receiving betting software is defined as a 512KB two-dimensional array, the size of which can be adjusted according to the scale of the betting software. In this embodiment, the array is set to 1KB per row, for a total of 512 rows.
[0036] Furthermore, when the uploading process control state machine is in the uploading remote control package enabled state, it receives and processes the software uploading remote control package; it compares the count of received packages with the package sequence number in the currently received software uploading remote control package. If they match, it calculates the XOR sum checksum of the on-orbit programming program data in the software uploading remote control package and compares it with the XOR sum checksum in the software uploading remote control package; when the checksum matches, it copies the on-orbit programming program data to the buffer area and stores the checksum valid flag at the checksum flag of the corresponding package sequence number; if the package sequence number does not match or the checksum does not match, it records the abnormal telemetry and transmits it down; when the count of received packages is equal to the total number of on-orbit programming packages defined in the software uploading remote control package, it determines that the uploading package reception is complete and sets the uploading completion flag.
[0037] Step S4: Verify the betting software in the cache area. If the verification is successful, generate a successful betting telemetry.
[0038] Specifically, the remote control packet verification adopts an XOR checksum method, storing the XOR checksum value of the data in the uploaded remote control packet, and calculating the XOR checksum value of the data in the received remote control packet. By comparing the two checksums, the correctness of the received remote control data is determined.
[0039] Furthermore, an XOR check is performed on the betting software in the buffer; when all flags in the check flag storage array are valid, the check is deemed successful, the state of the betting process control state machine is set to the check completed state, and the software master control enable flag is set to disabled, ready to be written to memory; after the check is successful, a successful betting telemetry is generated.
[0040] Step S5: Send software hardening command to write the verified betting software from the cache to the betting area of the specified hardenable storage device according to the configuration. After the writing is completed, generate a write completion flag. The hardenable storage device supports multiple memory such as MRAM and FLASH memory.
[0041] Specifically, the solidifiable storage device is divided into four physical areas, three of which are pre-storage areas, storing programs before on-orbit programming, and one is an uploading area, storing the uploading software after the software uploading remote control package is reassembled, that is, the uploaded new program.
[0042] Furthermore, when implementing on-orbit programming, the software uses a state machine to transition through the entire process from clearing the injection area to writing to the storage area, and the control variable values of each state change dynamically with the injection stage.
[0043] Furthermore, after sending the software hardening command, the verified uploading software is written from the cache to the designated hardenable storage device; during the writing process, in order to minimize the impact on other storage devices, all periodically running functions of the software are disabled.
[0044] Each cycle only involves writing to memory. During the data writing process, after each sector is written, the sector content is read out and compared with the written data. If the data does not match, a write error flag is set, and the state of the above process control state machine is reset to the initial state.
[0045] When the persistent storage device is MRAM, data is directly assigned to the destination address, and one sector is written per cycle. Each MRAM sector is 512 bytes in size, which is the unit of writing. After all sectors have been written, a write completion flag is set. When the hardenable storage device is FLASH memory, the target sector is erased first, and then a separate write thread is started. The write thread is started by waiting for a write start semaphore, which is set after the write process is completed and a write command is received. The write thread provides real-time feedback on its running status during the write process. After each sector is written, a write count is given. Each sector in FLASH memory is 128KB in size, which is the write unit. After all sectors are written, a write completion flag is set.
[0046] The entire process of on-orbit programming, from clearing the betting area to writing to the storage area, is transitioned through a state machine, and the values of the control variables in each state change dynamically with the betting stage.
[0047] Step S6: Generate a memory area selection signal through FPGA gating operation. When the write completion flag is detected, point the selection signal to the upper bet area. Specifically, in step S6, after the write completion flag is set, the hardware strobe signal is configured through the FPGA to make the selection signal point to the upper betting area.
[0048] Step S7: Perform a hardware restart. The monitoring program loads the betting software from the betting area into memory for execution based on the memory area selection signal generated by the FPGA.
[0049] Specifically, the program is selected to load the pre-stored area or the upper-entry area by the strobe signal output by the FPGA, and the monitoring program guides the program of the corresponding storage area to the memory for execution according to the strobe signal.
[0050] Furthermore, when the memory selection signal generated by the FPGA points to the pre-stored area, a two-out-of-three fault-tolerant operation is performed on the program in the three pre-stored areas to restore the program data in the faulty area and load the unified program; when the memory selection signal points to the upper betting area, the upper betting software is loaded from the upper betting area.
[0051] Example 2: The present invention also provides a global replaceable on-orbit programming system that supports multiple types of memory. The global replaceable on-orbit programming system that supports multiple types of memory can be implemented by executing the process steps of the global replaceable on-orbit programming method that supports multiple types of memory. That is, those skilled in the art can understand the global replaceable on-orbit programming method that supports multiple types of memory as a preferred embodiment of the global replaceable on-orbit programming system that supports multiple types of memory.
[0052] Specifically, this globally replaceable on-orbit programming system that supports multiple memory types includes: Module M1 generates a software-uploaded remote control package based on the executable bin file of the onboard software; Module M2 sends a buffer clearing command to clear the buffer of the current storage software receiving and uploading software, and confirms the completion of buffer clearing through telemetry; Module M3 sends the software betting remote control package to the buffer area and confirms the betting completion via telemetry; Module M4 verifies the betting software in the cache. Once the verification is successful, a telemetry signal for successful betting is generated. Module M5 sends a software hardening command to write the verified uploading software from the cache to the uploading area of the specified hardenable storage device. After the writing is completed, a write completion flag is generated. The hardenable storage device supports MRAM and FLASH memory. Module M6 generates a memory area selection signal through FPGA gating operation. When a write completion flag is detected, the selection signal is pointed to the upper bet area. Module M7 performs a hardware restart. The monitoring program selects the memory area based on the memory area selection signal generated by the FPGA and loads the betting software from the betting area into memory for execution.
[0053] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.
[0054] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.
Claims
1. A global replacement-based on-orbit programming method supporting multiple memory types, characterized in that, Includes the following steps: Step S1: Generate the software-uploaded remote control package based on the executable bin file of the satellite software; Step S2: Send a cache clearing command to clear the cache of the current storage software, and confirm the completion of the cache clearing by telemetry; Step S3: Send the software betting remote control package to the cache area, and confirm the betting is completed via telemetry; Step S4: Verify the betting software in the cache area. If the verification is successful, generate a successful betting telemetry. Step S5: Send a software hardening command to write the verified uploading software from the cache area to the uploading area of the specified hardenable storage device. After the writing is completed, a write completion flag is generated. The hardenable storage device supports MRAM and FLASH memory. Step S6: Generate a memory area selection signal through FPGA gating operation. When the write completion flag is detected, point the selection signal to the upper area. Step S7: Perform a hardware restart. The monitoring program loads the betting software from the betting area into memory for execution based on the memory area selection signal generated by the FPGA.
2. The global replacement on-orbit programming method supporting multiple memories as described in claim 1, characterized in that, In step S1, the onboard software bin file is in binary file format, and the remote control package is generated by packaging software that encapsulates the binary data in the onboard software bin file into a remote control package that conforms to a specific format.
3. The global replacement on-orbit programming method supporting multiple memories as described in claim 1, characterized in that, In step S2, after sending the buffer clearing instruction, the operation of clearing the buffer is performed; the clearing operation is completed in a multi-cycle time-sharing manner, and the clearing progress is characterized by area counting and status telemetry; when the buffer is cleared, the betting process control state machine is set to the state of allowing betting remote control packages.
4. The global replacement on-orbit programming method supporting multiple memories as described in claim 1, characterized in that, In step S3, when the injection process control state machine is in the state of allowing injection remote control packages, it receives and processes the software injection remote control package; it compares the received package count with the package sequence number in the currently received software injection remote control package. If they match, it calculates the XOR sum checksum of the on-orbit programming program data in the software injection remote control package and compares it with the XOR sum checksum in the software injection remote control package; when the checksum matches, it copies the on-orbit programming program data to the buffer area and stores the checksum valid flag at the checksum flag of the corresponding package sequence number. If the packet sequence number does not match or the verification is inconsistent, the abnormal telemetry is recorded and transmitted; when the count of received packets is equal to the total number of on-orbit programming packets defined in the software-uploaded remote control packet, the uploading completion flag is set.
5. The global replacement on-orbit programming method supporting multiple memories as described in claim 1, characterized in that, In step S4, the betting software in the buffer is subjected to XOR verification; when all flags in the verification flag storage array are valid, the verification is determined to be successful, the state of the betting process control state machine is set to the verification completed state, and the software master control enable flag is set to disabled. After the verification is successful, a successful betting telemetry is generated.
6. The global replacement on-orbit programming method supporting multiple memories as described in claim 1, characterized in that, In step S5, after sending the software hardening command, the verified uploading software is written from the cache to the designated hardenable storage device; during the writing process, all periodically running functions of the software are disabled. When the solidifiable storage device is an MRAM memory, data is directly assigned to the destination address, one sector is written per cycle, and a write completion flag is set after all sectors are written. When the solidifiable storage device is a FLASH memory, the target sector is erased first and then a separate write thread is started. The write thread is started by waiting for a write start semaphore. After each sector is written, a write count is given. After all sectors are written, a write completion flag is set.
7. The global replacement on-orbit programming method supporting multiple memories as described in claim 1, characterized in that, In step S5, the solidifiable storage device is divided into four physical areas, three of which are pre-storage areas that store the program before it is programmed on track, and one is an uploading area that stores the uploading software after the software uploading remote control package is reassembled, i.e., the new uploading program.
8. The global replacement on-orbit programming method supporting multiple memories as described in claim 7, characterized in that, In step S6, after the write completion flag is set, the hardware strobe signal is configured through the FPGA to make the selection signal point to the upper injection area.
9. The global replacement on-orbit programming method supporting multiple memories as described in claim 8, characterized in that, In step S7, when the memory selection signal generated by the FPGA points to the pre-memory area, a two-out-of-three fault-tolerant operation is performed on the program in the three pre-memory areas to restore the program data in the faulty area and load the unified program; when the memory selection signal points to the betting area, the betting software is loaded from the betting area.
10. A global replacement on-orbit programming system supporting multiple memories, employing the global replacement on-orbit programming method supporting multiple memories as described in any one of claims 1-9, characterized in that, include: Module M1 generates a software-uploaded remote control package based on the executable bin file of the onboard software; Module M2 sends a cache clearing command to clear the cache of the current storage software, and confirms the completion of the cache clearing via telemetry; Module M3 sends the software betting remote control package to the buffer area and confirms the betting completion via telemetry; Module M4 verifies the betting software in the cache area, and generates a successful betting telemetry signal after the verification is passed. Module M5 sends a software hardening command to write the verified uploading software from the cache area to the uploading area of the specified hardenable storage device. After the writing is completed, a write completion flag is generated. The hardenable storage device supports MRAM and FLASH memory. Module M6 generates a memory area selection signal through FPGA gating operation. When the write completion flag is detected, the selection signal is directed to the upper area. Module M7 performs a hardware restart. The monitoring program loads the betting software from the betting area into memory for execution based on the storage area selection signal generated by the FPGA.