前陣子接了一個不算特別前沿、但相當(dāng)磨人的項目給某座中型體育館設(shè)計并部署一套基于物聯(lián)網(wǎng)的人流量監(jiān)測系統(tǒng)。體育館的場地運(yùn)營方最初的需求很簡單就一句話我想知道現(xiàn)在館里有多少人別再靠保安掐著對講機(jī)報數(shù)了。但真實(shí)落地之后你會發(fā)現(xiàn)這句話背后牽扯出的問題遠(yuǎn)比想象中復(fù)雜——傳感器選什么、裝在哪個位置、數(shù)據(jù)怎么傳、到了后臺怎么處理、報警閾值怎么定每一步都有坑。這篇文章不聊宏大的智慧場館概念主要把我在這套系統(tǒng)設(shè)計和實(shí)施過程中踩過的一些坑、比較系統(tǒng)的選型思路以及最終可復(fù)現(xiàn)的架構(gòu)方案整理出來完整復(fù)盤一個基于物聯(lián)網(wǎng)的體育館人流量監(jiān)測系統(tǒng)從需求到上線的全過程。如果你正準(zhǔn)備做場館人流統(tǒng)計、室內(nèi)空間密度監(jiān)測這一類項目這篇文章值得收藏。1. 需求解剖先搞清楚人流量監(jiān)測到底要解決什么1.1 場館運(yùn)營方的三個核心痛點(diǎn)做任何系統(tǒng)之前第一步都不是選硬件而是追問需求方背后真正的痛點(diǎn)。這個項目里體育館運(yùn)營團(tuán)隊列出的問題大概能歸結(jié)為三類。安全容量管理是第一優(yōu)先級。體育館平時承辦籃球賽、羽毛球活動、企業(yè)團(tuán)建偶爾還有明星演出。運(yùn)營方需要知道的在館人數(shù)不是一個大概數(shù)而是能夠和消防設(shè)計容量、場館安全規(guī)定掛鉤的可靠數(shù)字。按照相關(guān)要求當(dāng)館內(nèi)人數(shù)達(dá)到設(shè)計上限的一定比例時必須啟動限流措施這個數(shù)字錯幾千人沒問題但關(guān)鍵拐點(diǎn)不能錯。第二個痛點(diǎn)是分區(qū)域的人流密度分布。運(yùn)營方不僅僅是想知道總?cè)藬?shù)還想知道羽毛球片區(qū)和器械片區(qū)各自忙不忙。如果能把人流量分區(qū)域呈現(xiàn)管理員就能在某個區(qū)域接近飽和時通過廣播、引導(dǎo)等手段分流人群同時保潔、通風(fēng)、空調(diào)也能按需調(diào)度。只統(tǒng)計進(jìn)出總?cè)藬?shù)解決不了這個問題。第三個痛點(diǎn)是運(yùn)營數(shù)據(jù)沉淀。場館的租賃定價、賽事排期、工作人員排班都依賴什么時間段人多、高峰持續(xù)多久這類歷史數(shù)據(jù)。人工巡檢的方式?jīng)]法連續(xù)記錄也無法事后回溯。所以系統(tǒng)不僅要實(shí)時顯示數(shù)字還要在后臺保存完整的時間序列數(shù)據(jù)供月度、季度復(fù)盤使用。1.2 設(shè)計目標(biāo)與技術(shù)選型邊界明確了痛點(diǎn)之后我梳理出了以下幾項硬性指標(biāo)這些指標(biāo)直接影響后文的所有選型判斷指標(biāo)項目標(biāo)值說明出入口監(jiān)測精度誤差不超過5%以人工計數(shù)抽樣作為基準(zhǔn)數(shù)據(jù)上報延遲10秒以內(nèi)超過15秒時管理端需告警單監(jiān)測點(diǎn)覆蓋寬度2米至3米覆蓋常見雙開大門寬度在場人數(shù)計算一致性斷電恢復(fù)后不丟數(shù)據(jù)網(wǎng)關(guān)需本地緩存支持?jǐn)嗑W(wǎng)續(xù)傳系統(tǒng)運(yùn)行成本單點(diǎn)硬件成本控制在合理區(qū)間場館預(yù)算有限不做高端視覺方案這里要強(qiáng)調(diào)一個經(jīng)驗(yàn)設(shè)計目標(biāo)必須在選型之前固定下來否則后面很容易被硬件廠商帶著走。我在溝通前期見過不止一個供應(yīng)商推薦幾十萬一套的視覺分析方案需求方聽完覺得很先進(jìn)但實(shí)際場景只有一個普通體育館入口預(yù)算和必要性都不匹配。所以我給自己定的邊界是能用低成本的傳感器解決絕不上豪華設(shè)備。2. 系統(tǒng)總體架構(gòu)與數(shù)據(jù)流向一條完整的鏈路2.1 分層架構(gòu)感知、傳輸、平臺、應(yīng)用整個系統(tǒng)的架構(gòu)我最終分成了四層每一層職責(zé)單一方便后期單獨(dú)替換和排障。感知層由部署在各個出入口的人流檢測節(jié)點(diǎn)組成每個節(jié)點(diǎn)包括傳感器模組和邊緣計算單元。邊緣計算單元負(fù)責(zé)在本地完成人流方向判斷和數(shù)據(jù)緩存它輸出的不是原始信號而是進(jìn)1、出-1這種已經(jīng)結(jié)構(gòu)化的事件這樣做的好處是不占用太多網(wǎng)絡(luò)帶寬。傳輸層負(fù)責(zé)把各節(jié)點(diǎn)的結(jié)構(gòu)化事件上送到平臺。這里我沒有搞復(fù)雜的組網(wǎng)而是統(tǒng)一通過無線方式匯聚到場館弱電間里的網(wǎng)關(guān)再由網(wǎng)關(guān)通過有線網(wǎng)絡(luò)上傳到服務(wù)器。無線方式主要解決了兩個問題一是體育館出入口往往已經(jīng)裝修完畢拉網(wǎng)線會破壞地面和墻面二是后期增加監(jiān)測點(diǎn)時不需要重新布線。平臺層部署在體育館本地的服務(wù)器上運(yùn)行消息中間件、數(shù)據(jù)存儲服務(wù)和告警引擎?？紤]到場館的網(wǎng)絡(luò)環(huán)境并不總是穩(wěn)定我沒有把平臺完全放到外網(wǎng)云服務(wù)器而是采用本地優(yōu)先、云端可選的部署模式。本地部署保證了數(shù)據(jù)在主網(wǎng)絡(luò)中斷時依然可用給運(yùn)營方留下了充足的應(yīng)急窗口。應(yīng)用層就是管理員端和前臺展示大屏。管理員端承擔(dān)實(shí)時人數(shù)查看、歷史數(shù)據(jù)查詢、閾值設(shè)置等操作展示大屏放在場館值班室紅色、黃色、綠色三色狀態(tài)一目了然。2.2 數(shù)據(jù)鏈路的關(guān)鍵細(xì)節(jié)一條數(shù)據(jù)從產(chǎn)生到展示在真實(shí)系統(tǒng)里要經(jīng)過以下環(huán)節(jié)傳感器原始信號 → 邊緣節(jié)點(diǎn)本地濾波與方向判定 → 生成進(jìn)出事件 → MQTT消息發(fā)布 → 網(wǎng)關(guān)匯聚轉(zhuǎn)發(fā) → 服務(wù)器消息中間件接收 → 實(shí)時計算引擎更新在場人數(shù) → 寫入時序數(shù)據(jù)庫 → 前端通過WebSocket訂閱最新數(shù)據(jù) → 大屏刷新很多人做這類系統(tǒng)時容易忽略的一個點(diǎn)是實(shí)時通道和歷史通道要分開。實(shí)時顯示要求低延遲歷史統(tǒng)計要求高吞吐如果都走同一條鏈路歷史數(shù)據(jù)回放時可能會拖慢實(shí)時通道。我的做法是消息中間件把數(shù)據(jù)同時推給實(shí)時計算模塊和持久化模塊兩個模塊各自消費(fèi)互不阻塞。這算是一個很基礎(chǔ)但很有效的設(shè)計決策。3. 硬件選型與部署位置規(guī)劃數(shù)據(jù)質(zhì)量的前置決定因素3.1 傳感器方案橫向?qū)Ρ扔布x型是這套系統(tǒng)里最容易被低估的一環(huán)。體育館入口的光線、人員密集程度、攜帶物品的形態(tài)都會影響傳感器判斷。我對比了四類主流方案紅外對射傳感器成本最低兩個對射探頭跨門安裝人員穿過時遮擋光線產(chǎn)生脈沖。優(yōu)點(diǎn)是便宜、穩(wěn)定不受光線影響缺點(diǎn)是只能判斷有沒有人穿過無法可靠區(qū)分進(jìn)出方向需要成對安裝配合邏輯推斷對并列而行的人流容易誤判。ToF測距傳感器通過測量光飛行時間獲取目標(biāo)距離可以形成低分辨率的深度信息。它比紅外對射強(qiáng)的地方在于能夠做簡單的軌跡判斷兩個ToF模塊一前一后通過觸發(fā)順序判斷進(jìn)出方向也可以統(tǒng)計一定寬度內(nèi)的人流。缺點(diǎn)是測量范圍有限通常適合2米左右的通道。熱成像傳感器通過捕捉人體熱輻射識別目標(biāo)隱私保護(hù)很好不會采集人臉細(xì)節(jié)。在中型場館入口這種場景熱成像能夠比較好地解決多人并列和遮擋問題。但成本明顯高而且環(huán)境溫度接近人體溫度時誤報率會上來比如夏天出入口冷氣外泄門內(nèi)門外溫差大時目標(biāo)邊緣識別會抖。毫米波雷達(dá)通過發(fā)射和接收毫米波頻段電磁波檢測運(yùn)動目標(biāo)能輸出目標(biāo)距離、速度和方位角。它在雨霧、光線變化、非金屬遮擋等場景下表現(xiàn)比較穩(wěn)定能實(shí)現(xiàn)多目標(biāo)追蹤而且完全不受隱私問題影響。缺點(diǎn)是對靜止或緩慢移動的目標(biāo)不敏感如果有人在門口長時間停留雷達(dá)計數(shù)可能漏掉后續(xù)目標(biāo)。綜合對比之后我選擇了ToF測距傳感器為主、紅外對射為輔的組合方案。兩個ToF模塊間隔0.8米安裝通過目標(biāo)的觸發(fā)時序判斷進(jìn)出方向同時在門側(cè)部署一組紅外對射做交叉校驗(yàn)。這樣單監(jiān)測點(diǎn)的硬件成本控制在合理范圍內(nèi)精度也能滿足設(shè)計目標(biāo)。3.2 部署位置與安裝細(xì)節(jié)傳感器裝在哪、裝在什么高度比選型還要影響最終效果。這里直接說結(jié)論和依據(jù)。第一安裝高度建議在2.2米左右略微向下傾斜。這個高度可以覆蓋大多數(shù)人的頭部和肩部區(qū)域同時降低兒童、輪椅使用者被漏檢的概率。要注意不能裝太高否則ToF的俯視角度過大會導(dǎo)致相鄰并排人員的深度值混在一起難以區(qū)分。第二傳感器要避開金屬門框正上方。毫米波和ToF在貼近金屬反射表面時容易產(chǎn)生多徑效應(yīng)產(chǎn)生虛假目標(biāo)。如果門框上方空間有限寧可采用側(cè)裝支架斜跨過門洞也不要貼著金屬框垂直向下安裝。第三進(jìn)出口要分開檢測不要試圖用一個傳感器覆蓋雙向人流。場館入口在實(shí)際使用中經(jīng)常是出的人貼著左側(cè)進(jìn)的人貼著右側(cè)一個傳感器無法同時準(zhǔn)確區(qū)分兩個方向。我的方案是在門洞左右兩側(cè)各部署一組檢測單元一側(cè)負(fù)責(zé)統(tǒng)計進(jìn)一側(cè)負(fù)責(zé)統(tǒng)計出邏輯上徹底分離。這個設(shè)計后來實(shí)測效果非常好雙向?qū)α鞯恼`判率比單點(diǎn)方案低了一個數(shù)量級。提示如果出入口寬度超過3米建議拆分成兩個監(jiān)測點(diǎn)。一個傳感器覆蓋3米以上寬度時邊緣區(qū)域的目標(biāo)信號質(zhì)量會明顯下降與其后期調(diào)算法不如前期拆硬件。4. 通信方案與數(shù)據(jù)協(xié)議傳輸層的工程取舍4.1 無線通信方式怎么選感知層和網(wǎng)關(guān)之間我評估了三種常見無線方式LoRa是長距離低功耗的代表單節(jié)點(diǎn)通信距離在空曠環(huán)境能達(dá)到幾百米穿墻能力也不錯非常適合園區(qū)級廣覆蓋。但LoRa的帶寬很低如果每個監(jiān)測點(diǎn)每次上報的數(shù)據(jù)量稍大實(shí)時刷新會有明顯延遲。我在體育館場地實(shí)測從傳感器觸發(fā)到數(shù)據(jù)到達(dá)網(wǎng)關(guān)LoRa路徑的端到端時延在1到3秒抖動雖然勉強(qiáng)達(dá)標(biāo)但不夠理想。NB-IoT依托運(yùn)營商網(wǎng)絡(luò)覆蓋廣、穿透強(qiáng)而且模組功耗控制得很好。但NB-IoT依賴運(yùn)營商基站在信號覆蓋不佳的地下場館區(qū)域需要額外加裝增強(qiáng)設(shè)備而且單次通信會產(chǎn)生流量套餐成本?？紤]到體育館弱電間本身具有有線網(wǎng)絡(luò)沒必要繞一圈走運(yùn)營商網(wǎng)絡(luò)。Wi-Fi方案是我最終的選擇。理由很直接體育館內(nèi)已有商用無線網(wǎng)絡(luò)覆蓋每個出入口附近都有接入點(diǎn)傳感器數(shù)據(jù)量本身很小Wi-Fi的帶寬和時延完全夠用。Wi-Fi的功耗確實(shí)比前兩者高一些但監(jiān)測點(diǎn)可以直接用PoE供電不存在電池續(xù)航問題功耗劣勢也就不存在了。實(shí)際工程中還考慮過用RS-485有線總線布線太長、后期維護(hù)麻煩直接排除。4.2 數(shù)據(jù)協(xié)議與異常補(bǔ)償機(jī)制通信協(xié)議我采用輕量級的MQTT消息體使用JSON格式。為什么不用HTTP輪詢因?yàn)閷?shí)時人數(shù)變化需要秒級推送HTTP短連接輪詢費(fèi)流量、費(fèi)功耗且實(shí)現(xiàn)復(fù)雜。MQTT的發(fā)布-訂閱模式和長連接機(jī)制天然適合這種傳感器上報場景。上行消息最簡單的時候只有幾個字段{ node_id: gate_a_01, event: enter, ts: 1682312400, seq: 321 }node_id標(biāo)識監(jiān)測點(diǎn)event是事件類型ts是事件發(fā)生時間戳seq是節(jié)點(diǎn)側(cè)消息序號。seq這個字段非常重要它是實(shí)現(xiàn)斷網(wǎng)續(xù)傳和消息去重的關(guān)鍵。邊緣節(jié)點(diǎn)本地維護(hù)一個自增序號網(wǎng)絡(luò)恢復(fù)后服務(wù)器可以根據(jù)序號發(fā)現(xiàn)中間是否有丟包。消息中間件的QoS我設(shè)置在1也就是至少一次投遞。為什么不用QoS 2的恰好一次?因?yàn)镼oS 2的多次握手確認(rèn)對傳感器這種資源受限設(shè)備來說太重了而且我們靠消息序號去重完全能在應(yīng)用層解決重復(fù)問題。下行消息主要用于遠(yuǎn)程配置和指令下發(fā)比如遠(yuǎn)程修改告警閾值、重啟節(jié)點(diǎn)同樣走M(jìn)QTT但單獨(dú)劃一個topic前綴隔離控制指令和數(shù)據(jù)流。5. 人流統(tǒng)計算法的精度與容錯數(shù)據(jù)真正可用的關(guān)鍵5.1 邊緣節(jié)點(diǎn)的雙向計數(shù)邏輯每個入口的監(jiān)測點(diǎn)內(nèi)兩個ToF模塊在空間上前后安裝分別稱為A點(diǎn)外側(cè)和B點(diǎn)內(nèi)側(cè)。當(dāng)人員通過時理想情況下會依次觸發(fā)A和B。通過觸發(fā)順序即可判斷方向先觸發(fā)A后觸發(fā)B判定為進(jìn)入先觸發(fā)B后觸發(fā)A判定為離開?？雌饋矸浅：唵蔚鎸?shí)場景有太多看起來的問題。人不是點(diǎn)是多幀連續(xù)運(yùn)動軌跡。我用一個簡單的滑動窗口狀態(tài)機(jī)來處理狀態(tài)機(jī)包含四個狀態(tài)空閑、檢測到A目標(biāo)、檢測到B目標(biāo)、已計數(shù)。每個狀態(tài)有超時機(jī)制比如A點(diǎn)觸發(fā)后如果3秒內(nèi)沒有在B點(diǎn)檢測到對應(yīng)目標(biāo)就判定為無效觸發(fā)狀態(tài)回到空閑不產(chǎn)生任何事件。這樣可以過濾掉門口徘徊、彎腰系鞋帶、停下來看手機(jī)這類行為觸發(fā)。多人并排通過是另一個棘手問題。兩個ToF模塊測距數(shù)據(jù)里會出現(xiàn)兩個相近的目標(biāo)我在邊緣節(jié)點(diǎn)上維護(hù)一個目標(biāo)列表根據(jù)距離值做聚類再對聚類中心做前后關(guān)聯(lián)跟蹤。簡單來說就是不判斷這個點(diǎn)是張三還是李四只判斷前方目標(biāo)數(shù)量增加了還是減少了用通道內(nèi)目標(biāo)數(shù)量變化來推導(dǎo)通行事件。這個方法在2.5米以下寬度的出入口準(zhǔn)確率相當(dāng)高。5.2 干擾與異常場景的處理整個系統(tǒng)最容易出錯的環(huán)節(jié)其實(shí)是人流量大的時候。首先是長時間停留目標(biāo)。有人站在門口打電話、等人目標(biāo)在A點(diǎn)和B點(diǎn)之間長時間駐留如果不做處理就會一直占用跟蹤資源導(dǎo)致后續(xù)人員無法被正確關(guān)聯(lián)。我的方案是設(shè)置駐留超時目標(biāo)在監(jiān)測區(qū)內(nèi)停留超過10秒后邊緣節(jié)點(diǎn)就不再將其納入進(jìn)出判斷邏輯只當(dāng)作靜態(tài)背景處理。這樣雖然會犧牲一部分這個人后來到底走沒走的統(tǒng)計但總?cè)藬?shù)計算反而更穩(wěn)。說到底人流監(jiān)測關(guān)注的是流量脈沖不是長期駐留個體的精確去向。其次是多人同向快速連續(xù)通過。在比賽散場時幾十人會在幾十秒內(nèi)連續(xù)涌出。這時候邊緣節(jié)點(diǎn)的處理能力會面臨壓力如果算法處理不過來丟幀就會導(dǎo)致漏統(tǒng)。我的應(yīng)對是兩級緩沖傳感器數(shù)據(jù)先寫入邊緣節(jié)點(diǎn)的本地環(huán)形隊列業(yè)務(wù)算法按固定速率消費(fèi)處理隊列溢出時優(yōu)先丟棄舊幀而不是新幀。處理不過來的時候系統(tǒng)會主動降級把單目標(biāo)檢測降級為檢測到通道有密集人流通過用經(jīng)驗(yàn)流量系數(shù)估算本次通行數(shù)量。降級估算的總誤差雖然比逐目標(biāo)檢測大但至少不會完全丟失事件。最后是重復(fù)計數(shù)問題。場館出口和入口相距不遠(yuǎn)閘機(jī)附近存在大量折返人員。比如入場時發(fā)現(xiàn)走錯了安檢口立刻折返出門再重新走進(jìn)來。這套系統(tǒng)記錄到的是一個進(jìn)入事件加上一個離開事件兩者相抵總量實(shí)際上是正確且自洽的。5.3 與人工抽檢的數(shù)據(jù)校準(zhǔn)算法再穩(wěn)也需要真值基準(zhǔn)。我們上線第一周做了系統(tǒng)的數(shù)據(jù)校準(zhǔn)實(shí)驗(yàn)。安排兩名工作人員分別在主入口的人工計數(shù)點(diǎn)記錄真實(shí)通行數(shù)據(jù)每15分鐘與系統(tǒng)統(tǒng)計數(shù)比對一次。校準(zhǔn)過程中發(fā)現(xiàn)了一個非常典型的偏差系統(tǒng)計算的在場人數(shù)在閉館清場時和人工總數(shù)往往能對齊但中間的每個小時會出現(xiàn)幾十人的累計漂移。定位后發(fā)現(xiàn)漂移源主要集中在側(cè)門。側(cè)門平時用得少但保潔人員和商戶會頻繁通過而且側(cè)門通行方向無法固定區(qū)分導(dǎo)致狀態(tài)機(jī)出現(xiàn)間歇性誤判。處理方式分兩步一是給保潔、商戶人員集中通行時段加了輔助判斷邏輯在固定時間段內(nèi)降低觸發(fā)靈敏度減少機(jī)械性的誤判二是開發(fā)了一個日終自動歸零功能在每天閉館后由管理員確認(rèn)清場系統(tǒng)自動重置在場人數(shù)基準(zhǔn)切斷跨天累積誤差。這類周期性校準(zhǔn)是低成本且非常實(shí)用的手段。6. 后臺服務(wù)、數(shù)據(jù)存儲與可視化從計數(shù)到管理決策6.1 后端服務(wù)邊界與數(shù)據(jù)存儲選擇后臺服務(wù)需要做的事情包括消息接入、實(shí)時人數(shù)計算、區(qū)域人數(shù)聚合、歷史數(shù)據(jù)存儲、告警引擎和權(quán)限管理。為了避免堆成一個大單體我按數(shù)據(jù)職責(zé)拆成了三個服務(wù)接入服務(wù)、計算服務(wù)、管理服務(wù)。接入服務(wù)負(fù)責(zé)完整接收邊緣節(jié)點(diǎn)上報的MQTT消息先做格式校驗(yàn)、冪等去重再寫入消息隊列同時把原始數(shù)據(jù)歸檔到歷史庫。計算服務(wù)消費(fèi)消息隊列里的數(shù)據(jù)維護(hù)每個監(jiān)測點(diǎn)的最新計數(shù)狀態(tài)并周期性計算在場人數(shù)、各區(qū)域人數(shù)、單位時間內(nèi)進(jìn)出流量。計算服務(wù)不直接讀數(shù)據(jù)庫它的狀態(tài)全部保存在內(nèi)存中這樣性能會非常穩(wěn)定。管理服務(wù)處理管理后臺的API請求操作配置信息、查詢歷史趨勢、管理用戶權(quán)限。存儲方面我用了兩類存儲搭配。關(guān)系型數(shù)據(jù)庫存設(shè)備信息、用戶、閾值配置這類數(shù)據(jù)量小、變更少。時序數(shù)據(jù)庫存人流數(shù)據(jù)的時間序列數(shù)據(jù)量大、寫入頻繁。時序數(shù)據(jù)庫在寫放大和壓縮率上優(yōu)勢明顯接入1000個監(jiān)測點(diǎn)每天產(chǎn)生的數(shù)據(jù)量也只有幾十萬條左右普通機(jī)器完全扛得住。6.2 大屏可視化與告警聯(lián)動可視化層我沒有過度設(shè)計。室內(nèi)人流監(jiān)測系統(tǒng)的用戶是一個值班管理員他要看的核心信息只有四塊現(xiàn)在總?cè)藬?shù)多少、各區(qū)域人數(shù)多少、過去24小時趨勢曲線、當(dāng)前運(yùn)行狀態(tài)的設(shè)備數(shù)量。大屏的實(shí)時人數(shù)展示我用了WebSocket通道推送秒級刷新。區(qū)域熱度用簡單的色塊來表示不需要復(fù)雜的3D場館模型。之所以特意克制展示形式是因?yàn)閷?shí)踐中發(fā)現(xiàn)過度動畫化的可視化會讓值班人員失去對關(guān)鍵數(shù)字的敏感性。真正有用的告警不是花哨的彈窗而是清晰的分級狀態(tài)人數(shù)達(dá)到容量的80%顯示黃色提醒超過100%觸發(fā)紅色預(yù)警并通過廣播接口提示現(xiàn)場工作人員啟動限流措施。告警聯(lián)動還有一個容易忽視的細(xì)節(jié)告警要可確認(rèn)、可關(guān)閉。如果告警只能自動觸發(fā)、無法被人工確認(rèn)那么管理員會在頻繁的誤報中產(chǎn)生疲勞最終變成看到紅點(diǎn)也當(dāng)作例行公事。我在告警接口上加了確認(rèn)和備注功能讓管理員能記錄已通知現(xiàn)場引導(dǎo)員疏散這樣后續(xù)復(fù)盤時也能弄清楚當(dāng)時的處置鏈條。7. 實(shí)測數(shù)據(jù)與踩坑記錄幾個值得寫出來的真實(shí)問題7.1 門口陰影滯留導(dǎo)致的重復(fù)計數(shù)上線第一周遇到的第一個怪問題主入口的系統(tǒng)統(tǒng)計人數(shù)比人工計數(shù)多了不少而且多出來的數(shù)字主要集中在下午3點(diǎn)到5點(diǎn)。我?guī)еP記本去現(xiàn)場看日志發(fā)現(xiàn)某幾個ToF測距單元反復(fù)出現(xiàn)目標(biāo)進(jìn)入但長時間未離開的記錄而這個目標(biāo)的位置恰好是一根大理石門柱旁邊。排查后確認(rèn)是門柱形成了測距盲區(qū)的陰影滯留。目標(biāo)從柱邊走過時測距信號被柱子遮擋了一部分算法把單個人拆分成了兩個目標(biāo)其中一個目標(biāo)被錯誤地判定為長期駐留。這個問題的修復(fù)不是調(diào)參能徹底解決的而是從根本上調(diào)整了柱邊那一路傳感器的朝向角度同時在算法中增加了一個檢測邏輯兩個目標(biāo)的空間位置在連續(xù)多幀內(nèi)非常接近則判定為同一目標(biāo)的不同徑向投影合并處理。這類問題很難通過實(shí)驗(yàn)室測試發(fā)現(xiàn)因?yàn)槭覂?nèi)測試環(huán)境不可能覆蓋場館門口的各種物理結(jié)構(gòu)。我能給的建議是在算法邊緣節(jié)點(diǎn)上保留足夠長的原始調(diào)試日志第一周留下原始測距數(shù)據(jù)方便定位問題根源。7.2 金屬安檢閘機(jī)帶來的多徑干擾第二輪問題出現(xiàn)在貴賓通道。貴賓通道安裝有金屬安檢閘機(jī)閘機(jī)旁邊是金屬材質(zhì)的門框。部署完成后貴賓通道的離開事件數(shù)明顯偏高于進(jìn)入事件數(shù)而且高頻出現(xiàn)在設(shè)備開啟后的前30分鐘。用頻譜分析工具看了當(dāng)時的無線環(huán)境結(jié)合現(xiàn)場物理結(jié)構(gòu)推斷應(yīng)該是金屬閘機(jī)表面反射導(dǎo)致ToF測距信號出現(xiàn)多徑效應(yīng)產(chǎn)生了額外的虛假目標(biāo)。毫米波雷達(dá)方案在這種環(huán)境下的抗干擾能力會更強(qiáng)但我們已經(jīng)選了ToF方案調(diào)整手段是有限的。最終通過姿態(tài)調(diào)整和虛擬墻機(jī)制解決了問題將傳感器盡量避開閘機(jī)金屬面的正反射區(qū)同時在算法中把通道兩側(cè)的固定金屬結(jié)構(gòu)識別為背景點(diǎn)云建了一張?zhí)摂M屏蔽墻凡是落在屏蔽墻內(nèi)的測距點(diǎn)一律不參與目標(biāo)聚類。這個方法比較笨但效果直接貴賓通道后續(xù)的誤差率降到了2%以內(nèi)。這個經(jīng)驗(yàn)帶給我一個教訓(xùn)場館內(nèi)做傳感器部署時不能只看裝在哪合適還要觀察周圍是否存在大面積固定金屬結(jié)構(gòu)。凡是存在這種結(jié)構(gòu)的區(qū)域都要提前規(guī)劃傳感器角度和算法屏蔽策略。7.3 網(wǎng)絡(luò)波動導(dǎo)致的時序抖動與補(bǔ)償機(jī)制最后一個值得分享的問題是消息亂序。某天后臺運(yùn)維突然發(fā)現(xiàn)告警引擎頻繁彈出數(shù)據(jù)延遲但各監(jiān)測點(diǎn)狀態(tài)看起來卻都正常。排查后發(fā)現(xiàn)原因是核心交換機(jī)某端口出現(xiàn)了微小的流量擁塞部分MQTT消息在傳輸路徑上被重新排隊導(dǎo)致到達(dá)服務(wù)器的順序與節(jié)點(diǎn)發(fā)送順序不一致。消息亂序?qū)?shí)時人數(shù)計算是致命的。如果離開事件先到、進(jìn)入事件后到服務(wù)器臨時計算出的在場人數(shù)就會短暫虛低雖然最終消息都到了數(shù)據(jù)會修正但告警引擎會基于錯誤時間點(diǎn)的數(shù)據(jù)觸發(fā)誤報。解決辦法就是在協(xié)議中引入seq序號并增加一個緩沖隊列。服務(wù)器接收到消息后不按到達(dá)順序直接計算而是先進(jìn)入一個以seq排序的亂序緩沖隊列等待前序消息補(bǔ)齊后統(tǒng)一重放給計算服務(wù)。定時器兜底超過3秒未補(bǔ)齊的消息直接跳過避免阻塞后續(xù)消息。同時告警引擎接收到的人數(shù)變化數(shù)據(jù)增加了一個小時級別的平滑窗口避免單次抖動直接觸發(fā)預(yù)警。def replay_messages(message_buf, next_seq): while next_seq in message_buf: process_event(message_buf.pop(next_seq)) next_seq 1這個邏輯本身不復(fù)雜但加與不加系統(tǒng)的穩(wěn)定性完全是兩個體驗(yàn)。后來遇到網(wǎng)絡(luò)波動時告警引擎再也沒有因?yàn)閬y序產(chǎn)生誤報。寫在最后整套系統(tǒng)從需求梳理到上線運(yùn)行前后花了接近兩個月。最直觀的心得是物聯(lián)網(wǎng)系統(tǒng)設(shè)計的難度從來不在單點(diǎn)技術(shù)上而在所有環(huán)節(jié)疊加后的可靠性。傳感器精度再高部署位置不對也白搭通信協(xié)議再快服務(wù)器消息處理邏輯有缺陷也白搭。如果你打算做類似的場館人流量監(jiān)測項目我給三條建議。第一花足夠多的時間在現(xiàn)場觀察真實(shí)的人員流動模式別急著畫架構(gòu)圖。第二所有設(shè)備上線前先部署一套小范圍試點(diǎn)把狀態(tài)機(jī)、異常處理邏輯的日志調(diào)出來逐幀核對試運(yùn)行至少一周再全面鋪開。第三一定要設(shè)計一套人工抽樣校核機(jī)制沒有任何算法可以在缺乏真值基準(zhǔn)的情況下自我驗(yàn)證。這套系統(tǒng)的邊緣節(jié)點(diǎn)代碼和后臺服務(wù)骨架基本都是基于標(biāo)準(zhǔn)MQTT協(xié)議加通用狀態(tài)機(jī)邏輯寫的技術(shù)棧沒有稀有組件任何有基礎(chǔ)物聯(lián)網(wǎng)開發(fā)經(jīng)驗(yàn)的人都可以在類似場景復(fù)現(xiàn)。希望這次復(fù)盤能幫你少走一些彎路。