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 145 records · Page 8

Formal Safety Certification of Aerospace Software

In principle, formal methods offer many advantages for aerospace software development: they can help to achieve ultra-high reliability, and they can be used to provide evidence of the reliability claims which can then be subjected to external scrutiny. However, despite years of research and many advances in the underlying formalisms of specification, semantics, and logic, formal methods are not much used in practice. In our opinion this is related to three major shortcomings. First, the application of formal methods is still expensive because they are labor- and knowledge-intensive. Second, they are difficult to scale up to complex systems because they are based on deep mathematical insights about the behavior of the systems (t.e., they rely on the "heroic proof"). Third, the proofs can be difficult to interpret, and typically stand in isolation from the original code. In this paper, we describe a tool for formally demonstrating safety-relevant aspects of aerospace software, which largely circumvents these problems. We focus on safely properties because it has been observed that safety violations such as out-of-bounds memory accesses or use of uninitialized variables constitute the majority of the errors found in the aerospace domain. In our approach, safety means that the program will not violate a set of rules that can range for the simple memory access rules to high-level flight rules. These different safety properties are formalized as different safety policies in Hoare logic, which are then used by a verification condition generator along with the code and logical annotations in order to derive formal safety conditions; these are then proven using an automated theorem prover. Our certification system is currently integrated into a model-based code generation toolset that generates the annotations together with the code. However, this automated formal certification technology is not exclusively constrained to our code generator and could, in principle, also be integrated with other code generators such as RealTime Workshop or even applied to legacy code. Our approach circumvents the historical problems with formal methods by increasing the degree of automation on all levels. The restriction to safety policies (as opposed to arbitrary functional behavior) results in simpler proof problems that can generally be solved by fully automatic theorem proves. An automated linking mechanism between the safety conditions and the code provides some of the traceability mandated by process standards such as DO-178B. An automated explanation mechanism uses semantic markup added by the verification condition generator to produce natural-language explanations of the safety conditions and thus supports their interpretation in relation to the code. It shows an automatically generated certification browser that lets users inspect the (generated) code along with the safety conditions (including textual explanations), and uses hyperlinks to automate tracing between the two levels. Here, the explanations reflect the logical structure of the safety obligation but the mechanism can in principle be customized using different sets of domain concepts. The interface also provides some limited control over the certification process itself. Our long-term goal is a seamless integration of certification, code generation, and manual coding that results in a "certified pipeline" in which specifications are automatically transformed into executable code, together with the supporting artifacts necessary for achieving and demonstrating the high level of assurance needed in the aerospace domain.

Denney, Ewen↗

TU-FG-201-07: Development of SRS Conical Collimator Collision Prediction Software for Radiation Treatment Safety

Purpose: Stereotactic radiosurgery (SRS) treatments using conical collimators can potentially result in gantry collision with treatment table due to limited collision-clear spaces. An in-house software was developed to help the SRS treatment planner mitigate potential SRS conical collimator (Varian Medical System, Palo Alto, CA) collisions with the treatment table. This software was designed to remove treatment re-planning secondary to unexpected collisions. Methods: A BrainLAB SRS ICT Frameless Extension used for SRS treatments in our clinic was mathematically modelled using surface points registered to the 3D co-ordinate space of the couch extension. The surface points are transformed based on the treatment isocenter point and potential collisions are determined in 3D space for couch and gantry angle combinations. The distance between the SRS conical collimators and LINAC isocenter is known. The collision detection model was programmed in MATLAB (Mathwork, Natick, MA) to display graphical plots of the calculations, and the plotted data is used to avoid the gantry and couch angle combinations that would likely result in a collision. We have utilized the cone collision tool for 23 SRS cone treatment plans (8 retrospective and 15 prospective for 10 patients). Results: Twenty one plans strongly agreed with the software tool prediction for collision. However, in two plans, a collision was observed with a 0.5 cm margin when the software predicted no collision. Therefore, additional margins were added to the clearance criteria in the program to achieve a lower risk of actual collisions. Conclusion: Our in-house developed collision check software successfully avoided SRS cone re-planning by 91.3% due to a reduction in cone collisions with the treatment table. Future developments to our software will include a CT image data set based collision prediction model as well as a beam angle optimization tool to avoid normal critical tissues as well as previously treated lesions.

60 APPLIED LIFE SCIENCES↗

Global Precipitation Measurement (GPM) Safety Inhibit Timeline Tool

The Global Precipitation Measurement (GPM) Observatory is a joint mission under the partnership by National Aeronautics and Space Administration (NASA) and the Japan Aerospace Exploration Agency (JAXA), Japan. The NASA Goddard Space Flight Center (GSFC) has the lead management responsibility for NASA on GPM. The GPM program will measure precipitation on a global basis with sufficient quality, Earth coverage, and sampling to improve prediction of the Earth's climate, weather, and specific components of the global water cycle. As part of the development process, NASA built the spacecraft (built in-house at GSFC) and provided one instrument (GPM Microwave Imager (GMI) developed by Ball Aerospace) JAXA provided the launch vehicle (H2-A by MHI) and provided one instrument (Dual-Frequency Precipitation Radar (DPR) developed by NTSpace). Each instrument developer provided a safety assessment which was incorporated into the NASA GPM Safety Hazard Assessment. Inhibit design was reviewed for hazardous subsystems which included the High Gain Antenna System (HGAS) deployment, solar array deployment, transmitter turn on, propulsion system release, GMI deployment, and DPR radar turn on. The safety inhibits for these listed hazards are controlled by software. GPM developed a "pathfinder" approach for reviewing software that controls the electrical inhibits. This is one of the first GSFC in-house programs that extensively used software controls. The GPM safety team developed a methodology to document software safety as part of the standard hazard report. As part of this process a new tool "safety inhibit time line" was created for management of inhibits and their controls during spacecraft buildup and testing during 1& Tat GSFC and at the Range in Japan. In addition to understanding inhibits and controls during 1& T the tool allows the safety analyst to better communicate with others the changes in inhibit states with each phase of hardware and software testing. The tool was very useful for communicating compliance with safety requirements especially when working with a foreign partner.

Dion, Shirley↗

IV and V Issues in Achieving High Reliability and Safety in Critical Control System Software

Risk analysis and integrated verification and validation are two important elements in a plan for ensuring the safety of critical software systems. We describe an approach we are currently developing for integrating risk analysis, and metrics analysis, and propose a fault predictor that would integrate the results of these activities. Practical difficulties associated with our approach are also discussed, as are limitations of the proposed predictor. We conclude with a discussion of what as been learned to date, and with suggestions for future work.

validation software reliability software risk asse↗

Certification Processes for Safety-Critical and Mission-Critical Aerospace Software

This document is a quick reference guide with an overview of the processes required to certify safety-critical and mission-critical flight software at selected NASA centers and the FAA. Researchers and software developers can use this guide to jumpstart their understanding of how to get new or enhanced software onboard an aircraft or spacecraft. The introduction contains aerospace industry definitions of safety and safety-critical software, as well as, the current rationale for certification of safety-critical software. The Standards for Safety-Critical Aerospace Software section lists and describes current standards including NASA standards and RTCA DO-178B. The Mission-Critical versus Safety-Critical software section explains the difference between two important classes of software: safety-critical software involving the potential for loss of life due to software failure and mission-critical software involving the potential for aborting a mission due to software failure. The DO-178B Safety-critical Certification Requirements section describes special processes and methods required to obtain a safety-critical certification for aerospace software flying on vehicles under auspices of the FAA. The final two sections give an overview of the certification process used at Dryden Flight Research Center and the approval process at the Jet Propulsion Lab (JPL).

Nelson, Stacy↗

Certification Processes for Safety-Critical and Mission-Critical Aerospace Software

This document is a quick reference guide with an overview of the processes required to certify safety-critical and mission-critical flight software at selected NASA centers and the FAA. Researchers and software developers can use this guide to jumpstart their understanding of how to get new or enhanced software onboard an aircraft or spacecraft. The introduction contains aerospace industry definitions of safety and safety-critical software, as well as, the current rationale for certification of safety-critical software. The Standards for Safety-Critical Aerospace Software section lists and describes current standards including NASA standards and RTCA DO-178B. The Mission-Critical versus Safety-Critical software section explains the difference between two important classes of software: safety-critical software involving the potential for loss of life due to software failure and mission-critical software involving the potential for aborting a mission due to software failure. The DO-178B Safety-critical Certification Requirements section describes special processes and methods required to obtain a safety-critical certification for aerospace software flying on vehicles under auspices of the FAA. The final two sections give an overview of the certification process used at Dryden Flight Research Center and the approval process at the Jet Propulsion Lab (JPL).

Nelson, Stacy↗

Capability Enhancements for System-level thermal Hydraulic Modeling of Lead Fast Reactors

This project has focused on the use, assessment, and development of the SAS4A/SASSYS-1 (SAS) safety analysis software. Although SAS was originally intended as a safety analysis tool for Liquid Metal cooled Fast Reactors (LMFRs), which includes both Sodium Fast Reactors (SFRs) and Lead Fast Reactors (LFRs), the vast majority of its recent development and customization has been tailored to SFRs. In general, enhancements that are made to the software for SFRs are applicable to LFRs, however, the fuel composition and corrosive nature of lead requires careful consideration when performing safety analysis of an LFR. In this project an emphasis was placed on closing gaps that are associated with modeling LFRs using SAS. The principal objective of the project was to enhance the ability of SAS as a licensing tool for LFRs. This objective was to be accomplished through three tasks: 1) Enhance the ability of SAS to couple with external software; 2) Improve the underlying physics models in SAS, with priority given to models that are highly relevant to LFRs; 3) Extend the Verification and Validation (V&V) basis of the software

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Safety Requirement Management System (SRMS) - Improved Documented Safety Analyses Implementation - 18476

Savannah River Remediation (SRR) developed a new software application, Safety Requirement Management System (SRMS), to improve Documented Safety Analysis (DSA) safety requirement implementation in the Savannah River Site's Liquid Waste facilities. Technical Safety Requirement (TSR) Limited Conditions of Operations (LCOs) and related surveillances were previously tracked using four different applications. Due to their differences and their age, the applications introduced a number of operational challenges and vulnerabilities, including outdated platforms, usage demands beyond original design, and different organizational work processes. SRMS was developed to resolve these issues by using a single web-based approach that provides consistency, wider accessibility, simpler maintenance, and a platform for additional functionality. Other SRS facilities are evaluating the application for its applicability as a standard practice across the site. The new SRMS application decreased the administrative overhead for application maintenance, provided the needed TSR change management functionality, and reduced error precursors with the following advantages: - Consistent process/application across all SRR facilities - More efficient way to track and communicate compliance with DSA time-related requirements (i.e., TSR LCOs and surveillances). - Web-based search capability for LCO entries/exits and a record of surveillance performances. - TSR change management and independent reviews through electronic approvals. For example, the application provides the ability to bundle and stage LCO and surveillance changes associated with a TSR revision. The approval process involves multiple roles from the facility to ensure validity. - Formal configuration management program, fully supported by software life cycle documents. SRMS was implemented at Defense Waste Processing Facility (DWPF) in June 2017, with implementation in all Liquid Waste facilities expected by the end of 2017. Next, SRR plans to expand SRMS functionality to include a linking document database (LDD) to support the DSA requirements. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

CST: A Tool for Optimizing the Efficiency and Effectiveness of Static-Code Analysis Tools

Static Code Analysis (SCA) is a vital component of NASA IV&V’s mission assurance for safety-critical software as it reduces the likelihood of software-induced hazards impacting mission success. Static Code Analysis achieves this by identifying hazards that may not have been otherwise detectable by typical code reviews or other testing. Using SCA tools, however, can be intimidating due to steep learning curves, especially considering tool performance and defect coverage varies greatly. Because of this variation amongst SCA tools, understanding which tools support certain defects and which do not, as well as understanding how to run an analysis based on steps that are unique to each tool, can be difficult to both new and experienced analysts alike. To mitigate this, the SCAWG or the IV&V Static Code Analysis Working Group, created the SCA Checker Taxonomy and Starting Point Profiles. The Checker Selection Tool (CST) incorporates these two SCAWG products into an interactive tool which allows the user to: select organized categories of defects they would like the SCA tools to discover, select default checkers depending on their mission type (e.g. flight), and configure multiple SCA tools at once. C/C++, Java, and Python defect checkers from four common SCA tools were utilized in this iteration of the CST. This iteration also includes the addition of training, SCA tool specific help, and taxonomy guide links, into its design to help users new to Static Code Analysis learn how to perform SCA more efficiently. The CST has been subject to beta testing by experienced static code analysts from the SCAWG to ensure a usable and accurate final product. The implications of the CST in the mission assurance of NASA safety-critical software are profound, as the CST can help identify and reduce false positives and false negatives, fundamentally improving overall SCA efficiency and accuracy.

static code analysis↗

Software and Hardware Systems in the Safety Control Systems of Nuclear Power Plants

Fundamentally new software and hardware systems for lower level automation in the safety monitoring and control systems of nuclear power plants are examined. More than a hundred software-hardware systems employing software and hardware from different manufacturers have been developed and introduced in this area. Design and functional solutions based on specific software-hardware systems are presented and comparative data on the apparatus and the use of the diversity principle are discussed.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Lamellar: A Rust-based Asynchronous Tasking and PGAS Runtime for High Performance Computing

Cybersecurity is one of the largest concerns in modern computing, impacting and dictating how governments, private corporations, and individuals interact with and live in an increasingly digital world. The NSA has recently released a memo [ 1] on “Software Memory Safety” where they highlight that both Microsoft and Google have stated around 70% of software vulnerabilities were due to memory safety issues. Although languages such as C and C++ provide freedom and flexibility with memory management, guaran- teeing safety falls mostly on the developer. The NSA recommends using “memory safe” languages whenever possible. In this paper we introduce Lamellar, an asynchronous tasking and PGAS HPC runtime written in Rust, one such "memory safe" language. We describe the entire Lamellar stack, from network interfaces to high- level abstractions such as distributed LamellarArrays and Active Messages. We conclude by showing comparable performance to legacy PGAS runtimes (e.g. OpenSHMEM) on a subset of the BALE kernel suite while maintaining strong memory safety principles.

HPC Software Systems, Rust Programming Language, P↗

Utilizing Code Generation from Models for Electric Aircraft Motor Controller Flight Software

The processes followed to develop and test safety-critical flight software significantly increase development effort and overhead in comparison to both non-safety-critical and non-flight software. Generating code from models can be used to reduce development effort; however, the processes for using code generation to develop flight software are relatively immature. This work presents an approach for developing safety-critical flight software utilizing code generation from models to reduce development time and effort. The presented use-case is of electric aircraft motor control software developed for NASA's X-57 Maxwell aircraft.

flight software↗

Automated Reuse of Scientific Subroutine Libraries through Deductive Synthesis

Systematic software construction offers the potential of elevating software engineering from an art-form to an engineering discipline. The desired result is more predictable software development leading to better quality and more maintainable software. However, the overhead costs associated with the formalisms, mathematics, and methods of systematic software construction have largely precluded their adoption in real-world software development. In fact, many mainstream software development organizations, such as Microsoft, still maintain a predominantly oral culture for software development projects; which is far removed from a formalism-based culture for software development. An exception is the limited domain of safety-critical software, where the high-assuiance inherent in systematic software construction justifies the additional cost. We believe that systematic software construction will only be adopted by mainstream software development organization when the overhead costs have been greatly reduced. Two approaches to cost mitigation are reuse (amortizing costs over many applications) and automation. For the last four years, NASA Ames has funded the Amphion project, whose objective is to automate software reuse through techniques from systematic software construction. In particular, deductive program synthesis (i.e., program extraction from proofs) is used to derive a composition of software components (e.g., subroutines) that correctly implements a specification. The construction of reuse libraries of software components is the standard software engineering solution for improving software development productivity and quality.

Lowry, Michael R.↗

Joint Development of SAS4A Code in Application to Oxide-fueled LFR Severe Accident Analysis

The scope of this project was to pursue specific SAS4A liquid-metal cooled reactor (LMR) safety analysis software extensions to simulate postulated accidents with fuel failures for oxide-fueled Lead-cooled Fast Reactors (LFRs). Since most U.S. LMR experience is on sodium-cooled fast reactor options based on past testing and operation experience with EBR-II and FFTF, the DOE’s legacy fast reactor safety analysis capabilities were focused on metal-fueled pool-type concepts with sodium coolant. In recent years, Westinghouse Electric Company (WEC) has decided to pursue an LFR design as one of their next generation nuclear technology options because of its favorable safety and economics attributes. Oxide fuel is considered among other fuel options due to previous WEC experience with this fuel form. Development of this new technology requires the availability of adequately accurate computational tools, some of which can be adapted from versions of similar software used for analysis of other LMRs. Although Argonne National Laboratory’s (ANL) SAS4A/SASSYS-1 safety analysis software suite (shortened as SAS4A code hereafter for brevity) has the basic capabilities to model LFR system designs, the SAS4A code modules used in the analysis of accidents with fuel/cladding failures lack appropriate models for the unique phenomena that govern as-irradiated oxide-fuel damage mechanisms in lead coolant. Therefore, the objective of this project was to extend the capabilities of SAS4A with mechanistic oxide-fuel failure models in lead coolant for margin to failure assessments, analysis of failure modes, location and timing of failures under different accident scenarios consistent with the whole-plant dynamic response including the reactivity feedback, and assessment of the potential for fuel damage propagation due to potential fission gas jet and fuel-fragment/molten fuel impingement to neighboring fuel pins in an assembly. This report provides mainly a summary of Argonne’s technical contributions in the joint project, but the reports and publications by the Participant team are included as references at the end of the report.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗

Make safety awareness a priority: Use a login software in your research facility

We report on a facility login software, whose objective is to improve safety in multi-user research facilities. Its most important safety features are: 1) blocks users from entering the lab after being absent for more than a predetermined number of days; 2) gives users a random safety quiz question, which they need to answer satisfactorily in order to use the facility; 3) blocks unauthorized users from using the facility afterhours; and 4) displays the current users in the facility. Besides restricting access to unauthorized users, the software keeps users mindful of key safety concepts. In addition, integration of the software with a door controller system can convert it into an effective physical safety mechanism. Depending on DOE approval, the code may be available as open source.

99 GENERAL AND MISCELLANEOUS↗

A view of software development environment issues

The unique and challenging nature of the Space Station Program requires that software standards be effectively used to control costs, facilitate enhancements and ensure safety. The Software Standards Panel identified and developed recommendations in four areas to help the Space Station Program achieve these objectives. The areas in which recommendations are offered are policy, organization, process and candidate software standards for the Space Station Program. The concensus process employed by the panel is given and recommendations are made.

Boehm, B.↗