[PDF] GB/T 34590.8-2017 - 自动发货. 英文版
| 标准号码 | 美元 | 购买PDF | 工期 | 标准名称(英文版) |
| GB/T 34590.8-2017 | 345 | GB/T 34590.8-2017 | 9秒内发货PDF | 道路车辆 功能安全 第8部分：支持过程 |
| 基本信息 | |
|---|---|
| 标准编号 | GB/T 34590.8-2017 (GB/T34590.8-2017) |
| 中文名称 | 道路车辆 功能安全 第8部分：支持过程 |
| 英文名称 | Road vehicles -- Functional safety -- Part 8: Supporting processes |
| 行业 | 国家标准 (推荐) |
| 中标分类 | T35 |
| 国际标准分类 | 43.040 |
| 字数估计 | 46,417 |
| 发布日期 | 2017-10-14 |
| 实施日期 | 2018-05-01 |
| 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 |
GB/T 34590.8-2017
道路车辆 功能安全 第8部分：支持过程
Road vehicles -- Functional safety -- Part 8: Supporting processes
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.3-2017 道路车辆 功能安全 第3部分:概念阶段(ISO 26262-3: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.6-2017 道路车辆 功能安全 第6部分:产品开发:软件层面(ISO 26262-6:2011,
MOD)
GB/T 34590.7-2017 道路车辆 功能安全 第7部分:生产和运行(ISO 26262-7: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中ASIL等级在括号中给出,则对于该ASIL等级,相应的子章条应被认为是推
荐而非要求。这里的括号与ASIL等级分解无关。
5 分布式开发的接口
5.1 目的
本章的目的是描述相关项和要素进行分布式开发的流程及相关责任的分配。
5.2 总则
相关项开发的客户(如:车辆制造者)和供应商共同遵守GB/T 34590-2017中定义的要求。客户
和供应商就责任达成一致。分包的关系是被允许的。在与分布式相关项开发供应商或负责相关项开发全部安全责任的供应商合作中,类似于客户对内部相关项开发的计划、执行和文档化的安全相关定义,相似的流程需要得到同意。
注1:本章不适用于采购的标准组件及元器件、或未对供应商分配任何安全责任的委托开发。
注2:附录A中表A.1提供了对支持过程的目的、前提条件和工作成果的概览。
5.3 本章的输入
5.3.1 前提条件
参见已计划并开展了分布式开发的安全生命周期相关阶段的适用前提条件。
5.3.2 支持信息
可考虑如下信息:
---开发接口协议(DIA)的草拟版本(来自外部);
---基于报价需求(RFQ)的供应商投标(来自外部)。
5.4 要求和建议
5.4.1 要求的应用
5.4.1.1 应将第5章的要求用于每个按照GB/T 34590-2017开发的相关项和要素,但适用下述之一
的商业现成硬件元器件除外:
a) 无特定硬件安全要求分配给硬件元器件;或
b) 按照基于全球质量标准(如:电子组件的AEC标准)的公认流程,鉴定商业现成硬件元器件,且
对商业现成硬件元器件的鉴定涵盖了预期应用的参数范围。
5.4.1.2 应将有关客户-供应商关系(接口和交互)的要求,用于客户-供应商关系的每个层面。
注1:这包含顶层供应商采取的分包、分包商采取的分包等。
注2:对内部供应商的管理可以采取与管理外部供应商相同的方法。
5.4.2 供应商选择准则
5.4.2.1 供应商选择准则应包含对供应商按照GB/T 34590-2017开发和生产同等复杂度和ASIL等
级的相关项及要素能力的评估。
注:供应商选择准则包含:
---供应商质量管理体系的证据;
---供应商以往的表现和质量;
---对供应商功能安全能力(作为投标的一部分)的确认;
---以往按照GB/T 34590.2-2017的6.4.9进行的安全评估结果;
---来自整车厂开发、生产、质量和物流部门(因其影响功能安全)的推荐。
5.4.2.2 客户给候选供应商的报价需求(RFQ)应包含:
a) 符合GB/T 34590的正式要求;
b) 相关项定义或要素的功能定义;及
c) 基于供应商报价对象的安全目标、功能安全要求或技术安全要求(如果已存在,需包含其相应
ASIL等级)。
注:如果在选择供应商时ASIL等级未知,则做保守的假设。
5.4.3 分布式开发的启动和计划
5.4.3.1 客户和供应商应定义开发接口协议,包含以下:
注:附录B给出了开发接口协议的示例。
a) 客户和供应商安全经理的任命;
b) 按照GB/T 34590.2-2017的6.4.5进行安全生命周期的联合剪裁;
c) 客户需开展的活动及流程和供应商需开展的活动及流程;
d) 需交换的信息和工作成果;
注1:这包括对需提供的文档达成一致,以完成客户及供应商的安全档案。
注2:交换的信息包括安全相关的特殊特性。
注3:在分布式开发的情况下,对所涉及开发方的活动所必须的工作成果的相关部分,可进行识别和交换。
e) 活动的责任方或责任人;
f) 目标值的沟通。这些目标值由系统层面的目标导出,再分配给相关方,目的是使这些相关方能
满足单点故障度量及潜伏故障度量的目标值,通过硬件架构度量的评估和因随机硬件失效导
致违背安全目标的评估(参见GB/T 34590.5-2017);及
g) 支持过程和工具,含接口,以确保客户和供应商间的兼容性。
5.4.3.2 如果供应商执行危害分析和风险评估,则危害分析和风险评估应提供给客户做验证。
5.4.3.3 相关项开发的责任方应按照GB/T 34590.3-2017制定功能安全概念。客户和供应商应就功
能安全要求达成一致。
5.4.4 分布式开发的执行
5.4.4.1 供应商应向客户报告每个可能增加不符合项目计划、安全计划、集成和测试计划(按照
GB/T 34590.4-2017)、软件验证计划(按照GB/T 34590.6-2017)或开发接口协议中其他条款的风险
的问题。
5.4.4.2 供应商应向客户报告在其责任范围内和其分包商责任范围内(如有)的开发活动中发生的每个
异常。
5.4.4.3 供应商应确定每个安全要求是否能得到满足。如果不能,应重新检查安全概念,同时如果必
要,应修改安全概念以生成需要满足的安全要求。
5.4.4.4 对相关项安全产生潜在影响的每个变更,或对证明满足GB/T 34590-2017的计划活动产生
潜在影响的每个变更,都应与支持影响分析(按照第8章)的另一方进行沟通。
5.4.4.5 在导出用于当前开发的安全要求时,按照GB/T 34590.2-2017的5.4.2.7,双方都宜考虑从之
前相似开发中获得的经验。
5.4.4.6 供应商应向客户的安全经理报告安全计划中制定的任务和重要阶段上取得的进展。供应商和
客户应就报告的形式和提交的日期达成一致。
示例:客户在周期性间隔或日程框架中定义的节点,对供应商编制发布的质量管理报告进行检查。
5.4.4.7 应就由哪一方(供应商或客户)按照GB/T 34590.4-2017执行安全确认达成一致。
注:如果由供应商执行集成和确认,对供应商所需的能力和资源达成一致是重要的,因为安全确认工作需要集成后的车辆(参见GB/T 34590.4-2017)。
5.4.4.8 按照4.3,此要求适用于ASILD等级。客户应被允许在任何恰当的时间、在供应商场所内开
展额外的功能安全审核。
5.4.5 在供应商场所的功能安全评估
5.4.5.1 按照4.3,此要求适用于ASIL(B)、C、D等级。当接近已定义的节点时,应执行一次或多次功
能安全评估,这些评估应包含相关项开发的每个阶段。针对相关项的复杂性及其安全目标的ASIL等
级,应以适当的详细程度开展功能安全评估,并按照GB/T 34590.2-2017的6.4.9执行功能安全评估。
5.4.5.2 按照4.3,此要求适用于ASILB等级。宜开展功能安全评估。
注:这可由客户、其他组织或供应商自己完成。
5.4.5.3 按照4.3,此要求适用于ASILC和D等级。应由客户、其授权的组织或人员在供应商场所开
展符合GB/T 34590.2-2017的6.4.9的功能安全评估。
注:这可由供应商自己完成。
5.4.5.4 按照4.3,此要求适用于ASIL(B)、C和D等级。客户和供应商应有功能安全评估报告。
5.4.5.5 按照4.3,此要求适用于ASIL(B)、C和D等级。对识别出的每个潜在影响供应商交付物的异
常,应进行分析并得出解决它们的行动方案。双方应就由谁执行所要求的行动达成一致。
5.4.6 生产发布后
5.4.6.1 供应商应向客户提供证据,证明能具备并保持GB/T 34590.2-2017第7章和GB/T 34590.7-
2017第5章所要求的过程能力。
5.4.6.2 客户和供应商间的供应协议应依据GB/T 34590.2-2017的7.4.2.1明确功能安全责任,并应
定义各方的安全活动。
5.4.6.3 供应协议应规定各方间关于安全相关特殊特性的生产监控记录的访问和交换。
5.4.6.4 发现安全相关事件的各方应及时依照供应协议报告此事件。如果发生了安全相关事件,应对
事件开展分析。该分析宜包括类似相关项和受类似事件潜在影响的相关方。
5.5 工作成果
5.5.1 供应商选择报告,由5.4.2.1和5.4.2.2的要求得出。
5.5.2 开发接口协议(DIA),由5.4.3的要求得出。
5.5.3 供应商项目计划,由5.4.3的要求得出。
5.5.4 供应商安全计划,由5.4.3的要求得出。
5.5.5 功能安全评估报告,由5.4.5.1~5.4.5.5的要求得出。
5.5.6 供应协议,由5.4.6.2~5.4.6.3的要求得出。
6 安全要求的定义和管理
6.1 目的
第一个目的是确保正确的定义安全要求及其属性和特性。
第二个目的是确保在整个安全生命周期内对安全要求的一致管理。
6.2 总则
安全要求包含旨在达到并确保所要求的ASIL等级的全部要求。
在安全生命周期过程中,安全要求通过分层结构进行定义和细化。图2给出了GB/T 34590-2017
中用到的安全要求的结构和相依性。安全要求被分配给要素或在要素间分布。
注:图中GB/T 34590-2017每部分的特定章用以下方式标示:“m-n”,“m”代表部分号,“n”代表章号,例如“3-7”代表GB/T 34590.3-2017第7章。
安全要求的管理包括:管理要求、对要求达成一致、从要求的执行方取得承诺和保持追溯性。
为了支持对安全要求的管理,推荐使用合适的要求管理工具。
此章条包括对安全要求进行定义和管理的要求。
GB/T 34590.3-2017、GB/T 34590.4-2017、GB/T 34590.5-2017和GB/T 34590.6-2017列出了有
关安全要求内容在不同层面的特定要求。
6.3 本章的输入
6.3.1 前提条件
参见定义或管理安全要求的安全生命周期相关阶段的适用前提条件。
6.3.2 支持信息
参见已定义或管理安全要求的安全生命周期相关阶段的适用支持信息。
6.4 要求和建议
6.4.1 安全要求的定义
为了达到6.4.2.4所列安全要求的特性,应使用以下恰当的组合来定义安全要求:
a) 自然语言;及
b) 表1所列的方法。
注:对较高层面的安全要求(如:功能和技术安全要求),自然语言更合适;而对于较低层面的安全要求(如:软件和硬件安全要求),表1所列的标记法更合适。
6.4.2 安全要求的属性和特性
6.4.2.1 安全要求应能被明确的识别为安全要求。
注:为了符合该要求,可将安全要求列在一个单独的文件中。如果在同一文件中管理安全要求和其他要求,可通过使用6.4.2.5中给出的特殊属性而明确的识别出安全要求。
6.4.2.2 安全要求应继承将其导出的原安全要求的ASIL等级,但运用了按照GB/T 34590.9-2017的
ASIL分解除外。
注:因安全目标是顶层的安全要求,故 ASIL等级的继承始于安全目标层(参见 GB/T 34590.1-2017定义
2.108)。
6.4.2.3 应将安全要求分配给相关项或要素。
6.4.2.4 安全要求应具有如下特性:
a) 明确并可理解的;
注1:如果对要求的意思存在共同的理解,则要求是明确的。
注2:如果相邻抽象层面的读者(即:要求的利益相关者或要求的使用者)理解要求的意思,则要求是可理
解的。
b) 不可分割的;
注:当一个层面的安全要求在所考虑的层面上不能被分解为一个以上的安全要求,则这些要求是不可分
割的。
c) 内部的一致性;
注:不同于外部一致性(多个安全要求不互相抵触),内部一致性表示每个单独的安全要求不包含自相矛盾的内容。
d) 可行的;
注:如果某个要求在相关项的开发限制(资源、当前技术水平等)内可被实现,则其是可行的。
6.4.2.5 安全要求应具有如下属性:
a) 在整个安全生命周期中,具有唯一识别并保持不变;
示例:可通过不同的方法实现对要求的唯一识别,如对每个词“应”标注下脚标,例如:“系统应9782检查”;或者对含有词“应”的每个句子进行连续的编号,例如:“9782在情况下,系统应检查”。
b) 状态;及
示例:安全要求的状态可以是“建议的”“假设的”“接受的”或“经评审的”。
c) ASIL等级。
6.4.3 安全要求的管理
6.4.3.1 安全要求集应具有如下特性:
a) 分层结构;
注:如图2所示,分层结构是指安全要求是由几个连续层面构建而成的。这些层面与相应的设计阶段始终保持一致。
b) 依据恰当编组原则建立的有组织的结构;
注:安全要求的组织表示,通常依据架构将每个层面的安全要求组合在一起。
c) 完整性;
注:完整性表示一个层面的安全要求完整的实施了上一层面的全部安全要求。
d) 外部一致性;
注:不同于内部一致性,即每个单独的安全要求不包含与自身相矛盾的内容,外部一致性表示多个安全要求不互相矛盾。
e) 分层结构中任意一层的信息不重复;及
注:信息不重复表示安全要求的内容不重复出现在分层结构同一层面的其他安全要求中,并且在每个分层层面都得以实现。
f) 可维护性。
注:可维护性表示要求集可被修改或扩展,例如引入要求的新版本或增加/去掉要求集内的要求。
6.4.3.2 安全要求应是可追溯的,与以下内容相关联:
a) 安全要求在更高分层层面的每个来源;
b) 导出到更低分层层面的每个安全要求,或各安全要求在设计中的实现;及
c) 按照9.4.2的验证规范。
注:此外,可追溯性还支持:
---对特定安全要求进行更改时的影响分析;及
---功能安全评估。
6.4.3.3 应将表2所列验证方法的恰当组合用于验证安全要求是否符合本章的要求,及是否符合得出
安全要求的GB/T 34590-2017相关部分中关于验证安全要求的特定要求。
6.4.3.4 按照第7章,安全要求应置于配置管理下。
示例:当较低层面的安全要求与较高层面的安全要求相符合时,配置管理可定义一个基线作为安全生命周期后续阶段的基础。
6.5 工作成果
无。
7 配置管理
7.1 目的
第一个目的是确保工作成果及其产生的原理和一般条件,在任何时间以可控的方式可被唯一识别
和重生成。
第二个目的是确保可追溯较早版本和当前版本的关系及区别。
7.2 总则
配置管理是汽车工业中的成熟实践,可依据ISO/T S16949、ISO 10007和ISO/IEC 12207进行
应用。
配置管理对GB/T 34590的每个工作成果进行管理。
7.3 本章的输入
7.3.1 前提条件
应具备如下信息:
---安全计划,按照GB/T 34590.2-2017的6.5.1。
---在配置管理计划和管理的安全生命周期的相关阶段中适用的前提条件。
7.3.2 支持信息
无。
7.4 要求和建议
7.4.1 应计划配置管理。
7.4.2 配置管理过程应符合:
a) 质量管理体系(如ISO/T S16949或ISO 9001)的相关要求;及
b) 依照ISO/IEC 12207中配置管理章条的软件开发特定要求。
7.4.3 按照GB/T 34590.2-2017安全计划要求的工作成果,应置于配置管理下,并应依照配置管理策
略生成基线。
7.4.4 在配置管理计划中,应对置于配置管理下的工作成果进行文档化。
7.4.5 在整个安全生命周期中,应对配置管理进行维护。
7.5 工作成果
配置管理计划,由7.4.1、7.4.2和7.4.5的要求得出。
8 变更管理
8.1 目的
变更管理的目的是在整个安全生命周期中,分析和控制安全相关工作成果的变更。
8.2 总则
变更管理确保对变更进行系统性计划、控制、监测、实施和记录,同时确保工作成果的一致性。在进
行变更前,评估对功能安全的潜在影响。为此,引入并建立变更决策流程,并将责任分配给相关方。
注:此处,变更理解为因组件或元器件的异常、移除、增添、加强、报废等导致的修改。
8.3 本章的输入
8.3.1 前提条件
应具备如下信息:
---配置管理计划,按照7.5.1;
---安全计划,按照GB/T 34590.2-2017的6.5.2。
8.3.2 支持信息
无。
8.4 要求和建议
8.4.1 计划和启动变更管理
8.4.1.1 对工作成果进行变更前,应计划和启动变更管理流程。
注:配置管理和变更管理同时启动,定义并维护两个流程间的接口,以确保对变更的可追溯性。
8.4.1.2 识别出需符合变更管理的工作成果,并应包括GB/T 34590-2017要求的、需在配置管理下的
那些工作成果。
8.4.1.3 应为每个工作成果定义应用变更管理流程的日程表。
8.4.1.4 变更管理流程应包括:
a) 变更需求,按照8.4.2;
b) 变更需求分析,按照8.4.3;
c) 变更需求的决策和依据,按照8.4.4;
d) 已接受的变更的实施,按照8.4.5;及
e) 文档化,按照8.4.5。
8.4.2 变更需求
8.4.2.1 应为每个变更需求分配唯一的识别码。
8.4.2.2 每个变更需求应至少包含以下信息:
a) 日期;
b) 所需变更的理由;
c) 所需变更的准确描述;及
d) 所需变更基于的配置。
8.4.3 变更需求分析
8.4.3.1 对于每个变更需求,应针对以下信息,对所涉及的相关项、接口及关联相关项进行影响分析:
a) 变更需求的类型;
注:可能的变更类型有:解决错误、调整、加强、预防。
b) 对需更改的工作成果和受影响的工作成果进行的识别;
c) 在分布式开发的情况下,对受影响方的识别和引入;
d) 变更对功能安全的潜在影响;及
e) 变更的实现和验证的日程表。
8.4.3.2 对工作成果的每个变更,应重新启动安全生命周期的适当阶段,后续阶段的开展应符合
GB/T 34590-2017。
8.4.4 变更需求的评估
8.4.4.1 应使用依照8.4.3.1进行的影响分析的结果,对变更需求进行评估,并且应由授权人员决定是
否接受、拒绝或推迟变更。
示例:典型的授权的人员包括:
---项目经理;
---安全经理;
---负责质量保证的人员;及
---涉及的开发人员。
注:已接受的变更需求可按优先级排序,并与已接受的相关变更需求合并。
8.4.4.2 对于每个已接受的变更需求,应决定由谁来开展变更及变更的最晚时间。该决定应考虑开展
变更时涉及到的接口。
8.4.5 变更的开展和记录
8.4.5.1 应按计划开展和验证变更。
8.4.5.2 如果变更影响了安全相关功能,则应在发布相关项前,对按照GB/T 34590.2-2017的6.4.7
和6.4.9的功能安全评估和适用的确认评审进行更新。
8.4.5.3 变更的记录应包含以下信息:
a) 适度水平的变更工作成果清单,包括:配置和版本,按照第7章(配置管理);
b) 开展的变更细节;及
c) 变更部署的计划日期。
注:对被拒绝的变更需求,变更需求和拒绝的理由也需被记录。
8.5 工作成果
8.5.1 变更管理计划,由8.4.1.1~8.4.1.3的要求得出。
8.5.2 变更需求,由8.4.2的要求得出。
8.5.3 影响分析和变更需求计划,由8.4.3.1、8.4.4.1和8.4.4.2的要求得出。
8.5.4 变更报告,由8.4.5.3的要求得出。
9 验证
9.1 目的
验证的目的是确保工作成果符合它们相应的要求。
9.2 总则
验证适用于以下安全生命周期阶段:
a) 在概念阶段,验证确保了概念是正确的、完整的、并符合相关项的边界条件,同时确保了定义的
边界条件本身是正确的、完整的和一致的,以使概念可以得到实现。
b) 在产品开发阶段,以不同的方式执行验证,描述如下:
1) 在设计阶段,验证是对工作成果的评估,例如:需求规范、架构设计、模型或软件编码,从而
确保它们与之前建立的要求在正确性、完整性和一致性方面相符合。评估可通过评审、模
拟或分析技术开展,并以系统化方式计划、定义、执行和记录。
注:设计阶段是指GB/T 34590.4-2017第7章(系统设计)、GB/T 34590.5-2017第7章(硬件设计)、
GB/T 34590.6-2017第7章(软件架构设计)和GB/T 34590.6-2017第8章(软件单元设计和实现)。
2) 在测试阶段,验证是在测试环境下对工作成果的评估,以确保其满足要求。测试以系统化
的方式进行计划、定义、执行、评估和记录。
c) 在生产和运行阶段,验证确保了:
1) 安全要求在生产流程、用户手册、维修和维护指导中得到了恰当发布;
2) 通过在生产流程中应用控制措施,相关项的安全相关特性得到了满足。
注:这是一般性验证流程,GB/T 34590.3-2017、GB/T 34590.4-2017、GB/T 34590.5-2017、GB/T 34590.6-2017和GB/T 34590.7-2017中安全生命周期的各阶段给出了示例。该流程并不针对安全确认。参见GB/T 34590.4-2017第9章(安全确认),以获取更多细节。
9.3 本章的输入
9.3.1 前提条件
参见安全生命周期的相关阶段中适用的前提条件,在安全生命周期内进行计划和执行验证。
9.3.2 支持信息
参见计划和执行验证的安全生命周期的相关阶段中适用的支持信息。
9.4 要求和建议
9.4.1 验证计划
9.4.1.1 对安全生命周期的每个阶段及子阶段,应制定验证计划,并应涵盖以下方面:
a) 需验证的工作成果内容;
b) 用于验证的方法;
注:验证方法包括:评审、走查、检查、模型检查、模拟、工程分析、证明和测试。典型的验证会使用这些方法和其他方法的组合。
c) 验证通过和不通过的准则;
d) 如果适用,验证环境;
注:验证环境可以是测试或模拟环境。
e) 如果适用,用于验证的工具;
f) 当探测出异常时需采取的行动;及
g) 回归策略。
注:回归策略定义了在相关项或要素变更后如何重复进行验证。验证可以被全部或部分重复,并可包含其他能影响验证结果的相关项或要素。
9.4.1.2 制定验证计划宜考虑以下方面:
a) 所使用验证方法的充分性;
b) 需验证的工作成果的复杂性;
c) 与验证目标材料相关的前期经验;及
注:这包括服务历史及在用证明达到的程度。
d) 所使用技术的成熟度,或使用这些技术的风险。
9.4.2 验证规范
9.4.2.1 验证规范应对用于验证的方法进行选择和定义,并应包含:
a) 评审或分析的检查清单;
b) 模拟场景;
c) 测试用例、测试数据和测试目标。
9.4.2.2 对于测试,每个测试用例的定义应包含:
a) 唯一的识别;
b) 需验证的相关工作成果的版本;
c) 前提条件和配置;
注:如果对工作成果的可能配置(例如:系统变型)进行完整验证是不可行的,可选择一个合理的子集(例如:系统的最小或最大功能性配置)。
d) 如果适用,环境条件;
注:环境条件与周围物理属性(例如:温度)有关,测试在该环境进行或模拟部分测试。
e) 输入数据及其时序、量值;
f) 期望的表现,包括:输出数据、输出量值的可接受范围、时间表现和公差表现。
注1:当定义期望的表现时,对初始输出数据的定义可能是必要的,以探测变化。
注2:为避免重复定义和存储不同测试用例用到的前提条件、配置及环境条件,推荐使用这些数据的明确的参考。
9.4.2.3 对于测试,应按使用的测试方法对测试用例进行分组。对每种测试方法,作为测试用例的补
充,应定义以下内容:
a) 测试环境;
b) 逻辑和时间的依赖性;及
c) 资源。
9.4.3 验证的执行和评估
9.4.3.1 应按照9.4.1所做的计划及按照9.4.2所做的规范,执行验证。
9.4.3.2 对验证结果的评估应包含以下信息:
a) 所验证工作成果的唯一识别;
b) 验证计划和验证规范的参考;
c) 如果适用,评估中用到的验证环境配置、验证工具及标定数据;
d) 验证结果与期望结果的一致性水平;
e) 验证通过或不通过的明确的陈述,如果验证不通过,陈述应包含不通过的理由和对所验证工作
成果进行修改的建议;
注:按照验证的完成和结束准则[参见9.4.1.1c)]和预期的验证结果,对验证进行评估。
f) 每个验证步骤未执行的理由。
9.5 工作成果
9.5.1 验证计划,由9.4.1.1和9.4.1.2的要求得出。
9.5.2 验证规范,由9.4.2.1~9.4.2.3的要求得出。
9.5.3 验证报告,由9.4.3.1和9.4.3.2的要求得出。
10 文档化
10.1 目的
主要目的是开发用于整个安全生命周期的文档管理策略,以促进有效的和可重复的文档管理过程。
10.2 总则
GB/T 34590-2017中对文档的要求主要关注其内容,而非版面编排和外观。
除非GB/T 34590-2017有明确的定义,否则信息不需要呈现在物理文档中。文档可采取不同的
形式和结构,并可使用工具自动生成文档。
示例:可能的形式有:纸张、电子媒体、数据库。
信息是否充分取决于很多因素,包括:复杂性、安全相关系统/子系统的范围和与特殊应用相关的
要求。
宜避免一个文档中信息的重复及不同文档间信息的重复,以助于可维护性。
注:在一个文档中,使用交叉引用以代替信息的重复,将读者引向信息的源文件。
10.3 本章的输入
10.3.1 前提条件
应具备如下信息:
---安全计划,按照GB/T 34590.2-2017的6.5.1。
10.3.2 支持信息
无。
10.4 要求和建议
10.4.1 应计划文档制定和管理过程,以获得文档:
a) 用于在整个生命周期的每个阶段中有效完成各阶段及验证活动;
b) 用于功能安全的管理;及
c) 作为功能安全评估的输入。
10.4.2 应将对 GB/T 34590-2017中工作成果的识别理解为文档要求,包括关于相关要求的结果
信息。
注:文档可以是单个文档的形式,该文档包含工作成果的完整信息;也可以是一组文档的形式,这些文档合起来包含工作成果的完整信息。
10.4.3 文档宜是:
a) 准确的和简明的;
b) 结构清晰的;
c) 目标使用者容易理解的;及
d) 可维护的。
10.4.4 整个文档的结构宜考虑内部流程和工作实践。应对文档进行组织以助于搜索相关信息。
示例:文档树。
10.4.5 每个工作成果或文档应包含下面的正式要素:
a) 题目,参照内容的范围;
b) 作者和批准者;
c) 文档每个不同修订(版本)的唯一标识;
d) 变更历史;
注:变更历史包含:每次变更的作者姓名、日期和简要描述。
e) 状态。
示例:“草稿”“已发布”。
10.4.6 应能识别当前适用的文档修订(版本)或信息项,按照第7章。
10.5 工作成果
10.5.1 文档管理计划,由10.4.1的要求得出。
10.5.2 文档指南要求,由10.4.3~10.4.6的要求得出。
11 所使用软件工具的置信度
11.1 目的
本章的第一个目的是提供准则,以确定在适用时所要求的软件工具置信度水平。
本章的第二个目的是,在适用时提供鉴定软件工具的方法,以建立证据证明软件工具适合用于剪裁
GB/T 34590-2017要求的活动或任务(即,对那些GB/T 34590-2017要求的活动或任务,使用者可依
靠软件工具的正确功能)。
11.2 总则
在系统或其软件要素、硬件要素开发中使用的软件工具,可以通过剪裁GB/T 34590-2017要求的
活动或任务,来支持或促成对安全生命周期的剪裁。在这些情况下,需要具备软件工具有效达到下述目
标的置信度:
a) 开发产品中,将因软件工具功能异常导致错误输出的系统性故障的风险减小到最低;及
b) 如果GB/T 34590-2017要求的活动或任务依赖于所使用软件工具的正确功能,软件工具的
开发流程充分符合GB/T 34590-2017。
注:对“软件工具”的理解,可从单独使用的独立软件工具变化到由一组软件工具集成的工具链。
示例:该软件工具可以是商业工具、开源工具、免费工具、共享工具或使用者自己开发的工具。
为了制定上述条件下开发的软件工具的置信度水平要求,对以下准则进行评估:
---软件工具功能异常及其相应的错误输出,可导致或无法探测出正在开发的安全相关项或要素
中的错误的可能性;
---防止或探测软件工具相应输出中的这些错误的置信度。
为评估防止或探测措施的置信度,考虑并可评估在安全相关项或要素开发过程中实施的软件工具
内部措施(如:监控)及软件工具外部措施(如:指南、测试、评审)。
如果受已确定的工具置信度水平要求,则使用合适的鉴定方法以符合此工具置信度水平,并符合分
配给将使用此软件工具开发的相关项或要素的全部安全要求中最高ASIL等级。否则,无需使用该鉴
定方法。
11.3 本章的输入
11.3.1 前提条件
应具备如下信息:
---安全计划,按照GB/T 34590.4-2017的5.5.2;
---使用了软件工具的各安全生命周期阶段的适用前提条件。
11.3.2 支持信息
可考虑以下信息:
---预先确定的最大ASIL等级;
---软件工具的用户手册(来自外部);
---软件工具的环境和约束(来自外部)。
11.4 要求和建议
11.4.1 一般要求
11.4.1.1 如果安全生命周期包含使用软件工具用于系统、硬件要素或软件要素的开发,使得
GB/T 34590-2017要求的活动或任务依赖于软件工具的正确功能,与此同时未按照适用的流程步骤
对工具的相关输出进行检查或验证,则该软件工具应符合本章的要求。
11.4.2 预先确定的工具置信度水平的有效性或鉴定的有效性
如果对软件工具置信度水平评估或鉴定的执行,独立于特定安全相关项或要素的开发,......
英文网页English: GB/T 34590.8-2017
相关标准: GB/T 34590.7|GB/T 34590.1|GB/T 34590.12|GB/T 34590.11|GB/T 34590.8-2017|GB/T 34590.8|