Hello everyone,
I was just wondering what kind of features orekit has for mission design and operations of EO satellites and also what features there are for constellations mission analysis and operations.
Thank you.
Iliass
This is a wide question!
Well, here are some random elements, a more complete list can be found here.
For mission analysis, you have the obvious basic set:
- classical propagation you will find everywhere: analytical for speed, numerical for accuracy with all
force models (gravity field to any degree and order, drag, solar radiation pressure, third body for any
celestial body (i.e. not limited to Sun and Moon, you can add Venus or Jupiter or anything else for
increased accuracy), solid tides, ocean tides, Earth albedo and infrared (i.e.rediffused radiation
pressure), empirical forces, relativity, maneuvers (impulsive or continuous, including low thrust) - semi-analytical propagation with DSST, which combines the speed of analytical models with the
accuracy of numerical models; this is useful for long term simulation, even past end of life of
satellite, to assess reentry time if you want to comply with debris mitigation rules - events prediction (too many predefined to list, and also users can add their own mission-specific
events, this includes on-board sensors fields of view with any shape) - covariance propagation
- attitude modelisation
- Taylor algebra (this is specially useful for doing Monte-Carlo analysis orders of magnitude faster
than with regular propagation in a loop with randomized inputs) - generation of realistic simulated measurements for orbit determination (see below about OD)
For operations you can use the same set as above, perhaps with other sets of events more related
to operations (sensors dazzling, contacts with ground stations, fly over a region of interestā¦). Another feature important for operations is data exchange (orbit, attitude, tracking data) both importing and exporting them (Orekit 11 will by the way be one of the two reference implementation of the next CCSDS ODM standard which is not published yet and add OCM to the already supported OPM, OEM and OMM), we will also add Conjunction Data Messages support for debris mitigation. Of course reading and propagating TLE is supported since years, but we can also improve existing TLEs and do orbit determination directly in TLE (a paper was published a few weeks ago on this). A major feature for operation is Orbit Determination, which can be done using a lot of different measurements (Range, Doppler (one or two way), Azimut-Elevation, Right ascension-Declination, Turn-around, inter-satellite
range, position, position-velocity, inter-satelite phase, GNSS code, GNSS phase with ambiguity
resolution and wind-up. OD can be done with Batch Least Square or with Kalman filtering, and a sequential least square will be added soon (it is complete and is ongoing validation). OD can be used for calibrating maneuvers, and can be used in multi-satellite environment.
For constellations, the main features are the parallel propagation (i.e. propagation any number of orbits at the same time, with each propagator synchronized with the other ones, even if some are analytical propagators (for example for a reference satellite picked up among the constellation of formation-flying) and the other ones are numerical. This is used also in multi-satellite orbit determination, which is typically used if you have inter-satellite measurements and you need to adjusts several orbits in the same process.
One thing to note is that Orekit is used operationally since years by many space systems in the world and has been thoroughly validated: it is flight-proven. I remember a few years ago when someone at a conference presenting a new library explained that for validating it, they used Orekit as it was a reference. I was happy to learn that. The fact it is used and maintained by a community (agencies, operators, satellite manufacturers, academics and ground system integratorsā¦) is also a key point: it increases reliability a lot as they all have different uses.
1 Like
Hello Luc,
Thank you very much for the very extensive answer. A couple of questions:
- I am very interested in the āEarth albedo and infrared (i.e.rediffused radiation
pressure)ā part. Are we talking about radiometric budgets? Could you please point me at the functions to use this, in celestial body I can only find the PVCoordinates side of things.
How is parallel propagation performed, letās say for one same propagator but many satellites? And is there any easy way of creating constellations, as in by following patterns rather than defining the satellitesā orbit sone by one?
Also, surely one of Orekitās strength is the forum, thank you for making it so good 
Earth albedo and infrared correspond to the radiation pressure coming from the ground due to direct reflection of Sun light in the day time (albedo) and due to Earth thermal radiation (infrared). We use the classical Knock rediffused model. It is built from a PVCoordinatesProvider given by CelestialBodyFactory to know where the Sun is, and the model sums up the accelerations coming from Earth visible points with the current satellite, Earth, Sun geometry.
Parallel propagation is handled by PropagatorsParallelizer. You need to first build the set of individual propagators and give them to the parallelizer with a multisat step handler. Beware that the propagators will be run in a multithreaded environment (one thread for each propagator, the main thread remaining for the parallelizer), so you must make sure you donāt reuse some objects that store some internal state from one propagator from the other. Sharing frames, celestial bodies or gravity field providers and things like that is OK, but events handlers for example may not. I strongly recommend if you use numerical propagators to build each one from scratch with their own instance of integrator, their own instances of all force models. Some force models could be reused, but donāt rely on that, it is much safer and cleaner to just have everything separate. Look at the class javadoc, it explains how synchronization is achieved. The multisat step handle will see all satellites as it will be called with a list of interpolators, all valid for the current global step. There is one limitation with the parallelizer : you cannot set up directly multisatellite events (but you can enable events on each individual propagator).
I forgot about building a constellation.
Thereās no helper for this, but it should be really simple, for example for Walker constellations. Something could be set up with a PropagatorBuilder and the Walker parameters, but we would need to check if force models can be shared or not, then the constellation builder would generate the list of propagators so they can be fed directly to the parallelizer. This would be a nice little project, perfectly suited for a first contribution if you want 
Thank you very much Luc!
Hi,lucļ¼
I am trying to compute the satellite acceeses inside a constellation, and I have done this by using InterSatDirectViewDetector.But I found the calculation cost too much time when the constellation have more than 500 satellites.Is it possibile to combine InterSatDirectViewDetector and a multisat step handler?
When using propagator parallelizer, events are only available at each propagator level, all propagators ignore each other and are combined at higher level (by the parallelizer) in the step handler, which is different from an event detector.
So if you want to achieve intersat detection in the step handler, you will have refrain from registering the InterSatDirectViewDetector in the propagator, and rather register it to your step handler with a proxy PVCoordinatesProvider and call the g function by yourself in a loop, searching for zeros by yourself. It will certainly work, but is not an easy task. Having multi-sat events detection in the propagator parallelizer is something we would love to have, but we did not manage to do it yet. As usual, contributions welcome (but this one is hard).
If your constellation has numerous symmetries (like for example a Walker constellation) and if you can use just nominal intersat views, you may consider precomputing the visibilities on a very short schedule (typically T/(N/P) where T is period, N is total number of satellites and P is number of planes) and then use the periodic properties of the constellation to generate a full schedule from this short time span. This of course does not work if your constellation is not regular or if you need events taking into account the current orbit instead of the regular nominal one).
1 Like
Thank luc! I now understand the trick here, and I will try that direction.