也是在周六的ASPICE V4.0 Upgrade培训的课堂上，与一个具备CA资质的学员就设计、以及模型开发(MBD)时的MIL测试，做了一些讨论，讨论内容具备普遍性，整理出来，供读者参考。
学员首先阐述了如下的观点：
关于软件设计：
为满足ASPICE V3.1/V4.0的“SWE.2 Software Architectural Design”, “SWE.3 Software Detailed Design and Unit Construction”的要求，项目中的软件设计必须包括软件架构设计和软件详细设计
在ASPICE V2.5的时候，由于只有“ENG.5 Software design”，所以项目中可以只包括一份软件设计
关于模型设计和MIL测试：
模型开发(MBD)时，使用Matlab/Simulink所做的模型设计，不能满足“SWE.3 Software Detailed Design and Unit Construction”的要求，必须有一份软件详细设计
因为如果只有模型设计的话，MIL测试的依据如果只是这个模型设计，那就相当于在手写代码开发场合的基于代码来做单元测试，这是不合适的（如下图所示）
如上的内容，涉及到三个的话题，我们逐一讨论下。
Topic 1. 必须有软件架构设计、软件详细设计，才能满足ASPICE V4.0 SWE.2 / SWE.3的要求吗？
(1) “ASPICE模型要求”与“项目中的过程活动及工作产品”的Mapping
ASPICE模型中的所有要求，都是What层面的要求
项目中的过程活动的切分，各过程活动的输出工作产品，都是属于How，是依赖于组织及项目的具体Context来确定的
ASPICE评估时，评估师有责任进行如下的映射：
ASPICE中的Process (如：SWE.2, SWE.3) <--> 项目中的过程活动
ASPICE中的Work Product (V3.1)或Output Information Item (V4.0) <--> 项目中的工作产品
ASPICE PA培训/以及ASPICE V4.0 Upgrade培训中，对此有明确的说明，如下图所示：
(2) 软件设计的初衷
软件设计的目的，是“承上启下”，是软件需求和软件实现之间的桥梁，通过软件设计能使得软件内部的结构是清晰透明的、可管理可控的、可维护的
满足如上的目的，实际项目中可以存在如下情况：
复杂的软件，可能会是三层设计
通常的软件，恰好有两层是合计
简单的软件，可能会是一层设计
ASPICE PA培训中，有类似的示例说明，如下图所示：
文章写到这里，我想说一句玩笑话：是不是考虑对PA培训的内容，重修一下呢？
Topic 2. 模型开发(MBD)时，模型设计真的不能完全满足SWE.3的Detail Design的要求吗？
关于这个话题，请参考如下文章
当模型的规模较小，逻辑较简单时，模型设计也是可以作为Detail Design的
Topic 3: 模型开发(MBD)时的验证(Verification)
在这里，我们假设模型规模较小，逻辑较简单，在软件设计层面，只是包括软件架构设计和模型设计。如下图所示：
(1) 对需求及设计的“验证”
软件需求到模型设计，有如下三类转化(Transform)，为保证转化(Transform)的正确性和完整性，需要进行验证
【系统需求 + 系统架构设计】-> Transform To ->【软件需求】
验证活动：验证软件需求（上图中的黄色背景的活动）
验证对象：软件需求
【软件需求】-> Transform To ->【软件架构设计】
验证活动：验证软件架构设计（上图中的黄色背景的活动）
验证对象：软件架构设计
【软件架构设计】-> Transform To -> 【模型设计】
验证活动：验证模型设计（上图中的黄色背景的活动）
验证对象：模型设计
采用MBD方法的好处是：模型设计的验证方法，可以包括动态验证，即：通过运行模型来验证模型设计。
这可以满足ISO 26262:2018 Part 6 - Table 4中的要求“1c Simulation of dynamic behaviour of the design”.
(2) 对实现的“验证”
模型开发场合，通常不会对模型生成的Source Code进行修改和维护，修改和维护的对象都是“模型”。因此“模型”是设计，也是实现
对”实现(模型)”的测试
测试对象：模型
测试方法：MIL
测试用例的依据：模型设计的依据（即：分配给模型的软件架构设计和软件需求）+ 模型设计
这个部分，我再次请教了董淑成老师，董老师说：MIL测试用例的开发，首先是基于分配给模型的需求（即：黑盒测试），在执行MIL测试后，如果发现覆盖度达不到要求，则需要分析模型，看一下哪些地方没有被覆盖到，是设计有问题，还是测试用例不足，之后根据情况，补充测试用例（白盒测试），目的是提高测试的充分性。
【模型设计】-> Transform To -> 【Source Code】
如果工具是可信赖的，且模型生成的代码不会进行修改和维护，则这个步骤可以通过工具来保证，可以不验证。
26262标准中要求：ASIL C/ASIL D，需要通过Back-to-Back方式进行验证（模型和代码的等效性验证）。（图中所示的SIL Test / B2B Test）
(3) 与ASPICE的映射
模型开发(MBD)时，如果模型生成代码的工具是可信赖的，且模型生成的代码不会被修改和维护，则单元验证，可以只在模型层面来做。
VDA Guideline的相关Rules如下：
[MBD.RL.6] If there is no static verification and unit testing performed on code automatically generated from the model by a qualified tool chain (and without any modification after generation), then SWE.4.BP3 shall not be downrated.
如上示例与ASPICE Process之间的映射，可以如下图所示：
关于SWE.4的补充说明：软件单元验证的通常方法包括：Code Review, Static/Dynamic Analysis, Unit Test，但这不是绝对的。
可参考如下的VDA Guideline的Rules：
[SWE.4.RL.1] If it is made reasonably plausible based on context-specific arguments that a particular verification measure is not necessary, then SWE.4.BP1 shall not be downrated.
（-- 完 --）
先起公司近期公开课：
推荐阅读：
欢迎访问公众号菜单，下载文章合集
