物聯網:把外圍變成藍牙?

三月 11, 2014
Facebook
Twitter
在旅行時監控自家的情況,或是預先打開別館的暖氣,像這種利用物聯網(IoT)來四處連接的情況就是利用網際網路協定(IP)。因此在我花了三年完成的著作《Getting Started with the Internet of Things》中就將IoT定義為「利用網際網路協定連接的電腦、感測器及致動器的總體網路」。
這是將IoT大幅度地單純化且理想化後的姿態,是一幅技術被完美俐落地展現的景象。在那裡IP封包能從溫度感測器傳送至雲端數據中心,再送到暖氣的控制器。過程中不會有麻煩的通訊協定變換,或是讓配置或程式傷透腦筋的複雜閘道。
現實總是事與願違。有時要互相配合、有時又互相對抗,簡直是不可理喻的標準規格聚集的動物園(動物越多越熱鬧)。

我經常思考三年後、或是十年後,現在的情況會變成什麼模樣呢?新的技術也加入的話,一定會變得更有趣吧。把我跟我的朋友們人生的時間及付出的血水、汗水、眼淚全投注在特定的技術上並不快樂;建議客戶採用某個技術後結果之後摔了個大跤也很無聊。

走正道或走小路?

人們對這個難以理解的狀況的反應,我發現大致上可以分成兩種類型:一種是站起身並捲起袖子,說:「好,為了達成理想,來做我能夠做的事吧。讓網際網路協定遍地開花吧,反正從歷史的觀點來看,網際網路協定已經勝過了所有其他競爭的通訊協定。」另一種是聳聳肩,說:「反正世界就是這樣運轉的。競爭是好事。網際網路協定碰上大麻煩也沒差,反正其他能用的通訊協定還有一大堆,選自己喜歡的來使用就好了。」

讓我們把這件事看成一條「正道」對上許多「小路」吧,這可是炒熱討論的有趣拔河賽。相對於「從一開始就要設計成低耗電量,以此最佳化感測器網路的無線通訊協定,否則消耗太多電力就不實用了。應該停止採用網際網路協定。」另一方則是「有壓縮IP標頭等各種技巧。因此從感測器到路由器的無線通訊並不會消耗太多電力。IP才是開展未來的手段。」

技術爭論的焦點則集中在到IoT的最後一哩(Last Mile)的幾公尺處所要求的架構品質,這正是IoT「成為實體」的部份。例如置於庭院的電池式植物感測器、控制輸送帶的即時決定機制、為了不熟悉技術且平均年齡超過80歲的系統管理員而簡化的系統管理,或是為幾乎不具備技術知識的現場工作者簡化管理他們所設定的工具機控制器鑰匙等等。 

我很懷疑在這種情況下還能說網際網路協定「已經足夠了」嗎?要到什麼程度才夠好?即使讀了各種討論或研究報告,但每篇都有它的道理在。如果要從長遠的眼光去思考何者才是正確的,則更陷入十里迷霧中了。有時我會因此戰慄,有時也想無奈地聳聳肩。確實,網際網路協定曾有過把類似IBM的令牌環(Token Ring)的特殊規格如推土機一般地推走的驚人世界記錄,或是踏入了很明顯地不適合的領域。舉例來說,Ethernet已經成功進化到能支援工業領域的即時性(然而現在想要取代即時性Ethernet的新規格就有20個(!)在相爭,要選出一個還真困難)。

因此如同歷史告訴我們的一般,網際網路協定要取代其他「古董」通訊協定也只是時間的問題吧。

 

低功耗藍牙(Bluetooth Low Energy

這裡有兩個反例,那就是跟網際網路成功並行的通訊技術:USB及藍牙。他們對於網際網路協定有很強的免疫能力,使用它們甚至可能辦到穿隧協定。因此它們或許能在IoT的最後一哩上發揮免疫效果也不一定。

2005年時我的客戶CTO告訴我諾基亞的研究中心正在開發新的無線技術,那項技術叫作WibreeWibree被認為在短距離、低耗電自動化家庭方案或醫療相關應用上是十分有用的技術。幾年後諾基亞運用非常巧妙的戰略將Wibree讓渡給藍牙技術聯盟(Bluetooth Special Interest Group)。加上些許改良讓它更符合現有藍牙的規格後,2010年它正式成為藍牙4.0的一部份。現在這項技術被稱為低功耗藍牙(Bluetooth Low EnergyBLE),在行銷上則叫「Bluetooth Smart」。

儘管它跟網際網路協定間無法互換,但讓BLE爆炸性地成長的特點即是跟過去的藍牙解決方案相較之下,它增加的成本非常地低廉。在支援藍牙的現行產品上加入支援BLE的升級費用也十分便宜。自iPhone 4S之後,Apple所有的產品都開始支援BLE。除了搭載新藍牙的晶片,Apple也發表了能支援BLE APP開發的應用程式設計介面(API)。現今這類APP,及與其連接使用的裝置則被稱作智慧配件Appcessory)。舉例來說,一位現場技術人員能透過BLE來用自己的智慧型手機設定新幫浦,如此一來幫浦本身就不需要裝設設定用的液晶面板或USB插頭。當有需要時,它也能做為印表機連接網路的臨時閘道,如此印表機就能提取新的韌體。
當然,智慧配件可不是只有商業用途。我們初踏入這個領域的作品是這個在2012年聖誕節發表的電子將臨花環(Advent Wreath。它給我們著實上了一課。舉例來說,假如Apple 要求你得寄一個裝置給他,否則他就取消你的APPApp Store的上架許可。那如果是BMW的高級轎車裝載BLE的話,BMW也得寄一輛車給Apple嗎?我不禁思考起這個問題。
 
去年GoogleAndroid API終於也開始支援BLE。或許正因如此,今年MicrosoftWindows Phone也不得不開始支援BLE。這讓BLE從鞋子感測器或心跳監測器等運動裝置到智慧手錶,接著是大門、電視、庭院的灑水器等等,所有在你身邊的且你想控制的事物它都能支援,成為真正意義上的跨平臺技術。

多虧Google API登場,我才能在2013年的聖誕節推出支援Android版的將臨花環APPGoogleBLE功能才實裝沒多久,還沒像Apple那麼成熟,所以還有一些毛病。不過這個問題正確實地改善中,開發者們也熱烈地交換情報。為此我們還成立了一個Facebook社團

就此妥協嗎?

BLE或許是一個不會屈服於網際網路龐大勢力的新通訊技術。雖然它才誕生沒多久,但儼然有孩子王的架勢了。前陣子我聽說了一個大樓自動化的計劃,該計劃明言要用BLE來控制照明。我個人認為ZigBee比較適合這棟建築。「能用智慧型手機或平板電腦控制」這句話似乎能把所有反BLE派想得到的反對意見徹底推翻,但事情也有無法順利進行的時候。曾有家新創企業跟我們聯絡,他們的構想是在大型商業設施中的數百臺感測器上裝設BLE,再用一臺GSM閘道直接連結。但很遺憾的是,現今的BLE是為了最後一哩而生的技術,因此它無法穿透不同樓層或數面牆壁的障礙來提供穩定的連接。


服務導向架構的裝置
 

身為一名軟體架構師,我發現BLE在有些面向上非常深奧,有時卻又讓人煩躁,它同時存在程度極低的最佳化,以及極高完成度的架構概念。它是被最佳化過的低耗電用設計,也將需要傳輸的數據量抑制在最小限度。然而它卻又定義了所有的「通用屬性設定檔」(Generic Attribute ProfileGATT),包含了「Characteristic (舉個例子,房間的氣溫或閥的開關狀態)、一套含有相關Characteristic的「Service」,以及一套包含相關Service的「Profile」。Profile的用途是支援使用目的,像是測試血壓的Profile就會用在測試血壓上,它就是如此運作的。Service則是允許再使用的介面,像是裝置資訊的Service就會提供裝置製造者及產品編號等資訊。

 
韌體地獄:類固醇成癮的DLL地獄

ServiceBLE的核心概念。單一的Service被定義為不能變更的Characteristic集合。為什麼不能變更?這樣有什麼意義嗎?理由如下:低成本的裝置大多不易更新韌體,或者完全不行。如此一來,要是該裝置已經開始販賣的話,之後想要再變更Service就會發生問題。假設當你想增加某些便利的Characteristic時,卻沒辦法把這個新韌體傳送到已散布到世界各處的裝置上。當一臺更新完APP的智慧型手機要連接舊裝置上的新Characteristic時,會產生很麻煩的問題。像這種元件間的版本不相容問題,軟體界稱它叫「DLL hell」(DLL 地獄)。在這種情況下,雖然可以藉由再安裝具有格式相容性的組件化解不相容,但如果是不具相容性的裝置且韌體又無法升級,你會陷入更嚴重的「韌體地獄」。

因此,當你出貨一臺附有某項Service的裝置時,先把它定義為不可變更的「ServiceA」。<*註>當之後變更Service的需要產生時,增加一個新的Service並定義為「ServiceA1」。如此一來它就變成ServiceA的母集合,可以涵蓋額外追加的Characteristic。這種新裝置可以安裝兩種Service。(要是除了多加的Characteristic以外都是同種類的話,那樣會更便宜)。這裡有四個群集,顯示Service的提供者(「周邊設備」)能與Service的使用者(「中央」)連接的狀態。把中央想成你的智慧型手機吧。

  1. 你的智慧型手機內安裝了執行初版ServiceAPP,當它跟初版的裝置相連,智慧型手機會去尋找裝置內的ServiceA,找到的話就可以連接。
  2. 你的智慧型手機內安裝了執行初版ServiceAPP,當它跟擴充後的裝置相連,智慧型手機會去尋找裝置內的ServiceA,找到的話就可以連接。由於該APP無法辨認已擴充裝置增加的Characteristic,所以無法使用新的功能。但這不成問題,原本的功能仍能正常使用。
  3. 你的智慧型手機內安裝了執行擴充後ServiceAPP,當它跟擴充後的裝置相連,智慧型手機會去尋找裝置內的ServiceA1,找到的話就可以連接。由於該APP可辨認已擴充裝置增加的Characteristic,所以可以使用新的功能。
  4. 你的智慧型手機內安裝了執行擴充後ServiceAPP,當它跟初版的裝置相連,智慧型手機會去尋找裝置內的ServiceA1。但是裝置回答「這是什麼?我不認得ServiceA1。」接著APP會去尋找較舊的ServiceA,執行舊Service的功能。雖然用起來沒像用新裝置那麼酷,不過還是堪用。


讓我用圖解來說明以上四個狀況吧。

當你確定不會再使用、或是決定停止支援舊裝置時,你可以讓APP的新版本改支援別的功能。要是裝置不支援ServiceA1的話,就趕快放棄為這個APP花額外工夫吧,早點告訴使用者不支援這個裝置,如此你也不須煩惱得一直保留老東西,只為了應付使用者持續的要求。

當將來所有的裝置及APP都能互相連接時,上面的機制將會成為根基。裝置與APP的組成將會是由新東西、有點舊跟非常舊的東西結合而成。

網際網路協定為核心,外圍用其他技術

在這之後,我們也會彷彿迷路一般在各種小路裡前進吧,因為那裡有許多通往正道的出入口。特別是在網路的「外圍」,暫時還有許多技術會殘留在那。其中有不支援網際網路協定,也不像網狀路由協議一般擁有先進的功能,BLE就是其中一項。我祈禱對BLE的高度關注不會成為最大的問題。有許多團體正試著以各種形式擴充BLE,此外新的藍牙4.1的規格中也加入了BLE hub,在IPv6上試行BLE的嘗試也正要開始。

然而,其他的IoT外圍技術又如何呢?雖然有看似能使用的技術,但果然還是無法無縫整合進IP的世界。那麼只要超越這些優點(已經能使用、很適合用在工作上等等),或缺點(得學習新技術,網路效應network effect)較低等等)就好了嗎?同樣的問題在應用層的通訊協定上更加嚴重。什麼時候我們可以認真考慮把HTTP做為一致的通訊協定並用在「物聯網」上?什麼時候可以轉移成MQTTXMPPAMQPZeroMQ等等。

我希望可以聽到你們的想法。

*註:如果你知道MicrosoftComponent Object ModelCOM)的話會許就會懂了。COM介面跟BLE Service有點像,皆是無法變更的Method集合。要我說的話,這是Microsoft出產的產品中最創新且合適的點子了。由於之後開發的.NET,它失去了發展的機會,不過最近Windows Runtime的開發者們開始重新審視它了。

– Cuno Pfister

[原文]

Social media & sharing icons powered by UltimatelySocial