Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “core Flight 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.

At least 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Baselining the New GSFC Information Systems Center: The Foundation for Verifiable Software Process Improvement

This paper describes a study performed at the Information System Center (ISC) in NASA Goddard Space Flight Center. The ISC was set up in 1998 as a core competence center in information technology. The study aims at characterizing people, processes and products of the new center, to provide a basis for proposing improvement actions and comparing the center before and after these actions have been performed. The paper presents the ISC, goals and methods of the study, results and suggestions for improvement, through the branch-level portion of this baselining effort.

Parra, A.↗
NASA NTRS2015

Core Flight System (cFS) a Low Cost Solution for SmallSats

The cFS is a FSW product line that uses a layered architecture and compile-time configuration parameters which make it portable and scalable for a wide range of platforms. The software layers that defined the application run-time environment are now under a NASA-wide configuration control board with the goal of sustaining an open-source application ecosystem.

flight software↗
NASA NTRSDate not supplied

Space Robot Operating System (Space ROS)

Space Robot Operating System (Space ROS) is an open-source software framework for flight-quality robotic and autonomous space systems. It combines the benefits of open-source software and flight software best-practices into a single framework. Space ROS is predicated on ROS2 and is therefore reusable, modular and adoptable. As an open-source framework, it is accessible to the global space community. Space ROS is intended to be compliant with NASA flight software engineering practices in order to facilitate meeting mission and safety standards. Space ROS has fault management and real-time capabilities at its core.

Will Chambers↗
NASA NTRS2018

NASA Pilot-Engaged Expert Response Using IBM Watson Technology: Prototype Evaluation of Knowledge Retrieval System

NASA Langley Research Center and IBM have been investigating the use of IBM Watson technology in aerospace research and development. One application of Watson technology is the Pilot-Engaged Expert Response (PEER) use case. The PEER system is envisioned as an in-cockpit advisor that will act as a source of situationally-relevant information for pilots and other flight crew members to assist in decision making about real-time events and situations that arise in the course of aircraft operations. PEER will make available vast stores of knowledge and information quickly and directly, putting important informational resources where they are needed most. IBM has worked with NASA to develop an architecture and articulate a roadmap for the development of the PEER system. That vision is built around Watson Discovery Advisor (WDA) software solution, derived from IBM's Jeopardy!-winning automatic question answering system. PEER makes use of WDA's sophisticated question-answering capabilities as its core, adding important User Interface components and other customizations for the cockpit environment, including communication with flight systems and other external data sources. The development plan for PEER includes four development stages, with the current project constituting the first phase. In this project, a prototype instance of PEER was successfully adapted to the aviation domain, enabling users to ask questions about aviation topics and receive useful and accurate answers to these questions. Major tasks accomplished include the development of procedures for domain adaptation through automatic lexicon extraction from domain glossaries; generation of question-answer training data which was used to train the system; and assessment of the effectiveness of domain adaptation, which showed a dramatic improvement in the ability of the PEER system to answer domain-relevant questions. In addition, the vision for the PEER system was pushed forward by the articulation of a plan for the automatic enhancement of question-answering with contextual information. This initial phase focused on two main goals: 1) the targeted domain adaptation of the underlying WDA system to the aviation domain; and, 2) the design of the software systems needed to leverage flight-contextual data. Domain adaptation of the WDA system proceeds via three main activities: Domain data ingestion, lexical customization and model training. A textual corpus consisting of 1,147 individual documents with more than 7.5 million words of text was ingested into the system and this served as the basis of all further development. A domain lexicon of over 3,500 aviation-domain terms was semi-automatically generated from domain documents and used to train the system. In addition, a set of over 500 question-answer (QA) pairs relevant to the PEER use case was developed; these were used to train and assess the system. These important first steps established the basis for the PEER system. In addition, steps were taken towards the integration of the PEER system into the cockpit environment with the development of a functional design for the Contextual Data Augmentation (CDA) subsystem. This subsystem brings to bear contextual data to improve system responses. It has three main submodules: the Contextual Data Collection module, the Contextual Data Selection module, and the Contextual QA Augmentation module. These modules form a processing pipeline that addresses the problems associated with automatically integrating information from external resources into the knowledge-retrieval mechanism.

Machine learning↗
NASA NTRS2000

Rapidly Re-Configurable Flight Simulator Tools for Crew Vehicle Integration Research and Design

While simulation is a valuable research and design tool, the time and difficulty required to create new simulations (or re-use existing simulations) often limits their application. This report describes the design of the software architecture for the Reconfigurable Flight Simulator (RFS), which provides a robust simulation framework that allows the simulator to fulfill multiple research and development goals. The core of the architecture provides the interface standards for simulation components, registers and initializes components, and handles the communication between simulation components. The simulation components are each a pre-compiled library 'plug-in' module. This modularity allows independent development and sharing of individual simulation components. Additional interfaces can be provided through the use of Object Data/Method Extensions (OD/ME). RFS provides a programmable run-time environment for real-time access and manipulation, and has networking capabilities using the High Level Architecture (HLA).

Schutte, Paul C.↗
NASA NTRS2002

Rapidly Re-Configurable Flight Simulator Tools for Crew Vehicle Integration Research and Design

While simulation is a valuable research and design tool, the time and difficulty required to create new simulations (or re-use existing simulations) often limits their application. This report describes the design of the software architecture for the Reconfigurable Flight Simulator (RFS), which provides a robust simulation framework that allows the simulator to fulfill multiple research and development goals. The core of the architecture provides the interface standards for simulation components, registers and initializes components, and handles the communication between simulation components. The simulation components are each a pre-compiled library 'plugin' module. This modularity allows independent development and sharing of individual simulation components. Additional interfaces can be provided through the use of Object Data/Method Extensions (OD/ME). RFS provides a programmable run-time environment for real-time access and manipulation, and has networking capabilities using the High Level Architecture (HLA).

Pritchett, Amy R.↗
NASA NTRS2022

Cross-Cutting Flight Infrastructure Improvements on M2020

Mars2020 (M2020) was formulated as a mission that leveraged as much Mars Science Laboratory (MSL) heritage as possible, while focusing major new development efforts on the original and unique elements needed to accomplish the different mission objectives. Well publicized examples of high profile new developments include precision landing, the sampling and caching system, the specific instrument suite, improved mobility via Autonomous Navigation, and later the addition of the Ingenuity helicopter. Less well known are the refinements to the core flight infrastructure, primarily in the cross-cutting functions of Telecom, Avionics, Data Management, Communications Behaviors, and Parameter Management. These enhancements are introduced predominately via flight software, and represent increases in capability that justified their inclusion in an otherwise heritage-focused project environment.Perseverance’s cross-cutting flight infrastructure improvements fall into and across the following five categories. First is a trimming of the software footprint of infrastructure modules, in order to make room for memory demands elsewhere in the system. Second is the minimization of data volume to be downlinked, through various methods such as the incorporation of new compression options. Third is the maximization of the available downlink bandwidth for data, by curtailing content-less data (fill) and introducing an improved UHF proximity link protocol. Fourth is a reduction in vulnerabilities, through increased file system redundancy, robustness, and software process monitoring. Fifth is an increase in operations efficiency by lowering file system mount times, improving parallelism between simultaneous events, minimizing the time to recover from file system errors, streamlining the purging of obsolete data, and reducing the number of commands to service parameters by a factor of 100.Individually, none of the cross-cutting infrastructure improvements are likely to garner headlines, but collectively they appreciably improve the safety and operability of Perseverance over its predecessor. This paper will describe the improvements, their promise, and where applicable, their actual impact in operations.

Bohannon, Emily↗
NASA NTRS1976

Payload specialist station study. Volume 3: Program study cost estimates. Part 1: Work breakdown structure

The work breakdown structure (WBS) for the Payload Specialist Station (PSS) is presented. The WBS is divided into two elements--PSS contractor and mission unique requirements. In accordance with the study ground rules, it is assumed that a single contractor, hereafter referred to as PSS Contractor will perform the following: (1) provide C and D hardware (MFDS and elements of MMSE), except for GFE; (2) identify software requirements; (3) provide GSE and ground test software; and (4) perform systems engineering and integration in support of the Aft Flight Deck (AFD) C and D concept. The PSS Contractor WBS element encompasses a core or standardized PSS concept. Payload peculiar C and D requirements identified by users will originate as a part of the WBS element mission unique requirements; these requirements will be provided to the PSS Contractor for implementation.

Source record↗
NASA NTRS2015

AMO EXPRESS: A Command and Control Experiment for Crew Autonomy Onboard the International Space Station

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 experiment on-board the International Space Station that demonstrated single action intelligent procedures for crew command and control. The target problem was to enable crew initialization of a facility class rack 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 initialization of a medical facility to respond to 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). Utilization of Draper Laboratory's Timeliner software, deployed on-board the ISS within the Command and Control (C&C) computers and the Payload computers, allowed development of the automated procedures specific to ISS without having to certify and employ novel software for procedure development and execution. The procedures contained the ground procedure logic and actions as possible to include fault detection and recovery capabilities.

Stetson, Howard K.↗
NASA NTRS2015

AMO EXPRESS: A Command and Control Experiment for Crew Autonomy Onboard the International Space Station

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 experiment on-board the International Space Station that demonstrated single action intelligent procedures for crew command and control. The target problem was to enable crew initialization of a facility class rack 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 initialization of a medical facility to respond to 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). Utilization of Draper Laboratory's Timeliner software, deployed on-board the ISS within the Command and Control (C&C) computers and the Payload computers, allowed development of the automated procedures specific to ISS without having to certify and employ novel software for procedure development and execution. The procedures contained the ground procedure logic and actions as possible to include fault detection and recovery capabilities. 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 (via Timerliner) 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. WebPD is a web based application that serves as the user interface for electronic procedure execution. It incorporates several aspects of the HTML5 standard. Procedures are written in a dialect of XML called Procedure Representation Language (PRL). WebPD tracks execution status in the procedure or procedures being displayed. WebPD aggregates and simplifies the auto-sequence execution status information, and formatted to be easily followed and understood by an operator who is not dedicated to actively monitoring the task. WebPD also provides an integrated data and control interface to pause or halt the execution in order to provide a check point of operation and to examine progress before starting the next sequence of activities. For this demonstration, the procedure was initiated and monitored from the ground. As the Timeliner sequences executed, their high-level execution status was written to PLMDM memory. This memory is read and downlinked via Ku-Band at a 1 Hz rate. The data containing the high-level execution status is de-commutated on the ground, and rebroadcast for WebPD consumption. A future demonstration will be performed onboard, with ISS astronauts initiating the operations instead of ground controllers. The AMO EXPRESS experiment demonstrated activation and de-activation of EXPRESS rack 7, providing the capability of future single button activations and deactivations of facility class racks. The experiment achieved numerous technical and operations 'firsts' for the ISS

Stetson, Howard K.↗
NASA NTRSDate not supplied

A new template for developing C++ applications in NASA's Core Flight System

In this presentation, we will demonstrate an example Core Flight System (cFS) application written in C++, compatible with the Draco releases of the Core Flight Executive (cFE) and NASA Operating System Abstraction Layer (OSAL). The application boilerplate, supporting library, and associated generation script were recently developed and licensed under the permissive Apache License 2.0 with the goal of easing the cFS app development with C++. The design and features of this application will be presented, including a higher-level interface for interactions with the cFE software bus pipes, tables, and event services. Data structures are provided for centralized telecommand and telemetry parsing which isolates bookkeeping of message components from the calling code in an application's core logic. Specific advantages of writing a cFS application in C++ will be shown, including easier avoidance of symbol collisions via namespaces, expanded compile-time checks via constant expressions, default initialization for data structures, null safety via references, improved syntax for operating on multi-dimensional arrays, and reliable serialization of enumerations via enumeration classes. Special considerations needed for integrating a C++ application will be identified, including function linkage, exceptions, and stack unwinding. Evidence for the usefulness of this template will be discussed in the context of development of a flight software application used for interfacing with a solid-state data recorder.

Dominick Allen↗
NASA NTRS1993

Profile of NASA software engineering: Lessons learned from building the baseline

It is critically important in any improvement activity to first understand the organization's current status, strengths, and weaknesses and, only after that understanding is achieved, examine and implement promising improvements. This fundamental rule is certainly true for an organization seeking to further its software viability and effectiveness. This paper addresses the role of the organizational process baseline in a software improvement effort and the lessons we learned assembling such an understanding for NASA overall and for the NASA Goddard Space Flight Center in particular. We discuss important, core data that must be captured and contrast that with our experience in actually finding such information. Our baselining efforts have evolved into a set of data gathering, analysis, and crosschecking techniques and information presentation formats that may prove useful to others seeking to establish similar baselines for their organization.

Hall, Dana↗
NASA NTRS2019

UAS Service Supplier Checkout: How UTM Confirmed Readiness of Flight Tests with UAS Service Suppliers

NASA collaborated with industry partners to develop and test the small Unmanned Aircraft System (sUAS) Traffic Management (UTM) research platform, a software prototype used for developing airspace integration requirements for sUAS operations. The lessons learned from these activities will help inform the Federal Aviation Administration (FAA) on what is needed to safely manage sUAS operations. A core component of the UTM platform is the UAS Service Supplier (USS), which acts as a communications bridge to meet the regulatory and operational requirements. As the UTM partners began USS flight tests, NASA found that it was difficult to get all USSs functioning at comparable quality levels to ensure successful flight tests. Also, NASA anticipated that the FAA would encounter similar challenges when they begin to register USSs for operational use. These realizations led to the development of USS Checkout, a set of processes and tools designed to increase flight test efficiency. We learned that a good USS Checkout process is balanced for simplicity versus test coverage, and is amenable to automation. We also learned that when USS Checkout is a USS prerequisite for flight tests, flight tests were more efficient and effective.

Smith, Irene Skupniewicz↗
NASA NTRS2019

High-Performance Spaceflight Computing (HPSC) Middleware Overview

High Performance Spacecraft Computing (HPSC) is a joint project between the National Aeronautics and Space Administration (NASA) and Air Force Research Lab (AFRL) to develop a high-performance multi-core radiation hardened flight processor. HPSC offers a new flight computing architecture to meet the needs of NASA missions through 2030 and beyond. Providing on the order of 100X the computational capacity of current flight processors for the same amount of power, the multicore architecture of the HPSC processor, or "Chiplet" provides unprecedented flexibility in a flight computing system by enabling the operating point to be set dynamically, trading among needs for computational performance, energy management and fault tolerance. The HPSC Chiplet is being developed by Boeing under contract to NASA, and is expected to provide prototypes in 2021. The HPSC Chiplet prototypes will be delivered with an evaluation board, system emulators, comprehensive system software, and a software development kit. In addition to the vendor deliverables, the AFRL is funding the development of a flexible Middleware to be developed by NASA Jet Propulsion Laboratory and NASA Goddard Space Flight Center. The HPSC Middleware provides a suite of thirteen high level services to manage the compute, memory and I/O resources of this complex device.This presentation will provide an overview of the HPSC project, including a hardware overview, system software overview, Middleware overview, and mission use cases. The hardware overview will provide a look at the 8 core High Performance Processing Subsystem (HPPS), the Real Time Processing Subsystem (RTPS), the Chiplet Configuration Management Subsystem, on chip peripherals, and high speed I/O. The system software overview will introduce the boot loaders, operating systems, device drivers, and software development environment. The Middleware overview will provide insight into the high-level services that will be provided to help mission developers manage the many resources and configurations made possible with the Chiplet. Finally, the presentation will provide a brief look at the mission use cases that can be enabled with this next generation architecture.

middleware↗
NASA NTRS1991

JPL's Space Flight Operations Center: Development project overview

The topics are covered in view graph form and include the following: (1) major elements of deep space flight programs; (2) development schedule; (3) primary design goals; (4) Space Flight Operations Center (SFOC) data systems architecture; (5) technical guidelines; (6) SFOC data system functional architecture; (7) typical SFOC node; (8) SFOC components; (9) SFOC software categories; (10) planned subsystem core diagram for Mars observer; (11) SFOC use of public domain/3rd party software; (12) SFOC hardware; (13) SFOC target six mission configuration; and (14) SFOC development status and plans.

Ebersole, M.↗
NASA NTRS1991

The development of a post-test diagnostic system for rocket engines

An effort was undertaken by NASA to develop an automated post-test, post-flight diagnostic system for rocket engines. The automated system is designed to be generic and to automate the rocket engine data review process. A modular, distributed architecture with a generic software core was chosen to meet the design requirements. The diagnostic system is initially being applied to the Space Shuttle Main Engine data review process. The system modules currently under development are the session/message manager, and portions of the applications section, the component analysis section, and the intelligent knowledge server. An overview is presented of a rocket engine data review process, the design requirements and guidelines, the architecture and modules, and the projected benefits of the automated diagnostic system.

Zakrajsek, June F.↗
NASA NTRS1991

The development of a post-test diagnostic system for rocket engines

An effort was undertaken by NASA to develop an automated post-test, post-flight diagnostic system for rocket engines. The automated system is designed to be generic and to automate the rocket engine data review process. A modular, distributed architecture with a generic software core was chosen to meet the design requirements. The diagnostic system is initially being applied to the Space Shuttle Main Engine data review process. The system modules currently under development are the session/message manager, and portions of the applications section, the component analysis section, and the intelligent knowledge server. An overview is presented of a rocket engine data review process, the design requirements and guidelines, the architecture and modules, and the projected benefits of the automated diagnostic system.

Zakrajsek, June F.↗
NASA NTRS2000

X-33 Leading the Way to VentureStar(Trademark) in this Decade

The X-33, reusable space plane technology demonstrator is on course to begin the flights of the X-33 by the end of 2002 that will serve as a basis for industry and government decisions that could lead to VentureStar(Trademark). Lockheed Martin has placed the VentureStar(Trademark) LLC in it's Space Company and is now competing in an industry wide effort that will permit NASA to select a Second Generation RLV source by 2005. This move provides the focus for firm business planning needed to enable the decision by the time X-33 flies in mid 2002 and possibly with upgraded technologies a year or so later. Since the IAF 50th Congress in Amsterdam, most of the major hardware elements of X-33 have been through their assembly and test. The flight liquid oxygen tank was the first major element to complete final assembly. Aerospike Engine qualification testing has progressed successfully through its test objectives and the two flight engines are in preparation to be delivered to the Assembly Facility in Palmdale. All Thermal Protection System (TPS) metallic panels have completed qualification testing and have been delivered to Palmdale and all remaining TPS elements have been assembled and are ready for delivery. Flight Software and Avionics have been delivered and are in integration testing. In November 1999, the first graphite composite liquid hydrogen tank experienced a debond between the tank inner skin and the honeycomb core in testing. This tank had completed its third successful cryogenic and loads testing at MSFC. Replacement liquid hydrogen tanks have completed design and are in fabrication. The resulting delay from this change of design for the liquid hydrogen tank will be approximately two years.

Austin, Robert E.↗