Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “legacy flight software”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2

Developing a Multilingual Auto-coding Interface Control for the MAVERIC-II Dynamics Simulator

Simulation model development in certain high-level languages such as Python, MATLAB, or Simulink are unparalleled by their convenience and rapid turnover time. However, legacy simulation engines often depend on more traditional languages such as FORTRAN or C/C++. The NASA Marshall Aerospace Vehicle Representation in C version II (MAVERIC-II) is a modular, legacy-derived computer program used for high-fidelity, 6 degree-of-freedom (6DOF) simulation for aerospace vehicle flights and analyses of guidance and control performance with built-in mathematical modeling of environmental effects such as wind, atmosphere, and gravity as well as dispersion capability for Monte Carlo analysis. MAVERIC-II is modular in the sense that each component software element of the simulation engine may be supplanted for a higher or lower fidelity version. The design flow of the development of these models is often performed in high-level languages as mentioned previously, which must then be translated into C or C++ code to be integrated into MAVERIC-II. Using principles of model-based design, we propose a unified method of auto-coding and interfacing between several languages and MAVERIC-II, which may be generalized further to any type of 6DOF simulation engine.

Mason Nixon↗

Reconfigurable Very Long Instruction Word (VLIW) Processor

Future NASA missions will depend on radiation-hardened, power-efficient processing systems-on-a-chip (SOCs) that consist of a range of processor cores custom tailored for space applications. Aries Design Automation, LLC, has developed a processing SOC that is optimized for software-defined radio (SDR) uses. The innovation implements the Institute of Electrical and Electronics Engineers (IEEE) RazorII voltage management technique, a microarchitectural mechanism that allows processor cores to self-monitor, self-analyze, and selfheal after timing errors, regardless of their cause (e.g., radiation; chip aging; variations in the voltage, frequency, temperature, or manufacturing process). This highly automated SOC can also execute legacy PowerPC 750 binary code instruction set architecture (ISA), which is used in the flight-control computers of many previous NASA space missions. In developing this innovation, Aries Design Automation has made significant contributions to the fields of formal verification of complex pipelined microprocessors and Boolean satisfiability (SAT) and has developed highly efficient electronic design automation tools that hold promise for future developments.

Velev, Miroslav N.↗

Advanced Strategic and Tactical Relay Request Management for the Mars Relay Operations Service

This software provides a new set of capabilities for the Mars Relay Operations Service (MaROS) in support of Strategic and Tactical relay, including a highly interactive relay request Web user interface, mission control over relay planning time periods, and mission management of allowed strategic vs. tactical request parameters. Together, these new capabilities expand the scope of the system to include all elements critical for Tactical relay operations. Planning of replay activities spans a time period that is split into two distinct phases. The first phase is called Strategic, which begins at the time that relay opportunities are identified, and concludes at the point that the orbiter generates the flight sequences for on board execution. Any relay request changes from this point on are called Tactical. Tactical requests, otherwise called Orbit - er Relay State Changes (ORSC), are highly restricted in terms of what types of changes can be made, and the types of parameters that can be changed may differ from one orbiter to the next. For example, one orbiter may be able to delay the start of a relay request, while another may not. The legacy approach to ORSC management involves exchanges of e-mail with "requests for change" and "acknowledgement of approval," with no other tracking of changes outside of e-mail folders. MaROS Phases 1 and 2 provided the infrastructure for strategic relay for all supported missions. This new version, 3.0, introduces several capabilities that fully expand the scope of the system to include tactical relay. One new feature allows orbiter users to manage and "lock" Planning Periods, which allows the orbiter team to formalize the changeover from Strategic to Tactical operations. Another major feature allows users to interactively submit tactical request changes via a Web user interface. A third new feature allows orbiter missions to specify allowed tactical updates, which are automatically incorporated into the tactical change process. This software update is significant in that it provides the only centralized service for tactical request management available for relay missions.

Allard, Daniel A.↗

Reengineering legacy software to object-oriented systems

NASA has a legacy of complex software systems that are becoming increasingly expensive to maintain. Reengineering is one approach to modemizing these systems. Object-oriented technology, other modem software engineering principles, and automated tools can be used to reengineer the systems and will help to keep maintenance costs of the modemized systems down. The Software Technology Branch at the NASA/Johnson Space Center has been developing and testing reengineering methods and tools for several years. The Software Technology Branch is currently providing training and consulting support to several large reengineering projects at JSC, including the Reusable Objects Software Environment (ROSE) project, which is reengineering the flight analysis and design system (over 2 million lines of FORTRAN code) into object-oriented C++. Many important lessons have been learned during the past years; one of these is that the design must never be allowed to diverge from the code during maintenance and enhancement. Future work on open, integrated environments to support reengineering is being actively planned.

Pitman, C.↗

SCaN Testbed Software Development and Lessons Learned

National Aeronautics and Space Administration (NASA) has developed an on-orbit, adaptable, Software Defined Radio (SDR)Space Telecommunications Radio System (STRS)-based testbed facility to conduct a suite of experiments to advance technologies, reduce risk, and enable future mission capabilities on the International Space Station (ISS). The SCAN Testbed Project will provide NASA, industry, other Government agencies, and academic partners the opportunity to develop and field communications, navigation, and networking technologies in the laboratory and space environment based on reconfigurable, SDR platforms and the STRS Architecture.The SDRs are a new technology for NASA, and the support infrastructure they require is different from legacy, fixed function radios. SDRs offer the ability to reconfigure on-orbit communications by changing software for new waveforms and operating systems to enable new capabilities or fix any anomalies, which was not a previous option. They are not stand alone devices, but required a new approach to effectively control them and flow data. This requires extensive software to be developed to utilize the full potential of these reconfigurable platforms. The paper focuses on development, integration and testing as related to the avionics processor system, and the software required to command, control, monitor, and interact with the SDRs, as well as the other communication payload elements. An extensive effort was required to develop the flight software and meet the NASA requirements for software quality and safety. The flight avionics must be radiation tolerant, and these processors have limited capability in comparison to terrestrial counterparts. A big challenge was that there are three SDRs onboard, and interfacing with multiple SDRs simultaneously complicatesd the effort. The effort also includes ground software, which is a key element for both the command of the payload, and displaying data created by the payload. The verification of the software was an extensive effort. The challenges of specifying a suitable test matrix with reconfigurable systems that offer numerous configurations is highlighted. Since the flight system testing requires methodical, controlled testing that limits risk, a nearly identical ground system to the on-orbit flight system was required to develop the software and write verification procedures before it was installed and tested on the flight system. The development of the SCAN testbed was an accelerated effort to meet launch constraints, and this paper discusses tradeoffs made to balance needed software functionality and still maintain the schedule. Future upgrades are discussed that optimize the avionics and allow experimenters to utilize the SCAN testbed potential.

radio communication↗

Managing Risk in Safety Critical Operations - Lessons Learned from Space Operations

The Mission Control Center (MCC) at Johnson Space Center (JSC) has a rich legacy of supporting Human Space Flight operations throughout the Apollo, Shuttle and International Space Station eras. Through the evolution of ground operations and the Mission Control Center facility, NASA has gained a wealth of experience of what it takes to manage the risk in Safety Critical Operations, especially when human life is at risk. The focus of the presentation will be on the processes (training, operational rigor, team dynamics) that enable the JSC/MCC team to be so successful. The presentation will also share the evolution of the Mission Control Center architecture and how the evolution was introduced while managing the risk to the programs supported by the team. The details of the MCC architecture (e.g., the specific software, hardware or tools used in the facility) will not be shared at the conference since it would not give any additional insight as to how risk is managed in Space Operations.

Gonzalez, Steven A.↗

Micrometeoroid and Orbital Debris (MMOD) Testing, Ballistic Limit Definition and Risk Assessment of the Exploration Extravehicular Mobility Unit (xEMU)

A well-known hazard associated with exposure to the space environment is the risk of failure due to an impact from a micrometeoroid and orbital debris (MMOD) particle. As NASA prepares to return astronauts to the moon with the Artemis program, the next generation of spacesuit is in development to support future extravehicular activities (EVAs.) An MMOD impact to the spacesuit is of great concern as a large leak could prevent an astronaut from safely reaching an airlock in time resulting in a loss of life. The exploration extravehicular mobility unit (xEMU) must meet MMOD requirements for multiple environments including those in low earth orbit (LEO) as well as the meteoroid and secondary lunar regolith ejecta environments found on the lunar surface. The subject of this paper is an internal xEMU configuration design developed by NASA Johnson Space Center (JSC) personnel. The xEMU shares similarities with the legacy Extravehicular Mobility Unit (EMU) spacesuit that is currently used for ISS EVAs, however differences in the layup (e.g., materials, thicknesses, and layers) of the fabric environmental protection garment (EPG), portable life support system (xPLSS) and helmet required an extensive test program to determine ballistic performance. Over 100 hypervelocity impact (HVI) tests were performed by the NASA/JSC HVIT and White Sands Test Facility (WSTF) teams on the xEMU EPG, xPLSS and helmet to generate ballistic limit equations (BLEs) for MMOD impacts. Additionally, over 50 low speed tests (< 1km/s) were performed by the NASA/JSC HVIT and Southwest Research Institute (SwRI) teams on the xEMU EPG, xPLSS and helmet to generate BLEs for lunar ejecta impacts. Post testing, ballistic limit equations (BLEs) used to define the performance of the various regions on the xEMU spacesuit were developed from a generic set of BLEs. The HVI and low speed testing was performed to establish a physical basis for the equations with the coefficients and exponents of the generic BLEs adjusted to fit the test data. The xEMU BLEs were added to the NASA/JSC software application used for spacecraft MMOD risk assessments (BUMPER-3). A finite element model (FEM) of the xEMU spacesuit, which defines the size and shape of the spacesuit as well as the locations of the various shielding configurations, was created based on a solid model provided by the xEMU program office. Using the FEM file and added xEMU BLEs, BUMPER-3 assessments of the xEMU spacesuit for probability of no penetration (PNP) were performed. For the LEO assessment of a typical ISS EVA, the orbital debris and meteoroids environments were defined using the latest engineering models, ORDEM 3.2 and MEM-3 respectively. The lunar surface assessment again used the MEM-3 engineering model to define the meteoroid environment along with the current released lunar surface ejecta model, NASA SP-8013 (developed during the Apollo Program). The Space Team in the Natural Environments Branch at Marshall Space Flight Center (MSFC) will soon release the new Lunar Meteoroid Ejecta Engineering Model (LMEEM), at which time the xEMU lunar surface EVA will be reassessed. Assessment of the MMOD risk for an 8-hour, 2-person EVA in both LEO and on the lunar surface showed that the xEMU spacesuit meets the program technical requirement of 1 in 2500 failure odds. Similar to the legacy EMU spacesuit, the majority of the MMOD risk (96% of the LEO EVA risk and 99% of the lunar surface EVA risk) is concentrated in regions of xEMU that are comprised primarily of softgoods (arms, legs, and gloves) rather than the hardgoods (xPLSS, hard upper torso and helmet).

Micrometeoroid↗

Micrometeoroid and Orbital Debris (MMOD) Testing, Ballistic Limit Equation Definition and Risk Assessment of the Exploration Extravehicular Mobility Unit (xEMU)

A well-known hazard associated with exposure to the space environment is the risk of failure due to an impact from a micrometeoroid and orbital debris (MMOD) particle. As NASA prepares to return astronauts to the moon with the Artemis program, the next generation of spacesuit is in development to support future extravehicular activities (EVAs.) An MMOD impact to the spacesuit is of great concern as a large leak could prevent an astronaut from safely reaching an airlock in time resulting in a loss of life. The exploration extravehicular mobility unit (xEMU) must meet MMOD requirements for multiple environments including those in low earth orbit (LEO) as well as the meteoroid and secondary lunar regolith ejecta environments found on the lunar surface. The subject of this paper is an internal xEMU configuration design developed by NASA Johnson Space Center (JSC) personnel. This paper will expand on the hypervelocity impact (HVI) testing and ballistic limit equation (BLE) definition work that was partially presented at the 2nd International Orbital De-bris (IOC-II) Conference held in Sugar Land, TX in December 2023. The xEMU shares similarities with the legacy Extravehicular Mobility Unit (EMU) spacesuit that is currently used for ISS EVAs, however differences in the layup (e.g., materials, thicknesses, and layers) of the fabric environmental protection garment (EPG), portable life support system (xPLSS) and helmet required an extensive test program to determine ballistic performance. Over 100 hypervelocity impact (HVI) tests were performed by the NASA/JSC HVIT and White Sands Test Facility (WSTF) teams on the xEMU EPG, xPLSS and helmet to generate ballistic limit equations (BLEs) for MMOD impacts. Additionally, over 50 low speed tests (< 1km/s) were performed by the NASA/JSC HVIT and Southwest Research Institute (SwRI) teams on the xEMU EPG, xPLSS and helmet to generate BLEs for lunar ejecta impacts. Post testing, ballistic limit equations used to define the performance of the various regions on the xEMU spacesuit were developed from a generic set of BLEs. The HVI and low speed testing was performed to establish a physical basis for the equations with the co-efficients and exponents of the generic BLEs adjusted to fit the test data. The xEMU BLEs were added to the NASA/JSC software application used for space-craft MMOD risk assessments (BUMPER-3). A finite element model (FEM) of the xEMU spacesuit, which defines the size and shape of the spacesuit as well as the locations of the various shielding configurations, was created based on a solid model provided by the xEMU program office. Using the FEM file and added xEMU BLEs, BUMPER-3 assessments of the xEMU spacesuit for probability of no penetration (PNP) were performed. For the LEO assessment of a typical ISS EVA, the orbital debris and meteoroids environments were defined using the latest engineering models, ORDEM 3.2 and MEM-3 respectively. The lunar sur-face assessment again used the MEM-3 engineering model to define the meteoroid environ-ment along with the current released lunar surface ejecta model, NASA SP-8013 (developed during the Apollo Program). The Space Team in the Natural Environments Branch at Mar-shall Space Flight Center (MSFC) will soon release the new Lunar Meteoroid Ejecta Engineering Model (LMEEM), at which time the xEMU lunar surface EVA will be reassessed. Assessment of the MMOD risk for an 8-hour, 2-person EVA in both LEO and on the lunar surface showed that the xEMU spacesuit meets the program technical requirement of 1 in 2500 failure odds. Similar to the legacy EMU spacesuit, the majority of the MMOD risk (96% of the LEO EVA risk and 99% of the lunar surface EVA risk) is concentrated in regions of xEMU that are comprised primarily of softgoods (arms, legs, and gloves) rather than the hardgoods (xPLSS, hard upper torso and helmet).

Micrometeoroid↗

Space Communications and Navigation (SCaN) Network Simulation Tool Development and Its Use Cases

In this work, we focus on the development of a simulation tool to assist in analysis of current and future (proposed) network architectures for NASA. Specifically, the Space Communications and Navigation (SCaN) Network is being architected as an integrated set of new assets and a federation of upgraded legacy systems. The SCaN architecture for the initial missions for returning humans to the moon and beyond will include the Space Network (SN) and the Near-Earth Network (NEN). In addition to SCaN, the initial mission scenario involves a Crew Exploration Vehicle (CEV), the International Space Station (ISS) and NASA Integrated Services Network (NISN). We call the tool being developed the SCaN Network Integration and Engineering (SCaN NI&E) Simulator. The intended uses of such a simulator are: (1) to characterize performance of particular protocols and configurations in mission planning phases; (2) to optimize system configurations by testing a larger parameter space than may be feasible in either production networks or an emulated environment; (3) to test solutions in order to find issues/risks before committing more significant resources needed to produce real hardware or flight software systems. We describe two use cases of the tool: (1) standalone simulation of CEV to ISS baseline scenario to determine network performance, (2) participation in Distributed Simulation Integration Laboratory (DSIL) tests to perform function testing and verify interface and interoperability of geographically dispersed simulations/emulations.

Jennings, Esther↗

Airspace Technology Demonstration 3 (ATD-3): Dynamic Routes for Arrivals in Weather (DRAW) Technology Transfer Document Summary Version 2.0

Airspace Technology Demonstration – 3 (ATD-3) is part of NASA’s Airspace Operations and Safety Program (AOSP) – specifically, its Airspace Technology Demonstrations (ATD) Project. ATD-3 is a multi-year research and development effort which proposes to develop and demonstrate automation technologies and operating concepts that enable air navigation service providers and airspace users to continuously assess weather, winds, traffic, and other information to identify, evaluate, and implement workable opportunities for flight plan route corrections that can result in significant flight time and fuel savings in en route airspace. In order to ensure that the products of this tech-transfer are relevant and useful, NASA has created strong partnerships with the FAA and key industry stakeholders. This summary document and accompanying technology artifacts satisfy the third Research Transition Product (RTP) defined in the Applied Traffic Flow Management (ATFM) Research Transition Team (RTT) Plan, which is Dynamic Routes for Arrivals in Weather (DRAW). This technology transfer consists of artifacts for DRAW Arrival Metering (AM) Operations delivered in June 2018, DRAW AM updates, and DRAW Extended Metering (XM) Operations. Blue highlighting indicates the new or modified deliverables. Some of the artifacts in this technology transfer have distribution restrictions that need to be followed. Distribution information is noted in each section. DRAW is a trajectory-based system that combines the legacy Dynamic Weather Routes (DWR) weather avoidance technology with an arrival-specific rerouting algorithm and arrival scheduler to improve traffic flows on weather-impacted arrival routes into major airports. First, DRAW identifies flights that could be rerouted to more efficient Standard Terminal Arrival Routes (STARs) that may have previously been impacted by weather. Second, when weather is impacting the arrival routing, DRAW proposes simple arrival route corrections that enable aircraft to stay on their flight plan while avoiding weather. The DRAW system proposes reroutes early enough to allow Time Based Flow Management (TBFM) to make the necessary schedule adjustments. As a result, metering operations can be sustained longer and more consistently in the presence of weather because the arrival schedule accounts for the dynamic routing intent of arrival flights to deviate around weather. The first DRAW tech transfer in June 2018 focused on arrival metering operations with the DRAW algorithm implemented in the NASA Center TRACON Automation System (CTAS) automation software. This tech transfer delivery includes updates for DRAW implemented in FAA’s TBFM 4.7 automation software and preliminary research into DRAW for XM operations.

Isaacson, Douglas R.↗

Extending the International Space Station Life and Operability

The International Space Station (ISS) is in an operational configuration with final assembly complete. To fully utilize ISS and extend the operational life, it became necessary to upgrade and extend the onboard systems with the Obsolescence Driven Avionics Redesign (ODAR) project. ODAR enabled a joint project between the Johnson Space Center (JSC) and Marshall Space Flight Center (MSFC) focused on upgrading the onboard payload and Ku-Band systems, expanding the voice and video capabilities, and including more modern protocols allowing unprecedented access for payload investigators to their on-orbit payloads. The MSFC Huntsville Operations Support Center (HOSC) was tasked with developing a high-rate enhanced Functionally Distributed Processor (eFDP) to handle 300Mbps Return Link data, double the legacy rate, and incorporate a Line Outage Recorder (LOR). The eFDP also provides a 25Mbps uplink transmission rate with a Space Link Extension (SLE) interface. HOSC also updated the Payload Data Services System (PDSS) to incorporate the latest Consultative Committee for Space Data Systems (CCSDS) protocols, most notably the use of the Internet Protocol (IP) Encapsulation, in addition to the legacy capabilities. The Central Command Processor was also updated to interact with the new onboard and ground capabilities of Mission Control Center -- Houston (MCC-H) for the uplink functionality. The architecture, implementation, and lessons learned, including integration and incorporation of Commercial Off The Shelf (COTS) hardware and software into the operational mission of the ISS, is described herein. The applicability of this new technology provides new benefits to ISS payload users and ensures better utilization of the ISS by the science community

Cecil, Andrew J.↗

Formal Safety Certification of Aerospace Software

In principle, formal methods offer many advantages for aerospace software development: they can help to achieve ultra-high reliability, and they can be used to provide evidence of the reliability claims which can then be subjected to external scrutiny. However, despite years of research and many advances in the underlying formalisms of specification, semantics, and logic, formal methods are not much used in practice. In our opinion this is related to three major shortcomings. First, the application of formal methods is still expensive because they are labor- and knowledge-intensive. Second, they are difficult to scale up to complex systems because they are based on deep mathematical insights about the behavior of the systems (t.e., they rely on the "heroic proof"). Third, the proofs can be difficult to interpret, and typically stand in isolation from the original code. In this paper, we describe a tool for formally demonstrating safety-relevant aspects of aerospace software, which largely circumvents these problems. We focus on safely properties because it has been observed that safety violations such as out-of-bounds memory accesses or use of uninitialized variables constitute the majority of the errors found in the aerospace domain. In our approach, safety means that the program will not violate a set of rules that can range for the simple memory access rules to high-level flight rules. These different safety properties are formalized as different safety policies in Hoare logic, which are then used by a verification condition generator along with the code and logical annotations in order to derive formal safety conditions; these are then proven using an automated theorem prover. Our certification system is currently integrated into a model-based code generation toolset that generates the annotations together with the code. However, this automated formal certification technology is not exclusively constrained to our code generator and could, in principle, also be integrated with other code generators such as RealTime Workshop or even applied to legacy code. Our approach circumvents the historical problems with formal methods by increasing the degree of automation on all levels. The restriction to safety policies (as opposed to arbitrary functional behavior) results in simpler proof problems that can generally be solved by fully automatic theorem proves. An automated linking mechanism between the safety conditions and the code provides some of the traceability mandated by process standards such as DO-178B. An automated explanation mechanism uses semantic markup added by the verification condition generator to produce natural-language explanations of the safety conditions and thus supports their interpretation in relation to the code. It shows an automatically generated certification browser that lets users inspect the (generated) code along with the safety conditions (including textual explanations), and uses hyperlinks to automate tracing between the two levels. Here, the explanations reflect the logical structure of the safety obligation but the mechanism can in principle be customized using different sets of domain concepts. The interface also provides some limited control over the certification process itself. Our long-term goal is a seamless integration of certification, code generation, and manual coding that results in a "certified pipeline" in which specifications are automatically transformed into executable code, together with the supporting artifacts necessary for achieving and demonstrating the high level of assurance needed in the aerospace domain.

Denney, Ewen↗

Work Coordination Engine

The Work Coordination Engine (WCE) is a Java application integrated into the Service Management Database (SMDB), which coordinates the dispatching and monitoring of a work order system. WCE de-queues work orders from SMDB and orchestrates the dispatching of work to a registered set of software worker applications distributed over a set of local, or remote, heterogeneous computing systems. WCE monitors the execution of work orders once dispatched, and accepts the results of the work order by storing to the SMDB persistent store. The software leverages the use of a relational database, Java Messaging System (JMS), and Web Services using Simple Object Access Protocol (SOAP) technologies to implement an efficient work-order dispatching mechanism capable of coordinating the work of multiple computer servers on various platforms working concurrently on different, or similar, types of data or algorithmic processing. Existing (legacy) applications can be wrapped with a proxy object so that no changes to the application are needed to make them available for integration into the work order system as "workers." WCE automatically reschedules work orders that fail to be executed by one server to a different server if available. From initiation to completion, the system manages the execution state of work orders and workers via a well-defined set of events, states, and actions. It allows for configurable work-order execution timeouts by work-order type. This innovation eliminates a current processing bottleneck by providing a highly scalable, distributed work-order system used to quickly generate products needed by the Deep Space Network (DSN) to support space flight operations. WCE is driven by asynchronous messages delivered via JMS indicating the availability of new work or workers. It runs completely unattended in support of the lights-out operations concept in the DSN.

Zendejas, Silvino↗

Constellation Program Lessons Learned: Detailed Lessons Learned - Volume 2

These lessons learned are part of a suite of hardware, software, test results, designs, knowledge base, and documentation that comprises the legacy of the Constellation Program. The context, summary information, and lessons learned are presented in a factual format, as known and described at the time. While our opinions might be discernable in the context, we have avoided all but factually sustainable statements. Statements should not be viewed as being either positive or negative; their value lies in what we did and what we learned that is worthy of passing on. The lessons include both "dos" and "don ts." In many cases, one person s "do" can be viewed as another person s "don t"; therefore, we have attempted to capture both perspectives when applicable and useful. While Volume I summarizes the views of those who managed the program, this Volume II encompasses the views at the working level, describing how the program challenges manifested in day-to-day activities. Here we see themes that were perhaps hinted at, but not completely addressed, in Volume I: unintended consequences of policies that worked well at higher levels but lacked proper implementation at the working level; long-term effects of the "generation gap" in human space flight development, the need to demonstrate early successes at the expense of thorough planning, and the consequences of problems and challenges not yet addressed because other problems and challenges were more immediate or manifest. Not all lessons learned have the benefit of being operationally vetted, since the program was cancelled shortly after Preliminary Design Review. We avoid making statements about operational consequences (with the exception of testing and test flights that did occur), but we do attempt to provide insight into how operational thinking influenced design and testing. The lessons have been formatted with a description, along with supporting information, a succinct statement of the lesson learned, and recommendations for future programs and projects that may be placed in similar circumstances.

Jennifer Rhatigan↗

Lunar Search & Rescue Applications of Lunar GNSS

Accurate lunar navigation and timing knowledge provides for the development of safety-critical services in the cislunar and lunar surface domain. Currently under development, the Goddard Space Flight Center’s (GSFC) Search and Rescue Mission Office is investigating and integrating search and rescue (SAR) capability into planned and future lunar communication and navigation interfaces. Lunar Search and Rescue (LunaSAR) development has a stated end-goal for assured, reliable, and timely indication of distress events for a wide variety of lunar surface users, including government-sponsored, commercial, and international users. LunaSAR performance requirements are modelled after the current terrestrial Cospas-Sarsat distress notification system, leveraging an internationally robust global navigation satellite system (GNSS) ecosystem as a core element of survivor locating capability. This presentation will discuss NASA’s work to develop user-focused distress messaging capabilities including infusion of example sensor data for triggering of automated distress alerts coupled with location-tagging. Additionally, the presentation will examine overall message structures, rotating fields for use in bi-directional distress messaging, and specific use cases based on NASA’s lunar exploration and lunar communication relay architectures. Modelling and simulation of LunaSAR use by individual lunar explorers will be discussed, based on notional industry and government design reference missions and mission considerations. Results from GSFC-funded Internal Research and Development (IRAD) efforts will be detailed, including successful distress message formulation simulating the ingestion of example legacy space suit telemetry fields. Hardware-in-the-loop testing using high-reliability software defined radio (SDR) modules serve as an example of IRAD successes and the framework for technical requirements. Architectural development and technical evolution from 2020 to 2021 included alignment of LunaSAR distress waveforms with ongoing NASA LunaNet interoperability development, as well as engagement with NASA Lunar Spectrum authorities for allocation of UHF-band distress frequencies on the lunar surface. S-Band and UHF-band transmission characteristics will be detailed, along with band-specific applications of each emission type. Additionally, examples of ingestion and formatting of GNSS signals (using historical terrestrial National Marine Electronics Association-formatted GNSS data) will be detailed, underscoring lunar user needs for a common lunar GNSS receiver output message framework. Maturity and ability to support evolving lunar exploration goals has been demonstrated and will be detailed, with maturity gaps such as position, navigation, and timing (PNT) and lunar reference frames identified within the context of distress message generation. Provision of LunaSAR services for lunar surface users represents a new era of ensured safety for lunar explorers and builds off of forty years of the Cospas-Sarsat program, underscoring the importance of lunar GNSS for safety-critical applications and growing interest in safe, reliable lunar surface operations. Enabled by new GNSS systems being developed by government and industry partners, NASA will continue to evolve and integrate lunar GNSS types into distress message generation, with a focus on compact and efficient message transmission over various lunar communication links. When fielded, LunaSAR will be the first dedicated search and rescue notification system employed on another celestial body. Robust lunar navigation and timing services form the core of LunaSAR capabilities, allowing for system syncing with time-dominant sensors, and high-accuracy location of those in distress while engaged in lunar surface activities.

Search and Rescue↗

Superboom Caustic Analysis and Measurement Program (SCAMP) Final Report

The objectives of the Superboom Caustic Analysis and Measurement (SCAMP) Program were to develop and validate, via flight-test measurements, analytical models for sonic boom signatures in and around focal zones as they are expected to occur during commercial aircraft transition from subsonic to supersonic flight, and to apply these models to focus boom prediction of low-boom aircraft designs. The SCAMP program has successfully investigated sonic boom focusing both analytically and experimentally, while gathering a comprehensive empirical flight test and acoustic dataset, and developing a suite of focused sonic boom prediction tools. An experimental flight and acoustic measurement test was designed during the initial year of the SCAMP program, with execution of the SCAMP flight test occurring in May 2011. The current SCAMP team, led by Wyle, includes partners from the Boeing Company, Pennsylvania State University, Gulfstream Aerospace, Eagle Aeronautics, and Central Washington University. Numerous collaborators have also participated by supporting the experiment with human and equipment resources at their own expense. The experiment involved precision flight of a McDonnell Douglas (now Boeing) F-18B executing different maneuvers that created focused sonic booms. The maneuvers were designed to center on the flight regime expected for commercial supersonic aircraft transonic transition, and also span a range of caustic curvatures in order to provide a variety of conditions for code validations. The SCAMP experiment was designed to capture concurrent F-18B on-board flight instrumentation data, high-fidelity ground-based and airborne acoustic data, and surface and upper air meteorological data. Close coordination with NASA Dryden resulted in the development of new experimental instrumentation and techniques to facilitate the SCAMP flight-test execution, including the development of an F-18B Mach rate cockpit display, TG-14 powered glider in-flight sonic boom measurement instrumentation and "Where's the Focus?" (WTF) software for near-real time way-point computation accounting for local atmospherics. In May 2011, 13 F-18B flights were conducted during 5 flying days over a 2 week period. A densely populated 10,000 ft-long ground acoustic array with 125-ft microphone spacing was designed to capture pre-, focus, and post-focus regions. The ground-based acoustic array was placed in a nominally east-west orientation in the remote Cuddeback lakebed region, north of Edwards AFB. This area was carefully selected to avoid placing focused booms on populated areas or solar power facilities. For the SCAMP measurement campaign, approvals were obtained to temporarily extend the Black Mountain supersonic corridor northward by three miles. The SCAMP flight tests successfully captured 70 boom events, with 61 focus passes, and 9 calibration passes. Seventeen of the focus passes and three of the calibration passes were laterally offset; with the others being centerline flights. Airborne incoming sonic boom wave measurements were measured by the TG-14 for 10 of the F-18B flight passes including one maximum focus signature, several N-u combinations, several overlapped N-u signatures, and several evanescent waves. During the 27-month program, the SCAMP team developed a suite of integrated computer codes with sonic boom focusing predictive capabilities: PCBoom, Lossy Nonlinear Tricomi Equation Method (LNTE) and the Nonlinear Progressive wave Equation (NPE) method. PCBoom propagates the rays through the atmosphere and, in addition to legacy focus signature prediction based on the Gill-Seebass method, provides input source characteristics and propagation parameters to LNTE and NPE. LNTE, a Tricomi solver that incorporates atmospheric losses, computes the focus signature at the focus, and computes the focus signature in the vicinity of the focal zone, including the evanescent and post-focus zones. LNTE signature auralization from low-boom vehicle designs has been demonstrated in the NASA Langley Interior Effects Room (IER). The NPE has also been validated for use in prediction of focused ground boom signatures in sonic boom focal zones. The NPE formulation has the capability to incorporate atmospheric turbulence in the predictions. This has been applied to sonic boom propagation in the past. Prediction of turbulence effects on focal zone signatures was not, however, explored during the SCAMP program.

Page, Juliet↗

DSN Beowulf Cluster-Based VLBI Correlator

The NASA Deep Space Network (DSN) requires a broadband VLBI (very long baseline interferometry) correlator to process data routinely taken as part of the VLBI source Catalogue Maintenance and Enhancement task (CAT M&E) and the Time and Earth Motion Precision Observations task (TEMPO). The data provided by these measurements are a crucial ingredient in the formation of precision deep-space navigation models. In addition, a VLBI correlator is needed to provide support for other VLBI related activities for both internal and external customers. The JPL VLBI Correlator (JVC) was designed, developed, and delivered to the DSN as a successor to the legacy Block II Correlator. The JVC is a full-capability VLBI correlator that uses software processes running on multiple computers to cross-correlate two-antenna broadband noise data. Components of this new system (see Figure 1) consist of Linux PCs integrated into a Beowulf Cluster, an existing Mark5 data storage system, a RAID array, an existing software correlator package (SoftC) originally developed for Delta DOR Navigation processing, and various custom- developed software processes and scripts. Parallel processing on the JVC is achieved by assigning slave nodes of the Beowulf cluster to process separate scans in parallel until all scans have been processed. Due to the single stream sequential playback of the Mark5 data, some ramp-up time is required before all nodes can have access to required scan data. Core functions of each processing step are accomplished using optimized C programs. The coordination and execution of these programs across the cluster is accomplished using Pearl scripts, PostgreSQL commands, and a handful of miscellaneous system utilities. Mark5 data modules are loaded on Mark5 Data systems playback units, one per station. Data processing is started when the operator scans the Mark5 systems and runs a script that reads various configuration files and then creates an experiment-dependent status database used to delegate parallel tasks between nodes and storage areas (see Figure 2). This script forks into three processes: extract, translate, and correlate. Each of these processes iterates on available scan data and updates the status database as the work for each scan is completed. The extract process coordinates and monitors the transfer of data from each of the Mark5s to the Beowulf RAID storage systems. The translate process monitors and executes the data conversion processes on available scan files, and writes the translated files to the slave nodes. The correlate process monitors the execution of SoftC correlation processes on the slave nodes for scans that have completed translation. A comparison of the JVC and the legacy Block II correlator outputs reveals they are well within a formal error, and that the data are comparable with respect to their use in flight navigation. The processing speed of the JVC is improved over the Block II correlator by a factor of 4, largely due to the elimination of the reel-to-reel tape drives used in the Block II correlator.

Rogstad, Stephen P.↗

Standards-and Component-Based Mission Operations Architecture at NASA's Goddard Space Flight Center

NASA Goddard Space Flight Center (GSFC) manages many of NASA s earth and space science satellite missions. A wide variety of commercial products and GSFC-developed software components are typically integrated into a unique system configuration for each mission. Independent development of the many mission operations center systems has led to systems that are expensive to integrate, difficult to infuse with new capabilities developed for other programs, and cumbersome to maintain. This traditional approach becomes even more problematic as NASA moves towards satellite constellations, new operations concepts, and even further budgets reductions. The GSFC Mission Services Evolution Center (GMSEC) is creating a new architecture for future missions at GSFC. Instead of selecting the best-in-class components and creating a standard control center system, GMSEC is developing component interface standards so that multiple products can plug-and-play into the configuration. Missions can then select the best components based on the merits of the product and not simply based on recent integration history at NASA. The GMSEC system utilizes a publish/subscribe information bus and standard XML-based key message interfaces. Functional components can either match directly to the interface standard, or adapters can be developed to match the product's interface to the GMSEC standard with out impacting the source product. Applications Program Interfaces (API's) are being developed to isolate the underlying middleware from the applications software and to allow the middleware product to be switched if necessary. Interface Control Documents (ICDs) between each pair of communicating components is replaced by a single message/API specification document. New applications must simply match to the information bus standards and need not worry about all of the other applications in the system. For legacy software, adapters can be developed to facilitate communications between the application and the information bus. As the approach has matured, it has become apparent that it can provide innovative solutions to some of the multi-satellite challenges facing GSFC.

Smith, Danford↗