This paper is composed of two sections. The first provides a conceptual framework for expressing the attributes of what constitutes dependable and reliable computing: a) the impairments to dependability (faults, errors, and failures), 6) the means for dependability (fault avoidance, tolerance, removal, and forecasting), and c) the measures of dependability (reliability, availability, safety). The second section focuses on one of the most challenging pro& /ems for dependable computing: coping with design faults.

The first part of this paper provides rigorous definitions for several basic concepts underlying the design of dependable programs, such as specification, program semantics, exception, program correctness, robustness, failure, fault, and error. The second part investigates what it means to handle exceptions in modular programs structured as hierarchies of data abstractions. The problems to be solved at each abstraction level, such as exception detection and propagation, consistent state recovery and masking are examined in detail. Both programmed exception handling and default exception handling (such as embodied for example in recovery blocks or database transactions) are considered. An assessment of the adequacy of backward recovery in providing tolerance of software design faults is made. An earlier version of this paper was published in "Dependability of Resilient Computers", T. Anderson, Editor, BSP Professional Books, Blackwell Scientific Publications, UK, 1989, pp. 68-97 INTRO...

Abstract not found

In this paper, we analyse the exception handling mechanism of a state-of-the-art industrial embedded software system. Like many systems implemented in classic programming languages, our subject system uses the popular return-code idiom for dealing with exceptions. Our goal is to evaluate the fault-proneness of this idiom, and we therefore present a characterisation of the idiom, a fault model accompanied by an analysis tool, and empirical data. Our findings show that the idiom is indeed fault prone, but that a simple solution can lead to significant improvements. 1.

Abstract. API error-handling specifications are often not documented, necessitating automated specification mining. Automated mining of error-handling specifications is challenging for procedural languages such as C, which lack explicit exception-handling mechanisms. Due to the lack of explicit exception handling, error-handling code is often scattered across different procedures and files making it difficult to mine error-handling specifications through manual inspection of source code. In this paper, we present a novel framework for mining API errorhandling specifications automatically from API client code, without any user input. In our framework, we adapt a trace generation technique to distinguish and generate static traces representing different API run-time behaviors. We apply data mining techniques on the static traces to mine specifications that define correct handling of API errors. We then use the mined specifications to detect API error-handling violations. Our framework mines 62 error-handling specifications and detects 264 real error-handling defects from the analyzed open source packages. 1 1

We classify standby redundancy design space in process-control programs into the following three categories: cold standby, warm standby, and hot standby. Design parameters of warm standby are identified and the reliability of a system using warm standby is evaluated and compared with that of hot standby. Our analysis indicates that the warm standby scheme is particularly suitable for longlived unmaintainable systems, especially those operating in harsh environments where burst hardware failures are possible. The feasibility of warm standby is demonstrated with a simulated chemical batch reactor system.

A software system interacts with third-party libraries through various Application Program Interfaces (APIs). Using these APIs correctly often needs to follow certain programming rules, i.e., API specifications. API specifications specify the required checks (on API input parameters and return values) and other APIs to be invoked before (preconditions) and after (postconditions) an API call. Incorrect usage of APIs (in short, API violations) can lead to security and robustness problems, two primary hindrances for the reliable operation of a software system. Hence, for a software system, adherence to the specifications, which govern the correct usage of APIs used by the system, is paramount for software reliability. Specifications, when known, can be formally written for third-party APIs and statically verified against a software system. This dissertation addresses two main problems faced by programmers in effectively and correctly reusing third-party APIs. (1) Formal API specifications are complicated and lengthy mainly due to the various API details (such as input/return type, error-flag codes, and return values for APIs on success/failure) and language-specific syntax considerations required for the specification to be accurate and complete. Hence, manually writing a large number of formal API specifications, when known, for static verification is often inaccurate or incomplete,

Abstract not found

Abstract--This paper serves a dual purpose. It presents a unified framework and terminology for the study of computer system dependability. It also surveys the field of dependable computing in light of the proposed framework. Specifically, impairments to dependability are viewed from six levels, each being more abstract than the previous one. It is argued that all of these levels are useful, in the sense that proven dependability assurance techniques can be applied at each level, and that it is beneficial to have distinct, precisely defined terminology for describing impairments to, and procurement strategies for, computer system dependability at these levels. The six levels are: (I) Defect level or component level, dealing with deviant atomic parts. (2) Fault level or logic level, dealing with deviant signal values or path selections. (3) Error level or information level, dealing with deviant data or internal states. (4) Malfunction level or system level, dealing with deviant functional behavior. (5) Degradation level or service level, dealing with deviant performance. (6) Failure level or result level, dealing with deviant outputs or actions. Briefly, a hardware or software component may be defective (hardware may also become defective due to wear and aging). Certain system states will expose the defect, resulting in the development of faults