Design assurance level

Acceptance test criteria are identified, can be implemented and are consistent with the hardware design assurance levels of the hardware functions. o o Hardware Acceptance Test Criteria 10.5 HC2 HC2 HC2 HC2... 

Objective Applicability by Design Assurance Level Output Control category ... 

TABLE 2.3 Hardware Design Assurance Level Definitions and Their Relationships to Systems Development Assurance Level... 

See Design Assurance Level (DAL) and Software Level (SL) for additional related information. 

Since the OBSW is in charge of the safety of the whole IXV spacecraft (and thus the success of this mission), this software is assigned a high Design Assurance Level... 

Safety integrity levels (SILs) and design assurance levels (DATs) are allocated to systems commensurate with the significance of any residual malfunctions. Essentially we establish the safety significance of the design and initiate a commensurate amount of design rigour to minimise the risk of malfunction and to concentrate effort where it is most needed. 

Identifies functions and required design assurance levels for those functions. 

Any sufficiently complex system is subject to failure as a result of one or more subsystems or components failing. The aim of the FTA is to use deductive logic to understand all the underlying causes of a particular failure in a sufficiently complex system so that the likelihood of failure can be reduced through improved system design (i.e. different component selection, more stringent development assurance levels and/or via system architectural improvements). 

RTCA/DO-254 (App C) refers to Design Assurance , which are all of those planned and systematic actions used to substantiate, at an adequate level of confidence, that design errors have been identified and corrected such that the hardware satisfies the application certification basis . 

The design of aeronautics safety critical systems deals with two families of faults random faults of equipments and systematic faults in the development of the equipment, which include errors in the specification, design and coding of hardware and software. Two different approaches are used when assessing whether the risk associated with these two types of faults is acceptable. Qualitative requirements (minimal number of failures leading to a Failure Condition) and quantitative requirements (maximal probability of a Failure Condition occurrence) are associated with equipment faults whereas requirements stated in terms of Development Assurance Levels (DAL) are associated with development faults. 

The term DAL comes from Radio Technical Commission for Aeronautics (RTCA)/DO-254, Design Assurance Guidance for Airborne Electronic Hardware, 2000. In this document hardware is classified into five levels based on a set of criteria for each level. The derived software level (SL) is based on the contribution of the software to potential failure conditions as determined by the system safety assessment (SSA) process. 

Systemic failures are due to human errors (e.g. mistakes, misconceptions, miscommunications, omissions) in the specification, design, build, operation and/or maintenance of the system. Errors in this case are taken to include both mistakes and omissions. Errors can be introduced during any part of the lifecycle and errors are caused by failures in design, manufacture, installation or maintenance. Systematic failures occur whenever a set of particular conditions is met and are therefore repeatable (i.e. items subjected to the same set of conditions will fail consistently) and thus apply to both hardware and software. It is difficult to quantify the rate at which systemic failures will occur and a qualitative figure based on the robustness of the development/build process is normally used. The probability of systemic failures is often evaluated by means of safety integrity (or development assurance) levels. 

---