盡管時間同步技術已廣泛應用于服務器集群、物聯網設備和金融系統中，但配置不當或網絡異常仍會導致時間不同步的困擾。本文旨在以通俗易懂的方式，解析時間同步中的典型問題，結合實際場景提供清晰的排查步驟與優化建議，讓時間同步變得不再復雜。

一、什么是時間同步？

在 LuatOS 開發中，時間同步是指通過專用硬件模塊或網絡協議，將蜂窩模組的本地時鐘校準為標準 UTC 時間（或指定時區時間），使單個模組時鐘長期準確，或多個模組 / 云端的時間戳誤差控制在可接受范圍的技術過程。

二、為什么需要時間同步

每個設備都有自己的本地時鐘（如單片機的 RTC 模塊、服務器的系統時鐘），受硬件精度、溫度變化、電壓波動等影響，本地時鐘會產生漂移（即時間走快或走慢）：

1、模組默認時間非常不準確：

模組默認本地時間是 2000-01-01 08:00:00；

模組默認 UTC 時間是 2000-01-01 00:00:00，所以需要時間同步來校準。

2、即使已經做過時間同步，模組時鐘在運行過程中也會出現微小的誤差，低功耗模式、psm+ 模式下都會有誤差(誤差測試數據見本文第六章)，所以實際項目中休眠喚醒以后也會需要再次時間同步。

3、實際的項目開發中也需要準確的時間。

時間同步的核心目標，就是通過特定機制校準這些漂移的時鐘，使多設備的時間基準統一，時間同步是很多物聯網系統，嵌入式設備穩定運行的基礎，核心必要性體現在以下 幾個場景：

數據采集與時序對齊

在物聯網場景中，多個傳感器 / 設備會向主控平臺上報數據。如果沒有統一時間戳，無法判斷數據產生的先后順序。例如：合宙 4G 模組采集的溫濕度數據，若時間不同步，分析時會混淆 “溫度升高” 和 “設備負載增加” 的因果關系。

多設備協同控制

分布式系統或工業控制場景中，設備需要按統一時間執行動作。例如：智能電網的多臺斷路器需同步跳閘、流水線的多臺電機需同步啟停，時間不同步會導致動作錯亂，引發設備故障或生產事故。

日志溯源與故障排查

嵌入式或服務器系統出現問題時，需要通過多設備的日志定位根因。如果日志時間戳不統一，無法還原故障發生的完整時序。例如：合宙模組的網絡通信日志、若時間差過大，無法判斷是 “模組網絡斷開” 先發生，還是 “主控應用崩潰” 先發生。

安全認證與事務一致性

金融支付、身份認證等場景中，時間戳是防篡改、防重放攻擊的關鍵。例如：一筆支付請求的時間戳若與服務器時間偏差過大，會被判定為非法請求；分布式數據庫的事務提交，需要統一時間戳保證數據一致性。

三、時間同步的五種方法

3.1 NTP 時間同步

基于socket核心庫https://docs.openluat.com/osapi/core/socket/

原理：通過網絡時間協議（NTP）向 NTP 服務器（如阿里云、騰訊云服務器）請求時間，模組訪問這些免費公共的 NTP 服務器，獲取 NTP 服務器返回時間。

開關控制和觸發條件 核心接口為 socket.sntp()。 調用一次 socket.sntp() ， 模組就主動去網絡服務器同步一次時間，同步成功后，發送系統消息 NTP_UPDATE，NTP_UPDATE 的回調參數 tp 返回 1 表示是基站時間同步,返回 0 表示是 NTP 時間同步; 如果沒有調用 socket.sntp()的話，就不會去同步網絡服務器的時間。 時間同步成功后，調用 rtc.get()（https://docs.openluat.com/osapi/core/rtc/）獲取當前系統實時時鐘的時間， 調用 os.time()（https://docs.openluat.com/osapi/core/os/）將時間表轉換為時間戳。 使用 os.date(fmt, time)（https://docs.openluat.com/osapi/core/os/）將時間轉換為指定格式的字符串或時間表

代碼實現邏輯

同步結果NTP 時間一旦同步成功，是否準確取決于 NTP 服務器是否有 bug 導致返回錯誤的時間

優點：

精度較高（秒級），網絡穩定時可靠；

支持多服務器，自動切換失敗的服務器；

適用于有網絡連接的場景，配置簡單。

缺點：

依賴網絡連接，無網絡時失效；

受網絡延遲影響（首次同步可能有 10~500ms 偏差，二次同步后精度提升）；

可能受 DNS 解析、NTP 服務器響應超時影響。

適用場景：有穩定網絡連接的設備（如物聯網網關、工業監控設備），需定期同步時間的場景。

3.2 基站時間同步

基于 mobile 核心庫https://docs.openluat.com/osapi/core/mobile/

原理：運營商提供的蜂窩網絡基站會下發時間，模組通過基站信號來獲取時間。

開關控制和觸發條件核心接口 mobile.syncTime()。 默認是開啟基站時間同步功能，由模組底層自動處理，成功同步時間會發送系統消息 NTP_UPDATE，NTP_UPDATE 的回調參數 tp 返回 1 表示是基站時間同步,返回 0 表示是 NTP 時間同步。 使用 mobile.syncTime(false)關閉基站時間同步。 時間同步成功后，調用 rtc.get()（https://docs.openluat.com/osapi/core/rtc/）獲取當前系統實時時鐘的時間， 調用 os.time()（https://docs.openluat.com/osapi/core/os/）將時間表轉換為時間戳。 使用 os.date(fmt, time)（https://docs.openluat.com/osapi/core/os/）將時間轉換為指定格式的字符串或時間表

代碼實現邏輯

同步結果無基站信號、模組注冊網絡失敗等因素會導致時間同步失敗。一旦時間同步成功，時間是否正確，取決于基站時鐘偏差，根據歷史經驗來看，出錯的概率是極低的，且偏差量級嚴格受控于電信級同步體系。 當基站時間同步出錯，如果是基站出問題，需要找運營商來解決。

優點：

開啟后會自動不定期的同步基站時間，模組應用程序不關心也不控制同步的時機

無需額外配置，有網絡信號即可；

適用于無 GNSS 信號但有移動網絡的場景，如城市高樓區域。

缺點：

精度秒級，受基站時鐘偏差影響；

依賴基站信號，偏遠地區可能信號弱或無信號；

不同運營商基站時間可能存在微小偏差。

僅支持移動 / 電信卡，部分聯通卡沒有基站授時；

適用場景：依賴蜂窩網絡的設備，作為 GNSS 和 NTP 的補充。

3.3 自建服務器時間同步

原理：自建服務器下發時間，解析后手動同步系統時間。

開關控制和觸發條件

業務服務器下發時間參數，調用 rtc.set()（https://docs.openluat.com/osapi/core/rtc/）設置 RTC 時鐘的時間

時間同步成功后，調用 rtc.get()（https://docs.openluat.com/osapi/core/rtc/）獲取當前系統實時時鐘的時間，

調用 os.time()（https://docs.openluat.com/osapi/core/os/）將時間表轉換為時間戳。

使用 os.date(fmt, time)（https://docs.openluat.com/osapi/core/os/）將時間轉換為指定格式的字符串或時間表

代碼實現邏輯

同步結果

同步的時間是否準確取決于服務器時間本身。

優點：

時間與業務服務器強綁定，確保業務邏輯時間一致性；

服務器可控，客戶可自行保證服務器時間準確性。

缺點：

精度依賴業務服務器時間精度和網絡延遲；

依賴服務器可用性和網絡連接，服務器故障則同步失敗；

需自定義請求和解析邏輯。

適用場景：業務對時間統一性要求高的場景，如交易系統、數據上報需與服務器時間對齊。

3.4 GNSS 時間同步

基于 exgnss 擴展庫 https://docs.openluat.com/osapi/ext/exgnss/

原理：通過全球導航衛星系統（如 GPS、北斗等）獲取時間。

開關控制和觸發條件

使用 exgnss.rmc()接口，獲取獲取 RMC 的信息，包含時間信息。

調用 rtc.set()（https://docs.openluat.com/osapi/core/rtc/）設置 RTC 時鐘的時間

調用 os.time()（https://docs.openluat.com/osapi/core/os/）將時間表轉換為時間戳。使用 os.date(fmt, time)（https://docs.openluat.com/osapi/core/os/）將時間轉換為指定格式的字符串或時間表

代碼實現邏輯

同步結果依賴 GNSS 信號，僅在 GNSS 模塊搜星成功后返回有效數據，搜星未成功前的，即使顯示了時間，也不是可靠時間，室內、遮擋嚴重（如隧道、地下室）場景下會獲取時間失敗。成功獲取的時間是否準確，取決于輸出的衛星有效時間是否正確，根據歷史經驗來看，出錯的概率可忽略不計，截止到 2026 年，在合宙支持客戶的 10 幾年中，僅 2018 年遇見過某一款國外的 GNSS 芯片，出現 GNSS 時間同步錯誤，合宙出貨的模組暫未遇見過 GNSS 時間同步出錯的情況。 當 GNSS 時間同步出錯，如果是 GNSS 芯片軟件或者 GNSS 芯片服務出現問題，需要找 GNSS 芯片服務器商解決

優點：

精度高，時間源為衛星，全球統一且可靠；

無需依賴網絡或基站，獨立工作。

缺點：

依賴衛星信號，室內、地下、高樓遮擋等場景可能定位失敗（無法同步）；

啟動需一定時間（首次定位可能耗時數秒至數十秒）；

硬件需支持 GNSS 模塊。

適用場景：戶外開闊區域（如車輛、船舶、無人機）、對時間精度要求極高的場景（如軌跡記錄、精準計時）。

3.5 SMS 時間同步（不到萬不得已，不要使用，誤差太大）

（基于sms核心庫https://docs.openluat.com/osapi/core/sms/）

原理：通過接收包含時間信息的短信，解析內容后手動同步系統時間，此時間是 sms 發送者將 sms 傳輸到基站的時間，需自定義解析邏輯。

開關控制和觸發條件用 sms.send()接口，可以發送任意查詢指令給運營商，比如 sms.send("10001", "102")，給電信運營商發送查詢話費的短信，當模組收到運營商返回的短信時，會發布系統消息"SMS_INC"，開發者可以通過"SMS_INC"攜帶的時間參數表 metas 手動同步系統時鐘。 此方式收發短信雙向免費。 獲取時間后，調用 rtc.set()（https://docs.openluat.com/osapi/core/rtc/）設置 RTC 時鐘的時間；調用 os.time()（https://docs.openluat.com/osapi/core/os/）將時間表轉換為時間戳；調用 os.date(fmt, time)（https://docs.openluat.com/osapi/core/os/）將時間轉換為指定格式的字符串或時間表

代碼實現邏輯

同步結果通過解析收到的運營商短信，來獲取到運營商發出短信的時間，依賴短信發送和接收，延遲可能達分鐘級。所以時間同步是否正確，取決于發送和接收短信的延遲程度，此種方式獲取到的時間出錯概率較大。 如果短消息服務器中心出問題導致無法收取短信，需要找運營商解決。

優點：

適用于網絡和 GNSS 信號均差但能接收短信的場景，如偏遠地區；

無需主動聯網，被動接收即可。

缺點：

實時性差，依賴短信發送和接收延遲，可能達分鐘級；

需手動解析短信內容，易受短信格式錯誤、亂碼影響；

依賴短信功能正常

適用場景：緊急情況下的時間校準，如 GNSS 失效時的備用方案，極端網絡環境（僅能收發短信）、低頻次同步需求的設備。

四、僅啟用一種還是同時啟用多種？

4.1 僅啟用一種時間同步

優點是，實現簡單、資源消耗低、無需處理多源沖突；

缺點是，單點依賴，該方式失效時時間無法同步。任何時間同步都有可能出錯，時間同步的任何單元節點都有可能出bug；出bug是不可避免的，即使之前沒出現過，也并不代表以后不會出現。

4.2 同時啟用多種時間同步

優點是，冗余備份，一種方式失效時自動切換到其他方式；缺點是，實現復雜，需處理時間源優先級和沖突，如多源時間不一致時以哪個為準；且很容易出現的問題是：第一種時間同步和第二種時間同步的時間本身存在誤差， 例如 NTP 服務器的時間比基站的時間慢 5 秒，這樣就會出現基站先同步，NTP 后同步，假設在實際時間 12:00:00，基站同步時間成功，此時模組的時間為 12:00:00，過了 3 秒后，模組的時間為 12:00:03，此時 NTP 時間同步成功，會將模組時間同步為 11:59:58，模組時間就出現了跳變；在實際網絡環境中，可能出現忽前忽后的跳變。

所以啟用一種還是多種時間同步，取決于項目業務邏輯對時間的容錯要求。

五、項目開發中如何選擇時間同步方法

5.1 如果項目業務要求必須要有正確的時間

時間同步如果是受限于模組或者用戶自己的服務器之外的其他節點，時間同步出錯時解決的時效性是不可控制的;

如果項目要求時間必須準確，且時間同步出錯之后可以得到及時解決，推薦僅僅使用自建服務器進行時間同步，并且這個服務器就是項目業務服務器，當模組和服務器建立連接后，服務器首先下發時間給模組，這樣模組在和業務服務器進行其他業務交互時，就能保證時間的正確性。如果出問題，我們和用戶雙方也可以及時溝通解決。

5.2 其他應用場景

推薦多種方法并用，在用戶腳本可以控制是否將獲取到的時間同步到模組的方法（自建服務器，GNSS）中，可以根據項目需求，設置一個誤差閾值來決定是否更新時間，這樣可以大大降低時間跳變的概率。

六、不同模式下時鐘誤差

模組時鐘在運行過程中的誤差實測

測試硬件：Air780EHM

常規模式：無誤差

低功耗模式：暫無數據

psm+ 模式 ：

時間差距和休眠時間有關系，也和內部/外部晶振有關系，和休眠時間成非線性關系，整體來說，休眠時間越長，時鐘偏差越大。

今天的內容就分享到這里了~

審核編輯 黃宇