其實(shí)我剛開(kāi)始接手這個(gè)項(xiàng)目的時(shí)候心里是打鼓的。“自定義工控協(xié)議”這六個(gè)字在自動(dòng)化行業(yè)混過(guò)的人都知道意味著什么幀結(jié)構(gòu)設(shè)計(jì)、字節(jié)序、序列化、校驗(yàn)、加密、粘包半包、斷線重連、多車(chē)并發(fā)——任何一個(gè)環(huán)節(jié)踩進(jìn)去輕則加班半個(gè)月重則直接給項(xiàng)目排期畫(huà)上句號(hào)。但我所在的那條AGV調(diào)度線確實(shí)到了不自己動(dòng)手不行的地步。工廠要把AGV從5臺(tái)擴(kuò)到18臺(tái)原有的調(diào)度模塊只能做“開(kāi)閘機(jī)、到點(diǎn)位、急停”這類(lèi)基礎(chǔ)離散控制遇到動(dòng)態(tài)路徑規(guī)劃、任務(wù)批量下發(fā)、多車(chē)避讓協(xié)同完全無(wú)能為力。用原廠協(xié)議棧授權(quán)費(fèi)高得離譜源碼又不開(kāi)放等他們排需求還不知道排到哪一年。最后我在項(xiàng)目會(huì)上拍板基于C#和.NET自研一套AGV調(diào)度通信協(xié)議從幀設(shè)計(jì)到加密容錯(cuò)全部自己來(lái)交付周期壓到三周。這篇文章就是這三周的完整踩坑記錄涉及AGV調(diào)度、自定義協(xié)議、幀設(shè)計(jì)、工業(yè)加密、斷線容錯(cuò)等完整鏈路。如果你也在做AGV調(diào)度、邊緣控制器或者廠級(jí)設(shè)備通信這篇內(nèi)容可以當(dāng)參考手冊(cè)用。1. 整體設(shè)計(jì)與折分協(xié)議不是越復(fù)雜越好1.1 先搞清楚通信協(xié)議要背多少業(yè)務(wù)我在寫(xiě)第一行代碼之前沒(méi)有急著畫(huà)幀結(jié)構(gòu)而是拉了一張需求清單。這個(gè)習(xí)慣是從上一個(gè)項(xiàng)目學(xué)來(lái)的當(dāng)時(shí)因?yàn)樾枨鬀](méi)對(duì)齊協(xié)議改了四版差點(diǎn)把隊(duì)友逼瘋。這次我先把真實(shí)約束列清楚驅(qū)動(dòng)規(guī)模18臺(tái)AGV后期可能擴(kuò)到30臺(tái)通信鏈路必須是點(diǎn)對(duì)點(diǎn)TCP長(zhǎng)連接。指令實(shí)時(shí)性調(diào)度指令從服務(wù)器發(fā)出到AGV控制器收到延遲要求小于100毫秒絕大多數(shù)情況下應(yīng)該落在20到50毫秒。網(wǎng)絡(luò)環(huán)境廠房?jī)?nèi)工業(yè)Wi-Fi和有線混合部署會(huì)存在信號(hào)遮擋、漫游切換、AP重啟等情況不能假設(shè)鏈路永遠(yuǎn)穩(wěn)定。數(shù)據(jù)安全AGV調(diào)度指令涉及路徑、任務(wù)、鎖站一旦被篡改或重放輕則撞車(chē)重則夾人所以完整性校驗(yàn)和防重放必須做好。調(diào)試便利產(chǎn)線維護(hù)人員不會(huì)天天拿著Wireshark抓包協(xié)議自帶的日志和故障定位能力要足夠強(qiáng)。搞清楚了這幾點(diǎn)后面設(shè)計(jì)基本不會(huì)跑偏。協(xié)議不是給自己炫技的而是給產(chǎn)線背書(shū)的。1.2 為什么不用現(xiàn)成的Modbus/OPC UA很多人問(wèn)為什么不直接用Modbus TCP或者OPC UA。說(shuō)實(shí)話如果是簡(jiǎn)單點(diǎn)位讀寫(xiě)Modbus完全夠原廠就是這么接的。但AGV調(diào)度系統(tǒng)里要透?jìng)鞯臄?shù)據(jù)是“結(jié)構(gòu)化的動(dòng)態(tài)任務(wù)包”不是單個(gè)線圈和寄存器能表達(dá)的。Modbus的寄存器尋址方式做復(fù)雜報(bào)文要把數(shù)據(jù)塞進(jìn)一堆寄存器塊里還要自己維護(hù)映射表代碼寫(xiě)出來(lái)極其難看排錯(cuò)也費(fèi)勁。OPC UA更不用提優(yōu)點(diǎn)是生態(tài)完整、安全模型強(qiáng)但在這種嵌入式AGV控制器上輕量級(jí)客戶端SDK不好找就算找到了ARM架構(gòu)下內(nèi)存和CPU開(kāi)銷(xiāo)也是個(gè)問(wèn)題。更重要的是AGV本體上跑的多是C/C或者專(zhuān)用控制器固件你讓現(xiàn)場(chǎng)去適配一套UA協(xié)議棧成本和風(fēng)險(xiǎn)都不小。自研TCP協(xié)議的收益在于幀格式完全可控任何一端用C#、C甚至單片機(jī)裸機(jī)都能解析不依賴特定SDK調(diào)試和定制成本最低。權(quán)責(zé)也清晰出了問(wèn)題自己翻日志就能定位不用拉著原廠一起甩鍋。1.3 協(xié)議棧的模塊邊界劃分協(xié)議棧不是寫(xiě)一個(gè)類(lèi)就完事我拆成了四個(gè)清晰的層項(xiàng)目結(jié)構(gòu)如下AgvProtocol/ ├─ Frame/ // 幀編解碼、粘包拆包、CRC校驗(yàn) ├─ Security/ // AES加密、防重放、密鑰管理 ├─ Transport/ // TCP連接管理、心跳、斷線重連 ├─ Messages/ // 業(yè)務(wù)消息定義、序列化/反序列化 └─ Simulator/ // AGV模擬器、壓測(cè)工具這樣拆分是為了以后替換任何一層都不影響其他層。比如現(xiàn)在用AES做數(shù)據(jù)加密之后想換國(guó)密算法只要改Security層上層業(yè)務(wù)代碼不用動(dòng)。再比如現(xiàn)在TCP假如下一版要支持串口電臺(tái)通信Transport層封裝好接口就能接上。2. AGV調(diào)度幀設(shè)計(jì)從指令需求到字節(jié)級(jí)布局2.1 幀結(jié)構(gòu)總覽協(xié)議設(shè)計(jì)里面最容易犯的錯(cuò)是把幀定得過(guò)于復(fù)雜。復(fù)雜的幀意味著解析代碼多、出錯(cuò)概率高、現(xiàn)場(chǎng)排查難。我最終定的幀結(jié)構(gòu)是把“頭部”焊死固定“尾部”保持固定“數(shù)據(jù)段”按命令自由拼。下面是完整幀布局字段長(zhǎng)度說(shuō)明幀頭標(biāo)志2字節(jié)固定 0xAA 0x55用于幀同步協(xié)議版本1字節(jié)當(dāng)前為 0x01用于協(xié)議升級(jí)命令字1字節(jié)區(qū)分心跳、任務(wù)下發(fā)、狀態(tài)上報(bào)等消息ID2字節(jié)請(qǐng)求-響應(yīng)配對(duì)用于超時(shí)重傳序列號(hào)4字節(jié)單調(diào)遞增用于防重放加密標(biāo)志1字節(jié)0明文1密文數(shù)據(jù)長(zhǎng)度2字節(jié)數(shù)據(jù)段字節(jié)數(shù)不含頭部和尾部數(shù)據(jù)段N字節(jié)業(yè)務(wù)負(fù)載CRC162字節(jié)對(duì)幀頭數(shù)據(jù)段整體計(jì)算幀尾2字節(jié)固定 0x0D 0x0A頭部一共13字節(jié)加上2字節(jié)CRC和2字節(jié)幀尾固定開(kāi)銷(xiāo)17字節(jié)。對(duì)于AGV這種控制報(bào)文這開(kāi)銷(xiāo)完全可接受。為什么幀尾還要加0x0D 0x0A因?yàn)槿f(wàn)一信道上出現(xiàn)半包、粘包導(dǎo)致幀邊界錯(cuò)亂接收端可以重置解析狀態(tài)用幀頭幀尾雙重定位。有些協(xié)議只有一個(gè)幀頭做定位一旦跑飛就要丟完整包等超時(shí)這在工業(yè)環(huán)境很致命。2.2 C#里如何優(yōu)雅地編解碼幀我選擇了手動(dòng)字節(jié)流方式構(gòu)建幀沒(méi)有用BinaryFormatter也沒(méi)有用System.Text.Json做全量序列化。原因是AGV控制器性能有限而且協(xié)議幀包含二進(jìn)制數(shù)據(jù)JSON不管怎么壓縮都比原生二進(jìn)制重。下面是我實(shí)際在用的編碼實(shí)現(xiàn)public static byte[] EncodeFrame(AgvCommand cmd, ushort msgId, uint seq, byte[] payload, bool encrypt, byte[] aesKey) { byte[] data payload; if (encrypt aesKey ! null) { data AesEncryptWithRandomIv(payload, aesKey); // 返回 IV 密文 } using var ms new MemoryStream(); ms.WriteByte(0xAA); ms.WriteByte(0x55); ms.WriteByte(0x01); // 協(xié)議版本 ms.WriteByte((byte)cmd); // 命令字 WriteUInt16BE(ms, msgId); // 消息ID WriteUInt32BE(ms, seq); // 序列號(hào) ms.WriteByte(encrypt ? (byte)0x01 : (byte)0x00); WriteUInt16BE(ms, (ushort)data.Length); ms.Write(data, 0, data.Length); byte[] body ms.ToArray(); ushort crc Crc16Modbus(body, 0, body.Length); byte[] frame new byte[body.Length 4]; Array.Copy(body, frame, body.Length); frame[body.Length 0] (byte)(crc 8); frame[body.Length 1] (byte)(crc 0xFF); frame[body.Length 2] 0x0D; frame[body.Length 3] 0x0A; return frame; }這里我全表統(tǒng)一使用大端字節(jié)序。為什么不用小端因?yàn)锳GV控制器端的單片機(jī)或嵌入式處理器很多是大端體系而且現(xiàn)場(chǎng)還有PLC設(shè)備參與聯(lián)動(dòng)。統(tǒng)一大端能讓所有設(shè)備用同一套規(guī)則解析少踩一半的坑。2.3 業(yè)務(wù)消息任務(wù)下發(fā)、狀態(tài)上報(bào)與心跳幀是傳輸殼真正干活的是數(shù)據(jù)段里的業(yè)務(wù)消息。我給AGV調(diào)度定義了四組核心消息TaskAssign、TaskCancel、StatusReport、Heartbeat。以TaskAssign為例數(shù)據(jù)段里我定了這樣的結(jié)構(gòu)字段長(zhǎng)度說(shuō)明任務(wù)ID4字節(jié)調(diào)度系統(tǒng)生成的唯一任務(wù)編號(hào)目標(biāo)點(diǎn)位4字節(jié)點(diǎn)位編號(hào)優(yōu)先級(jí)1字節(jié)0-255越大越優(yōu)先動(dòng)作類(lèi)型1字節(jié)叉取、放貨、充電、待命等超時(shí)時(shí)間2字節(jié)單位秒0表示不限附加數(shù)據(jù)長(zhǎng)度2字節(jié)后續(xù)附加數(shù)據(jù)長(zhǎng)度附加數(shù)據(jù)N字節(jié)如路徑點(diǎn)列表、貨架編號(hào)對(duì)應(yīng)的消息類(lèi)型枚舉public enum AgvCommand : byte { Heartbeat 0x01, TaskAssign 0x10, TaskCancel 0x11, PathPlan 0x20, PointReach 0x30, StatusReport 0x40, ErrorReport 0x41, Ack 0x80 }消息ID的使用規(guī)則很重要每次請(qǐng)求發(fā)起方遞增一個(gè)msgId接收方回Ack時(shí)必須原樣填回這個(gè)msgId。這樣發(fā)送方可以判斷哪條消息超時(shí)了、哪條需要重發(fā)。最初版本里我沒(méi)做這個(gè)機(jī)制結(jié)果丟包時(shí)根本不知道是哪條指令丟了現(xiàn)場(chǎng)調(diào)車(chē)的時(shí)候一片混亂。3. 工業(yè)級(jí)加密與容錯(cuò)鏈路安全和可靠性怎么落地3.1 加密方案選型AES-CBC還是GCM加密這塊我糾結(jié)了很久。最初想做AES-GCM因?yàn)镚CM自帶完整性校驗(yàn)?zāi)芤淮涡越鉀Q加密和防篡改。但AGV控制器的算力有限有些主控芯片甚至沒(méi)有AES硬件加速指令GCM在軟件實(shí)現(xiàn)上的開(kāi)銷(xiāo)比CBC高不少。而且我們的幀已經(jīng)有CRC16做傳輸層校驗(yàn)對(duì)完整性要求已經(jīng)覆蓋了一部分最終選了AES-CBC。注意一個(gè)問(wèn)題CRC只能防隨機(jī)錯(cuò)誤不能防惡意篡改。如果現(xiàn)場(chǎng)安全要求高后面還是得上帶認(rèn)證的加密模式。我這里按工業(yè)級(jí)中等威脅模型設(shè)計(jì)防竊聽(tīng)、防普通重放不防頂級(jí)攻擊者。AES-CBC落地有幾個(gè)細(xì)節(jié)private static byte[] AesEncryptWithRandomIv(byte[] plainBytes, byte[] aesKey) { using var aes Aes.Create(); aes.Key aesKey; aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; aes.GenerateIV(); // 每次加密隨機(jī)IV byte[] iv aes.IV; using var encryptor aes.CreateEncryptor(); byte[] cipher encryptor.TransformFinalBlock(plainBytes, 0, plainBytes.Length); // 返回 IV 密文方便接收端直接使用前16字節(jié)作為IV return iv.Concat(cipher).ToArray(); }解密端的前16字節(jié)取出來(lái)做IV后面才是密文。這個(gè)模式跑起來(lái)很穩(wěn)不需要額外傳輸IV字段。3.2 防重放與校驗(yàn)機(jī)制防重放是工控協(xié)議容易漏掉的一環(huán)。廠區(qū)無(wú)線網(wǎng)絡(luò)環(huán)境下攻擊者哪怕沒(méi)有破解密鑰只要把之前抓到的合法幀重新發(fā)一遍都可能造成指令重復(fù)執(zhí)行——比如讓AGV重復(fù)走一遍路徑或者重復(fù)下放任務(wù)。我用了“序列號(hào)滑動(dòng)窗口”的組合方案。序列號(hào)每發(fā)一幀遞增1接收端維護(hù)一個(gè)接受窗口。窗口內(nèi)的序列號(hào)按位圖記錄收到重復(fù)號(hào)直接丟棄。窗口大小為32超過(guò)窗口一半以上的批次直接重置連接這樣即使中間丟了幾個(gè)號(hào)也不會(huì)誤殺正常幀。public bool CheckSequence(uint seq) { if (_lastAcceptedSeq 0 || seq _lastAcceptedSeq) { _lastAcceptedSeq seq; _window 1; return true; } long diff (long)_lastAcceptedSeq - (long)seq; if (diff 0 || diff 32) { return false; // 太舊的幀直接丟棄 } if ((_window (1UL (int)diff)) ! 0) { return false; // 重復(fù)幀 } _window | (1UL (int)diff); return true; }這個(gè)邏輯通俗點(diǎn)講就像快遞站里的包裹簽收系統(tǒng)貨物按編號(hào)入庫(kù)重復(fù)送貨單號(hào)直接退件舊編號(hào)超過(guò)保留窗口就自動(dòng)清理防止緩存撐爆。3.3 心跳與斷線重連AGV調(diào)度通訊的“命脈”AGV最怕的不是通信中斷而是中斷后調(diào)度系統(tǒng)不知道車(chē)在哪、在干什么。一旦丟鏈調(diào)度器如果還繼續(xù)下發(fā)任務(wù)就可能出現(xiàn)兩臺(tái)車(chē)同時(shí)搶一個(gè)工位的情況。所以心跳機(jī)制必須放在協(xié)議層而不是業(yè)務(wù)層。我定的心跳方案是AGV每2秒上報(bào)一次Heartbeat幀數(shù)據(jù)段里帶上電池電量、當(dāng)前位置、當(dāng)前任務(wù)ID、運(yùn)行狀態(tài)和故障碼。調(diào)度端連續(xù)3次沒(méi)收到某臺(tái)車(chē)的心跳就把該車(chē)標(biāo)記為“離線”暫停后續(xù)任務(wù)下發(fā)。TCP層還開(kāi)了保活機(jī)制應(yīng)用層心跳和TCP KeepAlive是兩回事。TCP KeepAlive默認(rèn)可能要等兩個(gè)小時(shí)才探活業(yè)務(wù)上根本等不起。應(yīng)用層的2秒心跳才能做到快速感知。斷線重連用指數(shù)退避AGV端如果發(fā)現(xiàn)連接斷開(kāi)按1秒、2秒、4秒、8秒的間隔遞增重連最大間隔16秒。這個(gè)時(shí)間不能太短否則網(wǎng)絡(luò)抖動(dòng)時(shí)所有AGV同時(shí)重連會(huì)把服務(wù)器擠爆也不能太長(zhǎng)否則調(diào)度空窗期太長(zhǎng)。實(shí)測(cè)下來(lái)18臺(tái)車(chē)同時(shí)掉線再恢復(fù)用這個(gè)退避策略服務(wù)器CPU占用峰值在12%不會(huì)產(chǎn)生重連風(fēng)暴。4. 三周實(shí)操時(shí)間線從模擬器到現(xiàn)場(chǎng)部署4.1 第1周協(xié)議原型、模擬器與單機(jī)聯(lián)調(diào)三周時(shí)間聽(tīng)起來(lái)緊但節(jié)奏安排得當(dāng)是夠的。第一周我干了兩件事協(xié)議庫(kù)成型AGV模擬器成型。說(shuō)實(shí)話沒(méi)有模擬器協(xié)議開(kāi)發(fā)就相當(dāng)于盲人摸象。真實(shí)AGV要等機(jī)械、電控聯(lián)調(diào)完才有信號(hào)可不能等它。我用C#寫(xiě)了一個(gè)AGV Simulator模擬實(shí)際車(chē)輛行為接收調(diào)度端下發(fā)的任務(wù)按路徑點(diǎn)逐步移動(dòng)每移動(dòng)一個(gè)點(diǎn)位上報(bào)PointReach消息遇到障礙物或故障上報(bào)ErrorReport隨機(jī)模擬網(wǎng)絡(luò)抖動(dòng)每5分鐘丟一幀每10分鐘斷線重連一次模擬器的好處是所有通信細(xì)節(jié)都在可控環(huán)境里暴露出來(lái)。我把調(diào)度端日志和模擬器日志對(duì)拍用時(shí)間戳對(duì)齊分析一眼就能看到延遲超了多少毫秒、哪條消息被重傳了。這一周里最耗時(shí)的不是寫(xiě)協(xié)議庫(kù)而是調(diào)字節(jié)序和踩CRC坑。我用某標(biāo)準(zhǔn)例子測(cè)CRC自測(cè)怎么都對(duì)但到了模擬器對(duì)接時(shí)CRC老校驗(yàn)失敗。后來(lái)發(fā)現(xiàn)是計(jì)算范圍不一致我在CRC計(jì)算里把幀尾CRC那兩個(gè)字節(jié)位置也算進(jìn)去了接收端在解析時(shí)卻排除CRC去算兩邊口徑對(duì)不上。這種問(wèn)題必須靠?jī)啥斯灿靡惶诇y(cè)試向量才能提前揪出來(lái)。4.2 第2周調(diào)度系統(tǒng)集成與并發(fā)性能測(cè)試第二周開(kāi)始接真實(shí)調(diào)度系統(tǒng)這一步是最容易出幺蛾子的。調(diào)度系統(tǒng)是另一個(gè)同事維護(hù)的.NET項(xiàng)目我們倆的代碼風(fēng)格完全不一樣。他習(xí)慣用ConcurrentDictionary我習(xí)慣用鎖對(duì)接新協(xié)議后第一個(gè)半包問(wèn)題就暴露了。這里簡(jiǎn)單說(shuō)下TCP粘包和半包。TCP是流式協(xié)議內(nèi)核緩沖區(qū)合并發(fā)送接收端可能一次收到多幀的粘連數(shù)據(jù)也可能只收到一幀的一半。我的解析器在處理粘連數(shù)據(jù)時(shí)漏了循環(huán)解析導(dǎo)致一條消息包含了兩幀解析完第一幀第二幀被丟在了緩沖區(qū)里沒(méi)處理。修復(fù)思路統(tǒng)一在解析入口處加了個(gè)TryDecode方法每次讀到的數(shù)據(jù)都追加到一個(gè)待解析緩沖區(qū)循環(huán)解析出所有完整幀剩下的留在緩沖區(qū)繼續(xù)等補(bǔ)包。這個(gè)邏輯獨(dú)立寫(xiě)成工具類(lèi)后調(diào)度端對(duì)接就沒(méi)再出過(guò)粘包丟幀問(wèn)題。并發(fā)測(cè)試這周也在做。我用模擬器起了30個(gè)TCP客戶端同時(shí)向調(diào)度服務(wù)器發(fā)送心跳和位置上報(bào)持續(xù)壓測(cè)1小時(shí)。主要觀測(cè)兩點(diǎn)服務(wù)器端有多少處鎖導(dǎo)致的線程阻塞以及高頻上報(bào)時(shí)消息隊(duì)列有沒(méi)有積壓。測(cè)出來(lái)的兩個(gè)性能瓶頸都很有代表性狀態(tài)上報(bào)數(shù)據(jù)里有個(gè)“當(dāng)前路徑點(diǎn)列表”設(shè)計(jì)時(shí)用了Listbyte每次上報(bào)都要重新分配內(nèi)存高頻下GC壓力極大后來(lái)直接換成池化數(shù)組。調(diào)度服務(wù)器處理每條消息時(shí)都打了詳細(xì)日志到文本文件高并發(fā)下日志IO反而成了最大的瓶頸。壓測(cè)時(shí)我臨時(shí)關(guān)掉日志吞吐量直接翻了三倍。所以正式代碼里日志必須是異步寫(xiě)入且分級(jí)開(kāi)關(guān)可控。4.3 第3周現(xiàn)場(chǎng)部署、環(huán)境適配與問(wèn)題修復(fù)第三周就是把整套系統(tǒng)搬到廠區(qū)實(shí)地跑。我一直認(rèn)為實(shí)驗(yàn)室測(cè)試做得再好現(xiàn)場(chǎng)總會(huì)有你想不到的驚喜。果然我們遇到了三個(gè)典型問(wèn)題。第一工業(yè)Wi-Fi漫游導(dǎo)致通信瞬斷。AGV在移動(dòng)時(shí)從一臺(tái)AP漫游到另一臺(tái)APWi-Fi信號(hào)會(huì)瞬間切換TCP連接雖然沒(méi)有斷開(kāi)但會(huì)產(chǎn)生短暫的延遲和重傳。最開(kāi)始心跳間隔2秒沒(méi)問(wèn)題但任務(wù)下發(fā)后Ack遲遲不回觸發(fā)重傳后AGV已經(jīng)到位了造成重復(fù)下發(fā)。解決方案是對(duì)TaskAssign這類(lèi)冪等性較差的指令收到Ack前不允許同消息ID重傳必須等超時(shí)后先查一次AGV當(dāng)前狀態(tài)再?zèng)Q定是否重發(fā)。第二現(xiàn)場(chǎng)存在電磁干擾偶爾有一兩個(gè)字節(jié)被污染。雖然CRC能檢測(cè)出來(lái)但丟幀率高了以后AGV狀態(tài)更新延遲還是會(huì)變大。后來(lái)我把狀態(tài)上報(bào)頻率從2秒提到1秒并在調(diào)度端做了“三次確認(rèn)才更新”的防抖邏輯體感好了不少。第三不同型號(hào)AGV的字節(jié)序行為不一致。有一批AGV的主控芯片是某廠商的ARM Cortex-M系列它們的固件對(duì)多字節(jié)字段默認(rèn)小端解析。我們協(xié)議統(tǒng)一大端結(jié)果這批車(chē)狀態(tài)上報(bào)里電池電量解析出來(lái)是亂碼。還好通過(guò)自定義幀頭里的版本號(hào)我在協(xié)議層做了一次“字節(jié)序兼容轉(zhuǎn)換”問(wèn)題得到解決。但這也是個(gè)教訓(xùn)前期就該跟AGV控制器固件方對(duì)齊字節(jié)序而不是等真機(jī)聯(lián)調(diào)才發(fā)現(xiàn)。5. 常見(jiàn)問(wèn)題盤(pán)點(diǎn)與排查技巧實(shí)錄5.1 粘包/半包的排查方法這個(gè)坑做網(wǎng)絡(luò)通信的人基本都要走一遭。我把自己用的排查方法寫(xiě)下來(lái)可以直接抄先看單幀抓包數(shù)據(jù)用Wireshark或者tcpdump抓一次TCP流。如果一包數(shù)據(jù)里有多組0xAA 0x55開(kāi)頭說(shuō)明粘包如果只有半組完整的0xAA 0x55頭但尾部數(shù)據(jù)不完整說(shuō)明半包。解析器里一定要留緩沖不能每次收到數(shù)據(jù)就按單幀解析。public ListAgvFrame TryDecode(byte[] chunk, ref Listbyte buffer) { buffer.AddRange(chunk); var frames new ListAgvFrame(); while (buffer.Count 17) // 最小直接幀長(zhǎng)度 { // 查找?guī)^ int headerIdx -1; for (int i 0; i buffer.Count - 1; i) { if (buffer[i] 0xAA buffer[i 1] 0x55) { headerIdx i; break; } } if (headerIdx 0) { buffer.Clear(); break; } if (headerIdx 0) { buffer.RemoveRange(0, headerIdx); // 丟棄臟數(shù)據(jù) } if (buffer.Count 17) break; // 連完整幀頭都不夠繼續(xù)等 ushort dataLen (ushort)((buffer[11] 8) | buffer[12]); ushort totalLen (ushort)(13 dataLen 4); if (buffer.Count totalLen) break; // 幀未完整等待剩余數(shù)據(jù) byte[] frame buffer.Take(totalLen).ToArray(); buffer.RemoveRange(0, totalLen); frames.Add(ParseFrame(frame)); } return frames; }這個(gè)解析器默認(rèn)“丟棄垃圾字節(jié)找?guī)^”雖然效率不是最高但工業(yè)現(xiàn)場(chǎng)難免有殘余數(shù)據(jù)這種設(shè)計(jì)更抗干擾。5.2 加密幀解析失敗的排查速查表現(xiàn)象可能原因排查思路CRC校驗(yàn)失敗CRC計(jì)算范圍不一致對(duì)齊兩端計(jì)算范圍定義解密時(shí)填充錯(cuò)誤IV不一致或密文被截?cái)鄼z查IV是否作為密文前綴傳輸序列號(hào)重復(fù)被丟棄重傳過(guò)來(lái)的幀號(hào)太舊調(diào)整滑動(dòng)窗口大小或重置窗口明文幀偶爾亂碼字節(jié)序不匹配用固定測(cè)試向量對(duì)拍各端解析結(jié)果服務(wù)器收不到心跳連接被中間設(shè)備斷開(kāi)但TCP沒(méi)感知啟用應(yīng)用層心跳并縮短間隔5.3 現(xiàn)場(chǎng)排查用的實(shí)用技巧最后分享幾個(gè)我每次做工業(yè)通信項(xiàng)目都會(huì)用到的排查技巧這些不是文檔里能找到的做一個(gè)獨(dú)立的小工具專(zhuān)門(mén)解析幀日志輸入十六進(jìn)制幀輸出解析后的字段。這樣不用開(kāi)Wireshark直接看日志文本就能定位問(wèn)題。每條關(guān)鍵指令都要有“業(yè)務(wù)追蹤ID”不管是TaskAssign還是StatusReport同一個(gè)業(yè)務(wù)操作全鏈路共用一個(gè)ID查日志效率翻倍。現(xiàn)場(chǎng)調(diào)試時(shí)不要用開(kāi)發(fā)環(huán)境的日志級(jí)別直接把傳輸層日志打到信息級(jí)數(shù)據(jù)量可以大但一定要帶時(shí)間戳和連接標(biāo)識(shí)按AGV車(chē)號(hào)過(guò)濾。6. 寫(xiě)到最后的一些真心話這套協(xié)議從設(shè)計(jì)到落地前后三周熬了大概四個(gè)通宵?；剡^(guò)頭看自研協(xié)議這件事本身不是最難的難的是在“不過(guò)度設(shè)計(jì)”和“充分容錯(cuò)”之間找到平衡點(diǎn)。協(xié)議太簡(jiǎn)單無(wú)法支撐復(fù)雜的調(diào)度業(yè)務(wù)協(xié)議太復(fù)雜開(kāi)發(fā)周期和現(xiàn)場(chǎng)維護(hù)投入都會(huì)失控。我個(gè)人的判斷是做AGV這類(lèi)移動(dòng)設(shè)備的自定義通信協(xié)議一定要抓住三個(gè)核心幀結(jié)構(gòu)清晰、校驗(yàn)可靠、狀態(tài)可感知。加密這類(lèi)安全能力是加分項(xiàng)但如果沒(méi)有底層可靠性托底加密做得再好也沒(méi)用。再一個(gè)經(jīng)驗(yàn)是協(xié)議棧必須配合模擬器開(kāi)發(fā)先讓代碼互相打再去找設(shè)備聯(lián)調(diào)能省掉一半的時(shí)間。最后再分享一個(gè)小經(jīng)驗(yàn)協(xié)議版本號(hào)的坑越早踩越好。我們的第一版部署后AGV固件升級(jí)過(guò)兩次每次改協(xié)議字段都有兼容性問(wèn)題。剛開(kāi)始我把版本號(hào)只寫(xiě)進(jìn)幀頭但業(yè)務(wù)層沒(méi)有做版本協(xié)商導(dǎo)致老車(chē)走新指令直接解析失敗。后來(lái)改成啟動(dòng)時(shí)兩端握手交換版本號(hào)并啟用最大公約版本老的AGV還能繼續(xù)用新的AGV則能享受新功能。這種項(xiàng)目做完我的體會(huì)是協(xié)議這東西真正約束你的不是你設(shè)計(jì)了什么而是什么場(chǎng)景下你沒(méi)想到。三周時(shí)間雖然緊但只要把心放在“現(xiàn)場(chǎng)會(huì)怎么壞”這個(gè)思路上提前想好應(yīng)對(duì)措施大部分問(wèn)題都能在部署前干掉。希望這篇踩坑實(shí)錄能幫你省下幾個(gè)通宵。