汽车嵌入式系统的 ASPICE（Automotive SPICE）评估，核心是看开发过程是否规范、受控、可重复，并能持续交付满足质量要求的软件/系统。可以从下面几个维度把握要点：

一、基础：过程与能力等级认知

ASPICE模型结构：

过程域（Process Areas）：如系统工程、软件工程、支持过程等；

过程能力等级（0–5级）：从“不完整”到“持续优化”。

嵌入式特点：软硬一体、实时性、功能安全（ISO 26262）、OTA、信息安全等，需要在各过程域中体现这些约束。

二、项目管理类过程要点

1. MAN.3 项目管理（Project Management）

计划与估算

是否针对嵌入式项目制定完整计划：需求开发、软硬件设计、集成、测试、标定、路试、产线验证等；

工作量和进度估算是否合理，有无考虑硬件资源、芯片交期、台架/试验场资源。

监控与风险

是否有机制跟踪进度、成本、关键里程碑（如首版样件、DV/PV试验节点）；

风险清单是否覆盖：硬件选型风险、芯片供货、RTOS/驱动兼容性、功能安全目标达成风险等。

2. ACM.3 配置管理（Configuration Management）

版本控制

代码、模型（Simulink/ASCET）、Makefile、编译脚本、硬件原理图、BOM、标定数据是否统一纳入配置库；

分支策略是否清晰（如开发分支、发布分支、补丁分支）。

变更与追溯

代码/硬件变更是否走评审、影响分析（尤其是涉及接口、时序、内存布局的变更）；

能否追溯到对应需求/缺陷记录。

三、工程类过程要点

1. SYS.2/SYS.3 系统需求与系统设计

需求质量

系统需求是否覆盖功能、性能、接口（CAN/LIN/Ethernet、电源、IO）、环境（温度、振动、EMC）、安全目标、信息安全、诊断/刷写、法规等；

是否可验证（如“启动时间<200ms”“CAN通信误码率<10⁻⁷”）。

系统架构设计

软/硬件划分是否合理：哪些放MCU/SoC，哪些用外设+驱动，哪些在应用层；

是否定义关键机制：任务调度/优先级、中断/事件模型、内存分区、看门狗策略、安全岛/安全相关分区。

2. SWE.1–SWE.6 软件工程全过程

SWE.1 软件需求

从系统需求分解到软件需求，是否明确：功能行为、接口协议、时序约束、错误码/异常行为、资源占用（RAM/Flash/CPU负载）。

SWE.2 软件架构设计

模块/组件划分、接口定义、调用关系、数据流向是否清晰；

是否考虑：可测性（预留测试点/模式）、可维护性、重用性、安全/非安全分区隔离。

SWE.3 软件详细设计

函数/任务级设计：算法实现、状态机、数据结构、关键计算路径；

对关键实时逻辑，是否说明执行时间、堆栈使用、并发/竞态处理。

SWE.4 软件单元实现

编码规范（MISRA C、AUTOSAR C++14等）是否落地，静态检查工具（Coverity、Polyspace等）结果是否被管理；

注释、命名、模块化是否符合团队/项目标准。

SWE.5 软件单元验证

单元测试覆盖率：语句/分支/MC/DC是否满足要求（如安全相关代码要求MC/DC≥95%）；

是否对边界条件、异常输入、故障注入场景进行验证。

SWE.6 软件集成与集成测试

按架构层次逐步集成：驱动→中间件→应用；

验证模块间接口、协议一致性、任务间同步/资源竞争、实时性、内存溢出/泄漏。

3. SPL.2 产品集成

软硬件联合集成流程是否定义：

板级测试（电源、时钟、复位、外设功能）、HIL（硬件在环）测试、实车/台架联调；

是否管理好：

软硬件版本匹配、标定数据版本、生产工具链（刷写/检测设备）版本。

四、支持类过程要点

1. SUP.1 质量保证（Quality Assurance）

是否对各过程进行独立/受控的质量审计：

查计划 vs 实际、查过程是否按约定执行、查工作产品是否合规；

对发现的不符合项，是否形成闭环：整改、验证、再评估。

2. SUP.8 配置管理（已在前文结合说明）

特别要关注：

自动构建/持续集成的产出物（elf、hex、map文件、标定文件、测试报告）是否受控归档。

3. SUP.9 问题解决管理

问题/缺陷从发现、记录、分析、修复、验证、关闭是否全链路可追溯；

对安全/严重问题，是否上升到问题审查委员会，并评估对功能安全/项目节点的影响。

4. SUP.10 变更请求管理

所有变更（需求、设计、代码、硬件、工具链）是否走统一CR流程；

是否评估影响：功能、性能、安全、成本、交期，并由授权人决策。

五、嵌入式特殊关注点

1. 功能安全与信息安全

若项目适用 ISO 26262，需检查：

安全需求是否从系统逐层分解到软件/硬件；

安全机制（冗余、监控、看门狗、ECC/CRC、安全启动、访问控制）的设计、实现、测试是否到位；

安全案例/安全档案是否完整，支持评估与认证。

信息安全（如 SecOC、加密/签名、安全刷写、入侵检测）相关需求、设计、实现、渗透/模糊测试是否纳入过程。

2. 实时性、资源与平台依赖

评估过程中应看到：

对关键任务的执行时间、周期、抖动分析；

RAM/Flash/CPU负载评估与余量分析；

对特定芯片/RTOS/编译器/外设驱动的依赖是否有管理（如芯片停产、BSP升级、编译器新版本带来的行为变化）。

3. 测试环境与自动化

是否建立：

单元测试、集成测试、HIL、SIL/PIL、实车/台架测试等分层测试环境；

自动化测试框架与CI流水线，对提交进行自动构建+单元/接口测试+静态分析。

六、评估实施与证据准备

证据类型

计划/规程：项目计划、V&V计划、配置管理计划、安全计划等；

工作产品：需求文档、设计文档、代码、模型、测试规范/用例/报告、问题单、变更记录、审计报告；

工具链与记录：CI日志、静态分析结果、覆盖率报告、HIL测试报告。

评估方法

访谈：项目经理、系统工程师、软件工程师、测试负责人、质量/配置管理人员；

文档审查 + 现场演示：如展示一个需求从提出到实现、测试、问题修复、变更的全链路追溯。

七、常见薄弱点与改进建议

需求可验证性差、缺量化指标；

测试覆盖不足，尤其对异常/故障/边界场景；

配置管理混乱，软硬件/标定/工具链版本对不上；

安全/实时/资源分析停留在“经验值”，缺乏系统方法；

问题/变更未形成有效闭环，导致同类问题重复出现。

改进方向：

在早期就引入ASPICE与功能安全要求，做过程策划；

将工具链（需求管理、建模、代码/测试/静态分析、CI/CD）与过程强绑定；

用度量数据（缺陷密度、测试覆盖率、需求实现率、问题关闭周期）持续评估并优化过程。