汽车电子嵌入式MBD开发软件质量探究
1.简介
汽车电子嵌入式软件开发方式是多样性的，其中，基于模型的开发(Model Based Design:MBD)经常用于复杂逻辑设计场景下的嵌入式软件开发中，比如车载控制器状态机、智能车辆动力学以及运动控制等，随着MBD开发技术的高速发展，其也不断的下探到汽车嵌入式开发的不同领域。基于MBD的软件开发有其自身一套非常成熟且高效的开发流程，但是在整个MBD软件开发过程中，其软件质量的保证是非常重要的，软件质量的考究和提升始终是软件开发生命周期中重要的一环。在整个MBD软件开发过程中保证软件质量需要考虑的方面很多，尤其是基于ASPICE方法论下的软件质量，本文从以下几个方面来探究MBD软件开发过程中的软件质量。
- 追溯性和一致性:需求、设计以及验证之间的追溯性和一致性
- 模型规范化和质量：构建模型的规范化、模型的质量
- 生成代码的质量度量：符合静态代码规则以及安全性要求
- 工作产物的质量：软件需求、架构、详细设计、测试用例
1.1 MBD软件开发流程
首先，分析系统需求(含 功能安全技术安全需求TSR)和软件需求、系统架构和软件架构；
其次，从这些输入中设计好整个模块的功能逻辑，以控制器状态机(Non-Functional Safety)为例，通过需求和架构的分析,梳理清楚涉及到的信号接口、状态跳转条件、状态执行，在详细设计文档中进行功能逻辑的设计，包括: 输入/输出/标定量/NVM变量的数据类型、初始值、精度、数值范围、偏移量等；软件架构中的静态行为/动态行为分析；详细的功能逻辑设计以及验证准则；
随后，根据详细设计文档进行功能逻辑模型设计，包括数据字典，通用库模型等的设计
最后，对搭建好的功能逻辑模型进行编译、模型规范检查、生成代码以及A2L(针对封装好的底层，不需要再次集成底层代码的，会直接生成可刷写文件.S19或.Hex)、对生成的.c代码进行静态代码检查(MISRA C, CERT C),通过设计Testcase进行模型单元测试来验证模型设计是否符合软件需求。
图1. MBD开发流程
1.2 V模型软件开发
谈到汽车电子软件开发，就离不开V模型设计方法，由于现在汽车电子嵌入式开发考虑到功能安全的设计，以及越来越注重信息安全的建设，V模型开发完全可以覆盖功能安全和信息安全开发，遵循的开发流程大致相同。
图2. V模型开发
1.3 V模型开发过程工具链部署
整个V模型过程中，针对软件开发测试验证活动，需要部署大量的工具来高效的实现软件开发、保证软件质量，尤其是在越发复杂的软件开发场景下，客户需求、系统需求、软件需求、架构、详细设计、测试用例等输入输出物多且复杂，需要利用工具来对其进行管理、分析以及追溯，下图是比较主流的工具，能够很好的实现软件开发过程中的追溯性和一致性。
图3. V模型软件开发过程中工具链部署
2. 系统与软件需求
通过对客户需求的分析得到系统需求，加上平台化的部分系统需求整合成功能模块/组件的Functional以及Non-Functional系统需求，如果针对该功能模块/组件有功能安全或信息安全的要求，可以将功能安全/信息安全的需求融合在整个系统需求中，也可单独一份文档作为系统需求的补充，在后期进行双向追溯的过程中考虑高效性和可靠性。
软件需求是针对系统需求进行一个更加细化、逻辑性更强、需求信息更加明了的完善过程，通过对系统需求、系统架构、软硬件接口HIS等的分析对功能模块/组件进行条目化的设计软件需求。
系统需求和软件需求都应该具备以下特性：
- 清晰易理解:清晰易懂的描述需求，不应模棱两可
- 原子化:颗粒度
- 一致性:ASIL等级、软硬件接口定义、平台定义等需要一致
- 可验证:能够通过采用不同测试方法进行验证，如无法验证，能够通过专家评审的方式确保其无风险
针对系统需求和软件需求应该定义好其各项属性，比如:功能属性(功能需求/非功能性需求), 测试层级(系统测试/软件测试), ASIL等级(QM,A,B,C,D),状态(Draft/In Review/Reviewed/Release)
对每条系统需求和软件需求能够遵循固定的明确的句式结构，尤其是软件需求，从软件质量和软件开发角度看，其句式结构中需要包含需求前置条件、信号、确切词等，在软件需求中应该能够通过不同的标识来区分变量和标定量，与此同时，制定清晰的验证准则。
系统需求和软件需求需要实现条目化的追溯，以保证系统需求和客户需求、软件需求和系统需求的一致性。
图4. 需求分解
3. 系统架构设计
系统架构的设计需要充分分析系统需求，梳理出功能软件系统需求和非功能软件系统需求所要考虑的点，从静态行为和动态行为规划好整个系统架构的设计。
系统架构的静态行为能够从功能Feature、模块Module以及组件Component进行逐层分解，Feature之间的逻辑接口、物理接口并且能够在组件之间定义好接口，全面的描述清楚各个功能软件对象的接口:
- 物理接口:通讯方式，控制方式
-
详细地设计出功能Feature、模块Module以及组件Component的输入输出接口，其需要包含:
- 数据类型；初始值；维度；数值范围；偏差；精度等
- 全局变量，配置量
- 标定量: 故障阈值、功能启动/关闭阈值等
其动态行为应该能够充分地体现出各个组件的控制流信息、数据流信息，尤其是针对组件中的功能能够清晰的描述清楚其动态活动并且定义好其需要实现的目标，例如，电池管理系统的上下电状态机管理，既能够描述清楚状态跳转条件的数据流信息，也能够描述清楚各个状态下需要进行的活动；其系统架构的动态行为描述的整体目标:
- 控制流信息贯穿整个系统架构各个功能模块组件
- 数据流信息贯穿整个系统架构各个功能模块组件
- 利用状态机活着时序图描述控制流动态行为
如果系统和功能安全、信息安全相关，则需要在常规的功能性系统架构中增加功能安全和信息安全的静态行为、动态行为，进行相应的安全分析:
- FMEA/FTA分析
-
DFA分析
- 随机硬件失效
- 故障处理
- 热失效
图5. 系统架构设计
4. 软件架构设计
软件架构更多的是需要通过对软件需求(客制化与平台化)的分析后对具体的软件单元进行架构设计，其要覆盖的内容和系统架构相似，同样需要对静态行为和动态行为进行描述，尤其是控制流贯穿在功能软件单元中，整体的软件架构设计内容和系统架构大致相同，其描述需要更加的条目化和原子化，此处不再赘述，不同的一个需要重点考虑的是其需要进行资源消耗管理，从动态行为层次上进行资源消耗的优化:
- RAM,ROM,NVM,堆栈
- CPU Loading
- Runnable(Trigger or Periodic)
图6. 软件架构设计
5.软件详细设计
经常会遇到一个大的疑问，基于模型设计的软件开发还需要进行软件详细设计么，从ASPICE和VDA软件质量的要求来说，其并没有强制对模型设计的开发方式进行详细设计，但是基于VDA中关于基于模型设计的软件详细设计打分规则[MBD.RL.1] -[MBD.RL.5]以及大众汽车集团KGAS[A:KGAS_3455]中的规定，明确的建议基于模型设计开发的软件需要进行详细设计，而且随着软件的功能越来越复杂，设计逻辑越来越复杂，需要有更加详细设计的文档进行软件功能策略的描述，其应包含:
-
软件单元接口定义: 数据类型；初始值；维度；数值范围；偏差；精度等
- 输入输出信号
- 标定量
- EEPROM Data
- Runnable(Trigger or Periodic)
- 数据流
- 控制流
-
软件单元详细设计
- 控制策略
- 验证准则
- ASIL等级
- 追溯性
图7. VW汽车KGAS
6.功能软件模型构建
在软件需求、软件架构和软件详细设计完成或，对整个功能组件中的软件单元进行模型构建，完成逻辑功能设计。目前汽车电子嵌入式MBD开发基本上基于MATLAB/Simulink/Stateflow进行建模，在进行功能软件建模过程中，需要遵循MAAB建模规范，整体上的要求:
- 可理解:模型构建能够基于MAAB规范化使用模块、语句等，复杂逻辑能够加上相应的文字说明
- 一致性:和软件需求、软件架构、详细设计保持一致
- 简洁性：建模整洁，信号交叉少
- 模块化:模块化建模
- 封装化: 将具有可封装的模块进行封装，简洁且易于理解
- 可维护性: 遵循MAAB规范
由于在MATLAB/Simulink/Stateflow中对软件单元进行建模，软件详细设计文档可能在Word或ALM工具平台(PTC,Polarion,Confluence)上进行，二者处于隔离的状态，追溯性操作在一定程度上具有难点，需要将软件单元和详细设计进行条目化的追溯，以确保两者之间的一致性，目前业界实现追溯的方式有两种:
- 通过在MATLAB/Simulink/Stateflow构建的模型中进行标记Tag的方式，将软件详细设计条目的ID标记在相应的软件单元模型中:
图8. Tag标记进行追溯
- 通过部署在Polarion中的三方插件Polarion Connector for Simulink®进行追溯:
图9 . Polarion插件进行追溯
在完成软件单元模型构建后需要进行模型静态检查，基本上基于MAAB以及组织级自定义的一些建模规范进行检查，当然，在生成代码后，会对生成的代码进行MISRA C规范化的检查，如果涉及到信息安全的代码，会进行CERT C代码规范扫描。
图10 . MAAB模型静态检查以及代码规范检查
7.模型单元验证
在模型构建以及规范化检查完成后，会进行模型单元测试验证，通过在MATLAB/Simulink/Stateflow中进行软件单元逻辑验证，最终生成单元测试报告，整体的流程大致如下:
- 分析软件需求和详细设计，制定模型单元测试用例，必须覆盖到所设计的软件单元；
- 单元测试用例评审，主要从用例的设计方法上以及追溯性上进行检查，需要应用边界值、等价类、错误值设计方法进行软件单元测试用例设计，对测试用例进行追溯性和一致性检查；
- 在MATLAB/Simulink/Stateflow中生成TestHarness测试床，随后导入单元测试用例进行单元测试执行
- 经过单元测试发现的软件Bug进行Bug修复，如果分支覆盖率未达到要求，需要分析原因，实在无法达到的需要详细地记录，能够通过优化测试方法或者测试用例的，需要再次进行单元测试，最终达到分支覆盖率，最后生成测试报告
图11 . MAAB模型单元测试流程
8.总结
- 规范化进行MBD软件开发
- 部署工具链来确保软件开发全生命周期的追溯性和一致性
- 系统架构和软件架构充分的描述清楚静态行为和动态行为
- 有条件的进行代码的规范性检查，包括MISRA C、CERT C代码扫描
- 针对MBD软件开发下软件单元的功能逻辑充分地进行详细设计
参考文献
- ASPICE 3.1
- Polarion: https://polarion.plm.automation.siemens.com/
- Autosar: https://www.autosar.org/
- Mathworks: https://www.mathworks.com/products/matlab.html
- CERT: https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards
