Conference PaperPDF Available

Sharing the Knowledge: An Open-Source Vision for Flight Dynamics



No caption available
No caption available
Content may be subject to copyright.
Sharing the knowledge,
an open-source vision for flight dynamics
Luc Maisonobe1 and Christine Fernandez-Martin2
CS Communication & Systèmes, Toulouse, France
Flight Dynamics systems have long been considered to be restricted fields inhabited by
strange people performing highly complex computation on specific computers with specific
languages. These systems did not really embed smoothly with the rest of the ground system.
They use their own frameworks, their own GUI, their own database, and are often triggered
either manually on dedicated computers or using very low level mechanisms like files
dropped in shared folders or scripts wrappers. These systems are costly to maintain and
clearly don't scale to today's needs with more demanding space missions and tighter
schedules. The use of old technology implies skilled engineers are difficult to find and the few
available have high hourly cost. Lots of work is to be done on interfaces because none of the
new features brought by web technology is ever used. This paper shows a different approach
for flight dynamics systems. It explains there is no reason such systems could not benefit
from the current technology. The new development paradigms are mature and well known.
They have proven useful on many critical fields and a tremendous offer of tools allows to
improve code quality, testing, validation, traceability ... The open-source approach has also
been time tested by now and is accepted for its unique features in critical systems and when
long term maintenance are needed. The Orekit library ( is an
implementation of these ideas. It is an open-source library freely available with a business-
friendly license and using state of the art models and technology. It demonstrates high
performance operational products can be embedded in modern control centers to smoothly
integrate complex flight dynamics functions right within the system. The project also shows
the open-source approach is well suited for the flight dynamics field and that putting down
some fences and sharing the code is a key feature for the success of such a library.
I. Traditional architecture
light Dynamics systems are an essential part of ground systems for space applications, just like those many
other essential parts as control center, mission center, tracking stations Two main architectures have been
used in ground systems. The first one considers Flight Dynamics as a self-contained subsystem exchanging data
with control center (AOCS and propulsion telemetry, maneuvers commands …), mission center (ephemeris,
operational forecasts, visibilities …) and tracking station (localization measurements, pointing data). The second one
embed Flight Dynamics within the control center, which acts partly as a data gateway with the other systems. In
neither case is Flight Dynamics tightly integrated with the other parts. A general interface is used to shield all
computation programs from the rest of the ground system.
Control centers typically puts flat files containing telemetry, tracking data, time-dependent atmospheric
observations on a network shared folder at predefined hours each day. The Flight Dynamics system wakes up, grab
the data, perform its computation and put its results back in the same folder. Work cycles may be triggered by the
control center scheduler, but this is often limited to an on/off action or they may be triggered by a separate scheduler
managed by flight dynamics or simply by data availability using a simple polling automaton. There is no high level
control. If a mission manager needs some prediction to be recomputed, if a maneuver should be delayed or if any
non-routine computation is needed, it has to be handled in a manual mode, mainly by specific flight dynamics
1 Flight dynamics expert, Space and Intelligence division,
2 Head of engineering department,Space and Intelligence division,
American Institute of Aeronautics and Astronautics
II. Drawbacks of the traditional architecture
This architecture is simple and well suited for routine operations. It has been successfully used for years. It has
however several drawbacks. It is seldom possible to add extra work requests, even if they correspond to already
supported computation. Spacecraft data has to be stored by flight dynamics systems because it has no access to the
central database, which implies data duplication and database updates problems. Several boilerplate mechanisms
have to be implemented several times (backups, scheduling, logs, authentication, testing or training modes …). Real
time monitoring is not possible, so if it is needed (for example for critical operations like LEOP), another operating
mode with yet another data exchange mechanism has to be set up (sometimes with duplication of the telemetry
processing chain).
As the flight dynamics programs involve specific algorithms and mathematical knowledge, they are developed
by flight dynamics experts rather than by computer science experts. They focus on their core topics so the
mathematical algorithms are efficient. They are not IT architects or even designers so the computer implementation
often leaves a lot to be desired (data handling, graphical user interface, error management, testing, integration,
separation of concerns, best practices ...). As space mechanics does not evolve at the same fast pace as computer
science, algorithms are reused and slowly polished but without complete rewrite. Computing algorithms are still
developed in FORTRAN (FORTRAN 77 for the most part, FORTRAN 90 sometimes, FORTRAN 2003 being only a
futuristic dream), graphical user interfaces are in TCL/TK, data are stored in custom flat files and shell scripting is
used for operating system integration. Such technology is clearly not the same one that is used in the other parts of
the ground system. So the flight dynamics systems becomes more and more separate, up to being on dedicated
computer. The modern techniques developed in the last decades are commonplace and every young engineer fresh
out of school knows them. So why should flight dynamics still use FORTRAN 77 and use a shell script to poll a
network shared directory when message bus are everywhere ?
One often claimed rationale is that FORTRAN is seen as THE language for numerical computation, with the
assumption that no other language can compute as accurately or as fast as it. This is false. Programming languages
are on this part almost equivalent to each other. Compilers translate some high level statement expressed in one
language or another into the same kind of basic instructions as now modern processors do perform floating point
operations by themselves. Sines, cosines and square roots are wired in the floating point units. The programming
language is a convenience for developers. FORTRAN does provide some unique convenient features like complex
types, but they are not used in flight dynamics (they are essential in electronics, though).
The previous figure shows a performance comparison for a classical operation: solving a least squares problem
by QR decomposition of large matrices. The green curve is the Java implementation used in Apache commons-math
library whereas the four other curves are FORTRAN implementations: a basic one and an highly optimized one. The
American Institute of Aeronautics and Astronautics
same type of algorithm is used in all implementations. The figure shows that the language choice is not the only key
to efficiency, the implementation is very important too. It shows it is possible to do very fast computation in Java.
Numerical comparison of the results also shows the same accuracy is achieved in all languages. In fact, at processor
level, regardless of which language is used, almost the same work is done in Apache commons-math and Lapack, so
the same results are obtained, both in terms of performances and in terms of accuracy.
Once the pretext of only FORTRAN being the only adequate language for computation has been discarded, there
are some good reasons for using it: people skills and legacy software.
Flight dynamics engineers have been using the FORTRAN language for years and know it. They are at home
with it and don't feel the need to change. This rationale is slowly becoming less and less true as new engineers
graduate from school and don't learn this language anymore and as the new development tools are not available for
it. Considering competition in terms of speed of development, help for debugging and testing and automated
checking of code quality, the FORTRAN language is clearly behind. New developments ought to be done with
modern languages and tools.
Legacy software is a more interesting part. Space related software is difficult to validate, so new developments
are often based on legacy libraries with a few enhancements to fulfill spacecraft specific needs (a new attitude mode,
some platform constraints on maneuvers …). The maintenance cost of this systems is also plagued by skills
preservation and home grown tools maintenance for example. Without a validated modern alternative, flight
dynamics teams keep using their legacy product line and a vicious circle is engaged. Even if they want to get rid of
some aging software packages, short term cost reductions pressure prevent them from restarting everything from
scratch in-house. There is also little incentive for commercial editors to develop new low level layers (orbit
propagation, operational forecasts …) as there are almost no differentiating features from competitors (except for a
modernized infrastructure). Editors wants to provide a full software stack, and focus on the high level part (SSA
being the current hot topic).
III. Looking outside
Systems architectures have tremendously evolved everywhere in the rest of the IT industry. Cost and risk
reductions have lead researchers to create new development methods, new languages, new tools. Integrated
development environment provide many features to ease development and avoid (or at least detect early) some
programming errors. These productivity gains compensate on the long term the skills acquisition cost. On the
negative side, the environments are most complex to manage and they evolve, so some continuous training is often
needed. These “new” techniques have been time-tested for decades (object-oriented programming, design patterns,
MVC, 3-tiers architectures, distributed systems …) or at least years (service oriented architecture, agile
programming, test-driven development, collaborative tools, continuous integration ...).
As opposed to flight dynamics, the market for low infrastructure layers in general systems is large, which
allowed investments to be spent in competitive research. Now network-centric applications have been deployed in
financial and commerce domains, the market has matured a lot and the low layers are standardized. The offer for
such low layers is currently dominated by open-source implementations. Interoperability between services provided
by different vendors is the rule. The basic blocks from which applications are built have grown from mere classes at
object-oriented programming language level to components and then to services, following a natural path towards an
ever increasing abstraction level.
Flight dynamics market is much smaller than e-commerce, but its needs are also of much smaller size. It could
also benefit from the same solutions and follow the trend of standardizing the low level parts, sharing costs and
efforts in developing these parts in an open-source collaborative way, optimizing investments on high level
applications were competition occurs. This would allow cheap maintenance and evolution of the shared layers, bring
the field back to up-to-date technology with smoother integration in complex systems, open the way to more
interactive or real-time applications, eliminate data and features redundancy by being directly embedded with the
control center and optimize human resources management with flight dynamics engineers doing real flight dynamics
Despite price is often seen as the first feature of open-source products, it is not the key point. The most
interesting feature is the fact the source code is available, both for reviewing and for modifying. This is a very
important point in flight dynamics systems. For real critical applications, it is important to really know what happens
under the hood, which physical models are used and how they are implemented. It is also important to be able to
either fix some problems quickly without having to wait for next release, hoping your problem has been addressed
or to adapt the system to your needs and data interfaces.
American Institute of Aeronautics and Astronautics
IV.The Orekit approach
The Orekit library ( is such an open-source library for space flight dynamics using
modern languages, methods and tools. The library has been in development since 2002. Version 3.1was the first
version released as an open-source product in 2008, followed by 4.0 in late 2008, 4.1 in summer 2009 and 5.0 in
early 2010.
From a pure flight dynamics point of view, Orekit provides basic elements (orbits, dates, attitude, frames ...) and
various algorithms to handle them (conversions, analytical and numerical propagation, pointing ...). It features both
the latest available physical models and the classical ones used for compatibility with legacy systems. A typical
example is the frames package with the CIO-based frames from IERS conventions 2003 and the older equinox-
based frames like TEME used in TLE for example. From a computer science point of view, Orekit is based on the
ubiquitous Java language and its architecture follows best practices and well accepted design patterns. From a mixed
flight dynamics and computer science point of view, Orekit is designed to be simple to use without sacrificing
accuracy. Physical models configuration can be handled automatically by the library itself so complex models can be
used by non-specialists while still taking into account all technical details. The dual flight dynamics and computer
science aspects have also inspired some unique features. As an example, the event-based principles used in graphical
user interfaces and the g-stop features invented by mathematicians for ordinary differential equations have been
combined in a new way to handle discrete events within continuous orbit propagation algorithms, greatly
simplifying development of operational programs.
Orekit is an example of the sharing principles explained above. The source code can be shared by all
stakeholders of space flight dynamics. The chosen license is the Apache V2.0 software license. It is a well known
license belonging to the “business friendly” category (as opposed to the “copyleft” category). Like all other free
software licenses it respect the four freedoms (freedom to run, freedom to study and modify, freedom to redistribute,
freedom to distribute modified copies). It does not mandate reuse of the same license for derived work, thus
allowing commercial companies to build closed-source products on top of Orekit.
As Orekit is available for everyone to use in its own software stack, different teams can provide alternate
implementation and customers can select the best suited for their purposes without worrying too much about
integrating them together in a ground system: as they are based on the same low level layer, data structures, concepts
and behavior are consistent from the ground up. There is no urge to select a complete suite from one provider only
and no vendor lock-in. The library is a building block for software integrators and they can adapt it easily to build
American Institute of Aeronautics and Astronautics
custom solutions.
The library is already in use in several projects. Its first operational use was for the Jules Verne Automated
Transfer Vehicle docking to the International Space Station in 2008. Orekit was used to monitor in real time the
rendez-vous phase and reconstruct the geometry using several independent sensors data.
The feedback from users is unanimously positive and many see its availability as an opportunity to switch to
more modern concepts and tools for next generation flight dynamics systems. The open-source approach was a very
good surprise for many observers. They agree with the approach and the first contributions from users have been
integrated in the latest library versions. Orekit has been brought to the flight dynamics community so they can use it
and build their own programs on top of a shared infrastructure. Orekit will evolve the community will see fit.
V. Conclusion
Flight dynamics systems have long been a separate subsystem in ground systems, using old techniques that are
more and more difficult to maintain and to integrate with the other more modern subsystems. The historic use of the
FORTRAN language and some reluctance to change have engaged a vicious circle preventing innovation. An open-
source approach mimicked on what was observed in the rest of IT industry for low level infrastructure layers can be
used to escape from this vicious circle. All flight dynamics stakeholders can share a common basis developed with
modern languages, tools and methods and freely available to everyone. The open-source Orekit library is such a
basis. It is freely available under the terms of a business friendly license, so it can be used by open-source and
closed-source commercial products. It has been flight-proven with the ATV/ISS mission in 2008. The community is
gathering around the product and its approach.
American Institute of Aeronautics and Astronautics
... The program was integrated with the above algorithms and the OREKIT library [Maisonobe, 2010] was used for the time and frame handlings. Furthermore, the results are compared with the metadata of the provided image. ...
Conference Paper
Full-text available
The aim of this study is to calculate the geolocation of an image acquired from an electro-optic earth observation satellite using the satellite external and internal orientation parameters. The main purpose of this study is to determine the intersecting coordinates of an ellipsoid model defined according to WGS84 and a looking vector. In the first phase, these calculations will be conducted without any Digital Terrain Model (DTM). In order to compare the results, in a second phase, the same calculations will be conducted with DTM. For demonstration purposes, a geolocation software will be developed using open-source libraries. This software will be tested with sample data from the SPOT-5 satellite. There are several plug-ins for certain open source and commercial Geographical Information Systems (GIS) software. One of the objectives of this study is to later develop an independent program which will be used to assist in the development of a satellite and a ground station image processing unit. This program is also intended to be used in the training of individuals with various areas of expertise.
... Bu çalışmada güneş senkronize ve yer izi tekrarlı dairesel donuk yörünge tasarım algoritması icra edilmiş ve kullanıcı ara yüzü ile birleştirilerek bir tasarım aracı haline getirilmiştir. Temel olarak OREKIT 10.0 Uçuş Dinamikleri kütüphanesinden yararlanılmıştır [Maisonobe, 2010]. Bu bölümde tasarım aracı içerisindeki algoritma üzerinde durulacak ve tasarımın matematiği aktarılacaktır. ...
Conference Paper
Full-text available
Bu çalışmada güneş senkronize ve tekrarlı yer izine sahip donuk dairesel yörüngeleri tasarlayabilen bir yazılım geliştirilmiş, matematiksel temelleri açıklanmış ve kullanıcılar için bir arayüz oluşturulmuştur. Bu bağlamda oluşturulan yazılım Java tabanlı olup OREKIT 10.0 kütüphanesi kullanılarak yazılmıştır. Çalışmanın temel hedefi, “FreeFlyer Demo V7.5” programı içerisinde bulunan “Güneş Senkronize Tekrarlı Yer İzi Yörünge Tasarım Sihirbazının” hesapladığı yörünge verisini açık kaynak kodlu kütüphaneler ve literatürde sıklıkla kullanılan hesaplamalar ile üretmek, bu sayede ticari yazılım bağımlılığını ortadan kaldırmaktır. Yazılım içindeki algoritma, OREKIT 10.0 kütüphanesinde bulunan örnekler yardımıyla “FreeFlyer” algoritmasına yakınsanmıştır. Yazılım çıktıları olan “Ekvatoral Geçiş Noktaları” ve “Gök günlüğü”, “FreeFlyer” çıktıları ile karşılaştırılmış, hata analizi yapılarak sonuçların tutarlılığı gösterilmiştir.
... Orekit has been selected in early 2011 by CNES to be the basis of its next generation space flight dynamics systems, including operational systems, study systems and mission analysis systems. 12 Tide modelling is a recent Orekit feature, released in December 2013. It is based on the IERS conventions models. ...
Conference Paper
Full-text available
Open source software tools have been gaining acceptance in the astrodynamics community for some applications, though heritage tools still dominate precision orbit determination and propagation. This paper examines recent tide modeling improvements in the open source Orbit Extrapolation Toolkit (Orekit) and compares it with the US Naval Research Laboratory's (NRL) heritage Orbit Covariance Estimation And ANalysis (OCEAN) system. First, the two tools are compared directly against each other by propagating a given state vector for Stella, a geodetic satellite sensitive to tidal variations in the geopotential. Second, orbits were fit to International Laser Ranging Service (ILRS) laser ranging data using OCEAN and orbit determination software built around Orekit so that a more useful comparison could be made. Five days of data were used to solve for orbital parameters using OCEAN and Orekit. This solution orbit is then propagated forward 25 days and compared to subsequent five day orbit solutions. This comparison between predicted and fitted orbit solutions is used as a metric to compare the quality of each piece of software's dynamic modeling capability. Results from the direct orbit propagation comparison indicate the RSS of postion difference between the OCEAN and Orekit propagated orbit grow to only 7 meters over 25 days. It is also seen that the difference between OCEAN's and Orekit's implementation of Earth tides are less than 3% of the total tidal effect. The results of the orbit determination analysis show that the Orekit orbit solution comparison is at worst on the same order of magnitude in accuracy as the OCEAN orbit solution comparison, and at best more accuate than the OCEAN orbit solution comparison. While OCEAN produces a more accurate orbit prediction than Orekit in the majority of the cases studied, more testing is need to understand the origin of the difference.
Conference Paper
Full-text available
In this study, a computer software so called "ColAvo" is introduced along with the developed algorithms. The "ColAvo" can parse the Conjunction Data Messages, illustrates the possible conjunction between two earth orbiting objects and computes the collision avoidance maneuver. The main objective of this study is to help the satellite operators to reduce the decision time of the collision avoidance maneuver, since the conjunction assessment operations require quick actions. The software initially let the user to understand the possible collision by visualizing the provided Conjunction Data Message via Visualization Tool For Space. Afterwards, the developed targeting algorithm is used to calculate the collision avoidance maneuver according to the user inputs. The software development is done by using OREKIT 10.0 library in JAVA. Furthermore, the algorithm tests are done with the GMAT and the FreeFlyer software.
Full-text available
Japanese Title: 多重ディスパッチとメタプログラミングに着目した構成可能なアストロダイナミクスソフトウェアの構築 Abstract: Modern planetary exploration missions increasingly operate in ever more complex dynamical environments, and require designs for lower cost, higher efficiency, and more ambitious trajectories. Current computational astrodynamics practice utilises techniques from simulation and analysis of dynamical systems to better understand and exploit the chaotic dynamics of the solar system. In this thesis, new computational astrodynamics tools are developed to leverage Julia, a modern, high-performance numerical programming language that combines high-level abstraction with the computational efficiency of dynamic compilation. Julia enables the development of highly composable and extensible programs, with state-of-the-art performance and applications across many scientific fields. Its unique combination of language features, most notably of multiple dispatch and meta-programming, provide opportunities to develop software that exploits performant automatic differentiation and automated composition to enable more composable, accurate, and higher performance software designs. These modern numerical programming language features are applied in OrbitalTrajectories.jl, a proof-of-concept trajectory design toolkit developed as part of this thesis to demonstrate the consequences of such features towards applications in astrodynamics. The toolkit’s composability, extensibility, and performance are briefly compared to JAXA’s in-house jTOP trajectory propagation and optimisation tool, outperforming it by up to an order of magnitude in orbital propagation. Advanced capabilities are also demonstrated, including composition of dynamical models, generic N-order State Transition Tensors (STTs) with support for Automatic Differentiation (AD) and symbolic Variational Equations (VE), dynamic retrieval of ephemeris kernels, and more. In addition, simple motivating proof-of-concepts are provided for generating quasi-periodic orbit families via a generic single-shooting correction scheme, as well as for computing expectations under orbital uncertainty. Through these demonstrations, the motivation, implementation, and application of the developed toolkit serve to motivate the use of modern numerical language features towards more efficient development of next-generation astrodynamics software. Ancillary material is available online:
ResearchGate has not been able to resolve any references for this publication.