Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software engineering safety”

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 217 records · Page 12

Hot gas ingestion effects on fuel control surge recovery and AH-1 rotor drive train torque spikes

This report summarizes the work accomplished through computer simulation to understand the impact of the hydromechanical turbine assembly (TA) fuel control on rocket gas ingestion induced engine surges on the AH-1 (Cobra) helicopter. These surges excite the lightly damped torsional modes of the Cobra rotor drive train and can cause overtorqueing of the tail rotor shaft. The simulation studies show that the hydromechanical TA control has a negligible effect on drive train resonances because its response is sufficiently attenuated at the resonant frequencies. However, a digital electronic control working through the TA control's separate, emergency fuel metering system has been identified as a solution to the overtorqueing problem. State-of-the-art software within the electronic control can provide active damping of the rotor drive train to eliminate excessive torque spikes due to any disturbances including engine surges and aggressive helicopter maneuvers. Modifications to the existing TA hydromechanical control are relatively minor, and existing engine sensors can be utilized by the electronic control. Therefore, it is concluded that the combination of full authority digital electronic control (FADEC) with hydromechanical backup using the existing TA control enhances flight safety, improves helicopter performance, reduces pilot workload, and provides a substantial payback for very little investment.

Tokarski, Frank↗

Evolution of safety-critical requirements post-launch

This paper reports the results of a small study of requirements changes to the onboard software of three spacecraft subsequent to launch. Only those requirement changes that resulted from post-launch anoma-lies (i.e., during operations) were of interest here, since the goal was to better understand the relation-ship between critical anomalies during operations and how safety-critical requirements evolve. The results of the study were surprising in that anomaly-driven, post-launch requirements changes were rarely due to previous requirements having been incorrect. Instead, changes involved new requirements (1) for the software to handle rare events or (2) for the software to compensate for hardware failures or limitations. The prevalence of new requirements as a result of post-launch anomalies suggests a need for increased requirements-engineering support of maintenance activities in these systems. The results also confirm both the difficulty and the benefits of pursuing requirements completeness, especially in terms of fault tolerance, during development of critical systems.

Software requirements↗

Fault Propagation, EMI Propagation, and Fault Containment in Aerospace Systems

The occurrence of faults in aerospace system hardware and software have consequences ranging from minor effects to catastrophic effects, and such faults can directly affect the safety of hardware and personnel. There are many origins to fault conditions, and the hardware that is capable of still meeting its performance requirements after experiencing itself a fault is said to be fault tolerant. A fault tolerant hardware is capable of detecting, isolating, and recovering from a fault condition; and this is a subfield of control engineering. An aerospace system that has been shown to have electromagnetic compatibility (EMC) in all its subsystems and systems cannot induced faults caused by electromagnetic interference (EMI). It can be proposed that the presence of EMI (or lack of EMC) is analogous to a potential fault initiator and the effects can likewise range from minor to severe. This paper starts by addressing the consequences of hardware failure in aerospace systems from a fault perspective, because the design of fault tolerant system is a major endeavor in aerospace. To arrive to this goal the paper starts with the concepts of fault, fault propagation, and a new concept called fault containment region. The paper then proceeds to provide two very recent examples in the aircraft industry of fault propagation with catastrophic effects. The paper proceeds to introduce the concept of EMI fault containment and a brief introduction to another new concept called the EMI containment region. The paper proceeds with an example of EMI fault containment region. The paper ends with a lesson learned conclusions.

Perez, Reinaldo↗

Hardware interface for isolation of vibrations in flexible manipulators: Development and applications

NASA's Langley Research Center (LaRC) is addressing the problem of isolating the vibrations of the Shuttle remote manipulator system (RMS) from its end-effector and/or payload by modeling an RMS flat-floor simulator with a dynamic payload. Analysis of the model can lead to control techniques that will improve the speed, accuracy, and safety of the RMS in capturing satellites and eventually facilitate berthing with the space station. Rockwell International Corporation, also involved in vibration isolation, has developed a hardware interface unit to isolate the end-effector from the vibrations of an arm on a Shuttle robotic tile processing system (RTPS). To apply the RTPS isolation techniques to long-reach arms like the RMS, engineers have modeled the dynamics of the hardware interface unit with simulation software. By integrating the Rockwell interface model with the NASA LaRC RMS simulator model, investigators can study the use of a hardware interface to isolate dynamic payloads from the RMS. The interface unit uses both active and passive compliance and damping for vibration isolation. Thus equipped, the RMS could be used as a telemanipulator with control characteristics for capture and berthing operations. The hardware interface also has applications in industry.

Manouchehri, Davoud↗

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↗

Resilient Space Habitat Design Using Safety Controls

Space habitats will involve a complex and tightly coupled combination of hardware, software, and humans, while operating in challenging environments that pose many risks, both known and unknown. It will not be possible to design habitats that are immune to failure, nor will it be possible to foresee all possible failures. Rather than aiming for designs where ―failure is not an option,‖ habitats must be resilient to disruptions. We propose an approach to resilient design for space habitats based on the concept of safety controls from system safety engineering. We model disruptions using a state-and-trigger approach, where the space habitat is in one of three distinct states at each time instance: nominal, hazardous, or accident. We use safety controls as ways of preventing a system from entering or remaining in a hazardous or accident state. We develop a safety control option space for the habitat, from which designers can select the set of safety controls that best meet resilience, performance, and other system goals. The safety control option space is likely to be large, accordingly, we design a database that links safety controls to the applicable states and triggers. We demonstrate our approach on the early design stage of a Martian space habitat.

Safety↗

Multimission Telemetry Visualization (MTV) system: A mission applications project from JPL's Multimedia Communications Laboratory

This paper describes the Multimission Telemetry Visualization (MTV) data acquisition/distribution system. MTV was developed by JPL's Multimedia Communications Laboratory (MCL) and designed to process and display digital, real-time, science and engineering data from JPL's Mission Control Center. The MTV system can be accessed using UNIX workstations and PC's over common datacom and telecom networks from worldwide locations. It is designed to lower data distribution costs while increasing data analysis functionality by integrating low-cost, off-the-shelf desktop hardware and software. MTV is expected to significantly lower the cost of real-time data display, processing, distribution, and allow for greater spacecraft safety and mission data access.

Koeberlein, Ernest, III↗

Learning the Task Management Space of an Aircraft Approach Model

Validating models of airspace operations is a particular challenge. These models are often aimed at finding and exploring safety violations, and aim to be accurate representations of real-world behavior. However, the rules governing the behavior are quite complex: nonlinear physics, operational modes, human behavior, and stochastic environmental concerns all determine the responses of the system. In this paper, we present a study on aircraft runway approaches as modeled in Georgia Tech's Work Models that Compute (WMC) simulation. We use a new learner, Genetic-Active Learning for Search-Based Software Engineering (GALE) to discover the Pareto frontiers defined by cognitive structures. These cognitive structures organize the prioritization and assignment of tasks of each pilot during approaches. We discuss the benefits of our approach, and also discuss future work necessary to enable uncertainty quantification.

Validation↗

A Tool for the Automated Design and Evaluation of Habitat Interior Layouts

The objective of space habitat design is to minimize mass and system size while providing adequate space for all necessary equipment and a functional layout that supports crew health and productivity. Unfortunately, development and evaluation of interior layouts is often ignored during conceptual design because of the subjectivity and long times required using current evaluation methods (e.g., human-in-the-loop mockup tests and in-depth CAD evaluations). Early, more objective assessment could prevent expensive design changes that may increase vehicle mass and compromise functionality. This paper describes a new interior design evaluation method to enable early, structured consideration of habitat interior layouts. This interior layout evaluation method features a comprehensive list of quantifiable habitat layout evaluation criteria, automatic methods to measure these criteria from a geometry model, and application of systems engineering tools and numerical methods to construct a multi-objective value function measuring the overall habitat layout performance. In addition to a detailed description of this method, a C++/OpenGL software tool which has been developed to implement this method is also discussed. This tool leverages geometry modeling coupled with collision detection techniques to identify favorable layouts subject to multiple constraints and objectives (e.g., minimize mass, maximize contiguous habitable volume, maximize task performance, and minimize crew safety risks). Finally, a few habitat layout evaluation examples are described to demonstrate the effectiveness of this method and tool to influence habitat design.

Simon, Matthew A.↗

Fault Management Architectures and the Challenges of Providing Software Assurance

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 missions is system complexity due to a need to establish a multi-dimensional structure across hardware, software and spacecraft operations. FM is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. Generally, FM 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 (V&V) is challenging. A breakout session at the 2012 NASA Independent Verification & Validation (IV&V) Annual Workshop titled "V&V of Fault Management: Challenges and Successes" exposed this issue in terms of V&V for a representative set of architectures. NASA's Software Assurance Research Program (SARP) has provided funds to NASA IV&V to extend the work performed at the Workshop session in partnership with NASA's Jet Propulsion Laboratory (JPL). NASA IV&V will extract FM architectures across the IV&V portfolio and evaluate the data set, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This SARP initiative focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures and associated V&V/IV&V techniques provides a data set that can enable improved assurance that a 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 space community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research.

Fault Management↗

SpaceVPX Interoperability Assessment

The existing VMEbus (VersaModular Eurocard bus) International Trade Association (VITA)-78 industry standard, also known as SpaceVPX, is an avionics board- and chassis-level standard derived from the OpenVPX standard as defined in VITA-65. While VITA-65 defines backplane and board-level profiles from COTS vendors to ensure interoperability of products used in developing systems and subsystems, the VITA-78 standard defines SpaceVPX to incorporate fault tolerance features that are required by many spaceflight systems. However, VITA-78 allows so much flexibility that interoperability between modules cannot be assured. This assessment provides guidelines on the use of, and extensions to, the VITA-78 standard to enable avionics interoperability for future NASA missions. The assessment team was comprised of subject matter experts (SMEs) from Goddard Space Flight Center (GSFC), the Jet Propulsion Laboratory (JPL), Johnson Space Center (JSC), and Langley Research Center (LaRC). The team included valuable external consulting support from a SME who was a key participant in the development of the VITA-78 standard. The team had extensive collaboration with the NASA Space Technology Mission Directorate (STMD) High Performance Spaceflight Computing (HPSC) project, specifically in the development of SpaceVPX interconnect findings, observations, and NESC recommendations. To provide an understanding of the breadth of implementations that SpaceVPX must accommodate, multiple NASA use cases were analyzed to assess the requirements for SpaceVPX implementations across a wide range of NASA missions (Appendix C). Applications included crewed missions, science missions, and orbital and surface robotic systems. Product surveys were conducted to assess the level of industry support for SpaceVPX, applications, and the variations in their implementations (Appendix D). In-depth analysis was conducted in the areas of: (a) power management and distribution, (b) form factors and daughtercards, (c) interconnect, and (d) fault tolerance. Leveraging the use cases, product surveys, and SMEs from multiple NASA Centers, these areas were analyzed to determine the range of implementations permitted by the VITA-78 standard and potential interoperability issues. Applicable findings and NESC recommendations were provided for each area. During this assessment, there were multiple opportunities to engage with other agencies to learn about their interest in SpaceVPX, their strategies for implementing SpaceVPX-based systems, and their internal development efforts. These engagements also generated findings and NESC recommendations. Based on this assessment analysis, NESC recommendations were made regarding the feature set and module profiles to support NASA SpaceVPX implementations. This feature set includes restrictions on features in VITA-78, and extensions to the standard. Key recommendations in this area include the use of 10 Gigabit Ethernet and Peripheral Component Interconnect Express (PCIe) as high bandwidth interconnect on the backplane, the retention of SpaceWire interconnect for control functions, and support for 3U (unit) and 6U, form factors for NASA systems. Restrictions were proposed on the usage of user-defined signals to promote interoperability, and specific power managements and distribution schemes for 3U systems. Beyond the technical implementation of SpaceVPX, recommendations were made on areas that warrant further investigation. Primary among these is the recommendation for NASA to collaborate with other space-going agencies and industry to incorporate recommendations into a future ‘dot spec’ of VITA-78. This would ensure wide adoption and availability of the modules that comply with the specification. The assessment includes appendices with candidate module profiles that can be considered as a starting point for this activity, and example systems based on the recommendations. Follow-on studies are recommended for architectures beyond SpaceVPX to address potential enhancements including condensed set of interconnect, software required to implement protocol layers on the interconnect (and other features), alternative power architectures, and system-level testability.

SpaceVPX↗

Chapter 12 - Flight Envelope

The term "flight envelope" is used to refer to the boundaries of aircraft loading and flight conditions within which operation of the aircraft is satisfactory, and beyond which some aspect becomes unacceptable. This flight envelope represents, in fact, the limiting conditions arising from a matrix of inter-related flight envelopes covering the appropriate variables. Thus, for each loading (i.e., external stores configuration and its associated range of weight and center of gravity (c.g.) position) and aircraft configuration (i.e., position of undercarriage (u/c), flaps, slats, etc.), the envelopes of airspeed versus altitude, airspeed versus load factor, angle of attack versus angle of sideslip, etc., must be investigated to establish the limits within which all aspects such as handling qualities, engine behavior, structural loads, etc., remain acceptable. Flight testing of new or derivative aircraft models is carried out with the initial purpose of defining a flight envelope which is, first and foremost, safe and secondarily, which enables the effective use of the vehicle for its intended purpose. Flight testing occurs only after numerous reviews of the design and review of results from ground tests and predictions of flight characteristics in such areas as structures, aerodynamics, stability and control, flight controls (particularly fly-by-wire control systems, propulsion, etc.). Accordingly, opening and expanding the envelope is a task that must be approached cautiously, systematically, and with coordination and cooperation of the many disciplines involved in the design and test of an airplane. (Sections 8 and 10 cover test planning and safety of flight considerations, respectively). The fundamental tenet in establishing a flight envelope via flight test is risk reduction. This is reflected in the typical sequence of events leading to initial flight test - design reviews (both hardware and software), then ground test involving singular disciplines (windtunnel tests for aerodynamics, structurally loading the wing/fuselage/nacelle on a ground test article with loads anticipated to occur in flight, flight control system control law checkout, propulsion test cell runs and/or flying test bed tests, etc.), and then ground tests involving multi-disciplines (See Section 9). Only after these have been accomplished will an initial, limited, low-risk, flight envelope be established. The limited envelope will typically be in the middle of the projected final flight envelope. Subsequent flight tests will then be devoted to expanding the initial envelope by operating the airplane at increasing ranges - representing increasing risk - of engine operation, airspeeds both fast and slow, altitude, load factor both above and below 1g, centers of gravity (fore and aft), and with system/subsystem failures. Whether flight tests are to define a flight envelope on a new model airplane with the attendant new airframe, new engine(s), and new subsystems (hydraulics, pressurization, etc.), or on an airplane involving only a few of these areas such as new engines in an old airframe, the fundamental approach to establishing an envelope is the same.

H Walgemoed↗

A Software Safety Risk Taxonomy for Use in Retrospective Safety Cases

Safety standards contain technical and process-oriented safely requirements. The best time to include these requirements is early in the development lifecycle of the system. When software safety requirements are levied on a legacy system after the fact, a retrospective safety case will need to be constructed for the software in the system. This can be a difficult task because there may be few to no art facts available to show compliance to the software safely requirements. The risks associated with not meeting safely requirements in a legacy safely-critical computer system must be addressed to give confidence for reuse. This paper introduces a proposal for a software safely risk taxonomy for legacy safely-critical computer systems, by specializing the Software Engineering Institute's 'Software Development Risk Taxonomy' with safely elements and attributes.

Hill, Janice L.↗

Model Based Engineering for Software Assurance

NASA's successful development of next generation space vehicles, habitats, and robotic systems will require reliable hardware and software systems. The aim of this initiative is to develop modeling methodology and tools to support Model-Based Systems Engineering (MBSE) for software assurance and reliability analysis. This effort expands the Unified Modeling Language (UML) software design models to include fault data for the extraction of Failure Modes and Effects Criticality Analysis (FMECA) and Fault Tree Analysis (FTA) for software. We explored different modeling approaches to integrate the UML software design models with the Systems Modeling Language (SysML) system models to generate an integrated model and reliability tools that take into account software and hardware interfaces.The benefits of this concept directly affect the safety community with quick turnarounds to produce software assurance and reliability analysis artifacts and the ability to visualize failure effects, both hardware and software. The result is enhanced system design integrity and early identification of system risks. This initiative will enable software assurance activities early in the system design lifecycle, facilitating the discovery of design weaknesses and enhancing the capability to produce safe, hazard-free systems

Wang, Lui↗

NASA's approach to flight confidence

NASA's confidence in the flight readiness of aerospace hardware and software is achieved by a thorough integration of safety activities into every program facet, from concept through the mission. This involves technical and administrative personnel, organizations that specify requirements, design, manufacturing, test and the operators. Reviews by inhouse and external specialists form an integral part of the assurance process. Examples of safety issues and their resolution for some power and propulsion functions are given (lithium cells, autoignition/fretting in high pressure oxygen environments, ignition sources from auxiliary power unit, and low thrust rocket engines). Finally, some comments on NASA's integrated safety activities and the Aerospace Safety Advisory Panel's role in the NASA review and assessment process all of which provides added confidence in achieving a high level of mission safety and success.

Roth, G. L.↗

A Fully Automated Approach to Requirement Extraction from Design Documents

Design documents are intended to outline the goalsof a system or project, which are utilized in the creation ofspecific software requirements. At the NASA Jet PropulsionLaboratory, California Institute of Technology, Functional DesignDescription (FDD) documents describe the scope of theproject and reflect the design and implementation of the system.The specifications in the document are not explicitly writtenas requirements, though these guidelines must be reflected inthe official software requirements. In this work we present afully automatic approach to extracting software requirementsfrom design documents as well as comparing the extractedrequirements to those that exist in the official software requirementdatabase. We do this through (1) sentence extractionfrom the design document, (2) the incorporation of coreferenttext, and (3) aligning the extracted text to the official softwarerequirements. Via natural language processing and informationretrieval techniques, our system results in an automated processthat ensures that the specifications in the design document resultin official software requirements. We find that extraction ofimperatives results in a recall rate of 0.73 and the TF-IDF cosinesimilarity metric is shown to be a useful and successful way tocompare requirements.Though there has been recent work investigating the usefulnessof natural language processing techniques in requirement engineering,this has not been made use of in the aerospace industry.Aerospace requirement engineering is a field particularly ripefor this type of innovation because these techniques can bothautomate some of needlessly manual work and contribute toaerospace safety practices by identifying issues that a humanmay miss. We present the first fully automated approach thatextracts requirements from a design document and comparesthem to a database, and use these findings as encouragementfor future work that makes use of natural language processingtechniques in aerospace requirement engineering.

Briggs, Paul↗

Status of Venus Global Reference Atmospheric Model (Venus-GRAM) Upgrades

Venus-GRAM Overview - Engineering-oriented atmospheric model that estimates mean values and statistical variations of Venus atmospheric properties - Outputs include atmospheric density, temperature, pressure, chemical composition, and wind components along a user-defined path - Widely used by the engineering community because of its ability to create realistic atmospheric dispersions - Can be integrated into high fidelity flight dynamic simulations of launch, entry, descent and landing (EDL), aerobraking and aerocapture - Has been used in multiple studies and proposals including NASA Engineering and Safety Center (NESC) Autonomous Aerobraking Study and various Discovery proposals - Optional trajectory input file consisting of time, height, latitude, and longitude can be used to provide the Venus-GRAM trajectory path - Optional auxiliary profile consisting of height, latitude, longitude, temperature, pressure, density, eastward wind, and northward wind may be used to replace model data in Venus-GRAM - Not a forecast model - GRAMs are also available for Earth, Mars, Titan, Neptune, Uranus, and Jupiter - Available through the NASA Software Catalog https://software.nasa.gov/software/MFS-33888-1

atmospheric models↗

Automating Bug Report Classification with Few Shot Learning

Orthogonal defect classification (ODC) is a method used to categorize software defects, providing valuable insights into the development process. This study focuses on automating the classification of software bug reports into different ODC defect types using few shot learning, a machine learning approach that requires minimal labeled data. Previous research has manually classified bug reports or used traditional machine learning algorithms like linear support vector machine, achieving limited success. Our approach uses few shot learning to improve classification accuracy and efficiency. The results show a harmonic mean of recall and precision (i.e., the F1 score) of around 0.6 which is a performance improvement over previous methods. The results highlight the potential benefit of few shot learning techniques and their application in enhancing the safety and reliability of nuclear digital instrumentation and control (DI&C) systems. Future work will explore incorporating advanced techniques to supplement the model's training data and achieve better results.

42 - ENGINEERING↗