|
作者：梓 元節能
第一章 系統構架概述
對于這個構架，我們已經開發了3年，從最初的《校園節能》到《無線組網》再到《smart school》再到《smart OS》我們已經經歷了4個版本的變化了。在這4個版本里面，我們在不斷變換著自己的工作重心，試圖讓各種不同的設備相互通信。但是每一次都是在10個 設備左右就出現了各種奇葩的問題，導致我們的協議系統崩潰。無法讓各個設備之間進行兼容或者因為兼容的問題導致我們需要做大量的重發開發工作。這些看似簡 單的工作卻要消耗我們大量的時間來進行驗證作業。我們已經累了，真的不想為每一個設備因為要調用其他設備而獨立的進行開發了，所以我們開始了自己的內部的 標準化之路。
我們希望使用類似微軟的RDP（遠程桌面協議）來對各個設備進行訪問。當一個設備需要解讀其他的設備時，只需要你將需要接入的設備的RDP協 議加載到你的通信協議系統中，就可以完成對于該設備的加入操作。相關的調用過程你可以按照自己的思路來進行開發。我們希望讓自己的開發作業變得標準化，不 想為每一個設備都進行獨立的作業！這樣的效率實在太低下并且因為通用性的原因，讓我們為了讓一個系統可以穩定的動作而不等不做出各種各樣的讓步。導致系統 的設計遠離了我們的初衷。
為什么要有這樣的ML_network？
因為我們發現對于單品設備在這個地球上基本很難賣出了，你不可能要去用戶每購買一個智能設備就安裝一個APP！我們需要有集成方案，用戶可以使用一個APP就可以管理所有的設備。但是用戶不是流水線上的產品，有統一的需求。所有對于每一個用戶其使用基本都是定制開發。如果沒有一定規模的智能硬件可以相互通信，做定制開發玩搭積木的有效簡直就是胡扯！為了實現基本的類似IFTTT（if this than that 如果**就**），我們就需要在一個最基本的系統里面有一個傳感器 、執行器和控制器。這三者需要互聯！相互通信并且為了配置的方便我們希望有更多的設備可以相互接入。
如果只是單純的10個設備互聯，我們可以使用輪詢的方式實現，但是我們需要考慮未來的接入能力，我們希望我們的網絡是復雜的結構，我們想到了螞蟻算法，我們找到了一種高效而有簡單的方式來實現對整個網絡節點的管理，當然這個算法需要泡在32位的單片機上才不會顯得吃力。
如果有這樣一個ML_network 我們可以做什么？
我 們現在是一家關注與校園能源管理的公司，我們希望在公共能源管理上面有所為！為學校師生提供基于時間、人員密度、日照、溫度、課程計劃等多維度的能源管理 方案。當我們去做這些時，我們發現學校用戶并不是每一個都需要所有的設備的，他們可能需要裁剪，只是提取其中的某一部分來進行應用。實現比如：1、天黑有人開燈，人來燈亮；2、當人員數量超過X數值時，開啟全部照明，否則僅開啟一部分；3、當22點以后，請及時熄燈。如果教室內有人則提示請及時離開。
通過在教室內布置不同的傳感器和執行器，我們有理由實現用戶的各種需求并為他們提供長久的能源管理服務。我們需要對我們的設備能源管理邏輯的本身進行監管，以提高我們的利用效率，并試圖在合同能源管理中有一份屬于自己的地盤。
如果我們有照度傳感器，當你設備開燈后，而照度值沒有改變，你可以判斷出照明設備損壞，可以向用戶推送相關的維護服務。這也許就是互聯網下的020的變種。
如果我們有人員運動傳感器，在夜間我們起夜是使用柔和的光線來為你照亮前方的道路。
如果我們離家在外，家里的老人超過12小時無運動跡象，我們可以及時向你推送相關消息，可能我們來晚了，但我們還是來了。
我們有很的想法，但是當我們止步不前時，很多東西都會變成別人的成果！
我們這么做的目的是什么？
我們希望像我們這樣一類只會寫C代碼的人，能夠在智能家居或者居家養老這類相對比較定制化的市場里面有一席之地，我們通過購買已經開源的硬件產品。自己修改代碼實現自己想要的功能，或者通過RDP來調用相關接口實現對于設備的遠程讀取或控制，為客戶實現定制開發，施展自己的才華從而獲得利潤！
未來的智能硬件，一定會向著個性化定制的方向移動！對于智能硬件的制造將會是巨頭們的游戲，我們平民就學會使用并創造價值即可。如果不理解我們可以想一下電腦。做電腦的就那么幾家公司，但是靠電腦吃飯的就有很多！
對于智能硬件，開源并協助開發者快速投入市場將會是智能家居或者居家養老、安防等定制領域的風口！
為了建立起ML_Network，我們需要哪些設備？
我們需要開關量執行器，使用AC switch 或者繼電器來進行控制；我們需要有PWM的調速控制，實現對風扇或者電機的調速控制。我們需要人員運動傳感器、時間、日照、溫度傳感器；我們需要一個總控設備來建立起屬于用戶自己的控制邏輯。
如果你認為這個ML_Network對于你有作用，我們希望與你合作！我們尋求知識產權、軟硬件開發、物料與方案供應、生產等相關流程的協助。
如果您認為您可以幫助到我們，歡迎關注我們的微信公眾號：我們將在微信公眾號里面推送更多相關ML_Network 相關的開發進度及我們需要的實際需求。
第二章 通信協議構架說明
關于通信協議，我們做了很多的嘗試！因為通信協議的問題讓我們的設備開發在經歷了一段時間的積累后因為協議設計的局限性導致后期的設備屬性變得異常復雜。一個設備要想和另一個設備通信，需要對其中的一個設備通信協議進行修改以便匹配對應的邏輯關系。
我們不想每次都要重復以前的勞動，也因為這個原因，我們在不斷進行著改版的測試。
這一次，我們想到了RDP的方式，每一個功能模塊都以同樣的接口形式出現。方便使用同一的標準來進行規范。方便后期的多設備互聯通信。
協議的基礎構架如下：
項目名稱
空間大小
備注
發送類別
1byte
用于指示發送端的類別碼，在協議中相當于關鍵字用來識別使用什么樣的協議模式來進行解析
發送序列
1byte
用于區別同一類別碼中不同的設備ID，防止因為系統中的設備過多發生沖突
發送序列號
1byte
用于指示發送包的序列號，防止在雙向通行時重復接收
發送數據包長度
1byte
一個數據包的最大長度為32byte，可以進行組包發送。數據從發送類別到LRC前的數據長度
接收類別
1byte
用于指示接收端的類別碼
接收序列
1byte
用于指示接收的設備ID號
RDP1 keyword
1byte
用于指示本指令的具體命令
RDP1內容
N byte
該出為協議的具體內容部分
RDP2 keyword
1byte
用于指示本指令2的具體命令
RDP2內容
N byte
RDP2 協議具體內容
RDPN keyword
1byte
用于指示本指令N的具體命令
RDP N內容
N byte
RDPN 協議具體內容
LRC校驗
1byte
用于確認協議是否完整，從協議頭到RDPN的所有數據異或和
為什么ML_Network 需要有**類別、**序列？
對于一個網絡而言，我們需要對網絡里面的每一個成員分配一個唯一ID，使用類別+序列的方式可以實現分類管理，比如我們將ML_Network的成員分為主控、路由、執行、傳感器這幾大類。設備里的成員需要知道使用什么樣的協議格式來繼續處理，而類別正好回答了我們的問題。使用序列的目的是為了區分同一系統里面因為有多個同類別的設備，防止設備控制沖突產生。
之所以使用收發雙向，是為了在通信協議中建立起收發應答機制，同時加入序列號的目的是為了防止重復執行的問題出現。
ML_Network中RDP的內容長度是怎么進行區分的？
我們使用sizeof（）來測量一個結構體的長度，在解析完一個RDP后，返回一個長度，計算偏移量后確定是否還要繼續或者退出解析。在早期的版本中，我們有一個內容長度的指令來進行偏移，這一版本中我們去掉了，主要是用時間來換空間。提高數據包的利用率。
ML_Network中的RDP的結構內容是怎么劃分的？
Typedef struct
{
U8 ioSwitch :1;
U8 ioRelay :1;
}is_xxxio_rdp;
Typedef struct
{
U8 key;
U8 (*fun)(u8 *inBuf);
}is_xxxFun;
Typedef struct
{
U8 classID;
U8 indexID;
//U8 index ;
//U8 *struct;
}gs_Rdp;
按照上面的結構，我們將每一個RDP里面的放置一個KEY，以便程序快速的查找相關的RDP協議指令。
在ML_Network中我們將如何讓設備進行相關的注冊和通信控制？
關于注冊：
在ML_Network中，如果一個設備想要控制另一個設備，必須將自己的類別和序列加入到gs_Rdp中，以便獲得相關的許可。
關于控制：
接收方對比了許可buf后，會判斷是否可以進行相關的操作，如果可以則會根據接收類別碼跳轉到指定的協議構架函數中，通過調用is_xxxFun結構體的函數和key來找到合適的解析函數。
在完成解析函數的查找后，會進行相關的控制指令操作，并隨后對該數據包進行應答操作。
我該如何獲取ML_Network 協議解析源碼？
關注我司微信公眾號（揚州梓元節能：yzzyjn）并在公眾號中回復自己的收件人郵箱號后我們將在第一時間內將相關的源碼發送到您指定的郵箱中，我們期望與您合作，共同將ML_Network生態系統建立起來，實現對設備的互聯互通！
第三章 設備注冊
對于一個系統級別的產品，因為其數量相對龐大。我們需要使用一個統一的編碼規則來進行相關類別設備的管理工作。
在本協議中，允許存在的類別數量為256種。下面按照一定的規則來進行相關設備編碼的說明。
項目名稱
空間大小
備注
廠標
2byte
用于識別是哪一家企業生產的
代理區域
3byte
廠家對于設備進行區域控貨管理使用
物料類別碼
1byte
用于確認設備所屬的類別，建立起基礎的產品分類
物料細分碼
2byte
各廠家自定義區域，用于對軟硬件版本號的識別或做它用
產品流水
4byte
各廠家生產流水號
防偽碼
8byte
該區域可以和315網站聯動或廠家自建防偽編碼規則
建立起這樣的注冊編碼原因是為了實現對廠家產品的精確管理。實現對生產廠家和代理商的管理工作。
為什么要建立廠標？
對于ML_Network 我們最終會將其聯網管理，我們的主機在未來將具備遠程升級的能力！我們可以根據廠家的編碼去尋找對應的新版本驅動文件進而實現對ML_Network中的設備精確控制與管理。
建立該標識也是為了后面的驗證與防偽工作。我們希望在這個系統里的每一個成員都能夠和睦的相處。并且通過大數據清楚的知道什么類別的設備用戶使用頻次最高，用戶的使用習慣行為是怎么樣的，進而有針對性的進行研發工作。
為什么有代理區域碼？
建立這個代理區域碼的目的是為了實現對代理商的控貨管理。同時可以根據平臺反饋回來的數據進行區別實現對各個區域間的差別化分析，以便有目的性的進行研發與推廣作業。
為什么有物料類別碼？
建立該物料類別碼的目的是為了實現設備在聯網注冊時可以快速的找到對應的解析程序。同時也用于規范各個廠家間的基礎功能版本。
為什么有物料細分碼？
建立物料細分碼的目的是為了方便各個廠家對于自身產品的軟硬件版本管理，維護人員快速找到問題的原因及提供及時的維護建議。
為什么有產品流水？
建立該流水號的目的是為了廠家實現對產品的溯源管理，通過流水可以查找產品的是什么時候由誰生產或質檢出來的。進而有針對性的進行產品品質的管理工作。
為什么有防偽碼？
我們不想自己的系統被別人無情的山寨，我們希望通過聯網的方式，當設備注冊的時候通過互聯網將防偽碼發送到各個廠家的平臺上，有各個廠家來授權是否通過驗證。使用這樣的方式是為了實現ML_Network 的健康發展，我們從內部建立起屬于自己的產品品控體系。為自己的生態系統建立一個有效的保障與管理機制。MicrosoftInternetExplorer402DocumentNotSpecified7.8 磅Normal0
第三章 設備注冊
對于一個系統級別的產品，因為其數量相對龐大。我們需要使用一個統一的編碼規則來進行相關類別設備的管理工作。
在本協議中，允許存在的類別數量為256種。下面按照一定的規則來進行相關設備編碼的說明。
項目名稱
空間大小
備注
廠標
2byte
用于識別是哪一家企業生產的
代理區域
3byte
廠家對于設備進行區域控貨管理使用
物料類別碼
1byte
用于確認設備所屬的類別，建立起基礎的產品分類
物料細分碼
2byte
各廠家自定義區域，用于對軟硬件版本號的識別或做它用
產品流水
4byte
各廠家生產流水號
防偽碼
8byte
該區域可以和315網站聯動或廠家自建防偽編碼規則
建立起這樣的注冊編碼原因是為了實現對廠家產品的精確管理。實現對生產廠家和代理商的管理工作。
為什么要建立廠標？
對于ML_Network 我們最終會將其聯網管理，我們的主機在未來將具備遠程升級的能力！我們可以根據廠家的編碼去尋找對應的新版本驅動文件進而實現對ML_Network中的設備精確控制與管理。
建立該標識也是為了后面的驗證與防偽工作。我們希望在這個系統里的每一個成員都能夠和睦的相處。并且通過大數據清楚的知道什么類別的設備用戶使用頻次最高，用戶的使用習慣行為是怎么樣的，進而有針對性的進行研發工作。
為什么有代理區域碼？
建立這個代理區域碼的目的是為了實現對代理商的控貨管理。同時可以根據平臺反饋回來的數據進行區別實現對各個區域間的差別化分析，以便有目的性的進行研發與推廣作業。
為什么有物料類別碼？
建立該物料類別碼的目的是為了實現設備在聯網注冊時可以快速的找到對應的解析程序。同時也用于規范各個廠家間的基礎功能版本。
為什么有物料細分碼？
建立物料細分碼的目的是為了方便各個廠家對于自身產品的軟硬件版本管理，維護人員快速找到問題的原因及提供及時的維護建議。
為什么有產品流水？
建立該流水號的目的是為了廠家實現對產品的溯源管理，通過流水可以查找產品的是什么時候由誰生產或質檢出來的。進而有針對性的進行產品品質的管理工作。
為什么有防偽碼？
我們不想自己的系統被別人無情的山寨，我們希望通過聯網的方式，當設備注冊的時候通過互聯網將防偽碼發送到各個廠家的平臺上，有各個廠家來授權是否通過驗證。使用這樣的方式是為了實現ML_Network 的健康發展，我們從內部建立起屬于自己的產品品控體系。為自己的生態系統建立一個有效的保障與管理機制。
第三章 設備注冊實現方法
為了實現對從設備的注冊管理，我們需要建立起類似FAT文件系統來實現對文件的讀取與寫入操作。系統注冊文件按照固定的格式來進行劃分，在先階段一個數據塊劃分出14個設備ID，第一個字節用于表示所屬類別，第二字節用于表示本系統中該類設備總量，第三個字節為相關詳細的ID，其中00表示無意義，一個塊的最后一個字節用來表示下一個鏈表的偏移地址。
為了實現對設備的管理，我們需要在本機里面做好記錄，以便主機可以快速的查找到對應的設備ID號，在通信的階段我們將使用本機的設備ID來設置通信地址，從設備使用主機加從設備分配ID來構建一個通信ID，主機通過這個ID來和從設備通信，從設備使用主機+0xff來和主設備通信。
設備間的通信采用雙向應答的方式來進行。
在ML_Network的初始階段，我們采用的最基本的方案來實現，在本模塊中僅實現了對設備的注冊和注銷管理，并不對設備的合法性進行檢驗并對設備的原始數據進行讀取。
為什么ML_Network 使用兩個不同的設備ID來進行通信？
我們使用RFID來進行通信，為了降低各個聯網設備的通信壓力，并保證數據傳輸的可靠性，固我們對每一個設備都分配了一個獨立的ID號，本機在默認情況下僅監聽該ID號的數據。如果一方需要對另一方通信，則需要找到對方的ID號來進行通信，在完成發送后需要切換到本機的ID號進行監聽。
ML_Network 如何實現數據交互？
1、發起方主動發起數據，確認發送成功；
2、發起方切換模式進入接收狀態；
3、接收方解析數據包并生成相關的應答數據包；
4、接收方切換為發送模式，將數據包發送成功。接收放并不會使用自動重發機制，有發起方通過軟件協議自行確定。
ML_Network 中的ID號是該如何進行解析？
我們使用16位的設備ID號來進行數據傳輸，分為4個區位，15-8位地址碼，用于在組網中來使用螞蟻算法快速的找到通信的設備位置坐標，7-4位主設備ID號，3-1為從設備ID號。在這種配置模式下，一個主設備可以管理15個執行和或傳感器。一個路由設備可以管理同時管理6個主設備。在一個系統里面最大允許存在254個路由設備。00xx為空地址。Ffxx為系統主控設備。
在這樣的體系構架下面，如果僅使用多個主控設備可以彼此相互通信來實現傳感器的互聯，實現對運動傳感器的誤動作排除和或通過主控設備來橋接，對非本主控設備的管理。
我該如何獲得ML_Network 的注冊和注銷源碼？
關注我司微信公眾號（揚州梓元節能：yzzyjn）并在公眾號中回復自己的收件人郵箱號后我們將在第一時間內將相關的源碼發送到您指定的郵箱中，我們期望與您合作，共同將ML_Network生態系統建立起來，實現對設備的互聯互通！
ML_Network 事件處理機制
對于常規的控制邏輯而言，在我的映像中應該有兩種情況，一種是基于時間的事件，比如什么時間做什么事情，我們可以當做鬧鐘來處理。另一個是標志事件，比如：天冷了請注意保暖。拆分來看，天冷是標志，請注意保暖是一個通知事件。對于鬧鐘事件，百度百科給出的定義是：既能指示時間，又能按人們預定的時刻發出音響信號或其他信號。我們可以簡單的認為在什么時候做什么事情。
對于一個鬧鐘事件狀態機而言，我們需要定義的內容如下：
1、告訴設備我需要安排一個事情：什么時間、什么周期
2、告訴設備如果運行到這個時間點了，我們該處理什么事情。
3、如果我不想這個時間按照計劃發生了，如何取消。
對于一個周期性的事件而言，我們首先需要思考的是這樣一個事件的大體描述是怎么樣的？比如在我們的應用中會有提示音事件，我們需要提示音在運行到我們設定的時間后就自動的取消掉。又或者是按鍵掃描事件，我們需要以固定的頻率來進行輪詢，不間斷來進行進行操作。對于這類OPM 單觸發模式的事件而言，我們需要設定的內容很少：
1、給我安排了一個什么樣的事情
2、這個事件大約需要執行多久才可以取消
對于一個時間范圍事件，我們需要設定的在什么樣的時間尺度下進行觀察和在什么樣的時間周期中進行觀察。其次是如果這個時間范圍合適，我們該做什么事情。對于這樣的一個事件我們需要設定的內容如下：
1、事件開始的時間：
2、事件結束的時間：
3、時間的參考標準是：1、系統時鐘；2、RTC時鐘；
4、什么事件。
5、取消該事件的辦法。
標志事件的處理辦法。
抽 象的描述這個事件其實很簡單，比如：天黑開燈。對于我們而言，我們從沒有必要考慮事件的反面該如何處理，不是不考慮，只是我們沒有必要把任何一個事情都認 為只有兩面，不是正就是反。其實在事件的處理過程中我們可能需要面對的事情要比這個復雜很多。對于一個標志事件我們需要考慮的的內容可以分為如下幾個部 分：如上所述，如果天黑我們是否要一直都保存燈亮，還是我們只是在天黑的那一刻開燈即可。這本身就是一個很復雜的邏輯。
對于標志事件，我們在很多情況下處理的是OPM（單脈沖）模式，只是在事件發生的那一刻執行一次即可。但也有可能需要連續的保持，比如處理報警類事件時，如果事件沒有正確的處理，我們將需要將事件長時間的保持。
對于OPM模式的事件：
我們需要處理的內容如下：
1、對事件標志位使用情況進行初始化并在將該事件綁定在對應的標志位上；
2、做出一個合適的接口來使外界來觸發該事件發生；
3、做出一個接口來使外界取消該事件的發生。
對于長時間維持事件，我們需要在標志位沒有清除前始終保證該事件的可靠運行。相對于OPM的模式，我們在執行完一次該事件后我們不會立即清楚掉標志而是繼續保持該標志，直到其他事件將該標志位清除為止。
對 于采用事件標志位的方式來進行控制，在沒有跑系統的程序中可能是一種浪費，因為如事件的執行本身沒有長時間過程的話，完全可以直接調用而不用進行復雜的關 聯操作。使用信號的方式來進行處理的目的主要是為了方便控制邏輯層的編寫。將執行成與業務成分離有助于后期的擴展和或方便快速的對指令的本身做出應答。Make devices running at right ,make your life better!
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
