Assurance cases provide a structured method of explaining why a system has some desired property, e.g., that the system is safe. But there is no agreed approach for explaining what degree of confidence one should have in the conclusions of such a case. In this paper, we use the principle of eliminative induction to provide a justified basis for assessing how much confidence one should have in an assurance case argument.

For critical systems it is important to know whether the system is trustworthy and to be able to communicate, review and debate the level of trust achieved. In the safety domain, explicit Safety Cases are increasingly required by law, regulations and standards. Yet the need to understand risks is not just a safety issue and the type of argumentation used for safety cases is not specific to safety alone. Prior workshops, beginning with one held at DSN 2004, have identified a number of technical, policy and research challenges. The focus of this workshop is on one of these challenges: metrics for assurance cases for security.

The use of a declarative language, called Dura, designed to support application-level programming is illustrated by distributed avionics system. The authors show how the language is used to describe the application, its components and structure; how the run-time executive provides support for fault-tolerance by reconfiguration of the application; and how an interactive interface to the executive supports debugging and monitoring of the application.>

We describe methods for achieving an acceptable level of fault-tolerance in a multiprocessor designed for the execution of critical flight tasks on commercial aircraft. The SIFT (Software Implemented Fault-tolerant) system differs from other reliable computer architectures in the manner of utilization of redundant resources. The SIFT system is designed to cope with hardware faults by detecting discrepancies in the results computed by separately executed versions of critical programs. When such a discrepancy occurs we identify the processor/memory unit, bus unit, or processor/bus interface that has failed. A reconfiguration of task execution among the available resources is carried out to avoid the use of hardware units that have been identified as faulty or unreliable. We explain how the identification of faulty units can be effected, how the system may be reconfigured to avoid use of faulty units, and show that these reconfiguration policies are "safe" with respect to faults that do not occur in separated units during the short interval required to carry out the reconfiguration of tasks.