标准搜索结果: 'GB/T 34590.6-2017'
| 标准编号 | GB/T 34590.6-2017 (GB/T34590.6-2017) | | 中文名称 | 道路车辆 功能安全 第6部分：产品开发：软件层面 | | 英文名称 | Road vehicles -- Functional safety -- Part 6: Product development at the software level | | 行业 | 国家标准 (推荐) | | 中标分类 | T35 | | 国际标准分类 | 43.040 | | 字数估计 | 42,448 | | 发布日期 | 2017-10-14 | | 实施日期 | 2018-05-01 | | 起草单位 | 中国汽车技术研究中心、上海海拉电子有限公司、舍弗勒投资(中国)有限公司、泛亚汽车技术中心有限公司、博世汽车部件(苏州)有限公司、中国第一汽车股份有限公司、北京兴科迪科技有限公司、联合汽车电子有限公司、东软集团股份有限公司、北京经纬恒润科技有限公司、上汽大众汽车有限公司、上海汽车集团股份有限公司商用车技术中心 | | 归口单位 | 全国汽车标准化技术委员会(SAC/TC 114) | | 提出机构 | 全国汽车标准化技术委员会(SAC/TC 114) | | 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 | GB/T 34590.6-2017
道路车辆 功能安全 第6部分：产品开发：软件层面
Road vehicles -- Functional safety -- Part 6: Product development at the software level
1 范围
GB/T 34590的本部分规定了车辆在软件层面产品开发的要求,包括:
---启动软件层面产品开发;
---软件安全要求的定义;
---软件架构设计;
---软件单元设计及实现;
---软件单元测试;
---软件集成和测试;及
---软件安全要求的验证。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统,例如,为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。
对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时,仅修改的部分需要按
照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害,包括这些系统相互作用而
引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能,即使这些系统(例如,主动和被动安全系统、制动系统、自
适应巡航系统)有专用的功能性能标准。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 34590.1-2017 道路车辆 功能安全 第1部分:术语(ISO 26262-1:2011,MOD)
GB/T 34590.2-2017 道路车辆功能安全 第2部分:功能安全管理(ISO 26262-2:2011,MOD)
GB/T 34590.4-2017 道路车辆功能安全 第4部分:产品开发:系统层面(ISO 26262-4:2011,
MOD)
GB/T 34590.5-2017 道路车辆功能安全 第5部分:产品开发:硬件层面(ISO 26262-5:2011,
MOD)
GB/T 34590.8-2017 道路车辆功能安全 第8部分:支持过程(ISO 26262-8:2011,MOD)
GB/T 34590.9-2017 道路车辆功能安全 第9部分:以汽车安全完整性等级为导向和以安全为
导向的分析(ISO 26262-9:2011,MOD)
3 术语、定义和缩略语
GB/T 34590.1-2017界定的术语、定义和缩略语适用于本文件。
4 要求
4.1 一般要求
如声明满足GB/T 34590-2017的要求时,应满足每一个要求,除非有下列情况之一:
a) 按照GB/T 34590.2-2017的要求,已经计划了安全活动的剪裁并表明这些要求不适用;或
b) 不满足要求的理由存在且是可接受的,并且按照GB/T 34590.2-2017对该理由进行了评估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求,不应作为要求本身且不具备完备性。
将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的
某些要求是依照ASIL定义的或可剪裁的,某些工作成果可不作为前提条件。
“支持信息”是可供参考的信息,但在某些情况下,GB/T 34590-2017不要求其作为上一阶段的工
作成果,并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。
4.2 表的诠释
表属于规范性表还是资料性表取决于上下文。在实现满足相关要求时,表中列出的不同方法有助
于置信度水平。表中的每个方法是:
a) 一个连续的条目(在最左侧列以顺序号标明,如1、2、3);或
b) 一个选择的条目(在最左侧列以数字后加字母标明,如2a、2b、2c)。
对于连续的条目,全部方法应按照ASIL等级推荐予以使用。除了所列出的方法外,如果应用所列
出方法以外的其他方法,应给出满足相关要求的理由。
对于选择性的条目,应按照指定的ASIL等级,对这些方法进行适当的组合,不依赖于这些方法是
否在表中列出。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级,宜采用具有较高推
荐等级的方法。应给出所选的方法组合满足相关要求的理由。
注:表中所列出的方法的理由是充分的。但是,这并不意味着有倾向性或对未列到表中的方法表示反对。
对于每种方法,应用相关方法的推荐等级取决于ASIL等级,分类如下:
---“++”表示对于指定的ASIL等级,高度推荐该方法;
---“+”表示对于指定的ASIL等级,推荐该方法;
---“o”表示对于指定的ASIL等级,不推荐也不反对该方法。
4.3 基于ASIL等级的要求和建议
若无其他说明,对于ASILA、B、C和D等级,应满足每一子章条的要求或建议。这些要求和建议
参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解,按照GB/T 34590.9-2017
第5章,应遵循分解后的ASIL等级。
如果GB/T 34590-2017中ASIL等级在括号中给出,则对于该ASIL等级,相应的子章条应被认
为是推荐而非要求。这里的括号与ASIL等级分解无关。
5 启动软件层面产品开发
5.1 目的
本子章条的目的是计划并启动软件开发子阶段的功能安全活动。
5.2 总则
软件开发的启动是一项计划活动,即按照相关项开发的范围和复杂度确定并计划软件开发中各子
阶段及其支持过程(参见GB/T 34590.8-2017和GB/T 34590.9-2017)。通过确定适当的方法,启动
软件开发各子阶段和支持过程,以满足要求及其相应的ASIL等级。这些方法得到指南和工具的支持,
这些指南和工具是为每个子阶段和支持过程而确定和计划的。
注1:用于软件开发的工具可包括其他非软件工具。
示例:用于测试阶段的工具。
软件开发计划包括协调系统层面(参见GB/T 34590.4-2017)和硬件层面(参见GB/T 34590.5-
2017)的产品开发。
注2:附录A中表A.1提供了对软件层面产品开发特定子阶段的目的、前提条件和工作成果的概览。
5.3 本章的输入
5.3.1 前提条件
应具备下列信息:
---项目计划(细化的),按照GB/T 34590.4-2017的5.5.1;
---安全计划(细化的),按照GB/T 34590.4-2017的5.5.2;
---技术安全概念,按照GB/T 34590.4-2017的7.5.1;
---系统设计规范,按照GB/T 34590.4-2017的7.5.2;及
---相关项集成和测试计划(细化的),按照GB/T 34590.4-2017的8.5.1。
5.3.2 支持信息
可考虑下列信息:
---经鉴定合格的软件工具(参见GB/T 34590.8-2017第11章);
---可用的经鉴定合格的软件组件(参见GB/T 34590.8-2017第12章);
---用于建模语言和编程语言的设计和编码指南(来自外部);
---方法应用的指南(来自外部);及
---工具应用的指南(来自外部)。
5.4 要求和建议
5.4.1 应对软件层面产品开发的活动和适当方法的确定进行计划。
5.4.2 应按照GB/T 34590.2-2017的6.4.5,并基于图2给出的参考阶段模型,为软件层面产品开发进
行生命周期的剪裁。
5.4.3 如果开发可配置软件,应按照附录C。
5.4.4 包括生命周期阶段、方法、语言和工具在内的相关项软件开发流程,应在软件生命周期的所有子阶段保持一致,并与系统和硬件开发阶段兼容,由此,所需的数据可被正确的转化。
注:相关项软件的各阶段、任务和活动(包括迭代步骤)的顺序,用于确保软件相关工作成果与硬件层面产品开发(参见GB/T 34590.5-2017)及系统层面产品开发(参见GB/T 34590.4-2017)保持一致。
注:图中GB/T 34590-2017每部分的特定章用以下方式标示:“m-n”,“m”代表部分号,“n”代表章号,例如“4-7”代表GB/T 34590.4-2017第7章。
5.4.5 应为软件开发的每个子阶段进行如下选择,包括其应用的指南:
a) 方法;及
b) 相应的工具。
5.4.6 当选择一种合适的建模语言或编程语言时,应考虑准则:
a) 无歧义的定义;
示例:语言的语法和语义。
b) 为嵌入式实时软件和运行时错误处理提供的支持;及
c) 为模块化、抽象化和结构化的构建提供的支持。
对于通过语言本身不能充分说明的准则应由相应的指南或开发环境来覆盖。
注1:所选择的编程语言(如ADA、C、C++、Java、汇编或图形化的建模语言)支持5.4.7中给出的通则。可应用编程指南或建模指南以满足这些通则。
注2:汇编语言可用于那些不适合使用高级语言的软件部分,如与硬件接口的底层软件、中断处理程序、或对时间敏感的算法。
5.4.7 为了支持设计和实现的正确性,建模语言或编程语言的设计和编码指南应按照表1所列出的
通则。
注1:对不同的编程语言,编码指南通常是不同的。
注2:对基于模型的开发,编码指南可以是不同的。附录B描述了基于模型的开发的概念。
注3:对特定相关项的开发,可对现有编码指南进行修改。
示例:MISRAC[3]和 MISRAACAGC[4]是C语言的编码指南。
5.5 工作成果
5.5.1 安全计划(细化的),由5.4.1~5.4.7的要求得出。
5.5.2 软件验证计划,由5.4.1~5.4.5和5.4.7的要求得出。
5.5.3 模型语言和编程语言的设计和编码指南,由5.4.6和5.4.7的要求得出。
5.5.4 工具应用指南,由5.4.5和5.4.6的要求得出。
6 软件安全要求的定义
6.1 目的
该子阶段的第一个目的是定义软件安全要求。软件安全要求来源于技术安全概念和系统设计
规范。
第二个目的是对GB/T 34590.4-2017第7章建立的软硬件接口要求进行细化。
第三个目的是验证软件安全要求和软硬件接口要求与技术安全概念和系统设计规范的一致性。
6.2 总则
应在GB/T 34590.4-2017第7章定义的系统设计阶段中将技术安全要求细化并分配给硬件和软
件。软件安全要求的定义考虑硬件约束及其对软件的影响。该子阶段包括软件安全要求的定义,以支
持后续设计阶段。
6.3 本章的输入
6.3.1 前提条件
应具备下列信息:
---技术安全概念,按照GB/T 34590.4-2017的7.5.1;
---系统设计规范,按照GB/T 34590.4-2017的7.5.2;
---软硬件接口规范,按照GB/T 34590.4-2017的7.5.3;
---安全计划(细化的),按照5.5.1;
---软件验证计划,按照5.5.2。
6.3.2 支持信息
可考虑下列信息:
---硬件设计规范(参见GB/T 34590.5-2017的7.5.1);
---方法应用指南(来自外部)。
6.4 要求和建议
6.4.1 软件安全要求应针对每个基于软件的功能,这些功能的失效可能导致违背分配到软件的技术安
全要求。
示例:失效可能导致违背安全要求的功能可以是:
---使系统达到或维持安全状态的功能;
---与安全相关硬件要素的故障探测、指示和处理相关的功能;
---与软件自身故障的探测、通知和减轻相关的功能;
注1:这些功能包括操作系统中软件的自身监控及应用层特定的软件自身监控,以探测、指示和处理应用软件中的系统性故障。
---与车载测试和非车载测试相关功能;
注2:车载测试可以在车辆运行过程、预运行阶段和运行后阶段内,由系统自身或通过车载网络内的其他系统执行。
注3:非车载测试参照生产或服务阶段对安全相关的功能或属性的测试。
---允许在生产和服务过程中对软件进行修改的功能;及
---与性能或对时间敏感的运行相关的功能。
6.4.2 软件安全要求的定义应由符合GB/T 34590.4-2017中7.4.1和7.4.5的技术安全概念和系统设
计得出,并应考虑:
a) 安全要求的定义和管理,按照GB/T 34590.8-2017第6章;
b) 已定义的系统和硬件的配置;
示例1:配置参数可包括增益控制、带通频率和时钟分频。
c) 软硬件接口规范;
d) 硬件设计规范的相关要求;
e) 时间约束;
示例2:由系统层面要求的响应时间得出执行或反应时间。
f) 外部接口;及
示例3:通讯和用户接口。
g) 对软件有影响的车辆、系统或者硬件的每个运行模式。
示例4:硬件装置的运行模式可包括默认模式、初始化模式、测试模式和高级模式。
6.4.3 如果对软件安全要求进行了ASIL分解,应满足GB/T 34590.9-2017第5章的要求。
6.4.4 在GB/T 34590.4-2017第7章初步定义的软硬件接口规范,应细化到可以正确控制和使用硬
件的程度,并应描述硬件和软件间每个与安全相关的依赖性。
6.4.5 除与6.4.1定义的安全要求相关的功能外,如果嵌入式软件执行了其他功能,则应对这些功能进
行定义,或参考其规范。
6.4.6 应按照GB/T 34590.8-2017第9章,计划对软件安全要求和细化的软硬件接口规范的验证。
6.4.7 应由负责系统开发、硬件开发和软件开发的人员共同验证细化的软硬件接口规范。
6.4.8 应按照GB/T 34590.8-2017第6章和第9章,对软件安全要求和细化的软硬件接口要求进行
验证,以展示它们:
a) 与技术安全要求的符合性和一致性;
b) 与系统设计的符合性;及
c) 与软硬件接口的一致性。
6.5 工作成果
6.5.1 软件安全需求规范,由6.4.1~6.4.3和6.4.5的要求得出。
6.5.2 软硬件接口规范(细化的),由6.4.4的要求得出。
注:该工作成果参照GB/T 34590.5-2017中6.5.2相同的工作成果。
6.5.3 软件验证计划(细化的),由6.4.6的要求得出。
6.5.4 软件验证报告,由6.4.7和6.4.8的要求得出。
7 软件架构设计
7.1 目的
该子阶段的第一个目的是开发实现软件安全要求的软件架构设计。
该子阶段的第二个目的是验证软件架构设计。
7.2 总则
软件架构设计描述全部软件组件及其在层次结构中的交互。静态方面,如所有软件组件间的接口
和数据路径;动态方面,如进程顺序和时序行为,都得到描述。
注:软件架构设计不必局限于某个微控制器或电控单元,它关系到技术安全概念和系统设计。每个微控制器的软件架构也在本章讨论。
为开发既实现软件安全要求又实现非安全要求的软件架构设计,在此子阶段,安全和非安全性要求
应在同一开发过程中处理。
软件架构设计提供了实施软件安全要求和管理软件开发复杂性的方法。
7.3 本章的输入
7.3.1 前提条件
应具备下列信息:
---安全计划(细化的),按照5.5.1;
---用于建模及编程语言的设计和编码指南,按照5.5.3;
---软硬件接口规范,按照GB/T 34590.4-2017的7.5.3;
---软件安全需求规范,按照6.5.1;
---软件验证计划(细化的),按照6.5.3;及
---软件验证报告,按照6.5.4。
7.3.2 支持信息
可考虑下列信息:
---技术安全概念(参见GB/T 34590.4-2017的7.5.1);
---系统设计规范(参见GB/T 34590.4-2017的7.5.2);
---可用的经鉴定合格的软件组件(见GB/T 34590.8-2017第12章);
---工具应用指南,按照5.5.4;及
---应用方法指南(来自外部)。
7.4 要求和建议
7.4.1 为确保软件架构设计获取必要信息以允许后续开发活动得到正确且有效的执行,应使用表2中
列出的软件架构设计的标记法,对软件架构设计进行恰当抽象层级的描述。
7.4.2 在软件架构设计开发中应考虑下述方面:
a) 软件架构设计的可验证性;
注:这表明软件架构设计和软件安全要求之间的双向可追溯性。
b) 可配置软件的适用性;
c) 软件单元设计和实现的可行性;
d) 软件集成测试中,软件架构的可测性;及
e) 软件架构设计的可维护性。
7.4.3 为避免因高度复杂性导致的失效,应通过使用表3列出的原则,使软件架构设计具有以下属性:
a) 模块化;
b) 封装性;及
c) 简单性。
7.4.4 软件架构设计应被开发到能够识别出所有软件单元的程度。
7.4.5 软件架构设计应描述:
a) 软件组件的静态设计方面;及
注1:静态设计方面涉及:
---包括分级层次的软件结构;
---数据处理的逻辑顺序;
---数据类型和它们的特征参数;
---软件组件的外部接口;
---软件的外部接口;及
---包括架构的范围和外部依赖的约束。
注2:在基于模型开发的情况下,结构建模是整个建模活动的固有部分。
b) 软件组件的动态设计方面。
注1:动态设计方面涉及:
---功能性和行为;
---控制流和并发进程;
---软件组件间的数据流;
---对外接口的数据流;及
---时间的限制。
注2:为确定动态行为(如任务、时间片和中断),需要考虑不同的运行状态(如开机、关机、正常运行、标定和诊断)。
注3:为描述(如任务、时间片和中断的)动态行为,需要定义通讯关系及其在系统硬件(如CPU和通讯通道)上的分配。
7.4.6 每个与安全相关的软件组件应被归类为下述之一:
a) 新开发的;
b) 有修改的复用;或
c) 未经修改的复用。
7.4.7 新开发的或修改后使用的安全相关软件组件应按照GB/T 34590来开发。
注:在这些情况下,不适用GB/T 34590.8-2017第12章。
7.4.8 对未经修改而复用的安全相关软件组件应按照GB/T 34590.8-2017第12章进行鉴定。
注:使用经鉴定合格的软件组件不影响第10章和第11章的适用性。然而,第8章和第9章描述的某些活动可以被省略。
7.4.9 应将软件安全要求分配给软件组件。因此,每个软件组件应按照分配给它的要求中最高的
ASIL等级来进行开发。
注:根据这一分配,进一步细化软件安全要求可能是必要的。
7.4.10 如果嵌入式软件不得不实现不同ASIL等级的软件组件,或实现安全相关及非安全相关的软件
组件,除非软件组件符合GB/T 34590.9-2017第6章定义的共存准则,否则全部嵌入式软件应按照最
高ASIL等级来处理。
7.4.11 如果用软件分区(参见附录D)实现软件组件间免于干扰,则应确保:
a) 共享资源的使用方式应确保软件分区免于干扰;
注1:一个软件分区内的任务彼此之间不能免于干扰。
注2:一个软件分区不能改变其他软件分区的代码或数据,也不能控制其他软件分区的非共享资源。
注3:一个软件分区从共享资源获取的服务不能被另一个软件分区影响。这包括相关资源的性能,以及对资源调度访问的使用率、延迟、抖动和持续时间。
b) 由专用的硬件功能或等效方法来支持软件分区(该要求适用于ASILD,按照4.3);
c) 实现软件分区的软件部分,按照分配给软件分区要求的相同ASIL等级进行开发,或按照比分
配给软件分区要求的最高ASIL等级更高的一个ASIL等级进行开发;
注:一般来说操作系统提供或支持软件分区。
d) 在软件集成和测试(按照第10章)过程中执行软件分区的验证。
7.4.12 如果软件安全要求的执行依赖于软件组件间免于干扰或足够的独立性,则应按照
GB/T 34590.9-2017第7章进行相关失效的分析。
7.4.13 应按照GB/T 34590.9-2017第8章在软件架构层面执行安全分析,目的是:
---识别或确认软件的安全相关部分;及
---支持安全机制的定义和验证其有效性。
注:安全机制可被定义为同时覆盖随机硬件失效和软件故障的有关问题。
7.4.14 为了在软件架构层面定义必要的软件安全机制,应基于符合7.4.13的安全分析结果,使用表4
列出的错误探测机制。
注:当分配给软件的技术安全要求没有对软件安全机制的使用进行直接要求时,则应在系统层面对软件安全机制的使用进行评审,以分析对系统行为的潜在影响。
7.4.15 此子章条适用于等级为ASIL(A)、(B)、C和D的安全目标,按照4.3:基于符合7.4.13的安全
分析结果,为了在软件架构层面定义必需的软件安全机制,应使用表5列出的错误处理机制。
注1:当分配给软件的技术安全要求没有直接要求时,则在系统层面对软件安全机制的使用进行评审,以分析对系统行为的潜在影响。
注2:在GB/T 34590.5-2017中描述了由于硬件导致的在软件架构层面的潜在危害的分析。
7.4.16 如果软件架构设计所引入的新的危害没有被现有的安全目标覆盖,应按照GB/T 34590.8-
2017第8章所述的变更管理流程在危害分析和风险评估中对它们进行介绍和评估。
注:未体现在安全目标中的新识别危害,通常是非功能性危害。如果这些非功能性危害超出了本标准的范畴,则建议在危害分析和风险评估中用以下声明“因不属于GB/T 34590的范畴,而未对该危害分配ASIL”来标注它们,
然而,为了参考,允许对其分配一个ASIL等级。
7.4.17 应该对嵌入式软件所需资源进行上限预估,包括:
a) 执行时间;
b) 存储空间;及
示例:用于存储堆和栈的RAM,用于存储程序和非易失性数据的ROM。
c) 通讯资源。
7.4.18 软件架构设计应按照GB/T 34590.8-2017第9章来进行验证,并使用表6中所列出的软件架
构验证方法来论证下述属性:
a) 与软件安全要求的符合性;
b) 与目标硬件的兼容性;及
注:这包括在7.4.17中定义的资源。
c) 与设计指南保持一致。
7.5 工作成果
7.5.1 软件架构设计规范,由7.4.1~7.4.6、7.4.9、7.4.10、7.4.14、7.4.15和7.4.17的要求得出。
7.5.2 安全计划(细化的),由7.4.7的要求得出。
7.5.3 软件安全需求规范(细化的),由7.4.9的要求得出。
7.5.4 安全分析报告,由7.4.13的要求得出。
7.5.5 相关失效分析报告,由7.4.12的要求得出。
7.5.6 软件验证报告(细化的),由7.4.18的要求得出。
8 软件单元设计和实现
8.1 目的
本子阶段的第一个目的是按照软件架构设计和相关的软件安全要求,定义软件单元。
本子阶段的第二个目的是按照定义,实现软件单元。
本子阶段的第三个目的是静态验证软件单元的设计及其实现。
8.2 总则
基于软件架构设计,开发软件单元的详细设计。详细设计将分别按照建模或编码指南,以模型或直
接以源代码的形式实现。在进入到软件单元测试阶段前,对详细设计和实现进行静态验证。如果使用
手工开发代码,在源代码层面具备与实现相关的特性。如果使用基于模型开发的自动生成代码,这些特
性用于模型而不需要用于源代码。
为了将软件安全要求和非安全相关要求同时实施到同一软件单元设计中,本子阶段用一个开发过
程处理安全相关和非安全相关要求。
软件单元的实现包含源代码生成和转换为目标代码。
8.3 本章的输入
8.3.1 前提条件
应具备下列信息:
---建模和编程语言的设计及编码指南,按照5.5.3;
---软件验证计划(细化的),按照6.5.3;
---软件架构设计规范,按照7.5.1;
---安全计划(细化的),按照7.5.2;
---软件安全需求规范(细化的),按照7.5.3;及
---软件验证报告(细化的),按照7.5.6。
8.3.2 支持信息
可考虑下列信息:
---技术安全概念(参见GB/T 34590.4-2017的7.5.1);
---系统设计规范(参见GB/T 34590.4-2017的7.5.2);
---工具应用指南,按照5.5.4;
---软硬件接口规范(细化的)(参见6.5.2);
---安全分析报告,按照7.5.4;及
---方法应用指南(来自外部)。
8.4 要求和建议
8.4.1 如果软件单元是安全相关的,应符合此子阶段中的要求。
注:“安全相关”是指单元实现了安全要求,或此单元不满足与其他单元的共存原则(参见GB/T 34590.9-2017第6章)。
8.4.2 为确保软件单元设计获得必要的信息以允许后续开发活动得到正确和有效的执行,应使用表7
中列出的标记法描述软件单元设计。
注:在应用自动代码生成的基于模型开发的情况下,将软件单元设计的表示方法,用于作为代码生成基础的模型中。
8.4.3 软件单元的定义应将功能表现和内部设计描述到必要的细节程度以支持其实现。
示例:内部设计可包含对寄存器使用和数据存储的限制。
8.4.4 应运用表8列出的源代码层面软件单元设计和实现的设计原则,以具有如下特性:
a) 基于软件架构设计,软件单元内的子程序和函数执行的正确次序;
b) 软件单元间接口的一致性;
c) 软件单元内和软件单元间的数据流及控制流的正确性;
d) 简单性;
e) 可读性和可理解性;
f) 鲁棒性;
示例:避免不合理值、执行错误、以零做除数、数据流及控制流错误的方法。
g) 软件修改的适宜性。
8.4.5 应按照GB/T 34590.8-2017第9章,并用表9列出的验证方法,对软件单元设计和实现进行验
证,以证明:
a) 对软硬件接口规范的符合性(按照GB/T 34590.5-2017的6.4.10);
b) 通过追溯性表明满足了分配给软件单元的软件安全要求(按照7.4.9);
c) 源代码与其设计规范的一致性;
注:对基于模型开发的情况,要求c)仍然适用。
d) 源代码与其编码指南的一致性(参见5.5.3);及
e) 软件单元的实现与目标硬件的兼容性。
注:表9仅列出了静态验证技术。动态验证技术(例如,测试技术)在表10、表11和表12中给出。
8.5 工作成果
8.5.1 软件单元设计规范,由8.4.2~8.4.4的要求得出。
注:在基于模型开发的情况下,运用表8所列技术实现的模型和支持说明文档,定义软件单元。
8.5.2 软件单元实现,由8.4.4的要求得出。
8.5.3 软件验证报告(细化的),由8.4.5的要求得出。
9 软件单元测试
9.1 目的
这个子阶段的目的是要证明,软件单元满足软件单元设计规范,且不包含非期望的功能。
9.2 总则
根据软件单元设计规范,建立软件单元测试流程,并按照该流程执行测试。
9.3 本章的输入
9.3.1 前提条件
应具备下列信息:
---软硬件接口规范(细化的),按照6.5.2;
---软件验证计划(细化的),按照6.5.3;
---安全计划(细化的),按照7.5.2;
---软件单元设计规范,按照8.5.1;
---软件单元实现,按照8.5.2;及
---软件验证报告(细化的),按照8.5.3。
9.3.2 支持信息
可考虑下列信息:
---工具应用指南,按照5.5.4;及
---方法应用指南(来自外部)。
9.4 要求和建议
9.4.1 如果软件单元是与安全相关的,则应符合本子章条的要求。
注:“安全相关”是指单元实现安全要求,或此单元不满足与其他单元的共存原则。
9.4.2 应按照GB/T 34590.8-2017第9章,计划、定义和执行软件单元测试。
注1:基于GB/T 34590.8-2017第9章的定义,软件单元测试的对象是软件单元。
注2:基于模型的软件开发,实现模型的相应部分也代表了测试计划的对象。根据选定的软件开发过程,测试对象可以是由模型产生的代码或该模型本身。
9.4.3 应使用表10中列出的软件单元测试方法,证明软件单元达到:
a) 符合软件单元的设计规范(按照第8章);
b) 符合软硬件接口的定义(按照GB/T 34590.5-2017的6.4.10);
c) 已定义的功能;
d) 确信没有非预期的功能;
e) 鲁棒性;及
示例:不存在不能访问的软件、错误检测的有效性和错误处理机制的有效性。
f) 足够的资源来支持它们的功能。
9.4.4 应使用表11列出的方法得到测试用例,以恰当定义符合9.4.3的软件单元测试的测试用例。
9.4.5 为了评估测试用例的完整性并证明没有非预期的功能,应确定在软件单元层面的要求覆盖率,
同时应按照表12列出的度量对结构覆盖率进行测定。如果认为已实现的结构覆盖率不充分,应定义额
外的测试用例或提供接受理由。
示例1:结构覆盖率分析可以显示基于需求的测试用例的不足、要求的缺陷、无作用码、无效代码或非预期的功能。
示例2:基于可接受的无作用码(例如:用于调试的代码)或不同软件配置的代码区段可以给出接受所达到的覆盖率水平的理由;或可以使用补充方法(例如:检查)验证未被覆盖的代码。
注1:通过使用适当的软件工具可以确定结构覆盖率。
注2:在基于模型开发的情况下,结构覆盖率分析可以利用相似的模型结构覆盖率度量在模型层面进行。
注3:如果“检测代码”用于确定覆盖率水平,证明检测对测试结果没有影响可能是必要的,这可以通过使用“非检测代码”重复测试实现。
9.4.6 对于软件单元测试的测试环境,应尽可能地接近目标环境。如果软件单元测试不是在目标环境
下执行,应分析源代码和目标代码的差异及测试环境和目标环境之间的差异,以便在后续测试阶段的目
标环境中,定义额外的测试。
注1:测试环境和目标环境之间的差异,可出现在源代码或目标代码中,例如,由于不同处理器的数据字和地址字的不同位宽引起的差异。
注2:根据测试范围,使用适当的测试环境(例如目标处理器、处理器仿真器或开发系统)执行软件单元测试。
注3:软件单元测试可以在不同的环境中执行,例如:
---模型在环测试;
---软件在环测试;
---处理器在环测试;及
---硬件在环测试。
注4:对基于模型的开发,在模型层面执行软件单元测试,随后,在模型和目标代码之间进行背靠背的比较测试。背靠背的比较测试用于确保关于测试对象的模型表现等同于自动生成的代码。
9.5 工作成果
9.5.1 软件验证计划(细化的),由9.4.2~9.4.6的要求得出。
9.5.2 软件验证规范,由9.4.2和9.4.4~9.4.6的要求得出。
9.5.3 软件验证报告(细化的),由9.4.2的要求得出。
10 软件集成和测试
10.1 目的
此子阶段的第一个目的是集成软件要素。
此子阶段的第二个目的是证明软件架构设计已被嵌入式软件实现。
10.2 总则
在此子阶段,按照软件架构设计,对软件要素之间特有的集成层次和接口进行测试。软件要素的集
成和测试的步骤直接对应着软件的分层架构。
嵌入式软件由安全相关和安全无关的软件要素组成。
10.3 本章的输入
10.3.1 前提条件
应具备以下信息:
---软硬件接口规范(细化的),按照6.5.2;
---软件架构设计规范,按照7.5.1;
---安全计划(细化的),按照7.5.2;
---软件单元实现,按照8.5.2;
---软件验证计划(细化的),按照9.5.1
---软件验证规范,按照9.5.2;及
---软件验证报告(细化的),按照9.5.3。
10.3.2 支持信息
可考虑如下信息:
---经鉴定合格的软件组件,参见GB/T 34590.8-2017中第12章;
---软件工具鉴定报告,按照GB/T 34590.8-2017中11.5.2;
---工具应用指南,按照5.5.4;及
---方法应用指南(来自外部资源)。
10.4 要求和建议
10.4.1 软件集成的计划应描述将各个软件单元分层集成到软件组件中的步骤,直到整个嵌入式软件
全部被集成,并应考虑:
a) 与软件集成相关的功能依存关系;及
b) 软件集成和软硬件集成之间的依存关系。
注:对基于模型的开发,软件集成可被模型层面的集成和后续由集成的模型生成自动代码来代替。
10.4.2 应按照GB/T 34590.8-2017第9章来计划、定义并执行软件集成测试。
注1:基于GB/T 34590.8-2017第9章中的定义,软件集成测试的对象是软件组件。
注2:对基于模型的开发,测试对象可以是与软件组件相关的模型。
10.4.3 应使用表13列举的软件集成测试方法以证明软件组件和嵌入式软件均实现:
a) 与软件架构设计的符合性,按照第7章;
b) 与软硬件接口规范的符合性,按照GB/T 34590.4-2017第7章;
c) 已定义的功能性;
d) 鲁棒性;及
示例:不存在无法访问的软件;具备有效的错误检测和处理。
e) 支持功能的足够资源。
10.4.4 为了能够给软件集成测试方法(按照10.4.3选择的)定义恰当的测试用例,应使用表14所列的
方法。
10.4.5 为了评估测试的完整性并确信没有非预期的功能,应确定测试用例在软件架构层面对要求的
覆盖率。如果必要,应指定附加的测试用例或者提供理由。
10.4.6 按照4.3,该子章条适用于ASIL(A)、(B)、C和D等级:为了评估测试用例的完整性并确信没
有非预期的功能,应按照表15列出的度量对结构覆盖率进行测定。如果认为结构覆盖率不充分,应定
义额外的测试用例或提供可接受的理由。
示例:结构覆盖率分析可以显示基于需求的测试用例的不足、要求的缺陷、无作用码、无效代码或非预期的功能。
10.4.7 应验证作为生产发布(按照GB/T 34590.4-2017第11章)一部分的嵌入式软件包含了全部已
定义的函数,且仅包含不损害软件安全要求符合性的未定义函数。
示例:未定义的函数包括用于调试或检测的代码。
注:如果可确保这些未定义的函数不被执行,这是一种符合要求的可接受的方法。否则就要参见GB/T 34590.8-2017第8章做变更将这些代码移除。
10.4.8 软件集成测试的测试环境应尽可能接近目标环境。如果集成测试没有在目标环境中执行,应
分析源代码和目标代码之间的差异以及测试环境和目标环境之间的差异,来定义后续测试阶段中在目
标环境中的附加测试。
注1:测试环境与目标环境之间的差异可出现在源代码或目标代码中,例如,由于不同处理器的数据字和地址字的不同位宽引起的差异。
注2:根据测试范围和集成的层级,使用适当的测试环境进行软件要素测试。这些测试环境可以是用于最终集成的目标处理器,或者是用于之前集成步骤的处理器模拟器或开发系统。
注3:软件集成测试可在不同环境中执行,例如:
---模型在环测试;
---软件在环测试;
---处理器在环测试;及
---硬件在环测试。
10.5 工作成果
10.5.1 软件验证计划(细化的),由10.4.1~10.4.6和10.4.8的要求得出。
10.5.2 软件验证规范(细化的),由10.4.1、10.4.2、10.4.4、10.4.5、10.4.7和10.4.8的要求得出。
10.5.3 嵌入式软件,由10.4.1的要求得出。
10.5.4 软件验证报告(细化的),由10.4.2的要求得出。
11 软件安全要求验证
11.1 目的
该子阶段的目的是证明嵌入式软件满足软件安全要求。
11.2 总则
软件安全要求验证的目的是证明嵌入式软件在目标环境下满足软件安全要求。
11.3 本章的输入
11.3.1 前提条件
应具备下列信息:
---软件架构设计规范,按照7.5.1;
---安全计划(细化的),按照7.5.2;
---软件安全需求规范(细化的),按照7.5.3;
---软件验证计划(细化的),按照10.5.1;
---软件验证规范(细化的),按照10.5.2;
---软件验证报告(细化的),按照10.5.4;及
---集成测试报告,按照GB/T 34590-2017的8.5.3。
11.3.2 支持信息
可考虑下列信息:
---验证计划(细化的)(参见GB/T 34590.4-2017的6.5.3);
---技术安全概念(参见GB/T 34590.4-2017的7.5.1);
---系统设计规范(参见GB/T 34590.4-2017的7.5.2);
---工具应用指南,按照5.5.4;及
---方法应用指南(来自外部)。
11.4 要求和建议
11.4.1 应按照GB/T 34590.8-2017第9章,计划、定义和执行软件安全要求的验证。
11.4.2 为验证嵌入式软件是否满足软件安全要求,应在表16所列的测试环境中执行测试。
注:可以复用已有的测试用例,如来自软件集成测试的测试用例。
11.4.3 应在目标硬件上执行对软件安全要求实现的测试。
11.4.4 软件安全要求验证结果的评估应考虑:
a) 与期望结果的一致性;
b) 软件安全要求的覆盖率;及
c) 通过或不通过的准则。
11.5 工作成果
11.5.1 软件验证计划(细化的),由11.4.1~11.4.3的要求得出。
11.5.2 软件验证规范(细化的),由11.4.1~11.4.3的要求得出。
11.5.3 软件验证报告(细化的),由11.4.1~11.4.3的要求得出。
附 录 A
(资料性附录)
产品开发软件层面管理的概览和工作流程
表A.1提供了产品开发软件层面特定阶段的目的、前提条件和工作成果的概览。
附 录 B
(资料性附录)
基于模型的开发
B.1 目的
本附录描述了基于模型的车载软件开发概念,概述了其对软件层面产品开发的影响。
B.2 总则
数学建模,已被广泛的应用于许多工程领域,也正逐步在嵌入式软件开发中得到普遍使用。在汽车
领域,建模既用于待实现功能(开、闭环控制,监控)的概念捕获中,也用于真实物理系统行为(车辆环境)
的仿真中。
建模通常使用商业现成的建模和仿真软件工具。这些软件工具通过半形式的图形化模型来支持系
统、软件要素以及它们之间的连接和接口的开发与定义。这些模型采用可编辑的、层级化框图(例如控制图)以及扩展的状态转换框图(例如状态图)。软件工具提供必要的描述方法、运算技术和解释器/编译器。图形编辑器使复杂模型的直观开发和描述成为可能。使用层级结构的模块化来控制复杂度。模型由明确定义了输入与输出的功能块组成。这些功能块在框图中通过它们接口之间的定向边连接起来,这些定向连接描述了信号流。由此,它们表征了数学模型中的方程式,即将不同要素的接口变量联系起来。连接线代表了有因果动机的行动方向,定义了一个模块的输出是另一个的输入。其他工具特有的建模语言也可用来理出执行顺序和定时。要素的层级可以包含数个细化级别。
这些模型可以被仿真,例如执行。在仿真过程中,计算遵循已定义的执行方向,直到整个模型都被
处理完。有许多不同的求解器可用于求解由模型描述的方程。变步长求解器主要用于对车辆和环境建模。对于嵌入式软件的开发,使用的是定步长求解器,它代表了高效代码生成的一个必要的先决条件。
所描述的建模风格在基于模型开发的嵌入式车载软件中得到了广泛应用。典型的,在开发周期的
早期,创建控制软件(例如功能模型)的可执行模型和周边系统的模型(例如整车模型)及环境的模型(例
如环境模型),并一起进行仿真。这样,能在可接受的计算速度下对高复杂性的汽车系统以高细节度进
行建模,并对其行为进行近乎实际的仿真。当整车/环境模型在开发过程中逐步被真实系统及其真实环
境所替代,通过代码生成,功能模型可作为在控制单元上实现嵌入式软件的蓝本。
基于模型开发模式的一个特征在于功能模型不仅详述了所想要的功能,而且还提供了设计信息,并
最终作为代码生成方法的实施基础。换言之,这样的一个功能模型表征了规范方面以及设计和实现方
面。实际上,这些不同的方面反映了功能模型从早期规范模型经过设计模型直到实施模型并最后自动
转换成代码(模型的演变)的演变。与具备清晰阶段分隔的基于代码的软件开发相比,在基于模型开发
中,可注意到在“软件安全要求”,“软件架构设计”和“软件单元设计和实现”之间更强的阶段合并。此
外,在连续的开发阶段中,可使用一种一致的图形建模标记法。验证活动也会变得不同,因为模型可以
作为测试过程(例如基于模型的测试)的有用信息来源,或者可以作为对象来验证。无缝地使用模型能
够促进高度一致、有效的开发。
注:基于模型开发的样式不局限于上述所提到的已有模型类型。可使用例如UML的其他模型。
附 录 C
(规范性附录)
软件配置
C.1 目的
软件配置的目的是使软件行为的变化可控,以进行不同的应用。
C.2 总述
可配置软件允许使用配置数据和标定数据开发特定应用的软件(参见图C.1)。
C.3 本章输入
C.3.1 前提条件
前提条件依照应用软件配置的相关阶段。
C.3.2 支持信息
参见应用软件配置的相关阶段中的适用的支持信息。
C.4 要求和建议
C.4.1 为确保在安全生命周期中可配置软件的正确使用,应对配置数据进行定义,包含以下内容:
a) 配置数据的有效值;
b) 配置数据的目的和用法;
c) 范围、比例、单位;
d)配置数据不同要素之间的相互依赖。
C.4.2 应验证配置数据以确保:
a) 使用的值在其规定的范围内;
b) 与其他配置数据的兼容性。
注:在软件生命周期的测试阶段[参见第9章(软件单元测试)、第10章(软件集成和测试)、第11章(软件安全要求验证)和 GB/T 34590.4-2017第8章(相关项集成和测试)]测试已配置的软件。
C.4.3 配置数据的ASIL等级应等于使用该数据的可配置软件的最高ASIL等级。
C.4.4 应根据GB/T 34590.8-2017第9章计划、定义、执行可配置软件的验证。可配置软件应结合所
考虑的相关项开发中使用的配置数据组进行验证。
注:只有其行为依赖于配置数据的那部分嵌入式软件要针对配置数据组进行验证。
C.4.5 对于可配置软件,可能使用图C.2或图C.3所示的简化的软件安全生命周期。
注:下列验证活动的组合可实现对已配置软件的完整验证:
a) 可配置软件的验证;
b) 配置数据的验证;
c) 已配置软件的验证。
组合的方式是下面之一:
---在a)中验证允许的配置数据的范围,并说明它符合在b)中的范围,或
---说明与b)中允许的配置数据范围的符合性并执行c)。
图C.2 可配置软件和不同配置数据的软件开发的参考模型的变型
图C.3 可配置软件和不同标定数据的软件开发的参考模型的变型
C.4.6 应定义与软件组件关联的标定数据以确保配置后软件的正确运行和预期性能,包含
a) 标定数据的有效值;
b) 标定数据的目的和用法;
c) 范围、比例和单位,以及它们对运行状态的依赖(如果适用);
d)不同标定数据之间已知的相互依赖;及
注:相互依赖可存在于同一标定数据组内的标定数据之间,或者不同标定数据组的标定数据之间,如:不同电子控制单元的软件中执行的应用于相关功能的标定数据。
e) 配置数据和标定数据之间的已知的相互依赖。
注:配置数据可对使用标定数据的已配置软件有影响。
C.4.7 应根据GB/T 34590.8-2017第9章计划、定义、执行标定数据的验证。标定数据的验证应检查
标定数据是否在其规定的边界范围内。
注:标定数据的验证,可在特定应用的软件验证时进行,或者在运行时由可配置软件验证。
C.4.8 标定数据的ASIL等级应等于其可能违反的软件安全要求的最高ASIL等级。
C.4.9 为探测安全相关的标定数据的非预期变化,应使用表C.1中所列的数据非预期变化的探测
机制。
......
|