7,216 research outputs found

    Model Based Mission Assurance: NASA's Assurance Future

    Get PDF
    Model Based Systems Engineering (MBSE) is seeing increased application in planning and design of NASAs missions. This suggests the question: what will be the corresponding practice of Model Based Mission Assurance (MBMA)? Contemporaneously, NASAs Office of Safety and Mission Assurance (OSMA) is evaluating a new objectives based approach to standards to ensure that the Safety and Mission Assurance disciplines and programs are addressing the challenges of NASAs changing missions, acquisition and engineering practices, and technology. MBSE is a prominent example of a changing engineering practice. We use NASAs objectives-based strategy for Reliability and Maintainability as a means to examine how MBSE will affect assurance. We surveyed MBSE literature to look specifically for these affects, and find a variety of them discussed (some are anticipated, some are reported from applications to date). Predominantly these apply to the early stages of design, although there are also extrapolations of how MBSE practices will have benefits for testing phases. As the effort to develop MBMA continues, it will need to clearly and unambiguously establish the roles of uncertainty and risk in the system model. This will enable a variety of uncertainty-based analyses to be performed much more rapidly than ever before and has the promise to increase the integration of CRM (Continuous Risk Management) and PRA (Probabilistic Risk Analyses) even more fully into the project development life cycle. Various views and viewpoints will be required for assurance disciplines, and an over-arching viewpoint will then be able to more completely characterize the state of the project/program as well as (possibly) enabling the safety case approach for overall risk awareness and communication

    Software system safety

    Get PDF
    Software itself is not hazardous, but since software and hardware share common interfaces there is an opportunity for software to create hazards. Further, these software systems are complex, and proven methods for the design, analysis, and measurement of software safety are not yet available. Some past software failures, future NASA software trends, software engineering methods, and tools and techniques for various software safety analyses are reviewed. Recommendations to NASA are made based on this review

    Towards Declarative Safety Rules for Perception Specification Architectures

    Full text link
    Agriculture has a high number of fatalities compared to other blue collar fields, additionally population decreasing in rural areas is resulting in decreased work force. These issues have resulted in increased focus on improving efficiency of and introducing autonomy in agriculture. Field robots are an increasingly promising branch of robotics targeted at full automation in agriculture. The safety aspect however is rely addressed in connection with safety standards, which limits the real-world applicability. In this paper we present an analysis of a vision pipeline in connection with functional-safety standards, in order to propose solutions for how to ascertain that the system operates as required. Based on the analysis we demonstrate a simple mechanism for verifying that a vision pipeline is functioning correctly, thus improving the safety in the overall system.Comment: Presented at DSLRob 2015 (arXiv:1601.00877

    System safety in Stirling engine development

    Get PDF
    The DOE/NASA Stirling Engine Project Office has required that contractors make safety considerations an integral part of all phases of the Stirling engine development program. As an integral part of each engine design subtask, analyses are evolved to determine possible modes of failure. The accepted system safety analysis techniques (Fault Tree, FMEA, Hazards Analysis, etc.) are applied in various degrees of extent at the system, subsystem and component levels. The primary objectives are to identify critical failure areas, to enable removal of susceptibility to such failures or their effects from the system and to minimize risk

    Is "Better Data" Better than "Better Data Miners"? (On the Benefits of Tuning SMOTE for Defect Prediction)

    Full text link
    We report and fix an important systematic error in prior studies that ranked classifiers for software analytics. Those studies did not (a) assess classifiers on multiple criteria and they did not (b) study how variations in the data affect the results. Hence, this paper applies (a) multi-criteria tests while (b) fixing the weaker regions of the training data (using SMOTUNED, which is a self-tuning version of SMOTE). This approach leads to dramatically large increases in software defect predictions. When applied in a 5*5 cross-validation study for 3,681 JAVA classes (containing over a million lines of code) from open source systems, SMOTUNED increased AUC and recall by 60% and 20% respectively. These improvements are independent of the classifier used to predict for quality. Same kind of pattern (improvement) was observed when a comparative analysis of SMOTE and SMOTUNED was done against the most recent class imbalance technique. In conclusion, for software analytic tasks like defect prediction, (1) data pre-processing can be more important than classifier choice, (2) ranking studies are incomplete without such pre-processing, and (3) SMOTUNED is a promising candidate for pre-processing.Comment: 10 pages + 2 references. Accepted to International Conference of Software Engineering (ICSE), 201

    An overview of decision table literature 1982-1995.

    Get PDF
    This report gives an overview of the literature on decision tables over the past 15 years. As much as possible, for each reference, an author supplied abstract, a number of keywords and a classification are provided. In some cases own comments are added. The purpose of these comments is to show where, how and why decision tables are used. The literature is classified according to application area, theoretical versus practical character, year of publication, country or origin (not necessarily country of publication) and the language of the document. After a description of the scope of the interview, classification results and the classification by topic are presented. The main body of the paper is the ordered list of publications with abstract, classification and comments.
    corecore