4、架构文档的层级划分：系统级、子系统级、组件级、接口级文档的职责与关系
在汽车软件架构设计中，文档并非单一、扁平的产物，而是一个具有明确层级结构的体系。随着智能网联汽车电子电气架构（EEA）从分布式向域集中式、中央计算式演进，软件系统的复杂度呈指数级增长。一套完整的架构文档需要覆盖从整车电子电气顶层设计到单个软件组件内部实现的全部视角。如果所有信息都堆砌在一份文档中，不仅阅读者难以快速定位所需内容，更会导致架构决策与实现细节相互污染，造成维护混乱。因此，将架构文档划分为系统级、子系统级、组件级和接口级四个层级，是确保架构可读性、可追溯性和可维护性的核心手段。本章将深入剖析各层级文档的职责边界、核心内容、编写方法以及它们之间的派生与追溯关系。
4.1 系统级架构文档：定义边界与顶层规则
4.1.1 核心原理：从整车视角出发的“宪法”
系统级架构文档是整个软件架构体系的“宪法”，它不关心某个具体传感器如何驱动，也不关心某个算法如何实现，而是站在整车电子电气架构的高度，回答“系统由哪些部分组成”、“各部分之间如何连接”、“整体遵循什么技术路线”这三个根本问题。在汽车领域，这份文档通常由整车厂（OEM）的架构团队主导编写，其输入是产品需求规格书（PRS）和法规标准（如ISO 26262、ISO 21434）。它定义了软件的逻辑分层（如经典AUTOSAR CP与自适应AUTOSAR AP的混用策略）、通信骨干（如车载以太网为主干、CAN FD为支线）、以及核心服务（如OTA升级、远程诊断、数据采集）的部署位置。
4.1.2 关键内容与判断方法
编写系统级文档时，建议采用“上下文图+功能矩阵”的组合方式。上下文图展示系统与外部实体（驾驶员、云端、充电桩、其他车辆）的交互；功能矩阵则明确每个整车功能（如自动紧急制动AEB）在哪个域控制器中实现，以及该功能涉及哪些传感器和执行器。判断一份系统级文档是否合格，可以看它是否明确了以下关键决策：
- 功能分配表：每个整车功能必须且只能有一个“责任域控”，避免功能归属模糊。
- 通信拓扑约束：明确哪些域之间采用SOME/IP服务调用，哪些采用信号通信，并规定最大延迟预算。
- 非功能需求基线：包括功能安全目标（ASIL等级）、信息安全等级（CAL等级）、OTA升级时间要求等。
实战经验：在某新势力车企的中央计算平台项目中，系统级文档曾因未明确“车辆下电后哪些服务必须保持唤醒”而导致后续子系统设计时，网关节点与车身域控的休眠唤醒逻辑冲突，最终通过修订系统级文档，新增“电源模式状态机”章节才解决。这提醒我们，系统级文档必须包含跨域的状态管理规则。
4.2 子系统级架构文档：承上启下的“设计蓝图”
4.2.1 核心原理：聚焦域内聚合与模块划分
子系统级文档是系统级文档的“分解物”，通常对应一个域控制器（如智能座舱域控、自动驾驶域控）或一个关键物理单元（如电池管理系统BMS）。它的核心职责是将系统级分配下来的功能需求，转化为该子系统内部的软件模块划分、数据流设计和状态管理逻辑。这一层是架构师投入精力最多的层级，因为它是连接“整车愿景”与“代码实现”的桥梁。如果子系统划分不合理，后续组件开发将陷入混乱。
4.2.2 操作流程：从功能到模块的映射
- 功能聚类：将系统级功能矩阵中分配给本子系统的功能进行内聚性分析，将强相关的功能（如车道保持与自适应巡航）聚合为一个模块群。
- 模块定义：定义逻辑模块（如感知融合模块、决策规划模块、车辆控制模块），并明确每个模块的输入、输出和内部状态。
- 交互设计：绘制子系统内部的时序图和状态图，定义模块间的数据接口（通常为C/S或P/S接口）。
- 资源预算：初步分配CPU、内存、通信带宽资源，确保子系统在满负载情况下仍有30%以上的冗余。
4.2.3 案例拆解：ADAS域控的子系统文档编写
以某L2+级ADAS域控制器为例，其子系统级文档需要描述：感知子系统（处理摄像头、毫米波雷达数据）、融合与决策子系统（输出目标列表与驾驶策略）、控制子系统（输出转向/制动请求）。在编写过程中，架构师发现感知子系统输出的目标列表数据量极大（约500个目标/帧），若直接通过SOME/IP传输给决策模块，会占用大量带宽。因此，在子系统文档中定义了“感知数据共享内存机制”，并规定仅在目标置信度超过阈值时才触发事件型更新。这一决策在子系统级解决，避免了后续组件级开发的返工。
| 子系统文档章节 | 核心内容 | 验收标准 |
|---|---|---|
| 1. 范围与目标 | 本子系统的功能边界、关联子系统列表 | 与系统级文档无冲突 |
| 2. 架构视图 | 模块分解图、数据流图、部署视图 | 每个模块有明确职责，无循环依赖 |
| 3. 状态管理 | 子系统状态机（初始化、正常运行、降级、休眠） | 覆盖所有系统级定义的电源模式 |
| 4. 接口需求 | 对组件级的接口约束（数据类型、周期） | 接口定义可被组件级直接引用 |
4.3 组件级架构文档：指导编码的“施工图”
4.3.1 核心原理：关注实现细节与局部设计
组件级文档描述的是单个软件组件（SWC）或独立进程的内部设计。在AUTOSAR CP中，它对应一个SWC的详细设计；在AP中，对应一个Execution Manifest或State Client。这份文档的读者是具体的软件开发工程师，因此它必须包含足够详细的信息，使工程师无需查阅其他文档即可完成编码。组件级文档应明确：内部数据结构、Runnable（可运行实体）的触发方式（周期/事件）、访问的端口（Port）、以及组件内部的状态机（如故障处理状态）。
4.3.2 编写要点与误区
常见的误区是将组件级文档写成“代码注释的集合”，大段粘贴代码逻辑。正确的做法是使用“结构图+端口定义表+时序约束”来描述。例如，对于“车速信号处理组件”，文档应包含：
组件名称: VehicleSpeedProcessor
端口定义:
- 输入端口: SpeedSensorRaw (CAN信号, 周期10ms)
- 输出端口: ProcessedSpeed (Float, 周期10ms)
- 服务端口: GetSpeedStatus (SOME/IP, 事件触发)
内部Runnable:
- Runnable_ReadSensor: 周期10ms, 读取CAN信号并滤波
- Runnable_Calculate: 周期10ms, 计算有效车速与置信度
- Runnable_ProvideStatus: 事件触发, 当车速超过阈值时上报状态
内部状态变量:
- speed_filtered: Float
- sensor_fault_counter: Uint8同时，组件级文档必须明确该组件在故障时的降级策略。例如，当传感器信号无效超过50ms时，组件应输出无效标志并切换至安全状态。
风险提示：组件级文档切忌过度设计。如果组件逻辑非常简单（如仅做信号取反），则无需编写冗长的设计文档，可在子系统文档中以“组件设计约束”形式简要说明。过度文档化会消耗开发资源，降低迭代效率。
4.4 接口级文档：保障互联互通的“契约”
4.4.1 核心原理：独立于实现的通信契约
接口级文档是四个层级中唯一可以独立于具体ECU或软件模块而存在的文档。它定义了通信双方必须遵守的语法和语义规则，包括信号矩阵（DBC/ARXML）、服务接口定义（SOME/IP IDL、DDS Topic）、诊断规范（UDS）以及应用层数据类型。接口级文档的核心价值在于“解耦”——只要接口契约不变，通信双方可以独立演进。例如，网关控制器升级软件后，只要仍遵循原有的CAN信号矩阵，车身域控无需任何修改即可正常通信。
4.4.2 接口文档的版本管理策略
接口文档必须采用严格的版本管理。在汽车项目中，通常使用“语义化版本号”（Major.Minor.Patch）。Major版本变更意味着不兼容的接口修改（如删除信号、改变数据类型），必须经过变更控制委员会（CCB）审批；Minor版本变更表示向后兼容的修改（如新增可选信号）；Patch版本用于修正描述性错误。接口文档的变更必须同步更新对应的子系统级和组件级文档，确保追溯链完整。
4.4.3 实战场景：跨域服务调用的接口定义
在中央计算+区域控制的架构中，座舱域需要调用智驾域提供的“车辆周围环境模型”服务。接口级文档需要定义：服务ID、方法名（如GetSurroundingObjects）、请求/响应参数（包括数据类型、范围、超时时间）、以及错误码（如E_SERVICE_NOT_AVAILABLE）。此外，还需定义通信QoS策略（如可靠性Reliability、截止时间Deadline）。如果接口文档中未明确“当智驾域处于降级模式时，服务应返回空列表并附带警告码”，则座舱域在异常情况下可能误判为通信故障，导致显示黑屏。
4.5 四层文档的协同关系与追溯机制
4.5.1 纵向追溯与横向一致性
四个层级的文档并非孤立存在，而是通过“需求追溯矩阵”紧密关联。系统级文档中的“功能需求”应追溯到子系统级文档中的“模块职责”；子系统级文档中的“接口需求”应追溯到接口级文档中的“具体信号/服务定义”。在项目里程碑评审时，架构师应抽取关键路径进行追溯验证。例如，从系统级的“AEB功能”出发，应能一路追踪到组件级“AEB决策算法组件”的代码实现，以及接口级“制动请求CAN信号”的ID和Byte位置。
4.5.2 变更影响分析
当任一层级文档发生变更时，必须进行影响分析。例如，若接口级文档将“车速信号”的数据类型从Uint8改为Uint16，则所有使用该信号的组件级文档、子系统级文档中的资源预算（内存占用）都需要同步更新。建议在文档管理工具中建立“链接关系”，实现变更的自动提醒。
最佳实践：在ASPICE（汽车软件过程改进及能力评定）认证中，这四层文档的追溯性是评估“支持过程域”是否达标的关键指标。建议使用专门的ALM工具（如Jama Connect、DOORS）来管理追溯关系，而非依赖手工维护的Excel表格。
4.5.3 常见误区与总结复盘
| 误区描述 | 后果 | 纠正措施 |
|---|---|---|
| 系统级文档过细，包含代码级逻辑 | 架构文档臃肿，难以维护，限制了下层设计自由度 | 系统级只写“什么”和“为什么”，不写“怎么做” |
| 组件级文档缺失，依赖口头沟通 | 人员流动后代码无法维护，集成时接口不匹配 | 强制要求每个SWC有最小集成的设计说明 |
| 接口文档与代码实现脱节 | 联调时发现信号字节序错误，导致数据解析异常 | 接口文档必须经过静态检查工具（如DBC Validator）验证 |
| 各层级文档更新不同步 | 追溯链断裂，变更影响无法评估 | 建立文档发布流程，下层文档必须引用上层文档版本号 |
总结而言，系统级、子系统级、组件级、接口级文档构成了汽车软件架构描述的完整闭环。系统级文档定义了“做什么”和“为何做”，子系统级文档规划了“在哪做”和“如何分块”，组件级文档细化了“具体怎么做”，接口级文档则锁定了“如何协作”。在实际项目中，架构师应像管理代码一样管理文档，将其纳入配置管理工具，并建立自动化检查机制，确保文档与代码、文档与文档之间的一致性。只有建立起清晰的层级划分和严格的追溯机制，才能应对汽车软件日益增长的复杂度和安全性要求。