可重構傳感器系統關鍵技術研究

摘 要：文中研究了面向復雜環境感知的傳感器系統可重構技術，并提出了具體的系統實現方案。該論文的主要工作包括：提出了面向環境參數動態感知的任務需求，設計了“協議轉換單元+傳感器管理服務平臺”的系統結構模型，針對傳感器系統設備動態識別與驅動/設備加載、感知設備硬件接口優化配置、感知數據解析與標準化轉換等關鍵技術做出相應解決方案，并基于這些技術研制了面向復雜環境感知的可重構傳感器系統，進行了詳細測試驗證。文中的研究成果有效提升了在突發情況下，面對復雜環境傳感器的部署效率，為研究具備動態適配、快速重構典型特征的傳感器系統提供了理論支持和工程應用價值。

關鍵詞：復雜環境感知；傳感器系統；可重構技術；多傳感器；協議轉換單元；傳感器管理服務平臺

中圖分類號：TP212.9 文獻標識碼：A 文章編號：2095-1302（2024）06-00-06

0 引 言

自20世紀70年代美國首次建立了第一個水環境監測系統以來，各個國家都在大力研發、部署各種類型的環境參數監測系統：以信息化技術為基礎，綜合運用各類傳感器，實現對自然環境的探測、環境參數信息的實時傳輸，保障對作業時空信息的及時掌控。

進入21世紀之后，隨著物聯網、大數據、人工智能相關新興信息技術的快速發展及物聯網理論依據的涌現，各個國家都更加重視災難環境的提前預測和智能預警。特別的，在現代科技條件下，面對因意外因素引發的災難對環境參數探測、搜集提出了更高要求：環境參數傳感器系統需能夠快速適配環境探測需求，而面向復雜環境感知的傳感器系統可重構技術為實現該目標提供了技術支撐。

面向復雜環境感知的傳感器系統可重構技術涉及相應的分層模型、傳感器動態加載、傳感器優化配置、接口協議轉換等關鍵技術。對這些關鍵技術發展現狀的分析有助于理清技術發展脈絡、探究未來的演進方向。

1 可重構傳感器系統層次模型及體系架構

1.1 層次模型的研究

綜合參考美國ORS計劃的SPA模型、物聯網層次模型及計算機網絡的OSI參考模型等典型層次模型，特別是PnP技術從軟件層面形成對接口驅動的統一規劃、以消息形式進行數據傳遞的設計思想[1]，項目通過采用協議轉換單元+傳感器管理服務平臺的方式解決傳感系統耦合度高的問題，同時也提升了傳感器的可擴展性。

根據復雜環境條件下對快速動態構建環境狀態傳感系統的要求[2]，參考SPA、RSPA、SWE及物聯網層次模型提出基于多總線復用的三層可重構傳感器系統層次模型，如圖1所示。

數據從傳感器到上位機，其中數據的轉化與上傳主要由可重構傳感器系統實現，系統包含協議轉換單元以及傳感器管理服務平臺兩大部分。

感知層主要包含各類直接感知環境狀態參數的傳感器，它們具有各異的物理接口、電氣接口以及通信協議等功能性能參數。為了方便接入系統，需要提前根據其通信協議對其物理接口做出相應改造。

異構數據與設備接入層主要由協議轉換單元構成，實現統一的外部物理層接口、傳感器類型標識與自動識別、傳感器驅動適配與動態加載、異構通信協議轉換與數據解析等。在傳感器首次連接轉換單元時需要通過傳感器管理服務平臺對轉換單元進行傳感器類型標定，以提升驅動加載的效率。圖2所示為協議轉換單元的上報數據狀態機。

動態適配支撐層由傳感器管理服務平臺構成，主要實現協議轉換單元的接口歸一化、驅動、數據、交互命令的管理等功能。通過傳感器管理服務平臺向上與數據處理控制中心、向下與協議轉換單元通信，起到數據存儲、數據集中、數據處理的樞紐作用。圖3所示為傳感器管理服務平臺接收數據狀態機。

應用層主要包括數據存儲、回調、分析與展示、人機交互、系統管理等功能。

1.2 體系架構的研究

參考歐洲航天局根據國際空間數據系統咨詢委員會制定的SOIS標準[3]，結合我國在總線架構方面的設計思想，將各種傳感器協議轉化為統一格式并通過以太網上傳至上位機。圖4所示為本課題設計的系統硬件資源架構示意圖。

系統核心由協議轉換單元MCU、以太網交換機以及傳感器管理服務平臺MCU組成。其中，協議轉換單元MCU為協議轉換單元核心部件，以太網交換機以及主控MCU組成傳感器管理服務平臺核心部件。

擴展電路主要位于傳感器管理服務平臺，包括以太網交換接口電路、HDMI接口電路、USB HUB擴展電路、下載調試接口電路等。以太網交換接口主要負責傳感器管理服務平臺與上位機之間對數據訪問、驅動管理、系統升級等操作。HDMI接口電路與USB HUB擴展電路結合后外接屏幕、鍵盤、硬盤等設備，方便調試、維護等。下載調試接口主要用于對設備進行系統安裝、測試等相關操作。

從整體架構來看，可重構傳感器系統基本統一了物理、電氣以及協議接口，現階段傳感器管理服務平臺設置了6個網口形式的數據輸入接口，最多支持6種協議形式的傳感器數據同時上傳。采用PoE供電的形式，由傳感器管理服務平臺對協議轉換單元以及傳感器供電。其中，對于傳感器的物理接口、電氣接口以及協議接口的統一以及傳感器數據上報由協議轉換單元實現。

2 傳感器接口優化配置策略研究

2.1 傳感器接口優化技術研究

根據上述設計方案，傳感器接口優化需要考慮物理接口、電氣接口以及協議接口三方面的接口優化問題[4]。

2.1.1 物理接口

針對傳感器物理接口，需要對待轉換的傳感器進行物理接口改造，這里主要將CAN、RS 232、RS 485、USB以及網口五類傳感器的信號接口根據自定義接口標準改造為航空插頭形式的物理接口，具體接口標準見表1所列。

目前基于RJ 45網口類型的傳感器僅考慮百兆以太網，因此采用4芯航空接插件。后續若采用千兆以太網或需給傳感器供電，此處更改為8芯以太網即可。

供電引腳主要由傳感器自身決定，協議轉換單元底板提供5 V、12 V供電電壓。

2.1.2 電氣接口

CAN、RS 232、RS 485、USB、RJ 45各自的電氣特性相差甚遠，具體的電氣指標及邏輯特性見表2所列。

針對以上5種協議的電氣接口特性，對每種協議的電路進行局部設計。

上面詳細討論了CAN、RS 232、RS 485、USB以及網口5種類型的傳感器在硬件層次電氣接口轉換的解決方案。下面將從軟件角度分析協議接口的轉換過程。

2.1.3 協議接口

協議接口的統一主要由協議轉換單元完成，通過協議轉換單元將CAN、RS 232、RS 485、USB、TCP/IP協議轉換為統一的MQTT協議[5]，協議定義如下：

res={

\"state\"：\"1\"，

\"FN\"：\"0\"，

\"senderId\"：senderId，

\"reciverId\"：reciverId，

\"type\"：\"request\"，

\"order\"：order，

\"sign\"：\"None\"，

\"msg\"：\"success\"，

\"data\"：data}

標準協議以字典的形式存儲于轉換單元中，傳輸時通過MQTT協議轉換為統一的Json格式以消息的形式進行數據收發。其中，data為傳感器的探測感知數據，具體數據結構如下：

{\"DATA1\"：X1，

\"DATA2\"：X2，

…，

DATAn：Xn，

\"error\"：0/1}

2.2 傳感器接口適配技術研究

借鑒基于FPGA設計CAN協議適配卡方案[6]，本項目采用ARM主控芯片設計RJ 45適配接口。相對于FPGA設計方案而言，通過ARM芯片先轉換再采集的方式不僅避免了更換不同協議接口傳感器時需要重新為其分配總線結構以及硬件資源的弊端。而且相比于FPGA設計方案，本方案增加了可轉換協議的種類、完善了錯誤檢測和故障界定等機制，以保障設備穩定運行。

項目采用的ARM主控+MQTT協議的接口適配方案主要由異構數據與設備接入層完成，包含以下兩部分功能：

（1）協議轉換單元主要實現傳感器接入與標識、傳感器驅動加載及環境狀態參數探測數據的采集與解析。項目設計實現以太網設備協議轉換單元、CAN設備協議轉換單元、RS 232設備協議轉換單元、RS 485設備協議轉換單元、USB設備協議轉換單元。協議轉換單元輸入輸出接口采用防水型航空接插件，同時配備指示燈指示傳感器通信狀態。

（2）傳感器管理服務平臺由核心處理單元、外部接口以及交換單元構成。處理單元主要實現傳感設備驅動存儲、適配、更新以及對協議轉換單元的驅動選擇、參數設定等。外部接口主要由PoE網口輸入、網口輸出電路、USB接口電路組成。交換單元主要由以太網交換機組成，實現以太網設備協議轉換單元、CAN設備協議轉換單元、

RS 232設備協議轉換單元、RS 485設備協議轉換單元、USB設備協議轉換單元的數據通信。

2.3 傳感器接口拓展技術研究

FT311D接口芯片擴展協議接口方案可以將USB接口擴展為外部UART、GPIO、PWM、I2C、SPI等硬件接口[7]，雖然可以有效解決設備硬件接口的擴展難題，但是在適配的協議類型上不夠全面。比如常用的USB協議、TCP/IP協議以及RS 485協議沒有得到相應的適配。

因此，將接口擴展芯片替換為ARM處理芯片，在滿足UART、GPIO、PWM、I2C、SPI等協議接口的同時還支持USB協議、TCP/IP協議以及RS 485協議。按照要求，項目先期實現USB協議、RS 232協議、RS 485協議、CAN協議以及以太網協議，后續可以根據需要靈活擴展到I2C、SPI、UART等其他協議。其實現的前提為ARM芯片（本課題采用全志H3芯片）支持如USB、TCP/IP、串口、I2C等常用協議。根據這些協議設計硬件接口電路，接入傳感器。通過協議解析獲取傳感器數據后，對這些數據進行下一步處理。而對于RS 232、RS 485以及RS 422等串口協議，因芯片僅支持TTL形式的串口協議，所以需要利用電平轉換芯片進行電平轉換步驟，而對于全志H3不支持的CAN芯片，則需利用CAN轉串口協議模塊進行間接轉換。

采取此折中的方案，雖然成本上有所增加，但從通用性角度來看，基本上滿足了市面上大部分協議的需求，并且其軟件協議可根據需求自由定制，解決了不同廠家傳感器相同而協議存在差異的問題。

3 傳感器動態加載技術研究

3.1 傳感器自動識別技術研究

動態識別技術最具代表性的是操作系統以枚舉法來識別USB設備[8]，即讓HOST識別USB設備，并為其準備相應資源來建立主機與設備之間的數據傳遞機制。但使用枚舉法識別效率低，且僅僅能識別USB HID設備。

出于效率、穩定性考慮，設備基于雙核心結構（轉換單元+傳感器管理服務平臺）采用主動上報的方式，各類型協議轉換單元上電后，進行各類資源的初始化，將設置的傳感器標識主動上報給傳感器管理服務平臺，等待傳感器管理服務平臺下發與識別碼相匹配的傳感器驅動后，轉換單元開始工作。

轉換單元向傳感器管理服務平臺發送握手指令，得到傳感器管理服務平臺的應答信號后，轉換單元向傳感器管理服務平臺發送線纜類型，以便傳感器管理服務平臺存儲相關信息到結構體中，待傳感器管理服務平臺回復應答信號后，即完成轉換單元的動態識別部分[9]。

傳感器管理服務平臺上電啟動后基于6個轉換單元的IP地址建立相應的MQTT鏈接，傳感器管理服務平臺通過解析轉換單元推送的自描述消息后，得到相應接口的傳感器信

息[10]；同時傳感器管理服務平臺根據接口依次對轉換單元推送應答消息，轉換單元訂閱到傳感器管理服務平臺推送的應答消息即代表通信建立成功。傳感器管理服務平臺訂閱得到轉換單元的自描述信息存儲在結構體變量中。

3.2 傳感器驅動動態加載技術研究

從整體上驅動動態加載流程如下：

首先，將相關傳感器驅動存儲于傳感器管理服務平臺的驅動文件夾內，然后將帶有“傳感器-協議轉換單元”標識的轉換單元通過網口連接至傳感器管理服務平臺；傳感器管理服務平臺通過PoE網口為轉換單元供電，轉換單元上電啟動后，首先完成系統自檢，接著進行內核初始化，然后啟動系統與協議轉換單元程序。之后，協議轉換單元通過硬件自檢獲取傳感器協議類別信息，在獲得傳感器的類別后將獲取的傳感器協議類別信息與存儲的“傳感器-協議轉換單元”標識比對，檢測是否匹配，檢測結果將放入隨后上報的MQTT握手消息中。此過程同時完成了與傳感器管理服務平臺握手和“傳感器-協議轉換單元”標識上報。隨后傳感器管理服務平臺通過握手信息獲取傳感器型號與線纜協議類型，并將結果存儲在數據庫中。然后傳感器管理服務平臺根據“傳感器-協議轉換單元”標識從存儲的傳感器驅動中為協議轉換單元加載相應驅動；最后協議轉換單元接收驅動，解壓并加載驅動即可完成驅動動態加載流程。

驅動動態加載狀態機如圖5所示。

4 軟件協議動態適配技術研究

4.1 傳感器接口協議轉換技術研究

項目采用異構數據定向轉換的方法來實現傳感器接口協議轉換，該方案在可靠性、穩定性以及通用性方面都得到了大幅提升，但是其硬件復雜度、成本也相應有所增加。與異構數據不定向轉換相比，此舉大幅減少了傳感器驅動數量，便于管理傳感器驅動的同時也提高了驅動開發效率。

傳感器接口協議轉換方案選擇MQTT協議作為異構數據定向轉換的協議，共分為以下4種接口協議轉換技術：

（1）串口協議（包含RS 232及RS 485）轉MQTT協議；

（2）USB協議轉MQTT協議；

（3）CAN協議轉MQTT協議；

（4）以太網相關協議轉MQTT協議。

以上4種協議的轉換操作都由協議轉換單元中的ARM主控芯片完成。

4.1.1 定制驅動

為傳感器設計相應的驅動，此過程又分為兩種情況：

（1）主動上報型傳感器：主動上報類型傳感器的上報數據較為單一，其協議結構也往往較為簡單。因此，這類傳感器的驅動只需先將傳感器主動上報的數據接收到協議轉換單元中，然后根據傳感器協議即可解析出具有物理含義的探測數據。

（2）被動查詢型傳感器：以ModBus為通信協議傳感器，其上報的往往是多種類型的復合數據，其協議構成也較為復雜，包含查詢指令、修改參數指令以及恢復出廠設置等指令。針對這一類型的傳感器驅動，首先需要根據其通信協議為其制定專用操作指令，用于訪問、修改、初始化傳感器等操作；然后以輪詢的方式不斷獲取傳感器探測數據，之后將獲取的探測數據存儲于協議轉換單元；最后根據傳感器數據語義定義解析出具有物理含義的探測數據。

4.1.2 數據采集

對于接入協議轉換單元的傳感器，在定制驅動后協議轉換單元即可完成對傳感器數據的解析、采集，將目標數據存儲到轉換單元寄存器內。數據采集包含以下3部分：

（1）數據校驗：對于傳感器上報的數據首先需要經過數據校驗來避免數據受元器件質量、電路故障或噪音干擾等因素的影響以及處理、傳輸、存儲過程中出現錯誤。當校驗未通過時，轉換單元將對傳感器重發采集指令。

（2）數據解析：對于采集的一幀數據往往包含幀頭、數據長度、指令信息、數據、校驗碼以及幀尾等信息，而數據解析就是在通過數據校驗后，根據傳感器數據幀格式獲取傳感器上報的目標數據幀，然后通過計算將數據解析為具有實際物理含義的可用數據。

（3）數據存儲：得到具有實際物理含義的數據后，協議轉換單元將這些數據存儲到FLASH內存以便后續使用。

4.1.3 協議轉換

協議轉換單元在得到傳感器數據后需要將數據以MQTT消息的方式上傳給傳感器管理服務平臺，此時需要將探測數據、傳感器協議類型、轉換單元MAC地址等填入MQTT協議字典的相應鍵值內以封裝成一個MQTT消息，然后通過MQTT協議上傳給傳感器管理服務平臺完成各傳感器協議對MQTT協議數據的轉換。具體流程如圖6所示。

4.2 感知數據解析與標準化轉換技術研究

項目針對復雜環境下的特殊需求設計了一套基于Web端的桌面訪問控制平臺。Web端服務器主要負責采集數據的展示以及驅動管理。與現有Web端服務器參與數據處理的方案相比[11]，其優勢在于：

（1）Web端服務器任務量小，運行效率高；

（2）數據解析在數據采集階段由協議轉換單元完成，以多異構數據并行的方式進行，解析效率高；

（3）數據以消息的形式代替幀數據進行MQTT通信，解決了復雜度高的復合型傳感器數據接入效果不理想的問題。

數據傳輸延時方面，本次研究內容針對小型、低速傳感器，在實時性上得益于百兆以太網以及MQTT協議可以實現毫秒級低延時。

在數據吞吐量方面，百兆以太網理論傳輸速度為12 800 KB/s，理論上每個協議轉換單元每秒可以傳輸2 133 KB，這對于小型傳感器數據而言，其吞吐量方面有足夠的冗余度。

數據協議標準化由自定的針對異構數據可重構MQTT通信協議標準決定，異構數據可重構MQTT通信協議標準規定了通信雙方的通信規則、內容以及通信指令，根據標準生成一個標準化協議通信字典，最后將通信字典轉換為JSON標準格式進行MQTT消息的推送、訂閱。

5 結 語

文中總結了課題針對可重構傳感器系統的相關關鍵技術的設計方案及研究內容，分別概述了本課題關于可重構傳感器系統層次模型及體系架構設計、傳感器優化配置策略研究、傳感器動態加載研究與實現以及軟件協議動態適配技術研究與實現。研究以硬件可行性、軟件可靠性為原則，以可重構技術關鍵技術方案為導向，完成了可重構傳感器系統的軟硬件設計。為接下來系統架構、芯片選型、軟件平臺的搭建奠定了基礎。

注：本文通訊作者為張會兵。

參考文獻

[1]蔡亞梅，寧勇，汪立萍.美國空間快響小衛星載荷技術現狀與分析[J].航天電子對抗，2012，28（6）：28-31.

[2]高永明.快速響應空間體系與應用[J].裝備學院學報，2012，23（3）：92.

[3]王君，王志杰，樂浪.基于SOIS的星載平臺軟件架構設計探索[J].航天器工程，2017，26（3）：84-89.

[4]劉成亮，吳寶元，董京京，等.面向傳感器標準化接口模塊的應用平臺設計[J].自動化與儀表，2012，27（6）：37-41.

[5]于海飛，張愛軍.基于MQTT的多協議物聯網網關設計與實現[J].國外電子測量技術，2019，38（11）：45-51.

[6]倪一洋.基于FPGA的多總線接口適配技術研究[D].南京：南京航空航天大學，2016.

[7]張佳進，陳立暢，唐愛云.基于FT311D的Android移動設備硬件接口拓展設計[J].單片機與嵌入式系統應用，2014，14（3）：13-15.

[8]張學雷，李占羽，李丹寧.嵌入式Linux下USB設備的驅動開發研究[J].電腦知識與技術，2010，6（28）：7974-7977.

[9]任艷艷. Linux設備驅動程序自動更新的研究與實現[D].北京：北京交通大學，2018.

[10]衛飛. 傳感器專用接插模塊的設計研究[D].合肥：安徽農業大學，2019.

[11]葛丹.物聯網傳感器數據處理平臺的設計與實現[D].南京：南京郵電大學，2016.

作者簡介：劉明政（1981—），男，高級工程師，研究方向為無人智能化裝備技術、裝備保障、模式識別等。

張盛煜（1997—），男，碩士研究生，研究方向為嵌入式物聯網。

張會兵（1976—），男，博士，教授，研究方向為人工智能與大數據、社交網絡、物聯網與嵌入式系統相關領域。