这是 AUTOSAR 学习系列番外的番外篇。在上一篇的结尾有提到过可以用 EA 看官方模型，仔细查看后发现，官方模型是不可多得的学习材料，值得再深入讲讲。

相比晦涩的 SWS 文本规范，图形能帮我们在脑海中瞬间建立直观骨架。本文梳理如何利用官方 UML Model 建立 AUTOSAR BSW 的整体认知。

什么是 AUTOSAR BSW UML Model

AUTOSAR 官方在发布 CP 规范包时，除了 PDF 规范外，还会随附一份 UML 模型（通常是 MOD 类文档，如 AUTOSAR_MOD_BSWUMLModel.zip）。它本质上是所有 BSW SWS 规范中架构图、时序图与类图的「设计母版」：

• 静态结构：完整定义了各 BSW 模块的组件关系、对外提供/引用的接口、API 签名与数据类型
• 动态行为：包含典型场景下的跨模块交互时序图与核心模块的状态机
• 可追溯性：在 EA 中所有元素均有关联关系，支持双向跳转与依赖反查，要比翻阅 PDF 高效

准备工作

1. 获取官方模型：访问 Search AUTOSAR，搜索 BSW UML Model，在 Doc Type 中筛选 MOD 下载。

2. 安装查看工具：解压后找到 .eap 并使用 Enterprise Architect 打开¹。

3. 建立学习副本：保留一份未修改的原始副本。若需要在模型中添加标注或自定义视图，建议新建独立的根包（如 Learning_Sandbox），不要直接更改官方包结构。

模型目录

模型工程树内容庞大，不必逐个展开阅读，重点聚焦以下 4 个核心入口：

mindmap
  root((BSW UML Model))
    OverallViews["Overall Views<br/>宏观全景"]
    InteractionViews["Interaction Views<br/>跨模块动态交互"]
    SoftwarePackages["Software Packages<br/>模块静态定义与 API"]
    DocumentationDrawings["Documentation Drawings<br/>核心状态机与辅助图"]

Overall Views

这里通常放 AUTOSAR 分层架构、BSW 模块分布和模块之间的宏观依赖。

Interaction Views

这里主要是跨模块的时序图。

官方建模指南规定，Interaction Views 用于放置不同模块之间的交互时序图，并按软件栈组织；这些时序图用于表现 BSW 模块之间的典型用例，并被纳入对应 SWS。

当你想理解“一帧报文如何收发”、“一次诊断请求如何响应”、“一次 NvM 数据如何异步读写”时，应优在这里找找：

• 典型时序：主控调用链路与模块流转
• 调用性质：区分同步轮询、同步阻塞与异步回调
• 异常流向：如超时、校验失败、Bus-off 等异常分支的触发与通知机制

比如，下面是模拟 EEPROM（Fee_Write）的写时序图，描述的是 NvM 发起一次写请求，经过 MemIf → Fee² → Fls，最终把数据写入 Flash，并通过 JobEndNotification 逐层通知完成。

对应的，这是真实 EEPROM（Ea_Write）的写时序图：

对比两张时序图会发现，Fee 的复杂度要高于 Ea：

• Ea 更像一个转发模块：EEPROM 物理特性支持字节级随机读写与原地覆盖。因此 Ea 只需做 32 位逻辑地址到物理偏移的线性映射，将 NvM 的请求打包转发给底层的 Eep 驱动，调用链很平直
• Fee 是一个真正的内部状态机模块：Flash 物理特性决定其不能原地覆盖，必须“先按扇区擦除、再按页写入”，且擦写寿命有限。为了在只支持块擦除的 Flash 上“模拟”出 EEPROM 的随机读写能力，Fee 内部必须依赖复杂的状态机驱动，包括动态映射、扇区轮转、垃圾回收和掉电安全

尽管下层机制差异很大，但对于上层的 NvM 来说，通过 MemIf 调用的却是完全相同的 MemIf_Write 接口与异步 Job 模型。NvM 既不需要关心当前操作的是 Flash 还是 EEPROM，更无需理会底层是在做垃圾回收还是在做直接的物理覆写。

Software Packages

当需要落地到代码或查阅具体 API 时，从 Software Packages 进入对应模块包：

• 模块组件：对外提供的 Required/Provided 接口
• API 列表：函数名称、入参、出参及返回值类型
• Callback 规范：下层向上层通知的统一回调规范
• Header File Diagrams：模块间头文件的包含关系，帮助理清编译依赖

比如下图是 Fee 模块的提供的接口图，路径位于 AUTOSAR.SoftwarePackages.ECUAL.MemHwA.Fee.Fee Provided Interfaces：

Documentation Drawings

这里放的是状态机和活动图，主要是网络管理与通信控制模块相关的。这些模块往往不是简单的数据转发，状态和模式是理解行为的核心。

比如下图是 DEM 模块处理故障的活动图，可以帮助我们更好理解 Event 从“检测到故障”到“生成 DTC 并存储”的核心流程：

学习流程

同阅读 PDF 一样，不建议无目的地漫游模型，还是要以具体的工程问题为切入点：

• 一帧 CAN 报文从应用发出到硬件发送经历了什么？
• CAN 报文接收后如何解析并通知到 RTE/SWC？
• 发生 Bus-off 后，CanSM 与 CanIf 如何协调恢复？
• NvM 读取 Block 时底层的异步任务是如何轮询完成的？
• ComM 如何协同各个通道的通信模式？

推荐参考如下路径展开学习：

flowchart TD
    Q["🎯 工程问题驱动"] --> A["<b>1. Overall Views</b><br/>定位涉及模块与分层拓扑"]
    A --> B["<b>2. Interaction Views</b><br/>阅读时序图，理清动静态交互主线"]
    B --> C["<b>3. Software Packages</b><br/>查阅关键 API、Callback 与参数类型"]
    C --> D["<b>4. 对应模块 SWS</b><br/>核对详细时序要求、返回值与配置项约束"]
    D --> E["<b>5. 工具配置与代码生成</b><br/>结合 DaVinci / EB Tresos 及生成的代码验证"]

总结

AUTOSAR BSW UML Model 最大的价值，倒不在于具体画了多少张图，而是把散落在几十个 SWS 规范里的模块、接口、数据类型和状态机，串成了一张能随时点击、跳转和导航的全局地图。比起直接硬啃大段的英文规范，先看图理顺逻辑确实要友好得多。

另外，如果你平时工作里也用 EA 做软件设计和架构，官方这份工程也是现成的参考样本³。

文档入口

从下面这个地址可以直达，左边可以做过滤，比如释放版本、文档类型、模块等等。

• Search AUTOSAR

目前，提供的文档主要有以下几大类：

RS: Requirements Specification

RS 通常是比较高层的需求文档，回答 AUTOSAR 为什么需要这个能力，以及这个能力总体上必须满足什么要求？这类文档一般不会告诉你某个 API 的参数如何定义，而是描述功能目标、使用场景、系统约束、安全性和兼容性要求等。

SRS: Software Requirements Specification

SRS 比 RS 更接近软件架构层，但通常还不是某个具体模块的最终实现规范。SRS 经常定义某类基础软件模块共享的软件需求，比如通信、诊断、存储等相关的公共需求。

SWS: Software Specification

这是做 BSW 开发时最常阅读的文档类型。SWS 通常包含：模块职责与边界、依赖关系、API 定义、数据类型、状态机或行为描述、错误处理、配置参数等等。

EXP: Explanatory Document

EXP 是解释性文档，主要帮助读者理解规范背后的概念和使用方式，它往往比 SWS 更适合入门，但通常不作为开发符合性判断的唯一依据。建议的阅读顺序：

flowchart TD
    A["<b>💡 先读 EXP </b><br/>建立整体概念，理解背景与设计初衷"]
    --> B["<b>🎯 再读 RS / SRS </b><br/>追溯需求来源与上层约束，明确功能边界"]
    --> C["<b>🔍 最后读 SWS / TPS </b><br/>查阅精准实现规则，掌握 API 定义、状态机及配置参数"]

对于大多数使用成熟工具进行 AUTOSAR 配置和集成的工程师而言，没有必要系统阅读全部 AUTOSAR 官方文档。实际工作通常以工具厂商提供的技术文档、User Manual 和集成指南为主，并在需要确认模块标准行为时查阅对应的 SWS。

对于 AUTOSAR 工具开发者、BSW 或 MCAL 开发者，以及需要手写 CDD 或其他 AUTOSAR 相关代码的工程师，则需要根据具体问题进一步阅读 SWS、TPS、MMOD 等文档，理解接口行为、配置模型、协议规则和工具生成逻辑。

开发阅读建议

没有人会把 2 万多页¹的 AUTOSAR 规范当成长篇小说从头读到尾。真这么读，大概率在术语定义和版权声明里就被劝退了。

理解 AUTOSAR，首先要认识到它是一套标准化规范，而不是某个具体的软件实现。阅读时，核心是厘清它规定了什么、约束了什么，以及哪些内容由具体实现自行决定。

区分标准、厂商与项目

实际开发中，我们接触最多的通常不是 AUTOSAR 规范本身，而是 Vector、EB 或芯片厂商提供的配置工具、基础软件和参考文档。遇到行为异常或联调争议时，查规范最大的价值在于区分责任边界：

flowchart TD
    Issue["现场问题 / 行为分歧"] --> Q{"根因在哪个层面？"}
    Q -->|"标准规定"| SWS["<b>AUTOSAR 规范</b><br/>标准强制要求还是可选推荐？"]
    Q -->|"厂商实现"| Vendor["<b>供应商 Technical Reference</b><br/>厂商私有扩展还是已知限制？"]
    Q -->|"工程配置"| Project["<b>项目 ARXML / Cfg</b><br/>参数配错还是集成逻辑有误？"]

• 标准规定：AUTOSAR SWS 明确规定的强制性要求，例如标准返回码、API 行为、状态机及其跳转条件
• 供应商选择：标准未强制约束或明确允许自行实现的部分，由供应商根据产品架构作出选择，例如内部缓冲队列机制、资源管理策略和扩展 callout
• 项目决定：由 OEM / Tier 1 或具体项目根据系统需求确定的参数和策略，通常通过 ARXML、生成配置、集成代码

分清这三个层次，才能知道应该查 AUTOSAR SWS、供应商技术文档，还是项目的 ARXML、生成代码与集成逻辑。

SWS 定模块边界

很多时候，弄清楚一个模块 不负责什么，比记住它负责什么更重要。初学者最容易把模块的职责想得过宽：

• PduR 只负责 PDU 级别的路由分发，但不解析其中的 signal
• ComM 负责协调通信模式，但不直接操作底层 controller
• NvM 负责高层非易失数据块的排队与管理，但不直接擦写 flash
• RTE 负责组件解耦与数据搬运，但不负责底层任务调度

当你对模块产生边界模糊时，在 SWS 翻到它向谁提供接口、又依赖谁的接口，职责边界自然就水落石出。

SWS 重点看什么

一份 SWS 动辄数百页，但工程开发最常用的内容主要集中在四个部分：

flowchart LR
    A["<b>Chapter 5</b><br/>Dependencies<br/>理清上下游依赖"]
    --> B["<b>Chapter 7</b><br/>Functional Spec<br/>掌握状态机与时序"]
    --> C["<b>Chapter 8</b><br/>API Spec<br/>看接口分类与签名"]
    --> D["<b>Chapter 10</b><br/>Configuration<br/>对应工具配置项"]

1. Dependencies to other modules
   先看模块依赖谁、又被谁依赖，确定它在软件栈中的位置和职责边界。

2. Functional specification
   这是 SWS 的核心。重点关注：

   • 状态机：模块有哪些生命周期状态？什么条件触发跳转？
   • MainFunction 与运行时序：周期函数里究竟在干什么？异步任务的 Job 是如何处理的？

3. API specification
   不必死记每个函数的参数，先按用途理解接口：

   • 初始化（Init / DeInit）
   • 控制与请求（RequestMode / Transmit）
   • 回调通知（RxIndication / TxConfirmation）
   • 周期调度（MainFunction）

4. Configuration specification
   配置工具中的复选框、下拉列表和数值参数，通常都能在这里找到对应的标准定义与约束。遇到不理解的配置项，直接按参数名全文搜索即可。

问题驱动，而非页码驱动

AUTOSAR 规范不适合漫无目的地通读。更有效的方法是先建立骨架，再带着问题查细节。

第一遍：30 分钟建立骨架

暂时跳过 API、配置参数和需求细节，只回答四个问题：

1. 模块解决什么问题？
2. 模块负责什么，不负责什么？
3. 模块与哪些上下游交互？
4. 模块依靠状态机、数据流还是调用链运行？

第二遍：带着问题按图索骥

在设计、配置、编码或排错时，把问题具体化为某个接口、状态、配置项或运行场景，再回到 SWS 中精准查找。

PDF 之外，也可以看模型

AUTOSAR 的部分发布包包含模型文件，可以使用 Enterprise Architect（EA） 工具打开并查看其中的 UML 图，包括模块依赖、接口关系、状态机和时序图。

下图是使用 EA 打开的 AUTOSAR_MOD_BSWUMLModel.zip。如果平时使用 EA 进行软件架构设计，这套 AUTOSAR UML 模型是很有价值的学习材料。