GB/T 41295.2-2022 PDF English
Search result: GB/T 41295.2-2022 English: PDF (GB/T41295.2-2022)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GB/T 41295.2-2022 | English | 320 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Application guide of functional safety - Part 2: Design and realisation
| Valid |
BUY with any currencies (Euro, JPY, GBP, KRW etc.): GB/T 41295.2-2022 Related standards: GB/T 41295.2-2022
PDF Preview: GB/T 41295.2-2022
GB/T 41295.2-2022: PDF in English (GBT 41295.2-2022) GB/T 41295.2-2022
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 25.040
CCS N 10
Application guide of functional safety - Part 2: Design and
realisation
ISSUED ON: MARCH 09, 2022
IMPLEMENTED ON: OCTOBER 01, 2022
Issued by: State Administration for Market Regulation;
Standardization Administration of the People’s Republic of China.
Table of Contents
Foreword ... 3
Introduction ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions... 6
4 Abbreviations ... 7
5 General ... 7
6 Safety life cycle ... 8
7 System design ... 9
8 System architecture design ... 13
9 System detailed design and realisation ... 14
10 Software design and realisation ... 21
11 System integration ... 25
12 System operation and maintenance procedures ... 25
13 Validation of the system ... 27
14 Verification at each stage of the life cycle ... 27
15 Manufacturing ... 28
16 Functional safety system evaluation and assessment ... 29
References ... 32
Application guide of functional safety - Part 2: Design and
realisation
1 Scope
This document provides guidelines for the design and realisation of functional safety
systems, including safety sensors, safety logic controllers, safety communication buses,
and safety actuators.
This document applies to the team for functional safety system research and
development (e.g., manufacturer) to give normative guidance on the development of
safety products that meet the appropriate safety integrity capabilities; it is used, as a
reference, by system integrators, evaluation agencies and users for the selection and
evaluation of appropriate functional safety systems.
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
version corresponding to that date is applicable to this document; for undated references,
the latest version (including all amendments) is applicable to this document.
GB/T 19001-2016, Quality management systems - Requirements
GB/T 20438.1-2017, Functional safety of electrical/electronic/programmable
electronic safety-related systems - Part 1: General requirements
GB/T 20438.2-2017, Functional safety of electrical/electronic/programmable
electronic safety-related systems - Part 2: Requirements for
electrical/electronic/programmable electronic safety-related systems
GB/T 20438.3-2017, Functional safety of electrical/electronic/programmable
electronic safety-related systems - Part 3: Software requirements
GB/T 20438.4-2017, Functional safety of electrical/electronic/programmable
electronic safety-related systems - Part 4: Definitions and abbreviations
GB/T 20438.6-2017, Functional safety of electrical/electronic/programmable
electronic safety-related systems - Part 6: Guidelines on the application of GB/T
20438.2 and GB/T 20438.3
GB/T 34040-2017, Industrial communication networks - Functional safety fieldbus
profiles - General rules and profile definitions
GB/T 41295.3, Application guide of functional safety - Part 3: Testing and
verification
IEC 61508-3-1, Functional safety of electrical/electronic/programmable electronic
safety-related systems - Part 3-1: Software requirements - Reuse of pre-existing
software elements to implement all or part of a safety function
3 Terms and definitions
Terms and definitions determined by GB/T 20438.4-2017, and the following ones are
applicable to this document.
3.1
functional safety system
A system that performs safety-related functions, has functional safety-related
characteristics, and satisfies a specific Safety Integrity Level (SIL).
Note: The system here is a broad concept, including different levels, such as safety
components, safety equipment or safety control systems. In an actual industrial
process, the functional safety system may be a transmitter, a relay, a safety
programmable controller or a safety instrumented system.
[Source: GB/T 41295.1-2022, 3.6]
3.2
team for functional safety system research and development
The liability subject for the design and development of functional safety systems.
Note: Including functional safety system hardware developers, software developers,
verification testers, functional safety managers, etc.
3.3
functional safety system manufacture team
The main body responsible for the production and manufacture of functional safety
systems, which may include assemblers, testers, managers, and processing personnel in
the manufacturing process of functional safety systems.
requirements of relevant functional safety basic standards such as GB/T 20438.2-2017
and GB/T 20438.3-2017. In order to ensure that the expected SIL goals and
requirements are actually achieved, this document gives relevant application guidelines.
Note: In some fields, there are functional safety standards for specific fields; the
functional safety standards in these fields inherit the overall architecture and
core concepts of GB/T 20438.2-2017 and GB/T 20438.3-2017; therefore, when
meeting the functional safety requirements in these fields, the relevant content
of this document may be referred to.
5.2 Functional safety systems should also meet specific requirements for basic safety
(such as electrical safety), environmental adaptability, and reliability/stability in their
product standards, which are prerequisites for achieving the corresponding safety
integrity.
5.3 The production and manufacturing process of the functional safety system needs to
take into account the provisions in Chapter 15 or the functional safety standards in
related fields.
6 Safety life cycle
6.1 General principles
6.1.1 The team for functional safety system research and development needs to establish
a functional safety management system and define the safety life cycle stage in the early
stage of safety R&D.
6.1.2 The establishment of the functional safety management system and safety life
cycle needs to combine the requirements of functional safety standards and the existing
experience of the R&D team.
6.2 Application considerations
6.2.1 The functional safety management system needs to consider the requirements in
Chapter 6 of GB/T 20438.1-2017. The functional safety R&D department can refer to
the company's existing quality/safety management system to establish a functional
safety management system.
Note: The construction and implementation of systems such as GB/T 19001-2016 or
CMMI is a powerful guarantee for the realisation of functional safety
management.
6.2.2 The functional safety management system needs to include the requirements for
system or software changes, and needs to consider the requirements of 7.8 in GB/T
20438.2-2017 and 7.8 in GB/T 20438.3-2017. When a change occurs, the impact
8.1.4 For the architecture design, it is necessary to consider the applicable requirements
of 7.4 in GB/T 20438.2-2017.
8.1.5 It is necessary to consider a validation of architecture designs.
8.1.6 It is necessary to consider the integration test plan based on the architecture design
content.
8.2 Architecture design application considerations
8.2.1 The following aspects shall be considered in the architecture design to ensure
functional safety:
-- Ensure sufficient robustness of the system;
-- Ensure proper independence between different modules and avoid complex
coupling relationships and common cause failures;
-- Ensure that non-safety-related modules do not negatively affect safety-related
modules.
8.2.2 It is necessary to have a normative description of the static characteristics of the
architecture design (for example, a block diagram of the architecture), and describe
each module and the interfaces between modules that make up the system architecture.
8.2.3 The architecture design should avoid describing the realisation details inside each
module, which shall be the content of the subsequent detailed design.
8.2.4 The multi-channel MooN voting structure can be considered to achieve high
security or high availability design. The multi-channel voting can be realized at
different levels, such as the device level, module level, board level, and even chip level.
8.2.5 It is necessary to clearly distinguish the difference between the MooN voting
structure and the standby structure. Generally, the standby structure is used to improve
availability rather than safety.
8.2.6 After completing the architecture design verification, it is necessary to develop an
integration test plan, which includes a test strategy for all architecture features and
interface features.
9 System detailed design and realisation
9.1 General principles
9.1.1 The basic requirements for the design and development of functional safety
systems need to consider the requirements in 7.4, Appendix A and B.2 of GB/T 20438.2-
2017.
9.1.2 It is necessary to consider the preparation of relevant documents for hardware
detailed design, and realize the hardware circuit based on the detailed design.
9.2 Application considerations
9.2.1 Requirements for random hardware failures
9.2.1.1 The final random hardware failures of the functional safety system is less than
or equal to the target specified in Chapter 7 (PFDavg or PFH value), and it is proved
through reasonable modeling and calculation that the target can be achieved.
9.2.1.2 The scope of random hardware failure estimation is for all safety-related parts
of a functional safety system.
9.2.1.3 It is necessary to consider the estimation of PFDavg or PFH in accordance with
Appendix B of GB/T 20438.6-2017. If this method is adopted, ensure that the actual
system to be analyzed meets all the specified assumptions. If other methods are used,
there should be a rationality proof in line with mathematical logic.
Note: Some literatures give very simplified formulas. Be more careful about the
application of simplified formulas, because the simplified conditions may not
match the current actual project requirements, which will lead to errors in the
simplified formulas.
9.2.1.4 Consideration should be given to the use of an appropriate component failure
rate/failure model database as input to the calculation, which can be derived from:
-- International standards or national standards, industry standards, such as ISO
13849-1;
-- Commercial databases widely recognized in the field;
-- On-site feedback data with a special collection system, which shall ensure a
statistical confidence ≥ 70%.
9.2.1.5 A single source failure rate/failure mode database should be used for
calculations of the same system. Data from multiple sources should only be used if it
can be demonstrated that the data were obtained under common conditions.
9.2.1.6 Some calculation input parameters, such as inspection and test cycle (T1), mean
time to restore (MTTR) and mean repair time (MRT), are not determined by the
functional safety system R&D and design unit, therefore, it is necessary to preset a
value to participate in the calculation based on the expected application of the product.
The rationality of the value needs to be analyzed and demonstrated specifically. These
preset values should be clearly stated in the subsequent product manual of the functional
safety system.
9.2.2.4 Care should be taken to distinguish between safe failures and no-effect failures;
no-effect failures cannot be included in safe failures.
9.2.2.5 Based on the conclusions of hardware failure analysis, the existing safety design
needs to be reviewed to ensure that all critical failures are effectively controlled or
avoided.
9.2.2.6 It is necessary to carefully judge the validity of each diagnostic function. Invalid
diagnosis cannot classify the corresponding failure as diagnosable. Invalid diagnosis
includes but is not limited to:
-- The diagnostic test interval is too long to meet the requirements of the process
safety time;
-- If a multi-channel design is used, pure inter-channel voting cannot be used as a
diagnostic measure for device failure in a single channel;
-- There is no proper fault response or alarm after a fault is diagnosed.
9.2.3 Determination of diagnostic coverage
The coverage rate of each diagnostic function needs to be carefully judged, and it is
generally judged according to the following considerations.
-- For simple components, if the diagnostic test can diagnose one of its failure modes,
the diagnostic coverage of this failure mode of the device is 100%, otherwise it is
0%. Examples of simple devices: resistors, capacitors, transistors, diodes,
optocoupler, etc.
-- For complex devices, in principle, it is based on the requirements of A.1 ~ A.14 in
GB/T 20438.2-2017. If there is a statement of higher diagnostic coverage or if a
technique not specified in Appendix A of GB/T 20438.2-2017 is used, use the test
method to prove the authenticity of the achieved diagnostic coverage. Examples
of complex components: central processing unit (CPU), analog-to-digital
conversion (ADC) chips, memory cells, etc.
-- For the same device or module, two or more diagnostic methods can be used to
diagnose the same failure mode, which can achieve higher diagnostic coverage
than that specified in Appendix A of GB/T 20438.2-2017. But these different
methods must be independent, and there is no possibility of common cause failure.
9.2.4 Diagnostic functions and diagnostic coverage (DC)
9.2.4.1 For the self-diagnostic measures for the sufficiency of functional safety system
design, the determination of whether the design is sufficient shall be considered as
follows:
-- The system follows the single failure principle;
-- PFDavg/PFH meets the requirements of the target failure;
-- SFF satisfies the requirements of architectural constraints.
Note: Sufficient diagnostic functions can be more conducive to the realisation of the
above requirements, but it does not rely solely on the diagnostic functions. For
example, the failure rate and the length of the inspection test interval also have
a significant impact on whether PFDavg/PFH meets the requirements. When
these requirements cannot be met, it can be considered whether it shall be
improved through improving the diagnostic ability.
9.2.4.2 The diagnostic function is designed to meet the behavior requirements of the
system after a fault is detected.
9.2.4.3 It is necessary but not limited to perform diagnostics in the following two stages:
-- During system initialization, the diagnostic focus is on all hardware, internal or
external data paths, etc.;
-- During the normal operation cycle, perform the diagnostic function, where the
focus includes hardware, software, soft error, data path and so on.
9.2.4.4 The interval time of all diagnostics, that is, the diagnostic test interval (TD),
should be determined based on the operating cycle of the system and the time when all
diagnostic functions are realized.
9.2.4.5 The diagnostic test interval should be small enough to meet 7.4.5.3 and 7.4.5.4
in GB/T 20438.2-2017.
9.2.4.6 In order to avoid frequent mis-operations, some diagnostic functions may adopt
a mechanism of diagnosing and decision-making after multiple judgments. It needs to
be considered that such multiple judgments and retries may lead to some kind of infinite
loop or failure to achieve the specified diagnostic capabilities.
9.2.5 Architectural constraints
9.2.5.1 The basic requirements of architectural constraints need to be considered to
meet 7.4.4 in GB/T 20438.2-2017.
9.2.5.2 The route 1 (1H) of 7.4.4 in GB/T 20438.2-2017 should be preferred, that is, the
SIL target that the architectural constraints satisfy is given by the determination of
hardware fault tolerance (HFT) and safe failure fraction (SFF).
9.2.5.3 The determination of HFT requires careful analysis of the redundancy methods
used. Some redundancy methods cannot guarantee the improvement of the hardware
fault tolerance.
9.2.7.3 When a critical dangerous failure is detected during system operation, it shall
result in:
-- Switch all fault-affected outputs to a defined safe state by built-in measures (such
as hardware or embedded software) within the fault response time specified by
the manufacturer; or
-- Notify (alarm) the fault to the applied measure (e.g., application) within the fault
response time specified by the manufacturer, so that the applied measure (e.g.,
application) can take appropriate action to maintain safety;
-- If it has not entered a safe state after any of the above situations, it means that the
system is already in degraded operation. If the system is not designed to
automatically output a safe value if there is no maintenance within the specified
time after the degraded operation, lead the process into a safe state; the function
of automatically entering a safe state after the degrading cannot be manually
turned off by the field operators; the specified time is included in the failure
calculation as one of the influencing factors of the mean time to restore (MTTR).
Note 1: The definition of critical dangerous faults is determined during the hazard
and risk analysis; it generally refers to those dangerous faults that cannot
perform safety functions and cannot be automatically recovered in a
short time.
Note 2: Which action is appropriate depends on the application, and the team for
functional safety system research and development can design it in a
configurable way.
9.2.7.4 Faults need to be detected and notified (alarmed) to the application, unless either
of the following conditions occurs:
-- By design, this fault is unlikely to occur in the system;
-- The failure is proven negligible by a written technical evaluation.
9.2.8 Safety data communication
9.2.8.1 The system generally has two types of data communication, one is safety-related
communication, and the other is non-safety-related communication. For safety-related
communication, it is necessary to consider the requirements of 7.4.11 in GB/T 20438.2-
2017.
9.2.8.2 Two methods, namely black channel and white channel, can be used to realize
secure communication. For the industrial control field, the black channel should be
adopted according to the requirements of GB/T 34040-2017.
9.2.8.3 In addition to estimating the residual error rate, it is also necessary to consider
proving the error detection capability of secure communication through testing. The
specific testing method is in accordance with the provisions of GB/T 41295.3.
9.2.8.4 The internal communication path may not be implemented in accordance with
the requirements of GB/T 34040-2017, but it also needs to have sufficient transmission
error detection capabilities.
Note: Typical internal communication paths include: data communication between
internal chips (such as I2C, etc.), and interface communication between two
boards in the same module.
9.2.8.5 Security layer software implementing secure communication protocols needs to
consider compliance with chapter 10.
9.2.8.6 ASIC component safety design: If the system includes ASIC components (such
as FPGA, CPLD, etc.), its development process needs to consider compliance with the
requirements of Appendix F in GB/T 20438.2-2017.
9.2.8.7 Realisation of hardware based on detailed hardware design needs to be
considered.
10 Software design and realisation
10.1 General principles
10.1.1 Software design and realisation includes software safety requirement
specification, software architecture design and software detailed design and realisation.
10.1.2 Safety-related software includes: embedded firmware of the system, operating
system applied by the system, security database applied by the system, online support
tools, etc.
10.1.3 The general principles of safety software design and realisation should comply
with GB/T 20438.3-2017.
10.1.4 Implement software detailed design and realisation based on the completed
software safety requirement specification and software architecture design.
10.1.5 Prepare the software validation plan according to the requirements of 7.3 in
GB/T 20438.3-2017,
10.2 Application considerations
10.2.1 Software safety requirement specification
-- T3: Produces output that can directly or indirectly affect the executable code of
safety-related systems.
Note 1: Examples of T1 include: text editors or support tools without requirements or
design of automatic code generation capabilities; configuration control tools.
Note 2: Examples of T2 include: test fixture generators; test coverage measurement
tools; static analysis tools.
Note 3: Examples of T3 include: optimizing compilers in which the relationship
between source code programs and generated object code is not obvious;
compilers that combine an executable runtime package into executable code.
Note 4: This classification is based on 3.2.11 in GB/T 20438.4-2017.
10.2.3.3 For offline support tools that have been evaluated for compliance in
accordance with GB/T 20438.3-2017, the designer may consider applying the tools
directly in accordance with the requirements of the tool manual.
10.2.3.4 For offline support tools that have not been evaluated for compliance in
accordance with GB/T 20438.3-2017, the designer needs to demonstrate the
applicability and correctness of the tool and form a demonstration report.
10.2.4 Programming language
10.2.4.1 Select a programming language that conforms to product characteristics and is
suitable for software designers.
10.2.4.2 For a specific programming language, it is necessary to consider appropriate
coding rules to standardize and constrain the realisation of the code. The coding rules
need to consider at least the standardized coding style and the coding forms that can
and cannot be used.
10.2.4.3 The content of the coding rules should come from:
-- The company's existing coding experience of similar projects, company
regulations, etc.;
-- International and domestic general and recognized coding rules or standards, such
as Mirsa C/C++, etc.;
-- Special circumstances of the project to be implemented, such as the special
circumstances of the compilation environment or test tools.
10.2.5 Software failure analysis
10.2.5.1 Software failure analysis should be carried out for SIL1 and SIL2 software,
and software failure analysis should be considered for SIL3 and SIL4 software.
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|