4、PD协议架构：协议分层模型与消息机制

USB Type-C PD（Power Delivery）协议之所以能够实现从5V/3A到48V/5A甚至更高功率等级的灵活协商，其核心在于一套严谨的分层协议架构。与OSI七层模型类似，PD协议将复杂的功率协商、数据交互和状态管理拆解为多个独立但又相互协作的层次。本章将深入剖析PD协议的分层模型、消息类型定义以及事务与重传机制，帮助工程师从宏观架构到微观时序全面理解PD通信的运作原理。只有透彻理解协议架构，才能在固件开发、硬件调试和认证测试中做到有的放矢。

上图展示了PD协议的四层架构及其核心职责。物理层负责比特流的可靠传输，协议层负责消息的语义解析，策略引擎是状态机的大脑，设备策略则是最高决策者。右侧列出了两类消息的典型示例。下面我们将逐层展开，并结合实际开发中的案例进行说明。

4.1 物理层：BMC编码与CC通道的可靠传输

核心原理

物理层是PD协议的最底层，负责在Type-C的CC（Configuration Channel）线路上实现数据的物理传输。与USB 2.0/3.x的数据线不同，PD通信使用单线双向半双工传输，且采用BMC（Bi-Phase Mark Coding）编码方式。BMC编码将时钟信号嵌入数据流中，每个比特周期内信号电平跳变一次表示逻辑"0"，跳变两次表示逻辑"1"。这种编码方式无需独立的时钟线，且对共模干扰有较好的抑制能力。此外，物理层还负责生成SOP（Start of Packet）和EOP（End of Packet）控制字符，以及CRC32校验码，确保数据帧的完整性和同步性。

判断方法与操作流程

在硬件调试中，工程师通常使用示波器或逻辑分析仪捕获CC线上的BMC波形。判断物理层是否正常工作的关键点包括：

• 静态电平：空闲状态下CC线应被拉至约0.35V（对于Rd下拉）或1.2V（对于Rp上拉），具体取决于设备角色。
• 信号摆幅：BMC信号摆幅通常在0~1.2V之间，过低的摆幅可能导致接收端无法正确解码。
• CRC校验：协议层会丢弃CRC错误的包，如果物理层噪声过大，会导致大量重传。

// 物理层调试示例：使用逻辑分析仪捕获的BMC波形关键参数
// 比特率：300kbps（标准模式）或 1Mbps（快速模式）
// 每个比特周期：3.33us（300kbps）或 1us（1Mbps）
// 上升/下降时间：应小于100ns
// 信号过冲：不应超过200mV

案例拆解：CC线短路导致的通信失败

某样机在连接PD适配器后，无法触发任何功率协商。使用示波器测量CC1引脚，发现静态电平为0V，而正常应为1.2V左右。进一步检查发现，CC1走线上的一颗0402电容虚焊，导致对地短路。更换电容后，CC1电平恢复，PD协商正常。此案例说明，物理层的电平检测是PD通信的第一步，任何硬件异常都会导致协议层无法收到有效数据。

4.2 协议层：消息头、数据对象与事务ID

核心原理

协议层位于物理层之上，负责将物理层收到的比特流解析为有意义的PD消息。每个PD消息由消息头（Message Header）和若干数据对象（Data Object）组成。消息头长度为16位，包含消息类型（Message Type）、数据对象数量（Number of Data Objects）、消息ID（Message ID）、端口角色（Port Role）和协议版本等信息。数据对象则根据消息类型不同，承载具体的功率参数（如PDO、RDO）或厂商自定义数据。

事务ID（Transaction ID）是协议层实现可靠传输的关键机制。每个发送的消息都携带一个递增的事务ID，接收方通过回复GoodCRC消息来确认收到。如果发送方在超时时间内未收到GoodCRC，则会重传相同事务ID的消息。事务ID的分配由协议层管理，策略引擎无需关心底层重传细节。

消息类型详解

操作流程：一次典型的功率协商事务

1. Source发送Source_Capabilities（事务ID=1），通告其支持的PDO列表。
2. Sink回复GoodCRC（事务ID=1），确认收到。
3. Sink发送Request（事务ID=2），请求选择第2个PDO（如9V/3A）。
4. Source回复GoodCRC（事务ID=2），确认收到。
5. Source处理请求，若接受则发送Accept（事务ID=3），Sink回复GoodCRC。
6. Source调整输出电压，完成后发送PS_RDY（事务ID=4），Sink回复GoodCRC。
7. 至此，显式契约建立，Sink可以开始使用9V/3A的功率。

4.3 策略引擎：状态机与显式/隐式契约

核心原理

策略引擎是PD协议的"大脑"，它根据设备策略的指令和协议层上报的事件，驱动状态机完成功率协商、电源切换、错误恢复等操作。PD规范定义了两种契约：隐式契约（Implicit Contract）和显式契约（Explicit Contract）。隐式契约是Type-C连接建立时的默认状态，Source提供5V/3A（或根据BC1.2协商的电流），无需任何PD消息。显式契约则通过Source_Capabilities和Request消息协商达成，可以请求更高的电压和电流。

策略引擎的状态机包括多个关键状态，例如：PE_SRC_Startup（Source启动）、PE_SRC_Send_Capabilities（发送能力）、PE_SNK_Select_Capability（选择能力）、PE_SRC_Transition（电源切换中）、PE_SRC_Ready（就绪）等。每个状态都有明确的进入条件、退出条件和超时处理。

判断方法与调试技巧

在调试策略引擎时，建议使用PD协议分析仪（如Total Phase的PD Analyzer）捕获完整的消息序列。常见的异常情况包括：

• Source重复发送Source_Capabilities：可能是策略引擎未收到GoodCRC，导致重传。
• Sink发送Request后未收到Accept：可能是Source策略引擎拒绝了请求（如过流保护），或消息在传输中损坏。
• PS_RDY超时：Source在切换电压时耗时过长，Sink端可能触发硬复位。

案例拆解：Sink请求过高功率导致Source拒绝

某移动电源（Source）支持5V/3A和9V/2A两个PDO。当连接一台笔记本电脑（Sink）时，Sink发送Request请求9V/3A（超出Source能力）。Source的策略引擎检测到请求功率超过自身最大输出，回复Reject消息。Sink收到Reject后，重新发送Request请求9V/2A，Source接受并完成协商。此案例展示了策略引擎的决策逻辑：它必须根据设备策略（如最大输出功率、温度保护阈值）来接受或拒绝请求。

4.4 设备策略：系统级决策与用户意图

核心原理

设备策略是PD协议栈的最高层，它不关心具体的消息格式和时序，而是根据整个系统的状态（电池电量、温度、负载电流、用户设置等）来决定功率请求或功率供给策略。例如，一台支持PD的笔记本电脑，其设备策略可能定义：当电池电量低于20%时，请求20V/5A的PDO以快速充电；当电量高于80%时，请求5V/3A以涓流充电。设备策略通常由系统软件（如EC或AP）实现，通过API与策略引擎交互。

操作流程：设备策略与策略引擎的交互

1. 系统软件（设备策略）读取电池电量、温度等传感器数据。
2. 根据预设的功率策略表，决定目标电压/电流。
3. 调用策略引擎API，如PE_SNK_Request_Power(voltage_mv, current_ma)。
4. 策略引擎将请求封装为Request消息，通过协议层发送。
5. 协商完成后，策略引擎回调设备策略，通知功率切换完成。

常见误区与复盘

• 误区1：将设备策略逻辑直接写在策略引擎中。这会导致状态机代码臃肿，且难以适应不同产品需求。正确做法是保持策略引擎的通用性，将产品特定逻辑放在设备策略层。
• 误区2：忽略系统热约束。设备策略在请求高功率时，必须考虑充电IC和电池的温升。建议在策略表中加入温度降额曲线。
• 误区3：未处理Source端过流保护。Source的设备策略应实时监测输出电流，如果超过PDO标称值，应主动发送Reject或触发过流保护。