SEQ _Pointer: Next Generations, Planetary Spacecraft Remote Sensing Observation Design Tool
Explore the source record for details and available documents.
Mariner Missions ground software SEQ_POINTER space↗
SEARCH · Engineering Papers
Results for “mission 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.
Software reconfigurable processor technologies: the key to long-life infrastructure for future space missions
They present an overview of long-life reconfigurable processor technologies and of a specific architecture for implementing a software reconfigurable (software-defined) network processor for space applications.
reconfigurable network processors↗
PyPele Rewritten To Use MPI
A computer program known as PyPele, originally written as a Pythonlanguage extension module of a C++ language program, has been rewritten in pure Python language. The original version of PyPele dispatches and coordinates parallel-processing tasks on cluster computers and provides a conceptual framework for spacecraft-mission- design and -analysis software tools to run in an embarrassingly parallel mode. The original version of PyPele uses SSH (Secure Shell a set of standards and an associated network protocol for establishing a secure channel between a local and a remote computer) to coordinate parallel processing. Instead of SSH, the present Python version of PyPele uses Message Passing Interface (MPI) [an unofficial de-facto standard language-independent application programming interface for message- passing on a parallel computer] while keeping the same user interface. The use of MPI instead of SSH and the preservation of the original PyPele user interface make it possible for parallel application programs written previously for the original version of PyPele to run on MPI-based cluster computers. As a result, engineers using the previously written application programs can take advantage of embarrassing parallelism without need to rewrite those programs.
Hockney, George↗
Field Tested Service Oriented Robotic Architecture: Case Study
This paper presents the lessons learned from six years of experiments with planetary rover prototypes running the Service Oriented Robotic Architecture (SORA) developed by the Intelligent Robotics Group (IRG) at NASA Ames Research Center. SORA relies on proven software methods and technologies applied to the robotic world. Based on a Service Oriented Architecture and robust middleware, SORA extends its reach beyond the on-board robot controller and supports the full suite of software tools used during mission scenarios from ground control to remote robotic sites. SORA has been field tested in numerous scenarios of robotic lunar and planetary exploration. The results of these high fidelity experiments are illustrated through concrete examples that have shown the benefits of using SORA as well as its limitations.
Flueckiger, Lorenzo↗
Guidance, Navigation, and Control Technology Assessment for Future Planetary Science Missions
Future planetary explorations envisioned by the National Research Council's (NRC's) report titled Vision and Voyages for Planetary Science in the Decade 2013-2022, developed for NASA Science Mission Directorate (SMD) Planetary Science Division (PSD), seek to reach targets of broad scientific interest across the solar system. This goal requires new capabilities such as innovative interplanetary trajectories, precision landing, operation in close proximity to targets, precision pointing, multiple collaborating spacecraft, multiple target tours, and advanced robotic surface exploration. Advancements in Guidance, Navigation, and Control (GN&C) and Mission Design in the areas of software, algorithm development and sensors will be necessary to accomplish these future missions. This paper summarizes the key GN&C and mission design capabilities and technologies needed for future missions pursuing SMD PSD's scientific goals.
position↗
Overview of the Layered and Extensible Aircraft Performance System (LEAPS)
Explore the source record for details and available documents.
aircraft↗
Preliminary results of the autonomous sciencecraft experiment
The Autonomous Sciencecraft Experiment (ASE) will operate onboard the Earth Orbiter 1 mission 2004. The ASE software uses onboard continuous planning, robust task and goal-based execution, and onboard machine learning and patter recognition to radically increase science return by enabling intelligent downlink selection and autnomous retargeting. In this paper we will discuss how these AI technologies are synergistically integrated in multi-layer control architecture to enable a virtual spacecraft science agent.
Rabideau, Gregg↗
Iris Deep-Space Transponder for SLS EM-1 CubeSat Missions
Several key design upgrades have been recently made to the Iris Deep-Space Transponder baselined to be used on secondary payload missions of the upcoming Space Launch System Exploration Mission One (SLS EM-1). The Iris Transponder is a reconfigurable software-defined radio (SDR) designed for missions requiring interoperability with NASA's Deep Space Network (DSN) on X-band frequencies (7.2 GHz uplink, 8.4 GHz downlink). The transponder provides radiometric tracking support with the DSN to provide navigational products for precise orbit determination while performing standard uplink and downlink communications in a CubeSat/SmallSat-applicable package size. The recent hardware changes include a volume reduction of 30% from previous models, with the main transponder unit weighing less than 1.0 kg, while maintaining total ionizing dose (TID) radiation tolerance of >23 krads (Si) for deep-space missions. Lab tests indicate maximum downlink rates of up to 6.25 Msps can be supported by the transponder in conventional BPSK modulation, but most SLS EM-1 CubeSat missions are link-performance limited to less than 256 kbps. A prototype unit of the flight production units has been assembled and various performance and characterization tests are underway. This talk discusses the key design aspects and specifications of the Iris Transponder and presents preliminary results from early testing of the assembled transponder.
Kobayashi, M. Michael↗
Psyche Hardware Abstraction Simulation Environment (PHASE): Development of High-Fidelity Downlink Model for Flight Software Performance Testing
NASA’s Katherine Johnson Independent Verification and Validation (IV&V) Independent Test Capability (ITC) Team develops high fidelity software-only simulations (or “digital-twins”) of NASA’s most critical missions that are then used for software verification and validation (V&V). One such digital-twin simulator nearing maturity is the Psyche Hardware Abstraction Simulation Environment (PHASE). PHASE utilizes an instruction set simulator along with ITC-developed avionics models. PHASE includes a newly-developed model of the telecom hardware with a high-fidelity downlink interface, capable of supporting reconfigurable downlink data rates and transmission modes. The different downlink transmission modes allow more processing to be ceded from software onto the telecom hardware. Thus, we are able to monitor the performance of the downlink software module in the time-partitioned OS and perform more realistic dynamic testing based on software’s resource utilization. This presentation will cover PHASE, avionics modeling, the downlink model, and its usage for flight software performance testing.
modeling↗
Integration of an Arm Kinematics Hot Patch onboard the Curiosity Rover
NASA's Mars Science Laboratory (MSL) mission has updated the Curiosity rover's flight software multiple times since landing on Mars on August 6, 2012. The most common patching method has been a hot patch, in which running flight software is modified after being copied into RAM from its persistent storage. The latest hot patch to be installed on Curiosity fixed an issue in the robotic arm software that computes generalized inverse kinematics. Additional unit testing performed since the start of the surface mission revealed that this software can sometimes produce erroneous solutions.The cause was identified as numerical instability in a quartic root finder. When the inputs to that solver are not well conditioned, floating-point numerical issuescan cause erroneous roots to be reported. In theory, this could result in the robotic arm turret instruments being commanded to unintended positions, for example, below the terrain surface. Out of approximately 3.7 million unit test cases, 97.2\% of the position errors were below 5 mm. However, there were 16 test cases where theposition error was greater than 20 cm, and the maximum position error was 1.2 meters.The patch was uploaded to Curiosity on sol 2642 (January 11, 2020) after the solution was developed, re-implemented as a hot patch, and validated and verified using Earth-based Curiosity testbeds. A checkout test of the patch was performed on Curiosity on sol 2657, and nominal use of the patch began on sol 2658. In this paper, we describe the steps that led to integrating the arm kinematic hot patch into Curiosity's flight software, from the discovery of the bug to the nominal use of the patch in flight.
Maimone, Mark↗
The Implementation of Satellite Control System Software Using Object Oriented Design
NASA established the Small Explorer (SMEX) program in 1988 to provide frequent opportunities for highly focused and relatively inexpensive space science missions that can be launched into low earth orbit by small expendable vehicles. The development schedule for each SMEX spacecraft was three years from start to launch. The SMEX program has produced five satellites; Solar Anomalous and Magnetospheric Particle Explorer (SAMPEX), Fast Auroral Snapshot Explorer (FAST), Submillimeter Wave Astronomy Satellite (SWAS), Transition Region and Coronal Explorer (TRACE) and Wide-Field Infrared Explorer (WIRE). SAMPEX and FAST are on-orbit, TRACE is scheduled to be launched in April of 1998, WIRE is scheduled to be launched in September of 1998, and SWAS is scheduled to be launched in January of 1999. In each of these missions, the Attitude Control System (ACS) software was written using a modular procedural design. Current program goals require complete spacecraft development within 18 months. This requirement has increased pressure to write reusable flight software. Object-Oriented Design (OOD) offers the constructs for developing an application that only needs modification for mission unique requirements. This paper describes the OOD that was used to develop the SMEX-Lite ACS software. The SMEX-Lite ACS is three-axis controlled, momentum stabilized, and is capable of performing sub-arc-minute pointing. The paper first describes the high level requirements which governed the architecture of the SMEX-Lite ACS software. Next, the context in which the software resides is explained. The paper describes the benefits of encapsulation, inheritance and polymorphism with respect to the implementation of an ACS software system. This paper will discuss the design of several software components that comprise the ACS software. Specifically, Object-Oriented designs are presented for sensor data processing, attitude control, attitude determination and failure detection. The paper addresses the benefits of the OOD versus a conventional procedural design. The final discussion in this paper will address the establishment of the ACS Foundation Class (AFC) Library. The AFC is a large software repository, requiring a minimal amount of code modifications to produce ACS software for future projects, saving production time and costs.
Anderson, Mark O.↗
Evolving from Planning and Scheduling to Real-Time Operations Support: Design Challenges
Versions of Scheduling and Planning Interface for Exploration (SPIFe) have supported a variety of mission operations across NASA. This software tool has evolved and matured over several years, assisting planners who develop intricate schedules. While initially conceived for surface Mars missions, SPIFe has been deployed in other domains, where people rather than robotic explorers, execute plans. As a result, a diverse set of end-users has compelled growth in a new direction: supporting real-time operations. This paper describes the new needs and challenges that accompany this development. Among the key features that have been built for SPIFe are current time indicators integrated into the interface and timeline, as well as other plan attributes that enable execution of scheduled activities. Field tests include mission support for the Lunar CRater Observation and Sensing Satellite (LCROSS), NASA Extreme Environment Mission Operations (NEEMO) and Desert Research and Technology Studies (DRATS) campaigns.
Marquez, Jessica J.↗
The Challenges of Searching, Finding, Reading, Understanding and Using Mars Mission Datasets for Science Analysis
This viewgraph presentation reviews the problems that non-mission researchers have in accessing data to use in their analysis of Mars. The increasing complexity of Mars datasets results in custom software development by instrument teams that is often the only means to visualize and analyze the data. The solutions to the problem are to continue efforts toward synergizing data from multiple missions and making the data, s/w, derived products available in standardized, easily-accessible formats, encourage release of "lite" versions of mission-related software prior to end-of-mission, and planetary image data should be systematically processed in a coordinated way and made available in an easily accessed form. The recommendations of Mars Environmental GIS Workshop are reviewed.
data sets↗
Rapid Spacecraft Payload Development: In-Orbit Demonstration of Flight Software Reuse, Scalability, and Dependability
As space mission design trends towards shared, multi-mission platforms and high-performance onboard computing architectures, the number of spacecraft launched into operation is also steadily rising. Through ridesharing, spacecraft miniaturization, and other cost-reduction measures, the barriers to space are lowering, resulting in compounded growth in the amount of flight software being deployed. To meet the needs of both the growing quantity and evolving nature of spacecraft, flight software design must accordingly adapt to support more efficient development, solutions to computational resource-sharing, and software reusability. This paper focuses on a software payload demonstrating several core technologies that improve the state-of-the-art in these identified areas. Launched into low-earth orbit in January 2022, our software payload was conceived, designed, and delivered in a span of merely two months. It was developed on top of the NASA core Flight System (cFS) framework and the Distributed Spacecraft Autonomy (DSA) Comm cFS application, which translates cFS software bus messages across a Data Distribution Service (DDS) network. The flight software, packaged in Linux container images, was deployed as one of 18 flight applications managed through the Unibap SpaceCloud Framework. The applications were run on a Unibap iX5-102 radiation-tolerant payload computer, hosted on the D-Orbit SCV-004 spacecraft as part of an ESA-sponsored in-orbit technology test. Our payload, referred to as the DSA D-Orbit software, demonstrates the reusability of the DSA Comm app in a substantially different context and purpose as its original mission. Comm’s original design goal was to reliably distribute messages between spacecraft swarms of arbitrary size and dynamic network topology. However, we leverage this same functionality to introduce redundancy and opportunistic parallel data processing in the context of a representative onboard image processing workload. This adaptive mission architecture was enabled in part by the SpaceCloud Framework’s use of container virtualization as the payload integration interface. By using a base container image with common high-level language runtimes and libraries, we were able to rapidly design, develop, and validate our image processing application without many of the technological barriers common to flight software development. We present details the goals, approach, results, and lessons learned through this technology demonstration experiment and contextualize those observations against present and future challenges in spacecraft software development.
computer programming↗
SEPAC: Spacelab Mission 1 report
The SEPAC Spacelab Mission 1 activities relevant to software operations are reported. Spacelab events and problems that did not directly affect SEPAC but are of interest to experimenters are included. Spacelab Mission 1 was launched from KSC on 28 November 1983 at 10:10 Huntsville time. The Spacelab Mission met its objectives. There were two major problems associated with SEPAC: the loss of the EBA gun and the RAU 21.
Source record↗
Aerobraking mission design - Mission domain and mass performance
The work reported comprises part of an Aerobraking Study that sought to establish a 'feasible mission design, navigation design, and MOS design and to show the desirability of aerobraking for the Venus Orbiting Imaging Radar (VOIR) mission by assessing mission performance, cost, and risk'. The developed software assesses accurately the mass performance of aerobraking and chemical missions that place a spacecraft in orbit about another planet. All injection date/arrival data combinations that provide a trajectory with adequate mass performance are available for further study. The considered analysis has been applied to the Type I trajectories from earth to Venus in 1988. The analysis can easily be applied to missions to Mars and to Titan. The intersection of the determined mass performance domain with the stable orbit domain provides an adequate mission domain for VOIR 1988.
Kerridge, S. J.↗
Mission Scenario Development Workbench
The Mission Scenario Development Workbench (MSDW) is a multidisciplinary performance analysis software tool for planning and optimizing space missions. It provides a number of new capabilities that are particularly useful for planning the surface activities on other planets. MSDW enables rapid planning of a space mission and supports flight system and scientific-instrumentation trades. It also provides an estimate of the ability of flight, ground, and science systems to meet high-level mission goals and provides means of evaluating expected mission performance at an early stage of planning in the project life cycle. In MSDW, activity plans and equipment-list spreadsheets are integrated with validated parameterized simulation models of spacecraft systems. In contrast to traditional approaches involving worst-case estimates with large margins, the approach embodied in MSDW affords more flexibility and more credible results early in the lifecycle through the use of validated, variable- fidelity models of spacecraft systems. MSDW is expected to help maximize the scientific return on investment for space missions by understanding early the performance required to have a successful mission while reducing the risk of costly design changes made at late stages in the project life cycle.
Kordon, Mark↗
Considerations for the Next Revision of STRS
Development of NASAs Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for NASA space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and have provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions
waveforms↗