符合功能安全要求的嵌入式系统软件安全需求管理研究

王曼，张舟云，张冀，陈雷，潘绪前

(1.上海汽车电驱动有限公司 电控开发部，上海201806；2.上海汽车电驱动工程技术研究中心有限公司 专家委员会，上海201806)

0 引言

随着汽车电子电气架构逐渐从分布式转向集中型，逐渐集中的汽车电子电气架构对车载ECU的嵌入式系统软件提出了多方面、更复杂的需求，软件需求作为软件开发的初始输入，来源多为与客户一起建立并不断更新的需求和软件开发、测试、管理等提出的需求[1-2]。嵌入式系统软件开发的全生命周期都在需求指导下展开，需求一旦出错或将导致软件的缺陷或产品返工，需求缺陷经变更纠正后，往往要针对需求变更进行大量回归验证测试，造成人力、物力和时间的巨大耗费，导致项目延期以及开发成本超出预算的恶性后果。此外，鉴于乘用汽车的应用场景，安全相关需求问题导致的缺陷，一旦流出到用户端或将带来人身生命安全的隐患。因此，对嵌入式系统软件安全需求的管理重要性极高，作为开发工作的前级，需求管理必须依据一定的原则谨慎开展。

1 嵌入式系统软件需求管理的常见问题

车载ECU嵌入式系统软件需求条目多，牵涉范围广，随项目实际情况不断更新，变更时间紧。在需求管理中存在的常见问题[3]，一是需求不明确，用户对产品的需求定义不明确，或者收集需求时解读需求出现解读错误、遗漏，导致后续产品开发过程频频变更需求。二是需求追溯困难，来自客户的需求多为企标、国标、技术规格要求等，常以word格式或者pdf格式提出，需求范围过大，梳理困难，需求的划分界限模糊，需求验证易遗漏。三是项目时间紧张导致需求的细致程度不足，需求的细致程度很难掌握。四是需求变更频繁，需求变更在产品开发中是必然存在的，频繁的变更需要更完善的变更管理及良好的沟通机制。

传统的需求管理工具多为文本文档或表格，存在以下问题：一是需求存储时版本多，需要有专人管理各个版本的需求，工程师从特定人员处获得某版本的需求，浪费人力。二是追溯困难，通过在需求后加备注说明的形式进行追溯，容易出错并且多层次需求的组织结构显示不直观。三是需求变更时对人工操作依赖太多，多个变更流程同时进行时流程复杂，出错概率大大增加。四是需求存储常以复制副本方式进行备份，对版本共享造成不便。五是权限分配难细分，修改需求时常常是串行工作，甲和乙无法同时编辑，或者甲无意间篡改了乙的内容，导致需求内容出现差错。

2 功能安全标准对软件安全需求的要求

ISO/FDIS 26262是以IEC 61508为基础[4]，为满足道路车辆上特定电子电气系统的需求而编写，适用于道路车辆上特定的由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。ISO/FDIS 26262-8在6.4 Requirements and recommendations章节中提出了企业在进行车载ECU软件开发过程中对软件安全需求的要求。软件开发参考阶段模型见图1，技术安全概念、测试要求、设计阶段验证是软件安全需求的输入，安全需求是进行软件架构设计的重要前提[5]。

图1 软件开发参考阶段模型

在需求管理下的安全需求应有如下特性：

a）需求的描述应明确，没有歧义。b）相关者对需求的理解能达成共识。c）一条需求不能被划分为两个以上的独立安全需求。d）内在一致性，每个单独的安全需求不包含自相矛盾的内容。e）在项目开发的条件限制(资源、最新技术等)下，需求应可以在技术上实现，并且可以接受项目的约束条件。f）需求应该可以被验证，提供证据证明需求被满足。g）需求的必要性，如果它被移除或删除，就会存在产品或过程的其他能力不能满足的缺陷。需求适用于当前项目，不会随着时间的推移而过时，并应有符合预期的截止日期或适用日期。h）需求的目标是实现独立的执行，应避免对软件架构设计施加不必要的限制。i）需求的表述是清晰的，没有隐含进一步的扩展。j）需求应符合适用的政府、汽车行业、产品标准、规范和接口要求。安全需求的集合应具有如下特性：

a）分层结构，安全需求是由几个连续层面构建而成的，这些层面与相应的设计阶段保持一致。b)依据恰当编组原则建立有组织的结构。c)完整性，一个层面的安全需求完整的实施了前一层面的全部安全需求。d)外部一致性，多个安全需求不互相抵触。e)分层结构中任意一层的信息不重复，安全需求的内容不重复出现在分层结构同一层面的其它安全要求中，并且每个分层层面都是如此。f）可维护性，需求集合可以被修改或扩展，例如新版本需求的引入，或者在需求集合中添加/删除需求。

3 基于DOORS的软件安全需求管理活动实践

需求管理的传统方法，即依靠word或excel文件管理安全需求已远不能满足功能安全国际标准ISO/FDIS 26262对软件安全需求集合管理的要求，为了支持对安全需求的管理，ISO/FDIS 26262推荐使用合适的要求管理工具。IBM Rational DOORS是一款需求管理应用程序[6]，可以捕获、连接、跟踪、分析和管理用户需求信息以保证实施的项目与需求规格说明和标准一致[7]。以专业的需求管理工具DOORS替代传统word、excel方式进行需求管理，一方面符合ISO/FDIS 26262、第三方评审机构在认证评审中对需求管理工具的要求，另一方面可以实现需求细化存储、版本控制、方便评审、需求多层追溯、简化流程、权限细分，解决传统管理方式存在的一些问题。

3.1 评审安全需求

在需求开发完成之后，需要进行分配评审，DOORS管理每一条安全需求时以需求模块为管理单位，在模块中每条需求和其附属的属性以一行对象形式存储，层次清晰，方便评审。需求集合应满足如下要求：

a)在整个安全生命周期中保持不变的唯一标识。安全要求应是可追溯的，以ID号为需求的唯一标识。b)对需求内容的明确描述。c)明确主要责任人。d)与该需求有关联的关系追溯，例如安全目标分解成下一个层次的需求。e)该需求相关，必须提供的一些属性，例如ASIL等级、FTTI等。f)需求的实时状态。例如完全满足，正在验证，设计阶段，发起变更，正在评审，评审未通过，评审通过，未满足。g）需求模块拥有版本号，以区分不同需求版本。

3.2 安全需求追溯管理

使用DOORS工具进行需求管理，最大的优势在于维护不同层次需求之间的追溯关系。需求之间的追溯关系通过建立链接来体现[8]，分为模块内链接和模块间链接以及外部链接。链接指向的常用规则是，由底层需求指向上层需求，例如测试项指向功能块，功能块指向TSR，TSR指向FSR，FSR指向最顶级的需求安全目标SG。

链接建立完成之后，DOORS会自动建立一个链接模块，和已建立的正式模块并列存储，存放链接的信息。链接模块是需求之间建立追溯的前提条件及重要追溯工具。

3.3 使用基线

使用基线可以有效备份多个版本，为提高管理效率，需要定期创建模块的基线，每次变更涉及到的模块需要打基线，使用基线时应描述变更内容。基线是模块的只读版本，复制基线时，将创建新模块，新模块可以复制基线中的所有信息，新模块与基线包含的数据完全相同，新模块不包含任何历史记录信息和任何链接。

3.4 变更评审

安全需求的变更，是多方共同协商认可的结果，因此变更过程及结果需变更发起人通知所有相关方。开展需求变更分析[9-10]，分析结果应明确变更相关的任务，并评估完成变更相关任务所需资源及工作量，需求变更分析将有助于领导层作出更适宜的决策。需求的变更引起需求版本的更迭，需求储存在模块中，模块的版本管理通过基线实现。变更验证需比较同一个模块两次基线之间的不同，可以使用DOORS工具提供的过滤器或者基线比较功能，或者模块比较功能。

3.5 权限控制

DOORS工具支持对需求管理进行权限细分，不仅可以对模块进行权限分配，更可以对每一行对象进行人员权限控制，允许多人同时编辑，权限分配可做到极为精细，节省大量人力物力。

4 结语

需求管理是开启嵌入式系统软件开发工作的前提条件，贯穿于整个项目生命周期中，基于 DOORS工具的软件安全需求管理，可以提高安全需求管理效率，解决了需求管理的细分、追溯、版本控制、权限控制等问题。基于DOORS工具的软件安全需求管理，应遵循ISO/FDIS 26262的指导思想，才能在需求管理中充分实践发挥作用，缩短理论和实践之间的距离。