SIST EN 9722:2023

SLOVENSKI STANDARD
01-december-2023
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: EN 9722:2023
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 9722
EUROPEAN STANDARD
NORME EUROPÉENNE
October 2023
EUROPÄISCHE NORM
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 - Architektur für das integrierte
intégrée de l'état de santé d'un système Management eines Systemzustandes
This European Standard was approved by CEN on 4 September 2023.

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, Türkiye 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
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9722:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and acronyms . 6
3.1 Terms and definitions . 6
3.2 Acronyms . 7
4 Information on which this document is based . 9
4.1 Overview of maintenance . 9
4.1.1 Content of the health card . 9
4.1.2 Health card value chain . 10
4.1.3 Use of the health card . 10
4.2 Overview of maintenance . 14
4.2.1 General. 14
4.2.2 Structuring of maintenance in terms of level of impact . 15
4.2.3 Health card and example of coordination between stakeholders . 15
4.2.4 Health card and predictive maintenance . 15
4.3 Overview of services engineering . 17
4.3.1 Link between system engineering and services engineering . 17
4.3.2 Enterprise architecture applied to the support architecture . 17
4.3.3 Enterprise architecture modelling . 18
4.3.4 Presentation of contact/visibility/control lines . 19
4.3.5 Link between product and services . 19
4.3.6 Fundamental constraints and requirements . 23
5 Recommendations on architectures (ecosystem and product) . 24
5.1 General. 24
5.2 Functional architecture centred on the health card . 25
5.3 Example of support organization . 26
5.3.1 General. 26
5.3.2 Stakeholders and roles . 26
5.3.3 Breakdown of support into areas and roles . 26
5.4 Evolution of the organic value enhancement architecture. 37
6 Using the health card . 38
6.1 OODA Loop applied to the health condition of a system. 38
6.1.1 General. 38
6.1.2 Observe . 38
6.1.3 Capitalize . 40
6.1.4 Detect . 40
6.1.5 Diagnose . 41
6.1.6 Predict . 41
6.1.7 Decide . 41
6.1.8 Act/react . 42
6.1.9 Visualize . 42
6.2 Capacity projection/reliability of projections. 43
6.2.1 General . 43
6.2.2 Operational configuration of a system. 43
6.2.3 Framework of design studies for operational applications for predictive
maintenance (AOMP) . 43
7 Recommendations regarding data . 45
7.1 General . 45
7.2 Cybersecurity . 45
7.3 Data centralization and digital continuity . 45
7.4 Obligations of manufacturers with regard to data . 51
8 Conclusion/outlook . 51
Annex A (informative) Enterprise architecture view of an organization example outside the
supply chain . 53
Annex B (informative) Added value and responsibilities of support stakeholders . 54
Annex C (informative) Illustration of the product and services engineering approach . 55
Annex D (normative) Overview of the OODA loop: application to a diagnostic and prognostic
system . 56
Annex E (informative) Decontextualization: an example of degradation and reliability models . 58
E.1 General . 58
E.2 Fundamental hypotheses . 58
E.3 Framework for a solution to assess the level of degradation and reliability . 58
E.4 Decontextualization . 60
E.5 The uses of these models . 61
E.6 Processes in which these models will be used . 62
E.7 Value enhancement architecture . 62
Annex F (informative) Use case/operational scenarios based on the phases . 63
F.1 For maintenance, preparation of missions . 63
F.2 For the pilot, on a mission . 64
F.3 For the manufacturer, the designers . 64
Bibliography . 67

European foreword
This document (EN 9722:2023) 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 April 2024, and conflicting national standards shall be
withdrawn at the latest by April 2024.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. CEN 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,
Türkiye and the United Kingdom.
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 is
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 dematerialization 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 optimizes the existing services (data processing or maintenance services management) or
even creates 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 dematerialization
of data. No assumption is made regarding the location of health card data, which can be decentralized 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 4. Clause 5 is the heart of this document and
gives recommendations about system and product architectures. Clause 6 presents the use of the health
card to make fleet maintenance projections. If the reader wishes to explore the subject in greater depth,
Clause 7 gives the precautions to be taken when handling data. Finally, the prospects are proposed in
Clause 8.
1 Scope
This document 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 this document is
applicable for systems from other areas.
This document specifies 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.
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, definitions and acronyms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 9721 apply.
ISO and IEC maintain terminology 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/
Explanations of recurring terms are given in Table 1.
Table 1 — Terminology (1 of 2)
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 4.2.4).
Table 1 — Terminology (2 of 2)
Terminology Explanation
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.
User A person in charge of fleet operation.
3.2 Acronyms
The acronyms are explained in Table 2.
Table 2 — Acronyms (1 of 3)
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
DB Database
DMC Direct Maintenance Cost
DOM Director of Maintenance
DRL Data Readiness Level
Table 2 — Acronyms (2 of 3)
Acronym Explanation
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
PHM Prognostic Health Management
PMA Part Manufacturer Approval (non-OEM parts but approved by the certification
authorities)
Table 2 — Acronyms (3 of 3)
Acronym Explanation
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 [Structure Intégrée du Maintien en conditions opérationnelles
des matériels Aéronautiques du ministère de la Défense]
Intelligent Predictive Maintenance System [Système Intelligent de Maintenance
SIMP
Prévisionnelle]
SSES Health Monitoring System [Système de Surveillance de l’État de Santé]
TRL Technology Readiness Level
WO Work Order
4 Information on which this document is based
4.1 Overview of maintenance
4.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) 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).
4.1.2 Health card value chain
4.1.2.1 General
Numerous parties are involved in managing the health card, whether for its use or its value
enhancement.
4.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.
4.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
4.1.3 Use of the health card
4.1.3.1 General
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.

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.
4.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.
4.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
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.
4.1.3.4 Integration, Verification, Validation and Qualification phase (IVVQ)
Monitoring the health condition of the system and its components during the IVVQ phases can be used
to enhance the validation process (extremely binary, i.e. OK or NOK) for the functions and performance
of the products, by also focusing on their remaining useful lifetime (or level of degradation). It would
appear legitimate for any equipment item delivered to the customers to be at its full remaining useful
lifetime and the industrial contractor shall therefore ensure that this is the case.
Study of the health card can also explain certain performance non-conformities during the validation
phase, which may be caused by the degradation of certain mechanical components for example.
4.1.3.5 Maintenance phase
The health card will of course be most valuable for maintenance activities. Using the health card can
help:
— to improve the diagnostic by not simply using the result of built-in tests (indicating whether or not
the equipment is operational at a given moment), but also by estimating the level of degradation of
replaceable items;
— to replace scheduled preventive maintenance (based on presumed wear) by predictive
maintenance based on actual degradation;
— to reduce corrective maintenance (random and unpredictable), replacing it with predictive
maintenance right before failure of the equipment. This helps optimize operational availability (by
avoiding failures during missions) and/or reduce support costs through improved scheduling of
maintenance tasks;
— to evaluate and predict the workload of the maintenance crews according to the health condition of
the fleet. Optimization could even go as far as grouping work on products with a similar remaining
useful life [optimization of predicted preventive maintenance steps by means of RUL (Remaining
Useful Life) calculations];
— to optimize the predictive models for supply of replacement equipment (which is profitable for
forward planning of the logistical supply chain);
— to reduce fault propagation following failure of an item not replaced in time (reduced cost of
replacing an item which suffered from the failure of another item and reduced diagnostic time);
— to acquire the necessary information for achieving the best trade-off between support costs and
operational availability;
— to generalize the use of MCO contracts with product operational availability undertakings;
— to forward plan for logistical resources for additional work triggered following inspections carried
out during overhauls (major maintenance carried out by the industrial contractor).
4.1.3.6 Operational phase
The health card can also play a major role in the operation of systems or products. It can help customers
or operators improve how they manage their fleet. This comprises:
— fleet management enabling the licensees to select the most appropriate equipment for the next
missions;
— assets management which, more generally than simple fleet management, allows improved
management of the equipment base (know which equipment is operational, under repair, used for
training, in stock, etc.);
— individual monitoring of the remaining useful life of each product would improve management of
the fleet through optimal tailoring of the product to the exact needs of the type of mission required
by the customer. Each product would thus optimally consume its remaining useful life which would
increase operational availability and optimize maintenance costs.
Whatever the phase in the system lifetime, the non-quantifiable advantages of the above gains are
mainly associated with the human aspect: customer confidence in the support services proposed by the
industrial contractor for their products.
NOTE Annex F presents the use cases and operational scenarios for the different phases.
When preparing for the mission, the operator shall carry out a specified number of missions but will
aim to optimize the distribution of their equipment fleet for these missions in order to ensure that all
the missions are successful while limiting any resulting maintenance costs. The time an equipment item
is used may for example be maximized before a major maintenance operation, by reassigning the
equipment to less severe missions. The operator shall thus be able to extrapolate the impact of a
mission or group of missions on each equipment item, in order to optimize its assignment.
There are two pre-requisites during this operational phase:
— familiarity with the health condition of the equipment before the operational phase and then on a
daily basis (remaining useful life or level of wear, absence of failure early warning signs, etc.).
This acts as the starting point;
— familiarity with the mission profiles and the corresponding degradation trajectories. The types of
uses guided by parameters that influence the equipment's remaining useful life shall be
categorized. Experience will be used to fine-tune the understanding of the equipment's uses and
their impacts. The arrival point (condition of the equipment at the end of the operational phase) is
thus deduced from the starting point and the trajectories.
The missions which are unsuccessful generally lead to unexpected costs (customer compensation, AOG
costs, loss of depreciation, etc.), in addition to the repair costs. Certain degradations causing these
events arrive suddenly with no advance warning and cannot be avoided. Others will lead to symptoms
on the available measurements (weak signals: drift, abnormal noise, etc.), which will provide a means of
alerting the user sufficiently in advance of the mission.
This implies that the time between retrieval of the data, their processing and production of the alert
report is short enough with respect to the dynamics of the equipment’s degradation. These dynamics
shall thus be well-known before attempting to introduce maintenance recommendations.
RECOMMENDATION — A knowledge base should be created, containing the fault and degradation
signatures, along with the forms in which they develop.
The alert reports for physical phenomena shall not be discredited by an excessively high number of
false positives.
Annex E gives a degradation model based on a physical understanding of the phenomena which enables
knowledge to be widely shared and lessons learned to be extensively applied to systems or components
under design.
RECOMMENDATION — Models based on physical explanations should be preferred to ensure the
extensive application of lessons learned beyond the system observed.
Lessons learned play an important role in correcting teething troubles and in determining whether to
re-design the system or optimize maintenance. These decisions are hard to make once costs or savings
are diluted over time, or even borne by stakeholders other than those making the decisions.
4.2 Overview of maintenance
4.2.1 General
The health card comprises all the scheduled maintenance technical operations and those performed
along with the corresponding reports. This is why this clause presents a reminder of the basics of
maintenance.
The purpose of the maintenance studies is to prevent any interruption of service for technical reasons,
by repairing anything that has been degraded.
Scheduling of maintenance is fundamental to operational scheduling.
What should be remembered: the centre of gravity of maintenance is prevention rather than correction.
Its value is to allow operational scheduling.

4.2.2 Structuring of maintenance in terms of level of impact
Maintenance studies are to be examined with respect to the four impacts as specified by specification
S4000P [7] and the safety studies:
1. Maintenance which guarantees the aircraft’s level of safety. This maintenance is part of the
airworthiness limitations.
2. Operational maintenance which targets the aircraft’s required commercial availability at least cost.
3. Economic maintenance, the aim of which is to maintain the value of the aircraft as an asset.
rd
To illustrate this point, maintenance which maintains anti-corrosion protection belongs to the 3 point,
whereas the treatment of damage resulting from corrosion can belong to the airworthiness limits.
4. A fourth type of maintenance is today considered: maintenance designed to control the ecological
impact resulting from operation of the aircraft.
This segregation of maintenance into 4 impacts is fundamental in the process to trace and certify
developments and continuous improvements in the predictive maintenance operational
applications (AOMP).
4.2.3 Health card and example of coordination between stakeholders
The operator aims for the best availability and punctuality of use for a given cost. Maintenance takes
part in ensuring this by above all preventing the use uncertainties arising for technical reasons and,
when this is not enough, by allowing repair with minimal disruption in terms of use.
From the viewpoint of the aircraft’s owner, the residual value of the asset (the aircraft) is an important
factor. This is why the owner is committed to ensuring that the maintenance programme prevents the
propagation of degradation that would prevent the aircraft from being authorized to fly or quite simply
lead to it losing value on the pre-owned market.
A compromise is to be sought at all times between the commercial availability required by the operator
and minimization of the propagation of degradation required by the owner.
The health card is a means of seeing the aircraft’s degradation condition and thus promotes
coordination between operator and owner.
4.2.4 Health card and predictive maintenance
According to standard EN 13306, predictive maintenance shall be on-condition maintenance performed
according to the forecasts extrapolated from the analysis and assessment of the parameters indicating
deterioration of the asset.
The data in the health card are a fundamental input for the analysis and assessment leading to
predictive maintenance.
NOTE The term “predictive maintenance” is used for the French term “maintenance prévisionnelle”.
The uses and the value enhancement architecture of predictive maintenance are presented in 4.1.2.2
and 4.1.2.3.
“The main aim of maintenance is prevention” (according to 4.3.2).
With this in mind, the purpose of predictive maintenance is to personalize the scheduling of technical
operations on the basis of the predictable degradation condition of the aircraft, constructed from their
specific history (design, production, maintenance applied, configuration applied and use) and their
future use and configuration, according to Figure 3.
The expected benefits of predicting the health condition are:
— to characterize just enough work for a use case based on circumstances (not necessarily fixed).
This is the MFOP concept: Maintenance Free Operating Period;
— to group the works according to condition, to minimize down-time and avoid disrupting the use
plan by inserting numerous shutdowns for technical operations;
— to make provision for additional works which, by definition, result from scheduled inspections;
— to prevent or limit degradation which, in propagating, either increases the operator’s maintenance
costs or degrades the value of the asset for the owner.
In the case of an aircraft, predictive maintenance involves CAMO (Continuing Airworthiness
Management Organization) and the operator’s DOM (Director Of Maintenance) (according to 5.3.2).

Figure 3 — The different types of maintenance with respect to the unscheduled or scheduled
issues
4.3 Overview of services engineering
4.3.1 Link between system engineering and services engineering
Management of the health card is a service. This is why this clause presents an overview of services
engineering.
There is a strong link between product engineering, service engineering and process engineering: these
types of engineering are instances of system engineering.
More specifically, the approach, principles and vocabulary of system engineering apply in full to
services engineering: the system architecture steps can be applied to the “services” considering that the
system engineering items or components are the organizations implementing the services
(see Annex C).
4.3.2 Enterprise architecture applied to the support architecture
Management of the health card is a business in its own right, the architecture of which should be
shared. Annex A gives an example.
Enterprise architecture is a systemic view of the business in the form of components. It aims to
standardize the components of the business in order to facilitate assemblies. The architecture methods
aim to implement principles and an architecture framework referred to as the “reference”. This is an
approach that aims to align all the layers within the enterprise (job, functional, application,
technical, etc.) with the enterprise’s strategy. (Wikipedia ref).
Enterprise architecture can address a number of legally independent organizations.
RECOMMENDATION — Enterprise architecture should be used to describe and manage the
interactions between support stakeholders and support companies.
In this document, support is considered as a business in which various stakeholders are coordinated
and that does not belong to any stakeholder.
RECOMMENDATION — The support architecture should be formalized in a rigorous manner, to ensure
consistency between stakeholders.
A support service generally aims to address the following types of needs:
— optimize use capacity (availability, dispatch rate, etc.);
— perform tasks remote from the prime contractor’s core business, for example, managing regulatory
constraints;
— simplify the tasks of the operator.
A long-term service is based on a dynamic process and its model is based on enterprise architecture.

4.3.3 Enterprise architecture modelling
The health card uses services (which will be dealt with in 5.2) for its own management and it is used for
higher-level services
...