EN 9721:2021

Aerospace series - General recommendation for the BIT Architecture in an integrated system

The purpose of this document is to harmonise the dialogue between manufacturers, prime contractors, owners and the customer in view of making it easier to draw up specifications, share BIT architecture models and the BIT technical configuration of systems during the operational use phase.
This recommendation proposes adopting BIT operational efficiency and performance definitions, architecture design principles, and BIT specification or validation principles. It provides no recommendations regarding the numeric values for operational efficiency or performance. The diversity of situations, development of technological solutions and ever-changing operational requirements make it impossible to list general recommendations.
Clause 6 and Clause 9 set out the general context of use of the BIT.
Clause 7 lists the constraints to be taken into account to design a BIT architecture.
Clause 8 lists the various BIT types currently known and the definitions of performance and operational efficiency (metrics).
Clause 10 provides recommendations on the BIT architecture.
Clause 11 recommends a language for exchanging BIT architecture models for assembling the complete model of a system.
Clause 12 is an introduction to the prognosis.
This European standard is mainly intended for system designers.
Although it is based on examples of aeronautic systems, it is applicable to any type of system.

Luft- und Raumfahrt - Allgemeine Empfehlungen für die integrierte Prüfungs-(BIT)-Architektur in einem integrierten System

Zweck dieses Dokuments ist es, den Dialog zwischen Herstellern, Hauptauftragnehmern, Eigentümern und dem Kunden zu harmonisieren, um die Erstellung von Spezifikationen, die gemeinsame Nutzung von BIT Architekturmodellen und die technische BIT-Konfiguration von Systemen während des Betriebs zu erleichtern.
In dieser Empfehlung wird vorgeschlagen, Definitionen der BIT-Betriebseffizienz und der BIT-Leistung sowie Grundsätze für den Entwurf der Architektur und die BIT Spezifikation oder  Validierung aufzustellen. Es werden keine Empfehlungen für die numerischen Werte der Betriebseffizienz oder der Leistung gegeben. Die Vielfalt der Situationen, die Entwicklung technologischer Lösungen und die sich ständig ändernden Betriebsanforderungen machen die Aufstellung allgemeiner Empfehlungen unmöglich.
Abschnitt 6 und Abschnitt 9 legen den allgemeinen Nutzungszusammenhang des BIT dar.
Abschnitt 7 führt Vorgaben auf, die beim Entwurf einer BIT-Architektur zu berücksichtigen sind.
Abschnitt 8 enthält ein Verzeichnis verschiedener gegenwärtig bekannter BIT Arten und die Definitionen der Leistung und der Betriebseffizienz (Metriken).
Abschnitt 10 gibt Empfehlungen für die BIT Architektur.
Abschnitt 11 empfiehlt eine Sprache für den Austausch von BIT Architekturmodellen für die Aufstellung des Gesamtmodells eines Systems.
Abschnitt 12 ist eine Einführung in die Prognose.
Dieses Dokument ist in erster Linie für Systementwickler vorgesehen.
Obwohl sie auf Beispielen von Luftfahrtsystemen beruht, ist sie für jede Systemart anwendbar.

Série aerospatiale - Recommandations générales pour l'architecture des BIT dans un système intégré

L’objet du présent document est d’harmoniser le dialogue entre les fabricants, les donneurs d'ordre, les maîtres d’ouvrage et le client en vue de faciliter l’établissement de spécifications, l’échange de modèles d’architecture BIT ainsi que la configuration technique BIT des systèmes pendant la phase d’utilisation opérationnelle.
La présente recommandation propose d’adopter des définitions de performances et d’efficacité BIT, des principes de conception d’architecture, des principes de spécification ou de validation du BIT. Elle ne fournit aucune recommandation quant aux valeurs numériques de performance ou d’efficacité à spécifier. La diversité des situations, l’évolution des solutions technologiques et les besoins opérationnels toujours changeants rendent illusoires des recommandations générales.
L’Article 6 et l’Article 9 définissent le contexte général d’emploi du BIT.
L’Article 7 recense les contraintes à prendre en compte pour concevoir une architecture BIT.
L’Article 8 recense les différents types de BIT connus aujourd’hui ainsi que les définitions de performance et d’efficacité (métriques).
L’Article 10 fournit des recommandations quant à l’architecture BIT.
L’Article 11 recommande un langage d’échange de modèles d’architecture BIT en vue de permettre l’assemblage du modèle complet d’un système.
L’Article 12 est une introduction au pronostic.
Le présent document s’adresse essentiellement aux concepteurs de systèmes.
Bien qu’il s’appuie sur des exemples de systèmes aéronautiques, il est applicable à tous types de systèmes.

Aeronavtika - Splošno priporočilo za arhitekturo BIT v integriranem sistemu

Namen tega dokumenta je uskladiti dialog med proizvajalci, glavnimi izvajalci, lastniki in stranko za lažjo pripravo specifikacij, deljenje modelov arhitekture BIT in tehnične konfiguracije sistemov BIT v fazi operativne uporabe.
To priporočilo predlaga sprejetje definicij operativne učinkovitosti in zmogljivosti BIT, načel oblikovanja arhitekture in specifikacij BIT ali načel potrjevanja. Ne daje nobenih priporočil glede številskih vrednosti za operativno učinkovitost ali zmogljivost. Raznolikost situacij, razvoj tehnoloških rešitev in nenehno spreminjajoče se operativne zahteve onemogočajo naštevanje splošnih priporočil.
Točki 6 in 9 določata splošni kontekst uporabe BIT.
V točki 7 so navedene omejitve, ki jih je treba upoštevati pri načrtovanju arhitekture BIT.
V točki 8 so naštete različne trenutno znane vrste BIT ter definicije zmogljivosti in operativne učinkovitosti (metrike).
Točka 10 vsebuje priporočila o arhitekturi BIT.
Točka 11 priporoča jezik za izmenjavo modelov arhitekture BIT za sestavljanje celotnega modela sistema.
Točka 12 je uvod v prognozo.
Ta evropski standard je namenjen predvsem projektantom sistemov.
Čeprav temelji na primerih aeronavtičnih sistemov, je uporaben za vse vrste sistemov.

General Information

• Status: Published
• Publication Date: 21-Dec-2021
• Withdrawal Date: 29-Jun-2022
• ICS: 49.020 - Aircraft and space vehicles in general
• Technical Committee: ASD-STAN - Aerospace
• Drafting Committee: ASD-STAN/D 1/S 8 - Built-In-Tests
• Current Stage: 6060 - Definitive text made available (DAV) - Publishing
• Start Date: 22-Dec-2021
• Completion Date: 22-Dec-2021
• Ref Project: SIST EN 9721:2022 - Aerospace series - General recommendation for the BIT Architecture in an integrated system

Overview

EN 9721:2021 - Aerospace series: General recommendation for the BIT Architecture in an integrated system is a CEN recommendation that harmonises how manufacturers, prime contractors, owners and customers specify, exchange and validate Built‑In Test (BIT) architectures and technical configurations during the operational phase. The document defines common terminology, operational efficiency and performance metrics, architecture design principles and model‑exchange conventions. It does not prescribe numerical thresholds for performance - instead it provides definitions and guidance to support consistent specification, verification and prognostics across diverse systems.

Key topics

• Purpose & scope
  • Harmonise dialogue and specification of BIT architectures for integrated systems.
  • Applicable primarily to system designers but relevant to manufacturers, maintenance engineers, operators and customers. Although aeronautic examples are used, guidance is applicable to any system type.
• Design constraints (Clause 7)
  • Lists system, interface, maintenance and operational constraints that influence BIT architecture decisions.
• BIT types & metrics (Clause 8)
  • Defines known BIT types: PBIT (Power‑on/PBIT), IBIT/DBIT (Initiated/Demanded), CBIT (Continuous), EBIT (External), MBIT (Maintenance).
  • Introduces metrics and formal definitions such as detection rate, isolation rate, unreliabilisation rate, false alarm / false correct operation rates.
• Architecture recommendations (Clause 10)
  • Principles for distributed vs centralised BIT architectures, supervisor functions, detection and diagnostic functional blocks, and exchanged data typology.
• Model exchange language (Clause 11)
  • Recommends a language/format to exchange BIT architecture models to assemble complete system models and support configuration.
• Prognosis (Clause 12)
  • Introduction to using BIT data for prognosis, including data requirements and organisational aspects for prognostic processes.
• Use across lifecycle
  • Guidance on using BIT during development, production, service, maintenance and validation.

Applications

• Create clear BIT specifications for avionics and integrated systems.
• Standardise BIT model exchange between suppliers and prime contractors to speed integration and reduce misinterpretation.
• Support diagnostics, maintenance planning and health‑management / prognostics programs.
• Aid system designers in selecting architectures (distributed vs centralised) and in defining verification/validation approaches.
• Useful for field data engineers, maintenance engineers, system technical managers and reliability teams.

Who should use it

• System designers and BIT architects
• Manufacturers and subcontractors supplying avionics or integrated subsystems
• Prime contractors, operators and owners specifying BIT requirements
• Maintenance, diagnostics and prognostics engineers

Related standards

• Complementary to aerospace reliability, diagnostics and health‑management standards and industry best practice for avionics verification, maintenance and prognostics. Use EN 9721:2021 alongside organisational and domain‑specific standards when defining quantitative performance targets (which EN 9721 deliberately leaves unspecified).

Keywords: EN 9721:2021, BIT architecture, Built‑In Test, aerospace diagnostics, BIT metrics, prognostics, avionics maintenance.

Standards Content (Sample)

SLOVENSKI STANDARD
01-marec-2022
Aeronavtika - Splošno priporočilo za arhitekturo BIT v integriranem sistemu
Aerospace series - General recommendation for the BIT Architecture in an integrated
system
Luft- und Raumfahrt - Allgemeine Empfehlungen für die integrierte Prüfungs-(BIT)-
Architektur in einem integrierten System
Série aerospatiale - Recommandations générales pour l'architecture des BIT dans un
système intégré
Ta slovenski standard je istoveten z: EN 9721:2021
ICS:
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 9721
EUROPEAN STANDARD
NORME EUROPÉENNE
December 2021
EUROPÄISCHE NORM
ICS 49.020
English Version
Aerospace series - General recommendation for the BIT
Architecture in an integrated system
Série aerospatiale - Recommandations générales pour Luft- und Raumfahrt - Allgemeine Empfehlungen für
l'architecture des BIT dans un système intégré die integrierte Prüfungs-(BIT)-Architektur in einem
integrierten System
This European Standard was approved by CEN on 2 November 2020.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2021 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9721:2021 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 13
4 BIT stakeholders . 15
4.1 BIT specifier . 15
4.2 BIT designer/developer . 15
4.3 Operational user . 15
4.4 Maintenance engineer . 15
4.5 System technical manager . 16
4.6 Expert . 16
4.7 Field data engineer . 16
5 System constraints . 16
5.1 System design . 16
5.2 BIT interface function . 17
5.2.1 The alarm function . 17
5.2.2 The diagnostic function . 18
5.2.3 Built-in reconfiguration. 18
5.2.4 The maintenance function . 18
5.2.5 The data recording for post analysis function . 18
5.3 System technical states . 19
5.4 Functional modes of a system . 19
5.5 System configuration . 19
5.5.1 Operational configuration of a system . 19
5.5.2 Technical configuration . 20
5.5.3 BIT parameterisation . 20
6 BIT types and metrics . 21
6.1 General. 21
6.2 The various types of BIT . 21
6.2.1 Power-up BIT or Power-on BIT (PBIT) . 21
6.2.2 Initiated BIT (IBIT) or Demanded BIT (DBIT) . 22
6.2.3 Continuous BIT (CBIT) . 22
6.2.4 External BIT (EBIT) . 22
6.2.5 Maintenance BIT (MBIT) . 22
6.2.6 Summary of characteristics of the various types of BIT . 23
6.3 The metrics . 23
6.3.1 Role of the mathematical definitions of the metrics . 23
6.3.2 Detection rate . 24
6.3.3 Isolation rate . 26
6.3.4 Unreliabilisation rate caused by the BIT . 29
6.3.5 False alarm rates, false correct operation rates . 29
7 Use of BIT . 34
7.1 During development . 34
7.2 During production . 34
7.3 During service . 36
7.3.1 In operational mode . 36
7.3.2 In maintenance mode . 36
7.4 During validation during repair . 36
8 Architecture of the BIT . 36
8.1 The generic functions of the BIT. 36
8.1.1 General . 36
8.1.2 BIT Detection function . 38
8.1.3 BIT Supervisor function. 38
8.2 The various architectures of the BIT function . 41
8.2.1 General . 41
8.2.2 Distributed BIT Architecture . 42
8.2.3 Centralised BIT Architecture . 42
8.2.4 Choice of BIT architecture . 43
8.3 Exchanged data typology . 44
8.4 Specification process . 45
8.4.1 System design arbitrations: Essential objective and effort . 45
8.4.2 The BIT specification process . 47
8.5 Generic modelling and configuration language. 48
8.5.1 Introduction . 48
8.5.2 General information . 50
8.5.3 Description of the language tables . 51
8.5.4 Functional language . 57
8.5.5 Model instantiation process . 57
8.6 Development process and validation/verification of a BIT system . 58
9 Prognosis . 58
9.1 Aim of the prognosis . 58
9.2 Organisation of the prognosis . 59
9.3 Data from BIT for use by the Prognosis . 59
10 Conclusions . 59
Annex A (informative) Examples . 61
A.1 Operational efficiency and performance . 61
A.1.1 General . 61
A.1.2 Example 1: How do you cut down a tree rapidly? . 61
A.1.3 Example 2: How do you cut a slab of butter cleanly? . 61
A.2 Example of calculations for some metrics . 62
A.2.1 General . 62
A.2.2 Calculating detection rates . 66
A.2.2.1 Calculating the FDC (Failure Detection Capability) . 66
A.2.2.2 Calculating the FDP (Failure detection probability) . 67
A.2.3 Calculating isolation rates . 68
A.2.3.1 Calculating the FIP (Failure isolation probability) . 69
n
A.2.3.1.1 General . 69
A.2.3.1.2 Calculating FIP . 69
A.2.3.1.3 Calculating FIP . 70
A.2.3.1.4 Calculating FIP . 70
A.2.3.2 Calculating the FRP (Failure resolution probability) . 70
n
A.2.3.2.1 General . 70
A.2.3.2.2 Calculating FRP . 73
A.2.3.2.3 Calculating FRP . 73
A.2.3.2.4 Calculating FRP . 74
A.3 Correct operation diagnostic vs failure diagnostic. 74
A.4 Example of propagation of the diagnostic values on a simple architecture case . 75
A.5 Ergodicity hypothesis . 82
A.6 Example of calculation for assessing the NFF — No fault found rate . 82
A.7 Timing chart of events . 84
Annex B (informative) List of recommendations . 86
Bibliography . 89
Index . 90

European foreword
This document (EN 9721:2021) has been prepared by the Aerospace and Defence Industries
Association of Europe — Standardization (ASD-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this document has
received the approval of the National Associations and the Official Services of the member countries of
ASD-STAN, prior to its presentation to CEN.
This document shall be given the status of a national standard, either by publication of an identical text
or by endorsement, at the latest by June 2022, and conflicting national standards shall be withdrawn at
the latest by June 2022.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this document: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
A Built-in-test (BIT) is a test carried out exclusively with the hardware and software resources specific
to an item of equipment/system, in order to test it and/or its sub-assemblies, in view of detecting
failures and isolating or even diagnosing them.
System designers are faced with the following questions:
— How do you define a strategy or method for a test built into a system?
— How do you assess the operational efficiency of a system’s BIT architecture? (False alarms, non-
reproducible alarms and false removals)
— How do you obtain a coherent BIT architecture between the various levels of a system? of a system
of systems?
— How do you take into account the needs of the various users of the BIT function bearing in mind
that the implementation, accesses, BIT reports, etc. are specific to the users?
1 Scope
The purpose of this document is to harmonise the dialogue between manufacturers, prime contractors,
owners and the customer in view of making it easier to draw up specifications, share BIT architecture
models and the BIT technical configuration of systems during the operational use phase.
This recommendation proposes adopting BIT operational efficiency and performance definitions,
architecture design principles, and BIT specification or validation principles. It provides no
recommendations regarding the numeric values for operational efficiency or performance. The
diversity of situations, development of technological solutions and ever-changing operational
requirements make it impossible to list general recommendations.
Clause 6 and Clause 9 set out the general context of use of the BIT.
Clause 7 lists the constraints to be taken into account to design a BIT architecture.
Clause 8 lists the various BIT types currently known and the definitions of performance and operational
efficiency (metrics).
Clause 10 provides recommendations on the BIT architecture.
Clause 11 recommends a language for exchanging BIT architecture models for assembling the complete
model of a system.
Clause 12 is an introduction to the prognosis.
This document is mainly intended for system designers.
Although it is based on examples of aeronautic systems, it is applicable to any type of system.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 5577, Non-destructive testing — Ultrasonic testing — Vocabulary
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 5577 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at https://www.electropedia.org/

3.1.1
ambiguity group
associated to a signature and consists of a set of replaceable elements of the system of which at least
one of the failures contributes to this signature but cannot be clearly indentified. Depending on the
maintenance level considered, the replaceable elements may be LRU, SRU, components, etc.; the notion
of ambiguity group refers to the requirement for isolating the failed element on the system tested with a
given maintenance level
3.1.2
cut set
combination of failures, taken from the total list of possible failures (internal or external to the system),
which lead to the loss of a service; it is said to be minimal if by removing any failure from the list, the
service is no longer failing; the size (or degree) of the cut set is the number of elements on the list
EXAMPLE
Figure 1 — Cut set example
In this example, it is presumed that Power supply 1 and 2 are operating as dual redundant parts.
Therefore, the service: “Provide 15 V” is lost in the case both power supplies fail.
There are 2 separate minimal cuts sets that have the same service failure (15 V loss):
— cut set 1: Loss of “Power supply 1” AND Loss of “Power supply 2” (upstream output fails);
— cut set 2: “Power supply board” failure.
However, there are many non-minimal cut sets. For example, the following cut set 3 is not minimal:
— cut set 3: (Loss of “Power supply 1” AND “Power supply board” failure) OR (No loss of
“Power supply 1” AND “Power supply board” failure).
Cut set 2 is preferable over Cut set 3.
3.1.3
defect
non-compliance to a requirement, within the context of a specified or expected use
3.1.4
degradation or failure cause
circumstances related to the design, manufacture and use that resulted in the failure or incident
Note 1 to entry: In this document, it is assumed that there is no system design fault.
[SOURCE: adapted from NF X 60-500]
3.1.5
degradation
gradual and partial change in a system’s ability to complete certain but not all required functions
3.1.6
degraded state
following a degradation (see the definition of “degradation” above), a system
3.1.7
detectability
system’s failure detection capability is assessed for each of the failures that may occur: a failure is
detectable or not
Note 1 to entry: Detectability is a metric that assesses the operational efficiency of an architecture. It takes into
account the operational efficiency of the tests (or presumes total operational efficiency of the tests).
3.1.8
diagnostic
identification of the probable cause of the failure (or failures) using a logical reasoning based on a set of
information coming from an inspection, a control or a test
3.1.9
disturbing test
test that is likely to modify the operational behaviour of the element tested
3.1.10
effect
result of a cause. This effect may be cascaded (domino effect) in the system; it is then a cause in relation
to the effects propagated at the upper level
3.1.11
failure
stopping of a system’s ability to complete the required function; it is observable through its effects (lack
of behaviour) such as the deviation of a physical variable outside of a given tolerance range; it is noted f
in this document
[SOURCE: adapted from NF X 60-500]
3.1.12
failure isolation
(troubleshooting) involves reducing the size of the ambiguity group through observations or additional
tests; the failure isolation process (troubleshooting) is iterative; it ends when the diagnostic stops being
ambiguous and when the troubleshooting is validated
3.1.13
failure sets
in this document, various failure sets (in the mathematical meaning of the term) will be used; they
include
— E: set of all failures: E = HF ∪ SDF = {f } for i from 1 to Card(E),
i
— HF: set of failures caused by the hardware. This set excludes hardware design faults,
— DF: set of failures detectable by the test considered. DF is included in E,
— FE: set of failures that have an effect deemed “to be considered” (for example, with regard to
criticality, a given usage scenario, etc.). FE is included in E. The scope of FE depends on the purpose
of the analysis and therefore on the type of effects: operational, safety, commercial, etc.,
— DFE: set of detectable failures that have an effect deemed “to be considered”. DFE = DF ∩ FE and
— SDF: set of software design failures (whether executed by a micro-processor or by a programmable
component). Theoretically, this set should be empty. Consequently, these software failures are not
considered in the FMECA analyses or in the detection rate calculations. However, experience shows
that they exist and that some of them can be detected by integrity tests.

Figure 2 — Failure sets
— SDF1: Detectable software design faults and that do not have an effect.
— SDF2: Detectable software design faults and that have an effect.
— SDF3: Software design faults that have an effect but that are not detected by integrity tests.
Note 1 to entry: Software design faults will not be considered in the remainder of this document. This document
will focus on the HF set. Consequently, and used somewhat imprecisely, all of the sets that will be mentioned in
the remainder of this document will be understood to be restricted to the intersection with HF.
Note 2 to entry: Mathematical reminder: the cardinal of the set E noted “Card(E)” is the number of elements
constituting this set.
3.1.14
failure signature
exhaustive combination (not minimal) of observable symptoms (OK or NOK results) resulting from the
failure of a service; the signature consists of a core and periphery; the signature core is the combination
of symptoms, always observable, that are sufficient to diagnose the failure; the periphery is the set of
symptoms that may accompany the core (cascade failure phenomenon)
Note 1 to entry: Recommendation 5: With respect to failure signatures, it is important to state whether it is the
signature core (design approach) that is adressed or the signature “core + periphery” set (maintenance approach).
Note 2 to entry: Several failures may have the same signature.
Note 3 to entry: The degree of the signature is n when this signature is associated to an ambiguity group of size n.
3.1.15
fault (Failed state)
internal cause that lead to a failure. In the case of fault, the item is in failed state
Note 1 to entry: The system can continue providing the service for example if its architecture has redundancies.
[SOURCE: adapted from NF X 60-500]
3.1.16
false alarm
result of a decision made between two possible choices (positive and negative), declared as positive,
when it is in reality negative
3.1.17
list of system failures
The list of failures is the set of failures identified during the design stage and enhanced by return of
experience. It may be formalised in a FMECA type form [2]; for each failure, it will also give as a
minimum:
— its occurrence rate (except for the failures which causes are outside the scope of the system
considered);
— its effect(s);
— the LRU/SRU or the resource/condition outside the scope of the system considered
Note 1 to entry: Recommendation 4: The design of the testability and the tests shall be based on the list of
system failures.
Note 2 to entry: The level of detail of the list of failures shall be precise enough to guarantee the relevance of the
values from metrics.
Note 3 to entry: For this, the failure modes of the functions provided by replaceable elements at the chosen
maintenance level should be defined.
3.1.18
operational efficiency
measures either
— the level of result obtained with regard to the effect sought by unit of time or effort to be made by
the operator or
— the time necessary or the degree of effort to be made by the operator to obtain the level of result
expected with regard to the effect sought
Note 1 to entry: Operational efficiency is an operational metric.
Note 2 to entry: Operational efficiency is the result of the performance and context of use:
Operational efficiency = function(Performance, Context)
Note 3 to entry: This notion is illustrated by the example given in A.1.
3.1.19
performance
intrinsic quality of the solution irrespective of the usage contexts; it is a design metric
Note 1 to entry: This notion is illustrated by the example given in A.1.
3.1.20
symptom
physical manifestation of a failure; symptoms can be observed through inspection, through tests or
come from the system’s usage information
EXAMPLE
For example, the failure symptom (landing gear not down) has a NOK result to the test “Is the LG
down?” when the “landing gear up” information is coded following a “lower landing gear” command.
Respectively, the result will be OK if the “landing gear down” information is coded after sending the
command.
Distinction between symptom and test result:
A test result is the coded expression of the result of observation of a symptom.
There are 2 types of test results:
— primary test results: those that result from the direct observation of a symptom;
— summary test results: those that result from an equation that combines other test results (primary
or summary).
Distinction between symptom and coded information
In the landing gear example, the “landing gear not down” symptom originates from a combination of
coded usage information: “lower landing gear” command and “landing gear up” information that do not
come from the BIT.
3.1.21
system failure rate
λ
f
frequency of occurrence of the failure f, expressed in number of occurrences per hour
Note 1 to entry: In the remainder of this document, it is considered that failure rates are constant over time. (This
hypothesis is commonly accepted for electronic systems).
Note 2 to entry: The failure rate λ of a system is assessed based on the failure rates of the set of failures identified
for this system. The system failure rate is equal to the sum of the failure rates for the failures identified for this
system (with the constant failure rate hypothesis).
Note 3 to entry: The system failure rate only applies to the intrinsic failures of the system considered.
3.1.22
technical efficiency
measurement of operational efficiency related to the technical resources necessary for the solution; it is
a design metric
3.1.23
test result
image of the presence or absence of a symptom; the result may take the OK or NOK value
3.1.24
troubleshooting
failure isolation process
3.2 Abbreviations
A table of indexes is provided at the end of the document (Annex C). It is used to find the definitions of
the main terms used in this document.
The abbreviations are explained in Table 1.

Table 1 — Explanation of abbreviations (1 of 2)
Abbreviation Explanation
BIT built-in test
C constraint
CAS crew alert system
CBIT continuous BIT
CO correct operation
COR correct operation rate
COTS commercial off-the-shelf
DBIT demanded BIT
DF detectable failures
DFE detectable failures with effect
DV diagnostic value
E set of failures
EBIT external BIT
F failure
FAR false alarm rate
FCOR false correct operation rate
FDC failure detection capability
FDP failure detection probability
FE failures with effect
FIP failure isolation probability
FM failure modemode
FMECA failure modes, effects and criticality analysis
FNOK false NOK
FOK false OK
FRP failure resolution probability
HF gardware failures
IBIT initiated BIT
LRU line replaceable unit
MBIT maintenance BIT
MC manufacturer code
NFF no fault found
OBIT operational BIT
Table 1 — Explanation of abbreviations (2 of 2)
Abbreviation Explanation
PBIT power-up BIT
SBIT start-up BIT
SDF “software” design fault
SE system engineering
Sn sensitivity
Sp specificity
SRU shop replaceable unit
TNOK true NOK
TOK true OK
UR unreliabilisation rate
4 BIT stakeholders
4.1 BIT specifier
The BIT specifier is responsible for defining the system requirements in terms of ability to detect and
isolate failures, with regard to
— customer requirements related to a project,
— requirements of stakeholders other than the customer and
— technical requirements derived or resulting from internal rules, design and/or return of
experience.
He sends these requirements to designers (including sub-contractors and co-contractors) by means of
technical specifications.
4.2 BIT designer/developer
The team of designers/developers is responsible for designing and developing the BIT for the system
(for the hardware and software elements) in accordance with the specifications.
It will also be responsible for justifying the content of the BIT requirements.
4.3 Operational user
The highest level operational user of the system wants to ensure that the operational functions are
available (nominal situation) and wants to be informed of a malfunction (degraded situation) before
starting a mission but also during a mission in order to react accordingly.
He is involved in the BIT through the alarm function.
4.4 Maintenance engineer
The maintenance engineer is responsible for supporting the system.
Among other things, he carries out the corrective maintenance tasks arising from the BIT results in
order to re-establish this system’s performances.
He shall have the necessary information to isolate the failed elements that he shall then replace/repair.
In some cases, he may be provided with additional prognosis information (that may come from BIT
results) in order to prepare/carry out predictive maintenance, in order to improve the system
availability.
4.5 System technical manager
The two main missions of the system technical manager are to
— ensure the testability requirements are met (detection, isolation and false removal rate, isolation
and test time, etc.) and
— ensure these requirements are taken into account (detection/isolation of failures at the various
maintenance levels)
For this, he has to carry out predictive analyses and testability demonstrations to ensure that the
requirements are met.
4.6 Expert
The expert is responsible for detecting and isolating the failures of a system/item of equipment down to
the lowest level of the maintenance concept, if this was not possible with the built-in-tests.
For this, he uses the built-in-test result (traces, events, statuses, etc.).
Therefore, he is very interested in the built-in-test performances and may hence be one of the
specifiers.
4.7 Field data engineer
The Field data engineer is responsible for analysing all incidents based on information collected on the
system/item of equipment during the operational phase. This is done in order to measure the indicators
(reliability, availability, etc.) or within the framework of a continuous improvement process. For this,
the Field data engineer needs to be aware of the failed elements, the context and the actions carried out
by the maintenance engineer.
Therefore, he is interested in the information contained in the test results (Test OK, NOK, context,
configuration, dating, etc.).
5 System constraints
5.1 System design
In this document, the “System” is considered as being a “technical system” that does not take Humans
and organisations into account.
A system is a set of components that interact with one another and with the environment to produce a
service [7].
A system is designed within a process known as System engineering (SE) which takes into
consideration the components and their interfaces and the system’s life cycle from the initial definition
of the problem to the final removal from service phase [8].
The System design processes include the definition, verification, validation, production, deployment,
operation, maintenance and removal from service. They also include the supporting elements that are
necessary for these processes (test equipment, simulators, etc.) [1].
A system is designed using basic components, often developed by various suppliers that are associated
to the global SE process.
A new basic component shall be developed such that it can be integrated into the system for which it is
initially designed. However, it shall also be able to satisfy certain constraints for adaptability
(reusability, etc.) such that is can be used within other systems (supplier’s portfolio).
In addition, the equipment acquisition strategy of the prime contractor, owner or customer that applies
throughout the system’s life cycle, may include the integration of Commercial Off-the-shelf (COTS)
components that have been modified to reduce development and maintenance costs.
The Top-down process (from the system to the basic components) is combined with the Bottom-up
process, to integrate pre-existing components (COTS) or technologies into the design of a system during
System engineering [9].
The overall System engineering design process applies to a system’s testability and therefore to the
design of the system’s BIT.
5.2 BIT interface function
NOTE This clause describes the functions that use the BIT results.
5.2.1 The alarm function
The aim of a system’s alarm function is to inform the system user of events that disturb the system’s
operation and the context of their occurrence.
Information that is useful for the alarm function translates either the system’s state (defect), or the
monitoring of usage conditions (for example for an aircraft: landing gear up during approach phase,
flaps out with excessive speed, inconsistency of orders received, external event, etc.).
The alarms related to system component failures are from the processing of BIT results.
The alarm function filters data from the monitoring systems and processes the level of urgency for
presenting visual (pictograms, parameter values, etc.) and sound cues to the user as well as
recommendations on the actions to take (messages, check-list, etc.).
For example, in civil aviation, information from electronic computers for monitoring engine and system
parameters (CAS: Crew alert system), is used to display at least two levels of processing urgency (see
[4]) on the electronic display systems:
— minor malfunction messages to be taken into account throughout the remainder of the flight;
— major defects or alarms to be processed urgently by the crew.
The levels of processing urgency translate a level of criticality of the minor or major alarm that
respectively causes
— negligible disturbance of the function, service or mission performed, which could cause hindrances
for the user, losses of redundancy of a non-vital system and
— major disturbance of the function, service or mission performed, which will cause the loss of a
critical function, or of the redundancy of a vital system.
An additional lower level of urgency alarm, that has no impact on the operation, may exist on certain
systems. In this case, this is referred to as “information”.
The Alarm function shall not disturb the system’s operational functioning. It shall draw the user’s
attention at the right time and according to the appropriate level of urgency. The time for displaying
information can also be managed based on the alarm level [5].
Alarm acknowledgement and clearance mechanisms are also processed by the Alarm function.
During operational use, the Alarm function is an input for the system’s “Degraded mode management”
function.
The events (with their occurrence circumstances) are also recorded in “logbooks”. They then provide
the inci
...