GBT《道路车辆 功能安全审核及评估方法》-第3部分:软件层面

 

1      范围... 5

2      规范性引用文件... 5

3      术语和定义... 5

4      要求... 5

4.1 一般要求... 5

4.2 审核和评估结果的汇总... 6

4.3 软件层面功能安全审核和评估结果... 6

4.4 功能安全审核和评估的独立性要求... 6

5      软件开发环境的审核和评估... 7

5.1 目的... 7

5.2 审核和评估的输入... 7

5.2.1前提条件... 7

5.2.2支持信息... 7

审核和评估的要求... 7

6      软件安全要求的审核和评估... 8

6.1 目的... 8

6.2 审核和评估的输入... 8

6.2.1前提条件... 8

6.2.2 支持信息:... 8

6.3 审核和评估的要求... 8

7      软件架构设计规范的审核和评估... 9

7.1 目的... 9

7.2 审核和评估的输入... 9

7.2.1前提条件... 9

7.2.2 支持信息... 10

7.3 审核和评估的要求... 10

8      软件单元设计及实现的审核和评估... 11

8.1 目的... 11

8.2 审核和评估的输入... 11

8.2.1 前提条件... 12

8.2.2 支持信息... 12

8.3 审核和评估的要求... 12

9      软件单元测试的审核和评估... 13

9.1 目的... 13

9.2 审核和评估的输入... 13

9.2.1 前提条件... 13

9.2.2 支持信息... 13

9.3 审核和评估的要求... 13

10        软件集成和验证的审核和评估... 14

10.1 目的... 14

10.2 审核和评估的输入... 15

10.2.1 前提条件... 15

10.2.2 支持信息... 15

10.3 审核和评估的要求... 15

11        嵌入式软件测试的审核和评估... 16

11.1目的... 16

11.2审核和评估的输入... 16

11.2.1前提条件... 16

11.2.2 支持信息... 16

11.3审核和评估的要求... 16

12        软件标定和配置管理的审核和评估... 17

12.1目的... 17

12.2审核和评估的输入... 17

12.2.1 前提条件... 17

12.2.2 支持信息... 18

12.3审核和评估要求... 18

13        软件工具鉴定的审核和评估... 19

13.1目的... 19

13.2审核和评估的输入... 19

13.2.1前提条件... 19

13.2.2 支持信息... 19

13.3审核和评估要求... 20

14        软件组件鉴定的审核和评估... 23

14.1目的... 23

14.2审核和评估的输入... 23

14.2.1前提条件... 23

14.2.2支持信息... 23

14.3审核和评估要求... 23

附录A. 26

附录B. 28

附录C. 31

附录D.. 36

附录E. 38

附录F. 41

附录G.. 44

附录H.. 46

附录I 49

附录J 56

道路车辆 功能安全审核及评估方法

第3部分:软件层面

  1. 范围

本标准规定了针对安全相关的电气/电子(E/E)系统在软件层面的功能安全相关活动和工作成果,开展功能安全审核及评估的要求和方法,以检查和判断开发过程及工作成果对于功能安全的符合性。

  1. 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。

GB/T 34590-XXXX(所有部分) 道路车辆 功能安全(ISO 26262:2018,MOD)

  1. 术语和定义

GB/T 34590.1-XXXX界定的术语、定义和缩略语适用于本文件。

  1. 要求

4.1 一般要求

GBT《道路车辆 功能安全审核及评估方法》的部分规定了功能安全软件层面审核的要求,应具备下列文件支持本部分的功能安全审核和评估:

项目计划(细化的),按照GB/T34590.4—20225.5.1

安全计划(细化的),按照GB/T34590.4—20225.5.2

软件开发环境文档,按照GB/T34590.6—20225.5.1

软件安全需求规范,按照GB/T34590.6—20226.5.1

软硬件接口规范(细化的),按照GB/T34590.6—20226.5.2

软件安全需求规范、软硬件接口规范评审记录表,按照GB/T34590.6—20226.5.3

软件架构设计规范,按照GB/T34590.6—20227.5.1

软件安全分析报告,按照GB/T34590.6—20227.5.2~7.5.3

软件架构设计规范、软件安全分析报告评审记录表,按照GB/T34590.6—20227.5.3

软件单元设计规范;按照GB/T34590.6—20228.5.1

软件单元实现,按照GB/T34590.6—20228.5.2

软件单元验证规范,按照GB/T34590.6—20229.5.1

软件单元验证报告,按照GB/T34590.6—20229.5.2

软件集成和验证规范,按照GB/T34590.6—202210.5.1

软件单集成和验证报告,按照GB/T34590.6—202210.5.2

软件安全需求验证规范,按照GB/T34590.6—202211.5.1

软件安全需求验证报告,按照GB/T34590.6—202211.5.2

软件配置数据规范及配置数据,按照GB/T34590.6—2022C.5.1C.5.3

软件标定数据规范及标定数据,按照GB/T34590.6—2022C.5.2C.5.4

软件工具准则评估报告,按照GB/T34590.8—202211.5.1

软件工具鉴定报告,按照GB/T34590.8—202211.5.2

软件组件文档及组件鉴定报告,按照GB/T34590.8—202212.5.1~12.5.2

软件组件鉴定的验证报告,按照GB/T34590.8—202212.5.3

4.2 审核和评估结果的汇总

执行软层面的功能安全审核和评估后,应将审核的评估的结果进行汇总并列举证据:

 

4.3 软件层面功能安全审核和评估结果

通过(无待完成的建议行动项、评估和审核的相关项符合GBT 34590.6-2022,6.4的要求)

有条件通过(已有相关项符合的相关证据,已识别相应的建议行动项)

不通过(相关风险消除的行动项待完成,通过前需做相应的偏差评估和审核)

4.4 功能安全审核和评估的独立性要求

功能安全审核和评估的独立性要求参照GBT 34590. 2-2022, 6.4.7的要求。

  1. 软件开发环境的审核和评估

5.1 目的

审核和评估软件开发环境文档,以提供证据证明:

  1. 与软件开发流程合适且一致;
  2. 软件开发环境满足相关项开发的要求;

5.2 审核和评估的输入

5.2.1前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软件开发环境文档

5.2.2支持信息

可考虑下列信息:

安全计划;

软件开发流程;

审核和评估的要求

对于软件开发环境的审核和评估,应涵盖以下检查项:

表1:软件开发环境的审核和评估检查清单

序号

审核和评估要求

1

是否定义了软件开发环境的模板且在项目中进行了实施?

2

软件开发环境模板是否与已定义的开发流程保持一致?

3

定义的软件开发环境模板是否可以覆盖下面列出的评估检查点?

4

在开发相关项时,使用的软件开发过程和软件开发环境是否适用并满足该相关项要求?

  1. 适用于开发安全相关的嵌入式软件,包括方法、指南、语言和工具;
  2. 软件阶段及相关阶段的工作成果的一致性;

与系统和硬件开发阶段在所需的交互和信息交换的一致性;

5

在开发相关项时,所应用的设计语言、建模语言或编程语言是否满足以下准则?

  1. 明确易理解的定义;
  2. 如果建模用于需求工程和管理,定义和管理安全要求的适用性;
  3. 支持模块化、抽象化和封装化的实现;
  4. 支持结构化构造的使用;

6

建模和编码指南是否满足对应的ASIL等级所要求的的通则,以涵盖适合于建模、设计或者编程语言的准则?

注:具体要求参考GB/T34590-6第5章表1

  1. 软件安全要求的审核和评估

6.1 目的

审核和评估软件安全需求规范、细化的软硬件接口规范,以提供证据证明:

a)定义或细化了由技术安全概念和系统架构设计规范导出的软件安全要求;

b)定义了软件实现所需的安全相关功能和特性;

c)细化了在GB/T 34590.4-XXXX第6章最初定义的软硬件接口要求;及

d)验证软件安全要求和软硬件接口要求是否适用于软件开发,及验证它们与技术安全概念和系统架构设计规范的一致性。

6.2 审核和评估的输入

6.2.1前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软件安全需求规范,按照GB/T34590.6—2022的6.5.2;

软硬件接口规范(细化的),按照GB/T34590.6—2022的6.5.2;

软件验证报告,按照GB/T34590.6—2022的6.5.3;

6.2.2 支持信息:

可考虑下列信息:

技术安全要求规范,按照GB/T34590.4—2022的6.5.1;

技术安全概念,按照GB/T34590.4—2022的6.5.2;

系统架构设计规范,按照GB/T34590.4—2022的6.5.3;

软硬件接口规范,按照GB/T34590.4—2022的6.5.4;及

软件开发环境文档,按照GB/T34590.6—2022的5.5.1;

6.3 审核和评估的要求            

对于软件安全需求规范的审核和评估,应涵盖以下检查项:

表2:软件安全需求规范的审核和评估检查清单

序号

审核和评估要求

1

是否定义了软件安全要求的开发流程?

2

是否定义了软件安全要求的模板且在项目中进行了实施?

3

软件安全要求模板是否与已定义的开发流程保持一致?

4

定义的软件安全要求模板是否可以覆盖下面列出的评估检查点?

5

软件安全要求的得出是否基于安全相关的软件功能和特性?如果嵌入式软件除了执行6.4.1定义的安全要求的功能外,还执行了其他功能,是否按照所应用的质量管理体系的要求提供了这些功能及其特性的规范?

6

软件安全要求的得出是否继承于技术安全需求、技术安全概念和系统架构设计规范?软件安全要求的得出是否包含如下内容:

  1. 安全要求的定义和管理,按照GB/T34590.8-2022,第6章;
  2. 已定义的系统和硬件的配置;
  3. 软硬件接口规范;
  4. 硬件设计规范的相关要求;
  5. 时间约束;
  6. 外部接口;
  7. 对软件有影响的车辆、系统或者硬件的每个运行模式及运行模式之间的转换;

7

若对软件安全要求进行了ASIL等级分解,其分解原则是否满足GB/T 34590.9-xxxx,第5章的要求?

8

软硬件接口规范在软件开发阶段是否进行了细化?细化程度是否足以支持软件正确控制使用硬件?

9

软硬件接口规范是否描述了硬件和软件间每个与安全相关的依赖性?

10

是否建立了软件安全要求与技术安全需求及技术安全概念之间的双向追溯性?

11

是否细化后的软硬件接口都定义了对应的验证准则?

12

是否为每个软件安全要求制定了验证准则?

13

是否基于GB/T 34590.8-xxxx,第6章和第9章执行了软件安全要求、细化后的软硬件接口规范的验证?其验证结果是否能证明如下要求得到了满足?

  1. 与技术安全需求的一致性和符合性;
  2. 与系统设计的符合性;
  3. 与软硬件接口的一致性;

  1. 软件架构设计规范的审核和评估

7.1 目的

审核和评估软件架构设计规范,以提供证据证明:

  1. 开发了满足软件安全要求和其他软件要求的软件架构设计;
  2. 验证了软件架构设计适合满足所要求ASIL等级的软件安全要求;及
  3. 支持软件的实现与验证。

7.2 审核和评估的输入

7.2.1前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软件架构设计规范规范,按照GB/T34590.6—2022的7.5.1;

安全分析报告,按照GB/T34590.6—2022的7.5.2~7.5.3;

软件架构设计的验证报告,按照GB/T34590.6—2022的7.5.4;

7.2.2 支持信息

可考虑下列信息:

软件安全需求规范,按照GB/T34590.6—2022的6.5.1;

软硬件接口规范(细化的),按照GB/T34590.6—2022的6.5.2;

7.3 审核和评估的要求

对于软件架构设计规范的审核和评估,应涵盖以下检查项:

表3:软件架构设计规范的审核和评估检查清单

序号

审核和评估要求

1

是否定义了软件架构设计规范的开发流程?

2

是否定义了软件架构设计规范的模板且在项目中进行了实施?

3

软件架构设计规范模板是否与已定义的开发流程保持一致?

4

定义的软件架构设计规范模板是否可以覆盖下面列出的评估检查点?

5

是否按照ASIL等级要求定义软件架构的设计标记方法,且满足GB/T34590.6-2022,表2的要求?

6

软件架构设计的描述是否满足如下特征?

  1. 可理解性;
  2. 一致性;
  3. 简单性;
  4. 可验证性
  5. 模块化;
  6. 抽象性;
  7. 封装性;
  8. 可维护性

7

软件架构设计的开发是否满足如下要求:

  1. 软件架构设计的可验证性;
  2. 可配置软件的适用性;
  3. 软件单元设计与实现的可行性;
  4. 软件集成测试中软件架构的可测试性;
  5. 软件架构设计的可维护性;

8

是否定义软件架构设计的原则,且满足GB/T34590.6-2022,表3的要求?

9

软件架构设计是否被开发到可以识别软件单元的程度且继承了相应的软件安全需求?软件单元是否按照分配给它的最高安全ASIL 等级进行的开发?

10

软件架构设计规范是否包含了静态设计和动态设计?

11

如果架构设计中复用了一个不满足功能安全开发的软件架构要素,是否对该软件架构要素进行了组件鉴定并满足GB/T34590.8-2022,第12章的要求?

12

如果架构设计要素被分配了不同的ASIL等级,该软件架构要素是否符合GB/T34590.9-2022, 第六章定义的共存准则或按照了最高ASIL 等级要求进行了开发?

13

软件架构设计如进行了软件分区,是否实现了软件组件间免于干扰且确保满足如下要求?

  1. 共享资源的使用方式应确保软件分区免于干扰;
  2. 对于ASILD等级,由专用的硬件特性或等效方法来支持软件分区;
  3. 实现软件分区的软件要素是根据分配给分区软件任何要求的最高ASIL等级开发的;及
  4. 软件分区有效性的证据会在软件集成和验证期间生成;(按照GB/T34590.6-2022,第10章的要求

14

是否对软件架构进行了安全导向分析?安全导向分析的结果是否满足如下要求:

a)提供软件的适用性证据证明具备了相应的ASIL等级要求所需的特定的安全相关的功能和特性;

b)识别或确认软件的安全相关部分;及

C)支持安全措施的定义并验证其有效性。

15

如果软件安全要求的实现依赖于软件组件间免于干扰或足够的独立性,检查是否按照GB/T34590.9,第七章进行了相关失效及其影响分析?

16

是否对安全分析的结果进行了处理?是否在架构设计中采用了错误探测和错误处理的安全机制?

17

是否对嵌入式软件所需资源进行了上限预估,包括:

  1. 执行时间;
  2. 存储空间;
  3. 通讯资源

18

是否基于GB/T 34590.8-XXXX,第9章执行了软件架构设计的验证?软件架构设计的验证方法是否按照GB/T34590.6-2022,表4的要求进行,为下列目标提供证据?

  1. 软件架构设计应满足对应ASIL等级的软件安全要求;
  2. 软件架构设计的评审或审核能够与为满足对应ASIL等级的软件安全要求提供证据;
  3. 与目标环境的兼容性;

与设计指南保持一致;

  1. 软件单元设计及实现的审核和评估

8.1 目的

审核和评估软件单元设计和软件实现,以提供证据证明:

  1. 软件单元设计和实现满足了所有的软件安全需求;
  2. 软件源代码实现了软件详细设计规范
  3. 软件设计实现了软硬件接口规范
  4. 软件设计有充分的资源支撑预期的功能和特征,避免非预期的功能和特征
  5. 软件设计实现了安全分析中得出的安全措施

 8.2 审核和评估的输入

8.2.1 前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软件单元设计规范,按照GB/T34590.6—2022的8.5.1

软件单元实现,按照GB/T34590.6—2022的8.5.2

8.2.2 支持信息

可考虑下列信息:

xxxx,按照GB/T34590.x—2022的xxx

xxxx,按照GB/T34590.x—2022的xxx

8.3 审核和评估的要求

对于软件单元设计及实现的审核和评估,应涵盖以下检查项:

表4:软件单元设计及实现的审核和评估检查清单

序号

审核和评估要求

1

是否定义了软件单元设计及实现的开发流程?

2

是否定义了软件单元设计及实现的模板且在项目中进行了实施?

3

软件单元设计及实现模板是否与已定义的开发流程保持一致?

4

定义的软件单元设计及实现模板是否可以覆盖下面列出的评估检查点?

5

软件单元设计是否与软件需求和软件架构设计保持了一致性和追溯性?

6

软件单元设计是否符合软硬件接口规范(如果适用)

7

软件单元设计的标记方法是否使用了GB/T34590.6,表5中要求的对应ASIL等级推荐的标记方法?

8

软件单元的定义是否将功能表现和内部设计描述到必要的细节程度以支持其实现?

9

软件单元设计和实现的设计是否满足了以下原则:

a) 基于软件架构设计,软件单元内的子程序和函数执行的正确次序;

b) 软件单元间接口的一致性;

c) 软件单元内和软件单元间的数据流及控制流的正确性;

d) 简单性;

e) 可读性和可理解性;

f) 鲁棒性;

10

软件单元设计是否符合GB/T34590.6,表6中要求的对应ASIL等级推荐的设计原则?

  1. 软件单元测试的审核和评估

9.1 目的

审核和评估软件单元测试规范、单元测试报告,以提供证据证明:

  1. 提供证据证明软件单元设计满足分配的软件要求且适合于实施;
  2. 验证由软件单元模块、函数层面的相关失效分析和安全分析得出的已定义的安全措施得到适当实施;
  3. 提供证据证明软件单元、函数符合软件单元设计与根据所需的ASIL等级分配的软件要求;
  4. 提供充分证据,证明单元不包含与功能安全相关的非预期功能和特性。

9.2 审核和评估的输入

9.2.1 前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软硬件接口规范, 按照GB/T34590.6—2017 6.5.2;

软件验证计划, 按照GB/T34590.6—2017 6.5.3

软件验证规范, 按照GB/T34590.6—2017 9.4.2和9.4.4~9.4.6

安全计划, 按照GB/T34590.6—2017 7.5.2

嵌入式软件,按照GB/T34590.6—2022的10.4.1

软件单元设计规范, 按照GB/T34590.6—2017 8.5.1

软件单元实现,按照GB/T34590.6—2017 8.5.2

软件验证报告,按照GB/T34590.6—2017 8.5.3。

9.2.2 支持信息

可考虑下列信息:

工具应用指南,按照5.5.4及方法应用指南(来自外部)。

9.3 审核和评估的要求

对于软件单元测试的审核和评估,应涵盖以下检查项:

表5:软件单元测试的审核和评估检查清单

序号

审核和评估要求

1

是否定义了软件单元测试的开发流程?

2

是否定义了软件单元测试的模板且在项目中进行了实施?

3

软件单元测试模板是否与已定义的开发流程保持一致?

4

定义的软件单元测试模板是否可以覆盖下面列出的评估检查点?

5

是否基于GB/T34590-6,第9章在同一开发流程中同时考虑了软件安全要求和所有非安全相关要求,以验证单个软件单元设计?”

是否编制了软件单元设计规范,且建立软件单元测试流程,并按照该流程执行了测试?

  1. 软件单元测试的对象是软件单元
  2. 制定并评审了软件测试计划
  3. 软件单元测试的软件单元设计与实现(软件详细设计、函数)层级的可追溯性、覆盖率
  4. 软件单元验证用例的开发方法、评审
  5. 软件单元验证的方法
  6. 嵌入式软件代码的评审
  7. 软件单元静态分析
  8. 软件单元动态测试
  9. 软件单元验证环境
  10. 软件单元验证Bug管理流程
  11. 软件单元验证结束退出准则

6

是否按照GB/T34590-8,第9章要求,对已制定的单元验证计划进行了验证?验证中发现的问题是否均已关闭?

注:验证方法包括了测试,也包括评审,分析,可参见表7 软件单元验证方法

7

是否按照GB/T34590-6,第9章要求确定了单元验证方法的合理组合?选择的单元验证方法组合是否与单元设计与实现中的ASIL定义保持一致?选择的软件单元验证方法是否与标准推荐ASIL保持一致?未使用及不适用的方法是否提供了合理理由?

8

是否按照GB/T34590-6,第9章要求得到单元验证用例?选择的单元验证用例开发方法是否与软件单元设计与实现(软件详细设计)中的ASIL定义保持一致?

9

是否按照GB/T34590-6第9章要求确定了软件验证的结构覆盖率?软件单元验证的结构覆盖率是否与单元设计与实现中的ASIL定义保持一致?软件单元验证结构覆盖率是否与标准推荐ASIL保持一致?测试结果是否能够提供证据说明单元验证活动满足已定义的软件单元设计及实现(软件详细设计)层级的结构覆盖度?

10

是否按要求对软件单元验证过程中所有的Bug进行了管理,并跟踪至关闭?

11

是否对通过软件单元验证的软件范围进行了分析,其是否包含全部定义的功能和性能,对于未定义的功能,是否评估了风险或执行了解决措施?

12

是否对软件单元验证环境进行了分析?如果软件单元环境与目标环境不一致,是否给出了对应措施?

  1. 软件集成和验证的审核和评估

10.1 目的

为了开展本章规定的审核和评估,应具备如下输入:

审核和评估软件验证规范、嵌入式软件和软件验证报告,以提供证据证明:

  1. 定义集成步骤并集成软件要素,直至嵌入式软件完全集成;
  2. 验证由软件架构层面的安全分析得出的已定义的安全措施得到适当实施;
  3. 提供证据证明集成的软件单元和集成的软件组件符合软件架构设计的要求;
  4. 提供充分证据,证明集成软件不包含与功能安全相关的非预期功能和特性。

 10.2 审核和评估的输入

10.2.1 前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软件验证规范,按照GB/T34590.6—2022的10.4.2~10.4.7

嵌入式软件,按照GB/T34590.6—2022的10.4.1

软件验证报告,按照GB/T34590.6—2022的10.4.2

10.2.2 支持信息

可考虑下列信息:

软硬件接口规范(细化的),按照GB/T34590.6—2022的6.5.2;

软件架构设计规范,按照GB/T34590.6—2022的7.5.1;

安全分析报告,按照GB/T34590.6—2022的7.5.2;

相关失效分析报告,按照GB/T34590.6—2022的7.5.3;

软件单元实现,按照GB/T34590.6—2022的8.5.2;

配置数据,按照GB/T34590.6—2022的C.5.3;

标定数据,按照GB/T34590.6—2022的C.5.4;

软件开发环境文档,按照GB/T34590.6—2022的5.5.1;

软件验证规范,按照GB/T34590.6—2022的9.5.1;

经鉴定合格的软件组件,按照GB/T 34590.8-2022的第12章

10.3 审核和评估的要求

对于软件集成和验证的审核和评估,应涵盖以下检查项:

表6:软件集成和验证的审核和评估检查清单

序号

审核和评估要求

1

是否定义了软件集成和验证的开发流程?

2

是否定义了软件集成和验证的模板且在项目中进行了实施?

3

软件集成和验证的模板是否与已定义的开发流程保持一致?

4

定义的软件集成和验证的模板是否可以覆盖下面列出的评估检查点?

5

是否基于GB/T34590-610章要求,定义了软件集成方法和策略?

6

是否按照GB/T34590-610章要求,通过表10软件集成验证方法确定了软件集成及验证方法的合理组合?

7

针对已选择的软件集成及验证方法,是否有相关内容说明相应的软件集成及验证活动执行符合要求?

8

是否正确执行了软件集成及验证?验证中发现的问题是否均已关闭?

9

是否按照GB/T34590-610章表11软件集成测试用例的得出方法要求开发了软件集成测试用例?

10

是否按照GB/T34590-610章要求确定了测试用例在软件架构层级的需求覆盖率和结构覆盖率(包括函数覆盖率和调用覆盖率)?

11

是否对通过软件集成及验证的软件范围进行了验证,其是否包含全部定义的功能和性能,对于未定义的功能,是否评估了风险或执行了解决措施?

12

是否对软件集成测试及验证环境进行了分析?如果软件集成测试及验证环境与目标环境不一致,是否进行分析并给出了对应措施?

  1. 嵌入式软件测试的审核和评估

11.1目的

审核和评估软件验证规范和软件验证报告,以提供证据证明嵌入式软件:

  1. 在目标环境执行时满足安全相关要求;
  2. 不包含与功能安全相关的非预期功能和特性。

11.2审核和评估的输入

11.2.1前提条件

为了开展本章规定的审核和评估,应具备如下输入:

软件验证规范,按照GB/T34590.6—2022的11.4.1~11.4.3

软件验证报告,按照GB/T34590.6—2022的11.4.1~11.4.4

11.2.2 支持信息

可考虑下列信息:

软件架构设计规范,按照GB/T34590.6—2022的7.5.1;

软件安全需求规范,按照GB/T34590.6—2022的6.5.1;

嵌入式软件,按照GB/T34590.6—2022的10.5.2;

标定数据,按照GB/T34590.6—2022的C.5.4;

软件开发环境文档,按照GB/T34590.6—2022的5.5.1;

软件验证规范(细化的),按照GB/T34590.6—2022的10.5.1

技术安全概念,按照GB/T 34590.4-2022的6.5.2;

系统架构设计规范,按照GB/T 34590.4-2022的6.5.3;

集成和测试策略,按照GB/T 34590.4-2022的7.5.1;

集成和测试报告,按照GB/T 34590.4-2022的7.5.2

11.3审核和评估的要求

对于嵌入式软件测试的审核和评估,应涵盖以下检查项:

表7:嵌入式软件测试的审核和评估检查清单

序号

审核和评估要求

1

是否定义了嵌入式软件测试的开发流程?

2

是否定义了嵌入式软件测试的模板且在项目中进行了实施?

3

嵌入式软件测试的模板是否与已定义的开发流程保持一致?

4

定义的嵌入式软件测试的模板是否可以覆盖下面列出的评估检查点?

5

是否基于GB/T34590-611章要求,制定了嵌入式软件测试策略?

6

是否按照GB/T34590-611章表13用于执行软件测试的测试环境要求,确定了嵌入式软件测试的测试环境?

7

是否按照GB/T34590-611章表14嵌入式软件的测试方法要求,确定了嵌入式软件测试方法的合理组合?

8

针对已选择的嵌入式软件测试方法,是否有相关内容说明相应的嵌入式软件测试活动执行符合要求?

9

是否按照GB/T34590-611章表15嵌入式软件测试用例的得出方法要求,开发了嵌入式软件测试用例?

10

是否正确执行了嵌入式软件测试?测试中发现的问题是否均已关闭?

11

是否对嵌入式软件测试的测试结果及覆盖率进行了评估?

  1. 软件标定和配置管理的审核和评估

12.1目的

审核和评估软件配置,包括配置数据规范、标定数据规范、配置数据、标定数据、验证规范、验证报告、软件架构设计规范和软件开发环境文档,以提供证据证明软件配置:

  1. 满足不同应用的软件行为变化的可控性;
  2. 证明配置数据和标定数据满足所需的ASIL等级要求;
  3. 证明专用嵌入式软件及其标定数据适合生产发布。

12.2审核和评估的输入

12.2.1 前提条件

为了开展本章规定的审核和评估,应具备如下输入:

前提条件按照应用软件配置的相关阶段。

12.2.2 支持信息

可考虑下列信息:

应用软件配置的相关阶段中的适用的支持信息。

12.3审核和评估要求

对于软件标定和配置管理的审核和评估,应涵盖以下检查项:

表8:软件标定和配置管理的审核和评估检查清单

序号

审核评估要求

1

是否定义了软件配置的验证流程?

2

是否定义了软件配置的模板且在项目中进行了实施?

3

软件配置模板是否与已定义的开发流程保持一致?

4

定义的软件配置模板是否可以覆盖下面列出的评估检查点?

5

是否对配置数据进行了定义?

  1. 配置数据的有效值;
  2. 配置数据的目的和用法;
  3. 范围、比例、单位;
  4. 配置数据不同要素之间的相互依赖;

6

配置数据及其规范是否能够提供证据证明以下内容?

  1. 配置数据符合软件架构设计规范
  2. 配置数据符合软件单元设计规范;
  3. 配置数据使用的值在其规定的范围内;

d) 配置数据与其他配置数据的兼容性;

7

是否规定了配置数据的ASIL等级应等于应用于该数据的可配置软件的最高ASIL等级?

8

是否按照GB/T 34590-8 2022,第9章定义了对相关项开发中要使用的配置数据集对可配置软件的验证?

9

是否执行了可配置软件的验证?是否关闭问题?

  1. 可配置软件的验证;
  2. 配置数据的验证;
  3. 已配置软件的验证;

10

是否定义了与软件组件关联的标定数据以确保配置后软件的正确运行和预期性能?

  1. 标定数据的有效值;
  2. 标定数据的目的和用法;
  3. 范围、比例和单位,以及它们对运行状态的依赖(如果适用);
  4. 不同标定数据之间已知的相互依赖;

配置数据和标定数据之间的已知的相互依赖;

11

是否规定了标定数据的ASIL等级应等于其可能违反的软件安全要求的最高ASIL等级?

12

是否按照GB/T 34590-8 2022,第9章定义了如何验证标定数据?

  1. 定义的标定数据合适并符合软件安全要求;
  2. 定义的标定数据符合软件架构设计规范;
  3. 定义的标定数据符合软件单元设计规范;
  4. 定义的标定数据与其他定义的标定数据是一致且兼容的;

13

是否按照GB/T 34590-8 2022,第9章定义了用于生产发布的标定数据的验证?是否关闭问题?

  1. 发布的标定数据符合其规范;
  2. 嵌入式软件的已标定的、应用特定的变体提供了定义的安全相关功能和特性;

14

是否定义了数据非预期变化的探测机制?

注:具体要求参考GB/T34590-6附录C表C.1

15

是否定义了标定数据应遵循的流程、生成标定数据的工具和验证标定数据的流程?

16

软件开发环境文档中是否针对软件配置的更新细化内容?

  1. 软件工具鉴定的审核和评估

13.1目的

   审核和评估软件工具准则评估报告、软件工具鉴定报告,以提供证据,证明在系统或其软件要素、硬件要素开发中使用的软件工具,适合用于支持GB/T 34590-XXXX要求的活动或任务(即,对那些GB/T 34590-XXXX要求的活动或任务,使用者可依靠软件工具的正确功能)。

13.2审核和评估的输入

13.2.1前提条件

为了开展本章规定的审核和评估,应具备如下输入:

安全计划,按照GB/T34590.2—2022的6.5.3

软件工具准则评估报告,按照GB/T34590.8—2022的11.5.1

软件工具鉴定报告,按照GB/T34590.8—2022的11.5.2

13.2.2 支持信息

可考虑下列信息:

组织专门的功能安全规章和流程,按照GB/T 34590.2-2022的5.5.1;

安全生命周期相关阶段(该阶段使用了软件工具)中适用的前提条件,按照GB/T 34590.8-2022的11.3.2;

预先确定的最大ASIL等级,按照GB/T 34590.8-2022的11.3.2;

软件工具的用户手册(来自外部),按照GB/T 34590.8-2022的11.3.2;

软件工具的环境和约束(来自外部),按照GB/T 34590.8-2022的11.3.2

13.3审核和评估要求

对软件工具鉴定的审核和评估,应涵盖以下检查项:

表9:软件工具鉴定的审核和评估检查清单

序号

审核评估要求

1

是否定义了软件工具鉴定的开发流程?

2

是否定义了软件工具鉴定的模板且在项目中进行了实施?

3

软件工具鉴定模板是否与已定义的开发流程保持一致?

4

定义的软件工具鉴定模板是否可以覆盖下面列出的评估检查点?

5

安全计划中是否基于考虑所使用软件工具的置信度的依据而按照6.4.5.1对某一安全活动进行剪裁?若有,剪裁是否满足GB/T 34590.8-XXXX,第11 章的要求?

6

是否有预先确定的工具在执行其置信度水平评估或鉴定时,独立于特定安全相关项或要素的开发?若有,是否对预先确定的工具置信度水平的有效性或鉴定的有效性进行验证?

7

使用软件工具时,工具的使用、工具定义的环境和功能约束及其一般运行条件是否和工具评估准则或鉴定相符合?

8

是否有对软件工具使用的计划?

9

对软件工具使用的计划中是否包含

  1. 软件工具的识别码和版本号;
  1. 软件工具的配置;
  1. 软件工具的使用案例;
  1. 软件工具执行的环境;
  1. 当软件工具功能异常并产生相应的错误输出时,会直接违背分配给相关项或要素的全部安全要求的最高ASIL等级;及

f) 如需要,基于确定的置信度水平和ASIL等级的软件工具的鉴定方法。

10

为了进行软件工具评估,是否收集了软件工具相关信息

  1. 软件工具的特征、功能和技术属性的描述;
  2. 如果适用,用户手册或其他使用指南;
  3. 工具运行要求的环境描述;
  4. 如果适用,对异常运行条件下期望的软件工具表现的描述;
  1. 如果适用,对已知软件工具功能异常,及恰当的安全保护、避免或应急措施的描述;及

f) 在制定软件工具要求的置信度水平过程中,识别出的对软件工具功能异常和相应错误输出的预防或探测措施。

11

软件工具准则评估报告对软件工具使用的描述是否包含下述信息:

  1. 预期的目的;
  1. 输入和期望的输出;及

c) 如果适用,使用过程、环境的和功能的约束。

12

软件工具准则评估报告中是否分析和评估了软件工具的预期使用,以确定:

  1. 特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中错误的可能性。这是通过工具影响(TI)等级表示的:

——当有论据表明没有这样的可能性时,应选择TI1;

——在所有其他情况下应选择TI2。

  1. 用于预防软件工具功能异常并产生相应错误输出的措施的置信度,或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度。这是通过工具错误探测(TD)等级表示的:

——当对预防或探测出功能异常及其相应错误输出具有高置信度时,应选择TD1;

——当对预防或探测出功能异常及其相应错误输出具有中等置信度时,应选择TD2;

——在所有其他情况下应选择TD3。

13

软件工具准则评估报告中是否存在对TI或TD选择的正确性是不清楚的或可疑的?若有是否对TI和TD进行了保守评估?

14

软件工具准则评估报告中基于为TI和TD等级确定的值,是否按照GB/T 34590.8—2022 11.4.5.4表3来确定所要求的软件工具的置信度水平?

15

软件工具鉴定报告中,对鉴定等级为TCL3的软件工具,是否按照GB/T 34590.8—2022 11.4.6.14列出的方法?

16

软件工具鉴定报告中,对鉴定等级为TCL2的软件工具,是否按照GB/T 34590.8—2022 11.4.6.15列出的方法?

17

软件工具鉴定报告中,是否包含以下文档化信息?

  1. 软件工具的唯一识别码和版本号;
  2. 软件工具划分的最高工具置信度等级,及其评估分析参考;
  3. 对于考虑的使用案例,当软件工具功能异常并产生相应的错误输出时,可能直接违背任何安全要求的预定义最高ASIL等级或特定ASIL等级;
  4. 软件工具被鉴定的配置和环境;
  5. 执行鉴定的人员或组织;
  6. 鉴定使用的方法,按照11.4.6.1;
  7. 用于鉴定软件工具的措施结果;及,
  8. 如果适用,在鉴定过程中识别出的使用约束和功能异常。

18

软件工具鉴定报告中,是否将“使用中积累置信度”的方法用于软件工具的鉴定?

19

软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

  1. 仅当具备以下方面的证据时,才应论证软件工具在使用中积累了置信度:
  1. 此前,已经将该软件工具用于相同的目的,具有相似的使用案例、相似的预定运行环境和相似的功能约束中;
  2. 使用中积累置信度的理由是基于充分适当的数据;
  1. 软件工具的定义未改变;及
  2. 在之前开发中获得的软件工具功能异常和相应错误输出的发生案例是以系统化方式累计的。

20

软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

  1. 应通过考虑以下信息,对给定开发活动中软件工具的先前使用经验进行分析和评估:

  1. 软件工具唯一的识别码和版本号;
  2. 软件工具的配置;
  3. 使用周期和使用相关数据的细节;
  1. 软件工具的功能异常和相应错误输出的详细文档化记录,其中包含引起功能异常和错误输出的条件;
  2. 所监控的先前版本清单,其中列出每个相关版本中解决的功能异常;及
  3. 如果适用,对已知缺陷的安全保护、避免措施、应急措施或相应错误输出的探测措施

21

软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

使用中积累置信度的论证应仅对所评估的软件工具版本有效。

22

软件工具鉴定报告中,是否将“工具开发流程评估”的方法用于软件工具的鉴定?若有,是否满足以下要求:

  1. 用于软件工具开发的流程应满足适当的标准。

2.应基于恰当的国内或国际标准对软件工具开发流程进行评估,同时提供恰当的软件开发流程被应用的证据。

23

软件工具鉴定报告中,是否将“软件工具确认”的方法用于软件工具的鉴定?若有,是否满足以下要求:

软件工具的确认应满足以下准则:

  1. 确认措施应提供软件工具符合分类中指定用途的特定要求的证据;
  1. 应对确认中发生的软件工具功能异常及其相应错误输出、其可能的后果信息、及避免或探测它们的措施进行分析;及
  1. 应检查软件工具对异常运行条件的响应。

  1. 软件组件鉴定的审核和评估

14.1目的

审核和评估软件组件鉴定定义、软件组件鉴定报告、软件组件鉴定的验证报告,以提供证据,证明在符合GB/T 34590开发的相关项中对软件组件的重复使用是合适的。

14.2审核和评估的输入

14.2.1前提条件

为了开展本章规定的审核和评估,应具备如下输入:

安全计划,按照GB/T34590.22022的6.5.3

软件组件鉴定计划,按照GB/T34590.82022的12.4.1

软件组件的文档,按照GB/T34590.82022的12.5.1

软件组件鉴定报告,按照GB/T34590.82022的12.5.2

软件组件鉴定的验证报告,按照GB/T34590.82022的12.5.3

14.2.2支持信息

可考虑下列信息:

组织专门的功能安全规章和流程,按照GB/T 34590.2-XXXX的5.5.1;

对软件组件的要求(来自外部),按照GB/T34590.82022的12.3.1;

软件组件的设计规范(来自外部),按照GB/T34590.82022的12.3.2;

先前对软件组件采用的验证措施的结果(来自外部),按照GB/T34590.82022的12.3.2;

14.3审核和评估要求

对于软件组件鉴定的审核和评估,应涵盖以下检查项:

表10:软件组件鉴定的审核和评估检查清单

序号

审核评估要求

1

是否定义了软件组件鉴定的开发流程?

2

是否定义了软件组件鉴定的模板且在项目中进行了实施?

3

软件组件鉴定模板是否与已定义的开发流程保持一致?

4

定义的软件组件鉴定模板是否可以覆盖下面列出的评估检查点?

5

安全计划中是否由于软件组件鉴定而按照6.4.5.1 对某一安全活动进行了剪裁?,若有,剪裁是否满足GB/T 34590.8-XXXX,第12 章的要求?

6

安全计划中是否包含对软件组件鉴定计划?

7

软件组件的软件开发过程是否基于适当的国际标准?

8

软件组件的文档是否包括了软件组件的唯一识别?

9

软件组件的文档是否包含当软件组件错误执行时,可能违背的所有安全要求的最高ASIL等级?

10

软件组件的文档是否包括了为鉴定软件组件所应执行的活动?

11

软件组件的文档是否包含以下要求?

・软件组件的要求

・软件组件预期用途的要求

    ・配置描述

    ・所需接口、供给接口、共享资源描述(如果适用)

    ・软件组件集成的描述

    ・异常运行条件下的功能反应

    ・对已知异常及相应应急措施的描述

12

是否提供了软件组件的鉴定报告,以证明组件的开发过程符合标准的证据,并记录了论证结果?

13

软件组件鉴定报告是否提供了软件组件的验证结果,以证明符合以下要求,并记录了论证结果?

・分配给软件组件的要求的测试覆盖率应满足GB/T34590.6-XXXX,第9章;

・满足测试用例完整性要求(ASILD适用),结构覆盖率应按照GB/T34590.6-XXXX,第9章来测量;

    ・既覆盖正常运行条件,也覆盖失效情况下的表现

    ・没有导致违背安全要求的已知错误

14

软件组件鉴定报告是否对软件组件的鉴定进行了记录?

15

对软件组件的鉴定记录中是否包含下述信息:

  1. 软件组件的唯一识别;
  2. 软件组件的唯一配置;
  3. 执行鉴定的人员或组织;
  1. 用于鉴定的环境;
  2. 用于鉴定软件组件的验证措施的结果;及

f) 分配给软件组件的安全要求的最高ASIL等级。

16

是否按照GB/T34590.8-XXXX,第9章的要求验证了软件组件的鉴定结果,以证明是否对软件组件资质评估结果进行验证?

附录A

(资料性)

软件开发环境的审核和评估示例

软件开发环境的审核和评估的说明及示例,见表A.1。

表A.1 软件开发环境的审核和评估的说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件开发环境的模板且在项目中进行了实施?

检查软件开发环境文档的模板

2

软件开发环境模板是否与已定义的开发流程保持一致?

检查软件开发环境文档和流程之间的一致性

3

定义的软件开发环境模板是否可以覆盖下面列出的评估检查点?

检查软件开发环境文档的正确性,应至少涵盖检查点4~7的要求

4

在开发相关项时,使用的软件开发过程和软件开发环境是否适用并满足该相关项要求?

  1. 适用于开发安全相关的嵌入式软件,包括方法、指南、语言和工具;
  2. 软件阶段及相关阶段的工作成果的一致性;
  3. 与系统和硬件开发阶段在所需的交互和信息交换的一致性;
  1. 在软件开发测试用到的方法,如导出测试用例时使用需求分析、边界值分析方法;
  2. 开发软件代码时参考的编码指南,如MISRA C;
  3. 软件开发时用到的编程语言,如模型、C语言;
  4. 在软件开发过程中用到的软件工具,如编译工具、建模工具等;
  5. 需要体现软件阶段各子阶段的对应的流程及工作成果描述;
  6. 描述相关项软件开发的阶段、任务和活动的排序,包括迭代步骤,和硬件/系统层面产品开发保持一致;

5

在开发相关项时,所应用的设计语言、建模语言或编程语言是否满足以下准则?

  1. 明确易理解的定义;
  2. 如果建模用于需求工程和管理,定义和管理安全要求的适用性;
  3. 支持模块化、抽象化和封装化的实现;
  4. 支持结构化构造的使用;
  1. 所选择语言的语法和语义定义明确,或对开发环境配置的限制。
  2. 选择语言需要考虑相应准则,如Simulink模型语言支持模块化、抽象化和封装化;汇编语言能用于那些不适合使用高级编程语言的软件部分,如与硬件接口的底层软件、中断处理程序、或对时间敏感的算法。

6

建模和编码指南是否满足对应的ASIL等级所要求的的通则,以涵盖适合于建模、设计或者编程语言的准则?

注:具体要求参考GB/T34590-6第5章表1

检查建模、设计或者编程语言的指南,按照不同ASIL等级应考虑如下准则:

  1. 强制低复杂度;
  2. 语言子集的使用;
  3. 强制强类型;
  4. 防御性实施技术的使用;
  5. 使用值得信赖的设计原则;
  6. 使用无歧义的图形表示;
  7. 风格指南的使用;
  8. 命名惯例的使用;
  9. 并发方面;

附录B

(资料性)

软件安全需求规范审核和评估示例

软件安全需求规范审核和评估的说明及示例,见表B.1。

表B.1 软件安全需求规范审核和评估的说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件安全要求的开发流程?

检查软件安全需求开发流程

2

是否定义了软件安全要求的模板且在项目中进行了实施?

检查软件安全需求的模板

3

软件安全要求模板是否与已定义的开发流程保持一致?

检查软件安全需求模板和流程之间的一致性

4

定义的软件安全要求模板是否可以覆盖下面列出的评估检查点?

检查软件安全需求模板的正确性,应至少涵盖检查点5~13的要求

5

软件安全要求的得出是否基于安全相关的软件功能和特性?如果嵌入式软件除了执行6.4.1定义的安全要求的功能外,还执行了其他功能,是否按照所应用的质量管理体系的要求提供了这些功能及其特性的规范?

应对软件功能和特殊特性进行失效分析,软件安全需求应该基于软件安全功能进行定义

示例1:软件安全功能可以是与安全相关硬件要素故障探测、指示和减轻相关的功能(检测EPS电机驱动电路故障并进行安全响应)

示例2:安全的特殊特性包括对错误输入的鲁棒性、不同功能之间的独立性或免于干扰、或软件的容错能力。

6

软件安全要求的得出是否继承于技术安全需求、技术安全概念和系统架构设计规范?软件安全要求的得出是否包含如下内容:

  1. 安全要求的定义和管理,按照GB/T34590.8-2022,第6章;
  2. 已定义的系统和硬件的配置;
  3. 软硬件接口规范;
  4. 硬件设计规范的相关要求;
  5. 时间约束;
  6. 外部接口;
  7. 对软件有影响的车辆、系统或者硬件的每个运行模式及运行模式之间的转换;

1. 检查软件安全需求和技术安全需求、技术安全概念和系统架构设计规范之间的追溯性和一致性;

2. 检查软件安全需求的属性应包括:

每条需求都有唯一标识、ASIL等级及需求状态

3. 检查不同ASIL等级的软件安全需求的描述方法是否符合GB/T34590.8-2022,第6章,表1的要求(ASIL C/D应选择半形式记法)

示例:

  1. 配置参数示例:可以考虑增益控制、带通频率和时钟分频;
  2. 时间约束示例:软件功能执行或响应时间应满足技术安全需求定义的FTTI;
  3. 运行模式示例:可包括初始化、正常运行、降级、休眠和用于测试的其他高级模式;
  4. 外部接口示例:通讯接口、用于测试的debug口;

7

若对软件安全要求进行了ASIL等级分解,其分解原则是否满足GB/T 34590.9-xxxx,第5章的要求?

检查ASIL等级分解的正确性应符合GB/T 34590.9-xxxx,第5章的要求

示例:GB/T 34590.9附录B

8

软硬件接口规范是否进行了细化,细化程度是否足以支持软件正确控制使用硬件?

检查软硬件接口规范的细化程度,应描述支持软件正确控制使用硬件;

9

软硬件接口规范是否描述了硬件和软件间每个与安全相关的依赖性?

检查细化后的软硬件接口规范中对硬件和软件间每个与安全相关的依赖性的描述

10

是否建立了软件安全要求与技术安全需求及技术安全概念之间的双向追溯性?

检查软件安全需求和技术安全需求之间的双向追溯性;

11

是否细化后的软硬件接口都定义了对应的验证准则?

检查是细化后的每条软件接口规范的验证准则,若软硬件接口不可验证,应提供论据说明其合理性

12

是否为每个软件安全要求制定了验证准则?

检查是每条软件安全需求的验证准则,若需求不可验证,应提供论据说明需求的合理性

13

是否基于GB/T 34590.8-xxxx,第6章和第9章执行了软件安全要求、细化后的软硬件接口规范的验证?其验证结果是否能证明如下要求得到了满足?

  1. 与技术安全需求的一致性和符合性;
  2. 与系统设计的符合性;
  3. 与软硬件接口的一致性;

检查软件安全需求的验证方法,不同安全等级等级的需求验证方法应按照GB/T34590.8-2022,第6章,表2进行选择,并给理由

示例1:半形式化验证可以通过FMEA/FTA/SEECA/SW DFA的形式分析安全机制的完整性;

示例2:检查可通过会议、需求检查单等检查软件安全需求;

附录C

(资料性)

软件架构设计规范审核和评估示例

软件架构设计规范审核和评估说明及示例,见表C.1。

表C.1 软件架构设计规范审核和评估说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件架构设计规范的开发流程?

检查软件架构设计规范开发流程

2

是否定义了软件架构设计规范的模板且在项目中进行了实施?

检查软件架构设计规范的模板

3

软件架构设计规范模板是否与已定义的开发流程保持一致?

检查软件架构设计规范的模板和流程之间的一致性

4

定义的软件架构设计规范模板是否可以覆盖下面列出的评估检查点?

检查软件安全需求模板的正确性,应至少涵盖检查点5~16的要求

5

是否按照ASIL等级要求定义软件架构的设计标记方法,且满足GB/T34590.6-2022,表2的要求?

软件架构设计的标记法根据不同的ASIL等级进行选择,需满足表2的要求,对于A/B的应使用非形式记法和自然语言结合的描述方式,对于C/D的,应使用半形式记法和自然语言结合的描述方法:

示例:半形式记法可以使用UML、SysML、simulink或stateflow的建模;

非形式记法:图片、图表

6

所选择软件架构设计标记方法是否支持软件架构设计的描述满足如下特征;

  1. 可理解性;
  2. 一致性;
  3. 简单性;
  4. 可验证性;
  5. 模块化;
  6. 抽象性;
  7. 封装性;
  8. 可维护性

检查软件架构设计规范的描述应可理解、简单可维护、可验证、模块化设计、一致性、抽象性及封装性。

示例:软件架构设计可参考使用AUTOSAR架构设计

7

软件架构设计的开发是否满足如下要求:

    1.  软件架构设计的可验证性;
    2. 可配置软件的适用性;
    3. 软件单元设计与实现的可行性;
    4. 软件集成测试中软件架构的可测试性;
    5. 软件架构设计的可维护性;

检查软件架构设计应和软件安全需求之间建立双向追溯性,且软件架构设计是可实现及可测试的

8

是否定义软件架构设计的原则,且满足GB/T34590.6-2022,表3的要求?

1.检查定义的软件架构设计原则,满足表3针对不同安全等级的要求;

2.应给出理由证明不选用时表中给予++号推荐的原则的合理性;

示例1:限制组件的规模和复杂度:可以限制函数的规模;

示例2:限制接口规模:可以限制函数参数变量的个数、可以限制返回出口的数量;

示例3:软件组件的适当空间隔离: MPU分区

9

软件架构设计是否被开发到可以识别软件单元的程度且继承了相应的软件安全需求?软件单元是否按照分配给它的最高安全ASIL 等级进行的开发?

检查软件安全需求和软件单元之间的双向追溯性;

检查软件单元的安全等级应继承所分配给其安全需求中的最高安全等级

10

软件架构设计规范是否包含了静态设计和动态设计?

检查软件架构的静态设计和动态设计内容

示例1:静态设计可包括:

  • 分层次的软件结构;
  • 数据类型和它们的特征参数;
  • 软件组件的外部接口;
  • 嵌入式软件的外部接口;
  • 全局变量;
  • 约束

示例2:动态设计可包括:

  • 事件和行为的功能链;
  • 数据处理的逻辑顺序;
  • 控制流和并发流程;
  • 通过接口和全局变量传递的数据流;
  • 时间的限制
  • 运行状态及其跳转

  

11

如果架构设计中复用了一个不满足功能安全开发的软件架构要素,是否对该软件架构要素进行了组件鉴定并满足GB/T34590.8-2022,第12张章的要求?

复用不满足安全等级要求开发的软件架构要素时应进行软件组件鉴定且满足GB/T34590.8-2022,第12张章的要求

12

如果嵌入式软件不得不实现不同ASIL等级的软件组件,或实现安全相关或非安全相关的软件组件,软件组件是否符合GB/T34590.9-2022, 第六章定义的共存准则或按照了最高ASIL 等级要求进行了开发?

检查不同安全等级的软件组件之间的共存原则。

示例1:不同安全等级的软件组件共存条件可以是:

  • 分解的组件之间没有功能依赖性;
  • 安全相关的元素不受干扰;

13

软件架构设计如进行了软件分区,是否实现了软件组件间免于干扰且确保满足如下要求?

  1. 共享资源的使用方式应确保软件分区免于干扰;
  2. 对于ASILD等级,由专用的硬件特性或等效方法来支持软件分区;
  1. 实现软件分区的软件要素是根据分配给分区软件任何要求的最高ASIL等级开发的;及
  2. 软件分区有效性的证据会在软件集成和验证期间生成;(按照GB/T34590.6-2022,第10章的要求

检查软件分区设计的原则,应保证软件组件之间免于干扰。

示例1:一个软件分区不能改变其他软件分区的代码或数据;

示例2:存储器保护单元等硬件特性;

示例3:软件分区应按照分区内组件的最高ASIL等级进行开发;

示例4:软件集成测试应提供软件分区有效性的证据

示例:GB/T34590.6-2022,附录D

14

是否对软件架构进行了安全导向分析?安全导向分析的结果是否满足如下要求:

  1. 提供软件的适用性证据证明具备了相应的ASIL等级要求所需的特定的安全相关的功能和特性;
  2. 识别或确认软件的安全相关部分;及
  3. 支持安全措施的定义并验证其有效性。

检查安全架构的软件安全分析,并检查安全分析结果满足该检查点所列的要求

示例:GB/T34590.6-2022,附录E

15

如果软件安全要求的实现依赖于软件组件间免于干扰或足够的独立性,检查是否按照GB/T34590.9,第七章进行了相关失效及其影响分析?

如果软件安全要求的实现依赖于软件组件间免于干扰或足够的独立性,,应检查DFA分析,且分析结果应满足该检查点所列的要求;

示例:GB/T34590.6-2022,附录E

16

是否对安全分析的结果进行了处理?是否在架构设计中采用了错误探测和错误处理的安全机制?

检查安全分析的结果应在软件架构设计中进行体现,软件架构设计中应包含错误探测和错误处理的安全机制;

示例1:用于错误探测的安全机制可包括:

  • 输入输出数据的范围检查;
  • 合理性检查;
  • 数据错误探测;
  • 外部要素监控程序执行;
  • 程序执行的时间监控;
  • 设计中的异构冗余;或
  • 在软件或硬件中实施的访问冲突控制机制,与授权访问或拒绝访问安全相关共享资源有关;

示例2: 用于错误处理的安全机制可能包括:

  • 为了达到或维持安全状态的功能;
  • 静态恢复机制;
  • 通过划分功能的优先级进行平稳降级,从而最小化潜在失效对功能安全的影响;
  • 设计中的同构冗余,主要侧重于控制运行相似软件的硬件中瞬态故障或随机硬件故障的影响;
  • 设计中的异构冗余,意味着在每个并行路径中使用不同的软件,主要侧重于预防或控制软件中的系统性故障;
  • 数据纠错码;
  • 在软件或硬件中实施的访问许可管理,与授权访问或拒绝访问安全相关共享资源有关;

17

是否对嵌入式软件所需资源进行了上限预估,包括:

  1. 执行时间;
  2. 存储空间;
  3. 通讯资源

检查软件的所需资源上限预估策略

示例1:评估存储堆和栈的RAM及存储程序和非易失性数据的ROM资源占用上限;

示例2:评估程序运行的最长时间;

示例3:评估通讯的负载率

18

是否基于GB/T 34590.8-XXXX,第9章执行了软件架构设计的验证?软件架构设计的验证方法是否按照GB/T34590.6-2022,表4的要求进行,为下列目标提供证据:

  1. 软件架构设计应满足对应ASIL等级的软件安全要求;
  2. 软件架构设计的评审或审核能够与为满足对应ASIL等级的软件安全要求提供证据;
  3. 与目标环境的兼容性;
  4. 与设计指南保持一致;
  1. 检查软件架构设计的验证应满足GB/T34590.8,2022,第9章的要求;
  2. 检查软件架构设计的验证方法应足表4对不同的ASIL等级的要求。
  3. 检查软件架构设计的验证结果满足本审核点所列出的要求;

附录D

(资料性)

软件单元设计及实现的审核和评估示例

软件单元设计及实现的审核和评估示例,见表D.1。

表D.1 软件单元设计及实现的审核和评估示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件单元设计及实现的开发流程?

检查软件单元设计及实现开发流程

2

是否定义了软件单元设计及实现的模板且在项目中进行了实施?

检查软件单元设计及实现的模板和规范

3

软件单元设计及实现的活动是否与已定义的开发流程保持一致?

检查软件单元设计及实现的模板和流程之间的一致性

4

定义的软件单元设计及实现是否可以覆盖下面列出的评估检查点?

检查软件单元设计及实现的正确性,应至少涵盖检查点5~9的要求

5

软件单元设计是否与软件需求和软件架构设计保持了一致性和追溯性?

软件需求的ID被相关的软件单元承接,软件单元设计是具体的软件架构模块的分解和细化。相关追溯关系通过需求管理ALM工具、架构设计工具和Git进行了链接。

6

软件单元设计是否符合软硬件接口规范(如果适用)

7

软件单元设计的标记方法是否使用了GB/T34590.6,表5中要求的对应ASIL等级推荐的标记方法?

软件单元设计使用了“ASCET/Simulink”等工具开展,并且有规范的设计原则和命名规则等确保了软件单元设计满足半形式的标记方法。

8

软件单元的定义是否将功能表现和内部设计描述到必要的细节程度以支持其实现?

软件单元设计使用了“ASCET/Simulink”等工具开展,以支持后续C-code的实现。

9

软件单元设计和实现的设计是否满足了以下原则:

a) 基于软件架构设计,软件单元内的子程序和函数执行的正确次序;

b) 软件单元间接口的一致性;

c) 软件单元内和软件单元间的数据流及控制流的正确性;

d) 简单性;

e) 可读性和可理解性;

f) 鲁棒性;

GB/T34590.6-2022, 8.4.5的相关单元设计的原则定义在 “xxx-  Guideline _ Software _ Development _ Strategy.docx”文件中,xx项目对应的软件单元存在Git,在ASCET/Matlab或者Word中实行,满足了“xxx-  Guideline _ Software _ Development _ Strategy.docx”中定义的单元设计的原则。

10

软件单元设计是否符合GB/T34590.6,表6中要求的对应ASIL等级推荐的设计原则?

GB/T34590.6-2022, 8.4.5的相关单元设计的要求和方法定义在 “xxx-  Guideline _ Software _ Development _ Strategy.docx”文件中,xx项目对应的软件单元存在Git,在ASCET/Matlab或者Word中实行,满足了“xxx-  Guideline _ Software _ Development _ Strategy.docx”中定义的单元设计的要求和方法,以满足后续C-code的实现。

附录E

(资料性)

软件单元测试审核和评估示例

软件单元测试审核和评估说明及示例,见表E.1。

表E.1 软件单元测试审核和评估说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件单元测试的开发流程?

检查软件单元测试的开发流程

2

是否定义了软件单元测试的模板且在项目中进行了实施?

检查软件单元测试的模板和规范

3

软件单元测试模板是否与已定义的开发流程保持一致?

检查软件单元测试的模板和流程之间的一致性

4

定义的软件单元测试模板是否可以覆盖下面列出的评估检查点?

检查软件单元测试正确性、合理性等,应至少涵盖检查点5~12的要求

5

是否基于GB/T34590-6,第9章在同一开发流程中同时考虑了软件安全要求和所有非安全相关要求,以验证单个软件单元设计?”

是否编制了软件单元设计规范,且建立软件单元测试流程,并按照该流程执行了测试?

  1. 软件单元测试的对象是软件单元
  2. 制定并评审了软件测试计划
  3. 软件单元测试的软件单元设计与实现(软件详细设计、函数)层级的可追溯性、覆盖率
  4. 软件单元验证用例的开发方法、评审
  5. 软件单元验证的方法
  6. 嵌入式软件代码的评审
  7. 软件单元静态分析
  8. 软件单元动态测试
  9. 软件单元验证环境
  10. 软件单元验证Bug管理流程
  11. 软件单元验证结束退出准则

检查软件测试对象,软件单元划分,确认软件单元设计满足分配的软件要求,软件单元测试验证了软件详细设计。

检查软件测试计划评审记录,是否使用审查的评审方法,评审问题是否形成闭环?

检查软件单元测试层级的追溯的实现工具、追溯矩阵、覆盖率等相关资料。

检查软件测试用例是否基于知识与经验的故障猜测建立,是否使用了功能安全要求的开发方法?是否通过评审,评审问题形成闭环?

检查软件代码是否符合MISRA 及企业自己的编码规范检?

静态分析方法、工具、步骤,圈复杂度要求是否满足?

动态测试方法、工具、步骤是否满足要求?

检查软件单元验证Bug管理流程

检查软件单元验证结束后退出准则要求

6

是否按照GB/T34590-8,第9章要求,对已制定的单元验证计划进行了验证?验证中发现的问题是否均已关闭?

注:验证方法包括了测试,也包括评审,分析,可参见表7 软件单元验证方法

检查测试计划、测试报告,测试不符合整改办法,整改后是否执行了回归测试等?

7

是否按照GB/T34590-6,第9章要求确定了单元验证方法的合理组合?选择的单元验证方法组合是否与单元设计与实现中的ASIL定义保持一致?选择的软件单元验证方法是否与标准推荐ASIL保持一致?未使用及不适用的方法是否提供了合理理由?

检查单元测试的确认评审检查单及记录

软件单元验证方法是否是基于GB/T34590.6-2022, 9.4.2 表7要求的基于ASIL等级的验证方法的组合。未选用的验证方法是否有合适的理由。

8

是否按照GB/T34590-6第9章要求得到单元验证用例?选择的单元验证用例开发方法是否与软件单元设计与实现(软件详细设计)中的ASIL定义保持一致?

软件单元测试的测试用例是否依照GB/T34590.6-2022, 9.4.3 表8的要求基于ASIL等级得出并检查单元测试用例评审检查单及记录

9

是否按照GB/T34590-6第9章要求确定了软件验证的结构覆盖率?软件单元验证的结构覆盖率是否与单元设计与实现中的ASIL定义保持一致?软件单元验证结构覆盖率是否与标准推荐ASIL保持一致?测试结果是否能够提供证据说明单元验证活动满足已定义的软件单元设计及实现(软件详细设计)层级的结构覆盖度?

需要确定软件单元验证的覆盖率,需求覆盖率尽量做到全覆盖,如果的确有无法覆盖的需求,需要说明理由

应按照GB/T34590.6-2022, 9.4.4 表9中列出的度量对结构覆盖率进行测定,如果认为已实现的结构覆盖率不充分,应定义额外的测试用例或提供基于其他方法的理由。对于设计及实现覆盖度指标,建议采用工具分析获得。对于无法达成的指标要求,需要说明理由。

10

是否按要求对软件单元验证过程中所有的Bug进行了管理,并跟踪至关闭?

检查软件缺陷Bug管理记录

需要针对软件单元测试工作进行总结,明确软件验证是否完成

测试中所有的问题需要被记录、跟踪,直至关闭。对于遗留的问题,需要进行评估,确保不影响后续的验证活动,且符合已定义的单元测试结束准则

11

是否对通过软件单元验证的软件范围进行了分析,其是否包含全部定义的功能和性能,对于未定义的功能,是否评估了风险或执行了解决措施?

检查软件单元测试策略

需要建立软件单元设计及实现和软件单元测试的追溯关系,确保软件单元测试覆盖了单元设计及实现的所有内容,没有与软件单元设计及实现无关的测试内容

需要建立软件单元设计及实现和软件单元测试的追溯关系,确保软件单元测试覆盖了单元设计及实现的所有内容,没有与软件单元设计及实现无关的测试内容

12

是否对软件单元验证环境进行了分析?如果软件单元环境与目标环境不一致,是否给出了对应措施?

软件单元测试可在不同环境中进行,例如:MIL、SIL、PIL、HIL?

需要明确软件单元测试的测试环境和工具,记录相关的配置信息

如果软件单元测试与目标环境不一致,需要分析差异,定义在目标环境下的附加测试。

附录F

(资料性)

软件集成和验证的审核和评估示例

软件集成和验证的审核和评估说明及示例,见表F.1。

表F.1 软件集成和验证的审核和评估说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件集成和验证的开发流程?

检查软件集成和验证流程

2

是否定义了软件集成和验证的模板且在项目中进行了实施?

检查软件集成和验证的模板

3

软件集成和验证的模板是否与已定义的开发流程保持一致?

检查软件集成和验证的模板和流程之间的一致性

4

定义的软件集成和验证的模板是否可以覆盖下面列出的评估检查点?

检查软件集成和验证模板的正确性,应至少涵盖检查点5~14的要求

5

是否基于GB/T34590-610章要求,定义了软件集成方法和策略?

定义软件集成方法和步骤可考虑以下内容:

  1. 软件集成及验证步骤和集成方式(Top DownBottom Up
  2. 对于大型软件需要明确集成步骤,可根据软件功能及软件架构明确每次集成的范围和先后顺序
  3. 在分步骤集成过程中,可能需要编制“桩函数”,建议在软件集成步骤说明中进行明确
  4. 对于复杂软件,建议编制软件集成操作指南,明确集成环境/工具的配置参数
  5. 对于小型软件,可以考虑“一次性集成”,建议说明原因

定义软件集成测试策略可考虑以下内容:

  1. 软件集成测试的测试目标,例如:软件架构层次的需求覆盖度和结构覆盖度
  2. 软件集成测试用例的导出方法
  3. 软件集成测试的方法组合
  4. 软件集成测试的环境,明确软件集成测试环境的配置参数
  5. 软件集成测试的Bug管理流程
  6. 软件集成测试中回归测试的策略
  7. 软件集成测试的结束准则

6

是否按照GB/T34590-610章要求,通过表10软件集成验证方法确定了软件集成及验证方法的合理组合?

  1. GB/T34590-6中给出了软件集成验证的方法,需要明确软件架构设计的ASIL,选择的软件集成验证方法需要与标准推荐ASIL保持一致。对于未采用的方法,需要说明原因,例如:当未采用MBD开发方法,模型和代码之间的背靠背比较测试不适用
  2. 对于选择的验证方法,需要有具体的验证证据,例如:如果选择了静态代码检查方法,并采用工具实施这一活动,需保留静态代码检查结果,如果静态代码检查发现了问题,需在问题解决后,再次执行静态代码检查,以证明发现的问题得到了解决
  3. 对于软件架构、软硬件接口规范和软件需求等,软件集成验证需要有一定的覆盖性,例如:对于软件架构设计中的控制流设计和数据流设计,需要在软件集成验证中有对应的测试用例
  4. 建议明确每条测试用例对应的软件集成验证方法
  5. 注:具体要求参考GB/T34590-610章表10

7

针对已选择的软件集成及验证方法,是否有相关内容说明相应的软件集成及验证活动执行符合要求?

  1. 针对选定的软件集成及验证方法,需要明确执行的方法和工具(例如:故障注入测试与静态代码分析会使用不同的工具)
  2. 如果使用工具执行分析和测试工作,需要维护好相应的输入和输出,并建立好与被验证方面的追溯关系

8

是否正确执行了软件集成及验证?验证中发现的问题是否均已关闭?

  1. 需要针对软件集成及验证的工作进行总结,明确软件集成及验证是否完成
  2. 验证中所有的问题需要被记录、跟踪,直至关闭。对于遗留的问题,需要进行评估,确保不影响后续的验证活动,且符合已定义的软件集成测试结束准则

9

是否按照GB/T34590-610章表11软件集成测试用例的得出方法要求开发了软件集成测试用例?

  1. GB/T34590-6中给出了软件集成测试用例的得出方法,需要明确软件架构设计的ASIL,选择的软件集成测试用例导出方法需要与标准推荐ASIL保持一致。对于未采用的方法,需要说明原因
  2. 基于知识或经验的错误推测方法,虽然标准中为“+”,如果有条件,建议选择
  3. 建议明确每条测试用例对应的软件集成测试用例导出方法
  4. 测试用例中建议包含必要的属性:测试用例ID、测试步骤、预期结果、ASIL等级、测试用例得出方法、软件集成验证方法

注:具体要求参考GB/T34590-610章表11

10

是否按照GB/T34590-610章要求确定了测试用例在软件架构层级的需求覆盖率和结构覆盖率(包括函数覆盖率和调用覆盖率)? 

  1. 需要确定软件架构层级的需求覆盖率,软件架构层级的需求覆盖率尽量做到全覆盖,如果的确有无法覆盖的需求,需要说明理由
  2. GB/T34590-6中给出了软件架构层次的架构覆盖度要求,需要明确软件架构设计的ASIL,选择的软件架构层次的架构覆盖度需要与标准推荐ASIL保持一致
  3. 对于架构覆盖度指标,建议采用工具分析获得。对于无法达成的指标要求,需要说明理由

注:具体要求参考GB/T34590-610章表12

11

是否对通过软件集成及验证的软件范围进行了验证,其是否包含全部定义的功能和性能,对于未定义的功能,是否评估了风险或执行了解决措施?

  1. 需要建立软件架构和软件集成验证的追溯关系,确保软件集成测试覆盖了软件架构的所有内容,没有与软件架构无关的测试内容
  2. 需要建立软件需求和软件集成验证的追溯关系,确保软件集成测试覆盖了软件需求的所有内容,没有与软件需求无关的测试内容
  3. 对于用于调试或检测的代码,需要进行妥善处理,不影响安全要求

12

是否对软件集成测试及验证环境进行了分析?如果软件集成测试及验证环境与目标环境不一致,是否进行分析并给出了对应措施?

  1. 软件集成测试可在不同环境中进行,例如:MILSILPILHIL
  2. 需要明确软件集成测试的测试环境和工具,记录相关的配置信息
  3. 如果软件集成测试与目标环境不一致,需要分析差异,定义在目标环境下的附加测试

附录G

(资料性)

嵌入式软件测试的审核和评估的示例

嵌入式软件测试的审核和评估的示例,见表G.1。

表G.1 嵌入式软件测试的审核和评估说明及示例

序号

要求对应的checklist

评估示例及说明

1

是否定义了嵌入式软件测试的开发流程?

检查嵌入试软件测试流程

2

是否定义了嵌入式软件测试的模板且在项目中进行了实施?

检查嵌入式软件测试的模板

3

嵌入式软件测试的模板是否与已定义的开发流程保持一致?

检查嵌入式软件测试的模板和流程之间的一致性

4

定义的嵌入式软件测试的模板是否可以覆盖下面列出的评估检查点?

检查嵌入式软件测试模板的正确性,应至少涵盖检查点5~11的要求

5

是否基于GB/T34590-611章要求,制定了嵌入式软件测试策略?

定义嵌入式软件测试策略可考虑以下内容:

  1. 嵌入式软件测试的测试目标,例如:软件需求覆盖度
  2. 嵌入式软件测试用例的导出方法
  3. 嵌入式软件测试的方法组合
  4. 嵌入式软件测试的环境,明确嵌入式软件测试环境的配置参数
  5. 嵌入式软件测试的Bug管理流程
  6. 嵌入式软件测试中回归测试的策略
  7. 嵌入式软件测试的结束准则

6

是否按照GB/T34590-611章表13用于执行软件测试的测试环境要求,确定了嵌入式软件测试的测试环境?

  1. GB/T34590-6中给出了嵌入式软件验证的测试环境要求,需要明确软件需求的ASIL,选择的嵌入式软件测试环境需要与标准推荐ASIL保持一致。对于未采用的测试环境,需要说明原因
  2. 需要明确嵌入式软件测试环境的软件测试工具、硬件测试工具的配置参数

注:具体要求参考GB/T34590-611章表13

7

是否按照GB/T34590-611章表14嵌入式软件的测试方法要求,确定了嵌入式软件测试方法的合理组合?

  1. GB/T34590-6中给出了嵌入式软件测试的测试方法要求,需要明确软件需求的ASIL,选择的嵌入式软件测试方法需要与标准推荐ASIL保持一致。对于未采用的测试方法,需要说明原因
  2. 对于选择的测试方法,需要有具体的测试证据,需要记录测试结果
  3. 建议明确每条测试用例对应的嵌入式软件测试方法

注:具体要求参考GB/T34590-611章表14

8

针对已选择的嵌入式软件测试方法,是否有相关内容说明相应的嵌入式软件测试活动执行符合要求?

  1. 针对每种选定的嵌入式软件测试方法,需要明确执行的方法和工具(例如:硬件在环方法和电子控制单元网络环境方法可能会使用不同的测试工具)
  2. 对于选择的嵌入式软件测试方法,需要维护好相应的输入和输出,并建立好与被验证方面的追溯关系

9

是否按照GB/T34590-611章要求,开发了嵌入式软件测试用例?

  1. GB/T34590-6中给出了嵌入式软件测试的测试用例导出方法,需要明确软件需求的ASIL,选择的嵌入式软件测试用例导出方法需要与标准推荐ASIL保持一致。对于未采用的测试用例导出方法,需要说明原因
  2. 建议明确每条测试用例对应的嵌入式软件测试用例导出方法
  3. 测试用例中建议包含必要的属性:测试用例ID、测试步骤、预期结果、ASIL等级、测试用例得出方法、嵌入式软件测试方法

注:具体要求参考GB/T34590-611章表15

10

是否正确执行了嵌入式软件测试?测试中发现的问题是否均已关闭?

  1. 需要针对嵌入式软件测试的工作进行总结,明确嵌入式软件测试是否完成
  2. 测试中所有的问题需要被记录、跟踪,直至关闭。对于遗留的问题,需要进行评估,确保不影响安全功能的执行,且符合已定义的结束准则

11

是否对嵌入式软件测试的测试结果及覆盖率进行了评估?

  1. 需要建立软件需求和嵌入式软件测试的追溯关系,确保嵌入式软件测试覆盖了软件需求的所有内容,没有与软件需求无关的测试内容
  2. 对于嵌入式软件测试,每条测试用例的测试结果均与软件需求定义的预期需求保持一致

附录H

(资料性)

软件标定和配置管理的审核和评估示例

软件标定和配置管理的审核和评估示例,见表H.1。

表H.1 软件标定和配置管理的审核和评估说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件配置的验证流程?

检查软件配置开发流程

2

是否定义了软件配置的模板且在项目中进行了实施?

检查软件配置的模板

3

软件配置模板是否与已定义的开发流程保持一致?

检查软件配置的模板和流程之间的一致性

4

定义的软件配置模板是否可以覆盖下面列出的评估检查点?

检查软件配置模板的正确性,应至少涵盖检查点5~16的要求

5

是否对配置数据进行了定义?

  1. 配置数据的有效值;
  2. 配置数据的目的和用法;
  3. 范围、比例、单位;
  4. 配置数据不同要素之间的相互依赖;
  1. 检查配置数据的定义属性,包括有效值、目的、用法、范围、比例、单位、依赖性等;
  2. 需要对在要素构建过程中分配的且控制要素构建过程的数据进行定义,如预处理器变量设置,用于从源代码导出出编译时间变量;用于控制构建工具或工具链的XML文件等;
  3. 如软件模块TESSY测试模式开关TESSY_TEST,此项打开将会取消部分函数参数和变量的const限制和变量的static限制方便TESSY的测试,正式版本需要设置为STD_OFF

STD_OFF:关

STD_ON:开

6

配置数据及其规范是否能够提供证据证明以下内容?

  1. 配置数据符合软件架构设计规范
  2. 配置数据符合软件单元设计规范;
  3. 配置数据使用的值在其规定的范围内;
  4. 配置数据与其他配置数据的兼容性;
  1. 配置数据规范的定义及内容应符合软件架构设计和软件单元设计,以其为主体,且使用的值在定义的范围内;
  2. 对配置软件的测试应软件单元测试、软件集成测试、嵌入式软件测试中进行测试;
  3. 如软件架构或软件单元设计规范中已定义好相关数据,配置数据应按其执行;

7

是否规定了配置数据的ASIL等级应等于应用于该数据的可配置软件的最高ASIL等级?

  1. 配置数据的ASIL等级应按照其在的可配置软件(软件单元/软件组件)的ASIL等级进行匹配,等于应用于该数据的可配置软件的最高ASIL等级;
  2. 如某传感器模块Mlx90365模块,其ASIL等级为B,则其配置数据应达到ASIL B等级;

8

是否按照GB/T 34590-8 2022,第9章定义了对相关项开发中要使用的配置数据集对可配置软件的验证?

1.其行为依赖于配置数据的那部分嵌入式软件要针对配置数据集进行验证;

9

是否执行了可配置软件的验证?是否关闭问题?

  1. 可配置软件的验证;
  2. 配置数据的验证;
  3. 已配置软件的验证;

在进行可配置软件的验证时,可通过如下任意一种方式实现:

  1. 应当在可配置软件的验证验证允许的配置数据的范围,并说明它在配置数据验证中定义的范围;
  2. 说明在配置数据验证中允许的配置数据范围的符合性,并执行已配置软件的验证;

10

是否定义了与软件组件关联的标定数据以确保配置后软件的正确运行和预期性能?

  1. 标定数据的有效值;
  2. 标定数据的目的和用法;
  3. 范围、比例和单位,以及它们对运行状态的依赖(如果适用);
  4. 不同标定数据之间已知的相互依赖;
  5. 配置数据和标定数据之间的已知的相互依赖;
  1. 检查标定数据的定义属性,包括有效值、目的、用法、范围、比例、单位、依赖性等;
  2. 相互依赖可存在于同一标定数据集内的标定数据之间,或者不同标定数据集的标定数据之间,如:不同电子控制单元的软件中执行的应用于相关功能的标定数据;
  3. 配置数据可对使用标定数据的已配置软件有影响;
  4. 需要将软件构建后将用作软件参数值的数据进行定义,如参数(例如,低怠速值、发动机万有特性图)、车辆特定参数(适应值,例如,节气门限位)、变量编码(例如,国家代码、左舵/右舵);

11

是否规定了标定数据的ASIL等级应等于其可能违反的软件安全要求的最高ASIL等级?

  1. 标定数据的ASIL等级应按照其在的已配置软件(软件单元/软件组件)的ASIL等级进行匹配,等于应用于该数据的已配置软件的最高ASIL等级;
  2. 如某传感器模块Mlx90365模块,其ASIL等级为B,并已经配置好,则其标定数据(如挡位对应范围)应达到ASIL B等级;

12

是否按照GB/T 34590-8 2022,第9章定义了如何验证标定数据?

  1. 定义的标定数据合适并符合软件安全要求;
  2. 定义的标定数据符合软件架构设计规范;
  3. 定义的标定数据符合软件单元设计规范;
  4. 定义的标定数据与其他定义的标定数据是一致且兼容的;
  1. 标定数据规范的定义及内容应符合软件架构设计和软件单元设计,以其为主体,且使用的值在定义的范围内;
  2. 标定数据要满足软件安全需求SSR中提出的要求;
  3. 已定义好的标定数据互相之间应没有影响或不一致,否则需要重新定义;
  4. 标定数据的验证可包含检查标定数据值的范围或者不同标定数据之间的相互依赖关系;

13

是否按照GB/T 34590-8 2022,第9章定义了用于生产发布的标定数据的验证?是否关闭问题?

  1. 发布的标定数据符合其规范;
  2. 嵌入式软件的已标定的、应用特定的变体提供了定义的安全相关功能和特性;
  1. 标定数据的验证也可以在系统层面执行;
  2. 在小批量生产、量产阶段的标定数据需要进行验证,符合标定数据规范、软件安全需求规范、软件架构设计规范、软件单元设计规范;

14

是否定义了数据非预期变化的探测机制?

注:具体要求参考GB/T34590-6附录C表C.1

对于不同ASIL等级的软件组件/软件单元的标定数据,应按照其等级,检查是否使用如下方法探测安全相关的标定数据的非预期变化,

  1. 标定数据合理性检查;
  2. 标定数据的冗余存储和比较;
  3. 使用错误检测码检查标定数据;

15

是否定义了标定数据应遵循的流程、生成标定数据的工具和验证标定数据的流程?

  1. 检查在标定数据规范中应标明标定数据产生、验证的流程,并按此进行执行;
  2. 生成标定数据所用到的工具需要明确,在软件开发环境文档和标定数据规范中进行定义;

16

软件开发环境文档中是否针对软件配置的更新细化内容?

1.在软件配置时需要按照上述5-15要求进行明确细化软件开发环境文档,将最初始不明确的地方进行完善。

附录I

(资料性)

软件工具鉴定审核和评估示例

软件工具鉴定审核和评估示例,见表I.1。

表I.1 软件工具鉴定审核和评估示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件工具鉴定的开发流程?

检查软件工具的鉴定开发流程

2

是否定义了软件工具鉴定的模板且在项目中进行了实施?

检查软件工具鉴定的模板

3

软件工具鉴定模板是否与已定义的开发流程保持一致?

检查软件工具鉴定的模板和流程之间的一致性

4

定义的软件工具鉴定模板是否可以覆盖下面列出的评估检查点?

检查软件工具鉴定模板的正确性

5

安全计划中是否基于考虑所使用软件工具的置信度的依据而按照6.4.5.1对某一安全活动进行剪裁?若有,剪裁是否满足GB/T 34590.8-XXXX,第11 章的要求?

检查安全计划中是否由于软件工具鉴定而对某一安全活动进行了剪裁

6

是否有预先确定的工具在执行其置信度水平评估或鉴定时,独立于特定安全相关项或要素的开发?若有,是否对预先确定的工具置信度水平的有效性或鉴定的有效性进行验证?

检查安全计划中是否包含对软件组件鉴定计划

7

使用软件工具时,工具的使用、工具定义的环境和功能约束及其一般运行条件是否和工具评估准则或鉴定相符合?

检查使用软件工具时,工具的使用、工具定义的环境和功能约束及其一般运行条件是否和工具评估准则或鉴定相符合?

8

是否有对软件工具使用的计划?

检查是否有对软件工具使用的计划

9

对软件工具使用的计划中是否包含

  1. 软件工具的识别码和版本号;
  1. 软件工具的配置;
  1. 软件工具的使用案例;
  1. 软件工具执行的环境;
  1. 当软件工具功能异常并产生相应的错误输出时,会直接违背分配给相关项或要素的全部安全要求的最高ASIL等级;及

f) 如需要,基于确定的置信度水平和ASIL等级的软件工具的鉴定方法。

检查对软件工具使用的计划中是否包含GB/T 34590.8—2022 11.4.4.1要求的内容

  1. 软件工具的配置;

示例1:通过设定编译器开关和C源文件中“#pragma”声明,定义编译器的配置。

  1. 软件工具的使用案例;

注1:在开展安全生命周期活动时,使用案例可以描述用户与软件工具的配合和软件工具功能的应用子集。

注2:使用案例可包含对软件工具配置及软件工具执行环境的要求。

  1. 软件工具执行的环境;

示例2:执行软件工具所需的资源、基础设施或运行时环境,应用软件工具所需的流程活动或与软件工具输出结果验证相关的后续流程活动。

  1. 当软件工具功能异常并产生相应的错误输出时,会直接违背分配给相关项或要素的全部安全要求的最高ASIL等级;及

注3:可根据特定开发确定最高ASIL等级,或可根据软件工具通用的用法确定最高ASIL等级。在预先假定ASIL等级的情况下,对该假设进行验证。

10

为了进行软件工具评估,是否收集了软件工具相关信息

  1. 软件工具的特征、功能和技术属性的描述;
  2. 如果适用,用户手册或其他使用指南;
  3. 工具运行要求的环境描述;
  4. 如果适用,对异常运行条件下期望的软件工具表现的描述;
  1. 如果适用,对已知软件工具功能异常,及恰当的安全保护、避免或应急措施的描述;及

f) 在制定软件工具要求的置信度水平过程中,识别出的对软件工具功能异常和相应错误输出的预防或探测措施。

检查为了进行软件工具评估,是否收集了软件工具相关信息

  1. 如果适用,对异常运行条件下期望的软件工具表现的描述;

示例1:异常运行条件可以是禁止的编译开关组合、不符合用户手册的环境或不正确的安装。

示例2:异常运行条件下期望的表现可以是对输出生成的阻止、用户提示或用户报告。

  1. 如果适用,对已知软件工具功能异常,及恰当的安全保护、避免或应急措施的描述;及

示例3:针对已知的功能异常、编译器编码优化局限或建模中使用受限制的一组构件的使用指南或应急措施。

示例4:安全保护包括通过使用约束防止全部已知的功能异常和问题、探测和报告全部已知的功能异常和问题,也包括提供安全替代技术以开展相应的活动。

  1. 在制定软件工具要求的置信度水平过程中,识别出的对软件工具功能异常和相应错误输出的预防或探测措施。

注1:相应错误输出的预防或探测措施可针对软件工具输出中的已知和潜在错误。

示例5:冗余软件工具输出的对比、执行的测试、静态分析或评审、软件工具日志文件的分析、具有已知问题的功能的避免。

11

软件工具准则评估报告对软件工具使用的描述是否包含下述信息:

  1. 预期的目的;
  1. 输入和期望的输出;及

c) 如果适用,使用过程、环境的和功能的约束。

检查软件工具准则评估报告对软件工具使用的描述是否包含下述信息

  1. 预期的目的;

示例1:功能的模拟、源代码的生成、嵌入式软件的测试、安全生命周期的裁剪、GB/T 34590要求的活动和任务的简单化或自动化。

  1. 输入和期望的输出;及

示例2:后续开发活动输入所需的数据、源代码、模拟结果、测试结果、或GB/T 34590的其他工作成果。

  1. 如果适用,使用过程、环境的和功能的约束。

示例3:软件工具嵌入到开发过程、不同软件工具使用共享数据及其他使用条件、预防或探测软件工具的功能异常的流程措施。

12

软件工具准则评估报告中是否分析和评估了软件工具的预期使用,以确定:

  1. 特定软件工具功能异常可引入或不能探测开发中安全相关项或要素中错误的可能性。这是通过工具影响(TI)等级表示的:

——当有论据表明没有这样的可能性时,应选择TI1;

——在所有其他情况下应选择TI2。

  1. 用于预防软件工具功能异常并产生相应错误输出的措施的置信度,或用于探测软件工具存在功能异常并已产生相应错误输出的措施的置信度。这是通过工具错误探测(TD)等级表示的:

——当对预防或探测出功能异常及其相应错误输出具有高置信度时,应选择TD1;

——当对预防或探测出功能异常及其相应错误输出具有中等置信度时,应选择TD2;

——在所有其他情况下应选择TD3。

软件工具准则评估报告中是否分析和评估了软件工具的预期使用。

注1:预防或探测可通过流程步骤、任务或软件工具的冗余、或软件工具自身的合理性检查完成。

注2:如果具备的开发流程中没有系统性措施,则典型适用TD3,为此,仅能随机探测出软件工具的功能异常及其相应错误输出。

注3:如果用一个软件工具验证另一软件工具的输出,当评估这一软件工具时,考虑软件工具间的相互依赖性,为该软件工具选择一个充分的TD。例如,工具之间可能因使用了公共组件或者共享资源而存在相互依赖性。

注4:此使用分析的详细程度仅需要允许恰当的确定TI和TD的等级。

示例1:在按照GB/T 34590对产生的源代码进行验证的情况下,为代码生成器选择TD1。当不对产生的源代码进行验证时,为代码生成器选择TD3

示例2:使用指南防止功能异常,例如编译器对代码构成的错误或不清晰的理解。

示例3:针对用于静态验证源代码中不存在潜在的除零情况的工具,如果为此目的也同时进行了测试,则可为该工具选择TD2。如果仅通过工具验证不存在除零的情况,可为该工具选择TD3。

13

软件工具准则评估报告中是否存在对TI或TD选择的正确性是不清楚的或可疑的?若有是否对TI和TD进行了保守评估?

示例:对TI选择的正确性存疑,那么TI=2

14

软件工具准则评估报告中基于为TI和TD等级确定的值,是否按照GB/T 34590.8—2022 11.4.5.4表3来确定所要求的软件工具的置信度水平?

检查TI和TD等级确定的值得出的TCL值是否能与GB/T 34590.8—2022 11.4.5.4表3中的对应

15

软件工具鉴定报告中,对鉴定等级为TCL3的软件工具,是否按照GB/T 34590.8—2022 11.4.6.14列出的方法?

检查对鉴定等级为TCL3的软件工具,是否按照GB/T 34590.8—2022 11.4.6.14列出的方法

1d 全标准开发a

a 没有安全标准完全适用于软件工具的开发。相反,可选择安全标准中相关的一组安全要求。

示例:按照GB/T 34590-XXXX、GB/T 20438、EN50128或RTCA DO-178开发软件工具。

16

软件工具鉴定报告中,对鉴定等级为TCL2的软件工具,是否按照GB/T 34590.8—2022 11.4.6.15列出的方法?

检查对鉴定等级为TCL2的软件工具,是否按照GB/T 34590.8—2022 11.4.6.15列出的方法

1d 全标准开发a

a 没有安全标准完全适用于软件工具的开发。相反,可选择安全标准中相关的一组安全要求。

示例:按照GB/T 34590-XXXX、GB/T 20438、EN50128或RTCA DO-178开发软件工具。

17

软件工具鉴定报告中,是否包含以下文档化信息?

  1. 软件工具的唯一识别码和版本号;
  2. 软件工具划分的最高工具置信度等级,及其评估分析参考;
  3. 对于考虑的使用案例,当软件工具功能异常并产生相应的错误输出时,可能直接违背任何安全要求的预定义最高ASIL等级或特定ASIL等级;
  4. 软件工具被鉴定的配置和环境;
  5. 执行鉴定的人员或组织;
  6. 鉴定使用的方法,按照11.4.6.1;
  7. 用于鉴定软件工具的措施结果;及,
  8. 如果适用,在鉴定过程中识别出的使用约束和功能异常。

检查软件工具鉴定报告中,是否包含GB/T 34590.8—2022 11.4.6.2规定的信息

18

软件工具鉴定报告中,是否将“使用中积累置信度”的方法用于软件工具的鉴定?

检查软件工具鉴定报告中,是否将“使用中积累置信度”的方法用于软件工具的鉴定?

19

软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

  1. 仅当具备以下方面的证据时,才应论证软件工具在使用中积累了置信度:
  1. 此前,已经将该软件工具用于相同的目的,具有相似的使用案例、相似的预定运行环境和相似的功能约束中;
  2. 使用中积累置信度的理由是基于充分适当的数据;
  1. 软件工具的定义未改变;及
  2. 在之前开发中获得的软件工具功能异常和相应错误输出的发生案例是以系统化方式累计的。
  1. 仅当具备以下方面的证据时,才应论证软件工具在使用中积累了置信度:

  1. 使用中积累置信度的理由是基于充分适当的数据;

注:可从累计使用量中获得数据(例如:时间长度或频率)。

20

软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

  1. 应通过考虑以下信息,对给定开发活动中软件工具的先前使用经验进行分析和评估:

  1. 软件工具唯一的识别码和版本号;
  2. 软件工具的配置;
  3. 使用周期和使用相关数据的细节;

示例1:软件工具相关使用案例中,使用的软件工具特征及使用频率。

  1. 软件工具的功能异常和相应错误输出的详细文档化记录,其中包含引起功能异常和错误输出的条件;
  2. 所监控的先前版本清单,其中列出每个相关版本中解决的功能异常;及
  3. 如果适用,对已知缺陷的安全保护、避免措施、应急措施或相应错误输出的探测措施
  1. 应通过考虑以下信息,对给定开发活动中软件工具的先前使用经验进行分析和评估:

  1. 使用周期和使用相关数据的细节;

示例1:软件工具相关使用案例中,使用的软件工具特征及使用频率。

  1. 如果适用,对已知缺陷的安全保护、避免措施、应急措施或相应错误输出的探测措施

示例2:使用报告的来源可以是日志、供应商提供的软件工具版本历史、已发布的勘误表。

21

软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

使用中积累置信度的论证应仅对所评估的软件工具版本有效。

检查软件工具鉴定报告中,用于软件工具鉴定的“使用中积累置信度”的方法是否满足以下要求:

  1. 使用中积累置信度的论证应仅对所评估的软件工具版本有效。

22

软件工具鉴定报告中,是否将“工具开发流程评估”的方法用于软件工具的鉴定?若有,是否满足以下要求:

  1. 用于软件工具开发的流程应满足适当的标准。
  2. 应基于恰当的国内或国际标准对软件工具开发流程进行评估,同时提供恰当的软件开发流程被应用的证据。
  1. 用于软件工具开发的流程应满足适当的标准。

注:对于开源开发,那些团体使用的某些标准也可能是适当的。

  1. 应基于恰当的国内或国际标准对软件工具开发流程进行评估,同时提供恰当的软件开发流程被应用的证据。

注:该评估涵盖了对软件工具的一个恰当且相关的特征子集的开发。

示例:使用基于Automotive SPICE、ISO/IEC 33000或CMMI 的评估方法。

23

软件工具鉴定报告中,是否将“软件工具确认”的方法用于软件工具的鉴定?若有,是否满足以下要求:

软件工具的确认应满足以下准则:

  1. 确认措施应提供软件工具符合分类中指定用途的特定要求的证据;
  1. 应对确认中发生的软件工具功能异常及其相应错误输出、其可能的后果信息、及避免或探测它们的措施进行分析;及
  1. 应检查软件工具对异常运行条件的响应。

  1. 确认措施应提供软件工具符合分类中指定用途的特定要求的证据;

注1:确认提供了评估的工具错误不会发生或将被检测到的证据;

注2:确认可通过使用用户开发的或工具供应商(如果供应商的测试套件包括用户的工具使用案例)开发的自定义测试套件来实施。

示例1:编程语言标准有助于定义相关编译器的确认要求。

  1. 应检查软件工具对异常运行条件的响应。

示例2:可预见的误用、不完整的输入数据、不完整的软件工具升级、使用被禁止的配置设置组合。

附录J

(资料性)

软件组件鉴定审核和评估示例

软件组件鉴定审核和评估示例,见表J.1。

表J.1 软件组件鉴定审核和评估说明及示例

序号

审核和评估要求

评估示例及说明

1

是否定义了软件组件鉴定的开发流程?

检查软件组件的鉴定开发流程

2

是否定义了软件组件鉴定的模板且在项目中进行了实施?

检查软件组件鉴定的模板

3

软件组件鉴定模板是否与已定义的开发流程保持一致?

检查软件组件鉴定的模板和流程之间的一致性

4

定义的软件组件鉴定模板是否可以覆盖下面列出的评估检查点?

检查软件组件鉴定模板的正确性

5

安全计划中是否由于软件组件鉴定而按照6.4.5.1 对某一安全活动进行了剪裁?,若有,剪裁是否满足GB/T 34590.8-XXXX,第12 章的要求?

检查安全计划中是否由于软件组件鉴定而对某一安全活动进行了剪裁

6

安全计划中是否包含对软件组件鉴定计划?

检查安全计划中是否包含对软件组件鉴定计划

7

软件组件的软件开发过程是否基于适当的国际标准?

检查软件组件的软件开发过程是否基于适当的国际标准?

8

软件组件的文档是否包括了软件组件的唯一识别?

检查软件组件的文档是否包括了软件组件的唯一识别

示例1:标识软件组件的ID

9

软件组件的文档是否包含当软件组件错误执行时,可能违背的所有安全要求的最高ASIL等级?

检查软件组件的文档中是否包含最高ASIL等级

10

软件组件的文档是否包括了为鉴定软件组件所应执行的活动?

检查软件组件的文档是否包括了为鉴定软件组件所应执行的活动

11

软件组件的文档是否包含以下要求?

・软件组件的要求

・软件组件预期用途的要求

    ・配置描述

    ・所需接口、供给接口、共享资源描述(如果适用)

    ・软件组件集成的描述

    ・异常运行条件下的功能反应

    ・对已知异常及相应应急措施的描述

检查软件组件的说明资料是否满足以下要求。

12

是否提供了软件组件的鉴定报告,以证明组件的开发过程符合标准的证据,并记录了论证结果?

检查软件组件的鉴定报告是否有提供,是否有证明组件的开发过程符合标准的证据及论证结果记录

13

软件组件鉴定报告是否提供了软件组件的验证结果,以证明符合以下要求,并记录了论证结果?

・分配给软件组件的要求的测试覆盖率应满足GB/T34590.6-XXXX,第9章;

・满足测试用例完整性要求(ASILD适用),结构覆盖率应按照GB/T34590.6-XXXX,第9章来测量;

    ・既覆盖正常运行条件,也覆盖失效情况下的表现

    ・没有导致违背安全要求的已知错误

检查软件组件鉴定报告是否提供了软件组件的验证结果,以证明符合要求,并记录了论证结果。

    ・展示对要求的覆盖率,按照GB/T 34590.6-XXXX 第9 章;

注:该验证是主要基于要求的测试,可使用软件组件开发过程中或在之前的集成测试中执行的基于要求的测

试结果。

示例:专用鉴定测试套件的应用,对软件组件实施和全部集成期间的所有已执行测试的分析。

14

软件组件鉴定报告是否对软件组件的鉴定进行了记录?

检查软件组件鉴定报告是否对软件组件的鉴定进行了记录

15

对软件组件的鉴定记录中是否包含下述信息:

  1. 软件组件的唯一识别;
  2. 软件组件的唯一配置;
  3. 执行鉴定的人员或组织;
  1. 用于鉴定的环境;
  2. 用于鉴定软件组件的验证措施的结果;及

f) 分配给软件组件的安全要求的最高ASIL等级。

检查对软件组件的鉴定记录中是否包含GB/T 34590.8—2022 12.4.2

要求的信息;

16

是否按照GB/T34590.8-XXXX,第9章的要求验证了软件组件的鉴定结果,以证明是否对软件组件资质评估结果进行验证?

检查是否按照GB/T34590.8-XXXX,第9章的要求验证了软件组件的鉴定结果,以证明是否对软件组件资质评估结果进行验证?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

电气_空空

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值