基于STM32的PROFINET IO協議棧框架的實現

周 侗，張哲睿，于 洋

(沈陽理工大學 自動化與電氣工程學院，沈陽 110159)

PROFINET是應用最為廣泛，最有前景的工業以太網技術之一[1]。可以為工業自動化領域提供完整的網絡解決方案，將整個工廠從管理層、控制層，到現場層使用同一種網絡連接起來，實現一網到底[2]。PROFINET IO是PROFINET標準中實現模塊化、分布式應用的技術。

PROFINET經過近20年的發展，成為國際市場上領先的工業以太網標準，自身技術也在不斷革新，引領著工控網絡的發展方向。其產品涵蓋領域廣闊，技術成熟。在中國市場，PROFINET在官方推廣下取得了長足發展，但仍處于技術研究和應用開發不成熟的階段，產品多為在集成了協議棧的設備上進行上層開發，底層設備往往價格昂貴，對協議棧本身配置和開發的難度較大。

考慮到國內缺少易學易用，開放靈活的PROFINET方案，本文基于應用廣泛、性價比高的STM32F407VET6主控芯片，設計了PROFINET IO協議棧，可接入PROFINET網絡平臺中，作為IO設備實現數據收發與診斷報警功能，并能夠根據用戶的需要進行靈活的配置和移植。該協議棧對處理芯片性能無過高要求，可在非運動控制的工業領域替代市場主流的ERTEC系列PROFINET解決方案，對PROFINET技術在國內的應用與普及起到積極作用。

1 協議棧結構設計

1.1 PROFINET IO通信類別

依據不同的響應時間，PROFINET IO實現的通信方式可劃分為三種，分別為

非實時(NRT)通信：通過使用基于UDP/IP的標準IT服務完成，具有100ms級的響應時間。

實時(RT)通信：用于循環數據交換，精簡了通信通道，與UDP/IP通道并行，響應時間5～10ms[3]。

硬實時(IRT)通信：用于運動控制，需要專用設備的硬件支持。響應時間小于1ms。

圖1為典型的PROFINET IO網絡結構圖。

圖1 PROFINET IO網絡結構圖

1.2 協議棧模塊結構設計

基于STM32硬件平臺的硬件特性，設計了以RT通信為最高標準的PROFINET IO協議棧框架結構，如圖2所示。

圖2 PROFINET IO協議棧框架結構圖

系統適配集成部分起到內存管理、任務管理、進程間通信與時鐘等作用[4]，通過操作系統抽象層實現；LLDP通過與鄰居交換信息起到無組態工具情況下進行設備替換的作用[5]；DCP協議用于對所有組態的IO設備進行地址解析和名稱分配[6]；CM用于設備和主站建立應用關系，通過基于UDP協議的RPC發起連接請求并參數化通信模塊。框架預留了上層應用接口，可供進一步開發。

2 通信通道設計

NRT信道的主體是UDP/IP協議，一般用于非循環傳輸，如出錯日志、設備參數化、I&M數據、詳細診斷、信息功能等[7]。出于節約內存的考慮，通過移植LwIP協議棧來實現。非實時數據收發時，分別調用udp_sendto()和udp_recv()。

RT信道主要調用LLDP、CM、DCP、DIM、ACP、IOM等模塊。下文將分別介紹實時通信處理相關模塊的功能與設計。

2.1 DIM模塊設計

DIM(數據交互狀態機)模塊是多個模塊的集合體，通過這些模塊建立與MAC層的映射，對外實現數據的發送調度和接收轉發，對內將有效信息送入相應的上層模塊中處理。本設計中，DIM可看作由兩個子模塊構成，SAC模塊負責發送調度，檢查待發送數據，并維護隊列，確保可持續使用。RTX模塊負責接收轉發，實現隊列中數據實際的收發流程。

2.1.1 SAC模塊設計

根據數據幀類型不同，SAC模塊提供三組緩沖隊列作為不同數據幀類型的入口，分別是非循環非實時隊列NRT，非循環實時隊列ART，循環實時隊列RT。NRT隊列服務于UDP/IP幀，由LwIP協議棧實現收發；ART隊列主要服務于DCP及報警、診斷報文；RT隊列服務于RT通信所傳輸的IO數據。此外，SAC線程還負責管理DSC(數據送達確認)信號量和QDS(待發送數據)隊列。線程工作時，首先初始化各個隊列和信號量緩存，然后檢測隊列中有無待發送數據。接收到數據幀后，交由RTX模塊處理發送過程。發送完成，收到隊列清空信號后，線程回到檢測狀態繼續運行。圖3描述了SAC模塊待發送隊列處理流程。

圖3 SAC模塊待發送隊列處理流程圖

2.1.2 RTX模塊設計

RTX主要通過映射訪問與MAC層進行數據交換。數據的接收轉發由RTX_ Snd和RTX_ Rec實現。由于硬件平臺不能實現等時同步發送，因此RTX_ Snd僅實現了固定優先級的軟實時發送調度。該函數將依優先級次序發送ART，RT，NRT隊列中的數據。

其中，RTX_Rec接收函數的作用是把收到的PROFINET IO幀發送至DSC隊列之中。為了讓接收到的數據可以得到及時的傳遞，接收到數據幀的第一個中斷會立即調用RTX_ Rec函數，用于快速喚醒SAC、DCP等線程，用于下一步處理。該函數可識別RT幀，并根據Frame_ ID進行處理。RT幀處理部分程序流程見圖4。

圖4 RT幀處理部分程序流程圖

2.2 IO通信模塊設計

IO模塊用于IO數據在設備內部的傳輸。數據交換按照生產者/消費者模式進行[8]。IO模塊包含了三個長度相同的緩沖區，分別是數據傳遞(D)緩沖區、用戶處理(U)緩沖區和Next(N)緩沖區。其中，D緩沖區用于存放模塊待接收或待發送的數據；U緩沖區用于存放可供等待用戶讀取或修改的數據；N緩沖區中存放的是在D狀態和U狀態間，等待進一步處理的數據，該緩沖區可避免數據在等待過程中被覆蓋或破壞，保證傳遞的安全。IO設備建立起用于IO數據交換的數據緩沖區后，通過槽和子槽進行尋址[9]。IO數據交換模塊提供了一組函數用于讀取更新緩沖區函數。其中Get_Input_IOCS()函數用于讀取數據對應模塊的消費者狀態，Set_Output_IOPS()用于設置生產者數據狀態；Set_Input與Get_Output都通過槽和子槽尋址，從對應模塊找到待處理數據，Set_Input用于設置輸入數據，Get_Output用于讀取輸出數據；New_Output函數為輸出回調函數，用于在IO模塊中有待輸出數據時通知用戶處理。

New_Output_APDU_Data_Status()用于通知用戶輸出數據的APDU狀態發生改變；Buffer_Snd函數負責判斷信息的正確性，并將輸入緩沖區的有效數據封裝成實時幀，交由DIM模塊進行發送，程序流程見圖5。

2.3 ACP模塊設計

PROFINET系統中，報警是非循環數據事件，需要發送報警信息時，會在收集診斷相關報文后，交給ACP模塊處理[10]。Alarm_Now()函數將報警幀添加到報警請求隊列中，Alarm_ Process線程依照優先級將該報文從隊列中取出發送，同時將其存放到報警應答隊列，通過Alarm_Status()函數查詢警報處理狀態以及來自主站的報警應答事件。應答隊列中找到對應的回復報文，即可確認該條報警請求處理完成。如果模塊在預設時間內未能等到主站的應答，或接收到處理警報方發送的錯誤消息，則發送錯誤消息到CM線程。

3 通信測試

測試環境的搭建通過測試設備的安裝和系統組態實現。測試平臺包含搭載了協議棧的STM32設備板，S7-1500 PLC和SCALANCE X208交換機。系統組態采用TIA Portal v14軟件。

圖5 IO通信模塊Buffer_Snd程序流程圖

首先，利用PLC 1500通過SCALANCE X208交換機連接PROFINET IO應用平臺，通過TIA Portal安裝之前編寫的設備GSD文件，并與S7-1500進行組態，完成PROFINET IO通信網絡的搭建；然后，設備板通過ENC28J60引出網線連接至PC端，搭建與putty超級終端的連接，實現對PROFINET IO應用平臺接收數據的觀測。硬件測試環境搭建實物圖如圖6所示。

圖6 硬件測試環境搭建實物圖

3.1 數據幀抓包測試

在搭建好的測試環境中，建立PLC與設備板間的循環RT數據收發，通過Wireshark監聽，并抓取其中一個報文進行解析，如圖7所示。

圖7 RT報文結構

從該數據幀解析出的信息中可知，發送端S7-1500的MAC地址為08∶00∶06∶13∶02∶11，接收端PROFINET IO設備板的MAC地址為29∶59∶43∶79∶f3∶f4；MAC地址后是以太網類型Ethertype 0x8892，代表當前通信所用協議為PROFINET RT協議；Frame_ID 0x8000，由PROFINET的編號分配可知，該幀是RT_Class_1通信報文，且APDU狀態字段顯示，RT通信正常。由測試結果可知，本文設計的協議棧能夠在一個時鐘周期內完整準確的解析與處理RT_Class_1報文，實現了RT_Class_1通信，滿足協議的實時性要求。

3.2 數據接收測試

使用虛擬HMI連接PLC，創建一個簡易的界面，并設置PLC收發數據地址關聯至HMI。在S7-1500收發數據時轉換為十進制，并顯示于HMI；設備板收發數據轉換為十六進制。為便于觀測，64bytes數據只在其中8bytes中填入非0數值，輸出數據如表1所示。

表1 輸出數據列表

終端(putty)監視到的IO設備中接收到的數據，如圖8所示。

圖8 putty接收數據結果

Data_ output Slot=1 sub=1 length=64表示槽號1，子槽1，進行的是64字節輸出，其中O_byte_0、O_byte_1、O_byte_31、O_byte_32、O_byte_33、O_byte_34、O_byte_62、O_byte_63對應接收的十六進制數據不為0，將這些putty監視應用平臺得到的數據換算為十進制后，與S7-1500發送的數據對比，發現數據無誤，證明應用平臺能夠接收PROFINET網絡的數據，完成讀IO控制器的功能。

3.3 數據發送測試

在應用平臺通信程序內指定發送內容。在發送任務中設置一組64字節數據，I_byte_0設為0x10，I_byte_1設為0x11，I_byte_31設為0x12，I_byte_32設為0x13，I_byte_33設為0x14，I_byte_34設為0x15，I_byte_62設為0x16，I_byte_63設為0x17。

應用平臺將設置好的數據通過PROFINET IO協議發送給S7-1500，S7-1500將接收到的數據存儲到本地過程映像區，并同步到TIA Portal，顯示在虛擬HMI上，如圖9所示。

圖9 控制器端接收數據結果

將發送數據換算為十進制后，對比S7-1500接收的數據，結果一致，證明了應用平臺能夠實現對IO控制器的寫數據功能。

4 結論

基于STM32平臺，設計了協議棧框架和用于NRT和RT并行通道數據處理功能的多個模塊，實現了PROFINET IO協議棧，能根據不同數據幀選擇通信模式，在保留了傳統以太網處理IT應用功能的同時，也具備了處理循環實時數據的能力。相比其他的PROFINET IO通信方案，該協議棧可移植，可靈活配置，適應性強，成本低廉，實時性達到了RT_Class_1標準，能適用于不涉及運動控制的各種工控領域。測試驗證了該協議棧的實時性和可靠性，在工廠生產控制中具有廣泛的應用前景。