我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。
老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：
屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。
时间不知不觉中，快要来到深秋。国庆假期结束，又开始新的忙碌。成年人的我也不知道去哪里渡自己的灵魂，独自敲击一些文字算是对这段时间做一个记录。
本文分享电子电气架构—符合ASPICE 4.0 之软件开发流程（SWE)。
1、ASPICE介绍
ASPICE是Automotive SPICE的缩写，是一种用于评估和改进汽车软件开发过程的国际标准；ASPICE定义了一组标准化的软件开发过程和最佳实践，适用于整个软件生命周期，包括需求工程、软件设计、编码、测试和维护等各个领域。
通过规范化开发过程，ASPICE有助于提高软件产品的质量和可维护性，确保软件符合质量要求；同时对于开发者来讲，ASPICE的实施要求团队具备一定的技能和知识，这促进了团队技能和专业知识的提升，同时也促进了组织内的知识和经验的共享。
各家OEM与Tire1等可以去花费一定成本去做ASPICE评审，以彰显自家公司对于软件开发过程管理和实施能力水平。
评审的等级是基于ISO/IEC 15504的能力成熟度模型，对汽车软件开发过程的成熟度进行划分的。
ASPICE评审等级通常划分为以下六个等级，每个等级代表了不同的水平层次，目前行业内达到L1~L2的较多：
-> Level 0 - 未实施；
-> Level 1 - 执行；提供基本的项目管理和开发活动，但缺乏系统的管理；
-> Level 2 - 管理了过程的执行；企业不仅能够完成产品研发相关工作，还能提前制定严谨和周全的工作计划，确保各项目能够有序进行；
-> Level 3 - 定义了过程的执行；软件开发过程在组织范围内得到了定义和标准化，符合需求和目标；
-> Level 4 - 量化了过程的执行；软件开发过程的绩效进行了量化，通过数据分析和评估改进；
-> Level 5 - 优化了过程的执行；软件开发过程持续改进，并与组织的业务目标和策略相一致。
二、SWE介绍
ASPICE过程参考模型
作为汽车软件开发工程师，应该了解并尽量遵循SWE过程，不仅有助于提高软件质量，还能够降低开发成本、缩短开发周期，并增强软件的可维护性和可扩展性。
ASPICE SWE（Software Engineering Process Group，软件工程过程组）是ASPICE中的一个关键部分，它涵盖了软件开发的多个阶段和流程。SWE过程组的主要目标是确保软件开发过程中的各个阶段都遵循最佳实践，以提高软件质量、减少开发风险，并满足汽车行业的严格要求。
三、SWE.1
软件需求分析；目的是建立一套与系统需求和系统架构一致的结构化和分析的软件需求。
对应这一部分的开发者，应该接收来自SYS.2、SYS.3的输入，即系统需求和系统架构设计。
需要完成六项BP（Base Practices 基础实践；ASPICE各项流程均定义了不同的BP，需要开发者遵守并完成）：
-> Specify software requirements. 定义软件需求
-> Structure software requirements. 结构化软件需求
-> Analyze software requirements. 分析软件需求
-> Analyze the impact on the operating environment. 分析需求在操作环境中的影响
-> Ensure consistency and establish bidirectional traceability. 确保一致性和双向可追溯性
-> Communicate agreed system requirements and impact on the operating environment. 与利益相关者对系统需求及其影响沟通达成一致
举例说明，以车身控制中外灯系统中的近光灯部分需求点为例，SWE1对应描述如下：
SW_REQ-10001 若整车电源模式是ON，车辆应在打开近光灯开关被按下时打开近光灯；
SW_REQ-10002若整车电源模式是ON，车辆应在关闭所有灯光被按下时关闭近光灯；
SW_REQ-10003车辆应为用户提供信息（近光指示灯）以提示近光灯的工作状态。
架构化需求及环境模块影响分析：
四、SWE.2
软件架构设计；目的是建立一个与软件需求一致的且分析过的软件架构，包括静态和动态方面。
该过程的输入既是来源于SWE.1。
5个BP说明如下：
-> Specify static aspects of the software architecture.定义静态的软件架构
-> Specify dynamic aspects of the software architecture. 定义动态的软件架构
-> Analyze software architecture. 分析软件架构
-> Ensure consistency and establish bidirectional traceability. 确保一致性并建立双向可追溯性
-> Communicate agreed software architecture. 沟通商定的系统架构
静态架构示意：
定义软件模块的静态信息，如接口名、信号名、模块名等；
继续以上述SW_REQ-10001~ SW_REQ-10003需求为例
动态架构示意：重点在于模块的动态交互、时序等逻辑体现
五、SWE.3
软件详细设计和单元构建；目的是建立与软件体系结构一致的软件详细设计，包括静态和动态方面，并构建与软件详细设计一致的软件单元。
输入来源于SWE.1与SWE.2；
同样包含5个BP：
-> Specify the static aspects of the detailed design. 定义软件详细配置
-> Specify dynamic aspects of the detailed design. 定义软件详细模块交互
-> Develop software units. 开发并配置模块单元
-> Ensure consistency and establish bidirectional traceability. 确保一致性并建立双向可追溯性
-> Communicate agreed software detailed design and developed software units. 沟通商定的软件详细设计和开发的软件单元
这一环节是对软件架构设计中的SW Component的进一步设计，同样的也包含了动态详细设计与静态详细设计两个方面；通常需要识别出SWE.2环节中设定的软件模块SWC中包含哪些子模块，不过，在通常的正向开发过程中，SWE.2执行过程已经完成这一步分析，如LoBeam SWC中包含了SW unit：电源判断模块 与 SW unit：灯光判断模块两个软件子模块；
-对SW uint进行更详细的设计：定义操作函数、设定或理解交互接口；
如果涉及到复杂的数据类型或者算法，也需要在这个环节完成；
六、SWE.4
软件单元验证；目的是验证软件单元是否与软件详细设计一致，提供证据证明软件单元符合软件详细设计和非功能软件需求；
该流程含有5个BP：
-> Specify software unit verification measures. 规定软件单元验证措施
-> Select software unit verification measures. 选择软件单元验证措施
-> Verify software units. 验证软件单元
-> Ensure consistency and establish bidirectional traceability. 确保一致性，建立双向可追溯性
-> Summarize and communicate results. 总结并交流结果
所要验证的对象来自于SWE.3的输出；根据BP，实际操作流程可以如下：收齐输入物（被测模型/代码），即SWE.1需求，与SWE.3代码/模型。搭建测试环境
在代码模型里模拟输入，观测输出；如在代码simulink模型中搭建测试module；
导入测试用例
首先要制定测试用例，以SWE.3中的模块为例，制定测试case；
执行测试
按照测试case执行测试代码+功能代码，记录测试结果；
针对测试结果及覆盖度结果补充测试用例
分析测试结果，同步的检查测试用例制定的完整性
回归测试
反馈测试NG项，待代码修改后回归测试
完整的流程过程物/输出物应该还包含详细的测试计划、测试报告分析等内容。
七、SWE.5
软件组件验证和集成验证；这一环节目的是验证软件组件与软件架构设计一致，并集成软件元素，验证集成的软件元素与软件架构和软件详细设计一致
该流程含有7个BP：
-> BP1: Specify software integration verification measures 指定软件集成验证措施
-> BP2: Specify verification measures for verifying software component behavior 指定验证软件组件行为的验证措施
-> BP3: Select verification measures 选择验证措施
-> BP4: Integrate software elements and perform integration verification 集成软件元素并执行集成验证
-> BP5: Perform software component verification 执行软件组件验证
-> BP6: Ensure consistency and establish bidirectional traceability 确保一致性并建立双向可追溯性
-> BP7: Summarize and communicate results 总结和交流结果
SWE.4与SWE.5均是做软件验证，区别就是范围不一样，SWE.4侧重于单个软件单元的验证，确保单元的正确性和质量；而SWE.5则关注于软件组件的集成和整体系统的测试，确保系统能够正确运行并满足需求。
SWE.5参考流程
SWE.5的关键输入即是SWE.2中的输出物–软件架构；软件集成后，按照SWE.2中SWC模块逐步进行测试即可；测试过程与相关过程物类型与SWE.4接近，此处不再举例。
八、SWE.6
软件验证；确保集成的软件与软件需求一致，也叫软件合格性测试
该流程含有5个BP：
-> BP1: Specify verification measures for software verification 规定软件验证的验证措施
-> BP2: Select verification measures 选择验证措施
-> BP3: Verify the integrated software 验证集成软件
-> BP4: Ensure consistency and establish bidirectional traceability 确保一致性并建立双向可追溯性。
-> BP5: Summarize and communicate results 总结并沟通结果
该环节的输入主要来源于上级SYS.1中的系统需求与SWE.1中的软件需求；
SWE.6与SWE.4、SWE.5同属测试范畴，为了更好的区分，特意做出如下对比：
SWE.6参考执行流程
以SWE.1中软件需求SW_REQ-10001为例，验证用例和测试结果记录表格可参考如下：
九、总结
遵循ASPICE开发流程，既要有专业化知识，还要有标准化流程，专业化知识包含了专业的汽车电子技术、编程能力、专业工具使用能力等；标准化流程即是各家主机厂或者供应商根据ASPICE流程制定各家专属的开发流程及各个流程对应产出物；
有一点贯穿整个软件开发过程，并且在评审过程中也会相当注重的，就是追溯性；
双向追溯
-> 1)V模型左边的需求、设计和实现之间
-> 2)V模型左边的需求设计实现与V模型右边的测试规范（或测试用例）之间
-> 3)测试用例与测试结果之间
-> 4)变更与变更影响的工作产品之间
因此，除了功能实现，体现追溯性的各环节文档与工具等要做好记录与管控，实现符合ASPICE流程的标准化开发。