IEEE1888-物聯網領域的綠色節能標準（三）

四．現實中1888協議的實現         在1888標準通過後不久，日本東京大學即提交了自己的實現（見http://133.11.168.39/dist/），筆者不懂日文，不太明白上面的意思，但大致看出來，東京大學的相關應用工作一直在繼續，並且做得不錯，版本一直在升，應用情境也在擴大。文字不太懂，程式倒可以看看，以下是編號為201310的1888示意包（大概是2013年10月版）的特點：
代碼編寫規整，雖說注釋少了點，但命名規範還是嚴格遵守的，因此花點時間，仔細讀一下，也不算困難。 代碼只能在Linux下運行，不能說是一個“遺憾”。 代碼採用C語言編寫。 代碼不依賴於任何第三方庫，包括XML的解析以及HTTP的解析都是自己完成，因此，代碼的發布與部署就十分簡單。 以上兩個特點一結合，使代碼可以適用於Linux下的任何地方，通用性非常好。

關於東京大學的實現，本文不展開討論，有懂日文的同事可以協助翻譯解釋一下。

      中國這邊，由天地互連等組織做了一個IEEE1888開發平台（http://open.ieee1888.org/home.html），其中有標準的介紹以及相應的SDK，有興趣的同事可以下載自己研究。
      以上兩者的實現，都基於web service(SOAP)，並且在實現過程中，由於web service的一些特點，在標準規定的<transport>外層另外包裹了類似<dataRQ>,<dataRS>之類的節點，這類節點的命名是非標準性的，因此這樣的擴充值得商榷。
      實際上，在標準中，並未規定1888協議的承載協議一定需要SOAP。SOAP實現比較嚴格但相容性較差（最大的問題恐怕是上面提到的節點及命名空間），因此筆者建議不如直接採用HTTP+XML方式，而不是HTTP+SOAP+XML方式，並且一般情況下不採用命名空間。這樣的好處在於簡潔，實現方便且便於互連。
      今後標準的發展中，宜將協議中的細節例如命名等做進一步規定。

五．採集系統中1888協議的應用

在1888標準架構下，一個採集系統的主要工作流程（採用trap方法）及實現要點如下：

1.    網關的配置中，必須有Registration服務的訪問方式。

2.    網關通過registration服務，採用registration方法註冊自身以及它所管理的測點。

3.    registration服務在某網關註冊之後，按照註冊情況，向網關訂閱相關測點的資料（data方法，trap協議，目的為合適的storage地址）。

4.    網關收到storage的訂閱請求後，按時將涉及的測點的資料發送到storage（data方法）。

5.    如果網路發生異常，網關端是否快取資料，標準並未規定。

6.    如果storage發生變化，網關端如何檢查到並能遷移到新的storage，標準並未規定。

7.    如何取消網關資料的訂閱，標準並未規定。

8.    網關的query方法能夠接受外部來的、查詢測點數值的命令（即設定動作器的值，產生相關的動作）。

9.     網關的data方法能夠接受外部來的、能夠設定測點數值的命令（即設定動作器的值，產生相關的動作）。

10.  採用統一的規則建立點名，IEEE1888中建議採用uri的格式（不是必須遵守）。

11.   註冊時，測點的單位、資料類型，是否可寫的（可設定）必需指明（這一部分是非標準的，必須擴充）

12.  1888標準中，對組的定義不太詳細，如果支援測點組，需要做一定的擴充。例如規定不允許嵌套組等。

  六．對1888標準的一些思考

         從上面對1888標準的介紹，可以看出該標準主要應用於慢速、“自治”的網路中，例如建築節能、公用事業、智能傢具等即時性要求不高的場合，“自治”的意思是裝置的進入、退出都是自由的，沒有管理者，盡量減少依賴性和強制性。由此，1888標準只注意了資料的傳輸，並沒有注意如何保證這些資料的傳輸等措施，細節的規定也有待強化。

       總之，1888標準是一個比較泛化的標準，1888.1,1888.2,1888.3,1888.4等子標準即為這些“強化”措施。下面將介紹這些子標準。