GB/T 20438 consists of seven parts under the general title of Functional safety of electrical/electronic/programmable electronic safety-related systems:
——Part 1: General requirements;
——Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems;
——Part 3: Software requirements;
——Part 4: Definitions and abbreviations;
——Part 5: Examples of methods for the determination of safety integrity levels;
——Part 6: Guidelines on the application of GB/T 20438.2 and GB/T 20438.3;
——Part 7: Overview of techniques and measures.
This is Part 3 of GB/T 20438.
This part is developed in accordance with the rules given in GB/T 1.1-2009.
This part replaces GB/T 20438.3-2006 Functional safety of electrical/ electronic/ programmable electronic safety-related systems - Part 3: Software requirements and the following main technical changes have been made with respect to GB/T 20438.3-2006:
——“Properties for software systematic capability” is added (see Annex C);
——“Safety manual for compliant items –additional requirements for software elements” is added (see Annex D);
——“Relationships between GB/T 20483.2 and GB/T 20483.3” is added (see Annex E);
——“Techniques for achieving non-interference between software elements on a single computer” is added (see Annex F);
——“Guidance for tailoring lifecycles associated with data driven systems” is added (see Annex G).
This part, by means of translation, is identical to IEC 61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems - Software requirements.
This part was proposed by the China Machinery Industry Federation.
This part is under the jurisdiction of SAC/TC 124 National Technical Committee on Industrial Process Measurement and Control of Standardization Administration of China.
The previous edition of this part is as follow:
——GB/T 20438.3-2006.
Introduction
Systems comprised of electrical and/or electronic elements have been used for many years to perform safety functions in most application sectors. Computer-based systems (generically referred to as programmable electronic systems) are being used in all application sectors to perform non-safety functions and, increasingly, to perform safety functions. If computer system technology is to be effectively and safely exploited, it is essential that those responsible for making decisions have sufficient guidance on the safety aspects on which to make these decisions.
GB/T 20438 sets out a generic approach for all safety lifecycle activities for systems comprised of electrical and/or electronic and/or programmable electronic (E/E/PE) elements that are used to perform safety functions. This unified approach has been adopted in order that a rational and consistent technical policy be developed for all electrically-based safety-related systems. A major objective is to facilitate the development of product and application sector standards based on the GB/T 20438 series.
Note 1: Examples of product and application sector standards based on the GB/T 20438 series are given in the Bibliography (see references [1], [2] and [3]).
In most situations, safety is achieved by a number of systems which rely on many technologies (for example mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic). Any safety strategy must therefore consider not only all the elements within an individual system (for example sensors, controlling devices and actuators) but also all the safety-related systems making up the total combination of safety-related systems. Therefore, while GB/T 20438 is concerned with E/E/PE safety-related systems, it may also provide a framework within which safety-related systems based on other technologies may be considered.
It is recognized that there is a great variety of applications using E/E/PE safety-related systems in a variety of application sectors and covering a wide range of complexity, hazard and risk potentials. In any particular application, the required safety measures will be dependent on many factors specific to the application. GB/T 20438, by being generic, will enable such measures to be formulated in future product and application sector standards and in revisions of those that already exist.
GB/T 20438
——considers all relevant overall, E/E/PE system and software safety lifecycle phases (for example, from initial concept, thorough design, implementation, operation and maintenance to decommissioning) when E/E/PE systems are used to perform safety functions;
——has been conceived with a rapidly developing technology in mind; the framework is sufficiently robust and comprehensive to cater for future developments;
——enables product and application sector standards, dealing with E/E/PE safety-related systems, to be developed; the development of product and application sector standards, within the framework of GB/T 20438, should lead to a high level of consistency (for example, of underlying principles, terminology etc.) both within application sectors and across application sectors; this will have both safety and economic benefits;
——provides a method for the development of the safety requirements specification necessary to achieve the required functional safety for E/E/PE safety-related systems;
——adopts a risk-based approach by which the safety integrity requirements can be determined;
——introduces safety integrity levels for specifying the target level of safety integrity for the safety functions to be implemented by the E/E/PE safety-related systems;
Note 2: GB/T 20438 does not specify the safety integrity level requirements for any safety function, nor does it mandate how the safety integrity level is determined. Instead it provides a risk-based conceptual framework and example techniques.
——sets target failure measures for safety functions carried out by E/E/PE safety-related systems, which are linked to the safety integrity levels;
——sets a lower limit on the target failure measures for a safety function carried out by a single E/E/PE safety-related system. For E/E/PE safety-related systems operating in
——a low demand mode of operation, the lower limit is set at an average probability of a dangerous failure on demand of 10-5;
——a high demand or a continuous mode of operation, the lower limit is set at an average frequency of a dangerous failure of 10-9/h.
Note 3: A single E/E/PE safety-related system does not necessarily mean a single-channel architecture.
Note 4: It may be possible to achieve designs of safety-related systems with lower values for the target safety integrity for non-complex systems, but these limits are considered to represent what can be achieved for relatively complex systems (for example programmable electronic safety-related systems) at the present time.
——sets requirements for the avoidance and control of systematic faults, which are based on experience and judgement from practical experience gained in industry. Even though the probability of occurrence of systematic failures cannot in general be quantified GB/T 20438 does, however, allow a claim to be made, for a specified safety function, that the target failure measure associated with the safety function can be considered to be achieved if all the requirements in the standard have been met;
——introduces systematic capability which applies to an element with respect to its confidence that the systematic safety integrity meets the requirements of the specified safety integrity level;
——adopts a broad range of principles, techniques and measures to achieve functional safety for E/E/PE safety-related systems, but does not explicitly use the concept of fail safe. However, the concepts of “fail safe” and “inherently safe” principles may be applicable and adoption of such concepts is acceptable providing the requirements of the relevant clauses in the standard are met.
Functional safety of electrical/ electronic/ programmable electronic safety-related systems - Part 3: Software requirements
1 Scope
1.1 This part of the GB/T 20438 series
a) is intended to be utilized only after a thorough understanding of GB/T 20438.1 and GB/T 20438.2;
b) applies to any software forming part of a safety-related system or used to develop a safety-related system within the scope of GB/T 20438.1 and GB/T 20438.2. Such software is termed safety-related software (including operating systems, system software, software in communication networks, human-computer interface functions, and firmware as well as application software);
c) provides specific requirements applicable to support tools used to develop and configure a safety-related system within the scope of GB/T 20438.1 and GB/T 20438.2;
d) requires that the software safety functions and software systematic capability are specified;
Note 1: If this has already been done as part of the specification of the E/E/PE safety-related systems (see 7.2 of GB/T 20438.2-2017), then it does not have to be repeated in this part.
Note 2: Specifying the software safety functions and software systematic capability is an iterative procedure; see Figures 3 and 6.
Note 3: See Clause 5 and Annex A of GB/T 20438.1-2017 for documentation structure. The documentation structure may take account of company procedures, and of the working practices of specific application sectors.
Note 4: See 3.5.9 of GB/T 20438.4-2017 for definition of the term "systematic capability".
e) establishes requirements for safety lifecycle phases and activities which shall be applied during the design and development of the safety-related software (the software safety lifecycle model). These requirements include the application of measures and techniques, which are graded against the required systematic capability, for the avoidance of and control of faults and failures in the software;
f) provides requirements for information relating to the software aspects of system safety validation to be passed to the organisation carrying out the E/E/PE system integration;
g) provides requirements for the preparation of information and procedures concerning software needed by the user for the operation and maintenance of the E/E/PE safety-related system;
h) provides requirements to be met by the organisation carrying out modifications to safety-related software;
i) provides, in conjunction with GB/T 20438.1 and GB/T 20438.2, requirements for support tools such as development and design tools, language translators, testing and debugging tools, configuration management tools;
Note 5: Figure 5 shows the relationship between GB/T 20438.2 and GB/T 20438.3.
j) Does not apply for medical equipment in compliance with the IEC 60601 series.
1.2 GB/T 20438.1, GB/T 20438.2, GB/T 20438.3 and GB/T 20438.4 are basic safety publications, although this status does not apply in the context of low complexity E/E/PE safety-related systems (see 3.4.3 of GB/T 20438.4-2017). As basic safety publications, they are intended for use by technical committees in the preparation of standards in accordance with the principles contained in IEC Guide 1 04 and ISO/IEC Guide 51. GB/T 20438.1, GB/T 20438.2, GB/T 20438.3 and GB/T 20438.4 are also intended for use as stand-alone publications. The horizontal safety function of GB/T 20438 does not apply to medical equipment in compliance with the IEC 60601 series.
1.3 One of the responsibilities of a technical committee is, wherever applicable, to make use of basic safety publications in the preparation of its publications. In this context, the requirements, test methods or test conditions of this basic safety publication will not apply unless specifically referred to or included in the publications prepared by those technical committees.
1.4 Figure 1 shows the overall framework of the GB/T 20438 series and indicates the role that this part plays in the achievement of functional safety for E/E/PE safety-related systems.
Figure 1 Overall framework of the GB/T 20438 series
Figure 2 Overall safety lifecycle
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
GB/T 20438.1-2017 Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 1: General requirements (IEC 61508-1:2010, IDT)
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 (IEC 61508-2:2010, IDT)
GB/T 20438.4-2017 Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations (IEC 61508-4:2010, IDT)
IEC Guide 104:1997 The preparation of safety publications and the use of basic safety publications and group safety publications
IEC/ISO Guide 51:1999 Safety aspects - Guidelines for their inclusion in standards
3 Definitions and abbreviations
For the purposes of this document, the definitions and abbreviations given in GB/T 20438.4-2017 apply.
4 Conformance to GB/T 20438
The requirements for conformance to GB/T 20438 are as detailed in Clause 4 of GB/T 20438.1-2017.
5 Documentation
The requirements for documentation are as detailed in Clause 5 of GB/T 20438.1-2017.
6 Additional requirements for management of safety-related software
6.1 Objectives
The objectives are as detailed in 6.1 of GB/T 20438.1-2017.
6.2 Requirements
6.2.1 The requirements are as detailed in 6.2 of GB/T 20438.1-2017, with the following additional requirements.
6.2.2 The functional safety planning shall define the strategy for software procurement, development, integration, verification, validation and modification to the extent required by the safety integrity level of the safety functions implemented by the E/E/PE safety-related system.
Note: The philosophy of this approach is to use the functional safety planning as an opportunity to customize this standard to take account of the required safety integrity for each safety function implemented by the E/E/PE safety-related system.
6.2.3 Software configuration management shall:
a) apply administrative and technical controls throughout the software safety lifecycle, in order to manage software changes and thus ensure that the specified requirements for safety-related software continue to be satisfied;
b) guarantee that all necessary operations have been carried out to demonstrate that the required software systematic capability has been achieved;
c) maintain accurately and with unique identification all configuration items which are necessary to meet the safety integrity requirements of the E/E/PE safety-related system. Configuration items include at least the following: safety analysis and requirements; software specification and design documents; software source code modules; test plans and results; verification documents; pre-existing software elements and packages which are to be incorporated into the E/E/PE safety-related system; all tools and development environments which are used to create or test, or carry out any action on, the software of the E/E/PE safety-related system;
d) apply change-control procedures:
——to prevent unauthorized modifications; to document modification requests;
——to analyse the impact of a proposed modification, and to approve or reject the request;
——to document the details of, and the authorisation for, all approved modifications;
——to establish configuration baseline at appropriate points in the software development, and to document the (partial) integration testing of the baseline;
——to guarantee the composition of, and the building of, all software baselines (including the rebuilding of earlier baselines).
Note 1: Management decision and authority is needed to guide and enforce the use of administrative and technical controls.
Note 2: At one extreme, an impact analysis may include an informal assessment. At the other extreme, an impact analysis may include a rigorous formal analysis of the potential adverse impact of all proposed changes which may be inadequately understood or implemented. See GB/T 20438.7 for guidance on impact analysis.
e) ensure that appropriate methods are implemented to load valid software elements and data correctly into the run-time system;
Note 3: This may include consideration of specific target location systems as well as general systems. Software other than application might need a safe loading method, e.g. firmware.
f) document the following information to permit a subsequent functional safety audit: configuration status, release status, the justification (taking account of the impact analysis) for and approval of all modifications, and the details of the modification;
g) formally document the release of safety-related software. Master copies of the software and all associated documentation and version of data in service shall be kept to permit maintenance and modification throughout the operational lifetime of the released software.
Note 4: For further information on configuration management, see GB/T 20438.7.
Foreword i
Introduction iii
1 Scope
2 Normative references
3 Definitions and abbreviations
4 Conformance to GB/T 2
5 Documentation
6 Additional requirements for management of safety-related software
6.1 Objectives
6.2 Requirements
7 Software safety lifecycle requirements
7.1 General
7.2 Software safety requirements specification
7.3 Validation plan for software aspects of system safety
7.4 Software design and development
7.5 Programmable electronics integration (hardware and software)
7.6 Software operation and modification procedures
7.7 Software aspects of system safety validation
7.8 Software modification
7.9 Software verification
8 Functional safety assessment
Annex A (Normative) Guide to the selection of techniques and measures
Annex B (Informative) Detailed tables
Annex C (Informative) Properties for software systematic capability
Annex D (Normative) Safety manual for compliant items - additional requirements for software elements
Annex E (Informative) Relationships between GB/T 20438.2 and GB/T 204
Annex F (Informative) Techniques for achieving non-interference between software elements on a single computer
Annex G (Informative) Guidance for tailoring lifecycles associated with data driven systems
Bibliography
Figure 1 Overall framework of the GB/T 20438 series
Figure 2 Overall safety lifecycle
Figure 3 E/E/PE system safety lifecycle (in realisation phase)
Figure 4 Software safety lifecycle (in realisation phase)
Figure 5 Relationship between and scope of GB/T 20438.2 and GB/T 204
Figure 6 Software systematic capability and the development lifecycle (the V-model)
Figure G.1 Variability in complexity of data driven systems
Table 1 Software safety lifecycle - overview
Table A.1 Software safety requirements specification (see 7.2)
Table A.2 Software design and development – software architecture design (7.4.3)
Table A.3 Software design and development – support tools and programming language (see 7.4.4)
Table A.4 Software design and development – detailed design (see 7.4.5 and 7.4.6)
Table A.5 Software design and development – software module testing and integration (see 7.4.7 and 7.4.8)
Table A.6 Programmable electronics integration (hardware and software) (see 7.5)
Table A.7 Software aspects of system safety validation (see 7.7).
Table A.8 Modification (see 7.8)
Table A.9 Software verification (see 7.9)
Table A.10 Functional safety assessment (see Clause 6)
Table B.1 Design and coding standards
Table B.2 Dynamic analysis and testing
Table B.3 Functional and black-box testing
Table B.4 Failure analysis
Table B.5 Modeling
Table B.6 Performance testing
Table B.7 Semi-formal methods
Table B.8 Static analysis
Table B.9 Modular approach
Table C.1 Properties for systematic safety integrity - Software safety requirements specification
Table C.2 Properties for systematic safety integrity - Software design and development - software Architecture Design
Table C.3 Properties for systematic safety integrity - Software design and development - support tools and programming language
Table C.4 Properties for systematic safety integrity - Software design and development - Detailed design (includes software system design, software module design and coding)
Table C.5 Properties for systematic safety integrity - Software design and development - software module testing and integration
Table C.6 Properties for systematic safety integrity - Programmable electronics integration (hardware and software)
Table C.7 Properties for systematic safety integrity - Software aspects of system safety validation
Table C.8 Properties for systematic safety integrity - Software modification
Table C.9 Properties for systematic safety integrity - Software verification
Table C.10 Properties for systematic safety integrity - Functional safety assessment
Table C.11 Detailed properties - Design and coding standards
Table C.12 Detailed properties - Dynamic analysis and testing
Table C.13 Detailed properties - Functional and black-box testing
Table C.14 Detailed properties - Failure analysis
Table C.15 Detailed properties - Modelling
Table C.16 Detailed properties - Performance testing
Table C.17 Detailed properties - Semi-formal methods
Table C.18 Properties for systematic safety integrity - Static analysis
Table C.19 Detailed properties - Modular approach
Table E.1 Categories of GB/T 20438.2 requirements
Table E.2 Requirements of GB/T 20438.2 for software and their typical relevance to certain types of software
Table F.1 Module coupling – definition of terms
Table F.2 Types of module coupling
Figure G.1 Variability in complexity of data driven systems
