概述
嵌入式傳感器網絡是一種有前途的技術，它通過無線鏈接至家庭和工業自動化極大的改善我們的生活，比如農業中的作物健康監測以及傳感和驅動。 人們佩戴的健身追蹤器，工業恆溫器，智能門鎖只是物聯網的幾個例子 。儘管需要掌握傳感器，微控制器， 信號處理，聯網和編程語言，因此開發物聯網應用程序是艱巨的任務。 這些複雜的分布式系統中的許多共享3層 由嵌入式節點，網關組成的架構將嵌入式網絡連接到更廣泛的Internet 服務器或雲中的數據服務。物聯網應用分別為每個層的開發。所以， 開發人員需要合併這些獨特的應用程序 。
本文提出了一種新穎的編程方法， 使用分布式擴展擴展跨3層的應用程序 ：模型-視圖-控制器體系結構。我們添加新的原語： 一個空間-包含屬性和實現 特定層的 在這種架構下編寫應用程序可提供大量 優點：自動模型同步，數據傳輸， 和能源效率。
1.引言
物聯網（IoT）種類繁多 應用，從健身追蹤器到家庭自動化 農業中的健康監測，傳感和驅動 環境。這些超低功耗網絡橋接 通過網關連接到較大的Internet：手機或 運行嵌入式Linux的設備。後端服務器 雲存儲網關傳輸的數據並將其呈現給 用戶通過Web界面。 這些應用程序的一個子集跨三層運行 如圖1所示的設備：嵌入式，網關和雲。 每層都有不同的存儲，計算，能源資源 多樣的用戶界面（例如閃爍序列和點擊 在Fitbit或網頁上輸入）。一個或多個低功耗 嵌入式設備可以根據物理環境進行感知和激活。 這些設備可以是個人設備，也可以是移動設備（例如 智能手錶），共享和固定式（例如門鎖），或 兩者的某種混合。嵌入式傳感設備經常 面臨類似的挑戰和局限，包括 超低功耗運行，低占空比，感應， 驅動和低功耗個人區域無線協議 （802.15.4或藍牙）。 物聯網應用必須謹慎管理能源，應對延遲 網絡，在三種不同的處理器架構上運行 和三個不同的操作系統。改變一個 應用程序一部分中的小細節（例如數據值）需要將此更改傳播到許多在每個層上運行的語言和組件。 對此類傳感器網絡應用進行編程始終很難。雖然在操作系統、編程模型和低功耗嵌入式設備的聯網，這些進步 只是一個更大難題的一部分–物聯網編程由許多不同類型的設備組成的模型。 儘管做出了這些努力，但是每個層都是單獨開發的： 手動在不同模式之間轉換數據。我們 注意Model-View-Controller是一種軟體架構 在現代Web應用程序開發中占主導地位 框架，例如Rails，Django和Meteor。許多台式機應用程序也遵循這種架構（XEmacs： 使用相同的緩衝區同步多個窗口）。作為一個結果，MVC的抽象和方法得到了很好的理解 受到當今大多數開發商的歡迎。因此，我們如何進行物聯網應用開發像現代網絡一樣簡單？
本文介紹了Ravel，這是一個用於 物聯網應用遵循三層架構。一種 Ravel開發人員以單一語言編寫代碼（在我們的實現中， Python）跨系統的所有層。其應用程序是用Dist編寫的。
2.系統概述
Ravel應用程序是一組模型，視圖和控制器， 分布在不同的設備上。拉威爾的模型 定義應用程序收集，處理， 存儲並顯示給用戶。在Web框架中，模型是 通常綁定到特定的資料庫表：它們代表 模式和該模式的實例。拉威爾應用分布，因此一個模型有多個實例 跨越不同的空間；每個都有特定於空間的架構。 例如，嵌入式設備上的模型實例 在Android網關上以Cstruct形式表示為 類，並在後端作為表。每個實例 模型將具有獨特的存儲大小 空間。嵌入式設備，智慧型手機和後端 可能具有相同的心率模型。但是，每個 模型實例將僅存儲數據的子集 （例如，嵌入式設備當前的心率，移動設備 最後一小時，而服務器保留完整的歷史記錄）。 模型可以是持久的或易變的，並可以應用數據優化 （例如分配，緩存，壓縮）適當 限於嵌入式和網關設備的有限資源。 創建記錄的是模型的控制器， 將數據從內存中的緩衝區移動到閃存，應用數據優化， 在模式之間移動和轉換數據 空格。 模型和控制器與設備無關，但是 視圖是特定於空間的：淋浴傳感器的界面 帶有幾個LED的LED與手機的LED不同 或網絡應用程序。 Ravel提供統一的API來獲取 模型中的數據並將其傳遞給實現的模板 特定空間的視圖。 空格是一組規則，模板和代碼段 適用於特定平台（例如，Android手機，TinyOS 傳感器，一個Django服務器）。例如，TinyOS空間具有 有關nesC數據類型的信息（例如nx uint16 t）， 使用ActiveMessages，在任務中運行轉換並使用 TinyOS的存儲組件，用於耐用的型號。而是 而不是為每個層分別編寫代碼，Ravel開發人員 將相同的模型分配給空間並為其添加視圖。 每個空間規範都具有翻譯所需的全部邏輯 將應用程序代碼Ravel放入該特定代碼中 空間。對於某些空間，例如基於Python的Django，這 翻譯很簡單，因為實現了Ravel 在Python中，開發人員編寫的應用程序類似於 Django框架。對於更受限的環境， 例如TinyOS / nesC或Contiki，此翻譯的內容更多 複雜。 Ravel從空間模板生成代碼 和代碼段：通過將數據類型從內部映射到 特定的空間類型，並使用它來創建緩衝區， 通信例程，初始化主要功能。
2.1節水應用
為了將上述概念作為具體示例，我們 開發傳感器網絡應用程序。該應用程序的目標 是收集關於學生生活的細粒度用水數據 在一個大宿舍里。目前，大學只知道 整個建築物每天要消耗多少水。不帶 細粒度的數據，很難制定政策來減少 用水（鑒於加利福尼亞州 嚴重乾旱）。 我們在牆壁上的水管之間安裝一個傳感器 以及用於監控水流和溫度的固定裝置 宿舍的淋浴和水槽。傳感器有 通過收集能量充電的可充電電池 使用小型渦輪機從水流中吸收。傳感器裝置 使用藍牙低功耗（BLE）進行通信 智慧型手機網關（Android和iOS）。當。。。的時候 網關靠近傳感器，智慧型手機上的應用程序 連接到傳感器並向其請求數據。的 網關存儲此數據並將其異步發送到 在雲端運行的python-service（Django）。傳感器 加密僅在雲上解密的數據。感測器 保留記錄，直到他們收到端到端的確認 從雲端。
3.使用RAVEL進行編程
圖2顯示了Ravel原語中的Water Sensing Application。 主數據流（以藍色顯示）來自兩個 圖2：跨越三層eMbededGateway-Cloud的應用程序 Ravel原語中表示的體系結構。 源（溫度和流量傳感器）到水槽（ 雲與資料庫）通過Measurement模型。我們傑出 源和匯模型的符號，因為它們 是特定於空間的（它們代表特定的硬體或 軟體），並且無法移動。例如源模型 溫度是嵌入式設備上的傳感器。因此， 將其移動到網關將導致完全不同 模型。 衡量模型分布在所有三個層次上， 因此Ravel將初始化所需的存儲和通信 鏈接以在空間之間同步數據。綠流 顯示帶有視圖的“平均溫度”模型；拉威爾創造 該模型來自網關中的Measurement模型 空間。因為平均溫度只有一個空間，所以 不需要同步。 當開發人員運行Ravel的build命令時， 編譯器將為每個層生成靜態代碼： 緩衝，存儲和通信協議。 生成的靜態代碼可以進行編輯或直接編譯 並部署。結果應用程序將讀取傳感器， 將數據傳輸到網關，顯示平均值並 將測量結果轉發到雲進行存儲。
3.1型號
本質上，每個Ravel模型都是一組欄位，它們表示 數據。我們使用元編程來覆蓋標準 類初始化並為系統添加必要的欄位 元信息，類簽名和便利功能。 例如，每個模型將獲得自動欄位，例如 作為節點ID，時間戳，序列號。分布式 模型可以是盡力而為的，也可以是可靠的。在可靠 情況下，模型同步來自嵌入式空間的數據 到雲空間的記錄不會刪除，直到它收到 來自雲的端到端確認。 這些欄位由Ravel的數據類型（例如 編譯器映射的Integer，Float，TimeStamp等） 到每個空間中使用的類型。例如，如果我們決定 將傳感器讀數表示為uint32 t而不是uint16 t 更改只需要在一個地方執行– Ravel 會將這一更改傳播到所有三個層。這樣的方法 當模型跨越多個時非常有用 空格：不必為每個空格重新定義架構 設備和系統，開發人員只需維護 一個規範。此外，整體數據類型可以防止 安全漏洞的最常見原因之一： 錯誤的類型轉換[12]。 Ravel自動在之間同步模型實例 網絡可用時的空格。在此之前，記錄是 根據定義存儲在內存或閃存中 耐用性。因為在任何情況下都可能發生模型更改 在斷開連接的情況下，框架強制執行 定向數據流：出現在流中較早的記錄是 同步到以後的模型，反之亦然。 Ravel模型支持不同的數據持久性要求 在同一設備中的應用程序和模型之間 層。標準模式是持久的，可持久存儲數據 輕量模式僅保留RAM緩衝區時閃爍。 在後一種模式下，數據可能會因系統重新引導而丟失或 緩衝區溢出。
3.2視圖和控制器
視圖提供了一個外部接口（GUI，JSON） 從一個或多個模型得出的一組記錄。查看規格 功能僅是特定於設備（因此是空間）的。上 iOS網關，該接口可能是本機應用程序； 在雲中，它可能是網頁或JSON數據； 在嵌入式設備上，它可能是小的LED或LCD。 因此，視圖是特定於設備的組件 在拉威爾。該框架提供了一組乾淨的接口 將數據轉換為本地表示以供輸入 一個看法。 控制器響應來自其他控制器的推送 接口請求（例如顯示記錄）。他們讀 並修改其模型並調用視圖。拉威爾控制器 通過跨空間發送數據來擴展標準MVC；控制器 通常不修改或計算數據，因為這是 由模型完成。開發人員可以靈活地指定 選項，例如值更新時間，傳感器讀取間隔， 超時。 Ravel將控制器生成為一系列定時器，並且 中斷處理程序。例如溫度傳感器 將定期讀取，但數據傳輸將 取決於可用的連接。
3.3空間和模板
標線空間描述了屬性和技術細節 底層設備。從技術上講，一個空間包含 文件，函數，Makefile和包含模板以及 軟體組件。 Ravel使用模板和軟體 組裝控制器，模型和視圖的組件 將它們映射到特定的基礎OS本機類型 語言。在內部，Ravel使用 太空編程專用的數據類型和結構 系統。例如，溫度模型組件將 包含初始化功能，包括，構建和鏈接 依賴性。也是讀取傳感器並寫入的控制器 量度–在我們的示例中為模型。 Ravel使用類似於流行的模板方法 現代網絡框架。減少運行時開銷 Ravel會在部署之前生成靜態代碼，從而允許 手動檢查和修改代碼。
嵌入式傳感器網絡是一種有前途的技術，它通過無線鏈接至家庭和工業自動化極大的改善我們的生活，比如農業中的作物健康監測以及傳感和驅動。 人們佩戴的健身追蹤器，工業恆溫器，智能門鎖只是物聯網的幾個例子 。儘管需要掌握傳感器，微控制器， 信號處理，聯網和編程語言，因此開發物聯網應用程序是艱巨的任務。 這些複雜的分布式系統中的許多共享3層 由嵌入式節點，網關組成的架構將嵌入式網絡連接到更廣泛的Internet 服務器或雲中的數據服務。物聯網應用分別為每個層的開發。所以， 開發人員需要合併這些獨特的應用程序 。
本文提出了一種新穎的編程方法， 使用分布式擴展擴展跨3層的應用程序 ：模型-視圖-控制器體系結構。我們添加新的原語： 一個空間-包含屬性和實現 特定層的 在這種架構下編寫應用程序可提供大量 優點：自動模型同步，數據傳輸， 和能源效率。
1.引言
物聯網（IoT）種類繁多 應用，從健身追蹤器到家庭自動化 農業中的健康監測，傳感和驅動 環境。這些超低功耗網絡橋接 通過網關連接到較大的Internet：手機或 運行嵌入式Linux的設備。後端服務器 雲存儲網關傳輸的數據並將其呈現給 用戶通過Web界面。 這些應用程序的一個子集跨三層運行 如圖1所示的設備：嵌入式，網關和雲。 每層都有不同的存儲，計算，能源資源 多樣的用戶界面（例如閃爍序列和點擊 在Fitbit或網頁上輸入）。一個或多個低功耗 嵌入式設備可以根據物理環境進行感知和激活。 這些設備可以是個人設備，也可以是移動設備（例如 智能手錶），共享和固定式（例如門鎖），或 兩者的某種混合。嵌入式傳感設備經常 面臨類似的挑戰和局限，包括 超低功耗運行，低占空比，感應， 驅動和低功耗個人區域無線協議 （802.15.4或藍牙）。 物聯網應用必須謹慎管理能源，應對延遲 網絡，在三種不同的處理器架構上運行 和三個不同的操作系統。改變一個 應用程序一部分中的小細節（例如數據值）需要將此更改傳播到許多在每個層上運行的語言和組件。 對此類傳感器網絡應用進行編程始終很難。雖然在操作系統、編程模型和低功耗嵌入式設備的聯網，這些進步 只是一個更大難題的一部分–物聯網編程由許多不同類型的設備組成的模型。 儘管做出了這些努力，但是每個層都是單獨開發的： 手動在不同模式之間轉換數據。我們 注意Model-View-Controller是一種軟體架構 在現代Web應用程序開發中占主導地位 框架，例如Rails，Django和Meteor。許多台式機應用程序也遵循這種架構（XEmacs： 使用相同的緩衝區同步多個窗口）。作為一個結果，MVC的抽象和方法得到了很好的理解 受到當今大多數開發商的歡迎。因此，我們如何進行物聯網應用開發像現代網絡一樣簡單？
本文介紹了Ravel，這是一個用於 物聯網應用遵循三層架構。一種 Ravel開發人員以單一語言編寫代碼（在我們的實現中， Python）跨系統的所有層。其應用程序是用Dist編寫的。
2.系統概述
Ravel應用程序是一組模型，視圖和控制器， 分布在不同的設備上。拉威爾的模型 定義應用程序收集，處理， 存儲並顯示給用戶。在Web框架中，模型是 通常綁定到特定的資料庫表：它們代表 模式和該模式的實例。拉威爾應用分布，因此一個模型有多個實例 跨越不同的空間；每個都有特定於空間的架構。 例如，嵌入式設備上的模型實例 在Android網關上以Cstruct形式表示為 類，並在後端作為表。每個實例 模型將具有獨特的存儲大小 空間。嵌入式設備，智慧型手機和後端 可能具有相同的心率模型。但是，每個 模型實例將僅存儲數據的子集 （例如，嵌入式設備當前的心率，移動設備 最後一小時，而服務器保留完整的歷史記錄）。 模型可以是持久的或易變的，並可以應用數據優化 （例如分配，緩存，壓縮）適當 限於嵌入式和網關設備的有限資源。 創建記錄的是模型的控制器， 將數據從內存中的緩衝區移動到閃存，應用數據優化， 在模式之間移動和轉換數據 空格。 模型和控制器與設備無關，但是 視圖是特定於空間的：淋浴傳感器的界面 帶有幾個LED的LED與手機的LED不同 或網絡應用程序。 Ravel提供統一的API來獲取 模型中的數據並將其傳遞給實現的模板 特定空間的視圖。 空格是一組規則，模板和代碼段 適用於特定平台（例如，Android手機，TinyOS 傳感器，一個Django服務器）。例如，TinyOS空間具有 有關nesC數據類型的信息（例如nx uint16 t）， 使用ActiveMessages，在任務中運行轉換並使用 TinyOS的存儲組件，用於耐用的型號。而是 而不是為每個層分別編寫代碼，Ravel開發人員 將相同的模型分配給空間並為其添加視圖。 每個空間規範都具有翻譯所需的全部邏輯 將應用程序代碼Ravel放入該特定代碼中 空間。對於某些空間，例如基於Python的Django，這 翻譯很簡單，因為實現了Ravel 在Python中，開發人員編寫的應用程序類似於 Django框架。對於更受限的環境， 例如TinyOS / nesC或Contiki，此翻譯的內容更多 複雜。 Ravel從空間模板生成代碼 和代碼段：通過將數據類型從內部映射到 特定的空間類型，並使用它來創建緩衝區， 通信例程，初始化主要功能。
2.1節水應用
為了將上述概念作為具體示例，我們 開發傳感器網絡應用程序。該應用程序的目標 是收集關於學生生活的細粒度用水數據 在一個大宿舍里。目前，大學只知道 整個建築物每天要消耗多少水。不帶 細粒度的數據，很難制定政策來減少 用水（鑒於加利福尼亞州 嚴重乾旱）。 我們在牆壁上的水管之間安裝一個傳感器 以及用於監控水流和溫度的固定裝置 宿舍的淋浴和水槽。傳感器有 通過收集能量充電的可充電電池 使用小型渦輪機從水流中吸收。傳感器裝置 使用藍牙低功耗（BLE）進行通信 智慧型手機網關（Android和iOS）。當。。。的時候 網關靠近傳感器，智慧型手機上的應用程序 連接到傳感器並向其請求數據。的 網關存儲此數據並將其異步發送到 在雲端運行的python-service（Django）。傳感器 加密僅在雲上解密的數據。感測器 保留記錄，直到他們收到端到端的確認 從雲端。
3.使用RAVEL進行編程
圖2顯示了Ravel原語中的Water Sensing Application。 主數據流（以藍色顯示）來自兩個 圖2：跨越三層eMbededGateway-Cloud的應用程序 Ravel原語中表示的體系結構。 源（溫度和流量傳感器）到水槽（ 雲與資料庫）通過Measurement模型。我們傑出 源和匯模型的符號，因為它們 是特定於空間的（它們代表特定的硬體或 軟體），並且無法移動。例如源模型 溫度是嵌入式設備上的傳感器。因此， 將其移動到網關將導致完全不同 模型。 衡量模型分布在所有三個層次上， 因此Ravel將初始化所需的存儲和通信 鏈接以在空間之間同步數據。綠流 顯示帶有視圖的“平均溫度”模型；拉威爾創造 該模型來自網關中的Measurement模型 空間。因為平均溫度只有一個空間，所以 不需要同步。 當開發人員運行Ravel的build命令時， 編譯器將為每個層生成靜態代碼： 緩衝，存儲和通信協議。 生成的靜態代碼可以進行編輯或直接編譯 並部署。結果應用程序將讀取傳感器， 將數據傳輸到網關，顯示平均值並 將測量結果轉發到雲進行存儲。
3.1型號
本質上，每個Ravel模型都是一組欄位，它們表示 數據。我們使用元編程來覆蓋標準 類初始化並為系統添加必要的欄位 元信息，類簽名和便利功能。 例如，每個模型將獲得自動欄位，例如 作為節點ID，時間戳，序列號。分布式 模型可以是盡力而為的，也可以是可靠的。在可靠 情況下，模型同步來自嵌入式空間的數據 到雲空間的記錄不會刪除，直到它收到 來自雲的端到端確認。 這些欄位由Ravel的數據類型（例如 編譯器映射的Integer，Float，TimeStamp等） 到每個空間中使用的類型。例如，如果我們決定 將傳感器讀數表示為uint32 t而不是uint16 t 更改只需要在一個地方執行– Ravel 會將這一更改傳播到所有三個層。這樣的方法 當模型跨越多個時非常有用 空格：不必為每個空格重新定義架構 設備和系統，開發人員只需維護 一個規範。此外，整體數據類型可以防止 安全漏洞的最常見原因之一： 錯誤的類型轉換[12]。 Ravel自動在之間同步模型實例 網絡可用時的空格。在此之前，記錄是 根據定義存儲在內存或閃存中 耐用性。因為在任何情況下都可能發生模型更改 在斷開連接的情況下，框架強制執行 定向數據流：出現在流中較早的記錄是 同步到以後的模型，反之亦然。 Ravel模型支持不同的數據持久性要求 在同一設備中的應用程序和模型之間 層。標準模式是持久的，可持久存儲數據 輕量模式僅保留RAM緩衝區時閃爍。 在後一種模式下，數據可能會因系統重新引導而丟失或 緩衝區溢出。
3.2視圖和控制器
視圖提供了一個外部接口（GUI，JSON） 從一個或多個模型得出的一組記錄。查看規格 功能僅是特定於設備（因此是空間）的。上 iOS網關，該接口可能是本機應用程序； 在雲中，它可能是網頁或JSON數據； 在嵌入式設備上，它可能是小的LED或LCD。 因此，視圖是特定於設備的組件 在拉威爾。該框架提供了一組乾淨的接口 將數據轉換為本地表示以供輸入 一個看法。 控制器響應來自其他控制器的推送 接口請求（例如顯示記錄）。他們讀 並修改其模型並調用視圖。拉威爾控制器 通過跨空間發送數據來擴展標準MVC；控制器 通常不修改或計算數據，因為這是 由模型完成。開發人員可以靈活地指定 選項，例如值更新時間，傳感器讀取間隔， 超時。 Ravel將控制器生成為一系列定時器，並且 中斷處理程序。例如溫度傳感器 將定期讀取，但數據傳輸將 取決於可用的連接。
3.3空間和模板
標線空間描述了屬性和技術細節 底層設備。從技術上講，一個空間包含 文件，函數，Makefile和包含模板以及 軟體組件。 Ravel使用模板和軟體 組裝控制器，模型和視圖的組件 將它們映射到特定的基礎OS本機類型 語言。在內部，Ravel使用 太空編程專用的數據類型和結構 系統。例如，溫度模型組件將 包含初始化功能，包括，構建和鏈接 依賴性。也是讀取傳感器並寫入的控制器 量度–在我們的示例中為模型。 Ravel使用類似於流行的模板方法 現代網絡框架。減少運行時開銷 Ravel會在部署之前生成靜態代碼，從而允許 手動檢查和修改代碼。
4.評估
本節介紹Ravel評估。
首先，我們檢查 在分布式系統中開發物聯網應用的潛在好處 數據流體系結構中的模型-視圖-控制器。
其次，使用前面描述的節水應用程序 例如，我們比較所需的工作量 （代碼行，LoC）來實現傳感器應用程序 使用Ravel在C中手動轉換為用Python編寫的代碼。 一個由4名博士組成的團隊學生，一名本科生和一名 博士後研究員通過 六個月的時間裡，遇到了許多工程挑戰 正在進行中。例如，Android和iOS具有 完全不同的藍牙接口（和編程語言）， 強制完全獨立的網關實現。 系統每個組件的開發人員必須 決定數據表示形式並橋接這些表示形式 跨編程語言和體系結構：C 到Swift，從C到Java，從Swift到Python以及從Java到Python。 在設備之間移動功能（壓縮或加密） 需要全新的，單獨的實現， 更改數據處理的位置需要新的 數據格式以及封送處理代碼。結果，早期 有關如何分發應用程序的設計決策 跨設備有效地固定在石頭上，阻止了我們 在部署之前進行一些所需的更改。
4.1單一數據模型的好處 。
一個跨越所有三層的單一數據模型是很有幫助。在我們的示例應用程序中，數據為 ：
（1）從傳感器讀取為uint32t，
（2）存儲在緩衝區中（作為 C-包含時間戳uint32t的結構，序列號 和節點ID均為uint16t），
（3）已移至持久介質 （閃）。建立可用連接後，將從中讀取記錄 閃存驅動器，
（4）已轉換為與無線電兼容的緩衝區 （uint8t字節數組）並傳輸。當網關 接收數據（uint8t字節數組），應用程序
（5） 將字節數組轉換為預期的數據類型（兩個uint32t和 兩個uint16t以正確的順序解開）。存放在
（6）類型化類，
（7）寫入持久性存儲。最後， 數據被發送到後端服務器
（8）；在哪兒 從text / JSON轉換為適當的類型
（9）並存儲 在資料庫欄位中
（10）。 在Ravel中將數據類型從16位更改為32位 只需一行代碼即可實現。手動操作 需要在三個不同的設備上的十個不同位置進行更改， 用三種不同的編程語言描述 以上。
此外，此類更改可能需要拆分數據 嵌入式設備上的數據包（由於無線電受限） 郵件大小），這會使可靠的同步複雜化 進一步。 Ravel的另一個顯著優勢是可以定義 有效範圍或數據檢查：檢查之間的溫度 0和100C，否則發出警報。或者，監視不變量 數據必須滿足：驗證電池電量百分比已增加 當水流活躍時。進行此類健全性檢查並 將測試代碼添加到所有非Ravel實現中 三層手動（通過黑客攻擊）導致了許多錯誤，因為 系統的各個部分正在分別發展。在Ravel中，這是 自動化，不需要額外的努力，從而導致 一個不僅使開發人員更容易理解的系統， 而且還可以調試，維護和檢測錯誤。
4.2模型同步和耐久性 傳統的傳感器應用通常會定期流 數據到永久網關。因此，存儲數據值 設備上的選件是可選的，從而簡化了應用程序。 在我們的方案中，我們遇到了兩個挑戰 方法：首先，BLE設備的通信很短 範圍，因此在每個淋浴間部署網關會增加 成本。其次，將這些網關連接到電氣 出口需要特殊的外殼和電子認證 在潮濕的環境中，這會使部署更加昂貴 而且複雜。因此，我們決定進行眾包 應用程序O1 O3 Os Ravel LoC（C） 手寫20308 21936 17180-1025 拉威爾13100 13328 10300 80 1201 表1：使用Ravel作為節水應用程序的大小 以及手寫實現，均以字節為單位 編譯的代碼和源代碼行。 需要持久模型的數據收集及其同步。 Ravel模型具有可選的元類參數，該參數允許 指定同步和持久性的詳細信息。 啟用耐久性標記將自動初始化閃存 在嵌入式設備上，將數據存儲在那裡並讀取以進行傳輸。 例如，在網關上，它將創建一個 資料庫（例如Android上的SQLite）。已啟用同步 產生必要的緩衝區和控制器以 將數據從嵌入式設備移動到網關 並進一步發展到雲端。例如，平均溫度 模型僅存儲在網關上以將其存儲在雲中 開發人員需要在 雲和通信處理程序。強大且可擴展 實施將需要數十到數百行 Python，Java或C / C ++，而inRavel就足夠了 只有一個。
4.3完整申請 在我們的比較中，Ravel開發人員需要編寫 整個應用程序的80行代碼。結果 在為嵌入式設備生成的1201行C代碼中， 適用於Android的2393（1470 XML，908 Java和15 IDL），以及 136適用於Django的Python。比手寫的少 版本，但這種差異並不明顯：這主要是由於 Ravel如何分區功能並執行局部變量 初始化。 編譯時，Ravel版本使用的顯著減少 代碼空間比手寫的要大，即20308 B vs. 如表13中詳細說明的13100B。 1.差異使我們走了 令人驚訝-鑒於代碼行幾近相等，我們將 期望代碼大小相等。較大的代碼大小 手寫版本是因為其生成過程： 最終可執行文件中包含一些不必要的目標文件， 從該應用程序的先前版本遺留下來的。 一旦刪除這些和相同的編譯選項 手寫版本的代碼大致相等 大小到拉威爾之一。但是，這指向了好處- 適合使用框架，該框架可以自動最小化 不僅代碼，而且還可以智能地使用工具鏈 優化方式。拉威爾有助於避免許多常見錯誤 只有多年的實踐和經驗才能阻止。 值得注意的是，由於LoC，該評估是指示性的 作為主要指標。但是，很明顯， 在Ravel中開發應用程序要短得多。我們的 這種方法對於針對個人的應用更為可行 使用而不是關鍵任務的網絡物理系統。
5.相關工作
類似SQL的查詢接口可以進行數據檢索來自分布式傳感器網絡，就好像它是資料庫一樣。 單個查詢可以從資料庫中的多個節點檢索數據 網絡。用戶或應用程序從異構查詢數據 通過網關的傳感器網絡，在一個端點。例如，Cougar 添加了查詢代理 在應用程序運行時之上的圖層。的負擔 為應用程序的每一層編寫複雜的代碼： 節點，網關和後端系統–位於 開發人員。 宏編程不是發送查詢，而是專注於為節點組編寫高級應用程序。該範例隱藏了通信，存儲和運行時複雜性使開發人員可以專注於應用程序的 數據和邏輯。例如，EcoCast 是一個交互式面向對象的宏編程框架的開發人員編寫Python代碼，然後將其編譯為C 代碼並分發到節點。與類似SQL的方法類似， 這些系統假定特定的操作系統，庫 運行時在節點上可用。宏編程系統不能解決跨層編程問題： 開發人員必須手動編程和更改網關 和雲，確保數據架構兼容 節點應用程序更改後。 已經提出了許多系統來簡化開發 使用數據流，使開發人員能夠集中精力 關於數據模型和信息流而不是底層編程。這些方法允許用戶 指定對現有數據流的計算並處理 各種特定類型的流。例如，MISSA 實現了一種用於配置基於通用流的中間件 服務，而SPITFIRE 專注於啟用 從連接的傳感器訪問數據作為語義 網絡。但是，這些方法假設是二級開發商（誰根據 規範）或企業基礎架構的存在 並為每個層部署了代碼。 其他系統，例如SNACK ，提出了一種配置 語言，帶有用於開發的庫和編譯器 無線傳感器網絡。而不是創建一個 WuKong 的新語言使用基於流的編程熟悉的Java環境中的範例。開發商 從中的邏輯組件構造應用程序 悟空的圖書館，後來以 嵌入式Java VM的二進制可執行文件。 為了解決三層編程問題，示例允許 開發人員演示所需的身體互動 並將其綁定到結果操作。系統分析 傳感器跟蹤並分類不同的交互 （將頭向左或向右傾斜）。同樣，Fabryq 允許 開發人員編寫嵌入式網關雲應用程序 作為可交互的集中式Javascript應用程序 通過RPC功能與雲和嵌入式設備配合使用 電話。這些和許多其他技術使開發人員能夠 快速探索並製作MGC應用程序原型。然而它們缺乏可部署性：實施與 支持子集腳本語言的特定硬體。 同樣主要目標是原型設計。因此有無法將Exemplar或Fabryq原型過渡到 工作系統（對其進行縮放，移至其他硬體或添加 新的傳感器或執行器） 刮。 現有的編程範例具有一系列限制 物聯網。
首先：現有框架假設 通過中央始終連接的數據訪問數據（例如節點） 網關。
其次：他們要求數據 模式，通信協議，其他組件和 數據類型在體系結構的不同層中是靜態的。 例如，類似SQL的編程假定 系統輸出將具有正確且同質的數據類型 或者即使不重新編程也可以正確投射它們。
第三：新上傳的程序，腳本或 執行的查詢必須“標準化”，否則將需要 要重新編程的網關和雲，這是 這些系統未解決。
最後，這些系統 沒有滿足用戶交互的應用程序要求， 每個設備層的聯網和分布式功能： 嵌入式，網關和雲。 相反，Ravel解決了當前的限制。變化 在Ravel模型中，傳播給三個代碼中的每個代碼 層。 Ravel從每個模板的模板生成靜態代碼 架構中的層。
首先，這減少了對 特定的操作系統，庫或運行時。
其次，它允許 開發人員實施和使用任何現有系統，以及 其所需的功能。
最後，Ravel保留了收益 為三層體系結構開發單個應用程序的過程。
6.結論
本文介紹了Ravel，這是一種新穎的編程框架，允許開發人員明確編程3層架構與當今的Web應用程序非常相似， 通過模型，視圖和控制器。Ravel介紹概念空間，綁定特定的模型，控制器和視圖到特定的設備之間的網絡複雜性，設備被分布式模型隱藏，該模型會自動儘可能進行同步。 業內對整個嵌入式傳感器網絡進行編程高級語言已成為傳感器網絡的長期目標研究。Ravel的成長不容忽視，容許我們應該考慮更大範圍的編程，包括網關和雲幾乎是每個應用程序的一部分。
評論