USB PD协议规范
USB PD 协议规范
译者：李熙民
第二章 第一节：USB PD介绍
在USB PD中，一对直连的端口用USB Type-C连接器中的CC线作为通讯信道来协商出电压，电流以及在Cable里面供电的方向。这种被采用的机制，独立于其它的用来协商 USB 电源的操作方式。
USB PD 也会充当一个边带信道使其能够支持标准或厂家自定义的模式操作。工作 Mode 是与 SVID 联系在一起的。在 PD 协议中结构化的 VDM Message 可以被用来发现支持的 SVID 和 Modes，当有需要的话，同样支持 Modes 的进入与退出。多个 Active Modes 可以同时工作。
一旦用这个标准协商出来的契约的关系，都将替换任何之前使用的USB2.0、USB3.1、USB Type-C1.2 或 USB BC1.2 机制所协商出来的供电关系。当处于 PD 模式的时候，将会有个契约关系(既可以是显性契约也可以是隐性契约的关系)在工作中决定着可用的供电等级和方向。当一对正常工作在 PD 模式下的端口断开连接后，将引起系统复位或 SRC 端移去供电的电源 (除了发生在 PRS 和 FRS 过程之中，当起初的 SRC 去掉供电为了让新的 SRC 开启供电)。
显性契约关系协商的过程开始于 SRC 发起一系列的供电能力，然后 SNK 从其中申请一个特定能力的请求，接下来 SRC 接受了这个申请。
隐性契约关系是指在特定状态下的指定供电等级(比如在 PRS 和 FRS 过程中或者在它们发生之后)。由此可以知道，隐性契约关系的状态只是暂时的。端口间需要立即协商出新的显性契约来。
每个供电的一方都有个本地策略，管理着向对端端口的功率分配。SNK 也有自己的本地策略来管理应该吸收多少电能。基于 USB 所制定的系统策略允许对本地策略的更改，因此在系统中可以管理供电的分配。
当具有 PD 能力的设备互相连接成功之后，DFP 和 UFP 初始为 USB 默认的工作状态。DFP 提供了 vSafe5V，UFP 吸收电流与 USB2.0、USB3.1、USB Type-C 或者USB BC1.2 相关标准定义的规则相一致。在 PD 协商发生之后，可以输出比标准定义中更高或更低的电压和更高的电流。它也可以完成 PRS 或 FRS 来交换电源供给的角色，从而使得 DFP 变成受电一方，UFP 变成供电那一方。同时可以通过 DRS 使得 DFP 变成了 UFP，反之亦然。通过执行 VCONN Swap 来改变 VCONN 供电的方向。
在显性契约关系建立之前，SRC 可以发现连接上的线缆能力和特性。了解在 USB Type-C 1.2 中被标记 5A 能力的线缆和其它线缆的一些细节比如支持的速率这一点很重要。发生在端口连接上的初始，在显性契约关系建立之前，DFP 同时也是SRC 的情况下开始进行 Cable discovery。PRS 和 FRS 之后，显性关系建立之前，在 UFP 为 SRC，隐性契约在工作的情况下，也是有可能进行 Cable discovery 的动作。
一旦是显性契约工作的状态下，只有 DFP 允许和连接上的 Cable 进行通讯。不仅包括了 Discover identity，也包括了 Cable 所支持的 Discover SVID，Discover Mode，Enter Mode 和 Exit Mode 模式。
第二章 第二、三节：更新和兼容性
2.3.1 Changes from Revision 2.0
下面是对 PD3.0 与 PD2.0 主要变化的总结：
1、支持版本 2.0 和 3.0 的操作，以确保向后可以兼容现有产品（see Section 6.2.1.1.5）。
2、原来的 Profile 丢弃不用，取而代之的是 PD 的供电模式(see Section 2.7.9)。
这种改变也适用于 USBPD2.0。
3、BFSK 支持已弃用的设备，包括传统电缆，传统连接器，传统的电池耗尽的操作和相关的测试模式。
4、Extended Message 数据的有效载荷长度达到了 260bytes(see Section 6.2.1.2)。
支持将扩展消息分块为 USB PD 的大小，以实现与传统 PD 硬件的兼容性。
5、只有 VCONN SRC 允许和 Cable Plug 进行通讯(see Section 2.5.4)。
6、 SRC 尝试协调尽可能地避免碰撞使 SRC 和 SNK 中的任意一个端口能够发起 AMS 的序列。
USB Type-C 1.2 中，用 SRC 端上拉的 Rp 电阻值来表明当 SNK(能或不能)向 SRC 或者 Cable Plug 发起 AMS 的序列(see Section 2.7.3)。
SRC 和 SNK 中的任意一个端口都能发起 Vendor Defined 定义的 Message 序列。
当具备可以给 VCONN 供电的能力时，SRC 和 SNK 中的任意一个端口都可以和 Cable Plug 进行通讯。
7、删除了 Attention 命令的时间限制。
FRS 定义了能够将外接电源的 docks 和 hubs 快速转换到 bus power 模式上，当它们去除外部电源供给的时候(see Section 6.3.17)。
8、附加的状态和发现
扩展的供电能力和状态。
电池的能力和状态。
制造商定义的信息。
9、无源电缆，有源电缆和 AMA VDO 中字段的改变表明了将 Structured VDM 更改到 2.0 的版本。
10、支持与 USB 安全相关的请求与响应。
11、支持 USB PD 固件的更新请求与响应。
12、系统策略在当前的引用。
2.3.2 Compatibility with Revision 2.0
USB PD 标准的 3.0 版本被设计用来完美兼容 USB 2.0 的系统，此系统在 USB Type-C 1.2 连接器上使用 BMC 的信号是和 2.0 版本的硬件是一致的。
这份标准强制要求了所有 3.0 版本必须完全支持 USB PD 2.0 的操作。它们必须发现对端或 Cable Plug 所支持的版本，然后用最低，常见的版本号使回复到与之对应的状态。（see Section 6.2.1.1.5）
这个标准规定了 Extended Message ，其包的长度达到了 260 bytes(see Section 6.2.1.2)。这些 Message 要比目前 PHY HW 中包的长度要长。为了可以支持 2.0 版本的基础系统，分块机制被强制执行以便 Message 被限制到 PD 2.0 版本的尺寸，除非发现两个系统都可以支持最长包的收发。
这个标准包括了 Vendor Defined Objects(VDO) 的变化用来发现识别 passive/active cable 和 Alternate Mode Adapters(AMA)(see Section 6.4.4.2)。
为了能使系统决定用哪个 VDO，结构化的 Vendor Defined Message (SVDM)的版本号递增到 2.0。
如果变得有需要的话，版本号也已经包含了 VDO 本身，来促进接下来的变化。
第二章 第四节：USB PD 支持设备
在 Figure 2-1 中可以看到一些具有 USB PD 能力的设备(a Host, a Device, a Hub, a Charge)。这些都是仅供参考，不会限制基于这份标准而建立的产品可能的配置。
每一个具有 PD 能力的设备被认为至少组成了一个端口。Providers 被认为是 SRC, Consumers 被认为是 SNK。每个设备包含了一个甚至更多下面的要素。
UFPs 可以是：
受电。
可选择地供电(一个 DRP 的设备)。
可选择地通过 USB 进行数据通讯。
用 SOP Packets 进行通讯。
可选择地用 SOP* Packet 进行通讯。
DFPs 可以是：
供电。
可选择地受电(一个 DRP 的设备)。
可选择地与通过 USB 进行数据通讯。
用 SOP Packet 进行通讯。
可选择地用 SOP* Packet 进行通讯。
A SRC that 可以是：
一个外部电源(比如 AC)。
蓄电装置(比如电池)。
从另一个端口派生的(比如远供的 Hub)。
A Sink 可以是：
蓄电装置(比如电池)。
用于给内部功能供电的设备。
用于给连接到其它设备供电的设备。
A VCONN SRC 可以是：
可以是任意一个端口，既可以是 DFP/UFP,也可以是 SRC/SNK。
给 Cable Plug 供电。
在任何时候，只有是能够提供 VCONN SRC 的端口才可以和 Cable Plug 进行通讯。
第二章 第五节：SOP* 通讯
2.5 SOP* 通讯
2.5.1 Introduction
SOP Message 是用来识别是否是 SRC 和 SNK 端口的信息交互（SOP 交互）还是对一端为 Cable Plug 的信息交互（SOP’ /SOP”）。SOP/SOP’ /SOP”统称为SOP*。 Cable Plug 在 SOP’和 SOP”信息交互的相关术语被用来声明能够进行PD 交互线缆的性能(看插头上有没有检测到 Ra）。
接下来的部分是描述 SOP Message 在端口与端口之间和端口与 Cable Plug 之间的交互工作流程。
2.5.2 SOP* Message Collision Avoidance
对所有的 SOP* Message，SRC 为了避免在总线上通讯受到干扰，允许当 SNK 不需要和自己通讯时发起 Message 交互，从而协调通讯过程。一旦 SRC 和 SNK 之间被新的显性关系所代替，此时SNK 发起一段消息序列。此序列可以和 SRC 或者 Cable Plug 进行通讯。而 SRC 一旦需要发起一段消息序列就会向 SNK 表明，此时 SRC 在自身发起一段消息序列之前应该等所有 SNK SOP*通讯完成。
2.5.3 SOP Communication
SOP 的 Message 被用来 SRC 和 SNK 的端口通讯。SOP 通讯存在于 SRC 和 SNK 端口之间而不会被任何的 Cable Plug 所干扰。在完成和 Power 相关的协商操作之后，SOP 的 Message 交互尽可能的比其它 SOP* Message 优先开始。和 Power 相关的信息序列被允许可以打断其它序列的进行,确保在总线上优先进行 Power 的协商和控制。
2.5.4 SOP’/SOP” Communication with Cable Plug
当 Cable Plug 检测到VCONN打开后，SOP’的 Message可以被 Cable Plug 里的电子设备所识别。当 Cable Plug 支持 SOP’的通讯后，才会支持 SOP”的通讯。
在连接时 VCONN SRC 是 SRC/DFP,然而这些所有的模式都可以通过 PD Message 来改变。
Cable Plug 不会识别 SRC 和 SNK 之间 SOP Message 的通讯。Figure 2-2 部分介绍了 VCONN SRC(DFP/UFP)和 Cable Plug 之间进行 SOP*通讯的用法。
所有的 SOP信息通讯都发生在 CC 上。这意味着必须协调 SOP信息通讯来防止阻碍其它重要的通讯。对于不识别 SOP/SOP’/SOP”的产品来说，这一点看上去像一个非空闲的信道，从而导致丢包和重传。
两个端口之间是优先进行通讯的，意味着与 Cable Plug 的通讯是可以被打断的，但不会导致 Soft Reset 和 Hard Reset 的产生。
当没有契约或者默认契约关系在工作时（例如.在 PRS 或者 FRS 之后）SRC(既可以是 DFP 也可以是 UFP，但必须是 VCONN SRC)可以用 SOP’的包来与 Cable Plug 进行通讯，以此来发现并获得它的特性。在这个阶段所有与 Cable Plug 的通讯都是由 SRC 端发起和控制，以此防止和 SOP*的包形成冲突。SNK 是不会和 Cable Plug 进行通讯的，即使它是 DFP，也要丢掉任何收到的 SOP’类型的包。
当明确的契约关系在工作时，VCONN SRC（可以是 DFP 也可以是 UFP）可以用 SOP’/SOP”的包和 Cable Plug 进行通讯。在这个阶段所有与 Cable Plug 的
通讯都是由 VCONN SRC 发起，以此来防止和 SOP*的包形成冲突。不是 VCONN SRC 的那个端口则不会与 Cable Plug 进行通讯，同时也不会识别任何收到的
SOP’/SOP” Message。只有是 DFP，同时也是 VCONN SRC 的时候，可以允许发送 SOP*来控制进入或退出 Mode 及管理相应的工作模式（。通过发送 Discover Identity 来读取 Cable 的信息，如果是 Active Cable，则继续发送 Discover Mode/Enter Mode/Exit Mode 来控制 Mode 的整个过程）
Note: Cable Plug 既可以和 DFP 连接，也可以和 UFP 连接。
第二章 第六节：操作概述（一）
2.6 操作概述
USB PD 端口中供电的一方是 SRC，受电的一方为 SNK。在端口间，每个 PD连接中只有一个是 SRC，一个是 SNK。默认连接上的 SRC 端（提供上拉电阻）也是 DFP，也是 VCONN SRC。同时连接上的 SNK 端（提供下拉电阻）也是UFP，不是 VCONN SRC。
SRC/SNK，DFP/UFP，VCONN SRC 的模式都可以通过 PD Message 进行转换。同时支持 SRC 和 SNK 的端口叫做 DRP，同时支持 DFP 和 UFP 的端口叫做 DRD。
下面的部分描述的是高等级的工作来承担 DFP，UFP，SRC，SNK 的角色。这些部分不会描述不被允许的工作状态；但如果一种特定的行为没有描述到，那就很可能没有被这个标准所支持。
PD 如何在一个 PD USB 设备上绘制自己状态的详情请看 9.1.1 章。
2.6.1 SRC Operation
SRC 工作状态的不同取决于连接状态：
在连接状态时(没有 PD 的连接)
-
对一个 SRC_Only 的端口来说，SRC 会检测 SNK 有无连接上。
-
对 DRP 端口来说会切换使其变成 SRC 以完成和 SNK 的连接。
-
在 SRC 端设置 VBUS 到 vSafe5V。
在 PD 连接之前(没有 PD 的连接或者 PD 协商还没建立)
-
在发 SRC_CAP 之前，SRC 可以检测连接上的 Cable 的类型，然后根据检测到的 Cable 的类型来改变它的通告能力。
（1）SRC 会尝试用 SOP’的 Message 与 Cable Plug 进行通讯。如果Cable Plug 响应，则开始与其通讯。
（2）默认的 USB Type-C 的线缆支持的电流是 3A，但我们可以通过发SOP’的 Message 来获得这根线缆的能力。 -
SRC 会定期的在每个 tTypeCSendSourceCap 时间内通过向对端发送SRC_CAP 来通告自己的供电能力。
在 PD 连接的阶段(PD 连接还没完成或没有建立明确的契约关系)
-
有下面两种中的一种说明检测到存在的对面端口具有 PD 功能。
（1）SRC 收到了对端响应 SRC_CAP 而发出的 GoodCRC。
（2）SRC 收到了 Hard Reset 信号（此时对端没能收到 SRC 发出的 SRC-CAP）。建立契约关系(PD 连接但在 PRS 或 FRS 之后的契约关系还没建立)
-
SRC 从 SNK 那边收到 Request Message，然后用 Accept 来响应 SRC发出的 Request。如果是一个合法，有效的 Request,当准备好供电给SNK 协商好的 Power 之后，SRC 会发出 PS_RDY Message，这个时候显性契约就建立了。
-
DFP 不会生成 SOP’或 SOP ”的包，也不需要检测 SOP’/SOP”包,就算检测到也会将其丢掉。
在 PD 连接过程中 (建立了显性契约关系状态到 PE_SRC_Ready 状态)
-
SRC 会处理和响应(如果需要的话)所有收到的包，无论何时，当它本地策略需要的时候会发送恰当的包。
（1）无论何时供电的能力改变了，SRC 会通过发 SRC_CAP 来通知 SNK。
（2）SRC 在 CC 线路上总是 asserted RP。
（3）当端口电力模式为 DRP 时，SRC 可以发起或收到电力模式转变的请求。在 PRS 之后，SRC 将会变成 SNK，在明确的契约关系形成之前，由默认的契约关系暂时代替其工作。
（4）当端口数据模式为 DRD 时，SRC 可以发起或收到数据模式转变的请求。在 DRS 之后，DFP 会变成 UFP。此时端口的电力模式还是SRC，同时 VCONN SRC 也不会发生改变。
（5）可以发起或接收转变 VCONN SRC 供应的请求。当 VCS 通过两端被申请的时候，此时端口的电力模式和数据模式没有发生改变。 -
当 SRC 也是 VCONN SRC 的时候，在没有其它 SOP 通讯时，可以在任何时候用 SOP’或 SOP”与 Cable Plug 进行通讯。
（1）当 SRC 收到 SOP 的包，就算此时进行 SOP’或 SOP”通讯也要立即结束，优先开始 SOP 通讯(Cable Plug 超时，不会重试了)。
（2）如果 SRC 正在进行 SOP’或 SOP”通讯的时候需要发起 SOP 通讯(比如供电能力的改变)，SOP’或 SOP”通讯都将被终止。 -
当端口既是 SRC，同时也为 DFP 时
（1）SRC 可以通过对 Cable Plug 发包来控制 Mode 的进入和退出以及可以管理工作的模式。
（2）SRC 可以发起结构体和非结构体的 VDM 的 Message。
（3）SRC 可以在 SNK 控制进入和存在的模式和用结构体 VDM 的 Message 来控制其工作的模式。 -
如果 SRC 端口是一个多口的系统
（1）当需要输出备用功率时，将产生 Gotomin 的 Request。断开或通讯错误
-
当 SRC 检测到线路断开后，会在 tSafe5V 的时间内将电压降到 Vsafe5V, 在 tSafe0V 的时间内降到 Vsafe0V(SRC 通过检测 ADC 的值来看线路有无断开)。
-
当 SRC 在 tReceive 时间内，收到为响应 Message 而发出的 GoodCRC包，在此过程中检测到了错误。
（1）由于 CRCReceiveTimer 的期满，在 tSoftReset 时间内，产生了 Soft Reset。
（2）如果 Soft Reset 没有按时完成的话，就会在 CRCReceiveTimer timer out 之前，在 tHardReset 时间内产生 Hard Reset。同时在 1-1.5S 内将 VBUS 调到 USB 的默认电压 5V。
（3）当端口 SRC 同时也是 VCONN SRC 时，在发生 Hard Reset的过程中 VCONN 也是会掉电的。 -
SRC 为了进一步尝试通讯但没有收到响应表示出现了错误。
-
在 Power 协商过程中出现的错误会自动地产生 Hard Reset 为了将Power 维持在默认的等级(5V)。
错误的处理
-
当协议层出现错误时，会引起端口中的任意一个发出 Soft Reset.从而复位 counters, timers 和 states，但这个动作不会改变协商好的电压，电流或端口的模式(比如 SRC,DFP/UFP,VCONN SRC)也不会导致退出现有的工作模式。
-
当线路中出现严重错误的时候，两个端口中的任意一个都可能会发出Hard Reset 的信号。
（1）和 Soft Reset 一样，Hard Reset 会 reset protocol,同时为了保护 S NK，将 Power Supply 降到 vSafe0V 或 vSafe5V 输出。
（2）使端口的数据模式维持在最初状态的 DFP。
（3）当 SNK 为 VCONN SRC 时，此过程会关闭 VCONN 供电。同时将SRC 维持在 VCONN SRC 的状态。 -
在 Hard Reset 产生后，寄望于对端可以在 tNoResponse 的时间内对 Hard Reset 请求做出响应。如果未有响应，进行 Hard Reset 累加（最大为 2）直到 SRC 进入 Error Recovery 状态。
第二章 第六节：操作概述（二）
2.6.2 SNK Operation
在连接状态时（没有 PD 的连接）
-
SNK 会通过对端有无输出 vSafe5V 来判断连接。
-
对 DRP 端口来说会切换使其变成 SNK 以完成和 SRC 的连接。
-
一旦 SNK 在 VBUS 上检测到 vSafe5V 的存在，它通过等对端是否发出 SRC_CAP 来判断对端为具有 PD 能力的 SRC。
-
如果 SNK 没有在 tTypeCSinkWaitCap 时间内收到 SRC 发出的SRC_CAP，通过发出 Hard Reset 信号寄望于 SRC(具有 PD 能力)可以发出 SRC_CAP。
-
SNK 不会生成 SOP’或 SOP”的包，也没有必要检测 SOP’或 SOP”的包，同时不会去识别它们。
建立 PD 的连接(PD 连接没完成或没有建立明确的契约关系)
-
SNK 收到了 SRC_CAP 的 Message,然后用 GoodCRC 响应。
-
SNK 不会生成 SOP’或 SOP”的包，也没有必要检测 SOP’或 SOP”的包，就算检测到也要将其丢掉。
建立显性契约关系(PD 连接但在 PRS 或 FRS 之后的契约关系还没建立)
-
SNK 从 SRC 那边收到 SRC_CAP Message,然后用 Request Message向 SRC 发出供电请求。如果是一个合法，有效的 Request, SNK 收到了对端的 Accept Message，当准备好供电给 SNK 协商好的 Power 之后，同时会收到 SRC 发出的 PS_RDY Message，这个时候显性契约就建立了：
（1）SNK 申请的电压应该是 SRC 发出的电压能力中的一个，即使它是被 USB2.0,USB3.1,USB Type-C 1.2 或 USBBC 1.2 所支持的vSafe5V 输出，为的能够协商更高的电压。如果用了 Request Message 将会导致错误，SNK 就不会向申请任何的供电请求。
（2）假如 SNK 申请的电压能力不在 SRC 所能提供的范围内，那么将以默认的第一个进行申请，SNK 将它改变申请的动作通知最后一个。
（3）SNK 不会生成 SOP’或 SOP”的包，也没有必要检测 SOP’或 SOP”的包,就算检测到也要将其丢掉。在 PD 连接过程中(建立了显性契约关系状态到 PE-SNK-Ready 状态)
-
SNK 会处理和响应（如果需要的话）所有收到的包，无论何时，当它本地策略需要的时候会发送恰当的包。
-
当 SNK 的申请能力需要改变的时候，会通过发新的 Request Message 来通知 SRC。SNK 申请的电压应该是 SRC 发出的电压能力中的一个，即使它是被 USB2.0,USB3.1,USB Type-C 1.2 或 USBBC 1.2 所支持的 vSafe5V 输出，为的能够协商更高的电压:
（1）在一个错误的状态中，SNK 不会用 Request Message 来申请任何的电压能力。
（2）假如 SNK 申请的电压能力不在 SRC 所能提供的范围内，那么将以默认的第一个进行申请，SNK 将它改变申请的动作通知最后一个。
-
SNK 在 CC 线路上总是 asserted RD。
-
当端口电力模式为 DRP 时，SNK 可以发起或收到电力模式转变的请求。在 PRS 之后，SNK 将会变成 SRC，在明确的契约关系形成之前，由默认的契约关系暂时代替其工作。
-
当端口数据模式为 DRD 时，SNK 可以发起或收到数据模式转变的请求。在 DRS 之后，DFP 会变成 UFP.端口的电力模式还是 SNK，同时 VCONN SRC 也不会发生改变。
-
SNK 可以发起或接收转换 VCONN SRC 供应的请求.在 VCONN 交换期间，是可以被两端所运用的(中断之前)。此时端口的电力模式和数据模式没有发生改变。
-
当 SNK 也是 VCONN SRC 的时候，在没有其它 SOP 通讯时，可以在任何时候用 SOP’或 SOP”与 Cable Plug 进行通讯。
（1）当 SNK 收到 SOP 的包，就算此时进行 SOP’或 SOP”通讯也要立即结束，优先开始 SOP 通讯(Cable Plug 超时，不会重试了)。
（2）如果 SNK 正在进行 SOP’或 SOP”通讯的时候需要发起 SOP 通讯(比如供电能力的改变)，SOP’或 SOP”的通讯都将被终止。
（3）当端口 SNK 同时也是个 DFP 时，可以通过对 Cable Plug 发包来控制 Mode 的进入和退出以及可以控制工作的模式。 -
当端口既是 SRC，同时也为 DFP 时
（1）SNK 可以发起结构化和非结构化的 VDM 的 Message。
（2）SNK 可以在 SRC 端口上控制 Mode 进入与退出和用结构化 VDM 的 Message 来控制其工作的模式。通讯错误或断开
-
当 SNK 检测到线路上没有 VBUS 输出时，这就意味着 PD 连接的结束，除非是由于 Hard Reset, PRS,FRS 中的一个导致状态回到 vSafe0V。
-
SNK 检测到插头的移除,然后开始进行放电。
-
当 SNK 在 tReceive 时间，收到了为响应 Message 而发出的 GoodCRC 包的过程中检测到了错误。
（1）由于 CRCReceiveTimer 的期满，在 tSoftReset 时间内，产生了 Soft Reset。
（2）如果 Soft Reset 没有按时完成的话，就会 CRCReceiveTimer timer out 之前，在 tHardReset 时间内产生 Hard Reset。同时在 1-1.5S 内将 VBUS 调到 USB 的默认电压 5V。
（3）SNK 为了进一步尝试通讯但没有收到响应表示出现了错误。 -
在 Power 协商过程中出现的错误会自动地产生 Hard Reset 为了将Power 维持在默认的等级(5V)。
错误的处理
-
当协议层出现错误时，会引起端口中的任意一个发出 Soft Reset。从而复位 counters, timers 和 states，但这个动作不会改变协商好的电压，电流或端口的模式(比如 SRC,DFP/UFP,VCONN SRC)也不会导致退出现有的工作模式。
-
当线路中出现严重错误的时候，两个端口任意一个都可能会发出 Hard Reset 的信号。
（1）和 Soft Reset 一样，Hard Reset 会 reset protocol,同时为了保护SNK，将 Power Supply 降到 vSafe0V 或 vSafe5V 输出。
（2）使端口的数据模式维持在最初状态的 UFP。
（3）当 SNK 为 VCONN SRC 时，Hard Reset 会关闭 VCONN 供电.此时将回到最初 SRC 也是 VCONN SRC 的状态。
（4）将会导致退出所有的模式，比如 SRC 会退出现有的工作模式。在 Hard Reset 产生后，寄望于 SRC 可以在 tTypeCSinkCap 的时间内对Hard Reset 请求做出响应。如果 SRC 未有回应，在 UFP 还维持在 PESNKWaitforCap 状态的时候，再发出两个 Hard Reset 信号。
2.6.3 Cable Plug
Cable Plug 是由 VCONN 供电的，但不需要清楚此时的状态关系。
Cable Plug 不会主动发起 Message 的序列，只有为了响应 VCONN SRC 发的包才会发起 Message。
断开或通讯错误：
-
在任何时候，通讯都可以被中断。
-
在 VCONN SRC(DFP/UFP)与 Cable Plug 的通讯的时候，没有时间超时的说法。
-
Cable Plug 准备响应可能的重复请求。
错误地处理
-
Cable Plug 检测到 Hard Reset 信号后来判定 SRC 和 SNK 已经 Reset，之后 Reset 自身(相同的掉电过程)。
（1）Cable Plug 自身不能生成 Hard Reset 信号。
（2）Hard Reset 会使 VBUS 和 VCONN 同时掉电，这一点也就相当于 Reset Cable Plug 自身。 -
Cable Plug 检测到 Cable Reset 的信号来决定是否需要 Reset 它自身（相同的掉电过程）。
第二章 第七节：架构概述（一）
2.7 Architectural Overview 架构概述
逻辑架构并没有打算作为一种实现架构。按照定义，实现架构是产品定义的一部分，即它是在这个标准的范围之外的。
在每个具有 USB PD 能力的设备里面，USB PD 架构是由大量主要成分组成的。通讯堆栈在 Figure 2-3 可以看到包括了：
A Device Policy Manager(see Section 8.2)存在于所有的设备当中，通过一个或多个端口的 Local Policy 用来管理 USB PD 内部的资源。
A Policy Engine(see Section 8.3)存在于每个 USB PD 的端口中来执行 Local Policy。
A Protocol Layer(see Chapter 6)使 Source 和 Sink 端口之间的 Message 进行交换。
A Physical Layer(see Chapter 5)操控通讯线路上 bits 的传送与接收，同时也操控数据的传送。
此外，具有 USB PD 能力的设备同样可以作为 USB 设备在 USB 中实现通讯(see Figure 2-4)。一种任意的系统策略管理器(see Chapter 9)存在于 USB Host 与 PD设备之间的通讯中，经过 root 端口，可能地遍布在一棵树上的 USB 集线器上。在每个设备上，设备策略管理器与 USB 接口相互作用为了可以在域中提供和更新 PD 的相关信息。Note：PD 设备不需要有一个像 USB 设备那样的接口。
Figure 2-5 描述了两个连接 PD 端口的逻辑模块。另外，通讯协议 stack 部分上面也有描述包括了:
作为一个 SRC 或者 DRP 的设备：一个或多个的 SRC 向一个或多个的端口供电。
作为一个 SNK 或者 DRP 的设备：一个 SNK 吸收电能。
一个 USB-C 接口的控制模块(see Section4.4)会用 USB Type-C 1.2 中定义的协议来检测线缆的连接或断开。
USB PD 用的是 USB Type-C 1.2 定义的标准线缆。
设备的策略管理器会和通信 stack 进行通讯，SRC/SNK 和 USB-C 的控制模块来管理 Provider 和 Consumer 中的资源。
Figure 2-5 说明了一个 Provider 和 Consumer 内部通讯的框架结构。DRP 的设备结合了 Provider 和 Consumer 的功能要素。Provider 也可以包括多个的 SRC端口，它们每一个都有自己的通讯 stack 和 USB-C 接口的控制。
2.7.1 Policy
存在两种可能等级的策略:
- 系统策略应用在系统范围内来管理多个的 Providers 和 Consumers。
- 本地策略通过 DPM 作用在一个 Provider 或一个 Consumer 中。
策略包括了一些逻辑模块:
System Policy Manager(整个系统范围内)
Device Policy Manager(每一个 Provider 或 Consumer)
Policy Engine(每一个 SRC 和 SNK 端口)
2.7.1.1 System Policy Manager
既然 USB PD 的协议本质上是端口对端口，系统策略的启用需要另外的通信机制即 USB 来实现通讯。系统策略管理会监控和控制通过 USB 连接上的各个Provider 和 Consumer 的状态。系统策略管理存在于 USB Host 当中，每一个连接上的设备用设备策略管理器通过 USB 口进行通讯。没有 USB 数据通信能力的或者没有数据连接的设备将不能参加策略的管理。
任何给定的系统，系统策略管理是可选择的，非强制的。所以在没有系统策略管理的时候，USB PD Providers 和 Consumers 也可以正常工作。这一点包括了在系统中，USB Host 没有提供系统策略管理或者系统中没有任何的 USB Host。在不存在 Host 的情况下，USB PD 只是用来起到充电的目的，或给设备充电。
一个 USB Host 在没有系统策略管理的情况下，Provider 和 Consumers 可以基于 USB 的电源规则，自己独立协商出 Power, 使得在可用的电源管理选项上没有过多的限制。
2.7.1.2 Device Policy Manager
Device Policy Manager 在一个特定的 Consumer 或者 Provider 中提供机制来监测和控制 USB PD 的系统。Device Policy Manager 通过和系统策略进行通讯能够使 Local Policy 在系统中被强制执行。Local Policy 被制定在每一个依据于Device Policy Manager 控制下的 SRC/SNK 端口之中，用 Policy Engine 进行通讯且 USB-C 的端口控制。
2.7.1.3 Policy Engine
Providers 和 Consumers 在它们直连的 SRC 或 SNK 中可以自由地执行 Local Policies。对端口来说是支持通过 Policy Engine 进行协商和状态机制的执行的。
Policy Engine 会直接与 Device Policy Manager 相互作用为了来确定当前的 Local Policy 被执行。无论何时，当 Local Policy 发生改变的时候，Device Policy Manager 都会通知给 Policy Engine。
第二章 第七节：架构概述（二）
2.7.2 Message Formation and Transmission
2.7.2.1 Protocol Layer
The Protocol Layer 会组织好端口间用来通讯的 Message。比如 Capabilities Messages，request Message 和 acknowledgements。此外，它也会组织用来进行转换角色的 Message 和保持存在的状态。它从 Policy Engine 收到输入的Message，然后表明具体发送哪个 Message，同时向 Policy Engine 表明响应的Message。
The basic protocol 使用推送模式即 Provider 向 Consumer 通告自己的能力，相应地会用 Request 来响应。但是，the Consumer 可以异步申请 the Provider 能够提供的能力，即选择另一种电压/电流。
2.7.2.2 PHY Layer
PHY Layer 是负责通过 USB Type-C CC 来进行收发和管理数据的。它尽可能的在线路上避免冲突，而且当发生冲突时，矫正它。它也会用 CRC 来检测 Message 是否错误。
2.7.3 Collision Avoidance
2.7.3.1 Policy Engine
在 SRC 端的 PE 状态机表明了 Protocol Layer 上由 SRC 发起的每个 AMS 序列初始和结束的状态。在 SNK 端的 PE 状态机表明了 Protocol Layer 上由 SNK 发起的每个 AMS 序列的初始状态。这一点能够协调由两端发起的 AMS 的序列。
2.7.3.2 Protocol Layer
在 SRC 端的 Protocol Layer 会请求 PHY 将 Rp 的值设置成 SinkTxOk 表明 SNK可以通过发送序列中第一个 Message 来发起 AMS。既然 SRC 打算发起 AMS，那么在 SRC 端的 Protocol Layer 会请求 PHY 将 Rp 的值设置成 SinkTxNG，表明 SNK 此时不能发起 AMS。
在 SNK 端的 Protocol,当 Policy Engine 表明 AMS 是可以发起的时候，在发送序列中第一个 Message 来发起 AMS 序列之前将会等 Rp 的值被设置到 SinkTxOk。
2.7.3.3 PHY Layer
在 SRC 端的 PHY Layer 会依照 Protocol Layer 的请求把 Rp 的值设置成 SinkTxOk 或 SinkTxNG。而 SNK 端 PHY Layer 将会检测当前的 Rp 的值然后通知 Protocol Layer。
2.7.4 Power supply
2.7.4.1 Source
每一个 Provider 包含一个或多个 SRC 端口及相应的一个或多个 Power 源。这些 SRC 由本地策略所控制。SRC 开始 USB 的默认工作状态，端口在 VBUS 上
提供 vSafe0V 或 vSafe5V,在一个 Hard Reset 之后也会回到这个状态。如果 SRC将 vSafe0V 作为默认状态，检测到连接的时候，将它的输出调整到 vSafe5V。
2.7.4.2 SNK
Consumers 被认为有一个和端口连接的 SNK。这个 SNK 也由自己的本地策略所控制。当端口工作在 vSafe5V 和 USB 定义的默认电流等级，此时 Sink 开始工作在 USB 的默认状态。且在连接断开或发生 Hard Reset 之后会回到这个状态。
2.7.4.3 Dual-Role-Power Ports
DRP 既可以作为 SRC 也可以作为 SNK 来工作而且可以通过用 PRS 或 FRS 来改变端口间的工作模式。
2.7.4.4 Dead Battery or Lost Power Detection
USB Type-C 1.2 中定义了一套机制打算用 Dead Battery 来给 SNK 或 DRP 充电。
#欢迎使用CSDN-markdown编辑器 第二章 第七节：架构概述（三）
2.7.5 DFP/UFP
2.7.5.1 Downstream Facing Port (DFP)
在 USB 拓扑结构中，下行端口或 DFP 和 USB-A 起到的作用是相当的。DFP 就相当于 USB 中的 Host 而且只有当它是一个 DFP 的时候才支持 USB 的通信。
一个类似于墙插的产品可以是 DFP，然而却没有进行 USB 通信的能力。DFP 也可以作为主总线来控制交替模式。
2.7.5.2 Upstream Facing Port (UFP)
在 USB 拓扑结构中，上行端口或 UFP 和 USB-B 起到的作用是相当的。UFP 就相当于 USB 中的 Device 而且只有当它是一个 UFP 的时候才支持 USB 的通信。
Products which charge 可以是一个 UFP 然而却没有进行 USB 通信的能力。
2.7.5.3 Dual-Role Data Ports
DRP 既可以作为 SRC 也可以作为 SNK 来工作而且可以通过 DRS 来转换数据模式。Note:产品的数据模式是 DRD，但不是 DRP。例如从逻辑上讲，它们可以在 DFP 和 UFP 之间转变自己的数据模式，即使它们是 SRC-Only 或是 SNK-Only。
2.7.6 VCONN Source
一个端口，最初为 SRC，同时也是 VCONN SRC。Cable Plug 的线缆根据 VCONN供电来判断 SOP’。在 SRC 和 SNK 端口之间谁来给 VCONN 供电是可以转换的，以此来确保可以持续给 Cable Plug 供电。为了确保和 Cable Plug 之间进行可靠的通讯，只有 VCONN SRC 允许和 Cable Plug 进行通讯。在 PRS,DRS 或 FRS 之前，如果它们需要在转换角色之后可以和 Cable Plug 进行通讯，端口需要确保自己是 VCONN SRC。
2.7.7 Cable and Connectors
2.7.7.1 USB-C Port Control
USB-C 端口的控制模块提供了机制来通知 Device Policy Manager 关于线缆的连接与断开。USB PD 的标准认为经过论证的 USB 线缆和相关的检测机制都定义在 USB Type-C 1.2 的标准中。
2.7.8 Interactions between Non-PD/BC/PD devices
USB PD 只有在两个具备 PD 能力设备直连的时候才会正常工作的。当一个设备发现它处于混合环境当中时，即另一个设备不具备 PD 的能力，那么现有提供 vSafe5V 的规则就是根据 USB2.0, USB3.1, USBBC1.2 or USB Type-C 1.2 等标准制定的。
将会有两种情况需要考虑到：
（1）The Host(DFP/Source)是 Non-PD,自己不会向 SNK 发送任何的通告能力。与其连接上并且具备 PD 能力的设备不会看到任何的通告能力，将会采用基于 USB2.0,USB3.1,USBBC1.2 或 USB Type-C1.2 标准的模式来工作。
（2）The Device(UFP/Sink)是 Non-PD,自己不会看到任何对端发来的通告能力，也就不会响应对端的通讯。The Host 将会按照 USB2.0,USB3.1,USBBC1.2 或 USB Type-C1.2 中定义的持续输出 vSafe5V 给 VBUS。
2.7.9 Power Rules
Power Rules 定义了由 USB PD 中的 SRC 提供和 USB PD 的 SNK 所使用电压，电流的范围。详细的介绍请看第十章。