标准编号:	GB/T 20438.3-2017
中文名称:	电气/电子/可编程电子安全相关系统的功能安全 第3部分：软件要求
英文名称:	Functional safety of electrical/electronic/programmable electronic safety-related systems—Part 3: Software requirements
行业分类:	GB    国家标准
发布机构:	中华人民共和国国家质量监督检验检疫总局 中国国家标准化管理委员会
发布日期:	2017-12-29
实施日期:	2018-7-1
标准状态:	现行
替代旧标准:	GB/T 20438.3-2006 电气/电子/可编程电子安全相关系统的功能安全 第3部分: 软件要求
翻译语言:	英文
文件格式:	PDF
中文字符数:	82000 字
翻译价格(元):	4550.00 元
交付时间:	付款后 1 个工作日

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

电气/电子/可编程电子安全相关系统的
功能安全 第3部分：软件要求
1范围
1.1 GB/T 20438的本部分：
a)应建立在充分理解GB/T 20438.1和GB/T 20438.2的基础上使用；
b)适用于在GB/T 20438.1和GB/T 20438.2范围内构成安全相关系统的一部分或用于开发安全相关系统的任何软件。这种软件定义为安全相关软件(安全相关软件包括操作系统、系统软件、通信网络中的软件、人机界面功能、固件以及应用软件)；
c)提供适用于在GB/T 20438.1和GB/T 20438.2范围内开发和配置安全相关系统的支持工具的特定要求；
d)要求规定软件安全功能和软件系统性能力；
注1：如果这一要求作为电气/电子/可编程电子安全相关系统规范(见GB/T 20438.2—2017中7.2)的一部分已提出，则在此处不需重复。
注2：规定软件安全功能和软件系统性能力是一个反复的过程，见图3和图6。
注3：文档结构要求见GB/T 20438.1—2017的第5章和附录A。文档结构可能要考虑公司规程和特殊应用领域的工作实际情况。
注4：关于术语“系统性能力”的定义见GB/T 20438.4—2017的3.5.9。
e)建立安全相关软件设计开发过程中(软件安全生命周期模型)对安全生命周期各阶段和需开展活动的要求。这些要求包括根据系统性能力分级的、在软件中用于避免和控制故障及失效的措施和技术的应用。
f)对系统安全确认软件方面相关的信息提出了要求，这些信息将传递给执行E/E/PE系统集成的机构。
g)对操作和维护E/E/PE安全相关系统的用户所需的软件有关的信息和规程的准备提出要求。
h)对修改安全相关软件的机构提出要求。
i)结合GB/T 20438.1和GB/T 20438.2，提出对支持工具的要求如设计开发工具、语言翻译器、测试和调试工具、配置管理工具。
注5：图5表示了GB/T 20438.2和GB/T 20438.3之间的关系。
j)不适用于符合IEC 60601系列的医疗设备。
1.2 GB/T 20438.1、GB/T 20438.2、GB/T 20438.3和GB/T 20438.4是基础的安全标准，虽然它不适用于低复杂的E/E/PE安全相关系统(见GB/T 20438.4—2017的3.4.3)，但作为基础安全标准，各技术委员会可以在IEC指南104和ISO/IEC指南51的指导下制定相关标准时使用。GB/T 20438.1、GB/T 20438.2、GB/T 20438.3和GB/T 20438.4也可作为独立标准来使用。GB/T 20438的横向安全功能不适用于在IEC 60601系列指导下的医疗设备。
1.3各技术委员会的责任之一，是在其标准的起草工作中尽可能使用基础的安全标准。在本部分中，本基础安全标准中的要求、测试方法或测试条件只有在这些技术委员会起草的标准中已明确引用或包含时适用。
1.4 图1表示了GB/T 20438的整体框架，同时明确了本部分在实现E/E/PE安全相关系统功能安全过程中的作用。

技术要求
第1部分
编制整体安全要求(概念、范围、定义、危险和风险分析)
7.1～7.5
第1部分
将安全要求分配给E/E/PE安全相关系统
7.6
第1部分
E/E/PE安全相关系统的系统安全要求规范
7.10
第2部分
E/E/PE安全相关系统的实现阶段
第3部分
安全相关软件的实现阶段
第1部分
E/E/PE安全相关系统的安装、调试和安全确认
7.13和7.14
第1部分
E/E/PE安全相关系统的操作、维护、修理、修改和改型、退役或处置
7.15～7.17
第5部分
确定安全完整性等级的方法示例
第6部分
第2部分和第3部分的应用指南
第7部分
技术和措施概述
其他要求
第4部分
定义和缩略语
第1部分
文档
第5章和附录A
第1部分
功能安全的管理
第6章
第1部分
功能安全评估
第8章
图1 GB/T 20438的整体框架

概念
整体范围确定
危险和风险分析
整体安全要求
整体安全要求分配
整体计划编制
注：整体运行和维护计划编制
注：整体安全确认计划编制
注：整体安装和调试计划编制
E/E/PE系统安全要求规范
E/E/PE安全相关系统
实现(见E/E/PE系统安全生命周期)
其他风险降低措施
规范和实现
整体安装和调试
整体安全确认
整体运行、维护和修理
返回适当的整体安全生命周期阶段
整体修改和改型
退役或处置
图2整体安全生命周期
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 20438.1—2017 电气/电子/可编程电子安全相关系统的功能安全 第1部分：一般要求(IEC 61508-1：2010，IDT)
GB/T 20438.2—2017 电气/电子/可编程电子安全相关系统的功能安全 第2部分：电气/电子/可编程电子安全相关系统的要求(IEC 61508-2：2010，IDT)
GB/T 20438.4—2017 电气/电子/可编程电子安全相关系统的功能安全 第4部分：定义及缩略语(IEC 61508-4：2010，IDT)
IEC Guide 104：1997安全出版物的编写及基础安全出版物和多专业共用安全出版物的应用导则(The preparation of safety publications and the use of basic safety publications and group safety publi-cations)
IEC/ISO Guide 51：1999 涉及安全的内容将安全内容纳入标准的指南(Safety aspects-Guidelines for their inclusion in standards)
3定义和缩略语
GB/T 20438.4—2017界定的定义和缩略语适用于本文件。
4标准的符合性
本部分对GB/T 20438的符合性要求，详见GB/T 20438.1—2017的第4章。
5文档
本部分对文档的要求，详见GB/T 20438.1—2017的第5章。
6安全相关软件管理的附加要求
6.1 目的
见GB/T 20438.1—2017中6.1。
6.2要求
6.2.1见GB/T 20438.1—2017中6.2，以下为附加要求。
6.2.2功能安全计划应规定由E/E/PE安全相关系统执行安全功能的安全完整性等级所需的软件采购、开发、集成、验证、确认和修改的策略。
注：该方法的理念是：考虑到E/E/PE安全相关系统执行每个安全功能所要求的安全完整性等级，用功能安全计划作为对本部分进行定制使用的手段。
6.2.3软件配置管理：
a)应在整个软件安全生命周期中使用管理和技术控制以管理软件变更，从而保证安全相关软件的规定要求始终能得到满足；
b)应确保所有必需的操作已被执行以证明达到了所需的软件系统性能力；
c)应准确地和带唯一标识地维护满足E/E/PE安全相关系统性安全完整性要求所必需的所有配置项。配置项至少包括：安全分析和要求、软件规范和设计文档、软件源代码模块、测试计划和结果、验证文档、将要被纳入E/E/PE安全相关系统的已有软件组件和软件包；所有用于创建、测试或执行E/E/PE安全相关系统软件的工具和开发环境；
d)应采用变更控制规程：
——防止非授权的修改；归档修改请求；
——分析建议修改的影响以批准或拒绝请求；
——归档所有准许修改的细节和授权；
——在软件开发阶段中的适当点建立配置基线，并归档基线的(部分)集成测试；
——确保所有软件基线的构成和建立(包括早期基线的重建)。
注1：为指导、加强管理和技术控制的使用，有必要进行管理决定和授权。
注2：一种极端情况，影响分析可能包括一次非正式的评估；另一种极端情况，影响分析可能包括针对所有可能被不恰当地理解或执行的建议变更的潜在不利影响进行一次严格正式分析。见GB/T 20438.7影响分析指南。
e)确保使用适当方法，正确地加载有效软件组件和数据到运行时系统；
注3：本条款可能包括列特定目标系统以及通用系统的考虑。非应用软件可能需要一种安全的加载方法，如：固件。
f)应归档下列信息，以用于随后的功能安全审核：配置状态、发布状态、对所有修改的论证(考虑影响分析)、批准和修改的详细情况；
g)应正式归档安全相关软件的发布。软件的主要备份和所有有关文档和服务的数据版本在已发布软件的操作生命周期内应被保存，以允许维护和修改。
注4：对于配置管理的更详细的信息，见GB/T 20438.7。
7软件安全生命周期要求
7.1概述
7.1.1 目的
7.1的目的是将软件开发纳入到已定义的各阶段和活动中(见表1、图3～图6)。
7.1.2要求
7.1.2.1 软件开发的安全生命周期应在根据GB/T 20438.1—2017第6章的安全计划编制期间进行挑选和规定。
7.1.2.2只要本章的所有目的和要求都得到满足，可以使用任何的软件生命周期模型。
7.1.2.3软件安全生命周期的每个阶段应分成若干基本活动，每个阶段应规定范围、输入和输出。
注：见图3、图4和表1。
7.1.2.4只要软件安全生命周期满足表1要求，允许根据项目的安全完整性和复杂性对V模型(见图6)进行裁剪。
注1：满足本章要求的软件安全生命周期模型可按照项目或组织的需要适当定制。表1中生命周期各阶段的全部列表更适用新开发的大型系统。对于小的系统，例如将软件系统设计和架构设计合并也是合适的。
注2：数据驱动系统特性(例如：全可变/有限可变编程语言、数据配置的程度)见附录G，这些特性在定制软件安全生命周期时可能是相关的。
7.1.2.5软件安全生命周期的定制应基于功能安全进行论证。
7.1.2.6质量和安全保证规程应该集成到安全生命周期活动中。
7.1.2.7对生命周期的每个阶段，应使用适当的技术和措施。附录A和附录B提供了选择技术和措施的指南，并参考GB/T 20438.6和GB/T 20438.7。GB/T 20438.6和GB/T 20438.7给出了达到系统性安全完整性要求属性的特定技术推荐。仅从这些推荐中选择技术不能保证就实现了要求的安全完整性。
注：成功实现系统性安全完整性依赖于在选择技术时考虑如下因素：
——为整个开发周期选择的方法、语言和工具的一致性和互补性；
——开发者是否完全理解使用方法、语言和工具；
——在开发期间，方法、语言和工具是否对遇到的特定问题有很好的适用性。
7.1.2.8软件安全生命周期中的活动结果应归档(见第5章)。
注：GB/T 20438.1—2017第5章考虑了安全生命周期各阶段输出的文档。在E/E/PE安全相关系统的开发中，某些安全生命周期阶段的输出文档可能是单独的，而一些阶段的输出文档可能是合并的。本质的要求是安全生命周期阶段的输出与预期目的相匹配。
7.1.2.9如果在软件安全生命周期的任一阶段，要求对早期生命周期阶段改变时，那么要进行影响分析以确定：(1)哪个软件模块受到影响；(2)早期安全生命周期的哪些活动应该重复。
注：一种极端情况，影响分析可能包括一次非正式的评估；另一种极端情况，影响分析可能包括针对所有可能被不恰当地理解或执行的建议变更的潜在不利影响进行一次严格正式分析，见GB/T 20438.7影响分析指南。

图2的方框10
E/E/PE安全相关系统
实现(见E/E/PE系统安全生命周期)
E/E/PE系统安全生命周期(在实现阶段)
E/E/PE系统设计要求规范
E/E/PE系统安全确认计划编制
E/E/PE系统设计和开发包括ASIC和软件(见GB/T 20488.2-××××图3和GB/T20438.3)
E/E/PE系统集成
E/E/PE系统安全确认至图2方框12
E/E/PE系统安装、调试、运行和维护规程
至图2方框14
每个E/E/PE安全相关系统的一个E/E/PE安全生命周期
图3 E/E/PE系统安全生命周期(在实现阶段)

E/E/PE系统安全生命周期(见图3)
软件安全生命周期(在实现阶段)
软件安全要求规范
系统安全软件
部分的确认计划
软件设计和开发
PE集成(硬件和软件)
系统安全确认的软件部分
至图2方框12
软件运行和维护规程
至图2方框14
图4 软件安全生命周期(在实现阶段)