Methods, apparatus, equipment, and media for determining constellation size based on orbital edge computing

Abstract

This application provides a method, apparatus, device, and medium for determining the size of an orbital edge computing constellation, which can be applied to the field of aerospace technology. The method includes: determining the maximum sustainable computing power of a single satellite based on the thermal constraints of the satellite; determining the lower limit of the constellation size required to meet the computing power requirements based on the maximum sustainable computing power and the computing power requirements of the mission; inputting the lower limit of the constellation size and multiple candidate constellation sizes greater than the lower limit into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads, and predicting the hardware manufacturing cost corresponding to each candidate constellation size; determining the total mission cost of the orbital processing architecture and the ground processing architecture under each candidate constellation size based on the hardware manufacturing cost corresponding to each candidate constellation size; and comparing the total mission cost of the orbital processing architecture and the ground processing architecture to determine the constellation size that meets the preset target economically.

Description

Technical Field

[0001] This application relates to the field of aerospace technology, and more specifically to a method, apparatus, equipment, and medium for determining the size of an orbital edge computing constellation. Background Technology

[0002] With the rapid expansion of Earth observation capabilities, modern satellite constellations generate terabytes of raw image data daily. This creates a significant bottleneck: downlink bandwidth is expensive, limited, and often not available in real time. Orbital edge computing offers a paradigm shift by processing data in orbit and transmitting only actionable insights, thereby reducing downlink data volume by orders of magnitude.

[0003] Existing cost models for assessing the economic feasibility of orbit calculations are overly simplistic and fail to accurately reflect the economies of scale in large-scale constellation manufacturing. Traditional satellite cost estimation methods use a single learning rate model to evaluate satellite manufacturing costs, failing to differentiate between the different learning characteristics of satellite platforms and commercial payloads. Satellite platform manufacturing benefits from mass production and process optimization, resulting in a lower learning rate, while commercial payloads have relatively rigid prices and a higher learning rate. Using a single learning rate leads to overly optimistic or conservative cost predictions, failing to provide accurate cost basis for constellation-scale design. Summary of the Invention

[0004] In view of the above problems, this application provides a method, apparatus, device and medium for determining the size of a constellation by calculating the orbital edge.

[0005] According to the first aspect of this application, a method for determining constellation size by calculating orbital edges is provided, comprising:

[0006] Based on the thermal constraints of a single satellite, determine the maximum sustainable computing power of that single satellite;

[0007] Based on the maximum sustainable computing power and the computing power requirements of the task, determine the lower limit of the constellation size required to meet the computing power requirements;

[0008] The lower limit of the constellation size and multiple candidate constellation sizes larger than the lower limit are respectively input into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads to predict the hardware manufacturing cost corresponding to each candidate constellation size.

[0009] Based on the hardware manufacturing cost corresponding to the scale of each candidate constellation, determine the total task cost of the orbital processing architecture and the ground processing architecture under the scale of each candidate constellation.

[0010] By comparing the total mission costs of the orbital processing architecture and the ground processing architecture, the constellation size that meets the preset goals in terms of economy is determined.

[0011] According to an embodiment of this application, determining the maximum sustainable computing power of a single satellite based on its thermal constraints includes:

[0012] Obtain the thermal emissivity, effective radiative heat dissipation area, and upper limit of operating temperature of the single satellite;

[0013] The radiator temperature of the single satellite is determined based on the range of variation of the orbital angle β of the single satellite.

[0014] Substitute the thermal emissivity, Stefan-Boltzmann constant, effective radiative heat dissipation area, upper limit of operating temperature, and radiator temperature into the thermal radiation equation to calculate the upper limit of sustainable power for the single satellite.

[0015] The maximum sustainable computing capacity of a single satellite is determined based on the sustainable power limit and the energy efficiency ratio of the onboard computing equipment of the single satellite.

[0016] According to an embodiment of this application, the two-component learning curve cost model is expressed as follows:

[0017]

[0018] in, Let $i$ be the hardware manufacturing cost of the i-th satellite in the candidate constellation. The platform cost for the first satellite in the candidate constellation, The payload cost of the first satellite in the candidate constellation. For satellite platform learning rate, For commercial payload learning rates, and ≠ .

[0019] According to an embodiment of this application, determining the total task cost of the orbital processing architecture and the ground processing architecture for each candidate constellation size based on the hardware manufacturing cost corresponding to the size of each candidate constellation includes:

[0020] Acquire launch costs, operating costs, ground leveling calculation costs, and downlink data communication costs;

[0021] Based on the hardware manufacturing cost, launch cost and operating cost of each candidate constellation, calculate the leveled orbit calculation cost corresponding to the size of each candidate constellation.

[0022] Based on the leveled orbit calculation cost, the ground leveled calculation cost, and the data downlink communication cost, calculate the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale.

[0023] According to an embodiment of this application, the step of calculating the leveled orbit calculation cost corresponding to the size of each candidate constellation based on the hardware manufacturing cost, the launch cost, and the operating cost of each candidate constellation includes:

[0024] Obtain the total computational cost corresponding to the task lifetime and the size of each candidate constellation;

[0025] The leveled orbit calculation cost is obtained by dividing the sum of the hardware manufacturing cost, launch cost, and operating cost corresponding to each candidate constellation by the total computational cost over the mission's lifespan.

[0026] According to an embodiment of this application, calculating the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale based on the leveled orbit calculation cost, the ground leveling calculation cost, and the data downlink communication cost includes:

[0027] Obtain the daily amount of raw data generated by the task, the on-board data compression ratio, and the daily computational requirements;

[0028] Based on the original data volume and the downlink communication cost, determine the communication cost of the ground processing architecture;

[0029] The computational cost of the ground processing architecture is determined based on the daily computational requirements and the ground leveling computational cost.

[0030] The total daily task cost of the ground processing architecture is obtained by adding the communication cost and the computing cost of the ground processing architecture.

[0031] The communication cost of the track processing architecture is determined based on the original data volume, the compression ratio, and the downlink communication cost.

[0032] The computational cost of the orbit processing architecture is determined based on the daily computational requirements and the computational cost of the leveled orbit.

[0033] The total daily task cost of the orbit processing architecture is obtained by adding the communication cost and the computing cost of the orbit processing architecture.

[0034] According to an embodiment of this application, the on-board data compression ratio is determined based on the cloud coverage ratio and the region of interest retention ratio:

[0035]

[0036] Where α is the on-board data compression ratio. The proportion of invalid data caused by cloud cover. Reserve a percentage for the region of interest.

[0037] A second aspect of this application provides an apparatus for determining the constellation size by calculating the orbital edge, comprising:

[0038] The capability determination module is used to determine the maximum sustainable computing capability of a single satellite based on the thermal constraints of that single satellite.

[0039] The scale determination module is used to determine the lower limit of the constellation scale required to meet the computing power requirements based on the maximum sustainable computing power and the computing power requirements of the task.

[0040] The prediction module is used to input the lower limit of the constellation size and multiple candidate constellation sizes greater than the lower limit into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads, and to predict the hardware manufacturing cost corresponding to each candidate constellation size.

[0041] The cost determination module is used to determine the total task cost of the orbital processing architecture and the ground processing architecture under each candidate constellation scale based on the hardware manufacturing cost corresponding to each candidate constellation scale.

[0042] The constellation determination module is used to compare the total mission cost of the orbital processing architecture with that of the ground processing architecture to determine the constellation size that is economically compatible with preset goals.

[0043] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0044] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0045] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0046] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0047] Figure 1 A schematic diagram of an orbital edge computing architecture according to an embodiment of this application is shown.

[0048] Figure 2 A flowchart illustrating a method for determining constellation size by calculating orbital edges according to an embodiment of this application is shown schematically.

[0049] Figure 3A A schematic diagram of a two-component learning curve model according to an embodiment of this application is shown.

[0050] Figure 3B This illustration schematically depicts an embodiment according to the present application. Depending on the size of the constellation The curve of change;

[0051] Figure 3C This illustration schematically depicts an embodiment according to the present application. Economic feasibility heatmap of parameter space;

[0052] Figure 3D This illustration schematically shows the daily cost savings according to embodiments of this application as a function of bandwidth costs. Changes ( );

[0053] Figure 3E This illustration schematically depicts an embodiment according to the present application. launch cost Sensitivity;

[0054] Figure 3F This illustration schematically shows the daily cost savings according to embodiments of this application as a function of compression ratio. Changes;

[0055] Figure 4 A schematic diagram illustrating the structural block diagram of a constellation size determination device for orbital edge calculation according to an embodiment of this application; and

[0056] Figure 5 A block diagram of an electronic device for determining constellation size by calculating orbital edge according to an embodiment of this application is shown schematically. Detailed Implementation

[0057] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0058] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0059] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0060] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0061] Figure 1 A schematic diagram of an orbital edge computing architecture according to an embodiment of this application is shown.

[0062] like Figure 1 As shown, the coupling relationship between orbital dynamics, thermal constraints, and economies of scale is illustrated, comparing traditional raw data downlink (red arrow, 1TB) and in-situ orbital processing (blue arrow, 10GB).

[0063] Figure 2 A flowchart illustrating a method for determining constellation size by calculating orbital edge according to an embodiment of this application is shown.

[0064] like Figure 2 As shown, the orbital edge calculation constellation size determination method of this embodiment includes operations S210 to S250.

[0065] In operation S210, the maximum sustainable computing power of a single satellite is determined based on the thermal constraints of that satellite.

[0066] According to embodiments of this application, thermal constraints refer to the upper limit of power required for the onboard computing equipment to operate stably and continuously under the influence of the vacuum thermal radiation environment during satellite operation in orbit. In the vacuum environment of space, satellites mainly dissipate heat through thermal radiation, unlike ground-based equipment which can dissipate heat through convection. Therefore, the power consumption of onboard computing equipment is limited by the satellite's heat dissipation capacity.

[0067] According to embodiments of this application, the thermal constraints of a satellite can be described as follows: the satellite's heat dissipation power is jointly affected by its heat dissipation area, surface thermal radiation characteristics, and orbital thermal environment. Under given orbital conditions, there is a physical upper limit to the power that the satellite can continuously provide to the onboard computing equipment. This power upper limit determines the computing power level that the onboard computing equipment can continuously operate at.

[0068] As an example, for a 550km sun-synchronous orbit satellite, the power that a single satellite can continuously provide to its onboard computing equipment is typically limited to the order of several hundred watts due to fluctuations in heat dissipation caused by changes in the orbital β angle. Considering the current energy efficiency levels of onboard computing equipment, the maximum sustainable computing capacity of a single satellite is approximately in the order of 10 TFLOPS.

[0069] It should be noted that the above values ​​are for illustrative purposes only and may vary depending on the specific satellite design, orbital parameters, and type of computing equipment used in actual applications.

[0070] When operating the S220, the lower limit of the constellation size required to meet the computing power requirements is determined based on the maximum sustainable computing power and the computing power requirements of the task.

[0071] According to embodiments of this application, the computing power requirement of a task refers to the computing power required to process remote sensing data per unit time. The constellation size lower limit refers to the minimum number of satellites required to meet this computing power requirement.

[0072] Specifically, given the maximum sustainable computing power of a single satellite, the greater the computing power requirement of the mission, the more satellites are needed. There is a basic multiple relationship between the two: the required number of satellites is at least the mission's computing power requirement divided by the computing power of a single satellite, rounded up.

[0073] Among them, the lower limit of constellation size Determined by the following formula:

[0074]

[0075] in, The computing power requirement per unit time (TFLOPS) for the task. To operate on the maximum sustainable computing power (TFLOPS / satellite) of a single satellite as determined by S210, ceil represents the round-up function.

[0076] As an example, and not a limitation, suppose a remote sensing task requires real-time processing of remote sensing images acquired daily. The calculated computational power requirement per unit time is... The maximum sustainable computing power of a single satellite is 1000 TFLOPS, determined by operation S210. The lower limit of constellation size is 10 TFLOPS. = ceil(1000 / 10) = 100. This means that a constellation of at least 100 satellites is needed to meet the real-time processing requirements of this mission.

[0077] It should be noted that the lower limit for constellation size determined here is the minimum requirement, and the actual usable constellation size can be larger than this lower limit.

[0078] In operation S230, the lower limit of the constellation size and multiple candidate constellation sizes above the lower limit are respectively input into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads, to predict the hardware manufacturing cost corresponding to each candidate constellation size.

[0079] According to embodiments of this application, the two-component learning curve cost model is an empirical model used to predict the unit product cost under different production scales. Unlike traditional single learning rate models, this application decomposes satellite costs into platform costs and payload costs, applying different learning rates to each to more accurately reflect the different cost evolution patterns of the two types of components in large-scale production.

[0080] Specifically, platform cost refers to the manufacturing cost of basic service subsystems such as satellite structure, power supply, attitude control, thermal control, and satellite maintenance; payload cost refers to the manufacturing cost of specialized equipment (such as GPU computing units) that perform specific tasks. During mass production, the platform portion benefits from batch production and process optimization, resulting in a faster cost reduction; while the commercial payload portion, due to its high technological maturity and relatively rigid price, experiences a slower cost reduction. By modeling these two parts separately, the total hardware cost of the constellation at different scales can be predicted more accurately.

[0081] According to an embodiment of this application, based on the lower limit of the constellation size determined in operation S220, this operation further selects multiple candidate constellation sizes greater than the lower limit, such as the lower limit value, lower limit + 20, lower limit + 40, etc., to form a candidate size set. For each candidate size, a two-component learning curve cost model is used to predict the sum of the hardware manufacturing costs of all satellites at that size.

[0082] As an example, suppose the initial platform cost of a certain type of satellite is $5 million, and the initial payload cost is $3 million. During mass production, the platform cost decreases faster with increasing production volume, while the payload cost decreases more slowly. When the constellation reaches 100 satellites, the overall learning effect can reduce the average hardware cost per satellite to about 63% of the initial cost, and the total hardware cost of the constellation is approximately (500 + 300) × 100 × 0.63 ≈ $504 million.

[0083] When operating S240, the total mission cost of the orbital processing architecture and ground processing architecture under each candidate constellation scale is determined based on the hardware manufacturing cost corresponding to each candidate constellation scale.

[0084] According to embodiments of this application, the total task cost refers to all costs required to complete a specific remote sensing task, including data processing costs and data transmission costs. This application compares the total task costs of two data processing architectures:

[0085] Ground processing architecture: The satellite transmits all raw data it collects downlink to ground stations for processing at ground computing centers. Under this architecture, the total mission cost primarily includes downlink communication costs and ground computing costs.

[0086] Orbital processing architecture: The satellite processes the acquired data in orbit and only sends the processed results (compressed data) downlink to the ground station. Under this architecture, the total mission cost mainly includes satellite hardware costs, launch costs, on-orbit operation costs, and downlink communication costs for the compressed data.

[0087] Specifically, for each candidate constellation size, the determination of the total mission cost needs to take into account the following factors:

[0088] First, the hardware cost of the orbit processing architecture is predicted by the S230 operation; the launch cost depends on the total mass of the satellite; the operating cost includes ground station maintenance, mission control, software updates, and other expenses; the communication cost depends on the downlink data volume and unit bandwidth cost; and the computing cost depends on the required computing power and unit computing cost.

[0089] Secondly, the communication cost of the ground processing architecture depends on the amount of raw data and the cost per unit bandwidth; the computing cost depends on the amount of computing required and the cost of ground computing units.

[0090] Finally, by comparing the total costs of the two architectures, the economics of orbit processing at different constellation sizes can be evaluated.

[0091] As an example, suppose a remote sensing task generates raw data daily. For 1000 GB, the computational load is 10. 4 GFLOP, compression ratio The data downlink cost is 100 times higher. Ground computing cost is $3 / GB. The calculation is $0.005 per GFLOP-hour. The daily computational requirement W is set at 10,000 GFLOPs / day (i.e., 10...). 4 For a constellation of N=100 stars, the cost of orbit calculation (GFLOP / day) is... The daily cost of the ground processing architecture is $0.018 / GFLOP-hour. = 1000 × 3 + 10,000 × 0.005 = 3000 + 50 = $3050, daily cost of the orbital processing architecture =(1000 / 100) × 3 + 10,000 × 0.018 = 10 × 3 + 180 = 30 + 180 = $210. The calculation shows that, under these example parameters, the total daily mission cost of an orbital processing architecture with 100 satellites is $210 / day, significantly lower than the $3050 / day cost of a ground-based processing architecture, representing a cost saving of 93%.

[0092] By operating the S250, the total mission cost is compared between the orbital processing architecture and the ground processing architecture to determine the constellation size that is economically aligned with the preset goals.

[0093] According to embodiments of this application, the preset objective can be cost minimization or achieving specific economic feasibility conditions. By comparing the total task cost of the orbital processing architecture with the total task cost of the ground processing architecture for each candidate constellation size, the constellation size that satisfies the preset objective can be selected as the optimization result.

[0094] Specifically, if the preset objective is to minimize costs, the optimal constellation size is selected from the candidate size set as the size that minimizes the total cost of the orbital processing architecture tasks. If the preset objective is to achieve economic advantages, the feasible constellation size is selected as the size that makes the total cost of the orbital processing architecture tasks lower than that of the ground processing architecture.

[0095] As an example, let's assume we calculate the total daily mission cost of the orbital processing architecture for five candidate scales: 100, 120, 140, 160, and 180 stars. The daily costs for the orbital processing architecture are $210, $195, $188, $185, and $185, respectively.

[0096] The daily cost of the ground processing architecture is $3,050. In this example, the cost of orbit processing for all candidate sizes is lower than that of ground processing, indicating that orbit processing is economically advantageous under the current parameters.

[0097] As a comparative example, if the compression ratio is increased and the launch cost is reduced, it may be possible to find a range where the cost of orbital processing is lower than that of ground processing. For example, after parameter optimization, the cost of orbital processing for a constellation of 160 stars drops to $185 per day, lower than the $3,050 per day for ground processing. In this case, 160 stars would be a constellation size with economic advantages.

[0098] Through the above operations, this application embodiment achieves constellation size optimization that comprehensively considers thermal constraints, economies of scale, and total mission cost. This method considers both the physical limitations of the orbital thermal environment on single-satellite computing power and the prediction of hardware costs at different scales using a two-component learning curve. Finally, by comparing total mission costs, it finds the constellation size that economically meets the preset goals, providing a quantitative decision-making basis for the engineering design of orbital edge computing systems.

[0099] After determining the economically optimal constellation size in operation S250, this application embodiment further includes a Monte Carlo robustness assessment step to further verify the reliability of this conclusion under parameter uncertainty conditions. This step assesses the confidence interval of the economically optimal constellation size and its cost savings rate by considering the probability distribution of key parameters, providing quantitative risk analysis for decision-making.

[0100] Step S260: Apply probability distributions to key parameters and evaluate the robustness of the economically optimal constellation size under parameter uncertainty using Monte Carlo simulation.

[0101] First, the key parameters requiring uncertainty analysis and their probability distributions are identified. According to embodiments of this application, the key parameters affecting the economics of orbital edge computing mainly include launch cost, satellite platform learning rate, commercial payload learning rate, and on-board data compression ratio. These parameters exhibit uncertainty in practical engineering; for example, launch prices fluctuate with the market, learning rates vary due to differences in manufacturing processes, and the compression ratio depends on the actual performance of the on-board algorithm.

[0102] As an example rather than a limitation, the following probability distribution is set for each key parameter:

[0103] launch cost It follows a normal distribution, with a mean μ = $5500 / kg and a standard deviation σ = $1500 / kg, denoted as . ~ N(5500, 1500). This distribution reflects the price fluctuation range in the commercial launch market, covering current mainstream prices and potential future price reductions.

[0104] Satellite platform learning rate : It follows a normal distribution, with a mean μ = 0.85 and a standard deviation σ = 0.03, denoted as ~ N(0.85, 0.03). This distribution reflects the uncertainty of manufacturing processes and batch production effects of different satellite platforms.

[0105] Commercial payload learning rate : It follows a normal distribution, with a mean μ = 0.95 and a standard deviation σ = 0.02, denoted as ~N(0.95, 0.02). This distribution reflects the uncertainty in the procurement price of commercial components.

[0106] The on-board data compression ratio α follows a uniform distribution with a lower limit of a=50 and an upper limit of b=150, denoted as α ~ U(50, 150). This distribution reflects the possible range of compression ratio values ​​under different task scenarios and algorithm efficiencies.

[0107] Secondly, the sampling number for the Monte Carlo simulation is set. To ensure the stability of the statistical results, this application embodiment uses no less than 5000 random samplings. As an example, the total number of samplings n=5000.

[0108] Then, Monte Carlo iteration calculations are performed. For each sample i (i = 1 to 5000):

[0109] A set of parameter values ​​is independently and randomly selected from the probability distributions of each key parameter: , , α;

[0110] Substitute the extracted parameter values ​​into the method described in operations S210 to S250 to calculate the economically optimal constellation size under the current parameter sample. and its corresponding daily cost savings rate S⁽ 1 ⁾, where the cost saving rate is defined as:

[0111] S = ( - ) / × 100%

[0112] Positive values ​​indicate that the orbital processing architecture has an economic advantage, while negative values ​​indicate that the ground processing architecture is superior.

[0113] Repeat the above process until all 5000 samples are completed, obtaining 5000 sets of economically optimal constellation sizes. Sample data on cost savings rate S.

[0114] Next, statistical analysis was performed on the simulation results. The 5000 cost-saving rate samples were sorted, and their statistical quantiles were calculated:

[0115] P5 quantile: This indicates the cost savings rate at least as low as the 5% pessimistic scenario. In other words, 5% of the sample results are below this value, and 95% of the sample results are above it.

[0116] P50 quantile (median): Represents the cost savings rate under typical circumstances.

[0117] The 95th percentile indicates that, under 95% optimistic conditions, the cost savings rate will not exceed this value. That is, 95% of the sample results are below this value, and 5% of the sample results are above this value.

[0118] At the same time, the optimal constellation size for economic purposes We perform statistical analysis on the distribution, calculate its mode, mean, and main distribution intervals, and identify the most likely optimal size range.

[0119] Finally, the robustness assessment conclusions are output. Based on the statistical analysis results, the impact of parameter uncertainty on economic feasibility is assessed:

[0120] If the P5 quantile is still positive and significantly greater than zero, it indicates that even under pessimistic parameter assumptions, the orbital processing architecture still has economic advantages, and the conclusion has high robustness.

[0121] If the P5 quantile is negative, it indicates that there is a certain probability (greater than 5%) that the orbital processing architecture is not economically advantageous, and the source of risk needs further analysis.

[0122] As an example, suppose that after 5000 Monte Carlo simulations, the statistical results of the cost savings rate are as follows: P5 quantile: 89%; P50 quantile: 94%; P95 quantile: 97%.

[0123] The results show that even in the most pessimistic 5% scenario, the orbital processing architecture can still achieve 89% daily cost savings; in the typical scenario, it can achieve 94% cost savings; and in the most optimistic scenario, it can reach 97%. This statistical analysis verifies that the economic advantages of orbital edge computing over ground processing are highly robust, and the impact of parameter uncertainty on the conclusions is limited.

[0124] Economically optimal constellation size The distribution statistics can be used as a reference range for engineering design. For example, if The mode is 160, and 90% of the sampling results are concentrated between 150 and 170. Therefore, a constellation-scale design scheme with 160 as the core and a reserved adjustment space of ±10 can be recommended.

[0125] Through the Monte Carlo robustness assessment described above, the embodiments of this application not only provide a deterministic optimal constellation size, but also quantify the impact of parameter uncertainty on economic conclusions, providing decision-makers with more comprehensive risk information and enhancing the credibility of the technical solution in practical engineering applications.

[0126] In some embodiments, the maximum sustainable computing power of a single satellite is determined in the following ways:

[0127] First, obtain the thermal emissivity, effective radiative heat dissipation area, and upper limit of operating temperature for a single satellite. Thermal emissivity ε is a radiation characteristic parameter of the satellite's heat dissipation surface, typically ranging from 0.8 to 0.95, depending on the material and coating of the heat dissipation surface. Effective radiative heat dissipation area... This refers to the effective surface area of ​​a satellite used to radiate heat into space, measured in square meters. Its size depends on the satellite's configuration and heat dissipation surface design. Upper operating temperature limit. This refers to the highest permissible temperature at which a spaceborne computing device can operate stably for a long period of time. It is usually determined by the reliability requirements of electronic components, with a typical value of 313K (40°C).

[0128] Secondly, the radiator temperature of a single satellite is determined based on the range of variation of the β angle in its orbit. The β angle is the angle between the satellite's orbital plane and the solar vector; its range determines the duration and angle of solar radiation received by the satellite during its orbital operation, thus affecting the heat sink temperature of the radiator. For a given orbital altitude and inclination, the variation pattern of the β angle is definite, thereby allowing the determination of the radiator temperature. The fluctuation range. For example, in a 550km sun-synchronous orbit, changes in the β angle lead to variations in radiator temperature. It fluctuates between 250K and 280K.

[0129] Then, by substituting the thermal emissivity, Stefan-Boltzmann constant, effective radiative heat dissipation area, upper limit of operating temperature, and radiator temperature into the thermal radiation equation, the sustainable power limit for a single satellite is calculated. The Stefan-Boltzmann constant σ is 5.67 × 10⁻ 8 W / (m²·K 4 The equation for thermal radiation is:

[0130]

[0131] in, Here, is the Stefan-Boltzmann constant, with a value of 5.67 × 10⁻ 8 W / (m²·K 4 ).

[0132] Finally, based on the calculated sustainable power limit and the energy efficiency ratio of the onboard computing equipment (unit: Determine the maximum sustainable computing power of a single satellite. .in, This refers to the actual energy efficiency ratio of the onboard computing equipment.

[0133] As an example, and not a limitation, for a satellite in a 550km sun-synchronous orbit, the change in the β angle leads to a decrease in radiator temperature. The upper limit of the operating temperature for spaceborne computing equipment fluctuates within the range of 250-280K. Typically 313K (40°C), effective radiative heat dissipation area The area is approximately 2 m², and the thermal emissivity ε is taken as 0.85. Under these conditions, the upper limit of sustainable power is calculated. It is approximately 300W. If a modern AI accelerator (such as the NVIDIA A100) is used, its peak energy efficiency is approximately 30%. However, during continuous operation, the throttling rate needs to be reduced by 50% to ensure thermal stability; the actual energy efficiency ratio is taken as 15. The maximum sustainable computing power of a single satellite Approximately 10 TFLOPS.

[0134] It should be noted that the above parameter values ​​are for illustrative purposes only, and can be adjusted according to the specific satellite design, orbital parameters, and type of computing equipment in actual applications.

[0135] In some embodiments, the two-component learning curve cost model can be expressed as:

[0136]

[0137] in, Let $i$ be the hardware manufacturing cost of the i-th satellite in the candidate constellation. The platform cost for the first satellite in the candidate constellation, The payload cost of the first satellite in the candidate constellation. For satellite platform learning rate, For commercial payload learning rates, and ≠ .

[0138] The physical meaning of learning rate is: the proportion of unit cost retained when cumulative output doubles. For example, a learning rate of 0.85 means that when output doubles, unit cost drops to 85% of its original level, or a reduction of 15%.

[0139] For example, a satellite platform may include basic service subsystems such as a structural system, power system, attitude control system, thermal control system, and onboard computer. Its manufacturing process benefits from mass production and process optimization, resulting in a low learning rate. In one embodiment, such as... Figure 3A As shown, It can take the value 0.85. The value is 0.95. Commercial payloads (such as GPU computing units) are mature commercial components with relatively rigid prices, limited room for cost reduction through large-scale procurement, and high learning rates. For satellite platforms ( =0.85) and commercial GPU load ( =0.95) Applying different learning rates yields a more conservative but realistic cost reduction trajectory (red line), compared to the simple uniform learning rate assumption (gray dashed line).

[0140] According to an embodiment of this application, the constellation size lower limit determined in operation S220 is... Based on this, this operation further selects multiple values ​​greater than... The size of the candidate constellations, for example , , ... , forming the candidate size set { For each candidate size Calculate the sum of the hardware manufacturing costs of all satellites at this scale, i.e., the total hardware manufacturing cost of the constellation. .

[0141] As an example, and not a limitation, it is assumed that... = $5 million = $3 million = 0.85, = 0.95. For With a constellation size of 100 satellites, the platform cost of the 100th satellite can be calculated as 500 × 100^{log2(0.85)} US dollars, and the payload cost as 300 × 100^{log2(0.95)} US dollars. Adding these two together gives the hardware cost of the 100th satellite. Summing over all satellites, the total hardware cost of the constellation is approximately (500 + 300) × 100 × 0.63 ≈ 504 million US dollars, where 0.63 is the comprehensive learning factor, representing a 37% cost reduction compared to the first prototype.

[0142] In some embodiments, determining the total task cost of the orbital processing architecture and the ground processing architecture for each candidate constellation size based on the hardware manufacturing cost corresponding to each candidate constellation size can be achieved in the following specific ways:

[0143] First, obtain the launch cost, operating cost, ground leveling calculation cost, and data downlink communication cost.

[0144] Launch cost refers to the expense of transporting a satellite to its target orbit, typically priced per unit mass. As an example, based on current commercial launch market prices, launch cost... The value can be set at $5,500 per kg, which covers the entire process of rocket launch, satellite-rocket separation, and orbital injection.

[0145] Operating costs refer to the routine maintenance and management expenses required during the constellation's operation in orbit, including ground station maintenance, mission control, orbit maintenance, software updates, and troubleshooting. As an example, operating costs... It is usually estimated at 20% to 30% of the hardware manufacturing cost of the constellation.

[0146] Ground leveling calculation cost This refers to the total lifecycle cost of a unit of computing power processed by a terrestrial data center, encompassing data center construction, power consumption, equipment depreciation, and operation and maintenance. As an example, based on pricing from mainstream cloud service providers, Available at $0.005 / GFLOP-hour.

[0147] Data downlink communication cost This refers to the cost of transmitting a unit of data from a satellite to a ground station, including ground station rental, antenna usage, and spectrum allocation. As an example, based on Ka-band satellite communication market prices, Available for $3 / GB.

[0148] Secondly, based on the hardware manufacturing cost, launch cost, and operating cost of each candidate constellation, the leveled orbit calculation cost corresponding to the size of each candidate constellation is calculated.

[0149] Leveling orbit calculation cost This is the unit computational cost obtained by amortizing the total lifecycle cost of the orbit processing architecture across the total computational load. For a given candidate constellation size N, the calculation formula is:

[0150]

[0151] in, Number of satellites in the constellation. The hardware manufacturing cost of the i-th satellite in the candidate constellation is determined by the two-component learning curve. Mass of a single star (kg). Launch cost (USD / kg). Operating costs. Total computing power (FLOPs) over the lifetime of the task.

[0152] The physical meaning of this calculation process is as follows: The cost is calculated by including all hardware, launch, and operation / maintenance costs required for constellation construction, and then dividing this cost by the total computational output achievable throughout the mission. This yields the unit cost of orbital calculations. This metric can be used for horizontal comparison with the unit cost of ground-based calculations.

[0153] This means summing the hardware cost and launch cost of each satellite, and then adding the operating cost of the entire constellation to get the total cost of the orbital processing architecture.

[0154] The calculation method is as follows:

[0155]

[0156] in This represents the maximum sustainable computing power (GFLOPS) of a single star. The task lifetime is 3600, which is the conversion factor between hours and seconds, used to convert GFLOPS·hours to GFLOPs.

[0157] The physical meaning of this calculation process is as follows: The cost includes all the hardware investment required to build the constellation, the launch cost of each satellite, and the operation and maintenance cost of the entire constellation. This cost is then divided by the total computational output achievable throughout the mission to obtain the unit cost of orbital calculations. This metric can be used for horizontal comparison with the unit cost of ground-based calculations.

[0158] Finally, based on the leveled orbit calculation cost, the ground leveling calculation cost, and the data downlink communication cost, the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale is calculated.

[0159] Total mission cost refers to the total daily expense required to complete a specific remote sensing mission. For ground-based processing architectures, total mission cost... This includes downlink data communication costs and terrestrial computing costs:

[0160]

[0161] in, W represents the amount of raw data generated daily (GB / day), and W represents the amount of computation required daily (GFLOP / day).

[0162] For the orbit processing architecture, the total task cost This includes downlink communication costs and orbit calculation costs for compressed data:

[0163] (N) =

[0164] Where α is the on-board data compression ratio. Through the above calculations, the corresponding data size N for each candidate constellation can be obtained. (N), and with The comparison will provide a quantitative basis for optimizing the constellation scale in the subsequent S250 operation.

[0165] As an example, suppose the parameters of a task are as follows: daily raw data volume = 1000 GB, Daily computational load W = 10 4 GFLOP, compression ratio α = 100, data downlink cost = $3 / GB, Ground computing cost = $0.005 / GFLOP-hour / for a candidate size of N=100 stars, calculated =0.018 USD / GFLOP-hour. Therefore:

[0166] = 1000×3 + 10 4×0.005 = 3000 + 50 = $3050 / day

[0167] (100) = (1000 / 100)×3 + 10 4 ×0.018 = 30 + 180 = $210 / day

[0168] Calculations show that, under these example parameters, the total daily mission cost of an orbital processing architecture with 100 satellites is $210, higher than the $3,050 cost of a ground-based processing architecture, representing a cost saving of 93%.

[0169] According to embodiments of this application, as the constellation size increases, the inter-satellite link coordination overhead increases, which may prevent the effective computing power of a single satellite from being fully utilized. Therefore, this application introduces a communication efficiency correction factor to dynamically adjust the effective computing power.

[0170] First, determine the formula for calculating the communication efficiency correction factor.

[0171] Communication efficiency correction factor (N) is defined as the ratio of the effective computing power actually available for task processing to the theoretical maximum computing power.

[0172] As an example, when the constellation size N > 100, the communication efficiency correction factor is calculated using the following formula:

[0173] (N) = 0.9 - 0.002 × (N - 100)

[0174] When N ≤ 100, take (N) = 1.

[0175] The physical meaning of this formula is:

[0176] When N ≤ 100, the coordination overhead is negligible, and the efficiency is 1;

[0177] When N > 100, the efficiency decreases by 0.002 (i.e. 0.2%) for each additional satellite.

[0178] For example, when N=150, = 0.9 - 0.002 × 50 = 0.8;

[0179] When N=180, = 0.9 - 0.002 × 80 = 0.74.

[0180] Secondly, the correction factor is applied to the calculation of effective computing power.

[0181] The effective computing power of a single satellite is:

[0182] (N) = × (N)

[0183] The total computing power of the constellation during the mission's lifespan is:

[0184] = N × (N) × T_mission × 3600

[0185] The cost of leveling orbit calculations is adjusted accordingly as follows:

[0186]

[0187] As an example, consider a candidate size of N=180 stars:

[0188] Single-star theoretical calculation capability = 10 TFLOPS

[0189] Communication efficiency correction factor (180) = 0.74

[0190] Effective computing power of a single star = 10 × 0.74 = 7.4 TFLOPS

[0191] Without considering communication efficiency corrections, the total computing power of the constellation would be overestimated by about 35%, leading to an overly optimistic estimate of economic viability.

[0192] Finally, the impact of the modified model on constellation-scale optimization is discussed.

[0193] like Figure 3B As shown, The curves showing the variation of candidate constellation size N. Three regions: high fixed cost region (N<50), optimal size region (N=100-180), and coordination overhead region (N>180). Figure 3C As shown, An economic feasibility heatmap of the parameter space. Dashed contour lines mark the break-even point. Asterisks indicate baseline parameters (…). , It is located in a region with a strong economic advantage.

[0194] According to embodiments of this application, based on determining the economically optimal constellation size, to further assess the impact of key parameter fluctuations on economic conclusions, this application also includes a multi-parameter sensitivity analysis step. This step systematically changes the values ​​of key parameters and observes their impact on daily cost savings, providing a quantitative basis for engineering decisions.

[0195] First, determine the key parameters for which sensitivity analysis is required and their scanning range.

[0196] As an example rather than a limitation, the scan ranges for each key parameter are set as follows:

[0197] Data downlink bandwidth cost The scan range is from $0.5 to $5 / GB, covering the current market price ($3 / GB) and potential future fluctuations.

[0198] launch cost The scanning range is $400 to $8,000 / kg, covering the price range from low-cost Starship-class launches to conventional launches.

[0199] On-board data compression ratio α: The scanning range is 1 to 250, covering the full spectrum from no compression to efficient semantic compression.

[0200] Secondly, a single-parameter sensitivity analysis was performed.

[0201] Example 1: Bandwidth Cost Sensitivity Analysis

[0202] Fixed launch cost = $5500 / kg, compression ratio α = 100, bandwidth cost Scan from $0.5 / GB to $5 / GB. Calculate the daily cost saving rate S for each bandwidth cost value:

[0203] S = ( - ) / × 100%

[0204] like Figure 3D As shown, daily cost savings vary with bandwidth costs. The change (α=100). A 93% saving at the current Ka-band pricing ($3 / GB). Even Even at $0.50 / GB (a 6-fold reduction), it still maintains a 66% advantage.

[0205] Example 2: Launch Cost Sensitivity Analysis

[0206] Fixed bandwidth cost = $3 / GB, compression ratio α = 100, reducing launch cost The cost ranges from $400 / kg to $8000 / kg. For each launch cost value, the cost of calculating the leveled orbit is determined. .

[0207] like Figure 3E As shown, launch cost Sensitivity. At Starship-class pricing ($400 / kg), the calculated premium decreased from 3.6 times to 2.1 times.

[0208] According to an embodiment of this application, let = The critical compression ratio α* at break-even can be derived:

[0209] (Vraw / α∗)×cbw+W×LCOCorb=Vraw×cbw+W×LCOCgnd

[0210] After sorting, we get:

[0211]

[0212] The physical meaning of this formula is that the compression ratio required to break even depends on the balance between communication cost savings and computing cost premiums.

[0213] As an example, typical remote sensing mission parameters consistent with those used in operation S240 are employed:

[0214] Daily raw data volume = 1000 GB

[0215] Daily computational load W = 10 4 GFLOP

[0216] Data downlink cost = $3 / GB

[0217] Ground calculation cost = $0.005 / GFLOP-hour

[0218] Track calculation cost = $0.0155 / GFLOP-hour

[0219] Substitute into the formula to calculate:

[0220] W × ( - ) = 10 4 × 0.0105 = $105 / day

[0221] × = 1000 × 3 = $3000 / day

[0222] *α = 1 / (1 - 105 / 3000) = 1 / (1 - 0.035) ≈1.04**

[0223] As a comparative example, if the cost of orbital computation drops to = $0.006 / GFLOP-hour, then:

[0224] W × ( - ) = 10 4 × 0.001 = $10 / day

[0225] *α = 1 / (1 - 10 / 3000) = 1 / (1-1 / 300) ≈1.003

[0226] That is, only 1.003 times compression (that is, about 0.3% data compression) is needed to break even.

[0227] Specifically, according to simulation verification in this application, the break-even critical compression ratio α* can be as low as approximately 1.04 in typical remote sensing mission scenarios. The engineering implication of this value is that only about 4% data compression (equivalent to basic cloud filtering) is required to make the orbital processing architecture economically advantageous. This indicates that orbital edge computing is universally applicable, and the vast majority of remote sensing missions can meet the break-even requirements without complex algorithms.

[0228] like Figure 3F The figure shows the daily cost savings as a function of the compression ratio α. The graph indicates that the break-even point is reached at α*≈1.04; the cost savings increase rapidly after α>1.04; and the growth plateaus when α reaches around 50. This provides quantitative guidance for designing the compression ratio of on-board processing algorithms.

[0229] Next, a two-parameter sensitivity analysis was performed and a heatmap was plotted.

[0230] With compression ratio α and bandwidth cost As a two-parameter analysis object, fixed launch cost = $5500 / kg. Scan α from 1 to 250, Scan from $0.5 / GB to $5 / GB. For each parameter combination, calculate the daily cost savings rate and present it as a heatmap.

[0231] like Figure 3CAs shown, (α, Economic feasibility heatmap of parameter space. In the figure:

[0232] The horizontal axis represents the compression ratio α, and the vertical axis represents the bandwidth cost. ;

[0233] Different colors indicate the magnitude of daily cost savings;

[0234] The dashed contour lines mark the break-even point (cost savings rate is 0).

[0235] Baseline parameter points are marked with asterisks (α=100, =3 USD / GB), located in a region with deep economic advantages.

[0236] As can be seen from the heatmap, when the compression ratio α > 10, orbital processing still has an economic advantage even with bandwidth costs as low as $0.5 / GB.

[0237] Finally, the conclusions of the sensitivity analysis were synthesized.

[0238] The above analysis shows that: the higher the bandwidth cost, the more significant the economic advantage of orbit processing; the reduction in launch cost can linearly improve the orbit calculation cost; the compression ratio is a key parameter, and only α* ≈ 1.04 is needed to break even, and a compression ratio of 50-100 times can achieve cost savings of more than 90%; the parameter tolerance range is wide, and the orbit processing architecture maintains its economic advantage within a parameter variation range of up to two orders of magnitude.

[0239] In some embodiments, the on-board data compression ratio α is a key parameter affecting the communication cost of the orbital processing architecture. According to embodiments of this application, the on-board data compression ratio can be determined based on the cloud cover ratio and the region of interest retention ratio:

[0240]

[0241] Where α is the on-board data compression ratio. This refers to the proportion of invalid data caused by cloud cover, that is, the proportion of remote sensing images that are obscured by clouds and cannot be used for target identification. The region of interest retention ratio refers to the proportion of the original image that contains valid information and is retained after on-board intelligent processing.

[0242] The physical meaning of this model is that raw remote sensing images contain a large amount of invalid data, such as areas covered by clouds, oceans, and other areas that do not require attention. By performing semantic filtering and intelligent recognition in orbit, this invalid data can be discarded, retaining only the processing results for the regions of interest, thereby significantly reducing the amount of data that needs to be downlinked. The compression ratio α is the ratio of the original data volume to the processed data volume.

[0243] Cloud coverage ratio This can be determined based on long-term observational data from organizations such as the International Satellite Cloud Climatology Project (ISCCP). For example, the global average cloud cover is approximately 0.6, meaning that about 60% of the remote sensing image area may be obscured by clouds. (Region of Interest Retention Ratio) It depends on the specific mission objectives and the filtering efficiency of the onboard intelligent algorithm. For example, for ship detection missions, only the sub-regions containing ships in the ocean area need to be retained, and the retention ratio can be as low as 0.025.

[0244] As an example, suppose the cloud cover ratio for a certain remote sensing task is... =0.6, Region of Interest Retention Ratio =0.025, then the compression ratio is:

[0245] = 1 / [(1-0.6) × 0.025] = 1 / (0.4 × 0.025) = 1 / 0.01 = 100

[0246] This means that after on-board processing, the downlink data volume is only 1% of the original data volume, achieving a compression ratio of 100 times. Incorporating this compression ratio into the total mission cost calculation can significantly reduce the communication costs of the orbital processing architecture.

[0247] It should be noted that, and The value of is related to the specific mission scenario, orbital parameters, and on-board processing algorithms. In practical applications, it should be calibrated according to mission characteristics and data statistics.

[0248] Based on the above-described method for determining constellation size using orbital edge calculation, this application also provides a device for determining constellation size using orbital edge calculation. The following will be combined with... Figure 4 The device is described in detail.

[0249] Figure 4 A schematic block diagram of a constellation size determination device for orbital edge calculation according to an embodiment of this application is shown.

[0250] like Figure 4As shown, the orbital edge calculation constellation size determination device of this embodiment includes a capability determination module 410, a size determination module 420, a prediction module 430, a cost determination module 440, and a constellation determination module 450.

[0251] The capability determination module 410 is used by the capability determination module to determine the maximum sustainable computing capability of a single satellite based on the thermal constraints of the single satellite. In one embodiment, the capability determination module 410 can be used to perform the operation S210 described above, which will not be repeated here.

[0252] The scale determination module 420 is used to determine the lower limit of the constellation size required to meet the computing power requirements based on the maximum sustainable computing power and the computing power requirements of the task. In one embodiment, the scale determination module 420 can be used to perform the operation S220 described above, which will not be repeated here.

[0253] The prediction module 430 is used to input the lower limit of the constellation size and multiple candidate constellation sizes greater than the lower limit into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads, and to predict the hardware manufacturing cost corresponding to each candidate constellation size. In one embodiment, the prediction module 430 can be used to perform the operation S230 described above, which will not be repeated here.

[0254] The cost determination module 440 is used to determine the total mission cost of the orbital processing architecture and the ground processing architecture for each candidate constellation size based on the hardware manufacturing cost corresponding to each candidate constellation size. In one embodiment, the cost determination module 440 can be used to perform the operation S240 described above, which will not be repeated here.

[0255] The constellation determination module 450 is used to compare the total mission costs of the orbital processing architecture and the ground processing architecture to determine the constellation size that economically meets the preset target. In one embodiment, the constellation determination module 450 can be used to perform the operation S240 described above, which will not be repeated here.

[0256] According to an embodiment of this application, determining the maximum sustainable computing power of a single satellite based on its thermal constraints includes:

[0257] Obtain the thermal emissivity, effective radiative heat dissipation area, and upper limit of operating temperature of the single satellite;

[0258] The radiator temperature of the single satellite is determined based on the range of variation of the orbital angle β of the single satellite.

[0259] Substitute the thermal emissivity, Stefan-Boltzmann constant, effective radiative heat dissipation area, upper limit of operating temperature, and radiator temperature into the thermal radiation equation to calculate the upper limit of sustainable power for the single satellite.

[0260] The maximum sustainable computing capacity of a single satellite is determined based on the sustainable power limit and the energy efficiency ratio of the onboard computing equipment of the single satellite.

[0261] According to an embodiment of this application, the two-component learning curve cost model is expressed as follows:

[0262]

[0263] in, Let $i$ be the hardware manufacturing cost of the i-th satellite in the candidate constellation. The platform cost for the first satellite in the candidate constellation, The payload cost of the first satellite in the candidate constellation. For satellite platform learning rate, For commercial payload learning rates, and ≠ .

[0264] According to an embodiment of this application, determining the total task cost of the orbital processing architecture and the ground processing architecture for each candidate constellation size based on the hardware manufacturing cost corresponding to the size of each candidate constellation includes:

[0265] Acquire launch costs, operating costs, ground leveling calculation costs, and downlink data communication costs;

[0266] Based on the hardware manufacturing cost, launch cost and operating cost of each candidate constellation, calculate the leveled orbit calculation cost corresponding to the size of each candidate constellation.

[0267] Based on the leveled orbit calculation cost, the ground leveled calculation cost, and the data downlink communication cost, calculate the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale.

[0268] According to an embodiment of this application, the step of calculating the leveled orbit calculation cost corresponding to the size of each candidate constellation based on the hardware manufacturing cost, the launch cost, and the operating cost of each candidate constellation includes:

[0269] Obtain the total computational cost corresponding to the task lifetime and the size of each candidate constellation;

[0270] The leveled orbit calculation cost is obtained by dividing the sum of the hardware manufacturing cost, launch cost, and operating cost corresponding to each candidate constellation by the total computational cost over the mission's lifespan.

[0271] According to an embodiment of this application, calculating the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale based on the leveled orbit calculation cost, the ground leveling calculation cost, and the data downlink communication cost includes:

[0272] Obtain the daily amount of raw data generated by the task, the on-board data compression ratio, and the daily computational requirements;

[0273] Based on the original data volume and the downlink communication cost, determine the communication cost of the ground processing architecture;

[0274] The computational cost of the ground processing architecture is determined based on the daily computational requirements and the ground leveling computational cost.

[0275] The total daily task cost of the ground processing architecture is obtained by adding the communication cost and the computing cost of the ground processing architecture.

[0276] The communication cost of the track processing architecture is determined based on the original data volume, the compression ratio, and the downlink communication cost.

[0277] The computational cost of the orbit processing architecture is determined based on the daily computational requirements and the computational cost of the leveled orbit.

[0278] The total daily task cost of the orbit processing architecture is obtained by adding the communication cost and the computing cost of the orbit processing architecture.

[0279] According to an embodiment of this application, the on-board data compression ratio is determined based on the cloud coverage ratio and the region of interest retention ratio:

[0280]

[0281] Where α is the on-board data compression ratio. The proportion of invalid data caused by cloud cover. Reserve a percentage for the region of interest.

[0282] According to embodiments of this application, any multiple modules of the capability determination module 410, size determination module 420, prediction module 430, cost determination module 440, and constellation determination module 450 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the capability determination module 410, size determination module 420, prediction module 430, cost determination module 440, and constellation determination module 450 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the capability determination module 410, scale determination module 420, prediction module 430, cost determination module 440, and constellation determination module 450 may be at least partially implemented as a computer program module that can perform the corresponding function when the computer program module is run.

[0283] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a constellation size determination method based on an embodiment of this application.

[0284] like Figure 5 As shown, an electronic device according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0285] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 502 and / or RAM 503. It should be noted that programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0286] According to embodiments of this application, the electronic device may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output (I / O) interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output (I / O) interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0287] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0288] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0289] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the orbital edge calculation constellation size determination method provided in the embodiments of this application.

[0290] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0291] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0292] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0293] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0294] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0295] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for determining constellation size based on orbital edge calculation, characterized in that, include: Based on the thermal constraints of a single satellite, determine the maximum sustainable computing power of that single satellite; Based on the maximum sustainable computing power and the computing power requirements of the task, determine the lower limit of the constellation size required to meet the computing power requirements; The lower limit of the constellation size and multiple candidate constellation sizes larger than the lower limit are respectively input into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads to predict the hardware manufacturing cost corresponding to each candidate constellation size. Based on the hardware manufacturing cost corresponding to the size of each candidate constellation, determine the cost under each candidate constellation size. Total mission cost of orbital processing architecture versus ground processing architecture; By comparing the total mission costs of the orbital processing architecture and the ground processing architecture, the constellation size that meets the preset goals in terms of economy is determined.

2. The method according to claim 1, characterized in that, Determining the maximum sustainable computing power of a single satellite based on its thermal constraints includes: Obtain the thermal emissivity, effective radiative heat dissipation area, and upper limit of operating temperature of the single satellite; The radiator temperature of the single satellite is determined based on the range of variation of the orbital angle β of the single satellite. Substitute the thermal emissivity, Stefan-Boltzmann constant, effective radiative heat dissipation area, upper limit of operating temperature, and radiator temperature into the thermal radiation equation to calculate the upper limit of sustainable power for the single satellite. The maximum sustainable computing capacity of a single satellite is determined based on the sustainable power limit and the energy efficiency ratio of the onboard computing equipment of the single satellite.

3. The method according to claim 1, characterized in that, The two-component learning curve cost model is expressed as follows: in, Let $\frac{i}{i}$ be the hardware manufacturing cost of the $i$-th satellite in the candidate constellation. The platform cost for the first satellite in the candidate constellation, The payload cost of the first satellite in the candidate constellation. For satellite platform learning rate, For commercial payload learning rates, and ≠ .

4. The method according to claim 1, characterized in that, The determination of the total task cost of the orbital processing architecture and ground processing architecture for each candidate constellation size, based on the hardware manufacturing cost corresponding to the size of each candidate constellation, includes: Acquire launch costs, operating costs, ground leveling calculation costs, and downlink data communication costs; Based on the hardware manufacturing cost, launch cost and operating cost of each candidate constellation, calculate the leveled orbit calculation cost corresponding to the size of each candidate constellation. Based on the leveled orbit calculation cost, the ground leveled calculation cost, and the data downlink communication cost, calculate the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale.

5. The method according to claim 4, characterized in that, The step of calculating the leveled orbit calculation cost corresponding to the size of each candidate constellation based on the hardware manufacturing cost, launch cost, and operating cost of each candidate constellation includes: Obtain the total computational cost corresponding to the task lifetime and the size of each candidate constellation; The leveled orbit calculation cost is obtained by dividing the sum of the hardware manufacturing cost, launch cost, and operating cost corresponding to each candidate constellation by the total computational cost over the mission's lifespan.

6. The method according to claim 4, characterized in that, The calculation of the total task cost of the orbit processing architecture and the ground processing architecture for each candidate constellation scale, based on the leveled orbit calculation cost, the ground leveling calculation cost, and the data downlink communication cost, includes: Obtain the daily amount of raw data generated by the task, the on-board data compression ratio, and the daily computational requirements; Based on the amount of raw data and the downlink communication cost, determine the communication cost of the ground processing architecture; The computational cost of the ground processing architecture is determined based on the daily computational requirements and the ground leveling computational cost. The total daily task cost of the ground processing architecture is obtained by adding the communication cost and the computing cost of the ground processing architecture. The communication cost of the track processing architecture is determined based on the original data volume, the compression ratio, and the downlink communication cost. The computational cost of the orbit processing architecture is determined based on the daily computational requirements and the computational cost of the leveled orbit. The total daily task cost of the orbit processing architecture is obtained by adding the communication cost and the computing cost of the orbit processing architecture.

7. The method according to claim 6, characterized in that, The on-board data compression ratio is determined based on the cloud coverage ratio and the region of interest retention ratio: Where α is the on-board data compression ratio. The proportion of invalid data caused by cloud cover. Reserve a percentage for the region of interest.

8. A device for determining constellation size by calculating orbital edges, characterized in that, include: The capability determination module is used to determine the maximum sustainable computing capability of a single satellite based on the thermal constraints of that single satellite. The scale determination module is used to determine the lower limit of the constellation scale required to meet the computing power requirements based on the maximum sustainable computing power and the computing power requirements of the task. The prediction module is used to input the lower limit of the constellation size and multiple candidate constellation sizes greater than the lower limit into a pre-established two-component learning curve cost model that distinguishes between satellite platforms and commercial payloads, and to predict the hardware manufacturing cost corresponding to each candidate constellation size. The cost determination module is used to determine the total task cost of the orbital processing architecture and the ground processing architecture under each candidate constellation scale based on the hardware manufacturing cost corresponding to each candidate constellation scale. The constellation determination module is used to compare the total mission cost of the orbital processing architecture with that of the ground processing architecture to determine the constellation size that is economically compatible with preset goals.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images