根据该订货号6ES7131-6BF00-0CA08DI模块手册中对于过程报警的描述，“UserData”=0x00010401其中所表示的USI=0001，该USI用于表示硬件中断的信息。发生的通道号为0x04，即通道4发生过程报警，此报警通过上升沿（Risingedge=0x01）触发。该过程报警信息中包含通道号，这样如果出现两个通道的硬件中断，控制器针对ET200SP的报警要分别完成，也就是说先对一个通道的报警确认后，才能接收一个通道的报警。
打开OB40，编写一段程序，延迟5秒钟，在CPU的属性“Cycle”中设置Zui大循环时间“Maximum cycletime”为6000ms，取消Zui小循环周期的限制“Enable minimum cycle time for cyclicOBs”。在变量表中使能“Trigger”，设置“Cycle_number=500”。观察此时通道4上的硬件中断报警信息。
报文298为IO设备所发送的通道4的硬件中断报警信息，使用“Ctrl+T”设定该帧的时间为参考点，那么报文594作为应用层OB40该过程报警的应答，可见与298之间的时间差值为5秒钟，这与OB40中程序的延迟时间相同。报警应用OB40需要5秒钟的时间来确认该报警，这意味着报警应用OB40的运行时间影响报警的响应速度，这样在这段时间内会导致实际现场应用无法对产生的其它的硬件中断进行响应。为了更快的响应其它硬件中断，硬件中断组织块，例如OB40的运行时间尽可能的小。该规则同样也适用诊断中断，例如OB82，同样也尽可能的缩短运行时间。
同一模块同一时间段可能触发多个过程报警，过程报警Queue队列有限，当缓存的报警超过队列中所能缓存Zui大的过程报警数量时，该模块会发送诊断报警，通知控制器有中断丢失。报文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报文的报警通知“AlarmNotification” 信息包含了明确的故障信息，报警类型“AlarmType”为诊断“Diagnostis”报警。使用API0x0，槽0x0001/子槽0x0001组合以及模块标识符0x00004d4d来明确故障的位置。USI=0x8000表示随后的信息为通道诊断报警，ChannelNumber=0x8000代表整个子槽，通道错误类型“ChannelErrorType”为“Processevent lost/sampling error”，表示过程事件丢失/采样错误。
这次就整理到这里，后面会整理使用RLARM和RDREC对于诊断报警的读取的奇妙之处，并不是为了使用功能块来诊断PROFINET，而是为了通过报文来理解报警中所用到的USI，AR，Slot,Subslot，ModuleIdentNumber等等。欢迎大家随时提问。
