A dual-processor cooperative log fixation method for a satellite platform

Abstract

This invention proposes a dual-processor collaborative log persistence method for spaceborne platforms, comprising the following steps: dividing the on-chip memory into two independent shared memory channels, designated as the application log channel and the kernel log channel respectively; the main processor mirrors and writes the generated application logs and kernel logs into the corresponding shared memory channels; the coprocessor polls the two shared memory channels, reads newly added log data, and persists the read log data to storage; when the main processor experiences an anomaly, the frequency of log data reading and storage by the coprocessor is increased. This invention, by dividing the on-chip memory into independent shared memory channels, with the main processor mirroring and writing logs to the shared memory, and the coprocessor polling the shared memory and performing disk write operations, ensures that even if the main processor experiences an anomaly, the coprocessor can continue to read unprocessed log data and complete persistence, guaranteeing that critical logs before and after the anomaly are completely preserved.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a dual-processor collaborative log persistence method for spaceborne platforms. Background Technology

[0002] The onboard computing platform is the core of satellite data processing and mission control in orbit, and its reliability is directly related to the success or failure of space missions. During in-orbit operation, the system faces harsh space environments such as space radiation, drastic temperature changes, and single-event upsets. Coupled with factors such as software design defects or hardware aging, it is very easy to cause kernel anomalies, mission failures, or even sudden power outages. Log records are the key basis for post-fault diagnosis and on-orbit problem reproduction. Complete fault field logs are of great significance for locating the root cause of problems and improving system design.

[0003] Existing logging schemes for spaceborne systems typically rely on processors (such as the ARM Cortex-A53 core) to perform logging. These processors run a full Linux operating system and write logs directly to storage media via serial port output, network transmission, or the local file system. However, this single-processor-based logging method suffers from the following technical drawbacks in abnormal scenarios: 1) Log link interruption problem: When the processor experiences a kernel crash or unexpected restart, its local log output channel (such as serial port, network protocol stack) immediately fails. The critical context information at the time of the crash is often lost before it can be written to disk, making it difficult to trace the root cause of the fault. 2) Limited on-orbit debugging methods: During the on-orbit operation phase, the satellite cannot continuously connect to the debugging serial port as it does during ground development. Furthermore, the satellite-to-ground communication link has limited bandwidth and high latency, making it impossible to transmit complete log streams in real time. The traditional method of relying on external debugging channels to obtain logs is basically not feasible during the on-orbit phase. 3) Log mixing and timing disorder: Application layer logs and kernel layer logs are usually mixed and written to the same storage medium, lacking priority differentiation and isolation protection; when an anomaly occurs, the two types of logs overwrite each other or are mixed together, making it difficult to restore the accurate timing of the event and seriously affecting the efficiency of fault location.

[0004] In summary, there is an urgent need for a log persistence mechanism that can continue to operate after the main processor fails, in order to improve the on-orbit maintainability and fault diagnosis capabilities of the spaceborne system. Summary of the Invention

[0005] This invention proposes a dual-processor collaborative log persistence method for spaceborne platforms, which solves the problems in existing technologies.

[0006] The technical solution of this invention is implemented as follows: The first aspect of this invention provides a dual-processor collaborative log persistence method for spaceborne platforms, comprising the following steps: Two independent shared memory channels are allocated in the on-chip memory, serving as the application log channel and the kernel log channel, respectively. The main processor mirrors and writes the generated application logs and kernel logs into the corresponding shared memory channels. The coprocessor polls the two shared memory channels to read the newly added log data and persists the read log data to the storage device. When the main processor encounters an exception, increase the frequency at which the coprocessor reads and stores log data.

[0007] Specifically, the shared memory channel includes a channel header and a circular buffer. The channel header contains a magic number, version number, write pointer, write sequence number, exception flag, and reserved fields. The circular buffer is used to cache log data.

[0008] Furthermore, after the main processor powers on, it performs a validity check on the channel header. If the magic number or version number does not match, the channel header is initialized, the write pointer, write sequence number, and exception flag are cleared, and the version number is set. The memory barrier ensures that the initialized header state is visible to the coprocessor.

[0009] Furthermore, when the main processor writes the application log image to the application log channel, it determines whether it crosses the boundary of the circular buffer based on the current write pointer and log length. If it crosses the boundary, the log data is segmented, the remaining space at the end of the buffer is filled first, and then the remaining part is written from the beginning. During the writing process, a spinlock is used to implement mutual exclusion of operations, and a memory barrier is used to ensure that the write pointer and write sequence number are updated only after the log data is written.

[0010] Furthermore, the coprocessor polls the write sequence numbers of the two shared memory channels, compares them with the locally read sequence numbers, and calculates the length of the new data; it reads the new logs from the circular buffer in the order of reading the sequence numbers first and then reading the data, and processes the data splicing when the circular buffer rolls back; the coprocessor writes the read log data into the target file of the storage device according to the channel classification, and performs batch commit and forced flush operations during the writing process to ensure timely data persistence.

[0011] Specifically, the main processor obtains kernel log data in real time when the kernel prints information by registering a console callback function; when writing the kernel log image to the kernel log channel, a spinlock is used to implement mutual exclusion of operations, and a memory barrier is used to ensure that the write pointer and write sequence number are updated only after the log data is written.

[0012] Preferably, configurable switching parameters are set at runtime to control the enabling status of application log image, kernel log image and coprocessor solid-state storage functions; the solid-state storage function is turned off during the debugging phase to reduce system load, and the solid-state storage function is turned on during the on-orbit operation phase to improve the integrity of fault records.

[0013] Specifically, when an exception occurs in the main processor, the exception flag in the header of the shared memory channel is set through the exception notification mechanism, and the flag is made visible to the coprocessor. After the coprocessor detects that the exception flag is set, it increases the polling frequency of the shared memory channel and the writing frequency of the storage device, and appends the exception flag to the log record.

[0014] A second aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the computer program to implement the steps of the log persistence method.

[0015] A third aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the log persistence method.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) By dividing the on-chip memory into independent shared memory channels, the main processor only needs to write the log image to the shared memory, and the coprocessor independently polls the shared memory and performs disk write operations. Even if the main processor is abnormal or even crashes, the coprocessor can still continue to read the unprocessed log data and complete the persistence, ensuring that the key logs before and after the abnormality can be saved in a priority and complete manner. This fundamentally solves the problems of log link interruption and fault data loss in abnormal scenarios in traditional single-processor architecture, and significantly improves the on-orbit maintainability and fault diagnosis capability of the spaceborne platform. (2) This invention achieves physical isolation storage of two types of logs by setting up independent application log channels and kernel log channels in shared memory. Application logs and kernel logs do not interfere with each other and are written and read independently, avoiding the risk of overwriting and timing disorder caused by log mixing. The coprocessor writes the logs to different target files according to the channel classification, providing clear and orderly log data for post-fault analysis, which significantly improves the accuracy and efficiency of problem location; (3) This invention designs a segmented writing strategy for cross-boundary logs to address the boundary characteristics of the circular buffer. When the log length exceeds the remaining space at the end of the buffer, the log is automatically divided into two segments and written to the end and beginning respectively, ensuring the continuity and integrity of the log data. At the same time, a spin lock is used to implement mutual exclusion protection for multi-core concurrent writing, and a memory barrier is used to ensure that the write pointer is updated only after the data is written to memory, fundamentally eliminating concurrency problems such as log overwriting and corruption; (4) By setting configurable switching parameters during runtime, the present invention allows users to flexibly adjust the log storage strategy according to the task stage; during the debugging stage, the storage function can be turned off to reduce the system load and ensure the smoothness of development and debugging; during the on-orbit operation stage, the storage function is turned on to give full play to the fault recording capability of the coprocessor. This mechanism takes into account both performance and reliability and improves the engineering adaptability of the solution. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the overall process of the dual-processor collaborative log persistence method of the present invention.

[0019] Figure 2 This is a flowchart illustrating the application log writing and cross-boundary processing in an embodiment of the present invention.

[0020] Figure 3 This is a flowchart of coprocessor log reading and exception response in an embodiment of the present invention. Detailed Implementation

[0021] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0022] Reference Figure 1 The first aspect of this invention provides a dual-processor collaborative log persistence method for spaceborne platforms, comprising the following steps: Step S1: Divide the on-chip memory into two independent shared memory channels, which will serve as the application log channel and the kernel log channel, respectively.

[0023] Specifically, the on-chip memory uses the OCM (On-Chip Memory) inside the Zynq UltraScale+ MPSoC chip, which has low access latency, independent path, and does not depend on an external DDR controller. It can still be reliably accessed even when the main processor is abnormal or the external memory fails.

[0024] In this embodiment, the OCM is divided into two 64KB regions. For example, addresses 0xFFFC0000~0xFFFCFFFF are used as application log channels, and 0xFFFD0000~0xFFFDFFFF are used as kernel log channels. Each channel consists of a channel header and a circular buffer. The channel header contains a magic number, version number, write pointer, write sequence number, exception flag, and reserved fields. The magic number is used to identify the initialization state of the channel and is usually set to a fixed value. The version number is used to identify the version of the channel data structure for easy future upgrade compatibility. The write pointer points to the offset of the current writable position. The write sequence number is a monotonically increasing sequence number used by the coprocessor to detect the amount of new data. The exception flag indicates whether an exception has occurred in the main processor. Reserved fields are reserved for future expansion. The circular buffer is used to cache log data. By setting up two independent channels, physical isolation between application logs and kernel logs is achieved, avoiding the risk of overwriting and timing disorder caused by log mixing, and providing a clear data foundation for post-fault analysis.

[0025] Furthermore, after the main processor powers on, it performs a validity check on the channel header. If the magic number or version number does not match, the channel header is initialized, the write pointer, write sequence number, and exception flag are cleared, and the version number is set. The memory barrier ensures that the initialized header state is visible to the coprocessor.

[0026] Specifically, after the main processor boots up, it reads the magic number field of the channel header. If the value is not the default or the version number does not match the current driver version, the channel is considered uninitialized or incompatible. In this case, the write pointer, write sequence number, and exception flag are all cleared to zero, and the current version number is written. After these write operations, a memory barrier instruction is invoked to ensure that all write operations have been completed and flushed to memory. This allows the coprocessor to see complete and consistent header information when it subsequently reads the data, avoiding reading partially updated or incomplete data. This mechanism ensures that the shared memory channel remains in a usable initial state after multiple system boots or software upgrades.

[0027] Step S2: The generated application logs and kernel logs are mirrored and written to the corresponding shared memory channels by the main processor.

[0028] The main processor adds image writing logic to the existing log processing path: for application logs, after the Linux logger driver completes the local log writing, the same log data is copied and written to the application log channel.

[0029] For kernel logging, the main processor registers console callback functions to obtain kernel log data in real time when the kernel prints information. When mirroring the kernel log to the kernel log channel, a spinlock is used to implement mutual exclusion, and a memory barrier is used to ensure that the write pointer and write sequence number are updated only after the log data is written. Whenever the kernel calls to print the log, it iterates through all registered consoles, calls their write functions, and passes in the log string. In this callback function, the received kernel log data (including timestamp, level, content, etc.) is written to the kernel log channel as a complete record. The write process needs to handle the boundary issues of the circular buffer, and is protected by spinlocks and memory barriers. In this way, the kernel log can be mirrored to shared memory in real time without modifying the original kernel printing logic, which is simple to implement and has minimal impact on kernel performance.

[0030] Furthermore, such as Figure 2 As shown, when the main processor writes the application log image to the application log channel, it determines whether it crosses the boundary of the circular buffer based on the current write pointer and log length. If it crosses the boundary, the log data is segmented, the remaining space at the end of the buffer is filled first, and then the remaining part is written starting from the beginning. During the writing process, a spinlock is used to implement mutual exclusion of operations, and a memory barrier is used to ensure that the write pointer and write sequence number are updated only after the log data is written. This mechanism guarantees the integrity and correct order of log data, and even if there is concurrent writing by multiple cores or an interruption occurs during the writing process, there will be no data corruption or data loss due to premature pointer updates.

[0031] Step S3: The coprocessor polls the two shared memory channels to read the newly added log data and persists the read log data to the storage device.

[0032] like Figure 3 As shown, the coprocessor polls the write sequence numbers of the two channels at fixed intervals, compares them with the locally read sequence numbers, calculates the incremental data length, and then reads the new log from the circular buffer. During reading, it follows the order of "read sequence number first, then read data," and handles data concatenation during circular buffer rollback. The read log data is categorized by channel and written to target files on external storage devices (such as eMMC). The writing process employs batch commits and forced flush operations to ensure timely data persistence. By having the coprocessor independently handle the log persistence task, log generation and storage are decoupled, allowing log writing to disk to continue even when the main processor is busy or malfunctioning.

[0033] After reading, the log data is written to the target files in the EMMC according to the channel. To improve writing efficiency and reduce the risk of data loss, a batch commit strategy is adopted: after a certain number of logs have accumulated or after a certain period of time, a file synchronization operation is performed to force the data in the file cache to be flushed to the physical storage medium. This mechanism achieves a balance between write performance and data reliability, avoiding write amplification caused by frequent disk flushes while ensuring that critical logs are persisted as much as possible before power failure or reset.

[0034] Step S4: When the main processor encounters an exception, increase the frequency at which the coprocessor reads and stores log data.

[0035] like Figure 3 As shown, when the main processor experiences a fatal exception such as a kernel crash, it sets an exception flag in shared memory through an exception notification mechanism. Upon detecting this flag, the coprocessor immediately switches to emergency mode, shortens the polling cycle, increases the disk flushing frequency, and appends the exception identifier to the written log file. This mechanism ensures that critical context at the moment of the exception is saved preferentially and quickly, providing valuable on-site data for root cause analysis. This linkage mechanism ensures that the coprocessor can detect the exception immediately and enter emergency mode, maximizing the preservation of fault context information.

[0036] Preferably, configurable switching parameters are set at runtime to control the enabling status of application log mirroring, kernel log mirroring, and coprocessor persistent storage. During the debugging phase, mirroring and persistent storage can be turned off, allowing the main processor to focus on log output to the serial port or network, avoiding additional memory copy overhead. During the on-orbit operation phase, all functions are enabled to fully utilize the fault recording capability of this invention. This mechanism gives the system extremely high flexibility, ensuring reliability while also meeting performance requirements.

[0037] It should be noted that the processor architecture used in this embodiment is a heterogeneous multi-core processor, in which the main processor is an ARM Cortex-A53 core running the Linux operating system and the coprocessor is a real-time response Cortex-R5 core. However, the core idea of ​​this invention is also applicable to other heterogeneous multi-core platforms with similar main-coprocessor architectures.

[0038] A second aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the computer program to implement the steps of the log persistence method.

[0039] A third aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the log persistence method.

[0040] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A dual-processor collaborative log persistence method for spaceborne platforms, characterized in that, Includes the following steps: Two independent shared memory channels are allocated in the on-chip memory, serving as the application log channel and the kernel log channel, respectively. The main processor mirrors and writes the generated application logs and kernel logs into the corresponding shared memory channels. The coprocessor polls the two shared memory channels to read the newly added log data and persists the read log data to the storage device. When the main processor encounters an exception, increase the frequency at which the coprocessor reads and stores log data.

2. The dual-processor collaborative log persistence method for spaceborne platforms as described in claim 1, characterized in that, The shared memory channel includes a channel header and a circular buffer. The channel header contains a magic number, version number, write pointer, write sequence number, exception flag, and reserved fields. The circular buffer is used to cache log data.

3. The dual-processor collaborative log persistence method for spaceborne platforms as described in claim 2, characterized in that, After the main processor powers on, it performs a validity check on the channel header. If the magic number or version number does not match, the channel header is initialized, the write pointer, write sequence number, and exception flag are cleared, and the version number is set. The memory barrier ensures that the initialized header state is visible to the coprocessor.

4. The dual-processor collaborative log persistence method for spaceborne platforms as described in claim 2, characterized in that, When the main processor writes the application log image to the application log channel, it determines whether it crosses the boundary of the circular buffer based on the current write pointer and log length. If it crosses the boundary, the log data is segmented, the remaining space at the end of the buffer is filled first, and then the remaining part is written from the beginning. During the writing process, a spinlock is used to implement mutual exclusion of operations, and a memory barrier is used to ensure that the write pointer and write sequence number are updated only after the log data is written.

5. A dual-processor collaborative log persistence method for spaceborne platforms as described in claim 2, characterized in that, The coprocessor polls the write sequence numbers of the two shared memory channels, compares them with the locally read sequence numbers, and calculates the length of the new data; it reads the new log from the circular buffer in the order of reading the sequence number first and then reading the data, and processes the data concatenation when the circular buffer rolls back. The coprocessor writes the read log data into the target file of the storage device according to the channel, and performs batch commit and forced flush operations during the writing process to ensure timely data persistence.

6. The dual-processor collaborative log persistence method for spaceborne platforms as described in claim 1, characterized in that, The main processor obtains kernel log data in real time when the kernel prints information by registering a console callback function; when writing the kernel log image to the kernel log channel, a spinlock is used to implement mutual exclusion of operations, and a memory barrier is used to ensure that the write pointer and write sequence number are updated only after the log data is written.

7. The dual-processor collaborative log persistence method for spaceborne platforms as described in claim 1, characterized in that, Configure runtime configurable switch parameters to control the enabling status of application log image, kernel log image and coprocessor solid storage functions; disable solid storage function during the debugging phase to reduce system load, and enable solid storage function during the on-orbit operation phase to improve the integrity of fault records.

8. The dual-processor collaborative log persistence method for spaceborne platforms as described in claim 1, characterized in that, When an exception occurs in the main processor, the exception flag in the header of the shared memory channel is set through the exception notification mechanism, and the flag is made visible to the coprocessor. After the coprocessor detects that the exception flag is set, it increases the polling frequency of the shared memory channel and the writing frequency of the storage device, and appends the exception flag to the log record.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the log persistence method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the log persistence method as described in any one of claims 1 to 8.

Images