Heterogeneous constellation instruction packet automatic classification numbering record and recall method and system

Abstract

The application belongs to the technical field of spaceflight, and discloses a heterogeneous constellation instruction package automatic classification number recording and re-calling method and system. The application introduces a pre-trained language model in the field of satellite instruction management in view of the problem that different satellite instruction parameters have different names and formats, and through joint training of two tasks of a mask language model and parameter name-value matching, the heterogeneous parameter names of each satellite are respectively encoded after the standard concepts in the ontology are encoded, and then similarity comparison is performed, so that synonymous parameters with different names can be unified to the standard concept node without manually writing analysis scripts one by one, and the automation problem of heterogeneous instruction standardization into a database is fundamentally solved, and the efficiency of heterogeneous instruction into a database in a large-scale constellation is improved.

Description

Technical Field

[0001] This invention belongs to the field of aerospace technology, specifically relating to a method and system for automatically classifying, numbering, recording, and retrieving heterogeneous constellation command packets. Background Technology

[0002] The constellation encompasses a variety of heterogeneous platforms, including visible light imaging satellites, infrared remote sensing satellites, and synthetic aperture radar satellites. Satellite types are becoming increasingly diverse, with significant differences in orbital altitude, payload type, communication protocols, and command formats. This heterogeneity of mega-constellations has become a major trend in the development of current space-based systems.

[0003] To address the differences in command formats, parameter naming, and encoding rules among different satellite manufacturers and payload types, operators must write parsing scripts for each satellite, based on the interface control files, to parse hexadecimal code streams or XML-formatted commands into recognizable parameters. They then interpret the meaning of each parameter according to its manual definition and input it into the system. Command generation also relies on manual operation; operators must consult manuals to select parameters item by item and assemble binary packages. Regarding command classification and storage, existing systems mostly use simple file directories or database tables to classify and store commands according to satellite model or time sequence.

[0004] The inconsistent command formats and parameter naming conventions, coupled with the lack of a universal parsing mechanism that can automatically adapt to different satellite command formats without manual customization, result in extremely low efficiency in standardizing and storing heterogeneous commands. As the constellation grows and new satellites are continuously added, manual maintenance costs rise sharply. Furthermore, the lack of a unified classification and numbering system for similar commands across different satellites prevents the effective association and reuse of historical command knowledge, forcing operators to consult manuals and configure each command item individually when faced with new tasks.

[0005] To address the aforementioned issues, this invention proposes a method and system for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packets. Summary of the Invention

[0006] To address the aforementioned problems in the prior art, the present invention aims to provide a method and system for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packets.

[0007] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows: The method for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packages includes: Different formats of historical instructions are parsed into key-value pairs. A pre-trained language model is used to automatically align the heterogeneous parameter names to the standard ontology concept, forming a standardized instruction document that is stored in the database. Based on this, a database containing historical instruction embedding vectors is established. When a new instruction is received, it is converted into an embedding vector using a language model and matched with the prototype vector of an existing pattern in the database. If the match is successful, the new instruction is assigned to an existing pattern and missing parameter information is automatically filled in. If the match fails, the new instruction is stored in the database as a sample of a new pattern to expand the database. When an operator generates instructions by selecting them step by step, a unique identification code is assigned to the generated instructions according to the hierarchical coding system in the standardized instruction document, and an instruction package that can be annotated is output.

[0008] Preferably, the pre-training of the language model adopts a joint training of two tasks: masked language model and parameter name-value matching. During the parameter name alignment process, multiple aliases of each standard concept in the ontology are sent to the language model to generate representation vectors and stored in the vector library. The cosine similarity between the representation vector of the new parameter name and the representation vectors of all standard concepts in the vector library is calculated. When the similarity reaches or exceeds the first preset threshold, the alignment is automatic. When the similarity is lower than the first preset threshold, manual confirmation is pushed.

[0009] Preferably, the hierarchical coding system includes a four-level hierarchical structure, where the first level is the payload identifier, the second level is the working mode, the third level is the core feature parameters, and the fourth level is the optional adjustment parameters; the unique identification code is generated by concatenating the codes at each level and the timestamp sequence number and then extracting the first 16 characters.

[0010] Preferably, the prototype vector is the bitwise average of all historical instruction embedding vectors in each existing working mode in the database; similarity matching uses cosine similarity calculation, and when the similarity reaches or exceeds the second preset threshold, it is determined to be a successful match, and the missing parameter values ​​are filled in by weighting the K-nearest neighbor algorithm according to the inverse Euclidean distance; when the similarity is lower than the second preset threshold, it is determined to be a failed match, and a new mode is automatically created and a new code is assigned.

[0011] Preferably, when the operator selects the generation command step by step, after selecting the target satellite, payload and working mode in sequence, all parameters defined by the mode are listed; after the operator fills in the parameters, a local format verification is performed, and after the verification is passed, the command package is assembled according to the binary command template; the local format verification includes checking for exceeding the limit of parameter value range and checking for mutual exclusion between different parameters in the same working mode.

[0012] Preferably, before parsing historical instructions and forming standardized instruction documents, the process also includes the step of constructing a multi-dimensional constraint knowledge graph for heterogeneous constellations: defining entity types and relationship types between entities, extracting entities and relationships from historical instruction documents and satellite design manuals and storing them in a graph database, associating each constraint relationship with verification rules to form a constraint rule library; after the operator fills in the parameters and performs local format verification, converting the currently generated instruction parameters into graph database query statements, retrieving relevant constraint rules in the knowledge graph and executing judgment logic to complete global constraint reasoning.

[0013] Preferably, the global constraint reasoning includes energy conflict detection, thermal control conflict detection, and link conflict detection; energy conflict detection involves detecting whether the total power consumption of the current instruction and other planned instructions within the same time window exceeds the satellite's power supply capacity; thermal control conflict detection involves detecting whether the predicted temperature of the equipment after the execution of the current instruction exceeds the equipment's rated maximum operating temperature; link conflict detection involves detecting whether the communication frequency band or channel number used by the current instruction is occupied by other planned instructions; if a conflict is detected, a resolution suggestion is generated based on the priority rules in the knowledge graph.

[0014] This invention also discloses an automatic classification, numbering, recording, and recall system for heterogeneous constellation instruction packages, including: a knowledge construction and semantic alignment module, used to uniformly parse historical instructions of different formats into key-value pairs, use a pre-trained language model to automatically align each heterogeneous parameter name to a standard ontology concept, form a standardized instruction document stored in a database, and establish a database containing historical instruction embedding vectors accordingly; The multimodal prediction module is used to convert new instructions into embedding vectors using a language model when they are received. The vectors are then matched with the prototype vectors of existing patterns in the database. If the match is successful, the new instruction is assigned to an existing pattern and missing parameter information is automatically filled in. If the match fails, the new instruction is stored in the database as a sample of a new pattern to expand the database. The instruction generation and verification module is used to assign a unique identification code to the generated instruction according to the hierarchical coding system in the standardized instruction document when the operator generates instructions by selecting them step by step, and outputs an instruction package that can be annotated.

[0015] Preferably, the pre-training of the language model adopts a joint training of two tasks: masked language model and parameter name-value matching. During the parameter name alignment process, multiple aliases of each standard concept in the ontology are sent to the language model to generate representation vectors and stored in the vector library. The cosine similarity between the representation vector of the new parameter name and the representation vectors of all standard concepts in the vector library is calculated. When the similarity reaches or exceeds the first preset threshold, the alignment is automatic. When the similarity is lower than the first preset threshold, manual confirmation is pushed.

[0016] Preferably, the prototype vector is the bitwise average of all historical instruction embedding vectors in each existing working mode in the database; similarity matching uses cosine similarity calculation, and when the similarity reaches or exceeds the second preset threshold, it is determined to be a successful match, and the missing parameter values ​​are filled in by weighting the K-nearest neighbor algorithm according to the inverse Euclidean distance; when the similarity is lower than the second preset threshold, it is determined to be a failed match, and a new mode is automatically created and a new code is assigned.

[0017] Beneficial effects 1. This invention addresses the problem of inconsistent naming and formatting of satellite command parameters. It introduces a pre-trained language model into the field of satellite command management. Through joint training of a masked language model and parameter name-value matching, the heterogeneous parameter names of each satellite are encoded with standard concepts in the ontology and then compared for similarity. This eliminates the need for manually writing parsing scripts for each satellite, thus unifying synonymous parameters with different names to standard concept nodes. This fundamentally solves the problem of automating the standardization and storage of heterogeneous commands, and improves the efficiency of storing heterogeneous commands in large-scale constellations.

[0018] 2. This invention performs similarity matching between new instructions and existing patterns. When a match is successful, missing parameters are automatically filled in. When a match fails, a new pattern is automatically created and the database is expanded. This allows the system to continuously accumulate knowledge and expand the database during use. The operational experience implicit in historical instructions is effectively preserved and reused, avoiding the inefficiency of traditional methods that require reconfiguration from scratch for new tasks.

[0019] 3. This invention establishes a four-level hierarchical coding system, which classifies and encodes standardized instructions according to payload identifier, working mode, core feature parameters and optional adjustment parameters, and generates a unique identification code. This enables the effective association and rapid retrieval of similar instructions from different satellites and payloads, providing a standardized data organization scheme for centralized management of instructions from large-scale heterogeneous constellations.

[0020] 4. This invention integrates automatic instruction parsing and database entry, unified encoding and storage, intelligent matching and reuse, interactive generation and annotation, and execution feedback updates into a complete data flow chain, with each link reinforcing the others. Parsing and database entry provides the data foundation for encoding and matching, matching and reuse provides knowledge support for instruction generation, and execution feedback provides continuous impetus for database updates. This chain enables the system to continuously accumulate and solidify knowledge during use, forming a continuously optimized closed-loop system, avoiding the problems of fragmented links and ineffective accumulation of historical knowledge in traditional methods. Attached Figure Description

[0021] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system module diagram of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments. It should be understood that the specific embodiments described herein are merely for explaining the invention and are not intended to limit the scope of protection of the invention.

[0023] Example 1 Please see Figure 1 As shown, this embodiment provides a method for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packages, including the following steps: S0. Construct a multi-dimensional constellation constellation constellation knowledge graph; Before executing the formal command processing flow, a multi-dimensional constraint knowledge graph covering satellite platform, payload equipment, energy system, thermal control system and mission type is constructed to provide structured knowledge support for subsequent command verification, conflict detection and pattern reasoning.

[0024] Specifically, the allowed entity types and their relationships in the knowledge graph are defined. Entity types include satellites, payloads, operating modes, parameters, equipment, and constraint rules. The following six types of relationships are defined and stored between entities: If a payload is mounted on a satellite platform, a payload-satellite relationship is established; if a device is powered by a power system, a power supply relationship is established; if a device's temperature is regulated by a thermal control device, a heat dissipation relationship is established; if two payloads or two operating modes cannot be activated simultaneously, a mutual exclusion relationship is established; if the execution of a certain operating mode or command depends on the existence of another device or state, a dependency relationship is established; if there is a fixed execution order constraint between two actions (e.g., attitude adjustment must be completed before the payload is powered on), a sequential relationship is established.

[0025] Based on this, entities and relationships are extracted from historical instruction documents, satellite interface control files, and satellite design manuals, and stored in a graph database in the form of (head entity, relationship, tail entity) triples to form a basic constraint knowledge graph.

[0026] For each constraint relationship in the graph, it is associated with a corresponding validation rule to form a constraint rule library. Each rule in the constraint rule library is stored in a database in a structured data format (such as JSON or XML), containing the entity identifiers, parameter types, comparison methods, and triggering conditions involved in the rule. During validation, the corresponding rule is read from the database and parsed and executed. The types of validation rules include at least the following two categories: The parameter value range over-limit check is as follows: Each parameter has its allowed value range recorded in the knowledge graph. When the input control is generated in the interactive interface, the selectable values ​​or input prompts are automatically limited according to the value range. After the user fills in the parameter value, an over-limit check is performed. If the filled value exceeds the range of the parameter recorded in the knowledge graph, the check will be prompted that the verification failed.

[0027] Parameter mutual exclusion verification: Specifically, possible mutually exclusive combinations between different parameters in the same working mode are predefined in the form of a configurable verification rule file; this check is automatically performed when the instruction is generated, and if a mutual exclusion relationship is detected, the verification fails.

[0028] The entities, parameters, and judgment conditions involved in the verification rules are all stored corresponding to the nodes and relationships in the knowledge graph. When performing various verifications, the corresponding constraint definitions are read from the knowledge graph according to the instruction parameter content and the judgment is executed.

[0029] In addition, an incremental update mechanism for the knowledge graph is set up. Specifically, whenever a new pattern is determined and added to the database in a subsequent step, it automatically checks whether the payload, working mode and parameter combination involved in the new pattern already have corresponding nodes in the graph. If they do not exist, the corresponding entity is automatically created and the association relationship between it and the existing entity is established, so as to ensure that the knowledge graph expands synchronously with the standardized database without manual maintenance.

[0030] S1. Automatic parsing of heterogeneous historical instructions and semantic alignment of parameter names To unify the parsing of historical commands in different formats, a protocol adapter was deployed at each satellite ground station. This protocol adapter is a data parsing middleware that is configured according to the interface control files of different satellites and is used to uniformly convert raw command data in different formats into key-value pair format.

[0031] For instructions in hexadecimal code stream format, they are parsed byte by byte into "parameter name=value" key-value pairs according to the field offset, bit width, and value mapping table defined in the interface control file; for instructions in XML or JSON format, all terminal nodes are directly extracted and converted into key-value pairs using XPath (a path language for locating XML document nodes) or JSONPath (a query language for locating JSON document nodes).

[0032] All key-value pairs are organized by instruction, with each instruction corresponding to a set of key-value pairs.

[0033] Based on this, the payload operating mode ontology is defined using a YAML file. In this YAML file, each concept records its concept name, globally unique identifier, and all known aliases in key-value pairs, and is organized in a nested manner according to the hierarchy of satellite identifier, payload type, operating mode, and characteristic parameters. Each standard concept is assigned a globally unique identifier and records all its known aliases.

[0034] A BERT model was pre-trained on a large-scale historical command corpus, which consisted of historical command records accumulated from various satellite ground stations, covering command formats from at least three different satellite platforms, totaling no fewer than 10,000 commands. The training corpus was transformed from historical command key-value pairs, with each command beginning with the [CLS] marker and ending with the [SEP] marker. Training employed a two-task joint optimization: first, a masking language model, which randomly masked 15% of the markers in a sequence, enabling the model to predict the masked original word based on context; second, a parameter name-value matching task, which randomly selected 50% of the command sequences and replaced a parameter value with a random value. The model then used the [CLS] vector through a fully connected layer for binary classification to determine whether the parameter-value matching relationship in the entire command was correct. The losses from the two tasks were summed and backpropagated to update all parameters of the Transformer. The model was trained until the perplexity on the validation set stabilized, and then saved.

[0035] After model training, automatic semantic alignment of parameter names is performed. Specifically, multiple aliases for each standard concept in the ontology are fed into the BERT model, and the positional average of the output vectors corresponding to the [CLS] position is taken as the fixed representation vector of that standard concept and stored in the vector library. For any newly parsed parameter name, the [CLS] vector is also taken, and the cosine similarity with the representation vectors of all standard concepts in the vector library is calculated one by one. If the highest similarity reaches or exceeds a first preset threshold (preferably 0.85), the parameter name is automatically aligned to the corresponding standard concept. If it is below the first preset threshold, it is pushed to the manual confirmation interface, where the operator annotates the corresponding standard concept and then enters it into the ontology.

[0036] After alignment, each instruction is stored as a four-layer standardized JSON document containing satellite identifier, payload type, operating mode, and characteristic parameter values, and then stored in a MongoDB database.

[0037] S2. Natural language instruction intent parsing based on a large language model; While parsing historical instructions, a parallel natural language input channel is also provided. Operators can enter task description text in the natural language input box on the interface, such as "perform 0.5-meter resolution optical imaging of the region at 120 degrees east longitude and 35 degrees north latitude".

[0038] A large language model is used as the intent parsing engine. This large language model employs a general pre-trained generative large language model and runs in a locally deployed manner to ensure data security. The user's input natural language description, along with the constraint rules and entity information relevant to the current task from the constructed knowledge graph, is used to construct prompt words, which are the input text of the large language model. These prompt words contain four parts: task description, output format requirements, knowledge base constraint information, and the user's original description, separated by delimiters. These parts are then fed into the large language model, which is required to output structured parsing results in JSON format, including target payload type, operating mode, core parameters and candidate values, target region coordinates, etc.

[0039] The parsing results from the large language model are fused and verified with the semantic alignment results from BERT. Specifically, for each parameter name parsed by the LLM, its existence in the ontology is confirmed using the BERT vector library; for parameter values, their domain in the knowledge graph is confirmed. If both verifications pass, the process proceeds to the next step; if either fails, a prompt message is returned requiring user confirmation or correction. After successful fusion verification, the parsing results are passed to the pattern matching process in step S5. Some parameter values ​​can be pre-populated into the interactive interface in step S6, reducing the operator's input workload.

[0040] S3, Four-level hierarchical statistical induction and fixed-length coding allocation The BERT model traverses all standardized instructions in the database and automatically summarizes four levels of classification. The criteria for each level are as follows: Level 1 L1 is the load identifier, which is the content of the load identifier field in the instruction; Level 2 L2 is the working mode, which is the content of the working mode field under the same load; Level 3 L3 is the core feature parameter, which is the set of parameters that appear more than a preset threshold (80% of the total number of instructions under this mode in this embodiment); Level 4 L4 is the optional adjustment parameter, which is the set of parameters that appear less than or equal to the threshold under the same working mode.

[0041] A fixed-length code is assigned to each possible value at each level. Each code value uses a semantically meaningless, incrementing sequence of numbers, starting from 1 and increasing sequentially, ensuring that each possible value within each level receives a unique code. Specifically, level L1 occupies 2 bytes (16 bits), level L2 occupies 1 byte (8 bits), and levels L3 and L4 each parameter occupies a variable-length code consisting of a 1-byte identifier plus a 2-byte numerical value. A cascaded hash table is constructed using the payload identifier and operating mode as a combined key to store the list of optional parameters for L3 and L4 under that mode, as well as the value range of each parameter.

[0042] For each instruction, when generating a unique instruction identifier, the selected L1, L2, and L3 parameter identifiers are sequentially concatenated with the numerical sequence, followed by an 8-digit timestamp and a 4-digit sequence number. The first 16 hexadecimal characters of this string are taken as the instruction's UID. If the first 16 characters after concatenation are duplicated, a 4-digit random number is added after truncation for disambiguation to ensure the uniqueness of the UID.

[0043] S4. Automatic parsing of new satellite interface control files and autonomous construction of instruction templates; For newly connected satellites, the system automatically reads the new satellite's interface control file. This file is a command format definition file issued by the satellite developer and is usually provided in the form of an Excel spreadsheet, XML Schema, or structured text. It contains definitions of frame structure, field offsets, bit widths, and value mapping relationships for each command type. Information such as frame header and trailer identifiers, check field types and positions, offsets and bit widths of each data field, byte order, enumerated value mapping tables, and value range constraints are extracted from this file.

[0044] A directed acyclic graph (DAG) attribute graph for the instruction template is constructed, with each field as a node and the nesting, ordering, and dependency relationships between fields as edges. In this attribute graph, node attributes include field name, data type (integer, floating-point, enumeration, etc.), bit width, offset, and byte order; edge attributes include relationship type (nested, ordered, dependent). This attribute graph is then input into a trained graph neural network to extract the structural feature vector of the satellite instruction template. The network is trained using supervised learning with historical satellite ICD attribute graphs and their corresponding template structural feature vectors as training samples until the validation set accuracy reaches a preset threshold (90% in this embodiment).

[0045] Based on the cosine similarity between the structural feature vector and the structural feature vector of existing satellite templates in the database, a search is performed, and the most similar existing template is recommended as the initial configuration. The operator can preview the field mapping results of the candidate template on the interface, select the most suitable one or make fine adjustments before confirming. The system will then associate and store the template with the four-level coding system of step S3, completing the entry of the new satellite instruction template into the database.

[0046] S5. Pattern matching for new instructions, missing parameter completion, and automatic creation of new patterns. When a new instruction packet is received, it is parsed into key-value pairs and concatenated into a text sequence in the same way as in step S1. This sequence is then fed into the trained BERT model, and the 768-dimensional output vector at the [CLS] position is taken as the embedding vector of the instruction. Each existing working mode node in the database stores the bitwise average of all historical instruction embedding vectors for that mode as the prototype vector for that mode. The cosine similarity between the new instruction embedding vector and all mode prototype vectors is calculated, and the highest value is taken.

[0047] If the highest similarity reaches or exceeds the second preset threshold (preferably 0.875), the new instruction is assigned to the working mode corresponding to that highest similarity. At this point, the list of required parameters defined for that mode is read and compared one by one with the existing parameters of the current instruction to identify missing parameters. For each missing parameter, a query vector is formed using the existing parameters of the current instruction. K nearest neighbors (preferably K = 5) are retrieved from the historical instruction database of that mode using Euclidean distance. For continuous parameters, the missing parameter is filled in using a weighted average of the inverse distances of the nearest neighbors; for discrete parameters, the missing parameter is filled in using a weighted voting method based on the inverse distance, i.e., the discrete value with the highest cumulative weighted inverse distance is used as the filling result. After completion, a pop-up window prompts the operator to confirm before the instruction is entered into the database.

[0048] If the highest similarity is below 0.875, it is automatically identified as a new pattern. A parameter definition table is generated based on the existing parameter names parsed from the current instruction. Parameters with specific values ​​are labeled as L3 core parameters, and those not appearing are labeled as L4 optional parameters. The new pattern is automatically named using the payload type directly extracted from the parsing results plus an incrementing number. The instruction embedding vector is stored as the prototype vector of the new pattern in the prototype library. A new L2 code is assigned to the new pattern in the cascaded hash table. A new pattern node is created in the graph database and the current instruction is attached. After operator confirmation, the entire new process is completed.

[0049] S6, four-level linked interface interaction, knowledge graph constrained reasoning and binary instruction package generation; The interactive interface adopts a four-level linkage design. After the operator selects a target satellite, the payload list of that satellite is loaded and displayed; after selecting a payload, the cascaded hash table constructed in step S3 is queried to display a list of available working modes; after selecting a working mode, all L3 core parameters and L4 optional parameters defined for that mode are listed, and each parameter automatically generates an input control with a range indicator based on the value range recorded in the knowledge graph.

[0050] After the operator enters the parameters, a local format validation is performed: it checks whether the parameter values ​​exceed the limits, and whether there are predefined mutually exclusive relationships between different parameters in the same working mode.

[0051] After local validation passes, all parameters of the current instruction package are further converted into graph database query statements (preferably Cypher query language). All constraint rule nodes related to the current instruction parameters are retrieved along the relational path in the graph database. The judgment logic corresponding to each rule is executed sequentially, and the result is returned, thus completing the global constraint reasoning. The reasoning covers three types of conflict detection: Energy conflict refers to detecting whether the total power consumption of the current command and other planned commands within the same time window exceeds the satellite's power supply capacity, and this is determined when the command is generated. Thermal control conflict is determined after the temperature prediction in step S7 is completed. This involves detecting whether the predicted temperature of the device after the current instruction is executed exceeds the rated maximum operating temperature of the device or whether the heat dissipation power of the thermal control device is less than the heat dissipation power of the device. Link conflict detection involves checking whether the communication frequency band or channel number used by the current instruction is occupied by other planned instructions, and this is determined when the instruction is generated.

[0052] If a conflict is detected, a resolution suggestion is generated based on the priority rules in the knowledge graph. These priority rules are stored as separate rule nodes in the knowledge graph, containing the rule type (user priority, task priority, security priority) and ranking weight. When multiple instructions conflict, the higher-priority instructions are retained, and the lower-priority instructions are adjusted or delayed, according to their ranking weight from highest to lowest.

[0053] The resolution suggestions include adjusting the execution time window, reducing the power level, or changing the load. Operators can view conflict details and resolution suggestions on the interface, and after selecting to adopt the suggestion, the system will automatically adjust the parameters and re-verify, or they can manually modify the suggestions and re-trigger the verification.

[0054] After conflict resolution, the operator clicks on overhead estimation, invokes the prediction service in step S7 to calculate the total energy consumption, power of each state, temperature change curves, and risk reference values ​​for this command execution, and displays them in real time. After confirmation of generation, a unique command identification code is generated according to the method in step S3, and the command template configuration generated for the satellite in step S4 is read. According to the start bit, bit width, byte order, and enumeration value mapping defined in the template, each parameter value is filled into the specified position of the binary frame one by one, assembling a complete binary command package that can be directly uploaded.

[0055] S7. Instruction overhead prediction based on multimodal fusion; The historical telemetry database stores the measured power value, temperature time-series data of each key temperature measurement point, and satellite status context information for each command execution in the payload's working state, categorized by the payload's operating state.

[0056] For a new command packet, the duration of each state is determined based on its parameters. The state sequence and duration are read from the satellite command template. Historical samples with similar parameters to the command are retrieved from the historical telemetry database. The similarity is measured by the cosine similarity of the command embedding vectors obtained in step S5, and only samples with a similarity greater than 0.7 are retained. If no similar samples are found, an error message is displayed indicating that prediction is not possible.

[0057] The predicted power for this state is given by the weighted average formula: in, To predict power, Let be the cosine similarity of the i-th historical sample. This is the measured power of the sample. This represents the total number of samples with a similarity greater than 0.7.

[0058] The total energy consumption prediction for the entire instruction packet is equal to the sum of the products of the predicted power and duration of each state: in, The number of states. For the first Predicted power for each state, For the first The duration of each state.

[0059] The 90th percentile of the power values ​​in the sample set is used as the risk reference value. Specifically, similar samples are sorted in ascending order of power value, and the normalized cosine similarity weight of each sample is accumulated sequentially until the accumulated weight first reaches or exceeds 0.9. The power value of the current sample is then used as the risk reference value. For temperature prediction, the five historical temperature sequences with the highest similarity are selected, aligned with the current command status timeline, and the inversely weighted average of the similarity is calculated. The prediction interval is set at ±2 standard deviations of the predicted value.

[0060] Building upon this foundation, multimodal fusion prediction is further introduced as an enhancement method. For semantic modality, the new instruction embedding vector generated in step S5 is used as the semantic feature. For temporal modality, the retrieved historical power and temperature time-series data are subjected to multi-scale convolution using one-dimensional convolutional kernels of three different sizes (3, 5, and 7 time steps, respectively), with 64 kernels at each scale to capture local variation features at different time scales. The global semantic representation and temporal feature vector are concatenated and then weighted using a set of learnable fusion weights, initially set to 0.5 and automatically optimized through backpropagation during model training. Based on the fusion features, the predicted power, total energy consumption, and confidence intervals for each operating state, the predicted temperature change curve and its prediction interval, and the equipment health status trend score are output. The results of the pure numerical similarity weighted method are also displayed on the interface as reference values ​​for operator comparison.

[0061] S8, Instruction Packet Format Verification and Uploading The newly generated binary instruction packet undergoes three format checks. First, the UID is extracted and queried in the database to confirm its uniqueness. Then, the binary packet is reverse-parsed according to the satellite instruction template to extract all parameter values, which are compared one by one with the original values ​​entered by the operator to ensure correct assembly. Next, the packet length, frame header / footer, and checksum are verified to be correct according to the communication protocol configuration of different satellites. The checksum algorithm is defined according to the interface control file of each satellite, including CRC checksum, XOR checksum, and cumulative checksum, etc., and the corresponding checksum algorithm is automatically selected based on the satellite configuration.

[0062] After all verifications pass, the command packet is transmitted to the target satellite via the satellite-to-ground link. The ground telemetry system monitors the satellite in real time for command reception confirmation signals and execution start flags. If no confirmation is received within a preset timeout period (preferably 10 seconds), a retransmission is automatically triggered, up to a maximum of 3 retransmissions. If all 3 retransmissions fail, an alarm is issued and manual intervention is requested.

[0063] S9. Execution feedback and incremental learning updates; After the command is executed, extract the complete telemetry data for this operation, and calculate the actual total energy consumption, the actual power of each state, and the actual temperature sequence of each temperature measurement point.

[0064] If the absolute value of the energy consumption prediction error divided by the actual total energy consumption does not exceed 10%, the statistical average value of the corresponding state in the historical database is updated by exponential moving average. That is, the new statistical average value is equal to 90% of the original average value plus 10% of the current observation value. At the same time, the current execution record is added to the historical sample set as a new sample.

[0065] For temperature prediction errors, the greatest common divisor of the sampling periods of the predicted curve and the actual curve is taken as the unified resampling interval. If the resampling interval exceeds 200ms, the temperature data set is discarded. The root mean square error (RMSE) of the two curves after resampling is calculated. If the RMSE does not exceed 2K, the current temperature sequence is directly entered into the database; if it exceeds 2K, it is marked as an abnormal sample and the operation and maintenance personnel are notified.

[0066] When an anomaly is triggered, a preliminary root cause diagnosis is automatically performed: the parameter combination of the anomaly command is associated with the knowledge graph for querying, similar historical anomaly records are found, parameter differences and telemetry differences are compared to generate a difference report, and possible fault location is given.

[0067] If manual investigation confirms that the anomaly is caused by a systematic deviation, i.e., a deviation caused by persistent and regular factors such as performance degradation of payload equipment over time, seasonal changes in orbital environmental parameters, and long-term drift of satellite platform status, then the incremental learning mechanism is triggered. The abnormal sample is marked as a "difficult sample" and stored in the database. This type of sample (i.e., the abnormal sample whose deviation between the predicted value and the actual value exceeds the temperature RMSE>2K threshold) does not directly participate in the model update, but is accumulated and stored. When the accumulated amount reaches a preset number (50 in this embodiment), the recalculation of the mode prototype vector in step S5 is triggered (difficult samples are counted with 2 times the weight). At the same time, the difficult sample is added to the fine-tuning dataset of the multimodal fusion prediction model in step S7, and the fusion model is incrementally fine-tuned at regular intervals.

[0068] If, after manual investigation, the cause of the anomaly is confirmed to be an occasional factor (such as single-event upset, transient interference, etc.), the sample will be marked as a "noise sample" and stored in the database for query and auditing purposes, but will not be included in the model update, in order to avoid occasional outliers contaminating the accuracy of the prediction model.

[0069] S10. Continuous optimization of instruction generation strategy based on reinforcement learning The instruction generation process in step S6 is modeled as a Markov decision process, which assumes that the current state of the satellite (including information such as battery level, temperature, attitude, and mission queue) fully contains all the historical information needed to influence future decisions. Given the current state, future decisions are independent of earlier historical states.

[0070] In this Markov decision-making process, the state is defined as the current satellite state and the parameters of the task to be performed; the action is defined as the selectable working mode and the values ​​of each parameter; the reward comprehensively considers the task completion rate, energy efficiency, temperature change, and health loss, specifically: A positive reward is given when the task is completed after the instruction is executed; no reward is given if the task is not completed. Simultaneously, the reward is discounted based on actual energy consumption, with lower energy consumption resulting in a higher reward. A penalty is imposed for the highest temperature rise during execution, with a heavier penalty for a higher temperature rise. Penalties are also imposed for equipment health deterioration, with a heavier penalty for greater deterioration. All the above rewards and penalties are weighted and summed according to preset weighting coefficients to obtain a comprehensive evaluation index, which serves as the reward value for this decision.

[0071] Based on the historical generation records from step S6 and the execution feedback data from step S9, the policy network is trained offline. This policy network takes the current state representation vector (256 dimensions) as input and the Q-value vectors of each candidate action as output. The network structure consists of two Transformer encoder layers (each with four attention heads) and one fully connected output layer, with a total number of parameters not exceeding 5 million to ensure that the inference speed meets the requirements of real-time interaction. The Q-value represents the expected cumulative reward after taking a certain action given the current satellite state; this value is used to evaluate the merits of each candidate working mode and parameter combination.

[0072] A "Smart Recommendation" button is added to the interactive interface in step S6. After the operator clicks it, they input the current status and task parameters into the policy network. The network outputs the recommended working mode and the values ​​of each parameter, and displays the expected reward score for the recommended action. The operator can choose to adopt all the recommended parameters with one click, or modify some parameters themselves after referring to the recommended values.

[0073] Periodically fine-tune the policy network using proximal policy optimization (PPO) based on newly added telemetry feedback data, with the pruning hyperparameter set to 0.2 and the learning rate set to 3 × 10⁻⁶. -5The optimizer uses Adam, with a batch size of 64. After each policy update, the new policy is compared and evaluated with the old policy on the validation set. If the average reward of the new policy is improved by more than a preset threshold (5% in this example), the new policy is automatically launched; if the improvement is less than 5%, the old policy is retained, and the new policy continues to be iteratively optimized in the offline environment.

[0074] Example 2 See Figure 2 As shown, this embodiment provides an automatic classification, numbering, recording, and re-calling system for heterogeneous constellation instruction packets, including: Knowledge Construction and Semantic Alignment Module: Construct a knowledge graph covering satellites, payloads, operating modes, parameters, equipment, and constraint rules. Define the relationships between entities, including onboarding, power supply, heat dissipation, mutual exclusion, dependence, and sequence. Extract entities and relationships from historical instruction documents and satellite design manuals, store them in the graph database in the form of triples, and store each constraint rule in a structured format.

[0075] Building upon this foundation, this module uses protocol adapters deployed at various ground stations to uniformly convert historical instructions in hexadecimal, XML, or JSON formats into key-value pairs. It then pre-trains a BERT model on a large-scale historical instruction corpus, encoding each standard concept and its alias in the ontology and storing it in a vector library. For newly parsed parameter names, the module calculates their cosine similarity to all standard concept vectors in the vector library; those above 0.85 are automatically aligned, while those below a threshold are pushed for manual confirmation. The aligned instructions are then stored in the database as four-layer standardized JSON documents. This module also possesses incremental knowledge graph update capabilities, automatically creating nodes not yet present in the knowledge graph when new patterns are added.

[0076] Natural Language Intent Parsing Module: It provides a natural language input interface to receive task description text input by the operator. Using a large language model as the parsing engine, it constructs prompt words from the natural language description and knowledge graph context, outputting a set of structured instruction elements. Subsequently, the LLM parsing results are fused and verified with the BERT semantic alignment results. The existence of each parameter name in the ontology is confirmed, and the legality of each parameter value within the knowledge graph's domain is confirmed. After successful verification, the parsing results are passed to the instruction generation module.

[0077] Instruction Templates and Encoding Management Module: The module iterates through all standardized instructions in the database, automatically summarizing them into a four-level classification hierarchy: L1 payload identifier, L2 operating mode, L3 core feature parameters, and L4 optional adjustment parameters. L3 and L4 are distinguished by preset thresholds. Each level is assigned a fixed-length code. A cascaded hash table is constructed using the payload identifier and operating mode as the joint key to store the list of parameters and their value ranges, and a unique instruction identifier is generated. For newly connected satellites, the module automatically reads their interface control files, extracting information such as frame headers and trailers, field offsets, bit widths, byte order, and value ranges. An attribute graph is constructed using fields as nodes and relationships between fields as edges. The graph is then fed into a neural network to extract structural feature vectors, which are matched against an existing template library. After operator confirmation, the new template is added to the library and stored in association with the four-level coding system.

[0078] Instruction generation and verification module: It provides a four-level linkage interface. After the operator selects the satellite, payload, and working mode and fills in the parameters, the local verification is performed first. Then, with the current command parameters as input, the relevant constraint rules are retrieved from the graph database and the judgment logic is executed. Conflicts are detected from the three dimensions of energy, thermal control and link respectively, and resolution suggestions are generated according to priority rules.

[0079] After operator confirmation, the module generates a unique instruction identifier, reads the satellite instruction template, and fills in the parameter values ​​item by item according to the start bit, bit width, byte order, and enumeration value mapping to assemble a binary instruction packet. Subsequently, the instruction packet undergoes deduplication verification, reverse parsing verification, and communication protocol verification. After all verifications pass, the packet is uploaded to the satellite via the satellite-to-ground link, and the system monitors for receipts in real time. If a timeout occurs, the packet is automatically retransmitted.

[0080] Multimodal prediction module: The new instruction packet is fed into the BERT model and the [CLS] vector is taken as the instruction embedding. The cosine similarity between the embedding and the prototype vectors of all patterns is calculated. If the similarity reaches the threshold, it is assigned to an existing pattern and the missing parameters are filled in using the K-nearest neighbor algorithm. If the similarity is below the threshold, a new pattern is automatically created.

[0081] Based on this, the module uses the instruction embedding vector as the semantic feature and the time series features extracted from the power and temperature time series data of similar samples in the historical telemetry database through multi-scale convolution as the time series features. After weighted fusion of the two, it outputs the predicted power, total energy consumption prediction value, temperature change curve and equipment health status trend score for each working state. At the same time, it retains the results of the pure numerical similarity weighting method as reference values.

[0082] Feedback Learning and Optimization Module: After the command is executed, complete telemetry data is extracted, and the historical database is updated or abnormal samples are marked based on energy consumption error and temperature error. When an anomaly is triggered, the module correlates the abnormal parameters with the knowledge graph to generate a root cause diagnosis report, distinguishes between systematic deviations and occasional anomalies, and triggers incremental learning or marks them as noise samples respectively.

[0083] This module also models the instruction generation process as a Markov decision process, trains the policy network offline based on historical records, provides intelligent recommendation functions in the interface, and regularly fine-tunes the policy based on new telemetry feedback. After evaluation, it automatically launches new policies with performance improvements exceeding the threshold.

[0084] Data storage module: It connects to each of the above modules to store knowledge graphs, standardized instruction documents, prototype vector libraries, cascaded hash tables, instruction template libraries, historical telemetry libraries, policy network parameters, and verification rule files.

[0085] The data interaction relationships between the modules are as follows: the Natural Language Intent Parsing module transmits the parsing results to the Command Generation and Verification module; the Command Template and Encoding Management module transmits the template configuration and encoding rules to the Command Generation and Verification module; the Command Generation and Verification module uploads the generated binary command packets to the satellite and then transmits the telemetry feedback data to the Feedback Learning and Optimization module; the update results of the Feedback Learning and Optimization module are synchronized to the Multimodal Prediction module and the Command Template and Encoding Management module; the Multimodal Prediction module returns the prediction results to the Command Generation and Verification module for the interface to be displayed to the operator.

[0086] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for automatically classifying, numbering, recording, and retrieving heterogeneous constellation instruction packages, characterized in that: include: Different formats of historical instructions are parsed into key-value pairs. A pre-trained language model is used to automatically align the heterogeneous parameter names to the standard ontology concept, forming a standardized instruction document that is stored in the database. Based on this, a database containing historical instruction embedding vectors is established. When a new instruction is received, it is converted into an embedding vector using a language model and matched with the prototype vector of an existing pattern in the database. If the match is successful, the new instruction is assigned to an existing pattern and missing parameter information is automatically filled in. If the match fails, the new instruction is stored in the database as a sample of a new pattern to expand the database. When an operator generates instructions by selecting them step by step, a unique identification code is assigned to the generated instructions according to the hierarchical coding system in the standardized instruction document, and an instruction package that can be annotated is output.

2. The method for automatically classifying, numbering, recording, and retrieving heterogeneous constellation instruction packages according to claim 1, characterized in that, The language model is pre-trained using a combination of masked language modeling and parameter name-value matching tasks. During the parameter name alignment process, multiple aliases of each standard concept in the ontology are sent to the language model to generate representation vectors and stored in the vector library. The cosine similarity between the representation vector of the new parameter name and the representation vectors of all standard concepts in the vector library is calculated. When the similarity reaches or exceeds the first preset threshold, the alignment is automatic. When the similarity is lower than the first preset threshold, manual confirmation is required.

3. The method for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packages according to claim 1, characterized in that, The hierarchical coding system comprises a four-level structure, with the first level being the payload identifier, the second level being the working mode, the third level being the core feature parameters, and the fourth level being optional adjustment parameters. The unique identification code is generated by concatenating the codes at each level and the timestamp sequence number and then extracting the first 16 characters.

4. The method for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packages according to claim 1, characterized in that, The prototype vector is the bitwise average of all historical instruction embedding vectors in each existing working mode in the database; similarity matching uses cosine similarity calculation, and when the similarity reaches the second preset threshold, it is determined to be a successful match. The missing parameter values ​​are filled in by weighting the K-nearest neighbor algorithm inversely proportional to the Euclidean distance. When the similarity is lower than the second preset threshold, it is determined that the match has failed, and a new pattern is automatically created and a new code is assigned.

5. The method for automatically classifying, numbering, recording, and retrieving heterogeneous constellation instruction packages according to claim 1, characterized in that, When the operator selects the generation command step by step, after selecting the target satellite, payload and working mode in sequence, all parameters defined by the mode are listed; after the operator fills in the parameters, a local format verification is performed, and after the verification is passed, the command package is assembled and generated according to the binary command template. Local format validation includes checking for exceeding the range of parameter values ​​and checking for mutual exclusion between different parameters in the same working mode.

6. The method for automatically classifying, numbering, recording, and retrieving heterogeneous constellation instruction packages according to claim 1, characterized in that, Before parsing historical instructions and forming standardized instruction documents, the process also includes the steps of constructing a multi-dimensional constraint knowledge graph for heterogeneous constellations: defining entity types and relationship types between entities, extracting entities and relationships from historical instruction documents and satellite design manuals and storing them in a graph database, and associating each constraint relationship with verification rules to form a constraint rule library; After the operator enters the parameters and performs local format validation, the currently generated instruction parameters are converted into graph database query statements. Relevant constraint rules are retrieved in the knowledge graph, and judgment logic is executed to complete global constraint reasoning.

7. The method for automatically classifying, numbering, recording, and re-calling heterogeneous constellation instruction packages according to claim 1, characterized in that, Global constraint reasoning includes energy conflict detection, thermal control conflict detection, and link conflict detection; energy conflict detection involves detecting whether the total power consumption of the current command and other planned commands within the same time window exceeds the satellite's power supply capacity. Thermal control conflict is detected when the predicted temperature of the device after the execution of the current command exceeds the rated maximum operating temperature of the device; link conflict is detected when the communication frequency band or channel number used by the current command is occupied by other planned commands. If a conflict is detected, resolution suggestions are generated based on priority rules in the knowledge graph.

8. A system for automatically classifying, numbering, recording, and retrieving heterogeneous constellation instruction packages, characterized in that: include: The knowledge construction and semantic alignment module is used to uniformly parse historical instructions of different formats into key-value pairs, use a pre-trained language model to automatically align each heterogeneous parameter name to the standard ontology concept, form a standardized instruction document and store it in the database, and build a database containing historical instruction embedding vectors based on this. The multimodal prediction module is used to convert new instructions into embedding vectors using a language model when they are received. The vectors are then matched with the prototype vectors of existing patterns in the database. If the match is successful, the new instruction is assigned to an existing pattern and missing parameter information is automatically filled in. If the match fails, the new instruction is stored in the database as a sample of a new pattern to expand the database. The instruction generation and verification module is used to assign a unique identification code to the generated instruction according to the hierarchical coding system in the standardized instruction document when the operator generates instructions by selecting them step by step, and outputs an instruction package that can be annotated.

9. The system for automatic classification, numbering, recording, and recalling of heterogeneous constellation instruction packets according to claim 8, characterized in that, The language model is pre-trained using a combination of masked language modeling and parameter name-value matching tasks. During the parameter name alignment process, multiple aliases of each standard concept in the ontology are sent to the language model to generate representation vectors and stored in the vector library. The cosine similarity between the representation vector of the new parameter name and the representation vectors of all standard concepts in the vector library is calculated. When the similarity reaches or exceeds the first preset threshold, the alignment is automatic. When the similarity is lower than the first preset threshold, manual confirmation is required.

10. The system for automatic classification, numbering, recording, and recalling of heterogeneous constellation instruction packets according to claim 8, characterized in that, The prototype vector is the bitwise average of all historical instruction embedding vectors in each existing working mode in the database; similarity matching uses cosine similarity calculation, and when the similarity reaches the second preset threshold, it is determined to be a successful match. The missing parameter values ​​are filled in by weighting the K-nearest neighbor algorithm inversely proportional to the Euclidean distance. When the similarity is lower than the second preset threshold, it is determined that the match has failed, and a new pattern is automatically created and a new code is assigned.

Images