Multi-coordinate system satellite orbit prediction method, system, equipment and medium

Abstract

This invention relates to the field of satellite telemetry, tracking, and command (TT&C) technology, and provides a satellite orbit prediction method, system, equipment, and medium for a multi-coordinate system. The method includes the following steps: S1: Receiving prediction request parameters input by the user, the prediction request parameters including satellite identifier and prediction type; S2: Obtaining the satellite orbit status based on the satellite identifier; S3: Identifying the prediction algorithm to be used based on the prediction type; S4: Performing prediction based on the satellite orbit status and the prediction algorithm; S5: Outputting the prediction result. This solution can unify the multi-coordinate system prediction interface, improve prediction efficiency, simplify the operation process, ensure data consistency, optimize coordinate transformation, and enhance system scalability.

Description

Technical Field

[0001] This invention relates to the field of satellite telemetry, tracking, and command (TT&C) technology, and in particular to a satellite orbit prediction method, system, equipment, and medium based on a multi-coordinate system. Background Technology

[0002] With the rapid development of satellite technology, satellite orbit prediction is playing an increasingly important role in fields such as space mission planning, telemetry and control system design, collision warning, and communication link analysis. Satellite orbit prediction refers to predicting the position and velocity of a satellite at a future moment based on known orbital parameters through numerical integration or analytical methods.

[0003] In the process of satellite orbit prediction, different coordinate systems are needed to represent the orbital state of satellites due to different application scenarios and requirements.

[0004] Currently, existing satellite orbit prediction systems and methods suffer from the following technical problems: First, coordinate system transformation is complex and inefficient. Existing orbit prediction systems are typically designed for a single coordinate system. When forecast results in different coordinate systems are needed, it requires: calling different prediction interfaces or modules separately; manually performing coordinate system transformations; and repeatedly calculating the same orbit state. This approach has the following problems: Dispersed interfaces: Prediction interfaces for different coordinate systems are independent, requiring users to understand the calling methods and parameter formats of each interface, resulting in a high learning curve. Cumbersome transformations: Switching between multiple systems or modules and manually performing coordinate transformations is complex and prone to errors. Computational redundancy: For the orbit state at the same moment, orbit integration calculations need to be repeated in different coordinate systems, wasting computational resources. Data inconsistency: Due to multiple calls and transformations, data in different coordinate systems may have time deviations or accuracy losses.

[0005] Second, special event forecasts are separated from orbital forecasts. Forecasts of special events such as Earth shadows, lunar shadows, and solar outages typically require calculations based on orbital forecast results. However, existing systems often separate these two processes: orbital forecasts must be performed first to obtain satellite positions, and then the special event forecast module must be called to manually integrate the two types of forecast results. This approach leads to: complex processes: users need to operate step by step, making it impossible to obtain complete forecast information at once. Difficult time synchronization: the calculation time bases of different modules may be inconsistent, leading to time alignment issues in the forecast results. Difficult result integration: users need to manually correlate and analyze the orbital forecast results with the special event forecast results.

[0006] Third, the lack of a unified forecasting framework leads to: inconsistent interfaces: forecasting interface parameter formats and return formats differ across coordinate systems, making unified invocation difficult. Poor scalability: adding new coordinate systems or forecast types requires extensive code modifications, resulting in high system coupling. Difficult maintenance: multiple independent forecasting modules increase the complexity and cost of system maintenance.

[0007] Fourth, there are issues with the accuracy and efficiency of coordinate transformation. Existing systems suffer from the following problems with coordinate transformation: Long transformation chains: Transforming from one coordinate system to another may require multiple intermediate transformations, increasing accumulated errors. Inconsistent transformation algorithms: Different modules may use different transformation algorithms, leading to discrepancies in the transformation results. Poor real-time performance: Coordinate transformation requires additional computation time, affecting the real-time performance of the forecasting system.

[0008] Therefore, there is a need to provide a satellite orbit prediction method, system, equipment, and medium that unifies the multi-coordinate system prediction interface, improves prediction efficiency, simplifies operation procedures, ensures data consistency, optimizes coordinate transformation, and enhances system scalability.

[0009] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0010] The main objective of this invention is to overcome the problems of complex coordinate system transformation, low efficiency, and low accuracy, and to provide a satellite orbit prediction method, system, equipment, and medium that unifies multiple coordinate system prediction interfaces, improves prediction efficiency, simplifies operation procedures, ensures data consistency, optimizes coordinate transformation, and enhances system scalability.

[0011] To achieve the above objectives, the first aspect of the present invention provides a satellite orbit prediction method based on a multi-coordinate system, comprising the following steps: S1: Receive forecast request parameters input by the user, the forecast request parameters including satellite identifier and forecast type; S2: Obtain satellite orbit status based on satellite identifiers; S3: Identify the forecast algorithm to be used based on the forecast type; S4: Make predictions based on satellite orbital status and prediction algorithms; S5: Output the forecast results.

[0012] As an example implementation of the invention, in step S1, the prediction type is the required coordinate system type, including the following eight types: The first type is Kepler orbital elements; The second type is the Earth-fixed coordinate system; The third type is the inertial coordinate system; The fourth type is the geodetic coordinate system; The fifth type is ground shadow forecast; The sixth type is lunar shadow forecast; The seventh type is penumbra prediction; The eighth type is solar eclipse forecast.

[0013] As an example implementation of the invention, in step S2, the satellite orbital state includes initial orbital parameters, which include epoch time, Kepler orbital elements, satellite physical parameters, and orbital mode.

[0014] As an example implementation of the invention, in step S3, identifying the forecast algorithm to be used according to the forecast type includes: formulating a forecast type mapping table to map the forecast type code to the corresponding forecast algorithm; The first type corresponds to the Kepler orbital element prediction algorithm; The second type corresponds to the Earth-fixed coordinate system prediction algorithm; The third type corresponds to the inertial coordinate system prediction algorithm; The fourth type corresponds to the geodetic coordinate system prediction algorithm; The fifth type corresponds to the ground shadow prediction algorithm; The sixth type corresponds to the lunar shadow prediction algorithm; The seventh type corresponds to the penumbra prediction algorithm; The eighth type corresponds to the solar eclipse forecasting algorithm.

[0015] As an example implementation of the invention, step S4, the prediction based on the satellite orbital state and prediction algorithm, includes: For the first, second, third, and fourth types, orbital integration is performed first, followed by coordinate system transformation. For types 5, 6, 7, and 8, the inertial coordinate system prediction algorithm is first invoked to obtain the satellite's position sequence within the prediction time range, and then special event calculations are performed.

[0016] As an example implementation of the invention, the special event calculation includes: For the fifth type, calculate whether the satellite has entered the Earth's shadow zone, determine the geometric relationship between the satellite, the Earth, and the Sun, and calculate whether the satellite is blocked by the Earth; For the sixth type, it is calculated whether the satellite has entered the lunar shadow region. Based on the station information, it is calculated whether the satellite is blocked by the moon when observed from the station, taking into account the latitude, longitude and altitude of the station. For the seventh type, calculate whether the satellite has entered the Earth's penumbra; For the eighth type, it calculates whether the satellite, the sun, and the station are collinear, obtains station information and transit angle parameters, and determines whether the satellite signal is interfered with by the sun.

[0017] As an example implementation of the invention, in step S5, the output forecast result includes: The forecast results will be output in a standardized format, which includes: Time series data, including the orbital state or event state at each time point; Data column definition, including labels and attributes for generating data columns based on forecast type; Metadata information, including forecast parameters, calculation time, and data volume.

[0018] As a second aspect of the present invention, the present invention provides a satellite orbit prediction system with multiple coordinate systems, including a parameter receiving module, an orbit state acquisition module, a prediction type identification module, a unified orbit prediction module, and a result output module; The parameter receiving module is used to receive forecast request parameters input by the user, and the forecast request parameters include satellite identifier and forecast type; The orbit status acquisition module is used to acquire the satellite orbit status based on the satellite identifier; The forecast type identification module is used to identify the forecast algorithm to be used based on the forecast type; The unified orbit prediction module is used to make predictions based on satellite orbit status and prediction algorithms; The result output module is used to output the forecast results.

[0019] As a third aspect of the present invention, the present invention provides an electronic device comprising: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the satellite orbit prediction method of the multi-coordinate system.

[0020] As a fourth aspect of the present invention, the present invention provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the satellite orbit prediction method of the multi-coordinate system.

[0021] The advantages of this invention are: This solution integrates orbit forecasts and special event forecasts across multiple coordinate systems through a unified forecasting framework, improving forecasting efficiency and data consistency while simplifying user operation processes. Details are as follows: First, ease of operation: 1. Unified interface: Users only need to select the forecast type through a unified interface to obtain the forecast results in the required coordinate system, without needing to understand the underlying implementation details. 2. Simplified parameters: The system automatically determines which parameters are needed based on the forecast type. For forecast types that do not require station information, the relevant input items are automatically hidden, simplifying user operation. 3. Intuitive results: Forecast results are automatically adapted into a tabular format with clear column names, facilitating viewing and analysis.

[0022] Second, improved computational efficiency: 1. Avoiding redundant calculations: Through a unified forecasting framework, for the orbital state at the same time, only one orbital integration is needed, followed by coordinate transformation to obtain results in multiple coordinate systems. 2. Optimized transformation paths: Establishing direct transformation paths between coordinate systems reduces intermediate transformation steps and improves transformation efficiency. 3. Parallel computing: For forecast types that can be computed in parallel, the system can perform forecast calculations in multiple coordinate systems simultaneously.

[0023] Third, data consistency is guaranteed: 1. Time synchronization: Prediction results in all coordinate systems are calculated based on the orbital state at the same moment, ensuring complete time synchronization. 2. Consistent accuracy: A unified orbital integration algorithm and coordinate transformation algorithm are used to ensure consistent data accuracy in different coordinate systems. 3. Reduced error accumulation: By optimizing the transformation path and reducing intermediate transformation steps, error accumulation is reduced.

[0024] Fourth, functional integration: 1. Integration of orbit forecasting and special event forecasting: Orbit forecasting is integrated with forecasts of special events such as Earth shadow, lunar shadow, and solar outages within the same framework, allowing users to obtain complete forecast information at once through a unified interface. 2. Multi-coordinate system support: Supports multiple coordinate systems including Kepler elements, Earth-fixed coordinates, inertial coordinates, latitude, longitude, and altitude, meeting the needs of different application scenarios. 3. Strong scalability: Adopts a modular design, facilitating the addition of new coordinate system types or forecasting functions without modifying the core code.

[0025] Fifth, system maintainability: 1. Code reuse: A unified forecasting framework improves code reuse and reduces duplicate code. 2. Module decoupling: Forecasting algorithms for different coordinate systems are treated as independent modules, reducing system coupling. 3. Ease of testing: Modular design facilitates unit testing and integration testing.

[0026] Sixth, practical application value: 1. Improved work efficiency: Users no longer need to switch between multiple systems or modules, greatly improving work efficiency. 2. Lowered barrier to entry: The unified interface lowers the barrier to entry, allowing non-professionals to quickly get started. 3. Reduced error rate: Automated coordinate transformation and parameter processing reduce the possibility of human error. 4. Support for complex scenarios: Particularly suitable for complex application scenarios that require simultaneous acquisition of prediction results from multiple coordinate systems, such as multi-station collaborative observation and multi-satellite formation flight. Attached Figure Description

[0027] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0028] Figure 1 The schematic diagram illustrates the structure of a satellite orbit prediction system based on a multi-coordinate system.

[0029] Figure 2 The diagram illustrates the steps of a satellite orbit prediction method using a multi-coordinate system.

[0030] Figure 3 A schematic diagram of the electronic device is shown.

[0031] Figure 4 A schematic diagram of the structure of a computer medium is shown. Detailed Implementation

[0032] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0033] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0034] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0036] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0037] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0038] The technical problems that this solution aims to solve are as follows: 1. Unified multi-coordinate system forecasting interface: Provides a unified forecasting interface. Users only need to specify the forecasting type (coordinate system type), and the system will automatically call the corresponding forecasting algorithm without needing to understand the underlying implementation details.

[0039] 2. Improve forecast efficiency: By using a unified forecast framework, redundant calculations are avoided, and a single orbital integration can generate forecast results in multiple coordinate systems simultaneously.

[0040] 3. Simplified operation process: The orbit forecast and special event forecast (Earth shadow, lunar shadow, solar outage, etc.) are integrated into the same framework, and users can obtain complete forecast information at one time through a unified interface.

[0041] 4. Ensure data consistency: The forecast results in all coordinate systems are calculated based on the orbital state at the same time to ensure time synchronization and consistent accuracy.

[0042] 5. Optimize coordinate transformation: Establish an efficient coordinate transformation link, reduce intermediate transformation links, and improve transformation accuracy and efficiency.

[0043] 6. Enhanced system scalability: The modular design facilitates the addition of new coordinate system types or prediction functions, reducing system maintenance costs.

[0044] According to a first specific embodiment of the present invention, the present invention provides a satellite orbit prediction system with multiple coordinate systems, such as... Figure 1 As shown, it includes: a satellite orbit prediction system with multiple coordinate systems, including a parameter receiving module, an orbit status acquisition module, a prediction type identification module, a unified orbit prediction module, and a result output module.

[0045] The parameter receiving module is used to receive forecast request parameters input by the user, which include satellite identifier and forecast type.

[0046] The orbital status acquisition module is used to obtain the satellite orbital status based on the satellite identifier, which includes the initial orbital parameters.

[0047] The forecast type identification module is used to identify the forecast algorithm to be used based on the forecast type.

[0048] The unified orbit prediction module is used to make predictions based on satellite orbit status and prediction algorithms.

[0049] The results output module is used to output the forecast results.

[0050] According to a second specific embodiment of the present invention, the present invention provides a satellite orbit prediction method based on a multi-coordinate system, employing a satellite orbit prediction system based on a multi-coordinate system as described in the first specific embodiment, such as... Figure 2 As shown, it includes the following steps: S1: Receive forecast request parameters input by the user.

[0051] The forecast request parameters include satellite identifier, forecast type, time range, time step, and station information.

[0052] The satellite identifier (sateId) is used to identify the target satellite. In step S2, the satellite identifier (sateId) serves as a query key to locate the record corresponding to the satellite in the orbit configuration database and read the initial orbit parameters. In step S5, when outputting metadata information, the satellite identifier is written into the metadata so that the forecast results can be associated with the target satellite.

[0053] The forecast type (forecastType) specifies the required coordinate system type, including the following eight types: The first type is the Kepler orbital element (orbitEle). The second type is the geofixed coordinate system (WGS84). The third type is the inertial coordinate system (j2k, J2000); The fourth type is the geodetic coordinate system (blh, latitude, longitude, and altitude). The fifth type is the Earth Shadow Prediction (umber); The sixth type is moon forecast; The seventh type is penumbra forecast. The eighth type is suntransit.

[0054] In step S3, the forecast type (forecastType) serves as the index key of the mapping table, used to find and determine the forecast algorithm interface function to be called; in step S4, it is used to select the calculation path, i.e., to choose between "first orbital integration and then coordinate system transformation according to type" or "first obtain the inertial frame position sequence and then perform special event calculations"; in step S5, it is used to generate data column definitions (column names, physical quantity meanings, and unit attributes) that match the current forecast type, so that the output table or structured data is consistent with the selected type.

[0055] Time range (start, end): The start and end times of the forecast. In step S4, the time range (start, end) serves as the unified time boundary for orbit propagation and special event retrieval: the generation of orbital integrals and inertial frame position sequences is limited to the time between the start and end times; special event determination is performed at each sampling time based on the satellite position and celestial geometry within this time range; in step S5, the start and end times are written into metadata information and correspond one-to-one with the time columns in the time series data to ensure the results are verifiable.

[0056] Time step (step): The time interval of the forecast results, in seconds. A discrete forecast time sequence {tk} is obtained based on the time range and time step. The time step (step) determines the discretization sampling interval in step S4: during the generation of the orbital integral output and the inertial frame position sequence, the time step is used to advance from the start time to the end time, obtaining the orbital state or event state at each forecast time. In step S5, the time interval between adjacent data rows in the time series data is consistent with the time step. The time step can be recorded in the metadata information for post-processing or plotting purposes.

[0057] Station Information (staInfo): For forecast types requiring station information (such as lunar shadow or solar outage), the latitude, longitude, and altitude of the station are provided. The station information (staInfo) and the transit angle parameters required for type eight only participate in geometric calculations in step S4: For type six, the station's latitude, longitude, and altitude are converted into a station position vector in Earth-fixed or inertial frames, and geometrically combined with the satellite position and lunar shadow to determine whether the satellite is obscured by the moon when viewed from the station's line of sight; for type eight, the station position is calculated using collinearity and angular distance criteria with the satellite position and solar direction, and the transit angle parameters are used to limit or correct the solar outage criteria; for types one through five and type seven, if no station-related criteria are performed, the station information is not included in the calculations, or it is ignored during the parameter verification stage. Step S3 can verify whether station information and transit angle parameters are required based on the forecast type; if missing, execution is refused or an error message is returned.

[0058] S2: Obtain satellite orbit status based on satellite identifier.

[0059] The satellite orbital status includes initial orbital parameters. Based on the satellite identifier, the initial orbital parameters are obtained from the orbital configuration database. The initial orbital parameters include epoch time, Kepler orbital elements (a, e, i, Ω, ω, M), satellite physical parameters (mass, windward area, solar radiation area, etc.), and orbital mode (whether it is in orbit, whether it has maneuvers, etc.).

[0060] The epoch and Keplerian orbital elements (a, e, i, Ω, ω, M) together constitute the initial values ​​for orbit propagation. When the integration start point is inconsistent with the epoch, the elements are first propagated or converted to the orbital state corresponding to the predicted start time before numerical integration begins. Satellite physical parameters are used in step S4 to select or calibrate perturbation model coefficients. For example, atmospheric drag and radiation pressure area are used in drag and radiation pressure acceleration calculations, and mass is used in the conversion of acceleration to state derivative. The orbital mode is used in step S4 to select the integration model or force model branch. For example, depending on whether the satellite is in orbit or whether it includes powered maneuvers, it is determined whether to enable maneuver segment parameters or switch the force model, thus maintaining consistency with the configuration read in step S2.

[0061] S3: Identify the forecast algorithm to be used based on the forecast type.

[0062] Identifying the forecast algorithm to be used based on the forecast type includes: developing a forecast type mapping table to map forecast type codes to corresponding forecast algorithms; The first type corresponds to the Kepler orbital element prediction algorithm; The second type corresponds to the Earth-fixed coordinate system prediction algorithm; The third type corresponds to the inertial coordinate system prediction algorithm; The fourth type corresponds to the geodetic coordinate system prediction algorithm; The fifth type corresponds to the ground shadow prediction algorithm; The sixth type corresponds to the lunar shadow prediction algorithm; The seventh type corresponds to the penumbra prediction algorithm; The eighth type corresponds to the solar eclipse forecasting algorithm.

[0063] Mapping table structure: { Forecast type code: { label: 'Coordinate System Name', API: The corresponding forecast algorithm interface function } }

[0064] S4: Make predictions based on satellite orbital status and prediction algorithms.

[0065] For the first, second, third, and fourth types, orbital integration is performed first, followed by coordinate system transformation.

[0066] The normalized time range (start, end) received in step S1 is combined with the time step (step) to construct a discrete forecast time sequence {tk}: Let t0 = start, and obtain t1, t2, ... in sequence according to the step size step, until the forecast period is covered (the end point can be the largest tk no later than end, or the end time can be included separately in the output according to the system convention, which is recorded in the metadata for verification). The terms "each forecast time" and "each discrete time" mentioned below refer to tk in this sequence; the generation of orbital integral and inertial position sequences only outputs the satellite state at {tk}, and does not output additional states at any unspecified intermediate times.

[0067] The orbital integration starts with the initial orbital parameters obtained in step S2 and proceeds from start to end according to the discrete forecast time sequence: at each tk, a numerical integration step or equivalent state extrapolation is performed to make the time label of the output state consistent with tk; the time step determines the time interval between adjacent tk and also serves as the basis for setting the upper limit of the internal integration step or the output thinning interval (when the internal integration step is less than step, a smaller step can be used internally to ensure accuracy, and the output is only output at tk; when a large step is used to directly advance, the output time is still aligned with tk).

[0068] For types 5, 6, 7, and 8, the inertial coordinate system prediction algorithm is first invoked to obtain the satellite's position sequence within the prediction time range. Then, the satellite position sequence {r_sat(tk)} (including velocity sequence if necessary) is obtained from the discrete prediction time sequence {tk} as described above. Finally, special event calculations are performed. Specifically: for each tk, the inertial coordinate system satellite state, consistent with types 1 to 4 on the same integral link, is obtained first. Then, an ephemeris and geometric criteria are superimposed on this tk. Types 5 and 7 determine umbra or penumbra based on r_sat(tk) and r_sun(tk). Type 6 introduces the station position determined by station information (staInfo) and r_moon(tk) in addition to r_sat(tk) for line-of-sight occlusion determination. Type 8 introduces the station position determined by staInfo, r_sun(tk), and transit angle parameters in addition to r_sat(tk) for collinearity and angular distance threshold determination.

[0069] The solar and lunar ephemeris values ​​used in special event calculations are queried or interpolated at the same UTC epoch as each tk, ensuring that r_sat(tk) is at the same time as r_sun(tk) and r_moon(tk). In step S4, types 6 and 8 also combine the station information (staInfo) provided in step S1 and the transit angle parameters from type 8 with the satellite positions on the same {tk} after coordinate transformation to participate in the geometric criteria, avoiding mismatches between station constants and satellite timing.

[0070] The reasons for using the inertial coordinate system orbital state before calculating special events are as follows: First, the numerical integration of satellite orbits in the inertial frame is consistent with the expression of perturbation forces and the form of state derivatives. The integrated output r_J2k and v_J2k are usually in the same inertial frame as the positions of the Sun and Moon's centroids given by the celestial ephemeris, or unified to this frame through the standard ephemeris interface. This facilitates the construction of vector relationships between satellite, Earth, and the Sun, or satellite, Moon, and the station, under the same spatiotemporal reference, avoiding the introduction of additional phase errors or timestamp inconsistencies due to repeated coupling of Earth's rotation and celestial coordinate transformation in the Earth-fixed frame. Second, the criteria for Earth's shadow and penumbra are geometrically related to the spatial positional relationship of the satellite relative to the Earth's umbra cone and penumbra cone, and the criteria for solar outburst are the angular relationship between the station's direction from the satellite and its direction to the Sun. These relationships are most directly expressed in the inertial frame by straight lines, cone surfaces, and angular distances. If the satellite position is expressed using the Earth-fixed frame, the Sun's direction still needs to be transformed to the Earth-fixed frame, which is essentially equivalent to or even more cumbersome than "inertial prediction first, then unified transformation". Third, for the sixth type of lunar shadow, starting from station observations, the station's latitude, longitude, and altitude need to be converted to a coordinate system consistent with the satellite's position before determining line-of-sight occlusion. When the line-of-sight vector originating from the station is combined with the satellite's inertial position, using the same inertial prediction output as the third type ensures that the same force model and time discretization are used with the orbital integral, avoiding misjudgments caused by inconsistent epochs or step sizes when calling different modules. Therefore, the common technical choice for the latter four types is to use the satellite position sequence in the inertial frame as the main input for the geometric calculation of special events, rather than first forcibly converting it to a certain ground operational coordinate system and then back-calculating the event.

[0071] Special event calculations include: For the fifth type, calculate whether the satellite has entered the Earth's shadow zone, determine the geometric relationship between the satellite, the Earth, and the Sun, and calculate whether the satellite is blocked by the Earth; For the sixth type, it is calculated whether the satellite has entered the lunar shadow region. Based on the station information, it is calculated whether the satellite is blocked by the moon when observed from the station, taking into account the latitude, longitude and altitude of the station. For the seventh type, calculate whether the satellite has entered the Earth's penumbra; For the eighth type, it calculates whether the satellite, the sun, and the station are collinear, obtains station information and transit angle parameters, and determines whether the satellite signal is interfered with by the sun.

[0072] Specifically: For the first type, Kepler orbital element prediction, orbital integration is first performed: Starting with the initial orbital parameters, orbital propagation is performed using numerical integration methods (such as the Runge-Kutta method); Consider perturbations such as Earth's non-spherical gravity (J2 term, etc.), atmospheric drag, and solar radiation pressure; According to the specified time step, the orbital state at each time step tk is calculated (i.e., the orbital state is advanced sequentially for k=0,1,2,… until end is covered). In the preferred embodiment, the orbital state at each time step is represented as the three-dimensional position vector r_J2k and the three-dimensional velocity vector v_J2k in the J2K system.

[0073] Then, coordinate system transformation is performed: the Kepler elements obtained by orbital integration are directly output, that is, the J2K position and velocity are converted into instantaneous Kepler orbital elements.

[0074] The input data for coordinate transformation are: the three-dimensional position vector r_J2k and the three-dimensional velocity vector v_J2k at each predicted time. The transformation process is as follows: Angular momentum vector, orbital energy, and semi-major diameter are calculated based on the position and velocity vectors; the semi-major axis a, eccentricity e, orbital inclination i, right ascension of the ascending node Ω, argument of perigee ω, and a set of roots consistent with the system conventions are obtained from the vector relationships under the two-body problem. The formula type used is: a closed or semi-closed conversion relationship of orbital mechanics from Cartesian position and velocity to instantaneous Keplerian six roots (including the trigonometric function relationship between eccentricity and perigee derived from radial and lateral velocity components and geometric quantities). The output results are: the epoch time corresponding to each predicted time and the Keplerian orbital roots (a, e, i, Ω, ω, M or equivalent combinations of angular variables). If the implementation method of direct integration in the root space is adopted, the Kepler roots can be obtained directly in each step. At this time, the integration output can be formatted into the same root sequence as above, and the output should still be kept at the same discrete point in time as the second to fourth types to ensure data alignment.

[0075] For the second type, which is the prediction of the Earth-Fixed Coordinate System (WGS84), the orbital integration calculation is performed first. This calculation process is the same as that for the first type.

[0076] Then, a coordinate system transformation is performed: the position and velocity in the inertial coordinate system are converted to the ground-fixed coordinate system.

[0077] During coordinate system transformation, the J2K position and velocity are converted to the position and velocity in the WGS84 Earth-Fixed Cartesian coordinate system. The input data includes r_J2k, v_J2k, and the corresponding UTC time for each predicted time (tk is determined by start, end, and step). The transformation process is as follows: Earth orientation parameters (including precession, nutation, Earth rotation angle, and polar motion) are obtained or interpolated based on the predicted time; a coordinate transformation matrix chain from the J2000 inertial frame to the Earth-Fixed frame is constructed; rotations corresponding to precession, nutation, Earth rotation, and polar motion (or equivalent quaternion / matrix composition) are sequentially applied to the position vector r_J2k to obtain the Earth-Fixed frame position vector r_WGS84; the velocity vector v_J2k is subjected to the same rotation as the position vector, and a velocity correction caused by the cross product of the Earth's rotation angular velocity and the position vector is superimposed to obtain the Earth-Fixed frame velocity vector v_WGS84. The formulas used are: rotation matrix multiplication based on the IAU precession nutation model or equivalent model, calculation of Earth's rotation angle (GMST or GST) and polar rotation, and classical velocity transformation relationship between the inertial frame and the Earth-fixed frame. The output results are: position components x, y, z and velocity components vx, vy, vz in the WGS84 Earth-fixed rectangular coordinate system at each forecast time.

[0078] For the third type, which is inertial coordinate system prediction, orbit integration calculation is performed first, and the calculation process is the same as that for the first type.

[0079] Then perform a coordinate system transformation: directly output the position and velocity in the inertial coordinate system.

[0080] In the inertial coordinate system prediction, after completing the orbital integration to obtain r_J2k and v_J2k at each time, no inter-system transformation from J2K to other coordinate systems is performed; the input data are r_J2k and v_J2k at each time; the output results are directly the J2K system position vector and velocity vector at each prediction time (consistent with the integral output), that is, the coordinate system transformation step is to format the output while keeping the J2K Cartesian state unchanged.

[0081] For the fourth type, which is a geodetic coordinate system prediction, orbital integration is first performed, and the calculation process is the same as that for the first type.

[0082] Then, coordinate system transformation is performed: the position in the Earth-fixed coordinate system is converted to latitude, longitude, and altitude.

[0083] The geodetic coordinate system prediction, after obtaining r_J2k and v_J2k at each time point through orbital integration, involves a coordinate system transformation, comprising two consecutive transformation segments. The first segment is the same as the second type: converting the J2K position velocity to WGS84 position velocity. The inputs are r_J2k, v_J2k, and UTC time. The formulas used are the same as those for precession, nutation, Earth rotation, polar motion, and velocity transformation described in the second type, yielding r_WGS84 and v_WGS84. The second segment converts the WGS84 geodetic rectangular coordinates to geodetic coordinates (latitude, longitude, and altitude, BLH). The input data are: the components of r_WGS84 (x, y, z) and the WGS84 reference ellipsoid parameters (semi-major axis, flattening, or eccentricity). The conversion process is as follows: Longitude λ, latitude φ, and ellipsoidal height h relative to the reference ellipsoid are obtained from rectangular coordinates through geodetic back-calculation (latitude is often solved by solving a system of equations using x, y, z and ellipsoidal geometric constraints, and then the elevation is calculated from the radius of curvature of the prime meridian and the normal direction). The formulas used are: geometric relationships between the normal to a point on the ellipsoid and the equatorial and meridian planes, the arctangent relationship of longitude, the iterative equation for latitude, and the relationship between elevation and the radius of curvature of the prime meridian. The output results are: longitude λ, latitude φ, and ellipsoidal height h at each predicted time; optionally, v_WGS84 or the velocity components in the local northeast-northeast coordinate system can be retained, obtained from v_WGS84 using a rotation matrix around the ellipsoidal normal. Therefore, the overall data flow of the fourth type is "J2K position velocity → WGS84 position velocity → geodetic latitude and longitude (and optional velocity)", where the first two segments correspond to "J2K position velocity → WGS84 position velocity" and "WGS84 position velocity → latitude and longitude (BLH)" respectively; the conversion chain of "J2K position velocity → Kepler element" is only used for the first type and is not a necessary step for the fourth type.

[0084] For the fifth type, which is the Earth shadow prediction, the orbit prediction results are first obtained, that is, the inertial coordinate system prediction algorithm is called to obtain the position sequence of the satellite within the prediction time range.

[0085] Then, it calculates whether the satellite has entered the Earth's shadow region, determines the geometric relationship between the satellite, Earth, and Sun, and calculates whether the satellite is obscured by the Earth. Specifically, at each predicted time tk determined by start, end, and step, r_sat(tk) = r_J2k(tk) is obtained; at the same tk, r_sun(tk) is obtained from the astronomical ephemeris; at tk, the Earth's umbra / cone or cylinder geometric model is used to determine whether the satellite is located within the Earth's shadow region, obtaining the umbra marker or class at that time; if necessary, interpolation is performed between adjacent tk to refine the boundary times of entering and exiting the shadow. This type does not use station information.

[0086] For the sixth type, which is lunar shadow prediction, the orbit prediction results are first obtained, that is, the inertial coordinate system prediction algorithm is called to obtain the satellite's position sequence within the prediction time range.

[0087] Then, to calculate whether the satellite has entered the lunar shadow region, station information is needed. This involves calculating whether the satellite is obscured by the moon when observed from the station, considering the station's latitude, longitude, and altitude. Specifically, r_sat(tk) is obtained at each tk; r_moon(tk) is obtained from the ephemeris at the same tk; the station information (staInfo) provided in step S1 is transformed using an ellipsoid and coordinate system to obtain the station position r_sta in the same coordinate system as r_sat(tk); the line of sight from the station to the satellite and the geometry of the lunar apparent are constructed to determine whether obscuration occurs, thus obtaining the lunar shadow marker at that moment. The station information (staInfo) is only used in the calculation of the sixth type and is time-by-time linked with the satellite sequence at {tk}.

[0088] For the seventh type, which is the prediction of the Earth's penumbra, the orbit prediction results are obtained first, that is, the inertial coordinate system prediction algorithm is called to obtain the position sequence of the satellite within the prediction time range.

[0089] Then, it is calculated whether the satellite has entered the Earth's penumbra. That is, at each tk, the same r_sat(tk) and r_sun(tk) as in the fifth type are used, but the geometric criterion is changed to penumbra determination, obtaining the penumbra indicator or sunshine ratio; the time series uses the same {tk} and step as the fifth type, facilitating comparison with umbra results. This type does not use station information.

[0090] For the eighth type, which is solar outage forecast, the orbit forecast result is obtained first, that is, the inertial coordinate system forecast algorithm is called to obtain the satellite's position sequence within the forecast time range.

[0091] Then, to calculate whether the satellite, the sun, and the station are collinear, station information and transit angle parameters are needed to determine whether the satellite signal is affected by solar interference. Specifically, at each tk, r_sat(tk) and the sun's direction are obtained; the station information (staInfo) provided in step S1 is transformed into r_sta, and the transit angle parameters provided in step S1 are used as an angular distance threshold or a criterion threshold related to beamwidth; the angle between the satellite's direction and the sun's direction at the station is calculated and compared with the threshold to determine whether tk is affected by solar interference; the transit angle parameters and staInfo are only used in the calculation for the eighth type.

[0092] S5: Output the forecast results.

[0093] The forecast results will be output in a standardized format, which includes: Time series data, including the orbital state or event state at each time point; The data column definition includes labels and attributes generated based on the forecast type. Labels refer to the technical name of the column and the column header displayed to users or downstream systems (e.g., epoch, x_km, or "Epoch (UTC)" "X (km)"). Attributes refer to the non-numerical metadata associated with the column, including at least the meaning of the physical quantity, unit of measurement, numerical precision or decimal places, and data type (time, floating-point, Boolean, enumeration, etc.). They may also include coordinate system or standard reference (J2000, WGS84), effective value range, or enumeration value description. Different column sets and attributes are used for different forecast types to ensure consistency between the resulting columns and the forecast type, avoiding ambiguity. Metadata information, including forecast parameters, calculation time, and data volume.

[0094] Unified parameter processing is not only completed in step S5, but is distributed among steps S1 to S5 according to their correlation: After receiving the forecast request parameters, step S1 performs normalization and consistency processing on the original input; step S3 performs completeness, mutual exclusion, and dependency verification on the normalized parameters in combination with the forecast type; steps S2 and S4 call the coordinate transformation module when necessary to convert the database or intermediate state from one standard parameter form to another to meet the integrator or output convention; step S5 performs automatic result adaptation and packages metadata on the numerical results generated in step S4.

[0095] The data column definition is associated with the fields in the metadata and the forecast type, the parameters after normalization in step S1, and the output semantics of step S4.

[0096] The relationship between unified parameter processing and steps is as follows: Firstly, the input side is uniformly processed: external satellite identifiers are uniformly mapped to internal satellite identifiers or database primary keys to avoid mismatches caused by multiple aliases for the same satellite; station latitude, longitude, and altitude are uniformly set to specified angle units, elevation datums, and triples under the reference ellipsoid, and written into the session context along with extended fields such as the eighth type of transit angle; the time range and time step are uniformly set to UTC timescale and second-level step integers, verifying that the start time is earlier than the end time, the step size is greater than zero, and it matches the forecast duration; invalid fields are pruned or marked according to the forecast type (for example, when the first to fifth types and the seventh type do not require stations, the station-related fields are marked as not participating in the calculation or excluded from the verification range). Step S3 checks again according to the forecast type when parsing the mapping table: whether the sixth and eighth types have valid station information, and whether the eighth type has transit angle parameters. If they are missing, the process is interrupted and an error message is returned, thus closing the "type - required parameters" association before entering step S4.

[0097] Secondly, the connection between the calculation side and the independent coordinate transformation module: The system provides a coordinate transformation module decoupled from the forecast engine, which can be called as needed in step S2 after reading the orbit configuration and in step S4 before integration or format transformation. The relationship between each transformation capability and the step and forecast type is as follows: (1) J2K instantaneous root and J2K position velocity conversion: When the orbit configuration database is stored in Kepler roots and the numerical integrator requires Cartesian state, the instantaneous root is converted to J2K position velocity in the integration initialization stage of step S2 or step S4; when the first type output needs to be cross-calibrated with the internal Cartesian state or when the roots and Cartesian quantities need to be exported at the same time in step S5, it can be called in reverse. (2) J2K position velocity and WGS84 position velocity conversion: In step S4, the second type, the fourth type of ground solid segment and the station ground solid / inertial connection reuse, using the Earth's rotation, polar motion, precession nutation and the latest EOP parameters. (3) Conversion between J2K instantaneous roots and J2K flat roots: When step S2 is configured or the user agrees to use flat roots as initial values ​​and the integration is performed in instantaneous root or Cartesian space, the flat root to instantaneous root conversion is completed before step S4; if flat root output is required for long-term forecast archiving, the instantaneous root result can be converted to flat root before exporting in step S5, taking into account long-term terms such as J2 and the averaging theory conventions during the conversion. (4) Conversion between DX-2 coordinate system and J2K coordinate system: When the orbit configuration or external interface uses DX-2 to express the initial value or agrees with the coordinates of a specific task, it is uniformly converted to J2K after reading in step S2 or before integration in step S4, so that the subsequent integration and event geometry are consistent with the third type of output reference. (5) Conversion between Kepler roots and TLE format: When TLE is read from the database or external file in step S2, it is first converted to internal Kepler roots or Cartesian initial values ​​before participating in integration; when TLE needs to be returned according to the user format in step S5, it is converted from the current epoch state before output. The above calling relationship is reflected in the fact that the coordinate transformation module does not replace the complete forecast algorithm in step S4, but is selectively called at the boundaries of S2 / S4 / S5 according to the association of "data source form - integrator requirements - user output form", so as to avoid repeating the same transformation in each forecast type sub-module.

[0098] Third, the results are automatically adapted: based on the forecast type determined in step S3, the corresponding column set and column attributes (unit, precision, display name) are selected from the preset column definition template, and the time series output in step S4 is filled into a table or structured object. Preferably, the correspondence between each forecast type and the data column definition is as follows: The first type, Kepler orbital elements, includes the epoch and a, e, i, raan, pa, ma, where raan, pa, and ma correspond to the right ascension Ω of the ascending node, the argument ω of the perigee, the mean perigee M, or equivalent angular variables agreed upon by the system, respectively; the second type, Earth-fixed coordinates, includes epoch, x, y, z, vx, vy, and vz; the third type, inertial coordinates, includes epoch, x, y, z, vx, vy, and vz (when consistent with the J2K system, the coordinate system label is marked in the metadata); the fourth type, latitude, longitude, and altitude, includes epoch, lon, lat, and alt; the fifth to eighth types, special events, include epoch, event_type, and duration, and can be expanded according to type to include columns related to the parameters passed in step S1 and the judgment results in step S4, such as shadow depth, angular distance, whether an alarm is triggered, and station identification. The duration can be correlated with the interpolation refinement results of adjacent event boundaries, indicating the duration of the umbra, penumbra, lunar occlusion, or solar outage impact period. In addition to forecast parameters, calculation time, and data volume, metadata information also includes at least one of the following: satellite identifier used in this session, forecast type code, time range, step size, coordinate system label, and the version of the coordinate transformation module entry or EOP ephemeris used, to ensure traceability of the results and the input / calculation chain.

[0099] In summary, the unified parameter processing is coupled sequentially with steps S1 to S5, namely "input normalization - type-driven completeness verification - morphological transformation in the computation chain - type-driven column templates and metadata", so that the same set of interfaces can automatically complete the matching of parameters and result morphology under different forecast types.

[0100] The entire specific solution is described in detail through the following three embodiments: Example 1 (Third Type Inertial Coordinate Prediction, Orbital State Time Series): The user submits a prediction request through a unified interface. The request body, standardized in step S1, is as follows: Satellite identifier `sateId` is "SAT-EXAMPLE", prediction type `forecastType` is "j2k", time range `start` is 2026-03-30T00:00:00Z, `end` is 2026-03-30T01:00:00Z, and time step is 600 seconds. Station information is not mandatory for this type. Step S2 reads the initial orbital parameters, such as epoch, Kepler elements, and physical parameters, from the orbital configuration database based on `sateId`. Step S3 determines the inertial coordinate system prediction algorithm to be invoked based on the mapping table. Step S4 performs orbital integration within the stated time range at 600-second steps and outputs the J2K system position and velocity at each step. Step S5 encapsulates the results into a unified output body, where the data column definitions are as follows: column names are epoch (UTC time, ISO8601), x_km, y_km, z_km, vx_km_s, vy_km_s, and vz_km_s, along with the unit and precision attributes for each column; the time series data (rows) consists of multiple rows of records aligned with the column definitions, each row representing the orbital state at a predicted time. For example, the first row might be epoch=2026-03-30T00:00:00Z and its six corresponding components, the second row epoch=2026-03-30T00:10:00Z and its corresponding components, and so on, until the end time is covered. For instance, the values ​​in the first row could be represented schematically as (units consistent with column names): epoch=2026-03-30T00:00:00Z, x_km= 6821.45, y_km=12.03, z_km=1034.28, vx_km_s=-1.234, vy_km_s=7.456, vz_km_s=0.089. The second and subsequent rows are filled with the integral output for that moment under the same column name. These values ​​are only to illustrate the row-column correspondence. Metadata information is shown as follows: mapping between internalSatId and sateId, forecastType=j2k, coordinateFrame=J2000, start / end / step consistent with the request, rowCount is the row number, computedAt is the UTC time when the server completed the calculation, and eopVersion can be marked as "N / A" or omitted if no additional geo-fixed link conversion was performed on the J2K output. This embodiment demonstrates that the "orbit state corresponding to each moment" in the time series data, i.e., x, y, z, vx, vy, vz in each row on the epoch, together with the column definitions and metadata, constitute a unified format.

[0101] Example 2 (Type I Kepler Orbital Element Prediction): Steps S1 to S3 are similar to Example 1, except that forecastType is "orbitEle". Step S4 converts the J2K Cartesian state to instantaneous elements at each discrete time. In step S5, columns are represented as: epoch, a_km, e, i_deg, raan_deg, pa_deg, ma_deg; each row in rows corresponds to the six elements at a prediction time; the metadata adds rootType=osculating and an angle unit description. If the database stores elements but the integrator requires Cartesian initial values, the coordinate transformation module performs the conversion from J2K instantaneous elements to J2K position and velocity at the entry point of step S2 or S4 before integration. This process is written to the transformLog field of the metadata, for example, "init: elements→J2K Cartesian".

[0102] Example 3 (Fourth Type of Latitude, Longitude, and Height Forecast): forecastType is "blh". Step S4 first obtains the J2K state, then proceeds through the J2K→WGS84→BLH chain. In step S5, columns are represented as: epoch, lon_deg, lat_deg, alt_m; rows represent the geodetic coordinates at that moment; the coordinateFrame in metadata is labeled with latitude, longitude, and height under the WGS84 ellipsoid, and the ellipsoid parameter version is recorded.

[0103] In summary, this solution integrates orbit forecasts and special event forecasts across multiple coordinate systems through a unified forecasting framework, improving forecasting efficiency and data consistency while simplifying user operation processes. Details are as follows: First, ease of operation: 1. Unified interface: Users only need to select the forecast type through a unified interface to obtain the forecast results in the required coordinate system, without needing to understand the underlying implementation details. 2. Simplified parameters: The system automatically determines which parameters are needed based on the forecast type. For forecast types that do not require station information, the relevant input items are automatically hidden, simplifying user operation. 3. Intuitive results: Forecast results are automatically adapted into a tabular format with clear column names, facilitating viewing and analysis.

[0104] Second, improved computational efficiency: 1. Avoiding redundant calculations: Through a unified forecasting framework, for the orbital state at the same time, only one orbital integration is needed, followed by coordinate transformation to obtain results in multiple coordinate systems. 2. Optimized transformation paths: Establishing direct transformation paths between coordinate systems reduces intermediate transformation steps and improves transformation efficiency. 3. Parallel computing: For forecast types that can be computed in parallel, the system can perform forecast calculations in multiple coordinate systems simultaneously.

[0105] Third, data consistency is guaranteed: 1. Time synchronization: Prediction results in all coordinate systems are calculated based on the orbital state at the same moment, ensuring complete time synchronization. 2. Consistent accuracy: A unified orbital integration algorithm and coordinate transformation algorithm are used to ensure consistent data accuracy in different coordinate systems. 3. Reduced error accumulation: By optimizing the transformation path and reducing intermediate transformation steps, error accumulation is reduced.

[0106] Fourth, functional integration: 1. Integration of orbit forecasting and special event forecasting: Orbit forecasting is integrated with forecasts of special events such as Earth shadow, lunar shadow, and solar outages within the same framework, allowing users to obtain complete forecast information at once through a unified interface. 2. Multi-coordinate system support: Supports multiple coordinate systems including Kepler elements, Earth-fixed coordinates, inertial coordinates, latitude, longitude, and altitude, meeting the needs of different application scenarios. 3. Strong scalability: Adopts a modular design, facilitating the addition of new coordinate system types or forecasting functions without modifying the core code.

[0107] Fifth, system maintainability: 1. Code reuse: A unified forecasting framework improves code reuse and reduces duplicate code. 2. Module decoupling: Forecasting algorithms for different coordinate systems are treated as independent modules, reducing system coupling. 3. Ease of testing: Modular design facilitates unit testing and integration testing.

[0108] Sixth, practical application value: 1. Improved work efficiency: Users no longer need to switch between multiple systems or modules, greatly improving work efficiency. 2. Lowered barrier to entry: The unified interface lowers the barrier to entry, allowing non-professionals to quickly get started. 3. Reduced error rate: Automated coordinate transformation and parameter processing reduce the possibility of human error. 4. Support for complex scenarios: Particularly suitable for complex application scenarios that require simultaneous acquisition of prediction results from multiple coordinate systems, such as multi-station collaborative observation and multi-satellite formation flight.

[0109] According to a third specific embodiment of the present invention, the present invention provides an electronic device, such as... Figure 3 As shown, Figure 3 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0110] The following reference Figure 3 To describe an electronic device 300 according to this embodiment of the present application. Figure 3 The electronic device 300 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 3As shown, the electronic device 300 is presented in the form of a general-purpose computing device. The components of the electronic device 300 may include, but are not limited to: at least one processing unit 310, at least one storage unit 420, a bus 330 connecting different system components (including storage unit 320 and processing unit 310), a display unit 440, etc.

[0112] The storage unit stores program code that can be executed by the processing unit 310, causing the processing unit 310 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 310 can perform the steps shown in the second specific embodiment.

[0113] The storage unit 320 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 3201 and / or a cache storage unit 3202, and may further include a read-only memory unit (ROM) 3203.

[0114] The storage unit 320 may also include a program / utility 3204 having a set (at least one) program module 3205, such program module 3205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0115] Bus 330 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0116] Electronic device 300 can also communicate with one or more external devices 300' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 300, and / or any device (e.g., router, modem, etc.) that allows electronic device 300 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 350. Furthermore, electronic device 300 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 360. Network adapter 360 can communicate with other modules of electronic device 300 via bus 330. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 300, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0117] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware.

[0118] Therefore, according to a fourth specific embodiment of the present invention, the present invention provides a computer-readable medium. For example... Figure 4 As shown, the technical solution according to the embodiments of the present invention can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of the present invention.

[0119] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0120] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0121] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and 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).

[0122] The aforementioned computer-readable medium carries one or more programs, which, when executed by a device, cause the computer-readable medium to perform the functions of the second specific embodiment.

[0123] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0124] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions of the embodiments of the present invention can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, portable hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of the present invention.

[0125] Exemplary embodiments of the present invention have been specifically shown and described above. It should be understood that the present invention is not limited to the detailed structures, arrangements, or implementations described herein; rather, the present invention is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A multi-coordinate system consistent satellite orbit prediction method, characterized by, Includes the following steps: S1: Receive forecast request parameters input by the user, the forecast request parameters including satellite identifier and forecast type; S2: Obtain satellite orbit status based on satellite identifiers; S3: Identify the forecast algorithm to be used based on the forecast type; S4: Make predictions based on satellite orbital status and prediction algorithms; S5: Output the forecast results.

2. The multi-coordinate system unified satellite orbit prediction method according to claim 1, characterized in that, In step S1, the preparation type is the required coordinate system type, including the following eight types: The first type is Kepler orbital elements; The second type is the Earth-fixed coordinate system; The third type is the inertial coordinate system; The fourth type is the geodetic coordinate system; The fifth type is ground shadow forecast; The sixth type is lunar shadow forecast; The seventh type is penumbra prediction; The eighth type is solar eclipse forecast.

3. The multi-coordinate system consistent satellite orbit prediction method of claim 2, wherein, In step S2, the satellite orbital state includes initial orbital parameters, which include epoch time, Kepler orbital elements, satellite physical parameters, and orbital mode.

4. The multi-coordinate system consistent satellite orbit prediction method of claim 1, wherein, In step S3, identifying the forecast algorithm to be used based on the forecast type includes: developing a forecast type mapping table to map the forecast type code to the corresponding forecast algorithm; The first type corresponds to the Kepler orbital element prediction algorithm; The second type corresponds to the Earth-fixed coordinate system prediction algorithm; The third type corresponds to the inertial coordinate system prediction algorithm; The fourth type corresponds to the geodetic coordinate system prediction algorithm; The fifth type corresponds to the ground shadow prediction algorithm; The sixth type corresponds to the lunar shadow prediction algorithm; The seventh type corresponds to the penumbra prediction algorithm; The eighth type corresponds to the solar eclipse forecasting algorithm.

5. The multi-coordinate system consistent satellite orbit prediction method of claim 4, wherein, In step S4, the prediction based on satellite orbital state and prediction algorithm includes: For the first, second, third, and fourth types, orbital integration is performed first, followed by coordinate system transformation. For types 5, 6, 7, and 8, the inertial coordinate system prediction algorithm is first invoked to obtain the satellite's position sequence within the prediction time range, and then special event calculations are performed.

6. The multi-coordinate system consistent satellite orbit prediction method of claim 1, wherein, The calculation of the special event includes: For the fifth type, calculate whether the satellite has entered the Earth's shadow zone, determine the geometric relationship between the satellite, the Earth, and the Sun, and calculate whether the satellite is blocked by the Earth; For the sixth type, it is calculated whether the satellite has entered the lunar shadow region. Based on the station information, it is calculated whether the satellite is blocked by the moon when observed from the station, taking into account the latitude, longitude and altitude of the station. For the seventh type, calculate whether the satellite has entered the Earth's penumbra; For the eighth type, it calculates whether the satellite, the sun, and the station are collinear, obtains station information and transit angle parameters, and determines whether the satellite signal is interfered with by the sun.

7. The multi-coordinate system consistent satellite orbit prediction method of claim 1, wherein, In step S5, the output forecast result includes: The forecast results will be output in a standardized format, which includes: Time series data, including the orbital state or event state at each time point; Data column definition, including labels and attributes for generating data columns based on forecast type; Metadata information, including forecast parameters, calculation time, and data volume.

8. A multi-coordinates system consistent satellite orbit prediction system, characterized by, It includes a parameter receiving module, an orbit status acquisition module, a forecast type identification module, a unified orbit forecast module, and a result output module; The parameter receiving module is used to receive forecast request parameters input by the user, and the forecast request parameters include satellite identifier and forecast type; The orbital status acquisition module is used to acquire the satellite orbital status based on the satellite identifier, which includes the initial orbital parameters. The forecast type identification module is used to identify the forecast algorithm to be used based on the forecast type; The unified orbit prediction module is used to make predictions based on satellite orbit status and prediction algorithms; The result output module is used to output the forecast results.

9. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the satellite orbit prediction method of the multi-coordinate system as described in any one of claims 1-7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the satellite orbit prediction method of the multi-coordinate system as described in any one of claims 1-7.

Images