Health checker for EMS CORBA notification listener

A system and method is described for checking the health status of a communication pathways between an EMS and a notification listener that receives notification signals from the EMS when changes have occurred in a downstream electronic system architecture.

BACKGROUND

1. Field of the Invention

The present invention relates to systems and methods for determining the proper functioning status of listening processes for monitoring communications between electronic components connected via a network. More particularly, the present invention relates to systems and methods for determining the operational status of listening processes that receive information regarding changes in downstream architecture and relay such information upstream using a CORBA interface.

2. Background of the Invention

In the increasingly sophisticated field of electronic communication, particularly between electronic systems or machines, the TL-1 line protocol has remained a common industry standard. TL-1 lines are used as a communication medium between different electronic systems or machines, particularly in Internet- and telecommunication-related systems. However, TL-1 commands are typically very specific and limited to the type of systems or machines that utilize such lines. For example, each distinct system component may require its own unique TL-1 commands or inputs that take into account the specifics of the particular component.

Such a need for detailed characteristics makes use of TL-1 commands generally complicated and time-consuming. Further, TL-1 commands used by different system components make it difficult for the components to communicate with one another, even though all use the general TL-1 command protocol. Finally, much detail is required to determine the specific programming characteristics of each hardware component that is being connected with a given TL-1 line. Thus, although ubiquitously used, TL-1 lines have a number of limiting characteristics.

One of the most limiting characteristics of a TL-1 line is that it does not allow for efficient communication between interconnected hardware. For example, if a change is made in a downstream component of an electronic system, it would be very difficult for an upstream component to receive “real-time” information about that specific downstream change. Typically, when a downstream change is currently made to, for example, a component of a system, such change is communicated to an upstream programmer by the person who has made such a change in the downstream component. Such a requirement for the person who creates changes to communicate them “manually” to upstream programmers is inefficient and prone to errors, such as when the person forgets to relay such information to upstream programmers.

As a further non-limiting example, if an electronic switch or card is changed in a downstream component of an electronic network, TL-1 lines connecting the series of network components to an upstream programmer would not efficiently allow the programmer to be cognizant of the change. Such a programmer may receive some indication that a change was made in that specific downstream component if the programmer sends a specific command related to that changed component and the component responds, because of the change, in a way that the programmer was not expecting. This conventional “reactive” method of determining changes downstream is inefficient and prone to errors, particularly when the upstream programmer is not aware of the downstream changes.

Thus, there is a need for systems or methods that automatically update the status of a system architecture as it changes in “real time” in an effective and efficient manner. Additionally, there is a further need for a central processing center to receive all the information from downstream components, and reforms the information into a universal language that is understandable by an upstream component. To that end, there is a need for an automated system health checker that determines whether the communication pathways between the downstream components and the central processing center is viable or not.

SUMMARY OF THE INVENTION

In exemplary embodiments of the present invention, systems and methods are presented that verify and determine the operational status of communication pathways to listening processes in “real time”. Such listening processes enable an upstream component, such as, for example, a “notification listener”, to become aware of downstream changes in network architecture. As a non-limiting example, a status operation monitor process electronically communicates to the listening process, which is informed of downstream changes in machinery or system configurations when such changes occur, any comprises in communication pathways to the listening process as close to “real time” as possible. In other words, the status operation monitor determines whether the listening process's communication links with the downstream components are impaired. Such health status monitors may operate by, for example, periodically determining whether each of the communication pathways to the listening process are operating properly.

In one exemplary embodiment of the present invention, a system is disclosed for monitoring proper operation of a communication pathway between an EMS and an upstream notification listener. The system includes an EMS that receives a notification signal transmitted by an electronic component when a change has been made in the electronic component, a notification listener in communication with the EMS through a communication pathway, wherein the notification listener receives the notification signal from the EMS through the communication pathway, and a health checker in direct communication with both the EMS and the notification listener, wherein the health checker monitors the health status of the communication pathway by transmitting a health status signal to the EMS and detecting a reply signal from the EMS.

In another exemplary embodiment of the present invention, a system is disclosed for checking proper function of an electronic architecture that allows transmitting of real time information upstream. The system includes an EMS in communication with an electronic architecture, a signal translating device in communication with the EMS through a communication pathway, and a health checker in communication with the EMS and the signal translating device, wherein the health checker monitors proper function of the communication pathway by signaling the EMS and detecting an expected reply signal from the EMS.

In yet another exemplary embodiment of the present invention, a system is disclosed for checking the health status of an architecture for relaying information relating to changes in electronic architecture configurations. The system includes an EMS which receives a notification signal transmitted by an electronic component when a change has been made in the electronic component, means for receiving in communication with the EMS through a communication pathway, the means for receiving receives the notification signal from the EMS and translates it into a universally understandable format, and means for checking the proper operation of the communication pathway.

In another exemplary embodiment of the present invention, a method is disclosed of checking health status of a communication pathway between an EMS and a notification listener that receives notification signals from the EMS relating to changes in a system architecture. The method includes transmitting a health status signal to the EMS, and detecting a reply signal from the EMS in response to the health status signal, wherein if no reply signal is detected, then the communication pathway is not operational.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The systems and methods according to the present invention utilize a universal interface between machines to enable better communication in either direction. Such a universal interface may be, for example, CORBA, which will be described in more detail below. However, the present invention is not limited to CORBA and may use any other type of universal interface that facilitates communication between two or more machines in electronic communication. Other possible languages and technologies include, but are not limited to, RPC, RMI, and COM.

Showing an exemplary embodiment graphically as system100inFIG. 1, a network management system (“NMS”)110communicates with one or more electronic management systems (“EMS”)120and121through telecommunication pathways112and113, respectively. Telecommunication pathways112,113and others shown here and throughout this disclosure may be any common type of electronic communication medium that connects two electronic machines, unless otherwise indicated.

A given NMS may be, for example, a telecommunications company, and may have hundreds of EMS connecting to it. The NMS110shown inFIG. 1may be part of an asymmetric digital subscriber line (“ADSL”) operated by, for example, a telephone or telecommunications company. Each EMS120and121has control of one or more systems or machines in communication with it. For example, EMS120is in communication and in control of digital subscriber line access multiplexer (“DSLAM”)140. Similarly, EMS121is in communication and in control of asynchronous transfer mode network150(“ATM NETWORK”).

In exemplary system100shown inFIG. 1, a given user, such as a user in home130, is in communication with DSLAM140through communication pathway135. Also, DSLAM140is in communication with ATM NETWORK150through communication pathway145. Finally, ATM NETWORK150is in communication with a network service provider or Internet service provider (“NSP/ISP”)160through communication pathway155.

A programmer using the NMS110system may evaluate the conditions of the downstream components DSLAM140and ATM NETWORK150through use of EMS120and121, respectively. Furthermore, the proper operation of NSP/ISP160may also be evaluated by EMS120or121. For example, to evaluate the condition of DSLAM140, a programmer may send a signal through NMS10that is transmitted along communication pathway112to EMS120, and along communication pathway122to DSLAM140to evaluate its condition. If DSLAM140is not operating properly, the return signal from DSLAM140back to NMS110may indicate a malfunction. In a similar fashion, NMS110may determine the proper function of ATM NETWORK150using EMS121through communication pathways113and123.

Any anomalies in any component of the system100may be determined by NMS110and subsequent changes and repairs may be made. Although such a system100is typically effective in testing for proper operation of system components, it is “reactive” to changes that have already been made in the system. Further, system100does not detect a change when the change occurs but after a test signal is sent out, and is thus not “proactive” in considering such changes as they occur, for example, in “real time”.

The exemplary embodiment of a reactive system100shown inFIG. 1is merely one type of many possible types of reactive, synchronous systems. A more generic explanation of reactive and proactive systems is now provided for understanding the advantages realized from utilizing a proactive system, in accordance with the present invention.

A more generic example of a system having both reactive configurations, as is common in conventional systems, and proactive configurations, with exemplary embodiments of the systems or methods of the present invention shown herein, is shown as system200inFIG. 2. In this system200, an NMS210is in communication with one or more EMS220through exemplary communication pathways212and213. EMS220is also in communication through communication pathway221with one or more graphic user interfaces (“GUI”)230, which allow control and testing of EMS220. Further, one or more switches240may also be in communication with EMS220through communication pathway222.

Communication pathways212and213, although they both connect NMS210with EMS220, operate in different ways and therefore have different capabilities. Communication pathway213is based on open system interconnection (“OSI”) or CORBA communications protocol and is conventionally used as a two-way communication path. For example, when a signal is sent by NMS210to verify the operation of a downstream switch240, the signal travels along communication pathway213to EMS220, through communication pathway222, and to switch240. When the status of switch240is determined, then a signal is sent back through communication pathway222to EMS220, and then through communication pathway213, back to NMS210. Thus, communication pathway213may operate in both directions, NMS210to EMS220and EMS220to NMS210, and is thereby termed “synchronous” to indicate that for a given signal that is projected from NMS210, a corresponding return signal is returned to the NMS210that corresponds to, or is “in sync” with, the original NMS210signal.

Some of the limitations of utilizing only communication pathway213in system200become evident when a programmer changes a component or operation of the system200downstream of NMS210. For example, if a programmer using GUI230changes a function or operation of EMS220, for example, by changing a card stored within EMS220, such change is not registered into NMS210automatically. Usually, the programmer who affected such a change downstream in system200contacts an operator of NMS210and informs the operator of the change, thereby enabling the operator to make such a change in the configurations of NMS210to reflect the downstream change. This requirement of the programmer downstream having to communicate “manually” any changes in the downstream component of system200with an operator of NMS210to note such changes in NMS210configuration upstream is both inefficient and unreliable. If, for example, the programmer fails to make the operator of NMS210aware of the changes, then NMS210is not changed to reflect the true downstream architecture, and errors could result during operation of NMS210.

Alternatively, an operator of NMS210may be able to detect changes in the system200that have occurred downstream of NMS210if while a synchronous command operation through communication pathway213, a return message is received that is unexpected or specifically indicates that a certain operation is not possible because a certain downstream component is not in operation or has been changed. Although such reactive information gathering sometimes may be helpful in understanding what downstream changes have been made, it is inefficient and may result in wasted resources if such downstream changes are difficult to detect immediately. An operator of NMS210who notes that certain changes may have been made in the system without notification of NMS210, may not be able to discern what those changes were, and may have to spend wasted time and resources in determining such changes.

Thus, a need exists to efficiently and effectively communicate any downstream changes in an exemplary system200with the upstream NMS210to allow NMS memory architecture and design to be updated to reflect the true architecture of the system200. Communication pathway212may be used for such an “asynchronous” system that communicates upstream any changes that have been made downstream, in near “real time”. Thus such an exemplary asynchronous pathway212may be one directional, from downstream to upstream, and is activated upon effecting a change in the system architecture anywhere in system200downstream of NMS210.

Using the same scenario described above with respect toFIG. 2but with an “asynchronous” reaction system, if the same switch240is changed downstream in system200, NMS210will be alerted to this change automatically by a notification message that traverses upstream through EMS220and through communication pathway212into NMS210. To make such asynchronous messaging strategies effective and efficient, a “CORBA” interface is used in conjunction with communication pathway212to enable efficient and rapid inter-machine communication possible.

This “CORBA” is an alternative to the TL-1 protocol and stands for common object request broker architecture. CORBA is object-oriented, which means that the language or commands are structured in such a manner such that many machine interfaces may use it and thereby communicate effectively with each other. Thus, CORBA has the potential to unify the languages used by different electronic systems and machines into a single command language that is understandable by many different systems. A variety of systems, such as, for example, UNIX, SOLARIS, WINDOWS, DOS, and embedded systems, may support CORBA commands. Thus, CORBA may be universally supported by different computer systems that previously were not able to communicate with each other effectively.

Use of a universal command language and interface, such as CORBA, decreases time requirements for personnel, such as, for example, programmers, controllers, engineers, and technicians, who previously had to concern themselves with much detail of each new machine that was to be communicated with each existing system into the specifics of the language required by each machine. For example, when connecting a new machine to an existing system using a conventional communication line, such as for example, a TL-1 or similar line, the specific characteristics of the new machine must be considered in constructing a TL-1 command language that enables the new machine to communicate with the existing system. Such a stringent requirement is not necessary when using CORBA interface such that with CORBA, the machines are, for example, only instructed about what functions they are to perform, rather than having to the consider the specifics of the machine.

Having considered a universal interface language, such as, for example, CORBA, as the operating language of such an asynchronous notification system, another exemplary embodiment of such a system300is shown inFIG. 3. In system300, an NMS310is located upstream in system300and thereby has control over the operations of the system. One or more EMS332,334,336,338, and362are in communication with NMS310through one or more communication pathways331,333,335,337, and361, respectively.

Each such EMS332,334,336,338, and362may also be in communication and/or in control of one or more switches. Such additional switches and downstream components are not shown in this figure for sake of simplicity. A single exemplary switch370in communication with EMS362is shown as an example. However, each EMS, such as EMS362, may be in communication with one or more switches or other components (not shown for sake of simplicity).

Each switch, such as, for example, switch370, may control a given function of one or more customers372,374, and376through communication pathways371,373, and375, respectively. Thus, a given NMS310may have control over countless components downstream, including, for example, EMS332,334,336,338, and362, switch370, and customers372,374, and376.

In order to keep track of all such changes to the downstream components of system300, NMS310may use a notification listener320that receives all signals of change from downstream components, translates each signal into an understandable universal format through CORBA interface, aggregates all such changes into a common nucleus, and forwards such change notifications in translated form to NMS310. Notification listener320acts as a “central processing station” that receives, translates, aggregates, and filters incoming signals. Further, notification listener320is extensible and may expand to accommodate additional numbers of EMS inputs and other components.

Upon processing incoming notification messages from various EMS332,334,336,338, and362, notification listener320unravels the message, and determines which component sent the message and what the message is. Then, notification listener320represents the information in a fashion that is more easily understandable by upstream NMS310, and forwards the processed and translated messages to NMS310through communication pathway315. Optionally, before the forwarded message reaches NMS310, it first passes through a CORBA access server312(“CA Server”), which acts as an entry point to NMS310and may control and filter messages that reach NMS310. Although NMS310is shown in the figures herein as a single block or component for sake of simplicity, NMS310may comprise two or more software components operating independently and in coordination with each other. Thus, CA Server312acts as a gateway to these sets of software components that in conjunction constitute NMS310.

Any changes in system components of system300may be automatically relayed to NMS310through notification listener320using a common interface language, such as CORBA. A “trigger” enables the system300to know that a change has been made within it. This trigger may be made inherent in the hardware. For example, a trigger may be a set of higher level self diagnostic rules defined by a manufacturer. Such a trigger may be initiated by an action such as a technician physically pulling an electronic card, or a controller card trying to communicate to a lesser card but failing to do so. When such a triggerable condition is detected, the hardware may communicate this information to its controlling EMS software system. Other types of triggers, for example, based on software that periodically checks for system components, are possible.

If the CA Server312or NMS310have become non-operational because, for example, either has crashed, then messages from notification listener320are unable to reach NMS310. Hence, such messages may then be re-routed through communication pathway351to queue handler350, which may store the messages and all future messages that are also unable to reach NMS, in the order received. Queued messages in the queue handler351remain stored in queue until both CA Server312and NMS310are again operational, and any such messages are then forwarded to NMS310through communication pathway352.

Notification listener320may detect that CA Server312is non-operational through a number of different ways. For example, if CA Server312is non-operational, attempts to communicate with it using CORBA interface will give rise to an alert condition, which may be called an “exception” in technical terms. So while notification listener320tries to transmit a notification to CA Server312, and such an attempt fails and initiates an alert condition, this is an indication that something is wrong with the communication with CA Server312. At this point, a CORBA-provided checking mechanism may be used to determine whether CA Server312exists at all. Such an exemplary procedure may be used by a technician to determine whether CA Server312is functional. Other procedures are also possible.

Although the notification listener described in each of the above exemplary embodiments is a very useful tool in automatically determining any changes in an electronic system architecture in “real time”, communication pathways leading to the notification listener may malfunction and prevent information, such as notification signals from reaching the notification listener. As shown in the exemplary embodiment ofFIG. 4, a system400may have a notification listener420, as described above, which may be in electronic communication with one or more EMS432,434, and436through communication pathways431,433, and435, respectively.

Notification listener420may be generally controlled or monitored by a command interface450through communication pathway451. Command interface450enables an operator to specifically change, add, or delete EMS communication pathways to notification listener420or command the notification listener420to reconnect to a remote EMS through a given communication pathway. Other general maintenance functions are also possible through the command interface420, which may be an integral component of notification listener420or may be separate and distinct component as shown inFIG. 4.

To monitor the healthy operation status of the communication pathways between notification listener420and corresponding EMS, EMS health checker460is in communication with command interface450through communication pathway461. EMS health checker460is primarily responsible for determining that a healthy communication pathway is being maintained between notification listener420and any remote EMS.

There are multiple ways that EMS health checker may be used to automatically check the healthy status of the communication pathways between notification listener420and a given remote EMS. Although an exemplary methods is presented herein, the EMS health checker460is not limited to such a method, and other methods are possible. Further, inFIG. 4, EMS health checker460is shown separate from command interface450and notification listener420for sake of clarity, but they may be part of the same system or set of programs.

In an exemplary embodiment, EMS health checker460receives information from a given EMS when the EMS is electronically communicated with notification listener. For example, EMS432,434, and436communicate FILE1, FILE2, and FILE3, respectively, to EMS health checker460when a healthy communication pathways exists between each EMS and notification listener420. Further, EMS health checker periodically checks for such a healthy communication pathway between EMS and notification listener to ensure that any potential information from EMS would be received by notification listener420.

One exemplary way EMS health checker460checks for proper communication pathway health is to transmit a signal to a given EMS and await a reply by the EMS with the given file type. For example, to determine a healthy communication pathway between EMS432and notification listener420, EMS health checker460transmits a signal to EMS432and awaits a reply. If a reply is detected by EMS health checker460, then communication pathway431should be healthy because the output connection of EMS432is transmitting signals properly.

If, however, there is no response from exemplary EMS432, then there may be an unhealthy communication pathway. EMS health checker460may thus signal that pathway431or one or more components in it are not operating in a healthy manner. Such a determination may, for example, automatically signal for the non-healthy pathway to shut down or alert a programmer as to the defect. Optionally, when such an “unhealthy” discrepancy exists, command interface450may be signaled to induce notification listener420to re-connect to EMS432using communication pathway431to determine whether the re-connection will again establish a healthy communication pathway between notification listener420and EMS432. If after command interface450instructs notification listener420to re-connect with EMS432, and such re-connection attempt is unsuccessful, then the connection may be shut down altogether.

Because of the constant and periodic checking signal nature of EMS health checker460in determining a proper remote connection of EMS to a communication pathway leading to notification listener420, such a health checking process is substantially continuous, and any unhealthy status is determined in “real time”. The frequency of health checking may be set to correspond to a reasonable rate of signal checking without overburdening the system400.

The exemplary systems and methods described above according to the present invention have many advantages. One such advantage is the automated nature of the health checker system. Whenever a downstream change is made in an electronic architecture under the control of a specific NMS, the system enables that NMS to become aware of the change in the architecture through a notification signal derived from the point of change in the architecture. In other words, the specific area that receives a change in status notifies its controlling NMS upstream that the change has been made and that the NMS should make note of such a change in its cumulative architecture of the entire system. Such “asynchronous” notification signals are constantly being transmitted upstream through durable and efficient CORBA lines that enable fast object-oriented communication between components and machines in the communication lines between the point of change and the desired upstream NMS. The automated health checker promotes the proper operation of the system in real time and may serve to automatically fix any problem that may exist by, for example, re-connecting the components, and/or alerting programmers of an unhealthy condition.

Another unique advantage of the systems and methods according to the present invention is its ability for rapid expansion and thus determining health status of communication pathways of an ever-increasing system. New EMS modules may be added to an existing architecture very rapidly without typical concerns associated with TL-1 lines, such as, for example, concerns with the details of the machines and systems being added. Use of CORBA in attaching new system components and machines enable rapid expansion because of CORBA's characteristic object-oriented language protocol that does not require component or machine specifics.

Using the exemplary systems and methods described herein, the proper communication of EMS information to an upstream NMS via a notification listener may be automatically monitored when an NMS system is automatically notified of signals downstream that communicate changes in, for example, network creation/deletion notifications, configuration changes of ADSL network equipment, fault and alarms of network equipment, and other signals that an NMS system should be aware of. In response to such signals, NMS may make note of such changes and change the architecture of the entire network within its memory, reply with its own commands, or notify a programmer that such changes have been made, thereby letting the programmer be aware of changes that may need immediate attention, such as, for example, network failure.