Automated ground station software development
Automated ground station software program to control four tracking links by single computer
Rodgers, J. C.↗
SEARCH · Engineering Papers
Results for “Ground 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.
An Overview of the Process for Pre-Launch Checkout and Transition Activities in Support of the International Space Station (ISS) Payload Operations Integration Center
The objective of this paper is to provide future ISS scientists and/or engineers with an overview of the coordination process for the preparation and implementation of the pre-launch checkout and transition activities as observed from the Marshall Control Flight Center (MSFC) Payload Operations Integration Center perspective. This includes 4 major phases: (1) Verification and validation of the new command and telemetry databases that are needed for new payload experiments and new onboard formats; (2) Integration testing of the new ground control software and hardware; (3) Final internal and external pre-launch checkouts with cadre and experiment teams; (4) Performance of the actual synchronized transition between MSFC, Johnson Space Center (JSC), and ISS onboard configuration to new onboard software, ground software, and databases.
Digesu, Sam↗
How Usability Testing Resulted in Improvements to Ground Collision Software for General Aviation: Improved Ground Collision Avoidance System (IGCAS)
The NASA improved Ground Collision Avoidance System (iGCAS) team conducted an onsite usability study at Experimental Aircraft Association (EAA) Air Venture in Oshkosh, Wisconsin from July 19 through July 26, 2015. EAA Air Venture had approximately 550,000 attendees from which the sample pool of pilots were selected. The objectives of this study were to assess the overall appropriateness and acceptability of iGCAS as a warning system for General Aviation aircraft, usability of the iGCAS displays and audio cues, test terrain avoidance characteristics, performance, functionality, pilot response time, and correlate terrain avoidance performance and pilot response time data.
collision avoidance↗
Ground Support Software for Spaceborne Instrumentation
ION is a system of ground support software for the ion and neutral mass spectrometer (INMS) instrument aboard the Cassini spacecraft. By incorporating commercial off-the-shelf database, Web server, and Java application components, ION offers considerably more ground-support-service capability than was available previously. A member of the team that operates the INMS or a scientist who uses the data collected by the INMS can gain access to most of the services provided by ION via a standard pointand click hyperlink interface generated by almost any Web-browser program running in almost any operating system on almost any computer. Data are stored in one central location in a relational database in a non-proprietary format, are accessible in many combinations and formats, and can be combined with data from other instruments and spacecraft. The use of the Java programming language as a system-interface language offers numerous capabilities for object-oriented programming and for making the database accessible to participants using a variety of computer hardware and software.
Anicich, Vincent↗
Improving Security of Ground System Software
An estimated 84% of all security breaches are application-related, not firewall violations. To what extent is your organization focused on addressing security issues in its software? Software plays a critical role in mission success, and software similarly plays a role in mission security. However, software can introduce vulnerabilities to the system, such as use of a COTS product that has a backdoor, or a hole in the security of the system deliberately left in place by designers or maintainers. The motivations for such holes are not always sinister, but can provide a means for malicious intrusion into the mission. Students will learn an approach to securing ground software within the context of federal information systems. Federal requirements, coding standards, tool usage will be discussed as part of the solution to securing software.
Bailey, Brandon↗
Simulation Testing of Embedded Flight Software
Virtual Real Time (VRT) is a computer program for testing embedded flight software by computational simulation in a workstation, in contradistinction to testing it in its target central processing unit (CPU). The disadvantages of testing in the target CPU include the need for an expensive test bed, the necessity for testers and programmers to take turns using the test bed, and the lack of software tools for debugging in a real-time environment. By virtue of its architecture, most of the flight software of the type in question is amenable to development and testing on workstations, for which there is an abundance of commercially available debugging and analysis software tools. Unfortunately, the timing of a workstation differs from that of a target CPU in a test bed. VRT, in conjunction with closed-loop simulation software, provides a capability for executing embedded flight software on a workstation in a close-to-real-time environment. A scale factor is used to convert between execution time in VRT on a workstation and execution on a target CPU. VRT includes high-resolution operating- system timers that enable the synchronization of flight software with simulation software and ground software, all running on different workstations.
Shahabuddin, Mohammad↗
Multimission Modular Spacecraft Ground Support Software System (MMS/GSSS) state-of-the-art computer systems/ compatibility study
The compatibility of the Multimission Modular Spacecraft (MMS) Ground Support Software System (GSSS), currently operational on a ModComp IV/35, with the VAX 11/780 system is discussed. The compatibility is examined in various key areas of the GSSS through the results of in depth testing performed on the VAX 11/780 and ModComp IV/35 systems. The compatibility of the GSSS with the ModComp CLASSIC is presented based upon projections from ModComp supplied literature.
Source record↗
Developing satellite ground control software through graphical models
This paper discusses a program of investigation into software development as graphical modeling. The goal of this work is a more efficient development and maintenance process for the ground-based software that controls unmanned scientific satellites launched by NASA. The main hypothesis of the program is that modeling of the spacecraft and its subsystems, and reasoning about such models, can--and should--form the key activities of software development; by using such models as inputs, the generation of code to perform various functions (such as simulation and diagnostics of spacecraft components) can be automated. Moreover, we contend that automation can provide significant support for reasoning about the software system at the diagram level.
Bailin, Sidney↗
An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost
NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.
Utz, Hans↗
The Cassini/Huygens Mission to Saturn and Titan
The Cassini/Huygens mission is a joint endeavor between NASA, the EuropeanSpace Agency, and the Italian Space Agency to send a spacecraft to perform an extensive exploration of the Saturnian system, including an atmospheric probe to go to the surface of Titan. The spacecraft was launched on October 15, 1997, and now has completed five years of its nearly seven year journey to Saturn. The cruise period has been a relatively passive time for the spacecraft, but an intensely busy one for the flight team. There is now less than two years to go until arrival at Saturn, and a significant portion of the effort deliberately planned for the post-launch period remains to be completed. Ground activities include the development of flight software, ground software, and science observation plans in order to be prepared to operate the mission after arrival at Saturn. This paper provides an update to the mission status and progress over the past year.
Cassini Huygens Saturn Titan↗
Dynamic Assurance of Autonomous Systems through Ground Control Software
Assurance cases are being increasingly acknowledged as a way to build trust in complex systems with autonomous capabilities [1]. An assurance case is a comprehensive, defensible, and valid justification that a system will function as intended for the specific mission and operating environment. Such justifications for systems with autonomous capabilities are often based on various probabilistic quantifications [2]. Due to the dynamic nature of the environmental conditions in which these systems operate, as well as the changing nature of the autonomous systems themselves, these probabilistic quantifications cannot be simply estimated once during design time. Rather, they need to be continually evaluated during systems operations to ensure that the assurance case justifications are valid. We refer to the assurance case that combines both the static and dynamic elements as a Dynamic Assurance Case (DAC). Such complex systems with autonomous capabilities are often deployed with a Ground Control Software (GCS) component to enable remote operation. Whether the system is composed of a single unit or a fleet of units, deployed distributed or in remote environments, GCS acts as a window into the behavior of the deployed system. It receives telemetry from the system, issues commands to the system and provides various functionalities to visualize the system performance. We propose a dynamic assurance framework where the GCS acts as a relay between the autonomous system and its DAC. GCS can be used to measure both unit-specific as well as system-wide probabilistic quantifications using the incoming telemetry. We embed these quantifications throughout the DAC as variables that can be updated by external sources. We use the GCS to periodically update these variables, which allows us to continually evaluate the formally defined assurance case justifications. We demonstrate our dynamic assurance framework in the NASA Ames project Troupe1 that aims at developing a fleet of rovers capable of au- tonomously mapping their environment. The rovers work cooperatively, each collecting data for different parts of the environment. Each rover runs an identical core Flight System (cFS) [4] application. Troupe1 uses OpenC3 Cosmos [5] as the ground system, and AdvoCATE [3] to capture the system DAC. We show how we can measure both rover-specific and system-wide quantifications in Cosmos using its Ruby scripting editor and pass them into the DAC modelled in AdvoCATE. Then, we show how these incoming variables can be embedded in different parts of the DAC and how effects of their updates can be observed
Irfan Sljivo↗
Inflight Performance of Cassini Reaction Wheel Bearing Drag in 1997-2013
As the first spacecraft to achieve orbit at Saturn in 2004, Cassini has collected science data throughout its four-year prime mission (2004-08), and has since been approved for a first and second extended missions through September 2017. Cassini is a three-axis stabilized spacecraft. It uses reaction wheels to achieve high level of spacecraft pointing stability that is needed during imaging operations of several science instruments. The Cassini flight software makes in-flight estimates of reaction wheel bearing drag torque and made them available to the mission operations team. These telemetry data are being trended for the purpose of monitoring the long-term health of the reaction wheel bearings. Anomalous drag torque signatures observed over the past 15 years are described in this paper. One of these anomalous drag conditions is bearing cage instability that appeared (and disappeared) spontaneously and unpredictably. Cage instability is an uncontrolled vibratory motion of the bearing cage that can produce high-impact forces internal to the bearing that will cause intermittent and erratic torque transients. Characteristics of the observed cage instabilities and other drag torque "spikes" are described in this paper. In day-to-day operations, the reaction wheels' rates must be neither too high nor too low. To protect against operating the wheels in any undesirable conditions (such as prolonged low spin rate operations), a ground software tool named Reaction Wheel Bias Optimization Tool (RBOT) was developed for the management of the wheels. Disciplined and long-term use of this ground software has led to significant reduction in the daily consumption rate of the wheels' low spin rate dwell time. Flight experience on the use of this ground software tool as well as other lessons learned on the management of Cassini reaction wheels is given in this paper.
Cassini/Huygens Mission↗
Web Application Software for Ground Operations Planning Database (GOPDb) Management
A Web application facilitates collaborative development of the ground operations planning document. This will reduce costs and development time for new programs by incorporating the data governance, access control, and revision tracking of the ground operations planning data. Ground Operations Planning requires the creation and maintenance of detailed timelines and documentation. The GOPDb Web application was created using state-of-the-art Web 2.0 technologies, and was deployed as SaaS (Software as a Service), with an emphasis on data governance and security needs. Application access is managed using two-factor authentication, with data write permissions tied to user roles and responsibilities. Multiple instances of the application can be deployed on a Web server to meet the robust needs for multiple, future programs with minimal additional cost. This innovation features high availability and scalability, with no additional software that needs to be bought or installed. For data governance and security (data quality, management, business process management, and risk management for data handling), the software uses NAMS. No local copy/cloning of data is permitted. Data change log/tracking is addressed, as well as collaboration, work flow, and process standardization. The software provides on-line documentation and detailed Web-based help. There are multiple ways that this software can be deployed on a Web server to meet ground operations planning needs for future programs. The software could be used to support commercial crew ground operations planning, as well as commercial payload/satellite ground operations planning. The application source code and database schema are owned by NASA.
Lanham, Clifton↗
Rapid Centroids and the Refined Position Accuracy of the Swift Gamma-ray Burst Catalogue
The Swift X-ray Telescope autonomously refines the Burst Alert Telescope positions (approx.1-4' uncertainty) to better than 5 arcsec, within 5 seconds of target acquisition by the observatory for typical bursts. The results of the rapid positioning capability of the XRT are presented here for both known sources and newly discovered GRBs, demonstrating the ability to automatically utilize one of two integration times according to the burst brightness, and to correct the position for alignment offsets caused by the fast pointing performance and variable thermal environment of the satellite as measured by the Telescope Alignment Monitor. We present an evaluation of the position accuracy for both the onboard centroiding software and the ground software for the calibration targets and show that a significant improvement in position accuracy is obtained if the boresight detector position is optimized relative to the spacecraft pointing. Finally, we present an updated catalogue of Swift GRB X-ray positions obtained in Photon Counting Mode using the improved, calibrated boresight.
Hill, J. E.↗
SLS Flight Software Testing: Using a Modified Agile Software Testing Approach
NASA's Space Launch System (SLS) is an advanced launch vehicle for a new era of exploration beyond earth's orbit (BEO). The world's most powerful rocket, SLS, will launch crews of up to four astronauts in the agency's Orion spacecraft on missions to explore multiple deep-space destinations. Boeing is developing the SLS core stage, including the avionics that will control vehicle during flight. The core stage will be built at NASA's Michoud Assembly Facility (MAF) in New Orleans, LA using state-of-the-art manufacturing equipment. At the same time, the rocket's avionics computer software is being developed here at Marshall Space Flight Center in Huntsville, AL. At Marshall, the Flight and Ground Software division provides comprehensive engineering expertise for development of flight and ground software. Within that division, the Software Systems Engineering Branch's test and verification (T&V) team uses an agile test approach in testing and verification of software. The agile software test method opens the door for regular short sprint release cycles. The idea or basic premise behind the concept of agile software development and testing is that it is iterative and developed incrementally. Agile testing has an iterative development methodology where requirements and solutions evolve through collaboration between cross-functional teams. With testing and development done incrementally, this allows for increased features and enhanced value for releases. This value can be seen throughout the T&V team processes that are documented in various work instructions within the branch. The T&V team produces procedural test results at a higher rate, resolves issues found in software with designers at an earlier stage versus at a later release, and team members gain increased knowledge of the system architecture by interfacing with designers. SLS Flight Software teams want to continue uncovering better ways of developing software in an efficient and project beneficial manner. Through agile testing, there has been increased value through individuals and interactions over processes and tools, improved customer collaboration, and improved responsiveness to changes through controlled planning. The presentation will describe agile testing methodology as taken with the SLS FSW Test and Verification team at Marshall Space Flight Center.
Bolton, Albanie T.↗
Adaptive Independent Verification and Validation (IV&V) Reduces Risk of Software Impacting Safety in Artemis Missions
The National Aeronautics and Space Administration (NASA) is asking more of its human spaceflight programs than ever before through the collective Artemis Missions. The NASA Independent Verification and Validation (IV&V) Program contributes to NASA’s human spaceflight goals by providing IV&V services for NASA’s critical spacecraft and ground software. The IV&V Program is tasked with providing assurance from both individual and integrated mission software perspectives. The Artemis IV&V organization is actively supporting six distinct development efforts: Orion, the Space Launch System (SLS), Exploration Ground Systems (EGS), Mission Control Center (MCC), the Lunar Gateway, and the Human Landing System (HLS), representing a wide diversity of developer organizations, management structures, and development approaches. With much of this extremely complex flight and ground software being essential to human safety both on the ground and in space, Artemis IV&V is likewise challenged to provide more value-added assurance to future Artemis missions within a constrained budget. To meet this challenge, Artemis IV&V employs a variety of novel and evolving “Adaptive IV&V” approaches for planning and executing IV&V analysis to increase both the efficiency and effectiveness of the IV&V Program’s assurance activities, and to address the difficulties imposed by assuring software for a large, highly integrated, multi-mission enterprise managed and executed by physically and organizationally distinct programs. Instilling agile principles like iterative planning cycles, self-organizing teams, and regular retrospectives, into IV&V planning and execution has led to a more rapid turnaround of a minimum viable assurance product and allowed for increased alignment of assurance activities with development progress. Adopting an assurance case methodology has led to greater consistency and clearer communication of assurance design and provided a foundation for long-term maintenance of assurance plans, products, and results across missions. The IV&V-developed Assurance / Safety Case Analytical Network (A-SCAN) framework and tool has enabled the quantification and tracking of system/software risk and confidence. These confidence measures provide a means to repeatedly express the impact of planned and completed assurance work and the remaining residual risk. Applied as part of a “Follow-the-Risk” organizational ethos, this allows consistent rightsizing of analysis rigor and intensity commensurate with the perceived risk of defects, as well as appropriate targeting of the highest risk areas of the software to find safety issues before they can manifest. Finally, the development of the IV&V Advanced Risk Reduction Integrated Software Test and Operations Tri-program Lightweight Environment (ARRISTOTLE), an integrated software-only simulation of Orion, SLS, and EGS systems, has made it possible to independently test integrated pad and flight scenarios and inject faults to observe how the Artemis multi-program, mission software behaves in degraded modes and in response to hazards. These adaptive IV&V investments have enabled Artemis IV&V to become more efficient and effective in IV&V planning and execution and respond more readily to changes in the risk landscape, increasing the breadth and depth of risk reduction possible within the available resources. Residual risk tracking allows IV&V to communicate more effectively with stakeholders, both internal and external at all levels, and inform key decision-making personnel. This evolving assurance design approach provides IV&V surety that work is performed in the highest risk, most value-added areas of the software, to keep our astronauts and ground crews safe and ensure mission success.
Gerek A Whitman↗
Adaptive Independent Verification and Validation (IV&V) Reduces Risk of Software Impacting Safety in Artemis Missions
The National Aeronautics and Space Administration (NASA) is asking more of its human spaceflight programs than ever before through the collective Artemis Missions. The NASA Independent Verification and Validation (IV&V) Program contributes to NASA’s human spaceflight goals by providing IV&V services for NASA’s critical spacecraft and ground software. The IV&V Program is tasked with providing assurance from both individual and integrated mission software perspectives. The Artemis IV&V organization is actively supporting six distinct development efforts: Orion, the Space Launch System (SLS), Exploration Ground Systems (EGS), Mission Control Center (MCC), the Lunar Gateway, and the Human Landing System (HLS), representing a wide diversity of developer organizations, management structures, and development approaches. With much of this extremely complex flight and ground software being essential to human safety both on the ground and in space, Artemis IV&V is likewise challenged to provide more value-added assurance to future Artemis missions within a constrained budget. To meet this challenge, Artemis IV&V employs a variety of novel and evolving “Adaptive IV&V” approaches for planning and executing IV&V analysis to increase both the efficiency and effectiveness of the IV&V Program’s assurance activities, and to address the difficulties imposed by assuring software for a large, highly integrated, multi-mission enterprise managed and executed by physically and organizationally distinct programs. Instilling agile principles like iterative planning cycles, self-organizing teams, and regular retrospectives, into IV&V planning and execution has led to a more rapid turnaround of a minimum viable assurance product and allowed for increased alignment of assurance activities with development progress. Adopting an assurance case methodology has led to greater consistency and clearer communication of assurance design and provided a foundation for long-term maintenance of assurance plans, products, and results across missions. The IV&V-developed Assurance / Safety Case Analytical Network (A-SCAN) framework and tool has enabled the quantification and tracking of system/software risk and confidence. These confidence measures provide a means to repeatedly express the impact of planned and completed assurance work and the remaining residual risk. Applied as part of a “Follow-the-Risk” organizational ethos, this allows consistent rightsizing of analysis rigor and intensity commensurate with the perceived risk of defects, as well as appropriate targeting of the highest risk areas of the software to find safety issues before they can manifest. Finally, the development of the IV&V Advanced Risk Reduction Integrated Software Test and Operations Tri-program Lightweight Environment (ARRISTOTLE), an integrated software-only simulation of Orion, SLS, and EGS systems, has made it possible to independently test integrated pad and flight scenarios and inject faults to observe how the Artemis multi-program, mission software behaves in degraded modes and in response to hazards. These adaptive IV&V investments have enabled Artemis IV&V to become more efficient and effective in IV&V planning and execution and respond more readily to changes in the risk landscape, increasing the breadth and depth of risk reduction possible within the available resources. Residual risk tracking allows IV&V to communicate more effectively with stakeholders, both internal and external at all levels, and inform key decision-making personnel. This evolving assurance design approach provides IV&V surety that work is performed in the highest risk, most value-added areas of the software, to keep our astronauts and ground crews safe and ensure mission success.
Gerek Whitman↗
Ground Autonomy for an Aging Spacecraft
As it approaches the sixteenth of a 5 year prime mission, NASA's Solar Radiation and Climate Experiment (SORCE) mission continues to meet and exceed all science requirements while operating with severely degraded batteries. By 2013, the batteries had degraded such that the On Board Computer (OBC) could not be powered through eclipse. This prevents science data collection in eclipse and erases over 99% of all stored science and engineering telemetry. To mitigate these problems, the Flight Operations Team (FOT) at the Laboratory for Atmospheric and Space Physics (LASP) adopted a new operations scheme. "Daylight Only Operations" (DO-OP) transitions the spacecraft from safemode to science mode every orbit. This involved heavily automating the transition process using ground autonomy to improve spacecraft recovery time to 6 minutes - down from 3 orbits of manual commanding. While highly successful, this method of operations poses daily challenges that must be overcome using increasingly complex ground software.
Autonomous Operations↗