Hardware Development Assurance

The means of compliance of the hardware Development Assurance objectives, including strategies identified, are proposed to the certification authority. 

CM-SWCEH-001, 2011. Development Assurance of Airborne Electronic Hardware, Certification Memorandum. EASA. 

With reference to Table 9.21, the foUowing deliverables are required as evidence of complex hardware development process assurance ... 

ANM-03-117-09, January 14, 2004. Policy Statement on Guidance for Determination of System, Hardware, and Software Development Assurance Levels on Transport Category Airplanes. FAA Memorandum. 

Product Service Experience Service experience (i.e., previous or current usage of the component) may be used to substantiate Development Assurance for previously developed hardware and for COTS components, where change is not introduced within this application. Note that in this context, this is direct product service history evidence, and not colloquial here say evidence. Data from non-airborne applications is not specifically excluded under RTCA/DO-254, although often these applications lack the necessary failure reporting data in order to be able to assess the product service experience. RTCA/DO-254 defines criteria on how to evaluate product service history. It should be noted that this is an onerous process, and many product service history cases do not have sufficient data in order to successfully evaluate product service history. Therefore, the architectural mitigation or advance verification methods must be used. 

RTC A/DO-254 defines Functional Failure Path (FFP) as the specific set of interdependent circuits that could cause a particular anomalous behaviour in the hardware that implements the function or in the hardware that is dependent upon the function. FFP Analysis (FFPA) is used to iteratively decompose the hardware functions into a hierarchy of subfunction to determine if it will be possible to fulfil completely the objectives of RTCA/DO-254 for each subfunction. If the assurance lifecycle data available or expected to be available is complete, correct and acceptable per the RTCA/DO-254 objectives and guidance, then no further decomposition is necessary. If it is not, then decomposition continues until such a stage as the FFP feasibly maps to one of the Development Assurance methods (and associated data set) as described in the previous section. For FFPs that are not Levels A or B, their interrelationships with the Level A or B FFPs should be evaluated using an F-FMEA, common mode analysis or dependency diagram to ensure that the Level A and B FFPs cannot be adversely impacted by the FFPs which are not Level A or B. 

The factors that distinguish hardware DALs are the level of independence required for Levels A and B, which is not required for Levels C and D (as specified by the Applicability by Development Assurance-Level columns), and the degree of control... 

Chapter 9 addresses the systematic causes of failures or unanticipated system behaviours and provides guidance on Development Assurance Levels (DALs) to the Safety Assessor who may not be expert in the fields of software(SAV) or complex hardware (HAV). 

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. 

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

The Development Assurance Level of an aircraft function depends on the severity of the effects of failures or development errors of that function on the aircraft, crew, or occupants. The Development Assurance Level of each item depends on both the system architecture and the resulting failure effects of the item on the functions performed by the system. DO-178 procedures should be used to verify that the software implementation meets the required DALs. The hardware DALs are verified via procedures that are to be defined by RTCA DO-254. 

EASA Development assurance of airborne electronic hardware (2011)... 

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. 

Collating documentary evidence that the software and hardware provided by a snpplier have been developed and maintained under a quality assurance regime snpporting validation... 

A vendor should be selected who develops hardware and software equipment in accordance with a quality assurance system, for example, ISO 9001. ... 

The inspection of the capability of the process in order to gain the required assurance as to the fitness for purpose of the developed software—a measure of its validatabillty—is referred to here as a software quality assurance audit. The software quality assurance audit is occasionally referred to as a Supplier Audit (e.g., in the GAMP Guide). However, a Supplier Audit is also used to audit original equipment manufacturers, hardware suppliers, independent contractors and even an internal department with a pharmaceutical organization. There may be no "software" involved at all. For that reason, the term software quality assurance audit is more preferable than Supplier Audit. 

In MORT Safety Assurance Systems, a 1980 pubhcation, William G. Johnson refers to work done by R. J. Nertney, who developed a provocative method of examining the successive phases in hardware-procedure development and also examining the all important interfaces between those three elements. Elements in the Nertney system are... 

A complete lEC 61508 assessment includes a FMEDA, a study of Prior Use and adds an assessment of all fault avoidance and fault control measures during hardware and software development as well as detail study of the testing, modification, user documentation and manufacturing processes. The objective of all this effort is to provide a high level of assurance that an instrument has sufficient quality and integrity for a safety instrumented system application. This is clearly more important for products containing software as many end users have the strong opinion that software is "bad... 

RTCA DO-254. Design Assurance Guidance for Airborne Electronic Hardware. RTCA, Inc. SAE ARP4754A, 2010. Guidelines for Development of Civil Aircraft and Systems, the Engineering Society for Advanced Mobility Land Sea Air and Space. Aerospace Recommended Practise, Warrendale, USA. 

An interesting and useful classification of steps used to assure quality of analytical data (Bansal 2004) has drawn a clear distinction between quahfication of apparatus used to obtain the data and validation of the methods developed to use the apparatus to obtain the data pertinent to a particular analytical problem. Overlaid on this distinction is another, that between tests that must be completed satisfactorily before acquisition of the desired analytical data can begin (instrument quahfication and method vah-dation) on the one hand, and those that are conducted immediately before or simultaneously with data acquisition (system suitability and quahty control checks) on the other. The original paper (Bansal 2004) represented the outcome of a workshop intended to fiU a need for a more detailed scientific approach to what was termed Analytical Instrument Quahfication (AIQ) , particularly in the context of applications in the pharmaceutical industry. Note in particular that qualification of both hardware and software plays an important role in method validation. 

---