Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “agile software development”

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 73 records · Page 4

Evolution of the Scope and Capabilities of Uplink Support Software for Mars Surface Operations

In January of 2004 both of the Mars Exploration Rover spacecraft landed safely, initiating daily surface operations at the Jet Propulsion Laboratory for what was anticipated to be approximately three months of mobile exploration. The longevity of this mission, still ongoing after ten years, has provided not only a tremendous return of scientific data but also the opportunity to refine and improve the methodology by which robotic Mars surface missions are commanded. Since the landing of the Mars Science Laboratory spacecraft in August of 2012, this methodology has been successfully applied to operate a Martian rover which is both similar to, and quite different from, its predecessors. For MER and MSL, daily uplink operations can be most broadly viewed as converting the combined interests of both the science and engineering teams into a spacecraft-safe set of transmittable command files. In order to accomplish these ends a discrete set of mission-critical software tools were developed which not only allowed for conformation to established JPL standards and practices but also enabled innovative technologies specific to each mission. Although these primary programs provided the requisite capabilities for meeting the high-level goals of each distinct phase of the uplink process, there was little in the way of secondary software to support the smooth flow of data from one phase to the next. In order to address this shortcoming a suite of small software tools was developed to aid in phase transitions, as well as to automate some of the more laborious and error-prone aspects of uplink operations. This paper describes the evolution of this software suite, from its initial attempts to merely shorten the duration of the operator's shift, to its current role as an indispensable tool enforcing workflow of the uplink operations process and agilely responding to the new and unexpected challenges of missions which can, and have, lasted many years longer than originally anticipated.

CoUGAR↗

NASA ESTO Advanced Information Systems Technology (AIST)

"(Only Talk/No Publication) NASA’s Advanced Information Systems Technology (AIST) Program identifies, develops, and supports adoption of software and information systems, as well as novel computer science technologies expected to be needed by the Earth Science Division in the 5-10-year timeframe. This presentation gives an overview of the AIST Program. AIST’s previous thrusts have been New Observing Strategies (NOS) and Analytic Collaborative Frameworks (ACF). The current vision is to connect these two thrusts and integrate them into the larger concept of Earth System Digital Twins (ESDT). To implement this new vision, the AIST Program is focusing on technologies and innovative concepts with three main objectives: O1. Enable new observation measurements and new observing systems design and operations through intelligent, timely, dynamic, and coordinated distributed sensing; O2. Enable agile science investigations that fully utilize the large amount of diverse observations using advanced analytic tools, visualizations, and computing environments, and that interact seamlessly with relevant observing systems; O3. Enable the development of integrated Earth Science frameworks that mirror the Earth with state-of-the-art models (Earth system models and others), timely and relevant observations, and analytic tools. This thrust will provide technology for enabling near- and long-term science and policy decisions (“science decisions” including planning for the acquisition of new measurements; the development of new models or science analysis; the integration of Earth observations in novel ways; applications to inform choices, support decisions, and guide actions for societal benefit; etc.)."

Mathematical and Computer Sciences (General)↗

Non-Maximally Decimated Filter Banks Enable Adaptive Frequency Hopping for Unmanned Aircraft Vehicles

In the last few years, radio technologies for unmanned aircraft vehicle (UAV) have advanced very rapidly. The increasing need to fly unmanned aircraft systems (UAS) in the national airspace system (NAS) to perform missions of vital importance to national security, defense, and science has pushed ahead the design and implementation of new radio platforms. However, a lot still has to be done to improve those radios in terms of performance and capabilities. In addition, an important aspect to account for is hardware cost and the feasibility to implement these radios using commercial off-the-shelf (COTS) components. UAV radios come with numerous technical challenges and their development involves contributions at different levels of the design. Cognitive algorithms need to be developed in order to perform agile communications using appropriate frequency allocation while maintaining safe and efficient operations in the NAS and, digital reconfigurable architectures have to be designed in order to ensure a prompt response to environmental changes. Command and control (C2) communications have to be preserved during "standard" operations while crew operations have to be minimized. It is clear that UAV radios have to be software-defined systems, where size, weight and power consumption (SWaP) are critical parameters. This paper provides preliminary results of the efforts performed to design a fully digital radio architecture as part of a NASA Phase I STTR. In this paper, we will explain the basic idea and technical principles behind our dynamic/adaptive frequency hopping radio for UAVs. We will present our Simulink model of the dynamic FH radio transmitter design for UAV communications and show simulation results and FPGA system analysis.

UAV↗

Content Documents Management

The Content Documents are created and managed under the System Software group with. Launch Control System (LCS) project. The System Software product group is lead by NASA Engineering Control and Data Systems branch (NE~C3) at Kennedy Space Center. The team is working on creating Operating System Images (OSI) for different platforms (i.e. AIX, Linux, Solaris and Windows). Before the OSI can be created, the team must create a Content Document which provides the information of a workstation or server, with the list of all the software that is to be installed on it and also the set where the hardware belongs. This can be for example in the LDS, the ADS or the FR-l. The objective of this project is to create a User Interface Web application that can manage the information of the Content Documents, with all the correct validations and filters for administrator purposes. For this project we used one of the most excellent tools in agile development applications called Ruby on Rails. This tool helps pragmatic programmers develop Web applications with Rails framework and Ruby programming language. It is very amazing to see how a student can learn about OOP features with the Ruby language, manage the user interface with HTML and CSS, create associations and queries with gems, manage databases and run a server with MYSQL, run shell commands with command prompt and create Web frameworks with Rails. All of this in a real world project and in just fifteen weeks!

Muniz, R.↗

Flight Evaluation of the Army/NASA Variable Stability Fly-by-Wire Rotorcraft Aircrew Systems Concept Airborne Laboratory (RASCAL) JUH-60A

NASA Ames Research Center and the U.S. Army Aeroflight dynamics Directorate (AFDD) have performed initial flight evaluations of the Research Flight Control System (RFCS) integrated into the Army/NASA Rotorcraft Aircrew Systems Concepts Airborne Laboratory (RASCAL) JUH-GOA. The highly modified JUH-GOA Black Hawk helicopter is a full authority, high bandwidth, variable stability, in-flight simulator designed to support development of advanced flight control, sensor, and integrated display and control technologies in a fail safe environment. Preparation for flight test required an extensive hazard analysis and ground testing to ensure proper system operation. A hardware in the loop development facility was utilized to evaluate control law stability following software changes, assess servo hardover upset conditions during manual and monitor disengagements and provide pilot familiarization of test techniques and software changes prior to flight. First engagement of the RFCS was conducted on 31 Aug 2001. RFCS transfer system operation, envelope expansion and a limited rate monitor evaluation have been completed with low bandwidth and model following control laws. The presentation will discuss the following - System overview including aircraft modifications and integrated development facilities used with the RASCAL facility. - Preliminary hazard identification and mitigation prior to flight test. - Ground testing used to qualify the RFCS transfer system and verify fault monitor operation. - Flight test results of low-bandwidth and model following control law evaluations including maneuver agility, control limitations, fault monitor reliability, and recovery from manual and monitor disengagement. - Lessons learned including test techniques using a passive three-axis sidearm controller, the value of the development facility in reducing risk and crew coordination issues related to the operation of a full authority, variable stability platform. - Future research and modifications planned for the RASCAL aircraft.

Dave Arterburn↗

Understanding and Evaluating Assurance Cases

Assurance cases are a method for providing assurance for a system by giving an argument to justify a claim about the system, based on evidence about its design, development, and tested behavior. In comparison with assurance based on guidelines or standards (which essentially specify only the evidence to be produced), the chief novelty in assurance cases is provision of an explicit argument. In principle, this can allow assurance cases to be more finely tuned to the specific circumstances of the system, and more agile than guidelines in adapting to new techniques and applications. The first part of this report (Sections 1-4) provides an introduction to assurance cases. Although this material should be accessible to all those with an interest in these topics, the examples focus on software for airborne systems, traditionally assured using the DO-178C guidelines and its predecessors. A brief survey of some existing assurance cases is provided in Section 5. The second part (Section 6) considers the criteria, methods, and tools that may be used to evaluate whether an assurance case provides sufficient confidence that a particular system or service is fit for its intended use. An assurance case cannot provide unequivocal "proof" for its claim, so much of the discussion focuses on the interpretation of such less-than-definitive arguments, and on methods to counteract confirmation bias and other fallibilities in human reasoning.

Rushby, John↗

The Ejectable Data Recorder: A Lean, Risk-Informed Approach for Hardware Development

NASA is developing the Orion spacecraft to transport crew from the Earth to the Moon as part of the Artemis series of missions. To provide a crew escape capability from pre-launch through ascent, the Orion vehicle is equipped with a Launch Abort System (LAS), built by Lockheed Martin, which pulls the capsule away from the launch vehicle in the event of an abort scenario. The Ascent Abort 2 (AA-2) test flight occurred on July 2, 2019,and tested a production version of the LAS to ensure that it can operate as intended, and to collect a large data set from hundreds of sensors on the vehicle to support Orion flight certification. In the original AA-2 architecture, a single-string set of communications antennas on the LAS would downlink all of the in-flight test data to ground stations. However, that communications architecture was predicted to have data dropouts during abort and jettison of the LAS, and would not support data transmission at all after LAS jettison. As a result, a comprehensive trade study was completed, yielding the addition of antennas on the crew module (CM), a buffer/rebroadcast capability for key portions of the flight, and an ejectable data recorder (EDR) subsystem. This EDR subsystem would serve as a backup to the radio frequency (RF) communications system, and would be non-flight critical, providing a unique capability that enabled management to take a different approach with the hardware and software development. The Crew Module and Separation Ring were developed as “Class 1”Flight Hardware, albeit with some tailoring approaches to enable efficiencies. The Class 1 designation requires full rigor for flight hardware and software, documenting everything that happens to a piece of hardware from procurement through disposal, requiring a full spectrum of acceptance tests, and the highest rigor of quality assurance processes. At the other end of the spectrum, Class 3hardware is controlled, but not intended for flight, and leaves the level of rigor up to the project manager. This classification is often used for research and development projects. Similarly,Class-1E has been recently defined at NASA for ISS payloads and technology development projects that are not flight critical and do not need the full rigor of Class 1 to be successful. The EDR subsystem was challenged at commencement to adopt a skunkworks and agile-like approach to hardware development, allowing for a different risk posture than the rest of the AA-2 hardware. After initially pursuing Class 1 processes, the EDR subsystem design evolved to incorporating numerous commercial components, leading to re-designation as a Class-1E subsystem. The resulting EDR subsystem was fully successful in meeting all flight system requirements, and achieved 100% retrieval of flight test data. This paper will discuss the risk posture of the EDR subsystem and the subsequent tailoring that was enacted as part of its Class-1E status.

EDR↗

ISS Double-Gimbaled CMG Subsystem Simulation Using the Agile Development Method

This paper presents an evolutionary approach in simulating a cluster of 4 Control Moment Gyros (CMG) on the International Space Station (ISS) using a common sense approach (the agile development method) for concurrent mathematical modeling and simulation of the CMG subsystem. This simulation is part of Training systems for the 21st Century simulator which will provide training for crew members, instructors, and flight controllers. The basic idea of how the CMGs on the space station are used for its non-propulsive attitude control is briefly explained to set up the context for simulating a CMG subsystem. Next different reference frames and the detailed equations of motion (EOM) for multiple double-gimbal variable-speed control moment gyroscopes (DGVs) are presented. Fixing some of the terms in the EOM becomes the special case EOM for ISS's double-gimbaled fixed speed CMGs. CMG simulation development using the agile development method is presented in which customer's requirements and solutions evolve through iterative analysis, design, coding, unit testing and acceptance testing. At the end of the iteration a set of features implemented in that iteration are demonstrated to the flight controllers thus creating a short feedback loop and helping in creating adaptive development cycles. The unified modeling language (UML) tool is used in illustrating the user stories, class designs and sequence diagrams. This incremental development approach of mathematical modeling and simulating the CMG subsystem involved the development team and the customer early on, thus improving the quality of the working CMG system in each iteration and helping the team to accurately predict the cost, schedule and delivery of the software.

Inampudi, Ravi↗

Transcriptomics Processing Pipelines for Space Biology: An Open Source and Consensus-Driven Approach

Transcriptomics holds significant value in elucidating the relationship between gene expression, experimental factors, biological factors, and various types of omics data. Enhancing our understanding of these connections is paramount for foundational biology, which plays a pivotal role in devising solutions for challenges pertinent to both space travel and terrestrial life. The NASA GeneLab project, part of the Open Science Data Repository (OSDR.nasa.gov), seeks to accelerate space biology research through cataloging and democratizing ‘omics data, including transcriptomics. Since raw omics data are largely inaccessible to non-bioinformaticians, GeneLab works with the scientific community via the Open Science Analysis Working Groups (AWGs) to develop standard processing pipelines to generate and publish processed data. Unlike raw data, processed data have greater immediate value to diverse users with varying technical backgrounds and computational capabilities. Standardizing processing workflows is essential to match the pace of raw data generation, ensure reproducibility, and enable standardized processed data for comparison across datasets. As of June 2023, transcriptomics studies comprise over half of GeneLab datasets hosted on the OSDR, including data from bulk RNA-seq and Affymetrix or Agilent 1-Channel DNA microarray assays. In collaboration with the AWGs, GeneLab developed consensus processing pipelines for these transcriptomics data types that includes quality control, background correction (microarray only), data normalization and quantification, culminating in the detection and annotation of differentially expressed genes. The work presented here describes Nextflow implementations of GeneLab’s consensus transcriptomics pipelines that automates and accelerates processing of these datasets. In addition to the core data processing, these workflows also include raw data staging and a robust verification and validation program to identify errors in real-time, stop additional downstream computation, and preserve computational resources. These workflows are used to generate GeneLab processed data hosted on the OSDR, and are publicly available as open source software for others to use at: https://github.com/nasa/GeneLab_Data_Processing.

Jonathan Oribello↗

Towards a Decision Support System for Space Flight Operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The discrepancy of the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the three increments of this vision. These increments include (1) hardware and software system components and interfaces with the NASA ground system, (2) uncertainty management and (3) re-planning and automated execution. Each of these increments provide value independently; but some may also enable building of a subsequent increment.

Meshkat, Leila↗

Towards a decision support system for space flight operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The differences between the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the four increments of this vision. These increments include (1) the existing capabilities (2) hardware and software system components and interfaces with the NASA ground system, (3) uncertainty management and (4) re-planning and automated execution. Each of these increments provides value independently; but some may also enable building of a subsequent increment.

Ruszkowski, James↗

ACSYNT inner loop flight control design study

The NASA Ames Research Center developed the Aircraft Synthesis (ACSYNT) computer program to synthesize conceptual future aircraft designs and to evaluate critical performance metrics early in the design process before significant resources are committed and cost decisions made. ACSYNT uses steady-state performance metrics, such as aircraft range, payload, and fuel consumption, and static performance metrics, such as the control authority required for the takeoff rotation and for landing with an engine out, to evaluate conceptual aircraft designs. It can also optimize designs with respect to selected criteria and constraints. Many modern aircraft have stability provided by the flight control system rather than by the airframe. This may allow the aircraft designer to increase combat agility, or decrease trim drag, for increased range and payload. This strategy requires concurrent design of the airframe and the flight control system, making trade-offs of performance and dynamics during the earliest stages of design. ACSYNT presently lacks means to implement flight control system designs but research is being done to add methods for predicting rotational degrees of freedom and control effector performance. A software module to compute and analyze the dynamics of the aircraft and to compute feedback gains and analyze closed loop dynamics is required. The data gained from these analyses can then be fed back to the aircraft design process so that the effects of the flight control system and the airframe on aircraft performance can be included as design metrics. This report presents results of a feasibility study and the initial design work to add an inner loop flight control system (ILFCS) design capability to the stability and control module in ACSYNT. The overall objective is to provide a capability for concurrent design of the aircraft and its flight control system, and enable concept designers to improve performance by exploiting the interrelationships between aircraft and flight control system design parameters.

Bortins, Richard↗

NASA’s Satellite Needs Working Group Management Office: Developing Solutions in an Agile, Open Science Environment

Every two years, the National Aeronautics and Space Administration (NASA) leads an assessment of U.S. Federal civilian agency Earth observation needs submitted through the Satellite Needs Working Group (SNWG) survey. In four survey cycles beginning in 2016, nearly 400 high-priority satellite needs have been identified, spanning Earth Science and representing a wide variety of potential applications for Earth observation data. During each assessment cycle, new data products and services (i.e., solutions) that meet the needs of multiple agencies are identified and proposed for funding. The majority of solutions being developed or currently operational are global in scope, including harmonized land surface reflectance data from Landsat and Sentinel-2; composites of cloud properties derived from MODIS, VIIRS, and five geostationary satellites; dynamic surface water extent and land surface disturbance products derived from multiple optical and radar missions; a suite of low-latency products from the ICESat-2 mission; and a soil moisture product derived from the upcoming NISAR mission. The SNWG Management Office, within the Earth Action element of NASA’s Earth Science Division, manages both the biennial SNWG survey assessment and the development of solutions starting at full capacity with the 2020 cycle. Each solution project is required to align with NASA’s open science policy, including developing source code in an open code repository, having an open-source software license, and making all data freely available via NASA’s Earthdata website. The presentation will include an overview of the SNWG process, its emphasis on open science, and highlight several operational solutions freely available to the global research and applications communities.

Katrina Virts↗

Benchmarking and Testing of Qualcomm Snapdragon System-on-Chip for JPL Space Applications and Missions

As some space missions become more challenging due to new environments, greater distances, or more limited size, weight, and power (SWaP) constraints, spacecraft avionics must adapt to allow the spacecraft to be more autonomous and agile---eliminating the Spacecraft-Earth-Spacecraft feedback loop whenever possible. Prime examples of such missions include Aerobots (such as Ingenuity with extremely low SWaP constraints and demanding signal/image processing during flight) and landers in possibly hostile environments (such as a Europa lander mission, with limited communication capacity, high latency, and constrained power budget). To address these challenges, JPL worked with Qualcomm to demonstrate the use of their Snapdragon 801 system-on-chip (SoC) onboard the Ingenuity Helicopter on Mars. The Qualcomm Snapdragon SoC contains various subsystems, including an ARM cluster, a Graphics processing unit, a Digital Signal Processing subsystem, a Neural Processing Engine, Image Signal Processing subsystem, among others. Since the success of Ingenuity, JPL is continuing to work with Qualcomm to address other applications of the Snapdragon SoC technology. This includes the deployment of two 855 Snapdragon development boards onboard the International Space Station (ISS) for successful in-situ benchmarking of applications in space (beyond those tested on Ingenuity). In this paper, we will examine the performance of various applications that have been identified to benefit from greater onboard computational capability. These applications include (among others): machine vision algorithms that are expected to be critical in autonomous entry-descent-and-landing scenarios and real-time Aerobot flight navigation; Hyperspectral compression algorithms; Synthetic Aperture Radar Processing along with various instrument processing algorithms. We discuss how the infusion of Qualcomm's Snapdragon SoC is capable of enabling missions that may not have been able to achieve their goals with traditional flight computing. In addition, we also show that for some algorithms, the software implementation on the Snapdragon SoC outperforms traditional FPGA implementations.

Cretu, Vlad↗

Propulsive trajectory optimization to minimize surface contamination

MOTIVATION: We present an optimization technique for propulsive vehicles that autonomously minimizes contamination during surface approach and landing. In addition to short-range hoppers, the optimization technique is also fully applicable to traditional orbit-to-surface landers. This study addresses scenarios where surface alterations from propulsion events are counterproductive or hazardous to the mission objectives. This is of immediate interest for landers (whether human or robotic), that may rely on pristine soils collected in the immediate vicinity of landing sites to accomplish science investigations, mining, or ISRU surface operations. Such missions are averse to various surface-plume interactions such as thermal scoring, physical agitation, and contamination. The capability can be applied with minimal impact to the baseline mission concept. METHODS: Optimization algorithms have been developed to calculate descent trajectories and maneuvers, thrust magnitude, and attitude for various mission cases. These parameters are determined as an optimal solution when minimizing either fuel consumption, contamination deposited at the landing site, or some weighted combination of both. Among constraints imposed on the solution, we examined pitch rate, vertical takeoff and vertical landing (VTVL) requirements, size of the contamination zone, and minimum ground clearance during flight. This tool provides unique, non-intuitive solutions and can be a valuable resource for mission planners. RESULTS: A variety of agile trajectory solutions were obtained, each yielding different reductions in landing site contamination and corresponding to only modest increases in fuel consumption. Several optimal trajectories were obtained by varying the contamination weight in the fitness function. As expected, when the contamination weight is zero, the trajectory appears close to parabolic since the optimization scheme only attempts to minimize for fuel utilization, yielding essentially, the expected ballistic trajectory. Notably for contamination weights greater than zero, trajectory inflections are observed in the descent phase, which manifests as hovering or additional, mini “pseudo hops” before the final touchdown. A trajectory inflection is characterized by arresting the majority of the spacecraft vertical velocity component at a coordinate outside of the landing target, and without violating ground clearance constraints. FUTURE WORK: Our optimization technique is ready for laboratory or field demonstrations to validate the sophisticated maneuvering solutions obtained for fuel optimization and surface preservation. An appropriate testbed would validate the optimal guidance algorithms, the navigation system, and sensor suite by emulating vehicle flight in closed loop robotic tests. Critically, these algorithms could then be ported to flight software for implementation.

surface contamination↗

Jitter Controller Software

Sinusoidal jitter is produced by simply modulating a clock frequency sinusoidally with a given frequency and amplitude. But this can be expressed as phase jitter, frequency jitter, or cycle-to-cycle jitter, rms or peak, absolute units, or normalized to the base clock frequency. Jitter using other waveforms requires calculating and downloading these waveforms to an arbitrary waveform generator, and helping the user manage relationships among phase jitter crest factor, frequency jitter crest factor, and cycle-to-cycle jitter (CCJ) crest factor. Software was developed for managing these relationships, automatically configuring the generator, and saving test results documentation. Tighter management of clock jitter and jitter sensitivity is required by new codes that further extend the already high performance of space communication links, completely correcting symbol error rates higher than 10 percent, and therefore typically requiring demodulation and symbol synchronization hardware to operating at signal-to-noise ratios of less than one. To accomplish this, greater demands are also made on transmitter performance, and measurement techniques are needed to confirm performance. It was discovered early that sinusoidal jitter can be stepped on a grid such that one can connect points by constant phase jitter, constant frequency jitter, or constant cycle-cycle jitter. The tool automates adherence to a grid while also allowing adjustments off-grid. Also, the jitter can be set by the user on any dimension and the others are calculated. The calculations are all recorded, allowing the data to be rapidly plotted or re-plotted against different interpretations just by changing pointers to columns. A key advantage is taking data on a carefully controlled grid, which allowed a single data set to be post-analyzed many different ways. Another innovation was building a software tool to provide very tight coupling between the generator and the recorded data product, and the operator's worksheet. Together, these allowed the operator to sweep the jitter stimulus quickly along any of three dimensions and focus on the response of the system under test (response was jitter transfer ratio, or performance degradation to the symbol or codeword error rate). Additionally, managing multi-tone and noise waveforms automated a tedious manual process, and provided almost instantaneous decision- making control over test flow. The code was written in LabVIEW, and calls Agilent instrument drivers to write to the generator hardware.

Lansdowne, Chatwin↗

Experiences with Testing the Largest Ground System NASA Has Ever Built

In the 1980s, the National Aeronautics and Space Administration (NASA) embarked upon a major Earth-focused program called Mission to Planet Earth. The Goddard Space Flight Center (GSFC) was selected to manage and develop a key component - the Earth Observing System (EOS). The EOS consisted of four major missions designed to monitor the Earth. The missions included 4 spacecraft. Terra (launched December 1999), Aqua (launched May 2002), ICESat (Ice, Cloud, and Land Elevation Satellite, launched January 2003), and Aura (scheduled for launch January 2004). The purpose of these missions was to provide support for NASA s long-term research effort for determining how human-induced and natural changes affect our global environment. The EOS Data and Information System (EOSDIS), a globally distributed, large-scale scientific system, was built to support EOS. Its primary function is to capture, collect, process, and distribute the most voluminous set of remotely sensed scientific data to date estimated to be 350 Gbytes per day. The EOSDIS is composed of a diverse set of elements with functional capabilities that require the implementation of a complex set of computers, high-speed networks, mission-unique equipment, and associated Information Technology (IT) software along with mission-specific software. All missions are constrained by schedule, budget, and staffing resources, and rigorous testing has been shown to be critical to the success of each mission. This paper addresses the challenges associated with the planning, test definition. resource scheduling, execution, and discrepancy reporting involved in the mission readiness testing of a ground system on the scale of EOSDIS. The size and complexity of the mission systems supporting the Aqua flight operations, for example, combined with the limited resources available, prompted the project to challenge the prevailing testing culture. The resulting success of the Aqua Mission Readiness Testing (MRT) program was due in no small measure to re-structuring the traditional programmatic and technical approach to a more efficient and robust program. Programmatically, it meant gaining the endorsement, commitment, and cooperation of the numerous subsystem element managers and other stakeholder organizations. Technically, it required an MRT program that was agile, could rapidly adapt to requirements changes, and was flexible in its overall approach. Furthermore, this paper addresses the following questions: 1. What are the key ingredients (e.g., test tools, organization) needed to conduct a successful MRT program? 2. What distinguishes EOS MRT from the traditional system testing approach? 3. Where should the focus of testing be since it is infeasible to test every element or subsystem? 4. How can MRT be applied effectively to other systems or missions? To provide answers to these questions, this paper relies heavily on real-life, hands-on experiences ("lessons learned") gained during mission readiness testing of the Terra ground system and, most recently, the Aqua and ICESat missions. Moreover, this paper explores how lessons learned were turned into lessons applied for the upcoming Aura mission. Although derived from the EOS missions, MRT techniques and strategies can be applied to enhance the testing of other missions.

Lehtonen, Ken↗

Science Archives in the 21st Century: A NASA LAMBDA Report

Lambda is a thematic data center that focuses on serving the cosmic microwave background (CMB) research community. LAMBDA is an active archive for NASA's Cosmic Background Explorer (COBE) and Wilkinson Microwave Anisotropy Probe (WMAP) mission data sets. In addition, LAMBDA provides analysis software, on-line tools, relevant ancillary data and important web links. LAMBDA also tries to preserve the most important ground-based and suborbital CMB data sets. CMB data is unlike other astrophysical data, consisting of intrinsically diffuse surface brightness photometry with a signal contrast of the order 1 part in 100,000 relative to the uniform background. Because of the extremely faint signal levels, the signal-to-noise ratio is relatively low and detailed instrument-specific knowledge of the data is essential. While the number of data sets being produced is not especially large, those data sets are becoming large and complex. That tendency will increase when the many polarization experiments currently being deployed begin producing data. The LAMBDA experience supports many aspects of the NASA data archive model developed informally over the last ten years-that small focused data centers are often more effective than larger more ambitious collections, for example; that data centers are usually best run by active scientists; that it can be particularly advantageous if those scientists are leaders in the use of the archived data sets; etc. LAMBDA has done some things so well that they might provide lessons for other archives. A lot of effort has been devoted to developing a simple and consistent interface to data sets, for example; and serving all the documentation required via simple 'more' pages and longer explanatory supplements. Many of the problems faced by LAMBDA will also not surprise anyone trying to manage other space science data. These range from persuading mission scientists to provide their data as quickly as possible, to dealing with a high volume of nuisance (spam) messages. Because so many data center problems and solutions are common across individual data centers and disciplines it would be very valuable to establish some new systems of communication - such as informal email lists for administrators and developers. But resources are very limited, so new timeconsuming and inefficient mechanisms - like too-frequent and too-structured meetingsshould be avoided. Although there are great advantages to being small, agile and independent, there are also some areas where science data centers within and without NASA could be better coordinated - for the assignment of persistent identifiers; to encourage the early adoption of useful standards and technologies; etc. Some super-structure to facilitate such coordination might be beneficial as long as it doesn't begin to control the other work of the archives, and become a "methodology police". In this respect the CCSDS "Reference Model for an Open Archive Information System" is a little worrying. It may be that the closer a data center gets to following such a detailed prescription, the less effective it will become. It is much better to have an informal coordination process than a bureaucratic straight-jacket.

Butterworth, P.↗