在 ASPICE V4.1 过程框架中，SYS.3 系统架构设计承接 SYS.2 系统需求，向下衔接软件架构设计与硬件设计，是整车或系统项目从需求走向实现的第一层分解环节。系统架构需要回答系统由哪些组件构成、各组件承担什么功能、功能在软件与硬件之间如何分配、组件之间通过什么接口交互，以及关键架构决策依据是什么。架构阶段的划分结果会直接约束后续软件需求、硬件设计与系统集成，架构边界不清会在开发后期引发大量跨团队协调与返工。

SYS.3 的核心活动包括将系统需求分解映射到系统组件，明确每个组件的职责与约束，完成软硬件功能分配，定义组件之间的内部接口与对外接口，记录架构设计决策及其理由，建立系统需求到系统组件的追溯关系，并组织系统架构评审确认方案满足系统需求与设计约束。软硬件分配需要结合实时性、可靠性、成本与技术成熟度综合判断，安全相关功能的分配结果还要与功能安全概念保持一致。

实践中系统架构阶段常见问题集中在几个方面。组件职责交叉重叠，同一功能在多个组件间描述不清，后续软件与硬件团队对分工理解不一致。系统接口只标注信号名称，缺少数据类型、时序、通信方向、异常状态与容错要求。软硬件分配缺少依据记录，评估时无法说明为什么某项功能由软件实现、另一项由硬件承担。系统需求到架构组件的追溯只做单向标记，需求变更后受影响组件没有同步识别。架构评审缺少问题清单、讨论记录与整改闭环证据。

亚远景建议以工具体系固化系统架构阶段过程要求。APMS 过程管理平台承载系统架构描述、软硬件分配表、接口规范与架构决策记录的版本流转，评审任务与整改事项在平台内派发跟踪，架构工件状态与项目阶段保持同步。DPAI 垂类 AI 辅助工具在架构方案形成阶段辅助核查组件职责是否存在重叠与遗漏，比对系统需求条目与架构组件的对应关系，提示接口描述中缺少的时序、异常处理与容错定义，辅助工程师完善架构文档。PCAT 预评估检查工具在正式评估前扫描架构工作产品，核查系统需求到组件追溯覆盖率、软硬件分配依据完整性、接口规范要素与评审证据完备性，提前定位证据缺口。

规范的系统架构过程能够在项目早期固化系统边界。以 APMS 管理架构工件与评审流转，以 DPAI 辅助职责与接口一致性核查，以 PCAT 在评估前检查追溯与证据，三套工具形成计划、执行、检查的过程闭环。面向中央计算平台、多域融合等复杂系统项目，SYS.3 过程能力的提升能够降低下游软件与硬件开发的耦合风险，使系统架构决策在 ASPICE 评估与整车开发中形成可追溯依据。