Real-time data acquisition and redundant storage system for large-scale system testing

Abstract

A real-time data acquisition and redundant storage system used in large-scale system tests, such as space launch vehicle tests, is disclosed. The real-time data acquisition and redundant storage system for large-scale system tests according to the present invention comprises a single target computing device including a multi-core central processing unit, a real-time operating system running on a first core of the multi-core central processing unit and controlling the storage of multi-channel real-time data in a first storage device through a first storage path, and a general-purpose operating system running on a second core of the multi-core central processing unit and controlling the storage of multi-channel real-time data in a second storage device through a second storage path.

Description

Technology Field

[0001] The present invention relates to a real-time data acquisition and redundant storage system used in large-scale system tests, such as space launch vehicle tests. Background Technology

[0002] Space launch vehicles are highly complex systems involving large structures, extreme temperature and pressure conditions, high-speed rotating mechanical elements, and complex combustion systems; as such, ground testing conducted prior to launch is a critical procedure that determines the success of the launch. During these testing processes, various physical quantities such as combustion pressure, propellant flow rate, vibration, strain, temperature, and electrical signals are measured through multiple sensors, and multi-channel real-time data is generated simultaneously from hundreds to thousands of channels.

[0003] In particular, during test phases where data increases explosively over short periods, such as immediately after engine ignition, the amount of raw data generated per second can increase rapidly. Reliably acquiring and storing such a large amount of real-time data is directly linked to the accuracy of the analysis of test results, and if any data is lost or storage delays occur, the reliability of the test can be significantly reduced. Furthermore, since space launch vehicle testing requires enormous costs and time and is not easy to retest, it is required that all data generated during the test be preserved as completely as possible.

[0004] Conventional data acquisition and storage systems have generally adopted a structure in which data is acquired from a single-operating-based data collection device and then transferred to a separate storage device for storage, either within the same device or via a network. However, this structure has the following problems:

[0005] First, in a single operating system-based architecture, various tasks such as real-time data storage, user interfaces, logging, and network communication are performed on the same resources; therefore, if a specific workload increases, scheduling interference may occur in data storage operations. This may potentially lead to storage delays or data loss.

[0006] Second, in structures where data is transmitted to external storage devices over a network, there is a risk of data loss due to external factors such as network bandwidth limitations, transmission delays, packet loss, and connection interruptions. In particular, when network stability cannot be fully guaranteed in a test site environment, network-based redundancy may not provide sufficient reliability.

[0007] Third, in large-scale data environments, a structure relying on a single storage path carries the risk of total data loss in the event of storage device failure or I / O bottlenecks. While some conventional technologies provide internal storage redundancy such as RAID, this is merely physical redundancy within the same storage system and is distinct from parallel storage at the operating system level or independent path-based storage.

[0008] Fourth, there is also the issue of time alignment for multi-channel data. Since sampling rates and collection times may differ for each sensor, simply storing data in the order of arrival can make it difficult to align data based on the same reference point during the post-test analysis process. Accordingly, functions for assigning time tags and reordering are required; however, performing all of these tasks within a single operating system environment increases the processing load, which may affect real-time storage.

[0009] As such, conventional technology has not sufficiently resolved issues such as resource interference between operating systems, network dependency, dependency on a single storage path, and time alignment processing load when storing large amounts of multi-channel real-time data with high reliability.

[0010] A related prior art document is Korean Published Patent Application No. 10-2016-0073601 (Title of invention: Launch vehicle system integrated test facility system, Date of publication: June 27, 2016). Prior art literature

[0011] Republic of Korea Published Patent Application No. 10-2016-0073601 (June 27, 2016) The problem to be solved

[0012] The objective of the present invention is to provide a real-time data acquisition and redundant storage system for large-scale system testing, such as space launch vehicle testing, which stores data in parallel through multiple independent storage paths within a single computing platform without relying on network transmission, and enables the separation of real-time guarantee and post-processing functions. means of solving the problem

[0013] The above objective is achieved by a real-time data acquisition and redundant storage system for large-scale system testing, according to one embodiment of the present invention, wherein the system for acquiring and redundantly storing multi-channel real-time data generated from large-scale system testing comprises: a single target computing device including a multi-core central processing unit; and an operating system that runs on the multi-core central processing unit and controls the storage of the multi-channel real-time data in a first storage device through a first storage path and controls the storage of the multi-channel real-time data in a second storage device through a second storage path.

[0014] Preferably, the operating system may include a real-time operating system that runs on a first core of the multi-core central processing unit and controls the storage of the multi-channel real-time data in a first storage device through a first storage path, and a general-purpose operating system that runs on a second core of the multi-core central processing unit and controls the storage of the multi-channel real-time data in a second storage device through a second storage path.

[0015] Preferably, the second storage device is positioned at a location physically separated from the single target computing device and is directly connected to the single target computing device via a communication cable without passing through a network, and the general-purpose operating system can transmit and store the multi-channel real-time data in the second storage device through the second storage path without passing through a network.

[0016] Preferably, the first storage path and the second storage path may be configured to operate in parallel on the single target computing device without passing through a network.

[0017] Preferably, the multicore central processing unit may be configured to permanently allocate different physical cores to the real-time operating system and the general-purpose operating system so that each operating system runs independently without scheduling interference.

[0018] Preferably, the real-time operating system and the general-purpose operating system may be configured to exchange the multi-channel real-time data through a shared memory set in a physical memory area.

[0019] Preferably, the shared memory is formed as a ring buffer structure including a write pointer and a read pointer, and the real-time operating system may be configured to sequentially write the multi-channel real-time data and the general-purpose operating system may be configured to sequentially read the written data.

[0020] Preferably, the size of the shared memory is calculated based on the number of channels, data type, sampling rate, and buffering time, and the buffering time can be set to more than twice the required time for real-time data processing.

[0021] Preferably, a real-time data acquisition and redundant storage system for large-scale system testing according to one embodiment of the present invention may further include a time synchronization module that assigns a time tag to each data so that all channel data are aligned with respect to a common reference point.

[0022] Preferably, the general-purpose operating system may be configured to rearrange the multi-channel real-time data in chronological order based on the time tag, and to reconstruct data packets based on the rearranged data and store them in a second storage device.

[0023] Preferably, the multicore central processing unit may be configured to dynamically adjust the number of cores allocated to each operating system to two or more based on at least one of the raw data rate per second, the write processing time of the first storage device, and the load state of the second storage device.

[0024] Preferably, the general-purpose operating system may be configured to collect data generated from peripheral devices that do not require real-time performance, and to integrate and store the data collected from the peripheral devices and the multi-channel real-time data according to the same time standard. Effects of the invention

[0025] According to one embodiment of the present invention, by configuring data to be stored in parallel through a first storage path and a second storage path on a single target computing device without passing through a network, the risk of data loss caused by external communication environments, such as network bottlenecks, transmission delays, packet loss, and connection interruptions, can be structurally eliminated. Accordingly, data survivability can be significantly improved in environments where retesting is difficult and data value is very high, such as space launch vehicle testing.

[0026] According to one embodiment of the present invention, by configuring a real-time operating system and a general-purpose operating system to run simultaneously on different physical cores of a multi-core central processing unit, scheduling interference between real-time data storage operations and user interface / post-processing tasks can be minimized. Accordingly, determinism of storage operations handled by the real-time operating system can be ensured, and storage delay can be suppressed even in high-speed multi-channel data environments.

[0027] According to one embodiment of the present invention, by physically separating a first storage device and a second storage device to perform redundant storage, it is possible to prevent the simultaneous loss of all data even if problems such as failure of the storage device itself, file system errors, or I / O bottlenecks occur. This can provide an operating system-level independent path-based redundancy effect that is distinct from physical redundancy within a single storage system, such as RAID.

[0028] According to one embodiment of the present invention, by performing data exchange between two operating systems through a shared memory-based ring buffer structure, non-determinism caused by dynamic memory allocation is reduced, and a stable producer-consumer model can be implemented even in high-speed data environments. In addition, a structure based on write pointers and read pointers enables clear tracking of data duplication or omission, thereby improving the reliability of data verification after testing.

[0029] According to one embodiment of the present invention, time consistency of multiple channel data can be ensured by assigning a time tag for a common reference point to each data through a time synchronization module and performing time order rearrangement and packet reconstruction in a general-purpose operating system. Accordingly, causal relationships between events occurring in short intervals, such as immediately after ignition, can be accurately analyzed, and the efficiency of data analysis after testing can be improved. Brief explanation of the drawing

[0030] FIG. 1 is a block diagram illustrating the overall configuration of a real-time data acquisition and redundant storage system for large-scale system testing according to one embodiment of the present invention. FIG. 2 is a schematic diagram illustrating, in an embodiment of the present invention, an exemplary data exchange structure using shared memory. FIG. 3 is a diagram illustrating an exemplary data processing flow in which a time tag is assigned to sensor data using a time synchronization module according to an embodiment of the present invention, and the data is stored in a second storage device through RTOS-based storage and general-purpose OS-based reordering / packetization. FIG. 4 is a flowchart illustrating a method for real-time data acquisition and redundant storage for large-scale system testing according to an embodiment of the present invention. Specific details for implementing the invention

[0031] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. However, in describing the present invention, descriptions of already known configurations or functions will be omitted to clarify the gist of the present invention.

[0032] The terms used herein are for describing specific embodiments and are not intended to limit the invention. Additionally, the singular form in this specification may include the plural form unless the context clearly indicates otherwise.

[0033] The attached drawings are intended solely to facilitate an understanding of the concept of the present invention and should not be interpreted as limiting the scope of the invention. Additionally, relative thicknesses, lengths, or sizes in the drawings may be exaggerated for convenience and clarity of explanation.

[0034] FIG. 1 is a block diagram illustrating the overall configuration of a real-time data acquisition and redundant storage system for large-scale system testing according to one embodiment of the present invention.

[0035] Referring to FIG. 1, a real-time data acquisition and redundant storage system (100) for large-scale system testing according to one embodiment of the present invention may be configured to store data in parallel through multiple independent storage paths on a single computing device in order to stably store multi-channel real-time data that may occur explosively for a very short period of time, such as during the engine ignition phase in a space launch vehicle test, without interruption or delay.

[0036] Multiple sensors (101) can be distributed at each location of a space launch vehicle test facility (e.g., combustor, turbopump, valve, piping, tank, structure, etc.) and can output multi-channel real-time data by measuring physical quantities such as vibration, pressure, temperature, flow rate, and strain that occur during the test. The sensors (101) can be implemented in various forms, such as analog sensors, digital sensors, sensing modules including signal conditioners, or sensor arrays in which multiple sensors are integrated, and the number of channels and sampling rate can also be set in various ways depending on the purpose of the test.

[0037] A real-time data acquisition and redundant storage system (100) for testing a large system according to one embodiment of the present invention may include a single target computing device including a multi-core central processing unit (CPU) to receive and store multi-channel real-time data output from the sensor (101).

[0038] Here, a single target computing device serves as a core computing node for storing test data and can be configured to allow multiple operating systems to run simultaneously using multiple cores within a single hardware platform (e.g., a single motherboard / processor system). This single-device-based structure structurally avoids the risks of network bottlenecks, delays, and transmission interruptions that may occur in conventional methods where data is transmitted over a network to a separate external computing device to duplicate large amounts of data.

[0039] Inside a single target computing device, a real-time operating system (RTOS) (110) running on a first core and a general-purpose operating system (130), such as Windows, running on a second core may be provided.

[0040] The RTOS (110) is configured to stably perform data storage operations requiring real-time performance and can control multi-channel real-time data flowing in from the sensor (101) to be stored in the first storage device (120) through the first storage path.

[0041] The general-purpose operating system (130) is configured to perform tasks requiring user convenience (e.g., monitoring, providing an operation screen, non-real-time analysis / processing, linking with peripheral devices, etc.), and can also control multi-channel real-time data to be stored in the second storage device (140) through the second storage path according to the core purpose of the present invention.

[0042] Here, the first storage device (120) and the second storage device (140) may be implemented as different physical storage media, such as an HDD, SSD, RAID array, removable storage device, etc.

[0043] Preferably, the first storage device (120) may be provided inside the single target computing device, and the second storage device (140) may be provided outside the single target computing device. In this case, the second storage device (140) is placed in a safe location physically separated from the single target computing device, that is, a location far away from the single target computing device, and may be directly connected to the single target computing device via a communication cable without passing through a network. That is, the general-purpose operating system (130) can transmit and store multi-channel real-time data to the second storage device (140) through a second storage path that does not pass through a network.

[0044] According to one embodiment of the present invention, the first storage path and the second storage path can be configured to operate in parallel on a single target computing device without passing through a network. That is, while the RTOS (110) performs storage on the first storage device (120), the general-purpose operating system (130) also independently performs storage on the second storage device (140), thereby enabling redundant storage that improves data survivability even if a failure occurs in some storage devices or some storage paths in extreme environments such as space launch vehicle testing.

[0045] Meanwhile, according to one embodiment of the present invention, a general-purpose operating system (130) running on a second core can be connected to a monitoring terminal (102) via a network. The monitoring terminal (102) may be placed outside the test site or in a physically separated safety zone and may include a third storage device (103).

[0046] A general-purpose operating system (130) may be configured to transmit multi-channel real-time data to a monitoring terminal (102) via a network, and the monitoring terminal (102) may be configured to store the received data in a third storage device (103). Accordingly, in addition to redundant storage for the first storage device (120) and the second storage device (140) inside a single target computing device, a third storage path for a physically separated external device may be additionally secured.

[0047] In particular, even if a single target computing device is physically damaged due to an accident such as an unexpected explosion or fire during a space launch vehicle test, data that has already been transmitted to an external monitoring terminal (102) via a network and stored in a third storage device (103) can be preserved. Accordingly, according to one embodiment of the present invention, the level of data protection can be further enhanced by combining an external backup storage structure based on physical separation with an internal parallel redundancy storage structure.

[0048] Additionally, the monitoring terminal (102) may be configured to provide a real-time data monitoring screen, display the storage progress status, or output an alarm when an abnormal event occurs, and the data stored in the third storage device (103) may be stored in various formats, such as raw data, time tag-based reordered data, or partial summary data.

[0049] According to one embodiment of the present invention, by combining the simultaneous operation of an operating system with internal parallel storage, loss or delay that may occur during the process of transmitting data to an external device can be minimized. In particular, since the single target computing device of the present invention can operate the operating system separately using multi-core resources, it can operate as a configuration that achieves both the stability of real-time storage operations and user operational convenience.

[0050] Meanwhile, FIG. 1 describes the overall schematic configuration of a real-time data acquisition and redundant storage system (100) for testing a large-scale system according to one embodiment of the present invention, and specific implementations such as a data exchange method between an RTOS (110) and a general-purpose operating system (130) (e.g., shared memory-based exchange, ring buffer structure, pointer-based sequential write / read), a time-based sorting method (e.g., assigning time tags and reordering based on a common reference point), and a core resource allocation method based on data generation amount / storage device load, etc., will be described in more detail with reference to other drawings.

[0051] FIG. 2 is a schematic diagram illustrating, in an embodiment of the present invention, an exemplary data exchange structure using shared memory.

[0052] Referring to FIG. 2, since the real-time operating system (RTOS) (110) running on the first core and the general-purpose operating system (130) running on the second core operate simultaneously within the same physical hardware (single target computing device), necessary data between the two operating systems (e.g., data to be used for display / monitoring / reordering / packet reconstruction, etc. performed by the general-purpose operating system) can be transmitted directly internally without passing through a network.

[0053] To this end, a shared memory (200) is provided in a physical memory area, and the shared memory (200) can be implemented in a ring buffer structure. The shared memory (200) can be configured so that the direction in which the RTOS (110) writes data and the direction in which the general-purpose operating system (130) reads data are clearly separated.

[0054] Specifically, the shared memory (200) may include a write pointer (210) indicating a write location of the RTOS (110) and a read pointer (220) indicating a read location of the general-purpose operating system (130). The RTOS (110) updates the write pointer (210) while sequentially writing multi-channel real-time data (or a part / processed version thereof) to the buffer area of ​​the shared memory (200), and the general-purpose operating system (130) updates the read pointer (220) while sequentially reading the data written to the shared memory (200).

[0055] In this way, by distinguishing the roles of the RTOS (110) as the producer and the general-purpose operating system (130) as the consumer, the data exchange path can be simplified and operation predictability can be improved even in a high-speed data environment.

[0056] Since the ring buffer structure utilizes the physical contiguous space of memory in a circular manner, when the write pointer (210) reaches the end of the buffer, it returns to the beginning of the buffer, allowing writing to continue. Accordingly, the shared memory (200) simplifies buffer management even during long-term continuous operation and minimizes frequent dynamic memory allocation / deallocation. In particular, in environments where a large amount of data is generated explosively during short test intervals, such as space launch vehicle testing, delays may increase if non-deterministic factors such as dynamic allocation or garbage collection are involved; the ring buffer structure of the shared memory (200) can be implemented in a way that reduces such uncertainty.

[0057] Additionally, data exchange in the shared memory (200) is not limited to simply exchanging data byte sequences. According to one embodiment, for each data block (frame) written to the shared memory (200), the RTOS (110) may store at least one integrity verification field, such as a recording time or time tag, a channel identifier, a number of samples, a data type, a checksum, or a CRC. The general-purpose operating system (130) can use this metadata to reliably recognize the boundaries (frame boundaries) of the read data, detect missing reads or duplicate reads, and perform subsequent processing such as reordering or packet reconstruction if necessary. At this time, the placement of the metadata can be implemented in various ways, such as a frame header method, a fixed-length record method, or a separate metadata table method.

[0058] It is desirable that the size (buffer capacity) of the shared memory (200) provide sufficient buffering so that the writing of the RTOS (110) is not interrupted even if temporary processing delays (e.g., user interface load, background tasks, driver call delays, etc.) occur on the general-purpose operating system (130) side. According to one embodiment, the size of the shared memory (200) may be set based on the number of channels, data type (number of bytes), sampling rate, and buffering time, and the buffering time may be set to more than twice the required processing slack time.

[0059] For example, if 2-byte data per channel is acquired at 10,000 samples per second from 1,000 channels and 2 seconds of buffering is to be secured, the minimum capacity of the shared memory (200) can be 1,000 × 2 × 10,000 × 2 = 40,000,000 bytes (approx. 40 MB). Additionally, if a margin of more than double is provided to account for the potential latency of the general-purpose operating system (130), it can be set to approximately 80 MB or more. These settings can be adjusted according to the test environment and data rate, and in the actual implementation, metadata overhead and memory alignment can be additionally reflected.

[0060] Meanwhile, one of the important considerations in a ring buffer structure is to prevent or manage overflow, that is, a situation where the write pointer (210) of the RTOS (110) overtakes the read pointer (220) of the general-purpose operating system (130).

[0061] According to one embodiment, the RTOS (110) can avoid an overflow by continuously monitoring the distance between the write pointer (210) and the read pointer (220), or the remaining buffer capacity, and when the remaining capacity falls below a threshold, reducing the unit of data written to the shared memory (200), limiting the writing of a specific low-priority channel or low-resolution data, or providing a signal (e.g., an interrupt, an event flag) to the general-purpose operating system (130) to induce an increase in the reading speed.

[0062] According to another embodiment, the general-purpose operating system (130) may be configured to record in an event log that a delay has occurred in the read pointer (220), and to mark the data in the delay period as a missing period so that it can be referenced during subsequent analysis. Such policies are optional embodiments for the stable operation of the shared memory (200) and may be appropriately adopted according to the purpose of the test (e.g., priority of preserving raw data, priority of real-time monitoring, etc.).

[0063] In addition, since the two operating systems (110, 130) run independently on different cores, synchronization may be considered to prevent a race condition from occurring during the update process of the write pointer (210) and the read pointer (220).

[0064] According to one embodiment, pointer updates may be configured to be performed as atomic operations, and data written by the RTOS (110) may be configured to be accurately observed by the general-purpose operating system (130) by using a memory barrier or a cache coherency guarantee mechanism. According to another embodiment, to minimize locks, a lock-free ring buffer of a single producer-single consumer (SPSC) model may be applied to suppress latency in a high-speed data environment.

[0065] Additionally, the shared memory (200) can contribute to the stabilization of storage control as well as data exchange between operating systems. For example, if the source of data that the general-purpose operating system (130) stores in the second storage device is configured to be read directly from the shared memory (200), the general-purpose operating system (130) can obtain a relatively consistent input stream based on the data flow acquired and aligned by the RTOS (110).

[0066] In this case, the general-purpose operating system (130) may write the read data to the second storage device after performing reordering according to time tags, frame boundary reconstruction, or bundled storage in file / packet units. This configuration is also applicable to an implementation that performs real-time storage (first storage device) and post-processing / packetization-based storage (second storage device) in parallel within the same single device.

[0067] Additionally, the shared memory (200) is not limited to a single ring buffer and can be divided into multiple ring buffers depending on the implementation. For example, the buffer for high-speed core channels and the buffer for low-speed peripheral channels can be separated, or a buffer for log / state information can be kept separate to differentiate the read priority of the general-purpose operating system (130). Alternatively, independent ring buffers can be configured for each channel group so that the read delay of a specific group does not affect other groups.

[0068] While this partitioning structure may slightly increase the complexity of buffer management, it can be designed to simultaneously satisfy data survivability and real-time monitoring performance depending on the test objective.

[0069] FIG. 3 is a diagram illustrating an exemplary data processing flow in which a time tag is assigned to sensor data using a time synchronization module according to an embodiment of the present invention, and the data is stored in a second storage device through RTOS-based storage and general-purpose OS-based reordering / packetization.

[0070] In space launch vehicle testing, multiple events occur consecutively over short time intervals, such as engine ignition, valve opening and closing, and turbopump operation. In this case, the analysis of causal relationships between each event can largely depend on whether sensors at different locations acquired data at the same time reference. Therefore, simply storing sensor data generated from multiple channels is not sufficient; it is desirable to provide time reference information along with the data so that alignment with the same reference time can be ensured at least in subsequent analysis stages.

[0071] To this end, as illustrated in FIG. 3, a real-time data acquisition and redundant storage system (100) for large-scale system testing according to one embodiment of the present invention may further include a time synchronization module (300). The time synchronization module (300) may be configured to assign a time tag to each sample or each data frame of sensor data.

[0072] The time tag assigned by the time synchronization module (300) may be a value representing relative time or absolute time with respect to a common reference point (e.g., test reference point T0, or the reference time of the system reference clock). The time tag may be assigned on a sample unit of a single channel, or on a frame unit in which samples of multiple channels are grouped for a certain period (e.g., 1ms, 10ms, etc.). Additionally, the time tag may be implemented in a form that includes at least one of a timestamp value, a frame number, a sample counter, and a channel group identifier, and may be designed so that time order reconstruction is possible in a subsequent step regardless of which combination of these is adopted.

[0073] Sensor data with time tags can be processed in the RTOS storage step (310). The RTOS storage step (310) is a path for reliably performing data recording requiring real-time performance, and can be configured so that storage proceeds within a predictable delay range even while sensor data is being input.

[0074] At this time, the RTOS storage step (310) not only stores data containing time tags in the first storage device (corresponding to the first storage path in FIG. 1), but also transmits the data containing time tags to the general-purpose OS so that subsequent processing can be performed on the general-purpose OS side (e.g., transmitted via shared memory / ring buffer), or buffers it in a form accessible to the general-purpose OS. This transmission structure can be implemented through the shared memory (ring buffer) based data exchange structure described in FIG. 2, but FIG. 3 is illustrated as leading to the general-purpose OS reordering / packetization step (320) after the RTOS storage (310) to clarify the time tag-based processing flow.

[0075] The general-purpose OS reordering / packetization step (320) can perform the function of reordering sensor data in chronological order using time tags and reconstructing it in packet (or record / file block) units in a form suitable for storage or subsequent analysis. In a space launch vehicle test environment, there may be cases where the sampling rate differs for each sensor channel, where momentary delays occur in some channels, or where data is collected asynchronously by channel group. In this case, even if the stored raw data is physically recorded in the order of arrival, from an analysis perspective, it is necessary to collect the values ​​of each channel at the same reference point and reconstruct them in the form of a snapshot. By performing this reconstruction based on time tags, the general-purpose OS (320) can mitigate the problem where causal relationship analysis becomes difficult due to a lack of chronological alignment.

[0076] For example, assuming that Channel A (pressure) is acquired at 10 kHz, Channel B (vibration) at 50 kHz, and Channel C (temperature) at 1 kHz, the number of samples per channel differs even for the same 1 ms time interval. The general-purpose OS reordering / packaging step (320) can define a 1 ms unit frame based on the time tag, organize the samples of each channel included in the frame interval into channel-specific records, and then organize and store them as a single packet (or block). As another example, even if a momentary data delay occurs in a specific channel, as long as the time tag is maintained, the general-purpose OS can be configured to insert the delayed sample at the original time position or mark the interval as missing / delayed so that it can be referenced during analysis.

[0077] Packet reconstruction can be implemented in a form that enhances storage reliability and search efficiency. According to one embodiment, a general-purpose OS (320) may include at least one of a time interval start / end, a list of included channels or a channel map, sampling rate information, data length, a CRC / checksum for integrity verification, and a packet sequence number in the packet header. Additionally, channel-specific data may be stored in the packet body as a fixed-length record or a variable-length record. This configuration is advantageous for quickly querying specific events (e.g., pressure spike intervals of T0+0.2 seconds) after storage, or for analysis software to efficiently load data after testing.

[0078] The general-purpose OS (320) can store reordered / packetized data in the second storage device (140). The second storage device (140) can be understood as having the same components as the second storage device (140) of FIG. 1 and can be implemented as a medium physically separated from the first storage device (see 120 in FIG. 1) to enhance the effect of data redundancy. Additionally, the packetized storage performed by the general-purpose OS (320) can have a complementary relationship with raw data-centric storage written to the first storage device.

[0079] In other words, the RTOS side can be configured to reliably store raw or minimally processed data prioritizing real-time performance and continuity, while the general-purpose OS side stores structured data reordered based on time tags, thereby securing stored versions (raw / structured) from different perspectives for the same test. This enables the simultaneous verification of raw data and rapid event analysis during the post-test analysis process.

[0080] Additionally, the general-purpose OS reordering / packetization step (320) can be implemented in various modified forms to ensure storage stability even when processing load increases. For example, methods such as changing the packetization unit according to the test stage (e.g., differentiating packet sizes before and after ignition) to increase the time resolution of the core section, or structuring the channels included in the packet according to channel importance (e.g., core channel priority packet, auxiliary channel lower priority packet), creating an index file at regular time intervals to quickly find the data location of a specific time period, or separating the storage file into a sequential file and a metadata file to improve searchability can be applied. Furthermore, the common reference point that serves as the standard for the time tag may be synchronized at the start of the test or reset based on a specific event (e.g., ignition trigger), and such reference point management logic may be selectively implemented according to system operation requirements.

[0081] Meanwhile, one embodiment of the present invention may be configured to dynamically adjust the number of cores allocated to each operating system in response to changes in data characteristics occurring during testing. This configuration is intended to simultaneously ensure storage stability and processing efficiency in environments where the amount of data generated changes rapidly depending on the test phase, such as space launch vehicle testing.

[0082] Space launch vehicle tests can be divided into phases such as the pre-ignition waiting phase, the rapid combustion phase immediately after ignition, the normal combustion phase, and the termination phase, and the volume of sensor data, frequency of events, and potential for abnormal signals differ in each phase. In particular, during the phase immediately after ignition, data such as pressure, vibration, and temperature can occur at a very high frequency over a short period, and in this case, the raw data rate per second increases rapidly compared to normal. Under these circumstances, if the real-time storage throughput handled by the RTOS exceeds a critical level, the risk of storage delay or buffer overflow may increase.

[0083] To prevent this, according to one embodiment of the present invention, a core allocation control logic may be included within a multicore central processing unit. The core allocation control logic may monitor one or more indicators among the raw data rate occurring per second, the write processing time or average write latency of a first storage device, the load status of a second storage device (e.g., I / O wait time, queue length, write failure rate, etc.), the remaining capacity of a shared memory (ring buffer) or the distance between pointers, CPU utilization, or the frequency of interrupt occurrence:

[0084] As a result of monitoring, if the above indicator exceeds a preset threshold or satisfies specific conditions, the core allocation control logic can be configured to adjust the number of cores allocated to each operating system. For example, if the processing load of the RTOS increases due to a surge in data generation, it can be configured to expand parallel processing threads by allocating additional cores to the RTOS that was previously allocated to one core. Conversely, if the load increases on the general-purpose operating system side due to large-scale packet reconstruction or file writing operations, it can be configured to allocate additional cores to the general-purpose operating system to mitigate storage delays.

[0085] According to one embodiment, core allocation may be implemented by allocating two or more cores to each operating system. For example, if a multi-core central processing unit has an 8-core structure, initially, 2 cores may be fixedly allocated to an RTOS and 2 cores to a general-purpose OS, and the remaining 4 cores may be set as a variable area. If certain conditions are satisfied during testing, some of the cores in the variable area may be configured to be dynamically reallocated to an RTOS or a general-purpose OS. In this case, core reallocation may be performed through a hypervisor layer or a kernel-level control module, and interrupt routing between cores and cache consistency maintenance may be considered.

[0086] Dynamic core control is not limited to simply increasing the number of cores but can be combined with the adjustment of processing priorities. For example, during periods of increased data volume, high priority can be assigned to the RTOS's storage threads, while non-core tasks of the general-purpose OS (e.g., user interface updates, log compression) can be temporarily adjusted to a lower priority. Conversely, during the post-processing phase after the test concludes, more cores can be allocated to packet reconstruction and data alignment tasks on the general-purpose OS side to reduce analysis preparation time.

[0087] According to another embodiment, core dynamic adjustment can be performed in stages according to a predefined test scenario. For example, when a "start ignition signal" is input from the test control system, the core allocation control logic can be configured to automatically allocate additional cores to the RTOS, and to return to the original core configuration when a "stop ignition signal" is input. In this way, test event-based core reconfiguration has the effect of concentrating system resources in the section with the highest probability of data loss.

[0088] FIG. 4 is a flowchart illustrating a method for real-time data acquisition and redundant storage for large-scale system testing according to an embodiment of the present invention.

[0089] Referring to FIGS. 1 and FIGS. 4, in step (410), a real-time operating system (RTOS) (110) can be run on the first core of a multicore central processing unit.

[0090] The RTOS (110) can be configured to provide predictable delay characteristics during the data acquisition and storage process and can operate to prevent storage delays or processing interruptions in situations where a large amount of data is generated intensively over a limited time interval, such as in space launch vehicle testing. For example, the RTOS (110) can be operated in a way that prioritizes tasks responsible for data storage and minimizes the impact of non-deterministic operations (e.g., large-scale UI updates, non-essential background services, etc.) that may occur during testing.

[0091] Next, in step (420), multi-channel real-time data can be stored in the first storage device (120) through the first storage path.

[0092] Here, multi-channel real-time data may include not only measurement data such as pressure, vibration, and temperature generated from multiple sensors (101), but also event logs collected during the test process and status information of control signals, and in this step (420), such data can be controlled to be continuously recorded (stored) in the first storage device (120) by the RTOS (110).

[0093] The first storage path may be configured as an internal path that does not pass through a network, and the first storage device (120) may be implemented as an SSD, HDD, RAID, removable storage device, etc., but the key point is that it is configured to ensure sufficient write performance and stability so that real-time storage is not interrupted. For example, the first storage device (120) may operate in a form optimized for sequential write to be suitable for raw storage of test core data.

[0094] Next, in step (430), a general-purpose OS (130) can be run simultaneously with an RTOS (110) on the second core of a multi-core central processing unit.

[0095] The general-purpose OS (130) is an environment that provides user convenience and peripheral device compatibility, and can be configured to handle additional functions that are burdensome to perform in a real-time operating system, such as providing a monitoring screen, displaying test status, and data rearrangement / packetization. At this time, it is important that the additional functions performed by the general-purpose OS (130) are designed to be executed in parallel on different cores so as not to affect the storage function of the RTOS (110). Therefore, even if a high load occurs momentarily in the general-purpose OS (130) during testing, the real-time storage operation of the first storage path handled by the RTOS (110) can be configured so as not to be hindered by scheduling interference.

[0096] Next, in step (440), multi-channel real-time data can be stored in a second storage device (140) through a second storage path.

[0097] At this time, the general-purpose OS (130) controls the storage of data in the second storage device (140) through the second storage path, and the second storage device (140) is implemented as a storage medium physically separated from the first storage device (120) to ensure the effectiveness of data redundancy. The storage format of the second storage device (140) may be the same raw storage format as the first storage device (120), or it may be a structured storage format based on time tag-based reordering or packetization (reordering / packetization processing described in FIG. 3).

[0098] That is, it can also be implemented in a form that secures different stored copies of the same test data, such as a configuration in which continuous raw data is stored in the first storage device (120) and post-processed packet / record-based data is stored in the second storage device (140). This dual storage structure enables data verification (raw data verification) and rapid event analysis (packet / index-based lookup) to be performed in parallel during the post-test analysis process.

[0099] What is commonly emphasized in steps (410) to (440) of FIG. 4 is that the first storage path and the second storage path are configured to operate in parallel on a single target computing device without passing through a network. That is, in a structure where data acquired from a target device is transmitted to a separate storage device via a network and then duplicated, as in the conventional method, network bottlenecks or delays may occur, but the method of FIG. 4 can structurally eliminate such bottleneck factors through an internal parallel storage structure. As a result, it is possible to provide the effect of lowering the risk of data loss in space launch vehicle testing and improving the reliability of test results and data survivability.

[0100] Meanwhile, the method of FIG. 4 is not limited to the illustrated steps and may include various modified embodiments. For example, the execution order of the RTOS (110) and the general-purpose OS (130) is not necessarily limited to step (410) -> step (430), and may be implemented to perform the storage step after booting the RTOS (110) and the general-purpose OS (130) simultaneously. Additionally, the storage steps (420, 440) may start at exactly the same time, or they may start with a delay so that the second storage begins after the initialization of the general-purpose operating system is completed, and even in the case of such a delayed start, real-time storage for the first storage device (120) may be guaranteed preferentially in the test core section.

[0101] In another embodiment, each storage step (420, 440) may be combined with status monitoring to detect storage failure or storage delay. For example, if the I / O delay of the second storage device (120) increases above a threshold, the general-purpose OS (130) may be configured to maintain storage stability by adjusting the storage unit (e.g., increasing / decreasing the packet size) or adjusting the storage priority (e.g., prioritizing core channel storage). Additionally, if the write delay of the first storage device (120) increases, the RTOS (110) may be configured to maintain real-time storage continuity by changing the buffering strategy, adjusting the depth of the write queue, or simplifying the storage format. Such adaptive control can further reduce the possibility of storage failure in tests with significant environmental changes, such as space launch vehicle testing.

[0102] Additionally, the data stored in each storage stage (420, 440) may be the entirety of the same raw data, but depending on the implementation, the storage policy for some of the data may be different. For example, it is possible to store all raw data in the first storage device (120) and store only core channel-centric data or time tag-based reordered data in the second storage device (140). Conversely, it is also possible to store the entirety of the raw data in the second storage device (140) and store only the minimum set necessary for real-time analysis during testing in the first storage device (120). These variations can be optimized according to storage capacity, write performance, and testing purpose (priority for raw data preservation / priority for analysis efficiency) while maintaining the purpose of redundant storage.

[0103] In conclusion, the redundant storage method of the present invention enables high-reliability redundant storage of space launch vehicle test data by simultaneously running an RTOS (110) and a general-purpose OS (130) on different cores in a multi-core-based single-target computing device, and by allowing each operating system (110, 130) to store data in parallel in different storage devices (120, 140) through a network-non-internal storage path. Accordingly, network bottlenecks and transmission risks can be avoided even in a large-scale data environment, data survivability against storage path / storage device failures can be improved, and the efficiency and reliability of post-test analysis can be enhanced.

[0104] Although the present invention has been described in detail through preferred embodiments, it is obvious to those skilled in the art that the present invention is not limited to the aforementioned preferred embodiments and can be modified and varied in various ways without departing from the spirit and scope of the invention. Accordingly, such modifications or variations should be deemed to fall within the scope of the claims of the present invention. Explanation of the symbols

[0105] 101: Sensor 110: RTOS 120: First storage device 130: General Purpose OS 140: Second storage device 200: Shared memory 210: Write Pointer 220: Read Pointer 300: Time Synchronization Module

Claims

Claim 1 A system for acquiring and redundantly storing multi-channel real-time data output from multiple sensors deployed in a large-scale system test facility, comprising: a single target computing device including a multi-core central processing unit; and includes an operating system that operates on the multi-core central processing unit and controls the multi-channel real-time data to be stored in a first storage device through a first storage path and controls the multi-channel real-time data to be stored in a second storage device through a second storage path; the operating system includes a real-time operating system that operates on the first core of the multi-core central processing unit and controls the multi-channel real-time data to be stored in a first storage device provided inside the multi-core central processing unit through a first storage path, and a general-purpose operating system that operates on the second core of the multi-core central processing unit and controls the multi-channel real-time data to be stored in a second storage device provided outside the multi-core central processing unit through a second storage path; further includes a time synchronization module that assigns a time tag to each data so that all channel data are aligned with respect to a common reference point; the real-time operating system processes the multi-channel real-time data to which the time tag has been assigned by the time synchronization module and stores it in the first storage device; the general-purpose operating system rearranges the multi-channel real-time data in chronological order based on the time tag, and the sampling rate differs for each sensor channel or in some channels In the event that a momentary delay occurs or data is collected asynchronously by channel group, even if the raw data stored in the first storage device is physically recorded in the order of arrival, the data packet is reconstructed by collecting each channel value at a common reference point based on the reordered data and stored in the second storage device, and the multicore central processing unit includes a core allocation control logic, and the core allocation control logic includes the amount of raw data generated per second, the write processing time of the first storage device,A real-time data acquisition and redundant storage system for large-scale system testing, characterized by being configured to monitor one or more indicators of the load status of the second storage device, and to adjust the number of cores allocated to the real-time operating system and the general-purpose operating system, respectively, when the indicator exceeds a preset threshold or satisfies a specific condition as a result of the monitoring. Claim 2 delete Claim 3 A real-time data acquisition and redundant storage system for large-scale system testing, characterized in that, in claim 1, the second storage device is positioned at a location physically separated from the single target computing device and is directly connected to the single target computing device via a communication cable without passing through a network, and the general-purpose operating system transmits and stores the multi-channel real-time data to the second storage device through the second storage path without passing through a network. Claim 4 A real-time data acquisition and redundant storage system for large-scale system testing, characterized in that, in claim 1, the first storage path and the second storage path are configured to operate in parallel on the single target computing device without passing through a network. Claim 5 A real-time data acquisition and redundant storage system for large-scale system testing, characterized in that, in claim 1, the real-time operating system and the general-purpose operating system are configured to exchange multi-channel real-time data through a shared memory set in a physical memory area. Claim 6 A real-time data acquisition and redundant storage system for large-scale system testing, characterized in that, in claim 5, the size of the shared memory is calculated based on the number of channels, data type, sampling rate, and buffering time, and the buffering time is set to be at least twice the required time for real-time data processing. Claim 7 delete Claim 8 delete

Images