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

Full text

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 (http://www.orekit.org/) 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.
F
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
operators.
1 Flight dynamics expert, Space and Intelligence division, Luc.Maisonobe@c-s.fr
2 Head of engineering department,Space and Intelligence division, Christine.Fernandez-Martin@c-s.fr
American Institute of Aeronautics and Astronautics
1

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
2

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
work.
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
3

IV.The Orekit approach
The Orekit library (http://www.orekit.org/) 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
4

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
5