智能物聯電能表用嵌入式操作系統驅動程序檢測技術研究

王爽，段曉萌，趙婷，王曉東，李文文

(1.中國電力科學研究院有限公司，北京 100192； 2.國網冀北電力有限公司計量中心，北京 102208)

0 引 言

基于IR46標準和我國能源互聯網建設需求[1-3]，國家電網公司在原來智能電能表的基礎上新增加了停電主動上報、高效通信、電能質量監測等功能，研制了適應不同業務需求的智能物聯電能表[4-6]。

新研制的智能物聯電能表主要由計量模組、管理模組以及擴展模組構成。計量模組承擔法制計量的基本功能，管理模組從計量模組獲取電源和原始數據，擴展模組為通信或計算模組，如圖1所示。

圖1 智能物聯電能表硬件框圖

為了滿足電能表新增的非計量功能需求，智能物聯電能表中采用嵌入式操作系統設計理念，在管理模組部署了實時操作系統(RTOS)[7-9]。嵌入式操作系統將底層硬件與頂層應用APP功能剝離，實現了APP的靈活可換[10-13]。由于RTOS的驅動與管理模組硬件和其他模組的接口深度綁定，驅動程序運行的安全性、穩定性等與硬件密切關聯，因此，對驅動程序各項指標的測試顯得尤為重要[14-17]。

由于智能物聯電能表嵌入式專用實時操作系統是一項首次提出的技術，不同于國際上一些操作系統應用理念，因此目前行業內暫無針對電能表驅動程序的測試方法，無法實現對于電能表驅動程序功能符合性以及性能可靠性的驗證。而常規的嵌入式軟件通用測試方法，只能孤立的對驅動進行一般測試，缺少針對具體硬件實例的測試[18-20]。

為了實現建設一個開放式、跨硬件的智能電能表軟件生態系統，實現電能表頂層APP的完全可互換，文中研究智能物聯電能表RTOS的驅動測試方法，并對不同廠家的智能物聯電能表管理模組進行驅動程序測試。

1 驅動程序檢測技術及裝置研究

由于RTOS內核與驅動IP均以閉源方式發布，無法采用傳統的白盒測試方法對驅動程序的功能符合性、實時性和健壯性等指標進行檢測。為了解決上述問題，文中采用在管理模組中植入嵌入式測試代理子系統，該子系統與外設仿真子系統(仿真計量模組和擴展模組)共同進行驅動程序測試。

文中研發設計的電能表專用實時操作系統驅動測試裝置的框圖如圖2所示，該測試裝置包含外設仿真子系統、測試軟件子系統和嵌入式測試代理子系統三部分，可完成智能物聯電能表驅動程序的自動測試。

圖2 驅動程序測試系統框圖

外設仿真子系統完成計量模組和擴展模組仿真。它接收測試軟件的指令，控制仿真模塊產生指令行為，在指令流執行過程中與測試軟件實時交互。測試結束后，將結論和數據明細上傳給測試軟件。

測試軟件子系統分為客戶端和測試服務端兩部分，服務端依次接收客戶端下發的測試項，完成測試執行功能，客戶端完成測試方案，實驗結論、實驗明細和報告管理，并且具備操作和展示的人機界面功能。

嵌入式測試代理子系統由驅動、操作系統和APP(包括代理APP和測試APP)組成。其中，代理APP完成系統自檢和初始化、測試APP的安裝和運行、測試APP與上位機轉發通信、測試APP運行資源監控、測試結論和明細的生成和上報等功能。

1.1 外設仿真子系統設計

外設仿真子系統框圖如圖3所示。

圖3 外設仿真子系統框圖

由圖3可知，外設仿真子系統主要包括四個核心模塊：

(1)電源仿真模塊：完成管理模組電源仿真功能，產生15 V和5 V時序可控的電源；

(2)計量模組仿真模塊：完成計量模組數據通信仿真功能。它與上位機通信模塊通過uart口交互，接收測試軟件下發的計量數據并保存，通過SPI口與管理模組進行數據通信。同時，它還支持通過uart口轉發功能，即：由上位機直接模擬計量模組數據與管理模組通信；

(3)擴展模組仿真模塊：完成uart口轉發功能。即：由上位機直接模擬擴展模組與管理模組進行通信；

(4)I/O仿真模塊：完成計量模組、擴展模組與管理模組之間I/O模擬功能。該模塊可根據主控命令產生不同頻率和占空比的PWM輸出，也可對輸入進行脈寬和頻率的捕捉。

外設仿真子系統除四個核心模塊外，還包括上位機通信模塊和主控。上位機通信模塊將軟件測試系統的以太網接口轉換為多路uart口，完成與測試軟件與四個核心模塊和主控之間的通信。主控接收測試軟件下發的指令，根據指令控制四個核心模塊。

1.2 測試軟件子系統架構

測試軟件子系統包括測試服務端和客戶端兩部分。服務端與客戶端之間通過TCP建立“請求-響應”(SocketA)和“通知-確認”(SocketB)兩條通道。應用層數據單元采用靈活且易于閱讀的JSON編碼。測試軟件子系統架構框圖如圖4所示。

圖4 測試軟件子系統框架圖

測試軟件子系統工作前，需配置外設仿真系統的接口波特率、通信超時時間和初始狀態等參數，并保存到數據庫；然后，編制測試方案，并保存到數據庫。測試方案是由多個測試項組成，單個測試項的測試指令流程和對應的測試APP是相同的，對指令流和APP的運行參數進行不同的配置形成多個測試點。測試軟件子系統工作流程如下：

(1)客戶端從數據庫獲取編制好的測試方案，依次將測試項、對應APP和測試點參數通過SocketA下發到服務端，請求服務端執行測試；

(2)服務端收到任務后，刪除管理模組的APP和數據，恢復初始狀態后，將收到的測試APP安裝到管理芯；

(3)服務端按測試點參數啟動APP，并按測試項依次指令流，并將測試數據和日志實時上報到客戶端。指令流執行完成后，生成測試結論和整理明細數據，并上報給客戶端；

(4)客戶端保存測試項結論和明細數據，繼續請求服務器執行下一測試項。方案中所有項目完成后生成總結論整理所有項目測試明細，并生成測試報告。

1.3 嵌入式測試代理子系統架構和技術

寄宿在管理模組內的嵌入式測試代理子系統軟件架構框圖如圖5所示。

圖5 嵌入式測試代理子系統軟件架構

圖5中，測試APP和代理APP之間通過通道和共享內存兩種內部IPC機制進行通信。代理APP與上位機之間采用DL/T 698.45協議進行通信。測試APP和代理APP通過SYSTEM_CALL操作系統接口調用系統和驅動功能。

代理APP是驅動測試的核心技術，是測試前預置在系統中，不可卸載。執行測試APP前，代理APP首先執行APP卸載、數據清理和碎片整理、操作系統與上位機精確對時等操作；然后檢測系統主頻、心跳、定時器等是否工作在準確頻率上，確保APP運行前系統處于相同狀態。代理APP將監控測試APP運行前后的內存使用狀態和時間戳，實現驅動內存泄漏檢測和資源使用后未釋放的檢測，同時可對相同測試項在不同廠家上測試運行時間進行橫向對比。

驅動測試的另一個核心技術是驅動接口函數性能測試方法。由于物聯表操作系統是實時操作系統，在無事件發生時CPU處于idle狀態。測試驅動性能時，代理APP和測試APP均進入阻塞態，不占用CPU時間。CPU只在測試APP和內核間切換。通過將調用驅動前后時間戳相減可測得驅動性能數據。測試驅動的時序圖如圖6所示。

圖6 驅動測試時序圖

首先，測試APP調用讀取系統時間戳函數，記錄驅動接口調用前的時間：其次，調用驅動接口函數，驅動功能執行完后返回到APP;再次，測試APP再次調用讀取系統時間戳函數;最后，將開始和結束時間戳相減就是驅動運行時間(即性能)。

然而，該方法計算的驅動運行時間中包含返回讀系統時間戳函數的時間、調用和返回驅動接口函數(進出內核態)的時間、內核取時間戳的時間，使得測得的驅動運行時間比實際時間長。

下面通過時序分析設計時間補償方法。從圖6可知，進系統調用到內核獲取時間戳的時間為T3-T2和T9-T8，該時間應該由OS性能參數給出。此處假設T3-T2=T9-T8，無抖動或抖動可忽略。則廣義的驅動運行時間為T9-T3，而實際驅動運行時間為T6-T5。編寫不執行任何操作的驅動代碼，使得T6-T5=0，此時，補償時間即為T9-T3的數值。然后計算驅動實際執行時間，即為(T9-T3)-補償時間。為了較準確的估計進入tick服務的時刻，在測試每個驅動接口前，通過系統延時的方法使得測試開始時間與tick同步，確保最先的連續200 ms內不會進入tick服務。通過連續1萬次補償時間測試均為8 μs～28 μs之間，證明T3-T2基本等于T9-T8，抖動可忽略的假設成立。

2 測試用例和測試數據

文中研究的測試系統分別針對1類通信模組、2類通信模組、EEPROM、FLASH、ESAM、背光等智能物聯電能表的驅動程序進行測試。測試用例如表1所示。

表1 驅動測試用例

基于文中研究的測試方法和測試系統，對A、B、C電能表廠家生產的單相智能物聯電能表驅動程序進行測試，驅動測試界面如圖7所示。

圖7 驅動測試軟件界面

由圖8測試結果可知，廠家A、B、C操作系統的驅動程序功能測試均滿足要求，但是不同廠家的性能指標卻差距較大。

下面以EEPROM測試、UL_URT回環測試和FLASH固定字節數讀寫測試為例，分析各廠家性能指標情況。

(1)EEPROM測試：對EEPROM寫入數據、讀取后比較，測試點參數如表2所示。其中讀寫字節數：200字節，測試輪次：64次。

圖8 驅動測試結果界面

由表2可知，測試平均值和最小值之間相差很小，平均值和最大值之間因為進入tick或驅動存在定時器操作原因偶爾拉長時間。廠家C open接口測試時，最小值和平均值比較接近，但是最大值卻出現比較大的波動，這是由于是驅動性能存在偶發性能下降。

表2 EEPROM驅動測試用例測試數據

再進一步分析，由于操作系統tick設計為200 ms，廠家A的200次open調用總時間為15 452 μs，因此未進入tick服務，最長時間-最短時間=8 μs；200次read接口總時間為869 952，進入4次tick服務，最長時間-最短時間=38 μs。按此邏輯分析得到數據如表3所示。

表3 EEPROM測試數據

A廠家open和close測試過程中未進入tick服務，每次性能測試時間最多8 μs誤差。A廠家read和write測試過程中有進入過tick服務，性能測試時間存在38 μs誤差，即：tick服務時間約為30 μs。再次證明驅動性能測試數據誤差極小，且最長時間也較為準確。

由于B廠家和C廠家驅動程序中開啟了定時器，使得最長和最短時間差拉大；

(2)UL_URT回環測試：測試軟件控制擴展模塊模擬器將收發轉接，進行管理模組1類擴展模塊通信口回環測試。測試點參數：通信波特率：9 600 bps，收發字節數：200字節，測試輪次：5次。

由表4可知，廠家A、B、C的測試結果差異很大，特別是UL_ULT回環測試的write接口，測試時長相差巨大。因此，雖然智能物聯電能表的功能測試均滿足要求，但是其性能指標還存在較大差異，這些性能指標的差異可能會導致現場運行時死機、數據無法及時讀取等故障；

表4 UL_URT回環測試數據

(3)FLASH固定字節數讀寫測試：編寫測試FLASH驅動APP，以open/lseek/write/lseek /read/close的順序進行測試，使用隨機值對寫入數據進行初始化，比較寫入數據是否與讀取數據相同，并統計各接口調用的時間開銷。按上位機對測試點配置的參數進行兩個測試點的測試。

測試點1參數配置：固定字節數：64字節，測試輪次100次；測試點2參數配置：固定字節數：6字節，測試輪次128次。測試數據如表5所示。

表5 FLASH固定字節數讀寫測試

1)Open接口：A廠家平均耗時17 ms，B廠家平均耗時5 ms。原因是A廠家在每次open時均對底層硬件進行初始化，而B廠家只在上電時初始化一次，所以最終導致了差3倍速度；

2)lseek接口：該接口的功能是定位讀寫地址，常識考慮不對FLASH進行操作，應該速度很快，但實際由于lseek需要對緩存在RAM的數據進行FLASH回寫，產生了寫入時間開銷，最大達到160 ms，對于APP會出現明顯卡頓。lseek多次調用耗時不同，當無緩存數據回寫時只耗時40 μs，幾乎可忽略；

3)Close接口：該接口是關閉設備功能，常識考慮不對FLASH進行操作，應該速度很快。但同樣由于關閉設備時需要回寫，導致了很長的時間開銷；

4)Write接口：該接口是向FLASH寫入數據，常識考慮應該是需要很大時間開銷的。在測試點1時，由于單次寫入數據較長，無法完全RAM緩存，導致寫入操作，所以最短時間開銷也需要10 ms，而測試點2寫入數據較短，可RAM緩存，最短時間0.5 ms；

5)Read接口：該接口是從FLASH讀取數據，可反映FLASH底層SPI物理接口的速度，從測試數據分析B廠家的SPI速度約是A廠家的2倍～3倍。

FLASH驅動存在細節較多，雖然能完成功能，但在性能上各廠家差異很大，最大160 ms的開銷過大，導致APP設計較困難。

3 結束語

文中針對智能物聯電能表的驅動程序，提出了功能、性能和健壯性檢測方法。開發了驅動測試系統，可應用于智能物聯電能表驅動程序檢測，并具備擴展功能。但由于底層驅動的接口規范的開放性，接口參數較多，調用方式靈活。驅動完成所有參數要求的接口功能和各種調用方法是不可能的，各表廠所實現的功能和所能達到的性能也參差不齊。還需針對物聯電能表需求規范接口參數和調用方法。同時，由于物聯電能表性能指標沒有判定標準，當前只針對功能進行合格判定。另外，文中裝置僅測試了驅動的基本功能和調用方法。后續應根據完善的物聯電能表驅動接口和規范，按照文中系統框架進行全面的測試。再根據測試的性能明細數據進行評估，制定驅動性能指標要求，同時對驅動進行性能合格判定。