Satellite remote sensing data processing method, device, equipment, medium and product

Abstract

The invention discloses a satellite remote sensing data processing method and device, equipment, a medium and a product, and relates to the technical field of satellite telemetry, and the method comprises the steps: receiving and analyzing to-be-processed satellite remote sensing data, and obtaining a task type of the to-be-processed satellite remote sensing data; matching a corresponding task process model based on the task type of the to-be-processed satellite remote sensing data to obtain a target task process model; the task process model is a task process which is pre-constructed by a user through a visual user interface and can be matched with different task types and different satellite types, each node of the task process model is bound with one or more groups of plug-in queues, and the group number of the plug-in queues or the number of each group is set according to the function of the corresponding node; and inputting the to-be-processed satellite remote sensing data into the target task process model, and executing each node of the target task process model to process the to-be-processed satellite remote sensing data to obtain a processing result. According to the invention, the flexibility of scene adaptation and the compatibility of interactive interfaces are improved.

Description

Technical Field

[0001] This application relates to the field of satellite telemetry technology, and in particular to a method, apparatus, equipment, medium and product for processing satellite remote sensing data. Background Technology

[0002] Against the backdrop of rapid iteration in satellite application technologies and diversified development of ground receiving systems, heterogeneous platforms such as satellite ground control stations, user stations, and data receiving stations exhibit significant differences and technological fragmentation in their business processes, including task orchestration modes, equipment selection schemes, system interface design, and communication standards. This leads to systemic challenges for traditional rigid-architecture scheduling systems, such as insufficient flexibility, limited scalability, and weak compatibility. They struggle to adapt to the adjustment needs of different business processes and are incompatible with the interaction interfaces of different external systems and stand-alone devices. This has become a key issue restricting ground stations from quickly and effectively completing remote sensing data reception and processing tasks. Therefore, there is an urgent need to provide a satellite remote sensing data processing method that can be adapted to different scenarios. Summary of the Invention

[0003] In view of the above-mentioned defects or deficiencies in the related technologies, the purpose of this application is to provide a method, apparatus, equipment, medium and product for processing satellite remote sensing data, which can improve the flexibility of scene adaptation and the compatibility of interactive interfaces.

[0004] To achieve the above objectives, this application provides the following solution: In a first aspect, this application provides a method for processing satellite remote sensing data, comprising: receiving and parsing satellite remote sensing data to be processed to obtain the task type of the satellite remote sensing data to be processed; matching a corresponding task flow model based on the task type of the satellite remote sensing data to be processed to obtain a target task flow model; the task flow model is a task flow that can be matched with different task types and different satellite types and is pre-constructed by the user through a visual user interface; the task flow model includes multiple nodes, each node of the task flow model is bound to one or more sets of plug-in queues, and the number of sets of plug-in queues or the number of each set is based on the function settings of the corresponding node; inputting the satellite remote sensing data to be processed into the target task flow model, executing each node of the target task flow model to process the satellite remote sensing data to be processed, and obtaining a processing result.

[0005] Optionally, the task type of the satellite remote sensing data to be processed includes the corresponding satellite type, satellite payload, and processing requirements; the matching of the response task information with the corresponding task flow model to obtain the target task flow model includes: matching the corresponding task flow model with the satellite type, satellite payload, and processing requirements corresponding to the satellite remote sensing data to be processed to obtain the target task flow model; the satellite type includes low-orbit satellites, high-orbit satellites, optical satellites, electronic satellites, radar satellites, and SAR satellites; the satellite payload includes optical payloads, microwave payloads, and electronic payloads; the processing requirements include Level 0 product production requirements, Level 1 product production requirements, and Level 2 product production requirements.

[0006] Optionally, the construction method of the task flow model includes: obtaining the satellite remote sensing data reception and processing flow configured by the user according to different satellite types, payloads and data processing requirements, so as to generate an initial flow model corresponding to different satellite types, payloads and data processing requirements; registering several plugins, and configuring one or more plugin queues based on the functions of each node of the initial flow model to obtain a task flow model with plugin queues configured; configuring corresponding trigger rules for each plugin queue of the task flow model with plugin queues configured to obtain a task flow model corresponding to different satellite types, payloads and data processing requirements.

[0007] Optionally, registering several plugins includes: placing a JAR file containing the encapsulated node functions into a specified directory and scanning and parsing it to obtain metadata within the JAR file; the metadata within the JAR file includes plugin ID, name, input / output parameter specifications, and interface definition; obtaining a user-inputted input / output parameter relationship description file through a visual user interface, and associating the input / output parameter relationship description file with the corresponding plugin to obtain a plugin with a calling interface and parameter constraints; verifying the compatibility of the JAR file and the integrity of the parameter file, and completing the registration of the JAR file-type plugin and generating a unique plugin identifier if the verification passes; creating a new interface-type plugin and associating the new interface-type plugin with a user-defined business interface to obtain an interface plugin; verifying the reachability of the interface plugin, and completing the registration of the interface plugin if the verification passes.

[0008] Optionally, configuring one or more sets of plugin queues based on the functions of each node in the initial process model to obtain a task process model configured with plugin queues includes: determining the number of plugins required to be bound to each node of the initial process model based on the functions of each node; the functional nodes of the initial process model include data receiving nodes, data parsing nodes, data verification nodes, data distribution nodes, quality analysis nodes, and task status feedback nodes; configuring a single set of serial queues, multiple sets of serial queues, or multiple sets of parallel queues based on the number of plugins required to be bound to each node, and binding the configured single set of serial queues, multiple sets of serial queues, or multiple sets of parallel queues to the corresponding nodes to obtain a task process model configured with plugin queues.

[0009] Optionally, the triggering rules include admission rules and exit rules; configuring corresponding triggering rules for each plug-in queue of the task flow model with configured plug-in queues to obtain task flow models corresponding to different satellite types, payloads, and data processing requirements includes: configuring admission rules and exit rules for each plug-in queue based on the functions of each node of the task flow model with configured plug-in queues and the plug-in parameters of each plug-in queue to obtain task flow models corresponding to different satellite types, payloads, and data processing requirements; the admission rules are the startup rules for the execution of the plug-in queues; the exit rules are the result constraints and flow triggering rules for the execution of the plug-in queues.

[0010] Secondly, this application provides a satellite remote sensing data processing apparatus, comprising: The receiving and parsing module is used to receive and parse the satellite remote sensing data to be processed, and to obtain the task type of the satellite remote sensing data to be processed. The model matching module is used to match the corresponding task flow model based on the task type of the satellite remote sensing data to be processed, and obtain the target task flow model. The task flow model is a task flow that can be matched with different task types and different satellite types, which is pre-built by the user through a visual user interface. The task flow model includes multiple nodes, and each node of the task flow model is bound to one or more sets of plug-in queues. The number of plug-in queues or the number of each group depends on the function settings of the corresponding node. The data processing module is used to input the satellite remote sensing data to be processed into the target mission flow model, execute each node of the target mission flow model to process the satellite remote sensing data to be processed, and obtain the processing result.

[0011] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the satellite remote sensing data processing method described in any one of the above.

[0012] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the satellite remote sensing data processing method described in any one of the above.

[0013] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the satellite remote sensing data processing method described in any one of the above descriptions.

[0014] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method, apparatus, device, medium, and product for processing satellite remote sensing data. On the one hand, users can pre-build task flows that match different task types and satellite types through a visual user interface. By matching the task type of the satellite remote sensing data to be processed with the corresponding target task flow model, it can meet the customized needs of different users for the entire process of satellite remote sensing data reception, parsing, and distribution, improving the flexibility of scenario adaptation and the compatibility of interactive interfaces. On the other hand, each node of the task flow model is bound to one or more sets of plug-in queues, and the number of plug-in queues or the number of each group depends on the functional settings of the corresponding node. Functionality can be extended without modifying the core code, quickly adapting to the differences in multiple scenarios of satellite remote sensing data reception and processing, solving the problem of insufficient flexibility and scalability of traditional rigid architecture, effectively reducing the cost of function updates and maintenance, and providing faster response to business changes. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments 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 based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a satellite remote sensing data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the process for receiving satellite remote sensing data to be processed, provided in an embodiment of this application. Figure 3 This is a schematic diagram of the processing flow of satellite remote sensing data to be processed, provided in another embodiment of this application. Figure 4 A functional module diagram of a satellite remote sensing data processing device provided in an embodiment of this application; Figure 5This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0017] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] In one exemplary embodiment, such as Figure 1 As shown, a method for processing satellite remote sensing data is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is described using a server as an example, and includes the following steps S101 to S104. Wherein: Step S101: Receive and parse the satellite remote sensing data to be processed to obtain the task type of the satellite remote sensing data to be processed.

[0020] In the example implementation, mission types include low-Earth orbit satellites, high-Earth orbit satellites, optical satellites, electronic satellites, radar satellites, and SAR satellites; satellite payloads include optical payloads, microwave payloads, and electronic payloads; processing requirements include Level 0 product production requirements, Level 1 product generation requirements, and Level 2 product production requirements. Level 0 product production requirements refer to the raw data directly collected and transmitted by the satellite payload (such as optical cameras and SAR antennas), requiring only minimal preprocessing, i.e., removing errors during data transmission (such as bit errors and redundant frames) and standardizing the data format (such as converting from satellite-specific formats to general binary formats), without any radiometric correction, geometric correction, or physical quantity inversion. Essentially, it retains the raw material of the payload's original observation information. Level 1 product generation requirements refer to data that, based on Level 0 products, undergoes radiometric correction (Level 1A) or radiometric + geometric coarse correction (Level 1B). The core is to transform the raw data into standardized data with physical meaning or preliminary spatial reference, but without precise geographic positioning or environmental interference removal. Secondary product production requirements refer to data that, based on primary products, undergo geometric and environmental corrections (such as atmospheric correction), or are further inverted to obtain the inherent physical parameters of ground features. The core is to eliminate external environmental interference (such as atmosphere and topography), assign accurate geographic coordinates, and enable the data to be directly used for ground feature analysis.

[0021] Step S102: Match the corresponding task flow model based on the task type of the satellite remote sensing data to be processed to obtain the target task flow model.

[0022] In the example implementation, the task flow model is a pre-built task flow that matches different task types and satellite types, accessible to the user through a visual user interface. Specifically, the user draws the satellite remote sensing data reception and processing task flow through drag-and-drop interactions, enabling business process customization. The task flow model includes nodes with different functions. Each node's attributes include node timeout, plugin chain configuration, node flow attributes, and node exception handling methods. The node timeout defines the node's runtime effectiveness. The plugin chain includes the plugin information configured for the node, along with plugin admission and exit rules. The node flow attributes cover the plugin's working mode (manual / automatic) and the handling method for plugin exceptions (continue execution of subsequent nodes / termination of the entire process). Furthermore, each node in the task flow model is bound to one or more plugin queues, and the number of plugin queues or the number of items in each queue depends on the corresponding node's functional settings.

[0023] It should be noted that the visual user interface in this application embodiment displays flowchart information, process node status information, and attribute information of each process node for defining different types of planning processes. The visual user interface supports functions such as process drawing, node attribute editing, node plugin configuration (including plugin serial and parallel combination and admission / exit rule parameter configuration), and process node display file association, which can adapt to different types of satellites and application scenarios. In some embodiments, at least one target mission process model is matched according to satellite type, satellite payload, and production requirements.

[0024] Step S103: Input the satellite remote sensing data to be processed into the target mission flow model, execute each node of the target mission flow model to process the satellite remote sensing data to be processed, and obtain the processing result.

[0025] like Figure 2As shown, taking the satellite reception process scheduling scenario as an example, the above content is explained as follows: Step S20 is executed, receiving the satellite remote sensing data to be processed, parsing the data to obtain the task type, matching the corresponding target task process model according to the task type, and starting the target task process model normally. Next, step S21 is executed, scheduling the file distribution plugin to send the satellite task file under the specified path to the system monitoring service via FTP; and recording the file distribution status as the execution result of this node. Step S221 is executed, scheduling the phase calibration discrimination plugin to display whether the process has performed phase calibration discrimination, and sending the phase calibration status confirmation file back to the system monitoring service; and / or, step S222 is executed, scheduling the quality analysis discrimination plugin to perform instruction discrimination, sending the quality discrimination result to the record storage service, and receiving the quality analysis status confirmation pushed by the record storage service. When the quality analysis discrimination calculation is completed and the quality analysis discrimination result is successfully sent, this node is considered passed. And / or, execute step S223, schedule the receiving plugin to receive the "data logging task" file pushed by the system monitoring service, and push the file to the specified path; if the file distribution plugin's satellite task forwarding is normal, this node passes. Then, execute step S23, schedule the file receiving plugin to receive the "data logging task confirmation" file sent by the logging storage service, and push it to the scanning path of the file capture plugin; next, schedule the file parsing plugin to parse according to the interface and read the taskConStatus field value; finally, schedule the file distribution plugin to send it to the system monitoring service via FTP. If the file receiving plugin successfully receives the file and places it in the specified path; if the file parsing is successful and the taskConStatus parameter value is read; if the file distribution plugin's satellite task forwarding is normal, this node passes. Execute step S24, schedule the file receiving plugin to receive the satellite confirmation file pushed by the monitoring service; next, schedule the file parsing plugin to parse the file according to the interface and read the taskConStatus field value; if the file receiving plugin successfully receives the file and places it in the specified path and sends a planned response; if the file parsing is successful, this node passes. In step S25, the scheduling file distribution plugin distributes the received "satellite mission confirmation" file to the data interaction service via file distribution; the file distribution plugin forwards the satellite mission normally, and the node passes.

[0026] In a specific embodiment, the construction of the task flow model in the above method includes steps S201 to S203, namely: Step S201: Obtain the satellite remote sensing data reception and processing flow configured by the user according to different satellite types, payloads and data processing requirements, so as to generate an initial flow model corresponding to different satellite types, payloads and data processing requirements. Step S202: Register several plugins and configure one or more plugin queues based on the functions of each node in the initial process model to obtain a task process model with plugin queues configured. Step S203: Configure corresponding trigger rules for each plug-in queue of the task flow model with plug-in queues to obtain task flow models corresponding to different satellite types, payloads and data processing requirements.

[0027] It should be noted that the plugins in this application embodiment include JAR package plugins and HTTP plugins. JAR package plugins are plugins adapted to node functions, while HTTP plugins are interface plugins. Based on application capabilities, plugins are divided into general plugins and business plugins. General plugins are applicable to all satellite remote sensing reception and telemetry task scheduling. They mainly realize information interaction with external systems and databases; these include: file processing plugins (file receiving plugins, file parsing plugins, file distribution plugins, file format conversion plugins, file generation plugins), database application plugins (database update plugins, database query plugins), message middleware processing plugins, etc. Business plugins are customized according to business function requirements. For business plugins, plugins are classified according to the type of business, including: data reception business plugins (orbit calculation plugins, remote macro control plugins, phase correction plugins), data analysis plugins (quality analysis plugins, data report generation plugins), etc.

[0028] Optionally, the registration of several plugins in step S202 above may include steps S301 to S305, namely: Step S301: Place the JAR package containing the node functionality into the specified directory and scan and parse it to obtain the metadata within the JAR package; the metadata within the JAR package includes the plugin ID, name, input / output parameter specifications, and interface definition; Step S302: Obtain the input-output parameter relationship description file input by the user through the visual user interface, and associate the input-output parameter relationship description file with the corresponding plugin to obtain a plugin with calling interface and parameter constraints; Step S303: Verify the compatibility of the JAR package and the integrity of the parameter file. If the verification passes, complete the registration of the JAR package plugin and generate a unique plugin identifier. Step S304: Create a new interface-type plugin and associate the new interface-type plugin with the user-defined business interface to obtain the interface plugin; Step S305: Verify the reachability of the interface plugin. If the verification passes, complete the interface plugin registration.

[0029] Optionally, the above step S202, which configures one or more sets of plug-in queues based on the functions of each node of the initial process model to obtain a task process model configured with plug-in queues, may include: determining the number of plug-ins required to be bound to each node of the initial process model based on the functions of each node; the functional nodes of the initial process model include data receiving nodes, data parsing nodes, data verification nodes, data distribution nodes, quality analysis nodes, and task status feedback nodes; configuring a single set of serial queues, multiple sets of serial queues, or multiple sets of parallel queues based on the number of plug-ins required to be bound to each node, and binding the configured single set of serial queues, multiple sets of serial queues, or multiple sets of parallel queues to the corresponding nodes to obtain a task process model configured with plug-in queues.

[0030] It should be noted that if a node needs to perform a single function, such as the "Satellite Receiving Task Node" which only needs "file receiving function", then select one plugin (e.g., "JAR_003-File Receiving") and configure it as a "single group serial queue". If a node needs to perform multiple functions collaboratively, such as the "File Distribution Node" which needs "file reading + FTP distribution + status recording", then select multiple plugins in functional order (e.g., "JAR_004-File Reading" → "JAR_001-File Distribution" → "JAR_005-Status Recording") and configure them as a "group serial queue". During execution, plugins within the same group will be executed sequentially. If a node needs parallel functions (e.g., the "Data Backup Node" which needs "local backup + cloud backup"), then select two groups of serial queues ("JAR_006-Local Backup" and "JAR_007-Cloud Backup") and configure them as "multiple groups of parallel queues". During execution, plugins in each group will be executed synchronously.

[0031] Optionally, step S203 may include: configuring admission rules and exit rules for each plug-in queue based on the functions of each node in the task flow model configured with plug-in queues and the plug-in parameters of each plug-in queue, to obtain a task flow model corresponding to different satellite types, payloads and data processing requirements; the admission rules are the start rules for the execution of the plug-in queues; the exit rules are the result constraints and flow triggering rules for the execution of the plug-in queues.

[0032] It should be noted that the triggering rules include admission rules and exit rules; admission rules are the startup rules executed by the plugin queue; exit rules are the result constraints and flow triggering rules executed by the plugin queue.

[0033] In some embodiments, admission rules may include the following rules: Data source verification rules: These rules are used to verify whether the source of received file data or message data is a specified single or multiple sources. The data source identifier consists of English letters, numbers, and punctuation marks, including "-" and "_". The total length of the data source identifier cannot exceed 15 characters, for example: OMS, YXGL2, SHJC_BJ, etc.

[0034] Data type validation rules: These rules are used to verify whether the received file data or message data is of the specified type. Data types can be common file types, such as XML files or TXT files, or custom file types. For custom file types, the custom file type is used as the file extension, and the custom file type uses a combination of English letters. For example, if the satellite receiving task type is TRTASK, the receiving task file will be "filename.TRTASK". The custom file types used in this application include: receiving task (TRTASK), task receipt file (TRTASKACK), task cancellation (TRTASKCANCEL), task cancellation receipt (TRTASKCANCELACK), and completion report (RESULTREPORT), etc.

[0035] Data structure verification rules: Used to verify whether the format of received file data or message data conforms to the requirements of the interface specification and whether the data structure is complete. Data structure verification is designed and implemented according to the interface file. Taking the task data received by this system as an example. The data consists of two parts: header and body. (1) The header information includes file type, receiver, sender, file creation time, and missionary information. All information in the header must be valid; (2) The body content includes: task code, satellite information, circle number, task start time, task end time, channel information, working mode, target list, etc., of which the task code, satellite information, circle number, task start time, task end time, channel information, working mode, etc. must be valid. Data naming verification rules: Used to verify whether the naming specification of received file data conforms to the requirements of the interface specification. The file name content includes: file sender, file receiver, file creation time, satellite information, etc. The file naming rules in this application are as follows: file sender_file receiver_satellite name_YYYYMMDD_task circle number.file type.

[0036] Data naming verification rules: These rules are used to verify whether the naming conventions of received file data conform to the interface specifications. The file name includes: file sender, file receiver, file generation time, satellite information, etc. The file naming rules in this application are as follows: File Sender_File Receiver_Satellite Name_YYYYMMDD_Mission Circle Number.File Type.

[0037] Data format verification rules: used to verify the content correctness of received file data or message data, including: non-empty verification, date format verification, content length verification, data range verification, content comparison verification, etc. Among them, the date format supports multiple forms of verification such as YYYYMMDD-HH:MM:SS and YYYYMMDDHHMMSS. The length verification is applied to the verification of fixed-length data such as task codes and task circle numbers. For example, the task code is 9 digits in fixed length, and the task circle number is 6 digits in fixed length. The data range verification can verify whether the parameter values of integer, floating-point, and enumeration data in the data are within the standard range specified by the interface. The content comparison verification is for data with specific parameter value requirements. For example, for the file sender information, the system only analyzes and processes the data of the agreed sender.

[0038] The egress rules are the specification requirements that the output data or execution results must meet after the plugin or process node has completed execution. Essentially, it is to unify the output format and ensure that downstream plugins / nodes can correctly receive and parse the data. And the egress rules correspond to the ingress rules. Only after the output data meets the specifications can it be used as the ingress input for downstream plugins or the basis for process status records.

[0039] In the embodiments of this application, the egress rules may include output information types, output format constraints, and data transfer logics. Among them, the output information type is the core information output by the plugin / node, covering the execution status + process + result, for downstream plugins or nodes to judge and use. For example, the execution status: the execution result of the plugin (success / failure / time-out), such as the phase calibration discrimination plugin outputs "phase calibration passed (success)" and "phase calibration exception (failure)"; process parameters: key data during the execution process, such as the file distribution plugin outputs "distribution times (3 times)" and "transmission rate (10MB / s)"; result parameters: the final calculation result, such as the quality analysis plugin outputs "data qualification rate (98%)"; result object: the structured data carrier, such as a data queue, TreeMap (mapping storing task IDs and corresponding file paths).

[0040] The output format constraint means that the format of the output data needs to match the ingress rules of the downstream plugin to ensure that the data can be directly verified and passed by the downstream. For example, if the ingress rules of the downstream level-1 product production plugin require the result parameter to be in JSON format, then the egress format of the upstream data processing plugin must be JSON (such as {"taskId":"001","dataPath":" / data / raw / 001.dat","quality":"qualified"}); the output file naming needs to conform to the downstream data naming verification rules, that is, be consistent with the naming specification of the ingress rules.

[0041] Data transfer logic defines the objects to which output data is transferred, such as whether it is only transferred to the next sequential plugin or transferred in parallel to multiple plugins, in order to control the flow of the process. Data transfer logic mainly includes sequential and parallel processes. For example, in a sequential process, the output data of the phase calibration plugin is only transferred to the next quality analysis plugin. In a parallel process, the output data of the raw data processing plugin is simultaneously transferred to both the Level 0 product production plugin and the data backup plugin, allowing the two plugins to execute in parallel.

[0042] In this embodiment, a plugin is a functional module in the satellite remote sensing data processing workflow that can be independently developed, dynamically accessed, and flexibly combined. This functional module is an independent unit encapsulating specific business functions, possessing its own code logic and input / output interfaces (e.g., admission rules / exit rules), and can run without relying on the system's core code. In practical applications, users can register and configure plugins with different functions according to their actual needs to match different task flow models, expanding data reception, processing, and analysis capabilities without modifying the system's core code.

[0043] Implementing steps S101 to S104 allows users to, on the one hand, pre-build task flows that match different task types and satellite types through a visual user interface. By matching the task type of the satellite remote sensing data to be processed with the corresponding target task flow model, the customized needs of different users for the entire process of satellite remote sensing data reception, parsing, and distribution can be met, improving the flexibility of scenario adaptation and the compatibility of the interactive interface. On the other hand, each node of the task flow model is bound to one or more plugin queues, and the number of plugin queues or the number of each queue depends on the functional settings of the corresponding node. Functionality can be extended without modifying the core code, quickly adapting to the differences in multiple scenarios of satellite remote sensing data reception and processing. This solves the problem of insufficient flexibility and scalability of traditional rigid architecture, effectively reducing the cost of function updates and maintenance, and improving the response speed for business changes.

[0044] In another exemplary embodiment of this application, in order to facilitate user confirmation at nodes that require manual determination and to understand the current task execution node, the method further includes: monitoring the execution parameters of each node of the standardized task flow model during execution to obtain the attribute information, plugin admission information, and plugin exit information of the current node's plugin chain; generating detection results based on the attribute information, plugin admission information, and plugin exit information, and displaying the monitoring results on the visualization interface in real time so that users can confirm the nodes that require manual determination during execution.

[0045] Combining the above embodiments and Figure 3As shown, understandably, step S1 involves receiving and parsing the satellite remote sensing data to be processed to obtain the task type; then step S2 involves matching the corresponding target task flow model according to the task type and determining whether the match is successful. If the match fails, the task ends; if the match is successful, step S3 is executed to start the target task flow model, followed by step S4, which reads the node attributes, operation mode, and other information of the target task flow model and executes each flow node configured in the target task flow model sequentially; then step S5 is executed to determine whether all nodes in the target task flow model have been completed. If completed, the task ends and the processing result is obtained; if not completed, step S6 is executed to read the uncompleted nodes. The process begins by configuring the plugin chain information for each node. Step S7 then checks the completion status of the plugin queue for unfinished nodes. If completed, the task ends; otherwise, step S8 is executed. Based on the plugin's execution result, the plugin JAR file or HTTP interface is called to configure the corresponding plugin's admission and exit rules. Then, plugin attributes, admission and exit rules are read to execute step S9, which executes the plugin and sends back the plugin's execution status and result information via the output interface. Step S10 then collects plugin parameters and checks again whether the plugin queues for subsequent nodes have been completed. If all are completed, the task ends; otherwise, step S8 is executed, continuing until all nodes of the target task flow model are completed.

[0046] Based on the same inventive concept, this application also provides a satellite remote sensing data processing apparatus for implementing the satellite remote sensing data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more satellite remote sensing data processing apparatus embodiments provided below can be found in the limitations of the satellite remote sensing data processing method described above, and will not be repeated here.

[0047] In one exemplary embodiment, such as Figure 4 As shown, a satellite remote sensing data processing device 600 is provided, comprising: a receiving and parsing module 401, a model matching module 402, and a data processing module 403, specifically: The receiving and parsing module 401 is used to receive and parse the satellite remote sensing data to be processed to obtain the task type of the satellite remote sensing data to be processed. The model matching module 402 is used to match the corresponding task flow model based on the task type of the satellite remote sensing data to be processed, and obtain the target task flow model. The task flow model is a task flow that can be matched with different task types and different satellite types, which is pre-built by the user through a visual user interface. The task flow model includes multiple nodes, and each node of the task flow model is bound to one or more sets of plug-in queues. The number of plug-in queues or the number of each set depends on the function settings of the corresponding node. The data processing module 403 is used to input the satellite remote sensing data to be processed into the target mission flow model, execute each node of the target mission flow model to process the satellite remote sensing data to be processed, and obtain the processing result.

[0048] As an optional implementation, the task type of the satellite remote sensing data to be processed includes the corresponding satellite type, satellite payload, and processing requirements; the model matching module 402 is specifically used to match the corresponding task flow model based on the satellite type, satellite payload, and processing requirements corresponding to the satellite remote sensing data to be processed, to obtain the target task flow model; the satellite types include low-orbit satellites, high-orbit satellites, optical satellites, electronic satellites, radar satellites, and SAR satellites; the satellite payloads include optical payloads, microwave payloads, and electronic payloads; the processing requirements include Level 0 product production requirements, Level 1 product production requirements, and Level 2 product production requirements.

[0049] As an optional implementation, the satellite remote sensing data processing device 400 further includes a construction module. The construction module is used to: acquire the satellite remote sensing data reception and processing flow configured by the user according to different satellite types, payloads, and data processing requirements, so as to generate an initial flow model corresponding to different satellite types, payloads, and data processing requirements; register several plugins, and configure one or more plugin queues based on the functions of each node of the initial flow model to obtain a task flow model with plugin queues configured; configure corresponding trigger rules for each plugin queue of the task flow model with plugin queues configured to obtain a task flow model corresponding to different satellite types, payloads, and data processing requirements.

[0050] As an optional implementation, the aforementioned building module is specifically used to: place the JAR package containing the node functionality into a specified directory and scan and parse it to obtain the metadata within the JAR package; the metadata within the JAR package includes the plugin ID, name, input / output parameter specifications, and interface definition; obtain the user-inputted input / output parameter relationship description file through a visual user interface, and associate the input / output parameter relationship description file with the corresponding plugin to obtain a plugin with a calling interface and parameter constraints; verify the compatibility of the JAR package and the integrity of the parameter file, and complete the registration of the JAR package-type plugin and generate a unique plugin identifier if the verification passes; create a new interface-type plugin and associate the new interface-type plugin with the user-defined business interface to obtain an interface plugin; verify the reachability of the interface plugin, and complete the registration of the interface plugin if the verification passes.

[0051] As an optional implementation, the aforementioned construction module is specifically used to determine the number of plugins required to be bound to each node of the initial process model based on the functions of each node of the initial process model. The functional nodes of the initial process model include data receiving nodes, data parsing nodes, data verification nodes, data distribution nodes, quality analysis nodes, and task status feedback nodes. Based on the number of plugins required to be bound to each node, a single set of serial queues, multiple sets of serial queues, or multiple sets of parallel queues are configured, and the configured single set of serial queues, multiple sets of serial queues, or multiple sets of parallel queues are bound to the corresponding nodes to obtain a task process model configured with plugin queues.

[0052] As an optional implementation, the triggering rules mentioned above include admission rules and exit rules; the construction module further has the function of configuring admission rules and exit rules for each plug-in queue based on the functions of each node of the task flow model configured with plug-in queues and the plug-in parameters of each plug-in queue, so as to obtain a task flow model corresponding to different satellite types, payloads and data processing requirements; the admission rule is the start rule for the execution of the plug-in queue; the exit rule is the result constraint and flow triggering rule for the execution of the plug-in queue.

[0053] As an optional implementation, the satellite remote sensing data processing device 300 further includes a monitoring module. The monitoring module is used to monitor the execution parameters of each node of the standardized task flow model during execution, obtain the attribute information, plug-in admission information, and plug-in exit information of the plug-in chain of the current node; generate detection results based on the attribute information, plug-in admission information, and plug-in exit information, and display the monitoring results on the visualization interface in real time so that the user can confirm the nodes that need to be manually determined during the execution process.

[0054] This implementation approach offers several advantages. First, users can pre-build task flows that match different task types and satellite types through a visual user interface. By matching the task type of the satellite remote sensing data to be processed with the corresponding target task flow model, it can meet the customized needs of different users for the entire process of satellite remote sensing data reception, parsing, and distribution, improving the flexibility of scenario adaptation and the compatibility of the interactive interface. Second, each node of the task flow model is bound to one or more plugin queues, and the number of plugin queues or the number of each queue depends on the functional settings of the corresponding node. This allows for functional expansion without modifying the core code, quickly adapting to the differences in multiple scenarios of satellite remote sensing data reception and processing. It solves the problem of insufficient flexibility and scalability of traditional rigid architectures, effectively reducing the cost of function updates and maintenance, and improving the response speed for business changes.

[0055] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores processed satellite remote sensing data. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for processing satellite remote sensing data.

[0056] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0057] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0058] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0059] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0060] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0061] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0062] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchain. The processors involved in the embodiments provided in this application may be, but are not limited to, general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc.

[0063] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0064] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing satellite remote sensing data, characterized in that, The method for processing the satellite remote sensing data includes: Receive and parse satellite remote sensing data to be processed to obtain the task type of the satellite remote sensing data to be processed; Based on the task type of the satellite remote sensing data to be processed, a corresponding task flow model is matched to obtain the target task flow model. The task flow model is a task flow that can be matched with different task types and different satellite types, which is pre-built by the user through a visual user interface. The task flow model includes multiple nodes, and each node of the task flow model is bound to one or more sets of plug-in queues. The number of plug-in queues or the number of each set depends on the function settings of the corresponding node. The satellite remote sensing data to be processed is input into the target mission flow model, and each node of the target mission flow model is executed to process the satellite remote sensing data to be processed, and the processing result is obtained.

2. The method for processing satellite remote sensing data according to claim 1, characterized in that, The task type of the satellite remote sensing data to be processed includes the corresponding satellite type, satellite payload, and processing requirements; The response task information is matched with the corresponding task flow model to obtain the target task flow model, including: Based on the corresponding task flow model matching the satellite type, satellite payload, and processing requirements of the satellite remote sensing data to be processed, the target task flow model is obtained; the satellite types include low-orbit satellites, high-orbit satellites, optical satellites, electronic satellites, radar satellites, and SAR satellites; the satellite payloads include optical payloads, microwave payloads, and electronic payloads; the processing requirements include Level 0 product production requirements, Level 1 product production requirements, and Level 2 product production requirements.

3. The method for processing satellite remote sensing data according to claim 1, characterized in that, The task flow model is constructed in the following ways: Obtain the satellite remote sensing data reception and processing flow configured by the user according to different satellite types, payloads and data processing requirements, so as to generate an initial flow model corresponding to different satellite types, payloads and data processing requirements; Register several plugins, and configure one or more plugin queues based on the functions of each node in the initial process model to obtain a task process model with plugin queues configured. Configure corresponding trigger rules for each plugin queue of the task flow model with plugin queues to obtain task flow models corresponding to different satellite types, payloads and data processing requirements.

4. The method for processing satellite remote sensing data according to claim 3, characterized in that, The registration of several plugins includes: Place the JAR file containing the node functionality into the specified directory and scan and parse it to obtain the metadata within the JAR file; the metadata within the JAR file includes the plugin ID, name, input / output parameter specifications, and interface definition. The user input and output parameter relationship description file is obtained through a visual user interface, and the input and output parameter relationship description file is associated with the corresponding plugin to obtain a plugin with a calling interface and parameter constraints. Verify the compatibility of the JAR package and the integrity of the parameter file. If the verification passes, complete the registration of the JAR package plugin and generate a unique plugin identifier. Create a new interface-type plugin and associate the new interface-type plugin with a user-defined business interface to obtain the interface plugin; Verify the reachability of the interface plugin, and complete the interface plugin registration if the verification is successful.

5. The method for processing satellite remote sensing data according to claim 3, characterized in that, The process involves configuring one or more plugin queues based on the functional configuration of each node in the initial process model to obtain a task process model configured with plugin queues, including: Based on the functions of each node in the initial process model, the number of plugins required to be bound to each node in the initial process model is determined; the functional nodes of the initial process model include data receiving nodes, data parsing nodes, data verification nodes, data distribution nodes, quality analysis nodes, and task status feedback nodes. Configure a single-group serial queue, multiple-group serial queues, or multiple-group parallel queues based on the number of plugins required to bind to each node. Bind the configured single-group serial queue, multiple-group serial queues, or multiple-group parallel queues to the corresponding nodes to obtain a task flow model with configured plugin queues.

6. The method for processing satellite remote sensing data according to claim 3, characterized in that, The triggering rules include admission rules and exit rules; configuring corresponding triggering rules for each plug-in queue of the task flow model with the plug-in queue to obtain a task flow model corresponding to different satellite types, payloads, and data processing requirements includes: Based on the functions of each node in the task flow model configured with plug-in queues and the plug-in parameters of each plug-in queue, admission rules and exit rules are configured for each plug-in queue to obtain a task flow model corresponding to different satellite types, payloads, and data processing requirements; the admission rules are the startup rules for the execution of the plug-in queues; the exit rules are the result constraints and flow triggering rules for the execution of the plug-in queues.

7. A satellite remote sensing data processing device, characterized in that, The satellite remote sensing data processing device includes: The receiving and parsing module is used to receive and parse the satellite remote sensing data to be processed, and to obtain the task type of the satellite remote sensing data to be processed. The model matching module is used to match the corresponding task flow model based on the task type of the satellite remote sensing data to be processed, and obtain the target task flow model. The task flow model is a task flow that can be matched with different task types and different satellite types, which is pre-built by the user through a visual user interface. The task flow model includes multiple nodes, and each node of the task flow model is bound to one or more sets of plug-in queues. The number of plug-in queues or the number of each group depends on the function settings of the corresponding node. The data processing module is used to input the satellite remote sensing data to be processed into the target mission flow model, execute each node of the target mission flow model to process the satellite remote sensing data to be processed, and obtain the processing result.

8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the method for processing satellite remote sensing data according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the satellite remote sensing data processing method according to any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the satellite remote sensing data processing method according to any one of claims 1-6.

Images