安全需求规范和管理指南

这篇具有很好参考价值的文章主要介绍了安全需求规范和管理指南。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

  1. 安全需求规范
    1. 安全需求的标记法

对应于2.2章节中的安全需求特性,通过如下组合来定义安全需求:

  1. 自然语言(适应于较高层面的安全需求,如功能和技术安全需求);
  2. 表1中所列举方法(适应于较低层面的安全需求,如软件和硬件安全需求);

表1 定义安全需求

方法

ASIL

A

B

C

D

1a

用于需求定义的非正式标记法

++

++

+

+

1b

用于需求定义的半正式标记法

+

+

++

++

1c

用于需求定义的正式标记法

+

+

+

+

  • 注1:安全要求定义方法的恰当选择考虑:针对特定问题待定义的安全要求,方法是否足够准确以具备相关规定的安全要求的特性;方法的复杂性;定义或管理安全要求的人员的背景知识。示例包括使用状态图或关系图来定义软件或硬件的复杂行为,包括许多状态或/和复杂转换。
  • 注2:对于高等级的安全需求(安全目标、功能技术安全需求和技术安全需求)自然语言和其他类型非正式语言较为适合,有些要求可能用半形式记法更好处理。
  • 注3:半形式记法使用数学或图形要素【如方程、图形、图表、流程图、时序图和许多其他形式的表示(例如 UML®和 SysML™)】补充的自然语言来表达需求。示例包括基于模型的技术,以及在自然语言中为要求描述语句应用模板和受控词汇表。
  • 注4:对于低等级的安全需求,如详细的软件及硬件的行为、能力等,可明确定义,以半形式符号描述更加清晰;但不应该要求所有需求进行半形式化描述;
    1. 安全需求的特性和特点
  1. 安全需求应能被明确识别出。
  • 注:安全需求应被列在单独的文档中,如果安全需求与其他需求在同一个文档中,安全需求应被明确标识出;
  1. 安全需求应继承原安全需求的ASIL等级,安全目标已被分解的除外;
  • 注:安全目标是顶层的安全需求,对于ASIL等级的继承始于安全目标水平;
  1. 安全需求应被分配给实现这些要求的相关项或元素;
  2. 安全需求需具备如下特性:
  1. 明确的,无歧义的;
  2. 可理解;
  3. 不可分割,即不可再被细化为一个以上的需求;
  • 注:在此特性与其他重要的安全要求特性相反时,不可分割性的重要性可被降低;
  1. 内部一致:即每个单独的安全需求不包含自相矛盾的内容(不同于外部一致性,外部一致性指多个安全需求不含有相互抵触的内容);
  2. 可实现的;
  • 注:如果某个要求在相关项的开发限制(资源、当前技术水平等)内可被实现,则其是可行的。
  • 注:一项要求在技术上可以实现,它不需要重大的技术进步,并且在可接受范围内符合相关项限制(如成本、进度、技术、法律、法规等);
  1. 可验证的;
  • 注:如果在定义要求的层面上有方法检查这些要求是否得到了满足,则要求是可验证的。
  • 注:收集到有关相关项的证据表明相应的要求已得到满足。如果要求是可测量的,可验证性会更强。
  1. 必要的;
  • 注:某项需求定义了一项重要的能力、特性、约束或质量要素,如果该需求被移除或删除,会导致产品的其他能力或流程无法满足要求;
  • 注:需求当前适用,没有被废弃;需求应明确标识截止日期或使用时间;
  1. 实施自由的
  • 注:仅描述需求应陈述要求是什么,而不是如何满足要求;不要对架构的设计做太多不必要的限制;
  1. 完整的;
  • 注:对需求的表述要清晰,不进行进一步扩充。
  1. 合规的:
  • 注:符合政府法规、汽车行业和产品标准、规范及接口要求。
    1. 安全需求属性

安全需求应具有如下属性,

  1. XXX安全需求在安全生命周期内,具有唯一识别并保持不变。
  2. ASIL等级;
  3. 安全需求的状态

示例:安全需求的状态可以是Draft(未通过评审和批准)及Released(通过评审和批准的);

  1. 其他类型的

安全目标:安全状态、FTTI等  

功能安全需求可能有:运行模式,故障容错时间区间(间隔)或故障容错时间,安全状态,紧急操作时间区间,功能冗余几种属性。

对技术安全需求、软件安全需求、硬件安全需求的要求参见公司功能安全流程的相关文件(在下面表格中,ID,ASIL等级,Status使用了加粗字体代表必选,其他的属性用正常字体代表可选属性的举例)

      1. 安全目标

表2 安全目标属性描述

属性

属性描述

ID

ASIL等级

Status

安全状态

FTTI

      1. 功能安全需求

表3 功能安全需求属性描述

属性

属性描述

ID

ASIL等级

Status

运行模式

故障容错时间

安全状态

紧急操作时间区间

功能冗余

紧急操作

报警、降级

      1. 技术安全需求

表4 技术安全需求属性描述

属性

属性描述

ID

ASIL等级

Status

外部接口

限制条件

系统配置要求

      1. 软件安全需求

表5 软件安全需求属性描述

属性

属性描述

ID

ASIL等级

Status

维持安全状态

硬件故障监控处理

软件故障监控处理

是否车载测试

生产维护过程中是否可修改

与性能或时间敏感

      1. 硬件安全需求

表6 硬件安全需求属性描述

属性

属性描述

ID

ASIL等级

Status

控制要素内部失效

对外部失效容错

符合其他要素的安全需求

故障探测

未定义安全机制的硬件

  1. 安全需求管理
    1. 安全需求的管理方式
  1. 通过《System Safety Requirements Traceability Matrix 》表格对安全需求进行管理

每一层子需求都需要满足上一层的母需求,使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分标注追溯关系。参阅表格的相关标注。

  1. 安全需求的管理需要满足:
  1. 分层结构

注:如图1所示,分层结构是指安全需求分布在几个连续层面上的。这些层面与产品开发阶段一致。

  1. 合理的架构

注:与架构相对应,安全需求在每个层面都应进行合理地分组;

  1. 完整性

注:一个层面的安全需求完整地落实了前一层面的全部安全需求。

  1. 外部一致性

注:不同于内部一致性(每个单独的安全需求不包含自相矛盾的内容),外部一致性表示多个安全需求不互相抵触。

  1. 分层结构中任意一层的信息不重复

注:信息不重复表示安全需求的内容不重复出现在分层结构同一层面的其它安全需求中;

  1. 可维护性

注:可维护性表示需求集可被修改或扩展,例如引入需求的新版本或增加/去掉需求集内的需求。

注:当安全需求符合  2.2安全需求的特性和特点 3.1安全需求的管理方式 时,安全需求的可维护性更好。

                                           图1 安全要求的结构

  1. 安全需求应置于配置管理之下

       当较低层面的安全需求与较高层面的安全需求相符合时,配置管理可定义一个基线作为安全生命周期后续阶段的基础。

    1. 安全需求的追溯性要求

使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分标注追溯关系。参阅表格的相关标注。

安全需求应当是可追溯的,

  1. 安全需求源自于更高层级的安全需求;
  2. 安全需求导出到更低层级,或导出至设计中来实现。
  3. 按照《验证过程管理规定》中有关“验证规范”的章节中,验证规范所描述的测试案例,均可以追溯每个安全需求是被充分验证的。

注1:可使用各种追溯记录类型,如需求管理系统、电子材料等;

注2:可追溯性另外还支持了:

  • 实现安全需求、实现、验证之间的一致性;
  • 对特定安全需求进行更改时的影响分析;
  • 认可措施(如功能安全评估,以评估功能安全实现与否)的执行。
    1. 安全需求的追溯内容

安全需求的追溯应包括:

  1. 安全目标与功能安全需求之间的双向追溯性
  2. 安全目标与安全确认测试用例之间的双向追溯性
  3. 功能安全需求与技术安全需求之间的双向追溯性
  4. 功能安全需求与整车集成测试用例之间双向追溯性
  5. 技术安全需求与硬件安全需求
  6. 技术安全需求与软件安全需求
  7. 硬件安全需求与硬件设计
  8. 硬件安全需求与硬件集成测试用例
  9. 软件安全需求与软件架构设计
  10. 软件安全需求与嵌入式软件测试用例
  11. 软件架构设计与软件详细设计
  12. 软件架构设计与软件集成测试用例
  13. 软件详细设计与软件单元测试用例
    1. 验证方法

应将表2中所列举的验证方法,用于验证安全需求是否符合本章节的要求,及是否符合得出安全需求的公司功能安全流程体系相关部分中关于验证安全需求的特定要求。

表7 验证安全要求的方法

方法

ASIL

A

B

C

D

1a

通过走查验证

++

+

º

º

1b

通过检查验证

+

++

++

++

1c

半形式验证

+

+

++

++

1d

形式验证

º

+

+

+

*可执行模型可以支持方法1c

  1. 安全需求的分解
    1. 安全需求分解的条件
  1. 对功能安全需求进行ASIL分解需具备功能安全需求和功能安全概念;
  2. 对技术安全需求进行ASIL分解需具备技术安全需求和技术安全概念;
  3. 对软件安全需求进行ASIL分解需具备软件安全需求和软件安全架构;
  4. 对硬件安全需求进行ASIL分解需具备硬件安全需求和硬件安全架构;
  5. 分解后的安全需求必须互相冗余,且由相互独立的元素执行。
    1. 安全需求分解的标识

分解后的安全需求的ASIL等级表示方法为 ASIL X (Y),其中X为分解后的ASIL等级,Y为安全目标的ASIL等级。

示例:如果一个ASIL D的需求分解成一个ASIL C的需求和一个ASIL A的需求,则应标注成“ASIL C(D)”和“ASIL A(D)”. 如果ASIL C(D)的需求进一步分解成一个ASIL B 的需求和一个ASIL A的需求,则应使用安全目标的ASIL等级将其标注为”ASILB(D)”和“ASILA(D)”。

    1. 安全需求分解的模式

按照如下模式进行安全需求的分解,或可使用得出更高ASIL等级的方案。

  1. 按照图2所示对ASIL D的安全需求进行分解:

图2:ASIL D分解方案

  1. 一个ASIL C(D) 的需求和一个ASIL A(D)的需求;或
  2. 一个ASIL B(D) 的需求和一个ASIL B(D)的需求;或
  3. 一个ASIL D(D)的要求和一个QM(D)的要求。

当分解为两个ASIL B(D)的安全需求时,额外的要求如下:

  1. 参照表1中ASIL C的要求来定义分解后的安全需求。
  2. 如果用相同的软件工具开发分解后的元素,那么这些软件工具应考虑为开发ASIL D相关项或元素的软件工具,并符合《TK_P_SUP_06 工具评估流程》中软件工具使用的置信度。
  1. 按照图3所示对ASIL C的安全需求进行分解:

图3:ASIL C分解方案

  1. 一个ASIL B(C) 的需求和一个ASIL A(C)的需求;或
  2. 一个ASIL C(C) 的需求和一个QM(C)的需求。
  1. 按照图4所示对ASIL B的安全需求进行分解:

图4:ASIL B分解方案

  1. 一个ASIL A(B) 的需求和一个ASIL A(B)的需求;或
  2. 一个ASIL B(B) 的需求和一个QM(B)的需求。
  1. 一个ASIL A 的需求不应进一步分解,除非需要分解成一个ASIL A(A) 的需求和一个QM(A) 的需求,如图5所示:

图5:ASIL A分解方案

  1. 如果对初始安全需求的ASIL 分解是将分解后的需求分配给预期功能及相关安全机制,则相关安全机制宜被赋予分解后的最高ASIL等级。另一方面安全需求应被分配给预期功能,并按照相应分解后的ASIL等级执行。
    1. 安全需求分解的相关要求
  1. ASIL分解可以多次应用;
  2. 初始安全需求应分解为独立安全要素执行的冗余安全需求;
  3. 进行ASIL等级分解时,应分别考虑每一个初始的安全要求。应针对每一个初始安全需求单独进行ASIL分解;
  4. 初始安全要求应分解为冗余安全要求,并由充分独立要素实现。如果相关失效分析没有找到导致违反初始安全要求的合理原因,或者根据初始安全要求的ASIL等级,所识别的相关失效的每个原因都被充分的安全措施控制,则这些要素具有充分的独立性;

注1:一条被分解的要求可能是几个初始安全要求分解的结果。

注2:使用同构冗余来实现分解的要求(例如,通过复制的设备或复制的软件)并不能解决硬件和软件系统性失效。 除非相关失效的分析(参见第7章)提供了充分的独立性证据或存在潜在共因可进入安全状态的证据,否则不允许ASIL等级的降低。因此,在没有针对特定系统应用背景的相关失效分析的支持下,单靠同构冗余通常不足以降低ASIL等级。

注3:ASIL等级分解通常不适用于在多通道架构设计中确保通道选择或通道切换的要素。 应用ASIL分解时,需提供分解后安全需求冗余且执行元素相互独立的证据。

  1. 硬件架构指标(SPFM, LFM)和随机硬件失效导致违背安全目标的指标(PMHF)需参照安全目标的ASIL等级来要求。即便进行了ASIL分解,这些硬件相关的指标也维持不变
  2. 每个分解后的安全需求应符合初始安全需求

注4:此要求通过定义提供了冗余。

注5:如果将分解后的安全要求分配给安全机制,则应在评估分解后的要求是否符合初始安全要求时,考虑该安全机制的有效性。

示例:分配给指定ECU的ASIL D要求,可能被轻易的分解为分配给ECU中简单看门狗的ASIL D要求和该ECU微处理器的QM安全要求。然而,这个简单的看门狗不足以覆盖ASIL D要求的微处理器的失效模式。在这种情况下,该看门狗不能有效地满足初始的安全要求。

  1. 如果在软件层面应用ASIL 分解,应在系统层面检查执行分解后的元素间的充分独立性,如果有必要,应在软件层面、硬件层面或系统层面采取适当的措施来获得充分的独立性;
  2. 如果不能通过关闭元素来阻止对初始安全需求的违背,则应展示执行分解后安全需求的充分独立的元素具备足够的可用性;
  3. 应至少按照分解后的ASIL等级要求,在系统层面和软件层面开发分解后的要素;
  4. 应至少按照分解后的ASIL等级要求,在硬件层面开发分解后的要素,但硬件架构指标(SPFM, LFM)和随机硬件失效导致违背安全目标的指标(PMHF)除外;
  5. 按照分解前的ASIL等级要求开展对分解后的元素的相关集成活动及后续活动;
  6. 同质冗余(复制设备或复制软件)因缺少要素间的独立性,通常不足以降低ASIL等级;
  7. ASIL分解完成后需更新相应安全需求的ASIL等级和相应的架构设计;
  8. ASIL分解不适用于在多通道架构设计中用来确保通道选择或开关的要素;
  9. 如果架构要素不是充分独立的,则冗余需求和架构要素继承初始的ASIL等级;
  10. 如果对初始安全要求的ASIL等级分解导致将分解后的要求分配给预期功能及相关安全机制,则: a) 相关安全机制宜被分配分解后的较高ASIL等级;及

注1:通常,与预期功能相比,安全机制具备较低的复杂度和更小的规模。安全要求应被分配给预期功能,并按照相应分解后的ASIL等级实现。

注2:如果选择了分解方案 ASILx(x) +QM(x),则 QM(x)意味着质量管理体系足以实现预期功能要素安全要求的开发。

  1. 子元素的ASIL等级确定准则
    1. 初始ASIL等级为QM的子元素的ASIL等级的确定

如果未分配ASIL等级的子元素和安全相关子元素共同存在于同一元素中,如果能证明未分配ASIL等级的子元素不能直接或间接地违背分配给该元素的任何安全需求,即:未分配ASIL等级的子元素不能干扰元素中安全相关的任何子元素,则应仅视其为QM的子元素。

注1:该子元素到安全相关元素的级联失效是不存在的。

注2:可通过设计措施获得,诸如考虑软件的数据流和控制流,或硬件的输入/输出信号及控制线。

否则,应将不具备免于干扰证据的共存安全相关子元素的最高ASIL等级分配给该子元素。

    1. 具备不同的初始ASIL等级的子元素的ASIL等级的确定

如果同一元素中存在不同ASIL等级(包括QM(x))的安全相关子元素,若能证明对分配给元素的每个安全需求,某个子元素不会干扰任何分配了较高ASIL等级的其它子元素,则应仅视该子元素为较低ASIL等级的子元素。否则,由于不具备免于干扰的证据,应将共存安全相关子元素的最高ASIL等级分配给该子元素。

注: 对免于干扰的评估应与分配给共存的子要素的最高ASIL等级要求相匹配文章来源地址https://www.toymoban.com/news/detail-450322.html

到了这里,关于安全需求规范和管理指南的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Linux网络操作实操指南:从网络配置到安全管理

    Linux是一种开源的操作系统,具有稳定性高、安全性好、可定制性强等优点。作为一名Linux用户,掌握基本的Linux网络操作是非常必要的。以下是Linux网络操作的几个方面,包括具体的实操步骤: 1. 网络配置 Linux中的网络配置需要设置IP地址、子网掩码、网关等参数,以实现网

    2024年02月09日
    浏览(47)
  • 产品团队的需求分析指南

    需求分析是软件开发流程中需求识别与管理的关键环节,需求分析的目的在于确保所有产品需求准确地代表了利益相关者的需求和要求。选择合适的需求分析方式可以帮助我们获取准确的产品需求,从而保证我们所交付的成果与利益相关者预期相符。 需求分析是一个发现、理

    2024年02月11日
    浏览(42)
  • 更安全,更省心丨DolphinDB 数据库权限管理系统使用指南

    在数据库产品使用过程中,为保证数据不被窃取、不遭破坏,我们需要通过用户权限来限制用户对数据库、数据表、视图等功能的操作范围,以保证数据库安全性。为此,DolphinDB 提供了具备以下主要功能的权限管理系统: 提供用户和组角色,方便权限控制 提供19种权限控制

    2024年02月15日
    浏览(42)
  • 商用密码应用与安全性评估要点笔记(密评管理测评要求、测评过程指南)

    4.5 密评管理测评要求 词条 内容 层面 管理制度(包括6个测评单元) 单元-1 具备密码应用安全管理制度(1-4级) 测评指标:具备密码应用安全管理制度,包括人员管理、密钥管理、建设运行、应急处置、密码软硬件及介质管理等制度 测评对象:安全管理制度类文档 测评实施

    2024年02月01日
    浏览(50)
  • Git提交规范指南

    在开发过程中,Git每次提交代码,都需要写Commit message(提交说明),规范的Commit message有很多好处: 方便快速浏览查找,回溯之前的工作内容 可以直接从commit 生成Change log(发布时用于说明版本差异) 为了方便使用,我们避免了过于复杂的规定,格式较为简单且不限制中英文

    2024年02月12日
    浏览(29)
  • 2023-数仓建设规范指南

    1. 数仓分层原则 优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长。那么问题来了,一直在讲数仓要分层,那数仓分几层最好? 目前市场上主流的分层方式眼花缭乱,不过看事情不能只看表面,还要看

    2024年02月07日
    浏览(39)
  • 数仓建设七大规范指南

    一、数据模型架构规范   1.数据层次的划分   ODS: Operational Data Store,操作数据层,在结构上其与源系统的增量或者全量数据基本保持一致。它相当于DW数据的一个数据准备区,同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到DMP。   CDM: Common D

    2024年02月08日
    浏览(41)
  • 终极指南:Scrum中如何设置需求优先级

    需求众多不知道如何下手?总想先做简单的需求,复杂需求却一拖再拖?那么,我们是时候开始考虑如何设置需求优先级了。 本期终极指南将展示如何为需求设置有效优先级,如何有效管理工作量,让效率指数倍增长,搭配 《 Scrum流程:如何科学地进行需求优先级排序 ?

    2024年02月08日
    浏览(49)
  • 好看又规范的Github Readme 制作指南

    精心设计的 README 对于任何 GitHub 存储库都至关重要,因为它是潜在用户和贡献者的主要信息来源。 以下是创建 README 时要遵循的基本结构。 1. 标题和描述 Title and Description 首先要包含在README中的是您的项目的清晰简洁的标题和描述。 这个项目是做什么的? 它存在的原因是什

    2024年02月08日
    浏览(40)
  • 一定要看的前端codeReview规范指南

    一、前言 针对目录结构、CSS规范、JavaScript规范、Vue规范 可参照官方给出的 风格指南 这里主要总结业务开发中常遇到的代码问题和实践,帮助大家后续各自做好codeReview,一些你遇到的典型问题,也可以在留言区评论,帮助团队共同进步。 二、实践规范 2.1 防止重复提交 --表

    2024年02月08日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包