BS EN 62741:2015
BSI Standards Publication
Demonstration of dependability requirements — The dependability case
BS EN 62741:2015
BRITISH STANDARD National foreword This British Standard is the UK implementation of EN 62741:2015. It is identical to IEC 62741:2015. It supersedes BS 5760-18:2010, which will be withdrawn on 24 March 2018. The UK participation in its preparation was entrusted to Tec Technical hnical Committee DS/1, Dependability Dependability.. A list of organizations represented on this committee can be obtained on request to its secretary secretary.. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. © The British Standards Institution 2015. Published by BSI Standards Limited 2015 ISBN 978 0 580 80390 1 ICS 03.120.01; 21.020; 29.020
Compliance with a British Standard cannot confer immunity from legal obligations.
This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 May 2015.
Amendments/corrigenda Amendments/ corrigenda issued since publication Date
Text affected
BS EN 62741:2015
BRITISH STANDARD National foreword This British Standard is the UK implementation of EN 62741:2015. It is identical to IEC 62741:2015. It supersedes BS 5760-18:2010, which will be withdrawn on 24 March 2018. The UK participation in its preparation was entrusted to Tec Technical hnical Committee DS/1, Dependability Dependability.. A list of organizations represented on this committee can be obtained on request to its secretary secretary.. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. © The British Standards Institution 2015. Published by BSI Standards Limited 2015 ISBN 978 0 580 80390 1 ICS 03.120.01; 21.020; 29.020
Compliance with a British Standard cannot confer immunity from legal obligations.
This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 May 2015.
Amendments/corrigenda Amendments/ corrigenda issued since publication Date
Text affected
BS EN 62741:2015
EUROPEAN STANDARD
EN 62741
NORME EUROPÉENNE EUROPÄISCHE NORM
March 2015
ICS 21.020; 03.120.01
English Version
Demonstration of dependability requirements The dependability case (IEC 62741:2015) Démonstration des exigences de sûreté de fonctionnement - Argumentaire dans le cadre de la sûreté de fonctionnement (IEC 62741:2015)
Leitfaden zur Darlegung von Zuverlässigkeitsanforderung Zuverlässigkeitsanforderungen en - Der Zuverlässigkeitsnachweis Zuverlässigkeitsnachweis (IEC 62741:2015)
This European Standard was approved by CENELEC on 2015-03-24. CENELEC 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 CENELEC member. This European Standard exists in three off icial versions (English, French, German). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions. CENELEC members are the national electrotechnical committees committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Centre: Avenue Marnix 17, B-1000 Brussels
© 2015 CENELEC All rights of exploitation in any form form and by any means reserved worldwide worldwide for CENELEC Members. Ref. No. EN 62741:2015 E
BS EN 62741:2015
EN 62741:2015
-2-
Foreword The text of document 56/1591/FDIS, future edition 1 of IEC 62741, prepared by IEC/TC 56 "Dependability" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as EN 62741:2015. The following dates are fixed: •
•
latest date by which the document has to be implemented at national level by publication of an identical national standard or by endorsement
(dop)
2015-12-24
latest date by which the national standards conflicting with the document have to be withdrawn
(dow)
2018-03-24
Attention is dr awn to the possibility that some of the elements of this document may be the subject of patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such patent rights.
Endorsement notice The text of the International Standard IEC 62741:2015 was approved by CENELEC as a European Standard without any modification. In the official version, for Bibliography, the foll owing notes have to be added for the standards indicated: IEC 60300-3-1
NOTE
Harmonized as EN 60300-3-1.
IEC 60300-3-4
NOTE
Harmonized as EN 60300-3-4.
IEC 61078
NOTE
Harmonized as EN 61078.
IEC 62347
NOTE
Harmonized as EN 62347.
IEC/ISO 31010
NOTE
Harmonized as EN 31010.
IEC 62198
NOTE
Harmonized as EN 62198.
BS EN 62741:2015
-3-
EN 62741:2015
Annex ZA
(normative) Normative references to international publications with their corresponding European publications The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. NOTE 1 When an International Publication has been modified by common modifications, indicated by (mod), the relevant EN/HD applies. NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here: www.cenelec.eu.. www.cenelec.eu
Publication
Year
Title
EN/HD
IEC 60050-192
-
IEC 60300-1
-
ISO 31000
-
International electrotechnical vocabulary - Part 192: Dependability Dependability management -EN 60300-1 Part 1: Guidance for management and application Risk management - Principles and guidelines
Year -
BS EN 62741:2015
–2–
IEC 62741:2015 © IEC 2015
CONTENTS FOREWORD ........................................................................................................................... 4 INTRODUCTION ..................................................................................................................... 6 1
Scope .............................................................................................................................. 7
2
Normative references ...................................................................................................... 7
3
Terms, definitions and abbreviations ............................................................................... 7
4
5
6
7
3.1
Terms and definitions .............................................................................................. 7
3.2
Abbreviations ....... ... ... ........ ........ ............. ............. ........ ............. ............. ............. .... 8
Background to the dependability case ............................................................................. 8 4.1
Principles and purpose ........................................................................................... 8
4.2
Relationship between the dependab ility case and depend ability plans .................... 9
4.3
Progressive assurance of dependability ................................................................ 10
Principles of the dependability case ............................................................................... 11 5.1
Description of the dependability case .................................................................... 11
5.2
Making claims in th e dependability c ase ............................................................... 12
5.3
Using evidence in the dependability case .............................................................. 13
5.4
Evidence framework.............................................................................................. 14
5.5
Dependability case report ..................................................................................... 16
Development of the dependability case .......................................................................... 16 6.1
General ................................................................................................................. 16
6.2
Preparation of the dependability case ................................................................... 17
6.3
Concept stage.......................................................................................................18
6.4
Development stage ............................................................................................... 19
6.5
Realization stage .................................................................................................. 19
6.6
Utilization stage .................................................................................................... 20
6.7
Enhancement stage .............................................................................................. 20
6.8
Retirement stage .................................................................................................. 20
Ass essin g the adequacy of evidenc e ... ... ............. ............. ........ ............. ............. ........ ... 21
Annex A (inform ative) Evidence framework ... ........ ............. ........ ............. ............. ............. ... 22 A.1
General ................................................................................................................. 22
A.2
Abbreviations used only in this annex ... ... ... ... ........ ............. ........ ............. ............. 23
Annex B (inform ative) General r equirements for the dependability c ase repor t ..... ............. ... 40 B.1
General ................................................................................................................. 40
B.2
Elements required for the dependability case report .............................................. 40
B.3
Context and assumptions ...................................................................................... 40
B.3.1
Stakeholders ................................................................................................. 40
B.3.2
System description ........................................................................................ 41
B.3.3
Dependability requirements ........................................................................... 41
B.3.4
Limitations on use ......................................................................................... 41
B.3.5
Assumptio ns ..... ........ ............. ............. ............. ........ ............. ............. ........ .... 41
B.4
Risks .................................................................................................................... 41
B.5
Dependability plan ................................................................................................ 42
B.6
The evidence framework ....................................................................................... 42
B.7
Body of evidence .................................................................................................. 42
B.8
Review of evidence to date ................................................................................... 42
B.9
Dependability claims and argument ....................................................................... 42
BS EN 62741:2015
IEC 62741:2015 © IEC 2015 B.10
–3–
Conclusions and recommendations ....................................................................... 42
Annex C (informative) Check lis t of point s for ass ess ing the adequacy of evide nce ... ... ........ 44 Bibliography .......................................................................................................................... 45 Figure 1 – Illustration of progressive assurance process ....................................................... 11 Figure 2 – The development of claims ................................................................................... 12 Figure 3 – Establishment and developm ent of the evidence framework ................................. 15 Table A.1 – Evidence framework for system “X” .................................................................... 24 Table A.2 – Evidence f ramework for s ystem Y ...................................................................... 28
BS EN 62741:2015
–4–
IEC 62741:2015 © IEC 2015
INTERNATIONAL ELECTROTECHNICAL COMMISSION ______________
DEMONSTRATION OF DEPENDABILITY REQUIREMENTS – THE DEPENDABILITY CASE FOREWORD 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and nongovernmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the t wo organizations. 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees. 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user. 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter. 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by independent certification bodies. 6) All users should ensure that they have the latest edition of this publication. 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications. 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication. 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62741 has been prepared by IEC tech nical committee 56: Dependability. The text of this standard is based on the following documents: FDIS
Report on voting
56/1591/FDIS
56/1609/RVD
Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table. This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
–5–
The committee has decided that the contents of this publication will remain unchanged until the stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to the specific publication. At this date, the publication will be •
reconfirmed,
•
withdrawn, replaced by a revised edition, or
•
•
amended.
BS EN 62741:2015
–6–
IEC 62741:2015 © IEC 2015
INTRODUCTION Dependability is the ability to perform as and when required. Acceptable levels of dependability are therefore essential for continued performance and optimized life cycle costs. In order to achieve dependability of a system, dependability requirements should be established, the risks of not meeting them identified and a suitable set of activities developed to meet and demonstrate the requirements and manage the risks. A dependability case provides a convenient and convincing means of recording the output of these activities in a single location and presenting an argument, supported by evidence, that risks have been treated and that the necessary dependability has been or will be achieved and will continue to be achieved over time. It serves as the main means of communication on dependability among customers, suppliers and other stakeholders and promotes cooperation among them. This is essential for dependability achievement and providing assurance as part of the customer/supplier relationship. Preparing a dependability case can also improve dependability through the actions taken to prepare and develop the argument within the dependability case. It can improve the cost effectiveness of a dependability programme because if an activity does not provide evidence to support the case, this may indicate that the activity is not necessary. The activities required for the achievement of dependability depend on the nature and development state of the system and are likely to vary significantly from one project to another. Throughout this International Standard, the term "dependability" includes all aspects of reliability, availability, maintainability and supportability, as well as other attributes such as usability, testability and durability. In addition, dependability of a system includes all aspects of that system, including components, processes, hardware, software and the interfaces between them. This standard is intended as guidance: the guidelines are not prescriptive in nature, they are generic, they should be tailored to the specific objectives and are not exhaustive. This standard does not address safety or the environment.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
–7–
DEMONSTRATION OF DEPENDABILITY REQUIREMENTS – THE DEPENDABILITY CASE
1
Scope
This International Standard gives guidance on the content and application of a dependability case and establishes general principles for the preparation of a dependability case. This standard is written in a basic project context where a customer orders a system that meets dependability requirements from a supplier and then manages the system until its retirement. The methods provided in this standard may be modified and adapted to other situations as needed. The dependability case is normally produced by the customer and supplier but can also be used and updated by other organizations. For example, certification bodies and regulators may examine the submitted case to support their decisions and users of the system may update/expand the case, particularly where they use the system for a different purpose.
2
Normative references
The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. IEC 60050-192, International Electrotechnical Vocabulary – Part 192: Dependability 1 IEC 60300-1, Dependability management – Part 1: Guidance for management and application ISO 31000, Risk management – Principles and guidelines
3
Terms, definitions and abbreviations
For the purposes of this document, the terms and definitions given in IEC 60050-192, as well as the following, apply. 3.1
Terms and definitions
3.1.1 dependability case evidence-based, reasoned, traceable argument created to support the contention that a defined system does and/or will satisfy the dependability requirements 3.1.2 evidence framework structure identifying what evidence will be/has been produced and when
_____________ 1
To be published.
BS EN 62741:2015
–8–
IEC 62741:2015 © IEC 2015
3.1.3 off-the-shelf OTS non-developmental item of supply that is both commercial and sold in substantial quantities in the commercial marketplace Note 1 to entry:
Sometimes referred to as COTS (commercial off-the-shelf) or MOTS (modified off-the-shelf).
3.1.4 customer party which orders or specifies the item, including the dependability requirements Note 1 to entry: This could be an organization, sponsor, department, company or an individual and can change through the life cycle.
3.1.5 subsystem part of a system, which is itself a system 3.1.6 supplier party which supplies the item, which meets its dependability requirement Note 1 to entry: life cycle.
This could be an organization, department, company or an individual and can change through the
3.1.7 system defined set of items that collectively fulfil a requirement Note 1 to entry: Note 2 to entry: operate.
A system is considered to have a defined real or abstract boundary. External resources (from outside the system boundary) may be required for the system to
Note 3 to entry:
A system structure may be hierarchical, e.g. system, subsystem, component, etc.
Note 4 to entry:
Conditions of use and maintenance should be expressed or implied within the requirement.
3.2
Abbreviations
COTS
Commercial off-the-shelf
FEM
Finite element modelling
FMECA
Failure mode, effects and criticality analysis
FTA
Fault tree analysis
MOTS
Modified off-the-shelf
OTS
Off-the-shelf
4 4.1
Background to the dependability case Principles and purpose
A dependability case provide s a reasoned and traceable argum ent based on evide nce that a system satisfies the requirements and will continue to do so over time. It demonstrates why certain activities have been undertaken and how they can be judged to be successful. For maximum effectiveness it should be initiated at the concept stage, revised progressively during a system life cycle and is typically summarized in dependability case reports at predefined milestones. It records progress in obtaining evidence that dependability requirements are met and remains with the system throughout its life cycle until retirement.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
–9–
The dependability case is of the greatest benefit for high value, low quantity systems where direct evidence of dependability may be difficult or expensive to obtain. Since these systems are often highly complex, involve novel technologies and have wide-ranging stakeholders, an explicit argument is necessary in order to demonstrate their detailed dependability claims with suitable evidence. 4.2
Relationship between the dependability case and dependability plans
Effective management of dependability requires organizational arrangements to implement policy, activities implemented in dependability programmes and plans and processes for performance evaluation, assurance and review. A dependabili ty programm e i nvolves a)
dependability plans, that define the activities, techniques and resources required to achieve dependability,
b)
methods for measurement and assessment,
c)
assurance and review.
The objectives of a dependability plan include ensuring that 1) the dependability requirements of the customer are determined and demonstrated to be understood by both the customer and supplier, 2) activities are planned, agreed and implemented to satisfy and demonstrate requirements and treat the risks of failure,
the
3) the customer is provided with assurance that the dependability requirements are being, or will be, satisfied and that uncertainty in the dependability decr eases over the course of the plan. The dependability case provides progressive assurance that dependability requirements are being or will be satisfied and that uncertainty in the dependability is decreasing. In addition, the case demonstrates that the activities in the plan achieve the requirements and treat the risks. This forms part of the argument and evidence for why the system is, or will be, dependable. The plan is usually based on standards and the organization’s experience in managing dependability and is tailored, taking into account factors such as the relevant life cycle stages, the organization’s context, resources available and the risks that need to be managed. The dependability plan and dependability case are often developed concurrently as both include consideration of the risks of not meeting the requirements. However, the system might meet the dependability requirements but it might not be possible to demonstrate that these requirements have been met. This might be because there is no appropriate activity which can demonstrate that the requirements have been met, or the cost or time required to do so might be excessive. Therefore the dependability plan may also include activities specifically intended to treat the risks of not being able to demonstrate that the requirements have been met and these activities also provide evidence in the dependability case. A register of ris ks produced as part of a dependability case should be coordinated wit h the risks identified as part of planning the dependability programme and with the project risk register. Activities proposed to treat the risks are included in the dependability plan and examined as sources of evidence that risks have been treated. As the dependability plan is implemented, the dependability case is populated with evidence of the successful implementation of the plan. This provides progressive assurance that requirements are being met. If sufficient evidence is not able to be obtained, then the dependability plan should be modified accordingly. In a well managed project, the dependability plan and dependability case are fully integrated with overall project management. In such a project, the use of the dependability case does not incur an increase in overall workload, since the cost of constructing the case is recouped by
BS EN 62741:2015
– 10 –
IEC 62741:2015 © IEC 2015
the saving from avoided miscommunication, avoided reworking caused by late discovery of faults, avoided activities without demonstrable benefits and so forth. In addition, preparing a dependability case assists the development of a cost-effective dependability plan because evidence sought in support of the argument in the dependability case can suggest activities which will improve the dependability plan. In addition, if an activity in the plan is not part of an argument in the dependability case, it should be reviewed to check that it performs a useful function in the plan. (Note that some activities in the dependability plan are included to support other disciplines such as safety which do not normally form part of the dependability case.) The dependability plan and dependability case should be reviewed and updated in the event of significant changes to the following: –
cus tomer requirement s or expectations;
–
envir onment or interfacing s ystems;
–
con ditions of use or des ign intent;
–
des ign;
–
actual per formanc e.
4.3
Progressive assurance of dependability
The dependability case provides an expanding body of evidence which aims to progressively decrease the uncertainty around the achievement of the dependability requirements. However, it is the norm rather than the exception that requirements, environments, etc. change during the system life cycle. Therefore uncertainty might not always decrease. There might be occasions, for example, when a different design option renders a proportion of the evidence obsolete, leading to increased uncertainty. There might also be periods when no evidence is provided, for example during testing prior to the release of test results, when uncertainty remains unchanged. In addition, if new evidence conflicts with the existing evidence, this might increase uncertainty. Figure 1 illustrates two types of product development: new development and MOTS. The vertical axis represents the level of uncertainty identified at any point in the project. As the quantity of dependability evidence increases, the uncertainty generally reduces and progressive assurance is obtained. The horizontal axis represents the time into the project, from the start of the concept stage "a", through start of development "b", to the end of the realization stage "c", end of utilization “d”, and "e", possible enhancement, and beyond.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 11 –
New development solution Modified OTS solution Re-design increases risk Enhancement (technology insertion) increases risk y t n i a t r e c n u y t i l i b a d n e p e D
Plateau (awaiting further evidence)
Evidence increasing Uncertainty reducing
a Concept stage
b Development stage
c Realization
d Entry into utilization
e Enhancement
Time into project
IEC
Figure 1 – Illustration of progressive assurance process At time "a" (start of concept stage) the lev el of uncer tainty is relatively high, but this uncertainty decreases as the project progresses. At time "c", namely at the transition from the realization stage to the utilization stage, the body of evidence is sufficient to assure the dependability to the degree that warrants this transition. The body of evidence (assurance) should continue to build in utilization as successful trials and usage are recorded and the remaining risks can be seen to reduce still further. Having gone through its own new development period, a MOTS solution is often considered less uncertain than new development as in Figure 1, provided all other things are equal. This is not the case for an OTS solution in new applications or in a new environment and a careful re-assessment is required. Finally, many changes to uncertainty will be step-changes rather than progressive changes.
5 5.1
Principles of the dependability case Description of the dependability case
The dependability case starts with an initial statement of dependability requirements. These requirements might include customer’s and supplier’s internal goals, market strategies, regulatory requirements, etc. as well as requirements explicitly stated by the customer. The dependability case then makes a top level claim explicitly stating the contention that the system meets the requirements (see 5.2). The dependability case then provides a multi-level structure of claims, sub-claims and connecting sub-arguments that are ultimately based on evidence (see 5.3) and assumptions. The evidence is presented in the evidence framework (see 5.4) and summarized and referenced in the argument in the dependability case report (see 5.5).
BS EN 62741:2015
– 12 – 5.2
IEC 62741:2015 © IEC 2015
Making claims in the dependability case
The dependability case uses evidence in order to create an argument for the claims that the dependability requirements have been or will be met. Figure 2 illustrates the process of building and arguing the claims in the dependability case using the evidence sources.
Collect evidence from multiple sources
Performance in previous usage
Identify assumptions
Identify context
Design calculations
Testing/trials data and results
Develop reasoned argument that dependability is achieved and risks treated
Simulations results
Analysis results
Expert opinion Assurance that dependability claims are met
Management and development processes
Operational and maintenance data
Component and subsystem dependability cases IEC
Figure 2 – The development of claims An y ass umption s necessary to make the argum ent should be identif ied and explicitl y stated, along with the activities planned to validate them. These might include assumptions regarding the conditions of use, the environment in which the system is used or the nature and type of maintenance. Ar gum ents can f all int o one of two categories: a)
arguments that all identified risks to the claim are eliminated or sufficiently treated, supported by evidence of successful treatments and by evidence that risk identification is comprehensive;
BS EN 62741:2015
IEC 62741:2015 © IEC 2015 b)
– 13 –
arguments that there are sufficient grounds for the claim, supported by evidence of truth of each and by evidence of adequacy.
The former requires that consideration is given to all significant sources of risks, areas of impacts, events (including changes in circumstances) and their causes and their potential consequences. The latter requires that the aspects covered by the evidence are sufficient to provide assurance of the claim. It is also necessary to identify the context and background for which the argument is made as this identifies the limitations of the dependability case. The context includes the stakeholders who might be interested in the system, the objectives and performance requirements, the system being considered and any proposed limitations on the system’s use. Should any of the assumptions or context change, then the argument and claims in the dependability case will need to be reviewed. During the implementation of the dependability plan, the ke y assumptions should be validated, where possible, effectively replacing each with substantiated evidence. Similarly, the contexts in which the argument is made should be validated to match the actual or intended application of the system and the dependability case. From these sources of evidence and explicitly stated assumptions, a reasoned argument demonstrates how the dependability claims are substantiated. Documents and data relating to all of these make up the dependability case. 5.3
Using evidence in the dependability case
Evidence in the dependability case can be of two sorts. The first is direct evidence that the dependability requirements have been demonstrated. The second is evidence that activities designed to treat the risks that the dependability requirements are not met or demonstrated have been successful. A wid e range of sourc es of evidence sh ould be used . T hese can inclu de a)
performance in previous usage/operation,
b)
design or other calculations,
c)
test and trial data results,
d)
simulation results (e.g. FEM or Monte Carlo),
e)
results from analysis (e.g. FMECA and FTA) including predictions and modelling,
f)
expert opinion, including previously recorded success of the supplier,
g)
management and development processes including –
corr ect implementation of best pra ctice ,
–
the management activit ies and s ystems processes follo wed,
h)
operational and maintenance data,
i)
dependability cases of components/subsystems provided by their suppliers.
It can also include evidence from activities and tasks carried out for purposes other than the implementation of the dependability plan, such as safety or logistic support analysis. Before undertaking a dependability activity, its objectives should be fully understood, i.e. how does the activity help achieve dependability, how does it provide evidence for the dependability case, and what are the success criteria for the activity. The success criteria are applied to the records and outputs of the activity to judge if it has achieved its objectives. Evidence that the criteria are met (including the records and outputs) substantiates the claims that the objectives are achieved. Where applicable, the success criteria include that the risks have been adequately treated.
BS EN 62741:2015
– 14 –
IEC 62741:2015 © IEC 2015
Quantified success criteria are preferred as determining success is simpler and less open to interpretation. However, quantified success criteria cannot be produced for all activities. In such cases qualitative criteria based on the objectives of the activity should be defined and should include evidence that the activity, as well as the ouput of the activity, are appropriate and correct. For example, the success criteria for modelling are not simply that the predictions and modelling demonstrate compliance with requirements, but that the model itself is an adequate representation of the system, and that all system or system elements (e.g. software) have been included in the modelling. The model should also address the robustness of the design against variations in usage conditions and manufacturing conditions and manufacturing tolerances. Assurance and evide nce doe s not just result from the outputs of a dependabili ty activit y, but also from the timeliness of the activity and any actions which arise. Undertaking the activity at the appropriate time so that it influences the design of the system is very important and activities should be carried out in parallel with the design process. Therefore, the evidence from an analysis activity should include the documentation showing that the activities and actions have been implemented in a timely manner. 5.4
Evidence framework
The evidence framework presents the evidence used to demonstrate the claims and support the argument and is generally presented as a table. The evidence framework captures the current set of compliance and assurance activities (and their success or acceptance criteria) which demonstrate that dependability is achieved and that risks to dependability have been treated. Figure 3 illustrates the steps to establish and develop the evidence framework. Each dependability case report should base its claims and argument for them on the latest status of the evidence framework.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 15 –
Identify context and stakeholder objectives
Analyse requirements
Managing and treating the risks Identify risks of not demonstrating dependability requirements Demonstrating the dependability requirements
Analyse risks
Identify risk treatments
Implement activities
Review and evaluation
Review and evaluation
Evidence framework A matrix of activities, success criteria, timescales and reports
IEC
Figure 3 – Establishment and development of the evidence framework The evidence framework should be tailored to the project. It will vary through the life cycle but should identify or contain a)
the dependability activities, including measurements and tests, which provide evidence for the dependability case,
b)
the success or acceptance criteria for the evidence,
c)
links to the risks that the activity is intended to treat or the claim which the activity supports (as applicable),
d)
the dates/milestones when the activity should be complete and the evidence available,
e)
references or links to the evidence actually provided,
BS EN 62741:2015
– 16 – f)
IEC 62741:2015 © IEC 2015
confirmation of its acceptance (or rejection) (when applicable).
Annex A contains examples of evidence frameworks. 5.5
Dependability case report
In practice, the collation of all documentation into a single document is unmanageable, particularly where there are many and diverse sources of evidence. An acceptable solution is to present periodic updates to the dependability case as dependability case reports. The dependability case is then the body of accumulated dependability case reports which, in turn, refer to source evidence. Dependability case reports are usually issued at pre-agreed points. They report on the evidence and conclusions drawn from work done so far (referring to papers and data sources where necessary), provide an assessment of overall dependability achievement/progress and a review and evaluation of the dependability activities. At the beginning of each stage, the supplier and customer should agree on the requirements to be satisfied at the end of that stage, i.e. the gate the project must pass before proceeding to the next stage. The agreement may include trade-offs between different competing requirements. The risks arising from this trade-off should be included in the evidence framework. Standards describing processes that could be used to reach robust agreements between customer and supplier are listed in the Bibliography. When required by a contract, they can be used to provide sufficient detail for stakeholders or the customer to make a decision of whether to proceed from one stage of a project life cycle to the next. Annex B contains a description of the possible contents of a dependability case report. The dependability case report can be presented as a narrative document but, if a more formal presentation of the argument is required, there are several techniques available which can be used to structure the argument and claims made from the evidence collected. The Bibliography provides informative references to some techniques.
6 6.1
Development of the dependability case General
This standard primarily describes a project which follows the V-model life cycle where the supplier develops or proposes a system to meet the customer’s requirements and the customer manages it according to the changing needs until its retirement. In projects using other project management processes, such as spiral models or SCRUM models, the requirements are defined as the project progresses and the guidance in this standard should be tailored to each project. However it is still important to agree on the requirements for the next stage and what is required by the end of that stage (e.g. a stable and functional product release). The dependability case does not belong solely to the customer or supplier but is a joint body of evidence which is developed and added to by different parties at different life cycle stages. Developing the dependability case enhances communication between the customer and the supplier. For example, a possible cause of failure to meet customer requirements is lack of understanding by the supplier of customer needs. Treating this risk requires the customer and supplier to communicate to reach a common understanding of requirements. Treating this risk early also minimizes costs.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015 6.2
– 17 –
Preparation of the dependability case
While the dependability case is most effective if started at the concept stage, it may be started at any life cycle stage. This subclause describes the activities which are required at whichever life cycle stage the dependability case is first developed. Subsequent subclauses describe how the dependability case might be developed throughout the project life cycle. For simplicity, it is written in the context of the project starting at the concept stage, where the supplier(s) might develop multiple solutions, one of which is selected by the customer and taken forward through to enhancement and retirement. The development of the dependability case begins with the customer's activities to determine the dependability requirements and their measurement base. Normally, the way these requirements have to be measured is documented as part of the concept stage of a project. IEC 62347 and IEC 60300-3-4 give guidance on the specification of dependability. The customer should include the dependability requirements, including availability, reliability, maintainability and supportability requirements, as part of the system specification that will also include performance and usage. Other requirements such as cost and risk profiles may also be specified. Where necessary, references to other documents or evidence (such as the documents that detail the proposed arrangements for the management of risk, safety, supportability and environment) are also included. The customer should also supply the context for these requirements, from their operating profiles, the role of the project, etc., down to the terminology they employ. Similarly, the customer should clarify all assumptions they made in developing the requirements and expect those which are relevant or appropriate to dependability to be shared with the suppliers. The customer may present these requirements, together with the context and the assumptions, in an initial dependability case report, with references to any pre-existing evidence, such as dependability performance of similar systems or subsystems. The customer might also identify risks to dependability and how they should be treated by either the supplier or customer. This should include inform ation on how the customer will determine that the r isks have been adequately treated. On receipt of the dependability requirements or initial dependability case report from the customer, the supplier should analyse these dependability requirements and plan the activities to satisfy them. This analysis and planning will involve a) gaining a full understanding of the requirements, b) analysing requirements to define system dependability targets, c) considering any existing evidence, d) identifying risks (and transferring to the overall project-level risk register) and how they are to be treated. The requirements that affect system dependability should be analysed to determine their impact at system and subsystem level as the results of these analyses form part of the dependability case. This analysis should include other aspects such as system operation, its environment and the human–machine interfaces, all of which have an impact on system dependability. To gain this understanding, the supplier should be involved in dialogue with the customer to ensure mutual understanding of all aspects. This dialogue results in a definitive statement of the customer’s requirement and all the operational and environmental conditions thereof. This statement gives confidence that the dependability requirements of the customer have been agreed and understood by both the customer and supplier (see 4.2). The customer and supplier should also agree how the risks are to be treated and how the customer will jud ge that the r isk s h ave been adequately treated.
BS EN 62741:2015
– 18 –
IEC 62741:2015 © IEC 2015
From this, the supplier’s dependability design targets and a measurement base are determined. These are design aims, possibly with a margin over the dependability requirement in order to reduce the risk that the requirement will not be met. The dependability activities lead to an evidence framework and a dependability case. The planning of the dependability activities (to be included in the response to the customer) is based on the work required to demonstrate the achievement of dependability requirements. The objective of planning the activities is to provide confidence to the customer and supplier that the risk of failing to meet or demonstrate the achievement of dependability requirements is minimized, before committing resources. However, different types of purchase or project can involve different combinations of life cycle stages and, depending upon the contractual arrangements, the dependability case may be started or completed at the end of any stage. For example, if a customer is buying an OTS system, the development might have been completed sometime earlier and the customer may prepare the dependability case that includes only the realization and utilization stages. Alt ernativel y, the OTS sys tem might provide its own dependability case, which includes the concept and development stages, which can be incorporated or referred to by many customers. However, whichever stage the project begins at, the first dependability case report should include a full assessment of the requirements and the tasks and activities which will be undertaken. 6.3
Concept stage
At the concept stage, the customer should develop an outline set of requirements and may issue an outline dependability case report to the supplier. The customer should also identify risks to be included in the overall project risk register. Where there is a lengthy project, including a significant competitive development stage, then the customer might need to examine the outline requirements to ensure that the proposals from competing suppliers can be assessed for dependability using a common assessment methodology. It is essential that all the dependability stakeholders are consulted at the concept stage to ensure that their requirements are fully captured. Expert advice and the use of dependability modelling techniques are probably necessary to validate that the requirements are suitable and sufficient. It is likely that there will be considerable trade-off between different requirements. For this trade-off, the risks of not demonstrating compliance with the requirements may form a key part of the decision-making process, i.e. if compliance with the dependability requirements cannot be demonstrated, this might be a reason for the option’s rejection. As part of the concept stage, the supplier or customer may move to a single preferred solution, or this might not occur until the development stage. The supplier should analyse the requirements and develop one or more solutions. Risks might be identified at this stage that are common to any potential solution and that require specific and timely treatment. These risks might lead to an initial evidence framework that identifies required minimum assurance activities and these activities might, in turn, form part of the contractual requirements or scope of supply. However, in developing these solutions, the supplier may identify different risks to compliance with the dependability requirements for the different solutions. These should also be presented in the initial evidence framework. The supplier should develop a preliminary set of dependability activities that will demonstrate the satisfaction of the dependability requirements and will treat the risks, based upon the initial evidence framework. This should be presented to the customer in the dependability plan which should outline the design philosophy and principal design features and then identify the differing risks for the proposed designs. In some instances, the risks could be determined using a checklist, but engineering judgement should be a significant input. These risks should
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 19 –
be included with other project risks into the overall project risk management plan. The risks and the plan for their management form part of t he dependability case (see IEC 62198). A dependabili ty case report should be com piled at the end of this stage. It should discuss the development of the plan for providing assurance of dependability and document the jus tific ation for the pro posed activitie s as well as outlini ng the proposed evidenc e to be collected. The objective of providing the customer with an early dependability case report is to demonstrate to the customer that dependability requirements will be met before resources are committed. 6.4
Development stage
At the development stage , the customer wil l generally provide a dependabili ty case for a single preferred solution. It is possible that the dependability requirements will be different to those at the concept stage, due to the trade-off between different requirements, which will require the dependability case to be updated. Through continued analysis of the dependability requirements, the supplier should decide upon a robust design philosophy for the preferred solution. The supplier develops, and places in the evidence framework, the detailed design of the preferred solution, explicit claims that the specific design will meet the requirements and an argument demonstrating how the claims will be substantiated. This should include ensuring that new risks identified while carrying out the activities are fed back to analysis and design at this stage in a timely manner and followed through. If not completed in the concept stage, or if an update is required, the onus is on the supplier to take the initiative and propose dependability design targets and a measurement base. For example, the customer may specify an availability requirement but the supplier needs separate reliability and maintainability targets to develop the system. At the develop ment stage, the supplier should updat e the evide nce framewo rk as development progresses and activities are planned and implemented. The dependability case report compiled at the end of this stage should include a partially completed evidence framework consisting of the current and future dependability activities, their success criteria and the project milestone at which the evidence from these activities will be produced in order to be effective. 6.5
Realization stage
The dependability case in the realization stage is primarily concerned with developing and populating the dependability case as activities are completed and evidence becomes available. If the dependability case has been properly managed during the concept and development stages, significant changes would not be expected to the dependability requirements or risks which have previously been identified. However, new risks might be identified or updated treatments proposed as a result of the completed activities and the evidence produced. The supplier should issue dependability case reports at agreed milestones throughout the realization stage, which should describe how the risks are being treated and provide the customer with increasing confidence that the requirements will be met. The customer’s acceptance of the dependability case reports will generally be o ne of the necessary conditions for interim payments to the supplier. The customer should study the dependability case reports produced by the supplier. They should review the argument and the nature of evidence provided, including the activities undertaken to treat risks, and monitor the progressive achievement of dependability. However if the customer finds the supplier’s progress unsatisfactory, this should be managed by the normal project procedures. The customer should also consider whether there are any
BS EN 62741:2015
– 20 –
IEC 62741:2015 © IEC 2015
additional risks relevant to their particular context and update the dependability case accordingly. At the end of the realiza tion stage, if the customer is sat isf ied with the dependabili ty case, this will indicate that the system is ready to be utilized. 6.6
Utilization stage
Once the system enters the utilization stage it is important that the dependability of the system be monitored and sustained. The dependability case should be updated to reflect the consequences of issues such as differences in the maintenance regime from that assumed, the way users interact with the system in practice or more detailed understanding of the operating environment. The manager of the system when it is in use (whether supplier or customer) should review the argument, assumptions and contextual information on which the dependability case was based and check that all are still valid. This review may be held periodically or may be triggered by pre-defined events. The manager should review the register of risks and add new risks that could arise in use that may not have been considered by the supplier. Evidence from operational usage and/or testing and maintenance should be added to the dependability case. It is possible that more than one organization could use the system in different contexts and develop the dependability cases independently. If the measured or achieved dependability differs significantly from that which was predicted, the possible reasons for this difference should be identified and corrective action undertaken to restore the levels of dependability identified in the requirement(s). If this is not feasible or justifiable, e.g. due to cost, the customer and supplie r co uld agree to revis e th e requirements. If the change in requirements is significant, the customer and original supplier may then return to the concept stage to agree on revised requirements. Alternatively, the customer may initiate the enhancement stage to adapt the system to the changes. The customer and/or supplier should consider whether there are any additional risks relevant to the changes and update the dependability case accordingly. At the end of the utiliza tion stage the expec tation is that the dependability case and evidenc e framework demonstrate that the dependability requirements have been met. 6.7
Enhancement stage
It is often the case that the system requires enhancement during the utilization stage. This might be by the customer, in which case the customer should develop the dependability case. Alternative ly, it might involve contract action on a supplier. If this happens, the supplier should treat the enhancement as a new project, effectively restarting the dependability case from the concept or development stages, but using the previous dependability case as a baseline. The customer’s monitoring actions (see 6.5) and the results should also be captured in the dependability case and the dependability case managed accordingly. 6.8
Retirement stage
For some systems, the retirement stage may also require the dependability case to be updated if, for example, there are specific requirements for disposal and dismantling of the system. The same processes for managing the dependability case should be followed as for previous project stages. It is also at this stage that the achieved dependability of the system can be measured. It is good practice to review the claims and evidence contained within the dependability case to determine whether these have been achieved. This may also provide lessons learnt for future projects.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 21 –
The evidence frameworks and the dependability cases accumulated across successful projects may serve as a library of reusable elements for the organization so should be stored within the organization’s knowledge management system.
7
Assessing the adequacy of evidence
The robustness of the dependability case in making dependability claims is dependent upon the adequacy of the evidence used. The customer should therefore review not only the argument and claims made in the dependability case but also consider the adequacy of the evidence upon which it is based. The adequacy of evidence is primarily a function of its practical impact on the demonstration of dependability, the reduction of uncertainty and the treatment of the risks. Whilst it is not necessary to assess the adequacy of specific, detailed dependability activities in their own right, the visibility, traceability and quality of evidence produced are crucial factors. It is therefore necessary to confirm that the evidence is generated, managed, validated and used within an effective dependability management system. Al l relevan t, availab le inf ormatio n on the dependabili ty achieve me nts and lessons lea rnt from a particular design should be used to provide assurance of dependability within the dependability case. It is not acceptable to ignore evidence which counters the argument being made. The principal criteria for assessing the adequacy of evidence are as follows: a) the evidence as a whole is clearly derived from a properly planned dependability programme; b) the links between any specific item of evidence, a dependability requirement, an activity in the dependability plan and identified risks are clear; c) the evidence is derived from dependability activities carried out by competent people with adequate resources; d) the status of each item of evidence, in terms of its relevance, completeness, accuracy and how it has been used to influence the system and reduce risk, can be readily identified in the evidence framework. In order to assess the adequacy of evidence, it is important to seek traceable methods/techniques, assumptions and detailed results. Consequently, an open, honest dialogue between customer and supplier is important. Judgement is required to assess the evidence presented, including its visibility, traceability and quality in accordance with the criteria listed in this clause. Annex C provides a checklist of generic points which are not prescriptive, but which provide additional guidance on assessing the adequacy of evidence in appropriate circumstances.
BS EN 62741:2015
– 22 –
IEC 62741:2015 © IEC 2015
Annex A (informative) Evidence framework
A.1
General
The evidence framework is defined in 5.4. Example column headings and contents are described as follows: Column no.
Heading
Contents
1
Life cycle stage
Relevant stage in the project life cycle
2
Reference
Reference to the claim Cross-referenced to the project requirements specification or risk register
3
Claim description
Description of the claim supported Coordinated with the project requirements specification or risk register
4
Subclaim
A description of the subclaim Coordinated with the project requirements specification or risk register
5
Evidence required
support the Evidence needed to demonstration of the claim or treat the risks of not meeting the requirements (information, not deliverable reports)
6
Dependability activity
Activity required to generate the necessary evidence (usually a combination of traditional dependability and other activities, i.e. not necessarily an individual dependability activity or technique)
Acceptance criteria 7
Evidence
Deliverable document/contents
8
Time due
Time the evidence is due in order to be effective
Acceptance status 9
Evidence
References to the latest evidence, including issue no. and date delivered
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 23 –
Column no.
Heading
Contents
10
Approval status
Whether approved or not. If rejected, include reasons and corrective action. If accepted, signature of approving authority and date of acceptance
Two examples of partial evidence frameworks are illustrated in Table A.1 and Table A.2. Each covers examples of claims and risks at various stages in the project life cycle, assuming the system involves substantial development activity and at different levels of detail. While each row of the table is complete, neither example evidence framework examines all the expected claims or risks to be treated. Therefore, when creating an evidence framework, the system should be considered in its own right and it is expected that the evidence framework will be substantially longer than the examples given here. However, the layout of the table may be used as a template.
A.2
Abbreviations used only in this annex
BIT
Built-in test
DRACAS
Data recording and corrective action system
HUMS
Health and usage monitoring system
ITEAP
Integrated test, evaluation and acceptance plan
PRAT
Production reliability acceptance test
OMD
Operational and maintenance demonstration
SMART
Specific, measurable, achievable, realistic, time-bound
TDP
Technology development plan
BS EN 62741:2015 – 2 4 –
: e r u t a n g i S
s u t a t s e c n a t p e c c A
l a v s u d o t r a e p t t p s p e A c
e l r l a u t l n i . . a o d e d f n e n k g a l i e t a s g s t c i c e a e g r e e t d n d n d j i e r o a e i e n R C m m R b u
d , e t e a u s e a d t s i a a 1 , d t r 0 f o e e p u z R e s
d e t a b d b 2 t r 0 o e p u y e s s y R I y
e u d t e y t o N
t n u o c y n o s t t l i t r i i c a b i p i a d s l e r A e r p
o t r n o i g i r s p e s d k l e a w c i e e i w t i r v 2 c e r
y l t n e d d e A n C e p w e E e i d v M n e F i r
s e t s t n t l a r e u t s s m e r n e r t o i s m u e e q T d e r
n g i e b , s e l e d l i h A C s s w t i y E a n h b d t i o e : t d M F A a e n t c e c i d g u t C m i i d c v E r o o s n a f M e o r n r F i p d c p
; n s e s t o t s a s s r e e n d e t o o r t S t r i n A o s t u l i e p u p m C e a o p m m r f u i v u p A u d s l s R e o l s i a n o r e D t p a f a v d e n ) D a a
c A
s z R i z n g
: e t a D
” X “ m e t s y s r o f k r o w e m a r f e c n e d i v E – 1 . A e l b a T
: e u s s I
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
" X " m e t s y s r o f k r o w e m a r f
d e r i u q e r e c n e d i v E
m i a l c b u S
e c n e d i v E “ m i a l C
d o i e t s e l r r e t a w i d a i c e o e u i i d t r y i q p r p r v m i e a r s n u c e r T / i , t o n e k w e m e r i u i l i o g d e s w e v i
r r e 2 p e r p d
e c n e d i v E
n o i t c i d l y r t t e n p n e . u y d d o t i l c i n e e p w s b e t a e i r i v d a l n e P e r i r r a n l i o . S o t i d t i m . T r g c s g i e a e O n c i d i f t d , r s o r o l r v t e u n a e t e f t n p e a c s c r m n u y s s e t n n d y u o e r o i e t r o r n c l e i i i o i , s f r l b s p p s a g e t s t a t a m p u t r l i n p r d a e i s x a n a a o u P r u e p i d d c s f t y o l i g s e i n t n b t i a o a n s i i u u r t l o a e r e r c n r t u o s i l s i t t i n c r a s c o n a i f i t p d m r r e t y e r a n b D i p p
o s t d l e o l n b d e n t a a r s e ) o u s c f i o s g B t s i e s d i e o r r d B m a d e c d e t B t o t y e f t a m a r n a r h e a i l t r h i t e e e s b t k r r l t k l l a e i u l u g i s s i i i e n u l i R a f a s f a e R f r m (
f t s o n y e t i l n i b o s a p t i l m o e n e r c e c n h t m i e o s i s i t r n t i e u r l e u q t n o I s m e r
y d l n l f a u d s e n e r a a d f d o o ) s o y ( m o t t i l n e o s r a i r d e u i c t e t l u a i t d l a i r o n e r F c s u t
t n % y e t 9 , u m e 9 d i r s 9 t h u m i : e s d y 4 q ) t t 2 e s e i r e i l y v f i a ( A s i b e i e A c a r l A e h e i e l h c p e v c y f T a s r o c e r
f e R
e l c e y g c a e t s f i L
IEC 627 41: 201 5 © IEC 201 5
) t r n o e f ( m r p o e l d e n v e e T d
r s t e r h f y a t o r r t p n o f u t , f e g o e c n d r m v i f e n i a n t e p t o t s i a i s a i g l a o t e t s t g e t i c n i r a r n e t v d s m i l t e e n n e l o d a u t o e i t s a t ) ) b c
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
s u t a t s e c n a t p e c c A
l a v s u o t r a p t p s A
, e e u s e u t d s i a t , d e f y e t R o
N
: e t a D
: e u s s I
a i r e t i r c e c n a t p e c c a / s s e c c u S
m e t s y s r o f k r o w e m a r f
d o e t r r i o e u i n q r g m i e p i r T / s s e . e k d w u e l i e d e w a v
n 2 i f e r
e c n e d i v E
n g i a a n r e l e l e h a c p i t t e i n n n d u o l o l a o c r c t c i t t n i y n t n e a t e a i c d r r c r y e e i n t e n a t p a s l g a u m t e d e o n b r a p r t i e h h i f m o l u d m c a a t r n e v c i 4 q D a d a a w 2 e r h S a A s g s d t u i l v e o a n c e c r g C s a f A h o g e n n R t i p n d a t e r D o l n r i r f o f e c t n p o e p t o o a n i n a g i e s s p n n i o r i o o i t a m a t s b t l r r a m c y e m o r f o e l a v r p e d r f t e o e p n e e a n a D f r o a p d a d
e u d t e y t o N
e u d t e y t o N
e u d t e y t o N
y r t n e r e t f a e r s a u e y t o 1 i n
o t r n o i g i r s p e s d k l e a w c i e e i w t i r v 6 c e r
w e i o t v r e o r i r n g p i s s k e e d e l w a n 6 i f
s e t s t n t l a r e u t s s m e r n e r t o i s m u e e q T d e r
. y f s e h : k t o c n s e n h t r r c e l t h i o e g a r f t s h m u d h i i e t t e t s c . u s n a a d w h T n s s c e I o r h c s t t y i i n l d g w t n . u a B e t o e i e l i m i g y n v n i l g t n e e p u s o a d u o h i s i n o i i b e i - i t n e t r t t n r i r w t a t s t r g v u c n a a e o e o s a d q t c t r n r h h e t n e a o i o o n n u I p t s t s c f a r S C D L
. s T I ; k t B r c a o e f h t n h h t i o s c . s i s w t t w i s n a o m y t e s c i u h e t n . u t o l i n t e m l t e p u s a s s i o u i v t s i n o r y b t i i n r e o s a s u t t g a r t T a n a c q t e s n o i I p o e o B e r h t t c e r S C D L T I e B d e i f o h v t o n f r o o p i o t n t a e o l u g i A s a a n C v r e E e e t x M n v o E F a c n k i y s t g i i r l n t ( i i b y l t l o d a g a u n e t e c s t v s t e e a i t e n i t r i e h r r t t s c c ) s a n m a E s i e h o t n r g E t i g e s E k i u c s i s s e i n q n f i e e u r b e R d m f r s s e e d i f i t o n m e d e r i u l y i t i a l i f b l a a t c s i t e i r T c
d e r i u q e r e c n e d i v E
g n f i r o u d n o y i i t t l a r i b n t a o s d t n n i o e a z i m p l e e i t D d u
t d e n h e e g i g p i o ( s l s l l a e e n e v A d h o t i t e C ) T . I i n c d E 1 1 y M B y n . u h F 1 w g f c e t e e r e i i m a h r h v r a t t a e l e t f i n C R s o h i t o r k y n / o i s t i i n l r i e g d ( b r n n a a i a t m t s l e s t u e t o t i e c n r s n t e e o n g ) t r o a r e i n D a m d p m t e h m p D t i r i e r r o D o t f e f k u i r s e c s q r h t i e i e u c f R e r v e p c a e r
m i a l c b u S
e s s u m r n i o f r d e t e p c n i o d i e t u r p l o s S a
s n l n g l i o a s s i t e t c d s n u e f y t t i l d y i b g e r e i a t t u s a r q e t T s e r
y t i l i y b t a i v d i n t e c p a e D
" X "
– 25 –
e c n e d i v E “ m i a l C
e r f a e r s t t n T e I n B e d m m e e r m e i r v e i e u ) t i u C s q h q e C y c r S e r a ( C
f e R
e l c e y g c a e t s f i L
) t r n o e f ( m r p e o ) . d l t n e n v e e o c T d (
BS EN 62741:2015 – 2 6 –
: e r u t a n g i S
s u t a t s e c n a t p e c c A
l a v s u o t r a p t p s A
d e t p e c c A e u d t e y t o N
d e t a d d d 1 t r 0 o e w p u e s s w R i w
e u d t e y t o N
r 6 c e r
o t r n o i g i r s p e s d k l e a w c i e e i w t i r v 6 c e r
r d e r t f a a w a s t h t c n a r o t m n o 3 c
r t e t f s e a t s f o ) h s t t ( n i p l e o e d m c o 6 e r m
y t t a i l r h y i t b o t b y a p s t d g o d e e o e l o n r t s n a n e n t r s i h p i o i m c e t s o n r t e d i c n o i g p P d s m w e m D r e e o e T p d d c n
y t t a i l r h y i t b o t b y a p s t d g o d e e o e l o n r t s n a n e n t r s i h p i o i m c e t s o n r t e d i c n o i g p P d s m w e m D r e e o e T p d d c n
t , ) s s y e n n n t a o g i ( i t f s f e a o e i l l u n d d d c y n l e o r a t i a t a c a a s r e c s s i e s g l s f i e n e n e t a c a r s c t h c l u e S j n c a p
t t s s n e e t e t e m h e g t e f n r e i i l r i o m d f u d i v e n e g q t o i e c r a r r p n s e e e a l t d f r r i e o u l l c p s a e c s i n A e r a f h t y g o d l e o e t e h a d f i r o l t e h g l d i n e t e e t s c m c a r u a t e g l n l y s e e i h t c t s g f e c e i A t h i l
, e e u s e u t d s i a t , d e f y e t R o
N
: e t a D
: e u s s I
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
" X " m e t s y s r o f k r o w e m a r f
d e r i u q e r e c n e d i v E
m i a l c b u S
e c n e d i v E “ m i a l C
d o e t r r n i o i g e u i s q r m p e i e r d T / s l k e e a w u c i e i d e w t i v
e c n e d i v E
IEC 627 41: 201 5 © IEC 201 5
P D y t o T i t l i s e b n d h e t a o t d i c t r n t c u o i e d d p e n p e r o p u D p c s s s n e k a l c s p g i c r ( a s n n i i y s o d t e d i i t c u l i n y t l a e n y g t r c b e ) t a t c b l o s i n a G a n i r d o n ) d m s G h e t t t s e n o P n t e n s k i e h m p e s G s a r a D f c i e e e T r t e d ( d s s t R m i a e r t e r o c e w n n d n e s a i n e n a e m f o t o d i n e n t a r n o m o m i t t e t e a m c s t l l p i s s r a i y t u t e s s q s c c f n e e I r a o
n k s e i n t s o i a v r a e t i d l ( s c h p g f a m s e n o p e e c n i c u o t d i t i x d y t u n m s e o l a g y e r c d y s t r o t n m n g ) a p b l i H o s a s d h s n H ) s s i t i e n n o t t h P e d s H k t a c m s a i f s a i e e D e e s o x e r T R h t d T ( a l e r
d l a n t s g a c a a s n i s t d l e o i i r t e r a t e m c s f e t s , g i a d t l t i n / s f r e n n n n o e o l o i e a m n i t i i n t a a w m n s o a l m o r e r i r u u e o p i s i t c v v l l t m e n n a v a e c a o R o e e c d f c f y s i e n y r t y a r u b d f a k o s n o s i r d a n s r e e ( a o f e i c h o o f t o e t t i t e n w s n l e a n e t r o e n s v i m i a d t d e e t m e i e h t n a r h i c g r u u l e e n c u ) k t a t a a p s o v x e h q J i J o e R n e e d c t r J
s f e t v c o i y t s a g o s p e c m e o n e i m n t l c o o x h a s y n e c m r s h d o c s e i f g e m c h n w r t u t e i e d a p t s w t i s e y o r e n x N s p h o e
d n a e r d a o o s t r m s t i s e u n d d o a n e r h u g a a c l y n e e l a u m W m f
P D y t o T i t l i s e b n d h e t a o t d i c t r n t c u o i e d d p e n p e r o p u D p c s
e f h t f o y s t f e o g e o h n l n t o o r o o n n t y e t i i t t o t i s i t e l e n n a t e s i a e r h c n o i b l g c i e d m a p m n e e e t t u m n o d m m r n t m p g r n o e i i p ) s i i e c t u F e t e d m u s m p e s q e F h a n o q e o e h y r T l a c e d c d t s ( F
) I I I z r e t n o f f i e m s l e y e s t d m t l e e s s i r y e i r i i u s s b a u b s r q q e u o u r S p d e r (
) t r n o e f ( m r p e o ) . d l t n e n v e e o c T d (
t n e m p o l e v e D
f e R
e l c e y g c a e t s f i L
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
s u t a t s e c n a t p e c c A
– 27 –
l a v s u o t r a p t p s A
, e e u s e u t d s i a t , d e f y e t R o
N
: e t a D
: e u s s I
" X " m e t s y s r o f k r o w e m a r f
e u d t e y t o N
y t i l i y b t a i v d i n t e c p a e D
e h t f o n e o i t s a a u c l a d v a o E l
f f o o t . n n r n t a o a t i o s g i l t d s e n l p e t t s i e c r e r u T t l w p T T i d o u A o A u A f o l l m R q e r R s o R e e o P r b p P r f c P ) ) 1 2 s t . l n u e a s l h e p e r e t f r r t t h u o t s s t o f c e t e g t y t s a n i i f r r s u T T i g s n A A u e a a R R s s t n h P P a i c m ) ) 1 2 y t i l i b t a i l s e e r t n e o c i t n a ) c t u p T d e A o r c c R P a P (
d e r i u q e r e c n e d i v E
s i s e i r d s . e i s s d u e i f v l y e s t s i o e n e s i s s e n a c g n a s u n h h g n e ) n e h m g a t e ; i o t i i e i L s p r o c o c t y n h d t t o t e e t u x r L x f a o w e a d e ) e p h c s h L e b s d i n f s n s s t f / d d a ( e t m e i i r f h o s e a s e m e r o e f g s t r o u r t o s p e n s / n u t o c k k s a e l t d t a s a a t s t s r e f h u e h h n a x a f e i i r r o c s d c c a m i t h l i o R s t f n (
f o n g o n i t i r a u s r t t e s c a s n f o u s e c m n e a o r D m p
m i a l c b u S
o s d i y s e l s u b a g m h i t e c a e f / s c s s u e a d s g e s i n r e t e r r t u o f S d n i l
a i r e t i r c e c n a t p e c c a / s s e c c u S
e c n e d i v E “ m i a l C
d e r i e u m q i e r T / e u d
e c n e d i v E
o e t r f g a o o t i r s p n n o o s i i h t t e t a n l z i o p l m m o a 3 c e r , e , e e t s s s l h h s e r u s b d g e g r t s i n a T r g i t l . n o n n g i p s h f s a e r d c n i g o e h o r a u d e r e c i l g v c t m h c r l s c n n o y , n a i o a a l i a i l f i d e e s t r g a t e t m , w i i a t a i n s t a t s r s l u d ) n j e u y u w s r o l y t e d e q c o e o p a l e p n n d r e n a h t a o n f R a c s s e r ( p a i a
s e i f t i s e e v g i f r i i n m l m s t i t c m e s a d n i i t ( a a y o e ) n e r t s o s y y o r f y s n n l l l e t s e m t a i o s b b e v n y e e i s l r h s t g m m s e d c r c i ) r p n n e e e u u i t f e e m u q K e f r s s l f d a c f e K h u e u s s n h i h o r T s r d a a i t d w c ( K
f e R
e l c e y g c a e t s f i L
n o i t a z i l a e R
e u d t e y t o N n o i t c u d o r p g n i r u D n y o i t t i c g l e i n a p t u q s a r e n t i t y s s n a t i r o u l d q a o m e u c e d Q e r d a
y f s t i o e l n l a i o b u t a q r e l c v a e p i l n i s e n d F i
BS EN 62741:2015 – 2 8 –
: e r u t a n g i S
s u t a t s e c n a t p e c c A
e c n e d i v E – 2 . A e l b a T Y
l a s v u d o t e r a t p t p p s e c A
c A d
, e t e a u : s e e d s t e 3 I a t 0 , d r f o e e p u R e s v v
s v R I
a i r e t i r c e c n a t p e c c a / : s e s t a e c D c u S
Y m e t s y s r o f k r o : w e u e s s m I a r f
IEC 627 41: 201 5 © IEC 201 5
y t i l i y b t a i v d i n t e c p a e D
e u d e m i T
, e l e g i a s a n a t e t i c o h n s i t s i t s n p o s i i t e s e n m y c r i l r n i o b a o r s u u E c p b s
e c n e d i v E
t n y s e b s e m f , n s u f e s e c o . t o d s e n l d e r e e p t s n d a t i g l n i o m r e s h o c p e g o r m n k e a n p e r i e t p i b a u s e q s y e d e a e r g n R h k a a
s y n t o e i i s t l i t e e c g r d b a h a u i l t e s t l c a i y n y t t n v h t i i i l l a u i t i t i b c b n n w t a e i o a s n i s i t t r d m n f a u a e r e t c e g d p s o p r u n e a D o t s a d
p a l g a y . n t i o i l s i s i i s b s t a y r y a l p a e l a n p a n C a O a
s e i d t y u i l i t y d t s i g n s b a l i i n a r d l . b e n ) l s b a l e d h e t i t p u a d e m p e u i v o e w d i n A N n ( m
e d c e n i r e u d i q v e E r
s i s g l t e i n a t c y u n d - e i s b m t e a t b t i i i t r l r e e n u c i t s o : t b l d e t y t b t d a b a o e e m a n a d s i s e h h n f s i t n m t i d e t i r e e i t m t k e u k i n m p v s s s q a a i e y a e o e i l e r R d s h d i t r R c t
m i a l c b u S
s s t i y s y y s c t y y t t m , y i t i i t . t a y i l t l n t b l e t l e g l i i i i d b n T p i l r d s i n i b e c r e b o b R a m a b o a e d e r e a e y r i a e A r a t m s t e a e s d m d d s r d i t e e e s e a n p s f l n t m r M n i n r o r r i c n e i o n h e a e e S o / p e e r i i e u c t t u c t y p q e n p h p d m p l d e q e p d i g e s e r d n o f e n l r u n o e s d t u n D e r a i c a c D a a w e s o d o f u D e r a
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
r m e e m t o i t f s o u y c t i s l i i e s b f a i s d i l e e t a e R s n
t p e c n o C
t n n e i o y t t i m a l i . p i z b t s o l e l l i a e e t i g v u a a g e f t v r a d o s a t ) 1
y d t e n . i l i k i o t y n t . b e s i i l t l a a i a r d t z i e u m l e b n s a i l e b l q t e t a e g i e s m i g u t p a a d y u i e r v n d a t o t A s n I t s a ) ) 2 3
y s t t t i l s l n c o a i a e p b n e n n a o e g e m m d i i v n s s s i s e n t t i r t e h e a r c w e c s t p e f e o v f e s f f e n p f h d f A o o d o o e s a e ) 4
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
– 29 –
l a s v u d o t e r a t p t p p s e c A
d . h n a g d g e h d n e t t e t r t r t t i g o p o c n r p e p e i e c c e j e w R a R e r b e r
d e t p e c c A
n 2 , a 0 l e p e u : s e n u u s t o s u I i t a s u , d c t f u I e f e j c f d e t o R r e x f a
d d e h t e g t a h a m g d t d a d t e r 1 r 1 T e o 0 o 0 ) i z p p e l e e R e 2 i . b u u R s . s s o ) s t s s 1 I t t I s m
d e t i a i d e l 7 u 0 d e e h u c s r s r S I r
c A
P e e r d
e u d e m i T
, e l e g i a s a n a t e t i c o h n s i t s i t s n p o s i i t e s e n m y c r i l r n i o b a o r s u u E c p b s
e c n e d i v E
y d n n b t i h n i s d t n f n i e a a d o e d e a w y d n l m s p t s i u e n u e i u s l l e l e c n i g o t p c i i l i d a u b i o b n n i a q a v m e t i u e l i t y e e t e v d u . c r i l c a r s a v r p s d a n y s l r a l a a f e n h a e x r e a e o . i y a v p d e g t c s l s t i n i e c n t g r t n l r i r i i e c r e d s i c l n b i s r a b e u j e a d p j e u a s t m n t a m e o s i a t e s l u o r e n u r r n l o e u P o p R f n p p e e r h t c T
. s y g n t r n a s i g m l n o p u r f i r e d o f r n w n t o i o h n t r y h g . i a o g a r s u h t m t o p o o a s l s r h r c t r l o n f r h s a u n o t g o t m m h m u u l e p l o r r a e u s o c e p e e h e n R p r F t d I t t
y t i l i y b t a i v d i n t e c p a e D
f g o n g i l y g y e k e n t t i e i n h e i i l t a l t v c l l h i i t d e l y e b o n m l b g u c d g l a t e a n n d f c i o d i n n e d m i i o f e n o r n t t i r i n m d e i s l e s i v u e u ( t ) e i e c d t l p u l s s q v e n o c o m e e p e p e n i n d a c i n c i D i t d r d
y e s l f y g e h t n e k o g n e h o i n t i h t l i t l i o t n o d f y d e n l u y g o g e p o n y l o s n m c t i i h l t s c i i s n r o u o s e n b e i i i n e i t e t s i u h s d t u s e k a u m b l a s h i s e t x a c o e o A t r f s e m t t s
h t i f o e w d e t l n t a l n a o l a e c c s e r i i m s r e s y a r , r o t s b t m p l c s i a s i j e e t s m h s e k i m r o s h i s o i r A t r C s o p
e d c e n i r e u d i q v e E r
d i p o n h t a s k s n y r n l i i t e s t a l i l f i n i s n w e w o o t r h b c a o g d a e t n d n r f i h e e e t m m n t o e t z e t l o i k t l t w p s u a a e s s a s e r i u e e e o e r t R c r b d c r g s
l o n e t v o s o l e i s e r n e h t h a h t f r y n e n o t t f e f o g i m t r r d x l o m o g m a e e t e l n a s e o i e h d t m r e t c i i r y l n p o n a s k t u m g l h u a p s n s q s e o c o i u o e h r e e e m R c c i r t c t r p d
o n t e i s h e g l t l y i n t i i a t l e f d a l i c n s u b m t r a e s i a m a e t h s r a s r l m e t m r i o r y o e t s e r / k t g l a d k d s y s i u n e i s w n o r e o R c u k r l a p d
e y t u t n d e i m l i e a / d i v b m d e e e t r a r e t a z i d e s i z c e n g f n t s m m f e a i w s i n e p n o o t p i o e a D c o m t d m
s t e n r m l e e o s m a m n e a r s c o r t i s g e e u p s o q r e i m f P m t e r o
d n a e l d d e a e y e i l z c r r g a s e a m e s p n i k o a i n m i s r T i r p m m
a i r e t i r c e c n a t p e c c a / s s e c c u S
m Y i a m l c e t b s u y s S r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
d e o n . i g t s d e s a c y d t y i r a n t t n o i l l h a i s a a i i o i r m s b r t e y b a g a t e e e e l e a c d d v m r n v n c u i r o e e e e a q t e t c i r e e u c s p p h p a f o s l a u o r e c e h d f e C p d a d c A e r p
t p e ) . c t n n o o c C (
) 1
) 2
d e n c a d e n e y e h t e n a g e r b w d r l o g o e o o . a v h a c n s d s h c h k s n o s a c i t r a n e e i t l d e s l e l e a d e a c t u s c e h i d y s n t n p l e e a e n t h c c a h i n i c h m l c e A t p w t A s
BS EN 62741:2015 – 3 0 –
: e r u t a n g i S
: e t a D
: e u s s I
Y
s u t a t s e c n a t p e c c A
IEC 627 41: 201 5 © IEC 201 5
l a s v u d o t e r a t p t p p s e c A
c A
, e u : s e s t I a , d f e R
t f a r q d q q j j d t e r t o a p d e R C
e u d t e y t o N
e u d t e y t o N
e u d e m i T
, e l e g i a s a n a t e t i c o h n s i t s i t s n p o s i i t e s e n m y c r i l r n i o b a o r s u u E c p b s
o s t t r s e n n e i o e n i h o t m r i s s p p n u s i l o , b i y e e l m l e r v g s b a a a e t n a u E d s i f c s
o s t t n r s e n e i o i n i o m r s p p s u s o , b i e l e l e m e h t v g s b a a e n t a u n d s i I f c s
e c n e d i v E
s n ’ r i e y r e h k f o s . e t y e e m t i i d e k o a l d s t r i h n u a s i r o b e a t t c e t w s u t a h t c i k a s d r e f e s r n g o t o e s e i e c n r s g a n p n w d t i o t s s u e , t c e i s n d l t t y n u l t e c a n g m p b i t t n f u o e l . e p e a e t s t c i a n e r n m a n c t d l a a a l e t r k i s t o n l c A p e s i r S c i P a
. r e e h i t l y t i e e p l i h t c s p i b w n e a u h c s a e t d t y d i n t e n s i h v i l i t e n e e p d b o e e a t e t i i d d d m e r i s n r i a n e e a u u t p u e q q n l o e s s C e r e r c d i
r e t s i g e r k s i r l a i t i n I
s t r t a s e o h p t a h t e r e h o s y t t n c i i l n s e o n i e i t d b d c o c i a e r e v d r l o e t p e n c n s g e o a i n p f n i t e o d n c i t w e o e e l p h e e O s h t b s
y t i l i d b e a e r d g n a e n a n p e l A d p
r d . a n l c i a o t n y t s , t i e i m s i , t e s , y l n s i s s t t e u e l e t y n n n a r o b e i t o d t i i a m o o e r t c c x d l i t c d n y , l e g n e b i e c d m e r a c e e n p r f l i r g p i e i a d e i i e t y a m u y p f d p u l s u l e f u s o a e q e r a q i p i a n e d e R p b e f a a d d u c l r
e g a d t s n l y f n a a i n t o i o i i s i o l s t s t b s l e i a l a i a l z y r i a i d t l a e a i n p v t u e t D u a o a s
. s g e n b n i y o t w t f i t o l o p n l t o i i e l b s y s o t i t a e t m a d l i e s s t a b p s i n a e e a i e m m c e i d l n s u p i t e t s o s t e s R e c A s d e
e d c e n i r e u d i q v e E r
o t d n s l t e c r o i e i o r u t a f e o e i n n d m c o f a t r h f g t e e o r t a e t y c n s i c s n a p h g i e a u m n t t o n e r t u e g c a l t q i u u d n s k t l t a e i i d s s s r s i s s d v e n i u u t R c o s a e r a e b a d
n r o e i i n t l g r a a p n e o t y i s i p t n t t i n e u d s n l e c e s n ' e o i g b d n g h b t a r r p t t a e t a i n n e e i s e x a o t m g d t l e c p m i s m r / e h s n m n o t r o i r i a e o s n n o e l c f e e o r d s p e t k e d t u d p p d v h d d s e s o n s a e u i i v e d n d u e u q e e R d u c r l d s e d a a a c n
y i o t s l l i s b i a y a f t y i l i d m s l s u b n t n i a e a o n o p r s d i h s e a t t c h o e n d g r e t i k l c e p a s e e r d i e o d R s m t a d h t
m i a l c b u S
f t y o i l r e i e s i c b a l n d r p d a a r n p s d t u e u e s s p e n a s e y t A d b m s
s d e d e t s e n v t v a a a d n i c e e t r h i c e r n e e m r j u e g e m b i r l o i a t p m u o s p m d u u o d n q n C s c a e r a
y n d t e n i l e a y m i y l b l s b n i a s s e o n s i d v e a u i t a d t c h u n h o r e e c l p d o c l e f e e c g f e n i n d S m i a r e
s n t o e i e t a y d m r t t i n e l s a d c e i i p b g n m e n o a t e a t x e c t d i t a s r / n o n u c u s e p e q e c d p p d e r r e e e u i v d o h e D s e a c t n
y s t t i l c a i o e l y s b a t e l m i s a o l e d i r b i v n r f e e e i m n a t p r t o d c m e a e p i n o d p l s t o t e u s s e l r t a a u h o p e e h o C t s d p t g
) t r n o e f ( m r p o e l d e n v e e T d
) t r n o e f ( m r p e o ) . d l t n e n v e e o c T d (
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
t p e ) . c t n n o o c C (
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
e d c e n i r e u d i q v e E r
Y
m i a l c b u S
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
– 31 –
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d t e y t o N
e u d t e y t o N
e u d e m i T
o s t t n r s e n e i o i n i o m r s p p s u s o , b i e l e l e m e h t v g s b a a e n t a u n d s i I f c s
o s t t n r s e n e i o i n i o m r s p p s u s o , b i e l e l e m e h t v g s b a a e n t a u n d s i I f c s
o s t t n r s n e i o e n i o m r i s p p s u s o , b i e l e l e m e h t v g s b a a e n t a u n d s i I f c s
h r t i o e w r h e t d d e n i n d i t y v e l o e r r h a P t e
e c n e d i v E
r d i o e f y s b t e e h t t i c n y l e e i o c n n h t r a e i e t k b a s d t s i h s e t n f l m u d v i i a o n o l o e r p e m c n w c f d p y y , e t t o i e t s t i n o i t t l l n n e i i d c b i b r e e y u a t a a o m d r a d d c s n m e n d o s s a v s r n o n l e s i e s e p e c e a s k h p p n s s c c i e e e e r e F a i r a n h t d a d
s t r f y t o o i i p t l b e r n e a d n m o s n i t s e c e p e f e s d e l i e s l s a e h e r n d a g o w u i u t t l o r p c f n o O i s h t
e c n a n n t g e p i e e s e b c d c t s a c y a t r j i h l e e i o d r b s l e d p o a i n e h e d l n n e h e e i k t p i a d t a r e u b t o S f d g o
y t i e l i b h a t d t a n h e t p s e e d t t a s r o t r ’ r p s e e i l r n p e o p s m u a e S c d
e h f e t s d t n f o n a o t r e y n a w y e t t m e i i e f z t i x r m o x h e r s l s s l e u a s y p g s e e e l u a h p t w s e m o t m f r e s i f o o o k A l c h t m o c s
w s o e d h n y n l i t f i a l e i s o d b e n i e d e a n o u b t t d n i i g c t s t c n l a o t r i n g e i e e i t n e j i s d s i f e e n a o r p e e u e h r o g P d d g d t a c a
y t u , d s f d e r o a t u s l o a i s , r y e e l p a l n c y m e A c t
d n h s i t s e g i o r i e n , t y r y t i u w t t t o k t e s i i l u t c o l l f t c r c g b i n a i a n o e l u n i b e s b u g a c r r e , t o t t s a m n m e g a q i n d l n n d e t o r i m s i a a s n m d r a n n t r s m h r e t a o t t n e o e e s u f e d e g f e u e o i a p s e h s p e h t t p t v i e r p s e i m y r e s u n c n e i e n n i o i o s D d a q t s e d g w p t d e v e i h c a t o n s i
n e y y v t s e t t i u r i i a l e d g l e t i i h t y t b n v b t i u s l i o n a u e a i b t i d e o r g b t a g d n m s t n n t n n a a u i e i e d e t p p s o a i h v t d t q s h h r e g e e e h g g n k d e i e i d s t s h e e t i a e d e p s e o i n w t n a m o r R i a w d
t e a r d n o h e i t a l t t s a p e a i o t c c o l h s n y t i o h e d e t g t m o s a l t s c t a e s e h e a a o t o r u s e i n s n q e u m k h h e s t s c k i i e s t r d s q o e i R t r w a a a e r n
t o n e s h a t h t r a e l y h t i l l a k p m p s i u r o R s f
d e s u
e d e d v a t n h a a r i c r e n e u i l m o m p t p s m u u o S c c
d e v e i h c a
e h t y s l l d e u n h f t r t a f e o i l s r p e t n p d t u n e n S u i
) t r n o e f ( m r p e o ) . d l t n e n v e e o c T d (
t n e m p o l e v e D
BS EN 62741:2015 – 3 2 –
: e r u t a n g i S
: e t a D
: e u s s I
Y
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
IEC 627 41: 201 5 © IEC 201 5
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d e m i T
e u d t e y t o N
n o i t a z i l e g a t a e r s
s e s h e t e e c t h r c t o e n n f p o p e n n u n y e i l g t m p g f y i o i l n i t r s i u a e o s e o r q E d t d p e f s e y n h o e t n , t t i a g e l o s d n i f i i h h e t i o b t t i o s o s l c h a y m t s e a d e s r n f t s e l l e r d a e l u i i u a c n g t u l e f i n f d u r t a i s m m o n n p s o i t i a l u n r a e t s i s s o e h i i h ; d u n e h t t h t e g t c m t a t s e o g n e n e t u e n r f g d t e o t e t f e n i u l n d e t n e , v i a r o i r n s e i ) a t l u r s y o c a t l m e p u n u s t i s s s p u s h n h e s d s q d o r e n t i d a a m t c e e d u t b m o e o e f u o d e n r q s o e l o f o e a p t o m m ( h t o s c a n a t
d s r s o e o h o t t t d s c a e r o a f l e c d n l l e a e t c n u n y u l f e c n i n y e m l t e l n u b i n o r d e w i g i v d v d s n n a n e e a h a d
f x o i r e s : w t a a g e i m c i n v y t y w e k i b l r i o s r r d i b h e r t e a s e r d s m i o n t o l r t e p p s p p p o u u u e p C s s d e r
y t i l i y b t a i v d i n t e c p a e D
t d r i n i s n s d . o e a s i , c t l n t y t d a o s t n o n f i r a l e t o a u m i b , a d e i n n e t o l , s v A i d a o m i e , r u r n s , . t o e s s t g t u r e s s l s e a y a m l r i p l c e r i s u u r i e e h e g o e v q o a m c f v v t n f p n f a c f e l e o o e e n m l r o A d a e i
l f d a e . e i o t c h t y a i n i i t t r s y o l s f c t t i f i u d t c b o o f n a o d e s a i o t a s h c s d o i t n n f o s l a n s i g y t s e l n i n l p i g n k h p a e s m a e e s t r e o g c i e n t y d I i r w d A s d c a c
d l n a a o i c s t t r . n g i o i n c i t l y s f c l m i i e t t e d d n e e s r o d y P m i s
e d c e n i r e u d i q v e E r
s o t n s l e a n y e h t o t m t n i e t s l i i e d f e t b r e o m n m a u s t n i t a d q s c o t r e o e r s n r a i e r n d p v n p t a e d m n o e h r a i e c d t a
r e l n s i o k l a t i p e s d i y m v t p l r a c r n u o i l o i n a f f s v i i i b h t t i d . a t g g n a n d n i e d i e i n i h o t t n w d e f t i e l b i t e f k l s p f k u n t t s s a s o e a i i e e t a d r R f s i r e r n d i t
g t i n t d n o d a n a n e y k e e t s i m s r l i i k r a d n l s b g t s e i r a i n d a r t l t a h e a t t s e r i n c e s g w e j e k i e m t p o s g t i e e o b d r n t R e r i p
m i a l c b u S
, o l a s r t t t f t c n s d o n l a e t e t e u e n p m e m c r n s n i e e i a t g t e r r r r o t a i n i r a i s u h d e e q p t n e v n h h e n i h n o a t t r i w t e c
k t s y s n a i t i t r e h l i c b n d e e m t e n d a j a e k d a e n o r u g a e d p t q a e s u n c l h e a s a c p t k d a l n e i i s A m h p i d w r
o h t s s i s e w t v n i d t e c e r e n e m j g m e i r b i o l o u t a t s q a e r u e r h t a c
y e i s h o t r l i d k a b i s n i s t y a t s t s a r w i d n a d e d l i n h e h e b e e r i z t t m a a p e n d i i e e l g e c d r n d i p o t o e t u t p c a s p a q e u e e e r s S e r t a d h t r m
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
e c n e d i v E
d f n o a n o i s e t i s c a a r s y f l r g e a t e u t s n e n n i s A i i
t n e m p o ) l . e t v n e o c D (
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
– 33 –
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d e m i T
e c n e d i v E
t s e r o e a n s e r s u e a a u d c ; s n s t y d i s a i n a d l i a n d e b o e k i a i e t l c a s o s a r e l r o e f r g r r n u e e d e t t d v f n i n a o o i
e n i , m g r n e i l t l e e d d d n o o a t m s s y n y o n t o t i i t l l t i i c i a b i a c a d c i i t o l r e l i l r e r p a c
e u d t e y t o N
e u d t e y t o N
h r t t i o n e e w r h e t m d d e n i n p o d i t y l e e v e l v g o e r a r h a e t P t e d s
h r t t i o n e e w r h e t m d d e n i n p o d i t y l e e v e l v g o e r a r h a e t P t e d s
d e w e i v e r y l t n e d n . e t p r e o d p n e I r
s b t r u y o s t l p S i i e r T b a d n i c O o r n i t t o e s f c i p e l e a s d l n e e o s s r i e t n d c m o u i e i t t l d s p c e y n r O i p s
s i s y y b l a n g d a n e r y i y e t i f v l i i t o b n c a e s n d i i n a t i o S t n r o t c M i n U a p e u H M r f
y t i l i y b t a i v d i n t e c p a e D
g w e n e d h i t t n n e y r s e t i o a t r o e a t e i l x f n h i h t f s e b s - e h t n e t e a o l c n i d e b s r o m w a t t b e n t n e a f a d s s d a u d a c e s i e n s m c o i c e r e l c i e i e d e i l r a m s t a e w t S s u p t T s n t p f p a p u f t s t e s y o a m i e p h p o A s d e O s c d i d b a t a s
s d n s s e e d e a a c b t y y e o r l o n e e l t h t p t v n i e f n S m o i e t g c i l M c t e i s p f f f r U m f a e H i e e p d
e d c e n i r e u d i q v e E r
r s f o f o m a t e n t y o y i i t b a s t l s d y a r i b n d e s t e i a i o t c b s d u t r n n c v s o e i o r e p S m p d s p e e e r u - T n O D d p s i
g s s i n r t , e n n r l t u l y e e d t a w v l o e i i e e d s m e d t b e a a r n c b a b e a t c , a k n d r t t h g p o e n o u t o n h e n s e n t n i n t k n n t u d p n a s a e s p e i n e a e e i n r R c s t a a d c m
S s T t i n n O n h i e t e n i g l w s b o e p a d d t i m e e u o s S c u h t
s g d e n n i k t a a d d r e n o d n m t p r o i e n f a a t r o i e c m g o m e e i t g d g o l e s e t r t s n a e s u a s u y o a t o s c s D u a u f u
s t n g n e i t n r u n o s d p a e m m d e p o m t o c r c l o e e e S f p v g a T r e x e t O p e d s
t s e e t b s n a a d s i e c y e g i v s l r c n n t t e t i e c l t p u s f e o n e f s r e T e e r p s
m Y i a m l c e t b s u y s S r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
BS EN 62741:2015 – 3 4 –
: e r u t a n g i S
: e t a D
: e u s s I
Y
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
IEC 627 41: 201 5 © IEC 201 5
l a s v u o t r a p t p s A
, e u : e s e u s t d I a t , d e f y e t R o
e u d e m i T
e c n e d i v E
N
e u d t e y t o N
r t o l n f d y e r n s l a a m a t e p g s o c g l n o e i n e e i j r p r v g a u o r o r u e t D p p d d s
t n e m p g l o n e i r v u e D d
y t i l i b a d n e : p g e n d i s d u ’ r l e c i n l i p n p a u l S p
y t i l i d b n a a l a d t n n n o e e i t p m a ; e e z e r d g i t u n a r a c a n g u r e a r t l c m o s –
d e i f f o t i t e n n s e a l d y t e t s i p r h i o t l n e i c f i e h t g b t a m a s n d t e i i e y m t r s i f n i n ; e e i v s s t i i a k t p u s t q s y c a e e g i s a s d r a r –
r a e ; l a c i r h d y t n e t i a t i i l i w s r b s e c a e v s d i i t s n t c e e i v i e c p t j c e c b u d a o s –
y t i l i o b t ; a d e n g n i i m e t s p e n d e i d s e d i e c e t n n i v e n i u l a t l c f n p a i –
t e g r a ; t s y t o r o t i t l i s c b n a r a o t d i t n a n o e c c p l o b e l u d a s –
s n a ' l p s r y o t t i c l i ; a r b a e t s n d o n a c e c b p d u e n s d a –
d ; n n l a a t p s n e i o t r t a a u e l l c a v a e –
y t i l i b h a t s i d n r w w e f y t e p o t i n i e s l i e v d e b m e r a e c d n i d o e t n v d n s e i e o n l e h i r a i p l e c e p m d a p –
e c n a t p e c c a s s ’ r ’ r i e e l m p o p t s u s u f C o
y t i l i y b t a i v d i n t e c p a e D
t s e e f h a s r o t e e u d e r s n y t h n c n d i t c n , t e a o l n o i s h , s u e p t k t a i s o p l y t a s b / i t s s a i a e i a c k d d s t h l e c i c i i r w i a r l f e n t s i i o b i i l t r n e v e g n a u t r r l n n p i s n h p o n t e i e e l o l a e t o c a s c o i r w e d h h e I t p d a t a t c r c c t i
r o t i n o m w , e e i v t e u r c e d x n E a
e d c e n i r e u d i q v e E r
r d e e r n i h l o a t p y e y o y n p t i o t i b b n p i u a t t l l i i n l s h i i l d r n b r c i a t t b a w e a e f o g a s d s e i s n d m t t i h s i m s t t c n e e o a t n o a l e r e e z u t s k p p u d t i l s s s x e s d s i s p i e u i u t s R e d i a c u e r d c d
f o y n b y o t i i t l i a r b t a s d n n o e m p e e D d
m i a l c b u S
s n t i d o n n d e n i r n t o a e e i i r a e t d i s m k n p a l y e u s e t a z a i q r i g o t r l i l e a e i r t t p n r i e e v e m v u o a e t d h o e r c n r d t o p m h T f t a u
n o d i n t a a u t l s a e v T e
d e r e o i t u y h m t t t o q i r n l f i r m e r e n e n e s b f t t m o a o p i s e d a i y v n s t o t a s i e e l i s l z e e h p v n e v i l i h c e e a e t r T a d l t d u
s e i r e r t a a c u r q e e i l d p a p t u u S o
t n e m p o ) l . e t v n e o c D (
t n ) e d m e p u o i n l e t v n e o c D (
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
– 35 –
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d e m i T
e c n e d i v E
e u d t e y t o N m n o e i t t s e a y c i z s n l a a t o t p e r e r o c d i r c n p a a
e s : a g c n y i t i w l o i h b s a d t n s e r p o e p d e r
e v , i t s e n A c e g C f s h f t i e s s E e g m e s d e n o r M a r d t F n ; s h f f , a S ( s c g o d A i s n s e n i t t e s i C ; l u i y ) g l l i u p A d . t s s t u a c a e e u t n t e R d r o s a e D D –
m t t n e e e s y c m s n p o t a g l o t n e r p i e r v i c u e o r c D d p a
t s e t t n e n ; s o t p l m u o s c e r –
t s e t m e t s ; s y t s - l b u u s s e r –
; s t l u s e r t s e t r e h t o –
t s e t h t w o r g y t i ; l i t s b l a i u l s e r e r –
; s l a l i r a t d i r n n t a o i t l e c a n r a n a y t t o s n ; i l t t i n i s e t b o a r i n l a i m e a u l e p s e r d o m e r – –
l a i r t e c n a ; m s r l t o u f r s e e p r –
n g i s e d n ; o n o n i t o i c t a a w m r i e o f v n e i r –
r e h t o m o r f a t a d s r d l e e s i f u –
s w o h s t r o p f : e r o S e A c C n e A i d R v D e
y s r o n t o i c a t a f s i c i f t a i d s o o t m n g n g i i s d e a e d l –
y t i l i y b t a i v d i n t e c p a e D
e , r e s y e h t i i l e t i i w t b i v g i a t n a r d c i p n a d o e n n r e p a p e l m p d p a a
t r g n o i t p t s n e r t e e S e m A t h p o l C e A m d v R o n e r a d D f
e d c e n i r e u d i q v e E r
n d t t g n a i s n s t a h e i o y t s t t e e i t g l d i n d a h n l e n h b e n l u c i o e t r a c i a m a a i - t p t e i h s c n e e e y d e c t e t d e n v w r r d u e i i n i s f i p d o m n g e i i v t a t s d t o g a n e o o s p u e n a r n t o r r a e q d a d p e s c h t p p h d e r
e h t n n o n o i i t i t a h a t r r t g i s t e w e n n g r o i i n a w t t t m a s f e h e o D t t s
y l e d r e l e v a h n a m t a m o h r n r t o d e i s e a f i u r n e e l p w p c e e e t r t i e r e g e u h c b a b s t
e r a e s l S e b i e T c t h a a O f r p t h e e m i h t o t n T i c w
f e o d o i n t v o s i o t r r o t e t e n p t a c a m e r f o t o t m s t t n e i s c t s e n n e g i r a u n i c e o i s c i t f d i m u q s f e e v e e u t s e d e r h t h t
S T t O o n f n e s h o i y s w t i l d r e i e e b a g a t a w k c i t l e c f e f o a f R s p a
m Y i a m l c e t b s u y s S r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
t n e m p o ) l . e t v n e o c D (
BS EN 62741:2015 – 3 6 –
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
e d c e n i r e u d i q v e E r
m Y i a m l c e t b s u y s S r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
IEC 627 41: 201 5 © IEC 201 5
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d e m i T
e c n e d i v E
e u d t e y t o N n o i t a z i l a e r e d g a n t a s
; h t w o r g y t i l i b a i l e r
y t i o e l t r s i b s a l w e a t t c d r f n o o y p e e s c p r y s e e l e t d n a o i k i o t l r t c r r e t i u d e u l v e i p r o a n i p c f –
d f n f o a t n g s r i o n i i f t d g a e n i z c i l e g r e a r u a t e P d r s n n m y o i e n o t i o s o i c i t : t r l f i g a c e n t e r - s s b i c u c t e c n i u u a r e f d n s d d d ; s d w i l o a i o s r i s v t o t n o a r t f e r e c e c e h u p p ) - p o e a c e T ; n r f i c p s / q o ; c r e s y s c A t s i p e d n p d t r t l s y d i l r a R n o u t s e o o t u y P s e l i t y a ’ r p i a s t ( e g a r i m t u i l e e e m r i r n u t i i l i l r c a q p b g r s b g u i n h p e d a a S l i a i t c h p s o f c d c p x a l s t u a r n a f n o a i o i e r e S c p c t r t b o a t c S
s e i t i v i t c a
s d d d l e n t e i o a n r u c n i t h a b t e n e c u u o e l e l e i f d s c s r t p n o s y i n n p c t e o u o e r e d t v p c d m i s o o e o v s o r r a r r p p h h e f E l t p
s d S s e n e y d A a o i u e C l d t l y c s s b A n y t i n b y s o r c a I l e d R i o e d . a c D t t e l a f s n o t f n t r a a r r a a e l g r u o t p m e b t p s s o t e e i x p r o n l a o i n d e r t f e r f
y o l t r d e t o o o a h t b n e u o y t m t d p t e o r n e n i r n s y d e l h i t f e i b n a i e i b a s k m t n m n d g a t o r a i o p i e e a n d e t i t f i h g i o t t t i l r t n l l o a i v e k l z a a e k s u i n p i i n e v l d p t t s s i a u c n c i p i a e t e r d a e n d R t u m s a u l r i
e r u t e r c e m a t e t w i t h s f c y o r s s a
r d d o f s f n a e a n o h d g a e i o e e r t n l p t e n a a e n e y i l u m c g e t c u m e p o s n w t o d p c d e a t o o t u c n h h e r r s y S a a t c b p p s
e h t o t n i d e t a r m e g t e s t n y i s
d e r e o i t u y h m t t t o q i r n l f i r m e r e n e n e s b f t t m o a o p i s e d a i y v n s t o t a s i e e l i s l z e e h p v n e v i l i h c e e a e t r T a d l t d u
n o i t a z i l a e R
e s y d t s o h t e y d t i t l n t i e n e d l i a b h e t l a a d c n a i m i t t a t o u l b s i r a a h l s d n l t y t a e e p e g e b i d b t n r n l c n w n e e n t n o e e b d i o r a n i o i n i e t e c e t d r p m t h t d e e e t i a d e i c c a o t e r d u d i c u i i u n s i n a i r d f v g i d n d u w t f f l s g a n o o n t o t o a o r a e q h a e r u v r S e p e s c p s h t e r s h d p
d n a n s e o e d i t s i e y s s r c u t e g i u l t d a c n a o o r u o r l M p q p a
n ) o d i t e a u n z t i l i a n e o c R (
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
: e t a D
: e u s s I
Y
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
– 37 –
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d e m i T
e c n e d i v E
n g n i o i s e t c d u e d p o y r t p o - t e r o r p p
e u d t e y t o N
e u d t e y t o N
e u d t e y t o N
g n i n d r u i o e d t e a r t z e g s i n l g a i a t o a t e A p r s
g n i n d r u i o e d t e a r t z e g s i g n l a i a t o a t e A p r s
d n a t r t a u t o n o s h i t e g a e u i z g h t o l r i a t h t t A t u s
. s t l u s e r t s e t h c t a b T A R P
. s t l u s e r n t i o s t e t c e h p c s t n a i b y s i d T t r l A a o u R c P Q e r
y d u ) t D s y M t i l O i d ( b n n a a o d i . n l e t s a c t e a n n a t r l p o s u e . i s t n d s e n e t a r l o r t n D l e i m a u s p a e i r M O m d t O e r
n o i t c e p s n i y s t i d r l a o u c Q e r
n n s r i o o e r o t u t l f a i i a s s i g i a t c f e f c r t i , s e u e t s f c t d v e l e e i u r d c n f a d o e d r h n f n P t a o a
e h t e o a t d t t t n n a h t i i e a d a s r i w m e e p s p o g l y i g r u n r u a l a o p q s i l p a a a n E u f a
e d c e n i r e u d i q v e E r
f t y ) o i n l a n a e r l o u u i q t p t c t a r t a s n f t e s t e u t n s n T o i a A m s m R e n o f D c o P (
f f o o y t n n l o i o i t a i t u s a a r t n q e t r s e e u v d n m i t o l e c e m e p f e c o e h f r m D t i e p
f t y s t o i l n a f n T o u / o e i A y n t q l o a t b n p R r P n t n m o m i s t e t o h l a n s e a r c g o i s p u s g s S o t m n a t e r s e o f T h e n O t t D c o i
m i a l c b u S
s a d s h n o n e r t i s e e c a i s y l r u t i e p t u d l i p a o c c u r a o r S m p f p
d t n g u a t n r o e n i e l i e r i o l s e b c t i p i i a r f t p r i f n u a u u o S c s s m
r o s f i n t r o n o y n f o l i i t e b a e t l a m m m c p b i e r S i l a t s f o u i s n T q u p p A i O e s a
s s a t h n r e e d t m e r i m e m r i e o i o f t t p u s c e p s u p y u q C s s s e r
s t n g n e i n r u o s d p a n o m d t e i o m t c r c a z o e i S f p l T r e x a O p e e r
l l e d , n w e a d s t n u n a n e i s d d i t e e e m n i g f g o r i a t r o n i n n a v p e h n p u d a C e s i m
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
e l s b a m e t p t i e d c e c . a y c f u o t i l d a o r e r u P a q
f f o o y t r n n l o d o i o i t a f i n t a s a n t u a q r e n y i t e e r l o s u b t v d n m i r m a o l e t c e e g c m e p f e e s o e f r s t m n D h t i e p a i
o f s t o , i e n e y t u o s i l i d t e i t u a i n t b d a a e u r a d e e h q d t n d i g a e e r s k p g d n n a s e e a o h i n c c R d d i
n o i t a z i l i t U
BS EN 62741:2015 – 3 8 –
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
e d c e n i r e u d i q v e E r
Y
m i a l c b u S
m e t s y s r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
IEC 627 41: 201 5 © IEC 201 5
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d t e y t o N d n a t o n g t n o e n h t i i g o u a m g z e r i - o l i r i n h t t O t u e r
e u d e m i T
e c n e d i v E
d n a n o i t c e l l o c a t a s d i s y D l M a n O a
. s t l u s e r s e i d u t s y l r a E
y t i l i b a d n s e t p n e e d m e e r r i u t u a q M e r
h n g l a u p o r t h t n e m m o r e g f s a n t c a a r m t e x f i E l
f s r e i . o s f d s o s c a t n d n e s i o c d n n v p a n i o o o t i i p r o i s e r d s t e e t t y a r e t s n n e a a t m c c i t i h e e l c u i g n o a c r i a f m e h i d i b m e t t t d f i u i r r g a t s u e v i o a i n d u u t l d t r o t l s o o e s r s r l s i n n o h e a o s y i e a d a p r e f I s f a i m t d D c e r
h r s s g o m n e f f o o t o i y u t r o o s i r t f s i l r n v i o e t s i h i i n b m t t e t s e a t a n l c e s m o z m r a r p i o e d f l a t n e i l d l e k c t e n r u r l e p r u t i l l a u l e o n o o e g e F a d w c t r e r l
s e t r t y l l a r y o a t s i o t p r , f n s l i o t e o e t i r p b r s n m n a d o o e e d n o c p i t i r m n a a e r a u u e a a l l c p t o t q o o e a t a n d C e r d d d i
t h n a g - l a f t i p e o s r s n i v e i o n n t o o p g c h t i e t s n f e f r i c s f e d e o u l t i d l n v s r a a o o s o r i n e r t n e P f l P i n
t d n n e a m t r n o o r p i p v u n s e
s e d r n r y e d e o t u e r t e s o t t h u a m s n f t n t u o s e s p n i s i l a a o e t c m u g s g e t r v a a t n l s t e c n m i e d h t s i t t e c o s e t e a s l l n i n e h s k r s j d t u b e m s a a o e e i r r y s o r p h e p r R l p a o b e r p e r t d s e y n i t b r a i l d e p i e m b i i i o n t h g s n f s i n e s m r t e e r o d u t p c s n o s e y w p r e S o e r e r a h t
n e e c e n b y d a s e s l ’ e r d u n r n z o v o i s e e l a t s h i s s s e m i b a l t e o o l n p t e m s a m c d r m u e e n n a o e c C t d o a l
t n e e e v r u h t e r t e u r p f a m o n o s f r t o t s n t t s c o n c e e j e s r j s a o u o e e r s s r L l p i p
/ t n n o i t e a m z e i r l i i t t U e r
/ t n n o i t e ) a m . t z e i r n l i i t o t c U e r (
BS EN 62741:2015 IEC 62741:2015 © IEC 2015
: e r u t a n g i S
: e t a D
: e u s s I
s u t a t s e c n a t p e c c A
a i r e t i r c e c n a t p e c c a / s s e c c u S
y t i l i y b t a i v d i n t e c p a e D
e d c e n i r e u d i q v e E r
m Y i a m l c e t b s u y s S r o f k r o w e m m a i a r l f e C c n e d i v E . f e R
e l c e y g c a e t s f i L
– 39 –
l a s v u o t r a p t p s A
, e u : s e s t I a , d f e R
e u d e m i T
s g n , i t n e l e a m p y y t i t m i l i l o r i b b f a a s t d d u n n . p e e p ) . t e c u p e t O d d ( e
e c n e d i v E
y l i a t l i n i s f b a e d e e d t a v h t n e e i m i d p t h n e s c a d e a
e c n a t p e c c a d n a s P t A r o E p T e I r
) e h t l g i a a w n s e o u i s s t y t a e d a r c c t i l r e i e n y b o t t p a i a p a l l e o n i e r u b d g t p a n e n i n o d e c i a p n p n d u m e l y e e d l l p d c d i l u e l v n n F d a e i ( a
s n o s s e l f o s d i s e y n l a r n a e A l
BS EN 62741:2015
– 40 –
IEC 62741:2015 © IEC 2015
Annex B (informative) General requirements for the dependability case report
B.1
General
This annex provides the headings and describes the content for sections within the dependability case report. It is not envisaged that this structure will be suitable for every project, but it is intended to provide guidance on the information that should be contained within the reports. The dependability case report provides dependability evidence at a specific agreed milestone within the life cycle. The reports present an argument based on claims, which in turn is based on evidence and assumptions that the system will satisfy the dependability requirements. The report is not expected to contain all the evidence produced up to that milestone, but to summarize and act as a "signpost", indicating where the detailed evidence can be found. This standard refers to dependability, which might be taken to imply that documentary evidence for reliability and maintainability will be summarized in a single report. If the evidence framework requires separate reports, or the customer or supplier considers that having separate reports presents a clearer picture, or provide a more focused approach, separate reliability and maintainability case reports are considered perfectly acceptable. Where appropriate, to improve readability and the transfer of information, dependability case reports associated with a given project should attempt to adopt a common format.
B.2
Elements required for the dependability case report
Each dependability case report should list and cross reference the requirements in the evidence framework, against which the evidence shall be judged, and be traceable to the original customer’s requirements. The dependability case report should also outline the background, purpose and scope of the report detailing, for example: a) an outline of the circumstances which led to the need for, and development of, the dependability case report; b) the purpose of the dependability case report, i.e. why and for whom it has been produced; c) the scope and boundary of the dependability case report; d) what the report covers (and does not cover); e) boundaries of responsibility with respect to managerial control and other stakeholders; f)
relationship with other reports, if applicable;
g) applicability and compliance with relevant regulations and standards.
B.3 B.3.1
Context and assumptions Stakeholders
This clause describes the stakeholders interested in the system, their expectations and any requirements which are derived from them.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015 B.3.2
– 41 –
System description
The system description should contain the following items: a) Physical description – this should briefly describe the system’s physical or functional characteristics. b) System boundary – this should describe the system’s physical or functional boundary. Block diagrams can provide a good method of illustrating the boundary of the system considered in the dependability case (see IEC 61078). c) Operation – this should describe the system’s primary role or function and any secondary roles. It should include its typical anticipated duty cycle. d) Environment – this should describe the system’s operating environments. e) Interfaces with other equipment/systems – this should define equipment associated with the inputs, outputs and services to the subject system. Where appropriate, it should also describe such equipment physically near to the installed system. f)
Users and required human machine interfaces – this should describe the people who will use the system and the interfaces they will have with the system.
g) Build standard/software version – this should relate to a specific build standard of the system, including software version(s) where appropriate. h) Configuration control – to ensure the report reflects the latest build standard/version, the description should indicate where the latest build standard/version is defined, for example, the master record index. i)
Personnel skill levels and training – the skill level and the training required to operate and maintain the system should be described.
j)
Mai ntenanc e polic y – this sho uld describe the support regimes for eac h of the system’s role or anticipated duty cycle profiles.
B.3.3
Dependability requirements
This should reflect the customer’s requirements and the supplier’s understanding of those requirements and how they are to be measured. The requirements should be considered in their widest context in that they should include the environment and usage requirements, as well as the explicitly defined dependability requirements. The supplier should describe how the requirements have been interpreted for the proposed design solution and developed into project target dependability. B.3.4
Limitations on use
This section should define the boundaries on system use or the context in which the arguments are made which, if exceeded, mean that the dependability claims might not be valid. These limitations include the system’s operating envelope, the environment and important maintenance activities. B.3.5
Assumptions
Al l ass umption s should be explici tly identif ied, either in the dependability cas e report or in a separate assumptions register. Where possible, activities to validate the assumptions should be identified and included in the evidence framework.
B.4
Risks
Through analysis of the dependability requirements, the supplier should identify the risks associated with the system not satisfying the dependability requirements, and how these risks will be, or have been, treated during the project. This information would normally be found in the evidence framework.
BS EN 62741:2015
– 42 –
B.5
IEC 62741:2015 © IEC 2015
Dependability plan
The supplier should determine how they intend to meet and demonstrate the requirements and provide the necessary assurance. This section justifies the activities in the supplier’s dependability plan and identifies the success criteria for these activities.
B.6
The evidence framework
This section should provide a complete overview of the evidence, whether during the development and realization stages or during system utilization. It should also show when and by whom dependability case reports are to be issued. Specific entries in the evidence framework can be selected by the customer and might be matched to payment milestones for control purposes.
B.7
Body of evidence
This should index the existing evidence. See 5.3 for examples of the types of evidence which might be included. Every item of evidence should be cross-referenced to the evidence framework and to the claims it demonstrates or the risks which it treats. The body of evidence should also trace the history of reviews and updates of the dependability design philosophy, targets and plan, which keep these in line with the changing status of the original risks, as well as any new/emerging risks. The body of evidence should distinguish between the factual evidence and the arguments or inference drawn from the facts.
B.8
Review of evidence to date
This section should provide a balanced review of the body of evidence in terms of its completeness, timeliness and acceptability with regard to the criteria contained in the evidence framework.
B.9
Dependability claims and argument
This section contains the argument which supports the claims that the system satisfies each of the dependability requirements. This section should provide the reasoning why each of the requirements will be, or is being, met in utilization, based on the context, evidence and any assumptions. Al l assum ptions should be lis ted explici tl y or an ass umpti ons lis t referenced. At the start of the utilization stage, any remaining significant assumptions should be explicitly highlighted, along with any limitations on use which these may cause.
B.10 Conclusions and recommendations This section should contain a diary of the conclusions drawn from the dependability evidence accumulated to date, including whether the system is likely to satisfy its dependability requirements. This includes referring back to the conclusions of the previous issues of the dependability case report and describing how the arguments have changed. In interim issues, it should recommend whether the project should proceed to its next milestone, or what further work is required to enable the project to progress. In addition, it should recommend what activities should be conducted in the future in order to generate the necessary assurance that the dependability requirements will be satisfied.
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 43 –
The status of the dependability assumptions, evidence, argument, claims and residual risks should be summarized and discussed. Conclusions should be drawn with regard to the status of the progressive assurance and the activities necessary to treat the residual risks. The recommendations should be based on current shortfalls in the evidence available and should propose changes, as appropriate, to the dependability design philosophy, targets and activities in order to maximize the progress towards providing assurance that the system satisfies each of the dependability requirements.
BS EN 62741:2015
– 44 –
IEC 62741:2015 © IEC 2015
Annex C (informative) Checklist of points for assessing the a dequacy of evidence
This annex provides a checklist, which should be considered as a prompt to initiate action where the checklist points have relevance and does not imply a "Yes" and "No" answer. Judgement is required to evaluate the evidence presented. The checklist should not be considered as being prescriptive or exhaustive: it is generic and provides guidance to supplement the general guidance provided in Clause 7 of this standard. Checklist: 1) Are the objectives of the activity clearly defined? 2) Has the activity been undertaken in a systematic manner and is it complete? 3) Has the activity been undertaken at a time that allows influence on the design? 4) Does the activity properly reflect the usage and environment of the system and has this been documented? 5) Has the activity been undertaken to reflect the physical and functional boundaries of the system? 6) Are any assumptions recorded (e.g. inputs from other systems or services), and are they realistic and reasonable? 7) Is justification given for the activity method/technique used, and is it reasonable? 8) Who was consulted during the activity (e.g. user, maintainer, designer)? Was this level of consultation reasonable? 9) Are the activity recommendations clearly defined, and are they reasonable? 10) Does documentary evidence indicate that the recommendations have been implemented? 11) Have the activity results been progressively updated to reflect the latest design, and are these being used as an input to design reviews?
BS EN 62741:2015
IEC 62741:2015 © IEC 2015
– 45 –
Bibliography Documents for structuring arguments Toulmin method – Toulmin, S., The Uses of Argument, 1958, 2nd edition, 2003 Goal Structuring Notation – GSN Community Standard http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf Documents for reaching formal agreements ISO/IEC 12207, Systems and software engineering – Software life cycle processes ISO/IEC 15026, Systems and software engineering – Systems and software ass urance ISO/IEC 15288, Systems and software engineering – System life cycle processes Documents for dependability IEC 60300-3-1, Dependability management – Part techniques for dependability – Guide on methodology
3-1:
Application
guide
–
Analysis
IEC 60300-3-4, Dependability management – Part 3-4: Application guide – Guide to the specification of dependability requirements IEC 61078, An aly sis techniques for dependability – Reliability block diagram and Boolean methods IEC 62347, Guidance on system dependability specifications Documents for managing risks IEC/ISO 31010, Risk management – Risk assessment techniques IEC 62198, Managing risk in projects – Application guidelines
_____________
This page deliberately left blank
This page deliberately left blank