基于模型开发场景时，实施ASPICE的常见疑问
来源：公众号“汽车电子与软件”
2021-07-21
1502
以下文章来源于仨人谈起 ，作者庞伟
随着车载娱乐系统以及ADAS的持续火爆，软件在汽车上的占比越来越重，代码量不断增长。手工编码过程的固有复杂性，使得维护软件产品变得十分困难。可以想象，如果几千万行代码都是手工编写和维护，那会有多大的难度和工作量。
越来越多的OEM和供应商开始不断地应用基于模型开发(MBD)的方法来开发软件。同时OEM及供应商在软件质量管理上也不断增强，ASPICE越来越被广大汽车行业的供应商所应用。随之而来的出现了许多在MBD场景下，实施ASPICE的疑问。本文将就这些疑问和大家做一个探讨。MBD方式是完全可以满足ASPICE要求。VDA Guideline中明确说明MBD是可以支持系统和软件的开发的。VDA Guideline中给出了在MBD方式下，实施ASPICE的一些要求。[MBD.RL.1]若没有定义模型的使用场景，且有较大影响，应该降低打分。例如在什么情况下(APP层开发)或哪些活动(如详细设计)，使用了MBD开发方式，需要被定义。[MBD.RL.2]若没有定义所使用模型的语法和语义，且有较大影响，应该降低打分。- 通常需要额外的信息描述，对模型内容进行补充说明，如设计思路，设计决策等
[MBD.RL.3]若模型的补充信息是缺失或不足的，且有较大影响，应该降低打分。[MBD.RL.4]若模型的补充信息是记录在模型里面的，则不应该降低打分。如：在使用Matlab/Simulink建模时，将输入/输出信号的含义、数据类型、范围等记录在模型中[MBD.RL.5]如果在后续的开发阶段，没有参照模型的补充信息，且有较大影响，应该降低打分。[MBD.RL.6] [MBD.RL.7]需要确保用于代码生成的模型需要符合输入的详细设计及非功能性的软件需求，且需要对生成代码的模型进行静态验证和单元测试。[MBD.RL.8][MBD.RL.9] 对于模型生成的代码，如果不进行手工的修改，则在评估中不应该扣分。[MBD.RL.10][MBD.RL.11] 对于模型生成的代码，如果进行了手工的修改，则必须与手工编码类似，对代码进行静态检查和单元测试。业界的相关标准规范中，均没有统一的给出上述问题的答案。当模型不能体现全部内容时，通常需要单独的建立详细设计文档或在模型中增加说明性的内容。- 详细设计的目的是展示软件单元及内外部关系，包括设计思路以及设计决策。
- 如果模型能够达到这个目的，则没有其它形式的详细设计，是可以接受的。
- 有些时候，特别是SW Component的内部结构比较复杂的场合，模型很难达到上述目的，就需要采用其他的文档对详细设计进行描述。
目前从各OEM和供应商的要求来看，很多情况下是要求其开发团队要做单独的详细设计的。The software detailed design must also be created in case of graphical respectively model-based programming. [A: KGAS_3455]- MathWorks Automotive Conferences 2016上的分享资料“Software Detailed Design for Model-Based Development – Obligatory or Superfluous?”
疑问3：MBD开发方式下，需要关注编码规范还是建模规范？毫无疑问，MBD开发方式下，当然是建模规范。对于模型生成的代码通常可以不考虑编码规范。- 供应商必须分析和评估现有的建模规范是否适用于项目。分析时要考虑项目适用的MISRA规范和工具制造商的指南。并将分析和评估的结果进行定义（如：形成自己的建模规范）[A: KGAS_3861] [A: KGAS_3862] [A: KGAS_3863]
- 所有的与建模规范的偏差，都需要有合理的理由并进行文档化。[A: KGAS_3886]
采用MATLAB/Simulink进行模型开发时，通常采用以下建模规范：- First version released in April, 2001
- Collaboration by industry leaders in US, Japan,Europe: GM, Ford, Chrysler, Toyota, Daimler, John Deere, Delphi, Ricardo andothers
- Modeling Guidelines for High-Integrity Systems
- Leverage industry-best practices and MathWorks tool expertise when developing high-integrity systems
- ISO 26262, IEC 61508, DO-178B/C, and MISRA-C
疑问4：MBD开发方式下，对于软件单元的度量指标如何考虑？比如圈复杂度，还需要考虑模型生成的代码的圈复杂度吗？通常的标准是需要定义相应的模型的度量指标要求，但具体的指标及相应的目标值目前还没有明确的标准。可以考虑的度量指标包括模型复杂度、模型层次等。- MBD开发方式下，必须应用具有定义边界的适当模型度量（具体采用哪些度量，大众没有给出明确的要求），模型度量的选择和适当性必须合理（如，体现在相应的策略文件中）[A: KGAS_3865] [A: KGAS_3866]
- 如果由于项目特定的原因，有必要偏离模型度量或违反定义的限值，则必须对其进行评估，并给出可接受的理由，同时必须采取适当的措施来确保模型质量。[A: KGAS_3902] [A: KGAS_3867]
- 具体到圈复杂度来说，通常只关注模型单元的复杂度，可以不考虑生成的代码的复杂度。关于该要求，在VDA Guideline的[MBD.RL.8] [MBD.RL.9]中已经提及。
注：关于模型生成的代码，在大众KGAS早期版本(V3.1以前)的要求中，是要求遵守相应的代码度量指标的，不过在KGAS的新版本中，已经删除了该要求。疑问5：在MBD开发方式下，单元测试是针对模型还是针对代码？在MBD开发方式下软件单元的设计、验证和构建是融合在一起的，需要在模型和代码层面分别实施适当的测试。针对模型的测试，与传统的手写代码的测试目的相同，验证模型是否满足其输入（需求或详细设计），需要根据模型的输入（需求或详细设计）设计相应的测试用例，需要确保测试的覆盖度。针对代码的测试，主要是验证代码与模型之间等效性的背靠背测试。疑问6：Simulink Design Verifier生成的测试用例能满足单元测试的要求吗？DesignVerifier生成的测试用例是对模型的逻辑进行分析，达到对各种条件的覆盖执行，目的是排除一些越界、除零、死逻辑等问题。而单元测试中的大部分工作属于功能测试范畴（是否满足其需求或详细设计）。疑问7：模型层面的集成测试是否可以替代代码集成测试？Simulink环境可以对接口、数据类型等内容进行测试，但无法仿真代码中的抢占、中断等行为。以上是目前MBD开发在ASPICE实施过程中，常见的一些疑问，希望能够解决广大MBD开发及ASPICE爱好者们的问题。
