USBPD规范第二章（中文完整版）

USBPD规范第二章（中文完整版）USBPD规范第二章浓缩了USBPD规范的精华，走马观花地讲了USBPD协议的工作原理。假设你已经接触过USBPD协议，有一些基本的了解和相关知识，请先阅读本章，浅浅地尝一尝，试着找找感觉再决定要不要更加深入地了解和学习。2.1USBPD介绍在USBPD中，一对直连的端口用USBType-C连接器中的CC线作为通讯信道来协商出电压，电流以及在Cable里面供电的方向。这种被采用的机制，独立于其它的用来协商USB电源的操作方式。USBPD也会充当一个边带信道使其能够支持标准或厂家自定义的模式操作。工作Mode是与SVID联系在一起的。在PD协议中结构化的VDMMessage可以被用来发现支持的SVID和Modes，当有需要的话，同样支持Modes的进入与退出。多个ActiveModes可以同时工作。一旦用这个标准协商出来的契约的关系，都将替换任何之前使用的USB2.0、USB3.1、USBType-C1.2或USBBC1.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、USBType-C或者USBBC1.2相关标准定义的规则相一致。在PD协商发生之后，可以输出比标准定义中更高或更低的电压和更高的电流。它也可以完成PRS或FRS来交换电源供给的角色，从而使得DFP变成受电一方，UFP变成供电那一方。同时可以通过DRS使得DFP变成了UFP，反之亦然。通过执行VCONNSwap来改变VCONN供电的方向。在显性契约关系建立之前，SRC可以发现连接上的线缆能力和特性。了解在USBType-C1.2中被标记5A能力的线缆和其它线缆的一些细节比如支持的速率这一点很重要。发生在端口连接上的初始，在显性契约关系建立之前，DFP同时也是SRC的情况下开始进行Cablediscovery。PRS和FRS之后，显性关系建立之前，在UFP为SRC，隐性契约在工作的情况下，也是有可能进行Cablediscovery的动作。一旦是显性契约工作的状态下，只有DFP允许和连接上的Cable进行通讯。不仅包括了Discoveridentity，也包括了Cable所支持的DiscoverSVID，DiscoverMode，EnterMode和ExitMode模式。2.2章节概述此规格包含了下面的部分：2.3更新和兼容性2.3.1ChangesfromRevision2.0下面是对PD3.0与PD2.0主要变化的总结：1、支持版本2.0和3.0的操作，以确保向后可以兼容现有产品（seeSection6.2.1.1.5）。2、原来的Profile丢弃不用，取而代之的是PD的供电模式(seeSection2.7.9)。这种改变也适用于USBPD2.0。3、BFSK支持已弃用的设备，包括传统电缆，传统连接器，传统的电池耗尽的操作和相关的测试模式。4、ExtendedMessage数据的有效载荷长度达到了260bytes(seeSection6.2.1.2)。支持将扩展消息分块为USBPD的大小，以实现与传统PD硬件的兼容性。5、只有VCONNSRC允许和CablePlug进行通讯(seeSection2.5.4)6、SRC尝试协调尽可能地避免碰撞使SRC和SNK中的任意一个端口能够发起AMS的序列。USBType-C1.2中，用SRC端上拉的Rp电阻值来表明当SNK(能或不能)向SRC或者CablePlug发起AMS的序列(seeSection2.7.3)。SRC和SNK中的任意一个端口都能发起VendorDefined定义的Message序列。当具备可以给VCONN供电的能力时，SRC和SNK中的任意一个端口都可以和CablePlug进行通讯。7、删除了Attention命令的时间限制。FRS定义了能够将外接电源的docks和hubs快速转换到buspower模式上，当它们去除外部电源供给的时候(seeSection6.3.17)。8、附加的状态和发现扩展的供电能力和状态。电池的能力和状态。制造商定义的信息。9、无源电缆，有源电缆和AMAVDO中字段的改变表明了将StructuredVDM更改到2.0的版本。10、支持与USB安全相关的请求与响应。11、支持USBPD固件的更新请求与响应。12、系统策略在当前的引用。2.3.2CompatibilitywithRevision2.0USBPD标准的3.0版本被设计用来完美兼容USB2.0的系统，此系统在USBType-C1.2连接器上使用BMC的信号是和2.0版本的硬件是一致的。这份标准强制要求了所有3.0版本必须完全支持USBPD2.0的操作。它们必须发现对端或CablePlug所支持的版本，然后用最低，常见的版本号使回复到与之对应的状态。（seeSection6.2.1.1.5）这个标准规定了ExtendedMessage，其包的长度达到了260bytes(seeSection6.2.1.2)。这些Message要比目前PHYHW中包的长度要长。为了可以支持2.0版本的基础系统，分块机制被强制执行以便Message被限制到PD2.0版本的尺寸，除非发现两个系统都可以支持最长包的收发。这个标准包括了VendorDefinedObjects(VDO)的变化用来发现识别passive/activecable和AlternateModeAdapters(AMA)(seeSection6.4.4.2)。为了能使系统决定用哪个VDO，结构化的VendorDefinedMessage(SVDM)的版本号递增到2.0。如果变得有需要的话，版本号也已经包含了VDO本身，来促进接下来的变化。2.4USBPD支持设备在Figure2-1中可以看到一些具有USBPD能力的设备(aHost,aDevice,aHub,aCharge)。这些都是仅供参考，不会限制基于这份标准而建立的产品可能的配置。每一个具有PD能力的设备被认为至少组成了一个端口。Providers被认为是SRC,Consumers被认为是SNK。每个设备包含了一个甚至更多下面的要素。UFPs可以是：受电。可选择地供电(一个DRP的设备)。可选择地通过USB进行数据通讯。用SOPPackets进行通讯。可选择地用SOP*Packet进行通讯。DFPs可以是：供电。可选择地受电(一个DRP的设备)。可选择地与通过USB进行数据通讯。用SOPPacket进行通讯。可选择地用SOP*Packet进行通讯。ASRCthat可以是：一个外部电源(比如AC)。蓄电装置(比如电池)。从另一个端口派生的(比如远供的Hub)。ASink可以是：蓄电装置(比如电池)。用于给内部功能供电的设备。用于给连接到其它设备供电的设备。AVCONNSRC可以是：可以是任意一个端口，既可以是DFP/UFP,也可以是SRC/SNK。给CablePlug供电。在任何时候，只有是能够提供VCONNSRC的端口才可以和CablePlug进行通讯。2.5SOP*通讯2.5.1IntroductionSOPMessage是用来识别是否是SRC和SNK端口的信息交互（SOP交互）还是对一端为CablePlug的信息交互（SOP’/SOP”）。SOP/SOP’/SOP”统称为SOP*。CablePlug在SOP’和SOP”信息交互的相关术语被用来声明能够进行PD交互线缆的性能(看插头上有没有检测到Ra）。接下来的部分是描述SOPMessage在端口与端口之间和端口与CablePlug之间的交互工作流程。2.5.2SOP*MessageCollisionAvoidance对所有的SOP*Message，SRC为了避免在总线上通讯受到干扰，允许当SNK不需要和自己通讯时发起Message交互，从而协调通讯过程。一旦SRC和SNK之间被新的显性关系所代替，此时SNK发起一段消息序列。此序列可以和SRC或者CablePlug进行通讯。而SRC一旦需要发起一段消息序列就会向SNK表明，此时SRC在自身发起一段消息序列之前应该等所有SNKSOP*通讯完成。2.5.3SOPCommunicationSOP的Message被用来SRC和SNK的端口通讯。SOP通讯存在于SRC和SNK端口之间而不会被任何的CablePlug所干扰。在完成和Power相关的协商操作之后，SOP的Message交互尽可能的比其它SOP*Message优先开始。和Power相关的信息序列被允许可以打断其它序列的进行,确保在总线上优先进行Power的协商和控制。2.5.4SOP’/SOP”CommunicationwithCablePlug当CablePlug检测到VCONN打开后，SOP’的Message可以被CablePlug里的电子设备所识别。当CablePlug支持SOP’的通讯后，才会支持SOP”的通讯。在连接时VCONNSRC是SRC/DFP,然而这些所有的模式都可以通过PDMessage来改变。CablePlug不会识别SRC和SNK之间SOPMessage的通讯。Figure2-2部分介绍了VCONNSRC(DFP/UFP)和CablePlug之间进行SOP*通讯的用法。所有的SOP*信息通讯都发生在CC上。这意味着必须协调SOP*信息通讯来防止阻碍其它重要的通讯。对于不识别SOP/SOP’/SOP”的产品来说，这一点看上去像一个非空闲的信道，从而导致丢包和重传。两个端口之间是优先进行通讯的，意味着与CablePlug的通讯是可以被打断的，但不会导致SoftReset和HardReset的产生。当没有契约或者默认契约关系在工作时（例如.在PRS或者FRS之后）SRC(既可以是DFP也可以是UFP，但必须是VCONNSRC)可以用SOP’的包来与CablePlug进行通讯，以此来发现并获得它的特性。在这个阶段所有与CablePlug的通讯都是由SRC端发起和控制，以此防止和SOP*的包形成冲突。SNK是不会和CablePlug进行通讯的，即使它是DFP，也要丢掉任何收到的SOP’类型的包。当明确的契约关系在工作时，VCONNSRC（可以是DFP也可以是UFP）可以用SOP’/SOP”的包和CablePlug进行通讯。在这个阶段所有与CablePlug的通讯都是由VCONNSRC发起，以此来防止和SOP*的包形成冲突。不是VCONNSRC的那个端口则不会与CablePlug进行通讯，同时也不会识别任何收到的SOP’/SOP”Message。只有是DFP，同时也是VCONNSRC的时候，可以允许发送SOP*来控制进入或退出Mode及管理相应的工作模式（。通过发送DiscoverIdentity来读取Cable的信息，如果是ActiveCable，则继续发送DiscoverMode/EnterMode/ExitMode来控制Mode的整个过程）Note:CablePlug既可以和DFP连接，也可以和UFP连接。2.6操作概述USBPD端口中供电的一方是SRC，受电的一方为SNK。在端口间，每个PD连接中只有一个是SRC，一个是SNK。默认连接上的SRC端（提供上拉电阻）也是DFP，也是VCONNSRC。同时连接上的SNK端（提供下拉电阻）也是UFP，不是VCONNSRC。SRC/SNK，DFP/UFP，VCONNSRC的模式都可以通过PDMessage进行转换。同时支持SRC和SNK的端口叫做DRP，同时支持DFP和UFP的端口叫做DRD。下面的部分描述的是高等级的工作来承担DFP，UFP，SRC，SNK的角色。这些部分不会描述不被允许的工作状态；但如果一种特定的行为没有描述到，那就很可能没有被这个标准所支持。PD如何在一个PDUSB设备上绘制自己状态的详情请看9.1.1章。2.6.1SRCOperationSRC工作状态的不同取决于连接状态：在连接状态时(没有PD的连接)1.对一个SRC_Only的端口来说，SRC会检测SNK有无连接上。2.对DRP端口来说会切换使其变成SRC以完成和SNK的连接。3.在SRC端设置VBUS到vSafe5V。在PD连接之前(没有PD的连接或者PD协商还没建立)1.在发SRC_CAP之前，SRC可以检测连接上的Cable的类型，然后根据检测到的Cable的类型来改变它的通告能力。（1）SRC会尝试用SOP’的Message与CablePlug进行通讯。如果CablePlug响应，则开始与其通讯。（2）默认的USBType-C的线缆支持的电流是3A，但我们可以通过发SOP’的Message来获得这根线缆的能力。2.SRC会定期的在每个tTypeCSendSourceCap时间内通过向对端发送SRC_CAP来通告自己的供电能力。在PD连接的阶段(PD连接还没完成或没有建立明确的契约关系)1.有下面两种中的一种说明检测到存在的对面端口具有PD功能。（1）SRC收到了对端响应SRC_CAP而发出的GoodCRC。（2）SRC收到了HardReset信号（此时对端没能收到SRC发出的SRC-CAP）。建立契约关系(PD连接但在PRS或FRS之后的契约关系还没建立)1.SRC从SNK那边收到RequestMessage，然后用Accept来响应SRC发出的Request。如果是一个合法，有效的Request,当准备好供电给SNK协商好的Power之后，SRC会发出PS_RDYMessage，这个时候显性契约就建立了。2.DFP不会生成SOP’或SOP”的包，也不需要检测SOP’/SOP”包,就算检测到也会将其丢掉。在PD连接过程中(建立了显性契约关系状态到PE_SRC_Ready状态)1.SRC会处理和响应(如果需要的话)所有收到的包，无论何时，当它本地策略需要的时候会发送恰当的包。（1）无论何时供电的能力改变了，SRC会通过发SRC_CAP来通知SNK。（2）SRC在CC线路上总是assertedRP。（3）当端口电力模式为DRP时，SRC可以发起或收到电力模式转变的请求。在PRS之后，SRC将会变成SNK，在明确的契约关系形成之前，由默认的契约关系暂时代替其工作。（4）当端口数据模式为DRD时，SRC可以发起或收到数据模式转变的请求。在DRS之后，DFP会变成UFP。此时端口的电力模式还是SRC，同时VCONNSRC也不会发生改变。（5）可以发起或接收转变VCONNSRC供应的请求。当VCS通过两端被申请的时候，此时端口的电力模式和数据模式没有发生改变。2.当SRC也是VCONNSRC的时候，在没有其它SOP通讯时，可以在任何时候用SOP’或SOP”与CablePlug进行通讯。（1）当SRC收到SOP的包，就算此时进行SOP’或SOP”通讯也要立即结束，优先开始SOP通讯(CablePlug超时，不会重试了)。（2）如果SRC正在进行SOP’或SOP”通讯的时候需要发起SOP通讯(比如供电能力的改变)，SOP’或SOP”通讯都将被终止。3.当端口既是SRC，同时也为DFP时（1）SRC可以通过对CablePlug发包来控制Mode的进入和退出以及可以管理工作的模式。（2）SRC可以发起结构体和非结构体的VDM的Message。（3）SRC可以在SNK控制进入和存在的模式和用结构体VDM的Message来控制其工作的模式。4.如果SRC端口是一个多口的系统（1）当需要输出备用功率时，将产生Gotomin的Request。断开或通讯错误1.当SRC检测到线路断开后，会在tSafe5V的时间内将电压降到Vsafe5V,在tSafe0V的时间内降到Vsafe0V(SRC通过检测ADC的值来看线路有无断开)。2.当SRC在tReceive时间内，收到为响应Message而发出的GoodCRC包，在此过程中检测到了错误。（1）由于CRCReceiveTimer的期满，在tSoftReset时间内，产生了SoftReset。（2）如果SoftReset没有按时完成的话，就会在CRCReceiveTimertimerout之前，在tHardReset时间内产生HardReset。同时在1-1.5S内将VBUS调到USB的默认电压5V。（3）当端口SRC同时也是VCONNSRC时，在发生HardReset的过程中VCONN也是会掉电的。3.SRC为了进一步尝试通讯但没有收到响应表示出现了错误。4.在Power协商过程中出现的错误会自动地产生HardReset为了将Power维持在默认的等级(5V)。错误的处理1.当协议层出现错误时，会引起端口中的任意一个发出SoftReset.从而复位counters,timers和states，但这个动作不会改变协商好的电压，电流或端口的模式(比如SRC,DFP/UFP,VCONNSRC)也不会导致退出现有的工作模式。2.当线路中出现严重错误的时候，两个端口中的任意一个都可能会发出HardReset的信号。（1）和SoftReset一样，HardReset会resetprotocol,同时为了保护SNK，将PowerSupply降到vSafe0V或vSafe5V输出。（2）使端口的数据模式维持在最初状态的DFP。（3）当SNK为VCONNSRC时，此过程会关闭VCONN供电。同时将SRC维持在VCONNSRC的状态。3.在HardReset产生后，寄望于对端可以在tNoResponse的时间内对HardReset请求做出响应。如果未有响应，进行HardReset累加（最大为2）直到SRC进入ErrorRecovery状态。2.6.2SNKOperation在连接状态时（没有PD的连接）1.SNK会通过对端有无输出vSafe5V来判断连接。2.对DRP端口来说会切换使其变成SNK以完成和SRC的连接。3.一旦SNK在VBUS上检测到vSafe5V的存在，它通过等对端是否发出SRC_CAP来判断对端为具有PD能力的SRC。4.如果SNK没有在tTypeCSinkWaitCap时间内收到SRC发出的SRC_CAP，通过发出HardReset信号寄望于SRC(具有PD能力)可以发出SRC_CAP。5.SNK不会生成SOP’或SOP”的包，也没有必要检测SOP’或SOP”的包，同时不会去识别它们。建立PD的连接(PD连接没完成或没有建立明确的契约关系)1.SNK收到了SRC_CAP的Message,然后用GoodCRC响应。2.SNK不会生成SOP’或SOP”的包，也没有必要检测SOP’或SOP”的包，就算检测到也要将其丢掉。建立显性契约关系(PD连接但在PRS或FRS之后的契约关系还没建立)1.SNK从SRC那边收到SRC_CAPMessage,然后用RequestMessage向SRC发出供电请求。如果是一个合法，有效的Request,SNK收到了对端的AcceptMessage，当准备好供电给SNK协商好的Power之后，同时会收到SRC发出的PS_RDYMessage，这个时候显性契约就建立了：（1）SNK申请的电压应该是SRC发出的电压能力中的一个，即使它是被USB2.0,USB3.1,USBType-C1.2或USBBC1.2所支持的vSafe5V输出，为的能够协商更高的电压。如果用了RequestMessage将会导致错误，SNK就不会向申请任何的供电请求。（2）假如SNK申请的电压能力不在SRC所能提供的范围内，那么将以默认的第一个进行申请，SNK将它改变申请的动作通知最后一个。（3）SNK不会生成SOP’或SOP”的包，也没有必要检测SOP’或SOP”的包,就算检测到也要将其丢掉。在PD连接过程中(建立了显性契约关系状态到PE-SNK-Ready状态)1.SNK会处理和响应（如果需要的话）所有收到的包，无论何时，当它本地策略需要的时候会发送恰当的包。2.当SNK的申请能力需要改变的时候，会通过发新的RequestMessage来通知SRC。SNK申请的电压应该是SRC发出的电压能力中的一个，即使它是被USB2.0,USB3.1,USBType-C1.2或USBBC1.2所支持的vSafe5V输出，为的能够协商更高的电压:（1）在一个错误的状态中，SNK不会用RequestMessage来申请任何的电压能力。（2）假如SNK申请的电压能力不在SRC所能提供的范围内，那么将以默认的第一个进行申请，SNK将它改变申请的动作通知最后一个。3.SNK在CC线路上总是assertedRD。4.当端口电力模式为DRP时，SNK可以发起或收到电力模式转变的请求。在PRS之后，SNK将会变成SRC，在明确的契约关系形成之前，由默认的契约关系暂时代替其工作。5.当端口数据模式为DRD时，SNK可以发起或收到数据模式转变的请求。在DRS之后，DFP会变成UFP.端口的电力模式还是SNK，同时VCONNSRC也不会发生改变。6.SNK可以发起或接收转换VCONNSRC供应的请求.在VCONN交换期间，是可以被两端所运用的(中断之前)。此时端口的电力模式和数据模式没有发生改变。7.当SNK也是VCONNSRC的时候，在没有其它SOP通讯时，可以在任何时候用SOP’或SOP”与CablePlug进行通讯。（1）当SNK收到SOP的包，就算此时进行SOP’或SOP”通讯也要立即结束，优先开始SOP通讯(CablePlug超时，不会重试了)。（2）如果SNK正在进行SOP’或SOP”通讯的时候需要发起SOP通讯(比如供电能力的改变)，SOP’或SOP”的通讯都将被终止。（3）当端口SNK同时也是个DFP时，可以通过对CablePlug发包来控制Mode的进入和退出以及可以控制工作的模式。8.当端口既是SRC，同时也为DFP时（1）SNK可以发起结构化和非结构化的VDM的Message。（2）SNK可以在SRC端口上控制Mode进入与退出和用结构化VDM的Message来控制其工作的模式。通讯错误或断开1.当SNK检测到线路上没有VBUS输出时，这就意味着PD连接的结束，除非是由于HardReset,PRS,FRS中的一个导致状态回到vSafe0V。2.SNK检测到插头的移除,然后开始进行放电。3.当SNK在tReceive时间，收到了为响应Message而发出的GoodCRC包的过程中检测到了错误。（1）由于CRCReceiveTimer的期满，在tSoftReset时间内，产生了SoftReset。（2）如果SoftReset没有按时完成的话，就会CRCReceiveTimertimerout之前，在tHardReset时间内产生HardReset。同时在1-1.5S内将VBUS调到USB的默认电压5V。（3）SNK为了进一步尝试通讯但没有收到响应表示出现了错误。4.在Power协商过程中出现的错误会自动地产生HardReset为了将Power维持在默认的等级(5V)。错误的处理1.当协议层出现错误时，会引起端口中的任意一个发出SoftReset。从而复位counters,timers和states，但这个动作不会改变协商好的电压，电流或端口的模式(比如SRC,DFP/UFP,VCONNSRC)也不会导致退出现有的工作模式。2.当线路中出现严重错误的时候，两个端口任意一个都可能会发出HardReset的信号。（1）和SoftReset一样，HardReset会resetprotocol,同时为了保护SNK，将PowerSupply降到vSafe0V或vSafe5V输出。（2）使端口的数据模式维持在最初状态的UFP。（3）当SNK为VCONNSRC时，HardReset会关闭VCONN供电.此时将回到最初SRC也是VCONNSRC的状态。（4）将会导致退出所有的模式，比如SRC会退出现有的工作模式。在HardReset产生后，寄望于SRC可以在tTypeCSinkCap的时间内对HardReset请求做出响应。如果SRC未有回应，在UFP还维持在PESNKWaitforCap状态的时候，再发出两个HardReset信号。2.6.3CablePlugCablePlug是由VCONN供电的，但不需要清楚此时的状态关系。CablePlug不会主动发起Message的序列，只有为了响应VCONNSRC发的包才会发起Message。断开或通讯错误：1.在任何时候，通讯都可以被中断。2.在VCONNSRC(DFP/UFP)与CablePlug的通讯的时候，没有时间超时的说法。3.CablePlug准备响应可能的重复请求。错误地处理1.CablePlug检测到HardReset信号后来判定SRC和SNK已经Reset，之后Reset自身(相同的掉电过程)。（1）CablePlug自身不能生成HardReset信号。（2）HardReset会使VBUS和VCONN同时掉电，这一点也就相当于ResetCablePlug自身。2.CablePlug检测到CableReset的信号来决定是否需要Reset它自身（相同的掉电过程）。2.7ArchitecturalOverview架构概述逻辑架构并没有打算作为一种实现架构。按照定义，实现架构是产品定义的一部分，即它是在这个标准的范围之外的。在每个具有USBPD能力的设备里面，USBPD架构是由大量主要成分组成的。通讯堆栈在Figure2-3可以看到包括了：ADevicePolicyManager(seeSection8.2)存在于所有的设备当中，通过一个或多个端口的LocalPolicy用来管理USBPD内部的资源。APolicyEngine(seeSection8.3)存在于每个USBPD的端口中来执行LocalPolicy。AProtocolLayer(seeChapter6)使Source和Sink端口之间的Message进行交换。APhysicalLayer(seeChapter5)操控通讯线路上bits的传送与接收，同时也操控数据的传送。此外，具有USBPD能力的设备同样可以作为USB设备在USB中实现通讯(seeFigure2-4)。一种任意的系统策略管理器(seeChapter9)存在于USBHost与PD设备之间的通讯中，经过root端口，可能地遍布在一棵树上的USB集线器上。在每个设备上，设备策略管理器与USB接口相互作用为了可以在域中提供和更新PD的相关信息。Note：PD设备不需要有一个像USB设备那样的接口。Figure2-5描述了两个连接PD端口的逻辑模块。另外，通讯协议stack部分上面也有描述包括了:作为一个SRC或者DRP的设备：一个或多个的SRC向一个或多个的端口供电。作为一个SNK或者DRP的设备：一个SNK吸收电能。一个USB-C接口的控制模块(seeSection4.4)会用USBType-C1.2中定义的协议来检测线缆的连接或断开。USBPD用的是USBType-C1.2定义的标准线缆。设备的策略管理器会和通信stack进行通讯，SRC/SNK和USB-C的控制模块来管理Provider和Consumer中的资源。Figure2-5说明了一个Provider和Consumer内部通讯的框架结构。DRP的设备结合了Provider和Consumer的功能要素。Provider也可以包括多个的SRC端口，它们每一个都有自己的通讯stack和USB-C接口的控制。2.7.1Policy存在两种可能等级的策略:1)系统策略应用在系统范围内来管理多个的Providers和Consumers。2)本地策略通过DPM作用在一个Provider或一个Consumer中。策略包括了一些逻辑模块:SystemPolicyManager(整个系统范围内)DevicePolicyManager(每一个Provider或Consumer)PolicyEngine(每一个SRC和SNK端口)2.7.1.1SystemPolicyManager既然USBPD的协议本质上是端口对端口，系统策略的启用需要另外的通信机制即USB来实现通讯。系统策略管理会监控和控制通过USB连接上的各个Provider和Consumer的状态。系统策略管理存在于USBHost当中，每一个连接上的设备用设备策略管理器通过USB口进行通讯。没有USB数据通信能力的或者没有数据连接的设备将不能参加策略的管理。任何给定的系统，系统策略管理是可选择的，非强制的。所以在没有系统策略管理的时候，USBPDProviders和Consumers也可以正常工作。这一点包括了在系统中，USBHost没有提供系统策略管理或者系统中没有任何的USBHost。在不存在Host的情况下，USBPD只是用来起到充电的目的，或给设备充电。一个USBHost在没有系统策略管理的情况下，Provider和Consumers可以基于USB的电源规则，自己独立协商出Power,使得在可用的电源管理选项上没有过多的限制。2.7.1.2DevicePolicyManagerDevicePolicyManager在一个特定的Consumer或者Provider中提供机制来监测和控制USBPD的系统。DevicePolicyManager通过和系统策略进行通讯能够使LocalPolicy在系统中被强制执行。LocalPolicy被制定在每一个依据于DevicePolicyManager控制下的SRC/SNK端口之中，用PolicyEngine进行通讯且USB-C的端口控制。2.7.1.3PolicyEngineProviders和Consumers在它们直连的SRC或SNK中可以自由地执行LocalPolicies。对端口来说是支持通过PolicyEngine进行协商和状态机制的执行的。PolicyEngine会直接与DevicePolicyManager相互作用为了来确定当前的LocalPolicy被执行。无论何时，当LocalPolicy发生改变的时候，DevicePolicyManager都会通知给PolicyEngine。2.7.2MessageFormationandTransmission2.7.2.1ProtocolLayerTheProtocolLayer会组织好端口间用来通讯的Message。比如CapabilitiesMessages，requestMessage和acknowledgements。此外，它也会组织用来进行转换角色的Message和保持存在的状态。它从PolicyEngine收到输入的Message，然后表明具体发送哪个Message，同时向PolicyEngine表明响应的Message。Thebasicprotocol使用推送模式即Provider向Consumer通告自己的能力，相应地会用Request来响应。但是，theConsumer可以异步申请theProvider能够提供的能力，即选择另一种电压/电流。2.7.2.2PHYLayerPHYLayer是负责通过USBType-CCC来进行收发和管理数据的。它尽可能的在线路上避免冲突，而且当发生冲突时，矫正它。它也会用CRC来检测Message是否错误。2.7.3CollisionAvoidance2.7.3.1PolicyEngine在SRC端的PE状态机表明了ProtocolLayer上由SRC发起的每个AMS序列初始和结束的状态。在SNK端的PE状态机表明了ProtocolLayer上由SNK发起的每个AMS序列的初始状态。这一点能够协调由两端发起的AMS的序列。2.7.3.2ProtocolLayer在SRC端的ProtocolLayer会请求PHY将Rp的值设置成SinkTxOk表明SNK可以通过发送序列中第一个Message来发起AMS。既然SRC打算发起AMS，那么在SRC端的ProtocolLayer会请求PHY将Rp的值设置成SinkTxNG，表明SNK此时不能发起AMS。在SNK端的Protocol,当PolicyEngine表明AMS是可以发起的时候，在发送序列中第一个Message来发起AMS序列之前将会等Rp的值被设置到SinkTxOk。2.7.3.3PHYLayer在SRC端的PHYLayer会依照ProtocolLayer的请求把Rp的值设置成SinkTxOk或SinkTxNG。而SNK端PHYLayer将会检测当前的Rp的值然后通知ProtocolLayer。2.7.4Powersupply2.7.4.1Source每一个Provider包含一个或多个SRC端口及相应的一个或多个Power源。这些SRC由本地策略所控制。SRC开始USB的默认工作状态，端口在VBUS上提供vSafe0V或vSafe5V,在一个HardReset之后也会回到这个状态。如果SRC将vSafe0V作为默认状态，检测到连接的时候，将它的输出调整到vSafe5V。2.7.4.2SNKConsumers被认为有一个和端口连接的SNK。这个SNK也由自己的本地策略所控制。当端口工作在vSafe5V和USB定义的默认电流等级，此时Sink开始工作