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

• 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）与过程强绑定；

  
  

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

  
  

推荐阅读：

亚远景-配置管理与ASPICE评估的契合点分析

亚远景-ASPICE评估：汽车软件开发过程评估的方法与经验总结

亚远景-ISO/PAS 8800与全球汽车AI监管趋同下的中国企业合规策略与技术适配

亚远景-ASPICE与ISO 26262：汽车软件安全与质量的双标

亚远景-ASPICE评估：汽车软件开发过程评估的有效方法

亚远景-ISO 26262与ISO 21434：汽车安全标准的双基石

推荐服务：

点击查看亚远景ASPICE咨询、评估、“认证”、培训服务

点击查看亚远景ISO26262咨询、认证、培训服务

点击查看亚远景ASPICE、ISO26262培训课程

点击查看亚远景ASPICE、ISO26262实施工具-APMS研发过程管理平台