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開始工作