簡介： 我們常說，物聯網平台的使命就是将實體世界映射到數字世界，而對于具體的一個物聯網裝置而言，要完成數字化的前提，首先是必須要能夠通過某種方式直接或者間接的“接入”到雲端。從“接入”這個視角去看，傳統的網際網路場景下，往往以app、web接入為主，app和浏覽器在接入上的實作一般都是比較标準的，相應的提供接入服務的雲端實作也就比較标準。而在物聯網世界中，情況就大不相同了，千奇百怪的裝置，特點各異的應用場景，組合出非常多樣化的接入需求，因而對于物聯網的接入層的實作也就提出了多樣化的挑戰。
一、物聯網裝置的接入特點
我們常說，物聯網平台的使命就是将實體世界映射到數字世界，而對于具體的一個物聯網裝置而言，要完成數字化的前提，首先是必須要能夠通過某種方式直接或者間接的“接入”到雲端。
從“接入”這個視角去看，傳統的網際網路場景下，往往以app、web接入為主，app和浏覽器在接入上的實作一般都是比較标準的，相應的提供接入服務的雲端實作也就比較标準。而在物聯網世界中，情況就大不相同了，千奇百怪的裝置，特點各異的應用場景，組合出非常多樣化的接入需求，因而對于物聯網的接入層的實作也就提出了多樣化的挑戰。
終端碎片化
物聯網裝置碎片化嚴重，這種碎片化展現在很多元度。比如說，有的邊緣網關是超高配置的實體機伺服器，而有的傳感裝置則計算、存儲和網絡流量資源都極其受限。有的裝置沒有通路公網的能力，必須要借助網關才能連接配接雲端。有的裝置對功耗的要求極高，發一條消息就要休眠下，有的工業場景的傳感器裝置則一天24小時極其高頻的大量上報點位資訊，等等。這些不同的形态特點，所帶來的需求和挑戰也是不同的。
場景多樣化
對于典型的邊緣網絡的場景，既需要邊緣網關對裝置進行本地控制（本地有拓撲結構，子裝置資料通過網關通道上雲），又需要裝置能夠在雲端進行獨立的數字模組化。具體到拓撲結構上，既有樹狀的結構，也有mesh網狀的結構，典型的如藍牙mesh網絡等。
協定多樣化
物聯網平台支援裝置通過MQTT、CoAP和HTTP等标準協定，直接和雲端通信，其他類型協定，如消防協定GB/T 26875.3-2011、Modbus、JT808等則暫不支援，事實上，平台側也不可能将市面上所有的物聯網協定都支援全了，隻能優先支援廣泛使用的标準協定。對于這些必須要私有協定和外部通信的裝置，也需要有一套标準的适配方案。
更新困難或者周期長
有很多客戶想将已有的裝置接入體系遷移到物聯網平台，但是他們的原有體系下，裝置沒有OTA的能力，不能進行固件更新，或者說雖然能夠進行OTA，但是成功率低或者更新周期很長。
二、要解決什麼問題？
場景一：子裝置如何上雲模組化
舉個例子，比如一個園區中的傳感器，傳感器本身隻采集資料，沒有連雲的能力，它就必須要通過一個邊緣的資料網關将采集到的資料上報到雲端。
要借助網關的通道将資料上傳，一個直覺的做法是，使用者可以自己定義一套協定，把子裝置的資料作為網關上報的封包的payload發送到雲端，同時使用者通過服務端訂閱去接收資料。
這種做法本身是可以行的通的，但是這樣做有兩個問題。第一，這個方案下，隻能僅僅将物聯網平台作為一個傳輸通道，無法為子裝置進行獨立的數字模組化。這樣子裝置就無法利用物聯網平台的能力，而對于使用者來說接入物聯網平台的價值就大大降低。第二，使用者的業務系統需要感覺網關和子裝置的拓撲，并且裝置側和業務側需要follow同一套業務協定。
舉個例子，如果使用者想從雲端對這個子裝置進行控制（典型的比如通過APP調用雲端接口進行裝置控制），消息下發也必須通過網關的通道，那麼使用者就需要将發給子裝置的下行指令，封裝在網關的實體通道中，然後網關側再對封包進行解析。這樣操作會比較複雜。而且實際上，IoT的整個生産流程往往是需要多環節協作的，邊緣網關可能是A廠商的，施工是B廠商的、傳感器是C廠商的、C端使用者使用的APP又是D廠商的，是以要求裝置側和業務側去follow同一套私有協定是比較難的。
這個問題歸結為，邊緣拓撲下的子裝置，如何既能複用網關的實體通道，又能以獨立身份映射到雲端進行數字模組化和控制？
場景二：非标準協定裝置如何遷移上雲
很多客戶在接入物聯網平台之前，往往自己的裝置已經有了一套資料采集的基礎設施，比如智能抄水電表的系統；而且這些裝置往往使用的是某種特定的行業協定，比如消防協定等等。這樣的客戶，既想使用物聯網平台的賦予裝置的數字化模組化分析能力，但又不希望對已有裝置程式和網絡設施有深度的侵入性改動。
換句話說，已有自建基礎設施的客戶存量裝置，或者非标準協定的裝置，如何低成本平滑的遷移上雲？
場景三：存量裝置如何能力更新
物聯網平台的誕生已經有3年多了，平台所提供的能力是在不斷演進和發展的，早期的物聯網套件時期，主要是提供的基礎的接入和消息流轉的能力，後來才逐漸有了物模型模組化的能力，有了資料分析能力等等。如果早期的客戶，他的裝置隻是使用平台的基礎能力，後面又希望使用平台的物模型等能力，但是前面我們已經提到過，物聯網裝置的特點就是OTA更新的難度往往比較大，甚至是沒有OTA能力。
也就是說，原來使用自定義資料格式的客戶，怎麼能夠不對裝置進行OTA的情況下，更新使用平台的新能力？
場景四：超大資料量上報支援
在某些場景下，邊緣側要采集的資料量非常的大，典型的比如智能工業場景，工廠裡每條産線上都有很多資料采集點位，這些點位每時每刻都在大量的上報資料，用于高精度的實時控制作業。一般來說工廠是通過邊緣網關将資料上雲的，那麼這個邊緣網關上報的資料量是非常大的，帶寬和qps都會有瓶頸，而且單個tcp通道也很難支撐。
那麼，對于邊緣超大資料量上報的場景，怎麼支援？
三、如何解決上述問題
連接配接方式與業務解耦
前面我們提到了由于物聯網接入場景的多樣性和産業鍊的複雜性，端側往往需要通過多種協定或者網關形态接入，而雲側業務未必能和端側保持同樣的私有協定，是以阿裡雲物聯網平台将連接配接方式與業務解耦，無論裝置是通過何種方式接入上來的，都轉換為統一的身份模型提供給業務層，對于業務層而言，隻需要對直接對具體裝置進行模組化和控制即可，不需要了解其接入方式。
具體到技術實作上，一方面通過協定與流轉分離屏蔽協定差異，另一方面在接入層通過拓撲映射和身份轉換，将網關子裝置的拓撲打平為統一的流轉身份，進而實作業務系統和端側接入方式的完全解耦。
泛化接入适配體系
對于存量裝置或者第三方協定的接入适配，物聯網平台提供了兩種方式，一種是在使用者側适配，在使用者側搭建泛化橋接伺服器，物聯網平台提供泛化sdk，包含了與雲端之間的上下行協定，使用者隻需要編寫自定義協定的轉換邏輯，并調用泛化sdk的相應接口，就可以完成第三方協定的上雲适配。不過這種方式，橋接伺服器部署在使用者側，使用者需要自行完成相關的資源部署和運維工作。
另外一種方式是在雲端适配，這種方式也稱為雲網關。具體說來，就是在雲端通過配置的方式直接生成标準資源，在雲端進行托管部署，省去使用者的資源配置和部署運維工作。雲網關目前支援電信NBIoT接入方式，後續會繼續完善其他三方協定，并支援動态協定插件等更靈活的形式。
腳本解析
随着平台能力的演進和使用者業務的發展，使用者的存量裝置不可避免有能力更新的需求，最典型的就是從自定義業務協定更新到标準的物模型格式。此外還有一種場景是裝置資源受限，隻能用原始二進制格式上傳，但是又想使用平台提供的物模型或者規則分析的能力等。
針對這種場景需求，物聯網平台在接入層提供腳本解析的能力，使用者可以針對某個産品配置相應的自定義腳本，當裝置資料上報上來的時候，經過某種規則比對到自定義腳本，通過腳本的執行将原始資料轉換成物模型資料或者其他json格式的資料，然後消息就可以以轉換後的格式進一步流轉。
通過腳本解析的方式，使用者就可以實作在不對裝置進行OTA改造的前提下，無縫遷移使用平台的物模型等高階能力。
封包聚合與通道壓縮
對于工業這種超大資料量上報的場景，普通的傳輸方式帶寬和qps都會出現瓶頸，物聯網平台針對大資料量上報的場景，提供了以下解決方案。
封包聚合：就是将多個裝置的資料，聚合在一個封包裡，這樣一方面可以減少封包的公共開銷，提高傳輸效率，更重要的是簡化了邊緣側的處理流程，邊緣側在機關時間内采集了多個不同點位的資料資訊，可以不拆分為不同裝置的資料，直接将資料聚合上報，大大提高了處理效率。
通道壓縮：就是對于傳輸封包在邊緣側進行壓縮，然後到雲端再對應進行解壓縮，這樣可以大大提高封包的傳輸效率，減少邊緣側的帶寬壓力。
此外對于這種場景，還可以結合物聯網平台的連接配接型執行個體，讓網關連接配接獨享接入資源，進而可以保障傳輸資源的穩定性。
通過以上方案組合使用，可以大大提高傳輸效率，減少帶寬占用和傳輸qps，穩定支撐大資料量場景的資料傳輸。
五、總結
本文列舉了物聯網接入的特點和挑戰，以及幾個典型場景的問題，介紹了阿裡雲物聯網平台是解決這些物聯網場景下的典型痛點問題的。在平台标準接入方式的基礎上，通過身份解耦、泛化接入、腳本解析、壓縮解壓等多種能力的組合，讓廣泛的各種存量裝置、受限裝置、複雜拓撲場景下的裝置都能具備連雲的能力，并針對存量裝置的遷移與能力更新、大資料量上報等典型場景提供了針對性的解決方案，讓不同場景、不同特性的裝置都能接入到物聯網平台，享受數字世界帶來的便利。
物聯網平台産品介紹詳情：https://www.aliyun.com/product/iot/iot_instc_public_cn