Skip to main content
Fachgebiete
Automobil + Motoren Bauwesen + Immobilien Business IT + Informatik Elektrotechnik + Elektronik Energie + Nachhaltigkeit Finance + Banking Management + Führung Marketing + Vertrieb Maschinenbau + Werkstoffe Versicherung + Risiko
DE
EN
Bücher
Zeitschriften
Themenseiten
Organisationspsychologie Projektmanagement Marketing Smart Manufacturing
Weitere Formate
Podcasts Webinare Technik Webinare Wirtschaft Kongresse Veranstaltungskalender Awards
Jetzt Einzelzugang starten
Zugang für Unternehmen
Referenzkunden
SLX-Digitalkonferenz: Zukunftswerkstatt 2024

Mehr Umsatz mit Top-Kontakten

Am 7. Mai erfahren Sie, wie Vertriebsteams Leadgenerierung, Leadnurturing und Leadstrategien effizient steuern können.
Erweiterte Suche
Anmelden
nach oben
Erschienen in:
Implementing Next-Generation Relay Services at Mars in an International Relay Network Kapitel lesen Erstes Kapitel lesen

2019 | OriginalPaper | Buchkapitel

The Cassini/Huygens Navigation Ground Data System: Design, Implementation, and Operations

verfasst von : R. M. Beswick

Erschienen in: Space Operations: Inspiring Humankind's Future

Verlag: Springer International Publishing

Einloggen

Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.

search-config
loading …

Abstract

The highly successful Cassini/Huygens mission conducted almost 20 years of scientific research in both its journey across the solar system and its 13-year reconnaissance of the Saturnian system. This operational effort was orchestrated by the Cassini/Huygens Spacecraft Navigation team on a network of computer systems that met a requirement for no more than two minutes of unplanned downtime a year (99.9995% availability). The work of spacecraft navigation involved rigorous requirements for accuracy and completeness carried out often under uncompromising critical time pressures and resulted from a complex interplay between several teams within the Cassini Project, conducted on the Ground Data System. To support the Navigation function, a fault-tolerant, secure, high-reliability/high-availability computational environment was necessary to support operations data processing. This paper discusses the design, implementation, re-implementation, and operation of the Navigation Ground Data System. Systems analysis and performance tuning based on a review of science goals and user consultation informed the initial launch and cruise configuration requirements, and then those requirements were subsequently upgraded for support of the demanding orbital tour of the Saturn System. Configuration management was integrated with fault-tolerant design and security engineering, according to cornerstone principles of Confidentiality, Integrity, and Availability, and strategic design approaches such as Defense in Depth, Least Privilege, and Vulnerability Removal. Included with this approach were security benchmarks and validation to meet strict confidence levels. The implementation of this computational environment incorporated a secure, modular system that met its reliability metrics and experienced almost no downtime throughout tour operations.

Sie haben noch keine Lizenz? Dann Informieren Sie sich jetzt über unsere Produkte:

Springer Professional "Wirtschaft+Technik"

Online-Abonnement

Mit Springer Professional "Wirtschaft+Technik" erhalten Sie Zugriff auf:

  • über 102.000 Bücher
  • über 537 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Finance + Banking
  • Management + Führung
  • Marketing + Vertrieb
  • Maschinenbau + Werkstoffe
  • Versicherung + Risiko

Jetzt Wissensvorsprung sichern!

Jetzt informieren

Springer Professional "Technik"

Online-Abonnement

Mit Springer Professional "Technik" erhalten Sie Zugriff auf:

  • über 67.000 Bücher
  • über 390 Zeitschriften

aus folgenden Fachgebieten:

  • Automobil + Motoren
  • Bauwesen + Immobilien
  • Business IT + Informatik
  • Elektrotechnik + Elektronik
  • Energie + Nachhaltigkeit
  • Maschinenbau + Werkstoffe




 

Jetzt Wissensvorsprung sichern!

Jetzt informieren
Vorheriges Kapitel Attitude Control Optimization of a Two-CubeSat Virtual Telescope in a Highly Elliptical Orbit
Nächstes Kapitel Ground Enterprise Transformation at NESDIS
Anhänge
Nur mit Berechtigung zugänglich
Fußnoten
1
In one particularly egregious case, this author was headed out one evening to enjoy a two-week winter break in Oregon, and made the poor personal decision to answer “just one more call” on his office line. After some discussion with the caller, it was determined that the MMNAV network had gone silent. Over a twelve-hour period, this author assembled a team of four system and network administrators from three separate organizations to help isolate, and finally replace what turned out to be a bad optical Ethernet transceiver. Sadly, this ended up canceling the trip as the author missed his transportation, and promptly got sick for a week. This unfortunately would not resolve the issue either, as the same transceiver would fail again the following May (at least there was a suspicion where to look) [42]. It would take a network upgrade/overhaul some years later (see Section IV for more details) to finally put these problems to rest.
 
2
No general systems metric exists over this timespan, and it represents the combination of results from the Standard Performance Evaluation Corporation [25], specific Navigation benchmark utilities (NBODY), and performance comparison of Navigation software on differing hardware platforms to come up with this scale.
 
3
Valuable digressions to go into detail about relevant key areas of high-level systems design or systems engineering of interest will be denoted in the text as Strategic Considerations, while areas of relevant technical concerns (particularly covering areas of interest for systems administration) will be called out in the text as Tactical Considerations. In addition, the “Observations and Lessons Learned” section will cover a number of such observations.
 
4
During this time, nearly 75% of all 4-mm DDS-2 tape drives (the standard used for backup for Cassini Navigation at the time) shipped to the remote site would fail shortly after arrival. After some investigation, we suspected that the poor desert roads and high altitudes (nearly 5000 ft. in some locations) were probably contributing factors. Some improvement was achieved by flying both the tapes and the drives to the site in carry-on luggage.
 
5
These two terms are not, as popularly believed, the same. Patches and other software updates may introduce bugs, especially in the currently popular Agile/DevOps software engineering paradigms. Absent other testing schemes, it is wise to adopt a “wait and see” approach to patching of critical software systems—especially in times of stress when major computer security bugs are announced. Even large companies can make mistakes! A patch failure that causes a home computer to stop working can be painful. A similar failure on a critical operations machine could end the mission. An examination of the release schedule for Microsoft and Intel software and firmware updates during the MELTDOWN/SPECTER vulnerability in January 2018 may be instructive.
 
6
Versions of this problem involving significantly larger numbers of actors are considered in the case of the Byzantine General’s Problem, or more simply Byzantine failure, while solutions to this problem are classified as Byzantine Fault Tolerance [43].
 
7
Not being able to program your own network switches for such things as server failover can be irksome when trying to explain why a particular complex setup is necessary to another engineer; however, it is hard indeed to ignore a nearly immediate 100-fold upgrade from 10 MB/s Ethernet to 1000 MB/s Ethernet.
 
8
These estimates were, as all such estimates are, woefully inadequate. See the “Observations and Lessons Learned” section and the derivation of this estimate in the appendix for more detail.
 
9
See: Amiga, NeXT, VMS, SGI-IRIX.
 
10
The astute observer will note the central benchmark requirement denoted as [4.18] in Ref. [18] and the success of the interim upgrades in increasing performance, “… by a factor of three, and the servers by a factor of six.” Increasing the speed and capability of the “…current operational [Launch/Cruise] state, on both client and server systems” meant that the goalposts would be moved significantly higher for the requirements for tour. This may have not been accidental.
 
11
One may recall the protracted struggles in the microprocessor industry at this time between CISC—complex instruction set computer (×86 processors), its branch off to EPIC—explicitly parallel instruction computing (Itanium), and RISC—reduced instruction set computer (PA-RISC, ARM, others). CISC and RISC had radically different processor architectures, while EPIC attempted to merge some traits between the two others. Code compiled for these differing processors might have significantly different performance characteristics in different areas—much like trying to compare the performance of a heavy-duty truck and a sports car. All of these processor types were in this evaluation.
 
12
For example, this author took days off to support several graduate final exams.
 
13
We did not have to pay for these, and they were not part of our evaluation. They were provided for interface with other Cassini Project Operations teams and are included for completeness.
 
14
This would be another example of “cleverness” and “ownership”—while having a redundant network connection running in parallel is par for the course for such a critical fileserver, it took considerable effort (as well as late night discussions with the facility electrician) to get a second circuit installed, powering the N + 1 redundant power strip, connected to a different Power Distribution Unit. This meant that a power failure would have to impact not only two different rooms, but two different wings of the building before the server would lose power.
 
15
To be clear, we would have been happy to support him, we just needed a larger account if he wanted to continue… .
 
16
If one thinks of a computer on a network being akin to a building on a street, NMAP will attempt to find all the openings, and NESSUS will try to open all the doors and windows.
 
Literatur
1.
Antreasian, P. G., Ardalan, S. M., Beswick, R. M., Criddle, K. E., Ionasescu, R., Jacobson, R. A., et al. (2008). Orbit determination processes for the navigation of the Cassini/Huygens mission. In AIAA-2008-3433, SpaceOps Conference, Heidelberg, Germany, May 12–16, 2008. https://​doi.​org/​10.​2514/​6.​2008-3433.
2.
Williams, P. N., Gist, E. M., Goodson, T. D., Hahn, Y., Stumpf, P. W., & Wagner, S. V. (2008). Orbit control operations for the Cassini-Huygens mission. In AIAA-2008-3429, SpaceOps Conference, Heidelberg, Germany, May 12–16, 2008. https://​doi.​org/​10.​2514/​6.​2008-3429.
3.
Beswick, R., Antreasian, P., Gillam, S., Hahn, Y. H., Roth, D., & Jones, J. (2008). Navigation ground data system engineering for the Cassini/Huygens mission. In AIAA 2008-3247, SpaceOps 2008 Conference, Heidelberg, Germany, May 12–16, 2008. https://​doi.​org/​10.​2514/​6.​2008-3247.
4.
5.
Beswick, R. M. (2017). Computer security as an engineering practice: A system engineering discussion. In IEEE: 6th International Conference on Space Mission Challenges for Information Technology (SMC-IT), September 27–29, 2017. https://​doi.​org/​10.​1109/​smc-it.​2017.​18.
6.
Beswick, R. M. (2018). Computer security as an engineering practice: A system engineering discussion. In Advances in Science, Technology and Engineering Systems Journal (ASTESJ), vol. Special Issue 5, no. Multidisciplinary sciences and Engineering, p. (to be published).
7.
Byrne, D., Frantz, C., Weymouth, T., & Harrison, J. (1980). Composers, once in a lifetime [sound recording]. Sire Records.
8.
9.
Coulouris, G., Dollimore, J., & Kindberg, T. (2005). Distributed systems, concepts and design (4th ed., p. 519). New York: Addison-Wesley.
10.
Rich, B. R. (1995). Clarence Leonard (Kelly) Johnson, 1910–1990. In A biographical memoir (p. 231), National Academy of Sciences, National Academies Press, Washington, D.C.
11.
Kranz, G. (2009). Failure is not an option: Mission control from Mercury to Apollo 13 and beyond (p. 392). New York: Simon & Schuster.
12.
Affleck, B. (2012). Argo. [Film]. USA: Warner Brothers.
13.
Beswick, R. M. (2003). Response to RFA #3, of review for Cassini Navigation, of 28 August 2003. IOM 312.D/006-2003, Jet Propulsion Laboratory, NASA, Pasadena, CA, October 15, 2003.
14.
Goddard Technical Standard, Risk management reporting, GSFC-STD-0002, Goddard Space Flight Center, NASA, Greenbelt, MD, May 8, 2009.
15.
16.
Cheswick, W. R., Bellovin, S. M., & Rubin, A. D. (2003). Firewalls and internet security, repelling the Wily Hacker (2nd ed., pp. 10–14). New York: Addison-Wesley.MATH
17.
Ekelund, J. E. (2000). Functional requirements document for the navigation software system—Encounter version. 699-SCO/NAV-FRD-501-ENC, Jet Propulsion Laboratory, NASA, Pasadena, CA, April 25, 2000.
18.
Jones, J. (1992). Navigation requirements reference document for Cassini, 699-500-4. Jet Propulsion Laboratory, NASA, Pasadena, CA, December 1992.
19.
Beswick, R. M. (2002). Cassini Navigation hardware requirements. IOM 312.D/007-2002, Jet Propulsion Lab, NASA, Pasadena, CA, September 30, 2002.
20.
Moore, G. E. (1965, April 19). Cramming more components onto integrated circuits 38(8), 114–117.
21.
22.
Walter, C. (2005, August). Kryder’s law (pp. 32–33). Scientific American.
23.
Wall, L., Christiansen, T., & Schwartz, R. (1996, September). Programming perl (2nd ed.). O’Reilly & Associates.
24.
Beswick, R. M. (2002). Initial product evaluation for Cassini Navigation upgrades. IOM 312.D/008-2002, Jet Propulsion Laboratory, NASA, Pasadena, CA, November 24, 2002.
25.
Standard Performance Evaluation Corporation, SPEC: Standard Performance Evaluation Corporation, Standard Performance Evaluation Corporation, March 1, 2018. [Online]. https://​www.​spec.​org. Accessed March 30, 2018.
26.
27.
28.
Beswick, R. M. (2017). Cassini Navigation file server storage estimates through EOM. IOM 392K-17-001, Jet Propulsion Laboratory, NASA, Pasadena, CA, March 10, 2017.
29.
Beswick, R. M. (2018). Final disposition of Cassini Assets. IOM 392K-18-002, Jet Propulsion Laboratory, NASA, Pasadena, CA, September 24, 2018.
30.
31.
Twain, M. (1894). Pudd’nhead Wilson. New York City: Charles L. Webster & Co.
32.
Skodis, E., & Liston, T. (2006). Counter hack reloaded: A step-by-step guide to computer attacks and effective defenses (2nd ed.). New York: Prentice Hall.
33.
Bishop, M. (2003). Computer security, art and science (pp. 344–345). New York: Addison-Wesley.
34.
Anderson, R. J. (2008). Security engineering: A guide to building dependable distributed systems (2nd ed.). New York: Wiley.
35.
36.
37.
38.
39.
40.
Shakespeare, W. (1599). Henry V, Act IV, Scene III. [Performance].
41.
42.
Beswick, R. M. (1997). Saturday, May 24th, [MMNAV NAV-OPS LAN] NETDOWN, JPL NETDOWN report (MMNAV NAV-OPS archive: email distribution list), Pasadena, CA, Saturday, May 24, 1997.
43.
Metadaten
Titel
The Cassini/Huygens Navigation Ground Data System: Design, Implementation, and Operations
verfasst von
R. M. Beswick
Copyright-Jahr
2019
Buch
Space Operations: Inspiring Humankind's Future

Print ISBN: 978-3-030-11535-7

Electronic ISBN: 978-3-030-11536-4

Copyright-Jahr: 2019

DOI
https://doi.org/10.1007/978-3-030-11536-4_12

    Premium Partner

    Bildnachweise