目前很多自動駕駛汽車, 交通紅綠燈, 智能家居電器設備之間, 都是不能相互通信的, 這對未來人工智能帶來不方便,
人工智能中各設備制定全國性統一數據鏈非常重要.
因此, 我思考着: 汽車/ 手機app/ 冰箱/ 電視/ 風扇/ 洗衣機/ 空調/ 掃地機器人/ 熱水器/ 防盜門/ 等設備之間應當要能相互通信,肯定採用了相同的數據規約格式, 但是又能體現不同的特點.
比如基本需求:
1, 我們下班了, 用手機app告訴熱水器要預先熱水, 房間的空調要提前開啓.
2, 但是途中收到領導電話要加班, 這時又要告訴熱水器關閉, 空調關閉, 以節能省電
3, 空調與熱水器收到指令後, 回覆並告訴控制app, 並顯示當前狀態.
4, 數據加密與解密, 整個過程中採用ASE或者其它方式加密.
對通用數據鏈規約要求如下:
1, 1對1命令/響應/上報/讀寫等等
2, 1對n廣播命令
3, 1對n指定規約分類的局部廣播命令
4, 同一命令接者應可以多個,有個批量大小.
5, 報文中有設備分類碼,
6,報文中有作設備唯一標識碼
7,設備同時可以併發進行多流程會話
根據上述要求, 制定一個通用數據鏈規約標準框架格式:
規約標誌:2B, FB88,指總規約標誌.
會話流水:10B, 會話發起者生成19位唯一流水,同一次會話中請求/響應等不同流程由此號串聯起來.
報文控制:1B, 1-2位表示1請求 /2響應 /3主動上報, 3位讀/寫, 4位是否有後續幀, 5位是否要回復,6位流程是否結束,其它備用
報文長度:2B, 最長65535字節.
規約分類:2B, 規約分類(65535種), 汽車/ 手機app/ 冰箱/ 電視/ 風扇/ 洗衣機/ 空調/ 掃地機器人等, 0爲公共分類.
功能編號:2B, 表示功能(65535種), 每種規約分類單獨的功能號.
發送地址:4B, 如:192.168.0.1
接收個數:1B, 不用廣播方式時, 發給指定單位, 最多一次發給255個(比如座標同時發給指定的 255個空調)
接收地址:N, 127.0.0.1表示廣播, 或者地址數集合:192.168.0.1,192.168.0.2等等
信息體個數：1B,一次最多共255個,如果內容很大,可以配合報文長度與後續幀狀態標誌來分批發送
信息體內容:N, 根據功能確定格式(如: 空調溫度),可以無內容
校驗:2B
結束:2B,FE88
這樣一來, 使用中,所有類型的設備, 都可以接收各種設置, 又可以共享信息.
注: 本人做過電錶規約, 瞭解網上公開的國標通信規約標準.
以下是列子:
寫入目標溫度:
- 功能說明
|
規約分類 |
功能編號 |
功能名稱 |
說明: |
|
90 |
1 |
設置目標溫度數據 |
設備接收命令調節設置溫度, 此表爲10進制數, 91表示[手機] |
- 報文結構
|
規約結構 |
長度 |
例子值 |
說明: |
|
規約標誌 |
2B |
FB88 |
|
|
會話流水 |
10B |
00000000000000000001 |
會話發起者生成19位唯一流水, 同一會話編號相同,回覆時原樣返回 |
|
報文控制 |
1B |
60 |
請求,寫入,無後續幀, 需要回復, 流程未結束 |
|
報文長度 |
2B |
0031 |
指整個報文的長度,包括開始與結束: 49 |
|
規約分類 |
2B |
005B |
十進制值爲:91 手機 |
|
功能編號 |
2B |
0001 |
功能號爲:1 |
|
發送地址 |
4B |
C0A80001 |
地址爲:192.168.0.1 |
|
接收個數 |
1B |
02 |
接收者地址數: 2個 |
|
接收地址 |
N |
C0A80002C0A80003 |
接收者地址: 192.168.0.2, 192.168.0.3 |
|
信息體個數 |
1B |
03 |
3個 |
|
信息體內容 |
N |
000000FF000000FF000000FF |
每個值用4字節表示浮點數: 最高溫度, 最低溫度, 設置溫度, 共12字節 |
|
校驗碼 |
2B |
00 |
無 |
|
結束標誌 |
2B |
FE88 |
|
最終發送的報文:
FB8800000000000000000001600031005B0001C0A8000102C0A80002C0A8000303000000FF000000FF000000FF00FE88
APP發送之後, 空調地址爲 192.168.0.2, 192.168.0.3兩個空調就會收到 設置溫度, 然後啓動空調.
從報文件中可以看到: 發送者對象是 [手機], 接收者只知道地址爲 192.168.0.2, 192.168.0.3 的兩個設備