光伏逆變器老化系統的設計與實現

張鴻博，張 偉，于 靜，陳儒敏

（北京科技大學天津學院 信息工程學院，天津 301830）

0 引 言

國內某大型電力設備制造企業下轄多個產品事業部，隨著近年來碳中和、節能減排和新能源政策的穩步推進，其光伏事業部營業額一直穩居各部門前列[1-4]；尤其在2022 年初，由于公司獲得德國TUV 技術認證與ISO9001 認證，光伏逆變器（下文簡稱“逆變器”）系列產品進一步打開歐洲市場。在俄烏戰事不明朗的形勢下，石油、煤炭、天然氣等歐洲依賴度較高的化石能源價格高漲，且面臨短缺甚至斷供的可能性，但短期內歐洲各種能源的消費水平無法下降[5-6]。因此，在2022 年5 月后，歐洲出貨渠道的訂單量出現爆發式增長。

為滿足出口訂單的要求，公司一方面加大產能，臨時抽調其他事業部技術工人支援光伏事業部；另一方面，采取三班倒的工作模式，進一步激發產線潛能。在采取以上措施后，近3 個月的訂單基本達到預期目標，但也暴露出一些問題。首先，出貨依然面臨巨大的壓力。進入8 月中下旬后，歐方客戶的需求進一步增長；相當比例的客戶不但在商務談判階段給出超出預期的優惠價格，而且后續訂單需求翻番，同時交貨時間緊迫，以期應對秋冬季的能源危機。這就要求公司進一步優化生產流程，打通關鍵節點以釋放產能。其次，與以往公司出口客戶不同，歐方客戶對產品的要求更高。甲方普遍希望公司采用產品全生命周期的過程管理，對逆變器從零件采購、組裝生產、封裝測試、物流運輸、安裝運行等各個階段的數據可追溯可查詢[7]。最后，管理層意識到最近幾個月是難得的戰略機遇期，公司將以此為契機，在滿足逆變器訂單出貨的情況下，對企業內部各個子系統，如OA/ERP/MES/SCADA 等進行進一步整合；同時對行政業務、流程控制等進行優化升級，為企業下一階段發展奠定基礎。

為完成上述目的，公司組織業務骨干與第三方機構進行調研，得出以下結論：第一，在零件采購、整機生產等前期階段，由于公司已有的ERP/MES 系統應用已相對成熟，未發現可以大幅度提高生產效率的環節。第二，在光伏逆變器出廠前的老化測試階段，除去老化測試的程序已寫入逆變器控制邏輯，此部分屬于自動化控制外，在其他的批次控制、歷史數據記錄、過程控制等環節，事業部目前采取人工抽查、紙質記錄的方式，尚未形成自動化的流程機制。這種情況下，一方面，效率低下，多批次老化試驗間的切換浪費大量時間，人為記錄失誤率高；另一方面，未形成全批次全部設備的電子化數據記錄。第三，光伏事業部已有的SCADA系統，即XX 公司光伏運維智能管理平臺（下文簡稱“光伏平臺”）的功能相對完善，在平臺開發階段預留出了二次開發的接口，對于單臺逆變器的老化測試控制邏輯已基本具備。但OA/ERP/MES 系統由于是外包開發，系統的可擴展性不足，短期內難以相互整合[8-9]。綜合考慮開發成本和實現難度后，公司亟需開發一款光伏逆變器老化系統（下文簡稱“老化系統”），以做到逆變器老化測試流程的自動化處理，并與原SCADA 系統整合，將老化階段的數據進行全周期電子化記錄。

1 系統的開發要求

系統開發的總體原則是在短時間內，利用已有的平臺，以最小的工作量開發出一套既能實現批量老化測試，又能與現有SCADA 系統融合、記錄測試數據的自動化控制系統。具體的要求如下：

（1）開發調試周期盡量短，要求一周內完成；

（2）界面美觀，測試數據盡量以圖形化的形式展示；

（3）盡量利用事業部已有的軟硬件條件，減少開發成本；

（4）逆變器的控制流程，可以借助已有的光伏平臺實現，不必在新系統中重復開發。

（5）考慮到產線工人的計算機能力相對不足，老化系統的操作務必簡單，方便培訓及應用。由一名操作工即可完成整體老化測試流程。

（6）老化系統具備較強的防誤操作機制，老化測試開始后，操作員只能查看當前實驗記錄的歷史數據，不得擅自終止實驗。

（7）自動控制某批次老化測試的流程。當設備上線率達到95%以上，開啟老化測試；設備離線率達到50%以上，終止本批次實驗。某批次測試開始后，操作工無須進行其他操作。

（8）全周期記錄本批次逆變器老化測試過程中的逆變器電壓、電流、報警信息，存入本地數據庫中，批次完成后可以導出測試數據報表，由技術負責人確認簽字后存檔。同時，光伏平臺開發可以訪問老化系統數據庫的子模塊，將測試數據記錄到產品設備全生命周期數據中。

2 系統架構及硬件設計

老化系統的設計分為流程設計、軟件設計、數據庫及表結構設計等多部分，本章內容詳細講述系統架構及硬件設計。

由于系統開發要求盡可能應用現有硬件環境，不增加開發成本的條目，故老化系統計劃沿用事業部內的現有老化測試臺架、通信網絡和工位電腦，只涉及軟件及流程方面的開發。如圖1 所示為光伏事業部現有的逆變器老化測試臺架示意圖。此部分裝置統一安裝在事業部售前產品測試區域內，電源采取獨立雙回路380 V 動力供電，以保證供電穩定性。測試場地占地300 m2左右，方形布局，場地外設置有隔離柵欄及警示標語。每個測試臺架有5 層，單臺架容量為40 臺/套逆變器，共10 排臺架。在單臺操作工位上，預留有兩相/三相電源接口；同時，安裝有支持ModBus 通信的RS 232 通信線。電源線接口安裝在工位左側卡槽內，通信線接口在工位底部卡槽；在臺架電纜鋪設中，電源線與通信線之間設計了電磁屏蔽裝置，以避免強弱電信號相互干擾。逆變器集成有物聯網通信模塊，其IoT 天線在測試階段一般安裝在機箱上方。在測試區四個角落及正中央，安裝有無線信號放大器，以增強信號強度。

圖1 老化測試臺架結構示意圖

圖2 為系統整體架構示意圖。

圖2 系統整體架構示意圖

首先，對系統整體架構所在的運行環境作簡要說明。出于數據安全性與工廠供電可靠性的考慮，光伏平臺未安裝在事業部所在的廠區內部。光伏平臺系統較為復雜，由Web 服務器、通信前置機服務器、數據處理服務器、報警服務器、數據庫服務器等多臺服務器構成集群，部署在阿里云端上。服務器的日常維護由阿里云提供，事業部技術人員只關注平臺運行的情況。此部分服務器所在的外網，經由數據隔離裝置可以訪問事業部所在廠區的內部網絡。

其次，逆變器安裝有物聯網通信模塊，可以經由物聯網模塊和三大電信運營商提供的數據服務，與光伏平臺進行通信。通信規約及策略已經分別部署在逆變器內和光伏平臺，無須重新開發。在某批次老化測試開始后，安裝在老化測試臺架上的各臺逆變器通過RS 232 線與部署在工位電腦上的老化系統進行通信。

再次，老化系統部署在工位電腦上，通過公司內網與廠區內歷史庫服務器通信。外部客戶可以通過光伏平臺新開發的數據接口，訪問存儲在歷史庫數據庫中的某批次老化測試的數據。

最后，老化測試中，控制老化測試各步驟的任務主要是在單臺逆變器與光伏平臺間通信完成的。而工位電腦上部署的老化系統主要任務是被動接受各逆變器經由光伏平臺回傳的測試數據，并進行存庫。同時，對測試批次進行總體把控。這樣一方面能利用光伏平臺原有的逆變器完整通信及控制流程，減少新系統開發工作量；另一方面，可以令研發人員重點關注新系統的整體控制流程、生產自動化方面的需求。

3 系統軟件設計

軟件設計為本系統開發的重點，分為單臺逆變器老化的流程設計、光伏平臺端子模塊的設計、工位電腦端老化系統設計和數據庫設計4 個子模塊，下面分別進行詳細闡述。

3.1 單臺逆變器老化流程設計

單臺逆變器老化流程涉及到老化系統、光伏平臺和逆變器三部分的信息交互，具體流程如圖3 所示。

圖3 單臺逆變器老化流程設計

由圖3 可見，完成單臺逆變器的老化流程需要17 個步驟。圖中3 條豎直粗線條代表老化測試各階段的控制流程，其間的箭頭代表數據流和控制流；箭頭上方文字代表測試步驟的序號和名稱，箭頭下方文字代表數據流所應用的通信規約。比如第一個箭頭上方文字為“A.逆變器開機”；下方文字為“ModBus”，箭頭由老化系統指向逆變器，指代操作步驟A 是完成逆變器開機的任務，通信數據采用ModBus 規約由老化系統發往逆變器。

老化系統主要承擔測試臺架上逆變器的開關機，逆變器信息核對和記錄測試過程中的數據。逆變器的開關機命令采用ModBus 規約，通過鋪設在老化測試臺架卡槽中的RS 232通信線下發。由老化系統與逆變器直接進行通信。該命令改變逆變器設備開關量中任何一路的輸出狀態。它包括子站地址（逆變器地址）、功能碼、開關量地址、特征數據和CRC校驗碼。其中，功能碼05H 代表下發的數據屬于遙控數據。控制開關機的特定遙控地址是0000H，特征數據FF00H 使遙控開關量輸出狀態為ON，即遙控輸出繼電器接點閉合，逆變器開機；特征數據0000H 使遙控開關量輸出狀態為OFF，即遙控輸出繼電器接點打開，逆變器關機。開機報文見表1所列。其中數據均為16 進制數據，多字節數據項的排序方式為低字節在前，即小端方式。

表1 ModBus 規約開機報文示例

信息校驗步驟中，主要是老化系統針對某批次老化測試中的各臺設備做信息核對，比如驗證逆變器的ID 號、逆變器的生產日期等。在校驗完成后，老化系統將下發逆變器允許上線的命令，通信報文經由公司內網傳至光伏平臺，通信規約采取WebService 消息格式，具體在4.2 節詳述。然后，光伏平臺通過Q/GDW376.8 規約[10]，將命令經由物聯網發送至逆變器，逆變器端設備自動進入老化測試過程。在測試過程中，逆變器每15 min 采用Q/GDW376.8 規約上送光伏平臺一次電壓、電流、功率因數、電量值等信息；光伏平臺接收數據后，轉變規約格式，采用WebService 消息格式傳送至老化系統。老化系統在成功解析數據后，將測試記錄存入數據庫，并在界面做相應展示。在測試過程中，遇到報警信息，如電流過大、電路板溫度過高、電容擊穿等緊急情況，光伏平臺根據相應的處理流程向逆變器下發控制命令，同時將報警信息抄送至老化系統。在老化過程中，老化系統只被動接收光伏平臺轉發的逆變器的各種測試信息和報警數據，不直接參與單臺逆變器的老化控制流程。待某批次逆變器全部完成老化測試，或者完成度達到設定指標臺數后，本批次老化測試結束。

3.2 光伏平臺端模塊設計

光伏平臺端的任務在整體項目中屬于次要部分，主要負責逆變器與老化系統間信息的傳輸，以及讀取老化系統歷史庫記錄。在原光伏平臺中，已完整實現逆變器Q/GDW376.8規約的控制流程，新項目中無須重復開發，只需要開放出老化測試部分的功能即可。在信息傳輸階段，采用WebService消息的形式，與老化系統進行通信，具體的通信規約各字節定義見表2、表3 所列。

表2 老化系統->光伏平臺的WebService 消息格式

表3 光伏平臺->老化系統的WebService 消息格式

通過表2、表3 可以看出，WebService 消息采用報文分區的定義格式，每部分分區中再分出次一級定義字段；整體報文格式采用Q/GDW376.8 報文內嵌入WebService 消息的格式。在表2 中，報文分區的消息頭（CWEBCOMNT_MSG：：MSG_CLIENT_HEAD）部分msg_type 的值恒為1，代表此類報文需經由中繼平臺（即光伏平臺）在老化系統與逆變器之間通信；uuid 的消息ID 在老化測試流程開始后初始值為0，發送一幀值加1；其他字段如onlysend_flag、oper_type、nextframe等的值為固定的，是為老化測試定制的數值；任務頭分區（CWEBCOMNT_MSG：：MSG_TASK）中的subst_id 字段電站ID 一般默認設置成0，指代出廠前測試站的ID；在任務體分區（Data）中的data_frm 內填充入Q/GDW376.8 報文即可，實際長度不定。表3 中的各報文分區和字段含義與表2 類似。

由于老化系統與光伏平臺之間交互任務分工略有不同，光伏平臺發送至老化系統的報文多為確認信息類報文，所以WebService 消息體的設計略顯簡單。而老化系統發送至光伏平臺的消息還需要經過進一步解析后轉送至逆變器，因此消息體設置更為復雜，增加了信息校驗、多重字節長度確認等字段。

光伏平臺端另一部分設計任務在于讀取老化系統歷史數據庫中的測試數據，并形成電子版的報表，添加到對應逆變器的全生命周期管理信息中。此部分功能主要調用JDBC 接口來連接內網中的歷史庫服務器讀取數據，然后將測試數據填入預先設計的報告模板中。因其流程相對較簡單，此處不贅述。

3.3 老化系統設計

老化系統是需求的重點，其軟件設計的流程如圖4 所示。

圖4 老化系統流程設計

在某批次老化測試開始前，需要產線工人按要求整理本批次參加老化測試的逆變器信息，并形成CSV 電子檔案。文檔中包含逆變器總臺數，每臺逆變器的ID 號、型號、功率等信息。在老化測試開始后，系統先進行初始化檢測流程，主要檢查本系統與光伏平臺間的網絡監聽端口通信情況、歷史庫鏈接情況，并讀取本地工位電腦時間，存入日志中。網絡監聽端口及歷史庫連接參數可以通過圖5、圖6 的XML文件進行配置。為方便展示，將兩圖中的原始文件格式稍作調整。

圖5 網絡監聽端口配置XML 文件

圖6 歷史庫配置XML 文件

工位電腦的操作系統為Windows7 或Windows10，為避免出現中文亂碼的情況，編碼方式采用GB2313。監聽端口的等待時間設定為60 s。

在完成初始化檢測后，將由產線工人整理的CSV 檔案讀入老化系統，系統根據檔案中的信息在歷史庫中新建本批次老化測試的數據表。然后，老化系統以ModBus 規約格式通過RS 232 通信線向臺架上的各逆變器發送開機命令，開機報文格式詳見表1 所列。逆變器收到開機命令后，經由物聯網向光伏平臺發送請求上線的Q/GDW376.8 報文；隨后光伏平臺將其封裝成WebService 消息轉發至老化系統。在老化系統端，將消息中的逆變器具體信息解析后與歷史庫中信息進行核對，如一致則允許逆變器待上線；當同批次的逆變器待上線數量達到設定值后，老化流程正式開始。在老化流程中，系統將每臺逆變器的測試數據與報警信息存儲入歷史庫服務器，歷史庫中的各數據表格式將在3.4 節中詳細說明。同時，在軟件的操作界面上，數據及報警信息用數據圖和區分度明顯的表格來展示，詳見第4 章。待所有逆變器完成測試流程后，本批次老化測試結束。

3.4 歷史庫設計

考慮到老化系統開發時間較為緊張，歷史庫的設計定位在滿足應用需求的情況下盡量簡單。整體數據庫設計為5 張數據表，其中4 張表格用于記錄老化測試的批次和具體數據值，1 張表格為報警信息索引表，具體見表4 ～表8所列。

表4 實驗參數

表6 實驗設備數據

表7 實驗設備報警

表8 報警索引

表4 記錄老化測試的某批次實驗名稱和信息。其中，Testid 作為表格主鍵，由老化系統按順序默認賦值，不可人為修改。Testname 是某次實驗的名稱，當新建實驗后，系統自動讀取工控電腦本地時間，命名為“實驗批次-YYYYMM-DD hh-mm”。實驗名稱可根據需要人為修改。Devnum是本批次實驗的逆變器臺數，需要人工輸入。Starttime 和Endtime 兩字段采用UTC 時間，在系統中自動編程進行轉換；數據格式定義為Int 是為節省存儲空間。

表5 記錄某批次老化測試中的具體逆變器信息。Verifyid字段記錄單臺逆變器的驗證ID 號。數據表主鍵為Testid 和Verifyid，通過二者聯合能夠定位出具體的逆變器出現在哪次老化測試批次中。

表6 記錄老化測試過程中逆變器的測試數據。其中，Dtime 字段是逆變器數據上報時間，一般規定每5 min 上送一次數據；但由于每臺逆變器上送數據時刻不同，故在老化系統數據展示界面中，每分鐘刷新一次，以降低數據的延遲；此字段同樣采用UTC 時間。Status 代表逆變器當前的工作狀態：0-關機，1-開機，2-待上線，3-工作，4-故障，5-測試，在老化測試流程中，可能會出現除狀態3 外的其他值。Data1 ～Data40 是逆變器的各項數據，如A、B、C 三相電壓以及電流、頻率、功率因數等。

表7 中存儲歷次老化測試出現的報警信息。Level 字段代表報警的等級，本系統設計3 種：0-普通故障/狀態，1-一般故障，2-嚴重故障。普通故障/狀態只有待機、運行兩種取值；一般故障下逆變器可以帶故障運行，嚴重故障下逆變器必須停機。Descrip 字段描述報警的具體信息，其字符串由系統自動生成，格式為：“Devname”在XX 時間出現“Desc”故障；時間由Dtime 自動換算成北京時間，“Desc”通過查詢表8 中的對應字段得到。

表8 是不可更改的報警信息索引表，以供生成具體設備的記錄信息。同時，Info 字段詳細描述故障的細節。表8中的信息在老化系統部署階段，通過SQL 語句進行插入，如下所列舉的幾條SQL 語句所示，總共126 條，其中inverteralarm 是數據表的名稱。

4 界面設計與實現

老化系統界面布局如圖7 所示。界面左側列出實驗批次；菜單欄設計新建實驗、停止、退出3 個按鈕；右側數據區分為3 類選項。圖7 中展示的是參數部分，列有設備名稱驗證ID 和通信相關的數據。新建實驗按鈕顯示灰色，因截圖所示的最新批次實驗已開啟，按鈕不可操作。圖中顯示為2017 年的虛擬測試數據。

圖7 老化系統界面布局

當產線工人點擊新建實驗的按鈕后，彈出圖8 所示的新實驗批次命名及設備數量確認界面。

圖8 新建實驗界面

圖9 和圖10 展示了數據界面的情況。圖9 是數據的數值展示；在雙擊某個數值單元格后，能打開截止到上一數據刷新時刻的數值曲線界面，如圖10 所示。

圖9 數值展示界面

圖10 數值曲線界面

報警界面如圖11 所示，對于嚴重故障，即表7 和表8中Level 值是2 的報警數據，記錄標紅；對于一般故障標黃，普通故障/狀態不變色。

圖11 報警界面

在某批次實驗完成后，操作員可以從左側實驗批次導出實驗數據，交由負責人簽字存檔。如圖12 所示，實驗批次的刪除只是在界面展示段不顯示，不會將測試數據從歷史庫中刪除。

圖12 數據導出界面

5 結 語

本文針對光伏事業部出現的逆變器產能不足問題，對于老化測試階段設計出一套光伏老化測試系統。本系統能與原有光伏平臺進行初步整合，并自動控制老化實驗流程，降低人為失誤概率，顯著提高生產效率。經過一周的研發測試后，成功交付事業部應用，取得了良好效果。下一步，考慮將系統與行政職能部門的OA/ERP/MES 進一步整合，以提高公司的信息化程度。