SIST EN 9227-1:2025

SLOVENSKI STANDARD
01-julij-2025
Aeronavtika - Vodenje programov - Vodilo za nadzor zanesljivosti in varnosti
Aerospace series - Programme management - Guide to dependability and safety control
Luft- und Raumfahrt - Programm-Management - Richtlinien für die RAMS-Management
Série aérospatiale - Management de programme - Guide pour la maîtrise de la sûreté de
fonctionnement
Ta slovenski standard je istoveten z: EN 9227-1:2025
ICS:
03.100.40 Raziskave in razvoj Research and development
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 9227-1
EUROPEAN STANDARD
NORME EUROPÉENNE
May 2025
EUROPÄISCHE NORM
ICS 49.140
English Version
Aerospace series - Programme management - Guide to
dependability and safety control
Série aérospatiale - Management de programme - Luft- und Raumfahrt - Programm-Management -
Guide pour la maîtrise de la sûreté de fonctionnement Richtlinien für die RAMS-Management
This European Standard was approved by CEN on 7 April 2025.

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
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9227-1:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 List of acronyms . 10
5 Fundamental notions and principles . 12
6 Organizational provisions . 13
6.1 RAMS positioning in relation to the programme . 13
6.2 RAMS resources . 14
6.3 Distribution of the responsibilities for RAMS . 15
6.3.1 Responsibilities of the customer . 15
6.3.2 Responsibilities of the users . 15
6.3.3 Responsibility of the suppliers . 16
6.4 Documentation management . 16
7 Construction of RAMS . 16
7.1 General. 16
7.2 RAMS targets . 17
7.2.1 Responsibilities . 17
7.2.2 Principles for defining and expressing targets . 18
7.3 Technical risk control . 19
7.3.1 General. 19
7.3.2 Identification and analysis of technical risks . 20
7.3.3 Criticality assessment . 20
7.3.4 Prioritization of the identified risks . 21
7.3.5 Selection of unacceptable risks . 21
7.3.6 Reduction of unacceptable risks . 22
7.3.7 Management of technical risks . 23
7.4 Execution logic . 23
7.4.1 General. 23
7.4.2 Activities during the feasibility phase . 24
7.4.3 Activities during the definition and development phases . 24
7.4.4 Activities in the production phase . 25
7.4.5 Activities during the operating phase . 25
7.4.6 Activities during the disposal phase . 26
7.5 Growth of RAMS . 26
7.5.1 General. 26
7.5.2 Integrated RAMS growth programmes . 27
7.5.3 Specific RAMS test and growth programmes . 28
7.6 Documentation of the RAMS studies and digital continuity . 29
7.6.1 Documentation of the RAMS studies . 29
7.6.2 Digital continuity . 30
8 RAMS management . 31
8.1 General principles . 31
8.2 Provisions . 32
8.3 RAMS plan. 32
8.4 Relations with quality assurance . 33
8.5 Relations with system engineering . 33
8.6 Relation with the Integrated Logistics Support (ILS) process . 34
8.7 Relations with the human factors analysis process . 34
8.8 Relations with cybersecurity . 34
Annex A (informative) Example of a RAMS plan template . 36
Annex B (informative) Examples of RAMS requirements in programmes . 37
Annex C (informative) Tasks to be performed in the various phases of a programme. 38
Bibliography . 43

European foreword
This document (EN 9227-1:2025) has been prepared by 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 November 2025, and conflicting national standards shall be
withdrawn at the latest by November 2025.
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
The success of a programme depends on optimizing the compromise between the expected technical
and operational performance of the products, the cost of these products and the lead-time to
realize them.
In this context, products dependability and safety control is a key activity which cannot be separated
from other product performance control or programme management.
This document is thus one of the documents supporting EN 9200 concerning the programme
management specification.
1 Scope
The purpose of this document is to provide customers and their suppliers with a document specifying
the notions of “construction” and “management” of product dependability and safety (RAMS).
It offers programme directors and project managers information likely to help them:
— determine the tasks to be performed and the application procedures, according to the specific
nature of the programme and its goals;
— define and implement the provisions necessary for performing these tasks;
— within programme execution, situate the various tasks involved in constructing and managing the
RAMS of a product.
This document applies to all programmes that involve customer/supplier relation.
RAMS management concerns not only all the products covered by these programmes, but also the
components of these products and the production and support resources and processes to be
implemented.
The provisions of this document can be negotiated at all levels between the parties directly concerned
by a given programme. This implies, on the part of the ordering parties, that each lower level is
provided with the information needed to perform the tasks and meet the specified targets. This also
implies, on the part of suppliers, an escalation of information pertaining to the RAMS results of the
products for which they are responsible.
This document is mainly concerned with the technical aspects, aspects of a legislative (in particular
safety at work and regulatory conformity) and confidential nature are not dealt with in this document.
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 9200, Aerospace series — Programme management — Guidelines for project management
specification
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 9200 and the following 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/
3.1
availability
aptitude of a product to be in a condition to perform a required function in given conditions, at a
given time
Note 1 to entry: This ability depends on the combined aspects of the reliability performance, the maintainability
performance and the maintenance support performance.
[SOURCE: adapted from EN 13306:2017]
3.2
durability
ability of an item to perform a required function, under given conditions of use and maintenance, until
the end of its useful life
Note 1 to entry: Useful life ends with the definitive cessation of use of the entity, and is determined by a limit
state, i.e. when the risk of failure becomes unacceptable or when the entity is considered non-repairable following
a failure. The limit state is linked most often to wear or degradation. An entity may be considered non-repairable
when a repair cost is deemed unacceptable.
Note 2 to entry: In the case of non-repairable equipment, durability and reliability are synonymous. In the case
of repairable equipment, the limit state is decided in relation to economic reasons, a benefit/risk balance, etc.
Note 3 to entry: Not to be confused with sustainable development performance.
Note 4 to entry: Lifetime is the necessary time between commissioning and reaching the limit state.
[SOURCE: adapted from EN 13306:2017 – notes added]
3.3
reliability
aptitude of a product to perform a required function, in given conditions, for a given period of time
Note 1 to entry: It is assumed that the item is in a state to perform this required function at the beginning of the
time interval.
Note 2 to entry: Generally, reliability performance is quantified using appropriate measures. In some applications,
these measures include an expression of reliability performance as a probability, which is also called reliability.
[SOURCE: EN 16601-00-01:2015, 2.3.170 and ISO 10795:2019]
3.4
incident
unexpected event or combination of such events, disrupting a process and likely to have adverse effects
on dependability, safety and security of a product during a phase of its life
EXAMPLE An incident can be:
— a deviation from a specification;
— failure of the test, manufacturing, measuring, implementation, other means and/or procedures;
— failure of the product concerned (in its condition at that time);
— any other unforeseen event or problem.
3.5
maintainability
ability of an item to be maintained in, or restored to, a state in which it can perform as required under
given conditions of use and maintenance
Note 1 to entry: Given conditions of use may include storage.
Note 2 to entry: Given conditions of maintenance include the procedures and resources for use.
Note 3 to entry: Maintainability may be quantified using such measures as mean time to repair, or the
probability of repair within a specified period of time.
Note 4 to entry: Testability (ability to detect failures or their effects and to locate their origin) is a component of
maintainability.
[SOURCE: ISO 10795:2019]
3.6
maintenance
combination of actions allowing to maintain or restore a product in a specified state or in a state which
it is able to perform the required function(s)
Note 1 to entry: Maintenance includes management and supervision activities for support (see EN 9276).
Note 2 to entry: In the operation phase, maintenance contributes to the preservation over time of the safety,
security and availability aptitudes of the product.
3.7
product RAMS maturity
through a RAMS growth process, attainment of complete development of a product when its RAMS
characteristics can be considered stabilized in relation to the specifications
Note 1 to entry: Maturity is the result of a process of gradual elimination of attributable causes of failure on the
product concerned and associated processes (RAMS maturing process). The stabilized level may be higher than
the specifications.
3.8
product
result of activities or processes
Note 1 to entry: Product categories can be services, hardware, software, processed materials, systems,
intermediate work products from elementary activities, such as documents or models.
Note 2 to entry: In the frame of a product developed to satisfy a customer's need, the processes involved are the
expression of the need, the establishment of the definition, the industrialization and the production.
Note 3 to entry: The product can be either a final product to be delivered to a customer (e.g. aircraft, equipment)
or one of its components. In both cases, it represents the supply due under the contract.
Note 4 to entry: Solution and product can be considered synonymous for the purposes of this document.
3.9
life profile
chronological description of the situations in which a physical product is expected to be found, from ex-
factory to disposal
Note 1 to entry: These situations could be: transport, handling, storage, maintenance, preparation for use,
operational use, with all environmental conditions, durations and respective occurrences.
Note 2 to entry: The life profile is described for product/customer or product/job couples. For a given product,
there may be several life profiles depending on the considered concepts of use or deployments.
Note 3 to entry: Not to be confused with lifecycle (which includes life profile).
Note 4 to entry: The disposal phase is part of the lifecycle but is not part of the life profile.
Note 5 to entry: Depending on the organization, the terms “use profile” or “mission profile” may be used.
3.10
robustness
property of a product resulting in a reduced sensitivity of its performance to possible deviations from
the environmental constraints to which it is subjected, to dispersions of its constituent components and
to deviations from its manufacturing processes
Note 1 to entry: Robustness largely results from actions aimed at both obtaining sufficient operating margins
and reducing all forms of variability.
3.11
safety
aptitude of a product, throughout its lifecycle, to guarantee acceptable levels of a risk of accident likely
to injure personnel or lead to a major deterioration of the product or its environment
Note 1 to entry: It is safety in the sense of unintentional events, unlike the notion of security. Therefore,
malevolence is excluded from this definition.
Note 2 to entry: For unacceptable risks, see 7.3.5.
3.12
security
following a malevolent act, aptitude of a product to guarantee, throughout all the phases of its life,
an acceptable level of risk, so as not to cause:
— aggression against the personnel;
— serious damage to the product or its environment;
— a loss of the confidentiality, availability or integrity of data
Note 1 to entry: Cybersecurity is a subset of security, in particular with regard to the above data-related aspects.
3.13
dependability and safety
RAMS
all aptitudes (reliability, availability, maintainability, safety) of a product which enable it to have the
specified functional performances, at the requested time, for the considered duration and without
damage for itself and its environment
Note 1 to entry:
— For the user, this is a guarantee that the product will provide the expected services when they are needed.
— For the company, this is a guarantee that the product to be delivered will retain the specific functional
performance, with an acceptable level of probability.
— For the expert, this means choosing and implementing exactly the right tools and methods for obtaining
RAMS performance.
Note 2 to entry: For certain products, the RAMS concept can be expanded to other aptitudes such as
survivability, invulnerability or durability.
Note 3 to entry: Certain fields of activity do not include the safety aspect.
Note 4 to entry: RAMS takes the interface with security into consideration.
Note 5 to entry: The aggressions of the environment on the product are to be taken into account at the level of
the aptitudes.
3.14
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the
individual constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative
noun, e.g. aircraft system.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer
programs, firmware, technical documentation, services, and personnel required for operations and support to the
degree necessary for self-sufficient use in its intended environment.
[SOURCE: adapted from ISO/IEC/IEEE 15288:2023 – note 2 incomplete]
4 List of acronyms
ADMP Allied dependability management publication
AMSAA United States army material systems analysis activity
ANSSI French national information systems security agency / agence nationale de la sécurité
des systèmes d'information
EUROCAE European organization for civil aviation equipment
CIL Critical items list
CMMS Computerized maintenance management system
CONOPS Concept of operations
DJD Definition justification dossier
DJP Definition justification plan
EBIOS Expression of need and identification of safety objectives / expression des besoins et
identification des objectifs de sécurité
FMEA Failure mode and effects analysis
FMECA Failure modes, effects and criticality analysis
FPS Functional performance specification
FRACAS Failure reporting, analysis and corrective action system
HAZID Hazard identification
HAZOP Hazard and operability analysis
ILS Integrated logistics support
LSA Logistic support analysis
LSA DB Logistic support analysis database
MBSA Model-based safety analysis
MBSE Model-based system engineering
MTBF Mean operating time between failures
MTTR Mean time to restoration
(N)TS (Need) technical specification
PHA Preliminary hazard analysis
PLM Product life management
RAMS Reliability, availability, maintainability, safety (also used as an acronym for safety and
dependability)
RTCA Radio technical commission for aeronautics
SAE Society of automotive engineers
SIL Safety items list
STANREC NATO standardization recommendation
SPF Single point of failure
WBS Work breakdown structure
5 Fundamental notions and principles
The purpose of RAMS activities is to obtain an acceptable level of confidence in the behaviour of the
expected product and its components. These activities are based on analyses, which may be backed up
by tests.
Figure 1 below shows the main enablers of RAMS:

Key
RAMS targets
Other RAMS components
Other RAMS enablers
Figure 1 — The main enablers of RAMS
RAMS performance, expressed in terms of reliability, maintainability (including testability), availability,
and safety, should be considered to be as important as the expected functional performance of the
product. In this respect, the product life is a useful characteristic in the design of the product and is
included in each component of RAMS.
NOTE 1 RAMS is logically a part of the process to achieve the quality of the product. RAMS maturity contributes
to the maturity of the product quality.
NOTE 2 In many systems, safety and availability can appear to be contradictory in certain aspects, with different
actors and need a systemic approach.
The lifetime of the product shall be defined contractually.
RAMS management coordinates the various activities concerning reliability, maintainability,
availability, and safety and manages compromises between the corresponding required characteristics.
By identifying the potential malfunctions of the expected product and the events which could lead to
them, as well as by defining design rules, RAMS activities are primarily a design aid, aimed at obtaining
a product that is robust with respect to the feared events. Given this, RAMS activities participate in
justifying the design of the product. In any case, the results of the various RAMS analyses are included in
the definition justification dossier (DJD) (see EN 9215) of the product concerned.
This approach, employed for the design of a product and continued in production and use, provides the
customer with the supplier's guarantee that it is in control of product technical risks which could
compromise RAMS performance, using the following sequence: identification, evaluation, prioritization,
processing, management.
RAMS activities have an impact on product design, its industrialization, its use and its logistic support.
This RAMS related activities are integrated into the programme activities; they cover the entire lifecycle
of the product concerned, keeps pace with programme scheduling, and are organized and have the
suitable necessary resources.
These RAMS activities are conducted in interface with the various programme management processes,
including configuration management, support engineering and security in particular. Figure 2 below
shows an example of an interface between safety and security applied to the field of
programmable systems.
Figure 2 — The safety and security of programmable systems
6 Organizational provisions
6.1 RAMS positioning in relation to the programme
In order to attain RAMS targets with the best possible cost-efficiency ratio, it is recommended that
stakeholders place each their RAMS activities under the responsibility of a single person designated for
the programme.
The mission of this RAMS manager, using the company's skills network, is:
— to organize RAMS management;
— to establish the RAMS plan consistently with the other elements of the programme
management plan;
— to ensure that RAMS activities are given financing, work packages and the appropriate resources;
— to ensure integration of the RAMS activities consistently with the other programme activities
(see Figure 3).
Figure 3 — The RAMS process linked to the programme
This figure shows the main interactions (not exhaustive) with the other processes of the programme.
At the end of the RAMS process, requirements and/or recommendations may be sent to:
— the teams in charge of development;
— the teams in charge of the support analyses.
The dialogue with these programme teams produces iterations further to the update of the definition
and/or the operating and maintenance procedures.
6.2 RAMS resources
The resources to be allocated to RAMS activities depend on:
— contractual clauses and specified requirements (e.g. RAMS, logistical support);
— design choices;
— cost constraints (design costs, manufacturing costs, operating costs);
— standards, regulatory and operational constraints inherent to the field of activity in which the
product in question is to be used;
— the highlighting of unacceptable risks, throughout the programme period.
These resources are of various types:
— human resources for RAMS management, expertise related to implementation of the various RAMS
tools and/or technical fields concerned;
— IT resources and media for helping with analyses and simulations;
— test resources and objects subjected to specific RAMS tests;
— external expertise, if applicable.
RAMS being a cross-cutting activity with several “silo” activities, RAMS resources differ in their nature
and in the scale of the resources deployed during the various phases of the lifecycle of the product
concerned. The level of expertise, the number of people, the methods and tools used, are, for example,
different in the feasibility phase, in which the analyses concern the system as a whole and are of short
duration (e.g. elaboration of the RAMS plan, allocations, functional analyses, overall knowledge of the
standards context) from what is the case during the production phase, in which the analyses are more
closely targeted on critical products and take place over a longer period.
6.3 Distribution of the responsibilities for RAMS
6.3.1 Responsibilities of the customer
In terms of RAMS activities, the customer is responsible for:
— the expression of technical requirements: definition of the life profile, operating and maintenance
policies, the mission profiles, the environments associated with the life profile situations, the
service functions, the conditions required for the success of the missions (normal and degraded
conditions), quantitative and qualitative RAMS requirements;
— the expression of RAMS management requirements, including the definition of the expected level of
visibility and the exchange formats (e.g. tables, files, tools);
NOTE The level of visibility is the authorization given to the RAMS actors of a program to access all or part
of the information of the program concerned in the customer/supplier relations of the program.
— acceptance of the RAMS plans, the various RAMS study files, the justification files and, more
generally, all contractual supplies established by the first-level supplier.
The customer may take part in a certain number of RAMS tasks (see Annex C).
6.3.2 Responsibilities of the users
The users who deploy the system and contribute to maintaining it in operational condition may, as
system operators, be required to take part in a certain number of RAMS tasks (see Annex C).
They are in particular responsible for acquiring and transmitting – in accordance with predetermined
procedures – experience feedback data relative to RAMS.
6.3.3 Responsibility of the suppliers
With regard to RAMS, the suppliers are in charge of:
— optimizing the tasks concerning inclusion of RAMS requirements and the construction of
products RAMS;
— identifying the resources necessary and how they match the resources available;
— elaborating the RAMS plans, if necessary;
— the traceability of the RAMS requirements assigned to them;
— proposals for compromises, for the customer, between resources, costs and risks linked to
achieving RAMS targets;
— forwarding to their own suppliers the technical requirements and management requirements
linked to RAMS;
— establishing the various RAMS study files, justification files and all contractually
required documents.
6.4 Documentation management
Management of the documentation produced during the RAMS activities, as well as the documents to be
applied and the reference documents, comply with the requirements of the management specification
for the documents required under the contract and are adequate for the others.
The status and type of management of these documents are defined in the management plan, in
response to the management specification.
7 Construction of RAMS
7.1 General
The construction of RAMS results from all those tasks performed by the customer and the supplier,
throughout the programme, to ensure that the product meets the needs of the customer in
terms of RAMS.
The nature and importance of these tasks vary according to programme phasing and scheduling
(see EN 9241).
The tasks performed during the feasibility and definition phases, aimed at achieving a consensus on the
RAMS targets specified for the expected product, are carried out jointly by the customer and the
supplier and are accomplished for the entire duration of the programme.
However, it is up to the supplier to determine those tasks it should carry out during the development,
production, use and removal (e.g. dismantling, scrapping, recycling) phases, and to choose the tools and
methods to be implemented to attain the targets specified for the product to be realized.
These choices depend on:
— the nature of the product concerned;
— the nature of the RAMS requirements specified;
— negotiations with the customer on how to justify the product definition and the realization
processes with regard to these requirements;
— possible areas for optimization, with a view to reducing costs and times, including:
o the various tasks necessary for compliance with the requirements concerning each
RAMS component;
o the various tasks necessary for compliance with the other programme requirements;
— the methods and tools recognized by the customer and the supplier.
The tasks thus selected may be specific to the RAMS activity or may be performed in connection with
other programme activities. In this latter case, the supplier clearly mentions how they are
applied to RAMS.
It is possible to place the RAMS construction tasks in main families:
— tasks allocating targets and establishing design/production/operation rules with respect to RAMS;
— tasks implementing the established rules;
— tasks identifying the RAMS performances achieved (e.g. qualitative or quantitative analyses,
calculations, studies, tests, simulations). Depending on their results, these tasks will lead to the
justification of the product definition or the examination of changes;
— capitalization of the experience (experience feedback) gained in the implementation of the
RAMS approach.
The tasks involved in constructing RAMS are described in the RAMS plan and in the definition
justification plan (DJP), for acceptance by the customer. They also appear in the program work
breakdown structure and in the associated phasing and scheduling plans (e.g. development plan,
qualification plan, production plan).
7.2 RAMS targets
7.2.1 Responsibilities
The customer is responsible for expressing the RAMS targets.
The supplier is responsible for reaching these targets in accordance with:
— the expressed requirements;
— the methods and criteria adopted for justifying that they are reached.
The customer and the supplier agree on the means and methods to be implemented. In a general way, it
is up to the supplier to define the means to be used, although the customer may, for certain
considerations, be required to recommend all or part of these means. These considerations may, for
example, be:
— the supplier's know-how;
— the need to ensure consistency between several suppliers of the same level, particularly in terms of
data and analysis and calculation tools;
— the industrial organization of the programme.
In the RAMS plan, the supplier expresses its understanding of the customer's requirements and the
terms (methods and resources) it intends to implement in order to meet them. This plan is a contractual
document, kept up to date, approved by the supplier and accepted by the customer.
NOTE 1 Non-expression of any safety requirements by the customer does not release the supplier from their
obligation to control the level of intrinsic safety of their product.
NOTE 2 Regarding product liability and the means of production, local regulations and requirements can apply.
NOTE 3 In the event of an incident with the product, the responsibility can be borne by the customer, the user
and/or the supplier.
7.2.2 Principles for defining and expressing targets
RAMS targets are generally determined from the identification of:
— the needs of the user and the environments associated with life profile situations of the system
(or product);
— the feared events and their consequences;
— experience feedback available;
— relevant regulations in force;
— the state of the art and the client's internal rules.
When the RAMS targets are not directly expressed by the customer, the RAMS targets shall be deducted
from more general targets, such as cost of ownership or cost of operation.
RAMS targets can be expressed in various ways:
— quantitative: e.g. probabilities, mean operating time between failures (MTBF), lifetime, mean time
to restoration (MTTR), test coverage rate, time to detect failures;
— qualitative: e.g. design rules, security barriers, documents concerning standards or regulations,
single point of failure criteria, degraded modes.
RAMS targets are accompanied by additional information defining:
— the object concerned by the RAMS targets (e.g. system, device), specifying the excluded elements
(external supplies for example), wherever applicable;
— operation and maintenance policies;
— the environmental conditions;
— the lifecycle phases of the product in question;
— mathematical formulae if necessary (if, for instance, there is a risk of ambiguity);
— experience feedback data, if available.
These targets appear in the functional performance specification (FPS) and the (need) technical
specification [(N)TS] of the products in question (see EN 9208).
NOTE Annex B contains examples of RAMS requirements.
Non-verifiable RAMS targets shall be justified by analyses. To this end, the means of verification and the
hypotheses (justification) shall be defined.
Transmission by the supplier of the RAMS targets to the lower levels, consistently with the
requirements it itself received from its own customer, is done realistically, taking account of state-of-
the-art, the impact on costs, experience feedback and the relevance of certain targets to the specificity
of the lower-level components.
7.3 Technical risk control
7.3.1 General
Control of technical risks is a continuous and iterative process which contributes to the achievement of
the specified RAMS targets, by the knowledge of each risk as early as possible in the programme
sequence. This process is based on quantitative and qualitative approaches and consists in:
— identifying and analysing the potential risks;
— assessing their criticality and their impact on product performance;
— prioritising the identified risks;
— selecting the risks felt to be unacceptable;
— eliminating or reducing these risks;
— managing the residual technical risks.
This risk-based approach applies to the safety aspect in particular.
7.3.2 Identification and analysis of technical risks
A technical risk is associated with a feared event that may occur in precise circumstance in the life of
the product and, the appearance of which is not certain, but the occurrence of which is likely to lead to
non-compliance with the specified targets and/or to non-negligible disruption in use of the product.
This risk can be the result of one or more causes, which can be internal or external to the product.
Identification of each potential risk is a means of revealing:
— the product function(s) affected by this event;
— the impact of this event on product performance, on its environment and on the operators;
— the causes of this event.
Risks identification begins following the functional analysis of the product concerned. It needs a
complete identification of the functions the product shall perform and the best possible knowledge of
its life profile.
The most commonly used techniques for risk identification and analysis are:
— analysis of experience feedback;
— the preliminary hazard analysis (PHA);
— failure modes, effects and criticality analysis (FMECA), hazard identification (HAZID), hazard and
operability analysis (HAZOP);
— fault trees;
— the cause-consequence diagrams.
7.3.3 Criticality assessment
The criticality of a risk is assessed from two components:
— the severity of its consequences (nature of the damage, scope of the loss) in terms of product
operation (expressed either quantitatively or qualitatively);
— the probability of occurrence of the feared event.
The criticality is assessed using severity and probability of occurrence rating scales, chosen according
to the field concerned (see Figure 4).
NOTE The notion of controllability can be introduced, in addition to the severity and the probability of
occurrence of the risk, in order to assess the criticality and to take account of the capability to control the risk in
certain situations or scenarios. Controllability is the capability to avoid damage thanks to the appropriate
reactions of the persons i
...