Search NASA⌕ Search

SEARCH · Search NASA

Results for “Spacecraft Communications, Command and Tracking”

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
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

Automated and Adaptive Mission Planning for Orbital Express

The Orbital Express space mission was a Defense Advanced Research Projects Agency (DARPA) lead demonstration of on-orbit satellite servicing scenarios, autonomous rendezvous, fluid transfers of hydrazine propellant, and robotic arm transfers of Orbital Replacement Unit (ORU) components. Boeing's Autonomous Space Transport Robotic Operations (ASTRO) vehicle provided the servicing to the Ball Aerospace's Next Generation Serviceable Satellite (NextSat) client. For communication opportunities, operations used the high-bandwidth ground-based Air Force Satellite Control Network (AFSCN) along with the relatively low-bandwidth GEO-Synchronous space-borne Tracking and Data Relay Satellite System (TDRSS) network. Mission operations were conducted out of the RDT&E Support Complex (RSC) at the Kirtland Air Force Base in New Mexico. All mission objectives were met successfully: The first of several autonomous rendezvous was demonstrated on May 5, 2007; autonomous free-flyer capture was demonstrated on June 22, 2007; the fluid and ORU transfers throughout the mission were successful. Planning operations for the mission were conducted by a team of personnel including Flight Directors, who were responsible for verifying the steps and contacts within the procedures, the Rendezvous Planners who would compute the locations and visibilities of the spacecraft, the Scenario Resource Planners (SRPs), who were concerned with assignment of communications windows, monitoring of resources, and sending commands to the ASTRO spacecraft, and the Mission planners who would interface with the real-time operations environment, process planning products and coordinate activities with the SRP. The SRP position was staffed by JPL personnel who used the Automated Scheduling and Planning ENvironment (ASPEN) to model and enforce mission and satellite constraints. The lifecycle of a plan began three weeks outside its execution on-board. During the planning timeframe, many aspects could change the plan, causing the need for re-planning. These variable factors, ranging from shifting contact times to ground-station closures and required maintenance times, are discussed along with the flexibility of the ASPEN tool to accommodate changes to procedures and the daily or long-range plan, which contributed to the success of the mission. This paper will present an introduction to ASPEN, a more in-depth discussion on its use on the Orbital Express mission, and other relative work. A description of ground operations after the SRP deliveries were made is included, and we briefly discuss lessons learned from the planning perspective and future work.

scheduling↗
NASA NTRS2014

Studying NASA's Transition to Ka-Band Communications for Low Earth Orbit

As the S-band spectrum becomes crowded, future space missions will need to consider moving command and telemetry services to Ka-band. NASAs Space Communications and Navigation (SCaN) Testbed provides a software-defined radio (SDR) platform that is capable of supporting investigation of this service transition. The testbed contains two S-band SDRs and one Ka-band SDR. Over the past year, SCaN Testbed has demonstrated Ka-band communications capabilities with NASAs Tracking and Data Relay Satellite System (TDRSS) using both open- and closed-loop antenna tracking profiles. A number of technical areas need to be addressed for successful transition to Ka-band. The smaller antenna beamwidth at Ka-band increases the criticality of antenna pointing, necessitating closed loop tracking algorithms and new techniques for received power estimation. Additionally, the antenna pointing routines require enhanced knowledge of spacecraft position and attitude for initial acquisition, versus an S-band antenna. Ka-band provides a number of technical advantages for bulk data transfer. Unlike at S-band, a larger bandwidth may be available for space missions, allowing increased data rates. The potential for high rate data transfer can also be extended for direct-to-ground links through use of variable or adaptive coding and modulation. Specific examples of Ka-band research from SCaN Testbeds first year of operation will be cited, such as communications link performance with TDRSS, and the effects of truss flexure on antenna pointing.

International Space Station↗
NASA NTRS2014

Studying NASA's Transition to Ka-Band Communications for Low Earth Orbit

As the S-band spectrum becomes crowded, future space missions will need to consider moving command and telemetry services to Ka-band. NASA's Space Communications and Navigation (SCaN) Testbed provides a software-defined radio (SDR) platform that is capable of supporting investigation of this service transition. The testbed contains two S-band SDRs and one Ka-band SDR. Over the past year, SCaN Testbed has demonstrated Ka-band communications capabilities with NASAs Tracking and Data Relay Satellite System (TDRSS) using both open- and closed-loop antenna tracking profiles. A number of technical areas need to be addressed for successful transition to Ka-band. The smaller antenna beamwidth at Ka-band increases the criticality of antenna pointing, necessitating closed loop tracking algorithms and new techniques for received power estimation. Additionally, the antenna pointing routines require enhanced knowledge of spacecraft position and attitude for initial acquisition, versus an S-band antenna. Ka-band provides a number of technical advantages for bulk data transfer. Unlike at S-band, a larger bandwidth may be available for space missions, allowing increased data rates. The potential for high rate data transfer can also be extended for direct-to-ground links through use of variable or adaptive coding and modulation. Specific examples of Ka-band research from SCaN Testbeds first year of operation will be cited, such as communications link performance with TDRSS, and the effects of truss flexure on antenna pointing.

space communications↗
NASA NTRS1999

Low Earth Orbiter: Terminal

In response to the current government budgetary environment that requires the National Aeronautics and Space Administration (NASA) to do more with less, NASA/Goddard Space Flight Center's Wallops Flight Facility has developed and implemented a class of ground stations known as a Low Earth Orbiter-Terminal (LEO-T). This development thus provides a low-cost autonomous ground tracking service for NASA's customers. More importantly, this accomplishment provides a commercial source to spacecraft customers around the world to purchase directly from the company awarded the NASA contract to build these systems. A few years ago, NASA was driven to provide more ground station capacity for spacecraft telemetry, tracking, and command (TT&C) services with a decreasing budget. NASA also made a decision to develop many smaller, cheaper satellites rather than a few large spacecraft as done in the past. In addition, university class missions were being driven to provide their own TT&C services due to the increasing load on the NASA ground-tracking network. NASA's solution for this ever increasing load was to use the existing large aperture systems to support those missions requiring that level of performance and to support the remainder of the missions with the autonomous LEO-T systems. The LEO-T antenna system is a smaller, cheaper, and fully autonomous unstaffed system that can operate without the existing NASA support infrastructure. The LEO-T provides a low-cost, reliable space communications service to the expanding number of low-earth orbiting missions around the world. The system is also fostering developments that improve cost-effectiveness of autonomous-class capabilities for NASA and commercial space use. NASA has installed three LEO-T systems. One station is at the University of Puerto Rico, the second system is installed at the Poker Flat Research Range near Fairbanks, Alaska, and the third system is installed at NASA's Wallops Flight Facility in Virginia. This paper will describe the current NASA implementation of the LEO-T network of antenna systems, the customers now being supported, and the services NASA can now offer with this new breed of autonomous ground stations. In addition, the paper will define the technical capabilities of the system and the cost effectiveness of using the systems including the capital costs of installation.

Kremer, Steven E.↗
NASA NTRS2018

Ground System Development at the Morehead State University for Interplanetary Smallsat Missions

As more small satellites are used for interplanetary research and exploration, more ground antennas with sufficiently large aperture are needed to support the increased demand in deep space communication. The 21-m ground antenna at the Morehead State University in Kentucky, United States is under development to upgrade its telemetry, tracking and command capability at X-band. The system architecture is based on a hybrid design that combines commercially available products with specialized equipment developed for the National Aeronautic and Aerospace Administration’s Deep Space Network. This architecture produces a low-cost and geographically diverse system, connecting elements at the Morehead State University and those of the DSN at the Jet Propulsion Laboratory in Pasadena, California. The architecture makes Morehead antenna appears as one of the DSN nodes, albeit with a different performance metrics due to difference in aperture size. Its operation is geared for automation, with automated data retrieval of information needed for configuring the ground station for spacecraft tracking. An incremental testing approach is used to verify system capabilities as various components are deployed into the system.

Kruth, Jeff↗
NASA NTRS2004

Readout of DSN Monitor Data

DSN Monitor Data Reader is a computer program that, as its name suggests, reads file of monitor data from the Deep Space Network (DSN). The monitor data constitute information on the status and performance of tracking, telemetry, command, and pointing equipment at the DSN antennas. The DSN has recently introduced a new, more advanced monitor data format, denoted 0158-Mon, that is based on the standard formatted data unit (SFDU) and compressed header data objects (CHDO) of the Consultative Committee for Space Data Systems (CCSDS). The 0158-Mon data format is a very flexible generic format that provides for specific variable-length formats and for self-identifying parameters that obviate the proprietary NASA Communications (NASCOM) bit-packed formats of the past. The monitor data SFDUs are also encapsulated in Standard DSN Blocks and routed to DSN customers for processing at their local mission control centers. This program helps a DSN customer to read and parse the monitor data to assess the statuses of the DSN stations in support of spacecraft flight operations.

Levister, Katherine↗
NASA NTRS1993

EOS ground data systems: A description and interface overview

The Earth Observing System (EOS) is planned as a space-based measurement system, earth-science research program, and data and information system (EOSDIS). It will consist of several high data rate spacecraft with multiple earth sensing instruments which provide investigators with a thorough, longterm view of the earth's environment. Up to seven spacecraft may be supported at once, either in operational, checkout, or testing phases; and the average data rate from the EOS satellites in orbit at any one time is expected to be from 18 to 60 Mbps. Providing the data processing and flight operations support for EOS will be the EOSDIS Core System (ECS). The ECS will command and control the spacecraft; process and store the EOS data; provide access to the data for years; and support researchers. The data processing aspects of the ECS consist of a collection of Distributed Active Archive Centers (DAAC's) which perform the product generation, data archive and distribution, and information management services. Flight operations aspects will be provided by the EOS Operations Center, by instrument control centers, and by widely distributed instrument support terminals. The communications and system management aspects will be provided by the EOSDIS Science Network and the System Management Center. In addition to the EOS satellite data, other data sets from earlier earth science missions are also to be added to designated DAAC's. Other ground data systems which will provide support to EOS for acquiring, transporting, processing, and distributing the transformed spacecraft data are currently being defined or are being upgraded for the EOS era. These systems include the Space Network consisting of the Tracking and Data Relay Satellite System (TDRSS), the TDRSS Ground Terminals, and the Network Control Center as well as the night Dynamics Facility, the EOS Data and Operations System, and EOS Communications. This paper briefly describes data handling by the ECS, the support data systems, their interfaces, and their roles.

Smith, Gene↗
NASA NTRS2016

Human Flight to Lunar and Beyond - Re-Learning Operations Paradigms

For the first time since the Apollo era, NASA is planning on sending astronauts on flights beyond LEO. The Human Space Flight (HSF) program started with a successful initial flight in Earth orbit, in December 2014. The program will continue with two Exploration Missions (EM): EM-1 will be unmanned and EM-2, carrying astronauts, will follow. NASA established a multi-center team to address the communications, and related tacking/navigation needs. This paper will focus on the lessons learned by the team designing the architecture and operations for the missions. Many of these Beyond Earth Orbit lessons had to be re-learned, as the HSF program has operated for many years in Earth orbit. Unlike the Apollo missions that were largely tracked by a dedicated ground network, the HSF planned missions will be tracked (at distances beyond GEO) by the DSN, a network that mostly serves robotic missions. There have been surprising challenges to the DSN as unique modern human spaceflight needs stretch the experience base beyond that of tracking robotic missions in deep space. Close interaction between the DSN and the HSF community to understand the unique needs (e.g. 2-way voice) resulted in a Concept of Operations (ConOps) that leverages both the deep space robotic and the Human LEO experiences. Several examples will be used to highlight the unique challenges the team faced in establishing the communications and tracking capabilities for HSF missions beyond Earth Orbit, including: Navigation. At LEO, HSF missions can rely on GPS devices for orbit determination. For Lunar-and-beyond HSF missions, techniques such as precision 2-way and 3-way Doppler and ranging, Delta-Difference-of-range, and eventually possibly on-board navigation will be used. At the same time, HSF presents a challenge to navigators, beyond those presented by robotic missions - navigating a dynamic/"noisy" spacecraft. Impact of latency - the delay associated with Round-Trip-Light-Time (RTLT). Imagine trying to have a 2-way discussion (audio or video) with an astronaut, with a 2-3 sec or more delay inserted (for lunar distances) or 20 minutes delay (for Mars distances). Balanced communications link. For robotic missions, there has been a heavy emphasis on higher downlink data rates, e.g. bringing back science data. Higher uplink data rates were of secondary importance, as uplink was used only to send commands (and occasionally small files) to the spacecraft. The ratio of downlink-to-uplink data rates was often 10:1 or more. For HSF, a continuous forward link is established and rates for uplink and downlink are more similar.

Kenny, Edward (Ted)↗
NASA NTRS1999

Autonomous Navigation Using Celestial Objects

In the twenty-first century, National Aeronautics and Space Administration (NASA) Enterprises envision frequent low-cost missions to explore the solar system, observe the universe, and study our planet. Satellite autonomy is a key technology required to reduce satellite operating costs. The Guidance, Navigation, and Control Center (GNCC) at the Goddard Space Flight Center (GSFC) currently sponsors several initiatives associated with the development of advanced spacecraft systems to provide autonomous navigation and control. Autonomous navigation has the potential both to increase spacecraft navigation system performance and to reduce total mission cost. By eliminating the need for routine ground-based orbit determination and special tracking services, autonomous navigation can streamline spacecraft ground systems. Autonomous navigation products can be included in the science telemetry and forwarded directly to the scientific investigators. In addition, autonomous navigation products are available onboard to enable other autonomous capabilities, such as attitude control, maneuver planning and orbit control, and communications signal acquisition. Autonomous navigation is required to support advanced mission concepts such as satellite formation flying. GNCC has successfully developed high-accuracy autonomous navigation systems for near-Earth spacecraft using NASA's space and ground communications systems and the Global Positioning System (GPS). Recently, GNCC has expanded its autonomous navigation initiative to include satellite orbits that are beyond the regime in which use of GPS is possible. Currently, GNCC is assessing the feasibility of using standard spacecraft attitude sensors and communication components to provide autonomous navigation for missions including: libration point, gravity assist, high-Earth, and interplanetary orbits. The concept being evaluated uses a combination of star, Sun, and Earth sensor measurements along with forward-link Doppler measurements from the command link carrier to autonomously estimate the spacecraft's orbit and reference oscillator's frequency. To support autonomous attitude determination and control and maneuver planning and control, the orbit determination accuracy should be on the order of kilometers in position and centimeters per second in velocity. A less accurate solution (one hundred kilometers in position) could be used for acquisition purposes for command and science downloads. This paper provides performance results for both libration point orbiting and high Earth orbiting satellites as a function of sensor measurement accuracy, measurement types, measurement frequency, initial state errors, and dynamic modeling errors.

Folta, David↗
NASA NTRS2009

Ka-Band High-Rate Telemetry System Upgrade for the NASA Deep Space Network

The NASA Deep Space Network (DSN) has a new requirement to support high-data-rate Category A (Cat A) missions (within 2 million kilometers of Earth) with simultaneous S-band uplink, S-band downlink and Ka-band downlink. The S-band links are required for traditional TT&C (Telemetry, Tracking, and Command) support to the spacecraft, while the Ka-band link is intended for high-data-rate science returns. The new Ka-band system combines the use of proven DSN cryogenic designs, for low system temperature, and high data rate capability using commercial telemetry receivers. The initial Cat A support is required for the James Webb Space Telescope (JWST) in 2013 and possibly other missions. The upgrade has been implemented into 3 different 34-meter Beam Waveguide (BWG) antennas in the DSN, one at each of the complexes in Canberra (Australia), Goldstone (California) and Madrid (Spain). System test data is presented to show that the requirements were met and the DSN is ready for Cat A Ka-band operational support.

space communications↗
NASA NTRS2016

Human Flight to Lunar and Beyond - Re-Learning Operations Paradigms

For the first time since the Apollo era, NASA is planning on sending astronauts on flights beyond Low-Earth Orbit (LEO). The Human Space Flight (HSF) program started with a successful initial flight in Earth orbit, in December 2014. The program will continue with two Exploration Missions (EM) to Lunar orbit: EM-1 will be unmanned and EM-2, carrying astronauts, will follow. NASA established a multi-center team to address the communications, and related navigation, needs. This paper will focus on the lessons learned in the team, planning for the missions' parts that are beyond Earth orbit. Many of these lessons had to be re-learned, as the HSF program after operated for many years in Earth orbit. Fortunately, the experience base from tracking robotic missions in deep space by the Deep Space Network (DSN) and close interaction with the HSF community to understand the unique needs (e.g. 2-way voice) resulted in a ConOps that leverages of both the deep space robotic and the Human LEO experiences. Several examples will be used to highlight the unique operational needs for HSF missions beyond Earth Orbit, including: - Navigation. At LEO, HSF missions can rely on Global Positioning System (GPS) devices for orbit determination. For Lunar-and-beyond HSF missions, techniques such as precision 2-way and 3-way Doppler and ranging, Delta-Difference-of-range, and eventually on-board navigation will be used. - Impact of latency - the delay associated with Round-Trip-Light-Time (RTLT). Imagine trying to have a 2-way discussion (audio or video) with an astronaut, with a 2-3 sec delay inserted (for Lunar distances) or 20 minutes delay (for Mars distances). - Balanced communications link. For robotic missions, there has been a heavy emphasis on the downlink data rates, bringing back science data from the instruments on-board the spacecraft. Uplink data rates were of secondary importance, used to send commands to the spacecraft. The ratio of downlink-to-uplink data rates was often 10:1 or more. For HSF, rates for uplink and downlink, at least for high-quality video, need to be similar.

Kenny, Ted↗
NASA NTRS2012

Communicating by Doppler: Detecting Spacecraft Dynamics During Critical Maneuvers

Communicating information from spacecraft in deep space utilizes sophisticated techniques of modulations onto a microwave signal carrier. Under most conditions, there is a high success rate of sending commands to the spacecraft and receiving science data acquired by on-board instruments along with health and status information. There are conditions, however, where the signal dynamics are too high and/or the received signal-to-noise ratio is below the receiver threshold. Under these conditions, often by design and sometimes as a result of planned or unplanned critical maneuvers, events (e.g., orbit insertion or descent and landing), safe mode, etc., it becomes highly critical but exceedingly challenging to receive information about the health and dynamical behavior of the spacecraft. The Deep Space Network, being a world-class instrument for Radio Science research, developed openloop receivers, called the Radio Science Receiver, designed to capture the raw incoming electromagnetic signals and associated noise for Radio Science experiments; post data capture digital signal processing extracts the signal carrier for scientific analysis. This receiver provides a high level of configuration flexibility and can be optimized for the various types of experiments. In addition to its scientific utility, it proved to be useful, and in some cases critical, for the support of missions during specific scenarios were the link budget is below the threshold of the tracking receiver to maintain lock or the frequency dynamics are faster than the limits of the tracking receiver. In these cases, the signal carrier is often detected only in the open-loop receiver to provide information on the specific behavior of the spacecraft from the carrier dynamics. This paper describes the utility of the system to support mission-critical events for the three cases of Cassini's Saturn orbit insertion, Huygens Titan landing, and Mars rovers landing.

radio science↗
NASA NTRS2017

Operating Small Sat Swarms as a Single Entity: Introducing SODA

Swarm concepts are a growing topic of interest in the small satellite community. Compared to a small satellite constellation, a swarm has the distinction of being multiple spacecraft in close proximity, in approximately the same orbit. Furthermore, we envision swarms to have capabilities for cross-link communication and station-keeping. Of particular interest is a means to maintain operator-specified geometry, alignment, and/or separation.From NASA's decadal survey, it is clear that simultaneous measurements from a 3D volume of space are desired for a variety of Earth scientific studies. As this mission concept is ultimately extended to deep space, some degree of local control for the swarm to self-correct its configuration is required. We claim that the practicality of ground commanding each individual satellite in the swarm is simply not a feasible concept of operations. In other words, the current state-of-practice does not scale to very large swarms (e.g. 100 spacecraft or more) without becoming cost prohibitive. To contain the operations costs and complexity, a new approach is required: the swarm must be operated as a unit, responding to high-level specifications for relative position and velocity.The Mission Design Division at NASA Ames Research Center is looking to the near future for opportunities to develop satellite swarm technology. As part of this effort, we are developing SODA (Swarm Orbital Dynamics Advisor), a tool that provides the orbital maneuvers required to achieve a desired type of relative swarm motion. The purpose of SODA is two-fold. First, it encompasses the algorithms and orbital dynamics model to enable the desired relative motion of the swarm satellites. The process starts with the user specifying the properties of a swarm configuration. This could be as simple as varying in-track spacing of the swarm in one orbit, or as complex as maintaining a specified 3D geometrical orientation. We presume that science objectives will drive this choice. Given these inputs, the tool provides the most efficient maneuver(s) to achieve the objective.Second, SODA provides a variety of visualization tools. We acknowledge that the relationship between a desired relative motion amongst the swarm, and the corresponding orbital parameters for each individual satellite may not be immediately apparent for ground controllers and mission planners. The purpose of SODA's visualization tools is to illustrate this concept clearly with a variety of graphics and animations. After computing the optimal orbital maneuvers to modify the swarm, these results are simulated to demonstrate successful swarm control.Our emphasis in this paper is on the importance of relating the desired motion of the swarm satellites relative to one another with the required orbital element changes. One cannot joystick a drifting swarm satellite back into position; the underlying orbital mechanics dictate the most efficient recovery maneuvers. To illustrate this point, results from several case study simulations are presented. We conclude with our forward work for ongoing SODA development and potential science applications.

small satellites↗
NASA NTRS2015

AMO EXPRESS: A Command and Control Experiment for Crew Autonomy

NASA is investigating a range of future human spaceflight missions, including both Mars-distance and Near Earth Object (NEO) targets. Of significant importance for these missions is the balance between crew autonomy and vehicle automation. As distance from Earth results in increasing communication delays, future crews need both the capability and authority to independently make decisions. However, small crews cannot take on all functions performed by ground today, and so vehicles must be more automated to reduce the crew workload for such missions. NASA's Advanced Exploration Systems Program funded Autonomous Mission Operations (AMO) project conducted an autonomous command and control demonstration of intelligent procedures to automatically initialize a rack onboard the International Space Station (ISS) with power and thermal interfaces, and involving core and payload command and telemetry processing, without support from ground controllers. This autonomous operations capability is enabling in scenarios such as a crew medical emergency, and representative of other spacecraft autonomy challenges. The experiment was conducted using the Expedite the Processing of Experiments for Space Station (EXPRESS) rack 7, which was located in the Port 2 location within the U.S Laboratory onboard the International Space Station (ISS). Activation and deactivation of this facility is time consuming and operationally intensive, requiring coordination of three flight control positions, 47 nominal steps, 57 commands, 276 telemetry checks, and coordination of multiple ISS systems (both core and payload). The autonomous operations concept includes a reduction of the amount of data a crew operator is required to verify during activation or de-activation, as well as integration of procedure execution status and relevant data in a single integrated display. During execution, the auto-procedures provide a step-by-step messaging paradigm and a high level status upon termination. This messaging and high level status is the only data generated for operator display. To enhance situational awareness of the operator, the Web-based Procedure Display (WebPD) provides a novel approach to the issues of procedure display and execution tracking. For this demonstration, the procedure was initiated and monitored from the ground. As the Timeliner sequences executed, their high level execution status was transmitted to ground, for WebPD consumption.

Stetson, Howard K.↗
NASA NTRS2004

Transitioning to Intel-based Linux Servers in the Payload Operations Integration Center

The MSFC Payload Operations Integration Center (POIC) is the focal point for International Space Station (ISS) payload operations. The POIC contains the facilities, hardware, software and communication interface necessary to support payload operations. ISS ground system support for processing and display of real-time spacecraft and telemetry and command data has been operational for several years. The hardware components were reaching end of life and vendor costs were increasing while ISS budgets were becoming severely constrained. Therefore it has been necessary to migrate the Unix portions of our ground systems to commodity priced Intel-based Linux servers. hardware architecture including networks, data storage, and highly available resources. This paper will concentrate on the Linux migration implementation for the software portion of our ground system. The migration began with 3.5 million lines of code running on Unix platforms with separate servers for telemetry, command, Payload information management systems, web, system control, remote server interface and databases. The Intel-based system is scheduled to be available for initial operational use by August 2004 The overall migration to Intel-based Linux servers in the control center involves changes to the This paper will address the Linux migration study approach including the proof of concept, criticality of customer buy-in and importance of beginning with POSlX compliant code. It will focus on the development approach explaining the software lifecycle. Other aspects of development will be covered including phased implementation, interim milestones and metrics measurements and reporting mechanisms. This paper will also address the testing approach covering all levels of testing including development, development integration, IV&V, user beta testing and acceptance testing. Test results including performance numbers compared with Unix servers will be included. need for a smooth transition while maintaining real-time support. An important aspect of the paper will involve challenges and lessons learned. product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support. This paper will also address the deployment approach including user involvement in testing and the , This includes COTS product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support.

Guillebeau, P. L.↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2018

Utilizing Testing Frameworks for Launch Control Systems Continuous Integration

Command and control software is an integral part of the launch procedure. The most important part of this type of software is its ability to communicate well with the user and relay information in a correctly formatted way such that the user can understand the data. There is a tool that aides the communication between the different parts of the system, and effectively, the user. This instrument is capable of taking several complex values and ensuring that they are correctly sorted into their distinctive message values and distributed properly among the different facets of the system. This tool will easily translate and publish the data inside of messages in the system to something that is readable and understandable. The tool also allows for transmission of the recorded data to the user, effectively ensuring the communication between different components of the system. As well as keeping track of messages and ensuring that the information contained within each of them reaches the correct location, this tool has the ability to keep track of its own statistics and determine how many messages passed in were erroneous and how many were successfully transmitted. It is able to check and see what the total message failure count is when an invalid message is given, as well as the number of different messages and their respective types passed into the tool. This tool is of great value to the new Space Launch System (SLS). As such, the tool must be thoroughly tested with test cases that, although improbable, are possible, where the tool may not function properly. Testing an interface this complex is necessary to ensure mission safety and create unlikely scenarios where the tool would work as intended, and stretch its limits to test that even under the most uncommon conditions it would still continue to function. This software will be an important part of the control system for the newest spacecraft which will fly deeper into space than humans have ever travelled. It will fly beyond the moon, into deep space to Mars and perhaps set the groundwork for a manned mission even further to create more opportunities for interplanetary and even interstellar travel by humans. This mission relies heavily on software and hardware to ensure the safety of the humans that will be on board and therefore must be checked, exhausting each and every different situation, such that there is not a doubt surrounding the well-being of the humans aboard the rocket. That is why testing is such an important part of the mission. It provides evidence that the systems aboard the rocket and on the launch pad are safe.

Unit Testing↗
NASA NTRS2009

Protocol for Communication Networking for Formation Flying

An application-layer protocol and a network architecture have been proposed for data communications among multiple autonomous spacecraft that are required to fly in a precise formation in order to perform scientific observations. The protocol could also be applied to other autonomous vehicles operating in formation, including robotic aircraft, robotic land vehicles, and robotic underwater vehicles. A group of spacecraft or other vehicles to which the protocol applies could be characterized as a precision-formation- flying (PFF) network, and each vehicle could be characterized as a node in the PFF network. In order to support precise formation flying, it would be necessary to establish a corresponding communication network, through which the vehicles could exchange position and orientation data and formation-control commands. The communication network must enable communication during early phases of a mission, when little positional knowledge is available. Particularly during early mission phases, the distances among vehicles may be so large that communication could be achieved only by relaying across multiple links. The large distances and need for omnidirectional coverage would limit communication links to operation at low bandwidth during these mission phases. Once the vehicles were in formation and distances were shorter, the communication network would be required to provide high-bandwidth, low-jitter service to support tight formation-control loops. The proposed protocol and architecture, intended to satisfy the aforementioned and other requirements, are based on a standard layered-reference-model concept. The proposed application protocol would be used in conjunction with conventional network, data-link, and physical-layer protocols. The proposed protocol includes the ubiquitous Institute of Electrical and Electronics Engineers (IEEE) 802.11 medium access control (MAC) protocol to be used in the datalink layer. In addition to its widespread and proven use in diverse local-area networks, this protocol offers both (1) a random- access mode needed for the early PFF deployment phase and (2) a time-bounded-services mode needed during PFF-maintenance operations. Switching between these two modes could be controlled by upper-layer entities using standard link-management mechanisms. Because the early deployment phase of a PFF mission can be expected to involve multihop relaying to achieve network connectivity (see figure), the proposed protocol includes the open shortest path first (OSPF) network protocol that is commonly used in the Internet. Each spacecraft in a PFF network would be in one of seven distinct states as the mission evolved from initial deployment, through coarse formation, and into precise formation. Reconfiguration of the formation to perform different scientific observations would also cause state changes among the network nodes. The application protocol provides for recognition and tracking of the seven states for each node and for protocol changes under specified conditions to adapt the network and satisfy communication requirements associated with the current PFF mission phase. Except during early deployment, when peer-to-peer random access discovery methods would be used, the application protocol provides for operation in a centralized manner.

Jennings, Esther↗