帶你認識物聯網 Modbus 通訊協議（二）

The Modbus Protocol

在上一篇文章裡，我們已經介紹了本系列的前三個部分，包含機器通訊的運作原理，0 與 1 構成的計算機結構，數據要如何用二進位與十六進位來表示以及通訊上什麼是 Master-Slave 的主從式架構，雖然知識都是有點硬卻也是後續要聊的 Modbus 通訊協議的重要基礎，如果還沒看過第一篇的人，建議點選上面連結先回去看看。從第二篇開始，我們就要正式來進入 Modbus 通訊協議主題了，這次我們會談談：

1. 什麼是通訊協議，了解 Modbus.org 為何要規範通訊協議
2. 完整的一句話該怎麼說，了解如何用協議規範組合成 PDU
3. ADU & CRC，了解 ADU 的組成方式與 CRC 數據檢核機制

協議就是一種共同語言

以前當 RD 在開發系統產品的時候需要控制很多硬體設備，韌體工程師有說硬體控制可以走自定義的通訊格式，需要搭配一張指令對照表，按表組成命令下給終端設備，設備們接收到正確的指令後才會做出正確的回應（對於不認識的指令，設備會只會已讀不回！）。仔細看對照表裡面有各種動作或設定代碼，例如：可以用讀取的功能代碼再加上存放某個電壓或電流的記憶體位址就能組成來提取要監控的電壓、電流等數值的指令。原則上，每一類設備會有自己的對照表，裝置總類何其多，難道要逐一客製所有的通訊功能嗎？有沒有更簡單的方法呢？

Modbus.org 協會起了大作用，他們是負責定義跟標準化 Modbus 通訊協議的組織。

所謂的「協議」指的是經過談判、協商後所決議共同遵守的約定。

在官網所提供的的白皮書裡有也有交代協會已經把通訊主要的動作代碼整成一張表了，總共有 65 個標準動作，這些官方指定動作代碼也叫做 function code，功能碼意思。只要設備商們有按表實作協議要求的通訊功能的話，我們就能預期機器接收指令後該有的反應。這就是有標準協議的好處，大家講好規則，對照表一張就夠了。

Table of function codes.

如果還是覺得協議感覺很抽象的話，不妨把協議想成我們日常使用的任意一種語言。就以英文為例好了，英文明確規定所有的單字都是 26 個字母組成，每一個單字都有明確的發音規則，文法裡也定義了各種組合多個單字來表達意思的規則… 也因為我們人類有了這套「英文聽說讀寫的協議」，我們才能正確理解對方，才不會有看到或聽到「Apple」卻不曉得對方講的是「蘋果」的窘境。同理在物聯網的 Modbus 通訊協議就是人類幫機器們在工業通訊領域所規範的一套語言，有了共同語言就能提高溝通的正確性與效率。

用 PDU 說出完整的一句話

在我們的語言裡，要組合出一句有意義的話，對機器來講是非常困難的，在這複雜的語系裡面有代表你我他的主詞、有代表行為的動詞、有代表具體事務的名詞、有用來描述物體的形容詞，修飾動詞的副詞、連接詞、介系詞… 片與、慣用語、成語、文法有這麼多特性的詞語特性所構成的龐大體系，一個普通人要學會一套新的語言，絕對要有個幾年修為。而 Modubs 通訊協議作為給機器用的語言有著簡單易懂的特性，想要組成一句話，就只要動詞、名詞、跟量詞就可以了。

Modbus 通訊協議裡面有 65 個官方功能碼可以運用。這些功能碼又可以區分為讀跟寫兩大類，按照讀寫的目標對象不同，還可以進行細部分類。例如：如果我們想要讀寫一個線圈（或叫做開關）就可以用 01 (讀) 跟 05 (寫) 來起頭串接指令。假設我們要的開關的記憶體位置在 x5678（十六進位表示），那麼 05 5678 01 的意思可以把 5678 這個開關打開，05 5678 00 就是關閉開關，用功能碼＋記憶體位址＋數值組成的一句話就叫做 PDU，Protocol Data Unit，也叫做協議資料單元。

ADU & CRC

PDU 被定義為與底層無關的應用層級的資料格式，什麼叫做底層無關的應用層級資料呢？我想大家都有寄送過包裹的經驗對不對？在選擇實體的物流上我們可以指定不同的運輸方式，例如：透過郵局寄掛號或超商宅急便，不管用哪一種寄送方式送包裹，裡面的內容物 (PDU) 永遠不變，此時負責實體物流的郵局、宅急便就對應到不同的通訊底層。 Modbus 協議的目標就是不管底層通訊要走的哪一種類型傳輸介面都可以，確保送出去給對方裝置的 PDU 是不變的，這就是應用層級資料內容的概念。

要注意的是不同底層通訊介面需要對 PDU 將行二次包裝。就像我們不能直接拿貼有郵票的包裹直接叫超商宅急便收貨寄件，必須按宅急便的要求二次包裝跟寫單據。同理，當 PDU 要走不同的實體通訊介面時，也該根據不同介面要求來二次包裝 PDU，經過包裝過的 PDU 就會變成 ADU，Application Data Unit，也叫做應用資料單元。再來借用 RS485 的 Modbus ASCII 為例，ADU = 裝置 ID + PDU + CRC， 由於 RS485 定義的主從式通訊架構的 Master 底下可以有多個 Slave 裝置，所以 Master 在發送訊息的給特定的 Slave 裝置時就要帶上 Slave 的 ID 作為識別。

ADU = 裝置 ID + PDU + CRC

這裡的 CRC 叫做 Cyclic Redundancy Check 也叫做循環冗余校驗，它就是一種用來檢查 PDU 內容是否有錯誤的一種檢查碼演算機制，兩個互相傳遞訊息的 Master 或 Slave 會各自計算跟比對來源的 CRC 來確認 PDU 的正確性。只有收到的跟計算的 CRC 一致，裝置才會開始解讀 PDU 執行裡面的指令。

結語

我本身很少引用宗教的語言，實在不好意思班門弄斧。不過 Modbus 通訊協議與於人類的語言還真的有幾分上帝按照自身形象造人的味道。我們人類本身就是這些機器裝置的設計者（造物主），而由人類為它們定義的各種通訊方式與通訊協議也都模擬了人與人的溝通方式，時而單字單詞，時而完整語句，就算不小心聽錯或者沒聽懂的時候也都有相互確認機制來讓溝通持續下去，所以機器裝置間的溝通還真的跟人的溝通本質上真的沒有太大的不同啊。說完了 Modbus 通訊協議的基礎，接下來，我們準備進入第三篇，正式來看 Modbus TCP 這個 Turbo 版本的 Modbus 通訊協議，並實際看看一個完整的數據搜集系統的架構的樣貌。那我們就下一篇見了。