凌晨4:13,我被手機震動驚醒。變電站值班人員發(fā)來緊急消息:昨晚部署的SR800突然離線。我立即查看了STAR Device Manager平臺,確認是設(shè)備A37號在3:47分失去連接。(key-iot.com/iotlist/sr800-3.html)

6:30到達變電站。檢查SR800狀態(tài),發(fā)現(xiàn)是供電問題導致設(shè)備重啟。這個老舊變電站的電源質(zhì)量不穩(wěn)定,電壓波動超出了SR800的9-36V工作范圍。我們連接了UPS穩(wěn)壓,同時調(diào)整了SR800的電源保護參數(shù),將過壓保護閾值從默認的37V提高到40V。這個臨時方案解決了問題,但我在維護日志里記錄了需要和客戶溝通改善站點供電的事項。

正當準備離開時,監(jiān)控屏幕顯示數(shù)據(jù)傳輸延遲突然飆升到300ms以上。我立即登錄SR800的Web管理界面,查看網(wǎng)絡(luò)狀態(tài)。5G信號強度正常,但吞吐量急劇下降。

經(jīng)過排查,發(fā)現(xiàn)是網(wǎng)絡(luò)切片配置出了問題。前幾天為了滿足客戶臨時需求,我們調(diào)整了APN參數(shù),將默認QCI值從9改為了5。這導致了大量非關(guān)鍵業(yè)務(wù)占用了高優(yōu)先級網(wǎng)絡(luò)資源。

我重新梳理了業(yè)務(wù)需求,調(diào)整了網(wǎng)絡(luò)切片配置:

將SCADA系統(tǒng)數(shù)據(jù)傳輸?shù)腝CI值設(shè)為2,確保低延遲。

將普通遙測數(shù)據(jù)的QCI值改回9。

啟用了SR800的QoS功能,為不同業(yè)務(wù)設(shè)置了帶寬限制。

這些調(diào)整后,數(shù)據(jù)傳輸延遲迅速降到了50ms以下。我在SR800上設(shè)置了SNMP Trap,如果延遲超過100ms就自動發(fā)送告警。

下午對站內(nèi)其他SR800進行了全面檢查。發(fā)現(xiàn)一臺設(shè)備5G信號異常弱,檢查后發(fā)現(xiàn)是天線連接松動。我們重新固定了天線,并用測試儀確認各頻段信號強度恢復正常。這個問題提醒我們需要在安裝規(guī)范中加入天線緊固度的檢查項。

最后,我們還解決了一個安全隱患。通過查看SR800的系統(tǒng)日志,發(fā)現(xiàn)有多次可疑的SSH登錄嘗試。我立即更新了防火墻規(guī)則,限制了SSH訪問源IP,并啟用了SR800的入侵檢測系統(tǒng)(IDS)功能。

18:30,所有問題得到解決。監(jiān)控屏幕顯示所有SR800運行正常,5G連接穩(wěn)定,數(shù)據(jù)傳輸延遲維持在30ms左右。雖然過程曲折,但SR800的靈活配置和強大功能再次證明了它在智能電網(wǎng)中的價值。

審核編輯 黃宇