Formal verification and testing are complementary approaches which are used in the development process to verify the functional correctness of software. However, the correctness of software cannot ensure the safe operation of safety-critical software systems. The software must be verified against its safety requirements which are identified by safety analysis, to ensure that potential hazardous causes cannot occur. The complexity of software makes defining appropriate software safety requirements with traditional safety analysis techniques difficult. STPA (Systems-Theoretic Processes Analysis) is a unique safety analysis approach that has been developed to identify system hazards, including the software-related hazards. This paper presents a comprehensive safety engineering approach based on STPA, including software testing and model checking approaches for the purpose of developing safe software. The proposed approach can be embedded within a defined software engineering process or applied to existing software systems, allow software and safety engineers integrate the analysis of software risks with their verification. The application of the proposed approach is illustrated with an automotive software controller.

No abstract

No abstract

Background. Today, redundancy in source code, so-called ''clones'' caused by copy &paste can be found reliably using clone detection tools. Redundancy can arise also independently, however, not caused by copy&paste. At present, it is not clear how only functionally similar clones (FSC) differ from clones created by copy&paste. Our aim is to understand and categorise the syntactical differences in FSCs that distinguish them from copy&paste clones in a way that helps clone detection research. Methods. We conducted an experiment using known functionally similar programs in Java and C from coding contests. We analysed syntactic similarity with traditional detection tools and explored whether concolic clone detection can go beyond syntax. We ran all tools on 2,800 programs and manually categorised the differences in a random sample of 70 program pairs. Results. We found no FSCs where complete files were syntactically similar. We could detect a syntactic similarity in a part of the files in <16% of the program pairs. Concolic detection found 1 of the FSCs. The differences between program pairs were in the categories algorithm, data structure, OO design, I/O and libraries. We selected 58 pairs for an openly accessible benchmark representing these categories. Discussion. The majority of differences between functionally similar clones are beyond the capabilities of current clone detection approaches. Yet, our benchmark can help to drive further clone detection research.

Abstract. Modern safety-critical systems are increasingly reliant on software. Software safety is an important aspect in developing safetycritical systems, and it must be considered in the context of the system level into which the software will be embedded. STPA (System-Theoretic Process Analysis) is a modern safety analysis approach which aims to identify the potential hazardous causes in complex safety-critical systems at the system level. To assure that these hazardous causes of an unsafe software's behaviour cannot happen, safety verification involves demonstrating whether the software fulfills those safety requirements and will not result in a hazardous state. We propose a method for verifying of software safety requirements which are derived at the system level to provide evidence that the hazardous causes cannot occur (or reduce the associated risk to a low acceptable level). We applied the method to a cruise control prototype to show the feasibility of the proposed method.

Abstract

Context: Today's safety critical systems are increasingly reliant on software. Software becomes responsible for most of the critical functions of systems. Many different safety analysis techniques have been developed to identify hazards of systems. FTA and FMEA are most commonly used by safety analysts. Recently, STPA has been proposed with the goal to better cope with complex systems including software. Objective: This research aimed at comparing quantitatively these three safety analysis techniques with regard to their effectiveness, applicability, understandability, ease of use and efficiency in identifying software safety requirements at the system level. Method: We conducted a controlled experiment with 21 master and bachelor students applying these three techniques to three safety-critical systems: train door control, anti-lock braking and traffic collision and avoidance. Results: The results showed that there is no statistically significant difference between these techniques in terms of applicability, understandability and ease of use, but a significant difference in terms of effectiveness and efficiency is obtained. Conclusion: We conclude that STPA seems to be an effective method to identify software safety requirements at the system level. In particular, STPA addresses more different software safety requirements than the traditional techniques FTA and FMEA, but STPA needs more time to carry out by safety analysts with little or no prior experience.

Safety has become of paramount importance in the development lifecycle of the modern automobile systems. However, the current automotive safety standard ISO 26262 does not specify clearly the methods for safety analysis. Different methods are recommended for this purpose. FTA (Fault Tree Analysis) and FMEA (Failure Mode and Effects Analysis) are used in the most recent ISO 26262 applications to identify component failures, errors and faults that lead to specific hazards (in the presence of faults). However, these methods are based on reliability theory, and they are not adequate to address new hazards caused by dysfunctional component interactions, software failure or human error. A holistic approach was developed called STPA (Systems-Theoretic Process Analysis) which addresses more types of hazards and treats safety as a dynamic control problem rather than an individual component failure. STPA also addresses types of hazardous causes in the absence of failure. Accordingly, there is a need for investigating hazard analysis techniques like STPA. In this paper, we present a concept on how to use STPA to extend the safety scope of ISO 26262 and support the Hazard Analysis and Risk Assessments (HARA) process. We applied the proposed concept to a current project of a fully automated vehicle at Continental. As a result, we identified 24 systemlevel accidents, 176 hazards, 27 unsafe control actions, and 129 unsafe scenarios. We conclude that STPA is an effective and efficient approach to derive detailed safety constraints. STPA can support the functional safety engineers to evaluate the architectural design of fully automated vehicles and build the functional safety concept.