An analysis of test solutions for COTS-based systems in space applications

Abstract

One of the current trends in space electronics is towards considering the adoption of COTS components, mainly to widen the spectrum of available products. When substituting space-qualified components with COTS ones a major challenge lies in guaranteeing the same level of reliability. To achieve this goal, a mix of different solutions can be considered, including effective test techniques, able to guarantee a high level of permanent fault coverage while matching several constraints in terms of system accessibility and hardware complexity. In this paper, we describe an approach based on Software-based Self-test, which is currently being adopted within the MaMMoTH-Up project, targeting the development of an innovative COTS-based system to be used on the Ariane5 launcher. The approach aims at testing the OR1200 processor adopted in the system, combined with new and effective techniques for identifying the safe faults. Results also include a comparison between functional and structural test approaches.I.

New categories of Safe Faults in a processor-based Embedded System

“…As a major result of this effort, it is now possible to compute the Fault Coverage achieved by a generic test step by considering a list of faults from which safe faults have been removed. For this purpose, we can use the Fault Coverage without Safe Faults (FC_safe) metric, as done already in [4], computed via the expression: FC_safe = #detected faults / (#faults -#safe faults) The proposed method for the identification of safe faults and for the calculation of the FC_safe is independent of the test method chosen to test the device. In our case study we chose to test the OR1200 CPU by resorting to a Self-Test Library (STL) based on the Software-Based Self-Test (SBST) paradigm.…”

“…The set of Safe Faults for a given system includes the well-known Untestable Faults, that are usually caused by structural or sequential redundancy (which cannot be tested even by an exhaustive test) but it also contains faults that cannot produce any failure (and thus cannot be tested) due to the specific configuration of the system, which in some way limits the controllability and observability of each unit inside. It has been shown [4] that the percentage of Safe Faults may be significant (achieving 20% or 30% of the total number of faults in many cases), and it is thus crucial to be able to identify them. Similar figures have been obtained when analyzing the portion of a processor which is not used by a given application [5].…”

“…Moreover, any solution able to preliminarily identify Safe Fault will also be able to make the test generation step more effective. Following our previous work on the topic [2][3] [4], in this paper we focus on the Safe Faults which may exist in an embedded system based on a pipelined processor (as it commonly happens in several safety-critical systems). Initially, an overview about the safe faults is shows (Section 2).…”

Determined-Safe Faults Identification: A step towards ISO26262 hardware compliant designs

“…For those which are not detected we must rely on alternative analysis methods that can prove whether they could disturb safety-critical functionalities or not (Safe Faults). Previous works [4] showed that the number of Safe Faults can be significant in real applications. In complicated designs, manual analysis of fault effects is an arduous task that requires extensive knowledge of the design functionalities.…”

System-on-chip testing

“…In Figure 5.15 and Figure 5.16 we compare test-programs generated using the proposed method with 274 T M Is against SBST programs P1 to P6 (details about these test programs can be found in [206,207]) in terms of stuck-at and transitionfault coverage. Test programs P1 to P6 have been generated manually, requiring several weeks of significant test-engineering effort.…”