• Home
  • Current congress
  • Public Website
  • My papers
  • root
  • browse
  • IAC-08
  • D1
  • 5
  • paper
  • Blue Screen in Space: Recommendations for Preventing and Coping with Software Anomalies

    Paper number

    IAC-08.D1.5.10

    Author

    Mr. Christopher Krupiarz, The Johns Hopkins University Applied Physics Laboratory, United States

    Coauthor

    Ms. Annette Mirantes, The Johns Hopkins University Applied Physics Laboratory, United States

    Year

    2008

    Abstract
    Flight software is an integral part of spacecraft development and operations.  Software enables intricate mission operations, autonomous operations, and science gathering. Software complexity will continue to grow as processor speed and memory availability increase.  With this complexity, however, comes the ever increasing potential for software issues, such as misunderstood requirements, user errors, and bugs, to reveal themselves in various ways.  Unfortunately, while a bug on a desktop computer may result in some data loss and a frustrated user, a software anomaly on-board a spacecraft could cause the loss of a multi-million dollar mission and/or the corresponding science capability.   As a result, great care must be taken in software development to ensure that software anomalies on-board are properly handled and analyzed.  This paper discusses techniques for handling and analyzing on-board software anomalies along with real-world lessons learned by the authors and others.
    
    Preventing anomalies during a mission begins with a well defined software development process.  As with any critical software system, successful software deployment requires strict adherence to a software process in order to avoid costly problems arising late in the development cycle.  Each step in the process is important for success.  For example, in the coding phase, the developers must follow a set of best practices for software quality that meets the needs of a high performance embedded environment.  What may be acceptable at the office application level (such as dynamic memory allocation) may not be a best practice in a flight software system.  Once the software is complete, proper training is required to ensure the users of the software, which is primarily mission operations personnel, can fully operate the system with minimal interaction with the flight software development team.  The software development team’s responsibility does not end at launch; however, as code updates in the form of patches of full-blown deliveries may be required for capability enhancement or bug fixes throughout the mission.  
    
    Finally, even with a process built upon industry best practices, anomalies occur.  Debugging a computer at a distance of millions of miles requires a fault protection system with a high degree of foresight.  As such, the software design team needs to develop a built-in system of safeguards to allow a graceful degradation of the software and a method of data collection for debugging purposes, keeping in mind, even in an optimal safing situation, that the resultant data available for analysis may be minimal.
    Abstract document

    IAC-08.D1.5.10.pdf

    Manuscript document

    (absent)