SIST EN 9721:2022
(Main)Aerospace series - General recommendation for the BIT Architecture in an integrated system
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
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 9721:2022
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
SIST EN 9721:2022 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 9721:2022
---------------------- Page: 2 ----------------------
SIST EN 9721:2022
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.
---------------------- Page: 3 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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
2
---------------------- Page: 4 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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
3
---------------------- Page: 5 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
A.2.3.1.1 General . 69
A.2.3.1.2 Calculating FIP . 69
1
A.2.3.1.3 Calculating FIP . 70
2
A.2.3.1.4 Calculating FIP . 70
3
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
1
A.2.3.2.3 Calculating FRP . 73
2
A.2.3.2.4 Calculating FRP . 74
3
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
4
---------------------- Page: 6 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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.
5
---------------------- Page: 7 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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?
6
---------------------- Page: 8 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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/
7
---------------------- Page: 9 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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
8
---------------------- Page: 10 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
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.,
9
---------------------- Page: 11 ----------------------
SIST EN 9721:2022
EN 9721:2021 (E)
— 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 b
...
SLOVENSKI STANDARD
oSIST prEN 9721:2020
01-september-2020
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: prEN 9721
ICS:
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
oSIST prEN 9721:2020 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 9721:2020
---------------------- Page: 2 ----------------------
oSIST prEN 9721:2020
DRAFT
EUROPEAN STANDARD
prEN 9721
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2020
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 draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee ASD-
STAN.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CEN 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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.
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
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9721:2020 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
Contents
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 13
4 BIT stakeholders . 14
4.1 BIT specifier . 14
4.2 BIT designer/developer . 14
4.3 Operational user . 14
4.4 Maintenance engineer . 15
4.5 System technical manager . 15
4.6 Expert . 15
4.7 Field data engineer . 15
5 System constraints . 15
5.1 System design . 15
5.2 BIT interface function . 16
5.2.1 The alarm function . 16
5.2.2 The diagnostic function . 17
5.2.3 Built-in reconfiguration . 17
5.2.4 The maintenance function . 17
5.2.5 The data recording for post analysis function . 18
5.3 System technical states . 18
5.4 Functional modes of a system . 18
5.5 System configuration . 19
5.5.1 Operational configuration of a system . 19
5.5.2 Technical configuration . 19
5.5.3 BIT parameterisation . 19
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) . 21
6.2.3 Continuous BIT (CBIT) . 21
6.2.4 External BIT (EBIT) . 21
6.2.5 Maintenance BIT (MBIT) . 22
6.2.6 Summary of characteristics of the various types of BIT . 23
6.3 The metrics . 24
6.3.1 Role of the mathematical definitions of the metrics . 24
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 . 35
2
---------------------- Page: 4 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
7.1 During development . 35
7.2 During production . 35
7.3 During service . 35
7.3.1 In operational mode . 35
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 . 45
8.4 Specification process . 45
8.4.1 System design arbitrations: Essential objective and effort . 45
8.4.2 The BIT specification process . 48
8.5 Generic modelling and configuration language . 49
8.5.1 Introduction. 49
8.5.2 General information . 51
8.5.3 Description of the language tables . 52
8.5.4 Functional language . 59
8.5.5 Model instantiation process . 60
8.6 Development process and validation/verification of a BIT system . 60
9 Prognosis . 60
9.1 Aim of the prognosis . 60
9.2 Organisation of the prognosis . 61
9.3 Data from BIT for use by the Prognosis . 61
10 Conclusions . 62
Annex A (informative) Examples . 63
A.1 Operational efficiency and performance . 63
A.1.1 Example 1: How do you cut down a tree rapidly? . 63
A.1.2 Example 2: How do you cut a slab of butter cleanly? . 63
A.2 Example of calculations for some metrics . 64
A.2.1 General . 64
A.2.2 Calculating detection rates . 67
A.2.3 Calculating isolation rates . 70
A.3 Correct operation diagnostic vs failure diagnostic . 75
A.4 Example of propagation of the diagnostic values on a simple architecture case . 76
A.5 Ergodicity hypothesis . 83
A.6 Example of calculation for assessing the NFF — No fault found rate . 83
A.7 Timing chart of events . 85
Annex B (informative) List of recommendations . 87
Bibliography . 90
3
---------------------- Page: 5 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
European foreword
This document (prEN 9721:2020) 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 Standard 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 is currently submitted to the CEN Enquiry.
4
---------------------- Page: 6 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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?
5
---------------------- Page: 7 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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
6
---------------------- Page: 8 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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 http://www.iso.org/obp
— IEC Electropedia: available at http://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
7
---------------------- Page: 9 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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]
8
---------------------- Page: 10 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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.
9
---------------------- Page: 11 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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
10
---------------------- Page: 12 ----------------------
oSIST prEN 9721:2020
prEN 9721:2020 (E)
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 m
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.