2018年2月24日 星期六

BACnet 學習心得

在深入淺出 RS485 Part 2 一文裡提到了 BACnet,這裡就來公開這方面的學習心得,很多人一定好奇,這麼複雜 protocol 值得花力氣研究嗎?

這裡留幾條線索給大家自行判斷重不重要:
  • 根據去年看到的資料,BACnet 在建築自動化的通訊協議佔有率:
    • 美國 > 60%
    • 全世界 > 50%
  • 據消息指出,台灣發電量 60% 用於冷凍空調,而冷凍空調屬於建築自動化的一環(冷凍空調在台灣屬於特許行業,甚至考乙級證照還需要兩年以上工作經驗)
  • BACnet 為工研院可技轉項目之一
  • BACnet 與 IoT 的關係?

筆者把學習 BACnet 分為幾個方向:
  • 參考資料
  • 開發與測試工具
  • 測試與開發環境建置

參考資料

BACnet specification

不用說,這是一定要的,跟很多知名 protocol 一樣,這份 spec 也是要花錢買的,規格加測試方法需要 200 多美元,內容超過一千頁以上。

沒有這些 spec 能不能做?當然能,筆者當年把 Yet Another BACnet Explorer 硬從 C# 改成 C++/Qt 在 Linux 上跑(C# 還是第一次接觸,邊改邊學),只不過那些 ASN.1 編碼、State Machine、各種 Network Services 的細節與限制就一無所知了。

還有一點是 BACnet 大量充斥各種專有名詞縮寫,spec 還兼具字典的功效,BACnet 產品操作手冊與規格裡也是大量這類縮寫,少了這份 spec 可能連產品廣告都看不懂。另外記得下載 errata。

簡體印象中有兩本,不過建議別買了,因為大部分都是抄襲官方 spec,還抄的不清不楚。當出會買是因為前公司不願意出錢買 spec,要我做功德那就只好選擇最便宜的方案。另外官方也有出一本,筆者讀過試閱版覺得很不錯,不過價格也跟 spec 差不多,換算成台幣大概要 3000,照簡介來看,這本書的用意是解釋規格背後的成因跟脈絡,如果預算夠當然也是建議買一本備查。

網路資源

Steve Karg's blog

Steve Karg 大師身兼 BACnet 委員會成員與 BACnet stack 作者,他的 blog 是一定要拜訪的。他的文章與投影片也極具參考價值,可以當作研讀 spec 的輔助教材。

The BAC Cave

此公也是 BACnet 委員會成員之一,很遺憾他已於 2011 年過世,所以 2011 年後就沒更新了,不過 BACnet 是 1987 年就開始發展了,裡面應有不少寶貝有待挖掘。

其他

台灣還有人把 BACnet 當作碩士論文發表,不過在筆者學習 BACnet 的過程中幫助不大,有興趣的請自行上國家圖書館論文索引系統搜尋,或是直接 Google "BACnet + 論文" 可以找到幾篇。

開發與測試工具

BACnet router

需要 router 是為了研究 BACnet 跨越不同 physical layer 時是如何工作的(如 BACnet IP 如何跨到 BACnet MS/TP),要買當然要買通過 BTL(BACnet Testing Labs) 測試的產品,BTL 官網已經做了很好的分類。

BACnet gateway

建議購買 BACnet IP or MS/TP to Modbus Gateway,原因很簡單,因為可以把 gateway 接上 modsimModbus Slave 等 Modbus Slave 模擬軟體觀察 property 的變化,也可以與 BACnet router 組合測試。需要注意的是,在 BTL 裡大多被歸類為 BACnet Application Specific Controller (B-ASC)

BACbeat

這個工具是 BACnet  產品經銷商推薦的,不過是商業版軟體。

Visual Test Shell for BACnet(VTS)

原本由美國 N.I.S.T.'s Building and Fire Research Laboratory 開發的 BACnet 權威開源測試軟件,不過如果您是 BACnet 新手可能會覺得很難上手,因為他把 BACnet 很多 services 拆解成獨立測試項目,建議先熟習 spec 後再上路。

Yet Another BACnet Explorer(YABE)

對新手來說很容易上手,個人強力推薦,source code 可以看出參考了不少 Steve Karg's BACnet stack

USB/RS232 to RS485

研究 MS/TP 封包時使用

Ethernet Hub

現在已經很難買到全新的 Ethernet Hub,不過您可以 DIY 一個 Ethernet Tap,如下圖所示:



簡單來說就是把 Host A <---> Host B 的 Tx 訊號導向 LAN Port A's Rx,Rx 訊號導向 LAN Port B's Rx,材料就只是一般牆壁或辦公室隔間上的網路插座罷了。

Raspberry Pi

這個是為了執行 BACnet stack,當然如果您的電腦夠快記憶體夠大,後面會介紹一種使用 VMware or VirtualBox 的作法。

測試與開發環境建置

有人堅持學 BACnet 只能從 spec,看封包是錯誤的方式。但為何不能結合讀 spec 的 top-down 方式與看封包的 bottom-up 方式?再說,從封包回溯 spec 要比看 spec 去猜封包長什麼樣子、網路行為是怎樣要容易多了。筆者常用一個比方,如果你從來沒有看過大象,是給你看過大象的照片去寫一篇短文形容大象容易呢?還是給你一堆大象的描述,要你去畫大象簡單?

這邊介紹一個方法,不但可以錄製 MS/TP 封包,還可一兼二顧學習 BACnet stack,了解 spec。

首先把 VMWare or VirtualBox 安裝好 Ubuntu(筆者比較熟習 Ubuntu),然後進行 RS485 佈線:


觀察封包

先執行 mstpcap.exe,然後把 BACbeat/VTS/YABE 跑起來與 BACnet MS/TP 通訊,接著按下 Ctrl+C 中斷 mstpcap.exe,mstpcap.exe 在結束前就會把封包儲存成 .cap,接著就可以用 Wireshark 打開(如下圖所示):


也可以把 BACbeat/VTS/YABE 放在同一台 PC 上執行,不過這樣就需要 3 個 USB to RS485,這邊到不用花大錢去買 M 牌的產品,淘寶上有很多便宜選擇。

觀察封包+研究 BACnet stack

因為 VMware/VirtualBox 可以連接實體 USB  to RS485,所以可以用虛擬機內的 Ubuntu 執行 BACnet stack 範例程式連上 BACnet MS/TP device。這時候關鍵的地方來了,因為我們有 BACnet stack source code,所以可以利用筆者之前發表的文章:
把 BACnet stack runtime 時的 function 呼叫路徑給列出來,除了避免閱讀不需要的部份外,配合 spec 可以加深對 spec 的了解,比方說 MS/TP Master state machine。

這下子封包有了,BACnet stack run-time call graph 有了,spec 有了,再弄不懂 BACnet 大概也沒辦法了?

尾聲

寫這篇的原因是去年花了不少時間研究 BACnet,但最後不了了之,與其選擇遺忘不如分享給需要的朋友們

7 則留言:

  1. 可不可以請教一個問題:

    文中有提到 USB/RS232 to RS485 。以我自己的經驗,其實許多這種東西

    一般也都是用 Virtual COM 的方式來處理,這可能是牽涉到APP 底層還是都是

    以CALL COM PORT 的方式處理,大家懶得改?

    我自己在用就覺得有點"拙"...因為這一種做法要底層自己去找出對應到哪一個

    COM port 就有點怪... 有時是COM4,又不知道跑到哪一個COM X?

    所以我自己在做這件事時,我就乾脆用USB HID 下去,然後呢?反正

    到了USB Controller MCU 那邊時,也會自己的UART,就乾脆把原本

    PC 對應的 UART 的事轉到那棵 USB Controller MCU 去處理。

    不知道這種作法對於你們這一種搞工控的人來說:我想法是否是比較天真的?

    還是吃米不知米價的"外行人"?

    回覆刪除
  2. USB to RS485/RS232 有人做成地攤價,也有人做成精品(4PORT要價8000TWD),做成精品的那一家,就可以把 COM Port 編號給鎖定,也就不會有編號跑掉的問題了。

    工控這幾年也慢慢接受 USB 了,Mitsubishi, OMRON 這些老字號 PLC 廠,上下載程式的CPU Port都可以見到USB了,否則工控的程式也是越長越大,每天光上下傳程式就飽了。

    當然歐美都是往Ethernet發展了(所謂的industrial ethernet),例如 Profinet, EtherNet/IP, EtherCAT...都是 Ethernet 相關,最近看到一個案例是 EtherNet/IP 接 84 台變頻器,如果用 RS485 跑起來效能一定很悲劇。

    不過有所謂的林迪效應(Lindy Effect),意思是對易損的東西來說,每多活一天,都會縮短其壽命;相反的,對於不易損的東西來說,每多活一天,都將更拉長其存在壽命

    RS232/RS485/RS422 就很像這種東西,工廠一用10幾20年都不太會壞,壞了更換成本也很低,也不太會像USB挑線材,DIY easy,很少相容性問題,距離也夠長,要跟 HMI/SCADA 通訊也容易,缺點就是頻寬小了點

    如果要改成USB,Mitsubish, OMRON 這些廠商也未必願意把資料放出來,像小弟以前搞HMI,就算你願意放出來,那我還要花很大力氣處理 USB driver(10家廠商做10次)...那乾脆跳一級直接上 Ethernet 不是更快更好?國外某大廠牌HMI連上下傳HMI程式的USB device port都乾脆拿掉只留Ethernet,以前做HMI時Windows USB這邊還會被防毒軟體找碴,或是挑線材,客人弄幾次也沒耐心了,再說不是每間公司都有您老這種USB大師坐鎮,哈~

    所以雖然COMx 這種問題有時候很惱人,兩權相害取其輕,也只能繼續沿用了

    回覆刪除
  3. 指定com port這個問題感覺上像是歷吏包袱,
    就最近看STM32 USB相關的資料與網上搜尋windows usb com port通訊來看,
    要用CDC class的話,
    指定com port是免不了的,
    目前查到的方法都是從Registry 去讀取現在該裝置的com port設定,
    https://msdn.microsoft.com/en-us/library/aa394413(VS.85).aspx

    http://blog.xuite.net/miinyuan/blog/27862127-%E6%90%9C%E5%B0%8B%E9%9B%BB%E8%85%A6%E4%B8%8A%E6%89%80%E6%9C%89%E7%9A%84+RS232+Ports

    只是想一想,
    用USB HID不用driver,
    通訊速度還可以接受的話,
    我就沒動力去試了 orz

    USB就個人使用的感覺,
    就比較適合pc與受控端短距(3米內)的控制傳輸,
    要一對多的話,
    pc軟體介面就要多費心思。
    如果真要長距離通訊的話,
    還真不如RS485 / CAN 或Ethernet,
    成熟又資源多,
    而且Ethernet還有PoE可以加上去用,
    雖然很貴......

    回覆刪除
  4. 好吧。我果然是吃米不知米價的外行人。

    我原來的意思是:在PC 端換成USB ,但在實際上,還是會以傳統RS232/RS485

    傳輸。這樣子的成本應該還好一點,反正也都是要一顆 USB MCU。跟一顆 USB

    轉UART 是一樣的。不過,你們說得也沒錯:可以直接用 Ethernet 的,就比較

    簡單容易快速,至於硬體成本,我覺得那只是時間的問題而已。反正殺價的生意

    永遠都有人在做的。不是嗎?

    回覆刪除
  5. 應該說,如果軟硬體全部包給同一家公司,那當然越方便越好,幹麻還要弄個COMx折磨客人跟自己?

    但是一套工控系統是模組化的系統,可能圖控是A廠商,控制器是B廠商,馬達是C廠商,那可見得A廠商的產品要跟B廠商溝通,沒有一個通用公開的API那要怎麼溝通?最能夠在 XP/Win7/Win8/Win10 間無痛轉換的大概也只剩下 COMx 跟 TCP/IP?

    還有一個麻煩的點,就是 USB 接頭在工控環境實在不怎麼robust,工控環境線材幾乎都是端子台用鎖的加上號碼套管,就算USB可以用鎖的也不是什麼容易取得的標準品。

    還有一點是工控以DC24V 為主流, 可以接 5V 的工控元件幾乎沒看過, 再說沒有隔離這樣直接接大概等等PC也跟著掛了(工控環境很多干擾源),不過現在也有廠商做USB隔離器就是了

    再來是工控系統希望一次能讀/寫越多IO點越好,USB肯定可以把RS232/485幹掉,但通訊的即時性,頻寬,距離..跟Ethernet比起來又差了一截...

    最後是工控系統PC只佔一小部份甚至是不存在,大部份是嵌入式系統,能認得的USB裝置有限,就算是強如Linux也不是每種USB device都有辦法辨識

    所以工控搞到最後才會把自家產品的USB縮限成只能上下傳韌體跟資料的,或者是可以跟自家的產品通訊(我看過三菱的人機界面可以用USB與三菱PLC通訊,但肯定不會讓台達知道怎麼通訊)

    回覆刪除
  6. 就我所遇到的領域來說,
    硬體環境故然是一個問題點,
    傳輸的資料量與傳輸情境也是主導選用傳輸界面的因素之一,
    一但需要pc或nb作為使用終端的操作界面,
    USB與Ethernet就成為極少數的選項之一,

    就看其使用情境,
    要長距傳輸的話,
    USART to RS232/RS485 driver IC就是必備的,
    相對的baudrate就比較低,
    若要用高baudrate(921600 bps以上),
    那driver IC要選別過,
    其次,
    一但將USB作為與PC溝通的傳輸界面,
    USB的Firmware與PC的software人力也是要準備的,
    也就代表後續有相容性問題要處理的心理準備,
    畢竟不是每間公司都有像Chamber大這種熟USB界面的人材,
    也不見得想養這樣的人。
    所以大多數還是會選像FTDI這種廠家的產品,
    把USB相容性與PC driver的問題由廠商來包了。

    而且就我所看到的,
    需要長距離傳輸的,
    很少只要1~2個port.......

    回覆刪除
    回覆
    1. 感謝分享...剛剛想起,其實還有RS485轉光纖這種東西,長距離有時是連RS485 9600bps 1.8公里都不夠用阿

      刪除