Speaker
Mr
Philippe PAVERO
(CAPGEMINI)
Description
The objective of this article is to present the current state of the CNES flight dynamics software ELECTRA maintained by Capgemini and some of the main principles used for validating its scientific and computational facets in an industrial context.
First of all, we will describe the development history. Some pieces of software have been created by industry. Other parts have been developed initially by research teams, based on the ELECTRA method the CNES developed, followed by an industrialization process to meet industrial standards and code quality requirements.
Following the prototype phase, the development of the operational tool ELECTRA was decided by CNES Steering Committee of Safeguard Working Group in July 2006 and started in 2007. At the beginning, ELECTRA was implemented for internal CNES safety needs, but it was soon provided to space operators to assess victim risk associated with their operations and comply with the French Space Operations Act. Since December 2010, ELECTRA has been deployed and used operationally to monitor the risk associated with each launch from Guyana Space Centre in place of the existing “SUZHANE” tool. ELECTRA was written in FORTRAN.
In 2015, it was decided to port ELECTRA in JAVA.
Secondly, we will describe the functional coverage of ELECTRA. The ELECTRA software computes the risk of making a victim during atmospheric reentries, with or without taking into account protection coefficients in several contexts (Random (or Uncontrolled) reentry, Controlled reentry, launch failure, Reentry on final orbit). ELECTRA computes two complementary estimations of the risk, the probability of causing at least one victim and the expected value of the number of victims, taking into account fragmentation of the spatial vehicle after atmosphere re-entry. The risk computation is done by assessment of fragment impact location and probability of occurrence and consideration of population distribution and habitat protection.
Third, a description of the underlying architecture of the Fortran and JAVA software components will be proposed: different libraries, the role of the different libraries, how each library has been constructed to meet needs of modularity and re-use. We will also point out some limitations of the existing architecture, and pit-falls which should be avoided in JAVA future developments.
Then, we will explain the methods and principles used for validating the new version of ELECTRA (JAVA). Two different and complementary approaches are used: non-regression based on comparison with the previous version developed in Fortran language, and “from scratch” validation in case of major evolutions or implementation of new functionalities. Using examples, we will present the mechanisms, tools and documents used for following the validation of the tool through different versions, and some principles and feed-back of validating new functionalities.
As a conclusion, we will present what seems to us to be the key topics for developing and maintaining the flight dynamics software ELECTRA in terms of architecture and validation, and how this could be taken into account in developing new products.
| Applicant type | Co-author |
|---|
Primary author
Mr
Philippe PAVERO
(CAPGEMINI)
Co-authors
Mr
Guillaume ROCHAIS
(CAPGEMINI)
Mr
Mirentxu BEUVELOT
(CAPGEMINI)
