Search NASA⌕ Search

SEARCH · Search NASA

Results for “SARP”

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 37 records · Page 2

Performance of a commercial transport under typical MLS noise environment

The performance of a 747-200 automatic flight control system (AFCS) subjected to typical Microwave Landing System (MLS) noise is discussed. The performance is then compared with the results from a previous study which had a B747 AFCS subjected to the MLS standards and recommended practices (SARPS) maximum allowable noise. A glide slope control run with Instrument Landing System (ILS) noise is also conducted. Finally, a linear covariance analysis is presented.

Ho, J. K.↗

Software Engineering Research/Developer Collaborations (C104)

The goal of this collaboration was to produce Flight Software Branch (FSB) process standards for software inspections which could be used across three new missions within the FSB. The standard was developed by Dr. Forrest Shull (Fraunhofer Center for Experimental Software Engineering, Maryland) using the Perspective-Based Inspection approach, (PBI research has been funded by SARP) , then tested on a pilot Branch project. Because the short time scale of the collaboration ruled out a quantitative evaluation, it would be decided whether the standard was suitable for roll-out to other Branch projects based on a qualitative measure: whether the standard received high ratings from Branch personnel as to usability and overall satisfaction. The project used for piloting the Perspective-Based Inspection approach was a multi-mission framework designed for reuse. This was a good choice because key representatives from the three new missions would be involved in the inspections. The perspective-based approach was applied to produce inspection procedures tailored for the specific quality needs of the branch. The technical information to do so was largely drawn through a series of interviews with Branch personnel. The framework team used the procedures to review requirements. The inspections were useful for indicating that a restructuring of the requirements document was needed, which led to changes in the development project plan. The standard was sent out to other Branch personnel for review. Branch personnel were very positive. However, important changes were identified because the perspective of Attitude Control System (ACS) developers had not been adequately represented, a result of the specific personnel interviewed. The net result is that with some further work to incorporate the ACS perspective, and in synchrony with the roll out of independent Branch standards, the PBI approach will be implemented in the FSB. Also, the project intends to continue its collaboration with the technology provider (Dr. Forrest Shull) past the end of the grant, to allow a more rigorous quantitative evaluation.

Shell, Elaine↗

Mission Operations Insights

The mission description Polar Operational Environmental Satellites (POES): I) Collect and disseminate worldwide meteorological and environmental data: a) Provide day and night information (AVHRR): 1) cloud cover distribution and type; 2) cloud top temperature; 3) Moisture patterns and ice/snow melt. b) Provide vertical temperature and moisture profiles of atmospheres (HIRS, AMSU, MHS. c) Measure global ozone distribution and solar UV radiation (SBUV). d) Measure proton, electro, and charged particle density to provide solar storm warnings (SEM). d) Collect environmental data (DCS): 1) Stationary platforms in remote locations; 2) Free floating platforms on buoys, balloons, migratory animals. II) Provide Search and Rescue capabilities (SARR, SARP): a) Detection and relay of distress signals. b) Has saved thousands of lives around the world.

Littman, Dave↗

Simulation and Performance of Data Communication using AMSS

This paper reports the findings of a simulation of the Aeronautical Mobile Satellite Service (AMSS) to be used in the ATN (Aeronautical Telecommunications Network). The models of the protocols used in this simulation were designed to be compliant with the International Civil Aviation Organization (ICAO) Standards and Recommended Practices (SARP). The focus of this research is on the data communication capabilities of the AMSS. The simulated performance characteristics for a region of the AMSS are presented. The results are analyzed to determine the efficiency, limitations, and behavior of this service for the foreseen data communication

Ripamonti, Claudio↗

Using Sequence Diagrams to Detect Communication Problems Between Systems

Many software systems are evolving complex system of systems (SoS) for which inter-system communication is both mission-critical and error-prone. Such communication problems ideally would be detected before deployment. In a NASA-supported Software Assurance Research Program (SARP) project, we are researching a new approach addressing such problems. In this paper, we show that problems in the communication between two systems can be detected by using sequence diagrams to model the planned communication and by comparing the planned sequence to the actual sequence. We identify different kinds of problems that can be addressed by modeling the planned sequence using different level of abstractions.

Lindvall, Mikael↗

Analyzing and Detecting Problems in Systems of Systems

Many software systems are evolving complex system of systems (SoS) for which inter-system communication is mission-critical. Evidence indicates that transmission failures and performance issues are not uncommon occurrences. In a NASA-supported Software Assurance Research Program (SARP) project, we are researching a new approach addressing such problems. In this paper, we are presenting an approach for analyzing inter-system communications with the goal to uncover both transmission errors and performance problems. Our approach consists of a visualization and an evaluation component. While the visualization of the observed communication aims to facilitate understanding, the evaluation component automatically checks the conformance of an observed communication (actual) to a desired one (planned). The actual and the planned are represented as sequence diagrams. The evaluation algorithm checks the conformance of the actual to the planned diagram. We have applied our approach to the communication of aerospace systems and were successful in detecting and resolving even subtle and long existing transmission problems.

Lindvall, Mikael↗

Survey of Product-line Verification and Validation Techniques

This report presents the results from the first task of the SARP Center Initiative, 'Product Line Verification of Safety-Critical Software.' Task 1 is a literature survey of available techniques for product line verification and validation. Section 1 of the report provides an introduction to product lines and motivates the survey of verification techniques. It describes what is reused in product-line engineering and explains the goal of verifiable conformance of the developed system to its product-line specifications. Section 2 of the report describes six lifecycle steps in product-line verification and validation. This description is based on, and refers to, the best practices extracted from the readings. It ends with a list of verification challenges for NASA product lines (2.7) and verification enablers for NASA product lines (2.8) derived from the survey. Section 3 provides resource lists of related conferences, workshops, industrial and defense industry experiences and case studies of product lines, and academic/industrial consortiums. Section 4 is a bibliography of papers and tutorials with annotated entries for relevant papers not previously discussed in sections 2 or 3.

testing↗

Connecting Research and Practice: An Experience Report on Research Infusion with SAVE

NASA systems need to be highly dependable to avoid catastrophic mission failures. This calls for rigorous engineering processes including meticulous validation and verification. However, NASA systems are often highly distributed and overwhelmingly complex, making the software portion of these systems challenging to understand, maintain, change, reuse, and test. NASA's systems are long-lived and the software maintenance process typically constitutes 60-80% of the total cost of the entire lifecycle. Thus, in addition to the technical challenges of ensuring high life-time quality of NASA's systems, the post-development phase also presents a significant financial burden. Some of NASA's software-related challenges could potentially be addressed by some of the many powerful technologies that are being developed in software research laboratories. Many of these research technologies seek to facilitate maintenance and evolution by for example architecting, designing and modeling for quality, flexibility, and reuse. Other technologies attempt to detect and remove defects and other quality issues by various forms of automated defect detection, architecture analysis, and various forms of sophisticated simulation and testing. However promising, most such research technologies nevertheless do not make the transition from the research lab to the software lab. One reason the transition from research to practice seldom occurs is that research infusion and technology transfer is difficult. For example, factors related to the technology are sometimes overshadowed by other types of factors such as reluctance to change and therefore prohibits the technology from sticking. Successful infusion might also take very long time. One famous study showed that the discrepancy between the conception of the idea and its practical use was 18 years plus or minus three. Nevertheless, infusing new technology is possible. We have found that it takes special circumstances for such research infusion to succeed: 1) there must be evidence that the technology works in the practitioner's particular domain, 2) there must be a potential for great improvements and enhanced competitive edge for the practitioner, 3) the practitioner has to have strong individual curiosity and continuous interest in trying out new technologies, 4) the practitioner has to have support on multiple levels (i.e. from the researchers, from management, from sponsors etc), and 5) to remain infused, the new technology has to be integrated into the practitioner's processes so that it becomes a natural part of the daily work. NASA IV&V's Research Infusion initiative sponsored by NASA's Office of Safety & Mission Assurance (OSMA) through the Software Assurance Research Program (SARP), strives to overcome some of the problems related to research infusion.

Lindvall, Mikael↗

Architectural Analysis of Complex Evolving Systems of Systems

The goal of this collaborative project between FC-MD, APL, and GSFC and supported by NASA IV&V Software Assurance Research Program (SARP), was to develop a tool, Dynamic SAVE, or Dyn-SAVE for short, for analyzing architectures of systems of systems. The project team was comprised of the principal investigator (PI) from FC-MD and four other FC-MD scientists (part time) and several FC-MD students (full time), as well as, two APL software architects (part time), and one NASA POC (part time). The PI and FC-MD scientists together with APL architects were responsible for requirements analysis, and for applying and evaluating the Dyn-SAVE tool and method. The PI and a group of FC-MD scientists were responsible for improving the method and conducting outreach activities, while another group of FC-MD scientists were responsible for development and improvement of the tool. Oversight and reporting was conducted by the PI and NASA POC. The project team produced many results including several prototypes of the Dyn-SAVE tool and method, several case studies documenting how the tool and method was applied to APL s software systems, and several published papers in highly respected conferences and journals. Dyn-SAVE as developed and enhanced throughout this research period, is a software tool intended for software developers and architects, software integration testers, and persons who need to analyze software systems from the point of view of how it communicates with other systems. Using the tool, the user specifies the planned communication behavior of the system modeled as a sequence diagram. The user then captures and imports the actual communication behavior of the system, which is then converted and visualized as a sequence diagram by Dyn-SAVE. After mapping the planned to the actual and specifying parameter and timing constraints, Dyn-SAVE detects and highlights deviations between the planned and the actual behavior. Requirements based on the need to analyze two inter-system communication protocols that are representative of protocols used in the Aerospace industry have been specified. The protocols are related: APL s Common Ground System (CGS) as used in the MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) and the Radiation Belt Space Probes (RBSP) missions. The analyzed communications were implementations of the Telemetry protocol and the CCSDS File Delivery Protocol (CFDP) protocol. Based on these requirements, three prototypes of Dyn-SAVE were developed and applied to these protocols. The application of Dyn-SAVE to these protocols resulted in the detection of several issues. Dyn-SAVE was also applied to several Testbeds that have previously been used for experimentation earlier on this project, as well as, to other protocols and logs for testing its broader applicability. For example, Dyn-SAVE was used to analyze 1) the communication pattern between a web browser and a web server, 2) the system log of a computer in order to detect offnominal computer shut-down behavior, and 3) the actual test cases of NASA Goddard s Core Flight System (CFS) and automatically generated test cases in order to determine the overlap between the two sets of test cases. In all cases, Dyn-SAVE assisted in providing insightful conclusions about each of the cases identified above.

Lindvall, Mikael↗

Fault Management Architectures and the Challenges of Providing Software Assurance

The satellite systems Fault Management (FM) is focused on safety, the preservation of assets, and maintaining the desired functionality of the system. How FM is implemented varies among missions. Common to most is system complexity due to a need to establish a multi-dimensional structure across hardware, software and operations. This structure is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. These architecture, implementation and software assurance efforts increase with mission complexity. Because FM is a systems engineering discipline with a distributed implementation, providing efficient and effective verification and validation (VV) is challenging. A breakout session at the 2012 NASA Independent Verification Validation (IVV) Annual Workshop titled VV of Fault Management: Challenges and Successes exposed these issues in terms of VV for a representative set of architectures. NASA's IVV is funded by NASA's Software Assurance Research Program (SARP) in partnership with NASA's Jet Propulsion Laboratory (JPL) to extend the work performed at the Workshop session. NASA IVV will extract FM architectures across the IVV portfolio and evaluate the data set for robustness, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This work focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures, visibility, and associated VVIVV techniques provides a data set that can enable higher assurance that a satellite system will adequately detect and respond to adverse conditions. Ultimately, results from this activity will be incorporated into the NASA Fault Management Handbook providing dissemination across NASA, other agencies and the satellite community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research including identification of FM architectures, visibility observations, and methods utilized for VVIVV.

Fault Management↗

An Overview of Atmospheric Chemistry and Air Quality Modeling

This presentation will include my personal research experience and an overview of atmospheric chemistry and air quality modeling to the participants of the NASA Student Airborne Research Program (SARP 2017). The presentation will also provide examples on ways to apply airborne observations for chemical transport (CTM) and air quality (AQ) model evaluation. CTM and AQ models are important tools in understanding tropospheric-stratospheric composition, atmospheric chemistry processes, meteorology, and air quality. This presentation will focus on how NASA scientist currently apply CTM and AQ models to better understand these topics. Finally, the importance of airborne observation in evaluating these topics and how in situ and remote sensing observations can be used to evaluate and improve CTM and AQ model predictions will be highlighted.

Atmospheric↗

Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project

Over the past 5 years, the UAS integration into the NAS project has worked to reduce technical barriers to integration. A major focus of this work has been in support of RTCA SC-228. This committee has recently published the first UAS integration minimum performance standards (MOPS). This work has spanned detect and avoid (DAA) as well as command and control comm datalinks. I will discuss DAA efforts with focus on the human systems work. I will discuss how automation was discussed and addressed within this context. ICAO stood up a remotely piloted aircraft systems (RPAS) panel in 2014. They have developed an RPAS manual and are now working to revise existing annexes and standards and recommended practices. The Human In The System (HITS) has worked to infuse human factors guidelines into those documents. I will discuss that effort as well as how ICAO has defined and address autonomy. There is a great deal of interest in the control of multiple vehicles by a single operator. The UAS EXCOM Science and Research Panel (SARP) is holding a workshop on this topic in late June. I will discuss research performed on this topic when I worked for the Army and on-going work within the division and a NATO working group on Human-Autonomy Teaming.

Unmanned Aircraft Systems (UAS)↗

Single Operator Control of Multiple UAS: A Supervisory Delegation Approach

This presentation will be given as part of the UAS EXCOM Science and Research Panel's (SARP) workshop on multiple UAS controlled by a single operator. Participants were asked to identify public use cases for multiple UAS control and identify research, policy and technical gaps in those operations. The purpose of this workshop is to brainstorm, categorize and prioritize those use canses and gaps. Here, I will discuss research performed on this topic when I worked for the Army and on-going work within the division and a NATO working group on Human-Autonomy Teaming.

Human-Autonomy Teaming↗

Single Operator Control of Multiple UAS: A Supervisory Delegation Approach

This presentation will be given as part of the UAS EXCOM Science and Research Panel's (SARP) workshop on multiple UAS controlled by a single operator. Participants were asked to identify public use cases for multiple Unmanned Aircraft Systems (UAS) control and identify research, policy, and technical gaps in those operations. The purpose of this workshop is to brainstorm, categorize, and prioritize those use cases and gaps. Here, I will discuss research performed on this topic when I worked for the Army and on-going work within the division and a NATO working group on Human-Autonomy Teaming.

Unmanned Aircraft Systems (UAS)↗

Security Vulnerability Profiles of NASA Mission Software: Empirical Analysis of Security Related Bug Reports

NASA develops, runs, and maintains software systems for which security is of vital importance. Therefore, it is becoming an imperative to develop secure systems and extend the current software assurance capabilities to cover information assurance and cybersecurity concerns of NASA missions. The results presented in this report are based on the information provided in the issue tracking systems of one ground mission and one flight mission. The extracted data were used to create three datasets: Ground mission IVV issues, Flight mission IVV issues, and Flight mission Developers issues. In each dataset, we identified the software bugs that are security related and classified them in specific security classes. This information was then used to create the security vulnerability profiles (i.e., to determine how, why, where, and when the security vulnerabilities were introduced) and explore the existence of common trends. The main findings of our work include:- Code related security issues dominated both the Ground and Flight mission IVV security issues, with 95 and 92, respectively. Therefore, enforcing secure coding practices and verification and validation focused on coding errors would be cost effective ways to improve mission's security. (Flight mission Developers issues dataset did not contain data in the Issue Category.)- In both the Ground and Flight mission IVV issues datasets, the majority of security issues (i.e., 91 and 85, respectively) were introduced in the Implementation phase. In most cases, the phase in which the issues were found was the same as the phase in which they were introduced. The most security related issues of the Flight mission Developers issues dataset were found during Code Implementation, Build Integration, and Build Verification; the data on the phase in which these issues were introduced were not available for this dataset.- The location of security related issues, as the location of software issues in general, followed the Pareto principle. Specifically, for all three datasets, from 86 to 88 the security related issues were located in two to four subsystems.- The severity levels of most security issues were moderate, in all three datasets.- Out of 21 primary security classes, five dominated: Exception Management, Memory Access, Other, Risky Values, and Unused Entities. Together, these classes contributed from around 80 to 90 of all security issues in each dataset. This again proves the Pareto principle of uneven distribution of security issues, in this case across CWE classes, and supports the fact that addressing these dominant security classes provides the most cost efficient way to improve missions' security. The findings presented in this report uncovered the security vulnerability profiles and identified the common trends and dominant classes of security issues, which in turn can be used to select the most efficient secure design and coding best practices compiled by the part of the SARP project team associated with the NASA's Johnson Space Center. In addition, these findings provide valuable input to the NASA IVV initiative aimed at identification of the two 25 CWEs of ground and flight missions.

vulnerability↗

Using Airborne In-Situ Profiles to Evaluate TCCON Data from Armstrong Flight Research Center

A Fourier Transform Spectrometer (FTS) was deployed to the Armstrong Flight Research Center (AFRC) in Edwards, CA as a member of the Total Carbon Column Observing Network (TCCON) and has now been in operation for over 3 years. The data record from AFRC will be presented as well as airborne validation profiles obtained during the NASA SEAC4RS, SARP, KORUS-AQ, and ATom missions utilizing various NASA aircraft. One of the reasons that the AFRC location was selected is due to its proximity to a highly reflective lakebed, which has proven to be difficult for accurate satellite retrievals. As such, the data from AFRC has been used for OCO-2 calibration. In order for accurate calibration of OCO-2, the validity of the TCCON measurements must be established. To this end, integrated airborne in-situ vertical profiles will be presented and compared with the TCCON FTS measurements, where good agreement has been found.

Iraci, Laura T.↗

Investigating the Impacts of a Separation Standard for UAS Operations in Enroute and Transition Airspace

Unmanned aircraft systems will be required to equip with a detect and avoid system in order to satisfy the federal aviation regulations to remain well clear of other aircraft. To comply with regulations in today’s operations manned aircraft must “see and avoid” other aircraft and use subjective judgment to determine whether those aircraft are well clear. For a detect-and- avoid (DAA) system to satisfy the requirement to stay well clear, a quantitative definition of well clear needs to be defined and evaluated. Definitions for the boundary of well clear have been proposed by the Unmanned Aircraft System (UAS) Executive Committee Science and Research Panel (SaRP) and the Radio Technical Commission for Aeronautics (RTCA) Special Committee 228 on Detect and Avoid Systems. This study investigates the interoperability implications of UAS using proposed well clear definitions as a separation standard for conducting operations in the national airspace system. The first analysis in the study focuses on the effect of variations in well clear definition parameters on the rate of losses of well clear per flight hour. The second analysis considers three well clear definitions and presents the relative state conditions of intruder aircraft as they encroach upon the well clear boundary. The third analysis focuses on the definition of the alerting criteria needed to inform the UAS operator of a potential loss of well clear. All three analyses are conducted in a NAS-wide fast-time simulation environment using UAS aircraft models, proposed UAS missions, and historical air defense radar data to populate the background traffic operating under visual flight rules. The results from the three analyses presented in this study inform the safety case, requirements development, and the operational environment for the DAA minimum operational performance standards.

UAS Seperation Standard↗