MXPA99008797A - Interface for interfacing client programs with network devices in a telecommunications network - Google Patents

Abstract

Se proporciona una interfase genérica para interconectar múltiples programas de aplicación del cliente con múltiples dispositivos de red. Los programas de aplicación del cliente pueden diferir uno de los otros y pueden incluir programas de aplicación para realizar una restauración de la red, mantenimiento de la red, y administración de la red. Los dispositivos de red pueden ser de diferentes tipos de dispositivos. La interfase convierte las comunicaciones entre los programas de aplicación del cliente y los dispositivos de red, de manera que las comunicaciones sean compatibles con los requerimientos del destino. La interfase puede incluir funcionalidad agregada, tal como un mecanismo de examen automático y un mecanismo administrador de enlace de datos.

Description

INTERFACE TO INTERCONNECT CUSTOMER PROGRAMS WITH NETWORK DEVICES IN A TELECOMMUNICATIONS NETWORK TECHNICAL FIELD The present invention relates generally to telecommunications networks and, more particularly, to an interface for interconnecting customer programs with network devices. in a telecommunications network.

BACKGROUND OF THE INVENTION Telecommunication networks, such as telephone networks, include a number of different components. Typically, telecommunication networks include network devices that are interconnected by links that facilitate communications. Examples of network devices are digital cross-connections (DXCs), multiplexer equipment, completion equipment, computer systems, and fiber transmission system. A "link" as used herein is a physical connection between the network devices that carry the network's traffic. A single link can include multiple common links, where a "common link" is a logical communication channel. "With capacity that traverses one or more network devices and / or one or more links between network devices. As mentioned above, the V-network devices can be of many different types. Consider a DXC that commutates common communications links that are based on external commands. There are many different types of DXCs and there are many different vendors that sell the DXCs. Typically, each vendor device has its own set of commands and its own format for the 'data messages containing commands. Most telecommunication networks use a variety of res devices and manage those devices with common control systems, it is difficult - For example, a restoration system that restores traffic within the telecommunications network after a failure should be able to communicate with each one of the different types of devices that are used to perform the restoration. These devices include -the DXCs. The central control system must be able to send commands to, and receive messages from, each DXC within the affected area of the network. The central control system must be able to identify the type of device and the format of the commands for that device. In addition, the central control system must be able to receive messages in different formats from different types of devices, and interpret these messages from a common generic way. Many of the network devices complicate these difficulties because they are programmable devices that run a given version of the software. Identical devices can execute different versions of the software and, therefore, give rise to additional compatibility consequences.

SUMMARY OF THE INVENTION The present invention overcomes these difficulties of the prior art by providing a common interface that can interconnect multiple client programs with multiple network devices. The interface communicates with the client programs in a common format and communicates with the network devices in specific device formats. The interface can convert communications from the device-specific formats of the network device, into the common format of the client's programs. In the same way, the interface can convert the communications of the client's programs in the common format to the communications in the device-specific formats of the network devices. The interface can also include additional functionality, such as the examination and automatic monitoring of data links, to use optimal data links. In accordance with a first aspect of the present invention, a method for interconnecting a program with the network devices is performed by a computer system in a telecommunications network. An interface is provided to interconnect the program with the network devices, wherein each of the network devices has a communication format specific to the device. A first communication is received, which is intended for the selected network device, in the interface of the first format. The interface converts the first communication of the first format to a second format which is a communication format specific to the device of the selected network device for which the communication is intended. Then the communication converted in the second format is sent from the interface to the selected network device. In accordance with another aspect of the present invention, a telecommunications network includes a program running on a processor.The program adopts a communication format for communications.The telecommunications network also includes a number of network devices. , wherein each network device z has a device-specific communication format An interphase is provided in the telecommunications network to interconnect the program with the network devices to facilitate communications between the program and the network devices. it includes a converter to convert the communications from the program that are destined for the network devices, in the device-specific communication formats of the network devices.

In accordance with a further aspect of the present invention, a method implemented by computer in a telecommunications network having a network device, a processor running a program, and data links guiding the network device is practiced. An interface that interconnects the program with the network device is provided. The interface determines which of the data links is more reliable and determines the data link that should be the main link that will be used for communications with the network device. Another data link is designed as a secondary link that will be used for communications with the network device when the main link fails.

BRIEF DESCRIPTION OF THE DRAWINGS An exemplary embodiment of the present invention will be described in more detail in relation to the following figures. Figure 1 is a block diagram illustrating a portion of the telecommunications network that is suitable for practicing a first option in accordance with the present invention. Figure 2 is a block diagram illustrating the computer system of Figure 1 in more detail. Figure 3 is a block diagram of a portion of a telecommunication network that is suitable for practicing "a second option in accordance with the present invention." Figure 4 illustrates the main components of the NIFTE of the exemplary embodiment of the present invention. Figure 5 is a data flow diagram for the common interface module of Figure 4. Figure 6 is a flow diagram illustrating the steps performed by the Linear_Entrance_Commands object in Figure 5. Figure 7 is a diagram flow diagram illustrating the steps performed by the object Analyze_Entry_Commands of the_ Figure 5. Figure 8 is a flow chart illustrating the steps performed by the object NIFTE_Administrator_Data of Figure 5. Figure 9 is a flow chart illustrating the steps that performs the object Manage_Alarm_Scriptor_List of Figure 5. Figure 10 is a flow chart illustrating the steps performed by the object NIFTE_Apagar de la Figure 5. Figure HA is a flowchart that illustrates the steps performed by the Process_State_Changes object of the Figure 5 when you receive a Change_Celerity_ command Modo_Comando. Figure 11B is a flowchart illustrating the steps performed by the Process_State_Changes object of the Figure 5 when you receive a Change_Camb_Start_Command command. Figure 12 is a flowchart illustrating the steps performed by the Check_Counter_Device object of Figure 5. Figure 13 is a flow chart for the components of the specific interface module of the device of Figure 4. Figures 14A and 14B describe a flow chart of the steps that the device-specific interface performs when an examination command is received. Figures 15A, 15B, and 15C show a flow chart of the steps performed by the module of the device-specific interface when a port connection or port disconnect command is received. Figure 16 is a flow diagram illustrating the steps that are performed when the NIFTE receives an unsolicited alarm. Figure 17 is a data flow diagram for the components of the initialization module of Figure 4. Figure 18 is a flow chart illustrating the steps performed by the initialization module.

DETAILED DESCRIPTION OF THE INVENTION The exemplary embodiment of the present invention described herein provides a generic interface that interconnects the client application programs with multiple network devices. The client application programs can perform different functions that include restoration, maintenance, and administration of the telecommunications network. The interface is especially well suited for use in a telephone network, and for the purposes of the subsequent discussion, it is assumed that the interphase is used in a telephone network. The interface converts communications that originate in a common format shared by the client's application programs, in device-specific formats of the network devices. Conversely, the interface converts the communications of the network devices into the specific format of the device, into communications in the common format of the client application programs. As a result, the interface enables free communication between client application programs and network devices. The client application program does not need to have code or configuration information to communicate with each of the different network devices. Similarly, network devices do not need to have aggregate components to communicate directly with the client's application programs. The interface, therefore, greatly simplifies the ability of client application programs to communicate with network devices. The interface can be implemented in executable instructions by computer. You can implement the interface in software, hardware, firmware, or a combination thereof. As will be described in more detail below, multiple examples of the interface may be present within a given telecommunication network. The interface may include additional functionality, such as an automatic examination functionality that generates examination requests at periodic intervals without an external request. The exam request examines the network devices to retrieve the information regarding the status and configuration of the network devices. The interface may also include functionality to manage the data links that connect the interface with the network devices. This functionality enables the interface to determine which of the data links that lead to a given network device, is more reliable. This most reliable data link is designated as a main link to carry communications to and from the network device. A secondary link is also designated to serve as a backup link that becomes operational when the main link fails. The interface includes intelligence to change the links that are designated as the main link and the secondary link, in response to changing events and conditions within the telecommunications network. Figure 1 describes a portion of a telecommunications network that represents a first option under the present invention. A second option will be discussed in more detail later. A computer system 10 is interconnected with resources 12 of the network. The computer system 10 executes a number of client application programs 14A-14N, which may include an application program 14A for performing dynamic restoration of the telecommunications system network. The restoration application program 14A receives alarms from the network devices and sends commands to the devices to restore traffic in the telecommunications network after a failure. The client application programs may also include a maintenance application program 14B that sends maintenance commands to the network devices within the telecommunications system. Those skilled in the art will appreciate that different client application programs can be executed in the computer system 10 and that additional client application programs can also be executed in the computer system. In addition, you do not need to run the application programs on a single computer system, but you can run on multiple computer systems that are in communication with one another.

The computer system stores data from the real-time network device, which reflects the current configuration and topology in the network. These data can be organized in a separate database. The computer system 10 also executes an interface that is known as the front end of the network article (NIFTE). The NIFTE 18 serves as the common interface between application programs and network devices. Later, the details of the NIFTE 18 will be described. _ The resources 12 of the network communicate with the system of the computer by means of the NIFTE 18. The resources 12 of the network include a number of network devices 20A-20N. Those skilled in the art will appreciate that the network devices can be any of a number of different types of telecommunications devices, including digital cross connections (DXC). As discussed above, DXCs are devices that commute common links between different ports, with the goal of routing traffic. DXCs play a critical role in restoring the network. They can monitor traffic on their ports and generate alarms when one is detected. paralyzation. In addition, the DXCs can receive and process the commands from the restoration client application program 14A, to restore the traffic of the network. For the purposes of the subsequent discussion, it is assumed that the 20A-20N devices of the network are DXCs. The NIFTE 18 has a backup communication path for each network device via the communication gateway 24. The access gate 24 serves as a network concentrator interface between the NIFTE 18 and the network resources 12. The communication links 21 and 23 provide connectivity between the communication gateway 24 and the NIFTE 18 and the site controllers 22A-22N and the NIFTE, respectively. Communication links 21 and 23 can be standard X.25 connections. The site controllers 22A-22N provide, "access to the network devices 20A-20N A separate site controller is located at each site." Figure 2 shows a configuration of the computer system that is suitable for the computer system 10. Figure 1. The computer system includes a central processing unit (CPU) 26 which communicates with a number of peripheral devices, including a visual display 28 of video, a mouse 30, and a 32. The CPU 26 also gains access to a memory 34 and a secondary storage 36. The objects for implementing the NIFTE 18 are stored in the memory 34 together with the client application programs 14A-14N. of the real-time network device, within a standard storage 36 or resident within the main memory 34. The computer system 10 may additionally include a modem 38 to enable the storage computer system to send communications and receive communications over a telephone line. The computer system 10 may also include an adapter 40 of the network for interfacing with a network having computer resources. Those skilled in the art will appreciate that the configuration of the computer system described in Figure 12 is intended to be merely illustrative and not limiting of system configurations. As discussed above, the 14A-14N client programs and the NIFTE 18 can reside on different machines. In addition, the computer system 10 can be implemented as a distributed computing system, rather than as a single processor or personal computer system. Figure 3 describes a second option under the present invention, where multiple examples of the NIFTE are provided. In the embodiment described in Figure 3, NIFTEs 18A-18N are provided so that each of the 20A-20N devices in the network has its own corresponding NIFTE. Each example of NIFTE includes the same code, but is implemented as a separate process by the computer system 10. Each client application program 14A-14N can communicate with a given network device 20A-20N through the NIFTE associated with the network device. As shown in Figure 3, each client application program has a connection to each NIFTE. In addition, each NIFTE has access to the data base 16 of the real-time network device. Each NIFTE 18A-18N is connected to its corresponding network device 20A-20N by means of two redundant data links 42A-42N and 44A-44N, which may be, for example, X.25 data links. Each of the data links 42A-42N and 44A-44N is designated as being a main link or a secondary link for the associated network device 20A-20N. Communications between the NIFTE 18A-18N and the network device 20A-20N are performed on a link at a time when the link that is not being used serves as a secondary backup link. For each link pair, the NIFTE designates one of the links as a main link and the other link as a secondary link. Preferably, the NIFTE designates the most reliable link as the main link. In general, when the JTIFTE establishes communication with a network device 20A-20N, the connection request is sent over both links in the para of links that guide a particular network device, and the first link is designated to respond with a connection, as the main link in. where the other link is designated as a secondary link. If the main link fails, the NIFTE automatically switches its communication to the designated secondary link and changes the link designation, so that the secondary link is a new main link. It should be appreciated that each of the links 42A-42N and 44A-44N of binary data includes multiple logical communication channels. For example, a Alcatel device DXC supports four logical channels per link. The number of logical channels may depend on the type of network device. As mentioned above, 1 communication access gate 24 serves as a backup communication path, in the event that data links 42A-44N and 44A-44N fail for a particular network device 20A-20N. Each NIFTE 18 can provide administrative and maintenance functions to network devices 18A-18ST. The maintenance system 14B generates commands to perform maintenance functions such as the enabling and disabling of the binary links, the dynamic configuration of the binary links, and the change of the internal configuration parameters. Each NIFTE can also generate automatic exams of the network devices at periodic intervals. Figure 4 depicts a diagram of the high-level internal architecture of the NIFTE 18. Each example of the NIFTE 8 is comprised of three main software modules: a common interface module 50, a device-specific interface module 52, and a module 54 initialization. The common interface module 50 is responsible for 1 reception of the commands from the client application programs 14A-14N in a common format syntax. It communicates with the device-specific interface module 52 to send the commands to the network devices 20A-20N. In addition, the common interface module 50 receives the commands responses from the network devices 20A-20N by means of the common interface module 52 and sends the responses in a converted format to the client application programs 14A-14N. The common interface module 16 performs the automatic examination and administration by means of generating its own commands. The device-specific interface module 52 converts the commands from the common format into a device-specific format that is required, by the destination network device 20A-20N. The device-specific interface module 52 also receives the responses from the network devices 20A-20N and converts the responses into the common format so that the responses can be sent to the appropriate client application programs 14A-14N, by medium of the common interface module 50. Initialization module 54 performs initialization after the start of NIFTE 18. These functions include the initiation of links 42A-42N and 44A-44N of binary data, when the configuration information of the network device is determined. In the preferred embodiment, the common interface module 50 is implemented as a number of different objects. The Figure 5 is a data flow diagram showing the data flow between the respective objects of the common interface module 50. The discussion below details the functions performed by these objects. The object 62 List Lineal_Entrada_Comandos is responsible for the reception of commands from the client application programs 14A-14N and for putting these commands into linear lists for distribution to other objects within the common interface module 50. As can be seen in Figure 5, the commands 60 that received the object 62 Linear_Entrance_List Commands in the Entry_Command_List Linear 64. The following commands can be received in the object 62 List Linear_Entry_ Commands. Change_Camb_State_Comando _ Change_Cormity_Mode_Command NIFTE_Formza_Examen_Comando NIFTE_Alarma_Registro_Comando NIFTE_Puerto_Conectar_Comando NIFTE_Puerto_Desconectar_Comando NIFTE_Datos_Update_Command NIFTE_Detener_NIFTE_Command The command Change Change Status Command is responsible for changing the state of execution of NIFTE 18. The implementation status will be described in more detail later. The Change_Clevel_Mode_Command command changes the speed mode of NIFTE 18. The speed mode will also be described in more detail later. The command NIFTE_Forza_Examen_Comando causes an examination of a network device to be started. The command NIFTE_Alarma_Registro_Comando requests that certain unsolicited alarms that originate from the network devices 20A-20N be sent, to a customer application program. The NIFTE_Puerto_Conectar_Comando command instructs a network device 20A-20N to connect a port. Conversely, the command NIFTE_Port_Disconnect_Command instructs the network device to disconnect a port. The NIFTE_Data_Update_Command command updates the data within the. internal configuration of the NIFTE, or within the data the real-time network device. The command NIFTE_Data_Request_Comando requests that the data be retrieved either from the internal configuration of the NIFTE, or from the data the real-time network device. Finally, the command NIFTE_Detain_NIFTE_Comando causes the NIFTE 18 to turn off. Figure 6 is a flow chart illustrating the steps that are performed when one of the previous commands is received by the object 62 Linear_Input_CommandsLine. Initially, the command is received from one of the client application programs 14A-14N (step 140 in Figure 6).

Then, the object 62 Linear_List_Entry_Commands list adds the command that was received to the Input_Comando_Lista_ Linear 64 (step 142 Figure 6). After receiving the command, the object 62 Linear_List_Entry_Commands also sends a message 66 Set_Event to awaken 68 the object 70 Analyze_Entry_Commands (step 144 in Figure 6). Sending the message 66 Set_Event causes an awakening 68 of object 70 Analyze_Entry_Commands (step 146 in Figure 6). The object 70 Analyze_Entry_Commands is responsible for distributing the commands that are stored in the Enter_Command_List Linear 64 to the appropriate target objects. Figure 7 is a flow chart of the steps that are performed for a single recovery command using the object 70 Analyze_Entry_Commands. Initially, object 70 Analyze_Entry_Commands retrieves a command from the Enter_Command_List Line 64 (step 148 in Figure 7). Then, the object 70 Analyze_Entry_Commands identifies the type of command (step 150 in Figure 7). Based on the type of command, the object 70 Analyze_Entry_Commands determines where to distribute the command for the appropriate processing. If the command is a NIFTE_Current_Update_Data command or a NIFTE_Current_Single_Dir command (see step 152 in Figure 7), the Anal? Zar_Entry_Commands object sends the command to object 72 NIFTE_Administrator_Data (step 154 in Figure 7). If the command is the NIFTE Command_Alarm_Alarm_Alarm command (see step 156 in Figure 7), the object 70 Analyze_Coment_Input sends the command NIFTE_Alarma_Registro__Comando_ to the object 82 Manage_Alarma_Suscriptor_Lista (step 158 in Figure 7). If the command is a NIFTE_Stop__ NIFTE_Command command (see step 160 in Figure 7), object 70 Analyze_Entry_Commands sends the command to object 92 NIFTE_Apagar (step 162 in Figure 7). If the command is a Change_Camb_Command_Status command or a Change Command_Mode_Chlerhood command (see step 164 in Figure 7), then the command is sent to object 96 Process_States_Changes (step 166 in Figure 7). If the command is a NIFTE_Command_Exam_Command command, a NIFTE_Coming_Counter_Port command or a NIFTE_Port command__ Disconnect_Command, the command is sent to object 120 Verify_Command_Device (step 168 in Figure 7). As we discussed earlier, the commands NIFTE_Date_Update_Command and NIFTE_Data_Request_Command are sent to object 72 NIFTE_Datos_jAdministrator. The figure. 8 is a flow chart of the steps performed by this object. Initially, object 72 NIFTE__Administrator_Data receives the command from object 70 Analyze_Entry_Commands (step 170 in Figure 8). Then, the object 72 NIFTE_Datos_ Administrator obtains access to the data to update or recover the data, depending on the command (step 172 in Figure 8). If the update or the data request is for the internal configuration information of the NIFTE, object 72 NIFTE_Data_Administrator will have access to the internal data tables of the NIFTE to make the update. If the request or update is not for the internal configuration information of the NIFTE, access is obtained to the Real Time_Red_ Data_Device 126 from the database 16 of the data "of the real-time network device (Figure 1) to obtain access Then the object 72 NIFTE_Administrator_Data sends a response to the application program 14A-14N of the client that sent the command (step 174 in Figure 8) A response is sent 74 NIFTE_Data_Update_ Resp for each NIFTE_Data_Update_Command command receives, and sends a response 75 NIFTE_Applications_Request_Resp for each command NIFTE_Request_Update_Command that is received.In addition, the data is returned in response to the NIFTE_Data_Request_Command.Answers 74 and 75 confirm that the corresponding command was received and processed. answers 74 and 75, object 72 NIFTE_Datos_Administrador & use a _responder_list 90 that contains a list of all client application programs 14A-14N and the logical addresses for those client application programs. Object 72 NIFTE_Administrator_Data can generate a status message (Status_Msg) 78 from time to time, when certain limiting events are performed or detected.

Examples of limiting events include the detection of an error or the completion of a task about which the user knows. These status messages are kept in an internal record for NIFTE 18 and are available to users to view a report. Other objects within the common interface module 50 (Figure 4) also generate these status messages. For example, object 70 Analyze_Entry_Commands generates a message 80 Message_State when limiting events occur. Figure 9 describes the steps that the Manage_Alarm_Subscriber_list. Figure 9 is a flow chart illustrating the steps performed by the object 82 Manage_Alarm_Subscriber_List when it receives a command NIFTE_Alarma_Registro__Command from object 70 Analyze_ Input__Commands. Initially, the command is received (step 176 in Figure 9). Then, the object 82 Manage_Alarm_ Subscriber_List records the alarm request with the Alarm_Subscriber_List 84 (step 178 in Figure 9). The commands NIFTE_Alarma_Registro_Comando .al ^ sent 82 Administer _Alarma_Suscriptor_Lista are sent to a client application program to register the unsolicited alarms so that the client application program receives the alarms from the network devices 20A-20N, which usually would not send to the client application programs. The Alarm_Subscriber_List 84 is a list of client application programs that are registered by request to receive unsolicited alarms, and the list is updated and maintained by object 82 Manage_Alarm_ Subscriber_List. The object 82 Manage_Alarm_Scriptor__ List generates a response, the NIFTE_Alarma_Registro_Resp 86 to the registered client application programs 14A-14N (step 180 in Figure 9). The response confirms that the 'alarm log command' was received and processed. Object 82 Manage_Alarm_Scriptor_List uses Responder_List 90 to locate the name and address of the application program of the client to which the response is sent. Like the other objects in the common interface module 50, the object 82 Manage_Alarm_Scriptor_List will generate a Message_State 88 when certain events occur: triggers. Object 92 NIFTE_Apagar_ can receive the commands NIFTE_Detener_NIFTE_Comando from the object 70 Analyze___ Input_Commands. Figure 10 is a flow diagram illustrating the steps that are performed in that case. Initially, object 97 NIFTE_Apagar receives the command NIFTE Stop NIFTE_Comando (step 182 in Figure 10). The object 92 NIFTE_Adown generates a response (that is, the NIFTE_ Stop_NIFTE_Response 94 that it sends to the application program 14A-14N of the client that initiated the command (step 184 in Figure 10), then the object 92 NIFTE_Apagar proceeds to turn off the NIFTE (step 186 in Figure 10) Each NIFTE operates in one or two execution states: primary or backup To improve fault tolerance, the preferred mode provides two examples of the NIFTE, one that serves as the active NIFTE or This NIFTE example is executed in separate computer systems, and when a NIFTE changes from the primary execution state to the secondary execution state, the NIFTE closes its communications with the rest. of the network and abate its 42A-42N and 44A-44N binary links.While the NIFTE changes from its backup execution state to the main execution state, the NIFTE opens its links 42A-42N and 44A-44N binary and communications starts. The Change_Chan_State_ Command command activates these transitions in the execution state. The main NIFTE 18 can also operate in one of two speed modes: normal and alert. The normal mode is the nominal mode of operation in which the NIFTE performs the routing, administration and other functions. When unsolicited alarms are received that indicate a stoppage of the network, the system restore application program 14A sends a Change_Cheel_Mode_Command command to the NIFTE. This command activates a change in the speed mode, so that the NIFTE changes to the speed alert mode. In the celerity alert mode, the entire examination and background procedure ceases, and the NIFTE 18 remains ready to receive and process the commands NIFTE_Port_Connect_Connect and NIFTE_Puerto_Deconect_Command from the restoration 14A. Figure HA illustrates the steps performed by object 96 Process_States_Changes when it receives a Change_Chelling_Mode_Command command. Initially, the command is received in object 96 Process_State__Changes (step 190 in Figure HA). Then, object 96 Process_States_Changes updates the state that is maintained in Actual_NIFTE_State 98, to reflect the change in the state of speed mode. If the haste mode state is changing from normal to alert (see step 194 in Figure HA), object 96 Process_States_Changes sends a message 100 Interval_Exercise to the Time_Interval_Expert 102 to stop all automatic examination operations, which are described with more detail later (step 196 in Figure HA). When the change is from the normal state to the alert state or vice versa, object 96 Process_State_Change proceeds to suspend all exams that are in progress at that moment (step 198 in Figure HA). Incomplete initial device exams that are performed during initialization, however, are not suspended. Then, object 96 Process_Change_State sends a response 106 Change_Cheel__RespMode to the client application program that sent the initial command (step 200 in Figure HA).

Figure 11B shows the steps performed by object 96 Process_Change_State when a Change_Change_Command_Change command is received. Initially the object receives the Change_Camb_Command_State command (step 202 in Figure 11B). Then, object 96 Process_Change_State verifies Logical_System 108, which constitutes the data from the computer's operating system, which indicates the status and performance conditions of the computer, to make sure that the state change can be executed ( step 204 in Figure 11B). Then, the state that is maintained in Actual_NIFTE_Estado 98 is modified so that you notice eJ._cambio in the state. of execution (step 206 in Figure 11B). If the command is for the change in the state of execution from primary to secondary (see step 208 in Figure 11B), commands 12 are sent to the binary links to close the binary links (step 210 in Figure 11B). In addition, the message 100 Examination_ Interval is sent to the Exam_Interval_Timer 102 to stop the automated examination (step 212 in Figure 11B). In this case, the object 96 Process_Change_State then sends a response 108 Change_Chan_Resp_State to the application program of the client that sent the initial command (step 218 in Figure 11B). If the command is for a change from backup to primary (see step 208 in Figure 11B), object 96 Process Change Status reads in. Real Time_Red_Device_ - Data 110 to obtain the information that will be needed to open the binary links 42A-42N and 44A-44N (step 214 in Figure 11B). Then, a command 112 is sent to open the binary links and a message 100 Interval_Review is sent to the Time_Interval_Review 102 to initiate the automatic examination (step 216 in Figure 11B). A response 108 Change_Chan_RespState is sent to the application program of the client that sent the initial command (step 218 in Figure 11B). Object 96 Process_Change_state generates a message 114? Status_Message when certain events are activated. Object 105 Auto_Exam performs an automated examination process for NIFTE 18. The examination process automatically generates commands 116 NIFTE__Force_ Exam_Command at specified time intervals. These commands are sent to different network devices 20A-20N. The commands activate the response from the network devices 20A-20N, so that the devices specify their internal configuration. The Test_Interval_Timer 102 activates the execution of the sending of these commands 116 NIFTE_Forza_ Examen__Comando. The timer 102 sends the messages 104 Exam_Interruption to object 105 Auto_Examen, to cause the Auto_Examen object to generate the commands NIFTE Force Exam Command. These commands are sent to object 62 Linear List_ Entry__Commands. After generating this command, object 105 Auto_Examen re-establishes the Interval_Timer_Review 102 by means of sending an Interval_Review message. Object 120 Verify_Comands_Device receives and processes the commands to connect ports, disconnect ports, and force tests from object 70. Analyze_Entry_Commands. Specifically, the object 120 Verify_Comands_Device receives the commands NIFTE_Port__Connect_Cone, the NIFTE_Puerto_ Disconnect_Comand, and the NIFTE_Force_Examination_Command from object 70 Analyze_Entry_Commands. The object 120 Verify_Command_Device verifies that the commands of the type that it receives, include the necessary arguments and that it can be processed in effect through the specific interfaces of the device. Figure 12 is a flowchart of the steps performed by object 120 Verify_Comands_Device when it is processing the commands that were received. Initially, object 120 VerifyComposite_Device receives a port connection command, port disconnect, or force test (step 220 in Figure 12). After, object 120 Verify_Comands_Device gains access to the Current NIFTE state to ensure that the current operational mode 12 and execution state 124 are appropriate for the command (step 222 in Figure 12). For example, for port connection and port disconnection commands, the appropriate execution status is the main execution status and any speed mode is acceptable. However, with the force test command, the appropriate execution status is the main execution status and the appropriate speed mode is the normal mode. If the appropriate mode and status can not be verified, the command is not processed further. If, in step 222 in Figure 12, the appropriate operational mode 122 and execution state 124 have been verified, the Realtime_Red_Data_Device 126 is read to verify the command arguments (step 124 in Figure 12). For example, for the port connection and port disconnect commands, the range of the port specified in the commands must be valid. The data is also used to obtain a network address for the network device 20A-20N, for which the command was intended. If the arguments are verified, the 128 command is sent to the Linear_Computer_Device object (which will be discussed in more detail later), to process the device's specific interface module. (step 226 in Figure 12). Then, object 120 Verify_ Command_Site sends an appropriate response 130, 132, or 134 to the application program of the client that initiated the command (step 228 in Figure 12). If for some reason the command can not be sent to the specific interface module of the device, object 120 Verify_Composite_Device sends a response message indicating the inability to send the command. If the command is successfully sent; however, a response is sent to the client application program 14A-14N when the response is received from the network device 20A-20N. Figure 12 illustrates the architecture of the device-specific interface module 52 (Figure 4) in more detail. In particular, Figure 13 describes a data flow diagram showing the data flow between the objects, which comprises the specific interface module 52. As discussed above, the interface module -specific module 52 receives the client commands from the common interface module 50 in the common format and converts the commands into formats that are specific to the destination network devices 20A-20N. The converted commands are sent to the destination network devices 20A-20N, using the 42A-42N or 44A-44N data links. The device-specific interface module 52 receives the unsolicited responses and messages from the network devices 20A-20N and converts the responses and messages into the common format. The device-specific interface module 52 is further responsible for the administration of the binary 42A-42N and 44A-44N links. Among the objects in the specific interface module 52 of the device is object 230 Linear List_ Commands_Device. This object is responsible for putting in linear lists the commands of the device in the appropriate linear lists. The discussion below will focus on the steps that are performed when the object 230 Linear_Program_Command_Device receives the different types of commands: Figures 14A and 14J3 illustrate the steps that are performed when the object 230 Linear_Listener_Command_Device receives an examination command. Initially, object 230 Linear_Computer_Device receives assigns a sequence number to the examination command that uniquely identifies the example of the command (step 330 in Figure 14A). The sequence numbers are obtained from the server 234 Next_Sequence_ Number, which internally maintains the NIFTE 18. Because the command is an examination command, the object 230 Linear List_Composite_Device places the examination command in the Exam_Comando_Lista Linear 236 (step 332 in Figure 14A). Subsequently, object 252 Format_and_Present_Commands retrieves the examination command from the Command_Review_ Linear List 236 (step 334 in Figure 14A). Object 52 Format_Y_Present_Commands retrieves the commands from several linear lists and converts the common format commands used by the client application programs 14A-14N to the formats used by the network devices 20A-20N.

Then, object 252 Format_and_Present_Commands retrieves the device-specific information about the target device and the version information from the file 254 State_Device (step 336 in Figure 14A). The file 254 State_Device contains the information regarding the type of device and the version information for each of the network devices 20A-20N. The object 252 Format__Y_Present_Commands retrieves the configuration information of the device about the destination network device from the Real Time_Red_Data_Device 256 which is stored in the data base 16 of the real-time network device (Figure 1), to verify that the destination network device is configured appropriately and can receive the command (step 338 in Figure 14A). Object 252 Format_Y_Present_Commands proceeds to create an examination command in the specific format of the device (step 340 in Figure 14A). A copy of the device-specific command is then placed in the Linear Command_Exam_Review 236 (step 342 in Figure 14A). Object 252 Format_Y_Present_Commands sends a status request with reference to an examination channel 260 to object 258 Administer_Binary_Links (step 344 in Figure 14A). It is worth noting that there may be, for example, multiple channels for the binary link for most network devices 20A-20N. In that case, a channel is used for the -examination commands and is designated as the channel_examination 260. Another channel is used for the administration commands and is designated admin_channel 261. An additional channel is used for the connect / disconnect commands and designate as the channel_connector 282. A channel_normalization 271 may also be provided. Then, the object 258 Administer_Binary_Links sends a message 262 Binary_Board_State to object 252 Format_and_Present_Commands that specifies whether channel_examination 260 is available or not (step 348 in Figure 14A). If the 281_examination is not available for any of the binary links (see step 350 in Figure 14B). Object 252 Format_Y_Present_Commands rejects the command and sends a response to the client application program indicating that the command can not be processed (step 352 in Figure 14B). If, however, the channel_examination is available in the binary link (see step 350 in Figure 14B), object 252 Format_and_Present_Commands sends the formatted examination command to object 258 Manage_Binary_Links (step 354 in Figure 14b). Then, object 258 Administer_Binary_Links sends the exam command as a command 264 Binary_Device__Catching to the destination network device (step 256 in Figure 14B). The destination network device receives the formatted examination command and generates the configuration information in the form of Binary Data_Device 266 which receives the object 268 Linear_Binary_Day_Days_Datelist (step 358 in Figure 14B). Object 268 Linear_Binary_Device_Data List places the response in the Linear_Data_Data_Binary_Binary (step 360 in Figure 14B). The object 272 Analyze_Data_Binary_Backup retrieves and analyzes the data stored in the Linear_Data_Data_Binary_Binary 270 (step 362 in Figure 14B). The data is sent to object 274 Process_Exam_Response via object 272 Analyze_Data_Binary_Binary (step 264 in Figure 14B). Object 274 Process_Exam_Response places a copy of the data that was retrieved in the Linear_Link_Review Test 236 and matches the data with the original examination command (step 366 in Figure 14B). The Exam_Comando_Lista Linear_ 236 is the same linear list in which the examination commands are placed by means of object 230 Linear List_Composite_Device. Equalization of the response with the original command is achieved by matching the sequence numbers. In particular, the request includes the same sequence number as the object 230 Linear List_Complete_Device. Object 234 ^ Process_Exam_Response controls the hold of examination commands by ensuring that a command is not submitted for a particular network device, until the response is received for the last examination command. Object 274 Process_Examination_Response gains access to Real Time_ Data_Data_Risk 256 and updates this data in response to the response data that was received. Object 274 Process_Exam_Response sends the response, NIFTE_Force_Review_Resp 278 to the application program of the client that sent the original command. The Channel_Reponder_List 308 is used to determine where to send the response (step 368 in Figure 14B). Object 230 Linear_Composer_Device_ can also receive port connection and port disconnection commands from object 120 Verify_Composite_Device (Figure 5). Figures 15A-15C provide a flow diagram of the steps that are performed in the processing of these port connection and port disconnection commands within the module 52 of. specific interface of the device (Figure 4). Initially, object 230 Linear Lists_Device__Commands assigns a sequence number to the port connection or port disconnect command that was received (step 370 in Figure 15A). The sequence numbers are obtained from the server 234 Next_ Sequence_Number, which was discussed earlier. Then, the object 230 Place in Linear Lists_Compository_Device places the connection or disconnection command in the Connection_ Disconnection_Command_ Linear Lists 238 (step 372 in Figure 15A). These linear lists are dedicated to the destination network device to which the command is intended. For efficiency purposes, the connect / disconnect commands are packaged together and received and sent to the 20A-20N network devices, in packets. The maximum packet size is the maximum number of commands a particular network device 20A-20N can handle. The maximum packet interval is the time that is instructed to Linear Lists_Linear Linear Device 230 to wait before submitting a next command packet for processing. This avoids an excessive wait to collect a sufficient number of commands to connect / disconnect to realize the maximum packet size. In step 374 of Figure 15A, the object 230 Lists Linear_Computer_Device retrieves the maximum packet size (i.e., max_lot_size), the maximum packet interval (ie, max_lot_lot) 280, and the number of commands not submitted in Connection_Link_Link_List Linear 238, which is designated as No._Not Presented_Command 242. The object 230 Linear_Composite_Device_Definition determines whether the maximum packet size has been reached by comparing the No.Not Presented_Command 242 with the maximum packet size that was retrieved and also determines whether the maximum batch interval has been reached (step 376 in Figure 15A ). If the maximum packet size has not been reached or the maximum packet range has not been reached, the object must wait for the next connect / disconnect command (step 378 in Figure 15A). However, if the maximum packet size has been reached or if the maximum packet interval has been reached (as verified in step 376 of Figure 15A), the Linear_Computer_Device 230 submits the command packet to object 252 Format_and_Present_Commands for future processing (step 380 in Figure 15A). The object 252 Format_Y_Present_Commands sends the max_lot_interval to an interrupt generator 273 that generates an interrupt_breakup 275 when the maximum interval has been reached. Object 252 Format_Y_Present_Commands also sees some additional values 277 when determining whether or not to send a command. Max_Comando_Edad_Adad_Arrive to Send specifies the maximum amount of time that can be expected after a command is initially sent, before sending it again due to lack of response. The value Max_ Return to Send_Recuperations specifies how many times a command can be sent again, before the efforts have been exhausted. The value Commando_Measure specifies a maximum number of commands that can be highlighted concurrently. Object 252 Format_Y_Present_Commands retrieves the device type and version information for the destination device from file 254 State_Device (step 383 in Figure 15A). This information is used to determine the type of device and the current version information for the destination network device 20A-20N. The object 252 Format and Present Commands subsequently retrieves the device configuration information from Realtime_Red_Data_Device 256 (step 384 in Figure 15A), to determine whether the network device has been properly configured and can receive the connect / disconnect. Object 252 Format_and_Present_Commands creates a connect / disconnect command in the device-specific format of the destination network device 20A-20N (step 386 in Figure 15A). A copy of the specific command of the device is placed in the Connect_Disconnect_Comando_Lista Linear 238 (step 388 in Figure 15A). The object 252 Format_Y_ Submit_Commands sends a request for object 258 Manage Binary_Links to examine the state of the connection channel for binary links 42A-42N and 44A-44N (step 390 in Figure 15A). The object 258 Manage_Binary_Binding checks the state of the connection channels 282 of the binary links (step * 392 in Figure 15A) and sends this information in a message 262 Binary_Board_State which is sent to the object 252 Format_and_Present_Commands (step 394 in Figure 15A ) The Connect / Disconnect commands can be sent over the main communication path or the backup communication path that passes through the communication access port 24 (Figures 1 and 3). If connection channels are not available on the two main links, the secondary link can be used. In step 295 of Figure 15B, object 252 Format_Y_Present_Commands determines whether or not the connection channel is available in the binary links. If the connection channel in the main or secondary binary link is available, object 252 Format_Y_Present_Commands sends the formatted connect / disconnect command to object 258 Manage_Binary_Links (step 398 in Figure 15B). Object 258 Administer_Binary_Links sends the command as a command 264 Binary_Chip_Device to the destination network device (step 400 in Figure 15B). The destination network device receives the connect / disconnect command and generates a response. This response is sent to object 268 Linear_Binary_Data_Device_list (step 402 in Figure 15B). The object 268 Linear_ Binary_Data_Device_List places the response in the Linear_Data_Data_Binary_Binary 270 (step 4040 in Figure 15B). The object 272 Analyze_Data_Binary_DataBuilder retrieves the response from Linear_Data_Data_Binary_Binary 270 and analyzes the response (step 406 in Figure 15B).

Object 272 Analyze_Binary_Data_Device sends a response command to object 304 Process_Connection_Response (step 408 in Figure 15B). The object 304 Process_Connection_ Answer places a copy of the response in the Connect_ Disconnect Command Linear List 238, where the response is matched with the original command based on the sequence number (step 410 in Figure 15B). The object 304 Process Connection_Response updates the T35 Realtime_Red_ Device_Data 256 in view of the response. Then, the Process_Response_Processing object generates a response 310 or 312 that is sent to the client application program that sent the original command (step 412 in Figure 15B). If in step 296 of Figure 15B it is determined that the connection channel in any of the binary links is not available, the object 252 Format_Present_Commands sends a request for the state of the connection channel to the object 284 Send_Command_IDCS_Enlace (step 414 in the Figure 15B). In response, the object 284 Send_Comando_IDCS_Enlace verifies the state of the connection channel 283 in the backup link (step 416 in Figure 15B), and sends a message 286 IDCS containing the information regarding the state of the connection channel 283 in the backup link to object 252 Format_and_Present_Commands (step 418 in Figure 15B). Thus, in step 420 of Figure 15B object 252 Format_Y_Present_Commands makes a determination as to whether the connection channel in the backup link is available or not. If the connection channel 283 is available on the backup link, object 252 Format_and_Present_Commands sends a formatted connect / disconnect command to object 284 Send_Command__IDCS_link (step 422 in Figure 15B). The object 284 Send_Comando_IDCS_Enlace sends the connect / disconnect command as a command 290 IDCS_Port of Access_Command to the destination network device (step 424 in Figure 15B). The destination network device receives the command and tries to connect or disconnect the port, depending on the nature of the command. A response is sent from the destination network device. This response, the IDCS_RESP Access Gate 294, is received by the object 292 Linear List_IDCS_PA_Responses (step 426 in Figure 15B). This object 292 places the response in the IDCS_PA_Data_List Linear 296 (step 428 in Figure 15B). Object 300 Analyze_IDCS_PA_Responds retrieves and analyzes the response that was placed in the IDCS_PA_Data__ Linear List 296 (step 430 in Figure 15B). Object 300 Analyze_IDCS_PA ^ __ Answers sends the command to object 304 Process_Connection_ Response (step 432 in Figure 15B) where it is processed as discussed above starting at step 410. It should be noted that if the response that was retrieved from the list linear 296 was rather a response to an administrative command, the response would be sent to object 302 Procesar_IDCS_PA_Admin_Respuestas, which would process the response. If in step 420 of Figure 15B it was determined that the connection channel 283 is not available in the connection link, the object 252 Format_Y_Present_Commands rejects the connect / disconnect command (step 434 in Figure 15C). Then, object 252 Format_and_Present_Commands sends a response to the client application program indicating rejection (step 436 in Figure 15C). The commands that are received through the object Linear List_Composer_Device can also be administrative_commands. These commands are immediately placed in Administration__Command_List Line 240, where they are immediately presented with object 252 Format_Y_Present_Commands. The administration commands are generated by the NIFTE at startup, to configure the binary links 42A-42N, 44A-44.N, the network device identifiers and the alarm filter tables. You can send these administrative commands on admin_channel 262 to object 258 Manage_Binary_ Links, which sends the commands to the appropriate destination. Object 258 Administer_Binary_Links manages the binary links 42A-42N and 44A-44N by monitoring these links and determining the most reliable link of each pair that it designates as the main link. The object 258 Manage_Binary_Links is also responsible for switching communications from one link to the other when one fails, dynamically configuring links, and providing maintenance. Object 258 Manage_Letter_Birds ensures that there are links available by sending commands to keep assets to the network devices 20A-20N at regular intervals. The keep-alive commands cause the network devices to take no action, but instead request responses from the network devices and the corresponding link if both are still functioning properly. A Keep Assets_Timemonitor 263 activates object 258 Manage_Binelings_Links to send a command to keep assets at specified time intervals. Object 258 Manage_Link_Binary returns the Line Keeper_Tailometer 263 linear list after sending a command to keep assets by sending a message 265 Maintain Assets_Interval_Timer when Maintaining Assets_ Stopwatch 263. If a response to a command to keep assets is not received after of a certain time interval, the object 258 Manage_Binary_Links will disconnect and reconnect the link. The responses for the keep-alive commands are sent by means of object 268 Linear_Binary_Data_Device_List, which sends a message 265 Maintain Assets_Interval_Timer when Maintaining Assets ^ Stopwatch 263 to confirm the availability of the associated link. As mentioned above, object 258 Manage_Letter_Birds determines the most reliable link in a pair of binary links and designates the most reliable link as the main link. The other pair is designated as the secondary link. If the main link fails, the object 258 Manage_Binary_Links switches communications to the secondary link. As also mentioned above, object 258 Administer_Birds_Links can dynamically configure a binary link. If a configuration or maintenance of a main link is required, this object switches communications to the secondary link, designates a secondary link to be the new main link, and drops the old main link. When this configuration is complete, the secondary link that has just been designated is uploaded again, but the communications remain with the main link that has just been designated. This approach ensures the availability of communications even during configuration and maintenance activities. The previous discussion has talked about cases where object 268 Linear_Binary_Data_Device has received a response to a connect / disconnect message, a response to a hold command, or a response to an examination command. If the message is an unsolicited message indicating that disconnection of a binary link, a message is sent 267 Binario_Enlace_Estado that indicates the reception of that response to object 258 Manage_Binary_ Links.

Object 268 Linear_Binary_Data_Device_Library can also receive unsolicited alarms from network devices 20A-20N. Figure 16 is a flow chart illustrating the steps that are performed in those cases. Initially, object 268 Linear_Binary_Data_Fault_Disk receives an unsolicited alarm from a network device 20A-20N (step 440 in Figure 16). Object 268 Linear_Binary_Data_Device_List places the unsolicited alarm in the Binary_Data_Data_Dual_Binary 270 (step 442 in Figure 16). Object 272 Analyze_ Binary_Data_Device retrieves the unsolicited alarm from the linear list and analyzes the alarm (step -444 in Figure 16). Object 272 Analyze_Binary_Data_Device sends the alarm that was analyzed to the object 318 Process STo Requested_Alarms (step 446 in Figure 16). This object 318 queries the Subscriber_Alarm_Alarm Alert 320 to identify any client application programs that have been registered to receive that unsolicited alarm (step 448 in Figure 16). Then, the object 318 Process_No Requested_ Alarms formats the unsolicited alarm and sends the unsolicited alarm to the client application programs by means of sending a message 322 NIFTE_Alarm_Notification (step 450 in Figure 16). The object 318 Process_Applications_Alarms updates the Realtime_Red_Data_Device 256 with the alarm status information (step 452 in Figure 16).

Figure 17 shows the architecture of the initialization module 54 (Figure 4). Specifically, Figure 17 shows a data flow diagram of the objects that make the initialization component. As you can see in Figure 17, the initialization module includes an object 460 Initialize_NIFTE. This object 460 is responsible for starting the initialization process. As shown in Figure 18, object 460 Initialize_NIFTE receives a start message to begin initialization with a specified device number, Device_Number, 462 (step 500 in Figure 18). The Device_Number in the start message identifies a particular network device 20A-20N with which the current example of the NIFTE will establish communications. Object 460 Initialize_NIFTE starts initialization and reads Realtime_Red_Data_Device 256 to obtain the configuration information needed to open binary links 42A-42N and 44A-44N (step 502 in Figure 18). Object 460 Initialize_NIFTE also reads in Logical_System 108 from the operating system for later use (step 504 in Figure 18). The Actual_NIFTE_Estado 98 is set and sent by the object 460 Initialize_NIFTE (step 506 in Figure 18). In addition, object 460 Initialize_NIFTE sends a 464 Exam_Interval message to the Time_Expert_Timer_102 (Figure 5), to set the examination interval (step 508 in Figure 18).

Finally, object 460 Initialize_NIFTE activates the execution of object 466 Initialize_Binings_Links, object 468 Initialize_IDCS_Link, and object 470 Configure_D_evice (step 510 in Figure 18). The object 466 Initialize_Binary_Links retrieves the information that is needed to open the binary links 42A-42N and 44A-44N from the object 460 Initialize_NIFTE. This is the information that was retrieved from object 256 Real Time_Red_Data_Device by object 460 Initialize_ NIFTE. Object 466 Initialize Links_Binary sends a message with the configuration data to object 258 Manage_Link_Binary (Figure 13) to open the binary links (step 512 in Figure 18). Object 468 Initialize_IDCS_Enlace receives the data from object 460 Initialize_NIFTE to open the backup link. Then, object 468 Initialize_IDCS_ Link sends a message with this data to object 284 Send_Command_IDCS_Link (Figure 13), to open the backup link (step 514 in Figure 18). "Object 470 Configure_Device initiates administrative processing.This object 470 sends administrative commands 474 to network devices 20A-20N to request information from those devices (step 516 in Figure 18) .The commands include the Set_Node ID command , the Retrieve Software_Version command, and the command Configure_Alarm_Filters The responses 472 for these commands are received subsequently by the object Configure_Device.From the foregoing, it will be appreciated that, although specific embodiments of the invention have been described herein for For purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention In accordance with the foregoing, the invention is not limited except by the appended claims.

Claims (30)

1. In a telecommunications network having network devices and a processor, wherein the processor executes at least one program to communicate with the network devices and each of the network devices has a device-specific communication format, a method for interconnecting the program with the network devices, comprising the steps implemented by computer of: - providing an interface for interconnecting the program with the network devices; receiving a first communication destined for one of the network devices selected from the interface program in a first format; with the interface, convert the first communication from the first format to a second format which is the specific communication format of the device of the selected network device; and sending the first communication converted in the second format from the interface to the selected network device. The method according to claim 1, comprising the steps of: receiving a second communication from the program at the interface, the second communication being destined for a given network device that is a different one from the network devices of the first communication, and the second communication being in the first format; with the interface, convert the second communication from the first format to a third format which is the specific communication format of the device of the network device -given; and send the second communication converted in the third format from the interface to the given network device. 3. The method of compliance with the claim 2, wherein the selected network device and the given network device are different types of network devices. The method according to claim 2, wherein the selected network device and the given network device are the same type of network device that executes the programmable instructions, but the selected network device and the given network device they run different versions of the programmable instructions. The method according to claim 1, characterized in that it also comprises the steps of: receiving a second communication that is destined to the program from a given network device in the interface, the second communication being in a specific communication format of the device of the given network device; with the interface, convert the second communication from the device-specific communication format of the given network device, to a format that is compatible with the program; and send the second communication converted to the interface program. The method according to claim 5, wherein the second communication is a response from the given network device to a communication that was sent from the program. 7. The method of compliance with the claim 5, wherein the second communication is an unsolicited alarm indicating a problem in the telecommunications network. 8. The method according to claim 1, wherein the telecommunications network is a telephone network. 9. The method of compliance with the claim 1, where the processor executes multiple programs or the interface interconnects the multiple programs with the network devices. The method according to claim 1, wherein multiple examples of the interface are provided, so that a separate example of the interface is provided for each network device. The method according to claim 1, wherein the first communication is a command to request the selected network device to perform an action for the program. The method according to claim 11, wherein the command is an examination command that asks the selected network device to provide information about the status of the selected network device. 13. The method according to claim 1, wherein the selected network device is a digital cross connection (DXC). The method according to claim 1, wherein the program is a restoration program for restoring the network from a failure. 15. In a telecommunications network having network devices and a processor, wherein the processor executes at least one program to communicate with the network devices and each of the network devices has a communication format specific to the device, a computer readable medium containing computer executable instructions for performing a method for interconnecting the program with the network devices, comprising the computer-implemented steps of: providing an interface for interfacing the program with the network devices; receiving a first communication destined for one of the network ces selected from the interface program in a first format; with the interface, convert the first communication from the first format to a second format which is the specific communication format of the device of the selected network device; and sending the first communication converted in the second format from the interface to the selected network device. 16. The computer readable medium according to claim 15, wherein the method further comprises the steps of: receiving a second communication from the program at the interface, the second communication being intended for a given network device it is a different one from the network devices of the first communication, and the second communication being in the first format; with the interface, convert the second communication from the first format to a third format which is the specific communication format of the device of the given network device; and send the second communication converted in the third format from the interface to the given network device. 17. The computer readable medium according to claim 15, wherein the method further comprises the steps of: receiving a second communication that is destined to the program from a given network device at the interface, the second communication being in a device-specific communication format of the given network device; with the interface, convert the second communication. from the device-specific communication format of the given network device, to a format that is compatible with the program; and send the second communication converted to the interface program. 18. The computer readable medium according to claim 15, wherein the telecommunications network is a telephone network. 19. The computer readable medium according to claim 15, wherein the processor executes multiple programs and the interconnection interconnects the multiple programs with the network devices. 20. The computer readable medium according to claim 15, wherein multiple examples of the interface are provided, so that a separate example of the interface is provided for enetwork device. 21. A telecommunications network, comprising: a program execution on a processor, the program having a communication format for communications: network devices, enetwork device having a communication format specific to the device for communications; and an interface to interconnect the program with the network devices to facilitate communications between the program and the network devices, the interface including: a first converter to convert the communications from the program that are destined for the network devices within the device-specific communications formats of the network devices. The telecommunications network according to claim 21, wherein the interface additionally includes a second converter for converting communications from the network devices into the communication format of the program. 23. The telecommunications network according to claim 21, wherein the network is a telephone network. 24. The telecommunications network according to claim 21, characterized in that it also comprises at least one additional program execution on the processor, which communicates with the network devices and where the interface interconnects the programs with the network devices. 25. The telecommunications network according to claim 21, wherein the program is a restoration program for restoring the network from a fault. 26. The telecommunications network according to claim 21, wherein the interface includes a scanning mechanism to automatically examine at least one of the network devices, to obtain information regarding the status of the network device without a request originating from outside the interface for the examination. 27. The telecommunications network according to claim 21, wherein at least one of the network devices is a digital cross connection. 28. The telecommunications network according to claim 21, wherein the network devices include devices of different types. 29. In a telecommunications network having a network device, a processor that executes a program, and data links that guide the network device, a method comprising the computer-implemented steps of: providing an interface that interconnects the program with the network device; with the interface, determine which of the data links is more reliable; designate the link that was determined to be the most reliable as a primary link to be used for communications with the network device; and designate another of the data links as a secondary link that will be used for communications with the network device when the main link fails. 30. The method according to claim 29, characterized in that it further comprises the step of changing the designation of links to designate another of the data links as the main link, in response to a change in the conditions in the network.