DE69832096T2 - NETWORK MANAGEMENT - Google Patents

Description

TECHNICAL FIELD OF THE INVENTION

These The invention relates generally to the field of telecommunications. More particularly, the invention relates to a method of providing a software interface according to the preamble of Claim 1 and to a telecommunication platform, which is an interface according to the preamble of Claim 10 forms. A procedure and a telecommunications platform of this type are from MALTINTI P ET AL: "OSI SYSTEM AND APPLICATION MANAGEMENT: AN EXPERIENCE IN A PUBLIC ADMINISTRATION CONTEXT "1996 IEEE NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM (NOMS), KYOTO, 15.-19. April 1996, Volume 2, No. SYMP. 5, April 15, 1996 (1996-04-15), page 492-500, XP000634813 INSTITUTES OF ELECTRICAL AND ELECTRONICS ENGINEERS, known.

It It is an object of the present invention to provide a general interface between application programs, the telecommunication functions To run, and an operating system that is on at least one Node is running in one location, which supports the application programs, and continues to be generic Interface between the application programs and a telecommunications network to build.

This The object is achieved by a method according to claim 1 and by a Telecommunication platform according to claim 10 reached.

According to the present The invention will provide a method of providing a software interface between Application programs that perform telecommunications functions, and an operating system that resides on at least one node in a location running, which supports the application programs, and continues to be generic Interface between the application programs and a telecommunications network forms, provided. The method includes the provision a network platform manager that is able to node out to take the service back to service applications to take the service and put applications back into service, the provision of a network system integrity manager, who is able to monitor the nodes and failed ones Node to allow a restart providing a configuration manager who is capable is an interface with one with the telecommunication platform coupled host, providing a node platform manager, capable of providing management functions for a node providing a service manager who is able to Node platform manager instruction to start processes and stopping and providing a Node System Integrity Manager, which is able to monitor connections between the nodes.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better one understanding The present invention may be applied to the accompanying drawings Be referred to, in which:

1 Figure 5 is a simplified block diagram of the telecommunications platform architecture layers according to an embodiment of the present invention;

2 Figure 5 is a simplified block diagram of the conceptual components of the telecommunications platform according to one embodiment of the present invention;

3 Figure 4 is a block diagram of the conceptual components of the telecommunications platform and their relationships with each other according to an embodiment of the present invention;

4 Figure 5 is a simplified block diagram of the logical partition of the telecommunications platform according to an embodiment of the present invention;

5 Figure 5 is a simplified block diagram of the telecommunications platform services and their dependencies according to an embodiment of the present invention;

6 Figure 5 is a simplified block diagram of the physical distribution of the telecommunications platform according to an embodiment of the present invention;

7A Figure 10 is a block diagram of the NetPM test flow according to an embodiment of the present invention;

7B Fig. 10 is a block diagram of the NetPM time synchronization flow according to an embodiment of the present invention;

7C Fig. 10 is a block diagram showing error detection and interaction between network management services and node management services in accordance with an embodiment of the present invention;

7D Fig. 10 is a block diagram showing the interaction between core services according to an embodiment of the present invention;

8th a state transition diagram of telecommunications platform nodes according to an embodiment of the present invention;

9A Figure 5 is a simplified block diagram of the node startup process according to an embodiment of the present invention;

9B a message flow diagram of the node initialization process according to an embodiment of the present invention;

9C a message flow diagram of the node initialization process according to an embodiment of the present invention;

9D a message flow diagram of the node initialization process according to an embodiment of the present invention;

10 a message flow diagram of the service management interface protocol according to an embodiment of the present invention;

11 Figure 5 is a simplified block diagram showing the use of the event manager according to an embodiment of the present invention;

12 is a simplified information and problem reporting (IPR) flowchart according to one embodiment of the present invention;

13 a simplified IPR processing flowchart according to an embodiment of the present invention;

14 an example of a graphical user interface for IPR view according to an embodiment of the present invention;

15 Figure 5 is a simplified block diagram showing data collection according to an embodiment of the present invention;

16 Figure 5 is a simplified block diagram of the data collection subsystem according to an embodiment of the present invention;

17 Figure 5 is a simplified block diagram of the threshold counter data communication paths according to an embodiment of the present invention;

18 Figure 5 is a simplified block diagram of the threshold counter subsystem according to an embodiment of the present invention;

19 Figure 5 is a simplified block diagram of the message handling subsystem according to one embodiment of the present invention;

20 a simplified block diagram of the message handling test according to an embodiment of the present invention;

21 Figure 5 is a simplified block diagram of the distributed object messaging environment according to an embodiment of the present invention;

22 Figure 5 is a simplified block diagram of the internal debug and trace object relationships according to one embodiment of the present invention;

23 Fig. 10 is a simplified block diagram of the directory management system according to an embodiment of the present invention;

24 Figure 5 is a simplified block diagram of the handware representation of the telecommunications platform according to an embodiment of the present invention;

25 Figure 5 is a simplified block diagram of the software representation of the telecommunications platform according to one embodiment of the present invention; and

26 Figure 5 is a simplified block diagram showing the dynamic mapping of software to the hardware representation of the telecommunications platform according to an embodiment of the present invention.

DETAILED DESCRIPTION THE INVENTION

Overview of the architecture

The Telecommunications Platform (TP) 10 The present invention is a software system that has been developed to develop and execute distributed, scalable, error-resistant telecommunications applications 12 to support. The telecommunication platform 10 offers a unique set of tools designed for a computing environment such as UNIX. Not only do these tools include the set of interfaces, libraries, and executable programs provided by the telecommunication platform's development and runtime packages, but also a set of conceptual components needed to deliver distributed, scalable, non-buggy applications develop and manage.

As in 1 shown, is the telecommunications platform 10 from three separate software levels 14 - 16 , Level # 1 is a Telecommunications Platform Application Programming Interface (API) level 14 ; Level # 2 is a telecommunications platform services level 15 ; and level # 3 is a system interface level 16 , The Telecommunications Platform API level 14 Provides the communication procedure ready to access the telecommunication platform services level 15 access, which consists of telecommunication middleware services. The telecommunication platform services level 15 is the software layer that provides the most needed middleware services, such as a UNIX-based telecommunications system. The system interface level 16 consists of an operating system (OS) API and the network connections. The system interface level 16 defines the functions of process and thread management, memory management, timer, file system, communication, interface to hardware devices and other system components. The telecommunication platform 10 allows higher-level client applications 12 to be decoupled from the operating system and the network. By using the telecommunication platform 10 For example, developers can write application programs without having to overcome the difficulties of the underlying services, such as the operating system and the network running the work for the application.

2 is a block diagram of using the telecommunication platform 10 connected conceptual components. The smallest conceptual component is a configurable element (CE) 30 , A configurable element 30 is through the telecommunication platform 10 as one or more copies of a UNIX executable program defined by the Telecommunications Platform 10 is managed. For example, a configurable item may be a connection process, a database, a graphical user interface, a timing process, a query process, error handling programs, and so forth.

Configurable elements 30 are the basic building blocks of application programs. The most basic services, which is the telecommunications platform 10 for the application developers are services for creating, configuring and monitoring configurable elements 30 , Configurable elements 30 can be configured to start at specific points during node initialization. The configurable elements that can be executed under UNIX can be switched off Scalability or redundancy are performed multiple times. Thresholds for the number of instances of configurable elements required to provide suitable services may be configured as well as the indication of whether the instances are automatically retrieved from the telecommunications platform in the event of a process error 10 be restarted or not.

configurable Attributes of a configurable element contain the RunLevel, i.e. the level at which an I configurable element starts. RunLevels include PRE_MIN, OS_MIN, IN_SVC, and POST_IN_SVC. The Executive Level PRE_MIN specifies that the configurable element is at boot time is generated automatically by a service management subsystem. PRE_MIN configurable elements are not monitored by the platform manager subsystem. OS_MIN specifies that the configurable element is generated, when the node switches to OS_MIN. IN_SVC specifies that the configurable element is generated when the node is set to IN_SVC switches. POST_IN_SVC specifies that the configurable element is generated when the node switches to the state IN_SVC. Another configurable attribute is NumberOfInstances, the specifies how many copies of the executable program to execute. InServiceThreshold is a configurable attribute that specifies how many have to be started from NumberOfInstances so that the state of the configurable element is ENABLED. If the number of instances falls below this threshold, become the entire configurable element or all instances of the configurable element removed. Another attribute of the configurable Element's is HeartbeatSchedule, which specifies the plan for "heartbeat" messages, which are to be sent to a configurable element. Any configurable Element also has an AuditSchedule which provides the plan for review messages specified to be sent to the configurable element.

A set of configurable elements (CESet) 26 is from the telecommunication platform 10 defined as a group of configurable elements that are constructed to work together on one or more nodes 24 to be used. A set of configurable elements is a redistributable component. The telecommunication platform 10 can be sets of configurable elements 26 not directly manage but supports their production and their use. Sets of configurable elements 26 can be used as redistributable and / or reproducible components of an application 28 be considered.

An application 28 is a group of sets of configurable elements 26 defines all configurable elements 30 completely defined in a distributed program. The telecommunication platform 10 Provides software ready for applications 28 within a location 20 manage. Defining the configuration of applications for their distributable components allows the software to be defined for a distributed application, regardless of the hardware it is running on. The sets of configurable elements of an application become the nodes at a particular time 24 a location 20 distributed. When this happens, the scope and error insensitivity of the application become 28 determined based on the number of nodes that are used to support each set of configurable elements.

A knot 24 is defined as an instance of a supported operating system on which the telecommunications platform 10 running. The telecommunication platform 10 provides software that processes on nodes 24 managed. The knots 24 can be fault tolerant or fault tolerant and have one or more processors. The telecommunication platform 10 uses the services of the operating system and generally has no knowledge of the hardware on which it is running. The telecommunications platform requires very little configuration information for a node 24 , The nodes are configured in the system by specifying their names and unique device identifiers.

The knots 24 have operating states that are supported by the telecommunications platform and which describes the arrangement of configurable elements that were started in them. The operating states are HALTED, PRE_MIN, OS_MIN, IN_SVC and POST_IN_SVC. The node state HALTED indicates that the operating system of the node has been shut down. The state PRE_MIN is used to start configurable elements which must be started before configurable elements are started in the states OS_MIN. The telecommunications platform first launches all configurable elements configured to operate as PRE_MIN and then immediately starts executing configurable elements configured to operate in the OS_MIN state. Configurable elements that are configured to operate as PRE_MIN have no direct influence on the state of the node. The node state OS_MI coordinates all configurable elements that are configured for the execution plane OS_MIN and that are started to bring the node to the state OS_MIN. All configurable elements configured for node state OS_MIN reach their configurable Execution level transition state before assuming that the node has changed to the OS_MIN state. When the node state OS_MIN is reached, the telecommunication platform ranks the node back to the node state HALTED when any configurable element changes state under its execution plane transition state. A disconnected node can restart automatically. The node state IN_SRV coordinates configurable elements that are configured for the execution level IN_SRV. All configurable elements configured for node state IN_SRV reach their configurable execution plane transition state before the node goes to IN_SRV. When the node state IN_SRV has been reached, the telecommunication platform ranks the node back to the node state OS_MIN when any configurable element changes state under its execution level transition state. An automatic restart of a node can take place if the switching off of the node was not triggered manually. The node state POST_IN_SRV is used to configure configurable elements that must be started immediately after a node has transitioned to the IN_SRV state. When a node has reached IN_SRV, the telecommunications platform generates each POST_IN_SRV configurable item. State changes for POST_IN_SRV configurable elements have no effect on the node state and can be repeatedly started and stopped. The process of stopping a POST_IN_SRV configurable element does not cause the node to be downgraded to a lower node state.

A location 20 is defined by the Telecommunications Platform as a group of nodes on which distributed applications can be deployed. The Telecommunications Platform provides a telecommunications platform application known as Platform Manager and the Nodes 24 within a location 20 managed. A site can consist of at least one node. In multi-node sites, the platform manager application can run as a distributed application in two of the active / standby nodes. In single node sites, the platform manager application runs in single mode with user-defined application programs, but runs without the error handling properties provided by a standby node. The management of a site is provided by the platform manager.

A processor service group (PSG) 22 is defined as a group of nodes containing a special set of configurable elements 26 is used for redundancy reasons. The telecommunication platform 10 provides software applications for managing processor service groups within an application. Processor service groups support redundancy by allowing the user of the telecommunications platform to determine the number of nodes on which to run a set of configurable elements to provide an appropriate quality of service. As the state of the nodes or the sets of configurable elements running on them changes, the telecommunications platform checks 10 whether the appropriate quality of service is maintained, or it changes the application state as configured.

3 is a diagram that is a design of a system 40 shows in which the conceptual components of the telecommunications platform 10 used and mapped to hardware components.

Regarding the Hardware configuration is a node within a computer processor a network (such as Ethernet) acting as either client or can act as a server. On each node runs a single instance of the Operating system. Because of their dependence from the operating system the processors in a node do not run independently. Everyone Nodes at a site can act as platform managers or application nodes be classified. A location can be a node or a group consist of nodes connected to a host. The platform manager has a redundant counterpart. The platform manager node and its counterpart can be in an active / standby mode or work in a load sharing mode.

The system 40 has eight nodes, two platform manager nodes (active node 42 and standby nodes 43 ) and six application nodes 44 - 49 , The node becomes an application 50 to handle phone calls based on the time when the call is made or used for time-sensitive routing. The sets of configurable elements 52 and 54 the application 50 are the distributed components that provide the time-dependent routing functionality. Each set of configurable elements 52 and 54 Contains the software processes of UNIX executable programs or configurable items for a specific time zone. As shown, the application must 50 not on a single application node 44 - 49 are located. It may be desirable to map sets of configurable elements to different nodes. This allows the application to be scaled by increasing the number of nodes to which the sets of configurable elements are configured.

The internal architecture of the telecommunications platform is described from the perspective of both logical and physical partitioning. The logical partition divides the telecommunications platform into individual functional areas, as in 4 shown. Each functional area contains a contiguous set of classes that together provide a specific system function. The physical distribution describes the concrete software and hardware decomposition of the system context. The from the telecommunication platform 10 Provided services can be divided into two groups: Application Services 60 and core services 62 , Application services may include services, information and problem reports (IPR) / alarm 64 , Statistics 65 , Directories 66 , graphical user interface (GUI) 67 and Host Maintenance Simulator (HMS). IPR / alarm services 64 provide a standard mechanism to inform the system user about error conditions and other relevant system information. Statistics Services 65 provide procedures for accessing system-wide metrics and generating reports based on collected data. Directory services 66 provide classes designed to support data storage (permanent, shared or private) and to access the data. Graphical user interface services 67 provide abstractions of primitives for building GUI applications and accessing system utilities and the system itself, eg xterm window and operating system utilities. Host Maintenance Simulator services 75 provide a method to use an interface to the telecommunications platform if there is only one node in the system or if there is no host to which a connection is possible. The control and operation of the platform are enabled through the host.

Core Services 62 can include services related to network management 68 , the node management 69 , distributed objects 70 , the communication 72 , General Features 73 and the event treatment 74 To run. Network Management Services 68 Control network activities, such as configuring nodes and troubleshooting at the network level. Node Management Services 69 Control processes at the node level, such as node status reports and connection management. Distributed object services 70 provide a distributed database for object-based communication in a multiprocessing environment. communication services 72 provide the mechanism for handling messages about external collaborative connections for this platform. General services 73 provide a library of programming tools to support the rapid development of processes designed to run on or in the telecommunications platform. Event Services 74 provide the ability to initiate, terminate, and / or distribute special actions that are important to a task.

When At minimum, the telecommunications platform provides all the core services ready. Higher level applications use these services for execution the functions of lower levels.

5 shows the services of the telecommunications platform and their interdependencies. The developer accesses all core and application services via application programming interfaces 14 the telecommunications platform too. The developer can also access the operating system, network, and third-party software / hardware as needed. The object-based inter-process communication is provided by the communication services 72 treated. Most core and application services are from the communications services 72 and the general services 73 depending on their respective functions. It may be that graphical user interface services 67 only from communication services 72 are dependent. The arrows in 5 show the interdependencies between the services.

6 is a diagram of the physical distribution of the telecommunications platform 10 that has an application level 80 and a core level 82 contains. The core level 82 , the core services 62 contains, exists for each instance of a telecommunications platform. Core-level 82 contains Telecommunication Platform API 14 , Mechanisms for inter-process communication, event mechanisms and platform management. The telecommunication platform application level 80 is divided both vertically and horizontally. Vertically, each telecommunications platform's application process is classified, either as part of a core set of applications 84 to be or not. Processes not belonging to the main sentence depend on the processes of the main sentence. Horizontal are the telecommunication platform applications 80 categorized as required or optional. Optional applications can use an IPR / alarm package 86 , a data collection package 87 , a directory management system package 88 and a host maintenance simulation package 89 contain.

in the Below is a more detailed description of the services of Telecommunications platform indicated.

Network Management Services

Network Management Services 68 provide a general management view of the network element. They are responsible for implementing higher-level operations on the network element nodes, such as taking server nodes out of service, restoring server nodes, taking applications out of service, putting applications back into service enable or disable applications, maintain the status of distributed applications, maintain the health and status of server nodes, and report application status changes. Network Management Services 68 include a Network Platform Manager (NetPM), a Network Integrity Subsystem (NetSI), and a Configuration Manager (ConfigMgr). 7A is a block diagram illustrating an active platform manager node 100 with a corresponding or connected standby manager node 102 shows. Each platform manager node contains a network platform manager 104 , a network integrity subsystem 106 and a configuration manager 108 , A platform manager network test driver 110 offers a test at the network level.

Network platform manager (NetPMMain)

The Class name for the network platform manager is NetPM. NetPM is for deployment of management functionality of the platform resources responsible. The platform is a distributed system that multiple nodes or servers, the computing power for special Provide services, such as the verification of phone cards or Credit cards. The service provided by a server is through determines the configurable elements that are in the node. NetPM manages all configuration data associated with the platform. Configuration data contains information about the hardware, e.g. TCP / IP addresses a server, status information, such as server and query status, Software configuration information, such as application type, node name and information regarding the individually configurable elements.

• • Deskriptor-Information des konfigurierbaren Elementes – Liefert Konfigurations-Informationen für jedes konfigurierbare Element der Plattform. NetPM ruft diese aus einer Platten-Datei ab, welche die Informationen über konfigurierbare Elemente unterschiedlicher Arten enthält.
• • Anwendungs-Information – Diese liefert Konfigurations-Informationen über jede Anwendung (Dienst), die zur Berechnung eines Status der Anwendung verwendet werden kann. NetPM ruft diese Informationen aus einer Platten-Datei ab, welche die Informationen für alle Anwendungen in der Plattform enthält.
• • Prozessor-Dienstgruppen-Information – Diese liefert Konfigurations-Information über Prozessor-Dienstgruppen, die zur Berechnung eines Status der Prozessor-Dienstgruppe verwendet werden kann. (Prozessor-Dienstgruppe bezeichnet eine Gruppe von Prozessoren, welche dieselbe Anwendung bedienen, d.h. CCD, CCL). NetPM ruft diese Informationen aus einer Platten-Datei ab, welche die Informationen für alle Prozessor-Dienstgruppen in der Plattform enthält.
• • Server-Information – Diese liefert spezielle Informationen über alle Server in der Plattform. NetPM fordert diese Informationen vom ConfigMgr an und ruft sie von ihm ab. ConfigMgr versorgt NetPM zuerst mit der Server-Information über Plattform-Manager-Knoten. Danach, wenn ConfigMgr feststellt, dass der aktuelle Server der aktive Plattform-Manager ist, versorgt er den lokalen NetPM mit der Information über die restlichen Server in der Plattform. Andernfalls (Standby-Plattform-Manager) ruft NetPM diese Informationen von seinem Gegenstück ab und nicht vom ConfigMgr.

NetPM maintains the following configuration information. This information is collected by NetPM during its initialization.

• • configurable element descriptor information - provides configuration information for each configurable element of the platform. NetPM retrieves them from a disk file containing information about configurable elements of different types.
• • Application Information - This provides configuration information about each application (service) that can be used to calculate a status of the application. NetPM retrieves this information from a disk file containing the information for all applications in the platform.
• Processor Service Group Information - This provides processor service group configuration information that can be used to calculate a status of the processor service group. (Processor service group means a group of processors serving the same application, ie CCD, CCL). NetPM retrieves this information from a disk file containing the information for all processor service groups in the platform.
• • Server Information - This provides specific information about all servers in the platform. NetPM requests this information from the ConfigMgr and retrieves it. ConfigMgr first supplies NetPM with the server information about platform manager nodes. Afterwards, when ConfigMgr determines that the current server is the active platform manager, it provides the local NetPM with the information about the remaining servers in the platform. Otherwise (standby platform manager), NetPM retrieves this information from its counterpart and not from the ConfigMgr.

If when collecting this information an error is detected NetPM suitable IPRs and is terminated.

NetPM uses a NetMAP object to manage all configuration data. NetPM also uses a permanent directory to get information about the Server status, query status, and scheduled actions through one Restart the platform manager to save. An object disk file Dictionary is used to manage this directory. NetPM is for that responsible for the integrity of the configuration data between the two platform manager servers is maintained. NetPM uses a permanent directory, a database reconciliation and monitoring to ensure the integrity of the data to maintain.

• • PSG_DISABLED – Mindestens eine eingestellte Anzahl von Servern in der Prozessor-Dienstgruppe ist im ausgeschalteten Zustand.
• • PSG_INACTIVE – Mindestens ein Server in jeder Prozessor-Dienstgruppe befindet sich im Zustand Standby, und keiner ist im aktiven Zustand.
• • PSG_ACTIVE_MINIMAL – Nur eine bestimmte Anzahl von Servern in der Prozessor-Dienstgruppe ist im aktiven Zustand.
• • PSG_ACTIVE – Eine eingestellte Anzahl von Servern in der Prozessor-Dienstgruppe ist im aktiven Zustand (Hinweis: Die Anzahl ist größer als die Anzahl von Servern, die für

und der Anwendungs-Status kann unter Verwendung der folgenden Kriterien abgeleitet werden:

• • AP_DISABLED – Mindestens eine eingestellte Anzahl von Prozessor-Dienstgruppen für die gegeben Anwendung hat den Status PSG_DISABLED.
• • AP_INACTIVE – Mindestens eine Prozessor-Dienstgruppe für die gegebene Anwendung hat den Status PSG_INACTIVE, und keine Prozessor-Dienstgruppe hat den Status PSG_ACTIVE.
• • AP_ACTIVE_MINIMAL – Eine eingestellte Anzahl von Prozessor-Dienstgruppen für die gegebene Anwendung hat den Status PSG_ACTIVE_MINIMAL oder höher (PSG_ACTIVE).
• • AP_ACTIVE_PARTIAL – Eine eingestellte Anzahl von Prozessor-Dienstgruppen für die gegebene Anwendung hat den Status PSG_ACTIVE_MINIMAL oder höher (PSG_ACTIVE) (HINWEIS: Die für den Zustand AP_ACTIVE_PARTIAL erforderliche Anzahl von Prozessor-Dienstgruppen ist größer als die erforderliche Anzahl von Prozessor-Dienstgruppen für PSG_ACTIVE_MINIMAL).
• • AP_ACTIVE – Eine eingestellte Anzahl von Prozessor-Dienstgruppen für die gegebene Anwendung hat den Status PSG_ACTIVE (HINWEIS: Die für den Zustand AP_ACTIVE erforderliche Anzahl von Prozessor-Dienstgruppen ist größer als die erforderliche Anzahl von Prozessor-Dienstgruppen für PSG_ACTIVE_PARTIAL).

The application status is determined based on the status of the processor service group. The following criteria are used to determine the status of the processor service group:

• • PSG_DISABLED - At least one set number of servers in the processor service group is off.
• • PSG_INACTIVE - At least one server in each processor service group is in the standby state and none is in the active state.
• • PSG_ACTIVE_MINIMAL - Only a certain number of servers in the processor service group are in active state.
• • PSG_ACTIVE - A set number of servers in the Processor Service Group is in active state (Note: The number is greater than the number of servers that are running for

and the application status can be derived using the following criteria:

• • AP_DISABLED - At least a set number of processor service groups for the given application have status PSG_DISABLED.
• • AP_INACTIVE - At least one processor service group for the given application is PSG_INACTIVE, and no processor service group is PSG_ACTIVE.
• • AP_ACTIVE_MINIMAL - A set number of processor service groups for the given application has the status PSG_ACTIVE_MINIMAL or higher (PSG_ACTIVE).
• • AP_ACTIVE_PARTIAL - A set number of processor service groups for the given application is PSG_ACTIVE_MINIMAL or higher (PSG_ACTIVE) (NOTE: The number of processor service groups required for the AP_ACTIVE_PARTIAL state is greater than the required number of processor service groups for PSG_ACTIVE_MINIMAL) ,
• • AP_ACTIVE - A set number of processor service groups for the given application is PSG_ACTIVE (NOTE: The number of processor service groups required for the AP_ACTIVE state is greater than the required number of processor service groups for PSG_ACTIVE_PARTIAL).

NetPM keeps track of status changes in each server node and when he gets them, he determines the Status of the processor service group, and if a change It determines the new application status for the node and informs ConfigMgr these changes.

NetPM Provides required and autonomous updates to the application status. For autonomous updates the application process first registers a function with NetPM, to get updates for one specific application type (CCD or CCL). Always when NetPM a change the server or query status of NodePM receives the application status calculated and the registered function will work with the old and the called new application status. The application status can also NetPM is the last computed value of the Application status stored in its NetMAP to the returns requesting processes.

NetPM provides, partly through the use of two alias objects, two sentences routing options to other processes that communicate with NetPM would like. NetPM provides a local and a global active standby option. With the local option, all NetPM client requests become NetPM server object sent in the same node as the client object. At the global Active Standby option will accept all NetPM client requests globally (i.e. possibly via nodes away) active NetPM server object sent.

NetPM offers a set of reading and writing functions for a lot the server configuration data. These include read / write functions for the Schedule action data, the active status data of the platform manager, the server status data, etc. NetPM does not provide direct read / write operations for the descriptor data of configurable ones Elements.

NetPM also provides a function to initialize the majority of the server configuration data. These Function expects a ServerInfoMsg object as input.

NetPM provides a set of functions that have a specific configuration action (such as a graceful hold, an instant grip, a graceful Downgrade (soft downgrade) and recovery) on a particular server.

NetPM provides a feature that allows the server status to be special Server changed can be.

NetPM provides a release function and a feature to lock query processing a special server.

NetPM offers several features that changes server status and query status. These routines save the new one Status information in NetMAP inform the ConfigMgr software about the change and send the change to all NodePM software in the platform.

NetPM is also responsible for time synchronization in the server network. The time synchronization consists of three essential parts, as in 7B shown. The first part is for the active platform manager 100 to equate its local time with the time of the host. This includes the conversion of the time of the host ( 110 ) into a usable form and the information of the NodePMs 112 on platform manager node 100 and 102 that they need to perform a function adjtime () to get their clocks in line with the host 110 adjust. NetPM 104 also informs the Host Ticker class of the new host time when it receives the time message. An xntp process 120 then synchronizes the time of the application nodes ( 121 ) over time the platform manager node 100 and 102 , Each of the platform manager nodes 100 and 102 is configured as xntp master time source. The xntp daemon slaves 122 on the application node 121 choose one of the master xntp daemons 120 on the platform manager node 100 and 102 to stay in sync with them. Finally, whenever there is an unsolicited time setting message from the host 110 is received, the network time is the same as the received time.

Last comes NetPM 104 a feature that provides a newly-booted node with persistent server configuration information of all servers in the platform. NetPM 104 is a configurable element. NetPM 104 represents the non-embedded. Operations ready: Remove, Restore, and GetStatus, which NodePM needs to control the execution of NetPM. NetPMTimerHandler is called when the watchdog timer fires. It aborts the service provisioning loop and calls the NetPM function SettimeToVerify to start the verification.

NetPM 104 is an object with its own control thread. After building his NetMAP list, NetPM goes 104 in an infinite loop, waiting for requests. NetPM 104 notifies ConfigMgr 108 if there is a change in the service or query status of a server. NetPM 104 also sends these status changes to all NodePMs 112 in the platform. NetPM 104 notifies the special NodePM 112 to enable or disable query processing. NetPM 104 Provides service status synchronization functionality. NetPM 104 builds the IPU information for the servers in the platform and passes this information to the specific NodePM 112 in the member function BootNotify. In all service downgrade configuration requests (ie, GraceDown, ImmedDown, GraceHalt, and ImmedHalt), NetPM notifies the special NodePM 112 about the desired state of the server. NetPM 104 performs several things when requesting a server restore. First, get NetPM 104 the current status of the server from the specific NodePM 112 , Second, if the returned status is out-of-service / minimum software, NetPM sends 104 the relevant NodeSpecInfo to the specific NodePM 112 , Third, NetPM sends 104 the relevant descriptor information of the configurable element to the specific NodePM 112 , Finally, NetPM tells the special NodePM to restore the service.

Network System Integrity (NetSIMain)

• – Überwachung des Aktiv-/Standby-Status des Plattform-Managers
• – Korrelation des Knoten-Fehler-Berichtes
• – Wiederherstellungs-Aktionen für ausgefallene Knoten

The Network System Integrity (NetSI) subsystem 106 provides monitoring and recovery operations for the network element. It is responsible for implementing network monitoring and recovery. The operations implemented by the network system integrity include:

• - Monitor the active / standby status of the platform manager
• - Correlation of the node error report
• - Recovery actions for failed nodes

The class name for the network system integrity is NetSI. NetSI 106 manages the network system integrity for the platform manager. NetSI 106 receives messages about server downgrades and communication errors from NodeSI on the failed node. NetSI 106 determines which action to perform based on the data passed by NodeSi. When the node indicates a downgrade, NetSI performs the appropriate action to downgrade the node from the network level to the desired downgrade state. If the node indicates a communication error, NetSI issues 106 determine from the previously received data which node (if any) is faulty and perform actions to demote the faulty node if necessary. When NetSI detects For a node to be downgraded, NetSI will call the appropriate NetPM operation to perform the downgrade. If a change to the active state is required, NetSI will call the appropriate NetPM operation to set the active state. After NetPM is called to perform the demotion, NetSI ConfigMgr notifies that the status for a particular node changes. This allows the host to be instantly informed that a node is being downgraded. NetSI then writes an entry in the network configuration report that indicates the status change and the reason for it. NetSI recalls nodes to the valid service state based on the current state of the node.

NetSI contains a communication error list. This list contains the node name the reporting server and the node name of the problem server for each received communication error report. When received a communication error report will, the list for another report on the Searched for problem nodes. If nothing is found, the error information becomes added to the list. NetSI contains also a shutdown status info list. If NodePM indicates that a node is out of service and the NetPM status does not indicate that the node has been stopped, becomes a shutdown status info entry generated with the name of the stopped IPU. It becomes a timer and the shutdown status information is added to the list. If NodePM later a higher one Status for indicates the node (before the timer expires), the shutdown status info entry becomes out of the list deleted and no further action performed.

NetSI routinely checks the Status conditions of both PMs. If invalid conditions exist, NetSI tries to correct the situation by changing the active status is set to the correct state. Other processes can too contact NetSI to review the platform manager status conditions.

NetSI works with a load sharing concept "send to both". If both platform manager nodes are in operation, receive each NetSI process in each platform manager node the NodeSI request. Each NetSI process is determined based on the active / standby state and the faulty server of the platform, if he has the requirement must edit. The NetSI process of the active platform manager will normally perform the required action while the Standby platform manager ignores the information. If the however, if the node is the active platform manager, the standby platform manager turns off (if valid) yourself on active and leads the requested action off to the other platform manager node downgrade.

each Time, when a NetSI operation is called, NetSI first determines whether it is the active or standby platform manager. When active, processed NetSI the request for all conditions except the Target node is itself and the counterpart is in operation. In standby NetSI considers the requirement for everyone Conditions not, except if the destination node is the counterpart is.

During the Initialization requests NetSI the node name of the counterpart and the server descriptors of its own server and its counterpart server from NodePM. Before requesting the information, NetSI asks Status of NodePM and does not request the node name and server descriptors until NodePM is ready to deliver it. NetSI is not ready to provide a service until this information is received correctly has been.

NetSI uses the command line parameter DWN_RPT_FILE to get the name get the network configuration (downgrade) report file. If this Parameter is not specified, no report entry is the downgrades made.

In the 7C and 7D the process interaction between node management and network management is shown. Constant Monitor (ConMon) 132 is an instance of an object that is on an application node 136 running. ConMon 132 detects a failed process or a faulty configurable item and notifies a service management process program 134 , The service administration process 134 Determines if the configurable element error causes the process to fall below its threshold. If it does not, the service management process starts 134 the configurable element new. However, if the configurable item falls below its threshold, the service management process generates 134 a status change message of the configurable item and forwards the notification to NodeSI 130 further. NodeSI passes the state change of the configurable element to NodePM 112 further. NodePM 112 Determines if the status change of the configurable item affects the execution level of the node, which could cause the node to be downgraded. If the Node needs to be removed, NodePM delivers 112 Instructions to the service management process 134 to remove all configurable elements required to reach the state of being downgraded. NodePM 134 has NetPM 104 notified of the node status change. NetPM 104 performs a calculation to determine if the node status change affects the processor service group and the application status. The calculation of NetPM also determines whether an automatic action, such as removing a node from the service to min-set and restoring it on the node, must be performed. If the node needs to be removed, the node status change from NetPM to ConfigMgr 108 forwarded. ConfigMgr notifies the host 140 the status change for the node, the processor service group, and the application. These state changes can be viewed or printed in a report.

Especially Each NetSI determines if it is handling the downgrade request should. If so, the status of the destination server is retrieved. If the destination server is not already stopped, the server is on downgraded to the appropriate status based on the IPU status. If the IPU status is Out of Service, NetSI will call the NetPM operation to immediately pause on to the destination node either automatically or stop manually. When the IPU status out of service is minimal (OS-MIN), NetSI calls the NetPM operation for immediate demotion to downgrade the destination node to OS-MIN. If the IPU status In service is disabled, NetSI calls the NetPM operation to lock the query to lock the query state for the destination node. In all cases NetSI updates the active status when the destination node of the is active platform manager. If the destination node is to the local site belongs, informs NetSI as well the host over ConfigMgr that a status change occurs and dissolves the restoration of the processor service group (by ConfigMgr) when it detects that the processor service group of the destination server needs to be restored. NetSI then writes an entry in the network configuration report file that indicates that the status change occurs because the node reports an error.

NodeSI informs NetSI Communication errors that occur between two nodes. Based on stores previously received information (if any) NetSI the error or leads an action. Each NetSI provides the status of the reporting and the problem node. When every server is stopped, it will the communication error report discarded because the integrity of the data can not be guaranteed. If no server is stopped, the communication error list will be sent after another report about the Scanned problem nodes. If no report found about the problem node a communication error entry is added to the list of server information. If another report on the problem node is found and another reporting server this has been reported, the problem server is set up for downgrade processing. Once a decision has been made on whether the Server downgraded NetSI determines if it needs to handle this (based on his active state and whether he himself is the destination server or Not). If it is the demotion NetSI calls the Immediate Halt operation from NetPM on to either a car stop or a manually stop the problem node perform. If the server to be stopped is the active PM, NetSI updates the active state before it stops the node. If If the destination belongs to the local site, NetSI informs the host about ConfigMgr, that a status change occurs and dissolves restore the processor service group (through ConfigMgr), when it detects the processor service group of the destination server again must be made. NetSI also writes an entry in the network configuration report file, indicating that the stop occurs due to a communication error.

Configuration Manager (ConfigMgr)

• – Steuerungs-Nachrichten-Schnittstelle zwischen Host und Servern
• – Automat für gültige Operationen
• – Ansteuerung der Netzwerkverwaltung mit Anforderungen.
• – Steuerung von Operations-Timing/Timeouts.

The configuration management subsystem (class name: ConfigMgr) provides the control interface between the SCP host and the server components. All operations that can be performed on the server network are defined in this interface. The configuration management subsystem implements the following functions:

• - Control message interface between host and servers
• - Automatic machine for valid operations
• - Control of network management with requirements.
• - Control of operation timing / timeouts.

• • APPL_STATUS_MSG
• • ASPEC_MSG
• • CONFIGURE_SERVER_MSG
• • PSG_INFO_MSG
• • PSG_STATUS_MSG
• • QUERY_PROCESSING_MSG
• • RESET_SERVER_MSG
• • ROUTING_INFO_MSG
• • SCHED_ACTION_CTL_MSG
• • SERVER_INFO_MSG
• • SERVER_STATUS_MSG
• • TEST_SERVER_MSG
• • TIME_MSG

ConfigMgr manages the server configuration control for the platform manager. ConfigMgr receives host messages sent on the logical connections CONFIGCTL, MAINT, APPLCTL and ROUTINGCTL and processes each based on their message identifier and their type. When the host requests that a response or report be sent, ConfigMgr determines the required response and retrieves the required report information and sends it back to the host. ConfigMgr verar edit the following messages:

• • APPL_STATUS_MSG
• • ASPEC_MSG
• • CONFIGURE_SERVER_MSG
• • PSG_INFO_MSG
• • PSG_STATUS_MSG
• • QUERY_PROCESSING_MSG
• • RESET_SERVER_MSG
• • ROUTING_INFO_MSG
• • SCHED_ACTION_CTL_MSG
• • SERVER_INFO_MSG
• • SERVER_STATUS_MSG
• • TEST_SERVER_MSG
• • TIME_MSG

ConfigMgr also provides the platform manager with operations to Get server and time information from the host. He also sets Operations available at the host of server status changes to notify. When processing host command messages There are times when the ConfigMgr will respond to a response from the host or a status change from a particular server. ConfigMgr uses one Non-blocking philosophy regarding these waiting times. Instead of stop and wait for the event to occur ConfigMgr the desired Answer or the status in a queue PendingQueue and goes with it the normal processing of other host messages or with the Providing services to a client. If the desired answer or the status occurs, the corresponding procedure is called, to continue processing the message commanded by the host. If within the specified time limit the desired answer does not arrive or the desired one Status does not occur, an error procedure is called to the processing of the message commanded by the host is okay too bring and spend IPRs as needed.

In addition to Processing of host command messages requires that ConfigMgr notifies the host when a status change occurs. If ConfigMgr over a status change is notified, he checks the Status queues to determine if he is on the occurrence the status change waiting. If so, the operation becomes a queue match carried out. Otherwise, ConfigMgr sends server status messages to the host. While processing Host Response Messages checked ConfigMgr the queue for pending host responses (HostPendQueue) to determine if he waits for the answer. If so, the operation becomes a queue match carried out. Otherwise, ConfigMgr discards the response message from the host. If a platform manager node is booted to the OS-MIN state, he checks his counterpart and determines the status of the counterpart. In the event that no counterpart Platform Manager Node is present, the counterpart status becomes automatically set to paused. Similar checks are made on service server nodes (nodes, which are not a PM), to determine their status.

ConfigMgr has a registration feature that registers a subsystem can to get routing information for to provide a specific application. If the host has routing information about an application Requests ConfigMgr makes a request to the appropriate registered Subsystem (if any) to provide the routing information.

news to server configuration (ConfigServerMsgs) require because of the Type of services performed (i.e., stop, downgrades, Restores and bootstrap operations) a special processing. There Host messages are sent to both platform manager servers, have to Arrangements are made to ensure that only one Platform manager node the request is processed. This requires a review of the Server State of Platform Manager Node and its counterpart. On the Basis of the server states of the Platform Manager node and see if the ConfigServer request for one Platform Manager node, its counterpart, or a service server is, must different actions are carried out. The two finite ones Vendors (PMCfgSvrFSM and SvcCfgSvrFSM) manage all the different ones state-controlled actions.

PMCfgSvrFSM is the finite state machine that handles the restores, pauses, resynchronizations, demotions, and bootstrap operations for a platform manager application server. This automaton processes a request based on whether the request is for itself or its counterpart, its own status, or the status of its counterpart, and based on the requested event (stop, downgrade, restore, etc.). The reviewed platform manager server states are: Halted (Auto), Halted (Manual), XOS-MIN, AOS-MIN (Auto), MOS-MIN (Manual) and In-Svc. When In-Svc is present, the Active / Standby status is checked to see if the server is active or in standby. Valid events include Restore, Graceful Hold, Immediate Hold, Graceful Downgrade, Immediate Downgrade, Graceful Boot, Immediate Boot and Host Resync.

The Event is important to determine which platform manager node will process the request. When requested a restore Typically, the Platform Manager node that processes recovery (i.e., a platform manager node will restore itself). To process a restore request When the platform manager server is stopped sending the counterpart of the suspended Servers (if capable of doing so) denial response (denial) back to the host. When a stop, a downgrade or a bootstrap operation for a platform manager node is the counterpart of the platform manager node process it, unless the counterpart is stopped. If that counterpart stopped, the platform manager node handles the hold, the demotion or bootstrap itself. The processing of a halt, a demotion or a boot process, the actual execution of the requested action or return a rejection response back to the host. If a stop, a demotion, or a boot request is not rejected, the host considers the action to be successful.

If the platform manager node initiates a self-loading process process, the platform manager node calls the GraceHalt or Immedialt (dependent of the bootstrap type) from NetPM to itself in the paused To bring state. The processing is then terminated for this node because he was brought to the suspended state. (The host will be the Reset and boot the server.) If a stop, a downgrade or bootstrap process for the last in-service platform manager node is requested checks a force flag. If the Force Flag is not is set, the request is denied with the response "DENIED-LAST AMP". If the force flag is set, the stop becomes the downgrade or the boot process on the last in-service platform manager node.

If a host resync is requested by a platform manager node becomes the counterpart of Target platform manager server process the request unless the counterpart is paused. If the counterpart of the destination platform manager server is stopped, the platform manager node becomes resynchronized process the request. The processing of the request includes the change Server status from XOS-MIN to AOS-MIN or MOS-MIN or rejection the request if the current status is not XOS-MIN.

SvcCfgSvrFSM is the finite automaton that restores, stops, Resynchronizations, demotions and bootstrap events for one Service application server treated. This machine processes a request based on the state of the platform manager node, who performs the action, the state of the service server being worked on and the requested event (stop, demotion, recovery, etc.). The verified service states are: Halted (auto), Halted (manual), XOS-MIN, AOS-MIN (auto), MOS-MIN (manual) and InSvc. Valid Events are Restore, Graceful Hold, Immediate Hold, Graceful Downgrade, Immediate Downgrade, Graceful Boot, Immediate Boot and Host Resync.

Of the active platform manager node (OS-MIN or In-Service) processes the request to the server configuration for a service server. A boot, stop, resynchronization or Downgrade process is allowed on a service server as long as a platform manager at least OS-Min is. A restoration is for one Service server allowed only if at least one platform server in-service is. If no platform manager node is in service, the platform manager node sends which is active, a non-service DENY-AMP response back to the host. If a stop, a demotion or a boot process is not rejected, the host considers the action as successful.

If a stop, a demotion or a bootstrap for the last in-service node of an application is requested, a force flag is checked. If the force flag is not set is the request with the response "DENIED-LAST SERVER IN Processor service group PROCESSING QUERIES "rejected. If the force flag is set, the stop becomes the demotion or the boot process on the last in-service node of the application carried out.

Always, when processing a configuration event (except Immediate stop), an Under Configuration flag is checked. If the Under Configuration flag is set, the request is sent the answer "DENIED SERVER UNDER CONFIGURATION "rejected. ConfigMgr sets and clears that Under configuration flag during the event processing. The other messages (i.e., ServerInfoMsg, ServerStatusMsg, TimeMsg, etc.) do not require vending machines.

If a recovery request is not rejected ConfigMgr the flag UnderConfig for the server sends a ConfigServerMsg "Action Initiated" in response to the host and calls the operation Restore ISV from NetPM to get the server back on in-service too put. ConfigMgr then completes the recovery processing and sets up a server status PendingQueue entry for the server, to be put on in-service. The recovery processing will not continued, until ConfigMgr is informed that the server status is in-service is or the timer expires. When ConfigMgr informs of server status change to in-service Restore processing is continued by the Server query status is checked. If the server query status is DISABLED_SERVER_OOS and the number active server is less than the number of active servers of the processor service group, ConfigMgr calls the EnableQuery operation from NetPM to get the query status of the server and sets the current query status on pending. ConfigMgr then sends server status messages Host over Server and query status changes to inform. A query status PendingQueue entry for the Polling status of the server is set up to be shared (Enabled) becomes. Processing is then terminated until the query status is released or the timer expires. If configmgr of the Query status change is informed of Enabled, the recovery processing continued by sending server status messages and the under-configuration flag for the Server deleted become.

The Recovery error processing is triggered when the timer expires, before the server status on in-service changes or if the requested server information for the others Applications is never received. The error processing includes the Graceful Downgrade the server to OS-MIN, issue an IPR and the Clear of the Under Configuration flag for the server. If the timer expires before the query status Change to Enabled will restore processing with it continued that the query status is set to Disabled, the server with a graceful downgrade is set to OS-MIN server status messages sent, an IPR is issued, and the Under Configuration Flag for deleted the server becomes.

If A request for a graceful hold is not denied ConfigMgr the flag UnderConfig for the server, sends a ConfigServerMsg "Action Initiated" RESPONSE to the host and calls the operation GraceHalt from NetPM to pause the server. If the node is not already stopped, ConfigMgr stops the Halt processing and makes an entry in the Server Status Pending Queue for the server, to be stopped. He then makes an entry in the network configuration report, indicating that the host requested a stop. The Stop processing will not continue, until the ConfigMgr informs that the server status is Halted is or the timer expires. If ConfigMgr of the server status change is informed of the suspended state, the stop processing with sending server status messages and deleting of the Under Configuration flag for continued the server. When the timer expires, before the server status changes to Halted, the halt error processing becomes triggered. Error processing involves issuing an IPR and deleting the Under Configuration Flags for the server.

If a request for an immediate stop (Immediate stop) not is denied, ConfigMgr sets the flag UnderConfig for the server, removes all pending server status changes for this server from the status pending queue and calls the operation ImmedHalt from NetPM to pause the server. If the node is not already is stopped, ConfigMgr stops the Halt processing and makes one Entry in the server status pending queue for the server that stopped shall be. He then makes an entry in the network configuration report, indicating that the host requested a stop. The Halt processing will not continue until the ConfigMgr informs is that the server status is Halted or the timer expires. If ConfigMgr of the server status change is informed of a suspended state (or the node was already stopped when the stop was issued), the stop processing with To send server status messages, send the ConfigServerMsg "Successfully Completed" RESPONSE to the host and deleting of the Under Configuration flag for continued the server.

If the timer expires before the server status changes to Halted, the halt error is lost work triggered. Error processing involves issuing an IPR, sending a ConfigServerMsg "Action failed" RESPONSE to the host, and clearing the Under Configuration flag for the server.

If a request for a graceful downgrade is not denied, ConfigMgr sets the UnderConfig flag for the server, sends a ConfigServerMsg "Action Initiated" RESPONSE to the host and calls the GraceDown operation from NetPM to downgrade the server. If the node is not already in the desired reclassified state, ConfigMgr terminates the downgrade processing and makes an entry in the Server Status Pending Queue for the server, to be switched to OS-MIN. He then makes an entry in the network configuration report that indicates that through downgrading the host was requested. The downgrade processing will not continue, until the ConfigMgr is informed that the server status OS-MIN is or the timer expires. If configmgr of the Server status change is informed of an OS-MIN state (or the node already was in the state), the demotion processing is with sending server status messages and deleting of the Under Configuration flag for continued the server. When the timer expires, before the server status changes to an OS-Min state the downgrade error processing triggered. The error processing includes issuing an IPR and deleting the Under Configuration Flags for the server.

If an Immediate Downgrade Request is not denied, ConfigMgr sets the flag UnderConfig for the server and calls the ImmedDown operation from NetPM to downgrade the server. If the node is not already in the desired reclassified state, ConfigMgr terminates the downgrade processing and makes an entry in the server status pending queue for the server, to be switched to OS-MIN. He then makes an entry in the network configuration report, indicating that the host has requested a demotion. The downgrade processing becomes not continued, until the ConfigMgr is informed that the server status OS-MIN is or the timer expires. If configmgr of the Server status change is informed of an OS-MIN state (or the node already was in the state), the downgrade processing is with the sending of server status messages, Send a ConfigServerMsg "Successfully Completed" RESPONSE to the host and deleting of the Under Configuration flag for continued the server.

If the timer expires, before the status changes to an OS-MIN state, the downgrade error processing becomes triggered. Error processing involves issuing an IPR, sending a ConfigServerMsg "Action Failed "RESPONSE to the host and deleting of the Under Configuration flag for the server.

If not denied a request for a graceful or immediate boot ConfigMgr sets the UnderConfig flag for the server and sends one ConfigServerMsg "Action Initiated "RESPONSE to the host. ConfigMgr checks the server status for the server and calls the operation GraceHalt or Immedialt from NetPM if the server is not in a suspended state. If a halt operation is called, the processing is terminated, until ConfigMgr is informed that the server status is Halted is or the timer expires. He then makes an entry in the network configuration report, indicating that the host requested a bootstrap operation has been.

If ConfigMgr of the server status change is informed of an OS_MIN state (or the node already was in the state), the demotion processing is with To send server status messages, send a ConfigServerMsg "Successfully Completed" RESPONSE to the host and deleting of the Under Configuration flag for continued the server. If the timer expires before the server status changes to an OS-MIN state, the downgrade error processing is triggered. The Error processing involves issuing an IPR, sending a ConfigServerMsg "Action Failed" RESPONSE to the host and the deletion of the Under Configuration flag for the server.

If not denied a request for a graceful or immediate boot ConfigMgr sets the UnderConfig flag for the server and sends one ConfigServerMsg "Action Initiated "RESPONSE to the host. ConfigMgr checks the server status for the server and calls the operation GraceHalt or ImmedHalt from NetPM if the server is not in a suspended state. If a halt operation is called, the processing is terminated, until ConfigMgr is informed that the server status is Halted is or the timer expires. He then makes an entry in the network configuration report, indicating that the host requested a bootstrap operation has been.

If ConfigMgr has determined that the server is stopped sending It returns a ResetServerMsg REQUEST to the host. ConfigMgr generates one Entry in the Host Response PendingQueue to access the ResetServerMsg RESPONSE from the host to wait. Processing is then stopped until the RESPONSE is received or the timer expires. If the RESPONSE is received, ConfigMgr makes an entry in the ServerStatus Pending queue to wait for the server status OS-MIN will. If the RESPONSE is not received by the host before the timer expires, an IPR is issued and the Under Configuration flag is cleared. If the server status becomes OS-MIN, ConfigMgr sends server status messages to the host indicating the new server status and deleting it Under Configuration Flag. If the timer expires before the server status OS-MIN, ConfigMgr issues an IPR and deletes the Under Configuration Flag.

If A request for a host resync is not denied ConfigMgr determines if the server status is XOX_MIN. If yes, will The SetServerStatus operation is called by NetPM to determine the server status to put it on the appropriate Auto / Manual OS_MIN state Server status messages sent to indicate the new server status, and it becomes a ConfigServerMsg "Successfull" RESPONSE to the host Posted. If the server status is not XOS_MIN, an IPR becomes and a ConfigServerMsg "Action Failed" RESPONSE is sent to the host.

The Application Status message is processed by the Platform Manager node, which is In-Service Active is. If no platform manager node is in service, the Platform Manager Node processing the request, the OS_MIN Active is. When receiving a message of type ApplStatusMsg REQUEST from Host configmgr determines the application query status and sends an ApplStatusMsg S_REPORT with the current application query status back to the host. ConfigMgr sends messages of type ApplStatusMsg U_REPORT to the host when server status changes occur or as needed during processing a host request to configure the server.

ConfigMgr receives for every Application in the descriptor file ApplsInfo.des an ASPEC Data REQUEST message from the host. ConfigMgr queries NetPM to get the information for this application from NetMAP. It will be a reply message, which contains the ASPEC data, along with a response code that is a success or an error indicates, back sent to the host. IPRs are issued when an invalid application identifier, a message that is not an ASPEC Data REQUEST message, or a message type that is not a request exists.

The Processor Service Group Info message is from the Platform Manager node processed, which is in-service Active. If not a platform manager node In service, the platform manager node becomes the request process, which is OS_MIN Active.

at Receive a message of type PSGInfoMsg REQUEST from the host ConfigMgr determines the Processor Service Group Info and sends one PSGInfoMsg S_REPORT with the processor service group information back to the host.

The Processor Service Group Status message is from the Platform Manager node processed, which is in-service Active. If not a platform manager node In service, the platform manager node becomes the request process, which is OS_MIN Active. When receiving messages From the host's PSGStatusMsg REQUEST type, ConfigMgr sets the processor service group poll status and sends a PSGStatusMsg S_REPORT with the current processor service group poll status back to the host. ConfigMgr sends messages of type PSGStatusMsg U_REPORT to the host, if Server Status Changes occur or as needed during processing a host request to configure the server.

The process request message is processed by the Platform Manager node, which is In-Service Active. If no platform manager node is in service, the platform manager node will process the request, which is OS_MIN Active. ConfigMgr receives request types QueryProcMsg, DISABLE_SERVER, DISABLE_SERVER_FORCED, and ENABLE_SERVER from the host. When this message is processed, ConfigMgr triggers the enable / disable query processing for the destination server by calling NetPM's EnableServer / DisableServer operation. ConfigMgr sets up a Query Status PendingQueue entry for the server and stops further processing until the query status for the server changes to the desired state or the timer expires. NetPM informs ConfigMgr to change the query state by calling the NtfyQryStatChange operation from ConfigMgr. When ConfigMgr handles this operation, it checks the Query Status Pending Queue entries for the server query status tus state. If there is an entry with the desired query status, the appropriate success query processing procedure is called to resume processing of the QueryProcMsg. Success processing for the QueryProcMsg involves sending a QueryProcMsg RESPONSE back to the host indicating that the request was successful, and changing the active state is required for a platform manager node.

If the timer expires, before the server query status in the desired State is the appropriate query error processing procedure called to resume processing QueryProcMsg. The error processing for the QueryProcMsg involves issuing an IPR and sending a QueryProcMsg RESPONSE back to the host indicating the failed request.

During the When a server's bootstrap processing, the ConfigMgr sends messages of type ResetServerMsg REQUEST. If the host is a bootstrap of one Non-PM server requests, the ResetServerMsg REQUEST is sent, after stopping the destination server. ConfigMgr then stops the bootstrap processing and makes an entry in the Host Response Pending Queue for a message of type ResetServerMsg RESPONSE. The bootstrap processing will not work continues until the RESPONSE is received or the timer expires. When ConfigMgr receives the ResetServerMsg RESPONSE message, ConfigMgr checks whether an entry for the ResetServerMsg RESPONSE is present in the Host Response Pending Queue. If so, the appropriate procedure is called to do the bootstrap processing to end.

The Routing info message is processed by the platform manager node the in-service is Active. If no platform manager node in-service is, the message is discarded. When receiving messages from the Type RoutingInfoMsg REQUEST from Host sends ConfigMgr a RoutingInfoMsg RESPONSE back to the host, indicating that the request has been acknowledged, and tries to retrieve the routing information. If the routing information ConfigMgr sends a RoutingInfoMsg S_REPORT back to the host with the routing information. Requests another subsystem to send routing information ConfigMgr sends messages of the type RoutingInfoMsg U_REPORT to the host. Upon receiving a request to send routing information from another subsystem checks ConfigMgr the routing pending queue to determine if the host has the information has requested. If so, ConfigMgr sends a RoutingInfoMgr S_REPORT to the host with the routing information. Otherwise sends ConfigMgr a RoutingInfoMsg U_REPORT to the host with the routing information. After ConfigMgr sends a U_REPORT to the host, ConfigMgr waits that the host acknowledges receipt of the data by sends a RoutingInfoMsg ACK_RESPONSE. If configmgr inside If the time limit does not receive a response, ConfigMgr prompts corresponding subsystem, the application routing information again to send (to re-send the data to the host). If a NAK_RESPONSE is received from the host, ConfigMgr gives one IPR off, indicating a faulty response code from the host.

The Scheduled Action Control message is sent from the Platform Manager node processed, which is in-service Active. If not a platform manager node In-service, the Platform Manager node becomes the OS-MIN Active is to edit the request. When messages of type SchedActCtlMsg SET from the host, ConfigMgr calls the SetSchedAction operation from NetPM to the scheduled actions (such as constant monitoring or general reviews) as required to release / block. ConfigMgr sends a message of the type SchedActCtlMsg RESPONSE back to the host to indicate if the setting was successful or Not. ConfigMgr has a GetSchedActions operation by a Client can be used to get the host time information. If those Operation is called, ConfigMgr sends a message of type SchedActCtlMsg REQUEST to the host. ConfigMgr then makes an entry into the Host Response Pending Queue for the desired SchedActCtlMsg S_REPORT from Host Processing (from GetSchedActions) is terminated until S_REPORT is received or the timer expires. If the timer expires before the scheduled actions are received, no action is taken. If ConfigMgr a message of type SchedActCtlMsg S_REPORT from the host receives, checks ConfigMgr, whether there is an entry for SchedActCtlMsg S_REPORT in the Host Response Pending Queue is available. If so, ConfigMgr calls the SetSchedAction operation from NetPM to enable / disable scheduled actions.

The Server Info message is processed by the Platform Manager node, which is In-Service Active. If no platform manager node is in service, the request is processed by the platform manager node, which is OS-MIN Active. During initialization processing and recovery processing of a platform manager server, ConfigMgr sends messages of type ServeIn foMsg REQUEST and REQUEST ALL to the host. After the message has been sent, ConfigMgr stops processing the task and makes an entry in the Host Response Pending Queue for a ServerInfoMsg S_REPORT type (and / or the COMPLETE type if REQUEST ALL is used). Initialization and recovery processing will not continue until the required server information is received or the timer expires. If the timer expires during initialization (before the info is received), ConfigMgr resends the ServerInfoMsg REQUEST or REQUEST ALL until the information is received. If, during the recovery of a platform manager server, the timer expires (before the info is received), ConfigMgr issues an IPR that the recovery failed.

If ServerInfoMsg S_REPORT and COMPLETE are received by the host, ConfigMgr checks whether there is an entry for the ServerInfoMsg in the Host Response Pending Queue S_REPORT or COMPLETE exists. If yes, the appropriate Procedure called to initialize or restore processing to end. If messages of type ServerInfoMsg CHANGE from host ConfigMgr determines if it is in an appropriate state State is to process a CHANGE server info. If yes, ConfigMgr informs NetPM about the changed Server Information and sends a ServerInfoMsg RESPONSE message back to the host, to indicate if the server information succeeds changed was or not.

The Server status message is processed by the platform manager node, the in-service Active is. If no platform manager node is in-service, then Processes the request from the Platform Manager node OS-MIN Active is. When receiving ServerStatusMsg messages Receive REQUEST from the host ConfigMgr the server and Query status information and sends a ServerStatusMsg S_REPORT back to the host with the current status information. ConfigMgr sends messages of type ServerStatusMsg U_REPORT to host when server status changes occur or as needed during processing a host configuration server request.

The Message Test Server is processed by the Platform Manager node, which is In-Service Active is. If no platform manager node is in service, the Request processed by the Platform Manager node, the OS-MIN Active is. If the destination server is myself and my mateplatform manager is not stopped, becomes this platform manager node discard the request while the other platform manager processes the message. Will one Message of type TestServerMsg REQUEST or ABORT from the host receive the logical connection MAINT, ConfigMgr determines whether the status of the destination server is MOS_MIN. If yes, ConfigMgr sends a TestServerMsg Acknowledge RESPONSE back to the host. In the future will ConfigMgr trigger or terminate the appropriate test, as appropriate whether a REQUEST or ABORT is received. If the destination server is not If MOS_MIN is, ConfigMgr sends a TestServerMsg Server Not MOS-MIN RESPONSE back to the host. If the status of the destination server can not be obtained, ConfigMgr sends a TestServerMsg Denied RESPONSE back to the host and outputs a suitable IPR.

The Message Time is processed by the Platform Manager node, which In-Service is Active. If no platform manager node is in-service, then Processes the request from the Platform Manager node OS-MIN Active is. Is a message of type TimeMsg SET from the host ConfigMgr calls the SetTime operation of NetPM to set the server network time to the right time and sends a TimeMsg RESPONSE back to the host to indicate whether the setting was successful or not. ConfigMgr has one Operation GetTime, which can be used by a client to to get the host time information. When called this operation ConfigMgr sends a TimeMsg REQUEST message Host. ConfigMgr then makes an entry in the Host Response Pending Queue for the desired TimeMsg S_REPORT from the host. Processing is then terminated until S_REPORT is received or the timer expires. No action is taken when the timer expires, before the timer information Will be received. If the host has a message of type TimeMsg S_REPORT is received, ConfigMgr checks, whether there is an entry for the TimeMsg in the Host Response Pending Queue RESPONSE is present. If so, the operation SetTime of Called NetPM to set the server network time.

Node management services

Node platform manager (Node1PMMMain)

• – HALTED (Keine Software läuft – auch kein Betriebssystem (OS))
• – MIN-SET (OS + Minimal erforderliche Plattform-Software)
• – INSERVIConfigurable element (MIN-SET + Allgemeine Software

The node management subsystem provides process management within a single server node. It is responsible for starting / stopping processes within the server node to maintain certain execution levels. Node Management supports the following execution levels:

• - HALTED (No software running - no operating system (OS))
• - MIN-SET (OS + Minimal required platform software)
• - INSERVIConfigurable element (MIN-SET + General Software

The Network Management informs node management about the desired Execution level for one special knot. For In the case of a process error, the node administration examines the error and Determines what recovery action is required if one exists. Restore actions include ignoring the error, the automatic start of the node at the next lower execution level and back at the current execution level, as well as the shutdown of the system.

• • Instantiierung des NodeMAP-Objektes, und nach Erhalt der Konfigurations-Information über die minimal konfigurierbaren Elemente, die auf jedem Server konfiguriert werden müssen, bringt es den Server-Knoten in einen Minimal-Betriebszustand (OS-MIN). In diesem Zustand ist dem Server-Knoten nur ein minimaler Satz an Funktionen erlaubt, wie z.B. das Starten der restlichen Prozesse. Die Konfigurationsdaten, die in der NodeMAP jedes Knotens bereitgestellt werden, bestimmen die Fähigkeiten des Server-Knotens (Server-Knoten mit Plattform-Manager-Fähigkeiten gegenüber Server-Knoten mit Abfrage-Verarbeitungs-Fähigkeiten).
• • Erzeugung des NodePM-Server-Objektes zur Behandlung der NetPM-Anforderungen zur Ausführung von Operationen innerhalb desselben Server-Knotens. Pro NetPM-Anforderung kann NodePM (durch von seinem Server-Objekt bereitgestellte Operationen) die folgenden Operationen ausführen:
• • Bringen seines Server-Knotens in einen vollen Betriebszustand (IN-SERVIConfigurable element) aus einem Minimal-Betriebszustand (OS-MIN) (RestoreNode-Operation)
• • Herunterschalten seines Server-Knotens aus einem vollen Betriebszustand (IN-SERVIConfigurable element) in einen minimalen (OS-MIN) oder angehaltenen (HALT) Betriebszustand (RemoveNode-Operation).
• • Freigabe/Sperren der Abfrage-Verarbeitung auf seinem Server-Knoten.
• • Bereitstellen von Status-Information über konfigurierbare Elemente.

NodePM is started as part of the system startup procedure for each server node. As part of its initialization, NodePM does the following:

• • Instantiation of the NodeMAP object, and upon receiving the configuration information about the minimum configurable elements that must be configured on each server, brings the server node to a minimum operating state (OS-MIN). In this state, the server node is allowed only a minimal set of functions, such as starting the remaining processes. The configuration data provided in each node's NodeMAP determines the capabilities of the server node (server node with platform manager capabilities versus server nodes with query processing capabilities).
• • Creation of the NodePM server object to handle the NetPM requests to perform operations within the same server node. For each NetPM request, NodePM can perform the following operations (through operations provided by its server object):
• • Bringing his server node into a full operating state (IN-SERVIConfigurable element) from a minimum operating state (OS-MIN) (RestoreNode operation)
• • Downshifting its server node from a full operational state (IN-SERVIConfigurable element) to a minimum (OS-MIN) or halted (HALT) operating state (RemoveNode operation).
• • Enable / disable query processing on its server node.
• • Providing status information about configurable elements.

NodePM reports every change status on each IPU autonomously to NetPM (NodePM uses the operation, provided by NetPM to report the status change).

8th Figure 11 is a diagram showing the allowable service state transitions for a node. Note that all automatic states transition to other automatic states, and all manual states transition to other manual states. There is no permissible transition from a manual state to an automatic state. The ISV state currently has no label as automatic or manual. States can transition to / from any other state from / to the IN SERVICE (ISV) 200 state. In 8th the following abbreviations are used:

Node System Integrity (NodeSIMain)

• – Passive Prozessüberwachung (Signal-Erfassung)
• – Überwachung der Kommunikation zwischen den Knoten
• – Lokale Fehler-Berichte

The Node System Integrity subsystem (class name NodeSI) provides error isolation and monitoring services in a single server node. All process errors are logged by this subsystem and forwarded to node management for recovery actions. The functions implemented by Node System Integrity include:

• - Passive process monitoring (signal detection)
• - Monitoring the communication between the nodes
• - Local error reports

• • Fehler, die durch das Objekt Constant Monitor in jedem Prozess erkannt werden.
• • Fehler der Kommunikation zwischen den Knoten.
• • Kommunikationsfehler zwischen dem Host und dem Server-Netzwerk.
• • Vom IM-Server-Prozess erkannte Fehler.

The system integrity (SI) capabilities of the AIN platform can be categorized into those providing functions through the server nodes of the platform and those providing functions within a single server node. While NetSI addresses the system integrity functions at the platform level, NodeSI provides system integrity at the level of a single node. NodeSI is located in each server node of the platform and provides operations that allow processes for each configurable item to report error conditions for that process. These errors include the following:

• • Errors detected by the Constant Monitor object in each process.
• • Error of communication between the nodes.
• • Communication error between the host and the server network.
• • Errors detected by the IM server process.

she leads as well a constant monitoring in the node all connections to / from the node. If a communication error is detected, NodeSI informs NetSI about the communication error. Dependent NodeSI takes the appropriate actions from the reported error including the issuance of IPRs and demotion of the node state (in cooperation with NodePM).

• • Von NodePM empfangene IPU-Information
• • IPU-Status
• • Fehler-Zählwert
• • Anzeige für empfangene Alive-Nachrichten

NodeSI monitors disk utilization on each server node and issues an appropriate IPR when the total capacity used on a particular file system exceeds a certain threshold. NodeSI communication with other objects is handled through the DOME interface. NodeSI gets the list of all IPUs in the configuration of NodePM. A field is set up containing the following information from each IPU:

• • IPU information received from NodePM
• • IPU status
• • Error count
• • Display for received alive messages

Instead of the node name uses a field index in this list, to exchange the status with other NodeSIs, since string comparisons in terms of Speed and efficiency can be expensive. That's why it's important that each node in the configuration has the same IPU list in it Order has.

NodeSI registers with NodePM to get messages about the node state. If NodeSI of a status change for one other IPU is updated, it updates the IPU status in the IPU field. When the status change goes into the suspended state, NodeSI clears the error counts and the ad for the received alive messages.

• • BroadcastTimer – Zeitgeber, der bewirkt, dass NodeSI Nachrichten "I'm alive (ich lebe)" an die anderen NodeSIs in seiner Sicht sendet.
• • ConMonChkTimer – Zeitgeber, der bewirkt, dass NodeSI feststellt, ob die richtigen "I'm alive"-Nachrichten für alle Verbindungen innerhalb des Zeitintervalls empfangen wurden.

NodeSI has two timers to handle its constant-monitoring function:

• • BroadcastTimer timer, which causes NodeSI messages to send "I'm alive" to the other NodeSIs in its view.
• • ConMonChkTimer - Timer, which causes NodeSI to determine if the correct "I'm alive" messages have been received for all connections within the time interval.

If NodeSI about it informing that its node is on OS-MIN, it starts by sending "I'm alive" messages to other NodeSIs in it View. Then solve it turns off the broadcast timer. When the BroadcastTimer expires, sends NodeSI immediately re-announces "I'm alive" messages and solve that BroadcastTimer off again. This will make any running NodeSI processing interrupted.

If NodeSI an "I'm alive" message from one receiving another NodeSI, it marks the ad for the received alive messages of the corresponding entry in the IPU field.

If NodeSI about it informing that its node is on OS-MIN, it starts the ConMonChkTimer. When the ConMonChkTimer expires, NodeSI makes a dome call to the CommFailCheck operation to check for communication errors perform and re-trigger the timer. It uses the DOME call on itself to make sure Priority is given to sending the alive messages.

The Communication error processing involves verifying each IPU in its field, to determine if an Alive message has been received since the last time check has been. If so, the message for received live messages is cleared. If no message was received and the IPU status was not paused is, the error count becomes for the Node increments. If the number of errors for this IPU is at its maximum, NodeSI reports a communication error to NetSI.

The maximum number of error counts is a configurable value using the keyword "MAX_COMM_FAULTS" from the command line can be read. If no value is specified, the default is Number of errors 2. If the value specified in the command line is smaller than 2, the maximum number is set to 2.

The Number of seconds between each sending of Alive messages is on Configurable value using the keyword "BRDCAST_ALIVE_SECS" from the command line can be read. If no value is specified, the default is Number of seconds between sending 1 second. If in the Command line specified value is less than 1 second, the Number of seconds set to 1. The number of seconds between every review of the Constant monitoring is a configurable value using the keyword "CONMON_CHK_SECS" from the command line can be read. If no value is specified, the default is Number of seconds between checks 2 Seconds. If the value specified in the command line is smaller than 2 seconds, the number of seconds is set to 2.

• – FaultID – Fehler-Kennung
• – FaultActId – Für jeden gemeldeten Fehler durchzuführende Aktion.

NodeSI is started by NodePM as part of every node boot and before any other processes start. As part of its initialization, NodeSI reads a descriptor file (Fault.des) that contains the definition of the errors detected by NodeSI and generates a list (FaultInfoList) of those error records. Each error record (FaultInfo) contains the following parts:

• - FaultID - error identifier
• - FaultActId - Action to be taken for each reported error.

• • Ausgabe geeigneter IPRs.
• • Anhalten des Knotens für den Fall, dass katastrophale Fehler im NodePM-Prozess erkannt wurden.
• • Bericht über autonome Statusänderungen in konfigurierbaren Elementen an NodePM.
• • Meldung von Kommunikationsfehlern an NodePM und weiter an NetSI.

When errors are received, NodeSI looks for the error record in its list (FaultInfoList), using the identifier of the error, and performs the action associated with the error. These Actions may include:

• • Output of suitable IPRs.
• • Stop the node in the event that catastrophic failures have been detected in the NodePM process.
• • Report autonomous status changes in configurable elements to NodePM.
• • Communication error messages to NodePM and to NetSI.

All Error (originating from Constant Monitor or other processes) from every process over reported the NodeSI operation NotifyFault () to NodeSI. NodeSI tracks the plate exploitation on the server node and outputs an IPR if 80 was used.

NodePM interface

• • Zurückstufung des Knoten-Zustandes – Diese Aktion wird durchgeführt wenn die Statusänderung des konfigurierbaren Elementes einen bedeutenden Einfluss auf den aktuellen Betriebszustand des Knotens hatte. Vorher informiert NodePM NetSI von seiner Absicht und startet einen Zeitgeber. Bei Antwort von NetPM oder wenn der Zeitgeber abläuft, wird er den Zustand des Knotens zurückstufen.
• • Bericht eines Kommunikationsfehlers – Diese Aktion wird durchgeführt wenn die Statusänderung des konfigurierbaren Elementes einen Kommunikationsfehler zwischen den Knoten angezeigt hat (TCP-Verbindung ausgefallen). In dieser Situation wird NodePM NetSI über den Kommunikationsfehler informieren, und versucht, die Kommunikation wieder aufzubauen.

NodeSI uses the interface provided by NodePM to report the autonomous changes in the state of a configurable element (AutoChgCEStat (...)). Depending on the influence of the configurable item on the state of the node, the state change may cause NodePM to do one of the following:

• • Downgrading the Node State - This action is performed when the status change of the configurable element had a significant impact on the current operating state of the node. Before, NodePM informs NetSI of its intention and starts a timer. Upon response from NetPM or when the timer expires, it will downgrade the state of the node.
• • Communication error report - This action is performed when the status change of the configurable item indicates a communication error between the nodes (TCP connection lost). In this situation, NodePM will inform NetSI of the communication error and attempt to reestablish communication.

NetSI interface

• • Autonome Änderungen in einem IPU-Status (DowngradeIPStat(...)) – In dieser Situation führt NetSI eine Zurückstufung des Knotens durch NetPM aus (fordert NetPM zum Zurückstufen auf, wenn der Knoten nicht bereits angehalten ist).
• • Kommunikationsfehler (CommFaultRprt (...)) – In dieser Situation wird, wenn Kommunikationsfehler zur selben IPU von anderen IPUs gemeldet wurden, NetSI die IPU als fehlerhafte IPU markieren und versuchen, sie über NetPM zurückzustufen.

NetSI provides operations used by NodeSI and / or NodePM to report the following conditions:

• • Autonomous changes in an IPU state (DowngradeIPStat (...)) - In this situation, NetSI will downgrade the node through NetPM (prompts NetPM to downgrade if the node is not already paused).
• • Communication Error (CommFaultRprt (...)) - In this situation, if communication errors to the same IPU were reported by other IPUs, NetSI will mark the IPU as a bad IPU and try to downgrade it via NetPM.

Constant monitor interface

Everyone Process of a configurable item must be the Constant object Monitor instantiate to abnormal conditions / events generate, recognize and report different signals in the process. Constant Monitor reports these conditions through the NotifyFault () operation from NodeSI. For In the event that the communication of the error to NodeSI failed Constant Monitor can switch the node to HALT, which is from depends on the options which were discontinued at the time of its instantiation.

interface to Message Handler / Logical Link The processes Message Handler or Logical link of configurable elements use the NodeSI operation NotifyFault () to report errors on DNI / TCP connections.

Service Manager (SMProcess)

• – Aktive Prozessüberwachung (Heartbeats, Überprüfungen)
• – Unterstützung mehrerer Prozess-Instanzen
• – Anwendungs-Prozess-Zustands-Verwaltung
• – Verwaltungs-Zustand
• – Betriebszustand
• – Nutzungs-Zustand
• – Anwendungs-Prozess-Zustands-Änderungs-Meldung

The service management subsystem provides process control for application processes. Application processes are only started after the node has reached the execution level IN SERVICE. Application processes can be individually removed / restored and shared / unlocked on a server node. The network management informs the service management which applications to remove, restore, release, block. The functions implemented by the service administration are:

• - Active process monitoring (heartbeats, checks)
• - Support of multiple process instances
• - Application Process State Management
• - Management state
• - Operating state
• - usage condition
• - Application Process State Change Message

• • Es wird ein Urlade-Skript 230 erzeugt, das als erstes auf allen Knoten läuft. Wenn das Urlade-Programm 230 läuft, erkennt es den Plattform-Manager-Knoten 232 und kopiert die Tcl-Deskriptor-Datei 234 des aktiven Plattform-Manager-Knotens herüber, um den Knoten hochfahren zu lassen. Wenn er feststellt, dass er der erste Plattform-Manager-Knoten ist, der hochläuft, benutzt er zum Betrieb die vorhandene Tcl-Deskriptor-Datei 234.
• • Das Plattform-Manager-Untersystem und das Dienst-Verwaltungs-Untersystem 236 haben in der vorherigen Version der Plattform ein anderes Konzept davon, was ein konfigurierbares Element 238 ist. Diese beiden Konzepte werden in ein Konzept konfigurierbarer Elemente zusammengefasst, das ihre getrennten Funktionalitäten vereinigt. Hierzu wird das Plattform-Manager-Untersystem konfigurierbare Elemente nicht mehr entfernen und wiederherstellen, sondern wird die Dienst-Verwaltung davon informieren, wenn es möchte, dass ein konfigurierbares Element entfernt und wiederhergestellt werden soll. Die Dienst-Verwaltung ist nun das erste Programm der Telekommunikations-Plattform, das gestartet wird, und startet NodePM immer als Teil seiner Initialisierung. NodePM steuert dann das Starten und Stoppen von Prozessen wie vorher, nur über die Dienst-Verwaltung, nicht über die alten Funktionalitäten RemoveCE und RestoreCE.

In order for the telecom platform's navigator function to be a consistent interface to configurable elements, a change has been made so that the service management starts system configurable elements instead of NodePM. This will start all processes in the system (except service management) from service management, so that the functions of a configurable item are now system-wide. To create a telecommunications platform navigator GUI, there must be a consistent view of a telecommunications platform system. 9A Figure 12 is a diagram showing the new relationship that exists between nodes in the telecommunications platform during node initialization. For a configurable item to be able to use all the functionality of service management, the service management interface must be followed.

• • It will be a bootstrap script 230 which first runs on all nodes. If the bootstrap program 230 when it runs, it detects the platform manager node 232 and copies the Tcl descriptor file 234 active platform manager node to start up the node. If he determines that he is the first platform manager node to boot, he uses the existing Tcl descriptor file to operate 234 ,
• • The Platform Manager Subsystem and the Service Management Subsystem 236 In the previous version of the platform have a different concept of what a configurable item 238 is. These two concepts are grouped together in a concept of configurable elements that unifies their separate functionalities. To do this, the platform manager subsystem will no longer remove and restore configurable items, but will notify the service manager if it wants a configurable item to be removed and restored. The service management is now the first program of the telecommunication platform to be started and always starts NodePM as part of its initialization. NodePM then controls the starting and stopping of processes as before, only via the service administration, not via the old RemoveCE and RestoreCE functionalities.

9B is a message flow diagram showing node initialization in the MIN_SET state. 9C is a message flow diagram showing node initialization in the IN_SERVICE state, and 9D is a message flow diagram showing the node initialization in the POST_ISV state.

10 shows the message protocol used between SM and a configurable item. If a configurable item can not accommodate a service management interface (SMI) object, service management can still start the configurable item, but many of the features provided by service management are unavailable.

Event Manager (eventmanagerimpl)

The Event Manager subsystem gives users the ability to Event messages to one or more registered parties generally spend. It can There are multiple Event :: Manager object instances in the system. A node-level event :: Manager exists in all nodes. Other Event :: Manager instances may also be present interested parties the opportunity to give up for To register events that are special for a process. The eventmanagerimpl program provides an Event :: Manager object instance for the Node on which it runs. Events for A node is relevant through the Event :: Manager instance output. Users listening to events on a particular node are interested bind to the Event :: Manager instance by specifying the name of the Use node as Event :: Manager name. Programs can also Embed an Event :: Manager object in your program. The program IprMgrImpl is an example of a program that does this. IprMgrImpl has an Event :: Manager named IprEventMgr. Users who want to receive IPR events. User, who are interested in a particular event can become register with a particular Event :: Manager instance to do this Event over to receive the Event :: Manager instance. The Event :: Manager saves the list of registered parties not permanent. If the Event :: Manager tries to forward an event to an Event :: Receiver which is no longer there, the Event :: Receiver is removed from the list.

11 shows two examples of using Event :: Manager 250 in the telecommunication platform system. The eventmanagerimpl 252 contains the node Event :: Manager object instance 250 , The No dePMMain telecommunications platform program 254 uses this Event :: Manager 250 to issue an event when the node changes state. The application program 256 then creates an Event :: Receiver object 268 and passes a CORBA object reference to the register call on the "Node123" Event :: Manager 250 , If NodePMMain 254 generates an event by clicking on the "Node123" Event :: Manager 250 Notify calls becomes the Event: Manager 250 all Event :: Receiver objects 258 find out who have registered to receive this event. If he sees that the application program has registered for this event, call the Event :: Manager 250 the Notify () method on the Event :: Receiver object 258 on, making the method Notify () in the application program 256 is called. In the above example, the application program also has "IprEventMgr" Event :: Manager 260 in the IprMgrImpl program 262 registered. If NodePMMain 254 Using the IprMgrImpl interface to output an IPR, the IprMgrImpl program looks 262 in this IPR, perform the check and call Notify () on the "IprEventMgr" Event :: Manager 260 on. This causes Event :: Manager 250 the generated event to the Event :: Receiver 264 in the application program 256 that was passed in the register call.

application programs 256 can create their own Event :: Manager with their own name in the same way as the program IprMgrImpl did. Event :: Manager instances must have unique names in the system to prevent an event from being generated for the wrong Event :: Manager, or to help the user avoid being picked up by the wrong Event :: Manager registered.

IPR / ALARM services

The Information and Problem Reporting (Information and Problem Reporting, IPR) subsystem provides all processes in the system with the ability to Issue information and problem reports. IPRs are the standard mechanism which is used by system users about error conditions or others to inform relevant system information. The information and Problem Reporting Subsystem implements the collection of IPRs in the telecommunication platform. An alarm is a mechanism that attached to an IPR can be. Alarm services are currently unavailable but in a future Version of the telecommunications platform to disposal stand.

The IPR subsystem provides several functions. It provides active / standby IPR service redundancy, the ability, IPRs to registered recipients to pass on the ability to Forward IPRs to the host, the ability to display IPRs in real time, Backward compatibility with the Previous PAConfigurable element IPR interface, a CORBA IPR interface, the Ability, to use an IPR directory to check IPRs, the ability to add additional information about provide the IPR issued by the IPR directory, and the Ability, IPRs in the IPR directory to configure.

Regarding 12 the program IprMgrImpl is the collection point for all IPRs at the location of a telecommunication platform. This program contains the IprMgrImpl CORBA server object. The IprMgrImpl object runs on each of the active / standby platform manager nodes. The Active / Standby state to which the IprMgrImp responds is the node-level Active / Standby state of the Telecommunications Platform Manager nodes. The standby IprMgrImpl object will hide its interface, and the active IprMgrImpl object will announce its CORBA interface when the platform manager nodes change the active / standby state. This redirects IPRs to the active IprMgrImpl object for client users of both the IprMgr and IPRClient interfaces.

The Event Manager subsystem is used within the IPR subsystem to distribute IPRs. This allows IPRs to be forwarded to multiple destinations. By using Event Manager, additional IPR functions can be easily added to the system without any interface changes. The IPR subsystem event manager mechanism is currently being used within the telecommunications platform to provide some existing IPR services. The real-time IPR GUI 270 registers itself to receive IPRs for the purpose of displaying IPRs when they occur. The Ipr2host program 272 registers with the IPR subsystem to receive IPRs and forwards them to the host. An IPR logger can also register to receive IPRs for logging to disk.

The ipr2host program 272 is responsible for forwarding IPRs to the host. It receives IPRs from the event manager of the IprMgrImpl and formats a host message to be forwarded. All IPRs forwarded to the host use the message handler subsystem to route IPRs over the IPR_ASSERT logical connection.

The IPR subsystem has two external interfaces: the IPRClient interface 274 and the CORBA_IPR interface 276 , The IPRClient interface 276 is available for backwards compatibility with previous versions of PAConfigurable element. If the issued IPR from the IPRClient interface 274 has been converted by the IPRClient code, an IPR is issued using the IprMgrImpl CORBA interface to forward the IPR to the active IprMgrImpl object. This interface also uses the IPR directory LOCIPRDB.DSK as input to convert the old IPRs from PAConfigurable element to the current IPR subsystem format. This requires that there be a LOCIPRDB.DSK on each node that has programs that issue IPRs. The LOCIPRDB.DSK directory was used in previous versions to perform the IPR check before IPRs were forwarded to the host. The RegisterIPR utility is used to enter IPRs in the LOCIPRDB.DSK directory. The fields in the database entries include: ASCII key (IPR text), host IPR number, IPR priority, number of data words used, and data word format. To test the IPRMgr IPrs have to be defined in ipr.in, which are converted into a ciphered directory (via the utility RegisterIPR).

The IprMgrImpl interface is a CORBA IDL interface. When using this interface is issued an IPR, it is not necessary that it is entered in the directory LOCIPRDB.DSK. If that Object IprMgrImpl receives an issued IPR, it sees in its IPR directory and construct an IPR event to be issued. The IPR event contains information which was passed on by the client who issued the IPR, and information from the IPR directory. Before the issue of a IPR need IPRs are added to the IPR directory and to the MegaHub host IPR directory. The IprDriver tool is used to route IPRs to the IPR directory Add IprMgrImpl. The scripts Reformat and Reformat2 serve to assist in the Converting a VAX IPR file to a format using the IprDriver can be used to populate the IPR directory IprMgrImpl.

• 1) Die IPR GUI registriert ein Interesse am Empfang aller IPRs, die an den IPR-Ereignis-Manager gemeldet werden.
• 2) Eine Anwendung gibt einen IPR aus.
• 3) Der IPR-Ereignis-Manager leitet den IPR weiter an den Ereignis-Manager.
• 4) Der Ereignis-Manager verteilt den IPR zur IPR GUI.

13 shows the scenario in which an application issues an IPR, the IPR manager processes it, and the event manager forwards the IPR to an IPR GUI for visual display.

• 1) The IPR GUI registers an interest in receiving all IPRs reported to the IPR Event Manager.
• 2) An application issues an IPR.
• 3) The IPR Event Manager forwards the IPR to the Event Manager.
• 4) The event manager distributes the IPR to the IPR GUI.

14 is an example of a GUI screen printout of an IPR view. The IPR View GUI application offers the display of IPRs in a split window. The upper pane displays a graphical view of IPRs, with costs over time displayed on a per-category basis. The lower window shows a conventional full text / short text view of IPRs. Subcategories can be viewed, and a number of customer customizations of the ad are allowed. In addition, filtering and highlighting are available for the displayed IPRs. The communication is handled by CORBA.

Statistics Services

Data collection (DcMProcess, DcProcess)

Regarding 15 provides the data collection subsystem (DC) 298 the traffic measurement functionality for the application programs in a node. These measurements are counts recorded by the PegCounter class and the elapsed time recorded by the TimeMeter class. A test with the PegCounter 299 indirectly tests the shared memory 300 and semaphores. Client processes 301 access shared memory 300 to, and the data collection 298 collects from the shared memory 300 and sends to DCMaster 302 , All 30 Minutes sends the data collection 298 to the DCMaster 302 (in the active platform manager node) the 30-minute value of the PEG counter time slots 299 , and then the data collection sets these timeslots to zero. The active platform manager node 304 updates the standby platform manager node 306 ,

• – API-Unterstützung für PegCounter 322 und TimeMeter 324
• – Sammlung gespeicherter Daten von mehreren Knoten
• – Berichts-GUI zur lokalen Ansicht von Statistiken
• – Benutzerdefinierte Messungs-Sätze zur Kundenanpassung der Berichte

Regarding 16 provides the statistics service or data collection subsystem 320 the traffic measurement and measurement capabilities of the platform. This subsystem 320 supports the generation, collection and reporting of statistical measurements such as PEG counters, timers, threshold counters, collection and query. PEG-counter 322 and timepieces 324 are shown supported over a distributed application. From the data collection subsystem 320 implemented functions are:

• - API support for PegCounter 322 and TimeMeter 324
• - Collection of stored data from multiple nodes
• - Report GUI for local view of statistics
• - Custom measurement sets to customize the reports

Threshold counter (TCServer)

The Threshold counter subsystem can be used as a distributed Object of an Object Request Broker (ORB) can be implemented using the Orbital ORB implementation becomes. Applications are over Orbeline connected to a server object, located in the platform manager node located. The server reports passing through counter thresholds to applications over the Distributed Object Messaging Environment (DOME). The server objects are generated by the threshold counter server process, TCServer. Every TCServer process also communicates with the TC servers via Orbeline on remote nodes, allowing the meters to synchronize across the sites can be. The TC server stops all counters in a persistent store, what is it the permanent directory uses that in the general services library as a template class RepShmDict is provided.

17 shows the communication paths between application processes 340 and the counter server processes. The TCServer process 342 communicates with application processes 340 both about Orbeline 344 , as well as DOME 346 , The TCServer process 342 runs in an orbital-impl_is_ready loop and waits for service requests either from application processes 340 or from a TCServer process 342 on another node. He makes a DOME RegServ call to application processes 340 informing that a counter has reached its threshold.

Regarding 18 hides the API of the threshold counter subsystem 360 the Orbeline specific parts of the implementation before the application programmer. Instead, the client side of the subsystem consists of two levels: a level independent of ORB 362 and an ORB-dependent level 364 , Although the Orbeline-specific implementation of the subsystem is hidden from the application programmer, it does not become the distributed nature of the subsystem. To minimize the time required to increment counters, counter increments are buffered in the API and sent to the server in batches. This means that the application is unable to receive an immediate message about the success or failure of some operations on the API objects.

Communication services

Message Handling (MsgHand, LinkXXX)

• – Allgemeine Schnittstelle für mehrere Protokolle
• – TCP/IP 374
• – UDP/IP 376
• – DECNET 378
• – Eine einzige Zugangs-Kennung (Name der Gruppe logischer Verbindungen) für mehrere Verbindungen mit demselben Ziel.
• – Redundante Verbindungs-Verwaltung (Verbesserung der Skalierbarkeit)
• – Wiederanlauf nach Verbindungs-Fehlern
• – Asynchrone Empfangs-Schnittstelle

As in the 19 and 20 shown, provides the message handling subsystem 370 message-based interprocessor communication services. All inter-process communication between processes on the server node is generally handled via the in 21 Distributed Object Messaging Environment (DOME) shown 372 executed. DOME 372 uses the message handling subsystem 370 when information about node boundaries needs to be exchanged. The message handling subsystem 370 is also used for communication to external systems that are not servers, such as the SCP host. The message handling subsystem 370 implements the following functions.

• - Common interface for multiple protocols
• - TCP / IP 374
• - UDP / IP 376
• - DECNET 378
• - One access identifier (logical group name) for multiple connections with the same destination.
• - Redundant connection management (scalability improvement)
• - Restart after connection errors
• - Asynchronous receive interface

Services for distributed objects

Regarding 21 is DOME 372 a client / server interface used for interprocess client / server communication. It contains server interfaces 382 It's server processes 382 allow objects and members functions for use by client processes 384 to register. DOME 372 contains a shared memory database 380 to save the server descriptions, and a single process DOMEServices (domeSrv), which maintains the server object descriptions of other nodes. It also contains client interfaces 384 that provide access to each server object registered in the DOME database of the node.

• – Verwaltung der Namen registrierter Objekte über Knoten und Standorte
• – Priorisierte Behandlung von Anforderungen
• – Routing von Anforderungen aktiver/Standby-Objekte
• – Routing der Anforderungen von Objekten mit Lastaufteilung
• – Routing der Anforderungen von Broadcast-Objekten
• – Blockierende/Nicht-blockierende Objekt-Anforderungen

The interprocess communication subsystem consists mainly of DOME. DOME provides the ability for a process to register a server object and its methods in a way that allows other processes in the system to call those methods. DOME supports several types of registration and access, including special routing options that help develop error-prone software. The functions implemented by the interprocess communication subsystem include:

• - Manage the names of registered objects via nodes and locations
• - Prioritized treatment of requirements
• - routing of active / standby requests
• - Routing the requirements of objects with load sharing
• - Routing the requirements of broadcast objects
• - Blocking / non-blocking object requests

General services

• – Kommandozeilen-Objekt
• – Trace-Objekt
• – Shared Memory Objekt
• – Semaphor-Objekt
• – Keyed Dictionary Objekt
• – Listen-Objekt
• – Replicated Keyed Dictionary Objekt
• – Shared Memory Dictionary Objekt
• – usw.

The general services subsystem provides a library of programming tools to support the rapid development of processes that are being developed for execution at or at the platform level. The functions implemented by the subsystem of common utility programs include:

• - Command line object
• - Trace object
• - shared memory object
• - Semaphore object
• - Keyed Dictionary object
• - List object
• - Replicated Keyed Dictionary object
• - Shared Memory Dictionary object
• - etc.

DbgTrace object

Regarding 22 offer the DgbTrace functions 400 the ability to output trace messages to a trace buffer, to a file, and / or to standard error output.

The trace data can be entered in two different formats: standard print format and a data buffer output format. A mask 402 can be used to filter out different levels of messages. There is 32 possible masking levels for each DgbTrace group.

• – Setzen/Holen der Maske 402 für eine DgbTrace-Gruppe 400.
• – Setzen/Holen der Größe des internen Nachrichten-Puffers 410.
• – Holen einer Liste vorhandener Gruppen.
• – Ein-/Ausschalten der Anzeige zur Standard-Fehlerausgabe.
• – Ein-/Ausschalten der Ausgabe von jeweils einem Trace zu einem Zeitpunkt in eine Datei.
• – Freigabe/Sperren der Fähigkeit, Traces in eine Datei auszugeben, bevor sie überschrieben werden.

The DgbCntl interface 404 is the control interface for DgbTrace objects 400 , It allows users to many different aspects of the DgbTrace function 400 to specify. This interface allows users to do the following things with DgbTrace objects 400 perform:

• - Set / get the mask 402 for a DgbTrace group 400 ,
• - Set / get the size of the internal message buffer 410 ,
• - Get a list of existing groups.
• - Switching the display on / off for the standard error output.
• - Enable / disable the output of one trace at a time to a file.
• - enabling / disabling the ability to dump traces to a file before overwriting them.

A DbgDisk interface allows users to specify in which file the trace buffer 410 is written on all write requests.

The DgbTrace function 400 allows users to use different DgbTrace objects 400 which may each belong to one or more groups. This allows users to have a unique mask value for each group. All via the DgbTrace interface 400 output traces are stored in an internal message memory. Users can also specify whether traces should be output to the standard error output in addition to the internal buffer.

Trace object

The Trace object gives the user the ability to optionally trace messages to output to the standard error output. If the user has a Trace outputs a mask specifying the trace level represents for the this trace is output. The trace interface allows it the user to specify a mask containing all instances of Will use trace in this UNIX process to determine whether the trace message is to be output or not. The trace mask can support eight unique mask values.

Directory management system

Regarding 23 , Directory Management provides classes that are designed to support storage and access to data. Directories can be stored on disk (permanently) or in memory. Directories can also be private (used only by local processes) or shared (accessible to multiple processes). The purposes of these directories are defined by the application program. The primary interaction between DmsMaster 430 and DmsServer 432 is that DmsMaster 430 the DmsServer 432 updated when it receives an update message from the application. DmsMaster 430 runs as Active / Standby in the Platform Manager node, and DmsServer 432 runs in all (or a subset of) IPUs.

Event Services

Event Services provide the opportunity special, for a task under loosely coupled processes adds important events produce and distribute. An example of an event is the termination an input / output transfer. The event services can be a CORBA based interprocess communication function. It uses standard CORBA requests that cause an operation to be performed to lead an object. This is done by the event manager implementation program.

By doing two separate roles for Objects are defined, the communication between the objects decoupled, creating an asynchronous communication. An object is receiving and gathers new events while the other object registers an interest, these new events to be forwarded. This is achieved by two CORBA classes, EventManager and EventReceiver. EventManager provides an interface definition language (IDL) interface to receive new events. EventReceiver provides an interface definition language interface for clients, who are interested in receiving events.

Software and hardware representation

24 shows the hardware view of a telecommunication platform system. At the highest level, a telecommunications platform system consists of one or more sites 440 , Within a location 440 are several nodes 442 available.

The software representation is a hierarchy that allows components of the software to be grouped together. 25 shows this hierarchy. An application 450 exists at the highest level. An application 450 consists of one or more sets of configurable elements 452 consisting of one or more configurable elements 454 consist. In a system can have multiple applications 450 To be defined. All applications 450 in a system make up the software representation of a system.

In the 26 shown dynamic mapping of software to the hardware representation of a system as parts of an application 450 on knots 442 to be placed. Locations 440 contain applications 450 , applications 450 have processor service groups 456 , Processor service group 456 extend over several nodes 442 , The knots 442 have sets of configurable elements 452 that are placed on them. The configurable elements 454 are in sets of configurable elements 452 , For example, the software representation of a time-dependent routing application may have two sets of configurable elements. WestCoastSet and EastCoastSet. In WestCoastSet, the time-sensitive routing application can have all the programs that need to run on the nodes whose goal is to service calls to the West Coast. These can be database programs, connection processes, etc. that are specially configured to handle calls to the West Coast. In EastCoastSet, the time-sensitive routing application can have all the programs that need to run on the nodes whose goal is to service calls to the West Coast. The An The time-dependent routing can then be assigned to a location. Nodes on which the time-sensitive routing application will run are grouped into processor service groups. The sets of configurable elements for the application are then placed on nodes placed in a processor service group of the time-dependent routing application.

Even though several versions the present invention and its advantages have been described in detail, It must be understood that modifications, changes, substitutions, transformations, Modifications, variations and changes are made can, without departing from the scope of the teachings of the present invention, the spirit and scope of the invention being stated by the appended claims becomes.

1

• 1) Applications of the developer
• 2) Level number 1
• 3) Telecommunication Platform APIs
• 4) Level number 2
• 5) Telecommunication Platform Services
• 6) Level number 3
• 7) System interface level
• 8) operating system, network protocols, third party
• 9) Direct access

2

• 1) location
• 2) nodes
• 3) Application
• 4) CE-kit

3

• 1) SCP host
• 2) ethernet cards
• 3) UDP decnet protocols
• 4) Active
• 5) Telecommunication platform Network management-oriented Software is here
• 6) Platform Management Node
• 7) nodes
• 8) Application node 1
• 9) Application Node 2
• 10) Processor service group
• 11) One location
• 12) Application is mapped to a location
• 13) 4 different distributable CE sets
• 14) CE-kit
• 15) Application
• 16) Several copies of CE sentences are used distributed on the nodes
• 17) Exploded drawing of CE sentences
• 18) Configurable elements
• 19) additional Node configured as out of business

4

• 1) Application Services
• 2) IPR / alarm services
• 3) Statistics services
• 4) directory services
• 5) GUI services
• 6) core services
• 7) Network Management Services
• 8) Node Management Services
• 9) Services for distributed objects
• 10) communication services
• 11) General services
• 12) Event Services

5

• 1) Developer
• 2) Telecommunication Platform API
• 3) Network Management Services
• 4) Node Management Services
• 5) communication services
• 6) Host Maintenance Simulator
• 7) IPR / alarm services
• 8) Event Services
• 9) directory services
• 10) Statistical services
• 11) GUI services
• 12) Services for distributed objects
• 13) operating system, network protocols, third party
• 14) General services
• 15) Access to the operating system

6

• 1) Platform Applications
• 2) IPR / alarm package
• 3) Data collection package
• 4) Directory Management System Package
• 5) Host Maintenance Simulator Package
• 6) core
• 7) Telecommunication Platform API
• 8) Single-threaded process
• 9) Optional package

7A

• 1) PM subsystem test at the network level
• 2) PM node (active)
• 3) PM node (standby)
• 4) nodes
• 5) Application
• 6) Control (Host / ConfigMgr)
• 7) PM network test driver

7B

• 1) megahub host
• 2) Active PM node
• 3) Standby PM node
• 4) Application node

7C

• 1) transmission node, PSG and application states
• 2)
• 3) Ethernet TCP / IP
• 4) Network Management Services
• 5) Forward the status changes
• 6) notification about status changes
• 7) Determination of PSG and application states
• 8) Notification of changes
• 9) Platform Management Node
• 10) Sending node state changes
• 11) Node Management Services
• 12) Determine the node execution level
• 13) Notification of changes
• 14) Orders changes
• 15) Notification about error
• 16) Forwards notification
• 17) Generates CE status changes
• 18) Application node

7D

• 1) Process interaction of the TP core services
• 2) Runs on all nodes
• 3) Remove, restore, (test) node
• 4) megahub host
• 5) node status
• 6) node status change
• 7) node / link status change
• 8) Change the CE status; Connection status change
• 9) remove, restore, connection
• 10) Connection status
• 11) Remove, Restore, CE
• 12) CE status
• 13) CE status; Heartbeat, answer to review
• 14) Remove, Restore, CE; Heartbeat, answer to review
• 15) CE error
• 16) Remove, restore, connection
• 17) Connection status change

8th

9A

• 1) Copy script
• 2) sources
• 3) Tcl descriptor
• 4) 1.

9B

• 1) Starts SM as part of OS initialization
• 2) SM starts / initializes CE
• 3) Starts PRE-MIN CE
• 4) SM starts / initializes CE
• 5) CreateCE (others)
• 6) CE status changes
• 7) node status change (MIN-SET)
• 8) Network status of all nodes and time
• 9) Node / PSG / Application Status
• 10) PM node
• 11) Host or PM node
• 12) All nodes

9C

• 1) SM starts / initializes CE
• 2) CE status changes
• 3) List of ISV CEs
• 4) Restore request
• 5) node status change (ISV)
• 6) Node / PSG / Application Status
• 7) PM node
• 8) Host or PM node
• 9) All nodes

9D

• 1) Automatic recovery (AUTO RESTORE)
• 2) Manual Restore (MANUAL RESTORE)
• 3) Manual release (MANUAL ENABLE)
• 4) SM starts / initializes CE
• 5) SM releases CE
• 6) NetPM calls CreateCE for POST-ISV CEs on for Applications with permanent state 1-OOS
• 7) CE status changes
• 8) NetPM calls CreateCE for the requested application
• 9) NetPM calls EnableCE for the requested application
• 10) All nodes
• 11) PSG / Application Status
• 12) Restore request
• 13) Release request
• 14) PM node
• 15) Host or PM node

10

• 1) External requirement
• 2) I - Waiting (Idle) E - Released (Enabled) D - locked (Disabeled) S - switched off (Shut down) U - Unlocked L - Locked (Locked) X - Any
• 3) * This message will only be sent if the auto-unlocked status is on AUTO_UNLOCKED is set

11

• 1) Notify
• 2) Register
• 3) Generate event
• 4) spend IPR
• 5) Application program
• 6) Event :: Receiver (Node status change)
• 7) Event :: Receiver (IPR notification)
• 8) Generate event

12

• 1) Send to the host
• 2) Register
• 3) receiving
• 4) Monitor
• 5) Active PM node
• 6) Standby PM node
• 7) Output
• 8) Requests issued by client processes become the IprMgr forwarded in the active PM
• 9) CORBA I / F IPR Client I / F Wrapper old application
• 10) CORBA I / F New application
• 11) CORBA I / F IPRClient wrapper old library New application

13

• 1) application

14

• 1) Main window of the IPR browser
• 2) IPR category overview
• 3) IPR control
• 4) time

15

• 1) PM node (active)
• 2) PM node (standby)
• 3) Sends data
• 4) Application node
• 5) Updated
• 6) Collect
• 7) Shared storage
• 8) PEG counter (consists of 12 five-minute time slots)
• 9) (60 minutes in total)
• 10) Access

16

• 1) control (PM)
• 2) Application (user)
• 3) DC test driver process
• 4) PEG counter directory
• 5) Timing directory

17

• 1) PM node for SCP1
• 2) TC server process
• 3) TC server requirements
• 4) Counter Threshold Messages
• 5) Application node
• 6) Application
• 7) PM node for SCP2

18

• 1) application
• 2) application code
• 3) Independent of ORB Threshold counter subsystem objects (ThresholdedCouterStore, ThresholdedCounter)
• 4) Dependent on ORB Threshold counter-storage client (OrbThresholdedCouterStore)
• 5) PM node
• 6) Dependent on ORB Threshold counter storage server (OrbThresholdedCouterStore)

19

• 1) Sends outgoing messages to the host or to another node
• 2) shared memory (list of logical connections)
• 3) MH generates the connection processes
• 4) The processes LinkXXX handle incoming messages from Host or from other nodes

20

• 1) MH test driver
• 2) Application (User) and Control (PM)

21

• 1) DOME subsystem Local node client requests / responses
• 2) Control interfaces
• 3) DOME test driver
• 4) incoming messages
• 5) Shared storage
• 6) Remote node client requests / responses
• 7) Outgoing messages
• 8) Control interface

22

• 1) Application process
• 2) "Group A"
• 3) Insert
• 4) Put
• 5) Trace buffer
• 6) "Group B"
• 7) Empty the buffer
• 8) Mask
• 9) Get

23

• 1) counterpart
• 2) Update
• 3) control (PM)
• 4) Application (user)
• 5) Directory Management Test Driver Process

24

• 1) LOCATION: scp n
• 2) nodes

25

• 1) application
• 2) CE-Kit 1
• 3) CE sentence n

26

• 1) LOCATION: scp n
• 2) Application 1
• 3) Application 2
• 4) node 1
• 5) Node n
• 6) CE-Kit 1
• 7) CE sentence n

Claims (18)

A method of providing a software interface between application programs that perform telecommunications functions and an operating system that runs on at least one node at a location that supports the application programs, and further provides an interface between the application programs and a telecommunications network, characterized by providing a network platform manager ( 104 ), which is able to take nodes out of service, put nodes back into service and take applications out of service and put applications back into service; Provision of a System Network Integrity Manager ( 106 ) which is capable of monitoring the nodes and allowing failed nodes to restart; Provision of a configuration manager ( 108 ) capable of interfacing with a host coupled to the telecommunications platform; Provision of a Node Platform Manager ( 112 ) capable of providing management functions for a node; Provision of a service manager ( 134 ), which is able to start and stop processes at the direction of the node platform manager, and to provide a node integrity manager ( 130 ), which is able to monitor connections between the nodes. The method as set forth in claim 1, which further comprises: Providing an event manager, which is able to register client processes receiving events want; and Providing an event receiver that is able to provide an interface for client processes, which are registered to receive events. The method as set forth in claim 1, which further includes providing a timer manager, which is able to provide date and time functionality. The method as set forth in claim 1, which further comprises: Providing a PEG counter process, which is capable of counting special events occurring over several nodes; provision a time measurement process that is capable of measuring the duration of a to sum up to a special event; Providing a Data collection process that is able to counter data in a node to collect and store the collected data. The method as set forth in claim 1, which further comprises: Execution of a bootstrap script; begin a service manager according to the bootstrap script; By the service manager Start a node platform manager for one Node; Through the service manager, start operating state PRE-MIN configuration items for the Node; Through the service manager, start operating state OS-MIN configuration items for the Node; and Extension of a state of the node as a reaction to the OS-MIN configuration elements in the node. The method as set forth in claim 1, further comprising: Monitoring and detecting an error in a configurable element; Message the error to the service manager; By the service manager, generating a state change for the configurable item and forwarding the message to the node system integrity manager; Through the Node System Integrity Manager, forward the message to the Node Platform Manager; By the node platform manager, determining the node state in response to the failed configurable element; and by the node platform manager notifying the network platform manager of a change in state of a node. The method as set forth in claim 6, which further comprises: Through the Network Platform Manager Determination of a state change in an application that has the failed configurable element has, and a state change in a processor service group that has the application that has the failed configurable element; and Message everyone change in condition to the configuration manager. The method as set forth in claim 7, this continues through the configuration manager's redirect a node, processor service group application state change to a host. The method as set forth in claim 1, which further comprises: With an event manager through an application registration of interest, a specific Receive element; By sending the event receiver of the special event to the registered application. A telecommunications platform that interfaces between application programs that perform telecommunications functions and an operating system that runs on at least one node in a location that supports the application programs, and that further interfaces between the application programs and a telecommunications network, characterized by : A Network Platform Manager ( 104 ), which is able to take nodes out of service, put nodes back into service and take applications out of service and put applications back into service; A network system health manager ( 106 ) which is capable of monitoring the nodes and allowing failed nodes to restart; A configuration manager ( 108 ) capable of interfacing with a host coupled to the telecommunications platform; A node platform manager ( 112 ) capable of providing management functions for a node; A service manager ( 134 ), which is able to start and stop processes at the direction of the node platform manager, and a node integrity manager ( 130 ), which is able to monitor connections between the nodes. The telecommunication platform as in claim 10, which further comprises: a Event Manager, which is able to register client processes that have events want to receive; and An event receiver that is able to an interface for To provide client processes that receive events are registered. The telecommunication platform as in claim 10, which further includes a timer manager, which is able to provide date and time functionality. The telecommunication platform as in claim 10, which further comprises: a PEG-counter process, which is capable of counting special events occurring over several nodes; One Timing process that is capable of the duration of a specific Sum up event; A data collection process that is able to counter data to collect in a node and to save the collected data. The telecommunication platform as in claim 10, which further comprises means for: Execution of a Bootstrap script; Start a service manager according to the Bootstrap script; By the service manager launching a node platform manager for a node; By the service manager, starting operating state PRE-MIN configuration elements for the node; By the service manager, starting operating state OS-MIN configuration elements for the node; and extension a state of the node in response to the OS-MIN configuration elements in the node. The telecommunication platform as in claim 10, which further comprises means for: monitoring and detecting an error in a configurable element; report the error to the service manager; By the service manager Generation of a state change for the configurable element and forwarding the message to the Node System Integrity Manager; By the Node System Integrity Manager Forwarding the message to the node platform manager; By the node platform manager determining the node state as Reaction to the failed configurable element; and By the node platform manager notifies the network platform manager of a change the state of a node. The telecommunication platform as in claim 15, which further comprises means for: By the network platform manager determining a state change in an application that has the failed configurable element has, and a state change in a processor service group that has the application that has the failed configurable element; and Message everyone change in condition to the configuration manager. The telecommunication platform as in claim 16 announced that will continue to contain funds to the configuration manager a node, processor service group application state change to forward to a host. The telecommunication platform as in claim 10, which further comprises means for: With an event manager through an application registration of interest, to receive a particular element; By sending the event receiver of the special event to the registered application.