Conference PaperPDF Available

OPEN GOVERNANCE OF THE OREKIT SPACE FLIGHT DYNAMICS LIBRARY

Authors:

Abstract

Orekit is a library for space flight dynamics. It was released under an open-source license in 2008 and has since gained widespread recognition. It has already been used operationally, it has been selected as the basis of new generation systems in agencies, it has been used for several studies and ground systems developments by various industrial actors, and it is used for training purposes at universities. The project has gone through several phases, becoming more and more open at each step. During the first phase, Orekit started as a closed-source product. During the second phase (2008), Orekit switched to a permissive open-source license (Apache License V2) in 2008. The Orekit third phase started in early 2011. The third phase included a collaborative site, with direct public visibility of the development version control system, issue tracker, mailing lists, blog and wiki. The third phase culminated in late 2011 when the first external committer was nominated and gained write access to the source code repository. The Orekit project is now entering its fourth phase, with a completely open governance model, involving representatives from different space field actors in a Project Management Committee (PMC). The Orekit governance model follows the Apache Software Foundation meritocracy. This model is based on several roles (user, contributor, committer, Project Management Committee member and PMC chair). This paper explains the various roles and the rights that are bound to them. Everyone can go through the various roles. The rules to get access to the various roles are explained in the paper. They are based on merit previously earned within the project. Merit is gained through contributions and involvement. The first PMC of the Orekit project is officially set up as the 5 th ICATT conference is taking place. It is composed of people with different affiliations in order to meet the needs of the widest possible range of users. There are representatives of spacecraft manufacturers, academics (both European and US), satellite operators, software industry and independent experts. Representatives of space agencies are expected to join the PMC soon. This PMC will be in charge of defining the roadmap for the future evolution of the Orekit project. The rules for evolution of the PMC are explained in the paper. The role of the PMC is mainly to define global orientation. The technical low level decisions are still taken by the members of the development list where everyone can contribute to discussions, regardless of affiliation and whether they are or not members of the PMC. Orekit is a community oriented project.
OPEN GOVERNANCE OF THE OREKIT SPACE FLIGHT DYNAMICS LIBRARY
ESA/ESTEC, NOORDWIJK, THE NETHERLANDS
29 MAY – 1 JUNE 2012
Maisonobe L.(1), Cefola P.J.(2), Frouvelle N.(3), Herbinière S.(4), Laffont F.-X.(5),
Lizy-Destrez S.(6), Neidhart T.(7)
(1) CS Systèmes d'Information, 5 rue Brindejonc des Moulinais BP 15872,
31506 Toulouse CEDEX 5, France, Email: Luc.Maisonobe@c-s.fr
(2) Dept. Of Mechanical and Aerospace Engineering, University at Buffalo (SUNY) and consultant, USA,
Email: paulcefo@buffalo.edu
(3) CS Systèmes d'Information, 5 rue Brindejonc des Moulinais BP 15872, 31506 Toulouse CEDEX 5,
France, Email: Frouvelle.Nicolas@c-s.fr
(4) Thales Alenia Space, 100 Boulevard du Midi 06150 Cannes, France, Email:
Sebastien.Herbiniere@thalesaleniaspace.com
(5) CS Systèmes d'Information, 5 rue Brindejonc des Moulinais BP 15872, 31506 Toulouse CEDEX 5,
France, Email: Francois-Xavier.Laffont@c-s.fr
(6) ISAE, 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse Cedex 4, France, Email:Stephanie.Lizy-
Destrez@isae.fr
(7) Independent expert, Email: Thomas.Neidhart@gmail.com
ABSTRACT
Orekit is a library for space flight dynamics. It was
released under an open-source license in 2008
and has since gained widespread recognition. It
has already been used operationally, it has been
selected as the basis of new generation systems
in agencies, it has been used for several studies
and ground systems developments by various
industrial actors, and it is used for training
purposes at universities.
The project has gone through several phases,
becoming more and more open at each step.
During the first phase, Orekit started as a closed-
source product. During the second phase (2008),
Orekit switched to a permissive open-source
license (Apache License V2) in 2008. The Orekit
third phase started in early 2011. The third phase
included a collaborative site, with direct public
visibility of the development version control
system, issue tracker, mailing lists, blog and wiki.
The third phase culminated in late 2011 when the
first external committer was nominated and
gained write access to the source code
repository.
The Orekit project is now entering its fourth
phase, with a completely open governance
model, involving representatives from different
space field actors in a Project Management
Committee (PMC).
The Orekit governance model follows the Apache
Software Foundation meritocracy. This model is
based on several roles (user, contributor,
committer, Project Management Committee
member and PMC chair). This paper explains the
various roles and the rights that are bound to
them. Everyone can go through the various roles.
The rules to get access to the various roles are
explained in the paper. They are based on merit
previously earned within the project.
Merit is gained through contributions and
involvement. The first PMC of the Orekit project is
officially set up as the 5th ICATT conference is
taking place. It is composed of people with
different affiliations in order to meet the needs of
the widest possible range of users. There are
representatives of spacecraft manufacturers,
academics (both European and US), satellite
operators, software industry and independent
experts. Representatives of space agencies are
expected to join the PMC soon.
This PMC will be in charge of defining the
roadmap for the future evolution of the Orekit
project. The rules for evolution of the PMC are
explained in the paper.
The role of the PMC is mainly to define global
orientation. The technical low level decisions are
still taken by the members of the development
list where everyone can contribute to discussions,
regardless of affiliation and whether they are or
not members of the PMC. Orekit is a community
oriented project.
1. A continuous evolution
The Orekit project started in 2002; the evolution
of this project is typical of many current open-
source projects that were initiated in a
commercial company environment. An a
posteriori analysis of this evolution identifies four
different phases, each change leading to greater
openness.
Phase 1: an in-house closed product
At the beginning, Orekit was a small in-house
product developed by CS Systèmes d'Information.
In 2002, CS observed that several requests for
proposal (RFP) had been issued that requested
complete flight dynamics systems, either for low
earth orbit or for geostationary orbit. Although
there were several flight dynamics products
available in the marketplace, none of them fit the
requirements of the RFPs. The existing products
either partially fulfilled the requirements, or were
monolithic suites with much more capability than
necessary. Moreover, the proven suites were old
with potentially imposing maintenance
requirements over the projected lifetimes of the
new systems.
Subsequently, CS decided to develop a new core
library. This library was not intended to be a
standalone product by itself, but rather a
necessary asset for the company, on top of which
custom systems could be developed for
customers.
The product was developed using only internal
funding and internal human resources.
The design goals were to have something really
easy to adapt, up to date with respect to recent
space flight dynamics models and still compatible
with older models. The target audience was
composed of CS's own ground systems
development teams.
Orekit development was slow as resources were
scarce. The library matured from a small set of
core components to a fully fledged collection of
core classes and associated algorithms: orbit
elements, time and coordinate systems, multiple
central bodies, orbit propagation, and attitude
models.
This phase was quite long (six years). In the last
years of this phase, the sheer size and scope of
the libraries led CS to consider delivering it as a
product instead of considering it only as an
enabler for further value-added development
projects. However, despite its inherent technical
qualities and its successful operational use for
ATV in 2008, Orekit was just another closed-
product in an already crowded flight dynamics
market.
It was then decided to switch to another strategy.
Phase 2: switching to an open-source license
As it appeared that selling Orekit would not be
possible, it was decided to publish Orekit under
the terms of an open-source license. This move
may seem strange at first, but was in fact the key
to success.
CS operated on the rationale that the
investments previously made on Orekit should be
secured and that this could be done using a
classical service-based business model rather
than with a license-based business model. This
made sense as service is already the major part
of CS activity.
When doing such a move, the choice of the
license is a crucial one. There are a large number
of different licenses in the Free and Open Source
Software (FOSS) industry. The licenses are often
categorized in three main groups: strong copyleft,
weak copyleft and permissive licenses. Copyleft
licenses mandate distribution of source code for
derived works. Strong and weak copyleft differ in
what is considered derived work. Permissive
licenses do not mandate distribution of source
code for derived works. Examples of strong
copyleft licences are the General Public License
(GPL, [1]) and the Cea Cnrs Inria Logiciel Libre
license (CeCILL, [2]). Examples of weak copyleft
licences are the Lesser General Public License
(LGPL, [3]) and the component-oriented CeCILL
license (CeCILL-C, [4]). Examples of permissive
licenses are the Berkeley Software Distribution
license (BSD [5]), the Massachussets Institute of
Technology license (MIT, [6]) and the Apache
license (Apache, [7]).
As space industry stakeholders are mainly large
companies and agencies, they often consider that
the source code redistribution mandated by
copyleft licenses ([8], [9]) is contrary to their
goals of preserving the intellectual property
rights they hold on derived works. These actors
often favor permissive licenses ([10], [11]). In
order to allow a widespread adoption of Orekit in
the space industry, a well-known permissive
licence has been chosen: the Apache license
V2.0.
This choice of a permissive license means that
everyone can build a complete system on top of
Orekit or borrow code from Orekit to introduce
into their system while keeping the rest of the
code proprietary and closed source. There are no
license spreading issues with the Apache license.
The only things that must be done are that
recipients of the global system must get a copy of
the license, that any changed file must be
explicitly identified as changed from the original
distribution, and that all copyright, patent,
trademarks and attribution notices must be
preserved. These obligations are easy to fulfill.
Orekit was first published under the terms of the
Apache license V2 on July 16th 2008 [12]. This
release was very well received by the space flight
dynamics community and its use began to
spread. As expected for a niche domain package,
this spread was rather slow at first but steadily
increased over time.
One very interesting aspect of this diffusion is
that people we didn't know beforehand started to
discuss the Orekit library with us. They found the
library using online search engines, tested it and
adopted it for their own projects. The user base
then increased and different needs arose. A
direct side effect of this growth was that some
external contributions started to arrive. New
users identified bugs that were triggered by their
own use cases and they reported these bugs,
allowing the Orekit team to fix them faster and
thus improving the overall code quality. The
contributions ranged from simple kind 'thank you'
messages which were really appreciated, to bug
reports, tests cases and even fixes for the bugs
and small enhancements.
During this phase, the CS Orekit team was still
the single central point for all evolution. All
discussions were point-to-point only with the
Orekit team on one side and one specific user on
the other side. This was completely similar to a
classical provider-customer relationship, without
the contract or financial aspects.
There was no way for users to discuss together,
and no broadcast communication type that would
allow new users to anonymously browse available
information. General announcements were done
by mail using a list of interested users.
The release schedule was decided upon by the
Orekit team, much more in a cathedral-like model
as it is used in closed-source proprietary products
than in a bazaar-like model used by collaborative
open-source products [13]. The source code
control system was also hosted on a CS internal
server which was not reachable from outside.
Users were therefore forced to maintain their own
patches between releases and did not know
about the bugs and fixes provided by other users.
Phase 3: Collaborative development
The third phase was started in early 2011 to
alleviate these communication problems. The
project was switched from a cathedral model to a
bazaar model, mainly by simply using different
tools.
A public forge was set up, with public access to
activity, bug reports system, source code
repository, documentation, and downloads [14]. A
project blog was also started for announces [15].
Several public mailing lists have been set up with
browsable archives [16].
It is important to note that the public source code
repository is really the one used daily by the
development team. Users were therefore really
able to follow development in real time. They
could clone the repository and synchronize their
copy at their own pace and do not had to wait
until an official release was done if they
encountered a critical bug. Anonymous read
access to the repository was available to anyone,
write access was limited to the Orekit team.
With these new collaborative tools, contributions
increased again. Several major contributions
were done during this phase: new JPL and IMCCE
ephemerides, TLE conversion, orbit determination
not published yet -, documentation,
tropospheric and magnetic field models, SP3 files,
and most importantly DSST [17], [18].
Orekit was also selected at the same time as the
basis for the next generation space flight
dynamics systems at CNES (project SIRIUS [19])
and used by Eumetsat for long term station-
keeping analysis tool (Skat [20]).
As the CS Orekit team was small and principally
lead by the creator and main designer of the
library, the governance model in use during this
phase was the so-called benevolent dictatorship
[19], [20]. This governance model relies on a
single person making the final decision after
collaborative discussions. It is a very simple one
and is effective during the early stages of a
project. The crucial role of the leader is however
a difficult one to hold. This governance model
becomes cumbersome as more people get
involved, all of them having equally relevant
point of views and concerns and as trade-off
decisions become more commonplace. It is
clearly not a model that is well suited for the
Space Flight Dynamics field on the long term.
Phase 4: Open governance and meritocracy
While the collaborative development tools were
set up for phase 3, changes to the governance
model were also prepared. Right from the
beginning, phase 3 was intended to be as short-
lived as possible and a fourth phase was initiated,
opening also the decision making process in
addition to the development tools.
Just as the for the licence choice, the governance
model choice was carefully done. There are
several different well-known models for open-
source projects [21], [22], [23]. The model that
was selected for Orekit is the meritocratic model,
whose most prominent example is the Apache
Software Foundation (ASF) [24]. The core
principle of the meritocratic model is that people
get more power within the project as they get
more merit, and they get merit as they are
involved and work for the benefit of the project as
a whole. Anybody can join the project and the
contributions they provide will change their role.
The Orekit project uses the traditional roles
established by the ASF:
users are people who simply use the
product, they are not known to the
project team and have no specific rights,
contributors are users who registered to
the various collaborative tools (mailing
lists, forge) and contributed something
like bug reports, fixes, enhancements,
documentation or simply actively
participated to the public discussions,
they acquire some merit as they
contribute and acquire trust from others
in the project, some contributors get
write access to limited parts of the forge
like the wiki documentation,
committers are contributors who have
gained merit and proven their
contributions were worth including in the
library, they get direct commit access to
the source code repository,
Project Management Committer (PMC)
member are the decision-making people
on the project, they normally are
committers that showed up sufficient
hindsight about the long term objectives
of the project and what belongs or not to
its scope, they get voting rights when
deciding upon core decisions in the
project management and have so-called
binding votes,
PMC chair is the ultimate role in the
meritocracy; there is only one PMC chair
and this role is just the same as any other
PMC member with the only difference
being that in case of a tie during a vote
(and only in this case), then the PMC
chair can decide the outcome. There is
no leadership aspects involved in the PMC
chair role.
One difference between, the Orekit roles and the
Apache Software Foundation roles is that there
are no cross-project roles and hence nothing
similar to the Apache member status.
One important aspect of the meritocratic
governance model is that decisions occur on the
public lists so everyone can participate, even
people who do not (yet) have commit rights. The
final vote process for important decisions is
mainly a rubber stamp for a consensus that has
already been reached on the lists after everyone
has explained their views. Votes occur on the
mailing lists and can be -1 (I disagree and make a
counter-proposal), -0 (I don't agree but will not
block the process), +0 (I agree but will not help),
+1 (I agree and will help). The PMC members
votes are also considered with special care and
are binding votes.
Everyday development (fixing bugs, adding small
features...) does not require formal votes except
when the underlying design choices raise
concerns between the various members of the
team. Five different types of approval may be
used depending on the decision (technical
decision, new committer, new PMC member, PMC
rules changes...):
lazy consensus pertains to decisions that
are implicitly allowed unless a PMC
member cast a -1 binding vote,
lazy majority is a vote that passes if there
are more binding +1 than binding -1,
consensus approval which requires three
binding +1 and no binding -1 (which
means a binding -1 count as a veto),
unanimous consensus all binding votes
must be +1,
2/3 majority (there must be 2/3 binding
+1 and no binding -1).
PMC evolution rules are of two kinds. First, the
composition of the PMC (number of members and
representative names) can be changed by a 2/3
majority vote by existing PMC members. Second,
the rules of the PMC (for example voting rules)
can also be changed by PMC, also using the 2/3
majority vote. There are no upper level
committee. However, most PMC members are
representative of their employer and as such may
cast their vote according to their own hierarchy
decisions.
Most of the work of the PMC will be done through
discussions on mailing lists, with a few formal
meetings, once or twice per year.
In late 2011, the transition between phase 3 and
phase 4 was started when the first external
committer was nominated.
2. First Project Management committee
As the ICATT 2012 conference occurs, the first
official Orekit PMC has been officially launched.
Thus the start of phase 4 for the Orekit project is
confirmed.
A wide spectrum committee
The first PMC was formed by direct discussion
between the major Orekit contributors and users.
This was a long process.
The composition of this first PMC was deliberately
chosen to cover a wide spectrum of users. The
PMC members are representative of:
Spacecraft manufacturers (Thales Alenia
Space),
US academics (University at Buffalo),
European academics (Institut Supérieur
de l'Aéronautique et de l'Espace),
Public agencies (Centre National d'Études
Spatiales, European Space Agency),
Independent experts,
Software industry (CS Systèmes
d'Information).
The PMC composition includes members of three
important classes of actors for a component, with
some members belonging to several classes.
There are end users, who will make sure Orekit
does address their concerns for robust and
efficient operational systems. There are experts
who will ensure the models and underlying
theories are sound and up to date. There are
industrial architects who will guarantee the
modular architecture and easy integration and
testability of the product are maintained on the
long term. There are high level education actors
who will take care the product remains accessible
to everyone and the same system that is used
operationally can also be used for training, thus
ensuring a good transition when students will
apply for jobs.
This PMC is expected to be extended soon as
discussions are ongoing with other entities.
Committee first goals
The committee will define its goals on the long
term by itself, as its members will propose
agenda items before the meetings. The first
meeting will mainly be devoted to securing the
PMC rules and to define the scope of Orekit. It
may also already discuss about one or two new
members. Another top level priority decision will
be the release goals for upcoming 6.0 major
release.
3. Conclusion
The expected evolution for the future is to have
Orekit further deployed in the space industry and
be shared as a common basic layer by many
actors in the field. The start of the fourth Orekit
project phase and the advent of an independent
Project Management Committee is a cornerstone
for an independent project in which everyone can
participate. We hope more public entities and
private interests will join the project and share
knowledge and efforts for the benefit of
everyone. The meritocracy model ensures
everyone has equal access to Orekit, up to the
decision making process.
4. References
1. GNU General Public License,
http://www.gnu.org/licenses/gpl.html
2. Free Software Licensing Agreement
CeCILL,
http://www.cecill.info/licences/Licence_Ce
CILL_V1.1-US.html
3. GNU Lesser General Public License,
http://www.gnu.org/licenses/lgpl.html
4. CeCILL-C Free Software License
Agreement,
http://www.cecill.info/licences/Licence_Ce
CILL-C_V1-en.html
5. The BSD 3-Clause License,
http://www.opensource.org/licenses/BSD-
3-Clause
6. The MIT License,
http://www.opensource.org/licenses/MIT
7. Apache License, version 2.0,
http://www.apache.org/licenses/LICENSE-
2.0.html
8. What is copyleft?,
http://www.gnu.org/copyleft/copyleft.en.h
tml
9. What is copyleft? Is it the same as “open-
source“?,
http://www.opensource.org/faq#copyleft
10. Permissive Free Software License,
http://en.wikipedia.org/wiki/Permissive_fr
ee_software_license
11. What is a “permissive” Open Source
License?,
http://www.opensource.org/faq#permissi
ve
12. OREKIT (ORbits Extrapolation KIT) : CS
lance la 1ère bibliothèque Java
opérationnelle de mécanique spatiale en
logiciel libre, http://www.c-s.fr/OREKIT-
ORbits-Extrapolation-KIT-CS-lance-la-
1ere-bibliotheque-Java-operationnelle-de-
mecanique-spatiale-1-en-
logiciel_a206.html
13. The Cathedral and the Bazaar, Eric S.
Raymond, 1997,
http://www.catb.org/~esr/writings/homest
eading/cathedral-bazaar/
14. Orekit forge,
https://www.orekit.org/forge/projects/orek
it
15. Orekit blog, https://www.orekit.org/blog/
16. Orekit mailing lists,
https://www.orekit.org/wws/lists/orekit
17. Semi-analytical Satellite Theory for the
OREKIT Open-source Space Flight
Dynamics Library, Paul J. Cefola, Juan
Félix San Juan, Luc Maisonobe, Pascal
Parraud, Romain Di Costanzo, 5th
International Conference on
Astrodynamics Tools and Techniques -
ICATT 2012
18. Semi-analytical Satellite Theory for
Everyone: An Open-Source
Implementation of the DSST model, Paul
J. Cefola, Luc Maisonobe, Pascal Parraud,
Romain Di Costanzo , SpaceOPS 2012
19. The SIRIUS Flight Dynamics Library for
the next 25 Years, Denis Claude, Yannick
Tanguy, 5th International Conference on
Astrodynamics Tools and Techniques -
ICATT 2012
20. SKAT: a versatile station-keeping analysis
Tool for LEO and GEO , Pascal Parraud,
Luc Maisonobe, Jose Maria De Juana
Gamo, 5th International Conference on
Astrodynamics Tools and Techniques -
ICATT 2012
21. Governance models, http://www.oss-
watch.ac.uk/resources/governanceModels
.xml
22. Benevolent Dictator Governance Model,
http://www.oss-
watch.ac.uk/resources/benevolentdictator
governancemodel.xml
23. Meritocratic Governance Model,
http://www.oss-
watch.ac.uk/resources/meritocraticGover
nanceModel.xml
24. Apache meritocracy,
http://www.apache.org/foundation/how-it-
works.html#meritocracy
... Since 2008, Orekit is distributed under the Apache License version 2.0. 18 Orekit provides various functionalities related to coordinate transformations, reading and writing of standardized formats, orbit propagation, and orbit determination using batch-least squares algorithm and recursive filters. ...
Conference Paper
Full-text available
The paper presents an open-source orbit determination application based on the Draper Semi-analytical Satellite Theory (DSST) and a recursive filter, the Extended Semi-analytical Kalman Filter (ESKF). The ESKF reconciles the conflicting goal of the DSST perturbation theory (i.e., large step size) and the Extended Kalman Filter (EKF) theory (i.e., re initialization at each measurement epoch). Validation of the Orekit ESKF is demonstrated using simulated data. Both the satellite’s state vector estimation and the measurement residuals are used as comparison metrics.
... It was first developed by CS GROUP in 2002 as a private library for the company collaborators. In 2008, the library evolved towards an open-source project under Apache v2.0 License [8]. Orekit is now used worldwide, both by academics and industries, to realize space applications, studies and operations. ...
Conference Paper
Full-text available
Earth orbital space suffers from the ever increasing count of space objects, including operational satellites and space debris. Space system operations rely on the management of vast catalogs of objects to avoid any damaging collision. NORAD (North American Aerospace Defense Command) and NASA (National Aeronautics and Space Administration) both maintain a database for a large quantity of orbiting objects. Data are stored as Two Line Elements (TLE) and used along with specific analytical propagation models. Operation centers need Orbit Determination methods to accurately compute conjunctions and collision probabilities. With more and more flying objects, computations must be fast enough to ensure satellite safety. Mixing Orbit Determination and TLE analytical propagation models appears to be an effective way to grant security in space. This paper presents an open-source solution for an Orbit Determination method based on TLE propagation models. The method was implemented and validated inside the Orekit space mechanic library. It was then confronted with a classical numerical Orbit Determination on a GNSS test case.
... Orekit project started in 2002 as an in-house closed project developed by CS Group. Since 2008 Orekit is distributed under the open-source Apache License version 2.0 [14]. Fig. 1 illustrates the packages organization in Orekit. ...
Conference Paper
Full-text available
Orbit Determination is a technique used to estimate the position of a satellite from its observable measurements. Missing or incorrect modeling of troposphere and ionosphere delays is one of the major error source in space geodetic techniques such as Global Navigation Satellite Systems (GNSS). Accurate computation of these two delays is a mandatory step to cope with accuracy needs which are close to centimeter or millimeter levels. This paper presents the different steps of development of estimated tropospheric and ionospheric models. All these models are included in the Orekit open-source space flight dynamics library. Adding estimated tropospheric and ionospheric models into an orbit determination process can be a difficult procedure. Computing and validating measurement derivatives with respect to troposphere and ionosphere parameters are critical steps. To cope with this constraint, we used the Automatic Differentiation technique to avoid the calculation of the derivatives of long equations. Automatic Differentiation is equivalent to calculating the derivatives by applying chain rule without expressing the analytical formulas. Therefore, Automatic Differentiation allows a simpler computation of the derivatives and a simpler validation. This paper presents how the Jacobian measurement matrix is computed by Automatic Differentiation. It also describes the impact of using estimated tropospheric and ionospheric models. Finally, a study of different model configurations is performed in order to highlight the relevant tropospheric and ionospheric parameters to estimate. The performance of the different models is demonstrated under GPS orbit determination conditions. Both satellite state vector estimation and measurement residuals quality are used as indicator to quantify the orbit determination performance. This paper addresses that estimated tropospheric and ionospheric models are actually more accurate than empirical models to estimate satellite state vector in GNSS orbit determination. A gain of about 60% is obtained on the estimation of the satellite position when estimated models are used, without altering the computation time.
... The phase angle l is the mean longitude. The GMA involves the assumption of a transformation from the mean (2) elements to the osculating elements and an assumed form for the mean element equations of motion. The Fortran 77 DSST exists in two forms: 4. As an option within the MIT GTDS orbit determination system [25] 5. ...
Conference Paper
Full-text available
Verification of the java Orekit implementation of the Draper Semi-analytical Satellite Theory (DSST) is discussed. The Orekit library for space flight dynamics has been published under the open-source Apache license V2. The DSST is unique among analytical and semi-analytical satellite theories due to the scope of the included force models. However, the DSST has not been readily accessible to the wider Astrodynamics research community. Implementation of the DSST in the Orekit library is a comprehensive task because it involves the migration of the DSST to the object-oriented java language and to a different functional decomposition strategy. The resolution of the code and documentation anomalies discovered during the verification process is the important product of this project.
Conference Paper
Full-text available
Space agencies generally use numerical methods to meet their orbit determination needs. Due to the ever increasing number of space objects, the development of new orbit determination methods becomes essential. DSST is an orbit propagator based on a semi-analytical theory. It combines the accuracy of numerical propagation and the speed of analytical propagation. The paper presents an open-source DSST orbit determination application included in the Orekit library. Accuracy of the DSST orbit determination is demonstrated by comparison with a numerical method. Both the satellite's state vector estimation and the measurement residuals are used as comparison metrics.
Conference Paper
Full-text available
SKAT is a station-keeping simulator, which aims at building and evaluating different Orbit Maintenance Strategies for LEO and GEO spacecrafts of interest to EUMETSAT. SKAT enables to: 1) propagate orbits over long time spans, accounting for realistic effects, 2) automatically introduce maneuvers in the propagation process, according to control targets, margins and constraints, 3) analyze the performance of the achieved strategy by providing key performance parameters for single spacecrafts or spacecraft pairs. SKAT is a standalone Java application with a highly modular design. Its dynamic behavior is driven by one main loop, which mimics a classical station-keeping process, with an inside control loop for maneuvers computation according to parameterized control laws. Typical GEO and LEO study cases are presented.
Semi-analytical Satellite Theory for the OREKIT Open-source Space Flight Dynamics Library
  • Paul J Cefola
  • Juan Félix San Juan
  • Luc Maisonobe
  • Pascal Parraud
Semi-analytical Satellite Theory for the OREKIT Open-source Space Flight Dynamics Library, Paul J. Cefola, Juan Félix San Juan, Luc Maisonobe, Pascal Parraud, Romain Di Costanzo, 5 th International Conference on Astrodynamics Tools and Techniques -ICATT 2012
Semi-analytical Satellite Theory for Everyone: An Open-Source Implementation of the DSST model
  • Paul J Cefola
  • Luc Maisonobe
  • Pascal Parraud
Semi-analytical Satellite Theory for Everyone: An Open-Source Implementation of the DSST model, Paul J. Cefola, Luc Maisonobe, Pascal Parraud, Romain Di Costanzo, SpaceOPS 2012
  • The Cathedral
  • Eric S Bazaar
  • Raymond
The Cathedral and the Bazaar, Eric S. Raymond, 1997, http://www.catb.org/~esr/writings/homest eading/cathedral-bazaar/ 14. Orekit forge, https://www.orekit.org/forge/projects/orek it 15. Orekit blog, https://www.orekit.org/blog/ 16. Orekit mailing lists, https://www.orekit.org/wws/lists/orekit