安全需求规范和管理指南
对应于2.2章节中的安全需求特性，通过如下组合来定义安全需求：
|
方法 |
ASIL |
||||
|
A |
B |
C |
D |
||
|
1a |
用于需求定义的非正式标记法 |
++ |
++ |
+ |
+ |
|
1b |
用于需求定义的半正式标记法 |
+ |
+ |
++ |
++ |
|
1c |
用于需求定义的正式标记法 |
+ |
+ |
+ |
+ |
- 注1：安全要求定义方法的恰当选择考虑：针对特定问题待定义的安全要求，方法是否足够准确以具备相关规定的安全要求的特性；方法的复杂性；定义或管理安全要求的人员的背景知识。示例包括使用状态图或关系图来定义软件或硬件的复杂行为，包括许多状态或/和复杂转换。
- 注2：对于高等级的安全需求（安全目标、功能技术安全需求和技术安全需求）自然语言和其他类型非正式语言较为适合，有些要求可能用半形式记法更好处理。
- 注3：半形式记法使用数学或图形要素【如方程、图形、图表、流程图、时序图和许多其他形式的表示(例如 UML®和 SysML™)】补充的自然语言来表达需求。示例包括基于模型的技术，以及在自然语言中为要求描述语句应用模板和受控词汇表。
- 注4：对于低等级的安全需求，如详细的软件及硬件的行为、能力等，可明确定义，以半形式符号描述更加清晰；但不应该要求所有需求进行半形式化描述；
- 注：如果某个要求在相关项的开发限制（资源、当前技术水平等）内可被实现，则其是可行的。
- 注：一项要求在技术上可以实现，它不需要重大的技术进步，并且在可接受范围内符合相关项限制（如成本、进度、技术、法律、法规等）；
示例：安全需求的状态可以是Draft（未通过评审和批准）及Released（通过评审和批准的）；
功能安全需求可能有：运行模式，故障容错时间区间（间隔）或故障容错时间，安全状态，紧急操作时间区间，功能冗余几种属性。
对技术安全需求、软件安全需求、硬件安全需求的要求参见公司功能安全流程的相关文件（在下面表格中，ID，ASIL等级，Status使用了加粗字体代表必选，其他的属性用正常字体代表可选属性的举例）
|
属性 |
属性描述 |
|
ID |
|
|
ASIL等级 |
|
|
Status |
|
|
安全状态 |
|
|
FTTI |
|
属性 |
属性描述 |
|
ID |
|
|
ASIL等级 |
|
|
Status |
|
|
运行模式 |
|
|
故障容错时间 |
|
|
安全状态 |
|
|
紧急操作时间区间 |
|
|
功能冗余 |
|
|
紧急操作 |
|
|
报警、降级 |
|
属性 |
属性描述 |
|
ID |
|
|
ASIL等级 |
|
|
Status |
|
|
外部接口 |
|
|
限制条件 |
|
|
系统配置要求 |
|
属性 |
属性描述 |
|
ID |
|
|
ASIL等级 |
|
|
Status |
|
|
维持安全状态 |
|
|
硬件故障监控处理 |
|
|
软件故障监控处理 |
|
|
是否车载测试 |
|
|
生产维护过程中是否可修改 |
|
|
与性能或时间敏感 |
|
属性 |
属性描述 |
|
ID |
|
|
ASIL等级 |
|
|
Status |
|
|
控制要素内部失效 |
|
|
对外部失效容错 |
|
|
符合其他要素的安全需求 |
|
|
故障探测 |
|
|
未定义安全机制的硬件 |
注：如图1所示，分层结构是指安全需求分布在几个连续层面上的。这些层面与产品开发阶段一致。
注：不同于内部一致性（每个单独的安全需求不包含自相矛盾的内容），外部一致性表示多个安全需求不互相抵触。
注：信息不重复表示安全需求的内容不重复出现在分层结构同一层面的其它安全需求中；
注：可维护性表示需求集可被修改或扩展，例如引入需求的新版本或增加/去掉需求集内的需求。
注：当安全需求符合 2.2安全需求的特性和特点 与 3.1安全需求的管理方式 时，安全需求的可维护性更好。
当较低层面的安全需求与较高层面的安全需求相符合时，配置管理可定义一个基线作为安全生命周期后续阶段的基础。
使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分标注追溯关系。参阅表格的相关标注。
- 安全需求源自于更高层级的安全需求；
- 安全需求导出到更低层级，或导出至设计中来实现。
- 按照《验证过程管理规定》中有关“验证规范”的章节中，验证规范所描述的测试案例，均可以追溯每个安全需求是被充分验证的。
- 安全目标与功能安全需求之间的双向追溯性
- 安全目标与安全确认测试用例之间的双向追溯性
- 功能安全需求与技术安全需求之间的双向追溯性
- 功能安全需求与整车集成测试用例之间双向追溯性
- 技术安全需求与硬件安全需求
- 技术安全需求与软件安全需求
- 硬件安全需求与硬件设计
- 硬件安全需求与硬件集成测试用例
- 软件安全需求与软件架构设计
- 软件安全需求与嵌入式软件测试用例
- 软件架构设计与软件详细设计
- 软件架构设计与软件集成测试用例
- 软件详细设计与软件单元测试用例
应将表2中所列举的验证方法，用于验证安全需求是否符合本章节的要求，及是否符合得出安全需求的公司功能安全流程体系相关部分中关于验证安全需求的特定要求。
|
方法 |
ASIL |
||||
|
A |
B |
C |
D |
||
|
1a |
通过走查验证 |
++ |
+ |
º |
º |
|
1b |
通过检查验证 |
+ |
++ |
++ |
++ |
|
1c |
半形式验证 |
+ |
+ |
++ |
++ |
|
1d |
形式验证 |
º |
+ |
+ |
+ |
|
*可执行模型可以支持方法1c |
|||||
- 对功能安全需求进行ASIL分解需具备功能安全需求和功能安全概念；
- 对技术安全需求进行ASIL分解需具备技术安全需求和技术安全概念；
- 对软件安全需求进行ASIL分解需具备软件安全需求和软件安全架构；
- 对硬件安全需求进行ASIL分解需具备硬件安全需求和硬件安全架构；
- 分解后的安全需求必须互相冗余，且由相互独立的元素执行。
分解后的安全需求的ASIL等级表示方法为 ASIL X (Y)，其中X为分解后的ASIL等级，Y为安全目标的ASIL等级。
按照如下模式进行安全需求的分解，或可使用得出更高ASIL等级的方案。
当分解为两个ASIL B(D)的安全需求时，额外的要求如下：
- 参照表1中ASIL C的要求来定义分解后的安全需求。
- 如果用相同的软件工具开发分解后的元素，那么这些软件工具应考虑为开发ASIL D相关项或元素的软件工具，并符合《TK_P_SUP_06 工具评估流程》中软件工具使用的置信度。
- 如果对初始安全需求的ASIL 分解是将分解后的需求分配给预期功能及相关安全机制，则相关安全机制宜被赋予分解后的最高ASIL等级。另一方面安全需求应被分配给预期功能，并按照相应分解后的ASIL等级执行。
- ASIL分解可以多次应用；
- 初始安全需求应分解为独立安全要素执行的冗余安全需求；
- 进行ASIL等级分解时，应分别考虑每一个初始的安全要求。应针对每一个初始安全需求单独进行ASIL分解；
- 初始安全要求应分解为冗余安全要求，并由充分独立要素实现。如果相关失效分析没有找到导致违反初始安全要求的合理原因，或者根据初始安全要求的ASIL等级，所识别的相关失效的每个原因都被充分的安全措施控制，则这些要素具有充分的独立性；
注3：ASIL等级分解通常不适用于在多通道架构设计中确保通道选择或通道切换的要素。 应用ASIL分解时，需提供分解后安全需求冗余且执行元素相互独立的证据。
- 硬件架构指标(SPFM, LFM)和随机硬件失效导致违背安全目标的指标(PMHF)需参照安全目标的ASIL等级来要求。即便进行了ASIL分解，这些硬件相关的指标也维持不变
- 每个分解后的安全需求应符合初始安全需求
注5：如果将分解后的安全要求分配给安全机制，则应在评估分解后的要求是否符合初始安全要求时，考虑该安全机制的有效性。
- 如果在软件层面应用ASIL 分解，应在系统层面检查执行分解后的元素间的充分独立性，如果有必要，应在软件层面、硬件层面或系统层面采取适当的措施来获得充分的独立性；
- 如果不能通过关闭元素来阻止对初始安全需求的违背，则应展示执行分解后安全需求的充分独立的元素具备足够的可用性；
- 应至少按照分解后的ASIL等级要求，在系统层面和软件层面开发分解后的要素；
- 应至少按照分解后的ASIL等级要求，在硬件层面开发分解后的要素，但硬件架构指标(SPFM, LFM)和随机硬件失效导致违背安全目标的指标(PMHF)除外；
- 按照分解前的ASIL等级要求开展对分解后的元素的相关集成活动及后续活动；
- 同质冗余（复制设备或复制软件）因缺少要素间的独立性，通常不足以降低ASIL等级；
- ASIL分解完成后需更新相应安全需求的ASIL等级和相应的架构设计；
- ASIL分解不适用于在多通道架构设计中用来确保通道选择或开关的要素；
- 如果架构要素不是充分独立的，则冗余需求和架构要素继承初始的ASIL等级；
- 如果对初始安全要求的ASIL等级分解导致将分解后的要求分配给预期功能及相关安全机制，则： a) 相关安全机制宜被分配分解后的较高ASIL等级；及
注1：通常，与预期功能相比，安全机制具备较低的复杂度和更小的规模。安全要求应被分配给预期功能，并按照相应分解后的ASIL等级实现。
注2：如果选择了分解方案 ASILx(x) +QM(x)，则 QM(x)意味着质量管理体系足以实现预期功能要素安全要求的开发。
注2：可通过设计措施获得，诸如考虑软件的数据流和控制流，或硬件的输入/输出信号及控制线。
否则，应将不具备免于干扰证据的共存安全相关子元素的最高ASIL等级分配给该子元素。
注： 对免于干扰的评估应与分配给共存的子要素的最高ASIL等级要求相匹配
安全需求规范和管理指南相关推荐
- 信息技术服务连续性管理指南
连续性资源 概述 行业机构根据业务影响分析和信息技术 服务连续性风险评估结果,在信息技术服务连续性策略指导下,建设信息技术服务连续性 管理所需资源并定期维护,保障信息技术服务连续性计划顺利执行.行业机 ...
- 英特尔分布式深度学习平台Nauta-安装、配置与管理指南
2019独角兽企业重金招聘Python工程师标准>>> 英特尔分布式深度学习平台Nauta-安装.配置与管理指南 随着人工智能的发展,深度学习的价值不断增长,但实现它可能是一个复杂耗 ...
- 系统集成资质培训 - 标准系列 -软件文档管理指南
软件文档管理指南GB/T16680-1996 <GB/T16680-1996软件文档管理指南>(由原国家技术监督局于1996年12月18日发布,1997年7月1日起实施,该标准为那些对软件 ...
- 产品经理技能树之 需求规范
2019独角兽企业重金招聘Python工程师标准>>> "这个需求做不了",这或许是一句每个产品经理都曾经听到过的话吧.其实,我觉得,大部分的情况下,那个需求不是 ...
- 产品研发过程管理专题——软件工程（软件目的需求开发与管理）
需求开发与管理是软件项目中一项十分重要的工作,据调查显示在众多失败的软件项目中,由于需求原因导致的约占到45%,因此,需求工作将对软件项目能否最终实现产生至关重要的影响.虽然如此,在项目开发工作中,很 ...
- 需求调研过程管理小议
根据需求调研过程中的进展情况,我们将需求调研过程分为三个阶段:调研前准备.调研活动管理.调研结束.每个阶段需要遵循一定的工作流程和注意一些问题. 一.需求调研准备: 在需求调研过程中,应该做好三种准备 ...
- Austroads交通管理指南 2022（英）（附下载）
Austroads 交通管理指南共有13 个部分,为涉及交通工程.道路设计和道路安全的从业者提供全面的交通管理指南. 本指南仅限于交通管理建议,仅简要提及其他指南中更适宜处理的问题.<指南> ...
- 软件测试需求管理系统,软件测试管理及工具应用
本词条缺少概述图,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! <软件测试管理及工具应用>是2014年清华大学出版社出版的图书. 书 名 <软件测试管理及工具应用&g ...
- 指南解读：急性心力衰竭中国急诊管理指南（2022）
心力衰竭(heart failure,HF 简称心衰)是由于心脏结构和 / 或功能异常导致心室充盈和/或射血能力受损的一组临床综合征,其病理生理学特征为肺淤血和/或体循环淤血.伴或不伴有组织器官低灌注 ...
最新文章
- 伪数组(ArrayLike)
- 你觉得 ThreadLocalRandom 这玩意真的安全吗？
- 12. Leetcode 350. 两个数组的交集 II (数组-分离双指针)
- 软件体系结构的风格（转载）
- JAVA程序设计----多线程（上）
- Incorrect line ending: found carriage return (\r) without corresponding newline (\n)错误的解决方案...
- mysql实现斐波那契,C#实现斐波那契数列的几种方法整理
- html新年倒计时特效,js实现新年倒计时效果
- 记忆的分类及其理论模型
- 可视化大屏设计尺寸_UI设计中大屏可视化设计尺寸指南
- 扔掉Windows 中的盗版软件，使用免费正版软件
- 可爱的BpXXX-图
- linux绝育玩客云_玩客云实用指南（真·无痛绝育），附玩物下载对比
- 记录第一次开发android的学习心得
- 元宇宙技术在职业教育示范性虚拟仿真实训基地建设项目上的前景展望
- Eventually Consistent(最终一致性)（转）
- Java字符串分割的三种方法
- Opencv_11 阈值分割
- 【转载】 C#实现的CRC32算法
- RAC VIP地址飘移