这次我们谈谈PN的报警，因为这部分内容正好是我近期整理的内容，所以整理完之后和大家分享一下，由于时间仓促，如果有理解错误或者概念不清晰，希望大家多多提建议，也希望和大家多多交流。

关于报警概念，即损害自动化系统正确运行的事件必须作为报警发送给控制系统。报警来自与现场设备相连接的过程，称之为过程报警，例如温度超过上限；报警来自现场设备本身，称为诊断报警，例如插拔模块。发生过程报警时，设备仍然能正常工作。诊断报警标识为入向“Incoming”或者出向“Outgoing”来表示报警的到来和离开，而过程报警仅传递一个入向“Incoming”消息。

PROFINET 可以基于槽/子槽组合以及相关通道的进行报警起源定位，以及通过接口模块中的报警-ASE（Alarm Service Entity：报警服务实体）发送实时非循环的高优先级（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来明确故障的位置。“AlarmSpecifier”和“UserStructureIdentifier”与过程报警无关。“UserData”=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等等。欢迎大家随时提问。