oSIST prEN 9722:2022

Aerospace series - Architecture for integrated management of a system's health condition

This recommendation is mainly aimed at all the trades which are actively involved in managing the health of a system.
Although it relies on examples of aeronautical systems, the expert group considers that these general recommendations are of interest for systems from other areas.

Luft- und Raumfahrt - Zentralisierte Architektur für das Zustandssystemmanagement

Série aérospatiale - Architecture pour la gestion intégrée de l’état de santé d’un système

Cette recommandation s’adresse essentiellement à l’ensemble des corps de métier qui sont acteurs de la gestion de l’état de santé d’un système.
Bien qu’elle s’appuie sur des exemples de systèmes aéronautiques, le groupe d’expert considère que ces recommandations générales présentent un intérêt pour les systèmes des autres milieux.

Aeronavtika - Arhitektura za integrirano upravljanje stanja sistema

General Information

• Status: Not Published
• Public Enquiry End Date: 14-Sep-2022
• ICS: 49.020 - Aircraft and space vehicles in general
• Technical Committee: I13 - Imaginarni 13
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 07-Jul-2022
• Due Date: 24-Nov-2022
• Completion Date: 16-Sep-2022
• Ref Project: prEN 9722 - Aerospace series - Architecture for integrated management of a system's health condition

Standards Content (Sample)

SLOVENSKI STANDARD
oSIST prEN 9722:2022
01-september-2022
Aeronavtika - Arhitektura za integrirano upravljanje stanja sistema
Aerospace series - Architecture for integrated management of a system's health
condition

Luft- und Raumfahrt - Zentralisierte Architektur für das Zustandssystemmanagement

Série aérospatiale - Architecture pour la gestion intégrée de l’état de santé d’un système

Ta slovenski standard je istoveten z: prEN 9722
ICS:
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
oSIST prEN 9722:2022 en,fr,de

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN 9722:2022
---------------------- Page: 2 ----------------------
oSIST prEN 9722:2022
DRAFT
EUROPEAN STANDARD
prEN 9722
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2022
ICS 49.020
English Version
Aerospace series - Architecture for integrated
management of a system's health condition

Série aérospatiale - Architecture pour la gestion Luft- und Raumfahrt - Zentralisierte Architektur für

intégrée de l'état de santé d'un système das Zustandssystemmanagement

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

© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9722:2022 E

worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
Contents Page

European foreword ...................................................................................................................................................... 4

Introduction .................................................................................................................................................................... 5

1 Scope .................................................................................................................................................................... 6

2 Normative references .................................................................................................................................... 6

3 Terms and definitions ................................................................................................................................... 6

4 Terminology and acronyms ........................................................................................................................ 6

5 Information on which this document is based ..................................................................................... 9

5.1 Overview of maintenance ............................................................................................................................ 9

5.1.1 Content of the health card ........................................................................................................................... 9

5.1.2 Health card value chain ................................................................................................................................ 9

5.1.3 Use of the health card .................................................................................................................................. 10

5.2 Overview of maintenance .......................................................................................................................... 14

5.2.1 Introduction .................................................................................................................................................... 14

5.2.2 Structuring of maintenance in terms of level of impact ................................................................. 14

5.2.3 Health card and example of coordination between stakeholders .............................................. 14

5.2.4 Health card and predictive maintenance ............................................................................................. 15

5.3 Overview of services engineering ........................................................................................................... 16

5.3.1 Link between system engineering and services engineering ....................................................... 16

5.3.2 Enterprise architecture applied to the support architecture ....................................................... 16

5.3.3 Enterprise architecture modelling ......................................................................................................... 17

5.3.4 Presentation of contact/visibility/control lines ............................................................................... 18

5.3.5 Link between product and services ....................................................................................................... 19

5.3.6 Fundamental constraints and requirements ...................................................................................... 22

6 Recommendations on architectures (ecosystem and product) ................................................... 23

6.1 Introduction .................................................................................................................................................... 23

6.2 Functional architecture centred on the health card ........................................................................ 23

6.3 Example of support organization ............................................................................................................ 25

6.3.1 Introduction .................................................................................................................................................... 25

6.3.2 Stakeholders and roles ............................................................................................................................... 25

6.3.3 Breakdown of support into areas and roles ........................................................................................ 25

6.4 Evolution of the organic value enhancement architecture............................................................ 35

7 Using the health card ................................................................................................................................... 36

7.1 OODA Loop applied to the health condition of a system................................................................. 36

7.1.1 Observe ............................................................................................................................................................. 36

7.1.2 Capitalize ......................................................................................................................................................... 38

7.1.3 Detect ................................................................................................................................................................ 38

7.1.4 Diagnose ........................................................................................................................................................... 38

7.1.5 Predict ............................................................................................................................................................... 39

7.1.6 Decide ................................................................................................................................................................ 39

7.1.7 Act/react .......................................................................................................................................................... 39

7.1.8 Visualize ........................................................................................................................................................... 40

7.2 Capacity projection/Reliability of projections ................................................................................... 40

7.2.1 Introduction .................................................................................................................................................... 40

---------------------- Page: 4 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)

7.2.2 Operational configuration of a system.................................................................................................. 40

7.2.3 Framework of design studies for operational applications for predictive

maintenance (AOMP) .................................................................................................................................. 41

8 Recommendations regarding data ......................................................................................................... 42

8.1 Introduction ................................................................................................................................................... 42

8.2 Cybersecurity ................................................................................................................................................. 42

8.3 Data centralization and digital continuity ........................................................................................... 43

8.4 Obligations of manufacturers with regard to data ........................................................................... 48

9 Conclusion/outlook ..................................................................................................................................... 48

Annex A (informative) Enterprise architecture view of an organization example outside the

Supply Chain ................................................................................................................................................... 50

Annex B (informative) Added value and responsibilities of support stakeholders ............................ 51

Annex C (informative) Illustration of the product and services engineering approach .................... 52

Annex D (normative) Overview of the OODA loop: application to a diagnostic and prognostic

system ............................................................................................................................................................... 53

Annex E (informative) Decontextualisation: an example of degradation and reliability

models .............................................................................................................................................................. 55

E.1 Introduction ................................................................................................................................................... 55

E.2 Fundamental hypotheses ........................................................................................................................... 55

E.3 Framework for a solution to assess the level of degradation and reliability ......................... 55

E.4 Decontextualisation ..................................................................................................................................... 57

E.5 The uses of these models ........................................................................................................................... 58

E.6 Processes in which these models will be used ................................................................................... 58

E.7 Value enhancement architecture ............................................................................................................ 58

E.7.1 For lessons learned ...................................................................................................................................... 58

E.7.2 For design of the maintenance plans ..................................................................................................... 59

E.7.3 For design of aircraft ................................................................................................................................... 59

E.7.4 For predictive maintenance ...................................................................................................................... 59

Annex F (informative) Use case/operational scenarios based on the phases ....................................... 60

F.1 For maintenance, preparation of missions ......................................................................................... 60

F.2 For the pilot, on a mission ......................................................................................................................... 60

F.3 For the manufacturer, the designers ..................................................................................................... 61

Bibliography ................................................................................................................................................................. 64

---------------------- Page: 5 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
European foreword

This document (prEN 9722:2022) 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 is currently submitted to the CEN Enquiry.

Any feedback and questions on this document should be directed to the users’ national standards body.

A complete listing of these bodies can be found on the CEN website.
---------------------- Page: 6 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
Introduction

An equipment health card contains the mandatory deadlines for its maintenance, as well as the history

of maintenance technical operations. This chiefly concerns the log book.

A system health card contains all the health cards for the equipment of which it is comprised. It shall be

managed, on the one hand based on the information contained in each equipment health card, in order

to monitor maintenance scheduling and troubleshooting, and on the other hand based on system

configuration at a given time which results from the equipment exchanges caused, for example, by

system maintenance.

The system health card for the fleet includes all the health cards for the fleet systems.

Data dematerialisation leads to transformation of the business and thus of its internal architecture and

its external interactions, particularly through digital platforms. In addition, the numerous data sources

and their real-time availability give more and more intrinsic value to each data item; their exploitation

enables improved integrated management of the health condition of a system. This integrated

management shall optimize the existing services (data processing or maintenance services

management) or even create some new ones that will be proposed by the various stakeholders (actors)

of the complete ecosystem.

This document provides recommendations about the centralization of the health data for a fleet of

systems, such as an aircraft fleet for example, to ensure consistency between stakeholders (operators,

repair facilities, designers, etc.) and the management of its health card.

These recommendations are based on a generic support organization proposal backed up by a product

architecture for the system and its components.

The recommendations and diagrams in this document are functional and entail no constraints with

respect to the organic architecture.

In this document, it is assumed that system health card access and management have a centralized

address known to all, accessible to every rights holder, and within a time offered by dematerialisation

of data. No assumption is made regarding the location of health card data, which can be decentralised in

a cloud, for example. In this document, the health card is said to be centralized because the rights

holders access it in the same way, at the same address.

Data protection is a major issue, but one that is not dealt with in this document, because it is a more

general question which goes beyond the scope of health card management.
The document is structured in the following way:

General reminders on the health card are given in Clause 5. Clause 6 is the heart of this document and

gives recommendations about system and product architectures. Clause 7 presents the use of the health

card to make fleet maintenance projections. If the reader wishes to explore the subject in greater depth,

Clause 8 gives the precautions to be taken when handling data. Finally, the prospects are proposed in

Clause 9.
---------------------- Page: 7 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
1 Scope

This recommendation is mainly aimed at all the trades which are actively involved in managing the

health of a system.

Although it relies on examples of aeronautical systems, the expert group considers that these general

recommendations are of interest for systems from other areas.
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.

EN 13306, Maintenance — Maintenance terminology

EN 9721, Aerospace series — General recommendation for the BIT Architecture in an integrated system

3 Terms and definitions

For the purposes of this document, the terms and definitions given in EN 9721 apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
4 Terminology and acronyms
The acronyms are explained in Table 1.
Table 1 — Acronyms
Acronym Explanation
A/D Airworthiness Directive
AOG Aircraft On Ground
Predictive Maintenance Operational Applications [Applications Opérationnelles de
AOMP
Maintenance Prévisionnelle]
ASL Logistical Support Analysis [Analyse du Soutien Logistique]
BIT Built-In Test
BNAE Bureau de Normalisation de l’Aéronautique et de l’Espace
CAAC Civil Aviation Administration of China
CAMM Computer Aided Maintenance Management
CAMO Continuing Airworthiness Management Organization
CBM Condition Based Maintenance

Maintenance Report [Compte Rendu de Maintenance] (document containing information

CRM
including failures seen by the pilot in-flight)
CRS Certificate to Release to Service
---------------------- Page: 8 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
Acronym Explanation
DB Database
DMC Direct Maintenance Cost
DOM Director of Maintenance
DRL Data Readiness Level
FIDES Guide to reliability calculations
FMS Fleet Management System
GSE Ground Support Equipment
HAZOP HAZard and OPerability analysis
HUMS Health and Usage Monitoring System
IATA International Air Transport Association
IoT Internet of Things
IVHM Integrated Vehicle Health Management
IVVQ Integration, Verification, Validation and Qualification
KPI Key Performance Indicator
LIS Logistics information system
Implementation and Maintenance Equipment [Matériel de Mise en Œuvre et de
MATMOM
Maintenance]
MCO Maintenance in Operational Conditions
MEL Minimum Equipment List
MFOP Maintenance Free Operating Period
MIMS Maintenance Information Management System
MMS Maintenance Management System
MRO Maintenance Repair and Overhaul
MS Support Equipment [Matériel de Soutien]
NSI Industrial Support Level [Niveau de Soutien Industriel]
NSO Operational Support Level [Niveau de Soutien Opérationnel]
NTI Maintenance Level [Niveau Technique d’Intervention]
OAM Original Aircraft Manufacturer
OEM Original Equipment Manufacturer
OODA Observe, Orient, Decide, Act
ORA Operational Risk Assessment
Operational Readiness Assessment
OSA Open System Architecture
PEDS Prognostic Enhancements to Diagnostic Systems
---------------------- Page: 9 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
Acronym Explanation
PHM Prognostic Health Management
PMA Part Manufacturer Approval (non-OEM parts but approved by the certification
authorities)
RCM Reliability Centred Maintenance
RUL Remaining Useful Life
SB Service Bulletin
SCADA Supervisory Control and Data Acquisition

Integrated structure for maintenance in operational condition of Defence Ministry

SIMAD
aeronautical equipment
Intelligent Predictive Maintenance System [Système Intelligent de Maintenance
SIMP
Prévisionnelle]
SSES Health Monitoring System [Système de Surveillance de l’Etat de Santé]
TRL Technology Readiness Level
WO Work Order
Explanation are given on reccuring terms in Table 2.
Table 2 — Terminology
Terminology Explanation
Aircraft In this document, the term “aircraft” is used to illustrate a system.
Operator The organization comprising the users and administrators.
Refers to an industrial stakeholder which, depending on the context,

Industrial contractor performs either maintenance services, or produces systems (aircraft

for example) and equipment.

Corrective maintenance Technical operations designed to return a faulty system to service.

Preventive maintenance Technical operations designed to prevent failures.
Preventive maintenance based on a prognosis of the level of damage
Predictive maintenance
(see 5.2.4).
Preventive maintenance based on calendar events, or a schedule (also
Scheduled maintenance
called systematic maintenance).
Preventive maintenance based on a level of damage, may be a counter

On-condition maintenance or the result of operating tests (also called condition-based

maintenance).
Owner Owner of the aircraft fleet.
Maintenance service Refers to the service activity.
Maintenance work not stated in the initial work order and which was

Additional works added further to the results of inspections and observations made

during the work requested in this work order.
---------------------- Page: 10 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
Terminology Explanation
Aircraft In this document, the term “aircraft” is used to illustrate a system.
User A person in charge of fleet operation.
5 Information on which this document is based
5.1 Overview of maintenance
5.1.1 Content of the health card
The health card contains the following information (at least):
a) for each aircraft (or more generally system):

1) the aircraft breakdown structure (applied configuration): list of aircraft parts with their serial

numbers,
2) record of overall events (hard landing for example);
b) for each item (aircraft structure, equipment or component):
1) the condition of the service life counters,
2) record of hardware and software configurations,
3) installation record (on which aircraft the item was installed),

4) the record of technical events such as troubleshooting or fault records from the HUMS,

5) maintenance record (the mandatory deadlines can be deduced from this record, along with the

condition of the counters and the manufacturer’s maintenance obligations).
5.1.2 Health card value chain
5.1.2.1 Introduction

Numerous parties are involved in managing the health card, whether for its use or its value

enhancement.
5.1.2.2 The uses of the health card
The uses U of the health card are given below:

— U1: The health card offers the traceability underpinning the aircraft’s airworthiness (CAMO).

— U2: The heath card provides information specific to a system (designated by its serial number) and

needed for scheduling its maintenance.

— U3: The health card provides data for lessons learned for the stakeholders (users, designer, etc.).

Uses U1 and U3 can be seen in the architecture presented in Annex A - View of enterprise architecture

of the non-Supply Chain support organization. Only use U2 is detailed below.
---------------------- Page: 11 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
5.1.2.3 Architecture of the maintenance scheduling value (U2)

Management of the health card participates in control of the use plan through control of the

maintenance plan.

Figure 1 describes the construction of the maintenance plan, the value of which will be enhanced to

allow the use. This view is not truly representative as the process from health card to use is a

continuous loop at all stages:
Figure 1 — Architecture of maintenance value enhancement
5.1.3 Use of the health card
5.1.3.1 Introduction

The health card is of use during the operational and maintenance phases of a system, but the

“upstream” phases can also benefit from the information it contains, i.e. the level of degradation of the

system and its components.

Consequently, an architecture interconnecting the maintenance data in the health card with operational

and industrial data should be adopted, this is described in Figure 2.
The operational data shall be distinguished from the industrial data:

— the operational data are technical data recorded by the system in operation, along with the

environmental data;
— the industrial data are technical design, manufacturing and maintenance data.
---------------------- Page: 12 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)
Figure 2 — Interconnection of the various phases in the lifetime of the system

The health card can be used to optimize the cost of ownership of the equipment concerned, whether to

optimize its use or to optimize the corresponding maintenance operations. In the longer term, the

lessons learned can also help optimize design and manufacturing.
The health condition of an equipment item can be obtained in different ways:
— direct measurement by sensors on the equipment;

— indirect measurement based on direct measurement by means outside the equipment (inspection);

— estimation by means of a model, a digital twin for example, supplied with direct measurements and

readjusted by means of indirect measurements.

Knowledge of the configuration is often essential when associating measurements with an equipment

item.

NOTE The digital twin represents the behaviour and configuration of a real object using operating data

collected in real time. Historically, the digital twin appeared with video games: the driver of a car saw a

representation of the car’s digital twin at the top-right. As this was a game, the player did not have any

proprioceptive information (knowing where one’s body is in space). The digital twin provides the player with

information: skids, jolts, etc. that the player actually feels. With regard to maintenance, the digital twin enables a

remote expert to find out about the degradation condition of the actual object. In principle, the digital twin is

based on a representation model reflecting what the human would observe if in direct contact.

5.1.3.2 Design phase

Analysis of the health card, and more precisely evolution of the degradation of the system and its

components, may make it possible to steer the design of new products (for example improve the

reliability of certain components which degraded too rapidly in the past), through improved knowledge

of use of the products. Study of the health cards can thus make it possible to set targets such as

reliability, testability, etc., for new products.
5.1.3.3 Development/manufacturing phase

Monitoring the health condition as of the prototyping phase (or on the first production runs or during

flight testing) is a means of verifying that during the first hours of operation of a new product, the rate

---------------------- Page: 13 ----------------------
oSIST prEN 9722:2022
prEN 9722:2022 (E)

of degradation is normal. If degradation is too fast, this can indicate a design or manufacturing problem.

Very early in the life cycle, this can thus generate corrective solutions and measures.

One example is the first Concorde, which was fitted out with a host of sensors to verify the correct

working of the various systems.
5.1.3.4 Inte
...