专利名称：通用告警监视处理的实现方法
技术领域：
本发明涉及告警监控处理方法，特别是具有DCS(分布式控制系统)控制结构的告警监视处理方法。
各类控制系统中一般都有告警监视模块，用以尽快发现工作过程中出现的异常状态，及时进行故障定位，利用自动或人工的干预，尽早排除故障，使系统恢复正常工作。虽然控制系统的对象不一样，需要监视的告警内容不一样，但是所要达到的目的是一样的准确迅速地将发现的异常情况反映到主控界面上。由于不同DCS系统之间有不同的告警内容，即使同-DCS系统中不同的下位机所处理的告警内容也不一样，告警点扫描周期也不一样，上告的时间间隔也要求的不同。因此目前一般在规定了上下位机的通讯协议后，由各个不同的程序员将各自的告警处理并入各自的程序中。如对于
图1的SDH光传输系统，下位机MCU包括光板，支路板，时钟板等。光板包括有光信号丢失、帧失步、复用段全1告警、管理单元(AU)全1告警、高阶管理单元指针丢失告警、复用段远端缺陷、高阶管理单元远端缺陷、10E-3误码等告警；支路板包括支路单元信号丢失告警、支路单元全1告警、低阶通道远端缺陷告警、低阶管理单元指针丢失告警等；时钟板包括外部时钟源告警，光口时钟源告警，内部时钟源告警。除以上一些传输告警，各板还有不同的设备告警。如果每个单板由一个程序员来完成，势必造成警监视模块多样化，通用性差，使将来的维护变得困难。另外，由于上下位机通讯链路的不稳定，很容易造成告警的多告，少告。
本发明的目的就在于为各类具有DCS控制结构的系统提供一种统一的告警监视处理的实现方法，将告警发送处理作为其中一个进程(SDL编程规范所定义)，采用告警状态的迁移来解决通用性问题，也避免出现少告与误告。
为了实现上述发明目的，本发明提出一种通用告警监视处理的实现方法，所有下位机向上位机发送所有告警点的告警状态，上位机接受下位机的告警消息并给予应答，后台接受上位机的告警消息并给予应答；告警监视处理方法作为其中的一个进程处理，其它应用进程可以通过消息方式与它进行通讯；其特征在于所有下位机都采用相同的告警处理模块，与上位机的告警处理模块一起通过各自的状态迁移实现告警处理；所述上位机的状态迁移过程如下a．告警状态的初始位置为(0，1)状态，上位机在收到下位机告警后，状态将迁移至(1，0)；b．(1，0)状态在上告状态为非屏蔽的情况下，将向后台上报该告警消息，并迁至状态(1，0)#；但是如果上告状态为屏蔽，则上位机不会发送该告警消息；若在(1，0)状态时收到故障恢复消息，直接变为(0，1)状态；c．当上位机收到后台的上报告警的应答消息后，状态会随之从(1，0)#变为(1，1)状态；若有恢复产生，状态则从(1，0)#迁移到(0，2)状态，并在上位机收到上报告警的应答消息后，移至(0，0)状态；d．(1，1)状态在上告状态为非屏蔽的情况下，收到下位机上报的恢复后，将迁移至(0，0)状态；若为屏蔽状态，则发送恢复消息，收到后台的发送恢复的应答后，回到(1，0)状态；e．如果此时又有告警消息产生，则(0，0)迁回(1，1)状态；反之，如果上位机向后台上报恢复消息，则(0，0)迁移至状态(0，0)#，上位机在收到发送的恢复的应答后，状态将回到起始位置——(0，1)状态；但此时若有告警上报，状态将从(0，0)#迁至(1，2)，并在收到上报过的恢复消息的应答后，回到状态(1，0)；以上各状态作如下说明(1，0)有告警，没有发送；(1，0)#有告警，已发送，但没收到应答；(1，1)有告警，已发送，已收到应答；(1，2)有告警，但正在发恢复消息；(0，0)无告警，没有发送；(0，0)#无告警，已发送，但没收到应答；(0，1)无告警，已发送，已收到应答；(0，2)无告警，但正在发告警消息；对于下位机，采用如下状态迁移；a．初始化时，所有告警的发送状态为“初始状态”；b．在发送进程中依次对每个告警根据其历史记录判断是否有告警，如发现有告警，则将发送状态变为“发送告警”，同时发送这条告警记录给上位机；若在“发送告警”状态时，告警点的故障已经恢复，仍然不改变该告警的发送状态；
c．若在规定的时间内收到从上位机的告警应答，则将发送状态变为“告警已应答”，并继续查下一个告警点；d．若发现某一条告警记录为没有告警，但发送状态为“告警已应答”，则将发送状态变为“发送恢复”，若此时告警点又有故障，仍然不改变“发送恢复”状态，同时要向上位机发送恢复消息；若在规定的时间内收到从上位机的恢复应答，则将发送状态变为“初始状态”，并继续查下一个告警点。
由于采用一种新的状态迁移方法，本发明能适应各种复杂环境，具有较强的通用性和可操作性，占用的系统资源少，也减少许多人力上的重复开发，并降低系统的维护成本；同时具有很强的抗干扰性，不会因通讯上的不稳定造成(虚警或漏警)错误的上告或少告。
下面结合附图和具体的实施例对本发明做进一步详细的描述。
图1是SDH光传输系统的层次结构示意图；图2是下位机的状态迁移示意图；图3是上位机的状态迁移示意图。
如图1所示SDH光传输系统结构图，其中每个站点由MCU模块(相当于下位机)、NS模块(相当于上位机)以及后台网管(SMN或LMT)组成。MCU模块包括光板、支路板、交叉板、开销板等，每块板都有不同的需要定时扫描的告警点。NS模块负责接受从后台网管SMN或LMT下载的数据，以使站点能在脱离SMN或LMT独立运行；另外NS模块可以保存从各MCU传来的告警记录，并发送给SMN或LMT。MCU与NS通讯，NS与SMN、LMT通讯都采用RS232串行口；MCU与NS的编程接口为S接口，NS与SMN的编程接口为Q接口。
所有模块的程序都遵循SDL的流程规范。MCU模块都采用相同的告警处理模块，负责准确及时地向NS发送所有告警点的告警状态。其告警监视处理进程需要完成以下任务1)接受其它进程(如扫描进程)得到的当前扫描结果，存入历史记录中；2)定时扫描所有告警点，根据历史记录判断告警点当前发送状态，发现有需要发送的消息即向NS发送；3)接受NS的应答消息，并迁移告警点的发送状态。
NS模块的告警处理进程需要完成以下任务1)接受所有MCU的告警消息并给予应答；2)定时向后台SMN发送当前告警或恢复消息以更新后台界面。
SMN的告警模块负责接受NS的告警消息并给予应答。这样处理后，大大减少单板软件开发人员工作量，易于维护，而且没有出现少告与误告现象。
为实现模块的高度通用性与可操作性，根据SDL编程规范，将告警监视处理作为其中的一个进程处理，其它应用进程可以通过消息方式与它进行通讯。对外则提供一张告警登记表、告警屏蔽数组、当前告警点状态数组。
告警登记表为一个三维静态数组，登记了告警名、告警的类型和告警点的性质，以适用于不同的告警对象。根据该告警登记表可以判断是否有告警，同时根据告警点的性质确定告警条件，如确定历史记录中3次中有两次出现异常状态即认为告警，也可以确定出现一次异常即认为告警等。
告警屏蔽数组用来控制当前告警点的屏蔽状态，若为屏蔽，则不需要检测或向上位机发送；其它进程可以根据需要动态地改变屏蔽状态。
当前告警点状态数组用来反映当前所有告警点的实际状态，其它进程可以随时读取当前状态。进程运行时，内部有一张与告警登记表相同长度的告警状态数组，用来记录所有登记告警点运行时的历史记录、当前的发送状态。
由于下位机MCU一般为资源比较少的8031单片机，MCU的告警监视处理进程只设了一个定时器。该定时器负责定时扫描内部告警状态数组的所有发送状态。下位机的告警发送进程对其它进程提供一个外部函数，负责更新相应告警点的历史记录。一般调用此函数的是其它定时扫描进程，这样可以共享一个定时器以对告警点的历史记录和告警发送状态实现定时更新。
为保证告警消息(与恢复消息)准确传送，采用消息应答确认与轮发机制。MCU在定时扫描内部告警状态数组的发送状态时，一旦发现有需要发送的记录，则往NS发送，每次发送一条记录，若超时没有收到NS的应答，继续在告警状态数组中找下一个需要发送的记录，若收到NS的应答，则不等到超时立即找下一个需要发送的记录。这样即保证了消息快速准确发送，又能避免由于某条告警记录无法上告而使所有告警记录无法上告。
如图2所示的下位机的状态迁移示意图，初始化时，MCU上所有告警点的发送状态定为“初始状态”，NS有一个当前告警数据库，初始化后，该数据库为空。开始运行后，MCU的定时器便定时查看所有告警点的历史记录，根据历史记录判断是否有故障，并改变相应发送状态。例如某MCU发现某告警点有告警，在此不妨设为光板发现第一光口光信号丢失告警，则光板上相应告警点的发送状态改为“发送告警”，如果该条告警没有被屏蔽，向NS的告警处理模块发送第一光口光信号丢失告警，并等待应答。NS的告警处理模块在接受到这条告警消息后，立即往当前告警数据库添加该条告警记录，并设发送状态为(1，0)，参见图3，同时给光板回该条告警的应答消息。光板如果在规定时间内收到了应答，则将第一光口光信号丢失告警的发送状态改为“告警已应答”，如果没有收到，则发下一条需要发送的告警记录。
在NS上也设一定时器，定时查看当前告警数据库，发现需要发送给SMN的记录，则往SMN发送。此时发现数据库中有光口信号丢失告警，改发送状态为(1，0)#，并向SMN发送该告警，等待SMN应答。SMN的告警处理进程收到后发应答消息给NS。NS在规定时间内收到该应答消息将告警状态改为(1，1)，否则找告警数据库下一条需要发送的记录继续往SMN发送。若故障修复，光板该条记录的发送状态从“告警已发送”改为“发送恢复”，并向NS发送恢复消息，等待应答；在规定时间内收到应答则改发送状态为“初始状态”。NS收到恢复消息，在数据库中寻找第一光口光信号告警的记录，一般该记录的发送状态为(1，1)，将其发送状态改为(0，0)。发送一次给SMN后，改为(0，0)#，在规定时间内收到应答后，则删除该条告警记录，否则，等下次再发。
以上所述为图2、图3中实线箭头所示的一般的正常流程。下位机MCU在“发送告警”、“发送恢复”状态、上位机在(1，0)、(1，0)#、(1，1)、(0，0)、(0，0)#状态也可能出现异常情况，下面介绍出现异常情况时的流程，在图2、图3中用虚线箭头表示异常情况1．若MCU在“发送告警”状态时，告警点的故障已经恢复，则因为有存储历史记录的字节，MCU仍然不改变该告警的发送状态，直到收到告警应答，才设发送状态为“告警已应答”。如此时分析历史记录确定为该告警点故障已恢复，则改发送状态为“发送恢复”，并发恢复消息。在“发送恢复”状态时，告警点又有故障的处理与上类似。
2．NS某告警点在发送状态为(1，0)时收到告警点故障恢复消息，直接删除该告警记录。在(0，0)时状态收到告警点故障消息，直接变为(1，1)状态。
3．NS某告警点在(1，0)状态时，如果上告状态为屏蔽，则上位机不会发送该告警消息，不迁移到(1，0)#；(1，1)状态在上告状态为屏蔽状态时，则发送恢复消息，收到后台应答后，回到(1，0)状态。
4．NS某告警点在发送状态为(1，0)#时收到告警点故障恢复消息，改为(0，2)状态，在收到SMN的恢复应答后改为(0，0)状态。在(0，0)#状态收到告警点故障消息，改为(1，2)状态，在收到SMN的告警应答后改为(1，0)状态。
综上所述，告警状态将按上述条件始终在一个封闭的环路中迁移，保证NS在各种情况下都可以达到某个确定的状态。
权利要求
1.一种通用告警监视处理的实现方法，所有下位机(MCU)向上位机(NS)发送所有告警点的告警状态，上位机(NS)接受下位机(MCU)的告警消息并给予应答，后台(SMN)接受上位机(NS)的告警消息并给予应答；告警监视处理方法作为其中的一个进程处理，其它应用进程可以通过消息方式与它进行通讯；其特征在于所有下位机(MCU)都采用相同的告警处理模块，与上位机(NS)的告警处理模块一起通过各自的状态迁移实现告警处理；所述上位机(NS)的状态迁移过程如下a．告警状态的初始位置为(0，1)状态，上位机(NS)在收到下位机(MCU)告警后，状态将迁移至(1，0)；b．(1，0)状态在上告状态为非屏蔽的情况下，将向后台(SMN)上报该告警消息，并迁至状态(1，0)#；但是如果上告状态为屏蔽，则上位机(NS)不会发送该告警消息；若在(1，0)状态时收到故障恢复消息，直接变为(0，1)状态；c．当上位机(NS)收到后台(SMN)的上报告警的应答消息后，状态会随之从(1，0)#变为(1，1)状态；若有恢复产生，状态则从(1，0)#迁移到(0，2)状态，并在上位机(NS)收到上报告警的应答消息后，移至(0，0)状态；d．(1，1)状态在上告状态为非屏蔽的情况下，收到下位机(MCU)上报的恢复后，将迁移至(0，0)状态；若为屏蔽状态，则发送恢复消息，收到后台(SMN)的发送恢复的应答后，回到(1，0)状态；e．如果此时又有告警消息产生，则(0，0)迁回(1，1)状态；反之，如果上位机(NS)向后台(SMN)上报恢复消息，则(0，0)迁移至状态(0，0)#，上位机(NS)在收到发送的恢复的应答后，状态将回到起始位置--(0，1)状态；但此时若有告警上报，状态将从(0，0)#迁至(1，2)，并在收到上报过的恢复消息的应答后，回到状态(1，0)；所述各状态的含义为(1，0)有告警，没有发送；(1，0)#有告警，已发送，但没收到应答；(1，1)有告警，已发送，已收到应答；(1，2)有告警，但正在发恢复消息；(0，0)无告警，没有发送；(0，0)#无告警，已发送，但没收到应答；(0，1)无告警，已发送，已收到应答；(0，2)无告警，但正在发告警消息；对于下位机(MCU)，采用如下状态迁移a．初始化时，所有告警的发送状态为“初始状态”；b．在发送进程中依次对每个告警根据其历史记录判断是否有告警，如发现有告警，则将发送状态变为“发送告警”，同时发送这条告警记录给上位机；若在“发送告警”状态时，告警点的故障已经恢复，仍然不改变该告警的发送状态；c．若在规定的时间内收到从上位机的告警应答，则将发送状态变为“告警已应答”，并继续查下一个告警点；d．若发现某一条告警记录为没有告警，但发送状态为“告警已应答”，则将发送状态变为“发送恢复”，若此时告警点又有故障，仍然不改变“发送恢复”状态，同时要向上位机发送恢复消息；若在规定的时间内收到从上位机的恢复应答，则将发送状态变为“初始状态”，并继续查下一个告警点。
2.如权利要求1所述的一种通用告警处理模块的实现方法，其特征在于所述下位机(MCU)的告警发送进程对外提供一张告警登记表、告警屏蔽数组、当前告警点状态数组；所述告警登记表用来登记告警名、告警的类型和告警点的性质；所述告警屏蔽数组用来控制当前告警点的屏蔽状态，若为屏蔽，则不需要检测或向上位机发送；所述当前告警点状态数组用来记录所有登记告警点运行时的历史记录、当前的发送状态，其它进程可以随时读取当前状态。
3.如权利要求2所述的一种通用告警处理模块的实现方法，其特征在于所述下位机(MCU)的告警监视处理进程设了一个定时器，负责定时扫描内部所述的告警状态数组的所有发送状态；对其它进程提供一个外部函数，负责更新相应告警点的历史记录。
4.如权利要求3所述的一种通用告警处理模块的实现方法，其特征在于所述下位机(MCU)在定时扫描内部告警状态数组的发送状态时，一旦发现有需要发送的记录，则往上位机(NS)发送，每次发送一条记录，若超时没有收到上位机(NS)的应答，继续在告警状态数组中找下一个需要发送的记录，若收到上位机(NS)的应答，则不等到超时立即找下一个需要发送的记录。
全文摘要
一种通用告警处理模块的实现方法,该方法为上位机、下位机提供一种新的状态迁移保证准确无误的上告,告警状态按一定的条件在一个封闭的环路中迁移,保证上位机、下位机在各种情况下都可达到某个确定的状态;本发明为各类具有DCS控制结构的系统提供一个统一的告警监视模块的实现方法,将告警发送处理作为其中一个进程,采用告警状态的迁移来解块通用性问题,并能避免出现少告与误告。
文档编号G08B25/00GK1282947SQ9911865
公开日2001年2月7日 申请日期1999年9月2日 优先权日1999年9月2日
发明者苏楠曦 申请人:深圳市中兴通讯股份有限公司