摘要除了把全新的設備和系統的概念進入市場，考慮到“東西”完全是一種模糊的、不限制的話，物聯網需要正常的互操作性、集成和緊密相關的工件在解體，鬆散的耦合的能力。當存在鬆散定時約束的已知實體之間的耦合時，這是很好的。對於工業4所需的實時嵌入式系統來說，這個問題是完全不同的。本文回顧了將實時嵌入元素耦合在一起的問題，並將這些問題擴展到通過Internet耦合它們。方案，如MQTT，Python的扭曲的引擎，Jini(現在的Apache河)，Node.js，和PBOs的分類和優缺點都暴露的目標，推動開放標準的發展和管理機構。
介紹
如果互聯網使設備能夠很容易地使用一種成熟的通信標準進行通信，如果這個標準是工業4和物聯網的先驅，那麼爲什麼我們不能通過一個人的專有云解決方案把一個物聯網設備綁在另一個設備上呢?雖然我們可以連接任何藍牙爲基礎的鼠標到任何筆記本電腦，我想連接任何特性良好的物聯網設備到任何智能手機，而不使用專有的解決方案。鏈路的兩端都應該知道如何相互交談，即使設備處於不同的子網上或關閉相同的物理網絡，而不管使用的物理媒介——總的互操作性。我想起了通用遙控器。這個想法是，你可以更換所有的遙控器來與您的電視、音響、家庭影院、Blu ray等球員，一。問題是功能永遠都不對。事實上，唯一的東西是所有的人都使用紅外線發光二極管。這些遙控器存儲每個人的獨特的代碼。所有設備都可以使用相同的代碼是可行的。我們真的需要像電視製造商那樣增加“音量”或“一頻道”嗎?
這篇文章的動機是缺乏一個開放的和廣爲接受的標準和規範，說明基於TCP/IP的網絡上的物理終端設備如何相互作用，以促進一些更復雜的實時系統的組裝，可能是自組裝。我們的目標是開始發展，並強調機會、非專有的、開放的標準，任何人或任何團體，可以實現服務，允許來自多個廠商的設備互操作而不需要一個“封閉”的片。
在這篇文章發表的時間，文獻1認爲機會大爲物聯網產業公司(IIoT)。該報的作者聲稱，他們可以通過與其他公司合作，銷售更多的服務和產品，“使他們存儲和共享設備上的客戶數據更有價值。”。用相同的產品，他們可以爲客戶提供新的服務，從而擴大其客戶基礎。”文獻2中估計市場收入從整合、存儲、分析，並提出物聯網(IOT)數據”以57億美元2015美元!這聽起來像侵犯隱私和營銷富礦給我。換句話說，它是良好的業務保持關閉，暗示是這種器件的耦合需要處理的–不是你。如果我們什麼也不做，這將會發生。這個場景是我文章的對立面。這樣的服務存在是很好的，但他們不應該是唯一的選擇。蘋果和編織可以爲那些想讓他們管理細節的人提供解決方案，也有人需要這樣做，但是如果你更像一個Linux人，你可能希望有一個通用的開放標準可用。
本文調查採樣研究和框架上的各種技術來源廣泛。我選擇了在思考目標時吸引我的技術。還有比我在這裏所概述的要多得多的考慮。這只是其他人可以立足的一個開始。我的文章繼續解釋我認爲需要溝通和安全。然後，在我回顧一些接近的具體實現，但沒有我們需要的所有功能之前，我繼續研究實時系統所需要的內容。
通信需求
連接性、設備發現和網絡意識
互聯互通的問題不new3。開放系統互連模型(OSI)是在20世紀80年代初解決連通性問題的一項努力，它很好地服務了我們，但設備發現和網絡意識問題仍未解決。
計算機協會(ACM)對這個課題進行了大量的研究。應用程序將非常廣泛，包括從車載互聯網絡連接的存儲設備固定的一切。2012 ACM會議在赫爾辛基召開了霧networking5和普林斯頓大學演講積極參與其發展。名稱霧選擇包含雲的概念在地面–使更廣泛的、低水平的連通性。這項研究，以及軟件定義網絡(SDN)6，很可能會產生我們最終將使用的框架，但是，雖然理論基礎正在開發中，專有的解決方案繼續引入市場。什麼是可用的實用主義者?
通用串行總線(USB)作爲靈感來解決發現和意識問題。爲此，部分，由特定的“類”devices7美德。這使得幾乎任何設備都可以輕鬆地連接到幾乎所有主機。一旦定義了設備，它的基本功能就可以爲任何平臺的開發而開發。
usb主機充當設備協調器的角色。IIoT服務的雲服務，本質上是隱含在像主機，但需要主機有問題。它迫使USB實施者論壇，公司最終推出的USB On-The-Go讓USB設備”都與USB外圍設備和直接與對方溝通時，電腦不可用“8。我們需要相同的東西的物聯網：聯動設備或設備直接或設備到設備通過主機或兩者。
安全
物聯網安全的問題和解決方案很容易被忽視。高級加密標準(AES)128是最流行的解決方案。有理由相信任何嚴肅的部署將需要加密的IIoT。想象一下，一個物聯網設備被一箇中間人無意中或惡意攻擊的工廠。由於物聯網設備將使無線連接(如藍牙、Wi-Fi、蜂窩調制解調器、LoRa)、加密和認證必須是新標準的一部分。參考文獻9暴露了一些問題。
實時需求
斯圖爾特描述了嵌入式實時系統的需求。業4的IIoT如果他們要控制我們的機器和工廠都需要一定的實時性能。
斯圖爾特等人創建了一個支持基於組件的軟件的框架，這種抽象稱爲基於端口的對象(PBO)11。他們的目標是創建可重用的實時軟件組件。物聯網設備也可以被認爲是可重用的軟件組件。如果我們把斯圖爾特的接口概念應用到物聯網，我們就有了一個框架，在這個框架中可以創建一個網絡物理系統(CPS)。由於PBO的概念已經成熟，可以通過研究它的採用和它的原因來學習它。這個概念的核心是解決實時性能的需要。以下是斯圖爾特框架地址的條件。
獨立的過程
斯圖爾特認爲在嵌入式實時系統包含有一個需要在比較高的頻率的數據量相對較小的份額，獨立的過程。這些頻率肯定比互聯網所能處理的要高。雖然今天的互聯網的比特率是每秒數百兆，有效載荷的大小和握手的要求使互聯網在最現代的、基於嵌入式實時系統的通信是不切實際的。實時物聯網設備的通信密度將受到損害。或許可以將多個進程的通信有效負載捆綁起來，以提高有效負載效率，並最小化傳輸實例的數量。
TCP/IP通信的處理負擔通常迫使應用程序(只需要8位主機處理器)進入32位解決方案。幸運的是，32位設備的成本低於0.50美元，中等數量，所以我希望物聯網設備包含32位內核。
獨立進程之間的綁定
這些獨立的過程必須結合在一起，以確定來自不同輸入的輸出值，並且可能需要一些輸出來處理其他輸出。斯圖爾特認爲這些綁定是有利的，可以在特定的時間限制內動態地重新配置和耦合在一起。例如，設備可以在線或被發現，能夠減少上游設備的通信負擔，從而動態斷開下游接收器，並將其重新連接到新的上游源。在我們的標準中解決這個問題是有益的。設備應該提供解析、緩衝、分發和重新分配數據的能力。這意味着除了定義分佈式設備類型外，我們還必須指定分佈式函數和角色。這些功能和角色可能被認爲是“虛擬”或“抽象”的物聯網設備。
當主機繁忙時，基於USB的初始開發工具出現了問題。他們沒有辦法強迫主機注意，結果是斷斷續續的，而且“不可靠”，只有當這些工具變得更智能(例如，更多的內存，更少的依賴於一個遠程CPU的及時性)，這個問題就減輕了。物聯網設備必須是智能的。
多個處理單元
在實時嵌入式系統中經常使用一個或多箇中央處理單元(CPU)來實現性能目標。這可以採取多微處理器、編程邏輯芯片或兩者的形式。應該有一個多對多的CPU連接到物聯網設備。
多個CPU之間的協調應該允許每個CPU獨立於其他CPU操作。與在現代PC機的CPU中處理線程一樣，每個可用的CPU可能有助於通過從原始數據中冷凝/提取信息來減少通信帶寬，或者它們可能提供某種程度的容錯性。無論應用程序如何，系統應容忍斯圖爾特引用的不同操作頻率和不同通信速率，從而支持多個CPU(節點)。
可用框架抽樣
我現在列出一些已經臭名昭著的框架，並有一些適用於我們目標的特性。我將解釋它們爲什麼被髮明並對它們的適合度發表評論。該調查由Jini，Node.js，扭曲，並與世博會的éMQTT的這端，我估計，成爲事實上的標準，封閉的實現。
Jini(現在的Apache河)12 13
尊敬的Jini被太陽在上世紀90年代後期開發和現在的Apache項目。它是基於java。它的開發是爲了讓模塊化服務通過網絡連接在一起，從而建立所謂的面向服務的體系結構。Jini的一個有趣的特點是它的網絡實體的能力(例如，服務)發現自己。這是通過一個集中的代理(查找服務)完成的，所有的客戶都是爲了瞭解其他的客戶而進行聯繫的。一旦發現，服務可以相互交互。據報道，查找服務不能很好地擴展到非常大的系統，並且考慮到物聯網，我們正在討論潛在的巨大系統。
有Jini的三個總體目標：(1)客戶不需要知道一個特定的服務的位置，(2)客戶不應該如果服務不可用或不可用時執行失敗，和(3)客戶和服務應在檢測故障的情況下，積極主動。這些都是我們標準的值得追求的目標。
由於Jini是基於java，它與嵌入式設備一定的遺產，作爲java是原來的設想，作爲一個平臺，專爲小，電子電器如機頂盒嵌入式系統。到目前爲止，那麼好，但是java是IT部門的語言。這不是一個小的嵌入式系統平臺的今天，除非這些系統的單板計算機(SBC)如BeagleBone Black和Raspberry Pi。儘管如此，對象意識和發現在我們的規範中是很好的特性，集中代理作爲可選組件的概念是一件很方便的事情。正如我所提到的，今天存在的封閉系統本質上是集中式的代理。我在這方面看到了價值，但只是作爲一種選擇。
node.js14
Node.js創建於2009允許Web服務器到客戶自己的協議。不錯，我們內嵌的物聯網設備可以被看作是很少的Web服務器，所以這可能適合我們的場景。
Node.js的網站說，“節點。JS®使用事件驅動的，非阻塞I/O模型，使得它重量輕，高效，完美的數據密集型實時應用在分佈式設備上運行。”這聽起來是一個完美的平臺。然而，Node.js是建立在Chrome的JavaScript運行時引擎，和“實時”就是在這樣的背景下網絡基於會話的–實時在我們的上下文中嵌入不同的。想想一個物聯網設備所需要的數據速率，它符合包裝機完成它們的週期。這些機器以每分鐘幾千的速度包裝貨物。Node.js並不支持，很多物聯網設備將需要實時性能水平。
此外，如果使用的話，物聯網設備至少需要一個JavaScript引擎。而JavaScript引擎通常是建立在Web服務器Apache，還有其他的選擇，如v815和tracemonkey16，但是他們沒有一個是已知的速度。這意味着Node.js是太臃腫，太高的水平用於物聯網設備。該平臺可對SBC或更好的是，PCs.是，Node.js不吸引我作爲我們標準的平臺。
twisted13
扭曲是用Python編寫的，用於開發Internet應用程序，特別是遊戲。它是一個事件驅動的網絡編程框架。開發人員編寫由框架調用的回調例程。它的創建是爲了讓遊戲開發者在遊戲中嵌入基於互聯網的通信。TCP和UDP服務以及接口的UNIX套接字模型是這個框架的核心。
由於它基於Python，所以它的一個優點是它的底層引擎Python引擎是用C語言寫成的。這是讓它工作在嵌入式設備的一大優勢，因爲幾乎所有的嵌入式設備在C cpython17發展主線的Python的引擎，但引擎如pymite18存在運行在只有64 KB的非易失性存儲器和4 KB RAM位裝置。這並不是說一個8位設備應該是物聯網設備的目標。上面提到的只是指出Python引擎有多緊。由於TCP/IP的負擔，預計物聯網設備將嵌入32位內核。扭曲看起來像是我們標準的一個有價值的框架。
Python也可以嵌入在產品的最終用戶提供一個內置的編程interface19。扭曲的看起來更好。可編程的物聯網設備現在可能是由最終用戶在Python中編程的。好的!
回調例程所扭曲的被稱爲“延遲”。這些都是異步的所有其他處理。這就需要一種不同的思維方式來進行實時處理。儘管高優先級任務通常被放在中斷服務例程中，異步回調需要考慮一些其他方法來中斷例程，如基於信號量的門控。最終結果可能只是接近實時性能——偶爾會錯過實時事件的條件。
在客戶機服務器連接的兩端或兩端執行扭曲。由於該機制可以使用TCP/IP服務套件發送任何信息，所以它仍然是一個很好的候選者。
但是，扭曲不包括USB樣式類定義。對於任何具有基於TCP/IP的接口的特定應用程序或產品來說，扭曲是很容易使用的，它需要一個設備綁定到應用程序的自定義代碼。扭曲需要一個設備類型的規範，如USB在前進，使衆所周知的設備可以摺疊到應用程序沒有新的發展。這必須存在於鏈路的兩端或兩端。
綠洲的消息隊列遙測傳輸(MQTT)20
MQTT是一個輕量級的，發佈/訂閱消息傳遞協議。它最初是由IBM和ARCOM創建但2014成爲綠洲的開放標準。綠洲的使命是推動全球信息通信的開放標準開發、融合和採用。
MQTT是描述爲非常簡單，重量輕，是專爲約束裝置和低帶寬，高延遲或不可靠的網絡。其目的是在不影響可靠性和保證消息傳遞的情況下最小化網絡帶寬和設備資源需求。它被吹捧爲物聯網的理想，它是受歡迎的。
作爲一個協議，它必須實現成爲一個完整的框架。Eclipse的泛美衛生組織項目是一個實現。它支持多種語言，包括MQTT的C / C++，java，JavaScript，和python21。大多數實現都面向客戶端，但服務器端實現也可用。
服務器是一個叫做“信息經紀人”在MQTT。不同的扭曲，即終端設備可以直接告訴對方，一般涉及這中間MQTT消息代理。
mosquitto MQTT的經紀人是一個Python實現，和Apache ActiveMQ是另一個。ActiveMQ是java綁定到其他語言。還有其他的信息經紀人，像RabbitMQ和ZeroMQ。許多其他的代理存在支持各種其他IT起源的協議。
如前所述，許多專有的物聯網解決方案是採摘MQTT消息。問題是缺乏什麼標準來溝通什麼是物聯網設備。存在的MQTT實現兼容的只有自己。協議允許消息通信，但只有那些爲這些消息創建的物聯網設備知道它們的含義。郵件是亂碼，可以使用任何其他設備的信息。扭曲的情況也是如此。這將是完美的使用MQTT作爲協議的扭曲，但需要有一個爲每個類型的物聯網功能的信息內容的標準。
其他研究和協議
在考慮協議和框架方面，確實有一個錯綜複雜的選擇;大多數是學術性的。智能維護系統中心在網絡物理系統(CPS)22領域非常活躍。Jay Lee博士是該中心的主任和領導發展的一個概念叫5C architecture23 24 25。5C代表連接、轉換、網絡、認知和配置。這是一個可以應用於我們的工作的通用框架，因爲目前部署了使用此方案的系統。
還有其他的協議在reference26。它提到高級消息隊列協議(AMQP)簡單/流面向文本的消息傳遞協議(跺腳)，還有流行的數據格式，如XML和JSON。有很多材料可以考慮，但同時，現在有足夠的標準和開發框架。
專有解決方案的例子
該酒吧是一個物聯網入門套件，是由康拉德，由中繼、設計和製作的mikroelektronika27創建。它包括用於感知光、溫度、加速度、紅外線、聲音、溼度等等的物聯網模塊。這些模塊依次通過藍牙連接與主模塊通信。主模塊沒有傳感器。它的工作是與中繼提供雲服務通過基於MQTT交流通信方案。從雲服務，用戶可以訪問他們的Android或基於iOS的智能手機或PC從這些模塊的數據，這是一個聰明的包和深思熟慮。不提供硬件，而提供同等的雲服務，但他們是不兼容的中繼。即使他們使用MQTT，它們不能互換。
該中繼雲軟件是閉源的，但主要的模塊的代碼應該是可用的開源嵌入式世界2015。當這種情況發生時，用戶應該能夠創建自己的雲解決方案。無論如何，問題仍然是沒有一個開放的平臺可以使用。任何定製解決方案都必須重寫現有功能，以適應自定義或打開的雲。
另一個解決方案，即將從adafruit28。在博客中宣佈說介紹，“在Adafruit，我們出售的所有這些神奇的成分，但我們找不到與他們在互聯網上的一個好方法。當然有很多偉大的服務有數據記錄，或與你的單片機通過網絡，但這些服務要麼太複雜的開始，也不是特別有趣。“我不能同意更多。
消費和一個易於操作的儀表盤顯示的實時數據是Adafruit提供的點。他們實施雙向互動通過RESTful API，和某種程度的MQTT的支持。該框架是建立Node.js(已提到)，露比在鐵軌上，PostgreSQL，Redis和Memcached。
在這裏，在Adafruit，是一家致力於開源公司。然而，他們不得不推出自己的解決方案，因爲一個尚未開放的解決方案。
爲物聯網開放解決方案工作的組織
物聯網的話題絕對是熱門話題。從2015消費電子展，Adafruit已經存檔us29觀看演講很有趣。三星承諾開放，聽起來不錯。
我提到的Reference1發表在這篇文章的時候。當我寫完這篇文章的時候，另一篇文章剛剛出版。這個最新的文章中提到的公司和組織形成聯盟，研究這一問題制定標準和協同opportunities30。
其中一個是東西聯盟”“互聯網(IoTC)。我提到的問題，即物聯網正在成爲一個營銷富礦，似乎是有根據的。他們的主頁上說：“魚類研究實驗室進行的研究項目主要集中在瞭解消費者的購買意向，使用模式和物聯網產品的認識。”在他們的網站上列出的組織很有錢，但我不認爲這會對行業用戶和IIoT設備4。IOTC是消費者集中的實體。
另一個組織是AllSeen alliance31引。儘管它的網站看起來像是一家營銷公司，但它對開發人員來說具有重要的技術內容。“AllJoyn”代碼框架是開源但只支持C，C++，C，和java語言。
這些實體激勵我預測沒有統一的物聯網標準。我懷疑會有一個IIoT和產業4。我把辯論留給知識分子，看是否應該如此。
結論
有很多技術，但沒有人把一個開放的集合在一起，滿足我們的需要。市場中存在的解決辦法是有限的、封閉的或爲特殊利益集團開發而設立的。此外，像業餘無線電愛好者一樣，這是一個能夠進行大量實驗以滿足基層標準需要的小組。我喜歡有競爭想法的想法，但我希望他們是開放的，而不是大企業贊助。
