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

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

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

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

我重新梳理了業(yè)務需求,調整了網絡切片配置:

將SCADA系統(tǒng)數據傳輸的QCI值設為2,確保低延遲。

將普通遙測數據的QCI值改回9。

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

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

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

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

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

審核編輯 黃宇