Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software 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 199 records · Page 11

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗

NASA quality assurance in an MBSE world

We explore the impact and consequences of the MBSE Value items discussed above and how they impact the disciplines of quality assurance, reliability and maintainability, system safety, and software assurance. We provide insight into how the MBSE modeling tools can be used to define S&MA processes (ideally as a result of Use Case [1] elaboration of processes represented in MagicDraw®), produce S&MA products (ViewEditor output of various items), and represent S&MA disciplines (S&MA inside of MagicDraw). We also provide insight into the degree to which some elements can be directly integrated into a SysML® model and when, as often happens, an interface to some external source must be provided.

Evans, John W.↗

Advanced Multiphysics Thermal-Hydraulics Models for the High Flux Isotope Reactor

Engineering design studies to determine the feasibility of converting the High Flux Isotope Reactor (HFIR) from using highly enriched uranium (HEU) to low-enriched uranium (LEU) fuel are ongoing at Oak Ridge National Laboratory (ORNL). This work is part of an effort sponsored by the US Department of Energy (DOE) Reactor Conversion Program. HFIR is a very high flux pressurized light-water-cooled and moderated flux-trap type research reactor. HFIR s current missions are to support neutron scattering experiments, isotope production, and materials irradiation, including neutron activation analysis. Advanced three-dimensional multiphysics models of HFIR fuel were developed in COMSOL software for safety basis (worst case) operating conditions. Several types of physics including multilayer heat conduction, conjugate heat transfer, turbulent flows (RANS model) and structural mechanics were combined and solved for HFIR s inner and outer fuel elements. Alternate design features of the new LEU fuel were evaluated using these multiphysics models. This work led to a new, preliminary reference LEU design that combines a permanent absorber in the lower unfueled region of all of the fuel plates, a burnable absorber in the inner element side plates, and a relocated and reshaped (but still radially contoured) fuel zone. Preliminary results of estimated thermal safety margins are presented. Fuel design studies and model enhancement continue.

COMSOL↗

SAS4A/SASSYS-1 VERIFICATION AND VALIDATION TEST SUITE

SAS4A/SASSYS-1 is a safety analysis software package already under copyright by Argonne National Laboratory. There is interest from third-party users of the software to gain access to our internal verification and validation test suite. Therefore we are seeking to establish copyright over the test suite, which includes input files and reference results for hundreds of test cases that demonstrate functionality of the software. Making the test suite available to licensed users allows them to utilize the broad range of tests for commercial grade dedication activities needed to qualify the SAS4A/SASSYS-1 software under their own Software Quality Assurance program for use in a regulatory environment (e.g. with the Nuclear Regulatory Commission).

FANNING, THOMAS↗

Autonomy Software: V&V Challenges and Characteristics

The successful operation of unmanned air vehicles requires software with a high degree of autonomy. Only if high level functions can be carried out without human control and intervention, complex missions in a changing and potentially unknown environment can be carried out successfully. Autonomy software is highly mission and safety critical: failures, caused by flaws in the software cannot only jeopardize the mission, but could also endanger human life (e.g., a crash of an UAV in a densely populated area). Due to its large size, high complexity, and use of specialized algorithms (planner, constraint-solver, etc.), autonomy software poses specific challenges for its verification, validation, and certification. -- - we have carried out a survey among researchers aid scientists at NASA to study these issues. In this paper, we will present major results of this study, discussing the broad spectrum. of notions and characteristics of autonomy software and its challenges for design and development. A main focus of this survey was to evaluate verification and validation (V&V) issues and challenges, compared to the development of "traditional" safety-critical software. We will discuss important issues in V&V of autonomous software and advanced V&V tools which can help to mitigate software risks. Results of this survey will help to identify and understand safety concerns in autonomy software and will lead to improved strategies for mitigation of these risks.

Schumann, Johann↗

Proceedings of the Third International Workshop on Proof-Carrying Code and Software Certification

This NASA conference publication contains the proceedings of the Third International Workshop on Proof-Carrying Code and Software Certification, held as part of LICS in Los Angeles, CA, USA, on August 15, 2009. Software certification demonstrates the reliability, safety, or security of software systems in such a way that it can be checked by an independent authority with minimal trust in the techniques and tools used in the certification process itself. It can build on existing validation and verification (V&V) techniques but introduces the notion of explicit software certificates, Vvilich contain all the information necessary for an independent assessment of the demonstrated properties. One such example is proof-carrying code (PCC) which is an important and distinctive approach to enhancing trust in programs. It provides a practical framework for independent assurance of program behavior; especially where source code is not available, or the code author and user are unknown to each other. The workshop wiII address theoretical foundations of logic-based software certification as well as practical examples and work on alternative application domains. Here "certificate" is construed broadly, to include not just mathematical derivations and proofs but also safety and assurance cases, or any fonnal evidence that supports the semantic analysis of programs: that is, evidence about an intrinsic property of code and its behaviour that can be independently checked by any user, intermediary, or third party. These guarantees mean that software certificates raise trust in the code itself, distinct from and complementary to any existing trust in the creator of the code, the process used to produce it, or its distributor. In addition to the contributed talks, the workshop featured two invited talks, by Kelly Hayhurst and Andrew Appel. The PCC 2009 website can be found at http://ti.arc.nasa.gov /event/pcc 091.

Ewen, Denney, W.↗

Risk-based Classification of Incidents

As the penetration of software into safety-critical systems progresses, accidents and incidents involving software will inevitably become more frequent. Identifying lessons from these occurrences and applying them to existing and future systems is essential if recurrences are to be prevented. Unfortunately, investigative agencies do not have the resources to fully investigate every incident under their jurisdictions and domains of expertise and thus must prioritize certain occurrences when allocating investigative resources. In the aviation community, most investigative agencies prioritize occurrences based on the severity of their associated losses, allocating more resources to accidents resulting in injury to passengers or extensive aircraft damage. We argue that this scheme is inappropriate because it undervalues incidents whose recurrence could have a high potential for loss while overvaluing fairly straightforward accidents involving accepted risks. We then suggest a new strategy for prioritizing occurrences based on the risk arising from incident recurrence.

Greenwell, William S.↗

Growing the NASA Safety and Mission Assurance (SMA) Workforce of Tomorrow

The NASA Safety Center (NSC) was established in2006 in response to Columbia Accident Investigation Board (CAIB) recommendations to strengthen NASA’s safety program. The NSC supports all NASA centers and facilities. The NSC fosters world-class Safety and Mission Assurance (SMA) support for NASA programs and projects through professional development activities and the advancement of the following SMA technical disciplines: - Aviation Safety - Operational Safety - Quality Engineering - Reliability and Maintainability - SMA Technical Leadership - Software Assurance - System Safety The NSC’s Technical Excellence Office (TEO) is charged with encouraging technical excellence in NASA’s SMA community primarily through professional development products and services. TEO’s first initiative was the SMA Technical Excellence Program (STEP). STEP is a career-oriented, professional development roadmap for safety professionals, which is designed for the employee to learn specific knowledge and skills to improve performance in their current role.

Safety and Mission Assurance↗

Software Error Incident Categorizations in Aerospace

Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes historic aerospace software errors to determine trends of how and where automation is most likely to fail. A distinction between software producing wrong (erroneous) output versus no output (fail-silent) is introduced. Of the historical incidents analyzed, 87% were from software acting unexpectedly rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and only partially effective for silent software. Errors were traced back to the software logic itself in 62% of cases, 13% within configurable data, and 25% introduced through input. Thirty percent (30%) of unexpected software behavior was caused by the absence of software and 20% was due to “unknown-unknowns”. These findings indicate that to achieve fault tolerance in safety-critical systems, backup strategies must be employed to detect and respond to erroneous software behavior beyond only fail-silent cases, and robust off-nominal testing should be performed to uncover unanticipated situations.

Software↗

Finite-Test-Case Development to Demonstrate Logical Integrity of Software in DRPS

Reactor protection system (RPS) in nuclear power plant (NPP) is in the process of digitalization in response to advanced features of digital systems. In this context, software integrity in the RPS becomes an important issue since it may cause common-cause failure. Therefore, to guarantee the safety of NPPs, the integrity of the software need to be properly demonstrated or assessed. There are three typical approaches for software reliability quantification: software reliability growth model (SRGM), Bayesian belief network (BBN), and test-based method. Basically, SRGM is difficult to apply to the safety-critical software because not only sufficient failure sets are unavailable but consequence of system failure is also unacceptable. Then the result obtained through the BBN model may have large uncertainty, so it produces difficulties in integrity demonstration of safety-critical software. Thus, the BBN result need to be complemented or verified by test-based method. Currently, for the integrity demonstration of safety-critical software, black-box test which feeds inputs and examines just outputs whether they succeeded or failed is considered based on trajectory-form-of-input (a series of successive values for the input variables that occur during the operation of the software over time). Usually these trajectory-inputs are randomly sampled from operational profile. In this approach, however, there are some practical difficulties. Therefore, we proposed a new test method for safety-critical software in digitalized reactor protection system (DRPS). The main contents described in this paper are about basic concepts under development of finite-test-cases by which the integrity of the software logic can be verified. It should be noted that the influence of the environments, such as operating system and other hardware, are not considered since the method focuses on software logic only. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Measurement and Controls Data Acquisition System

Measurement and Controls Data Acquisition System (MCDAS) is an application program that integrates the functions of two stand-alone programs: one for acquisition of data, the other for controls. MCDAS facilitates and improves testing of complex engineering systems by helping to perform calibration and setup of test systems and acquisition, dissemination, and processing of data. Features of MCDAS include an intuitive, user-friendly graphical user interface, a capability for acquiring data at rates greater than previously possible, cooperation between the data-acquisition software subsystem and alarm-checking and analytical components of the control software subsystem, and a capability for dissemination of data through fiber optics and virtual and wide-area networks, including networks that contain hand-held display units. The integration of the data acquisition and control software offers a safety advantage by making alarm information available to the control software in a more timely manner. By enabling the use of hand-held devices, MCDAS reduces the time spent by technicians asking for screen updates to determine effects of setup actions. Previously recorded data can be processed without interruption to current acquisition of data. Analysts can continue to view test parameters while test-data files are being generated.

Hall, Rick↗

SU-E-T-599: Patient Safety Enhancements Through a Study of R&V System Override Data

Purpose: Record and verify (R&V) software systems include safety checks that compare actual machine parameters with prescribed values for a patient’s treatment, such as treatment couch position, linac, energy, and MUs. The therapist is warned of a mismatch with a pop-up and prompted to approve an override in order to continue without changes. Override approval is often legitimate, but the pop-up can also genuinely indicate a problem that would Result in the wrong treatment. When there are numerous pop-up warnings, human nature leads us to approve any override without careful reading, undermining the effectiveness of the safety mechanism. Methods: Override data was collected from our R&V system for all patients treated between October 8 and 29, 2012, on four linacs and entered into a spreadsheet. Additional data collected included treatment technique, disease site, immobilization, time, linac, and whether localization images were obtained. Data were analyzed using spreadsheet tools to reveal trends, patterns and associations that might suggest appropriate process changes that could decrease the total number of overrides. Results: 76 out of 113 patients had overrides. Out of the 944 treatments, 599 override items were generated. The majority were due to couch positions. 74 of the 84 overrides on a linac equipped with a 6D couch were due to the use of the rotational corrections and the fact that the 6D couch control does not communicate with the R&V system; translations required to rotate the couch appear to the R&V system as translations outside the tolerance range. Conclusion: Many findings were interesting but did not suggest a process change. Proposed process changes include creating site-specific instead of just technique-specific tolerance tables for couch shifts. Proposed improvements to the vendor are to facilitate direct communication between the 6D couch and the R&V system to eliminate those override warnings related to lack of communication.

61 RADIATION PROTECTION AND DOSIMETRY↗

Software Dependability

The purpose of this paper is to provide a brief introduction of Software Dependability and a summary of lessons learned. The components of Software Dependability vary among standards, however there is agreement among the standards that reliability, availability and maintainability are some the main components of dependability. Safety is also a main component is safety systems. Although reliability and safety are similar there is an additional difference, safety can withstand some level of fault tolerance. For the purposes of this discussion Software Dependability includes reliability, availability, maintainability and safety. Software Dependability: Trustworthiness of a computer system such that reliance can be justifiably placed on the service it delivers. Reliability, availability, and maintainability are aspects of dependability. Reliability: The ability of a system or component to perform its required functions under stated conditions for a specified period of time. Availability: The degree to which a system or component is operational and accessible when required for use. Often expressed as a probability. Maintainability: Speed and ease with which a program can be corrected or changed. Safety: a measure of the length of time the software system can be expected to run before failing in such a way as to cause a system hazard. (author)

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Retrospectively Documenting Satisfaction of the Overarching Properties: An Exploratory Prototype

Software-intensive aviation systems are typically developed in accordance with recognized development process, safety analysis, and software development standards such as SAE ARP4754A, SAE ARP4761, and RTCA DO-178C. Efforts to streamline assurance processes and make them flexible enough to handle future assurance challenges have produced the Overarching Properties (OPs) for airworthiness approval. Each of the three OPs is a property systems must possess to be certifiable. There is no mandated means of documenting possession of the OPs. To explore possible means, we have prepared retrospective documentation showing that a specimen software system possesses the OPs. The specimen system, Safeguard, enforces geofencing restrictions on unmanned aerial vehicles. Our OP-possession case for its airborne component comprises eight arguments in the Goal Structuring Notation (GSN): a main argument for each OP and five cross-cutting auxiliary arguments. We present this argument as an example for discussion and further research, e.g., into means of assessing OP possession.

safety case↗

lmprovements and Path Forward for Regulatory Acceptance of SAS4A/SASSYS-1

In the U.S., a key component of the commercialization of advanced reactors is completion of a license application, which must ultimately be approved by the Nuclear Regulatory Commission (NRC). The NRC’s approval of the license application is contingent on, among other things, satisfactory demonstration of the design basis and response to transient and accident scenarios using accepted codes and methods. This effort seeks to improve the regulatory acceptability of the SAS4A/SASSYS-1 advanced reactor design and safety analysis system software by identifying and addressing gaps in the SAS4A/SASSYS-1 documentation basis that support software qualification and dedication. The software’s unique capabilities to assess inherent fast spectrum feedback effects and passive safety features, which facilitate assessment of key safety metrics, position it as a key licensing tool in the field of sodium-cooled fast reactors (SFR).

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

V & V Within Reuse-Based Software Engineering

Verification and validation (V&V) is used to increase the level of assurance of critical software, particularly that of safety-critical and mission critical software. This paper describes the working group's success in identifying V&V tasks that could be performed in the domain engineering and transition levels of reuse-based software engineering. The primary motivation for V&V at the domain level is to provide assurance that the domain requirements are correct and that the domain artifacts correctly implement the domain requirements. A secondary motivation is the possible elimination of redundant V&V activities at the application level. The group also considered the criteria and motivation for performing V&V in domain engineering.

Addy, Edward A.↗