關于報警概念，即損害自動化系統正確運行的事件必須作為報警發送給控制系統。報警來自與現場設備相連接的過程，稱之為過程報警，例如溫度超過上限；報警來自現場設備本身，稱為診斷報警，例如插拔模塊。發生過程報警時，設備仍然能正常工作。診斷報警標識為入向“Incoming”或者出向“Outgoing”來表示報警的到來和離開，而過程報警僅傳遞一個入向“Incoming”消息。

PROFINET 可以基于槽/子槽組合以及相關通道的進行報警起源定位，以及通過接口模塊中的報警-ASE（Alarm Service Entity：報jingfu務實體）發送實時非循環的高優先級（5,6）報警傳輸至高層控制器。PROFINET 只會對發出的診斷報警保存在模塊的診斷緩存中，并在接口模塊上存在該報警信息的映射。此時控制器或者監視器可以利用數據記錄關系Record data-CR來讀取緩存中的診斷信息。診斷報警作為消息保存在報警ASE中，直到它們被明確消除并由上層控制器確認為止。而過程報警則不記錄在診斷緩存中，而是被報警-ASE直接發出，不過IO模塊存在過程報警的隊列，例如ET200SP 的一個8DI HF模塊可以緩存9個過程報警。

設置IO設備中的DI模塊，組態通道4的硬件中斷，當電壓出現上升沿就會立即觸發報警，這樣的報警可以認為是過程中出現的緊急狀態，即過程報警。過程報警不會對RTC的APDU狀態產生任何影響，不觸發任何設置，這樣的報警直接由控制系統評估，例如，硬件中斷“Hardware interrupt”組織塊OB40。

給該通道輸入高電平，觸發該通道過程報警，使用Bany捕捉相關的報文。過程報警通過PNIO-AL 幀（序號2588）發出報警，在報文中標記該報文FrameID=0xFC01，優先級為6（PRI：6）的高優先級報警（Alarm High）。同樣在“Alarm Notification”信息包含了明確的故障信息，報警類型“AlarmType”為過程“Process”報警。使用API 0x0，槽0x0001/子槽0x0001組合以及模塊標識符0x00004d4d來明確故障的位置?！癆larmSpecifier”和“UserStructureIdentifier”與過程報警無關?！癠serData”=0x00010401才是過程報警中的故障原因。

根據該訂貨號6ES7131-6BF00-0CA0 8DI模塊手冊中對于過程報警的描述，“UserData”=0x00010401其中所表示的USI=0001，該USI用于表示硬件中斷的信息。發生的通道號為0x04，即通道4發生過程報警，此報警通過上升沿（Rising edge=0x01）觸發。該過程報警信息中包含通道號，這樣如果出現兩個通道的硬件中斷，控制器針對ET200SP的報警要分別完成，也就是說先對一個通道的報警確認后，才能接收另外一個通道的報警。

打開OB40，編寫一段程序，延遲5秒鐘，同時在CPU的屬性“Cycle”中設置大循環時間“Maximum cycle time”為6000ms，取消小循環周期的限制“Enable minimum cycle time for cyclic OBs”。在變量表中使能“Trigger”，同時設置“Cycle_number=500”。觀察此時通道4上的硬件中斷報警信息。

報文298為IO設備所發送的通道4的硬件中斷報警信息，使用“Ctrl+T”設定該幀的時間為參考點，那么報文594作為應用層OB40該過程報警的應答，可見與298之間的時間差值為5秒鐘，這與OB40中程序的延遲時間相同。報警應用OB40需要5秒鐘的時間來確認該報警，這意味著報警應用OB40的運行時間影響報警的響應速度，這樣在這段時間內會導致實際現場應用無法對產生的其它的硬件中斷進行響應。所以為了更快的響應其它硬件中斷，硬件中斷組織塊，例如OB40的運行時間盡可能的小。該規則同樣也適用診斷中斷，例如OB82，同樣也盡可能的縮短運行時間。

同一模塊同一時間段可能觸發多個過程報警，但是過程報警Queue隊列有限，當緩存的報警超過隊列中所能緩存大的過程報警數量時，該模塊會發送診斷報警，通知控制器有中斷丟失。報文597為通道4新的硬件中斷報警，598為控制器的協議層應答，OB40開始處理此報警，708的出現意味著緩存的過程報警數量超限，從而該模塊（Slot:0x1/0x1）發出的診斷報警通知控制器硬件中斷丟失（CPU緩沖區可見），但控制器并未對708進行協議層應答，這是因為默認情況下OB40的中斷優先級高于OB82，1.6秒超時后只能通過序號804報文對708報文進行重傳，在OB40結束后，897和899分別對708和804進行協議層應答，同時898也對597完成此硬件中斷的應用層響應，而901是控制器對于診斷中斷（804和708）的應用層應答。

OB40作為過程報警的應用程序對過程報警進行處理，由于其具有很高的優先級（默認16），會中斷其它的組織塊的運行，例如OB82，即使在程序中不插入OB82，這意味著更高優先級的中斷處理時間盡可能的短，這樣可以盡快的響應其它類型的報警，這也意味著控制器無法同時處理兩種不同類型的報警。序號804報文的報警通知“Alarm Notification” 信息包含了明確的故障信息，報警類型“AlarmType”為診斷“Diagnostis”報警。使用API 0x0，槽0x0001/子槽0x0001組合以及模塊標識符0x00004d4d來明確故障的位置。USI=0x8000表示隨后的信息為通道診斷報警，ChannelNumber=0x8000代表整個子槽，通道錯誤類型“ChannelErrorType”為“Process event lost/sampling error”，表示過程事件丟失/采樣錯誤。

這次就整理到這里，后面會整理使用RLARM和RDREC對于診斷報警的讀取的奇妙之處，并不是為了使用功能塊來診斷PROFINET，而是為了通過報文來理解報警中所用到的USI，AR，Slot, Subslot，ModuleIdentNumber等等。歡迎大家隨時提問。