1．協議要素
圖1：協議要素
我們可以看一下乙個簡單的協議gb32960.3中的定義。協議流程一般都會使用時序圖進行描述，並對應答機制進行規定。該上報標準中規定，資料校驗正確平台不進行應答，校驗錯誤，平台應答後需t-box重新傳輸該錯誤資料。詳細可參考gb32960.3的附錄b的描述。
2．資料格式
通常情況下一套完整的協議，都會包含很多命令(比如，資料上傳、遠端配置、遠端引數讀取等等)，每乙個命令都會規定乙個完整的資料結構。
前面也提到資料格式可以設計為字元型(二進位制，節省流量)，也可以設計為位元組型(文字型ascii，易讀性高)，這兩種設計都比較常見，主要根據應用場景選擇。此外位元組型還需要規定大端模式和小端模式，這個在跨位元組的訊號解析中會不同。
gb32960為位元組型的協議，我們以位元組型為主進行講解。這兩個的區別在於位元組型一般會規定每乙個位元組表示的含義，而字元型由於都是可見的字元，一般會規定字元的含義。從上面的gb32960資料格式中我們可以發現除了業務字段(資料單元)之外還有許多字段，這些欄位都是該協議所需的包頭/包尾。乙個完整的資料報，一般包含以下幾部分：
這個是協議必須設計的，由於在協議傳輸中是以「流」的形式進行傳輸的，因此該欄位主要是為了確定資料的起始位置，從而進行資料流的解析。同時也由於網路的不確定性，無法保證一條完整的資料幀的一次性就傳送給對方。一般選擇用很少出現的位元組或者字元作為資料報的起始標識。
命令字就是標示此資料幀，需要完成的命令，例如：車輛登入、實時資訊上報等等。
對於位元組流的協議，一般會規定驗證資料幀的驗證部分，例如協議中規定了使用bcc校驗方式，有的協議中可能使用crc的校驗，這個可以根據應用情況進行選擇。對於字元型的協議可以加驗證字段，但因為每一部分都都是可視的字元，也可以不加。
再少出現的字元由於資料幀內容的不確定性，也有可能在資料幀內部出現，因此有些協議在設計時會加入對起始符資料的轉義。例如：jt808協議中規定當資料幀內部出現了起始符資料，也就是資料幀規定的開始部分，就必須轉義，否則就會解析出錯。導致乙個資料幀變成兩部分不完整無法理解的資料幀。在gb32960協議中增加了資料長度，因此當拿到資料起始位置再加上資料長度可以計算出該包的長度，從而定位出下乙個包的起始，這就避免了不轉義導致的解析出錯，也避免「粘包」的問題。
包頭和包尾可根據應用場景增加其他的固定內容，如該協議中有資料加密方式等。
業務資料字段是自定義最多的部分，會根據不同的命令進行定義，根據不同的業務進行定義即可，如下圖定義的車輛登入的資料格式。
3．協議時序
協議的時序，主要是指為了完成某個通訊所進行的互動，包含同步、非同步，以及一些必須的心跳維持等。同時要考慮通訊中的超時、重試等狀態。
Arduino通訊協議設計
最近在一直在研究arduino 硬體平台的東西，先從做乙個簡單的東西入手，比如說，我通過android端向arduino硬體傳送指令，控制電機的正轉 反轉。其中乙個必不可少的問題就是這兩個端裝置之間的通訊問題。它們之間的通訊可以通過藍芽模組來完成，此外，還需要自己設計通訊協議。從最簡單的模組開始，需...
網路通訊 協議設計
2 tlv 2.5 解析步驟 3 上下位機常用自定義協議 4 socket常用自定義協議 參考應用層的資料解析，目前博主涉及工業領域的上下位機串列埠通訊和客戶端服務端socket通訊，都是資料量不大的場景。在串列埠傳輸不穩定時，需要加上crc進行校驗。在socket通訊中，目前通訊丟包的可能性很小，...
通訊協議設計分析
幾乎任何專案都會涉及到通訊，那麼通訊協議的設計就顯得十分關鍵，目前就我個人來說串列埠 網口為從位元組流中取到正確的資料必須要開始通訊協議的設計。轉義字元 幾乎能保證99 的傳輸正確，除非硬體丟包太嚴重。對於很多裝置之間的通訊，經常需要自己設計一套通訊協議。當然此處的通訊協議一般都是建立在tcpip協...