A simulation payload data frame generation method for a data transmission protocol

Abstract

The application relates to a simulation load data frame generation method for a data transmission protocol, and belongs to the field of aerospace. According to a package type identifier, a working mode and an excitation engineering value, a main parameter table, a covering parameter table and a working mode mapping decision tree are read, the excitation engineering value is converted and encoded, a load byte buffer is updated in combination with covering description and mode flag bits, a binary simulation frame is generated, and after being interpreted through a homologous analysis link, the excitation engineering value is compared, and a consistency comparison report is output. The application solves the problems that usable data transmission test data cannot be obtained before positive sample joint test, and a ground monitoring and offline analysis system cannot be connected and debugged in advance, and the excitation engineering value can be directly compared and verified with homologous analysis readback.

Description

Technical Field

[0001] This application relates to the field of aerospace technology, and in particular to a method for generating simulated payload data frames for data transmission protocols. Background Technology

[0002] During satellite development, especially before prototype testing, it is difficult to obtain real or near-real data transmission test data suitable for ground-based software integration. However, ground-based telemetry, tracking, command and control, data interpretation, fault diagnosis, and scientific data processing software still require mode discrimination, bit field extraction, and engineering quantity conversion of the onboard data transmission binary frames. Existing software methods for generating test data mainly include random filling, fixed template playback, and original code-level assignment. Random filling, assuming a correct frame structure, fills the payload data field with random bytes; fixed template playback cyclically outputs captured real frames or manually constructed hexadecimal templates; and original code-level assignment allows specifying the written values ​​for each parameter at the original code level. For multi-mode payloads with local differences in payload layout under different operating modes, the above methods either maintain a complete parameter configuration separately for each operating mode or directly output data unrelated to the operating mode.

[0003] The existing technology has at least the following problems: the load data generated by random filling and fixed template playback, after bit field extraction and processing relationship conversion, lacks expected reference for the resulting engineering values. Moreover, the template is strongly bound to the protocol version, making it difficult to cover range boundaries and state switching as needed, and it is impossible to determine the correctness of the parsing at the parameter semantic layer. The original code-level assignment requires engineers to manually reverse calculate the physical quantity into the original code according to the processing relationship, which is labor-intensive and error-prone. The original code input of the simulation and the engineering value output by the parsing are in different semantic domains, and manual conversion is still required during comparison. It is impossible to directly answer whether the known engineering values ​​are consistent after being read back through the entire parsing link. Maintaining complete parameter configuration for each working mode makes the maintenance cost increase linearly with the number of modes, and the generated data is difficult to be uniquely identified by the downstream mode discrimination link. The simulation and parsing are prone to splitting. Summary of the Invention

[0004] This application provides a method for generating simulation load data frames for data transmission protocols, which can solve the problems of difficulty in obtaining usable data transmission test data before the prototype test and the inability to connect and debug the ground monitoring and offline analysis systems in advance. It also makes the simulation input and analysis output from the same source, and the engineering values ​​can be directly compared and read back, while reducing the maintenance cost of multi-mode parameter tables.

[0005] To achieve the above objectives, this application provides a method for generating simulated payload data frames for data transmission protocols, comprising the following steps: S1. Determine the package type identifier and working mode of the load to be simulated, and obtain the excitation engineering values; S2. Based on the package type identifier and working mode, read the corresponding main parameter table, overriding parameter table and working mode mapping decision tree; S3. The excitation engineering values ​​of each parameter are written into the main parameter table according to the declared path order, after being converted and encoded by the inverse formula, to generate the basic load byte buffer. S4. Read each line of coverage description from the coverage parameter table and record the valid coverage description lines; overwrite each valid coverage description line to the corresponding base payload byte buffer; S5. Traverse the working mode mapping decision tree and write back the mode flag corresponding to the selected working mode to the basic payload byte buffer. S6. Generate and output binary simulation frames based on the basic payload byte buffer.

[0006] This application overcomes the problems of input-output semantic domain splitting and the need for manual inverse calculation of the original code in existing random filling, template playback, and original code-level assignment methods. It adopts the same processing relationship and coefficient declaration as the forward interpretation method, and reverse-encodes the known engineering input into a basic load byte buffer. This ensures that the simulation excitation and analytical output are in the same engineering value semantic domain. Combined with deterministic excitations such as fixed values, count values, waveform values, and enumerated values, and with the cooperation of deterministic excitations such as fixed values, count values, waveform values, and enumerated values, configuration errors are directly manifested as visible deviations between the input and readback sequences. These errors can be judged item by item, intuitively, and automatically. Furthermore, it is generated purely by software, eliminating the need for a hardware simulator. Through byte-level segmented coverage, multiple working modes can be generated by simply adding small segments to the main table's common parameters and pressing the mode to generate the correct loads. It supports automatic rotation based on time, thus overcoming the problem that existing methods are only oriented towards a single fixed frame structure and cannot simulate multi-mode switching, and reducing maintenance costs, so that protocol iteration only requires configuration changes without recompiling; by writing back the mode flag bit through the decision tree constraint chain, the mode discrimination bit is uniquely associated with the configuration path, overcoming the problem that existing simulation data is difficult to be uniquely identified by downstream; by sharing the same coverage segment metadata semantics with simulation coverage and the inverse and forward formulas being reversible, the engineering values, coverage boundaries and mode identifiers are consistent in simulation, real-time monitoring and offline parsing, overcoming the problem of the split between simulation and parsing, and providing a repeatable and closed-loop data shortage mitigation solution for the development of ground systems under the condition of lacking real spaceborne data. Attached Figure Description

[0007] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0008] Figure 1This is a flowchart of a method for generating simulated payload data frames for data transmission protocols according to an embodiment of this application; Figure 2 This is a flowchart of the simulation load data frame generation and reverse analysis symmetric processing according to the embodiments of this application; Figure 3 This is a structural diagram of the main parameter table and the coverage parameter table provided according to the embodiments of this application; Figure 4 This is a schematic diagram of forward merging and simulation coverage symmetry processing provided according to the embodiments of this application; Figure 5 This is a schematic diagram of the working mode mapping decision tree and bit field write-back according to the embodiments of this application; Figure 6 This is a schematic diagram of the RS-422 laser channel AOS packaging according to an embodiment of this application; Figure 7 This is a schematic diagram of end-to-end readback verification and generation, i.e., self-testing, provided according to an embodiment of this application. Detailed Implementation

[0009] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0010] like Figure 1 , Figure 2 As shown in the figure, this application provides a method for generating simulated payload data frames for data transmission protocols, including the following steps: S1. The user selects the package type identifier and working mode of the load to be simulated, and configures the excitation engineering values; S2. Based on the package type identifier and working mode, read the corresponding main parameter table, overriding parameter table and working mode mapping decision tree; S3. The excitation engineering values ​​of each parameter are written into the main parameter table according to the declared path order, after being converted and encoded by the inverse formula, to generate the basic load byte buffer. S4. Read each line of coverage description from the coverage parameter table and record the valid coverage description lines; overwrite each valid coverage description line to the corresponding base payload byte buffer; S5. Traverse the working mode mapping decision tree and write back the mode flag corresponding to the selected working mode to the basic payload byte buffer. S6. Generate and output binary simulation frames based on the basic payload byte buffer.

[0011] Furthermore, such as Figure 3 , Figure 4 As shown, the parameter table represents the spreadsheet workbook file (i.e., an Excel file) used for parsing each load, and the worksheet represents a page (i.e., a workbook sheet) within the parameter table file. The parameter table is named according to the rule "packet type identifier_mode name_base / override.xlsx", where base is the main parameter table storing the definition of common parameters for the entire frame, and override is the coverage parameter table describing local differences according to the working mode. When the user selects which load and which mode data to simulate on the interface, the system locates the corresponding parameter table and program entry point according to "packet type identifier_mode name". The working mode mapping decision tree describes the multi-level mode discrimination path using a nested structure of field offsets, bit numbers, and branch codes. It should be noted that the use of spreadsheet (Excel) files to carry the main parameter table and coverage parameter table is only a preferred implementation method. Its essence is a structured configuration that carries parameter definitions, processing formulas, coefficients, and coverage segment metadata. In other embodiments, the same semantics can also be carried in structured configuration forms such as CSV, JSON, XML, or databases, and version management and format verification can be combined to improve maintainability and fault tolerance in automated testing and continuous integration scenarios.

[0012] In a specific embodiment, a laser scientific data transmission packet (2686 bytes) is received. The main parameter table (e.g., 1FFCDAEB_2686-Scientific Data Transmission Frequency Stabilization Mode-base.xlsx) stores the full frame definition of the default modes such as frequency stabilization. The coverage parameter table corresponds one-to-one with the mode name, and the file name contains the mode name placeholder. The mode main worksheet name is the same as the mode name. The coverage segment metadata includes at least: target coverage path sequence, whether secondary parsing is required, the name of the corresponding secondary parsing sub-worksheet, and the total length field. For example, the path sequence "W174~W211", secondary parsing valid, secondary parsing sub-worktable "weak light phase-locked data", and segment length 38 bytes indicate that the content of this sub-table will replace the 174~211 byte range of the main frame; the path sequence of the secondary parsing sub-worktable starts from local zero, with W0 aligned to the 174th byte of the main frame; multiple non-contiguous overlays can be defined in the same mode main table; the total length is automatically inferred from the path sequence start and end word order when the default is used; the system also pre-compiles the working mode mapping decision tree and establishes the "mode name - bit field constraint chain" index for subsequent mode bit write-back and downstream mode discrimination to share. The working mode mapping decision tree is implemented as a multi-level node structure. Each non-leaf node records the field byte offset, start bit sequence number, bit width, and encoded values ​​of each branch of a discrimination bit field. Each branch points to the next level node. The leaf node records the working mode name. During the initialization phase, the system generates this structure by parsing the mode declaration of the self-overwriting parameter table line by line, and simultaneously establishes indexes in two directions: "mode name → bit field constraint chain" and "discrimination bit value → mode name". This allows mode bit write-back and downstream mode discrimination to be queried in constant time, without having to repeatedly traverse the configuration file when generating each frame.

[0013] Furthermore, the excitation engineering values ​​include fixed engineering values, count values ​​that are deterministically incremented according to frame sequence number, periodic waveform values ​​that are deterministically changed according to time, or enumerated values; the count values ​​are used to determine the integrity of frame sequence through the continuity of the output sequence, and the periodic waveform values ​​are used to determine the correctness of bit width and sign bit processing through the coverage of parameter range by the output sequence.

[0014] The excitation configuration interface allows testers to directly set the excitation type for each parameter using physical quantities: fixed value (e.g., temperature parameter set to 25), count value (incrementing by a known step size according to frame number), periodic waveforms such as sine or ramp (systematically sweeping the parameter range), enumerated value (switching within the set of legal states), and checksum (automatically maintaining intra-frame consistency). For example, if a temperature parameter is configured with a fixed value of 25, the parser should strictly read back 25. If a frame count parameter is configured with a count value of step size 1, the parser output should be a continuously increasing sequence from the initial value to the maximum count value. When the count value reaches the preset maximum value, the next frame automatically resets to zero and starts incrementing again, presenting a periodic sawtooth waveform. If an unexpected jump occurs in the parser output sequence (i.e., not incrementing by step size 1 or not recounting to zero), it is determined that a frame loss or bit field misalignment has occurred. If a phase parameter is configured with a sine waveform, the parser output should reproduce the waveform. Clipping or sign flipping at both ends of the range indicates a bit width or sign bit configuration error. This judgment method does not require manual reverse calculation of the original code, and the correctness verification is intuitive and can be completed automatically by a script.

[0015] Furthermore, the operating mode is determined in any of the following ways: Users can directly select a single working mode from the interface; The user pre-configures multiple working modes and their respective durations and execution order. During program execution, the program automatically switches between the configured multiple working modes according to the elapsed simulation time to simulate the working mode switching over time during long-term continuous operation; and locates the corresponding coverage parameter table and bit field constraint chain according to the currently determined working mode name.

[0016] Furthermore, when S3 and S4 write to the basic load byte buffer, the initial value of the parameter or the excitation engineering value of each row of the main parameter table or the overlay parameter table is converted by the inverse formula, the engineering quantity is calculated in reverse and encoded into the original code, the parameter encoding value is obtained and written into the corresponding bit field in the path order. The inverse formula conversion employs a hierarchical strategy for the various processing formulas declared in the parameter table, and does not require the processing formulas to be mathematically global bijections. It is used for reverse analytical symmetric processing: for linear scaling formulas, the engineered value is converted to its original code using algebraic inverse solution; for modulo formulas, among multiple original code equivalence classes that ensure consistent readback of the forward processing formula, a standard representative original code is selected and written into the bit field; for piecewise linear formulas, the linear relationship within each segment is inversely solved after the engineered value is segmented, or numerical inversion is used when segment boundaries are difficult to determine; for conditional branch formulas, after determining the branch using the original code of other encoded parameters or the engineered value, the selected branch expression is inversely solved or numerical inversion is used; for combined derived formulas, when the expression does not reference the parameter's own symbol, the parameter is identified as a derived parameter without inverting its own original code; for custom expression, polynomial, or interpolation formulas without closed analytic inversion, the same processing formula as the forward interpretation is reused. Numerical solution of the equation within the physically reachable legal code range of this parameter. , where there is no sign The range of valid code values ​​for each bit field is The range of valid code values ​​for a signed n-bit two's complement is: Since the bit width of any field is finite, its legal code value range is a finite set of integers. Therefore, the above numerical inversion can be completed by bounded search on this finite set, and there is no risk of convergence. The monotonic processing formula is solved by bisection. For polynomial, interpolation or user-defined expression processing formulas, the inverse mapping lookup table from the engineering value to the original code is pre-calculated and cached during the system initialization stage. This makes the encoding in the real-time generation stage degenerate into a constant-time table lookup, so that the real-time requirements are still met when generating tens of thousands of frames of data continuously.

[0017] This allows non-bijective processing relationships such as modulo, segmentation, condition, polynomial, and user-defined expressions in the real or integer fields to still achieve verifiable encoding from engineering values ​​to original code under bit-field constraints.

[0018] In one specific embodiment, the processing formula for a certain 8-bit signed parameter P is declared as a user-defined expression. The simulation engineer configured the engineering input for this parameter as follows: .because The formula is not a monotonic function over the integer field, nor does it have a globally unique mathematical inverse mapping. Therefore, the simulation side cannot and does not need to determine whether the original code is what the user subjectively expects. 2 or +2. This embodiment employs a layered inverse conversion strategy: within the valid code value range determined by the parameter bit width and data type [ Within [128, 127], the same processing formula as the forward interpretation is reused. Numerical solution of equations When multiple feasible original codes are detected, the goal is not to recover a unique historical original code, but rather to select a representative original code from the candidate set that ensures consistency in the forward formula readback and write it into the bit field—for absolute value formulas, when Prioritize non-negative roots After the source code is encoded into the payload according to the path sequence, the parser then decodes it. ,and Consistency within the quantization tolerance is required to meet the verifiable simulation requirements. It should be noted that the correctness determination at the parameter semantic layer of this invention applies to parameters whose processing formulas are reversible or employ deterministic excitations (fixed values, count values, periodic waveform values, enumerated values). For such parameters, the correctness of the parsing can be uniquely determined. For processing formulas that are mathematically non-bijective, such as absolute values, this invention does not claim to recover a unique historical original code; it only guarantees that the generated original code, after being read back through a shared link, is consistent with the excitation engineering value within the quantization tolerance. When the sign or direction of a parameter has independent physical semantics, its excitation should be directly configured at the original code layer or the processing formula should be declared as reversible to avoid discrepancies between the selected specification representing the original code and the expected physical state.

[0019] Furthermore, the coverage description includes the target coverage path sequence, whether it is a secondary parsing flag, the name of the secondary parsing worktable, the total length field, and the initial value; the target coverage path sequence is the byte location number of the parameter row in the frame or segment, which is the absolute byte address of the whole frame in the main worktable of the coverage mode of the coverage parameter table, and the local address within the segment in the secondary parsing worktable, starting from zero.

[0020] Furthermore, the effective coverage description line includes a segmented coverage description line and a direct coverage parameter line. When the secondary parsing flag is valid, it indicates a segmented coverage description line, which means that the internal structure of a continuous byte range is defined by the referenced secondary parsing worksheet. When the secondary parsing flag is invalid, it indicates a direct coverage parameter line, which means that a single parameter is written directly in the absolute path order of the entire frame.

[0021] Furthermore, the coverage parameter table includes a main pattern worksheet and a secondary parsing sub-worksheet; the secondary parsing sub-worksheet (segment table) is a page referenced by a certain coverage description line and used to define the internal parameter structure of a continuous byte range; The main worksheet of the mode declares the parameter rows that need to be overwritten in the basic payload byte buffer line by line according to the actual absolute path order of the whole frame (e.g., W80~W88); The secondary parsing worksheet declares the parameters within a segment according to the local path sequence starting from W0; and performs coverage on each valid coverage description line: For parameter rows that are directly overwritten, i.e. do not require secondary parsing, the parameter encoding value is replaced and written to the corresponding byte position in the basic payload byte buffer according to its absolute path order of the whole frame. For example, when a parameter is located at W80, its encoding value is directly replaced with the content at the 80th byte of the basic payload byte buffer, without referencing the secondary parsing worksheet. For segmented overlay description lines, i.e. those requiring secondary parsing, the secondary parsing worksheet referenced by them generates a fixed-length segment byte stream in relative path order starting from W0. This segment byte stream is written in place to the byte range specified by the absolute path order of the entire frame in the base payload byte buffer. For example, when declaring W80~W88, W0 in the segment is aligned to the 80th byte of the main frame, and bytes 80 to 88 are written in sequence. For multiple discontinuous segmented coverage description lines, segment byte streams are generated sequentially according to the row order of the pattern master worksheet and written to the corresponding intervals in place; when the coverage parameter table corresponding to the current pattern does not exist, or the pattern master worksheet has no valid coverage description lines, the process degenerates into not performing coverage, only retaining the basic payload byte buffer generated by the master parameter table, without blocking subsequent encapsulation and verification.

[0022] In a specific embodiment, in the first stage, a 2686-byte basic payload is generated according to the main working table of the master parameter table and the known engineering input given by the user. In the second stage, if a coverage parameter table exists in the current mode, valid coverage rows are read one by one, and fixed-length segment data is generated by the segment table under the same parameter table semantics, and replaced and written into the corresponding interval of the basic payload. For example, 38 bytes of "weak light phase-locked data" are written into the interval 174~211, and can also be written into the interval 368~405. In the third stage, after the coverage is completed, the mode discrimination bit (such as the relevant bit field of the 89th byte) is written back according to the decision tree constraint chain, and then the outer frame is entered. If the coverage parameter table is missing, the second stage is skipped, and the master table frame is directly output without blocking the link. Other multi-mode inertial transmission packets follow the same structure, only the master parameter table file, the coverage parameter table template and the mode mapping bit field offset are different.

[0023] For each row of the parameter table, the system reads the initial value column or the time-varying engineering value given by the excitation configuration, uses the same processing relationship and coefficients as the forward interpretation in the parameter table, completes the encoding in the reverse order of bit field extraction, and then writes it into the buffer according to the path order; the simulation side does not maintain an independent formula library, and the parameter semantics come entirely from the parameter table declaration; therefore, changes in parameters within the coverage segment will simultaneously affect the forward merging table and the simulation coding path, ensuring consistency between the two paths.

[0024] After the entire table is traversed, the buffer length is constrained by the maximum path sequence value and the segment length in the overriding metadata. In the CAN hybrid simulation path, most packets are materialized according to the XML protocol description, while packets specified to be overridden by signature are replaced by a B-segment worksheet defined in Excel, which is symmetrical to the parsing side.

[0025] Preferred, such as Figure 5 As shown, step S5 further includes the following steps: The mode flag is written back from the root node of the working mode mapping decision tree to the leaf node where the target mode name is located. The discrimination bit fields at each level along the way and their corresponding branch coding values ​​are collected to form a bit field constraint chain. The branch coding values ​​are written to the corresponding bits of the basic payload byte buffer according to their specified field offset and bit number, with the high bit first. This makes the values ​​of the generated frame on these discrimination bits correspond one-to-one with the selected working mode, so that the downstream program can identify the current mode by reading these discrimination bits.

[0026] In a specific embodiment, the root node is located at bits 5 and 4 of byte 89; the first bit is further divided under the branch "00", and the code "1" corresponds to "scientific data transmission phase-locked mode"; constraint chains are collected from root to leaf, and written back sequentially after the segment is covered, retaining the contents of other bit fields of the same byte; the write-back order is arranged after the coverage segment is written to avoid accidental modification of the discrimination bit during coverage; in this embodiment, the mode bit is located in byte 89 of the common area of ​​the main table, and the coverage segment is located in the difference area such as byte 174, and the two do not conflict with each other.

[0027] Preferably, step S6 further includes the following step: Copy the main worksheet of the main parameter table to obtain the merged parameter table; For each valid coverage description line, if it is a segmented coverage description line, the coverage interval is calculated according to the absolute path order of the whole frame and the original parameter line falling into the interval in the merged parameter table is deleted, and the parameter line in the secondary parsing worksheet is added to the merged parameter table; if it is a direct coverage parameter line, the corresponding parameter line is replaced in the merged parameter table according to the absolute path order of the whole frame. The forward interpretation side parameter table segmentation and merging and the simulation side byte-level segmentation and overlay of S4 adopt the same coverage segment metadata semantics, row type identification rules, interval start and end calculation rules and secondary parsing worksheet selection rules.

[0028] Preferred, such as Figure 6 , Figure 7 As shown, step S6 further includes the following steps: The payload bytes of the base payload byte buffer are embedded into the outer structure of the transport protocol to generate a binary simulation frame; When the packet type identifier corresponds to the RS-422 channel, the payload bytes are loaded into the BPDU data field of the AOS transmission frame. When the packet type identifier corresponds to the CAN data bus channel, the data transmission protocol description and Excel overlay packet definition determine whether it is necessary to assemble subframes before encapsulating them into an AOS frame. When the packet type identifier corresponds to other types of bus channels, the corresponding payload encapsulation is performed according to the protocol rules of that channel. Among them, the encapsulation of the CAN data bus channel is performed according to the following rules: the frame identifier ID, data length code DLC and data field byte number of each CAN subframe are determined according to the data transmission protocol description and Excel overlay packet definition. The payload byte buffer is divided into several data field segments according to the data field capacity of each subframe. The bytes in the segment are arranged according to the byte order specified by the protocol (high byte first or low byte first). The last segment that is less than one data field is padded according to the protocol. After each CAN subframe is assembled according to the frame identifier ID and sequence number, it is then encapsulated into the BPDU data field of the AOS transmission frame, thus achieving symmetry with the CAN subframe splitting logic on the parsing side.

[0029] After the binary simulation frame is generated, it is sent to the parsing link with the same source as the simulation for engineering value interpretation and a consistency comparison is performed with the excitation engineering value. When the engineering value readback is consistent with the excitation engineering value and the mode discrimination result is consistent with the mode of the excitation engineering value, it is determined that the comparison is consistent; if the engineering value readback is inconsistent with the excitation engineering value or the mode discrimination result is inconsistent with the mode of the excitation engineering value, it is determined that the comparison is inconsistent. If the comparison is inconsistent, the main parameter table and the overriding parameter table configuration are automatically checked, and the process returns to step S1 to be re-executed until the comparison is consistent. After successful comparison and verification, indicating that the simulation program is running correctly, the binary simulation frames are sent to both the external real-time monitoring system and the offline parsing system for data transmission simulation. The real-time monitoring system interprets the data online as a real-time data stream, while the offline parsing system interprets it in batches as a post-processing file. Thus, through comparison and verification and the dual-path distribution mechanism, the correctness of the simulation load data is ensured, while also meeting the multi-scenario application requirements for real-time monitoring and post-processing analysis.

[0030] Furthermore, the excitation engineering values ​​configured in S1 are effective in both the main parameter table generation stage of S3 and the coverage segment generation stage of S4, so that the engineering value sequence of the parsing link re-interpretation in S6 can be compared parameter by parameter with the sequence of excitation engineering values.

[0031] In one specific embodiment, the RS-422 laser channel fills the 2686-byte payload (including the check bytes in the parameter table) into the BPDU of the virtual channel 010101 as is, and then assembles it into a 1024-byte AOS frame; the interface supports multi-mode selection and configuration of duration, frequency, and execution order; the system rotates the current mode according to the elapsed simulation time, dynamically switches the coverage table and mode mapping write-back constraints, and outputs a long-term multi-condition data stream.

[0032] In a specific embodiment, testers configure known engineering inputs (fixed values, count values, or sine waveforms) for the "scientific data transmission phase-locked loop mode," generating a data file containing 1024-byte AOS frames. The first path is sent to the real-time monitoring system, where the mode is determined by mapping to the same source mode. A 2686-byte payload is decoded using the phase-locked loop mode merging parameter table. The monitored values ​​are compared with the excitation engineering values ​​to confirm consistency between parameters inside and outside the coverage segment and mode labels. For parameters configured as count values, the monitoring curve should show a continuously increasing broken line, allowing for visual identification of frame drops or crosstalk. The second path is sent to the offline analysis system: frame cutting, channel segmentation, packet interception, mode determination, parameter decoding, and L1A product synthesis are performed. The decoded table is compared with the excitation engineering values, the mode name with the selected mode on the interface, and the product specifications with expectations. For count and waveform parameters, the consistency between the output sequence and the theoretical sequence is verified line by line using the script. Both paths share the same protocol configuration and the same set of master and coverage tables. Any errors in coverage metadata or mode mapping will be exposed simultaneously at the simulation, monitoring, and offline levels. This embodiment demonstrates that the present invention transforms the simulation system into a built-in regression probe of the ground software system: its value lies not in "how to find the inverse formula", but in the ability to generate verifiable frames that can be identified by the same source link and interpreted consistently even under conditions of data shortage.

[0033] The present invention has the following advantages or beneficial effects: 1. Solves the problem of missing test data before prototype testing: Existing publicly available technologies are mostly geared towards traditional telemetry downlinks, and there is no publicly available configurable and retrievable verification simulation solution for large data transmission packet lengths and multi-working-mode payloads; This invention can generate binary simulation frames of data transmission that can be identified and reinterpreted by the same source analysis link in a purely software manner before prototype testing, providing repeatable test data for the early connection and commissioning of ground real-time monitoring and offline analysis systems, and avoiding the high cost of hardware simulators and the investment in multiple buses and multiple boards; 2. Supports multi-mode data generation and dynamic mode switching: This invention generates more than ten working modes with correct payload structures by using a segmented maintenance method of master parameter table plus mode-overriding parameter table. Users can configure the duration and execution order of each mode, and the system automatically switches between multiple working modes according to the elapsed simulation time, outputting a long-term multi-condition continuous data stream. This simulates the working mode switching over time in actual satellite operation, solving the problem that existing methods can only generate data for a single fixed frame structure and cannot simulate multiple modes and dynamic mode switching. 3. Low maintenance cost and fast adaptation: Without copying the entire frame parameter table, the segmented maintenance method, which uses a single common parameter table in the main table and covers small differences by mode, significantly reduces the maintenance cost of multi-mode data transmission parameter tables and the scope of modification during protocol iteration; protocol changes only require modification of the parameter table and configuration file without recompiling the main program, which can quickly adapt to high-frequency protocol iteration scenarios; 4. Intuitive verification and easy interpretation: Simulation excitation and analytical output reside in the same engineering value semantic domain. Testers can directly configure excitations using engineering values ​​(physical quantities). Combined with deterministic excitation types such as fixed values, count values, waveform values, and enumeration values, the correctness of the analysis can be determined item by item, intuitively, and automatically at the parameter semantic layer: fixed values ​​verify conversion relationships, count values ​​verify frame sequence continuity and sampling integrity, waveform values ​​verify full-range bit domain and sign processing, and enumeration values ​​verify state discrimination. Any configuration errors in bit offset, bit width, sign, or processing formula are directly manifested as visible deviations between the input sequence and the readback sequence, eliminating the need for manual inversion of the original code. 5. Consistent caliber, verifiable readback, and highly practical: The parameter table segmentation and merging on the forward interpretation side and the byte-level segmentation coverage on the simulation side share the same set of coverage segment metadata semantics. The inverse formula conversion encoding on the simulation side and the forward processing formula on the parsing side are reversible to each other, and the mode discrimination bit is written back through decision tree constraints, ensuring that the engineering values, coverage boundaries, and mode identifiers are consistent across the simulation, real-time monitoring system, and offline parsing system, avoiding the caliber split of "one set of simulation, another set of parsing". The binary simulation frame generated in this way can directly drive the independent debugging of subsystems and the full link supplementation and connection test, and can also be used as the input of the same source parsing link (offline parsing system, real-time monitoring system) for re-interpretation and engineering value readback comparison. Before the prototype joint test and under the condition of scarce real satellite data, it provides a data shortage mitigation solution that can be debugged in advance, is repeatable, and auditable for the development of ground systems. Furthermore, the present invention can also incorporate a self-testing module on the simulation side: using the same processing formula as the forward decoding, a decoding path independent of the encoding path is constructed. Without relying on external parsing links, the consistency between the original code level and the engineering value level is self-tested parameter by parameter and a difference report is exported. Thus, implementation-level defects such as inverse / forward formulas not being mutually inverse, type encoding and decoding asymmetry, or bit order misalignment can be exposed on the generation side, further improving the verifiability of parsing symmetry and development efficiency.

[0034] In the embodiments provided in this application, it should be understood that the disclosed methods can be implemented in other ways. For example, the division of the method steps described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple steps may be merged, split, or the execution order may be adjusted, or some steps may be omitted or not executed. Furthermore, the data transfer or control relationship between the steps can be direct or indirect through intermediate modules or interfaces, and may take the form of program calls, message passing, or other methods.

[0035] In addition, each step of the method described in the various embodiments of this application can be implemented by computer program instructions; the computer program instructions can be loaded onto a general-purpose computer, a special-purpose computer or other programmable data processing equipment, so that when the instructions are executed on the computer or other programmable equipment, the corresponding function of the method described in the embodiments of this application is realized.

[0036] If the above methods are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0037] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating simulated payload data frames for data transmission protocols, characterized in that, Includes the following steps: S1. Determine the package type identifier and working mode of the load to be simulated, and obtain the excitation engineering values; S2. Based on the package type identifier and working mode, read the corresponding main parameter table, overriding parameter table and working mode mapping decision tree; S3. The excitation engineering values ​​of each parameter are written into the main parameter table according to the declared path order, after being converted and encoded by the inverse formula, to generate the basic load byte buffer. S4. Read each line of coverage description from the coverage parameter table and record the valid coverage description lines; overwrite each valid coverage description line to the corresponding base payload byte buffer; S5. Traverse the working mode mapping decision tree and write back the mode flag corresponding to the selected working mode to the basic payload byte buffer. S6. Generate and output binary simulation frames based on the basic payload byte buffer.

2. The method for generating simulation payload data frames for data transmission protocols according to claim 1, characterized in that, The excitation engineering values ​​include fixed engineering values, count values, periodic waveform values, or enumerated values.

3. The method for generating simulation payload data frames for data transmission protocols according to claim 1, characterized in that, The operating mode is determined in any of the following ways: Users can directly select a single working mode from the interface; The user pre-configures multiple working modes and their respective durations and execution order. When the program runs, it automatically switches between the configured multiple working modes according to the elapsed simulation time to simulate the working conditions of working modes switching over time during long-term continuous operation. And locate the corresponding coverage parameter table based on the currently determined working mode name.

4. The method for generating simulation payload data frames for data transmission protocols according to claim 1, characterized in that, When S3 and S4 write to the basic load byte buffer, the initial value of the parameter or the excitation engineering value of each row of the main parameter table or the overlay parameter table is converted by the inverse formula, the engineering quantity is calculated in reverse and encoded into the original code, the parameter encoding value is obtained and written into the corresponding bit field according to the path order.

5. The method for generating simulation payload data frames for data transmission protocols according to claim 4, characterized in that, The coverage description includes the target coverage path sequence, whether it is a secondary parsing flag, the name of the secondary parsing worktable, the total length field, and the initial value; the target coverage path sequence is the byte location number of the parameter row in the frame or segment, which is the absolute byte address of the whole frame in the main worktable of the coverage mode of the coverage parameter table, and the local address within the segment in the secondary parsing worktable, starting from zero.

6. The method for generating simulation payload data frames for data transmission protocols according to claim 5, characterized in that, The effective coverage description line includes a segmented coverage description line and a direct coverage parameter line. When the secondary parsing flag is valid, it indicates a segmented coverage description line, which means that the internal structure of a continuous byte range is defined by the referenced secondary parsing worksheet. When the secondary parsing flag is invalid, it indicates a direct coverage parameter line, which means that a single parameter is written directly in the absolute path order of the entire frame.

7. The method for generating simulation payload data frames for data transmission protocols according to claim 5, characterized in that, The coverage parameter table includes a main mode worksheet and a secondary parsing sub-worksheet; the secondary parsing sub-worksheet is a page referenced by a certain coverage description line and used to define the internal parameter structure of a continuous byte range. The main worksheet of the mode declares the parameter rows that need to be overwritten in the basic payload byte buffer line by line according to the actual absolute path order of the whole frame; The secondary parsing worksheet declares each parameter within a segment according to the local path sequence; it performs coverage on each valid coverage description line: For directly overriding parameter lines, replace the corresponding byte positions in the base payload byte buffer with the parameter encoding values ​​according to their absolute path order for the entire frame; For the segmented overlay description line, the secondary parsing worksheet referenced by it generates a fixed-length segment byte stream in the relative path order starting from W0, and writes the entire segment byte stream in place to the base payload byte buffer. For multiple discontinuous segmented coverage description lines, segment byte streams are generated sequentially according to the row order of the mode master worksheet and written to the corresponding intervals in place; when the coverage parameter table corresponding to the current mode does not exist, or the mode master worksheet has no valid coverage description lines, it degenerates into not performing coverage, and only retains the basic payload byte buffer generated by the master parameter table.

8. The method for generating simulation payload data frames for data transmission protocols according to claim 7, characterized in that, S5 also includes the following steps: The mode flag is written back from the root node of the working mode mapping decision tree to the leaf node where the target mode name is located. The discrimination bit fields at each level along the way and their corresponding branch coding values ​​are collected to form a bit field constraint chain. The branch coding values ​​are written to the corresponding bits of the basic payload byte buffer according to their specified field offset and bit number, with the high bit first.

9. The method for generating simulation payload data frames for data transmission protocols according to claim 8, characterized in that, S6 also includes the following steps: Copy the main worksheet of the main parameter table to obtain the merged parameter table; For each valid coverage description line, if it is a segmented coverage description line, calculate the coverage interval according to the absolute path order of the whole frame and delete the original parameter line that falls into the interval in the merge parameter table, and add the parameter line in the secondary parsing worksheet to the merge parameter table. If the parameter row is to be directly overwritten, the corresponding parameter row is replaced in the merged parameter table according to the absolute path order of the entire frame.

10. The method for generating simulation payload data frames for data transmission protocols according to claim 9, characterized in that, S6 also includes the following steps: The payload bytes of the base payload byte buffer are embedded into the outer structure of the transport protocol to generate a binary simulation frame; When the packet type identifier corresponds to the RS-422 channel, the payload bytes are loaded into the BPDU data field of the AOS transmission frame; when the packet type identifier corresponds to the CAN data bus channel, the data transmission protocol description and Excel overlay packet definition determine whether it is necessary to assemble subframes before encapsulating them into an AOS frame; when the packet type identifier corresponds to other types of bus channels, the corresponding payload encapsulation processing is performed according to the protocol rules of that channel. After the binary simulation frame is generated, it is sent to the parsing link with the same source as the simulation for engineering value interpretation and a consistency comparison is performed with the excitation engineering value. When the engineering value readback is consistent with the excitation engineering value and the mode discrimination result is consistent with the mode of the excitation engineering value, it is determined that the comparison is consistent; if the engineering value readback is inconsistent with the excitation engineering value or the mode discrimination result is inconsistent with the mode of the excitation engineering value, it is determined that the comparison is inconsistent. If the comparison is inconsistent, the main parameter table and the overriding parameter table configuration are automatically checked, and the process returns to step S1 to be re-executed until the comparison is consistent. After the comparison and verification were passed, it was determined that the simulation program was running correctly. The binary simulation frames were then sent to the external real-time monitoring system and the offline parsing system for data transmission simulation. The real-time monitoring system interpreted the data online in real-time data stream mode, while the offline parsing system interpreted the data in batches in post-processing file mode.

Images