SIST EN 16602-30:2018

Space product assurance - Dependability

This Standard defines the dependability assurance programme and the dependability requirements for space systems.
Dependability assurance is a continuous and iterative process throughout the project life cycle.
The ECSS dependability policy for space projects is applied by implementing a dependability assurance programme, which comprises:
-   identification of all technical risks with respect to functional needs which can lead to non-compliance with dependability requirements,
-   application of analysis and design methods to ensure that dependability targets are met,
-   optimization of the overall cost and schedule by making sure that:
-   design rules, dependability analyses and risk reducing actions are tailored with respect to an appropriate severity categorisation,
-   risks reducing actions are implemented continuously since the early phase of a project and especially during the design phase.
-   inputs to serial production activities.
The dependability requirements for functions implemented in software, and the interaction between hardware and software, are identified in this Standard.
NOTE 1   The requirements for the product assurance of software are defined in ECSS-Q-ST-80.
NOTE 2   The dependability assurance programme supports the project risk management process as described in ECSS-M-ST-80
This Standard applies to all European space projects. The provisions of this document apply to all project phases.
Depending of the product category, the application of this standard needs to be checked and if needed tailored. The pre-tailoring table in clause 8 contains the applicability of the requirements of this document and its annexes according to product type.
This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00.

Raumfahrtproduktsicherung - Zuverlässigkeit

Assurance produit des projets spatiaux - Sûreté de fonctionnement

La présente norme définit le programme d’assurance de la sûreté de fonctionnement et les exigences de sûreté de fonctionnement pour les systèmes spatiaux.
L’assurance de la sûreté de fonctionnement est un processus continu et itératif mené tout au long du cycle de vie du projet.
La politique de la sûreté de fonctionnement de l’ECSS pour les projets spatiaux est appliquée par le biais de la mise en oeuvre d’un programme d’assurance de la sûreté de fonctionnement qui comprend :
-   l’identification de tous les risques techniques relatifs aux besoins fonctionnels qui peuvent conduire au non-respect des exigences de la sûreté de fonctionnement ;
-   l’application de méthodes d’analyse et de conception afin de garantir que les objectifs de la sûreté de fonctionnement sont atteints ;
-   l'optimisation du coût global et du calendrier en s’assurant que :
-   les règles de conception, les analyses de la sûreté de fonctionnement et les actions de réduction des risques sont adaptées conformément à une catégorisation appropriée de leur gravité ;
-   les actions visant à réduire les risques sont mises en oeuvre de façon continue dès les premières phases d’un projet et plus particulièrement au cours de la phase de conception.
-   des données d’entrée, qui sont fournies aux activités de production en série.
Les exigences de sûreté de fonctionnement pour les fonctions mises en oeuvre dans les logiciels, et l’interaction matériel-logiciel, sont définies dans la présente norme.
NOTE 1   Les exigences de l’assurance produit logiciel sont définies dans la norme ECSS-Q-ST-80.
NOTE 2   Le programme d’assurance de la sûreté de fonctionnement soutient le processus de management des risques du projet tel que décrit dans la norme ECSS-M-ST-80.
La présente norme s’applique à tous les projets spatiaux européens. Les dispositions du présent document s’appliquent à toutes les phases du projet.
Selon la catégorie de produit, l'application de la présente norme doit être vérifiée et, si nécessaire, adaptée. Le tableau de préadaptation fourni à l'Article 8 précise l'applicabilité des exigences spécifiées dans le présent document et dans ses annexes, en fonction du type de produit.
La présente norme peut être adaptée aux caractéristiques et contraintes spécifiques d’un projet spatial, conformément à l’ECSS-S-ST-00.

Zagotavljanje kakovosti proizvodov v vesoljski tehniki - Zagotovljivost

Ta standard opredeljuje program za zagotavljanje zanesljivosti in zahteve za zanesljivost vesoljskih sistemov. Zagotavljanje zanesljivosti je neprekinjen postopek, ki se ponavlja skozi življenjski cikel projekta.  Pravilnik o zanesljivosti ECSS za vesoljske projekte se izvaja z izvedbo programa za zagotavljanje zanesljivosti, ki obsega: • opredelitev tehničnih tveganj, povezanih s funkcionalnimi potrebami, ki lahko povzročijo neskladnost z zahtevami za zanesljivost, • uporabo analiz in metod načrtovanja, da se zagotovi doseganje ciljev glede zanesljivosti, • optimizacijo skupnih stroškov in urnika, in sicer tako, da se zagotovi: – prilagoditev pravil za načrtovanje, analiz zanesljivosti in ukrepov za zmanjšanje tveganj v skladu z ustrezno kategorizacijo resnosti, – neprekinjeno izvajanje ukrepov za zmanjšanje tveganj že v zgodnji fazi načrtovanja, zlasti pa v fazi načrtovanja. • vložke v dejavnosti serijske proizvodnje. V tem standardu so opredeljene zahteve za zanesljivost funkcij, ki se izvajajo s programsko opremo ter interakcije med strojno in programsko opremo. OPOMBA 1: zahteve za zagotavljanje izdelkov ali programske opreme so opredeljene v standardu ECSS-Q-ST-80. OPOMBA 2: program za zagotavljanje zanesljivosti omogoča podporo v procesu obvladovanja tveganja, kot je opisan v standardu ECSS-M-ST-80. Ta standard se uporablja za vse evropske vesoljske projekte. Določila dokumenta veljajo za vse faze projekta. Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS-S-ST-00.

General Information

• Status: Published
• Public Enquiry End Date: 31-Jul-2017
• Publication Date: 13-May-2018
• ICS: 03.120.01 - Quality in general
• ICS: 49.140 - Space systems and operations
• Technical Committee: I13 - Imaginarni 13
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 07-May-2018
• Due Date: 12-Jul-2018
• Completion Date: 14-May-2018
• Mandate: M/496 - Mandate addressed to CEN, CENELEC and ETSI to develop standardisation regarding space industry (Phase 3 of the process)
• Ref Project: EN 16602-30:2018 - Space product assurance - Dependability

Overview

SIST EN 16602-30:2018 - "Space product assurance - Dependability" defines a structured dependability assurance programme and sets dependability requirements for European space systems across all project phases. It frames dependability as a continuous, iterative activity integrated into systems engineering, from mission analysis through disposal. The standard implements the ECSS dependability policy by requiring risk identification, analysis-driven design, and early, sustained risk-reduction actions to meet reliability, availability and maintainability targets.

Key technical topics and requirements

• Dependability programme planning and organisation - Establish a dependability programme plan, roles, documentation and progress reporting for project reviews.
• Risk assessment and control - Identify technical risks tied to functional needs and track mitigation actions across the life cycle.
• Dependability engineering - Capture dependability requirements in technical specifications and apply design criteria (failure tolerance, consequences, severity categorization).
• Criticality classification - Classify functions, hardware and software criticality (including software criticality categories and hardware/operation critical items).
• Dependability analyses - Use formal methods such as reliability prediction, maintainability analysis, availability analysis, common-cause analysis, zonal analysis, contingency analysis and failure detection/recovery analysis.
• Testing, demonstration and data collection - Define reliability/availability/maintainability demonstration plans and dependability performance monitoring.
• Tailoring and applicability - Apply pre‑tailoring matrix per product type and perform controlled tailoring in conformance with ECSS-S-ST-00.
• Software and HW/SW interaction - Identify dependability requirements for software-implemented functions and HW/SW interaction (note: software product assurance requirements are in ECSS‑Q‑ST‑80).
• Support to risk management - The dependability programme complements project risk management (see ECSS‑M‑ST‑80).

Practical applications and who uses it

SIST EN 16602-30:2018 is used to design, verify and assure the dependability of space products and systems. Typical users:

• Systems and reliability engineers drafting dependability plans and performing analyses (reliability, availability, maintainability)
• Project managers and product assurance leads integrating dependability into reviews and schedules
• Software engineers and QA teams addressing software criticality and HW/SW interactions
• Prime contractors, subsystem suppliers and space agencies ensuring compliance across development, production and operations
• Test and operations teams planning demonstrations, data collection and performance monitoring

Related standards

• ECSS‑Q‑ST‑80 (software product assurance) - complements software-specific product assurance aspects.
• ECSS‑M‑ST‑80 (project risk management) - describes project risk management with which the dependability programme must coordinate.
• ECSS‑S‑ST‑00 - provides rules for tailoring ECSS standards for specific project constraints.

Keywords: dependability assurance, space product assurance, dependability programme, space systems, reliability, maintainability, availability, dependability analyses, software criticality, ECSS dependability.

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Zagotavljanje kakovosti proizvodov v vesoljski tehniki - ZagotovljivostRaumfahrtproduktsicherung - ZuverlässigkeitAssurance produit des projets spatiaux - Sûreté de fonctionnementSpace product assurance - Dependability49.140Vesoljski sistemi in operacijeSpace systems and operations03.120.01Kakovost na splošnoQuality in generalICS:Ta slovenski standard je istoveten z:EN 16602-30:2018SIST EN 16602-30:2018en,fr,de01-julij-2018SIST EN 16602-30:2018SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16602-30
April
t r s z ICS
v {ä s v r
English version
Space product assurance æ Dependability
Assurance produit des projets spatiaux æ Sûreté de fonctionnement
Raumfahrtproduktsicherung æ Zuverlässigkeit This European Standard was approved by CEN on
s z September
t r s yä
C 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 and CENELEC memberä
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CENæCENELEC Management Centre has the same status as the official versionsä
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austriaá Belgiumá Bulgariaá Croatiaá Cyprusá Czech Republicá Denmarká Estoniaá Finlandá Former Yugoslav Republic of Macedoniaá Franceá Germanyá Greeceá Hungaryá Icelandá Irelandá Italyá Latviaá Lithuaniaá Luxembourgá Maltaá Netherlandsá Norwayá Polandá Portugalá Romaniaá Serbiaá Slovakiaá Sloveniaá Spainá Swedená Switzerlandá Turkey and United Kingdomä
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels y any means reserved worldwide for CEN national Members and for CENELEC Membersä Refä Noä EN
s x x r tæ u rã t r s z ESIST EN 16602-30:2018

Relationship between dependability activities and project phases . 41 A.1 Mission analysis / Needs identification phase (phase 0) . 41 A.2 Feasibility phase (phase A) . 41 A.3 Preliminary definition phase (phase B) . 41 A.4 Detailed definition and production/ground qualification testing phases (phase C/D) . 42 A.5 Utilization phase (phase E) . 42 A.6 Disposal phase (phase F) . 43 Annex B (informative) Dependability documents delivery per review . 44 Annex C (normative) Dependability plan - DRD . 47 C.1 DRD identification . 47 C.1.1 Requirement identification and source document . 47 C.1.2 Purpose and objective . 47 C.2 Expected response . 47 C.2.1 Scope and content . 47 C.2.2 Special remarks . 48 SIST EN 16602-30:2018

Tables Table 5-1: Severity categories . 17 Table 5-2: Criticality of functions . 19 Table 5-3: Criticality category assignment for software products vs. function criticality . 20 Table 8-1: Definitions of the columns of Table 8-2 . 33 Table 8-2: Pre-Tailoring matrix per “Space product types” . 34 Table B-1 : Dependability deliverable documents per project review . 45 Table L-1 : Common cause check list example for design . 62 Table L-2 : Common cause check list example for design (continued) . 63 Table L-3 : Common cause check list example for environment . 64 Table L-4 : Common cause check list example for unexpected operations . 64
The ECSS dependability policy for space projects is applied by implementing a dependability assurance programme, which comprises: • identification of all technical risks with respect to functional needs which can lead to non-compliance with dependability requirements, • application of analysis and design methods to ensure that dependability targets are met, • optimization of the overall cost and schedule by making sure that:  design rules, dependability analyses and risk reducing actions are tailored with respect to an appropriate severity categorisation,  risks reducing actions are implemented continuously since the early phase of a project and especially during the design phase. • inputs to serial production activities.
The dependability requirements for functions implemented in software, and the interaction between hardware and software, are identified in this Standard. NOTE 1 The requirements for the product assurance of software are defined in ECSS-Q-ST-80. NOTE 2 The dependability assurance programme supports the project risk management process as described in ECSS-M-ST-80 This Standard applies to all European space projects. The provisions of this document apply to all project phases. Depending of the product category, the application of this standard needs to be checked and if needed tailored. The pre-tailoring table in clause 8 contains the applicability of the requirements of this document and its annexes according to product type. This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00.
EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms
EN 16602-10 ECSS-Q-ST-10 Space product assurance —Product assurance management EN 16602-10 ECSS-Q-ST-10-04 Space product assurance – Critical-item control EN 16602-30-02 ECSS-Q-ST-30-02
Space product assurance — Failure modes, effects (and criticality) analysis (FMEA/FMECA) EN 16602-30-11 ECSS-Q-ST-30-11 Space product assurance – Derating - EEE components
failure detection isolation and recovery FMEA failure modes and effects analysis FMECA failure modes, effects and criticality analysis FTA fault tree analysis HSIA hardware-software interaction analysis MTBF mean time between failure MTTR mean time to repair NRB nonconformance review board PA product assurance WCA worst case analysis
b. The dependability assurance process shall be in conformance with the dependability assurance programme plan for the project. 4.2 Organization a. The supplier shall coordinate, implement and integrate the dependability programme management with the PA programme management. 4.3 Dependability programme plan a. The supplier shall develop, maintain and implement a dependability plan for all project phases in conformance with the DRD in Annex C. NOTE
The plan can be included in the PA programme plan. b. The plan shall address the dependability requirements applicable to the project. c. The extent that dependability assurance is applied shall take account of the severity (as defined in Table 5-1) of the consequences of failures. d. The establishment and implementation of the dependability programme plan shall be considered in conjunction with the safety aspects of the programme.
e. The Supplier shall ensure that any potential conflict between dependability and safety requirements are managed.
f. Responsibilities for carrying out all dependability tasks within each phase of the lifecycle shall be defined. SIST EN 16602-30:2018

ECSS-M-ST-80 describes the risk management process. b. Dependability risk analysis reduction and control shall include the following steps: 1. identification and classification of undesirable events according to the severity of their consequences; 2. analysis of failure scenarios, determination of related failure modes, failure origins or causes; 3. classification of the criticality of the functions and associated products according to the severity of relevant failure consequences; 4. definition of actions and recommendations for detailed risk assessment, risk elimination, or risk reduction and control to an acceptable level; 5. status of risk reduction and risk acceptance; 6. implementation of risk reduction; 7. verification of risk reduction and assessment of residual risks. NOTE
The process of risk identification and assessment implies both qualitative and quantitative approaches. c. Risk reduction measures that are proposed for dependability shall be assessed at system level in order to select the optimum solution to reduce the system level risk. 4.5 Dependability critical items a. Dependability critical items shall be identified by dependability analyses performed to support the risk reduction and control process performed on the project.
NOTE
The criteria for identifying dependability critical items to be included in the Critical Items List are given in clause 6.5. b. Dependability critical items, as part of the Critical Items List, shall be subject to risk assessment and critical items control in conformance with ECSS-Q-ST-10-04. c. The control measures shall include: 1. a review of all design, manufacturing and test documentation related to critical functions, critical items and procedures; SIST EN 16602-30:2018

b. All dependability data submitted shall indicate the design baseline and shall be coherent with all other supporting technical documentation. c. All design changes shall be assessed for their impact on dependability and a reassessment of the dependability shall be performed 4.7 Dependability Lessons learnt a. Dependability lessons learnt shall be collected during the project life cycle including operational and disposal phases. NOTE
Dependability lessons learnt consider: • the impact of newly imposed requirements; • assessment of all malfunctions, anomalies, deviations and waivers; • effectiveness of strategies of the project; • new dependability tools and methods that have been developed or demonstrated; • effective versus ineffective verifications that have been performed. 4.8 Progress reporting a. The supplier shall report dependability progress to the customer as part of product assurance activities in conformance with ECSS-Q-ST-10. 4.9 Documentation a. The supplier shall maintain all data used for the dependability programme. SIST EN 16602-30:2018

b. The dependability characteristics shall be traded off with other system attributes such as mass, size, cost and performance during the optimization of the design in all phases of the project.
NOTE
Dependability is an inherent characteristic of a system or product. c. Manufacture, assembly, integration, test and operations shall not degrade dependability attributes introduced into the design. 5.2 Dependability requirements in technical specification a. The dependability requirement specification shall be part of the overall project requirements. b. Dependability requirements shall be apportioned, in a top-down process, to establish dependability requirements for lower level elements.
c. Dependability requirements shall be applied during the preparation and review of design and test specifications.
d. The dependability requirements shall be included into the technical specifications.
NOTE
The technical specifications typically include: • functional, operational and environmental requirements, • test requirements including stress levels, test parameters, and accept or reject criteria, • design performance margins, derating factors, quantitative dependability requirements, and qualitative dependability requirements (identification and classification of undesirable events), under specified environmental conditions, • the identification of human factors and how they can influence dependability during the project lifecycle, SIST EN 16602-30:2018

• the degree of tolerance to hardware failures or software malfunctions,
• the detection, isolation, diagnosis, and recovery of the system from failures and its restoration to an acceptable state, • the requirement for the prevention of failures crossing interfaces with unacceptable consequences, • definition of the maintenance concept, • maintenance tasks and requirements for special skills,
• requirements for preventive maintenance, special tools, and special test equipment, • requirements for process and technology margin demonstration and qualification, • requirement on sampling strategy in serial production and for periodical demonstration of qualification preservation. 5.3 Dependability design criteria 5.3.1 General a. The identification of critical areas of design and the assessment of the severity of failure consequences shall be interpreted by the level at which the analysis is made.
NOTE
The Space System level can be broken down into Space Segment and Ground Segment where separate requirements can be provided. The Space Segment and Ground Segment can be further broken down, dependant on particular contractual requirements, into lower levels elements (e.g. subsystem, equipment…).
b. The success criteria (sometimes referred to as “mission success criteria”) shall be defined at each level to be analysed.
5.3.2 Consequences a. A severity category shall be assigned in accordance with Table 5-1 to each identified failure mode analysed according to the failure effect (consequence).
NOTE
The severity categories are common to dependability and safety. The Table 5-1 is SIST EN 16602-30:2018

NOTE
For example, for analysis at subsystem, and equipment level d. The number identifying the severity category shall be followed by a suffix to indicate either redundancy (R) single point failures (SP) or safety hazards (SH). e. An understanding to these criteria identified in Table 5-1shall be agreed between customer and supplier. Table 5-1: Severity categories Name Level Type of consequences Dependability Safety Catastrophic 1 Failure propagation (Only for lower than system level analysis) (refer to requirement 5.3.2.c) • Loss of life, life-threatening or permanently disabling injury or occupational illness • Loss of system • Loss of an interfacing manned flight system • Loss of launch site facilities • Severe detrimental environmental effects Critical 2 Loss of mission • Temporarily disabling but not life-threatening injury, or temporary occupational illness • Major damage to an interfacing flight system • Major damage to ground facilities • Major damage to public or private property
• Major detrimental environmental effects Major 3 Major mission degradation --- Minor or Negligible 4 Minor mission degradation or any other effect
---
5.3.3 Failure tolerance a. Failure tolerance requirements shall be defined in the performance specifications. SIST EN 16602-30:2018

a. The supplier shall confirm that reliability is built into the design using fault tolerance and design margins.
b. The supplier shall analyse the failure characteristics of systems in order to identify areas of design weakness and propose corrective solutions.
c. In order to implement dependability aspects into the design, the following approaches shall apply: 1. functional design: (a) the preferred use of software designs or methods that have performed successfully in similar applications (b) the implementation of failure tolerance; (c) the implementation of fault detection, isolation and recovery, allowing proper failure processing by dedicated flight and ground measures, and considering detection or reconfiguration times in relation with propagation times of events under worst case conditions; (d) the implementation of monitoring of the parameters that are essential for mission performance, considering the failure modes of the system in relation to the actual capability of the detection devices, and considering the acceptable environmental conditions to be maintained on the product. 2. physical design: (a) the application of proven design rules; (b) the selective use of designs that have performed successfully in the same intended mission environment; (c) the selection of parts having a quality level in accordance with project specification; (d) the use of EEE parts derating and stress margins for mechanical parts; (e) the use of design techniques for optimising redundancy (while keeping system design complexity as low as possible); (f) the assurance that built-in equipment can be inspected and tested; (g) the provision of accessibility to equipment. NOTE
Functional design is intended to imply non-physical design which includes software.
5.4.1 Classification of critical functions, hardware and operations a. During the preliminary design phase, the supplier shall classify functions in accordance with their criticality. b. The classification of the functions, as per requirement 5.4.1a, shall be submitted to the customer for approval. NOTE
The function criticality is documented by FMEA, i.e. by the attributed severity category assigned to the consequences of the functional failure. c. The criticality of functions shall be directly related to the severity of the consequences resulting from failure of the function as defined in Table 5-2. d. The highest identified severity of failure consequences shall determine the criticality of the function. NOTE
Failures can result from a function not executed or executed degraded, incorrectly, untimely, out of the specified time interval, out of sequence or inadvertently. e. The function criticality shall be assigned according to the categories of Table 5-2, without taking into account any compensating provisions. NOTE
Continuing functional decomposition into lower-level functions, to distinguish between functions that could lead to different feared events, is not considered as creating compensating provisions. Table 5-2: Criticality of functions Severity Function criticality Criteria to assign criticality categories to functions Catastrophic (Level 1) I A function that if not or incorrectly performed , or whose anomalous behaviour can cause
one or more
feared events resulting in catastrophic consequences
Critical (Level 2) II A function that if not or incorrectly performed , or whose anomalous behaviour can cause one or more feared events resulting in critical consequences Major (Level 3) III A function that if not or incorrectly performed , or whose anomalous behaviour can cause one or more feared events resulting in major consequences Minor or Negligible (Level 4) IV A function that if not or incorrectly performed , or whose anomalous behaviour can cause one or more feared events resulting in minor or negligible consequences SIST EN 16602-30:2018

For the criticality categorization of software, see clause 5.4.2. g. The criticality classification shall be used to focus efforts on the most critical areas during the project phases. 5.4.2 Assignment of software criticality category a. The criticality category of a software product (A, B, C, D) shall be assigned, based on the criticality assigned to the most critical function it implements, and meeting the criteria defined in Table 5-3 and requirements 5.4.2b to 5.4.2g. b. The criticality category of software products shall be assigned, considering the overall system design, and in particular whether hardware, software or operational means exist, including compensating provisions, which can prevent software-caused system failures or mitigate their consequences. NOTE 1 Compensating provisions include in particular inhibits, monitors, back-ups and operational procedures. NOTE 2 Compensating provisions can be implemented with different objectives, e.g. just making the system safe (fail safe) or keep the system operational (fail operational). c. The effectiveness of the compensating provisions for the purpose of reducing the software criticality category to a lower category than in absence of compensating provisions shall be demonstrated in all conditions, excluding failures of the compensating provisions themselves. d. In all situations there shall be sufficient time for the compensating provisions to intervene in order to prevent or mitigate the subject failure. e. In case the compensating provisions contain software, this software shall be classified at the criticality category corresponding to the highest severity of the failure consequences that they prevent or mitigate. f. Probabilistic assessment of software failures shall not be used as a criterion for software criticality category assignment. g. Any common resources shared by software products of different criticality shall be identified and software criticality allocation confirmed or changed accordingly. Table 5-3: Criticality category assignment for software products vs. function criticality Function criticality Criticality category to be assigned to a software product I Criticality category A if the software product is the sole means to implement the function
5.5 Involvement in testing process a. The supplier shall ensure that dependability aspects are covered in all development, qualification and acceptance test planning and reviews, including the preparation of test specifications and procedures and the evaluation of test results.
b. The dependability discipline shall support: 1. definition of test characteristics and test objectives, 2. selection of measurement parameters, and 3. statistical evaluation of test results. 5.6 Involvement in operational aspects a. The supplier shall ensure that dependability cognizant and qualified staff: SIST EN 16602-30:2018

2. review operations manual and procedures for verification of consistency with dependability analyses. b. Procedures for operations shall be analysed to identify and assess the risks associated with operations, sequences and situations that can affect dependability performance. c. The analyses mentioned in 5.6b shall take into account the technical and human environment, and verify that the procedures: 1. include dispositions to face abnormal situations and supply the necessary safeguard measures; 2. do not compromise equipment reliability; 3. are in accordance with established maintenance dispositions;
4. include dispositions to minimize failures due to human errors. 5.7 Dependability recommendations a. The supplier shall establish and maintain a system to track the dependability recommendations, in order to support the risk reduction process.
NOTE
These recommendations are derived
...