隨著物聯網的大潮，無數的設備被安裝上WiFi模塊，接入到互聯網上。比如國內的家電巨頭海爾、美的、格力、海信等，已經在2014年推出了一系列帶WiFi的智能家電產品，包括空調、冰箱、洗衣機、熱水器、空氣凈化器、烤箱、電飯煲等等。等待了這么多年，智能家居終于開始成熟了。
相對于藍牙和ZigBee等其他無線網絡技術，WiFi最大的優勢是無需依賴手機或者其他中間設備，通過WiFi路由器，就能夠連接到互聯網上，直接與云服務器連接或者進行遠程控制。而且目前的WiFi模塊功耗和價格已經下降得很多，很容易被嵌入到各種物聯網設備中，無需過多的擔心成本和功耗。
但是，將WiFi模塊用在物聯網設備中，也有一個麻煩，就是WiFi的初始設置。要讓這些設備連接上WiFi路由器，需要首先讓它們知道WiFi路由器的名稱（SSID）和密碼。但是不同于傳統的PC或者手機，大多數物聯網設備沒有按鍵或者觸摸屏這樣的輸入接口，因此需要其他的方法將路由器的SSID和密碼告知物聯網設備。因為這些物聯網設備大多有與之配套的手機APP，問題也就變成了如何將SSID和密碼從手機APP傳送給這些設備。從目前已知的方法來看，主要有以下兩種。
第一種是基于WiFi模塊的SoftAP模式。在WiFi協議中，設備可以工作在AP模式，也可以工作在Station模式。比如WiFi路由器就是典型的AP，而手機和PC就是典型的Station。物聯網設備在絕大多數情況下都是工作Station模式，但是為了支持初始配置，許多WiFi模塊支持AP模式，當然，不是全功能的AP模式，只是有限的功能，所以稱之為SoftAP。利用SoftAP進行WiFi初始配置的流程如下：
使用這種方式的智能設備很多，比如小K智能開關，第一次啟動后會產生一個OK_SP3的熱點，完成配置后就沒有了。
在具體APP的實現中，需要考慮Android和iOS的不同。比如WiFi路由器SSID一般是不用用戶輸入的，APP會提供一個周圍熱點的SSID列表，用戶選擇即可。但是iOS是不支持在APP中做WiFi掃描的，因此需要設備端先掃描一個SSID列表發給手機，然后用戶在APP里面選擇。另外iOS是不支持在APP中切換WiFi連接的，因此用戶需要先手工連接到SoftAP，完成配置后，再切換回來。而Android中是可以的。Android的APP中可以先自動連接SoftAP，配置完成后，再自動切換到原來的AP，而用戶可能感覺不到這個過程，從而改善了用戶體驗。
第二種是基于WiFi模塊的Sniffer模式。基于SoftAP的方式可以保證配置成功，但是用戶體驗不太好。因為它要求手機先連接到SoftAP上，無論是手工的（iOS）還是自動的（Android），配置完成后再切換回來。在此期間，手機因為離開了原先的WiFi路由器，因此失去了與互聯網的連接。這個是許多用戶感覺不爽的地方。而Sniffer模式不同。使用這種配置方式，用戶手機不需要斷開與當前WiFi路由器的連接，從而可以保持與互聯網的連接。這也是這種方式經常被稱為智能配置的原因。這種方式要求WiFi模塊支持Sniffer模式，也就是雜收模式（Promiscuous）。對無線通信熟悉的人都知道，無線通信本質上是一種廣播。理論上，一個WiFi設備可以收到空氣中的所有包，只不過正常工作時，底層將不需要的包過濾掉了。打開雜收模式，就是將底層收到的所有包，直接提交給上層處理。這樣，雖然WiFi模塊與路由器和手機之間沒有連接，但是它可以監聽手機發出來的包，而手機APP也可以在這些包里面隱含配置信息，從而達到將配置信息傳送給WiFi模塊的目的。
手機發包時，是連接在WiFi路由器上的。如果WiFi路由器是加密的，比如WEP和WPA，那么WiFi模塊收到的包必然也是加密的，模塊無法直接獲得包里面的信息，那么手機與模塊之間怎么傳遞信息呢？這就要深入理解一下WiFi幀的結構。
?圖1，通用的WiFi幀結構
從上圖可以看出，WiFi幀包括幀頭，幀體和校驗和三部分。其中幀頭是不加密的，幀體部分根據幀類型的不同，有加密的，也有不加密的，比如管理幀ProbeRequest中的幀體部分就是不加密的。
另外，WiFi幀的長度也是很有用的信息。不管幀怎樣加密，對于一定的加密方式（WEP，CCMP，TKIP），加密后的幀長度總是原始數據長度加上一個固定的偏移。這樣手機APP就可以通過控制數據包長度的方式來傳遞有用信息。
總結起來，目前的智能配置一般有下面三種方式：
1， 第一種方式通過WiFi幀的長度傳遞信息。比如要傳遞一個字符串”abc”，三個字符a、b、c對應的ASCII分別是97、98、99。手機APP可以生成數據包，控制其長度為97、98、99加上固定的偏移量。這樣WiFi模塊捕獲到包之后，就可以根據包長度提取有用的信息了。目前微信的airkiss就是使用這樣的方式。京東的通用智能家居APP也是使用的這樣的方式。
2， 第二種方式通過WiFi幀的MAC地址傳遞信息。WiFi幀頭雖然是不加密的，但是它的內容都是底層WiFi驅動填寫的，而手機APP處于應用層，是無法控制其中的內容的，但是有一個例外。就是手機APP發送UDP組播包時，組播包的目的IP地址的后23位會映射到WiFi幀目的MAC地址后23位，這樣手機APP可以通過修改UDP包的組播地址，達到傳遞信息的目的。比如傳遞“abc”，可以發送3個組播包，目的地址分別是229.0.0.97，239.0.0.98，239.0.0.99。這樣WiFi模塊捕獲到包之后，就可以從MAC地址中提取到有用的信息了。比如海爾的U+智能設備就是采用這樣的方式。
3， 第三種方式是通過管理幀的幀體部分傳遞信息，一般使用ProbeRequest，因為它是手機APP可以在應用層控制的。手機APP可以在應用層構造一個目標SSID，啟動掃描。比如傳遞”abc”，可以讓手機掃描名為“abc”的目標SSID。WiFi模塊捕捉到這樣的掃描幀之后，就可以從中提取出有用的信息了。
當然，上面說的只是原理，真正實現的時候，有許多細節需要考慮。比如WiFi模塊并不知道手機在哪個WiFi信道上發包，要捕捉到手機發出的包，首先要鎖定信道。這就需要一些技巧。另外，安全性也是一個問題。因為手機要把WiFi路由器的密碼傳送給WiFi模塊，如果是明文的，很容易就被截取了，從而給WiFi網絡帶來極大的安全隱患，這就需要對數據做擾碼，這就需要八仙過海、各顯神通了。
另外，SoftAP和智能配置也不是完全互斥的。智能配置雖然方便，但是在WiFi環境很復雜的時候，還是有一定的失敗概率，而SoftAP是可以保證成功的。所以很多智能設備都是先用智能方式配置，如果失敗就切換到SoftAP，比如海爾的U+智能家居設備。
以阿里云和百度智能云物聯網平臺為例，進行了相關產品的功能梳理，這樣就可以從大的層面感知一下常規的物聯網平臺都有哪些功能。其中阿里云的物聯網平臺是【阿里云物聯網平臺】，百度的物聯網平臺主要是【IOT core】，以上產品我們在各自的官網都可以找到。下面簡單列舉一下兩個平臺的功能點：
從產品功能性和豐富程度上，阿里云的物聯網平臺感覺成熟很多，是將iaas層基礎設施、設備接入服務、消息通信服務、監控運維服務、安全服務、設備端以及服務端的開發SDK集成服務全部整合在一起了，而百度智能云IOT core功能相對單一些。下圖中加粗的黃色字體是阿里云比百度云物聯網平臺多出來的大的菜單，其他的菜單基本能對標上，但是細看還是有不少差別（感興趣的朋友可以自己去文檔中心了解下）。
下面以阿里云物聯網平臺為例，加上之前做的平臺功能，結合起來介紹一下，設備接入物聯網平臺，需要的最小化的功能和配置，也可以認為是B端產品中常說的MVP。
平臺提供的實例，作為設備接入和業務管理的底層資源，可以理解為服務器資源，只不過物聯網平臺的創建的企業實例會對物聯網這個場景更有針對性。
主要配置項包括：地域、同時在線設備數、可創建的設備數、消息上下行TPS（ TransactionPerSecond)、規則引擎TPS等等。
阿里云在創建的實例頁面做了相應的監控，若設備接入后實際運行起來，發現資源不夠出現了預警，也可以選擇升配操作；百度物聯網平臺實例創建只選擇了實例所在地域，沒有細化到支持的在線設備數以及按照消息數計費，可能創建的單個實例有一個默認的配置。
設備接入過程，可以簡單理解為將設備端與物聯網平臺側進行連接，進而可以完成數據采集，解析，消息通信，對設備狀態進行遠程監控運維。
主要配置項包括：創建產品、創建設備（對應一個設備端的產品，比如攝像頭）、創建物模型（定義設備的信息采集點，設備屬性）、創建云網關，關聯設備和物模型。阿里云物聯網平臺對設備進行了分類，所以有產品的概念，即同類設備集合為一個產品類型，并且根據業務的成熟度也抽象出來了一些標準產品類型，比如說智能城市，智能工業等等，這些標準產品中定義了可以通用的標準功能，在此基礎上可以添加自定義功能。
設備管理可以理解為對設備全生命周期的管理，包括添加、刪除、上線/下線、禁用/啟用；一切和設備相關的能力都可以在設備管理中提現。
主要配置項包括：設備基本信息（設備名稱、產品類型、所在地域、設備三元組、激活時間、上線時間等）；設備topic列表；設備物模型數據；設備指令下發（遠程控制設備）；設備日志；設備分組等。
設備端開發主要是為設備端提供接入物聯網平臺的能力，可以根據設備端支持的協議不同選擇不同的SDK開發工具包，阿里云也可以支持自定義SDK，自動生成完整的開發工具包。
主要配置項包括：設備OS、設備硬件形態（單板系統、mcu/soc通信模組）、連接物聯網平臺協議（MQTT\HTTPS\CoAP)、數據加密、設備認證方案，生成SDK后，由后端開發人員集成代碼包，查看設備上報數據情況。
以阿里云為例，還包括以下功能，感興趣的朋友可以去官網學習。
以上是設備完成物聯網平臺接入的基本功能，比較完善的平臺會在這個基礎上提供更豐富更便利的功能配置，可以讓PM甚至是客戶可以通過平臺側的簡單配置，就完成開發運維的相關工作，十分便利。
阿里云物聯網平臺產品架構圖
本文由@Sara Leu 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
聯網（IoT）系統設計領域面臨的挑戰之一是配置。隨著越來越多的設備制造商轉向云配置，他們發現平衡可伸縮性和安全性是一個嚴重的障礙。
本文探討了配置與物聯網之間的關系；回顧不同配置方法的優缺點；并評估配置的類型以及何時執行。
對于物聯網設備，配置設備連接到網絡和適當的應用程序。配置的三個基本步驟是：
1. 注冊：包括分配一個唯一標識，通常以X.509證書的形式，為設備分配一個唯一的公鑰和私鑰。
2. 配置：包括網絡設置、安全設置和安裝任何軟件更新等方面。
3. 部署：包括設備的物理安裝、通電、連接到網絡以及能夠與云通信的位置。
將物聯網設備安全連接到云端并擴展流程的能力已被證明是一項挑戰，特別是在尋求具有成本效益的解決方案時。為了更好地理解這些問題，需要回顧物聯網配置的類型，包括它們的優缺點。
以下是物聯網配置有三種基本方法：
手動配置需要將特定于設備的信息（例如，密鑰或唯一標識符）手動輸入系統。雖然這種方法適用于小批量設備，但對于大規模設備部署來說，它就成了一個問題。另一方面，它是一種非常簡單的方法，不需要復雜的基礎設施，并提供了對配置過程的高度控制。同時，它的可擴展性很差，而且很容易出現人為錯誤。
OTA配置，也稱為零接觸或自動配置，發生在設備首次連接到網絡時自動請求和下載其配置時。服務器通常由提供配置服務的公司所有，可以使用從云服務供應商租用的服務器空間。OTA配置具有高度可伸縮性，并且消除了與手動配置相關的人為錯誤問題。潛在的問題包括安全性，因為配置服務器可能成為在線攻擊的目標。
基于云的配置是OTA供應的一個子集，它專門使用云存儲服務，在本文中，它涉及結合了安全私鑰和證書的云識別服務。它提供了出色的可伸縮性（這對于大規模設備部署非常理想）和自動化，以及通過單個平臺管理所有設備的能力，該平臺具有管理和監視設備的工具。基于云的配置的潛在問題包括對互聯網連接的依賴，就像OTA配置一樣，潛在的安全挑戰。盡管如此，基于云的配置為大型部署提供了高效的可伸縮性，并且可能是三種方法中最安全的。
另一個與配置相關的因素涉及到何時執行供應：
工廠配置，也稱為預配置，發生在芯片制造過程中。雖然它允許設備在接入網絡后立即使用，但它缺乏靈活性，如果需要進行更改，可能會導致問題。
預部署配置提供了高級別的自定義，但是如果在部署之后進行更改，可能會出現重大問題。這種類型的配置可能很耗時，而且只適用于大規模部署。有利的一面是，它支持在部署前對物聯網設備進行全面測試。
部署后配置提供了部署前可用的一些定制，同時支持高度的靈活性。使用這種方法，安全漏洞可能在配置過程中成為一個問題。
部署后配置是最靈活和適應性最強的方法，適用于涉及定期更新安全性或功能的情況。這種類型的配置可能更復雜。
將證書分配給設備也是物聯網預配的重要組成部分。證書配置通常包括生成證書請求，將該請求提交給證書頒發機構，以及安裝已簽名的證書。
物聯網設備認證的一個重要方面是它如何提供身份驗證，以確保設備是它所聲稱的，從而防止網絡安全攻擊，如中間人、欺騙和假冒。它還支持設備與網絡其他部分之間的加密通信。最后，它支持可伸縮性、安全的設備管理和數據完整性。
使用預配置的證書從設備到云的典型方法非常漫長且復雜，難以大規模執行。
在這種方法中，訂購一批具有預發放證書的預發放安全芯片。一旦收到芯片，就必須在設備制造過程中提取每個芯片的證書。然后將所有證書記錄在與產品云兼容的清單文件中。接下來，必須手動將證書提供給產品云。最后，物聯網設備使用提供的證書連接到其產品云。
注意，這個過程需要從每個單獨的芯片中提取證書并創建一個兼容的清單文件，然后進行手動云配置。這些步驟中的每一步都有可能引入錯誤。這個過程也很難擴展，而且很耗時。
本文轉載自 雪獸軟件
更多精彩推薦請訪問 雪獸軟件官網