2020年12月23日，中国汽研成功举办《2020第三届新能源汽车测试评价技术国际论坛》。中国汽研将持续为大家推送精彩演讲实录，本文为贝腾软件科技总经理刘春晓带来的《拥抱需求驱动，新能源汽车功能安全落地一站式最佳落地方法》。

1 背景 

随着软件驱动汽车时代的来临，不断增加的功能、系统、安全需求、自动驾驶等，使得软件复杂性急剧提升，在多场景下，如何确定需求测试的完整性是亟待考虑的。传统零部件和软件开发的区别在于硬件质量瑕疵可通过不良品率ppm量化，生产后的无瑕疵批次硬件依然可用，而软件开发发行后，由于是复制式部署，会影响所有最终产品。功能安全的作用主要体现在防范和监控方面。ISO26262于2011年正式颁布，聚焦两大问题，一是人为失误等导致系统性失效，二是电子件（硬件）随机失效，从组织成熟度、流程质量和产品质量三个维度进行把控，旨在提高汽车电子、电气产品功能安全。TS16949是针对整个组织的流程认证质量体系，ASPICE（汽车软件过程改进及能力评定）更多的聚焦于软件的过程品质，ISO26262聚焦于产品的安全，在相互穿插支撑整个产品实现的过程中需要一些文档来约束开发过程，确保产品吻合当前设计需求。

2 需求工程

ASPICE及功能安全落地的难点在于硬套模板、执行力虎头蛇尾、管理层志愿不足、对流程的理解和执行有较大偏差等，理解误差是开发过程中不可避免的，这些问题的核心点为需求工程，需求工程的目的是构建全体项目成员对开发内容的共通理解。需求的种类分为功能需求（描述系统的能力，在特定场景下系统的行为以及对于特定的外界激励如何响应），非功能需求（描述系统与功能无关的特质，比如代码质量、可用性、可扩展性、依赖性、可移植性、系统性能、强健性以及系统的开发成本、期限等），安全需求（源自于软硬件FMEA、FTA等，规定系统行为不得导致人身伤害的发生或者具有严重后果的系统故障）。需求获取方法包括头脑风暴、问卷、头脑风暴的悖论、变换视角、类比拆解、抽象建模快速原型、用例图等。

安全需求应当具备的特性包括用词明确（明确清晰的用词，一个词对应于一个概念），小颗粒度（一条需求处理事情的一个方面，一条需求不可细分为多条需求），自一致性（需求之间没有内在逻辑矛盾），可实施性（在工程限定条件之下可以得到实施），可验证性（定义需求时考虑到需求是否可以被验证）。

需求的基本属性（PUID：永久性唯一表记序列号；版本：方便变更管理时的可追溯性；描述：需求的文本表达），功能安全需求应当具有的属性（类别：安全需求、功能需求、非功能需求；ASIL等级：QM、 A、B、C、 D ；状态：建议、已确认、已拒绝、已评审、已实施、已验证）。

需求的管理贯穿整个系统生命周期。包括有层次有组织的结构：相应于产品（软件）的设计；完整性：每一层级的需求必须完整地实现其上层级的所有需求；一致性与非冗余性：必须贯穿所有的需求；可维护性：对需求的扩展，增补，删除进行管理；可追溯性：需求之间，与软件实现，与测试之间双向可追溯；配置管理：版本的明确定义与使用，历史版本可复现，版本的可追溯性。这些要求可以通过需求采集与管理工具辅助进行。

需求需要用文字的方式进行表达，国际需求委员会建议使用模板来表述需求会更加清晰（需求的非形式化语言模板）：

非安全需求和安全需求应该在系统中被隔离（非干扰），保持一定的独立性， 保证不会因为某一块的失效而导致安全目标被违反，同时非安全需求作为也需要遵循ISO26262相关要求。

系统和软件的功能安全产品开发的主要活动流程：

BMS功能安全需求例子 FSR（功能安全需求）：

BMS技术安全需求分析例子 TSR（技术安全需求）：在FSR的基础上进一步细化，通过TSR活动定义合理的安全机制来满足FSR；基于FSR的初步架构，在TSR环节部署元素和子元素，构建包含软硬件的技术架构；TSR需要指定元素的结构，行为，接口及交互。

BMS技术安全需求软硬件接口定义例子（HSI）：部署完各个元素的交互后，确定软硬件接口（HSI），为之后的系统集成打下良好的基础。

3 测试工程

功能安全测试的主要活动为 Verification & Validation + 量化结果。Verification：面向设计的验证（验证中间产物，比如设计文档，测试计划等；开发视点，上下工序的执行等），Validation：面向需求的验证（验证终端产品，如软件和系统需求等；客户视点，客户需求导向）。

软件单元测试测试方法包括基于需求的测试、接口测试、故障注入测试、等效性测试；测试用例制作包括需求分析、错误推测、等价类、边界值；测试覆盖率基准包括语句覆盖、判定覆盖、MC/DC覆盖。

软件集成和测试，集成测试包括测试计划和执行、测试用例生成、集成测试方法集、需求测试；集成测试方法包括基于需求的测试、接口测试、故障注入测试、等效性测试；测试用例制作包括需求分析、错误推测、等价类、边界值；测试覆盖率基准包括函数覆盖、函数调用覆盖。

软件单元测试的量化评估例子：

基于需求测试，也称为功能测试，是一种基于软件单元规格制定测试用例的质量保证（QA）手段。基于需求测试的目的是理解需求所定义的软件在各种场景下的功能与因果性，通过执行测试用例检查软件行为是否与软件规格一致。

在软件单元层级，接口测试通过测试接口变量的取值区间以及边界值来实施。接口测试的目的是根据软件单元的接口规格，通过测试保障软件单元接口的强健性。通过等价类分析、边界值分析进行接口测试。

故障注入测试通过故意导入故障来测试软件单元中实施的安全措施的有效性。目的是用于确认故障发生时软件单元的行为。通过将故障信号注入到被测软件单元的输入和定义系统的期待输出进行故障注入测试。

4 总结

ASPICE流程作为QM基础，构建企业标准流程，支持ASIL需求落地；ISO26262标准确保了面向于E/E系统的安全机制实现，在整个产品周期里，不仅包含了开发流程，也包含了技术的解决方案；需求工程是保证项目成功的关键要素，投入越多，总体成本越低，产品质量越高；测试工程的自动化是项目提质提效的关键手段；相对于硬件PPM的评估，衡量软件质量主要靠流程，文档和数据，有效性是重要考量指标；不存在“超人”必杀技，第三方咨询认证可提供外部智力辅助优化项目质量，提升产品力，然而企业内在的安全文化及持续的流程优化需求才是竞争力之核心。

返回第一电动网首页 >