物聯網 command 原型設計及架構

標籤：

在另一篇文章講述了client API設計（IOT command （based on sip）client API設計 for java ）。

前段時間梳理了command設計及架構，其實狹義上即裝置控制、管理，即可以家庭區域網路內進行管理，也可以遠端管理(通過開源的sip server: opensips)，當然也包含了裝置聯動規則的原型實現（即物聯網的ITTT）.

command包含兩部分：即client和server(eg. 手機上的client app，gateway上的server)

流程如所示：

1. 手機發送遠程請求：對房間內hue開燈2. 物聯網cloud平台接收到請求轉寄給相應的gateway3. command_svr接收，解析發送給hue模組，hue模組進行本裝置類型協議的通訊，實現開燈請求4-5. command_svr將操作結果發送回去，由opensips轉寄給client, client獲知開燈成功結果。 client主要功能：1. 請求gateway的裝置列表，裝置功能，狀態2. 發送裝置操作請求，並接收裝置操作結果3. 訂閱， 接收裝置訊息通知 sever主要功能：1. 管理接入到gateway的不同裝置類型列表，裝置外掛程式以動態庫形式接入，方便第三方接入。2. 接收client的裝置操作請求，轉寄給相應的裝置模組(eg ip_camera)，由該模組進行協議轉換，進行實際的裝置控制，然後接收操作結果，並將其轉換為command協議，返回給client response.3. 接收裝置模組的主動推送的訊息，並推送給相應的client.4. ittt功能：接收並儲存client制定的裝置聯動規則，檢查client的裝置控制請求，如符合if, 則觸發then的裝置控制。

 

目前command的實現是基於sip來實現的，對sip的方法進行擴充，即增加一個定製的方法sip-command，並在其基礎上實現裝置控制層，command在pjsip開源庫基礎上實現，而遠端管理藉助開源的opensips伺服器，達到快速原型目的; 另外一個原因是項目中流媒體傳輸播放需求是基於sip/rtp來實現，統一在sip下，減少學習投入成本，儘快出原型。 是一個command架構圖，底層是sip層，在pjsip基礎上增加了command方法；cmd_mng定義了兩個主要介面(cmd_send_inf, cmd_recv_inf)來和sip層進行通訊, 考慮將來方便替換或相容不同的協議，達到模組間松耦合。cmd_mng上層分別是dev_mng和iot_cmd_proc兩個模組，dev_mng包含了command server端的管理、載入裝置外掛程式，即裝置的function功能和裝置中繼資料檔案解析匯入（通過定義plugin_interface介面，提供給第三方開發為gateway接入新裝置類型），以及供client查詢裝置元資訊的內部介面。iot_cmd_proc模組則包含了client, server的收發command訊息的處理架構，和提供給第三方開發client端的介面(即開頭講到的client API設計)。
1. 下面介紹server端的供第三方接入新裝置類型開發的介面定義（第三方實現，並以動態庫的方式提供給gateway command-svr）plugin_interface介面:

typedef struct dev_func{ const char * funcname; int (* dev_method)(cmd_arg * param_list[], uint8_t plist_size);    }dev_func;typedef struct dev_plugin { char dev_pluginname[NAME_MAXSIZE];  //裝置類型名稱，具有唯一性 const dev_func * pt_func_array;     //函數列表，裝置實際執行函數，供command-svr回調。 char dev_metafile[NAME_MAXSIZE];    //裝置中繼資料檔案}dev_plugin;typedef int   (* init_devplugin)(dev_plugin * pt_plugin, dev_cmd_interface * pt_inf);

command-svr通過init_devplugin函數，會讀取到該裝置外掛程式的上面資訊， gateway便知曉該裝置類型具有的屬性和功能。（後續還需要有裝置外掛程式的熱更新，刪除，運行時載入等功能） 2. 下面介紹iot_cmd_proc模組，它是command的邏輯處理核心以client端為例，採用記憶體訊息佇列形式(使用mini_mq)來解耦業務層(cli_proxy)，command層(cmdhandler_proc)，承載msg的協議層(sip_proxy) 原型開發完後，總結了下開發，使用時碰到的各種問題：1. command的裝置控制設計，是以裝置的動作為目標，如下test裝置類型的中繼資料定義

<device type="test_plugin"><method name="test1"><param name="a" type="int" direction="IN"/><param name="b" type="string" direction="IN"/><param name="c" type="float" direction="OUT"/><param name="d" type="string" direction="OUT"/></method></device>

 

如果加入裝置propery屬性，可以很好的契合下個階段command的協議採用http的restful風格，以裝置資源屬性為目標，簡單通過set, get來實現對裝置的操作（當然正如不是所有的web服務都能完美的採用restful, 裝置控制操作可以採用屬性，動作均定義的方式）。 2. 正如上面描述到的，我考慮command的協議採用http，在gateway使用web服務方式，client端就採用hybrid方式，即避免command的client, server更新問題，又使用原生來避免web的不足，目前已經在調研中。 3. 設計一個的iot_cloud原型，暫訂功能主要為方便使用者遠端管理裝置，以及儲存使用者裝置資料，及簡單的資料分析。 

物聯網 command 原型設計及架構