Method for enhancing the process of software tool evaluation and selection: COTS, heritage, and custom software reviewed
Explore the source record for details and available documents.
software COTS process improvement tool evaluation↗
SEARCH · Engineering Papers
Results for “custom 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.
Method for enhancing the process of software tool evaluation and selection: COTS, heritage, and custom software reviewed
Explore the source record for details and available documents.
COTS↗
Stellar Inertial Navigation Workstation
Software and hardware assembled to support specific engineering activities. Stellar Inertial Navigation Workstation (SINW) is integrated computer workstation providing systems and engineering support functions for Space Shuttle guidance and navigation-system logistics, repair, and procurement activities. Consists of personal-computer hardware, packaged software, and custom software integrated together into user-friendly, menu-driven system. Designed to operate on IBM PC XT. Applied in business and industry to develop similar workstations.
Johnson, W.↗
Simulation-to-Flight 1 (STF-1): Automating the Planning, Scheduling, Assessment and Data Processing/Reduction for a Small Satellite
On December 16, 2019, a 3-U CubeSat named STF-1 launched as West Virginia's first spacecraft. This event marked the culmination of a run-up to launch involving the production of the spacecraft, creation/configuration of command and control infrastructure, and the evolution of its co-creation, the NASA Operational Simulator for Small Satellites (NOS3). This event also marked the beginning of a new phase: operations. While plans, procedures, and infrastructure were already in place or started for operations, many lessons were learned during the operations phase, especially during early operations (first month/commissioning phase). Additional plans, procedures, and infrastructure, especially related to communication planning and automated data processing, were created and developed to fill needs for the operation of the STF-1 mission.This paper and presentation will overview the STF-1 operations team's solutions to addressing the many needs of operating a low-earth orbiting CubeSat mission with a single ground antenna that is shared and scheduled with several other missions. The STF-1 operations team deployed a combination of virtualization technologies, ground station technology solutions, collaboration software, custom planning software solutions, and existing ground antenna scheduling solutions to create an effective and efficient CubeSat operations environment. The end-solution satisfied the operations stakeholders, which include NASA, its industry partner TMC Technologies, and four independent professor-student teams at West Virginia University.
CubeSat↗
STF-1 Ground Operations - Automating the Planning, Scheduling, Assessment and Data Processing/Reduction for a Small Satellite
On December 16, 2018, a 3-U CubeSat named STF-1 launched as West Virginia's first spacecraft. This event marked the culmination of a run-up to launch involving the production of the spacecraft, creation/configuration of command and control infrastructure, and the evolution of its co-creation, the NASA Operational Simulator for Small Satellites (NOS3). This event also marked the beginning of a new phase: operations. While plans, procedures, and infrastructure were already in place or started for operations, many lessons were learned during the operations phase, especially during early operations (first month/commissioning phase). Additional plans, procedures, and infrastructure, especially related to communication planning and automated data processing, were created and developed to fill needs for the operation of the STF-1 mission.This paper and presentation will overview the STF-1 operations team's solutions to addressing the many needs of operating a low-earth orbiting CubeSat mission with a single ground antenna that is shared and scheduled with several other missions. The STF-1 operations team deployed a combination of virtualization technologies, ground station technology solutions, collaboration software, custom planning software solutions, and existing ground antenna scheduling solutions to create an effective and efficient CubeSat operations environment. The end-solution satisfied the operations stakeholders, which include NASA, its industry partner TMC2 Technologies, and four independent professor-student teams at West Virginia University.
Suder, Mark↗
Using MCC Facility Metrics to Size, Inform, and Troubleshoot
The Mission Control Center (MCC) underwent a major architecture update that has been used for Mission Operations since 2016. The MCC Performance team has collected system performance and usage metrics to improve the configuration, troubleshoot incidents, and help size the system to accommodate future programs. The data is collected through MCC custom software and custom scripts to extract data from our Commercial Off The Shelf (COTS) tools. This data has enabled MCC to support more activities concurrently, help our operations and development teams to respond to issues more quickly, and make our directorate informed buyers to meet new requirements when developing project plans for the upcoming Fiscal Year.
Data Science↗
GRO/EGRET data analysis software: An integrated system of custom and commercial software using standard interfaces
The Energetic Gamma Ray Telescope Experiment (EGRET) on the Compton Gamma Ray Observatory has been in orbit for more than a year and is being used to map the full sky for gamma rays in a wide energy range from 30 to 20,000 MeV. Already these measurements have resulted in a wide range of exciting new information on quasars, pulsars, galactic sources, and diffuse gamma ray emission. The central part of the analysis is done with sky maps that typically cover an 80 x 80 degree section of the sky for an exposure time of several days. Specific software developed for this program generates the counts, exposure, and intensity maps. The analysis is done on a network of UNIX based workstations and takes full advantage of a custom-built user interface called X-dialog. The maps that are generated are stored in the FITS format for a collection of energies. These, along with similar diffuse emission background maps generated from a model calculation, serve as input to a maximum likelihood program that produces maps of likelihood with optional contours that are used to evaluate regions for sources. Likelihood also evaluates the background corrected intensity at each location for each energy interval from which spectra can be generated. Being in a standard FITS format permits all of the maps to be easily accessed by the full complement of tools available in several commercial astronomical analysis systems. In the EGRET case, IDL is used to produce graphics plots in two and three dimensions and to quickly implement any special evaluation that might be desired. Other custom-built software, such as the spectral and pulsar analyses, take advantage of the XView toolkit for display and Postscript output for the color hard copy. This poster paper outlines the data flow and provides examples of the user interfaces and output products. It stresses the advantages that are derived from the integration of the specific instrument-unique software and powerful commercial tools for graphics and statistical evaluation. This approach has several proven advantages including flexibility, a minimum of development effort, ease of use, and portability.
Laubenthal, N. A.↗
Reliable Customized Control Software in an R&D Environment
This paper describes the methodology by which we can allow each user or project a high degree of customization. To do this we rely on a mixture of public domain software and locally developed software.
configuration↗
Integrated Component-based Data Acquisition Systems for Aerospace Test Facilities
The Multi-Instrument Integrated Data Acquisition System (MIIDAS), developed by the NASA Langley Research Center, uses commercial off the shelf (COTS) products, integrated with custom software, to provide a broad range of capabilities at a low cost throughout the system s entire life cycle. MIIDAS combines data acquisition capabilities with online and post-test data reduction computations. COTS products lower purchase and maintenance costs by reducing the level of effort required to meet system requirements. Object-oriented methods are used to enhance modularity, encourage reusability, and to promote adaptability, reducing software development costs. Using only COTS products and custom software supported on multiple platforms reduces the cost of porting the system to other platforms. The post-test data reduction capabilities of MIIDAS have been installed at four aerospace testing facilities at NASA Langley Research Center. The systems installed at these facilities provide a common user interface, reducing the training time required for personnel that work across multiple facilities. The techniques employed by MIIDAS enable NASA to build a system with a lower initial purchase price and reduced sustaining maintenance costs. With MIIDAS, NASA has built a highly flexible next generation data acquisition and reduction system for aerospace test facilities that meets customer expectations.
Ross, Richard W.↗
CCSDS Time-Critical Onboard Networking Service
The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.
Parkes, Steve↗
Multiple-Flat-Panel System Displays Multidimensional Data
The NASA Ames hyperwall is a display system designed to facilitate the visualization of sets of multivariate and multidimensional data like those generated in complex engineering and scientific computations. The hyperwall includes a 77 matrix of computer-driven flat-panel video display units, each presenting an image of 1,280 1,024 pixels. The term hyperwall reflects the fact that this system is a more capable successor to prior computer-driven multiple-flat-panel display systems known by names that include the generic term powerwall and the trade names PowerWall and Powerwall. Each of the 49 flat-panel displays is driven by a rack-mounted, dual-central-processing- unit, workstation-class personal computer equipped with a hig-hperformance graphical-display circuit card and with a hard-disk drive having a storage capacity of 100 GB. Each such computer is a slave node in a master/ slave computing/data-communication system (see Figure 1). The computer that acts as the master node is similar to the slave-node computers, except that it runs the master portion of the system software and is equipped with a keyboard and mouse for control by a human operator. The system utilizes commercially available master/slave software along with custom software that enables the human controller to interact simultaneously with any number of selected slave nodes. In a powerwall, a single rendering task is spread across multiple processors and then the multiple outputs are tiled into one seamless super-display. It must be noted that the hyperwall concept subsumes the powerwall concept in that a single scene could be rendered as a mosaic image on the hyperwall. However, the hyperwall offers a wider set of capabilities to serve a different purpose: The hyperwall concept is one of (1) simultaneously displaying multiple different but related images, and (2) providing means for composing and controlling such sets of images. In place of elaborate software or hardware crossbar switches, the hyperwall concept substitutes reliance on the human visual system for integration, synthesis, and discrimination of patterns in complex and high-dimensional data spaces represented by the multiple displayed images. The variety of multidimensional data sets that can be displayed on the hyperwall is practically unlimited. For example, Figure 2 shows a hyperwall display of surface pressures and streamlines from a computational simulation of airflow about an aerospacecraft at various Mach numbers and angles of attack. In this display, Mach numbers increase from left to right and angles of attack increase from bottom to top. That is, all images in the same column represent simulations at the same Mach number, while all images in the same row represent simulations at the same angle of attack. The same viewing transformations and the same mapping from surface pressure to colors were used in generating all the images.
Gundo, Daniel↗
CCSDS File Delivery Protocol (CFDP): Why it's Useful and How it Works
Reliable delivery of data products is often required across space links. For example, a NASA mission will require reliable delivery of images produced by an on-board detector. Many missions have their own (unique) way of accomplishing this, requiring custom software. Many missions also require manual operations (e.g. the telemetry receiver software keeps track of what data is missing, and a person manually inputs the appropriate commands to request retransmissions). The Consultative Committee for Space Data Systems (CCSDS) developed the CCSDS File Delivery Protocol (CFDP) specifically for this situation. CFDP is an international standard communication protocol that provides reliable delivery of data products. It is designed for use across space links. It will work well if run over the widely used CCSDS Telemetry and Telecommand protocols. However, it can be run over any protocol, and will work well as long as the underlying protocol delivers a reasonable portion of the data. The CFDP receiver will autonomously determine what data is missing, and request retransmissions as needed. The CFDP sender will autonomously perform the requested transmissions. When the entire data product is delivered, the CFDP receiver will let the CFDP sender know that the transaction has completed successfully. The result is that custom software becomes standard, and manual operations become autonomous. This paper will consider various ways of achieving reliable file delivery, explain why CFDP is the optimal choice for use over space links, explain how the core protocol works, and give some guidance on how to best utilize CFDP within various mission scenarios. It will also touch on additional features of CFDP, as well as other uses for CFDP (e.g. the loading of on-board memory and tables).
Ray, Tim↗
Getting around Antarctica: New High-Resolution Mappings of the Grounded and Freely-Floating Boundaries of the Antarctic Ice Sheet Created for the International Polar Year
Two ice-dynamic transitions of the Antarctic ice sheet - the boundary of grounded ice features and the freely-floating boundary - are mapped at 15-m resolution by participants of the International Polar Year project ASAID using customized software combining Landsat-7 imagery and ICESat/GLAS laser altimetry. The grounded ice boundary is 53 610 km long; 74% abuts to floating ice shelves or outlet glaciers, 19% is adjacent to open or sea-ice covered ocean, and 7% of the boundary ice terminates on land. The freely-floating boundary, called here the hydrostatic line, is the most landward position on ice shelves that expresses the full amplitude of oscillating ocean tides. It extends 27 521 km and is discontinuous. Positional (one-sigma) accuracies of the grounded ice boundary vary an order of magnitude ranging from +/- 52m for the land and open-ocean terminating segments to +/- 502m for the outlet glaciers. The hydrostatic line is less well positioned with errors over 2 km. Elevations along each line are selected from 6 candidate digital elevation models based on their agreement with ICESat elevation values and surface shape inferred from the Landsat imagery. Elevations along the hydrostatic line are converted to ice thicknesses by applying a firn-correction factor and a flotation criterion. BEDMAP-compiled data and other airborne data are compared to the ASAID elevations and ice thicknesses to arrive at quantitative (one-sigma) uncertainties of surface elevations of +/-3.6, +/-9.6, +/-11.4, +/-30 and +/-100m for five ASAID-assigned confidence levels. Over one-half of the surface elevations along the grounded ice boundary and over one-third of the hydrostatic line elevations are ranked in the highest two confidence categories. A comparison between ASAID-calculated ice shelf thicknesses and BEDMAP-compiled data indicate a thin-ice bias of 41.2+/-71.3m for the ASAID ice thicknesses. The relationship between the seaward offset of the hydrostatic line from the grounded ice boundary only weakly matches a prediction based on beam theory. The mapped products along with the customized software to generate them and a variety of intermediate products are available from the National Snow and Ice Data Center.
Bindschadler, R.↗
Ground Processing Affordability for Space Vehicles
Launch vehicles and most of their payloads spend the majority of their time on the ground. The cost of ground operations is very high. So, why so often is so little attention given to ground processing during development? The current global space industry and economic environment are driving more need for efficiencies to save time and money. Affordability and sustainability are more important now than ever. We can not continue to treat space vehicles as mere science projects. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability which are not available for ELV's (Expendable Launch Vehicles). More human-rated vehicles are being developed, with the retirement of the Space Shuttles, and for a new global space race, yet these cost more than the many unmanned vehicles of today. We can learn many lessons on affordability from RLV's. DFO (Design for Operations) considers ground operations during design, development, and manufacturing-before the first flight. This is often minimized for space vehicles, but is very important. Vehicles are designed for launch and mission operations. You will not be able to do it again if it is too slow or costly to get there. Many times, technology changes faster than space products such that what is launched includes outdated features, thus reducing competitiveness. Ground operations must be considered for the full product Lifecycle, from concept to retirement. Once manufactured, launch vehicles along with their payloads and launch systems require a long path of processing before launch. Initial assembly and testing always discover problems to address. A solid integration program is essential to minimize these impacts, as was seen in the Constellation Ares I-X test rocket. For RLV's, landing/recovery and post-flight turnaround activities are performed. Multi-use vehicles require reconfiguration. MRO (Maintenance, Repair, and Overhaul) must be well-planned--- even for the unplanned problems. Defect limits and standard repairs need to be in-place as well as easily added. Many routine inspections and maintenance can be like an aircraft overhaul. Modifications and technology upgrades should be expected. Another factor affecting ground operations efficiency is trending. It is essential for RLV's, and also useful for ELV's which fly the same or similar models again. Good data analysis of technical and processing performance will determine fixes and improvements needed for safety, design, and future processing. Collecting such data on new or low-frequency vehicles is a challenge. Lessons can be learned from the Space Shuttle, or even the Concorde aircraft. For all of the above topics, efficient business systems must be established for comprehensive program management and good throughput. Drawings, specifications, and manuals for an entire launch vehicle are often in different formats from multiple vendors, plus they have proprietary constraints. Nonetheless, the integration team must ensure that all data needed is compatible and visible to each appropriate team member. Ground processing systems for scheduling, tracking, problem resolution, etc. must be well laid-out. The balance between COTS (commercial off the shelf) and custom software is difficult. Multiple customers, vendors, launch sites, and landing sites add to the complexity of efficient IT (Information Technology) tools.
Ingalls, John↗
Software IV and V Research Priorities and Applied Program Accomplishments Within NASA
The mission of this research is to be world-class creators and facilitators of innovative, intelligent, high performance, reliable information technologies that enable NASA missions to (1) increase software safety and quality through error avoidance, early detection and resolution of errors, by utilizing and applying empirically based software engineering best practices; (2) ensure customer software risks are identified and/or that requirements are met and/or exceeded; (3) research, develop, apply, verify, and publish software technologies for competitive advantage and the advancement of science; and (4) facilitate the transfer of science and engineering data, methods, and practices to NASA, educational institutions, state agencies, and commercial organizations. The goals are to become a national Center Of Excellence (COE) in software and system independent verification and validation, and to become an international leading force in the field of software engineering for improving the safety, quality, reliability, and cost performance of software systems. This project addresses the following problems: Ensure safety of NASA missions, ensure requirements are met, minimize programmatic and technological risks of software development and operations, improve software quality, reduce costs and time to delivery, and improve the science of software engineering
Blazy, Louis J.↗
Joint Augmented Reality Visual Informatics System: Concept of Operations
NASA proposed requirements for a digital display for an EVA spacesuit to provide relevant information to the crew member. The Joint Augmented Reality Visual Informatics System (Joint AR) project pursued four years of research and development towards a suit-display system in a near-eye, AR form factor. The project was responsible for developing software (custom graphics engine and core flight software), physical hardware prototyping (controls, projection display optics, suited display platform), virtual prototyping platform (a virtual reality testbed), and human-in-the-loop (HITL) operational testing informed by EVA flight controllers, crew members, and human factors engineers for con-ops definition. This document contains substantial updates to CTSD-ADV-1788 Rev. Basic. This revision was produced by the project to summarize the use-cases and and user experiences developed throughout the project, and refine the Basic revision originally drafted at the beginning of the project life cycle. The primary purpose of this document is to summarize and make available the scenario development efforts that have been pursued and explored within the Joint AR project. This includes descriptions of the scenarios themselves as well as corresponding potential of advanced informatics displays to support those specified scenarios. In doing so, this document provides a variety of approaches to deconstruct and hypothesize how future technological capabilities so that with future EVA work demands can be satisfied within future human planetary spaceflight missions.
Matthew Miller↗
Software support for improving technology infusion
This paper focuses on describing the custom software tool, DDP, that was developed to support the TIMA process, and on showing how the needs of the TIMA process have influenced the development of the structure and capabilities of the DDP software.
requirements risk decision-making tradeoffs↗
Pragmatic quality metrics for evolutionary software development models
Due to the large number of product, project, and people parameters which impact large custom software development efforts, measurement of software product quality is a complex undertaking. Furthermore, the absolute perspective from which quality is measured (customer satisfaction) is intangible. While we probably can't say what the absolute quality of a software product is, we can determine the relative quality, the adequacy of this quality with respect to pragmatic considerations, and identify good and bad trends during development. While no two software engineers will ever agree on an optimum definition of software quality, they will agree that the most important perspective of software quality is its ease of change. We can call this flexibility, adaptability, or some other vague term, but the critical characteristic of software is that it is soft. The easier the product is to modify, the easier it is to achieve any other software quality perspective. This paper presents objective quality metrics derived from consistent lifecycle perspectives of rework which, when used in concert with an evolutionary development approach, can provide useful insight to produce better quality per unit cost/schedule or to achieve adequate quality more efficiently. The usefulness of these metrics is evaluated by applying them to a large, real world, Ada project.
Royce, Walker↗